Hello!
I still have the same /etc/ntpd.conf which uses ‘constraints from
“https://www.google.com”’.
After the TLS changes this fails:
@
?0[root@sdaoden steffen]# ntpd -d -s
adjtimex returns frequency of –2.879990ppm
ntp engine ready
constraint request to 216.58.208.36
constraint request to 2a00:1450:401b:804::2004
tls connect failed: 2a00:1450:401b:804::2004 (www.google.com): connect:
Address not available
no constraint reply from 2a00:1450:401b:804::2004 received in time, next
query 900s
tls connect failed: 216.58.208.36 (www.google.com): ssl verify memory
setup failure
no constraint reply from 216.58.208.36 received in time, next query
900s
no reply received in time, skipping initial time setting
^Cpipe write error (from main): Invalid argument
pipe write error (from dns engine): Invalid argument
ntp engine exiting
Terminating
@
That openntpd simply fails to continue normally and does not try to
contact normal NTP servers (unfortunately NTP over DTLS has not been
invented yet), effectively hanging in the nowhere, is a different issue
i’d say.
The machine is up-to-date.
(from redmine: issue id 9635, created on 2018-11-10)
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
constraint request to 216.58.208.36
constraint request to 2a00:1450:401b:804::2004
tls connect failed: 2a00:1450:401b:804::2004 (www.google.com):
connect: Address not available
no constraint reply from 2a00:1450:401b:804::2004 received in time,
next query 900s
tls connect failed: 216.58.208.36 (www.google.com): ssl verify
memory setup failure
no constraint reply from 216.58.208.36 received in time, next query
900s
no reply received in time, skipping initial time setting
The same happens with openntpd-6.2_p3-r2 on 3.9.4, and can be
reproduced using the following steps:
Boot up alpine-standard-3.9.4-x86_64.iso in qemu and log in as
root.
This happens because of the chroot(2) call in ntpd(8) child. ntpd(8) calls open("/tmp/libtlscompat***", ...) after chrooting to /var/empty and fails because there is no /var/empty/tmp. Doing mkdir -m 1777 /var/empty/tmp helps, but I don't know if this is the right approach.
UPD 1: There is a way to specify the directory where ntpd(8) should chroot with ./configure ... --with-privsep-path=<dir>, so it would make sense to create /var/lib/openntpd with tmp inside owned by ntp:ntp.
UPD 2: Actually, there is no call to open("/tmp/libtls***", ...) on OpenBSD. I guess that this is standalone-only thing.
UPD 3: The offending function SSL_CTX_load_verify_mem resides here. Calling mkstemp(3) from there happens after chrooting and ntpd(8) does not expect that since vanilla libressl does all this in memory:
/* From libressl-2.9.1 */intSSL_CTX_load_verify_mem(SSL_CTX *ctx, void *buf, int len){ return (X509_STORE_load_mem(ctx->cert_store, buf, len));}
UPD 4: OpenNTPD does not use --with-privsep-path=<dir> in code, it just for hints. Instead it chroots to the home directory of a running user, so it's necessary to setup a dedicated user (e.g. openntpd) with a home directory pointing to e.g. /var/lib/openntpd.
Another possible solution is to create a full-blown LibreSSL package (with libs only) that can be installed simultaneously with OpenSSL (e.g. change conflicting names from /lib/libssl.* to /lib/libressl.*) and link all OpenBSD programs against it.
I am finding the same here, today with Alpine 3.12.0.
When openntpd is used it does not appear to be keeping the machine's clock in sync.
There's nothing logged, whether using syslog or rsyslog. One must run ntpd in foreground to find it.
# apk list openntpd libressl alpine-baseopenntpd-6.2_p3-r3 x86_64 {openntpd} (BSD) [installed]libressl-3.1.2-r0 x86_64 {libressl} (custom)alpine-base-3.12.0-r0 x86_64 {alpine-base} (MIT) [installed]# ldd /usr/sbin/ntpd /lib/ld-musl-x86_64.so.1 (0x7ff322a1c000) libtls-standalone.so.1 => /usr/lib/libtls-standalone.so.1 (0x7ff3229ed000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7ff322a1c000) libssl.so.1.1 => /lib/libssl.so.1.1 (0x7ff32296c000) libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x7ff3226ed000)# /usr/sbin/ntpd -dviolin:/var/lib# /usr/sbin/ntpd -d/var/db/ntpd.drift is emptyntp engine readyconstraint request to 216.58.211.164constraint request to 2a00:1450:4009:800::2004tls connect failed: 2a00:1450:4009:800::2004 (www.google.com): connect: Network unreachableno constraint reply from 2a00:1450:4009:800::2004 received in time, next query 900stls connect failed: 216.58.211.164 (www.google.com): ssl verify memory setup failureno constraint reply from 216.58.211.164 received in time, next query 900s
I wanted to try changing ntpd user's home directory, as suggested by @consus, but it's unclear what the permissions should be:
# mkdir /var/lib/ntp# chown ntp.ntp /var/lib/ntp# chown 0755 /var/lib/ntp# usermod -d /var/lib/ntp ntp# ntpd -d/var/db/ntpd.drift is emptyntp: bad privsep dir /var/lib/ntp permissions: 40755Terminating
I presume everyone is using busybox ntpd, as this is now logged as an issue for some time. I am likely to switch to busybox ntpd here; it was force of habit to use openntpd.
@mark, OpenNTPD's ntp.c includes this logic that enforces some ownership/permissions on the home directory:
if (stb.st_uid != 0 || (stb.st_mode & (S_IWGRP|S_IWOTH)) != 0) { fatalx("bad privsep dir %s permissions: %o", pw->pw_dir, stb.st_mode);}
So if either the directory is not owned by root or has the write bit set in the group or other spots, it throws this error. You can get around this by giving the ntp user write access to the tmp/ sub-directory.
This is the barebones Dockerfile recipe I've currently got that addresses this error. Note that I've changed the home directory for the ntp user created by OpenNTPD.
This looks still broken on v3.13. OpenNTPD will silently fail to work as distributed (it won't exit, it won't log anything to syslog), and the only way to notice is running ntpctl and then running ntpd -vv -d manually.
It might be worth pulling the package if this is not fixed?
(Not logging to syslog might be its own bug, too.)
i reproduced this with alpine 3.13 by running ntpd -d -vv in a Docker container:
ntpd: can't set priority: Permission deniedreset adjtime failed: Operation not permittedcreating new /var/db/ntpd.driftadjtimex failed: Operation not permittedadjtimex adjusted frequency by 0.000000ppmntp engine readyconstraint request to 9.9.9.9constraint request to 2620:fe::fetrying to resolve www.google.comresolve www.google.com done: 2constraint request to 172.217.1.4constraint request to 2607:f8b0:400b:80c::2004tls connect failed: 9.9.9.9 (9.9.9.9): ssl verify memory setup failureno constraint reply from 9.9.9.9 received in time, next query 900stls connect failed: 2620:fe::fe (2620:fe::fe): ssl verify memory setup failureno constraint reply from 2620:fe::fe received in time, next query 900stls connect failed: 172.217.1.4 (www.google.com): ssl verify memory setup failureno constraint reply from 172.217.1.4 received in time, next query 900stls connect failed: 2607:f8b0:400b:80c::2004 (www.google.com): ssl verify memory setup failureno constraint reply from 2607:f8b0:400b:80c::2004 received in time, next query 900sconstraints configured but none available
under alpine 3.15, it now prints:
ntpd: can't set priority: Permission deniedreset adjtime failed: Operation not permittedcreating new /var/db/ntpd.driftadjtimex failed: Operation not permittedadjtimex adjusted frequency by 0.000000ppmntp engine readyconstraint request to 9.9.9.9constraint request to 2620:fe::fetrying to resolve www.google.comresolve www.google.com done: 2constraint request to 172.217.1.4constraint request to 2607:f8b0:400b:80c::2004constraint reply from 2620:fe::fe: offset -0.507331trying to resolve pool.ntp.orgresolve pool.ntp.org done: 4trying to resolve time.cloudflare.comresolve time.cloudflare.com done: 4Adding address 138.197.153.200 to pool.ntp.orgAdding address 194.0.5.123 to pool.ntp.orgAdding address 209.115.181.110 to pool.ntp.orgAdding address 162.159.200.123 to pool.ntp.orgconstraint reply from 9.9.9.9: offset -0.576568cancel settime because offset is negative or close enoughreply from 2606:4700:f1::123: offset 0.002186 delay 0.016637, next query 5sconstraint reply from 2607:f8b0:400b:80c::2004: offset -0.591738constraint reply from 172.217.1.4: offset -0.610268reply from 162.159.200.123: offset 0.000943 delay 0.042414, next query 7sreply from 209.115.181.110: offset 0.001826 delay 0.060728, next query 7sreply from 194.0.5.123: offset 0.003268 delay 0.081530, next query 7s
therefore, I think this was fixed in 4cf64ea1 for alpine 3.14+.