From owner-freebsd-stable@freebsd.org Thu Aug 20 22:34:28 2015 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E2DE9BEA5C for ; Thu, 20 Aug 2015 22:34:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74ED4181C for ; Thu, 20 Aug 2015 22:34:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 20 Aug 2015 22:31:17 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t7KMYKc7007279; Thu, 20 Aug 2015 16:34:20 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1440110060.242.252.camel@freebsd.org> Subject: Re: Will 10.2 also ship with a very stale NTP? From: Ian Lepore To: Harald Schmalzbauer Cc: freebsd-stable@freebsd.org Date: Thu, 20 Aug 2015 16:34:20 -0600 In-Reply-To: <55B23B4E.1080400@omnilan.de> References: <20150710235810.GA76134@rwpc16.gfn.riverwillow.net.au> <20150712032256.GB19305@satori.lan> <20150712050443.GA22240@server.rulingia.com> <20150712154416.b9f3713893fe28bfab1dd4d7@dec.sakura.ne.jp> <20150712184910.2d8d5f085ae659d5b9a2aba0@dec.sakura.ne.jp> <1436715703.1334.193.camel@freebsd.org> <55B23B4E.1080400@omnilan.de> Content-Type: text/plain; charset="iso-2022-jp" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 22:34:28 -0000 On Fri, 2015-07-24 at 15:19 +0200, Harald Schmalzbauer wrote: > Bezglich Ian Lepore's Nachricht vom 12.07.2015 17:41 (localtime): > > And let's all just hope that a week or two of testing is enough when > > jumping a major piece of software forward several years in its > > independent evolution. > … > > I wonder how many other such things could be lurking in 4.2.8, waiting > > to be triggered by other peoples' non-stock configurations? We've > … > > I'd like to report one, most likely an upstream problem: > > 'restrict' definitions in ntp.conf(5) no longer work with unqualified DNS names. > A line like > "restrict time1 nomodify nopeer noquery notrap" > results in: > ntpd[1913]: line 7 column 7 syntax error, unexpected T_Time1 > ntpd[1913]: syntax error in /etc/ntp.conf line 7, column 7 > > I've always been using unqualified hostnames with 'restrict', and since defining 'server' with unqualified hostname still works, this seems to be a significant bug to me. People are forced to change 'restrict' definitions, but not to also change other unqualified definitions, which potentially leads to misconfigurations, since intentionally matching definitions can now differ easily. > > Has anybody already noticed this problem? And any idea if upstream is aware? I had a quick look at this today. It appears that the problem isn't unqualified names exactly, but rather an unqualified name that exactly matches an ntp.conf keyword will be mistaken by the ntpd config parser as a misplaced keyword token. So most unqualified names should work, but there are about 200 words that won't, many of them very sensible names for ntp servers such as "ntp" and "time1" and "time2". When I look at the ntp_parser.y grammar file it's not clear to me why "server time1" works and "restrict time1" doesn't. I couldn't find any way to trick it into taking a keyword as a hostname following restrict (like using quotes). You might be able to work around it using the new "restrict source" syntax that applies the restrictions to every server association that doesn't have a more-explicit matching restrict line. -- Ian