Installing ntpd on TurrisOS?


#1

The busybox-ntpd in Turris OS is too limited. No authentication, no monitoring possible and it simply does not work (clients cannot synchronize and there is no debugging possible, ntpq cannot be used, and it doesn’t log anything).

Before 3.11, it was possible to install ntpd to have a serious NTP server for the LAN. Now, it apparently fails: [string “transaction”] 323 [string “transaction”] 149: Collisions The post was closed immediately, without a solution :frowning: and I don’t see how to reopen it.

Installing it afterwards also fails:

 * check_data_file_clashes: Package ntpd wants to install file /sbin/ntpd
	But that file is already provided by package  * busybox
 * opkg_install_cmd: Cannot install package ntpd.

This is a sad regression.


#2

#3

Having looked into the relevant upstream documentation

By default busybox-ntpd runs as a client and does not serve time. You can set the UCI option enable_server in /etc/config/system (in the ntp section) to enable serving time as well.

That done there is still no server instance running since sysntpd is not enabled to run at boot time and thus needs to be set accordingly (LuCI) or invoke manually (does not survive reboot) from cli /etc/init.d/sysntpd restart

netstat -ulpnwe reveals the server instance up and listening on udp:::123.

Invoking from cli ntpd -d -q is not reporting anything if that is any indication that the server actually works.

When invoking it with -q it would act like ntpdate

Having set this conf it is not apparent though which of the settings are actually being parsed by uci | busybox-ntpd. Albeit reckon that pool instead of server may not work and Foris is throwing an error with the iburst argument.

Summary
config timeserver 'ntp'
	option enabled '1'
	option enable_server '1'
	list interface_listen '192.168.112.12'
	list interface_ignore 'wildcard'
	list restrict 'default kod notrap nomodify nopeer limited'
	list restrict 'source notrap nomodify noquery'
	list restrict '127.0.0.1'
	list restrict '::1'
	list server '0.europe.pool.ntp.org'
	list server '0.debian.pool.ntp.org'
	list server '0.openwrt.pool.ntp.org'
	list server '0.asia.pool.ntp.org'
	list server '0.north-america.pool.ntp.org'
	list server '1.europe.pool.ntp.org'
	list server '1.debian.pool.ntp.org'
	list server '1.openwrt.pool.ntp.org'
	list server '1.asia.pool.ntp.org'
	list server '1.north-america.pool.ntp.org'
	list server '2.europe.pool.ntp.org'
	list server '2.debian.pool.ntp.org'
	list server '2.openwrt.pool.ntp.org'
	list server '2.asia.pool.ntp.org'
	list server '2.north-america.pool.ntp.org'
	option driftfile '/var/lib/ntp/ntp.drift'
	option statsdir '/tmp/log/ntpstats/'
	option statistics_loopstats_peerstats_clockstats '1'
	option filegen_loopstats_file_loopstats_type_day_enable '1'
	option filegen_peerstats_file_peerstats_type_day_enable '1'
	option filegen_clockstats_file_clockstats_type_day_enable '1'

With the package ntp-utils installed the busybox-ntpd server cannot be queried with ntpq -p, suppose that would require the full ntpd package instead of busybox-ntpd


The upstream documentation then continues

It doesnt support advanced features like query, …
Example (install the real ntpd package (=not busybox-ntpd):

That however appears impossible since TOS 3.11 and hence looks like a bug since both, upstream and downstream, featuring/serving the ntpd package in their respective repos.


#4

The release notes for 3.11.1 do not indicate that the problem is fixed. I had to install a NTP server on a Raspberry Pi to synchronize the local clmocks :frowning:


#5

Because it is not fixed - as in facilitating the installation of the full ntpd package.


#6

Today I solved problem how to set date in my IPcam which have blocked internet access by using sysntpd server. It should also work in your case.

My version Turris OS is 3.11.1

Here are steps to enable ntp server:

Enable sysntpd server:

root@turris:/etc# uci set system.ntp.enable_server=‘1’
root@turris:/etc# uci commit
root@turris:/etc# /etc/init.d/sysntpd restart

Check if someone listenning on port 123:

root@turris:/etc# netstat -n -l | grep 123
udp 0 0 :::123 :::*

Test from Turris:

root@turris:/etc# ntpdate -q 127.0.0.1
server 127.0.0.1, stratum 2, offset 0.000016, delay 0.02768
5 Jan 21:11:15 ntpdate[24664]: adjust time server 127.0.0.1 offset 0.000016 sec

Test from Windows:

c:\Temp>w32tm /stripchart /computer:172.20.100.1 /dataonly /samples:2
Tracking 172.20.100.1 [172.20.100.1:123].
Collecting 2 samples.
The current time is 05.01.2019 21:13:17.
21:13:17, +00.0495635s
21:13:19, +00.0494819s


#7

Does not work for me. Same version of TurrisOS.

root@turris:~#  netstat -n -l | grep 123
udp        0      0 :::123                  :::*                                
root@turris:~# ntpdate -q 127.0.0.1
server 127.0.0.1, stratum 0, offset 0.000000, delay 0.00000
 6 Jan 15:14:39 ntpdate[11030]: no server suitable for synchronization found

#8

Which ntp package have you installed ?

root@turris:~# opkg list-installed | grep ntp
ntpdate - 4.2.8p11-1

Which process running ?

root@turris:~# ps | grep ntp
6167 root 1108 S< /sbin/ntpd -n -N -l -S /usr/sbin/ntpd-hotplug -p 217.31.202.100 -p 195.113.144.201 -p 195.113.144.238 -p
9002 root 1108 S grep ntp


#9

I would recommend you to install LXC on your router. It is separete environment with debian or other distro if you have omnia. Then you have isolated system with separate IP where you can run regular daemons from normal linux distros installed via apt/aptitude or rpm


#10

Yes enabling it in system config file seems to work.

Having to use a LXC container for basic network functionalities on a router seems plain wrong to me. I would like to be able to install a full-fledged ntp server as before.


#12

Well not running LXC on such powerfull hardware is such a waste anyway as openwrt is still limited. At least it is something.


#13

Whilst lxc is certainly fun it adds server maintenance cost since each lxc container being a server on its own. It should not require such effort just for running a fully fledged ntp server on the TO which worked peachy just prior the busybox update that shipped with TOS 3.11.x.

And the ntpd package is still be being offered in both distos, OpenWRT and TOS, and as such should be installable.


#14
root@turris:~# opkg list-installed | grep ntp
ntp-utils - 4.2.8p11-1
ntpdate - 4.2.8p11-1
root@turris:~# ps | grep ntp
 5567 ntp       5292 S    avahi-daemon: running [jadis.local]
 5676 ntp       5168 S    avahi-daemon: chroot helper
 9352 root      1108 S    grep ntp
13992 root      1108 S<   /sbin/ntpd -n -N -l -S /usr/sbin/ntpd-hotplug -p 192.168.2.4

#15

I already have LXC, with several containers. But here we talk about NTP. The LXC containers don’t have their own clock, so NTP must run on the host (the Turris, with OpenWRT), no?


#16

the guest is sharing the (kernel) clock with the host. If ntpd is run in a privileged guest it can discipline the host’s clock as well.

It should be ensured that there are not multiple ntp demons on the network trying to discipline the host (router) clock as it could cascade into conflicts.

! There is one caveat with that - if the lxc guest is not available for whatever reason so won’t be the ntp daemon. Thus the ntp daemon should logically and preferably run on the host as being a basic core component for the host to function.

For that reason I keep the ntp daemon always on all my nodes on the host.


Running it in an unprivileged container (which is currently not available in TOS)