* Brendan McKenna [03-14-16 12:06]:

Just a guess, but it looks as if the box isn't able to do a DNS lookup on the name us.pool.ntp.org (the "resolve" bit in the error message -- it can't resolve the name to the IP address(es) to use). Can you do a dig on that box and get an address for the name, or does that fail, too?

The names all resolve properly. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-14-16 12:33]:

Patrick Shanahan wrote:

...

I have a local box which I cannot get ntp to work properly, following error in logs: giving up resolving host us.pool.ntp.org: Servname not supported for ai_socktype (-8)

google does not provide a solution that I have found.

The issue is listed here, but specifically if your ntp is chroot'ed:

http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.5.3.

Thi one:

http://www.ducea.com/2006/09/11/error-servname-not-supported-for-ai_socktype...

seems to think that /etc/services needs to contain:

ntp 123/tcp ntp 123/udp

(which presumably it already does).

Yes, I saw those and yes /etc/services does contain the proper entries. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-14-16 12:54]:

Patrick Shanahan wrote:

...

* Per Jessen [03-14-16 12:33]:

...

Patrick Shanahan wrote:

...

I have a local box which I cannot get ntp to work properly, following error in logs: giving up resolving host us.pool.ntp.org: Servname not supported for ai_socktype (-8)

google does not provide a solution that I have found.

The issue is listed here, but specifically if your ntp is chroot'ed:

http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.5.3.

...

Thi one:

http://www.ducea.com/2006/09/11/error-servname-not-supported-for-ai_socktype...

...

seems to think that /etc/services needs to contain:

ntp 123/tcp ntp 123/udp

(which presumably it already does).

Yes, I saw those and yes /etc/services does contain the proper entries.

I've just tried with "us.pool.ntp.org", works fine. I think I would try to run ntpd with strace and see where it dies.

will do, back shortly -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan wrote:

* Patrick Shanahan [03-14-16 12:59]:

...

* Per Jessen [03-14-16 12:54]:

...

I've just tried with "us.pool.ntp.org", works fine. I think I would try to run ntpd with strace and see where it dies.

will do, back shortly

Ok, running as root ntpd from cl works and appears proper so probably chroot is borked. So: strace -o <file> rcntpd start

Hi Patrick, unless you're on a pre-systemd system, that just calls systemctl. if the chroot environment is bad, let's see what it contains, post some directory listings etc. In particular /etc/resolv.conf and /etc/services and such. -- Per Jessen, Zürich (5.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Patrick Shanahan [03-14-16 16:06]:

* Per Jessen [03-14-16 13:23]:

...

Patrick Shanahan wrote:

...

* Patrick Shanahan [03-14-16 12:59]:

...

* Per Jessen [03-14-16 12:54]:

...

I've just tried with "us.pool.ntp.org", works fine. I think I would try to run ntpd with strace and see where it dies.

will do, back shortly

Ok, running as root ntpd from cl works and appears proper so probably chroot is borked. So: strace -o <file> rcntpd start

Hi Patrick,

unless you're on a pre-systemd system, that just calls systemctl. if the chroot environment is bad, let's see what it contains, post some directory listings etc. In particular /etc/resolv.conf and /etc/services and such.

subject box is post-systemd, iirc (old-timers). All pool addresses resolve to dns addresses and did so when ntp was run w/o chroot. You may read resolve.com and services: http://wahoo.no-ip.org/~paka/resolve.conf.txt

sorry, sb: http://wahoo.no-ip.org/~paka/resolv.conf.txt

http://wahoo.no-ip.org/~pata/addresse.txt and the last 100 lines of var/log/ntp http://wahoo.no-ip.org/~paka/log.ntp.txt

tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [03-14-16 14:53]:

On 2016-03-14 17:31, Per Jessen wrote:

...

Patrick Shanahan wrote:

...

The issue is listed here, but specifically if your ntp is chroot'ed: ... seems to think that /etc/services needs to contain:

ntp 123/tcp ntp 123/udp

(which presumably it already does).

You need that file in the chroot. Is it?

How to tell ??? :) tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Carlos E. R. [03-14-16 17:59]:

On 2016-03-14 21:10, Patrick Shanahan wrote:

...

* Carlos E. R. [03-14-16 14:53]:

...

On 2016-03-14 17:31, Per Jessen wrote:

...

Patrick Shanahan wrote:

...

The issue is listed here, but specifically if your ntp is chroot'ed: ... seems to think that /etc/services needs to contain:

ntp 123/tcp ntp 123/udp

(which presumably it already does).

You need that file in the chroot. Is it?

How to tell ??? :)

Well, I guess that the init script sets up a directory to which it chroots with a copy of the files it needs access to. It is "/var/lib/ntp/", where I see many files, but no "/etc/services".

