News: impossible de poster (pb d'heure)

Pascal@plouf wrote:

Système, normalement. Que retourne la commande "date" dans un termina l ?

Merci de m'avoir mis sur la voie : le fuseau horaire que j'ai modifié h ier dans
KDE était correct (j'avais au moins ca de bon...).
Par contre, le système n'était pas bon... (pas cohérent tout ca...)

Sur Debian on peut ajuster le fuseau horaire avec "tzconfig". Sais pas
C'est timeconfig sur ma slackware (si ca peut servir à qqun un jour).

Et ca marche.
Merci pour ton aide !

<ironique>
Bah alors, Biggoron n'est plus à l'heure ?
</ironique>

M'sieu, il est méchant !
Non, biggoron est sûrement à l'heure (et puis de toute façon je m'en
fiche, du moment qu'il ne met pas trois heures à diffuser les articles).
C'est plutôt mon Windows qui avait quelques minutes d'avance. Je viens
de lui demander de se synchroniser sur un serveur NTP, ça devrait être
mieux.

Dans le message <news:dltjqr$2ls6$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :

<ironique>
Bah alors, Biggoron n'est plus à l'heure ?
</ironique>

M'sieu, il est méchant !

Mais non. Juste taquin comme tu le disais si bien. :)

Non, biggoron est sûrement à l'heure (et puis de toute façon je m'en
fiche, du moment qu'il ne met pas trois heures à diffuser les articles).

Ça c'est amélioré de ce côté là, non ?

C'est plutôt mon Windows qui avait quelques minutes d'avance. Je viens de
lui demander de se synchroniser sur un serveur NTP, ça devrait être mieux.

Ce qui m'étonnait, c'est que toi qui t'intéresses tant aux protocoles
réseaux, tu n'ais pas ton propre serveur NTP ou bien alors que tes machines
ne soient pas correctement synchronisées dessus.

--
TiChou

Dans le message <news:dltjqr$2ls6$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :

Non, biggoron est sûrement à l'heure (et puis de toute façon je m'en
fiche, du moment qu'il ne met pas trois heures à diffuser les articles).

Ça c'est amélioré de ce côté là, non ?

Oui. Jusqu'à la prochaine crise de constipation aiguë...

C'est plutôt mon Windows qui avait quelques minutes d'avance. Je viens
de lui demander de se synchroniser sur un serveur NTP, ça devrait être
mieux.

Ce qui m'étonnait, c'est que toi qui t'intéresses tant aux protocoles
réseaux, tu n'ais pas ton propre serveur NTP

Bah pour quoi faire, il y en a plein partout ?

ou bien alors que tes
machines ne soient pas correctement synchronisées dessus.

Mes Linux, oui. Mais pas mon Windows jusqu'ici (je savais pas faire,
apparemment il fallait démarrer un service). Et puis j'avais de la
chance, apparemment il dérive très peu, pas comme ma passerelle qui
prendrait une minute par jour autrement.

Dans le message <news:dltlkq$2mko$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :

Ce qui m'étonnait, c'est que toi qui t'intéresses tant aux protocoles
réseaux, tu n'ais pas ton propre serveur NTP

Bah pour quoi faire, il y en a plein partout ?

Il y a au moins deux bonnes raisons pour avoir un serveur NTP sur son
réseau, une bonne raison, voir deux, pour que le service ntp tourne sur
chaque machine et enfin d'autres bonnes raisons pour ceux qui s'intéressent
aux réseaux et à la sécurité. J'en parle juste après.

ou bien alors que tes machines ne soient pas correctement synchronisées
dessus.

Mes Linux, oui.

Avec ntpdate si je comprends bien ?

Mais pas mon Windows jusqu'ici (je savais pas faire, apparemment il
fallait démarrer un service).

Donc j'imagine un Windows 2000 ? Sur Windows XP et 2003 le service tourne
par défaut et se synchronise régulièrement sur le serveur de temps de
Microsoft.

Et puis j'avais de la chance, apparemment il dérive très peu, pas comme
ma passerelle qui prendrait une minute par jour autrement.

Ah bah tiens justement, voilà une des bonnes raisons pour que tourne ntpd
sur ta passerelle et que je commence mon «speech».

Bon, déjà pourquoi installer ntpd et avoir un serveur NTP qui va servir le
temps à l'ensemble de son réseau et pourquoi ne pas simplement laisser
chaque machine se synchroniser sur un serveur de temps externe ? Deux
raisons comme je l'évoquais précédemment.

La première, ça permet bien évidement de desservir les serveurs de temps
publiques qui ont généralement tous une politique d'utilisation bien définie
et stricte. En principe, ils autorisent un nombre limité de requêtes par
jour pour la même adresse IP. Personnellement, je me suis déjà vu dans le
passé me faire «blacklister» par un serveur de temps publique français juste
pour l'avoir trop utilisé (même pas 5 requêtes par jour).

