| To get around the problems of manually setting the date on every system, a utility named rdate can be used. This will set the local system time to that of a specified remote machine. For example, to set helium to the same date as hydrogen we would run: helium# rdate hydrogen Sun October 22 17:30:00 GMT 2002 hydrogen# To automate this procedure, we could nominate a machine to be our "time server." As explained above, we have chosen hydrogen for this task. First, we set the correct time on hydrogen. Next, we run rdate on a regular basis, by adding an entry to the root crontab. The redirection will ensure that we don't receive the output as mail every time cron runs: helium# crontab -l | grep rdate 0 4,12,20 * * * rdate timeserver > /dev/null 2>&1 helium# Then, we create a start-up script that performs exactly the same job at boot-time. These two methods ensure that the system will only be out of synchronization for a relatively short period: helium# cat /etc/rc2.d/S99rdate #!/bin/sh # # Set the system date to that of the "time server" # rdate timeserver > /dev/null 2>&1 if [ $? -ne 0 ]; then echo "Error: Check the date - cannot set it to the time server" fi helium# These two files would be copied around all the systems on the network to set them to the same time as hydrogen, our nominated time server. Setting the system time using rdate is a common method of synchronization, but may not be reliable enough in certain cases. For example, there could be problems if the system being used as the reference was down, or there could be problems with applications that required the time to be consistent within a small time window. The command can also have a detrimental effect on log files or time stamps, since it is easy for the reference system to be "older" than the local system and rdate would simply set the local clock back, rather than slowing it until the remote system caught up. This means we could end up with files created in the future; entries in log files would be out of order and so forth. | 
