ntpd: evitare la sincronizzazione locale

Post by NicoKid
cut...
server ntp1.ien.it key 1
server ntp2.ien.it key 2
server 127.127.1.0

Quale è il senso che desideravi dare a quest'ultima?
Hai un reference clock locale (inteso come scheda connessa al server con
funzioni di orologio di precisione)?

Post by NicoKid
Domanda: e' possibile evitare che ntpd si sincronizzi con se stesso ?

Basta non dirgli di farlo, e di default non lo fa...

bio

2007-09-04 09:27:05 UTC

Post by Skull

Post by NicoKid
server ntp1.ien.it key 1
server ntp2.ien.it key 2
server 127.127.1.0

Quale è il senso che desideravi dare a quest'ultima?
Hai un reference clock locale (inteso come scheda connessa al server con
funzioni di orologio di precisione)?

127.127.1.0 (alias LOCAL(0)) e' un riferimento orario locale che non
viene utilizzato per la sincronizzazione (stratum alto, non prefer),
tranne quando non sono disponibili altre sorgenti.

Il suo problema, forse, potrebbe essere in una non corretta gestione
delle chiavi di autenticazione che gli impedisce d'usare i server di
ien (che, peraltro, come nota anche giovanni, funzionano anche senza
auth) per cui ntpd fallbacca [1] a 127.127.1.0.

Penso che un "ntpq -p" possa aiutare a capire meglio, insieme ai log
in syslog (hint).

Possibile soluzione: non usare l'autenticazione.

Fabio

[1] bella, eh?

NicoKid

2007-09-04 11:02:49 UTC

Post by Skull

Post by NicoKid
server ntp1.ien.it key 1
server ntp2.ien.it key 2
server 127.127.1.0

Quale è il senso che desideravi dare a quest'ultima?
Hai un reference clock locale (inteso come scheda connessa al server con
funzioni di orologio di precisione)?

127.127.1.0 (alias LOCAL(0)) e' un riferimento orario locale che non
viene utilizzato per la sincronizzazione (stratum alto, non prefer),
tranne quando non sono disponibili altre sorgenti.

