This was recently posted at Novell Cool Solutions:
Over the past few months I noticed some of our NW 6.5 servers (eDir 8.7.3.3) would lose timesync. We have one reference (gets time via NTP over Internet) and two primary time servers. These 3 servers always appear to be in sync with each other.
The problem is with some of the secondary NW 6.5 servers. If I look at the timesync debug screen on some of these servers they may be several seconds (8 to 10 or more) out of sync. Restarting timesync will fix it but it may drift out again after several hours. I found that if I switched from using NTP (:123) in timesync.cfg to just using the IP address, time stays in sync without a problem. This is a workaround for now, but we would prefer to standardize on NTP for all time synching.
Solution
Two of our Forum experts contributed some practical suggestions on the topic, as follows:
Expert 1: On NetWare 6.5 Sp3 and above if you want to use NTP, use XNTPD.NLM instead of Timesync. You can make this happen automatically by editing TIMESERV.NCF and remming-out the LOAD TIMESYNC line and un-remarking the LOAD xntpd line.
You also need to edit /etc/ntp.conf to point it at the proper NTP server(s).
Expert 2: Here are some common gotcha's of timesync ...
* In Monitor > Server parameters > Time, make sure you have "Default Time Server Type" and "TimeSync Type" both set to the exact same thing.
* Set "Configured Sources" to "on" and theIP address with port 123, followed by a semi-colon.
* Make sure the NTP client can hit the NTP server's port 123 (nmap can tell easily, or at least I like it best)?
* Verify that RADIUS is set to just port 2000.
I have twice seen cases where the hardware clock was nuts. In both cases, we watched them rush ahead of real-world time when we disabled timesync and watched the time source and the bad box simultaneously (via rconj, freecon, whatever). That doesn't happen often, but it may be something to check.
No comments:
Post a Comment