Ntpdate no servers can be used + heure erronée VPS linux

Support Debian
#1

Bonjour, j’ai loué un vps linux il y a peu pour y installer un site. Sauf que l’heure UTC du VPS avance de 6h (très pratique --’)
Après quelques recherches, j’installe ntpdate et le configure, puis j’entre # ntpdate fr.pool.ntp.org
Là impeccable, je vois le message
30 Aug 13:55:51 ntpdate[2911]: step time server 188.165.242.229 offset -20767.527809 sec
Sauf qu’un rapide test avec # date m’affiche :
Tue Aug 30 19:42:58 CEST 2016
Et # date -u :
Tue Aug 30 17:43:42 UTC 2016
Et quand je rentre # ntpdate cela me donne
30 Aug 19:45:03 ntpdate[2915]: no servers can be used, exiting
Auriez vous une idée de la provenance du problème ? et surtout comment le solutionner ?
(je rappelle que je suis sur un VPS loué et je n’ai donc pas accès à l’horloge BIOS pour la recaler, pas les droits suffisants)

#2

C’est normal, ntpdate n’utilise pas la configuration de ntp, il faut lui donner un serveur en paramètre.

Il faut signaler le problème à ton fournisseur, si tu n’as pas les accès pour corriger ce problème.

#3

Déjà merci de la réponse rapide.

Hem, je suis un novice et je ne vois pas trop comment faire…
Pourrais-je avoir quelques précisions s’il vous plait ?

Chose déjà faite, mon hébergeur est cloud4you, mais j’ai plutôt l’impression de lancer des bouteilles à la mer, ça fait deux tickets en 4 jours que j’envoie… alors que le support est garanti 24/7

#4

La première chose que je vérifierais dans ton cas, c’est la configuration du fuseau horaire. Si la machine pense qu’elle sur la côte est des USA, elle est à la bonne heure. Que renvoie la commande timedatectl ?

#5

Tu vas rire (ou hurler) mais…
Command not found

#6

Bon, c’est pas grave, c’est juste que l’OS n’est pas sous systemd (ce qui n’est pas forcément une mauvaise chose ;-)). Alors essaie en root : dpkg-reconfigure tzdata.

P.S. : ntpdate est obsolète. Il est recommandé de n’utiliser que ntp.

#7

J’avais déjà fait une reconfiguration avec cette commande, je viens d’en refaire une au cas où.
Rien à faire, je sélectionne Europe puis Paris, mais toujours un magnifique décalage de 6h…

#8

Bon. Et avec ntp -gq ?

#9

ntp est bien installé mais aucune commande ntp ne répond (not found)

#10

Pardon, ntpd -gq.

#11

J’obtiens ntpd: time set -20767.510989s

#12

Et l’heure ?

#13

Avec cette commande je n’obtiens pas d’heure
Avec un date, Tue Aug 30 20:28:01 CEST 2016

#14

Bon, je suis à cours d’idée, désolé :frowning: . À moins que ton fournisseur ne te bloque sur une “fausse” horloge système (tu peux vérifier du côté de fake-hwclock), je ne vois pas.

#15

Merci quand même de l’aide ^^
Du côté de fake-hwclock, command not found

hwclock, j’y ai logiquement pas accès.
Le premier truc auquel j’ai pensé, c’est que mon hébergeur laisse les horloges BIOS de ses machines se décaler allègrement, ce qui expliquerait cela.
Malheureusement le support de Cloud4You 24/7 c’est… disons largement surfait, et je sens qu’à tous les coups ils vont me répliquer que le problème ne vient pas de chez eux mais de moi…

#16

Et le no servers can be used, ce serait pas un problème de pare feu et de port, genre le pare feu bloque l’arrivée des données ?

#17

Tiens ya du nouveau, les serveurs sont maintenant à la bonne heure… mais avec un jour d’avance…
Je ne sais pas si ça vient de moi qui ai fait un date -s et redémarré ou si c’est Cloud4You qui a réajusté ses horloges BIOS mais avec un jour d’avance… Quelle bande de branquignolles…

#18

Update :
Quand je tape # ntpdate -d 0.fr.pool.ntp.org