Questo e' il problema. Dovrebbe almeno scrivermelo nei log, oppure una cosa
bellissima sarebbe che negasse la sincronizzazione ai pc locali finche' non
riesce a connettersi con i server ntp remoti. O almeno mandarmi una mail :(

Post by bio
Il suo problema, forse, potrebbe essere in una non corretta gestione
delle chiavi di autenticazione che gli impedisce d'usare i server di
ien (che, peraltro, come nota anche giovanni, funzionano anche senza
auth) per cui ntpd fallbacca [1] a 127.127.1.0.
Penso che un "ntpq -p" possa aiutare a capire meglio, insieme ai log
in syslog (hint).

Si questo mi ha permesso di capire che ntpd non usava ien.

Post by bio
Possibile soluzione: non usare l'autenticazione.

L'autenticazione l'ho cavata infatti.
Ma la cosa strana e' che dopo aver cambiato i server e tolte le chiavi,
ntpq -p continuava a mettere "l'asterisco" su LOCAL. Ho dovuto fare un
ntpdate a mano per sistemare la cosa.

Grazie, Nicola.

--
chi va pian va san e va lontan

bio

2007-09-04 11:40:02 UTC

Post by NicoKid
Questo e' il problema. Dovrebbe almeno scrivermelo nei log, oppure una cosa

Un grep ntpd /var/log/syslog no nti dice niente? Mi pare strano.

Post by NicoKid
bellissima sarebbe che negasse la sincronizzazione ai pc locali finche' non
riesce a connettersi con i server ntp remoti. O almeno mandarmi una mail :(

Non vorrei sbagliarmi, ma l'aggiunta del 127.127.1.0 serve *proprio* a
permette l'erogazione del servizio anche in assenza di server esterni.
Deciditi, e crea una configurazione che ti soddisfi :-)

Post by bio
Possibile soluzione: non usare l'autenticazione.

L'autenticazione l'ho cavata infatti.

Ok. Adesso che abbiamo capito che questo poteva essere il problema, la
puoi rimettere in modo corretto, se vuoi.

Post by NicoKid
Ma la cosa strana e' che dopo aver cambiato i server e tolte le chiavi,
ntpq -p continuava a mettere "l'asterisco" su LOCAL. Ho dovuto fare un
ntpdate a mano per sistemare la cosa.

Differenza orario eccessiva?

Fabio

Skull

2007-09-04 12:42:07 UTC

Post by NicoKid
Questo e' il problema. Dovrebbe almeno scrivermelo nei log, oppure una cosa

Un grep ntpd /var/log/syslog no nti dice niente? Mi pare strano.

Post by NicoKid
bellissima sarebbe che negasse la sincronizzazione ai pc locali finche' non
riesce a connettersi con i server ntp remoti. O almeno mandarmi una mail :(

Non vorrei sbagliarmi, ma l'aggiunta del 127.127.1.0 serve *proprio* a
permette l'erogazione del servizio anche in assenza di server esterni.
Deciditi, e crea una configurazione che ti soddisfi :-)

Infatti, era quello cui mi riferivo commentando la conf precedente
(posto che tanto, vedendo il man, 127.127.1.0 si riferisce sempre e solo
al clock locale: schede esterne hanno altri indirizzi):

Se ben rammento dei pipponi tirati su ntpd, quella riga, unita a

fudge 127.127.1.0 stratum 13

fa sì che lo stratum del server ntp, in assenza di sincronia esterna,
vada a 14.

Se il server si trovasse in assenza di sincronia (quindi senza la riga
relativa a se stesso), invece, si porterebbe a stratum 15, che per il
protocollo NTP significa +infinito, e nessuno si allineerebbe più su di
lui...

NicoKid

2007-09-04 13:11:48 UTC

Post by NicoKid
Questo e' il problema. Dovrebbe almeno scrivermelo nei log, oppure una cosa

Un grep ntpd /var/log/syslog no nti dice niente? Mi pare strano.

Tanto per darti un'idea (log di ieri mentre stavo facendo i test):

3 Sep 16:23:25 ntpd[7946]: synchronized to 62.213.197.54, stratum 3
3 Sep 16:28:32 ntpd[7946]: time reset +307.137438 s
3 Sep 16:28:32 ntpd[7946]: kernel time sync enabled 0001
3 Sep 16:30:14 ntpd[7946]: ntpd exiting on signal 15
3 Sep 16:30:17 ntpd[8001]: frequency initialized 0.000 PPM
from /var/lib/ntp/ntp.drift
3 Sep 16:33:36 ntpd[8001]: synchronized to LOCAL(0), stratum 13
3 Sep 16:33:36 ntpd[8001]: kernel time sync enabled 0001
3 Sep 16:34:42 ntpd[8001]: synchronized to 62.213.197.54, stratum 3

Non spiega perche' alle ore 16:33 si e' sincronizzato con LOCAL(0)

Post by NicoKid
bellissima sarebbe che negasse la sincronizzazione ai pc locali finche'
non riesce a connettersi con i server ntp remoti. O almeno mandarmi una
mail :(

Non vorrei sbagliarmi, ma l'aggiunta del 127.127.1.0 serve *proprio* a
permette l'erogazione del servizio anche in assenza di server esterni.
Deciditi, e crea una configurazione che ti soddisfi :-)

Vuoi dirmi che se cavo "server 127.127.1.0" ntpd continua a fornire il
servizio anche ai pc della intranet?. La documentazione che ho trovato non
e' per niente chiara.

cut...

Post by NicoKid
Ma la cosa strana e' che dopo aver cambiato i server e tolte le chiavi,
ntpq -p continuava a mettere "l'asterisco" su LOCAL. Ho dovuto fare un
ntpdate a mano per sistemare la cosa.

Differenza orario eccessiva?

Boh, e' un'ipotesi.

Grazie, Nicola.

--
chi va pian va san e va lontan

2007-09-04 14:56:01 UTC

Post by NicoKid
Questo e' il problema. Dovrebbe almeno scrivermelo nei log, oppure una cosa

Un grep ntpd /var/log/syslog no nti dice niente? Mi pare strano.

3 Sep 16:23:25 ntpd[7946]: synchronized to 62.213.197.54, stratum 3
3 Sep 16:28:32 ntpd[7946]: time reset +307.137438 s
3 Sep 16:28:32 ntpd[7946]: kernel time sync enabled 0001
3 Sep 16:30:14 ntpd[7946]: ntpd exiting on signal 15
3 Sep 16:30:17 ntpd[8001]: frequency initialized 0.000 PPM
from /var/lib/ntp/ntp.drift
3 Sep 16:33:36 ntpd[8001]: synchronized to LOCAL(0), stratum 13
3 Sep 16:33:36 ntpd[8001]: kernel time sync enabled 0001
3 Sep 16:34:42 ntpd[8001]: synchronized to 62.213.197.54, stratum 3
Non spiega perche' alle ore 16:33 si e' sincronizzato con LOCAL(0)

prova ad aggiungere le opzioni burst e iburst alla direttiva dei server:
server ntp1.inrim.it burst iburst
server ntp2.inrim.it burst iburst

dovrebbe rendere la connessione con i server remoti più affidabile.

come vedi ho usato inrim.it invece che ien.it, che è "deprecato".

NicoKid

2007-09-04 16:32:57 UTC

Post by gt

Post by NicoKid
Questo e' il problema. Dovrebbe almeno scrivermelo nei log, oppure una cosa

Un grep ntpd /var/log/syslog no nti dice niente? Mi pare strano.

server ntp1.inrim.it burst iburst
server ntp2.inrim.it burst iburst
dovrebbe rendere la connessione con i server remoti più affidabile.
come vedi ho usato inrim.it invece che ien.it, che è "deprecato".

Ho usato questo:
server pool.ntp.org burst iburst

Altra domanda: l'ultimo log dice che e' stato sincronizzato alle 16:34. E
dopo ? Non si sincronizza piu' ?

Grazie, Nicola.

--
chi va pian va san e va lontan

bio

2007-09-04 16:12:35 UTC

Post by NicoKid
3 Sep 16:23:25 ntpd[7946]: synchronized to 62.213.197.54, stratum 3
3 Sep 16:28:32 ntpd[7946]: time reset +307.137438 s
3 Sep 16:28:32 ntpd[7946]: kernel time sync enabled 0001
3 Sep 16:30:14 ntpd[7946]: ntpd exiting on signal 15
3 Sep 16:30:17 ntpd[8001]: frequency initialized 0.000 PPM from /var/...
3 Sep 16:33:36 ntpd[8001]: synchronized to LOCAL(0), stratum 13
3 Sep 16:33:36 ntpd[8001]: kernel time sync enabled 0001
3 Sep 16:34:42 ntpd[8001]: synchronized to 62.213.197.54, stratum 3
Non spiega perche' alle ore 16:33 si e' sincronizzato con LOCAL(0)

Perche' per subito lui si sincronizza con 127.127.1.0. Poi, se e quando
ci riesce, con uno dei riferimenti esterni. In particolare l'offset con
62.213.197.54 era piccolo, visto che era gia' sincronizzato, e quindi i
tempi di sincronizazzione sono stati molto brevi (manco un minuto).

Post by bio
Non vorrei sbagliarmi, ma l'aggiunta del 127.127.1.0 serve *proprio* a
permette l'erogazione del servizio anche in assenza di server esterni.
Deciditi, e crea una configurazione che ti soddisfi :-)

