| With a broadcast client, we need to have a server(s) broadcasting NTP packets on our networks. It is a good idea to have multiple servers broadcasting in case one is down for urgent maintenance. In our case, both hpeos002 and hpeos003 are located on the same subnet and will both broadcast time packets to anyone listening. We need to ensure that this line:
broadcast 192.168.0.255
is added to the /etc/ntp.conf file. Once completed, we can configure a broadcast client. We will probably still want to use ntpdate to synchronize the broadcast client with one of our servers at boot time. It is in the /etc/ntp.conf file that we see a change in the setup:
root@hpeos004[] vi /etc/ntp.conf ... broadcastclient yes driftfile /etc/ntp.drift root@hpeos004[] vi /etc/rc.config.d/netdaemons export NTPDATE_SERVER="hpeos002 hpeos003" export XNTPD=1 export XNTPD_ARGS=
Notice that we are still using ntpdate to perform a step-change at boot time. Some administrators do not add the entry for ntpdate but purely rely on the use of the xntpd daemon. I leave it for you to decide which is appropriate for your installation. As we noted previously, performing a step-change at boot time will immediately bring both server and client into line. Thereafter, we rely on the xntpd daemon to keep both clocks synchronized. This appears to be the favored mode of operation. Let's run the startup script and see what happens:
root@hpeos004[] /sbin/init.d/xntpd start 28 Aug 13:03:22 ntpdate[2841]: step time server 192.168.0.203 offset -0.036973 sec xntpd root@hpeos004[] root@hpeos004[]
Once we have let the xntpd daemon settle down for the requisite 5 minutes, we can check the behavior of our associations with ntpq :
root@hpeos004[] ntpq -p remote refid st t when poll reach delay offset disp ============================================================================= *hpeos003 ntp1.gbg.netnod 2 b 24 64 377 0.34 -1.999 1.27 +hpeos002 murgon.cs.mu.OZ 2 b 14 64 377 0.82 -0.716 1.27 root@hpeos004[]
And that's about as easy as it gets. | 