the_ionic a écrit 14 commentaires

Oui merci mais en fait, c'est plus pour des protocoles plus complexes styles IGMP, STP, LACP etc...
Les trucs de bases ne me posent pas de problèmes (IP, UDP, TCP, ICMP).

Merci à tout le monde pour vos réponse, c'était ce qu'il me fallait pour le moment.

Ok merci pour la réponse, mais moi ce que je voulais savoir, c'est plutôt comment savoir ou elle est la fonction? Car bon, je suis en stage, et on m'a demandé de trouver quelle fonction du noyau était utilisé pour un certain protocole... donc moi, ben j'ai regardé les appels fonctions utilisées par le protocole et je veux ensuite, ben descendre de proche en proche pour arriver au fonction du noyau utilisé, c'est bien comme ça non?

Ethereal permet uniquement de capturer ce qui part ou passe, pas d'accélérer ou de ralentir les paquets... enfin c'est ce que tu me dis aussi remarque! mais dans ce cas là, pas d'utilité!
Concernant netfilter, j'y ai pensé aussi, je pense que cela peut me permettre de faire ce que je veux, ou tout du moins de m'en rapprocher mais de ce que j'ai lu, ça va pas forcément être simple. Je me disais que y'avait peut être un pti truc dans le genre qui avait déja été développé!

juste une petite précision, c'est >120ms pour que NTP considère que c'est une grande différence. 1000seconde est la différence à partir de laquelle NTP refuse de faire quelque chose avec le serveur car il le considère comme invalide et se kille (durée modifiable avec l'option tinkier panic 0) que j'utilise pour permettre de mettre à jour même en cas de grande différence...

<<que se passe t'il si mes machines locales doivent attendre 55 minutes avant que cron relance la tache? et bien on va pas être à l'heure pendant 55 minutes
Pas exactement: si le décalage n'est pas énorme, ntp va 'rattraper' le coup.>>
Oui mais justement, mon célèbre scénario du pire cas fait que c'est une grande différence ;-)

<<Sinon NTP peut fonctionner en broadcast il me semble. Ce ne sont plus les stations qui demandent l'heure mais ton serveur qui diffuse>>
Ca serait bien une solution oui, je comptais m'y attaquer dès lundi au broadcast, multicast, et manycast que propose NTP


<<je pense que ce qu'on me demande n'est tout simplement soit pas faisable, soit pas indiqué avec le protocole NTP.
C'est aussi ce que je pense. Voir http://www.hsc.fr/ressources/breves/ntp-auth.html.fr pour une description du fonctionnement de NTP. Il est bien dit que NTP est conçu pour ne jamais revenir en arrière et utilise les appels systèmes permettant d'"accélérer" ou de "ralentir" le décompte du temps.>>
Moi j'ai bien lu l'article que tu dis plusieurs fois, et ce n'est pas le seul qui dit que NTP est conçu pour ne jamais revenir en arrière mais ça n'est pas vrai pour moi. En effet, NTP quand il y a une trop grande différence entre l'horloge de référence et l'horloge du serveur (> 1000 secondes par défaut) fait ce qu'il apelle un STEP ADJUSTEMENT, c'est à dire qu'il met à l'heure l'horloge d'un seul coup, pas en ralentissant ou en augmentant le décompte du temps... il est donc parfaitement possible de revenir en arrière dans ce cas là!


<<.. mais on me demande pas à tout prix de le faire, on me demande si c'est envisageable et surtout utile mais moi, je pense dire non dans le pire des cas.
Ben le fait d'être utile ou non dépend de ce qui va derrière. Ca dépend aussi du matériel présent sur le réseau. Faut voir aussi la dérive de l'horloge de ta carte qui te sert de base de temps .>>
C'est exactement ce que j'ai répondu dans un doc interne tout à l'heure décrivant mon avancement, c'est que dans ce scénario du pire cas, il contient à l'utilisateur de la carte (je rapelle qu'à terme, le serveur NTP se trouvera sur une carte embarquée) de garantir que son horloge est correct sinon, cela revient à foutre le modèle NTP en vrac. J'ai pris cette exemple, en gros, NTP est organisé en strate, chaque strate synchronisant la couche qui est en dessous et se synchronisant avec la couche qui est au dessus... et bien dans mon cas, ça revient à intercaler une strate foireuse au milieu ce qui, on le comprends naturellement est un peu abérrant!
Bon en tout cas merci pour tes réponses, là, c'est le week end, mais promis, dès lundi je donne des nouvelles de mon avancement, et notamment l'utilisation des options de broadcast et de multicast, vu que ça à l'air de t'interesser et je me dis surtout que si qq'un à le même problème par la suite, sera bien content de trouver ces quelques éléments!

