serveur local NTP non utilisé par les clients. Problème d'installation
J'ai un réseau local sans Internet et je veux que tous les ordinateurs restent synchronisés. Je me moque du temps absolu, il devrait être identique pour tous.
J'ai trouvé plusieurs articles à ce sujet. Les plus utiles étaient:
serveur
J'ai installé le serveur avec l'IP 192.168.1.123 et il semble fonctionner correctement: le démon "ntpd" est en cours d'exécution et j'avais ajouté dans etc/ntp.conf les lignes
# this sets the source to local time
server 127.127.1.0
fudge 127.127.1.0 stratum 8
# this makes the ntpd deamon to send out its time on the local net.
broadcast 192.168.255.255
Je l'ai vérifié avec la commande ntpq:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.255.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
"BCST" dit plus en diffusion et l'IP montre sa diffusion à tous les ordinateurs du réseau local (réseau de classe B, donc 2x 255).
client
Côté client, j’ai également installé ntp, et utilisé le fichier /etc/ntp.conf par défaut et ajouté les lignes.
server 192.168.1.123 iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 8
où 192.168.1.123 est l'adresse IP locale du serveur de diffusion et l'autre ligne doit indiquer au client (un ordinateur portable) d'utiliser sa propre horloge lorsque la connexion réseau est désactivée. J'ai redémarré le service sur le client et exécuté ntpq pour vérifier la connexion
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
En répétant cette commande, je peux voir la colonne "when" compter les deux et repartir de 0 à 64 secondes. Je pensais que cela changerait après 64 secondes:
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
Notez le "*" avant l'adresse IP du serveur. Mais ce n'était pas . Ce que j'ai eu après environ une heure était
ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.123 .INIT. 16 u 1 64 0 0.000 0.000 0.000
*LOCAL(0) .LOCL. 8 l 63 64 377 0.000 0.000 0.000
Je pense que cela me dit, il y a 2 sources pour NTP configurées, mais comme la source distante ne fonctionne pas/n'est pas disponible/quoi qu'elle ne soit pas utilisée et que l'horloge locale de la cas de repli est utilisée, mais je ne le suis pas bien sûr si cette interprétation est correcte.
ce que j'ai essayé
J'ai attendu plus d'une heure, j'ai redémarré le serveur ntpd fois avec Sudo /etc/init.d/ntp restart et j'ai également redémarré. De plus, j'ai commenté l'horloge de la section locale de sorte que le seul serveur soit server 192.168.1.123. Je ne pouvais pas faire apparaître ce "*". J'ai aussi vu une section dans le fichier ntp.conf qui disait
#if you want to listen to time broadcasts on you local subnet,
#de-comment the next lines. Please do this only if you trust
#everybody on the network!
#disable auth
#broadcastclient
J'ai essayé de commenter et de redémarrer le service mais cette étoile n'apparaissait toujours pas. Cependant, je me pose des questions sur la dernière section, car cette section est apparue dans tout autre résultat post ou internet que j'ai vu dans la configuration ntp. Il y en a plusieurs sur les configurations locales et la plupart semblent être trouvés uniquement avec l'adresse du serveur. Ping de client à serveur est bon. Il n'y a pas de pare-feu, etc.
question
Je n'ai plus d'idées. Je pense avoir un serveur avec un serveur NTP pleinement opérationnel qui envoie l'heure. Mais j'ai un client qui ne parvient pas à recevoir les informations de temps du serveur.
Que puis-je faire pour que le client fonctionne?
Le problème était résolu, le système fonctionne maintenant. Je fais ce résumé pour moi-même et pour tous ceux qui doivent configurer un serveur NTP hors ligne (à nouveau). Le problème réel semblait être que l'expérimentation avec le mode de diffusion avait cassé le ntpd sur le serveur, cela fonctionnait à nouveau sur un autre redémarrage du serveur. Pourquoi cela n’a pas fonctionné quand j’ai suivi les publications ci-dessus, je ne suis pas vraiment sûr.
Arrière-plan
Une partie du problème était que je ne comprenais pas comment NTP fonctionnait et ce que je faisais. Ni la page de manuel, ni le guide du serveur 16.04 ne donnaient une vue d'ensemble simplifiée sur les différents ordinateurs fonctionnant ensemble. D'abord, NTP client et serveur est trompeur. C'est toujours le même programme, le NTP démon, "ntpd". Il doit être installé sur chaque ordinateur du réseau local pour que la synchronisation de l’heure fonctionne. Je n'ai pas encore vérifié les clients Windows, mais je suis sûr qu'il existe une version pour eux quelque part également (veuillez commenter si vous avez des informations à ce sujet - les fonctions intégrées seraient préférées). Le système hors ligne ne fonctionnerait que sur les horloges système. Il est avantageux d’utiliser plusieurs horloges système, pas seulement le serveur principal, car chaque horloge contribue à réduire la dérive temporelle. En d'autres termes, une horloge rendrait tous les ordinateurs synchronisés, mais le temps absolu serait plus stable et précis lorsque plusieurs horloges seraient prises en compte. D'après ce que j'ai lu, 4 devrait être un bon chiffre. NTP peut agir à la fois comme serveur et comme client. Le fichier de configuration par défaut ne contient pas vraiment de section de configuration pour le rôle de serveur. En tant que modèle simple, chaque instance ntpd est un client qui obtient des informations horaires quelque part en les interrogeant régulièrement. Interrogez une autre ntpd ou interrogez l'horloge locale embarquée. Il devient un serveur quand il répond aux sondages des autres. Par exemple, un réseau connecté à Internet par un serveur proxy. Ce serveur proxy exécuterait ntpd pour interroger plusieurs serveurs Internet NTP et lui transmettrait ainsi son propre temps. Lorsque tous les clients locaux interrogent ce serveur proxy pour obtenir son heure (synchonisée) et qu'il commence à répondre aux sondages, il devient et le serveur NTP lui-même. Hors cas hors ligne est exactement cela, sauf que les serveurs en ligne sont remplacés par l'horloge intégrée.
Configuration Pour la configuration, le fichier /etc/ntp.conf doit être modifié. Le défaut est assez complet. J'ai tout supprimé sauf:
# this is the IP or name of the local networks NTP server. This line
# should be commented out on the server
server 192.168.1.111
# this enables checking the local clock. Do not change that IP values!
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# this lines are required to run the ntpq -p command to verify the
# function of the system
restrict 127.0.0.1
restrict ::1
Le serveur dans cet exemple a l'IP 192.168.1.111. Cette configuration peut être la même pour tous les ordinateurs du réseau. Ne commentez que la section horloge locale sur les clients qui ne sont pas des ordinateurs portables. La ligne doit être conservée sur les ordinateurs portables et autres périphériques pouvant fonctionner hors connexion pendant un certain temps. La première section du serveur doit être commentée sur le serveur.
Après édition, redémarrez le service avec le script start/stop
Sudo /etc/init.d/ntp restart
Pour vérifier le parcours
ntpd -p
son un peu plus court que la version dans la question et donne le même résultat. Il y a un * avant la ligne d'horloge pour indiquer qu'il est utilisé. Voici la sortie pour un serveur en fonctionnement:
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 2 1 6 64 377 0.000 0.000 0.000
Lorsque la colonne compte, la portée est égale à 0. Voici la sortie pour un client actif:
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
Si vous avez déjà refid = .INIT., cela ne fonctionne pas. Les chiffres seraient évidemment différents. Les clients ne doivent pas afficher 0.000 0.000 0.000 valeurs. Une sortie pour un client avec une horloge de secours configurée supplémentaire (notez qu'elle n'est pas utilisée actuellement - no *):
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.111 LOCAL(0) 3 u 31 64 377 0.206 -5.900 0.654
LOCAL(0) .LOCL. 8 l 6 64 1 0.000 0.000 0.000
infos ajoutées La configuration par défaut décrit un envoi en diffusion et une option de réception en diffusion. Ne l'activez pas pour un fonctionnement normal. Il n'est pas nécessaire de démarrer le système et de configurer le client et le serveur. Si quelque chose se coince, ne redémarrez pas seulement le service, mais redémarrez complètement. Même un serveur Ubuntu. Lorsque le système ne fonctionnait pas, j’ai constaté que ps -e |grep ntpshould 2 processus 'ntpd'. La paire pourrait être démarrée et arrêtée régulièrement. La version en cours d'utilisation n'en montrait qu'un sur chaque ordinateur. D'autres options de restriction et options de journalisation du fichier de configuration par défaut pourraient être utiles. Je ne les ai pas testés.
Espérons que cela deviendra utile à un moment donné. Si vous avez des corrections, veuillez commenter, je vais essayer de mettre à jour la réponse.
Homme chat
PS: Un grand merci à Ken Mollerup , dont les commentaires m'ont permis de mieux comprendre le système NTP.