J’ai du faire quelques modifications d’un firewall qui n’était pas géré par mes soins. Il y avait un souci, car ce serveur est censé faire office de service NTP pour le réseau interne, mais ce n’est pas le cas. A partir d’une machine cliente, j’ai une erreur type « no server suitable for synchronization found » lorsque j’effectue un ntpdate. Voici la résolution du problème et quelques pistes…

Test à partir du client :

# ntpdate ntp
18 Sep 10:59:56 ntpdate[29280]: no server suitable for synchronization found
# ntpdate 0.pool.ntp.org
18 Sep 11:00:35 ntpdate[29337]: adjust time server 213.189.188.3 offset 0.002201 sec

Le client ne se met pas à jour à partir de notre serveur NTP. On essaye avec quelques détails :

# ntpdate -dv ntp
18 Sep 11:25:10 ntpdate[31272]: ntpdate [email protected] Sat Nov 23 18:21:48 UTC 2013 (1)
Looking for host ntp and service ntp
host found : ntp.local
transmit(192.168.78.100)
receive(192.168.78.100)
transmit(192.168.78.100)
receive(192.168.78.100)
transmit(192.168.78.100)
receive(192.168.78.100)
transmit(192.168.78.100)
receive(192.168.78.100)
192.168.78.100: Server dropped: strata too high
server 192.168.78.100, port 123
stratum 16, precision -22, leap 11, trust 000
refid [192.168.78.100], delay 0.02576, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Mon, Jan  1 1900  0:09:21.000
originate timestamp: d7c52376.872fab9b  Thu, Sep 18 2014 11:25:10.528
transmit timestamp:  d7c52376.87c1034c  Thu, Sep 18 2014 11:25:10.530
filter delay:  0.02585  0.02577  0.02579  0.02576
0.00000  0.00000  0.00000  0.00000
filter offset: -0.00234 -0.00236 -0.00234 -0.00236
0.000000 0.000000 0.000000 0.000000
delay 0.02576, dispersion 0.00000
offset -0.002363

18 Sep 11:25:10 ntpdate[31272]: no server suitable for synchronization found

stratum 16 est anormalement élevé. Ce chiffre représente la précision de l’horloge. Plus petit il est, mieux c’est. Mais s’il est à 16 alors le serveur NTP ne sera jamais utilisé.

 

Sur le serveur de temps la configuration à l’air correcte :

# cat /etc/default/ntp
NTPD_OPTS='-g'

 

# grep -v '^#' /etc/ntp.conf

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 0.be.pool.ntp.org
server 1.be.pool.ntp.org
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

 

En utilisant l’outil ntpq, on voit que le serveur s’interroge… Lui-même !

# ntpq -n
ntpq> pe
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
192.168.78.100   .INIT.          16 u    -   64    0    0.000    0.000   0.000

C’est là qu’est situé l’erreur. Pour plus d’informations sur la commande ntpq, le site d’Oracle y consacre une page.

 

Il y a un souci quand on regarde le fichier de configuration du processus ntpd en cours :

# ps aux | grep ntp
ntp      20613  0.0  0.0  27092  1956 ?        Ss   11:36   0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 103:107

La machine lors de son installation était en DHCP, et a obtenu l’IP du serveur NTP… Contenu dans :  /var/lib/ntp/ntp.conf.dhcp

Dans le man de ntpd, aucune information n’est donnée sur ce fichier, qui est pris par défaut s’il existe, même si /etc/ntp.conf est configuré!

       -c conffile
              Specify the name and path of the configuration file, default /etc/ntp.conf

Cela vous évitera peut-être de perdre votre temps inutilement….