16.16. Configurer les serveurs ntpdate

Le but du service ntpdate est de régler l'horloge pendant le démarrage système. C'était utilisé pour veiller à ce que les services lancés après ntpdate aient l'heure correcte sans « sauts » d'horloge. L'utilisation de ntpdate et de la liste des « step-tickers » sont déconseillés et Red Hat Enterprise Linux 7 utilise désormais l'option -g sur la commande ntpd et non plus ntpdate par défaut.
Le service ntpdate de Red Hat Enterprise Linux 7 est plus utile en autonome, sans ntpd. Avec systemd, qui lance des services en parallèle, l'activation du service ntpdate ne garantit pas que d'autres services lancés par la suite auront l'heure correcte, à moins qu'ils ne spécifient une dépendance de classement sur time-sync.target, qui est fournie par le service ntpdate. Pour vous assurer qu'un service soit lancé avec l'heure correcte, ajoutez After=time-sync.target au service et activez l'un des services qui fournit la cible (ntpdate ou sntp). Cette dépendance est incluse par défaut sur certains services Red Hat Enterprise Linux 7 ( par exemple, dhcpd, dhcpd6, et crond).
Pour vérifier si le service ntpdate est activé pour s'exécuter pendant le démarrage système, veuillez exécuter la commande suivante :
~]$ systemctl status ntpdate
Pour activer le service pour qu'il soit exécuté au moment du démarrage système, veuillez exécuter la commande suivante en tant qu'utilisateur root :
~]# systemctl enable ntpdate
Dans Red Hat Enterprise Linux 7, le fichier /etc/ntp/step-tickers par défaut contient 0.rhel.pool.ntp.org. Pour configurer des serveurs ntpdate supplémentaires, veuillez utiliser un éditeur de texte en tant qu'utilisateur root et modifiez /etc/ntp/step-tickers. Le nombre de serveurs répertoriés n'est pas très important car ntpdate utilisera uniquement ceci pour obtenir des informations sur la date une fois que le système aura démarré. Si vous possédez un serveur de temps interne, alors utilisez ce nom d'hôte pour la première ligne. Un hôte supplémentaire sur la seconde ligne en tant que copie de sauvegarde est une bonne idée. La sélection des serveurs de sauvegarde et le choix d'un second hôte interne ou externe dépend de votre évaluation des risques. Par exemple, quelles sont les chances qu'un problème affectant le premier serveur puissent également affecter le second serveur ? Est-ce que la connectivité d'un serveur externe sera plus facilement disponible que la connectivité aux serveurs internes en cas de panne réseau perturbant l'accès au premier serveur ?