J'ai aussi envisagé cette solution effectivement mais cela pose aussi un problème. Imagine, bon je suis toujours dans le cas le pire, que ma machine serveur NTP de mon réseau local qui se synchronise sur une source extérieure n'est pas à l'heure? Donc bon, mon serveur NTP va se mettre à jour (via un step adjustement, vu que c'est une grande différence car je rapelle que j'envisage le pire cas et que normalement ma carte est connectée à Internet que très rarement) et va par exemple gagner 5 minutes. Et bien que se passe t'il si mes machines locales doivent attendre 55 minutes avant que cron relance la tache? et bien on va pas être à l'heure pendant 55 minutes dans mon réseau local, alors certes je peux diminuer le temps d'exécution de la commande dans cron mais à ce moment là, on perd à mon sens tout l'intérêt de NTP... c'est à dire qu'on va pas effectuer les corrections régulièrement mais uniquement à coup de rdate (ou plutot de ntpdate je pense)... alors ouai je comprends bien que c'est un peu chiant ce que je demande mais c'est comme ça, mais en gros je pense que ce qu'on me demande n'est tout simplement soit pas faisable, soit pas indiqué avec le protocole NTP... mais on me demande pas à tout prix de le faire, on me demande si c'est envisageable et surtout utile mais moi, je pense dire non dans le pire des cas. C'est à dire celui que je présente depuis tout à l'heure, le cas ou ma carte va aller se connecter ponctuellement à une source avec laquelle il est en grand décalage... ce qui n'est normalement pas le cas pour NTP vu qu'en général avant d'aller se synchroniser, on fait un ntpdate sur le serveur; Le problème, c'est que je ne sais pas quand ma carte va être connecté au Net, donc quand faire le ntpdate parce que sinon, ça serait une solution... dès que je me connecte au net, j'arrête le démon, je fais un ntpdate sur mon serveur NTP puis je relance le démon. Le truc, c que pendant ce temps là, mes clients ne sont plus à la même heure et le temps qu'il se reconnecte à mon serveur NTP (même avec l'option iburst activé et minpoll au minimum), y se sera passé un petit peu de temps (genre peut être 4 secondes ce qui fait 4 secondes de log foireux, ce qui peut être assez problématique)...

<<Tu risque d'avoir des soucis si ton horloge avance par rapport à une base de temps universelle. Tu risque d'avoir des logs non cohérentes, surtout si tu fais une mise à jour brutale par rapport à la base de temps universelle.>>
Je suis bien d'accord avec ça, mais pour le moment, c'est le fonctionnement précis de NTP, et de l'adapter pour qui fonctionne dans les contraintes citées précédement qu'on me demande, tout en étudiant l'impact de problèmes comme celui que tu soulèves là, c'est à dire en gros, que toutes mes machines de mon réseau local se retrouve à faire un saut en arrière d'où gros problème au niveau des logs mais d'autres problèmes tout aussi grave... Si quelqu'un avait une URL ou qq chose sur ce sujet, ça serait cool. Et si tu veux, pour le moment, je fonctionne en imaginant le pire, normalement, ma carte ne va pas avoir 15 heures de décallage mais je sais qu'on va me demander ce qui se passe dans ces cas là et si NTP réagit bien, c'est pour ça que je le teste;

<<Y a un autre truc qui m'inquiète, c'est ton "dans un premier temps". Ca veut dire que d'autres choses sont prévues? Quoi donc Parce que ça risque d'influer sur le choix de la solution à apporter. les problèmes de synchronisation sur un ensemble de systèmes ne sont pas si simple à résoudre qu'ils en ont l'air.>>

Pour l'instant, le premier temps est uniquement ce qu'on m'a demandé, mais pour être bref, les clients de mon employeur sont les militaires qui sont plutot secrets secrets dans le genre, donc y ont demandé à la boite, pourriez pas nous mettre le NTP? Après pourquoi ils veulent l'utiliser à part pour synchroniser, j'en sais rien. C'est sur que si c'est pour par exemple de la gestion de base de données de transactions etc, ca risquerait d'être le merdier totale si le temps revient en arrière. Donc voilà, j'aimerai bien savoir si quelqu'un si connait un peu dans ce sujet, ça m'interesse aussi de philosopher un peu la dessus ;-)... merci d'avance

Ben si dans l'idéal enfin si je comprends bien ce que ça fait, en gros ce module fait horloge de référence à partir d'une source GPS, c'est bien ça? Le problème, c'est que moi, pour ne rien te cacher, je développe ce truc pour une carte switch routeur destiné à l'embarqué avec un linux faisant tourner le tout, et je dois faire que ça soit cette carte qui assure la synchronisation du temps... pas un truc externe car je doute que les utilisateurs de la carte embarqués soit prêt à faire une place dans leur avion pour un module externe! Le but n'est pas tant que la carte soit à la vraie heure en fait, mais que toutes les machines branchés sur cette cartes soit à l'heure (en gros pour permettre de faire un système de log cohérent dans un premier temps) mais que quand même si on veut être à la vraie heure, on puisse faire que la carte aille sur un serveur NTP public...

L'option -g marche bien, mais elle ne marche qu'une seule fois au démarrage du démon. Or moi, je ne veux pas arrêter mon démon, il doit tourner en permanence, on y a pas forcément accès sur la carte et le système de script me parait un peu trop lourd (même si ça marcherait j'en conviens). J'ai trouvé l'option ticker panic 0 à rajouter dans le ntp.conf qui permet de de faire des mises à jour même si l'écart de temps est grand à partir d'un serveur, mais un problème subsiste.
Si je mets q'un seul serveur dans mon fichier ntp.conf, ça marche bien, même si y'a un gros écart, pas de problème, il met à jour. Par contre dans le scénario que je veux tester, je dois donc mettre comme serveur NTP un serveur distant, et aussi mon horloge de référence. Donc je commence en étant uniquement sur mon réseau local, NTP synchronise alors à partir de mon horloge (que j'ai déréglé pour émuler un écart de temps important), puis je branche mon cable réseau. NTP choisit le serveur NTP distant (et me jette pas malgrè la grande différence de temps d'ou l'intéret de l'option Panic) mais par contre, il ne met pas à jour l'heure d'un seul coup comme je m'y attendais... alors toujours le même problême.

Ce document (que j'avais déja lu) et effectivement un des meileurs disponibles car il vulguarise mais en rentrant quand même dans les détails, le seul problème, c'est qu'il n'y rentre pas assez mais c'est vrai que si quelqu'un repasse par là, pour un premier contact avec NTP, je conseillerai ce document.... me reste plus qu'à plonger dans les RFC et sur la page de Mr "adorateur de lapins pas pédagogue" Mills...

NTP change effectivement l'horloge système mais je me demande toujours selon quelle stratégie. C'est vraiment un foutoir pas possible la doc, et à chaque fois que je pense avoir un début de solution, et bien je retombe sur un problème.
En effet, le client semble obtenir la déviation de son horloge interne par rapport au serveur NTP, et applique cette correction... la question est, comment calcule t'il cette déviation (qui est une fréquence appelée compensation drift)???

Effectivement, j'avais pensé au RFC, j'avais commencé à les lire et pi je me suis dis, peut être que quelqu'un aurait pu simplement me répondre parce que c'était pas trop pointu ce que je demandais, et que je n'avais peut être pas besoin de comprendre les algorithmes de calculs de temps en détail pour cela... Sachant en plus que le RFC 1305 décrit la version NTP3, et que j'utilise la version NTP4 qui n'est pas encore documenté sous forme de RFC. Il y a bien la page du créateur de NTP, david mills, mais ce monsieur semble plus doué pour la création que pour la pédagogie!
Merci quand même

Pour le premie lien, n'avais-je pas précisé que j'avais cherché sous google... enfin bref, je suppose que ça doit être un message de bienvenue. Le deuxième, je l'ai déja lu, et il ne dit absolument rien de concret, vulgarise bien mais c'est tout. Le troisième, c'est la FAQ que j'ai lu attentivement, et qui explique bien comment installé, comment NTP fonctionne (du point de vue informatique, comment fonctionne le démon etc...) mais ne dit pas précisément comment fait NTP pour fonctionner. Enfin si mais ne répond pas clairement aux questions posées ci-dessus, ou alors je n'arrive pas à comprendre.
Quel précision attendre de NTP? Comment voir la précision sur une machine synchronisée par NTP? Quels est l'impact de la jigue réseau sur la stabilité de NTP, exemple, le délai pour aller au serveur fluctue énormément? Est ce que le but de NTP au final est t'il simplement de calculer la dérive de la fréquence et de l'appliquer toutes les secondes à l'horloge interne, et de recalculer cette dérive selon un intervalle de temps?
Toutes ces questions qui je trouve n'ont pas clairement de réponse dans ce document....
Merci quand même