La deuxième raison, c'est que sur un réseau où des machines partagent
entre-elles différentes ressources, il est important que celles-ci aient la
même référence de temps. Peu importe même si cette référence de temps n'est
pas précisément à l'heure. Ce qui compte avant tout c'est que toutes les
machines soient exactement à la même heure. Seul un serveur de temps
centralisé peut assurer cela. De plus, si l'accès à Internet est interrompu
ou intermittent, par exemple un accès RTC, la synchronisation du temps des
machines sur le réseau continue à être maintenue.
Notons aussi que si on donne une liste de plusieurs serveurs NTP à ntpd
(c'est ce que généralement on conseille), ntpd sera alors déterminer, avec
le temps, le ou les serveurs qui semblent être les plus précis, fiables et
donc ceux à préférer des autres. Ça n'est pas vraiment possible avec
ntpdate.


Ensuite, la bonne raison de faire tourner ntpd sur toutes ses machines, je
la donne avec l'exemple concret suivant.
J'ai configuré sur ma passerelle mon serveur NTP pour qu'il se synchronise à
partir de trois serveurs NTP de strate 2 (que j'affectionne :]) et pour
qu'il sert le temps à toutes les machines de mon réseau. Or en temps normal,
c'est-à-dire sans synchronisation NTP, sur ma passerelle et aussi sur
d'autres machines, mes horloges système retardent ou avancent de plusieurs
secondes voir jusqu'à plusieurs minutes par jour. Ça tombe bien, c'est une
des fonctions de ntpd, si ce n'est sa fonction principale, que de corriger
ces dérives d'horloge qui sont fréquentes sur nos PC.
Pour vérifier, sur ma passerelle, le bon fonctionnement de ntpd à corriger
la dérive et à maintenir stable l'horloge système, je l'ai laissé tourner
plusieurs jours. À partir de là, il a du en principe calculer avec
suffisamment de précision la dérive de mon horloge système. J'ai alors
retiré pendant un certain temps les trois serveurs NTP de référence pour
voir comment ntpd allait, tout seul et d'après son calcul de dérive,
corriger la dérive «naturelle» de mon horloge système et maintenir cette
horloge la plus exacte possible. Et bien au bout de 5 jours, mon horloge
système avait seulement dérivé de moins de une demie seconde alors que sans
ntpd elle aurait dérivé de plusieurs minutes.

L'autre avantage à faire tourner ntpd sur une machine, c'est la manière dont
il corrige la dérive de l'horloge système.
Par exemple, une horloge qui avance et qu'on va régulièrement ou non
remettre à l'heure à un instant donné, peut conduire à des conséquences
inattendues. En effet, un évènement système ayant commencé avant cette mise
à l'heure pourrait alors se voir terminer à une date antérieure ou bien
alors avoir calculé un intervalle de temps erroné. Ce qui, dans certains
cas, peut être critique et fatal. Avec ntpd, cela ne peut pas arriver, car
si l'heure avance, ntpd va alors ralentir progressivement l'horloge système
sans jamais la faire retarder. Ainsi, le temps ne fait qu'augmenter tout en
étant plus ou moins corrigé.

Enfin, le protocole NTP est une bonne introduction sur la mise en pratique
du protocole broadcast et surtout du protocole multicast, mais aussi sur la
sécurisation des données échangées avec le protocole UDP connu pour être
facilement «spoofé».
En effet, le protocole NTP dans ses versions récentes permet de servir le
temps sur un réseau sans que les machines clientes connaissent à l'avance
l'adresse du serveur NTP, grâce au mode broadcast ou multicast, le dernier
ayant bien sûr l'avantage de ne pas polluer le réseau inutilement
contrairement au mode broadcast. Et NTP permet de sécuriser les paquets
échangés et d'authentifier les clients et serveurs grâce à une cryptographie
par signature numérique, soit avec une clé partagé ou soit avec un jeu de
bi-clés.

Conclusion, cela te semble-t-il convaincant ? La curiosité qu'on te connait,
va-t-elle se laisser tenter par l'expérience NTP ? :-P

--
TiChou

"TiChou" wrote in message <gniii.20051122011758@florizarre.tichou.org>:

L'autre avantage à faire tourner ntpd sur une machine, c'est la manière dont
il corrige la dérive de l'horloge système.
Par exemple, une horloge qui avance et qu'on va régulièrement ou non
remettre à l'heure à un instant donné, peut conduire à des conséquences
inattendues.

Si tu penses à un ntpdate appelé manuellement, ou bien par une crontab, la
situation est quand même meilleure : par défaut, si la désynchronisation
n'est pas trop importante, il va utiliser l'appel système adjtime, qui
corrige l'heure progressivement, en gardant la monotonie.

Dans le message <news:dlu2bs$2s50$2@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration :

L'autre avantage à faire tourner ntpd sur une machine, c'est la manière
dont il corrige la dérive de l'horloge système. Par exemple, une horloge
qui avance et qu'on va régulièrement ou non remettre à l'heure à un
instant donné, peut conduire à des conséquences inattendues.

Si tu penses à un ntpdate appelé manuellement, ou bien par une crontab,

Oui, c'est à ça que je pensais.

la situation est quand même meilleure : par défaut, si la
désynchronisation n'est pas trop importante, il va utiliser l'appel
système adjtime, qui corrige l'heure progressivement, en gardant la
monotonie.

Exact oui. Mais, comme tu le dis, seulement si la désynchronisation est
faible, à savoir moins de 0.5 seconde.
Or, comme je le faisais plus ou moins remarqué, ce n'est pas rare d'avoir
rapidement une dérive supérieure à 0.5 seconde sur une machine.

--
TiChou

Le 21 novembre 2005 à 09:11, dyrmak a dit :

En 15 lignes moi a écrit
dans news:dlqf7b$ksa$1@domitilla.aioe.org
le dimanche, 20 novembre 2005 à 19:21:56 :

Bonjour,

Je ne comprend pas trop là, tu dis bonjour

mais c'est plutôt le soir ?

C'est parce que Usenet est asynchrone :p

--
Sébastien Kirche

Ce qui m'étonnait, c'est que toi qui t'intéresses tant aux protocoles
réseaux, tu n'ais pas ton propre serveur NTP
ou bien alors que tes machines ne soient pas correctement synchronisées
dessus.

Mes Linux, oui.

Avec ntpdate si je comprends bien ?

Oui, pour la passerelle. A chaque reconnexion et une fois par jour. Les
autres... euh, je sais plus, peut-être au démarrage, ils ne sont pas
allumés en permanence.

Mais pas mon Windows jusqu'ici (je savais pas faire, apparemment il
fallait démarrer un service).

Donc j'imagine un Windows 2000 ?

Oui.

Sur Windows XP et 2003 le service
tourne par défaut et se synchronise régulièrement sur le serveur de
temps de Microsoft.

Mine de rien il en connaît un rayon sur Windows ;-)

