Serveur NTP unique sur un réseau isolé

J'ai deux machines Linux (A et B) sur un réseau isolé. Ils doivent être synchronisés dans le temps. La machine A est alimentée par intermittence et doit servir l'heure, car elle est connectée à une source de temps faisant autorité (GPS). La machine B n'est alimentée que si la machine A est alimentée, mais il s'agit d'un périphérique Linux intégré et son état d'alimentation changera fréquemment. Aucune des deux machines n'a accès à d'autres systèmes. C'est un réseau fermé.

Je comprends que c'est une tâche assez difficile pour NTP, car NTP s'attend généralement à avoir des contacts avec plusieurs serveurs. J'ai du mal à faire fonctionner cela correctement sur la machine B.La machine A se synchronise très bien avec le GPS, et la machine B peut atteindre la machine A et même faire des requêtes de temps, mais la machine A n'est pas fiable (peut-être en soi?). Après une bonne heure de fonctionnement de la machine A, cela a soudainement changé et la machine B a fonctionné. Cependant, lorsque la machine A est tombée en panne (et donc la machine B), la machine B est de nouveau incapable de trouver une bonne synchronisation de l'heure.

Voici quelques informations sur ntpdate. Veuillez noter que même lorsque la strate de la machine A est 1, l'opération échoue avec la même sortie à la fin.

10.10.10.1: serveur abandonné: strates trop hautes
serveur 10.10.10.1, port 123
strate 16, précision -19, saut 11, confiance 000
refid [10.10.10.1], retard 0,02614, dispersion 0,00000
transmis 4, dans le filtre 4
heure de référence: 00000000.00000000 jeu., 7 février 2036 6: 28: 16.000
horodatage d'origine: d3a9bdc4.27ebb350 jeu 12 juil 2012 21: 19: 00.155
horodatage de transmission: bc17c803.b42dfffe sam. 1 janvier 2000 0: 25: 39.703
retard de filtre: 0,02625 0,02614 0,02618 0,02625 
         0,00000 0,00000 0,00000 0,00000 
décalage du filtre: 39544160 39544160 39544160 39544160
         0.000000 0.000000 0.000000 0.000000
retard 0,02614, dispersion 0,00000
offset 395441600.451568

 1 janvier 00:25:39 ntpdate [677]: aucun serveur adapté à la synchronisation n'a été trouvé

Je suppose que la machine A ne se fait tout simplement pas confiance pour purger sa peine. Après 51 minutes (peut-être arrivé plus tôt, je ne sais pas) de disponibilité et ayant son horloge synchronisée avec le GPS, la machine A a commencé à fonctionner correctement, et la machine B l'a récupérée. J'ai besoin que cela se produise plus tôt. Comme, en quelques secondes si possible.

