[nycbug-talk] sys/systm.h

[Jesse Callaway]

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.
>
> ntpd.conf
> -----8<-----
> 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
> -----8<-----
>
>
> With all this together I've not gotten the whole damn thing to work
> smoothly.
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
>
>

Hey,

Thanks all. The "system" clock updates pretty quickly given there is
network access.

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 ; )

-jesse

-jesse