RE: -EXT-Re: [chrony-users] Using symbolic network names in /etc/chrony.conf file?

[ Thread Index | Date Index | More Archives ]

OK, The point was that  I was hoping that there was some way of using a
symbolic network name and variable netmask (CIDR) instead of hard coding raw
IP addresses in an allow statement.

Any ideas on how this could be done in a chrony.conf file?


-----Original Message-----
From: Bill Unruh [mailto:unruh@xxxxxxxxxxxxxx] 
Sent: Monday, July 24, 2017 2:06 PM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx
Subject: -EXT-Re: [chrony-users] Using symbolic network names in
/etc/chrony.conf file?

William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324 UBC,
Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx Canada V6T
1Z1 ____|____ and Gravity ______|_

On Mon, 24 Jul 2017, Parker, Michael D. wrote:

> The chrony allow directive allows the addition of a symbolic hostname 
> in its specification. However, I took a leap in entering the following
> allow hostname/16
> which failed to do what I expected but no configuration file error was 
> flagged. If hostname is, my expectation was that the allow
statement would apply to the entire 10.10.x.x network.

That is not how a netmask ever works. If you have IP/n That means you have a
netmask with the first n bits 1 and the rest 0. Another ip passes if ip AND
netmask equals IP. 
But your example IT has 10.10 as the lower 32-16 bits. and ip AND ALWAYS has the lower 16 bits equal to 0.0 and can never have
them equal 10.10

Had you used it might well have worked. but can
never ever be satisfied by any address.

> In this context, apparently the '/16' is ignored. Is there some way 
> that I could put basically a symbolic name in the /etc/chrony.conf file
instead of IP numbers in a network context? The documentation gives no hint
if this is possible.
If the hostnameip AND netmask=hostnameip then it would have a chance. Now I
do not know if chrony accepts  hostname/n as a valid network spec, but it
would have to obey the above if it were to work.



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Mail converted by MHonArc 2.6.19+