yes, I looked there and didn't see it either so asked :) tks ls -la /var/lib/ntp/ -rw-r----- 1 root ntp 2964 Jan 22 23:17 ntp.conf.iburst -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-03-15 08:40, Per Jessen wrote:

That's all?? Here's from my Leap test system:

per@office34:~> l /var/lib/ntp total 20 drwxr-xr-x 6 root root 32 Dec 17 06:33 ./ drwxr-xr-x 52 root root 4096 Mar 14 12:00 ../ drwxr-xr-x 2 root root 1 Dec 17 06:33 dev/ drwxr-xr-x 2 ntp ntp 12288 Mar 15 07:56 drift/ drwxr-xr-x 2 root root 32 Jan 14 12:00 etc/ drwxr-xr-x 4 root root 16 Dec 17 06:33 var/

Same as me, in 13.1.

Also, I would expect to find "ntp.conf.iburst" in /var/lib/ntp/etc/.

Did you yourself choose to run ntpd chroot'ed?

The funny thing is that I thought I was not, but the files there are up to date. There is a /var/lib/ntp/var/run/ntp/ntpd.pid which does point to ntpd, so it is running there. And indeed, in /etc/sysconfig/ntp I have: NTPD_RUN_CHROOTED="yes" -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

* Per Jessen [03-15-16 06:32]:

Carlos E. R. wrote:

...

The funny thing is that I thought I was not, but the files there are up to date. There is a /var/lib/ntp/var/run/ntp/ntpd.pid which does point to ntpd, so it is running there. And indeed, in /etc/sysconfig/ntp I have:

NTPD_RUN_CHROOTED="yes"

To make sure, try "ls -l /proc/$(pidof ntpd)" and look at root.

When chroot'ed your ntpd will be running with '-i' specified.

In Leap 42.1, sysconfig::NTPD_RUN_CHROOTED is "no". Same in 13.2, 13.1 and 12.3. Interestingly, in Leap421, /usr/bin/start-ntpd appears to have a hardcoded NTPD_RUN_CHROOTED="yes". I might not have read that script right.

OK, semi-solved. The problem apparently lies with the chrooted jail. If I unset NTPD_RUN_CHROOTED, ntpd operates as desired. I checked my other local boxes and none are running chrooted. Then the remaining question, why is it failing when running chrooted? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-15-16 09:18]:

Patrick Shanahan wrote: [...]

...

OK, semi-solved. The problem apparently lies with the chrooted jail. If I unset NTPD_RUN_CHROOTED, ntpd operates as desired. I checked my other local boxes and none are running chrooted.

Then the remaining question, why is it failing when running chrooted?

Your chroot jail wasn't properly set up - somehow. I assume you were the one who changed the system to NTPD_RUN_CHROOTED="yes"? Or are you on TW?

Cannot recall but believe chroot was selected on original tw install of ntp. I manually changed NTPD_RUN_CHROOTED= to "no" and restart ntpd and see successful operation. The original chroot setup was done by yast during install so if borked, yast is culprit .... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-15-16 10:50]:

Patrick Shanahan wrote:

...

* Per Jessen [03-15-16 09:18]:

...

Patrick Shanahan wrote: [...]

...

OK, semi-solved. The problem apparently lies with the chrooted jail. If I unset NTPD_RUN_CHROOTED, ntpd operates as desired. I checked my other local boxes and none are running chrooted.

Then the remaining question, why is it failing when running chrooted?

Your chroot jail wasn't properly set up - somehow. I assume you were the one who changed the system to NTPD_RUN_CHROOTED="yes"? Or are you on TW?

Cannot recall but believe chroot was selected on original tw install of ntp. I manually changed NTPD_RUN_CHROOTED= to "no" and restart ntpd and see successful operation.

The original chroot setup was done by yast during install so if borked, yast is culprit ....

Uh, I suspect the jail setup is done by the start script. That's how it used to be anyway. If it isn't done on start-up, the latest changes to the network aren't included.

That may well be but this system restart with NTPD_RUN_CHROOTED="yes" leaves ntpd failing to connect with/without ipv6 and a change to NTPD_RUN_CHROOTED="no" w/o a restart is successful. ??? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-15-16 11:32]:

Patrick Shanahan wrote:

...

* Per Jessen [03-15-16 10:50]:

...

Patrick Shanahan wrote:

...

[...]

...

...

OK, semi-solved. The problem apparently lies with the chrooted jail. If I unset NTPD_RUN_CHROOTED, ntpd operates as desired. I checked my other local boxes and none are running chrooted.

Then the remaining question, why is it failing when running chrooted?

Your chroot jail wasn't properly set up - somehow. I assume you were the one who changed the system to NTPD_RUN_CHROOTED="yes"? Or are you on TW?

