From owner-freebsd-current@FreeBSD.ORG Tue Oct 11 17:45:54 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 6ED8416A41F for ; Tue, 11 Oct 2005 17:45:54 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B85E143D45 for ; Tue, 11 Oct 2005 17:45:53 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EPO8Y-0001xH-SY for freebsd-current@freebsd.org; Tue, 11 Oct 2005 19:42:03 +0200 Received: from murdoc.gwi.net ([207.5.142.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Oct 2005 19:42:02 +0200 Received: from jcoombs by murdoc.gwi.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 11 Oct 2005 19:42:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: "Joshua Coombs" Date: Tue, 11 Oct 2005 13:39:10 -0400 Lines: 56 Message-ID: References: <434BCDF6.3090303@samsco.org> <434BEC96.4050801@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: murdoc.gwi.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: news 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 17:45:54 -0000 "Scott Long" wrote in message news:434BEC96.4050801@samsco.org... > Joshua Coombs wrote: > >> Given that we're in the RC stage, is it too late to get a PR >> 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 Two issues I spotted. First, ntpdate is still being used, despite it being marked as depreciated for quite some time. The preferred replacement is to call ntpd with the -q switch. This causes ntpd to match ntpdate's behavior, it sets the time, and then exits with a status code indicating success or failure. Second, when ntpdate, or what ever is set in ntpdate_program is called, there is an IP appended to the end of the arguments, which is not controlled by ntpdate_flags. This means you cannot setup ntpd -q to be used in place of ntpdate without editing the ntpdate rc.d script or creating a new one, a regression from 4.x's setup. I see some effort was put into the new ntpdate rc.d script, having it pull potential servers from /etc/ntp.conf rather than require the user specify one in rc.conf using ntpdate_flags. ntpd called with -q uses the ntp.conf server entries automatically, so the extra work by the rc.d script isn't required if we switch to ntpd -q in place of ntpdate. I was going to work up a tweaked ntpdate rc.d script that included a new option, ntpdate_use_ntpd, that when set, would use the preferred practice of calling ntpd -q after verifying a valid ntp.conf exists. If one isn't present, I was going to have it throw a warning, and reference an example conf using pool.ntp.org servers to get baseline time established. The ntpd rc.d script would receive the same check, the example conf would lock ntpd down such that it would only operate as a client for the local machine, and not act as a server for external hosts, or respond to external ntp query/command/conf requests. Unfortunately, I'm getting into this rather late, I just moved my 386 to 6.0b5 this weekend, hence my tardiness discovering ntpdate still in use in later releases of FreeBSD. I would like to see the correct behavior implemented for release, but if I'm beyond the deadline for this level of change, I'll accept that and work on making it the norm for 6.1. Joshua Coombs