J'ai redemarré mon viel Amiga 3000 UX. Marche comme un chef. Bien entendu, la
pendule hard est morte et je fais(ais) un rdate sur ma machine linux (ce qui me
valait des uptime > 7000 jours !) sous Debian 3.0. No problemo, ça fonctionnait.
Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux,
spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé
servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui
va bien). Me parlez pas de porter ci ou ça sous Sys Vr4, j'ai pas le temps.
Qui a de lueurs sur le port utilisé par rdate, qui sert ce client etc...
Viel Danke,
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
alain.didierjean
Selon :
J'ai redemarré mon viel Amiga 3000 UX. Marche comme un chef. Bien entendu, la pendule hard est morte et je fais(ais) un rdate sur ma machine linux (ce qui me valait des uptime > 7000 jours !) sous Debian 3.0. No problemo, ça fonctionnait. Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux, spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui va bien). Me parlez pas de porter ci ou ça sous Sys Vr4, j'ai pas le temps. Qui a de lueurs sur le port utilisé par rdate, qui sert ce client etc... Viel Danke,
# date 101120212005 Tue Oct 11 19:21:00 MET 2005 # setclk -s # uptime 7:21pm up 10145 days, 17:31, 2 users, load average: 0.00, 0.00, 0.03 # Pas beau, ça ?
-- mailing list
-- mailing list
Selon alain.didierjean@free.fr:
J'ai redemarré mon viel Amiga 3000 UX. Marche comme un chef. Bien entendu, la
pendule hard est morte et je fais(ais) un rdate sur ma machine linux (ce qui
me
valait des uptime > 7000 jours !) sous Debian 3.0. No problemo, ça
fonctionnait.
Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au
mieux,
spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est
censé
servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp
qui
va bien). Me parlez pas de porter ci ou ça sous Sys Vr4, j'ai pas le temps.
Qui a de lueurs sur le port utilisé par rdate, qui sert ce client etc...
Viel Danke,
# date 101120212005
Tue Oct 11 19:21:00 MET 2005
# setclk -s
# uptime
7:21pm up 10145 days, 17:31, 2 users, load average: 0.00, 0.00, 0.03
#
Pas beau, ça ?
J'ai redemarré mon viel Amiga 3000 UX. Marche comme un chef. Bien entendu, la pendule hard est morte et je fais(ais) un rdate sur ma machine linux (ce qui me valait des uptime > 7000 jours !) sous Debian 3.0. No problemo, ça fonctionnait. Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux, spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui va bien). Me parlez pas de porter ci ou ça sous Sys Vr4, j'ai pas le temps. Qui a de lueurs sur le port utilisé par rdate, qui sert ce client etc... Viel Danke,
# date 101120212005 Tue Oct 11 19:21:00 MET 2005 # setclk -s # uptime 7:21pm up 10145 days, 17:31, 2 users, load average: 0.00, 0.00, 0.03 # Pas beau, ça ?
-- mailing list
-- mailing list
Christophe Garault
a écrit :
J'ai redemarré mon viel Amiga 3000 UX.
Bonsoir tout d'abord,
Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux, spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui va bien).
Je ne vois pas pourquoi ce serait listé dans /etc/rpc: ce serait un peu dangereux d'avoir un serveur de temps qui lance des procédures appelées depuis un client ! Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil. Un "grep -i ntp /etc/services " t'indiquera que celà tourne sur le port TCP et UDP 123. Ensuite un " netstat -apnu" te montrera si oui ou non un service est lancé sur ce port. S'il ne l'est pas il faut le configurer, le lancer et l'enregistrer par un rc-update. La doc de ntpd est très bien faite.
PS: en lisant le readme on voit que rdate a eu 11 ans hier. Je me demande s'il existe beaucoup d'outils proprios avec une telle longévité d'autant que les rfc successives ont modifié le port tcp et udp. Belle preuve de la qualité de l'architecture d'Unix.
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
alain.didierjean@free.fr a écrit :
J'ai redemarré mon viel Amiga 3000 UX.
Bonsoir tout d'abord,
Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux,
spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé
servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui
va bien).
Je ne vois pas pourquoi ce serait listé dans /etc/rpc: ce serait un peu
dangereux d'avoir un serveur de temps qui lance des procédures appelées
depuis un client !
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres
machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305
qui est la dernière à définir le protocole NTP au cas où tu voudrais y
jeter un oeil.
Un "grep -i ntp /etc/services " t'indiquera que celà tourne sur le port
TCP et UDP 123.
Ensuite un " netstat -apnu" te montrera si oui ou non un service est
lancé sur ce port. S'il ne l'est pas il faut le configurer, le lancer et
l'enregistrer par un rc-update. La doc de ntpd est très bien faite.
PS: en lisant le readme on voit que rdate a eu 11 ans hier. Je me
demande s'il existe beaucoup d'outils proprios avec une telle longévité
d'autant que les rfc successives ont modifié le port tcp et udp. Belle
preuve de la qualité de l'architecture d'Unix.
--
Christophe Garault
Take your marks:
Gen too three: Emerge!
Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux, spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui va bien).
Je ne vois pas pourquoi ce serait listé dans /etc/rpc: ce serait un peu dangereux d'avoir un serveur de temps qui lance des procédures appelées depuis un client ! Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil. Un "grep -i ntp /etc/services " t'indiquera que celà tourne sur le port TCP et UDP 123. Ensuite un " netstat -apnu" te montrera si oui ou non un service est lancé sur ce port. S'il ne l'est pas il faut le configurer, le lancer et l'enregistrer par un rc-update. La doc de ntpd est très bien faite.
PS: en lisant le readme on voit que rdate a eu 11 ans hier. Je me demande s'il existe beaucoup d'outils proprios avec une telle longévité d'autant que les rfc successives ont modifié le port tcp et udp. Belle preuve de la qualité de l'architecture d'Unix.
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
alain.didierjean
Selon Christophe Garault :
a écrit :
>J'ai redemarré mon viel Amiga 3000 UX. > Bonsoir tout d'abord,
>Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux, >spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé >servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui >va bien). > Je ne vois pas pourquoi ce serait listé dans /etc/rpc: ce serait un peu dangereux d'avoir un serveur de temps qui lance des procédures appelées depuis un client !
Il me semblait clair que je cherchais rdate le client dans rpc. Relis, tu verras.
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que d'aucuns lisent autrement.
Un "grep -i ntp /etc/services " t'indiquera que celà tourne sur le port TCP et UDP 123.
Ce qui ne fait pas avancer le schmilblick, mais enfin, gràce à toi, je connais l'existence de grep. Bonsoir de bonsoir !!
Ensuite un " netstat -apnu" te montrera si oui ou non un service est lancé sur ce port. S'il ne l'est pas il faut le configurer, le lancer et l'enregistrer par un rc-update. La doc de ntpd est très bien faite.
C'est la 3ème leçon ?
PS: en lisant le readme on voit que rdate a eu 11 ans hier. Je me demande s'il existe beaucoup d'outils proprios avec une telle longévité d'autant que les rfc successives ont modifié le port tcp et udp. Belle preuve de la qualité de l'architecture d'Unix.
Pour ta gouverne, le RFC copétent pour rdate, c'est le 868
Exactement le mail qui craint : tu étales ta (courte) science, tu donnes des leçons, quant au service rendu, y'en a pas. Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Si quelqu'un a la réponse à ma question : en clair quel serveur doit traiter le client rdate + config si il y a astuce, il sera le bien venu.
-- ~adj~ (un rien agacé)
-- mailing list
Selon Christophe Garault <christophe@garault.org>:
alain.didierjean@free.fr a écrit :
>J'ai redemarré mon viel Amiga 3000 UX.
>
Bonsoir tout d'abord,
>Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au
mieux,
>spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est
censé
>servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp
qui
>va bien).
>
Je ne vois pas pourquoi ce serait listé dans /etc/rpc: ce serait un peu
dangereux d'avoir un serveur de temps qui lance des procédures appelées
depuis un client !
Il me semblait clair que je cherchais rdate le client dans rpc. Relis, tu
verras.
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres
machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305
qui est la dernière à définir le protocole NTP au cas où tu voudrais y
jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que
d'aucuns lisent autrement.
Un "grep -i ntp /etc/services " t'indiquera que celà tourne sur le port
TCP et UDP 123.
Ce qui ne fait pas avancer le schmilblick, mais enfin, gràce à toi, je connais
l'existence de grep. Bonsoir de bonsoir !!
Ensuite un " netstat -apnu" te montrera si oui ou non un service est
lancé sur ce port. S'il ne l'est pas il faut le configurer, le lancer et
l'enregistrer par un rc-update. La doc de ntpd est très bien faite.
C'est la 3ème leçon ?
PS: en lisant le readme on voit que rdate a eu 11 ans hier. Je me
demande s'il existe beaucoup d'outils proprios avec une telle longévité
d'autant que les rfc successives ont modifié le port tcp et udp. Belle
preuve de la qualité de l'architecture d'Unix.
Pour ta gouverne, le RFC copétent pour rdate, c'est le 868
Exactement le mail qui craint : tu étales ta (courte) science, tu donnes des
leçons, quant au service rendu, y'en a pas. Jusqu'ici, cette ML était à peu
près épargnée par les ramenards. On dirait que ça change.
Si quelqu'un a la réponse à ma question : en clair quel serveur doit traiter le
client rdate + config si il y a astuce, il sera le bien venu.
>J'ai redemarré mon viel Amiga 3000 UX. > Bonsoir tout d'abord,
>Sous Gentoo, j'obtiens un connection refused sec. La doc de rdate est, au mieux, >spartiate. Comment configurer ça ? Je n'arrive même pas à trouver qui est censé >servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui >va bien). > Je ne vois pas pourquoi ce serait listé dans /etc/rpc: ce serait un peu dangereux d'avoir un serveur de temps qui lance des procédures appelées depuis un client !
Il me semblait clair que je cherchais rdate le client dans rpc. Relis, tu verras.
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que d'aucuns lisent autrement.
Un "grep -i ntp /etc/services " t'indiquera que celà tourne sur le port TCP et UDP 123.
Ce qui ne fait pas avancer le schmilblick, mais enfin, gràce à toi, je connais l'existence de grep. Bonsoir de bonsoir !!
Ensuite un " netstat -apnu" te montrera si oui ou non un service est lancé sur ce port. S'il ne l'est pas il faut le configurer, le lancer et l'enregistrer par un rc-update. La doc de ntpd est très bien faite.
C'est la 3ème leçon ?
PS: en lisant le readme on voit que rdate a eu 11 ans hier. Je me demande s'il existe beaucoup d'outils proprios avec une telle longévité d'autant que les rfc successives ont modifié le port tcp et udp. Belle preuve de la qualité de l'architecture d'Unix.
Pour ta gouverne, le RFC copétent pour rdate, c'est le 868
Exactement le mail qui craint : tu étales ta (courte) science, tu donnes des leçons, quant au service rendu, y'en a pas. Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Si quelqu'un a la réponse à ma question : en clair quel serveur doit traiter le client rdate + config si il y a astuce, il sera le bien venu.
-- ~adj~ (un rien agacé)
-- mailing list
Stéphane GAUTIER
Le 11/10/05, a écrit :
Je n'arrive même pas à trouver qui est censé
servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui va bien). Me parlez pas de porter ci ou ça sous Sys Vr4, j'ai pas le temps. Qui a de lueurs sur le port utilisé par rdate, qui sert ce client etc...
Voila sur une debian standard la ligne qui sert à rdate dans /etc/inetd.conf time stream tcp nowait root internal
Avec une Gentoo en utilisant xinetd.conf
emerge rdate xinetd
Voila les lignes à rajouter dans xinetd.conf. Ou le contenu du fichier time dans /etc/xinetd.d ######## service time { disable = no type = INTERNAL id = time-stream socket_type = stream protocol = tcp user = root wait = no }
# This is the udp version. service time { disable = yes type = INTERNAL id = time-dgram socket_type = dgram protocol = udp user = root wait = yes }
Le 11/10/05, alain.didierjean@free.fr<alain.didierjean@free.fr> a écrit :
Je n'arrive même pas à trouver qui est censé
servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui
va bien). Me parlez pas de porter ci ou ça sous Sys Vr4, j'ai pas le temps.
Qui a de lueurs sur le port utilisé par rdate, qui sert ce client etc...
Voila sur une debian standard la ligne qui sert à rdate dans /etc/inetd.conf
time stream tcp nowait root internal
Avec une Gentoo en utilisant xinetd.conf
emerge rdate xinetd
Voila les lignes à rajouter dans xinetd.conf.
Ou le contenu du fichier time dans /etc/xinetd.d
########
service time
{
disable = no
type = INTERNAL
id = time-stream
socket_type = stream
protocol = tcp
user = root
wait = no
}
# This is the udp version.
service time
{
disable = yes
type = INTERNAL
id = time-dgram
socket_type = dgram
protocol = udp
user = root
wait = yes
}
servir le temps à rdate (pas listé dans /etc/rpc) (coté linux, j'ai un ntp qui va bien). Me parlez pas de porter ci ou ça sous Sys Vr4, j'ai pas le temps. Qui a de lueurs sur le port utilisé par rdate, qui sert ce client etc...
Voila sur une debian standard la ligne qui sert à rdate dans /etc/inetd.conf time stream tcp nowait root internal
Avec une Gentoo en utilisant xinetd.conf
emerge rdate xinetd
Voila les lignes à rajouter dans xinetd.conf. Ou le contenu du fichier time dans /etc/xinetd.d ######## service time { disable = no type = INTERNAL id = time-stream socket_type = stream protocol = tcp user = root wait = no }
# This is the udp version. service time { disable = yes type = INTERNAL id = time-dgram socket_type = dgram protocol = udp user = root wait = yes }
Exactement le mail qui craint : tu étales ta (courte) science, tu donnes des leçons, quant au service rendu, y'en a pas. Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Trop de café ? pas assez de pillules ?
Quoi qu'il en soit, certainement aucune raison d'insulter qui que ce soit ici... (Ton vrai nom c'est pas Dave Null, si?)
Si quelqu'un a la réponse à ma question : en clair quel serveur doit traiter le client rdate + config si il y a astuce, il sera le bien venu.
builtin xinetd, voir /etc/xinetd.d/time-{udp,tcp}
-- Yoann Pannier -- mailing list
alain.didierjean@free.fr wrote, On 10/11/2005 09:42 PM:
Exactement le mail qui craint : tu étales ta (courte) science, tu donnes des
leçons, quant au service rendu, y'en a pas. Jusqu'ici, cette ML était à peu
près épargnée par les ramenards. On dirait que ça change.
Trop de café ? pas assez de pillules ?
Quoi qu'il en soit, certainement aucune raison d'insulter qui que ce
soit ici... (Ton vrai nom c'est pas Dave Null, si?)
Si quelqu'un a la réponse à ma question : en clair quel serveur doit traiter le
client rdate + config si il y a astuce, il sera le bien venu.
builtin xinetd, voir /etc/xinetd.d/time-{udp,tcp}
--
Yoann Pannier
--
gentoo-user-fr@gentoo.org mailing list
Exactement le mail qui craint : tu étales ta (courte) science, tu donnes des leçons, quant au service rendu, y'en a pas. Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Trop de café ? pas assez de pillules ?
Quoi qu'il en soit, certainement aucune raison d'insulter qui que ce soit ici... (Ton vrai nom c'est pas Dave Null, si?)
Si quelqu'un a la réponse à ma question : en clair quel serveur doit traiter le client rdate + config si il y a astuce, il sera le bien venu.
builtin xinetd, voir /etc/xinetd.d/time-{udp,tcp}
-- Yoann Pannier -- mailing list
alain.didierjean
Selon Stéphane GAUTIER :
Le 11/10/05, a écrit :
Je n'arrive même pas à trouver qui est censé > servir le temps à rdate Voila sur une debian standard la ligne qui sert à rdate dans /etc/inetd.conf time stream tcp nowait root internal
Avec une Gentoo en utilisant xinetd.conf
emerge rdate xinetd
Voila les lignes à rajouter dans xinetd.conf. Ou le contenu du fichier time dans /etc/xinetd.d ######## service time { disable = no type = INTERNAL id = time-stream socket_type = stream protocol = tcp user = root wait = no }
# This is the udp version. service time { disable = yes type = INTERNAL id = time-dgram socket_type = dgram protocol = udp user = root wait = yes }
Voilà une réponse comme on les aime : concise, précise, courtoise ; en en un mot efficace. Merci à toi, Stéphane.
-- ~adj~
-- mailing list
Selon Stéphane GAUTIER <stephane.gautier@gmail.com>:
Le 11/10/05, alain.didierjean@free.fr<alain.didierjean@free.fr> a écrit :
Je n'arrive même pas à trouver qui est censé
> servir le temps à rdate
Voila sur une debian standard la ligne qui sert à rdate dans /etc/inetd.conf
time stream tcp nowait root internal
Avec une Gentoo en utilisant xinetd.conf
emerge rdate xinetd
Voila les lignes à rajouter dans xinetd.conf.
Ou le contenu du fichier time dans /etc/xinetd.d
########
service time
{
disable = no
type = INTERNAL
id = time-stream
socket_type = stream
protocol = tcp
user = root
wait = no
}
# This is the udp version.
service time
{
disable = yes
type = INTERNAL
id = time-dgram
socket_type = dgram
protocol = udp
user = root
wait = yes
}
Je n'arrive même pas à trouver qui est censé > servir le temps à rdate Voila sur une debian standard la ligne qui sert à rdate dans /etc/inetd.conf time stream tcp nowait root internal
Avec une Gentoo en utilisant xinetd.conf
emerge rdate xinetd
Voila les lignes à rajouter dans xinetd.conf. Ou le contenu du fichier time dans /etc/xinetd.d ######## service time { disable = no type = INTERNAL id = time-stream socket_type = stream protocol = tcp user = root wait = no }
# This is the udp version. service time { disable = yes type = INTERNAL id = time-dgram socket_type = dgram protocol = udp user = root wait = yes }
Voilà une réponse comme on les aime : concise, précise, courtoise ; en en un mot efficace. Merci à toi, Stéphane.
-- ~adj~
-- mailing list
alain.didierjean
Selon Stéphane GAUTIER :
Le 11/10/05, a écrit :
Je n'arrive même pas à trouver qui est censé > servir le temps à rdate
Merci à Stéphane qui m'a mis sur la voie : je n'avais pas réalisé que le serveur correspondant à rdate comme client était de type internal.
Par ailleurs Gentoo propose dans xinetd un time-tcp : le vieil rdate distribué avec Amiga UX (installé en Nov 91 sur ma machine) fonctionne en UDP ! Après cela, la solution est triviale et tout baigne !!
-- ~adj~
-- mailing list
Selon Stéphane GAUTIER <stephane.gautier@gmail.com>:
Le 11/10/05, alain.didierjean@free.fr<alain.didierjean@free.fr> a écrit :
Je n'arrive même pas à trouver qui est censé
> servir le temps à rdate
Merci à Stéphane qui m'a mis sur la voie : je n'avais pas réalisé que le serveur
correspondant à rdate comme client était de type internal.
Par ailleurs Gentoo propose dans xinetd un time-tcp : le vieil rdate distribué
avec Amiga UX (installé en Nov 91 sur ma machine) fonctionne en UDP !
Après cela, la solution est triviale et tout baigne !!
Je n'arrive même pas à trouver qui est censé > servir le temps à rdate
Merci à Stéphane qui m'a mis sur la voie : je n'avais pas réalisé que le serveur correspondant à rdate comme client était de type internal.
Par ailleurs Gentoo propose dans xinetd un time-tcp : le vieil rdate distribué avec Amiga UX (installé en Nov 91 sur ma machine) fonctionne en UDP ! Après cela, la solution est triviale et tout baigne !!
-- ~adj~
-- mailing list
Christophe Garault
a écrit :
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que d'aucuns lisent autrement.
Désolé si ntp n'est pas le protocole qui sert rdate (ok c'est bien time comme on le constate dans rdate.c: getservbyname("time","udp")) Mais ne vous en déplaise ntpd est bien un service.
[snip le délire du sysadmin asocial]
Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Elle était aussi épargnée par les malotrus. Ce n'est pas la 1ère fois que vous venez chercher de l'aide sur cette liste et que l'on vous répond en tentant de vous aider (et parfois en réussisant regardez vos archives) mais pour ma part je ne vous ai jamais vu contribuer dans l'autre sens. J'imagine que ça décrit bien le personnage.
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
alain.didierjean@free.fr a écrit :
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres
machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305
qui est la dernière à définir le protocole NTP au cas où tu voudrais y
jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que
d'aucuns lisent autrement.
Désolé si ntp n'est pas le protocole qui sert rdate (ok c'est bien time
comme on le constate dans rdate.c: getservbyname("time","udp"))
Mais ne vous en déplaise ntpd est bien un service.
[snip le délire du sysadmin asocial]
Jusqu'ici, cette ML était à peu
près épargnée par les ramenards. On dirait que ça change.
Elle était aussi épargnée par les malotrus. Ce n'est pas la 1ère fois
que vous venez chercher de l'aide sur cette liste et que l'on vous
répond en tentant de vous aider (et parfois en réussisant regardez vos
archives) mais pour ma part je ne vous ai jamais vu contribuer dans
l'autre sens.
J'imagine que ça décrit bien le personnage.
--
Christophe Garault
Take your marks:
Gen too three: Emerge!
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que d'aucuns lisent autrement.
Désolé si ntp n'est pas le protocole qui sert rdate (ok c'est bien time comme on le constate dans rdate.c: getservbyname("time","udp")) Mais ne vous en déplaise ntpd est bien un service.
[snip le délire du sysadmin asocial]
Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Elle était aussi épargnée par les malotrus. Ce n'est pas la 1ère fois que vous venez chercher de l'aide sur cette liste et que l'on vous répond en tentant de vous aider (et parfois en réussisant regardez vos archives) mais pour ma part je ne vous ai jamais vu contribuer dans l'autre sens. J'imagine que ça décrit bien le personnage.
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
Jean-Philippe ROPA
Christophe Garault a écrit :
a écrit :
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que d'aucuns lisent autrement.
Désolé si ntp n'est pas le protocole qui sert rdate (ok c'est bien time comme on le constate dans rdate.c: getservbyname("time","udp")) Mais ne vous en déplaise ntpd est bien un service.
[snip le délire du sysadmin asocial]
Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Elle était aussi épargnée par les malotrus. Ce n'est pas la 1ère fois que vous venez chercher de l'aide sur cette liste et que l'on vous répond en tentant de vous aider (et parfois en réussisant regardez vos archives) mais pour ma part je ne vous ai jamais vu contribuer dans l'autre sens. J'imagine que ça décrit bien le personnage.
Je n'en pense pas moins.
Et quand on demande un service ;-) , M. Didierjean, il faut savoir être courtois. Aucune envie d'essayer de répondre à tes prochaines questions !
Jean-Philippe ROPA
-- mailing list
Christophe Garault a écrit :
alain.didierjean@free.fr a écrit :
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres
machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305
qui est la dernière à définir le protocole NTP au cas où tu voudrais y
jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut
croire que
d'aucuns lisent autrement.
Désolé si ntp n'est pas le protocole qui sert rdate (ok c'est bien
time comme on le constate dans rdate.c: getservbyname("time","udp"))
Mais ne vous en déplaise ntpd est bien un service.
[snip le délire du sysadmin asocial]
Jusqu'ici, cette ML était à peu
près épargnée par les ramenards. On dirait que ça change.
Elle était aussi épargnée par les malotrus. Ce n'est pas la 1ère fois
que vous venez chercher de l'aide sur cette liste et que l'on vous
répond en tentant de vous aider (et parfois en réussisant regardez vos
archives) mais pour ma part je ne vous ai jamais vu contribuer dans
l'autre sens.
J'imagine que ça décrit bien le personnage.
Je n'en pense pas moins.
Et quand on demande un service ;-) , M. Didierjean, il faut
savoir être courtois.
Aucune envie d'essayer de répondre à tes prochaines questions !
Sinon ce n'est pas ntp mais ntpd le démon qui donne l'heure aux autres machines. Un petit "rfc -s time" t'indiquera qu'il s'agit de la rfc1305 qui est la dernière à définir le protocole NTP au cas où tu voudrais y jeter un oeil.
Il me semblait là aussi clair que je parlais du service, mais faut croire que d'aucuns lisent autrement.
Désolé si ntp n'est pas le protocole qui sert rdate (ok c'est bien time comme on le constate dans rdate.c: getservbyname("time","udp")) Mais ne vous en déplaise ntpd est bien un service.
[snip le délire du sysadmin asocial]
Jusqu'ici, cette ML était à peu près épargnée par les ramenards. On dirait que ça change.
Elle était aussi épargnée par les malotrus. Ce n'est pas la 1ère fois que vous venez chercher de l'aide sur cette liste et que l'on vous répond en tentant de vous aider (et parfois en réussisant regardez vos archives) mais pour ma part je ne vous ai jamais vu contribuer dans l'autre sens. J'imagine que ça décrit bien le personnage.
Je n'en pense pas moins.
Et quand on demande un service ;-) , M. Didierjean, il faut savoir être courtois. Aucune envie d'essayer de répondre à tes prochaines questions !
