Installation d’un serveur de temps sur votre réseau

Date: 16/11/2011 | Catégories: Open-source,Planet-libre,Reseau | Tags: ,,,

Dans un système d'information moderne, la synchronisation des machines sur une horloge commune est un pré-requis pour de nombreuses actions comme l'analyse des logs ou la supervision système et réseau. Si vos machines sont directement connectés à Internet alors il n'y a pas de problème car les distributions GNU/Linux, Windows et Mac OS X embarquent des mécanisme pour se mettre automatiquement à l'heure en se synchronisant sur des serveurs publics (par exemple 0.debian.pool.ntp.org sur une Debian Squeeze). Si ce n'est pas le cas et que vos machines sont isolées et/ou bien filtrées lors de leurs accès à Internet, il peut être intéressant d'installer un serveur de temps local sur une de vos machine.

Nous allons donc dans ce billet installer un serveur de temps NTP sur une machine sous Debian 6 (Squeeze).

Le protocole NTP

J'invoque le bon génie Wikipédia: "Le Protocole d'Heure Réseau (Network Time Protocol ou NTP) est un protocole qui permet de synchroniser, via un réseau informatique, l'horloge locale d'ordinateurs sur une référence d'heure."

La référence en question sera donc, dans notre cas, la machine ou nous allons installer puis configurer notre serveur NTP.

Le protocole NTP utilise le port UDP/123 pour effectuer les requêtes sur le réseau. Notre serveur sera donc en écoute sur le port UDP 123 (si vous avez un Firewall, il faudra bien entendu le configurer pour autoriser les requêtes sur ce port).

Installation du serveur NTP

On commence par installer les paquets nécessaires dans une console root:

[cc lang="bash"]

apt-get install ntp ntpdate

[/cc]