Cannot recall but believe chroot was selected on original tw install of ntp. I manually changed NTPD_RUN_CHROOTED= to "no" and restart ntpd and see successful operation.

The original chroot setup was done by yast during install so if borked, yast is culprit ....

Uh, I suspect the jail setup is done by the start script. That's how it used to be anyway. If it isn't done on start-up, the latest changes to the network aren't included.

That may well be but this system restart with NTPD_RUN_CHROOTED="yes" leaves ntpd failing to connect with/without ipv6 and a change to NTPD_RUN_CHROOTED="no" w/o a restart is successful. ???

Right - so whatever is supposed to set up the chroot jail isn't working, I would say. On Leap421, that is /usr/sbin/start-ntpd.

Which is as provided in ntp-4.2.8p4-2.1.x86_64 I would expect that *many* op's would be affected and wondering ???? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

6~On Tue, 15 Mar 2016 17:26, Per Jessen wrote:

Patrick Shanahan wrote:

...

* Per Jessen [03-15-16 11:32]:

...

Patrick Shanahan wrote:

...

* Per Jessen [03-15-16 10:50]:

...

Patrick Shanahan wrote:

...

[...] >> OK, semi-solved. The problem apparently lies with the >> chrooted >> jail. If I unset NTPD_RUN_CHROOTED, ntpd operates as >> desired. I checked my other local boxes and none are running >> chrooted. >> >> Then the remaining question, why is it failing when running >> chrooted? > > Your chroot jail wasn't properly set up - somehow. I assume > you were the one who changed the system to > NTPD_RUN_CHROOTED="yes"? Or are you on TW?

Cannot recall but believe chroot was selected on original tw install of ntp. I manually changed NTPD_RUN_CHROOTED= to "no" and restart ntpd and see successful operation.

The original chroot setup was done by yast during install so if borked, yast is culprit ....

Uh, I suspect the jail setup is done by the start script. That's how it used to be anyway. If it isn't done on start-up, the latest changes to the network aren't included.

That may well be but this system restart with NTPD_RUN_CHROOTED="yes" leaves ntpd failing to connect with/without ipv6 and a change to NTPD_RUN_CHROOTED="no" w/o a restart is successful. ???

Right - so whatever is supposed to set up the chroot jail isn't working, I would say. On Leap421, that is /usr/sbin/start-ntpd.

Which is as provided in ntp-4.2.8p4-2.1.x86_64

I would expect that *many* op's would be affected and wondering ????

Only if they're running ntpd in chroot, which is not the default (except perhaps in TW?)

Huh? that script (start-ntpd) seems older, the (c) is from 2014. Just one small correction (full-path was added to sntp call) in Jan.2016 So likely that bug was introduced with this script during the move from the sysV init /etc/init.d/ntp to the ntpd.service file. None the less, for running ntpd in client-mode, I see no added feature / security enhancement by using chroot, app-armor and or selinux brings better arguments to the table, at least for client-mode. For running ntpd as origin-server (with local hiprec timesource), or running a ntpd as ntp-relay for a bigger LAN, one can think of running in chroot. Then the bug hits you, but paging trough a OSS 12.3 install, it would also hit you prior to systemd, digging around a little, I found the following: The variable "NTPD_CHROOT_FILES" should be set to include all the "missing" files (/etc/sysconfig/ntp), this var defauls to empty. On openSUSE 12.3 as well as on Leap 42.1. TL;DR: just setting NTPD_RUN_CHROOTED="yes" in /etc/sysconfig/ntp does not get you a working chroot-ntpd, add the "missing" files with full path seperated by spaces to NTPD_CHROOT_FILES, which is empty by default. - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-03-16 07:58, Per Jessen wrote:

Yamaban wrote:

Having been looking at this the last 1-2 days, that was my thought too. Carlos, you have a working chroot'ed ntpd from 1911 (or thereabouts),

LOL

I'm curious, what does your NTPD_CHROOT_FILES say?

