The post describes how to setup the NTP (network time protocol) client on Solaris 8,9 and 10 as well as non-global zones. The configuration in the global zone and a non-global zone is exactly same, except for the fact that non-global zones are not allowed to change the time bye default. This can be enabled by assigning a privilege to the non-global zone. Below are some terms with which you should be familiar in order to configure and troubleshoot NTP client.
Stratum : Time is distributed through a hierarchy of NTP servers, with each server adopting Primary (stratum 1) servers which are at the top of the pile and have access to some external time source, usually a radio clock. A stratum-2 server is one which is currently obtaining time from a stratum-1 server, a stratum-3 server would get its time from a stratum 2 server and so on. To avoid long lived synchronization loops the number of strata is limited to 15.
The configuration
1. Copy the /etc/inet/ntp.client to /etc/inet/ntp.conf.
# cp /etc/inet/ntp.client /etc/inet/ntp.conf
2. start xntpd daemon on client
For Solaris 8 and 9:
# /usr/lib/inet/xntpd
For Solaris 10:
# svcadm enable ntp
There are 3 ways to configure the NTP client :
1. Using the multicast address :
Specifiy that the local server is to operate in multicast mode where the client will receive NTP time information via multicast packets addressed to the multicast address named in the command.
multicastclient 224.0.1.1
Note: this is the default configuration when the /etc/inet/ntp.client template is used to configure /etc/inet/ntp.conf.
2. Sync from specific server(s)
If you want to sync your clock to a particular server or servers, then specify it/them as below in the /etc/inet/ntp.conf file.
server (ipaddress)
For example :
server 192.168.1.20
3. symmetric active mode with another system
We can also specify the system to operate in symmetric active mode with another system as :
peer (ipaddress)
For example :
peer 192.168.1.20
Verifying the client setup
To verify if the client is setup correctly :
root@solarislab33# ntpq -p remote refid st t when poll reach delay offset disp =========================================================================== *192.168.10.10 172.30.1.1 3 u 1021 1024 377 0.64 -0.619 0.12
Where :
refid: The reference ID (0.0.0.0 if the ref ID is unknown)
st: The stratum of the remote peer
t: The type of the peer (local, unicast, multicast or broadcast) when the last packet was received
when: How many seconds ago was the last poll to this time server
poll: The polling interval in seconds
reach: The reachability register, in octal
delay, offset, disp: The current estimated delay offset and dispersion of the peer, all in milliseconds.
* in remote indicates currently selected peer + means that the host is an acceptable peer for synchronization but not accepted - not acceptable
If everything is working fine, the delay and offset value should be non-zero.
Configuring NTP client in a non-global zone.
The configuration settings for configuring the NTP client in a non-global zone is exactly the same as above. But there is a catch here, a Solaris instance running in a non-global zone fails to use the NTP service for time synchronization. An attempt to start the NTP service will fail with the following error message in the syslog :
Sep 7 18:45:47 zone ntpdate[19820]: [ID 999808 daemon.error] Can't adjust the time of day: Not owner Sep 7 18:45:47 zone xntpd[19822]: [ID 702911 daemon.notice] xntpd 3-5.93e+sun 03/08/29 16:23:05 (1.4) Sep 7 18:45:48 zone xntpd[19822]: [ID 272427 daemon.error] sched_setscheduler(): Not owner Sep 7 18:45:48 zone xntpd[19822]: [ID 301315 daemon.notice] tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100 Sep 7 18:45:48 zone xntpd[19822]: [ID 953130 daemon.error] loop_config: ntp_adjtime() failed: Not owner Sep 7 18:45:48 zone xntpd[19822]: [ID 266339 daemon.notice] using kernel phase-lock loop 0041, drift correction 0.00000 Sep 7 18:45:48 zone xntpd[19822]: [ID 953130 daemon.error] loop_config: ntp_adjtime() failed: Not owner Sep 7 18:45:48 zone xntpd[19822]: [ID 266339 daemon.notice] using kernel phase-lock loop 0041, drift correction 0.00000
Solution
In a system with non-global zone, the global zone kernel is being shared by all the non-global zones. As a result there is only one date/time on the entire setup and this time is usually controlled by the global zone only. By default the privilege to change the date and time is not available inside a non-global zone and therefore the NTP service will fail to adjust the time. The default configuration for non-global zones assumes that the time synchronization is done in the global zone and that there is no need to adjust the system time from inside a non-global zone. If the administrator of a non-global zone is able to change the system time then these changes will affect all running zones (including the global zone) and this maybe considered a security risk.
As mentioned above, the ability to adjust the time is controlled by a Solaris privilege. The privilege name for this is called “sys_time” and the information for this privilege can be viewed by using the ppriv command :
# ppriv -lv sys_time
sys_time
Allows a process to manipulate system time using any of the
appropriate system calls: stime, adjtime, ntp_adjtime and
the IA specific RTC calls.
If you are unsure whether the sys_time privilege is currently available to you then you can use the following command (as root) to check whether the privilege is available:
# ppriv -v $$ | grep sys_time
By default the command will only show output in the global zone but not in any non-global zone. By default the sys_time privilege is not assigned to a non-global zone. Starting with Solaris 10 Update 3 (11/06) the available privileges of a non-global zone can be changed by using the limitpriv option of the zonecfg command.
In the default configuration the limitpriv setting would be empty:
global-zone# zonecfg -z zonename info limitpriv limitpriv:
If you want to add the sys_time privilege to a zone then you can use the zonecfg command to modify the property and reboot the zone to activate the change:
global-zone# zonecfg -z zonename set limitpriv="default,sys_time" global-zone# zoneadm -z zonename reboot
Once the sys_time privilege is available in the non-global zone you can continue to setup NTP as usual, i.e. configure the /etc/inet/ntp.conf file and enable the ntp service.
Using the ntpupdate command
The ntpdate utility sets the local date and time. To determine the correct time, it polls the Network Time Protocol (NTP) servers on the hosts given as arguments. This utility must be run as root on the local host.It can be run on a regular basis from cron as an alternative to running a daemon. Doing so once every one to two hours will result in precise enough timekeeping to avoid stepping the clock. If you are already running the xntpd daemon you can’t use the ntpdate command. Trying to do so will generate the following error :
# ntpdate champ 07 Sep 14:55:52 ntpdate[19780]: the NTP socket is in use, exiting
You must also be root user to run the ntpdate command or you will see an error like this returned:
% ntpdate champ 23 Sep 14:44:36 ntpdate[19743]: bind() fails: Permission denied
In this example we are specifying the ntp server “kala” to sync with.
# ntpdate kala 07 Sep 17:12:21 ntpdate[20963]: adjust time server 129.148.nnn.nnn offset 0.001422 sec