On Thu, Jan 09, 2003 at 03:35:47PM -0500, Paul wrote:
To sync Windows to a Samba server you could use "net time \\servername
/set".
Hrm. Being as I use a Windows machine as an ntpd master at work, I
think it doesn't *need* to use SMB for that... but maybe there's
some add-on package installed for that, beats me.
On Thu, Jan 09, 2003 at 06:58:32PM -0500, eric@lucii.org wrote:
Whoa! I wanted to do this for months (my Linux server clock drifts) but
did not know how. The ntp documentation was completly confusing and did
not do what I wanted.
Whose ntpd documentation is confusing? :^>
Since the Red Hat Linux way has already gone past, here's the NetBSD
version. In /etc/rc.conf, add:
ntpdate=YES
ntpd=YES
Because /etc/rc.d/ntpd requires DAEMON and /etc/rc.d/ntpdate only
requires NETWORKING[1], ntpd won't start till after ntpdate has run
(important, because you can run ntpdate while ntpd is running on the
localhost; they can't both get at the clock at the same time).
Then, in /etc/ntp.conf, add:
server a.b.c.d
server w.x.y.z
restrict default nomodify notrap notrust noserve noquery
restrict a.b.c.d nomodify notrap
restrict w.x.y.z nomodify notrap
If you've got an internal network you want to serve to, you'll want
something like this:
restrict 10.0.0.0 mask 255.0.0.0 notrap noquery
(Adjusted for your network range, of course.)
There's no need for Red Hat's silly step-tickers file, since this:
awk '/^server[ \t]*127.127/ {next} \
/^(server|peer)/ {print $2}' < /etc/ntp.conf
will get you your servers and peers. (/etc/rc.d/ntpdate on NetBSD
does exactly this.)
On Thu, Jan 09, 2003 at 07:55:20PM -0500, Paul wrote:
Does rdate also adjust the system clock to compensate for drift? ntpd,
and chrony I believe, not only sync clocks, but they also make the clock
more accurate.
No, rdate is a less secure, less reliable system than ntpd, and it
only sets your clock once.
chrony, though I've never used it, looks to be a little more
user-friendly than traditional ntpd, allowing you to force a specific
time in without stopping the daemon (though, having never had ntpd
go *awry*, I don't feel much of a need for that... but I also can't
imagine living comfortably with my computers on anything but an
always-on line, so...).
Although... does chrony induce gradual skew the way that ntpd does?
There are some very good reasons (think log files and computer
forensics; think cron-scheduled jobs) that you don't want times
jumping abruptly all over the place on your systems.
On Thu, Jan 09, 2003 at 08:19:26PM -0500, Chris Hedemark wrote:
==== /etc/ntp.conf ====
driftfile /etc/ntp/drift
server ntp1.unc.edu
server ntp2.unc.edu
==== end ====
==== /etc/ntp/step-tickers ====
ntp1.unc.edu ntp2.unc.edu
==== end ====
That's maybe Red Hat-specific. That is, other operating systems
for sure and distributions probably won't know to go looking for
/etc/ntp/step-tickers, and ntpd only does on Red Hat because of
the way /etc/rc.d/init.d/ntpd is written. To whit (comments and
reporting removed for brevity):
start() {
if [ -s /etc/ntp/step-tickers ]; then
/usr/sbin/ntpdate -s -b -p 8 -u \
`/bin/sed -e 's/#.*//' /etc/ntp/step-tickers`
[...]
If you're going to sed(1)-out comments anyway, you may as well just
go with NetBSD's awk version to process /etc/ntp.conf. It's not
making it easier on users to have to go find another file (rather
than just flip a switch) to have ntpdate do it's thing, which you
almost invariably want (see Chris's good explanation of why).
Incidentally, if you put disparate things in /etc/ntp/step-tickers
and for servers in /etc/ntp.conf, expect to have trouble for that
same reason.
In theory, grappa.eclipsed.net (66.92.234.100) should be willing to
serve to anyone looking for a decently synchronized ntp server. In
practice, I'm pretty sure I still default to refusing to serve. But
if you'd like ntpd to work on your home systems and you can't find a
publicly available server (or want another data point, which is a
good idea), let me know (privately, please) and I'll be glad to
set you up as a client or a peer of grappa.
[1] For more on the NetBSD rc.d system and why it's cool--hrm,
maybe I should just do a PLUG presentation on this--see
http://www.netbsd.org/Documentation/rc/.