La cause de la non-synchronisation avec un serveur dont l'heure est si différente est documentée ici :
5.1.1.4. Que se passe-t-il si l'heure de référence change?
Idéalement, l'heure de référence est la même partout dans le monde. Une fois synchronisé, il ne devrait y avoir aucun changement inattendu entre l'horloge du système d'exploitation et l'horloge de référence. Par conséquent, NTP n'a pas de méthodes spéciales pour gérer la situation.
Au lieu de cela, la réaction de ntpd dépendra du décalage entre l'horloge locale et l'heure de référence. Pour un petit décalage, ntpd ajustera l'horloge locale comme d'habitude; pour les décalages petits et plus grands, ntpd rejettera le temps de référence pendant un certain temps. Dans ce dernier cas, l'horloge du système d'exploitation continuera avec les dernières corrections effectives pendant le rejet de la nouvelle heure de référence. Après un certain temps, de petits décalages (nettement moins d'une seconde) seront orientés (ajustés lentement), tandis que des décalages plus importants entraîneront un décalage de l'horloge (réglé à nouveau). Les compensations énormes sont rejetées et ntpd se terminera lui-même, croyant que quelque chose de très étrange doit s'être produit.
Dans ma configuration NTP actuelle, également contrôlée par puppet, je force la synchronisation avec le serveur, à la fois dans le ntp.conffichier, en utilisant tinker panicet dans les paramètres du démon ( /etc/sysconfig/ntpd), comme décrit dans la ntpd(8)page de manuel:
-g Normalement, ntpd se termine avec un message dans le journal système si le décalage dépasse le seuil de panique, qui est de 1000 s par défaut. Cette option permet de régler l'heure sur n'importe quelle valeur sans restriction; cependant, cela ne peut se produire qu'une seule fois. Si le seuil est dépassé après cela, ntpd se fermera avec un message dans le journal système. Cette option peut être utilisée avec les options -q et -x.
Je le fais parce que je peux faire confiance au serveur NTP auquel je me connecte.
La partie pertinente du module qui s'applique aux clients est la suivante:
class ntp (
$foo
$bar
...
){
$my_files = {
'ntp.conf' => {
path => '/etc/ntp.conf',
content => template("ntp/ntp.conf.$template.erb"),
selrole => 'object_r',
seltype => 'net_conf_t',
require => Package['ntp'], },
'ntp-sysconfig' => {
path => '/etc/sysconfig/ntpd',
source => 'puppet:///modules/ntp/ntp-sysconfig',
require => Package['ntp'], },
...
}
$my_files_defaults = {
ensure => file,
owner => 'root',
group => 'root',
mode => '0644',
selrange => 's0',
selrole => 'object_r',
seltype => 'etc_t',
seluser => 'system_u',
}
create_resources(file, $my_files, $my_files_defaults)
exec { 'ntp initial clock set':
command => '/usr/sbin/ntpd -g -q -u ntp:ntp',
refreshonly => true,
timeout => '-1',
subscribe => File['/etc/ntp.conf'],
}
}
Et le contenu des fichiers référencés est:
$ cat devops/puppet/modules/ntp/files/ntp-sysconfig
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g -a"
et:
$ cat devops/puppet/modules/ntp/templates/ntp.conf.RedHat.erb
# HEADER: This file was autogenerated by puppet.
# HEADER: While it can still be managed manually, it
# HEADER: is definitely not recommended.
tinker panic 0
<% server.each do |ntpserver| -%>
server <%= ntpserver %> autokey
<% end -%>
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
crypto pw hunter2
crypto randfile /dev/urandom
keysdir /etc/ntp
La hierapartie manque ici, mais vous avez l'idée.
tinker panic 0