La première chose à faire est de mettre le serveur à la bonne heure (quitte à avoir une référence, autant qu'elle soit juste...).

Pour cela deux solutions:

  • si votre machine à accès à Internet, utiliser la commande "ntpdate-debian" qui va synchroniser votre machine sur les serveur NTP Debian.
  • si votre machine n'a pas accès à Internet, alors téléphoner à l'horloge parlante (numéro payant: 3699) puis configurer l'heure système avec la commande "date". Par exemple "date -s 16:56:23".

On édite ensuite le fichier /etc/ntp.conf:

[cc lang="bash"]

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.

#statsdir /var/log/ntpstats/

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

# You do need to talk to an NTP server or two (or three).

#server ntp.your-provider.example

# http://www.pool.ntp.org/zone/fr

server 0.fr.pool.ntp.org

server 1.fr.pool.ntp.org

server 2.fr.pool.ntp.org

server 3.fr.pool.ntp.org

# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will

# pick a different set every time it starts up. Please consider joining the

# pool: <http://www.pool.ntp.org/join.html>

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for

# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>

# might also be helpful.

#

# Note that "restrict" applies to both servers and clients, so a configuration

# that might be intended to block requests from certain clients could also end

# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.

restrict -4 default kod notrap nomodify nopeer noquery

restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.

restrict 127.0.0.1

restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if

# cryptographically authenticated.

#restrict 192.168.123.0 mask 255.255.255.0 notrust

# My server is a public server

restrict 0.0.0.0 mask 0.0.0.0

# If you want to provide time to your local subnet, change the next line.

# (Again, the address is an example only.)

broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the

# next lines. Please do this only if you trust everybody on the network!

#disable auth

#broadcastclient

[/cc]

Les informations intéressantes sont les suivantes:

server 0.fr.pool.ntp.org

server 1.fr.pool.ntp.org

server 2.fr.pool.ntp.org

server 3.fr.pool.ntp.org

Permet de configurer les serveurs maîtres sur lesquels votre machine va essayer de se synchroniser pour rester à l'heure. Il faut bien sûr que votre machine est accès à Internet sur le port UDP/123.

restrict 0.0.0.0 mask 0.0.0.0

On rends notre serveur public, toutes les machines ayant un accès réseau (encore une fois sur le port UDP/123) pourront se synchroniser à partir de votre serveur. Il est bien sûr possible de limiter ce droit aux seules machines de vos réseaux.

broadcast 192.168.0.255

(optionnel) Diffuse le temps sur l'adresse de broadcast de votre réseau (par exemple 192.168.0.0/24).

On relance ensuite le serveur pour que la configuration soit prise en compte:

[cc lang="bash"]

# /etc/init.d/ntp restart

Stopping NTP server: ntpd.

Starting NTP server: ntpd.

[/cc]

Synchroniser vos machines avec votre serveur NTP

La configuration des clients est relativement simple car souvent inclus dans les "wizards" d'installations. Il suffit de préciser l'adresse IP ou le nom de votre machine hébergeant le serveur NTP comme serveur de temps.

Sur un client Debian 6 existant, il faut installer le package suivant (en root):

[cc lang="bash"]

apt-get install ntpdate

[/cc]

Puis lancer la commande suivante (si votre serveur de temps est hébergé sur la machine 192.168.0.100):

[cc lang="bash"]

ntpdate -dv 192.168.0.100

[/cc]

Conclusion

Le protocole NTP étant normalisé, il est bien sur possible de synchroniser toutes vos machines (Linux, BSD, Windows, OS X...) sur votre nouveau serveur de temps.

  • Vincent

    Quel est l’intérêt d’installer ntp sur le client ?
    Le package ntpdate couplé à une tâche cron n’est-il pas suffisant ?

    • Aucune, c’est une boulette, je corrige le billet 🙂

      • Desintegr

        L’avantage d’utiliser le daemon ntp est d’éviter les sauts brusques d’horloge que fait ntpdate. Certains logiciels n’aiment pas qu’on change l’heure de façon brutale.

        Le daemon ntp essayer aussi de régler l’heure de façon progressive.

        Autre avantage, le daemon ntp permet de garder la machine à l’heure et empêche son décalage naturel. ntpdate met l’heure à jour une fois et c’est tout.

        Personnellement, je ne vois aucun avantage à utiliser ntpdate par rapport au daemon ntpd.
        La seule utilisation que je fais de ntpdate est de vérifier que la synchronisation vers un serveur fonctionne.

        Voir aussi : http://serverfault.com/questions/16467/compare-ntpd-and-ntpdate/16513#16513

  • lord

    Le client ntp mettra en permanence la machine à l’heure. On peut atteindre une précision de l’ordre de la milliseconde. Pour certaines applications critique c’est nécessaire. Pour une utilisation classique ça ne l’est pas bien entendu. Le seul soucis du client ntp c’est qu’il ne peut pas effectuer de trop gros décalages contrairement à ntpdate. Une bonne pratique est donc de lancer un ntpdate au boot (après initialisation du réseau) puis de lancer le client ntp en daemon.

  • Frans

    D’accord avec Lord, sur un client il est préférable d’utiliser le démon ntpd.
    Du côté des clients je m’embête pas, et ça marche très bien le ntp.conf contient seulement les lignes :
    server ntp1
    server ntp2 (si un deuxième serveur ntp sur le lan)

    Pour la config du serveur, bravo pour les explications.

  • Garry3D

    Un détail que tu n’as peut-etre pas testé : si tu mets ton serveur NTP à l’heure manuellement, c’est à dire qu’il n’est relié à aucune source de temps, il prendra un Stratum à 16 et aucun serveur NTP n’acceptera de se connecter dessus. Pour cela fixer le stratum manuellement dans le fichier de conf si le serveur le permet (fonctionne sur openntpd).

  • eoxo

    Il est intéressant de rajouter les options suivantes
    server 0.fr.pool.ntp.org iburst dynamic

    iburst = retry plusieurs fois si il y a pas de réponse
    dynamic = pour que les serveurs unreachable soient retestés et utilisés lorsqu’ils redeviennent up (je crois)

    sinon toujours mettre
    server 127.127.1.0 cela permet de se synchroniser en local, comme ca si on perd l’internet de notre ISP notre ntp fait toujours office de serveur de temps !

    logiquement il y a pas besoin de jouer du coté des stratums (sert pour changer la préférence des servers) par defaut la clock local a un stratum 5 (en tout cas chez moi) et ne sera utilisé quand dernier recourt mais ca peut être intéressant de noter l’option

  • Pour l’histoire du ntpdate, tu installes le paquet fait la synchro au début, par la suite pas la peine de faire dans un cron, automatiquement ntpd fera un ntpdate au démarrage

    un petit ps -aux et tu verra (si t’es rapide)
    root … /usr/sbin/ntpdate -s -b server 0.fr.pool.ntp.org server 1.fr.pool.ntp.org

    Pour compléter ton post il faut préciser que le serveur de temps marche pas direct après un restart il faut attendre quelque minute pour la synchro (a moins d’avoir une clock en local), l’état de la synchro se voit grâce à la commande ntpq -p

  • Pingback: Installation d’un serveur de temps sur votre réseau | LorfDotNet()

  • Moi je trouve effarant que des sociétés puissent survivre sans serveurs de temps interne. 🙂

    On peut rajouter que la plupart des systèmes de clusters/HA (Checkpoint, VMware, etc.) se base sur le temps pour décider d’un basculement et pour les synchro entre éléments.

    Avec le protocole DNS, je pense que NTP fait partie des services obligatoires parmi les plus importants dans un réseau.

    Sinon, je suis d’accord avec les derniers commentaires, le démon ntp vaut 100x mieux qu’un cron avec ntpdate. Certaines applis peuvent planter quand la différence de temps est trop importante.

  • jacques

    Intéressant article (ainsi que les commentaires).

    Pour situer, j’aurais indiqué qu’ActiveDir à partir de 2003 IMPOSE la synchronisation des horloges des différents DC !

    Il est important de comprendre que les horloges de TOUS serveurs est impérative : comment se retrouver dans les logs en cas d’échange entre machines ?

    Dans le sens d’utilisation de pool.ntp.org, penser à réduire à une seule machine interrogeant les serveurs de temps « public » (pour limiter les requêtes à l’utile), et penser à configurer TOUS les serveurs vers cette seule source interne. C’est possible pour les Linux avec ntpd et un « server » judicieux, mais c’est aussi possible pour des machines windows (syntaxe dépendante de la version !).

    Attention à l’utilisation de ntp dans une machine virtuelle : c’est délicat puisque des cycles sont enlevés du fait de la virtualisation : utiliser de préférence les outils du moteur de virtualisation : hôte synchronisé sur ntp, VM synchronisé sur l’hôte.

    • En effet, une VM ne se fait pas forcément allouer du temps processeur (nécessaire à l’horloge) 100% du temps (soit quand la VM n’est pas demandeuse de CPU, soit quand les ressources du host sont saturées).

      VMware propose des KB sur ce sujet :
      – pour Linux : http://kb.vmware.com/kb/1006427
      – pour Windows : http://kb.vmware.com/kb/1318

  • max

    Au risque d’enfoncer une porte ouverte… a partir de quelques machines, même sur un petit lan d’entreprise ou a titre personnel, un serveur de temps devient rapidement indispensable. Tout comme un serveur de boot PXE, dhcp et DNS d’ailleurs !

  • Vincent

    Lorsque vous parlez des machines virtuelle, c’est dans le cas d’un serveur de temps ou comme client ?
    Car j’utilise depuis plusieurs mois des clients virtuelle (qui se synchronisent sur un serveur de temps physique) et je n’ai jamais rencontré de problème de synchro.

    • Dans les 2 cas (serveurs/clients)…on ne dit pas qu’il va y avoir des problèmes, mais que c’est probable.

  • Pingback: Installation d’un serveur de temps sur votre réseau | Informatique - Memo | Scoop.it()

  • Pingback: Nono’s vrac 10 « m0le'o'blog()

  • « Le protocole NTP étant normalisé, il est bien sur possible de synchroniser toutes vos machines (Linux, BSD, Windows, OS X…) sur votre nouveau serveur de temps. »
    Comment synchroniser une machine Win avec mon serveur NTP? Merci!