From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 20:56:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D73AB16A41F for ; Tue, 11 Oct 2005 20:56:32 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA5D843D62 for ; Tue, 11 Oct 2005 20:56:27 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9BKuQn1014660; Tue, 11 Oct 2005 13:56:27 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9BKuQ8v014659; Tue, 11 Oct 2005 13:56:26 -0700 Date: Tue, 11 Oct 2005 13:56:26 -0700 From: Brooks Davis To: Joshua Coombs Message-ID: <20051011205626.GA13461@odin.ac.hmc.edu> References: <434BCDF6.3090303@samsco.org> <434BEC96.4050801@samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 6.0-RC1 available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2005 20:56:33 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 11, 2005 at 01:39:10PM -0400, Joshua Coombs wrote: >=20 > "Scott Long" wrote in message=20 > news:434BEC96.4050801@samsco.org... > >Joshua Coombs wrote: > > > >>Given that we're in the RC stage, is it too late to get a PR=20 > >>stuffed in to correct ntpd/ntpdate behavior in /etc/rc.d? > >> > >>Joshua Coombs > >> > > > >Depends on the kind of problem that you are seeing. Any details? > > > >Scott >=20 > Two issues I spotted. >=20 > First, ntpdate is still being used, despite it being marked as=20 > depreciated for quite some time. The preferred replacement is to call=20 > ntpd with the -q switch. This causes ntpd to match ntpdate's=20 > behavior, it sets the time, and then exits with a status code=20 > indicating success or failure. >=20 > Second, when ntpdate, or what ever is set in ntpdate_program is=20 > called, there is an IP appended to the end of the arguments, which is=20 > not controlled by ntpdate_flags. This means you cannot setup ntpd -q=20 > to be used in place of ntpdate without editing the ntpdate rc.d script=20 > or creating a new one, a regression from 4.x's setup. >=20 > I see some effort was put into the new ntpdate rc.d script, having it=20 > pull potential servers from /etc/ntp.conf rather than require the user=20 > specify one in rc.conf using ntpdate_flags. ntpd called with -q uses=20 > the ntp.conf server entries automatically, so the extra work by the=20 > rc.d script isn't required if we switch to ntpd -q in place of=20 > ntpdate. >=20 > I was going to work up a tweaked ntpdate rc.d script that included a=20 > new option, ntpdate_use_ntpd, that when set, would use the preferred=20 > practice of calling ntpd -q after verifying a valid ntp.conf exists.=20 > If one isn't present, I was going to have it throw a warning, and=20 > reference an example conf using pool.ntp.org servers to get baseline=20 > time established. The ntpd rc.d script would receive the same check,=20 > the example conf would lock ntpd down such that it would only operate=20 > as a client for the local machine, and not act as a server for=20 > external hosts, or respond to external ntp query/command/conf=20 > requests. >=20 > Unfortunately, I'm getting into this rather late, I just moved my 386=20 > to 6.0b5 this weekend, hence my tardiness discovering ntpdate still in=20 > use in later releases of FreeBSD. I would like to see the correct=20 > behavior implemented for release, but if I'm beyond the deadline for=20 > this level of change, I'll accept that and work on making it the norm=20 > for 6.1. Since this is a matter of mostly pedantic correctness, I can't see risking the release on these changes. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDTCb6XY6L6fI4GtQRApNQAJ9fNYj27SXEy6MH/RrkFPaNCSrVrwCg1GbQ MG7tlmaLhIpRR/DLnspJlxg= =p6GL -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW--