Où se configure le serveur ntp à consulter sur une Debian Squeeze « de base » etc. ?
37 réponses
Francois Lafont
Bonjour à tous,
J'installe une Debian Squeeze « de base » sur une machine. Composants
installés (via une installation en mode expert) : "SSH server" et
"Standard system utilities" et c'est tout. Rien d'autre.
Durant l'installation, on m'a demandé de choisir un serveur NTP. J'avais
laissé le choix par défaut, à savoir 0.debian.pool.ntp.org ce qui était
très bien et je finis mon installation parfaitement. Tout va bien.
Mais finalement, après coup, je me dis « zut, ce que je voulais c'est
mettre comme serveur ntp "mon-ntp.mon-domain.priv" » parce que c'est un
ntp local du coup c'est mieux. Et là, une fois l'installation terminée
et la machine rebootée, sur ma console je cherche où changer ce
paramètre et là je ne trouve rien :
Donc, juste deux occurrences de "0.debian.pool.ntp.org" dans des logs et
c'est tout. Aucun paquet "ntp*" installé. Alors du coup, j'ai quelques
questions :
1) Lors de l'installation, le choix du serveur ntp ne serait-il pas au
bout du compte ponctuel uniquement ? Je veux dire par là que ma Debian
au moment de l'installation a bien réglé son heure sur
0.debian.pool.ntp.org mais ensuite le système (une Debian de base donc)
ne cherchera plus jamais à synchroniser son heure avec
0.debian.pool.ntp.org (ou avec qui que ce soit d'autre d'ailleurs) ? Je
me pose cette question car au niveau ntp rien ne semble installé sur le
système.
2) Ou bien je me trompe et en réalité ma Debian va bien régulièrement se
synchroniser sur 0.debian.pool.ntp.org mais alors dans ce cas où peut-on
modifier le choix du serveur ntp à consulter ?
En admettant que ça soit le cas 1) qui se produise alors je veux que ma
machine se mette à jour (au niveau de l'horloge) régulièrement. Du coup,
je veux installer un client ntp. Donc je pense au paquet "ntpdate" car
je vois dans sa description :
ntpdate: client for setting system time from NTP servers
Bien sûr, il y a le paquet "ntp" aussi mais lui fait client et serveur
ntp (si j'ai bien compris) or personnellement seul le client m'intéresse
ici. Si je jette un œil sur la page man de ntpdate, je vois que la
synchronisation avec les serveurs spécifiés dans "/etc/default/ntpdate"
se fait au boot uniquement (en fait il semble que ce soit plus
précisément au moment de l'activation des interfaces réseau). Le souci
c'est que la machine est un serveur qui est censé booter plutôt rarement
et donc je voudrais que la synchronisation se fasse régulièrement même
s'il n'y a pas de redémarrage. Du coup, je pense à faire une tâche cron
mais je peux lire dans la page man de ntpade :
« It is also possible to run ntpdate from a cron script. However, it is
important to note that ntpdate with contrived cron scripts is no
substitute for the NTP daemon, which uses sophisticated algorithms to
maximize accuracy and reliability while minimizing resource use.
Finally, since ntpdate does not discipline the host clock frequency as
does ntpd, the accuracy using ntpdate is limited. »
Bref, la page man m'incite plutôt à installer le paquet ntp. D'où ma
dernière question :
3) Est-ce vraiment nécessaire d'installer le paquet ntp dans mon cas (ie
ma machine a juste besoin d'un client ntp à faire fonctionner
régulièrement) ? Personnellement une précision du temps à la seconde
près me convient tout à fait (personnellement que le temps du serveur
soit exact à la nano seconde près m'importe peu). Est-ce qu'une tâche
cron peut faire l'affaire avec mon nptdate (voire ntpdate-debian) ou
bien je suis vraiment « en dehors des clous » et il faut vraiment que
j'installe le paquet ntp. Bref, c'est quoi les bonnes pratiques dans ce
domaine ?
Oui, on sait, Windows c'est de la merde, Linux est parfait.
Je ne suis pas d'accord : Linux n'est pas parfait. :-)
-- François Lafont
Francois Lafont
Le 18/10/2012 09:11, gerbier a écrit :
sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...
Ah quand même ! Ça fait tout de même 1h de décalage au bout de 450 jours. C'est énorme. J'étais déjà convaincu sur l'intérêt d'installer ntp mais là...
-- François Lafont
Le 18/10/2012 09:11, gerbier a écrit :
sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...
Ah quand même ! Ça fait tout de même 1h de décalage au bout de 450
jours. C'est énorme. J'étais déjà convaincu sur l'intérêt d'installer
ntp mais là...
sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...
Ah quand même ! Ça fait tout de même 1h de décalage au bout de 450 jours. C'est énorme. J'étais déjà convaincu sur l'intérêt d'installer ntp mais là...
-- François Lafont
Francois Lafont
Je me permets de revenir sur ce point.
Le 18/10/2012 03:08, Fabien LE LEZ a écrit :
Le système utilise une horloge locale, relativement peu précise. Imaginons que cette horloge, sur ton PC, aille 1 % trop vite.
Supposons qu'à 13:00 (heure réelle), ntpdate met ton PC à l'heure juste. Dix minutes plus tard, ton PC indiquera 13:10:06 (1 % d'erreur = 606 secondes au lieu de 600).
Supposons maintenant qu'au lieu de ntpdate, tu utilises ntp, et qu'à la même heure, il a interrogé le serveur. Puisque ntp sait que l'horloge local va 1 % trop vite, il a corrigé le tir au fur et à mesure ; à 13:10, ton PC indiquera bien 13:10, même si aucune autre requête vers le serveur n'a été effectuée entre-temps.
Juste une question (simple curiosité).
Comme ça se passe sur ma machine serveur (avec ntp installé dessus) quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes afin d'indiquer 2 heures du matin (la question se pose aussi pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
ntp s'arrange pour faire la transition en douceur aussi ? Mais auquel cas il se passe un certain temps avant que le serveur indique la « vraie » heure, non ?
-- François Lafont
Je me permets de revenir sur ce point.
Le 18/10/2012 03:08, Fabien LE LEZ a écrit :
Le système utilise une horloge locale, relativement peu précise.
Imaginons que cette horloge, sur ton PC, aille 1 % trop vite.
Supposons qu'à 13:00 (heure réelle), ntpdate met ton PC à l'heure
juste. Dix minutes plus tard, ton PC indiquera 13:10:06 (1 % d'erreur
= 606 secondes au lieu de 600).
Supposons maintenant qu'au lieu de ntpdate, tu utilises ntp, et qu'à
la même heure, il a interrogé le serveur. Puisque ntp sait que
l'horloge local va 1 % trop vite, il a corrigé le tir au fur et à
mesure ; à 13:10, ton PC indiquera bien 13:10, même si aucune autre
requête vers le serveur n'a été effectuée entre-temps.
Juste une question (simple curiosité).
Comme ça se passe sur ma machine serveur (avec ntp installé dessus)
quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28
octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes
afin d'indiquer 2 heures du matin (la question se pose aussi pour le
passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
ntp s'arrange pour faire la transition en douceur aussi ? Mais auquel
cas il se passe un certain temps avant que le serveur indique la « vraie
» heure, non ?
Le système utilise une horloge locale, relativement peu précise. Imaginons que cette horloge, sur ton PC, aille 1 % trop vite.
Supposons qu'à 13:00 (heure réelle), ntpdate met ton PC à l'heure juste. Dix minutes plus tard, ton PC indiquera 13:10:06 (1 % d'erreur = 606 secondes au lieu de 600).
Supposons maintenant qu'au lieu de ntpdate, tu utilises ntp, et qu'à la même heure, il a interrogé le serveur. Puisque ntp sait que l'horloge local va 1 % trop vite, il a corrigé le tir au fur et à mesure ; à 13:10, ton PC indiquera bien 13:10, même si aucune autre requête vers le serveur n'a été effectuée entre-temps.
Juste une question (simple curiosité).
Comme ça se passe sur ma machine serveur (avec ntp installé dessus) quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes afin d'indiquer 2 heures du matin (la question se pose aussi pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
ntp s'arrange pour faire la transition en douceur aussi ? Mais auquel cas il se passe un certain temps avant que le serveur indique la « vraie » heure, non ?
-- François Lafont
Damien Wyart
* Francois Lafont in fr.comp.os.linux.configuration:
Comme ça se passe sur ma machine serveur (avec ntp installé dessus) quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes afin d'indiquer 2 heures du matin (la question se pose aussi pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
NTP se base sur UTC ; c'est donc de la responsabilité du système d'exploitation de gérer le fuseau horaire et les décalages. Sous Debian, le paquet tzdata contient les données qui permettent de le faire.
-- DW
* Francois Lafont <francois.lafont@nospam.invalid>
in fr.comp.os.linux.configuration:
Comme ça se passe sur ma machine serveur (avec ntp installé dessus)
quand il y a un changement d'heure d'hiver ? Par exemple un dimanche
28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60
minutes afin d'indiquer 2 heures du matin (la question se pose aussi
pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
NTP se base sur UTC ; c'est donc de la responsabilité du système
d'exploitation de gérer le fuseau horaire et les décalages. Sous Debian,
le paquet tzdata contient les données qui permettent de le faire.
* Francois Lafont in fr.comp.os.linux.configuration:
Comme ça se passe sur ma machine serveur (avec ntp installé dessus) quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes afin d'indiquer 2 heures du matin (la question se pose aussi pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
NTP se base sur UTC ; c'est donc de la responsabilité du système d'exploitation de gérer le fuseau horaire et les décalages. Sous Debian, le paquet tzdata contient les données qui permettent de le faire.
-- DW
Nicolas George
Francois Lafont , dans le message <507f59bd$0$6150$, a écrit :
J'espère que l'exemple du « 1% trop vite » est purement didactique parce que 6 secondes d'avance toutes les 10 minutes sur un ordinateur, ça fait peur. :-)
J'ai regardé sur quelques unes des machines auxquelles j'ai accès : l'ordre de grandeur est de quelques dizaines de parties par million, ce qui fait quand même quelques secondes par jour.
Francois Lafont , dans le message
<507f59bd$0$6150$426a74cc@news.free.fr>, a écrit :
J'espère que l'exemple du « 1% trop vite » est purement didactique parce
que 6 secondes d'avance toutes les 10 minutes sur un ordinateur, ça fait
peur. :-)
J'ai regardé sur quelques unes des machines auxquelles j'ai accès : l'ordre
de grandeur est de quelques dizaines de parties par million, ce qui fait
quand même quelques secondes par jour.
Francois Lafont , dans le message <507f59bd$0$6150$, a écrit :
J'espère que l'exemple du « 1% trop vite » est purement didactique parce que 6 secondes d'avance toutes les 10 minutes sur un ordinateur, ça fait peur. :-)
J'ai regardé sur quelques unes des machines auxquelles j'ai accès : l'ordre de grandeur est de quelques dizaines de parties par million, ce qui fait quand même quelques secondes par jour.
Nicolas George
Damien Wyart , dans le message <507fd07e$0$6118$, a écrit :
Comme ça se passe sur ma machine serveur (avec ntp installé dessus) quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes afin d'indiquer 2 heures du matin (la question se pose aussi pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
Ce qui déplace la question : comment ça se passe quand il y a une seconde intercalaire ?
La réponse : mal.
Damien Wyart , dans le message <507fd07e$0$6118$426a74cc@news.free.fr>,
a écrit :
Comme ça se passe sur ma machine serveur (avec ntp installé dessus)
quand il y a un changement d'heure d'hiver ? Par exemple un dimanche
28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60
minutes afin d'indiquer 2 heures du matin (la question se pose aussi
pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
Damien Wyart , dans le message <507fd07e$0$6118$, a écrit :
Comme ça se passe sur ma machine serveur (avec ntp installé dessus) quand il y a un changement d'heure d'hiver ? Par exemple un dimanche 28 octobre 2012 à 3 heures du matin... boum !!! il faut retirer 60 minutes afin d'indiquer 2 heures du matin (la question se pose aussi pour le passage à l'heure d'été où là on ajoute 60 minutes d'un coup).
Ce qui déplace la question : comment ça se passe quand il y a une seconde intercalaire ?
La réponse : mal.
gerbier
Le 18/10/2012 11:12, Francois Lafont a écrit :
Le 18/10/2012 09:11, gerbier a écrit :
sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...
Ah quand même ! Ça fait tout de même 1h de décalage au bout de 450 jours. C'est énorme. J'étais déjà convaincu sur l'intérêt d'installer ntp mais là...
tout dépends de l'utilisation de la machine : sur un cluster de calcul c'est trop (et je ne parle pas d'une banque)
Le 18/10/2012 11:12, Francois Lafont a écrit :
Le 18/10/2012 09:11, gerbier a écrit :
sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...
Ah quand même ! Ça fait tout de même 1h de décalage au bout de 450
jours. C'est énorme. J'étais déjà convaincu sur l'intérêt d'installer
ntp mais là...
tout dépends de l'utilisation de la machine : sur un cluster de calcul c'est trop
(et je ne parle pas d'une banque)
sur un serveur (racké en salle climatisée), j'ai une horloge qui prends 8 secondes par jour ...
Ah quand même ! Ça fait tout de même 1h de décalage au bout de 450 jours. C'est énorme. J'étais déjà convaincu sur l'intérêt d'installer ntp mais là...
tout dépends de l'utilisation de la machine : sur un cluster de calcul c'est trop (et je ne parle pas d'une banque)
Très intéressant, zou un copier-coller (on ne sait jamais ce qu'en fera Google).
§1.3 tu dis :
À l'instant où j'écris ces lignes, ce nombre [décalage TAI/UTC] est 23 : le 10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.
Or il me semble que c'est le TAI qui avance plus vite que l'UTC ; en cas de seconde intercalaire, on a quelque chose du type : - TAI : 23h59'59" - 0h0'0" - 0h0'1" - UTC : 23h59'59" - 23h59'60" - 0h0'0" Je m'attends donc globalement à TAI>UTC.
Ce que semble confirmer cette page : http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab&lang=fr qui indique de plus que l'offset était 33 lorsque tu as écrit ton texte.
Très intéressant, zou un copier-coller (on ne sait jamais ce qu'en fera
Google).
§1.3 tu dis :
À l'instant où j'écris ces lignes, ce nombre [décalage TAI/UTC] est 23 :
le 10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.
Or il me semble que c'est le TAI qui avance plus vite que l'UTC ; en cas
de seconde intercalaire, on a quelque chose du type :
- TAI : 23h59'59" - 0h0'0" - 0h0'1"
- UTC : 23h59'59" - 23h59'60" - 0h0'0"
Je m'attends donc globalement à TAI>UTC.
Ce que semble confirmer cette page :
http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab&lang=fr
qui indique de plus que l'offset était 33 lorsque tu as écrit ton texte.
Très intéressant, zou un copier-coller (on ne sait jamais ce qu'en fera Google).
§1.3 tu dis :
À l'instant où j'écris ces lignes, ce nombre [décalage TAI/UTC] est 23 : le 10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.
Or il me semble que c'est le TAI qui avance plus vite que l'UTC ; en cas de seconde intercalaire, on a quelque chose du type : - TAI : 23h59'59" - 0h0'0" - 0h0'1" - UTC : 23h59'59" - 23h59'60" - 0h0'0" Je m'attends donc globalement à TAI>UTC.
Ce que semble confirmer cette page : http://hpiers.obspm.fr/eop-pc/index.php?index=TAI-UTC_tab&lang=fr qui indique de plus que l'offset était 33 lorsque tu as écrit ton texte.
-- LL
Nicolas George
Lucas Levrel , dans le message , a écrit :
À l'instant où j'écris ces lignes, ce nombre [décalage TAI/UTC] est 23 : le 10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.
Or il me semble que c'est le TAI qui avance plus vite que l'UTC ; en cas de seconde intercalaire, on a quelque chose du type :
Oui, tu dois avoir raison : on ajoute des secondes intercalaires pour éviter qu'UTC prenne de l'avance sur l'heure solaire. Au temps pour moi.
Enfin, de toutes façons, il me semble qu'on n'est pas censé décomposer TAI en date-heures-minutes-secondes.
Lucas Levrel , dans le message
<alpine.LNX.2.00.1210191118300.3052@coulomb.univ-paris12.fr>, a écrit :
À l'instant où j'écris ces lignes, ce nombre [décalage TAI/UTC] est 23 :
le 10 avril 2008, 12:00:00 TAI correspond au 10 avril 2008, 12:00:23 UTC.
Or il me semble que c'est le TAI qui avance plus vite que l'UTC ; en cas
de seconde intercalaire, on a quelque chose du type :
Oui, tu dois avoir raison : on ajoute des secondes intercalaires pour éviter
qu'UTC prenne de l'avance sur l'heure solaire. Au temps pour moi.
Enfin, de toutes façons, il me semble qu'on n'est pas censé décomposer TAI
en date-heures-minutes-secondes.
