Redhat 7.3 NTP/NTPD problems
The Network Time Protocol is a method for a computer to obtain the
correct time over the network, and keep its clock running at a high degree
of accuracy. Incorrect times will lead to widespread problems with mail,
nfs, make, backup scripts, etc. The hardware and software clocks in
inexpensive PC computers often drift far afield, and in any case it is a
nuisance to set the CMOS clock. An open source program - ntpd - is used in
most computer systems to implement the protocol, and ntpd is included with
Redhat 7.3, but not turned on by default. This leaves Linux with only the
CMOS clock and the CPU timer for timekeeping.
A simple client installation of ntpd is indeed very simple - a binary
daemon (ntpd) periodically connects to a time server at port 123 and
updates the system clock. The daemon rarely needs more than one argument,
and the configuration file need not be more than two lines. Nevertheless,
any newcomer is likely to be confused by the fact that (1) in spite of the
elaborate ntpd.conf file supplied, the Redhat ntp daemon won't be working
after a default install and (2) the hundreds of pages of documentation for
ntpd are strictly for advanced cronologists.
Redhat 7.3 comes with a complete set of ntpd binaries but they are not
enabled at boot time. There is a script in /etc/init.d to control ntpd,
but if run, ntpd does not run correctly. The problems seem to be entirely
in the script and configuration file.
Fatal Problems
- /etc/init.d/ntpd reads a list of arguments for ntpd from the
file /etc/sysconfig/ntpd when starting ntpd. By Redhat default the
arguments are "-U ntp". These arguments are not documented in the ntpd man
page or on the man pages at www.ntp.org,
but is mentioned in /usr/share/doc/ntp-4.1.1/ntpd.htm:
The apparent effect of this is to make ntpd run as user ntp. But user
ntp (with UID=38) is not root, and thus no has ability to update the OS
clock. It does apparently bind to the time port before giving up root.
It is very difficult to understand how this situation could persist, but
even after several months it is not mentioned on the RH website and "up2date" does not bring a
correction. A few people have mentioned it in newsgroups.
In a private communication, Mony Walls has written to me that the
ntp daemon can still set the time as user ntp, because it can switch back
to root for that purpose alone. Perhaps this is true, but without an
inaccurate clock, I don't see any way to test this.
- The Redhat installation program never prompts for the address of
an actual ntp server, nor does it do any searching on its own. Rather it
specifies 127.127.0.1 for the ntp server in the default /etc/ntp.conf
file. I can't imagine what this accomplishes, as that merely points to
localhost.
Minor Problems
- Man pages are not installed by default.
- The script uses the deprecated "ntpdate" command at startup, rather
than the endorsed "ntpd -q" command.
- There are no installation instuctions. This quick start
page is helpful but not Redhat specific and says nothing about choice
of command line arguments or basic testing.
- A couple of bits of information that will reduce frustration for
newbies are that ntptrace (the command to run for ntp status information)
won't start working for about an hour after the daemon runs, and that
error messages go to /var/log/messages.
Suggested Remedy
It is not necessary to reinstall ntpd. All you need to do is
delete the /etc/sysconfig/ntpd file and modify the server line of
/etc/ntp.conf to point to a real server. Run /etc/init.d/ntpd from your
/etc/rc.local. An hour later, try "ntptrace". That command will show you
the path from your clock to a "Stratum 1" time server, probably an atomic
clock at the National Bureau of Standards, but possibly elsewhere.
If your LAN doesn't already have one your ISP probably has an ntp
server. If they don't document the address, try host "ntp" in their domain
or their major routers and nameservers before resorting to public servers.
All Cisco routers can serve ntp, but it may not be turned on. I think more
ISPs would have a time server than would think to tell you about it - poke
around.
I did receive this letter from an informed source:
Date: Sun, 8 Sep 2002 20:45:21 -0700 (PDT)
From: Matt Perry
To: Daniel Feenberg
Subject: RedHat NTP details
On Fri, 6 Sep 2002, Daniel Feenberg wrote:
> You did see that someone wrote to me and pointed out that in spite of
> the note in the user docs, -u does not really run ntpd as non-root...
Well, sort of. Redhat's ntpd requires the use of libcap which is a set of
userspace utilities for an implementation of POSIX draft 1003.1e. Note
that this is libcap as in "capabilities" not libpcap which is for "packet
capture."
This draft used to be called "POSIX capabilities." What it does is allow
for programs that are non-root to have specific capabilites that root
would have. Rather than give a program all root privilges, you can define
certain functions that would require root privileges and assign them to
the program.
A process has three sets of bitmaps called the inheritable (I), permitted
(P), and effective (E) capabilities. Each capability is implemented as a
bit in each of these bitmaps which is either set or unset. When a process
tries to do a privileged operation, the operating system will check the
appropriate bit in the effective set of the process (instead of checking
whether the effective uid of the process is 0 as is normally done).
You can use the utilities that come with the libcap library to look at the
capabilities of a running process. On my system I have ntpd running with
a PID of 806:
# ps axfu |grep ntp
ntp 806 0.0 0.7 1904 1896 ? SL Aug24 0:03 ntpd -U ntp
So I can use the getpcaps command to see what capabilities ntpd has:
# getpcaps 806
Capabilities for `806': = cap_sys_time+eip
So it has the cap_sys_time capability for the inheritable, permitted, and
effective bits. This is what allows ntpd to run as a non-privleged user
and still make a single privleged function call.
So your next question is probably "Why isn't this in the docs on the NTP
site?" That's because this is a Red Hat patch. If you install the ntp
source RPM and cd to /usr/src/redhat/SOURCES you'll see the patch along
with three others.
Regarding configuration:
Just like dhcpd doesn't work out of the box, ntpd isn't going to either.
How you configure it depends on your network and how you handle time
services. Also, if Red Hat just included a default time server in the
config file, all those people who run ntpd would cause a denial of service
against that one poor server.
The latest Red Hat beta prompts to set an NTP server the first time X11
comes up, but you'll still need to set one by hand when running without X
just like on current versions of Red Hat.
Where I work, we have one machine as a master NTP server which has seven
public NTP servers defined. All of our other machines, both servers and
workstations (almost 500 in total) point to this one internal NTP server
for synchronization. Actually, I have NTP configured to make time
available via multicast and all of the other machines are set to receive
via the multicast IP to keep network traffic down.
Anyway, to configure NTP in its most basic form, all you need to do is
install the RPM, and then add a line like the following to /etc/ntp.conf:
server tick.usno.navy.mil
That's it. You can add more server lines if you want. I add at least two
to my ntp.conf file, sometimes more like the server at work. When
ntpd can't get a response from one, it'll move on to the next one.
Do not remove the one that points back to 127.127.0.1. You said in your
article that you don't know what this is used for, but it's explained
right in the comments above that line. It, along with the following
"fudge" command, creates a fake driver for use when there is no other
source of time. This will help the machine keep reasonably acurate time
when an outside time source can't be reached. This page explains in more
detail: http://www.eecis.udel.edu/~ntp/ntp_spool/html/driver1.htm
As for the other issues you mentioned:
1. There are no man pages because the original NTP distribution doesn't
contain any.
2. While ntpdate may be deprecated, it's still included in the current
distribution and as such, it's probably not a problem to use it.
There's really not any difference between ntpdate and 'ntpd -q' except
for the fact that ntpdate is just a separate program. I'm sure that
once the NTP distribution removes ntpdate altogether that Red Hat will
update their script.
The init script only calls ntpdate if you have populated
/etc/ntp/step-tickers with the name of a time server. If that file
doesn't exist or is blank then ntpdate isn't called. Instead, at least
on RH 7.3, ntpd is started with the -g option which allows it to make
time adjustments greater than 1000 seconds. By default, ntpd will exit
with an error in the syslog if the time is off by greater than 1000s.
I find this option preferable to the ntpdate option and the 'ntpd -q'
option because both of those will wait and not return until they have
either timed out or set the time. In contrast, starting ntpd with the
-g option will go ahead and daemonize the process so that the system
can continue booting while ntpd is dealing with getting and setting the
time.
As for your suggested remedy, I would advise against removing
/etc/sysconfig/ntpd entirely. Granted this is a sysadmin style so you
might admin your machines differently. However, if you wanted to run ntpd
as root, it would be better to edit /etc/sysconfig/ntpd to set OPTIONS=""
so that the existance of the file and the fact that you can add options
there is somewhat documented.
One other thing to note is that the time is update slowly. Rather than
just setting the date to the correct time, it slowly adjusts the time to
correct it. This helps from skewing the time on log files and such.
It's also why if you set your time wrong and run ntpd, it looks like it's
not working. The rate of correction is the clock is adjusted by 1 second
every minute.
Date: Tue, 06 Jan 2004 17:03:43 +0000
From: Martin Beecroft
To: feenberg at nber dot org
Subject: NTP
Hi Daniel,
I have been struggling with ntp on redhat servers, and have found your
page at http://www.nber.org/sys-admin/ntp.html very useful. However, to
get my clocks syncing correctly I had to perform one extra step which I
did not see listed anywhere.
At the top of /etc/ntp.conf, there is a line which reads:
restrict default ignore
None of my servers would sync correctly, until I commented this line
out. As matt@primefactor pointed out, the config files would need to be
changed from the default, but I would have thought that this line would
have been commented out by default, as it seems to be fairly crucial to
making NTP work.
Anyway, thanks for the ntp page as it has proved to be very useful in my
quest.
Cheers
Martin Beecroft
An updated version of this page will be kept at
http://www.nber.org/sys-admin/ntp.html
lost+found
Daniel Feenberg
feenberg at nber.org
5 September 2002