Comment configurer un serveur NTP local sans accès Internet sur Ubuntu?
J'ai essayé plusieurs guides sur la façon de configurer un serveur ntp local sur ubuntu mais aucun ne semble fonctionner correctement. Mes serveurs dérivent fortement dans le temps pour une raison quelconque et je dois garder leur temps proche car je gère des bases de données qui en ont besoin.
- J'ai 8 serveurs ubuntu 14.04 LTS, aucun d'entre eux n'a accès à Internet
- Je veux exécuter un serveur ntp sur un (ou plusieurs si c'est mieux) des serveurs et que tous les autres serveurs se connectent au (x) serveur (s) ntp pour régler l'heure
Actuellement, mon serveur (ip .24) exécute ce /etc/ntp.conf:
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
# Give localhost full access rights
restrict 127.0.0.1
# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap
broadcast 192.168.178.0
Et sur les "clients":
# Point to our network's master time server
server 192.168.178.24 iburst
fudge 192.168.178.24 stratum 10
restrict default ignore
restrict ::1
restrict 127.0.0.1
restrict 192.168.178.24 mask 255.255.255.255 nomodify notrap noquery
driftfile /var/lib/ntp/drift
minpoll 4
maxpoll 5
Remarque: J'ai utilisé PuTTY à onglets multiples pour envoyer les commandes suivantes à tous les clients ntp en même temps. J'ai arrêté les services ntp pour tous sauf le serveur, utilisé Sudo ntpdate 192.168.178.24 pour les laisser récupérer la date et redémarrer les services ntp par la suite. Cela a réussi. Tous les serveurs ont affiché la même date juste après la fin de la commande. Cependant, après environ 10 minutes, mes serveurs affichent l'heure suivante:
Fr 30. Sep 11:16:53 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016 (server .24)
Fr 30. Sep 11:16:50 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:17:05 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Fr 30. Sep 11:15:33 CEST 2016
Comment les synchroniser correctement avec le serveur ntp? Et comment puis-je réduire le temps de scrutin? Il semble que mes serveurs soient rapidement désynchronisés, j'ai donc besoin d'eux pour récupérer à nouveau l'heure "correcte" ...
Par heure "correcte", je veux dire une heure identique pour tous les serveurs. Il ne doit pas nécessairement être l'heure exacte exacte du monde (si vous l'appelez ainsi).
Edit: j'ai essayé le paramètre de configuration suggéré. D'après ce que j'ai compris, voici à quoi devraient ressembler mes configurations serveur/client. En attendant, j'ai vu que mon serveur .24 dérive vers un pire moment. Le serveur .20 est le plus précis et j'utilise maintenant le serveur .20 pour héberger le serveur ntp. Désolé pour la confusion.
Configuration du serveur:
# Use the local clock
server 127.127.1.0 prefer
fudge 127.127.1.0
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
# Give localhost full access rights
restrict default
# Give machines on our network access to query us
restrict 192.168.178.0 mask 255.255.255.0 nomodify notrap
broadcast 192.168.178.0
Pour les clients:
# Point to our network's master time server
server 192.168.178.20 iburst
restrict default
driftfile /var/lib/ntp/drift
minpoll 4
maxpoll 5
ntpq -as et ntpq -pe sur le serveur:
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 41906 963a yes yes none sys.peer sys_peer 3
2 41907 8811 yes none none reject mobilize 1
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 5 l 60 64 377 0.000 0.000 0.000
192.168.178.0 .BCST. 16 u - 64 0 0.000 0.000 0.000
Cinq fois une sortie similaire comme celle-ci (ces serveurs dérivent dans le temps):
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 62104 9024 yes yes none reject reachable 2
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
hadoop20.xx LOCAL(0) 6 u 27 64 377 0.151 63591.8 33407.0
Pour deux (très probablement?) Clients actifs:
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 7757 963a yes yes none sys.peer sys_peer 3
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
*hadoop20.xx LOCAL(0) 6 u 18 64 377 0.183 7.883 3.015
modifier 2:
J'ai utilisé Sudo service ntp stop, Sudo ntpdate 192.168.178.20, attendez la fin de ntpdate, Sudo service ntp start sur tous les clients. Il n'y a toujours que 2 clients successifs et 5 clients refusants.
Les clients qui refusent affichent cette sortie. Les valeurs delay + offset semblent élevées car les clients défaillants dérivent dans le temps. Peut-être qu'ils ne font pas confiance au serveur pour mettre à jour l'heure car le délai/décalage est si élevé?
ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 20981 905a yes yes none reject sys_peer 5
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
hadoop20.xx LOCAL(0) 6 u 34 64 3 0.166 18665.9 16201.3
J'ai également essayé d'utiliser cette réponse https://askubuntu.com/a/256004 , cela fonctionne pendant environ 30 secondes, puis l'état passe à "rejeter" à nouveau! Pareil pour ntpdate -s 192.168.178.20. Cela est probablement lié au fait que les clients ntp rejettent l'heure du serveur. Y a-t-il un moyen de les forcer à changer l'heure?
Ne fais pas ça. Sérieusement. Mais ne le fais pas. Les gens continuent de penser que NTP est conçu pour permettre à un tas de machines d'avoir toutes ( la même heure ) Il ne l'est pas. Il est conçu, avec beaucoup de soin, pour permettre à de nombreuses machines d'avoir toutes la chose la plus proche possible de l'heure correcte , ce qui n'est pas la même chose.
Si vous avez accès à une fenêtre, vous pouvez créer un serveur semi-décent de la couche 1 pour environ 50 £, ou un bon pour 100 £. Vous feriez beaucoup mieux de construire quelque chose comme ça, puis dirigez les autres clients vers cela. Des horodatages corrects sont bien meilleurs que des horodateurs simplement cohérents, notamment pour la criminalistique.
Mais si vous devez absolument faire ce que vous faites, alors vous devez vous rendre compte que vous pervertissez ntpd, et cela signifie comprendre ce que vous faites.
Sur le serveur
server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 10
signifie " utilisez l'horloge locale indisciplinée comme si elle faisait autorité", c'est ce que vous voulez. Je ne sais pas pourquoi vous le forcez à la couche 10, cependant; envisagez de supprimer le stratum 10, et laissez le pilote fournir sa strate par défaut de 0. Sur les clients
server 192.168.178.24 iburst
fudge 192.168.178.24 stratum 10
cela n'a absolument aucun sens. fudge 127.127.x.y est réservé pour forcer l'utilisation de différents types de pilotes d'horloge locale. Cela n'a aucun sens de lui donner une autre adresse. Supprimez la ligne fudge des clients et pointez-la simplement vers le serveur. Vous utilisez également un réseau fermé, alors supprimez tous les éléments de sécurité jusqu'à ce que cela fonctionne:
restrict default
Si cela ne semble toujours pas fonctionner, nous aurons besoin de voir la sortie de ntpq -c as et ntpq -c pe sur le serveur et sur un client qui se comporte mal, après au moins dix minutes de fonctionnement ininterrompu.
Edit : vous écrivez dans un commentaire ci-dessous que " Je pense que le décalage/la gigue est vraiment élevé parce que les clients défaillants dérivent dans le temps ".
Je pense que vous avez peut-être raison. Le blog de ce type suggère qu'il a eu la même expérience: que l'horloge du client était si mauvaise qu'elle a trompé le ntpd local en lui faisant croire que le serveur n'était pas fiable. Il a écrit
la raison de l'énorme gigue semble enfin claire! Notre horloge dérive si vite que le décalage augmentera de quelques secondes grâce à nos quelques mesures
Étant donné que ce sont vos clients dont le temps passe le plus rapidement qui ne parviennent pas à se synchroniser (marquant le serveur comme "rejet"), je pense que vous voyez le même effet. Sa solution consistait à utiliser adjtimex pour régler manuellement l'horloge du noyau (en ajustant la valeur tick) jusqu'à ce que l'horloge système soit moins capricieuse, point auquel ntpd avait une chance de reconnaître le serveur comme étant OK et synchronisez-le. Vous devriez probablement essayer d'abord le pire client et voir si cela aide.