以RHCE实验室为准,一个简单的NTP时间服务器标准配置如下:
服务器端:
首先修正下系统时间,并将系统时间写进硬件时间里
date MMDDhhmmYYYY.ss;hwclock -w
vim /etc/ntp.conf
restrict default nomodify notrap noquery
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
server 127.127.1.0
fudge 127.127.1.0 stratum 0

客户机端:
vim /etc/ntp.conf
server 192.168.1.2
vim /etc/ntp/step-ticker
192.168.1.2
客户端重启ntpd服务即可看到效果 service ntpd restart

※在授课过程发现，虚拟的linux的时间比真实机越走越慢，具体原因分析如下:
Linux 2.6核心里把系统计时器的频率加高到1000 Hz ，VMware没办法真的每隔1ms就报一次讯号给guestOS，所以guestOS里的Linux 2.6无法确实接到计时器的讯号。本来这也不应该造成问题，不过2.6核心处理这个"tick loss"的程式有问题，以致于guestOS里的Linux 2.6系统时间走一秒会慢一秒；外面过了两秒里面只过了一秒。具体解决方案也有:可以修改内核及安装vmware-tools软件包，均麻烦。

下面是我家里的vmware5.5虚拟机(如果不能上外网的话，可以选择内部ntp时间服务器)
①直接用脚本解决不能对时的问题，脚本如下: /root/ntptime.sh
#!/bin/bash
while :
do
/usr/sbin/ntpdate ntp.api.bz >/dev/null 2>&1
sleep 30
done
放入后台执行 nohup sh ntptime.sh & 

②当然还是crontab出马了，在这里注意下脚本与crontab的区别，脚本可以控制到秒，而crontab只能到分 vim /etc/crontab
*/1 * * * * root /usr/sbin/ntpdate ntp.api.bz >/dev/null 2>&1
效果很明显，每隔一分钟，系统自动对时，呵呵。
[root@ltos mail]# tcpdump -v host 192.168.0.154 and 221.130.196.230
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:16:02.359384 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 76) yuhongchun027.com.ntp > 221.130.196.230.ntp: NTPv4, length 48
Client, Leap indicator: clock unsynchronized (192), Stratum 0, poll 4s, precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
   Reference Timestamp: 0.000000000
   Originator Timestamp: 0.000000000
   Receive Timestamp:    0.000000000
   Transmit Timestamp:   3464918162.358386999 (2009/10/19 13:16:02)
     Originator - Receive Timestamp: 0.000000000
     Originator - Transmit Timestamp: 3464918162.358386999 (2009/10/19 13:16:02)
13:16:02.511502 IP (tos 0x0, ttl 49, id 5224, offset 0, flags [none], proto: UDP (17), length: 76) 221.130.196.230.ntp > yuhongchun027.com.ntp: NTPv4, length 48
Server, Leap indicator: (0), Stratum 2, poll 4s, precision -18
Root Delay: 0.158142, Root dispersion: 0.027862, Reference-ID: clock.fmt.he.net
   Reference Timestamp: 3464917189.288964740 (2009/10/19 12:59:49)
   Originator Timestamp: 3464918162.358386999 (2009/10/19 13:16:02)
   Receive Timestamp:    3464918182.209876791 (2009/10/19 13:16:22)
   Transmit Timestamp:   3464918182.209906405 (2009/10/19 13:16:22)
     Originator - Receive Timestamp: +19.851489782
     Originator - Transmit Timestamp: +19.851519405
13:16:02.512579 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 76) yuhongchun027.com.ntp > 221.130.196.230.ntp: NTPv4, length 48
Client, Leap indicator: clock unsynchronized (192), Stratum 0, poll 4s, precision -6
Root Delay: 1.000000, Root dispersion: 1.000000, Reference-ID: (unspec)
   Reference Timestamp: 0.000000000
   Originator Timestamp: 0.000000000
   Receive Timestamp:    0.000000000
   Transmit Timestamp:   3464918162.512529999 (2009/10/19 13:16:02)
     Originator - Receive Timestamp: 0.000000000
     Originator - Transmit Timestamp: 3464918162.512529999 (2009/10/19 13:16:02)
13:16:02.688528 IP (tos 0x0, ttl 49, id 5242, offset 0, flags [none], proto: UDP (17), length: 76) 221.130.196.230.ntp > yuhongchun027.com.ntp: NTPv4, length 48
Server, Leap indicator: (0), Stratum 2, poll 4s, precision -18
Root Delay: 0.158142, Root dispersion: 0.027862, Reference-ID: clock.fmt.he.net

※另外值得注意的是，尽管时间是一件很麻烦的事(还有UTC与GMT、系统时间与硬件时间的区别)，但其实在生产环境中，这件事很简单--服务器投入运行之前必须用crontab对时；如果时间不同步的话是件很麻烦的事，我维护的dovecot服务器经常因为时间问题出问题，还有FreeBSD下的jail虚拟机。所以时间的同步是linux/unix一件非常重要的事情，希望大家注意。