Dotaz: Debian 11 NTP server

[Filip]

Ahoj, prosím o radu odborníky. Marně si lámu hlavu s NTP serverem na mám Debian 11 serveru. Problém je v tom že ntp server žádný broadcast neposílá a ani se neaktualizuje s public ntp servery. Přikládám konfiguraci ntp.conf

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift

# Leap seconds definition provided by tzdata
leapfile /usr/share/zoneinfo/leap-seconds.list

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/
logfile /var/log/ntp.log
logconfig =all

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example
server tik.cesnet.cz
server tak.cesnet.cz
server ntp.nic.cz

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: 
#pool 0.debian.pool.ntp.org iburst
#pool 1.debian.pool.ntp.org iburst
#pool 2.debian.pool.ntp.org iburst
#pool 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page 
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Needed for adding pool entries
restrict source notrap nomodify noquery

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust
restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap nopeer

# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
broadcast 192.168.0.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

Výpis ntpq -p mě vypíše toto:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 gw.sh.cvut.cz   .INIT.          16 u    -  512    0    0.000   +0.000   0.000
 147.32.127.250  .INIT.          16 u    -  512    0    0.000   +0.000   0.000
 192.168.0.255   .BCST.          16 B    -   64    0    0.000   +0.000   0.000

Firewall pravidlo pro interni sit mam nastavene a klienti se snazi kontaktovat ntp server ale nedostanou odpoved.

Server provozuji na HW PCengines APU4D4 a mám podezření na HW hodiny daného zařízení. Nevím ale jak toto zjistit. Budou rád za případnou radu. Děkuji.

---

---

Odpovědi

[Filip]

Ještě v syslogu po rstartování NTP dostanu tuto chybu:

ntpd[2257735]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

[Max]

