On 4/13/2011 2:50 PM, Cal Webster wrote: > > You don't say what version of ntp you are using or whether the system in > question can access the Internet. > > Should be: ntp-4.2.2p1-9.el5.centos.2.1.i386 > > > [Refs] > > http://www.ntp.org/ > http://support.ntp.org/bin/view/Support/WebHome > http://www.eecis.udel.edu/~mills/ntp/html/index.html > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/s1-dateconfig-ntp.html > /usr/share/doc/ntp-<version>/ntpd.htm > > > [Main config files] > > /etc/ntp.conf > /var/lib/ntp/drift > /etc/ntp/step-tickers > > > [Time Sources] > > Three time sources you can use for your ntpd: > > 1. Public or corporate NTP servers > > If you have an Internet connection using a public ntp pool is the > simplest. > > http://www.pool.ntp.org/en/use.html > > 2. An accurate external reference clock > > http://doc.ntp.org/4.2.0/refclock.html > > Use if you need microsecond or better accuracy and you've got time and > money to setup. > > 3. Undisciplined local clock on a local computer > > http://doc.ntp.org/4.2.0/drivers/driver1.html > > This is what I use. You can use this if a few seconds off every few > months is less important than all clients being in sync. If it drifts at > least all clients will drift with it. You can compensate easily for > minor drift too. > > As long as all clocks are synced to the same source you should be able > to tolerate being off by even a few minutes from the "real" time. Some > networked services such as Kerberos cannot tolerate differences in time > stamps between client and server. You'll get lots of seemingly arbitrary > faults and errors with AD Windows Domains and Linux-based directory > authentication and such if all participants are not time-synced. > > > > Sounds like you're using your system clock. > > Here's how my isolated networks are configured: > > [Primary server] > > Machine with most stable system clock - uses system clock, compensating > for calculated drift in /var/lib/ntp/drift. > > [Secondary servers] > > One main RHEL/CentOS server in each of 3 buildings uses primary ntp > server as master and sister servers as peers. > > [Clients] > > CentOS, Windoze DC, Windows stand-alone, and Unix configured to sync > with secondary ntp servers using the closest first. > > > > [Using undisciplined system clock] > > > Best way to determine most stable clock is to: > > 1. turn ntpd off > 2. Sync time with accurate server > I use http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/ > 3. Wait days or weeks to check system time against same source > 4. Calculate and set drift > 5. Start ntpd > 6. Check against same time source periodically... every few weeks at > first until it's as close as you can get it. > 7. Adjust frequency offset and drift values for local (system) clock > 8. Start ntpd and use this as "server" in secondary servers. > > Sync secondary servers or just clients off this primary. > > > > > There are many ways to configure and implement ntp. You should study the > references and determine which options are best for your specific needs. > > > If you wish I can provide sample ntp.conf files, and details of my > calibration process. I'm kind of busy right now but I'll throw something > together as time permits and forward if you want. > > ./Cal > > > > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > The ntp server does connect to the internet fine. the version of ntp is as follows. ntp-4.2.2p1-9.el5.centos.2.1 The time is not off by a matter of minutes or I would not crab so much. It gets to the point of being more then an hour off after setting it. And also Dovecot dies after setting the tuime so much. As I had posted before, I never had any issue with the sync till I updated to 5.6. And whe I rolled it back to the old kernel time and sync went along flawlessly. Brian. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6022 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.centos.org/pipermail/centos/attachments/20110413/ad53fa59/attachment-0005.p7s>