Quick NTP question
Quick NTP question
(OP)
HI,
If I set up my Solaris box (8, 9, or 10) as an NTP client (Copying ntp.client to ntp.conf) will it "ask" the servers listed or will it just sit and wait for broadcasts? The servers are Internet based.
so my entries are
server IP Address
server IP Address
Thanks,
If I set up my Solaris box (8, 9, or 10) as an NTP client (Copying ntp.client to ntp.conf) will it "ask" the servers listed or will it just sit and wait for broadcasts? The servers are Internet based.
so my entries are
server IP Address
server IP Address
Thanks,
RE: Quick NTP question
Once that completes then xntpd will take over the port/socket and sit and wait for a broadcast from the NTP servers.
Depending on what other settings you have configured the time will be slewed up or down over a period to keep your time in sync.
IHTH
Laurie.
RE: Quick NTP question
However the default configuration is often to "slew" the time to correct it, which will be too slow to the naked eye; it's often best to manually "step" the time to correct it initially using ntpdate -b <ntpserverIP>. It's also a good way to make sure your NTP server is contactable and sane.
Annihilannic
tgmlify - code syntax highlighting for your tek-tips posts
RE: Quick NTP question
Thanks for the input.
Was wondering if it would be better to use ntpdate in a cron job or not.
RE: Quick NTP question
I should qualify what I said ealier about "asking"... that is usually the default configuration. It can be also set up to listen to broadcasts as Laurie described, but that is not a configuration I have encountered.
Annihilannic
tgmlify - code syntax highlighting for your tek-tips posts
RE: Quick NTP question
Obviously if the "client server" is a dB then the last thing you want is to be jumping back and forward with a cron task running ntpdate so as Annihilannic has indicated the preferable way is allowing the ntpd daemon to work its magic.
I spent weeks studying as much NTP documentation as I could before eventually getting a good ntpd (cluster) config that worked for us. Basic set-up is always simple but as we know nothing in our business is ever basic (well not for long).
Laurie.
RE: Quick NTP question
What I really need to know is does it (the daemon) really sit and passively wait for a broadcast packet after initially "asking" on startup?
If so then it seems running ntpdate at intervals would be the solution? The servers I manage are spread out around world and are only ever off by 5-10 minutes, in most cases, when I think to look a couple times a year. So really this isn't that big a deal but I still want the "right" set up.
I've seen posts about folks setting their servers to be an ntp server instead of a client even though it doesn't serve anything but itself.
RE: Quick NTP question
So for cluster (and similar for stand-alone's) this is the key config of my ntp conf ..
CODE --> example
#
# The local (undisciplined Solaris) clock is identified as 127.127.1.0.
#
# Some type of primary clock is important; but, it does not have
# to be the local kernel clock.
#
server 127.127.1.0
fudge 127.127.1.0 stratum 13
server dmz_timeserver01
server dmz_timeserver02
peer clusternode1-priv prefer
peer clusternode2-priv
peer fred_cpu_1_oam
peer fred_cpu_3_oam
peer fred_cpu_4_oam
# enable monitoring functions
enable monitor
#
# Drift file (optional)
#
driftfile /var/ntp/ntp.drift
# Stats (optional)
statsdir /var/ntp/ntpstats
I can do a test with snoop to confirm if the client is just waiting from broadcasts after the initial fetch but I'm on a day off so don't have direct access to my labs right now, but you may wish to do the same? Also if you do set up peers then you can watch your
CODE --> command
To be continued ......
Laurie