Date: Fri, 21 Aug 2015 08:51:08 +0200 From: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: Will 10.2 also ship with a very stale NTP? Message-ID: <55D6CA5C.1090905@omnilan.de> In-Reply-To: <1440110060.242.252.camel@freebsd.org> References: <20150710235810.GA76134@rwpc16.gfn.riverwillow.net.au> <20150712032256.GB19305@satori.lan> <20150712050443.GA22240@server.rulingia.com> <20150712154416.b9f3713893fe28bfab1dd4d7@dec.sakura.ne.jp> <CAGMYy3vKEUCD=Ssxt%2B2Vny4eQ7CNQHTxNKncyQnRk5dPQU6ZtA@mail.gmail.com> <20150712184910.2d8d5f085ae659d5b9a2aba0@dec.sakura.ne.jp> <1436715703.1334.193.camel@freebsd.org> <55B23B4E.1080400@omnilan.de> <1440110060.242.252.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55D6CA5C.1090905>