Quels sont les avantages et les inconvénients de ces deux façons de synchroniser votre serveur?
Il me semble que votre serveur ne dériverait probablement pas plus d'une seconde par jour, donc ntpdate sur un crontab serait ok. Mais j'ai entendu dire que vous pouviez utiliser des serveurs NTP redondants ici
http://www.pool.ntp.org/en/use.html
afin de maintenir l'heure synchronisée en cas de panne.
Avez-vous des suggestions?
Réponses:
L'algorithme NTP comprend des informations pour vous permettre de calculer et de corriger la dérive de l'horloge de votre serveur. NTPD inclut la possibilité de l'utiliser pour garder votre horloge synchronisée et fonctionnera plus précisément qu'une horloge sur un ordinateur qui n'exécute pas NTPD. NTPD utilisera également plusieurs serveurs pour améliorer la précision.
ntpdate ne conserve aucun état pour effectuer ce service pour vous et ne fournira donc pas le même type de précision. Il vous permettra de lui fournir une liste de serveurs qu'il utilisera pour tenter de vous fournir un meilleur résultat, mais cela ne remplace pas les algorithmes sophistiqués fournis dans NTPD qui suivent votre dérive de chacun des serveurs au fil du temps.
NTPDATE corrige instantanément l'heure du système, ce qui peut entraîner des problèmes avec certains logiciels (par exemple, la destruction d'une session qui apparaît désormais ancienne). NTPD corrige intentionnellement l'heure système lentement, en évitant ce problème. Vous pouvez ajouter le commutateur -g lors du démarrage de NTPD pour permettre à NTPD de faire une première mise à jour importante, ce qui équivaut plus ou moins à exécuter ntpdate une fois avant de démarrer NTPD, ce qui était à un moment recommandé.
En ce qui concerne les problèmes de sécurité, les serveurs ntp ne se reconnectent pas aux connexions non initiées, ce qui signifie que votre pare-feu devrait être en mesure de dire que vous avez initié la demande ntp et autoriser le trafic de retour. Il ne devrait pas être nécessaire de laisser les ports ouverts pour les connexions arbitraires afin de faire fonctionner NTPD.
Depuis la page de manuel ntpdate (8):
ntpdate peut être exécuté manuellement si nécessaire pour définir l'horloge de l'hôte, ou il peut être exécuté à partir du script de démarrage de l'hôte pour régler l'horloge au démarrage. Cela est utile dans certains cas pour régler l'horloge initialement avant de démarrer le démon NTP ntpd. Il est également possible d'exécuter ntpdate à partir d'un script cron. Cependant, il est important de noter que ntpdate avec des scripts cron artificiels ne remplace pas le démon NTP, qui utilise des algorithmes sophistiqués pour maximiser la précision et la fiabilité tout en minimisant l'utilisation des ressources. Enfin, comme ntpdate ne discipline pas la fréquence d'horloge de l'hôte comme le fait ntpd, la précision utilisant ntpdate est limitée.
ntpd est préféré à ntpdate car vous obtenez une correction temporelle fluide plutôt que des sauts dans votre horloge. Quel sens faites-vous de vos journaux quand il y a un saut dans le temps en arrière? ntpdate basculera également de manière transparente entre les serveurs selon les besoins.
Quant à la nécessité de ports ouverts (comme mentionné par Kyle), les nouvelles versions de ntpd (par exemple 4.2.4 sur mon serveur Debian) peuvent être configurées pour diffuser / multidiffuser sur le LAN, avec une authentification cryptographique.
Edit: voir aussi cette question .
Je recommande généralement d'exécuter NTPD et de synchroniser vos serveurs avec un serveur de temps désigné au sein de votre organisation. Ce serveur interne sera généralement synchronisé avec l'un des serveurs NTP publics (comme vous l'avez lié à).
J'ai utilisé la méthode ntpdate sans aucun problème, mais cela semble plus hackeux que d'exécuter un vrai démon ntpd.
J'ai entendu parler de problèmes avec le décalage d'horloge sur les machines virtuelles exécutant ntpd. J'ai également entendu des gens corriger ce problème en exécutant des tâches cron régulières qui appellent ntpdate sur plusieurs serveurs de pool. Je n'ai pas eu ces problèmes, mais j'en ai entendu parler plusieurs fois.
Comme mentionné ailleurs, NTP fournit une correction temporelle fluide. Si les applications sur votre serveur ne vous dérange pas d'avoir des secondes entières manquantes, ou de recommencer les mêmes secondes, alors ntpd ne vous rapporte pas beaucoup plus que ntpdate.
Si d'un autre côté, vous avez des applications sensibles au temps qui sont sensibles aux secondes, ou pire encore sont sensibles aux secondes partielles, alors ntpd est de loin le meilleur choix. Novell eDirectory horodate les mises à jour pour la gestion des collisions de mise à jour, ce qui devient critique si les mises à jour arrivent très rapidement (comme lors de la session de connexion matinale). Un serveur syslog doit avoir un temps précis d'au moins la demi-seconde afin de conserver des journaux sains.
Pour ma boîte MythTV à la maison, je remarque quand il est même à quelques secondes de ce que mon câblo-opérateur considère comme du temps, donc j'utilise NTP là-dessus. Pour le serveur de surveillance UPS au travail, j'utilise ntpdate crontabbed pour les mêmes raisons que Kyle Hodgson a souligné, car c'est un hôte bastion, je ne veux pas que ce port soit ouvert même si j'ai verrouillé l'application; pour cette application étant une seconde hors de vrai n'est pas terrible.
En ce qui concerne la redondance, nous maintenons au moins deux hôtes temporels sur notre réseau et pointons tous nos hôtes internes vers ces deux. Ces deux-là suivent ensuite différents hôtes NTP Internet. De plus, ils sont configurés dans un arrangement de pairs afin qu'ils puissent garder du temps entre eux de manière consensuelle si notre lien Internet tombe en panne. Un NTP robuste est certainement possible à concevoir.
Sur un serveur où l'accès et le renforcement sont critiques, j'ai utilisé le raisonnement selon lequel xntpd, la version de ntpd sur laquelle je comptais, nécessitait un port UDP ouvert 123. Comme je préférais avoir seulement tcp 22 et 80 ouvert, j'ai utilisé ntpdate dans un crontab à la place. Je n'ai jamais entendu une bonne raison pour laquelle il en avait besoin, ou pas une dont je me souvienne.
L'un des inconvénients de l'utilisation d'un appel ntpdate croisé est qu'il ne peut pas gérer la correction de dérive avec élégance. ntpdate, iirc, met à jour l'horloge dès qu'il peut dire que vous êtes obsolète - les démons ntp corrigent généralement la dérive en douceur. Cela a l'avantage que vos journaux restent sains d'esprit - vous pouvez imaginer, sur un serveur Web occupé par exemple, que si le RTC avait dérivé quelques minutes, que la lecture des journaux Web le lendemain pourrait déduire que les gens ont pu frapper en toute sécurité URL avant de se connecter, car les accès Web seraient hors service.
Vous n'avez pas besoin d'utiliser crontab, c'est à cela que sert ntpd.
Au départ, lorsque votre temps est écoulé, une façon consiste simplement à arrêter ntpd, puis à exécuter ntpdate ntp.server.compour le remettre en synchronisation, puis à redémarrer ntp.
Si vous avez un grand réseau, je configurerais probablement quelques serveurs ntp locaux et j'obtiendrais tous les hôtes pour les utiliser.
Consultez cette discussion pour comprendre pourquoi "ntpdate" est toujours souhaité et utilisé.
Pour résumer: ntpd est lent en comparaison lors d'un ajustement massif du temps, même avec l'option -g.
Pour un usage domestique, ntpdate n'est pas vraiment un problème. Il y a une raison pour laquelle il est "plus lent". Quiconque utilise un cron avec ntpdate dans un environnement PRODUCTION ENTERPRISE n'est qu'un idiot.