Dokud sám ntp server nebude mít syncnutý čas, nebude přijímat klienty.
Jinými slovy, nenačítá si čas z těch tvých definovaných serverů (proto tam máš nuly u jitteru, init u refid apod.
Osobně doporučuji nechat debianí ntp pooly, je to mnohem spolehlivější a reálně pro ntp server potřebuješ minimálně 3 ntp servery, ale větší počet je lepší.
Zdar Max

[Filip]

Ahoj, děkuji za rychlou odpověď. Bohužel nepomohla nechat ani Debian ntp pooly. Problém je úplně stejný:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 gw.sh.cvut.cz   .INIT.          16 u    -   64    0    0.000   +0.000   0.000
 147.32.127.250  .INIT.          16 u    -   64    0    0.000   +0.000   0.000
 192.168.0.255   .BCST.          16 B    -   64    0    0.000   +0.000   0.000

V syslogu je po restartu ntp naskoci stejna chyba:

Starting Network Time Service...
Jan 27 12:11:03 GFW01 ntpd[2267458]: ntpd 4.2.8p15@1.3728-o Wed Sep 23 11:46:38 UTC 2020 (1): Starting
Jan 27 12:11:03 GFW01 ntpd[2267458]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -u 107:113
Jan 27 12:11:03 GFW01 ntpd[2267458]: ----------------------------------------------------
Jan 27 12:11:03 GFW01 ntpd[2267458]: ntp-4 is maintained by Network Time Foundation,
Jan 27 12:11:03 GFW01 ntpd[2267458]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
Jan 27 12:11:03 GFW01 ntpd[2267458]: corporation.  Support and training for ntp-4 are
Jan 27 12:11:03 GFW01 ntpd[2267458]: available at https://www.nwtime.org/support
Jan 27 12:11:03 GFW01 ntpd[2267458]: ----------------------------------------------------
Jan 27 12:11:03 GFW01 ntpd[2267464]: proto: precision = 0.293 usec (-22)
Jan 27 12:11:03 GFW01 ntpd[2267464]: basedate set to 2020-09-11
Jan 27 12:11:03 GFW01 ntpd[2267464]: gps base set to 2020-09-13 (week 2123)
Jan 27 12:11:03 GFW01 ntpd[2267464]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Jan 27 12:11:03 GFW01 ntpd[2267464]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2022-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen and drop on 0 v6wildcard [::]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 2 lo 127.0.0.1:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 3 enp1s0 172.30.18.15:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 4 enp2s0 192.168.0.254:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 5 enp3s0 192.168.10.253:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 6 enp4s0.100 192.168.100.1:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 7 tun0 192.168.44.1:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 8 wg0 192.168.33.1:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 9 lo [::1]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 10 enp1s0 [2a07:bc0:4ff:4:5265:f3ff:fe7a:3ac4]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 11 enp1s0 [fe80::5265:f3ff:fe7a:3ac4%2]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 12 enp2s0 [fe80::20d:b9ff:fe5c:6bb5%3]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 13 enp3s0 [fe80::20d:b9ff:fe5c:6bb6%4]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 14 enp4s0 [fe80::20d:b9ff:fe5c:6bb7%5]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 15 enp4s0.100 [fe80::20d:b9ff:fe5c:6bb7%6]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listen normally on 16 tun0 [fe80::851:e86:f79a:5730%7]:123
Jan 27 12:11:03 GFW01 ntpd[2267464]: Listening on routing socket on fd #33 for interface updates
Jan 27 12:11:03 GFW01 ntpd[2267464]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jan 27 12:11:03 GFW01 ntpd[2267464]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

[Ptr]

Dostaneš se na ty NTP pool servery (reach je pořád 0)? Stopni na chvíli ntpd a zkus jednorázovou synchronizaci pomocí

ntpdate server.tld

Pokud se nebude synchronizovat, máš asi problém s konektivitou.

[Ptr]

Pardon, nedočetl jsem do konce. Jako kdyby jsem nic nenapsal.

[j]

Klienti nedostanou odpoved dokud nebude ntp server synclej, a ten sync nejakou dobu trva. Dokud synclej neni, tak proste (a logicky) nefunguje.

To ze synclej je poznas tak, ze u nazvu(ipcka) z toho vypisu je *. To je v dany okamzik primarni zdroj casu, kterej to vyhodnotilo jako nejlepsi.

NTP se ti nikdy nesyncne, pokud by lokalni hodiny byly zcela mimo (tusim ze max je hodina).

Zaroven ti taky nikdy nezacne fungovat, pokud by se ti lokalni hodiny prilis rozchazely (tikaj moc rychle nebo moc pomalu). Tohle se projevuje tak, ze mas obrovsky cisla v offsetu. Vetsinou staci zmenit zdroj hodin.

V takovym pripade by te zajimalo neco na tema:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

vs

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

A meni se to trebas jako parametr kernelu (clocksource=xyz)

Samo, muzes to nastavit i tak, ze ten NTP je samostatne bezici a tudiz se nikam nesyncuje.

---

Dete stim guuglem dopice!

[Filip]

Ahoj, díky. Zkousel jsem dane prikazy a dostavam toto.

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

A

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm 

[j]

Tj, ale jak sem rek, tohle portebujes resit jen v situaci, kdy ti ty hodiny nefungujou = porad se ti hodne rozchazej. Casove to pak muzes videt tak, ze ty hodiny rucne syncnes, a za minutu budou ujizdet klidne o desitky sekund.

Jinak uvodni sync trva pokud si pamatuju nejmin 15 minut, protoze se to snazi ty servery nenasrat abys na nich nedostal ban.

A je taky dobry pred startem samotnyho ntpcka udelat sync hodin. Viz niz max.

---

Dete s tim guuglem dopice!

[Filip]

Nasrat je rozhodně nechci Čas rozjetý nemám bohužel i po delší době je situace stejná.

[Max]

Teoreticky si to můžeš ručně zkusit syncnout přes ntpdate, tj. zastavit ntpd službu a pak "ntpdate tik.cesnet.cz".
Také doporučuji dodat k seznamu serverů parametr iburs.
Jinak se už také na některých místech přechází na chronyd a ntpd se upozaďuje.
Zdar Max

[Filip]

Ruční sync přes ntpdate proběhně. O tom chronyd moc nevím. Něco jsem četl v dokumentaci od Fedory.

[MP]

Kdyz si deaktivujes ntpd a systemd-timesyncd, muzes zkusit chrony (uprav si ty allow parametry):

server tik.cesnet.cz
server tak.cesnet.cz
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
makestep 1 3
log tracking measurements statistics
logdir /var/log/chrony
maxupdateskew 100.0
leapsectz right/UTC
dumpdir /var/lib/chrony
#rtcfile /var/lib/chrony/rtc
rtcsync
dumponexit
allow 192.168.0.0/16
allow subnet2
allow subnet3
local stratum 10

[Filip]

Ahoj, děkuji moc. Nyní vše funguje jak má. Ntp zřejmě mělo HW problém.

[Max]

Zkus se tedy podívat, co se přesně děje. Tj. příkaz "ntptime" a "ntpq -c sysinfo" a "timedatectl".
Zdar Max

[Filip]

ntptime:

ntp_gettime() returns code 5 (ERROR)
  time e59d0d57.ab009000  Thu, Jan 27 2022 13:23:51.667, (.667977),
  maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16000000 us,
  status 0x41 (PLL,UNSYNC),
  time constant 7, precision 1.000 us, tolerance 500 ppm,

ntpq -c sysinfo:

associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
system peer:        0.0.0.0:0
system peer mode:   unspec
leap indicator:     11
stratum:            16
log2 precision:     -21
root delay:         0.000
root dispersion:    0.000
reference ID:       .
reference time:     (no time)
system jitter:      0.000000
clock jitter:       0.000
clock wander:       0.000
broadcast delay:    -50.000
symm. auth. delay:  0.000

timedatectl:

Local time: Čt 2022-01-27 13:25:01 CET
           Universal time: Čt 2022-01-27 12:25:01 UTC
                 RTC time: Čt 2022-01-27 12:25:54
                Time zone: Europe/Prague (CET, +0100)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

[a1bert]

+ tcpdump

[R]

Toto som uz videl (nikdy sa to nedostalo zo stavu INIT) a problem bol sietovy.

[Filip]

Ahoj, komunikace output neni nijak blokováne. Zarizeni ma plny pristup na internet.

[a1bert]

a vraci se i odpovedi ?

[bmn]

ISP nejspíše blokuje port 123. Je to docela častý problém. Tohle rozbije ntpd, protože používá ten port nejen jako server, ale i jako klient.

[MMMMMMMMM]

Ahoj, všem moc děkuji za pomoc. Nakonec to vyřešila odinstalace ntp a instalace chrony. Nyní vš funguje jak má.

[MMMMMMMMM]

Já si tipnu: edituješ správný ntp.conf? podle logu se používá /run/ntp.conf.dhcp a ne /etc/ntp.conf (nemám Debian, na Centosu jsem s tím nikdy problémy neměl)

ntpq -p vypisuje IP adresy, které neodpovídají konfiguraci výše (tik.cesnet.cz, tak.cesnet.cz, ntp.nic.cz)

[MMMMMMMMM]

(ale Chrony je skvělá alternativa k ntp, takže nedoporučuju přejít zpět k ntp)

[Max]

Souhlasím, celou dobu to vypadalo na síťový problém a máš pravdu, že ty IP zjevně nesouhlasí.
Zdar Max

[Filip]

Sítoví problém to nebyl v nftables neomuzuji output a pro input udp 123 mam providlo. Take jsem potom sel jako prvni pres tcpdump.

[Filip]

Ahoj, ano edituji /etc/ntp.conf Problém se mě zdá v HW. Router co teď používám běží na PCengines APU4D4 a ten jejich BIOS může mít RTC jinak. Nicméně na jiných zařízeních v mé síti mám ntp a tam jsem zadal ip adresu routeru kde je chrony a vše běží bez problému. Možná by stálo za to zkusit napsat výrobci HW.