bonsaime at gmail.com
Mon Apr 27 19:23:41 EDT 2009
On Mon, Apr 27, 2009 at 5:14 PM, Miles Nordin <carton at ivy.net> wrote:
>>>>>> "ms" == Marco Scoffier <marco at metm.org> writes:
> ms> trying to figure out how to do the same on FreeBSD and it was
> ms> non-obvious...
> rdate works with a simple server built into inetd
> ntpdate works with ntp servers but cannot be run while ntpd is
> running. FreeBSD ships with init scripts to run it automatically
> before ntpd.
> the -g option of ntpd avoids the bashfulness you describe and thus the
> need for ntpdate, but was buggy on some versions of ntpd in my
> experience. in /etc/rc.conf:
> ntpd_enable="YES" ntpd_flags="-g"
> or the rather silly but equivalent:
> ntpd_enable="YES" ntpd_sync_on_start="YES"
> ntpd also has problems if bind is not available when it starts. It's
> supposed to spawn a thread to keep retrying the lookups in the
> background and reconfigure ntpd over the ntpdc command channel when
> nameservice becomes available, but there are two problems with this:
> * I can't confirm -g continues to work in that case. -g is supposed
> to apply once, at boot, but preserve sanity checking for
> whacked-out servers after boot. You can see how a naive
> implementation would mess this up.
> * ntpd uses UDP and needs to control its source address, so it binds
> to individual interfaces. If not all your interfaces are up before
> ntpd starts, that's a problem. bind has code to watch the routing
> socket and rebind interfaces that appear, but often gets fucked up
> because of privilege dropping.
> * if you try to ``lock down'' your ntpd by enabling all kinds of
> fancy security, you'll deny access to the background DNS process.
> You have to allow passwordless admin access to 127.0.0.1 for the
> background dns resolver trick to work.
> restrict default nomodify
> restrict 127.0.0.1 # no restrictions. needs 'modify' permission
> # so ntpd_initres works.
> restrict 192.168.2.1 nomodify notrust nopeer #untrusted ci$co client
> With all this together I've not gotten the whole damn thing to work
> talk mailing list
> talk at lists.nycbug.org
Thanks all. The "system" clock updates pretty quickly given there is
Anyway, like I said it's all about setting the *hardware* clock so
that it keeps time between boots. Supposedly this just gets set
magically when the system clock gets updated. Now, I noticed that I
don't have an nvram special device file and I wonder if this has
something to do with the issue. I'll take a look and let everyone know
what I come up with.
It's running on a G4 system, so there might be something funny with
the CMOS writeability. The hardware is considered Tier 2 in FreeBSD...
maybe it's time to throw OpenBSD on it.... or Debian ; )
More information about the talk