Vuoi dirmi che se cavo "server 127.127.1.0" ntpd continua a fornire il
servizio anche ai pc della intranet?. La documentazione che ho trovato non
e' per niente chiara.

Certo, ma devi attendere che si sincronizzi (vedi log) e potrebbe anche
metterci molto. E Finche' non si sincronizza non puo' servire i client.

Post by bio
Differenza orario eccessiva?

Boh, e' un'ipotesi.

No no... guarda che e' quasi sicuramente cosi'. Se non usi -g e/o -x, a
seconda dei casi, i tempi di sincronizzazione possono essere molto alti
con offset molto alti, oppure la sincronizzazione puo' non avvenire del
tutto.

Fabio

Skull

2007-09-04 16:17:23 UTC

Post by bio
No no... guarda che e' quasi sicuramente cosi'. Se non usi -g e/o -x, a
seconda dei casi, i tempi di sincronizzazione possono essere molto alti
con offset molto alti, oppure la sincronizzazione puo' non avvenire del
tutto.

Note: Since the slew rate is limited to 0.5 ms/s, each second of
adjustment requires an amortization interval of 2000 s. Thus an
adjustment of many seconds can take hours or days to amortize.

Significa che con 5 minuti di offset impiega 166 ore (praticamente una
settimana) prima di allinearsi...

NicoKid

2007-09-04 17:28:51 UTC

Ok.

Post by NicoKid
Vuoi dirmi che se cavo "server 127.127.1.0" ntpd continua a fornire il
servizio anche ai pc della intranet?. La documentazione che ho trovato
non e' per niente chiara.

Certo, ma devi attendere che si sincronizzi (vedi log) e potrebbe anche
metterci molto. E Finche' non si sincronizza non puo' servire i client.

Meglio, cosi' mi accorgo dai client che non riesco a sincronizzarmi, e vado
a guardare che ha il server :)

Post by bio
Differenza orario eccessiva?

Boh, e' un'ipotesi.

Beh, su ubuntu -g e' di default.

Grazie, Nicola.

--
chi va pian va san e va lontan

Nisciuno

2007-09-04 12:46:33 UTC

Post by bio
[1] bella, eh?

Minchia, ma è geniale!
:-)

Giovanni

2007-09-04 07:56:51 UTC