Empty. Telcontar:~ # cat /etc/sysconfig/ntp | egrep -v "^[[:space:]]*$|^#" NTPD_OPTIONS="-g -u ntp:ntp" NTPD_RUN_CHROOTED="yes" NTPD_CHROOT_FILES="" NTP_PARSE_LINK="" NTP_PARSE_DEVICE="" NTPD_FORCE_SYNC_ON_STARTUP="yes" NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes" Telcontar:~ # On another 13.1 machine (more recently built) ;-) AmonLanc:~ # cat /etc/sysconfig/ntp | egrep -v "^[[:space:]]*$|^#" NTPD_OPTIONS="-g -u ntp:ntp" NTPD_RUN_CHROOTED="yes" NTPD_CHROOT_FILES="" NTP_PARSE_LINK="" NTP_PARSE_DEVICE="" NTPD_FORCE_SYNC_ON_STARTUP="no" NTPD_FORCE_SYNC_HWCLOCK_ON_STARTUP="yes" AmonLanc:~ # But there is something weird on this machine, because clients say it is in init state: Telcontar:~ # rcntp status remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 66m 64 0 0.000 0.000 0.000 AmonLanc.valino .INIT. 16 u - 1024 0 0.000 0.000 0.000 <===== but it has been running for about 12 hours since last reboot. Nothing strange on its log: 15 Mar 23:33:07 ntpd[2702]: ntpd exiting on signal 15 15 Mar 23:36:18 ntpd[2640]: 0.0.0.0 c016 06 restart 15 Mar 23:36:18 ntpd[2640]: 0.0.0.0 c012 02 freq_set kernel -39.816 PPM 15 Mar 23:36:25 ntpd[2640]: Listen normally on 6 eth0 fc00::203:dff:fe05:17fc UDP 123 15 Mar 23:36:25 ntpd[2640]: Listen normally on 7 eth0 fc00::680d:f4c6:2da1:e0cd UDP 123 15 Mar 23:36:25 ntpd[2640]: peers refreshed 15 Mar 23:36:25 ntpd[2640]: new interface(s) found: waking up resolver 15 Mar 23:39:35 ntpd[2640]: 0.0.0.0 c61c 0c clock_step -0.214764 s 15 Mar 23:39:35 ntpd[2640]: 0.0.0.0 c614 04 freq_mode 15 Mar 23:39:36 ntpd[2640]: 0.0.0.0 c618 08 no_sys_peer 15 Mar 23:55:18 ntpd[2640]: 0.0.0.0 c612 02 freq_set kernel -39.155 PPM 15 Mar 23:55:18 ntpd[2640]: 0.0.0.0 c615 05 clock_sync -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

On 2016-03-16 10:36, Per Jessen wrote:

...

Telcontar:~ # rcntp status remote refid st t when poll reach delay offset jitter

==============================================================================

...

LOCAL(0) .LOCL. 10 l 66m 64 0 0.000 0.000 0.000 AmonLanc.valino .INIT. 16 u - 1024 0 0.000 0.000 0.000 <=====

If you run "ntpq -pn", you'll get the addresses (if they were resolved).

Yes, they are, but that tells me nothing more. Telcontar is my main desktop machine, and AmonLanc the acting server. Telcontar:~ # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 10 l 107m 64 0 0.000 0.000 0.000 192.168.1.15 .INIT. 16 u - 1024 0 0.000 0.000 0.000 #80.58.60.26 172.20.47.7 5 u 19 256 377 14.403 5.559 3.271 -194.140.131.21 158.227.98.15 2 u 251 256 377 46.669 -3.899 0.298 -193.145.15.15 193.147.107.33 2 u 260 256 377 18.654 -0.119 0.131 *158.227.98.15 .GPS. 1 u 56 256 377 35.235 0.536 0.300 -193.164.133.53 192.53.103.108 2 u 10 256 377 50.189 -1.799 0.600 +91.247.253.152 212.82.32.15 2 u 2 256 377 52.164 -0.192 0.282 -163.172.10.212 94.23.217.75 3 u 227 256 377 41.502 -1.851 0.300 -85.119.80.232 151.236.222.81 3 u 5 256 377 57.236 -1.251 0.378 -185.54.81.23 193.204.114.105 2 u 79 256 377 51.982 -0.577 0.172 -212.47.239.163 129.69.1.153 2 u 63 256 377 37.392 -0.306 0.129 +82.219.4.30 33.117.170.50 2 u 31 256 377 52.229 0.327 0.452 Telcontar:~ # AmonLanc:~ # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 192.168.1.14 .STEP. 16 u - 1024 0 0.000 0.000 0.000 -80.58.60.23 172.20.47.7 5 u 975 1024 377 14.601 1.053 4.663 *193.145.15.15 193.147.107.33 2 u 921 1024 363 18.935 -0.818 0.602 -91.240.0.5 81.63.144.23 3 u 974 1024 373 54.612 -1.971 0.546 -91.194.60.128 195.220.94.163 3 u 954 1024 373 38.497 0.816 1.094 -151.236.222.81 103.7.151.4 2 u 402 1024 377 44.976 0.219 0.540 +185.90.153.252 162.23.41.55 2 u 768 1024 357 75.986 -0.390 0.247 -94.23.210.194 145.238.203.14 2 u 433 1024 377 39.798 -2.487 4.070 +82.219.4.30 33.117.170.50 2 u 866 1024 377 52.311 -0.383 1.837 -81.19.96.148 145.238.203.14 2 u 947 1024 377 15.336 -7.936 0.519 AmonLanc:~ # If my server, AmonLanc, is in init status, stratum 16, it can not be used as reference in my LAN. :-? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