Avec les configurations suivantes (et beaucoup d'attente), cela réussit finalement.

Machine A ntp.conf:

serveur 127.127.28.0 préfère true minpoll 4 maxpoll 4
fudge 127.127.28.0 strate 1 time1 0.420 refid GPS 

Machine B ntp.conf:

serveur 10.10.10.1 préfère true minpoll 4 maxpoll 4

ntpq -c pairs sur la machine B sans correction du bon moment:

     refid à distance st t lorsque le sondage atteint le retard décalage de la gigue
================================================== ============================
 10.10.10.1. ÉTAPE. 16 u 9 16 0 0,000 0,000 0,000

ntp1 -c pairs sur la machine B avec une bonne correction de temps:

     refid à distance st t lorsque le sondage atteint le retard décalage de la gigue
================================================== ============================
* 10.10.10.1 SHM (0) 2 u 7 16 17 0,669 2,597 1,808

Donc, maintenant la question devient: comment puis-je faire confiance à Machine A rapidement?

Une sortie de débogage de la machine A avant et après la machine B décide que la machine A est assez bonne à utiliser.

avant..

~ # ntpq -c rv
associd = 0 status = c418 leap_alarm, sync_uhf_radio, 1 événement, no_sys_peer,
version = "ntpd 4.2.6p4@1.2324 ven.24 février 15:01:45 UTC 2012 (1)",
processeur = "armv7l", système = "Linux / 2.6.35.14", saut = 11, strate = 2,
précision = -19, rootdelay = 0,000, rootdisp = 44,537, refid = SHM (0),
reftime = d3ab0053.43b44780 ven.13 juil.2012 20: 15: 15.264,
clock = d3ab0062.e7e03154 ven.13 juil.2012 20: 15: 30.905, pair = 34819, tc = 4,
mintc = 3, offset = 0,000, fréquence = 0,000, sys_jitter = 3,853,
clk_jitter = 36,492, clk_wander = 0,000

après...

~ # ntpq -c rv
associd = 0 status = 0415 leap_none, sync_uhf_radio, 1 événement, clock_sync,
version = "ntpd 4.2.6p4@1.2324 ven.24 février 15:01:45 UTC 2012 (1)",
processeur = "armv7l", système = "Linux / 2.6.35.14", saut = 00, strate = 2,
précision = -19, rootdelay = 0,000, rootdisp = 41,278, refid = SHM (0),
reftime = d3ab0063.43b37856 ven.13 juil 2012 20: 15: 31.264,
clock = d3ab006d.9ee53ec2 ven.13 juil.2012 20: 15: 41.620, pair = 34819, tc = 4,
mintc = 3, offset = 0,000, fréquence = 43,896, sys_jitter = 0,762,
clk_jitter = 36,953, clk_wander = 0,000

NTP devrait fonctionner correctement. Regardez quelques-unes des options de synchronisation rapide au démarrage. Regardez les options burstet iburstpour le système B. Regardez l' trueoption pour la source d'horloge GPS.

Envisagez d'utiliser l'horloge matérielle comme source de temps de sauvegarde sur les deux systèmes. Définissez un système de strates plus élevé B. Quelque chose comme ce qui suit devrait fonctionner:

server  127.127.1.0
fudge   127.127.1.0 stratum 8

Regardez la sortie de ntpq -c peerspour voir quand vous obtenez une source d'horloge fiable. Veut normalement ntpun certain nombre de réponses d'une source de temps fiable avant de lui faire confiance. Ceci est indiqué par le premier caractère de chaque ligne.

Bien que NTP aime plus de sources, tout nombre impair de sources de temps au sein d'un niveau de strate devrait bien fonctionner. Comme vous n'avez que deux serveurs et une horloge GPS, la priorité (strate) des sources devrait augmenter à partir du GPS, horloge sur le serveur A, horloge sur le serveur B.L'augmentation de la strate entre chacun de trois ou quatre niveaux garantira le respect des priorités.

EDIT: Si vous avez le serveur NTP busybox sur le serveur A, il peut être utile d'installer le package complet du serveur ntp. Comprendre ce qui se passe avec le serveur A devrait contribuer grandement à résoudre votre problème. Vous aurez besoin d'au moins une source de temps approuvée avant que le serveur B ne l'approuve. Si ntpq -c peersne fonctionne pas, vous pouvez essayer ntpdc peers. Ces deux commandes vous permettent d'interroger d'autres hôtes. Un peerstatsjournal pourrait également être utile.

Sur le serveur B, utilisez ntpclient comme documenté le howto de busybox ntp pour enregistrer ce qui se passe dessus

Les horloges doivent être raisonnablement proches de l'heure correcte si les serveurs ne sont pas en panne depuis longtemps. Si vous devez synchroniser les deux systèmes, cela devrait suffire. Le GPS synchronisera éventuellement l'heure avec le monde réel.

'ntpd -q' se synchronise rapidement, mais se ferme (comportement ntpdate). Il doit être suivi d'une ntpdcommande sans l'option quit pour avoir une synchronisation continue.

EDIT2: J'ai vérifié mon serveur et j'ai découvert qu'un des serveurs était éteint d'une seconde. Tout en corrigeant cela, j'ai joué avec les paramètres. iburstobtient un serveur de confiance très rapidement. trueveillé à ce que le pilote d'horloge soit approuvé s'il n'y avait pas plusieurs autres sources fiables. L'horloge a pris un peu plus d'une minute avant d'être approuvée localement et de faire confiance à distance.

Lors du test, vous devriez pouvoir redémarrer le ntpdprocessus une fois qu'il est synchronisé et tester la vitesse de fonctionnement des paramètres. Dans le cas ci-dessus, il peut être nécessaire de redémarrer le serveur B pour tester sa vitesse de synchronisation. Lors de la surveillance des ntpdmodifications, j'utilise une ligne comme:

while ntpq -c peers localhost; do sleep 10; done

Le nom d'hôte et le temps de sommeil sont ajustés selon les besoins. Dans certains cas, j'enchaîne deux ntpqlignes de commande ou plus dans la boucle. Pour ce faire, j'utilise une commande echo et / ou date pour fournir une indication de l'évolution des ensembles de données.