On Fri, Apr 17, 2009 at 03:07:44PM -0400, Brian Utterback wrote: > >> /usr/lib/inet/ntpd Uncomitted NTP daemon > >> /usr/lib/inet/ntp-wait Project Private > >> /usr/sbin/ntpdate Volatile > > > >The manpages for NTP in Solaris now don't state interface stability. > > I thought that they should. If that is not the convention, then I can > remove them.
What I meant is that I looked at ntpdate(1M) and no stability attribute was listed. Therefore I'd assume it should be Committed. > > > >But it seems to me that it's all as if Committed. ntpdate(1M) in > >particular is quite useful, though I see that its main use is being > >subsumed into the ntp service via the config/wait_for_sync property, I > >think. > > Correct, we have treated them as being largely committed. I don't > expect this to change, per se, but since I intend to track the > community, I didn't want to formally lock in. In particular, several > of the existing commands are deprecated by the NTP project and may be > removed at a future date. These are ntpdate and ntpdc. The > functionality of ntpdate is being subsumed by ntpd itself, which now > has a "ntpdate" mode. This mode is not a complete replacement yet, but > that is the goal. Until then, ntpdate will continue to be delivered. Oh, I see, ntpdate has been deprecated. The perhaps you should make it Committed Obsolete rather than Volatile. > Also, the ntpdc (xntpdc) command is likewise having its feature set > folded into the ntpq command. Not all the functions are there yet, but > again, that is the goal. See above. > The ntpdate program is no longer called from the service startup > method. The ntpdate program, while useful was also a bit of a security > hole. It does not support most of the newer authentication methods > added in version 4, and it is very susceptible to getting the wrong > time from a single bad server. The ntpd program has a mode that allows > it to correct a very large offset once at startup just as ntpdate > always does. Plus, the new iburst option to the server line allows > ntpd to synchronize in seconds (like ntpdate) instead of the 5 minutes > it used to require. These two features make the use of ntpdate during > startup unnecessary. Ah, excellent. Thanks. > >Will there be a link for 'xntpdc'? Or does that just go away? > > We could, but it would be simpler to have it just "go away" since that > is what the community delivers now, and has for 11 years. Doesn't that require starting the EOF process? Wouldn't it be easier to add a link and mark it Committed Obsolete? Or is xntpdc different from ntpdc? > >I wonder if it wouldn't be better to have a separate SMF service for > >doing an ntpdate early at boot time (say, svc:/network/ntpdate:default), > >with svc:/network/ntp:default having an optional dependency on the > >former. > > As I explained above, that is no longer necessary. In addition, the > ntpd program now has a feature to retry hostname look-ups that fail > during initialization, so the need to wait for the naming service is > also no longer a problem. So, ntp can now start very early without > difficulty. This will make interaction with Secure DNS easy. Right, thanks. Nico --
