From owner-freebsd-stable@freebsd.org Fri Aug 21 06:51:21 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 B207F9BD2E4 for ; Fri, 21 Aug 2015 06:51:21 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40BB3111B; Fri, 21 Aug 2015 06:51:20 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t7L6pG7l068165; Fri, 21 Aug 2015 08:51:16 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id B9941DA3; Fri, 21 Aug 2015 08:51:15 +0200 (CEST) Message-ID: <55D6CA5C.1090905@omnilan.de> Date: Fri, 21 Aug 2015 08:51:08 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian Lepore CC: freebsd-stable@freebsd.org Subject: Re: Will 10.2 also ship with a very stale NTP? 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> <1440110060.242.252.camel@freebsd.org> In-Reply-To: <1440110060.242.252.camel@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCB2977B8C68622885D2EF53B" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 21 Aug 2015 08:51:16 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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: Fri, 21 Aug 2015 06:51:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB2977B8C68622885D2EF53B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Ian Lepore's Nachricht vom 21.08.2015 00:34 (localtime): > 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. >> =E2=80=A6 >>> I wonder how many other such things could be lurking in 4.2.8, waitin= g >>> to be triggered by other peoples' non-stock configurations? We've >> =E2=80=A6 >> >> 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 sinc= e defining 'server' with unqualified hostname still works, this seems to = be a significant bug to me. People are forced to change 'restrict' defini= tions, but not to also change other unqualified definitions, which potent= ially leads to misconfigurations, since intentionally matching definition= s 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). Thank you very much! This is very interesting and exactly matches my tested host names. I wish I had better C skills to find such things myself. Out of curiosity: How much time took it to find the ntp_parser.y route? (and with what =E2=80=9CIDE=E2=80=9D =E2=80=93 I'm stuck with vim) One additional observation was that the reserved-name-collision only happens with CNAME records. I hope I'll find some time to actually do look into sources - which I didn't at first hand because of my lousy C skills :-( But that's the place where to find hints :-) Thanks, -Harry --------------enigCB2977B8C68622885D2EF53B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlXWymIACgkQLDqVQ9VXb8izkACgqH7RX8BfsCnk1zAqT0avnqWs TdMAoNBFKTFFkAQY3inDeCBLlQeSmA60 =zVyk -----END PGP SIGNATURE----- --------------enigCB2977B8C68622885D2EF53B--