J’obtiens quelque chose comme
`1 Sep 09:34:43 ntpdate[2957]: ntpdate 4.2.6p5@1.2349-o Fri Jul 22 17:24:22 UTC 2016 (1)
transmit(62.4.12.66)
receive(62.4.12.66)
transmit(176.31.109.39)
receive(176.31.109.39)
transmit(51.255.119.22)
receive(51.255.119.22)
transmit(62.210.211.218)
receive(62.210.211.218)
transmit(62.4.12.66)
receive(62.4.12.66)
transmit(176.31.109.39)
receive(176.31.109.39)
transmit(51.255.119.22)
receive(51.255.119.22)
transmit(62.210.211.218)
receive(62.210.211.218)
transmit(62.4.12.66)
receive(62.4.12.66)
transmit(176.31.109.39)
receive(176.31.109.39)
transmit(51.255.119.22)
receive(51.255.119.22)
transmit(62.210.211.218)
receive(62.210.211.218)
transmit(62.4.12.66)
receive(62.4.12.66)
transmit(176.31.109.39)
receive(176.31.109.39)
transmit(51.255.119.22)
receive(51.255.119.22)
transmit(62.210.211.218)
receive(62.210.211.218)
server 62.4.12.66, port 123
stratum 2, precision -23, leap 00, trust 000
refid [62.4.12.66], delay 0.03043, dispersion 0.00000
transmitted 4, in filter 4
reference time: db710095.44543da7 Wed, Aug 31 2016 9:07:01.266
originate timestamp: db710700.981e762d Wed, Aug 31 2016 9:34:24.594
transmit timestamp: db725899.b8087c8c Thu, Sep 1 2016 9:34:49.718
filter delay: 0.03061 0.03067 0.03046 0.03043
0.00000 0.00000 0.00000 0.00000
filter offset: -86425.1 -86425.1 -86425.1 -86425.1
0.000000 0.000000 0.000000 0.000000
delay 0.03043, dispersion 0.00000
offset -86425.127118

server 176.31.109.39, port 123
stratum 3, precision -22, leap 00, trust 000
refid [176.31.109.39], delay 0.02739, dispersion 0.00000
transmitted 4, in filter 4
reference time: db7105c9.34968798 Wed, Aug 31 2016 9:29:13.205
originate timestamp: db710700.cac19a9b Wed, Aug 31 2016 9:34:24.792
transmit timestamp: db725899.eb3b0774 Thu, Sep 1 2016 9:34:49.918
filter delay: 0.03175 0.02820 0.02769 0.02739
0.00000 0.00000 0.00000 0.00000
filter offset: -86425.1 -86425.1 -86425.1 -86425.1
0.000000 0.000000 0.000000 0.000000
delay 0.02739, dispersion 0.00000
offset -86425.127816

server 51.255.119.22, port 123
stratum 3, precision -23, leap 00, trust 000
refid [51.255.119.22], delay 0.02792, dispersion 0.00000
transmitted 4, in filter 4
reference time: db71055e.e9d817ca Wed, Aug 31 2016 9:27:26.913
originate timestamp: db710700.fe814719 Wed, Aug 31 2016 9:34:24.994
transmit timestamp: db72589a.1e6e4745 Thu, Sep 1 2016 9:34:50.118
filter delay: 0.02798 0.02794 0.02792 0.02821
0.00000 0.00000 0.00000 0.00000
filter offset: -86425.1 -86425.1 -86425.1 -86425.1
0.000000 0.000000 0.000000 0.000000
delay 0.02792, dispersion 0.00000
offset -86425.125767

server 62.210.211.218, port 123
stratum 2, precision -25, leap 00, trust 000
refid [62.210.211.218], delay 0.03040, dispersion 0.00000
transmitted 4, in filter 4
reference time: db710549.a93b09bb Wed, Aug 31 2016 9:27:05.661
originate timestamp: db710701.31f64efc Wed, Aug 31 2016 9:34:25.195
transmit timestamp: db72589a.51a0e564 Thu, Sep 1 2016 9:34:50.318
filter delay: 0.03050 0.03046 0.03040 0.03072
0.00000 0.00000 0.00000 0.00000
filter offset: -86425.1 -86425.1 -86425.1 -86425.1
0.000000 0.000000 0.000000 0.000000
delay 0.03040, dispersion 0.00000
offset -86425.126137

1 Sep 09:34:50 ntpdate[2957]: step time server 62.210.211.218 offset -86425.126137 sec`

Il a l’air de correctement recevoir la date mais pourquoi s’amuse t’il à me coller un jour supplémentaire ?

#19

Help et Up :’(

#20

Ta situation n’a pas changé : la sortie d’ntpdate laisse penser qu’il a détecté le décalage et l’a corrigé (ton offset étant maintenant de 86425 secondes, soit 24 h), mais ça n’a au final aucune répercussion. À mon avis, la faute à ton hébergeur qui doit utiliser un autre moyen de régler l’heure, que tu ne sembles pas pouvoir outrepasser :confused:.