This hangs in UCS 5.2-0 alpha: root@backup81:~# rdate -np 10.200.8.80 ## the primary rdate: Not enough valid responses received in time rdate: Unable to get a reasonable time estimate Simple attempts at fixing like restarting ntpd, samba or disabling univention-firewall didn't help. Also didn't see obvious error messages in syslog of the primary.
<man:rdate(1)> TIME → [RFC 868](https://datatracker.ietf.org/doc/html/rfc868) → UDP/TCP port 37 NTP → [RFC 958](https://datatracker.ietf.org/doc/html/rfc958) → UDP port 123 SNTP → [RFC 2030](https://datatracker.ietf.org/doc/html/rfc2030) → UDP/TCP port 123 $ getent services 37 time 37/tcp timserver $ getent services ntp ntp 123/udp # journalctl -u ntpsec -g SNTP Feb 15 09:38:18 dc30 ntpd[1141564]: CONFIG: MS-SNTP signd operations currently block ntpd degrading service to all clients. # grep -n restrict /etc/ntpsec/ntp.conf 31:restrict default mssntp noquery ^^^^^^ 32:restrict 127.0.0.1 33:restrict ::1 It works™ after after removing the "mssntp": # rdate -np 10.200.17.30 rdate: Ignoring NTP server with alarm flag set rdate: Unable to get a reasonable time estimate
Sure, we need mssntp to deliver AD DC behavior for Windows clients. The question is, what changed with respect to UCS 5.0-6, where the "rdate -n" check for SNTP still works.
In Debian 12 ntp has been replaced by ntpsec. Ntpsec claims "almost full compatibility and interoperation with NTP Classic", however some differences are pointed out in this page: https://docs.ntpsec.org/latest/ntpsec.html
https://wiki.samba.org/index.php/Time_Synchronisation has the warning > It has been reported that ntpsec will not work with Samba. There is Debian bug report > here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033088 and the corresponding > NTPsec issue here: https://gitlab.com/NTPsec/ntpsec/-/issues/785 . Until this note has > been removed, it is recommended that only Chrony is used. And there's https://groups.google.com/g/linux.debian.bugs.dist/c/x-ynMEPUxzs
Looking back at Philipps analysis https://forge.univention.org/bugzilla/show_bug.cgi?id=47939#c7 maybe chrony is the way forward. ntpsec breaking Samba/AD DC functionality is not an option IMHO.
https://wiki.samba.org/index.php/Time_Synchronisation now says: > This problem has been fixed in the upcoming Debian Trixie ntpsec package, but is still in the Bookworm package. So a backport of ntpsec 1.2.3+dfsg1-3 from https://packages.debian.org/trixie/ntpsec should be fix this issue.
Ok, backported the source package from trixie like this: * dget http://deb.debian.org/debian/pool/main/n/ntpsec/ntpsec_1.2.3+dfsg1-3.dsc * dget http://deb.debian.org/debian/pool/main/n/ntpsec/ntpsec_1.2.2+dfsg1-1+deb12u1.dsc * dpkg-source -x ntpsec_1.2.2+dfsg1-1+deb12u1.dsc * uupdate --no-symlink ../ntpsec_1.2.3+dfsg1.orig.tar.xz -v 1.2.3 * cd ../ntpsec-1.2.3; dch -r --distribution unstable "" # to turn UNRELEASED into "unstable" * copied package to UCS 5.2-0 VM; ran `apt build-dep .` and `dpkg-buildpackage -S` * checked out https://salsa.debian.org/debian/ntpsec.git to check `git log -p debian/1.2.2+dfsg1-1+deb12u1.. -- debian` * adjusted the debian/patches and debian/rules accordingly * `dpkg-buildpackage -S` * import resulting source package using `repo_admin.py -F -p ntpsec -r 5.2-0` * b52 ntpsec Package: ntpsec Version: 1.2.3-1 Branch: ucs_5.2-0 No additional ucs-patches, that's why repo-ng didn't attach a build-timestamp. Tested with: * rdate -n from a replica to a UCS 5.2 primary running Samba/AD 4.21.1 * Windows 10 client (reboot, login as domain\Administrator) 4933a610434 | Entry for release changelog
- OK windows $ w32tm /monitor /domain:ucs.test master.ucs.test *** PDC ***[10.207.31.198:123]: ICMP: 0ms Verzögerung NTP: +0.0000000s Offset von master.ucs.test RefID: (unbekannt) [0x0300A8C0] Stratum: 3 ucs-3095.ucs.test[10.207.31.202:123]: ICMP: 0ms Verzögerung NTP: +0.0001539s Offset von master.ucs.test RefID: (unbekannt) [0x0300A8C0] Stratum: 3 $ net time \\master /set Aktuelle Zeit auf \\master ist 01.11.2024 10:47:43. Die aktuelle lokale Zeit ist 01.11.2024 10:47:42. Soll die Zeit des lokalen Computers mit der Zeit auf \\master übereinstimmen? (J/N) [J]: Der Befehl wurde erfolgreich ausgeführt. - OK UCS @replica $ rdate -n master Fri Nov 1 10:35:55 CET 2024 - OK changelog