Problèmes NTP

ntpdate ne marchait pas, mais maintenant j'utilise ntpdate -u S005 (bien que je ne sais pas à quoi ça correspond) et il marche.

voici le contenu de mon fichier ntp.conf:

logfile all
logfile /var/log/ntpd.log
server S005
driftfile /etc/ntp/drift
multicastclient
braodcastdelay 0.008
authenticate no

mon problème c'est que lorsque je fais un ntpq -p, j'ai ceci :

remote     refid    st  t    when    poll    reach   delay    offset    jitter 
========================================
S005     0.0.0.0   16  u   -            64     0      0.000   0.000  4000.00 

et là je vois qu'il n'y a pas d'etoile devant S005 alors qu'il devrait y en avoir un pour signifier que tous ce passe bien et qu'il est bien le serveur auquel je me synchronise. pourquoi n'ya t-il pas d'etoile et comment on fait pour qu'il y en ai un ?

merci

oui mais là rien est bloqué entre les deux

"ntpdate peut être lancé pour utiliser un port "non-privilégié" avec l'option -u que tu as utilisée"
je comprend pas grand chose à cette phrase, toujours est-il que mon offset s'eloigne de plus en plus de 0, c'est aussi un problème de firewall ? et mon fichier ntp.conf, il est correct ?

Les ports "non-privilégiés" sont les ports supérieurs à 1023.

Les ports en dessous de 1024 sont ceux sur lesquels tournent des services "importants" (tu as une liste des ports et des services correspondants au dessus et en dessous de cette limite dans ton fichier /etc/services).

Pour tester, ferme les firewall sur le serveur et sur le client (s'il est activé), et reteste (le démon ntp devrait synchroniser, pour aller plus vite essaye ntpdate sans l'option "-u", celà devrait marcher).

Remets les firewalls en marche en commençant par le serveur et reteste, puis le client et resteste.

Etant sous FreeBSD, je n'utilise pas IPTables. D'après ce que j'ai vu il semblerait que les règles à intégrer à IPTables doivent ressembler à çà :

/sbin/iptables -A INPUT -p udp --dport ntp -j ACCEPT
/sbin/iptables -A INPUT -p udp --sport ntp -j ACCEPT

A vérifier donc... Ainsi le firewall laisse passer les paquets destinés au port 123 et provenant d'un port 123. Bien sûr, tu peux renforcer les restrictions en rajoutant des conditions pour que n'importe qui n'accède pas au service ntpd.


Dal

je viens de comprendre pourquoi ça marchait pas. mon linux se trouve sur un VmWare Workstation, et donc peut etre qu'il a des problèmes au niveau des paquets NTP ?

j'ai vu quelque part que vmware "casse" les paquets. c'est peut etre à cause de ça ?

Salut Sonya,

Je ne connais pas vmware, désolé.

En faisant abstraction du fait que tu tournes sur wmware, pour moi, celà ressemble à un problème de firewall, étant donné que "ntpdate -u" fonctionne...

Mais là, je suppose qu'il peut y avoir une montagne d'autres explications possibles. Tu devrais chercher sur http://www.vmware.com/support/ les docs, faq, forums et newsgroups indiqués.

Je suppose aussi que si ton Windows sur lequel vmware est exécuté fait déjà tourner un service de synchronisation de temps, celà peut aussi occasionner des problèmes.


Dal

merci mais ma machine windows host n'est pas du tout raccordé à un service de synchro quelconque

tu pense que c'est un problème de firewall, mais j'ai demandé aux administrateurs et ils me disent qu'il n'y a pas de firewall bloqué.

autre problème que je n'arrive toujours pas à résoudre: toujours la même ligne log tous les heures:

15 Feb 09:00:25 ntpd[956]: offset 0.000000 sec freq 0.000 ppm error 0.000015 poll 4

15 Feb 10:00:25 ntpd[956]: offset 0.000000 sec freq 0.000 ppm error 0.000015 poll 4

15 Feb 11:00:25 ntpd[956]: offset 0.000000 sec freq 0.000 ppm error 0.000015 poll 4

Je ne connais pas wmWare. Comme c'est un émulateur ou une couche d'interface, je ne suis pas sûr que toutes les fonctions soient emulées.
j'ai vu quelque part que vmware "casse" les paquets :
les paquets du serveur de temps sont reçus par la pile IP de Windows qui ne sait peut être pas quoi en faire.

L'horloge de Linux peut-être celle de l'OS qui tourne en dessous.

Pour ta ligne [ntp] dans les logs, je n'ai pas grand chose dans les logs de NTP. sauf les démarrages du daemon. Benoît

merci

Pour ta ligne [ntp] dans les logs, je n'ai pas grand chose dans les logs de NTP. sauf les démarrages du daemon.

et connaitrais-tu pas l'interprétation de ces lignes ou ce qu'ils signifient ?

15 Feb 10:00:25 ntpd[956]: offset 0.000000 sec freq 0.000 ppm error 0.000015 poll 4

Sonya,

La ligne de tes logs indique une "erreur 0.000015" semble-t-il, qui a probablement la même cause que l'échec de ntpdate sans l'option -u (si tu veux vraiment savoir, essaye de trouver la signification de cette erreur dans la doc ntpd, j'ai cherché rapidement mais rien trouvé sur les codes d'erreur... s'il n'y a rien dans la doc, il faut rtfs, bon courage :).

Apparemment tu n'as pas accès à l'administration du serveur sur lequel se trouve ton serveur de temps. Sais-tu si d'autres machines de ton réseau arrivent à se synchroniser avec le même serveur ? Comment ?

Comme je te l'ai dit la particularité de la synchronisation sur la machine cliente avec le démon ntpd est que la communication doit être ouverte pour le trafic UDP destiné au port 123 *et* provenant du port 123. Es-tu sûre et certaine que tes administrateurs n'auraient pas "oublié" d'autoriser le trafic *dans les deux sens* sur le serveur ?

En attendant, tu peux toujours te synchroniser avec "ntpdate -u", en mettant une tâche cron qui effectue cette synchronisation à des heures que tu peux définir.

Bien évidemment, pour que ta machine windows synchronise, il faudra que vmware soit systématiquement lancé... ce qui est, entre nous, un peu lourd, juste pour synchroniser une horloge.

Tu pourrais simplement utiliser un client Windows ntp pour le faire. Voir http://www.commentcamarche.net/forum/affich-1232431-CRON#17 pour une récente discussion sur le sujet.


Dal