| The relationship we have just set up is a client/server relationship. This means that the client will always be synchronized from the server, never the other way around . Relationships are devised by settings in the file /etc/ntp.conf . The full list of relationships is: -
server : This is where the named host provides time to me. I can never provide time to them. Where multiple servers are listed, the xntpd daemon will choose the most appropriate. A server statement also configures an external clock via a specific Class-A IP address, e.g., 127.127.26.1 for an HP 58305A GPS receiver. -
peer : This is where the named host might provide me with the time. Likewise, I might supply them with time. Being a peer is effectively saying that we are equals. The xntpd daemon on all peers will calculate who is offering the best time and adjust the relevant clock(s) accordingly . -
broadcast : This signifies that I will broadcast NTP packets on the named address; this is probably the broadcast address of my machine (you can find the broadcast address by using ifconfig ). -
Clients can be broadcast clients by using the broadcastclient yes directive whereby they do not know (or care) where the time comes from, as opposed to using a server directive. Let's look at setting up a peer server as well as some pure clients. 18.7.1 Setting up a peer server The process of setting up a peer server is exactly the same as setting up our original timeserver. The main reason for setting up a peer server is to provide redundancy within your organization; we can direct clients to poll both peer servers and choose the most appropriate. The other advantage with peer servers is that they will communicate with each other and arbitrate over who is offering the best time. In this way, we are gathering more time data (from different Stratum-1/Stratum-2 servers, we hope) and in doing so, we are getting a more accurate estimate of the correct time. Here's the list of Stratum-1 servers I am using for my peer server: -
ntps1-0.cs.tu-berlin.de (130.149.17.21) Location : Technische Universitaet Berlin, D-10587 Berlin, FRG Geographic coordinates : 52.518N 13.326E Synchronization : NTP V3 primary (Meinberg GPS 166), Sun 4/65 SunOS4.1.3 Service area : Germany/Europe Access policy : open access Contact : Gerard Gschwind (gg@cs.tu-berlin.de) -
clock.cuhk.edu.hk (137.189.8.174) Location : The Chinese University of Hong Kong. Geographic coordinates : 22:25:10N,114:12:22E Synchronization : NTP V3 Primary (TSS-100 GPS clock) Service area : Hong Kong, China and South East Asia Access policy : open access Contact : Connie Law (connieL@cuhk.edu.hk), KM Fung (kinming@cuhk.edu.hk) Note: IP addresses are subject to change; please use DNS -
ntp1.gbg.netnod.se (192.36.133.130) Location : Netnod Internet Exchange i Sverige AB, Stockholm, SWEDEN (Exchange point Gothenburg, Sweden) Synchronization : NTP V4 primary (UTC(SP) Swedish National Time Scale via GPS CV), FreeBSD Service area : all areas Access policy : open access Contact : Magnus Andersson; see also NTP time server statistics Thank you again to the above-named administrators for your help during this demonstration; keep up the great work! The /etc/ntp.conf file I created looked like this:
server ntps1-0.cs.tu-berlin.de server clock.cuhk.edu.hk server ntp1.gbg.netnod.se peer hpeos002 driftfile /etc/ntp.drift
Notice the peer statement above; this relates to my original timeserver. The updates to the /etc/rc.config.d/netdaemons file look like this:
export NTPDATE_SERVER="ntps1-0.cs.tu-berlin.de clock.cuhk.edu.hk ntp1.gbg.netnod.se" export XNTPD=1 export XNTPD_ARGS=
The only problem I have is that I don't want to have to stop and restart the xntpd daemon on my original timeserver. There is a way I can get around this; I can use the xntpdc command to add entries into a running configuration ( addpeer command) while adding this line:
peer hpeos003
to the /etc/ntp.conf file to ensure that the added peer statement is adopted after every reboot. I have started the daemon on node hpeos003 :
root@hpeos003[] /sbin/init.d/xntpd start 28 Aug 10:05:19 ntpdate[19916]: step time server 130.149.17.21 offset 1037503.823128 sec xntpd root@hpeos003[] root@hpeos003[]
Looking at the nptq output immediately after starting the daemon, we can see the large disp and offset values. This should steady after 5 minutes or so. Here's what it looks like after 5 minutes:
root@hpeos003[] ntpq -p remote refid st t when poll reach delay offset disp ============================================================================= *hora.cs.tu-berl.PPS. 1 u 41 64 367 67.32 -0.902 5.52 +bill.itsc.cuhk..GPS. 1 u 41 64 377 336.27 -37.647 9.37 192.36.133.130 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0 +hpeos002 murgon.cs.mu.OZ 2 u 8 64 374 -6.29 4.972 130.92 root@hpeos003[]
As we can see, we are using the timeserver in Berlin as our primary source of time, with all others being included in the selection, even our peer hpeos002 (notice the small delay , offset , and disp ). To list our relationships with other NTP servers, we can either use the command ntpq or xntpdc . Here are some examples:
root@hpeos002[] # ntpq ntpq> associations ind assID status conf reach auth condition last_event cnt =========================================================== 1 51220 9614 yes yes none sys.peer reachable 1 2 51221 9314 yes yes none outlyer reachable 1 3 51222 9414 yes yes none synchr. reachable 1 4 51223 9414 yes yes none synchr. reachable 1 ntpq>
At first, I found this output a little off- putting in that there are no hostname/IP addresses. You can also use the command pstatus to print status information relating to an association ID :
ntpq> pstatus 51221 status=9414 reach, conf, sel_sync, 1 event, event_reach srcadr=metasweb01.admin.ch, srcport=123, dstadr=192.168.0.202, dstport=123, keyid=0, stratum=2, precision=-16, rootdelay=38.57, rootdispersion=48.17, refid=ntp1.ptb.de, reftime=c2f84fc2.59208e15 Thu, Aug 28 2003 10:54:10.348, delay= 59.56, offset= -7.19, dispersion=2.98, reach=377, valid=8, hmode=3, pmode=4, hpoll=7, ppoll=7, leap=00, flash=0x0<OK>, org=c2f8513c.b29a3d2d Thu, Aug 28 2003 11:00:28.697, rec=c2f8513c.bc112000 Thu, Aug 28 2003 11:00:28.734, xmt=c2f8513c.accf6000 Thu, Aug 28 2003 11:00:28.675, filtdelay= 59.56 57.24 74.91 63.83 59.83 54.41 52.99 101.78, filtoffset= -7.19 -10.57 0.79 -6.45 -1.89 -5.84 -9.52 14.53, filterror= 0.02 1.97 3.92 4.90 5.54 6.04 7.02 8.00 ntpq>
From this, we can see that this association relates to the entry for node metsaweb01.admin.ch . If this gets to be too much, you can always use the lpeers command (print a list of all peers and clients).
ntpq> lpeers remote refid st t when poll reach delay offset disp ============================================================================= *murgon.cs.mu.OZ.GPS. 1 u 122 128 377 337.84 -2.017 1.45 -metasweb01.admintp1.ptb.de 2 u 12 256 377 77.51 1.743 13.11 +ntp-cup.externa.GPS. 1 u 54 128 377 177.49 1.261 0.84 +hpeos003 hora.cs.tu-berl 2 u 27 128 377 0.43 0.749 2.47
Using both pieces of output, we can see that host metasweb01 is currently an outlyer ; in other words, we are not longer selecting it for synchronization (see the higher-than-normal disp value). This may change over time, depending on the reliability of our network connections. An alternative way to look at our associations is by using the xntpdc command:
root@hpeos002[] # xntpdc xntpdc> listpeers client murgon.cs.mu.OZ.AU sym_active hpeos003 client metasweb01.admin.ch client ntp-cup.external.hp.com xntpdc>
Some people prefer to use the listpeers command within xntpdc , because we can see immediately our relationship with other nodes. There are commands in xntpdc similar to commands in ntpq , although there are commands in xntpdc that can be useful for analyzing statistics:
xntpdc> sysstats system uptime: 2330 time since reset: 2330 bad stratum in packet: 0 old version packets: 0 new version packets: 260 unknown version number: 0 bad packet length: 0 packets processed: 121 bad authentication: 0 limitation rejects: 0 xntpdc> pstats hpeos003 remote host: hpeos003 local interface: 192.168.0.202 time last received: 60s time until next send: 250s reachability change: 2317s packets sent: 26 packets received: 31 bad authentication: 0 bogus origin: 1 duplicate: 0 bad dispersion: 19 bad reference time: 0 candidate order: 3 xntpdc>
There is always help as well. Before leaving the subject of peers, we should talk about authentication. If we are to run as we are, we could have other hosts sending us unauthenticated, unencrypted NTP packets. The problem with this is if a computer is posing as a Stratum-1 server, we might want to use it as our timeserver. That computer may not be a Stratum-1 server and, hence, our clock is now incorrect, posing potentially life- threatening problems for our applications. Access to public timeservers involves no authentication. It is worth considering setting up authentication at least between your peers so you know they are all trusted. 18.7.2 Setting up NTP authentication In order to trust the time we are receiving from other machines, we need to create some trusted keys (effectively a password) that will be used to authenticate other machines in our NTP network. Here's how it works: We create a key file (the name isn't important, but the usual name is /etc/ntp.keys ). Here's the one I created:
root@hpeos002[] # cat /etc/ntp.keys 100 M ThisIsALongPassword root@hpeos002[] # ll /etc/ntp.keys -rw------- 1 root sys 26 Aug 28 12:22 /etc/ntp.keys root@hpeos002[] #
The first thing to notice is the permissions. This is important. If not set to 600, authentication will not work. The key file itself is a relatively simple format. We have three fields in the following:
<key ID> <encryption method> <key>
-
<key ID> is a unique integer used to identify the key. -
<encryption method> can take one of four forms: - - S : a 64-bit hexadecimal number in the format specified in the DES document; that is, the high-order 7 bits of each octet are used to form the 56-bit key, while the low-order bit of each octet is given a value such that odd parity is maintained for the octet. Leading zeroes must be specified (i.e., the key must be exactly 16 hex digits long) and odd parity must be maintained . Hence, a zero key, in standard format, would be given as 0101010101010101.
- - N : The key is a 64-bit hexadecimal number in the format specified in the NTP standard. This is the same as the DES format except the bits in each octet have been rotated one bit right so that the parity bit is now the high-order bit of the octet. Leading zeroes must be specified, and odd parity must be maintained. A zero key in NTP format would be specified as 8080808080808080.
- - A : The key is a 1- to 8-character ASCII string. A key is formed from this by using the lower-order 7 bits of the ASCII representation of each character in the string, with zeroes being added on the right when necessary to form a full width 56-bit key, in the same way that encryption keys are formed from UNIX passwords.
- - M : The key is a 1- to 32-character ASCII string, using the MD5 authentication scheme. Note that both the keys and the authentication schemes (DES or MD5) must be identical between a set of peers sharing the same key number.
-
<key> is the actual key itself. I took the definition for the encryption methods straight from the manual for the xntpd command. When I read them I quivered. The first two encryption methods seem a bit difficult to work out the keys by hand. They are. Unless you have a specific command to create these keys, it can be very difficult, although they do offer a good level of security. The last two options are easier to understand, with the last option my favorite. A 32-character ASCII string gives us a reasonable length password . As you can see from the /etc/ntp.keys above, the last encryption method is not too difficult to set up. We must ensure that the same keys are used on all associated nodes. We can use keys in server , peer , and broadcast configurations. I will show you the changes I have made to enable authentication and to use the keys in my /etc/ntp.keys file. These changes were made to /etc/ntp.conf on both nodes hpeos002 and hpeos003 .
authenticate yes peer hpeos003 key 100 keys /etc/ntp.keys trustedkey 100
The number of different keys I have depends on the relationships I have with administrators on other sites; I may have different keys for all nodes. In that case, I would need to ensure that each node had the appropriate key in its /etc/ntp.keys file. Whether this is working will be evident when we fail to synchronize with our peers. We can monitor this with ntpq and entries in syslog . Distribution of key files is important because commands like rcp and ftp will simply copy the keys over our network in plain text. Perhaps all the NTP administrators could meet once a week to quaff some ale and exchange trusted keys? Before looking at configuring purely NTP clients, we look at the last of the possible server configurations. This is where we have no external access to the Internet and we cannot justify the use of a GPS/radio receiver. In this instance, we are going to use a reliable, if inaccurate internal clock of one of the servers on our network. | 