* Freek de Kruijf [03-15-16 11:06]:

Op dinsdag 15 maart 2016 08:44:19 schreef Patrick Shanahan:

...

* Per Jessen [03-15-16 06:32]:

...

Carlos E. R. wrote:

...

The funny thing is that I thought I was not, but the files there are up to date. There is a /var/lib/ntp/var/run/ntp/ntpd.pid which does point to ntpd, so it is running there. And indeed, in /etc/sysconfig/ntp I have:

NTPD_RUN_CHROOTED="yes"

To make sure, try "ls -l /proc/$(pidof ntpd)" and look at root.

When chroot'ed your ntpd will be running with '-i' specified.

In Leap 42.1, sysconfig::NTPD_RUN_CHROOTED is "no". Same in 13.2, 13.1 and 12.3. Interestingly, in Leap421, /usr/bin/start-ntpd appears to have a hardcoded NTPD_RUN_CHROOTED="yes". I might not have read that script right.

OK, semi-solved. The problem apparently lies with the chrooted jail. If I unset NTPD_RUN_CHROOTED, ntpd operates as desired. I checked my other local boxes and none are running chrooted.

Then the remaining question, why is it failing when running chrooted?

Might have to do with an unreachable file in the chroot needed for network access like /etc/resolv.conf

Well, resolv.conf does *not* appear /var/lib/ntp/etc/ How would that be added? tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Darryl Gregorash [03-21-16 14:45]:

On 15/03/16 09:58 AM, Patrick Shanahan wrote:

...

* Freek de Kruijf [03-15-16 11:06]:

...

Op dinsdag 15 maart 2016 08:44:19 schreef Patrick Shanahan:

...

* Per Jessen [03-15-16 06:32]:

...

Carlos E. R. wrote:

...

The funny thing is that I thought I was not, but the files there are up to date. There is a /var/lib/ntp/var/run/ntp/ntpd.pid which does point to ntpd, so it is running there. And indeed, in /etc/sysconfig/ntp I have:

NTPD_RUN_CHROOTED="yes" To make sure, try "ls -l /proc/$(pidof ntpd)" and look at root.

When chroot'ed your ntpd will be running with '-i' specified.

In Leap 42.1, sysconfig::NTPD_RUN_CHROOTED is "no". Same in 13.2, 13.1 and 12.3. Interestingly, in Leap421, /usr/bin/start-ntpd appears to have a hardcoded NTPD_RUN_CHROOTED="yes". I might not have read that script right. OK, semi-solved. The problem apparently lies with the chrooted jail. If I unset NTPD_RUN_CHROOTED, ntpd operates as desired. I checked my other local boxes and none are running chrooted.

Then the remaining question, why is it failing when running chrooted? Might have to do with an unreachable file in the chroot needed for network access like /etc/resolv.conf Well, resolv.conf does *not* appear /var/lib/ntp/etc/

How would that be added?

tks, Yast:Sysconfig Editor/Network/NTP/NTPD_CHROOT_FILES

OK, adding /etc/resolv using yast:sysconfig and running chroot provides: # ntpq -wpn remote refid st t when poll reach delay offset jitter ============================================================================== *173.51.147.14 .GPS. 1 u 33 64 1 79.785 *1.400 1.403 but unless I needed to allow more time, that doesn't look quite correct :( w/o chroot: # ntpq -wpn remote refid st t when poll reach delay offset jitter ============================================================================== -23.239.26.89 216.229.0.179 2 u 15 64 1 43.866 -0.101 0.545 -107.170.224.8 132.163.4.102 2 u 13 64 1 77.881 -5.505 0.153 +69.164.194.139 199.102.46.77 2 u 15 64 1 42.419 2.622 0.413 +2600:3c00::2:b401 129.7.1.66 2 u 13 64 1 55.907 -3.017 0.440 *128.138.141.172 .ACTS. 1 u 11 64 1 51.274 -4.490 0.383 tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Darryl Gregorash wrote:

On 21/03/16 04:13 PM, Patrick Shanahan wrote:

...

...

On 15/03/16 09:58 AM, Patrick Shanahan wrote: [snip] Yast:Sysconfig Editor/Network/NTP/NTPD_CHROOT_FILES OK, adding /etc/resolv using yast:sysconfig and running chroot

* Darryl Gregorash [03-21-16 14:45]: provides:

# ntpq -wpn remote refid st t when poll reach delay offset jitter

==============================================================================

...

*173.51.147.14 .GPS. 1 u 33 64 1 79.785 *1.400 1.403

but unless I needed to allow more time, that doesn't look quite correct :(

w/o chroot:

