Setting Time on the ABC Server

Some notes on setting the time.

Setting from the command line
The date command: date
(Seconds are optional; omit .ss if just setting to nearest minute.)
To set the year too: date
(Once again, seconds are optional.)
To discover what time and date the server thinks it is, use the date command without arguments.
Good to know, but it shouldn't be necessary to set the time from the command line.

The ntp daemon
The ntp daemon synchronises the system clock with remote NTP (network time protocol) servers.
Is there an ntpd service? Yes.
For some reason, ntpd isn't running. Now there's a surprise.
Have done the following:
service ntpd stop
(wasn't running anyway!)
ntpdate -u
( is the time server. There is a list of alternatives at:
service ntpd start

The configuration file for ntpd is /etc/ntp.conf.

Where are we now?
The system date as displayed by the date command is now correct, showing BST. However, forum posts still stamped with (presumably) GMT, 1 hour behind. Also, this sets the system clock but not necessarily the hardware clock.

Start the service at boot-up
Put that aside for a moment. Before I forget, I have to make sure that ntpd starts at boot-up in future. A look at top (table of processes?) (Could use ps - process snapshot?) shows init as pid 1, which tells me that we're not using the more modern upstart and that the pid isn't randomised, as it would be on a fully security-hardened server.

A look at /etc/inittab shows that init defaults to runlevel 3 (full multiuser mode), which is what I'd expect. Don't take anything for granted on this server, though!

chkconfig --list shows ntpd 'off' at all runlevels.

This is what we (think we) know about chkconfig, daemons, and so forth. In /etc/rc.d/init.d reside shell scripts to start and stop daemons. Any that are to be managed by chkconfig must have two or more commented lines as follows:

The first line tells chkconfig the default runlevels at which the service should be started, plus the start and stop priority levels. This line in the ntpd script currently says:

chkconfig: - 58 74

where 58 is the start priority and 74 is the stop priority. The '-' says that the daemon should not be started at any run level. At the very least, need to substitute a '3'. Edited to read:

chkconfig: 3 58 74

(If need to start it at other runlevels, these are just concatenated, e.g. chkconfig: 2345 58 74)

The second and subsequent lines, with a backslash continuation, contain a description of the service. There are four lines in the nptd file. No reason to edit them.

chkconfig --list still shows 3:off for ntpd. Let's see what happens if we do this:

chkconfig --level 3 ntpd on

The result is, or seems to be, what we want: chkconfig now shows 3:on for ntpd. Doing the same for level 2 shows up correctly in chkconfig --list too.

chkconfig works by manipulating symbolic links in /etc/rc[0-6].d to the scripts in /etc/init.d (actually in /etc/rc.d/init.d; there is a symlink from the /etc/init.d directory to /etc/rc.d/init.d). Issuing ls /etc/rc[n].d | grep ntpd shows K74ntpd for n=0,1,4,5,6 and S58ntpd for n=2,3. Interpreting K as kill and S as start, and assuming 54 and 78 are the priority levels, then all seems well. Issuing chkconfig --level 2 ntpd off turns the service off for runlevel 2; ls /etc/rc2.d | grep ntpd now shows K74ntpd.

We appear to have what we want. At what point chkconfig parses the start/stop scripts to determine the default runlevels is a Linux mystery.

Set the timezone
Now to check the timezone. A list of possible zones is in /usr/share/zoneinfo. In /etc there is a symbolic link called localtime to the appropriate entry in the /usr/share/zoneinfo directory, in this case to GB. Looks good to me.

Setting the hardware clock
Now a visit to /etc/sysconfig. I want the system clock set to UTC. The clock file shows UTC=false, so edit it to UTC=true. Now set the clock:

hwclock --systohc --utc

Now issue hwclock --utc to check the time is set correctly.

As it happens, ntpd appears to set the hardware clock too.

Setting the time in Drupal
Now we have the problem that Drupal is still an hour adrift. Navigating to Administer->Site configuration->Date and time gives a self-explanatory means of setting the time relative to UTC (for current purposes, UTC = GMT) in 1 hour steps. It looks as if BST has to be accommodated by setting the offset manually.