ntpd lancé en user ntp désiré en root [Résolu]

[tck-lt]

Bonjour,

j'ai installé un serveur ntp sur une machine Solaris 8 (S8). Mes 6 autres machine Solaris se mettent bien à l'heure avec ce serveur mais pas ma machine redhat (RH). La RH joint bien la S8, puisque je vois des échanges ntp s'effectuer :

Code :

1
2
3
4
5
6
7
8
9
10
11
 
________________________________
   RH -> S8    ETHER Type=0800 (IP), size = 90 bytes
   RH -> S8    IP  D=10.1.14.1 S=10.1.14.7 LEN=76, ID=0
   RH -> S8    UDP D=123 S=123 LEN=56
   RH -> S8    NTP  client (Thu Dec 31 14:47:24 2009)
________________________________
   S8 -> RH    ETHER Type=0800 (IP), size = 90 bytes
   S8 -> RH    IP  D=10.1.14.7 S=10.1.14.1 LEN=76, ID=58463
   S8 -> RH    UDP D=123 S=123 LEN=56
   S8 -> RH    NTP  server (Thu Dec 31 15:30:44 2009)

Quand je fais la commande : ntpdate @IPS8, le serveur RH se synchronise correctement. La seule différence notoire que j'ai vu et que RH lance le démon ntpd en user ntp alors qu'il est en root sur les autres machines. Comment lui forcer la main à se lancer en root svp ? Est-ce dans le ntp.conf ?

Merci d'avance pour vos réponses et bon réveillon !

[Mygale1978]

Salut,

Le fait de changer de user pour lancer ton service ntp n'aura pas d'influence sur la synchronisation entre le client et ton serveur de temps.

as-tu vérifié si ton client redhat utilisait le temps universel? (UTC)

http://fr.wikipedia.org/wiki/Network_Time_Protocol

Tu devrais déjà vérifier les points suivants:

Ce que ne fait pas NTP
L'heure de référence fournie par NTP est UTC, à ce titre, il ne s'occupe pas :

• du changement de l'heure dû au fuseau horaire ;
• du passage à l'heure d'été et d'hiver.

Cela est du ressort du système d'exploitation, qui suivant l'endroit où l'administrateur a déclaré que l'ordinateur se trouvait, doit effectuer les corrections adéquates pour se caler sur l'heure légale.
Aucun mécanisme de chiffrement n'est fourni, les messages NTP circulent en clair sur le réseau.

[tck-lt]

Je ne comprends pas en quoi le fait d'être en UTC ou pas pose problème. En effet, normalement le client est censé se caler sur l'heure et la date que lui fournit le serveur sans se soucier de rien.

RH# date
Tue Jan 5 10:15:49 CET 2010
RH# date -u
Tue Jan 5 09:15:51 UTC 2010

S8# date
mardi, 5 janvier 2010, 10:59:57 MET
S8# date -u
mardi, 5 janvier 2010, 09:59:58 GMT

Tu me confirmes que GMT=UTC ?

[Jenna]

Une idée comme cela, il y a des limitations dans le démon ntpd pour ne pas synchroniser si le décalage entre les 2 horloges est trop important.

Essaie d'abord une synchro "grosse louche" à la main et ensuite la synchro fine avec ntpd

[tck-lt]

Trugarez dit' mais ce n'est pas ça. J'ai un écart de 3-4 minutes entre mes 2 horloges et toujours pas de mise à jour. Je pense vraiment à un problème de user.

Vive les Merlus !
(En tant que Breton qui se respecte j'entonnerais bien une p'tite chanson sur les Lorientaises mais je vais m'abstenir).

Ce qui est étrange également c'est le résultat de cette commande :

[root@RH etc]# ntpdc -c sysinfo
system peer: 0.0.0.0
system peer mode: unspec
leap indicator: 11
stratum: 16
precision: -18
root distance: 0.00000 s
root dispersion: 0.00098 s
reference ID: [0.0.0.0]
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
system flags: auth monitor ntp kernel stats
jitter: 0.000000 s
stability: 0.000 ppm
broadcastdelay: 0.003998 s
authdelay: 0.000000 s

ainsi que de celle-là :

[root@RH etc]# ntptrace
localhost.localdomain: stratum 16, offset 0.000011, synch distance 0.00299
0.0.0.0: *Not Synchronized*

Pour un client Unix j'ai ça :

S10:/etc/inet # ntptrace
localhost: stratum 4, offset 0.000042, synch distance 0.09583
S6: stratum 3, offset -0.001652, synch distance 0.08559
ntp.univ-angers.fr: stratum 2, offset -0.000912, synch distance 0.05157
chronos.cru.fr: stratum 1, offset -0.005437, synch distance 0.00000, refid 'GPS'

donc je devrais avoir @IPS8 à la place de 0.0.0.0.
Ce que je ne comprends pas c'est que d'un côté il n'a pas l'air bien configuré, la preuve, le résultat des commandes mais que d'un autre côté il vient correctement sur le serveur S8 en requête NTP.

[tck-lt]

Solution : C'était bien un problème de droit. Le fait que le service client soit lancé avec le user ntp déplaisait à mon serveur en revanche il m'a fallu un peu de temps pour connaitre l'emplacement des options par défaut pour pouvoir les modifier en conséquence.
Dans le fichier /etc/sysconfig/ntpd, j'avais :
OPTIONS="-U ntp -p /var/run/ntpd.pid"

que j'ai remplacé par :
OPTIONS="-p /var/run/ntpd.pid"

Relance du service et la synchronisation s'est effectuée quasi-instantanément.

(Par contre, je ne comprends pas pourquoi cette différence de user l'a perturbé à ce point).

Merci pour votre aide quand même (et Meilleurs Vœux)

[Jenna]

probablement que sur ta machine, l'utilisateur ntp n'a pas le droit/privilège de mettre à jour l'horloge.

[tck-lt]

Le user ntp n'existe même pas
et il ne crie même pas en se lançant, étrange...
m'enfin bon ma première intuition était la bonne il fallait bien modifier le user par défaut c'était ça justement ma toute première question

Bloavez Mad quand même !