# ntpq -wpn remote refid st t when poll reach delay offset jitter

==============================================================================

...

-23.239.26.89 216.229.0.179 2 u 15 64 1 43.866 -0.101 0.545 -107.170.224.8 132.163.4.102 2 u 13 64 1 77.881 -5.505 0.153 +69.164.194.139 199.102.46.77 2 u 15 64 1 42.419 2.622 0.413 +2600:3c00::2:b401 129.7.1.66 2 u 13 64 1 55.907 -3.017 0.440 *128.138.141.172 .ACTS. 1 u 11 64 1 51.274 -4.490 0.383

tks, I've never run ntp chrooted, so I don't know all the files that have to be specified.. but resolv.conf is surely not the only one. Take a look back at some of the other replies; I am sure I saw a couple that have that information.

I also never run ntpd chroot'ed, but try adding /etc/services to the jail too. I've only seen it mentioned when I was out googling, I can't explain why it should help with your situation above. -- Per Jessen, Zürich (2.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2016-03-22 08:08, Per Jessen wrote:

...

Darryl Gregorash wrote:

...

...

I've never run ntp chrooted, so I don't know all the files that have to be specified.. but resolv.conf is surely not the only one. Take a look back at some of the other replies; I am sure I saw a couple that have that information.

I also never run ntpd chroot'ed, but try adding /etc/services to the jail too. I've only seen it mentioned when I was out googling, I can't explain why it should help with your situation above.

Interestingly, I'm running it chrooted (I don't remember why; maybe as a test, then I forgot), and it runs fine with no adjustements to that variable to add files.

But I'm on 13.1, might make a difference.

But probably not - are you 100% sure your ntpd is running chroot'ed? Check /proc/$(pidof ntpd)/root as well as the contents of the root jail. If there is no /etc/resolv.conf, I don't see how it will work (assuming you have names in ntp.conf that need resolving). -- Per Jessen, Zürich (7.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On Wednesday, 2016-03-23 at 11:19 +0100, Per Jessen wrote:

...

But probably not - are you 100% sure your ntpd is running chroot'ed?

Absolutely.

...

Check /proc/$(pidof ntpd)/root as well as the contents of the root jail. If there is no /etc/resolv.conf, I don't see how it will work (assuming you have names in ntp.conf that need resolving).

Telcontar:~ # l /proc/$(pidof ntpd)/root lrwxrwxrwx 1 root root 0 Mar 23 12:18 /proc/26596/root -> /var/lib/ntp/ Telcontar:~ #

Telcontar:~ # cat /proc/$(pidof ntpd)/cmdline /usr/sbin/ntpd-p/var/run/ntp/ntpd.pid-g-untp:ntp-i/var/lib/ntp-c/etc/ntp.confTelcontar:~ #

Telcontar:~ # ls /var/lib/ntp/etc localtime ntp.conf ntp.conf.iburst ntp.keys Telcontar:~ #

And yes, I use names in the config that need resolving.

I must be missing something, I don't understand how that can work. -- Per Jessen, Zürich (7.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Darryl Gregorash wrote:

On 23/03/16 06:13 AM, Per Jessen wrote:

...

Carlos E. R. wrote:

...

And yes, I use names in the config that need resolving. I must be missing something, I don't understand how that can work.

The start script does by default copy some files into the chroot jail (without having to name them in etc/sysconfig/ntp); I cannot recall if resolv is one of them.

Yes, but Carlos checked the jail at runtime, and /etc/resolv.conf wasn't there. -- Per Jessen, Zürich (5.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan [22.03.2016 13:50]:

* Per Jessen [03-22-16 03:09]: [...]

...

...

I've never run ntp chrooted, so I don't know all the files that have to be specified.. but resolv.conf is surely not the only one. Take a look back at some of the other replies; I am sure I saw a couple that have that information.

I also never run ntpd chroot'ed, but try adding /etc/services to the jail too. I've only seen it mentioned when I was out googling, I can't explain why it should help with your situation above.

I don't run chroot'ed on my other boxes and didn't *knowingly* on this but it is yast *default* on this box ???? But box was originally 12.1, iirc, and became tw when Greg KH started the project and continued since. When ntpd became chroot (and default as chroot) I have no idea, but it was not that way originally.

Today I got exactly this problem on a re-installed SLES 11 SP4 host. According to entry 9.2.4.2.5.3. on page http://support.ntp.org/bin/view/Support/KnownOsIssues I linked /etc/services to the chroot dir and everything worked. However, the other 15 SLES 11 SP4 don't have this link, and they work fine. And they have all the same version of the ntp package (ntp-4.2.8p4-5.1). Just to make things more confusing: it also works fine when the "server" entries in /etc/ntp.conf are IP addresses instead of host names. In this case, I do not need a services file inside the chroot.

Real question should probably be why yast does not provide the necessary files for the chroot ntp to succeed....

That is what I questioned the support engineer for, and he decided to ask his ntp specialist :) Maybe someone finds out why the problem exists on one host only... Just my 2¢, Werner -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-23-16 06:17]:

