You are not logged in.
I just noticed that my hwclock was off by nearly 30 seconds. It's almost certainly due to the recent initscripts update.
As I was looking into resetting the clock, I found out that openntpd is deprecated so I've switched to ntp, configured the daemon, reset the time with ntpd -q, and started the daemon. The time is not accurate again.
I remember back when I first installed Arch I tried to set up ntp but it didn't seem to work, so I tried openntpd and stuck with that. I reached the conclusion that ntp required open ports, which I felt was unnecessary given that openntpd could do the same thing without open ports.
Now that I'm looking at it again, I can't find any definitive answer...
Do I need to open ports for ntp if I only want to sync the system that it's running on?
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
This is what i know:
ntpd requires full bidirectional access to the privileged UDP port 123.
ᶘ ᵒᴥᵒᶅ
Offline
ISC ntpd (the ntp package) will open UDP 123 on all your interfaces regardless of what you do with it. It will work anyway even if you block this port in iptables, assuming that you're allowing responses to established traffic as usual - your outbound mobilization requests to your chosen servers will be enough to allow the responses, and the same with further traffic sent for the lifetime of ntpd. Using iptables like this is probably the easiest way to secure ntpd.
There's also some defense in depth you can do:
- run ntpd as non-root
- run it chrooted to some safe directory (really only makes sense when doing non-root as well, since root can break out of a chroot)
- apply ntpd's built-in access controls (see examples in ntpd.conf, and full docs in ntp_acc(5))
I accomplish the first two of these by chowning /var/lib/ntp (and any contents) to ntp:ntp (so ntpd can write ntp.drift there when non-root), by using a driftfile path relative to the chroot in ntp.conf, and by setting NTPD_ARGS="-g -i /var/lib/ntp -u ntp:ntp" in /etc/conf.d/ntp-client.conf.
For the third, I chose to not allow any remote traffic to initiate anything with my ntpd, with this /etc/ntp.conf:
server ac-ntp0.net.cmu.edu iburst
server ac-ntp1.net.cmu.edu iburst
server ac-ntp2.net.cmu.edu iburst
server ac-ntp3.net.cmu.edu iburst
server ac-ntp4.net.cmu.edu iburst
restrict default nomodify nopeer noquery
restrict 127.0.0.1
driftfile /ntp.drift
Note the two "restrict" lines. The first shuts out remote access of most kinds, and the second allows the local machine all the access that would also be denied to it as well otherwise by the first rule. Note also the driftfile path, relative to the chroot of /var/lib/ntp/.
With all these security features, ISC ntpd can be just as safe as openntpd.
The use of the "iburst" keyword on the server lines to recover more quickly from out-of-contact conditions is also quite nice, and not rude to the remotes like "burst" would be.
One of the nicest other features of ISC ntpd is that it's smart enough to notice when network state changes occur, like bringing a VPN up/down, changing routes, or switching from wired to wireless and back. openntpd tended to just lose connections in these cases.
Offline
Good advice, thanks. I've changed the configs to make it run as the "ntp" user.
Consider adding that to the ntp wiki page too.
I thought it might need open ports because I'm almost certain that it didn't work the first time that I set it up (nearly 3 years ago), despite my RELATED,ESTABLISHED rule. I thought maybe the replies were sent after some initial notification and thus counted as NEW. I'll find out in a few days if the system is keeping time this time.
Thanks again.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
I'm using it here also without opening any ports for it and it works fine. However I didn't make it run as a user as ataraxia suggests to improve security, the rest is the same.
One thing I have noticed is that if when you start ntpd and it can't resolve the names of the time servers into addresses it will just drop then out of the usable servers list.
In practice that will leave you without any servers to sync with.
The solution proposed in the wiki is to start/stop the daemon when a connection goes up/down but in my opinion that is not the best solution. I've added the names and addresses of the servers I use to /etc/hosts and so far everything has been running smoothly because the names can always be resolved and ntpd will just wait until it can connect to the servers.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Good advice, thanks. I've changed the configs to make it run as the "ntp" user.
Consider adding that to the ntp wiki page too.
Isn't it already there? https://wiki.archlinux.org/index.php/Nt … -root_user
One thing I have noticed is that if when you start ntpd and it can't resolve the names of the time servers into addresses it will just drop then out of the usable servers list.
In practice that will leave you without any servers to sync with.
But as soon as the the network connection is up, it will automatically try again, right? I'm pretty sure mine does that, without my interference.
I noticed another thing while trying to determine if ntp was working: I rebootet Arch, entered the BIOS, increased the clock by an hour and booted in to Arch. A few seconds after ntpd had started, the clock was immediately rolled back an hour. I thought ntpd was supped do adjust the time gradually, by small amounts at a time.
Offline
But as soon as the the network connection is up, it will automatically try again, right? I'm pretty sure mine does that, without my interference.
When I noticed the problem it would just discard all servers and would not try them again, the output of 'ntpq -p' would be empty and if I remember correctly it would output to the log something about no usable servers. The problem would be: ntpd tried to translate name to IP, it fails, discards server, repeat for all servers in the list. Since there is no network connection up yet the dns lookup fails instantly so all servers would be discarded in the blink of an eye.
At the time (an now) I'm using wicd to manage my network connections and both ntpd and wicd are started in the background so there is no assurance that I'll have the network up before ntpd starts, or that I will have network at all (because of no network or weak signal). Sometimes I connect to networks with a weak signal or too crowded and the connection drops and reconnects often so in my opinion restarting ntpd just because of that doesn't seem to make sense.
There is a catch to the method I use, if you use a time server address that returns a different IP based on your geographical location then you can't put it's address and IP in /etc/hosts (obviously ).
Edit:
Didn't actually answer your question In my case yes, when the connection is up it will work as expected. Since it can resolve the IP address of the server when it starts, ntpd will just assume the servers can't be reached temporarily and will keep trying to reach them from time to time.
Last edited by R00KIE (2011-07-10 11:14:49)
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
I noticed another thing while trying to determine if ntp was working: I rebootet Arch, entered the BIOS, increased the clock by an hour and booted in to Arch. A few seconds after ntpd had started, the clock was immediately rolled back an hour. I thought ntpd was supped do adjust the time gradually, by small amounts at a time.
The -g flag will make it set the clock all at once, one time right after startup, if needed.
Offline
Good advice, thanks. I've changed the configs to make it run as the "ntp" user.
Consider adding that to the ntp wiki page too.
As Lars pointed out, the non-root setup is already there. I did just now add a section on running in a chroot, and added some elaboration to the section on applying access controls.
Offline
Thanks x2, ataraxia.
Offline