[Plaidoyer pour ntpd]

La première, ça permet bien évidement de desservir les serveurs de temps
publiques qui ont généralement tous une politique d'utilisation bien
définie et stricte. En principe, ils autorisent un nombre limité de
requêtes par jour pour la même adresse IP. Personnellement, je me suis
déjà vu dans le passé me faire «blacklister» par un serveur de temps
publique français juste pour l'avoir trop utilisé (même pas 5 requêtes
par jour).

J'utilise le serveur NTP de mon FAI que je paie, alors j'espère bien
qu'il ne limite pas mes requêtes.

La deuxième raison, c'est que sur un réseau où des machines partagent
entre-elles différentes ressources, il est important que celles-ci aient
la même référence de temps.

Certes, mais là on ne parle pas d'un vrai réseau d'entreprise sérieux
mais de mon petit réseau domestique de quatre machines qui ne partagent
rien (pas de NFS ni Samba ni imprimante) parce que 1) je n'en ai pas
besoin et 2) je ne sais pas faire. FTP roulaize !

[...]

Or en temps normal, c'est-à-dire sans synchronisation NTP,
sur ma passerelle et aussi sur d'autres machines, mes horloges système
retardent ou avancent de plusieurs secondes voir jusqu'à plusieurs
minutes par jour. Ça tombe bien, c'est une des fonctions de ntpd, si ce
n'est sa fonction principale, que de corriger ces dérives d'horloge qui
sont fréquentes sur nos PC.

Il me semblait qu'il existait un autre moyen de corriger la dérive
d'horloge, sans avoir besoin de faire tourner un démon en permanence.

[...]

Enfin, le protocole NTP est une bonne introduction sur la mise en
pratique du protocole broadcast et surtout du protocole multicast, mais
aussi sur la sécurisation des données échangées avec le protocole UDP
connu pour être facilement «spoofé».

Ahem... multicast, crypto... justement les sujets qui fâchent. :(

Conclusion, cela te semble-t-il convaincant ? La curiosité qu'on te
connait, va-t-elle se laisser tenter par l'expérience NTP ? :-P

J'ai peur que la curiosité ne soit pas suffisante au regard du rapport
bénéfice/investissement que ça demanderait. C'est un métier tout ça, et
ce n'est pas le mien.

"TiChou" wrote in message <gniii.20051122011758@florizarre.tichou.org>:

Enfin, le protocole NTP est une bonne introduction sur la mise en pratique
du protocole broadcast et surtout du protocole multicast

Au fait, il faut quand même rappeler que le NTP passif en (broad|multi)cast
est moins précis que le NTP actif par interrogation du serveur (parce que
dans ce dernier cas, le client connaît le round-trip).