Patrick Shanahan wrote:

...

* Per Jessen [03-22-16 03:09]: [...]

...

...

I've never run ntp chrooted, so I don't know all the files that have to be specified.. but resolv.conf is surely not the only one. Take a look back at some of the other replies; I am sure I saw a couple that have that information.

I also never run ntpd chroot'ed, but try adding /etc/services to the jail too. I've only seen it mentioned when I was out googling, I can't explain why it should help with your situation above.

I don't run chroot'ed on my other boxes and didn't *knowingly* on this but it is yast *default* on this box ???? But box was originally 12.1, iirc, and became tw when Greg KH started the project and continued since. When ntpd became chroot (and default as chroot) I have no idea, but it was not that way originally.

I've checked my systems running 12.3 and 13.[12], none of them have ntp chroot'ed by default

...

I added /etc/resolv.conf and /etc/services to the chroot files and obtain following strace: http://wahoo.no-ip.org/~paka/ntp.trace.txt

Seems to have disappeared.

Sorry, typo: http://wahoo.no-ip.org/~paka/ntpd.trace.txt

...

yast publishes a complaint that systemd cannot find a service state for ntp and that the service, ntp, does not exist. Should be hunting for ntpd.

Yes, that's a little odd.

...

Real question should probably be why yast does not provide the necessary files for the chroot ntp to succeed....

Yes and no - more likely why ntp was chroot'ed in the first place, but as the later releases did not do it, there's probably not much point in pursuing the issue.

According to yast on this tw system, it is default to chroot ntpd. How does yast determine *default*? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-23-16 08:00]:

Patrick Shanahan wrote:

...

Sorry, typo: http://wahoo.no-ip.org/~paka/ntpd.trace.txt

...

...

yast publishes a complaint that systemd cannot find a service state for ntp and that the service, ntp, does not exist. Should be hunting for ntpd.

Yes, that's a little odd.

...

Real question should probably be why yast does not provide the necessary files for the chroot ntp to succeed....

Yes and no - more likely why ntp was chroot'ed in the first place, but as the later releases did not do it, there's probably not much point in pursuing the issue.

According to yast on this tw system, it is default to chroot ntpd. How does yast determine *default*?

I would assume from the contents of /etc/sysconfig/ntp, which I sguess is created by installation scripts or some such.

No, date stamp indicated it is *generated* by yast... And confirmed by using yast make a change to ntp. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-23-16 08:24]: [...]

Hmm, looking at /usr/share/YaST2/modules/NtpClient.rb, it reads NTPD_RUN_CHROOTED from sysconfig, and later writes it back, but afaict it does not change the setting. (very limited ruby skills). This is on Leap 42.1, have a look at your TW installation, maybe it does something else.

08:32 Crash: ~ # grep NTPD_RUN_CHROOTED /etc/sysconfig/ntp NTPD_RUN_CHROOTED="no" ran yast and changed NTPD_RUN_CHROOTED="no" to yes 08:32 Crash: ~ # grep NTPD_RUN_CHROOTED /etc/sysconfig/ntp NTPD_RUN_CHROOTED="yes" :) ?? But, necessitates "systemctl restart ntpd" as yast fails looking for "ntp" rather than "ntpd". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-23-16 08:55]:

Patrick Shanahan wrote:

...

* Per Jessen [03-23-16 08:24]: [...]

...

Hmm, looking at /usr/share/YaST2/modules/NtpClient.rb, it reads NTPD_RUN_CHROOTED from sysconfig, and later writes it back, but afaict it does not change the setting. (very limited ruby skills). This is on Leap 42.1, have a look at your TW installation, maybe it does something else.

08:32 Crash: ~ # grep NTPD_RUN_CHROOTED /etc/sysconfig/ntp NTPD_RUN_CHROOTED="no"

ran yast and changed NTPD_RUN_CHROOTED="no" to yes

Wait - with the sysconfig editor or the time&date module?

yast2 sysconfig

...

But, necessitates "systemctl restart ntpd" as yast fails looking for "ntp" rather than "ntpd".

Might be worth pinging the yast guys.

-- Per Jessen, Zürich (5.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-23-16 09:32]:

Patrick Shanahan wrote:

...

* Per Jessen [03-23-16 08:55]:

...

Patrick Shanahan wrote:

...

* Per Jessen [03-23-16 08:24]: [...]

...

