Bez?glich 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?> On Sun, 2015-07-12 at 18:49 +0900, Tomoaki AOKI wrote: >> Wow! Thanks for your time and quick response. >> I'm looking forward to seeing it MFCed. :-) >> >> On Sun, 12 Jul 2015 08:56:26 +0000 >> Xin LI <delphij at gmail.com> wrote: >> >>> I've spent some time on the MFC, the testing would still take some time >>> (likely a day or two) and once that's finished I'll ask re@ for approval.Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150724/d121b903/attachment.bin>
Bez?glich Harald Schmalzbauer's Nachricht vom 24.07.2015 15:19 (localtime):> Bez?glich 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 7That report is not entirely true, sorry! It's only the case if the unqualified hostname is of type CNAME. With A or AAAA records, the problem doesn't occur. ?> Has anybody already noticed this problem? And any idea if upstream is aware?Any hints who to contact best? Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150724/759342c3/attachment.bin>
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