If [ −z ARGS ] then
wait until date is close before starting xntpd usrsbinntpdate ARGS ; sleep 2 ; usrlibinetxntpd
else usrlibinetxntpd
fi fi
;;
This sequence is a part of the case statement. The way the xntpd daemon is started depends on the existence and contents of the configuration file. The start script lives in the etcrc2.d directory:
ls −l etcrc2.d | grep xntpd
203745 −rwxr−−r−− 4 root sys 1266 Jul 16 1997 S74xntpd
It is also the hard link to the rc script in the etcinit.d depot directory:
ls −l etcinit.d | grep xntpd
203745 −rwxr−−r−− 4 root sys 1266 Jul 16 1997 xntpd
13.1.2 The NTP Configuration File
The configuration file determines the behavior of the xntpd daemon; we will identify it as NTP configuration file. The NTP configuration file should be administered and set correspondingly for
each specific site. The existing self−explanatory template file and manual pages should be sufficient for ensuring successful time daemon setting. Four crucial configuration entries are possible to
define the basic behavior of the xntpd daemon:
peer •
The local time daemon operates in symmetric active mode. It can be synchronized to the specified remote time daemon the time daemon on the specified remote host. In
addition, the specified remote time daemon can also be synchronized by this local time daemon. Such a configuration can be implemented to prevent various failure scenarios
and to provide a choice for a better time source.
server •
The local time daemon operates in client mode. It can only be synchronized to the specified remote time daemon. This is a strictly client mode; please note that the
corresponding time server is selected by the client configuration. It is assumed that the selected remote time daemon provides the time service.
broadcast •
The local time daemon operates in broadcast mode. The local time daemon sends periodic broadcast messages to clients at a specified address, usually a broadcast
address on a local network.
fudge •
The support of the reference clock, used to configure reference clocks in special ways. Configuration entries are explained in more detail within the presented template configuration file
this file is found on HP−UX platform, although NTP is not flavor−colored at all. The example configuration files that follow are also part of the template file.
cat etcntp.conf.example
Sample XNTP Configurations File Use peer, server and broadcast statements to specify various time server to be used
andor time services to be provided. Peer: The peer statement specifies that the given host is to be polled in symmetric active mode.
302
peer addr [ key ] [ version ] [ minpoll interval_in_sec ] [ prefer ]
peer 128.116.64.3 key 2001 version 2 Server: The server statement causes polling to be done in client mode rather than symmetric
active. It is an alternative to the peer command above. Which you use depends on what you want to achieve. The syntax is:
server addr [ key ] [ version ] [ minpoll interval_in_sec ] [ prefer ]
server 128.8.10.1 key 2000 minpoll 6 prefer Broadcast: The broadcast statement tells it to start broadcasting time
out one of its interfaces. Syntax is:
broadcast addr [ key ] [ version ] [ minpoll interval_in_sec ]
broadcast 128.100.49.255 [ key n ] [ version n ] Fudge: Reference clock support which can be used to configure reference clocks
in special ways. The syntax is:
fudge 127.127.t.u [ time1 ] [ time2 ] [ stratum ] [ refid ] [ flag1 – flag4 ]
fudge 127.127.26.1 time1 −0.930 use one fudge line only 127.127.t.u identifies a clock see Local clock
broadcastclient: It tells the daemon whether it should attempt to sync to broadcasts or not default no
broadcastclient yes or no broadcastdelay: It configures in a default round−trip delay to use for
broadcast time in seconds. The default is 0.008 second. broadcastdelay 0.008
Presion: The default is −6. Unless there is a good reason to do so, this value should not be changed from the default value.
precision −6 Drift file: Put this in a directory which the daemon can write to. No symbolic links
allowed, either. driftfile etcntp.drift
authenticate: It configures us into strict authentication mode or not. The default is no. authenticate yes or no.
authdelay: It is the time in seconds it takes to do an NTP encryption on this host. AUTHDELAY
trustedkey: The keys defined here are used when authenticate is on. We only trust and sync to peers who know and use these keys.
trustedkey 1 3 4 8 keys: It specifies the file which holds the authentication keys.
keys etcntp.keys controlkey: It indicates which key is to be used for validating mode 6 write variables commands.
If this isnt defined, no mode 6 write variables commands can be done on the xntpd. controlkey 65534
restrict: This option places restrictions on one or more systems. This is implemented as a sorted address−and−mask list, with each entry including a set of flags which define what a host
matching the entry cant do. The syntax is:
restrict address [ mask numeric mask ] [ flag ]
The flags are: ignore − ignore all traffic from host
noserve − dont give host any time but let him make queries? notrust − give the host time, and let it queries, but dont sync to it.
noquery − host can have time, but can not make queries
303
statdir: Indicates the full path of the directory where statistics files should be created: statsdir vartmpntp
statistics: Enables writing of statistics records: loopstatspeerstats. statistics loopstats
statistics peerstats filegen: Configures the ways to generate the statistic file set. It provides a mean for handling files
that are continously growing during the lifetime of a server. The syntax is: filegen statsname [ file filename ] [ type typename ] [ linknolink ] [ enabledisable ]
filegen loopstats file loopstat type week link filegen peerstats file loopstat type week link
Local clock: Allows the server to synchronize to its own clock. server 127.127.1.1
fudge 127.127.1.1 stratum 10 show poor quality Reference clocks are specified with an invalid ip address 127.127.t.u
−t is an integer denoting the clock type −u indicates the type−specific unit number
Spectracom Netclock2 clocks: synchronize to netclock2 which receives WWVB. server 127.127.3.x PSTI 10101020 WWV Clock
server 127.127.4.1 Spectracom Netclock2 WWVB or GPS receiver devwwvb1 server 127.127.5.x Kinimetric Truetime 468−DC GOES receiver
server 127.127.9.x MX4200 GPS receiver server 127.127.10.x Austron 2201A GPS Timing Receiver
server 127.127.11.x Kinemetrics Truetime OM−DC OMEGA Receiver server 127.127.12.x KSIOdetecs TPRO−S IRIG−B TPRO−SAT GPS
server 127.127.13.x Leitch: CSD 5300 Master Clock System Driver server 127127.15.x TrueTime GPSTM−TMD
server 127.127.16.x Bancomm GPSIRIG Ticktock server 127.127.17.x Datum Programmable Time System
server 127.127.18.x NIST Modem Time Service server 127.127.23.x PTB Modem Time Service
server 127.127.24.x USNO Modem Time Service server 127.127.26.1 HP GPS receiver devhpgps1
Example configurations ================================================== NTP configuration file ntp.conf
baldwin.udel.edu 128.4.1.24 This illustrates the use of an external clock with the local clock
driver, as well as a multicast server. The prefer keyword on the local clock driver declares an external clock and that the time of
this server should not be wiggled by an NTP peer, unless the
304
There is no need for additional comments after such an elaborate template file. However, let us see 305
catetcntp.conf HP−UX
Configured using SAM by root on Thu Nov 20 15:02:29 1998 Sample XNTP Configurations File
server ntphost.scps.nyu.edu version 3 prefer
cat etcinetntp.conf Solaris The ntp.conf file
server tick.usno.navy.mil prefer server tock.usno.navy.mil
enable auth monitor driftfilevarntpntp.drift
statsdirvarntpntpstats filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable filegen clockstats file clockstats type day enable
cat etcinetntp.conf Solaris ntp.client 1.2 991109 SMI
etcinetntp.client An example file that could be copied over to etcinetntp.conf; it
provides a configuration for a client host that passively waits for a server to provide NTP packets on the ntp multicast net. A broadcastmulticast client
can automatically discover remote servers, compute one−day delay correction factors and configure itself. No need for specific configuration data.
multicastclient 224.0.1.1
cat etcntp.conf Linux ntp.client 1.2 991109 SMI
etcinetntp.client An example file that could be copied over to etcinetntp.conf; it
provides a configuration for a client host that passively waits for a server to provide NTP packets on the ntp multicast net.
multicastclient 224.0.1.1 This is a ntp client configuration
Listed ntp servers are stratum2 and located in NY They are open for public access
server sundial.columbia.edu prefer server ntp1.magenet.com prefer
server ntp0.cornell.edu
This file saves a drift calculation it takes almost a day, so it makes a start of xntpd daemon faster driftfile
varntpntp.drift
306
In UNIX the need for periodic program execution is a real demand. Primarily, it is a good idea to try to automate many administrative tasks, enabling their automatic periodic executions. A typical
example is an unattended backup, which usually occurs at night, outside of normal business hours. Automation offers many advantages over performing the same tasks manually from the command
line, such as:
Greater reliability — Tasks are performed the same way every time. Correct and complete performance is guaranteed by the fact that the very same program has already been run a
number of times without any problems. •
Guaranteed regularity — Tasks can be performed according to whatever schedule seems appropriate and need not depend on anyones availability presence.
•
Enhanced system efficiency — Time−consuming or resource−intensive tasks can be performed during off−hours.
•
In UNIX, automation is accomplished via shell scripts and by the cron daemon.
13.2.1 The UNIX cron Daemon