Hmm, looking at /usr/share/YaST2/modules/NtpClient.rb, it reads NTPD_RUN_CHROOTED from sysconfig, and later writes it back, but afaict it does not change the setting. (very limited ruby skills). This is on Leap 42.1, have a look at your TW installation, maybe it does something else.

08:32 Crash: ~ # grep NTPD_RUN_CHROOTED /etc/sysconfig/ntp NTPD_RUN_CHROOTED="no"

ran yast and changed NTPD_RUN_CHROOTED="no" to yes

Wait - with the sysconfig editor or the time&date module?

yast2 sysconfig

Okay, that makes sense - you might as well have used vi. I thought it was the time&date module that had a "Use chroot" setting.

It does, but (for my purposes) I cannot remember using that module anytime after original install :). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Per Jessen [03-24-16 16:56]:

Patrick Shanahan wrote:

...

* Per Jessen [03-23-16 09:32]:

...

Patrick Shanahan wrote:

...

* Per Jessen [03-23-16 08:55]:

...

Patrick Shanahan wrote:

...

* Per Jessen [03-23-16 08:24]: [...] > Hmm, looking at /usr/share/YaST2/modules/NtpClient.rb, it reads > NTPD_RUN_CHROOTED from sysconfig, and later writes it back, but > afaict > it does not change the setting. (very limited ruby skills). This > is on Leap 42.1, have a look at your TW installation, maybe it > does something else.

08:32 Crash: ~ # grep NTPD_RUN_CHROOTED /etc/sysconfig/ntp NTPD_RUN_CHROOTED="no"

ran yast and changed NTPD_RUN_CHROOTED="no" to yes

Wait - with the sysconfig editor or the time&date module?

yast2 sysconfig

Okay, that makes sense - you might as well have used vi. I thought it was the time&date module that had a "Use chroot" setting.

It does,

You're sure? I can't find it. This screenshot is from YasT->Time&Date ->Other Settings:

http://files.jessen.ch/screenshot-yast-timeanddate.jpeg

...

but (for my purposes) I cannot remember using that module anytime after original install :).

YaST is a little limited, but vi /etc/ntpd.conf works for me, that's the beauty of yast.

Agreed. Look at "yast timezone" -> "Other Settings..." -> "Configure" -> "Security Settings" (tab at top). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 23/03/16 06:06 AM, Patrick Shanahan wrote:

* Per Jessen [03-23-16 08:00]:

...

Patrick Shanahan wrote:

...

According to yast on this tw system, it is default to chroot ntpd. How does yast determine *default*?

I would assume from the contents of /etc/sysconfig/ntp, which I sguess is created by installation scripts or some such. No, date stamp indicated it is *generated* by yast... And confirmed by using yast make a change to ntp.

At least in 42.1, NTPD_RUN_CHROOTED is set to "yes" in the ntp start script, unless overridden by /etc/sysconfig/ntp. If you will check in that file, you will see that the Yast default for the variable is "" (variable not set). I assume that means you have to set it to "no" if you don't want ntp to be chrooted. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2016-03-15 11:30, Per Jessen wrote:

Carlos E. R. wrote:

...

...

Did you yourself choose to run ntpd chroot'ed?

The funny thing is that I thought I was not, but the files there are up to date. There is a /var/lib/ntp/var/run/ntp/ntpd.pid which does point to ntpd, so it is running there. And indeed, in /etc/sysconfig/ntp I have:

NTPD_RUN_CHROOTED="yes"

To make sure, try "ls -l /proc/$(pidof ntpd)" and look at root.

Telcontar:~ # ls -l /proc/$(pidof ntpd)/root lrwxrwxrwx 1 root root 0 Mar 15 19:08 /proc/14926/root -> /var/lib/ntp Telcontar:~ #

When chroot'ed your ntpd will be running with '-i' specified.

Telcontar:~ # cat /proc/$(pidof ntpd)/cmdline /usr/sbin/ntpd-p/var/run/ntp/ntpd.pid-g-untp:ntp-i/var/lib/ntp-c/etc/ntp.conf Telcontar:~ # So, yes.

In Leap 42.1, sysconfig::NTPD_RUN_CHROOTED is "no". Same in 13.2, 13.1 and 12.3. Interestingly, in Leap421, /usr/bin/start-ntpd appears to have a hardcoded NTPD_RUN_CHROOTED="yes". I might not have read that script right.

I have not intentionally configured it to run chrooted. That must have been the default at some time. This is 13.1, but upgraded all the way back to 5.3. Telcontar:~ # l /etc/sysconfig/ntp -rw-r--r-- 1 root root 1877 May 9 2015 /etc/sysconfig/ntp Telcontar:~ # The file is dated that time. Default config in 13.1: Telcontar:~ # rpm -qV ntp SM5....T. c /etc/ntp.conf Telcontar:~ # -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)