Re: [Dnsmasq-discuss] Always Ignore Client Identifier

2014-02-11 Thread Simon Kelley

On 08/02/14 17:42, Linux Luser wrote:

dhcp-ignore-clid might just work for the long-term. But I ended up
playing around a bit more and I've managed to isolate the part of my
config that I believe triggers the problem. Maybe this can be fixed
without a dhcp-ignore-clid option?

When I set a host's MAC address and IP association in /etc/ethers (with
the read-ethers option on of course) and that same host's IP address to
hostname association in /etc/hosts, I am able to get a consistent IP,
whether or not that same host is using PXE boot, the Debian installer
(where it send the vendor-id as d-i, which shouldn't matter in this
case) or boots to its own image on the drive. It is consistent, that is,
until I implement a trick that I wanted to use so I could whitelist
hosts for PXEboot. That's when it got inconsistent and I would end up
with a brand new IP address for PXE and usually another brand new one
when the host boot into it's own OS. I could only get the IP that I had
set in /etc/ethers if I restarted dnsmasq on the server. Otherwise the
host would receive the same WRONG IP over and over for each renewal.

Here's the config I had BEFORE implementing a PXEboot whitelist:

domain-needed
bogus-priv
log-dhcp

domain=mydomain
local=/mydomain/
server=8.8.8.8
server=8.8.4.4

interface=eth0
except-interface=eth1

expand-hosts
read-ethers

dhcp-range=tag:known,set:controller,10.1.0.1,10.1.255.254,2h
dhcp-range=tag:known,set:device,10.2.0.1,10.2.255.254,2h
dhcp-option=option:router,10.0.0.1

enable-tftp
tftp-root=/tftpboot
dhcp-boot=pxelinux.0


Now, I'll add the lines which allow me to use a directory of files for
dhcp-host commands:

dhcp-vendorclass=pxe,PXEClient
dhcp-ignore=tag:pxe,tag:!install
dhcp-hostsfile=/etc/dnsmasq-hosts.d


Inside of /etc/dnsmasq-hosts.d then I can put files that contain lines
like this one:

01:02:03:04:05:06,set:install

... and send a SIGHUP to dnsmasq process. After this, the host with that
MAC address gets the tag install and instead of ignoring PXEboot,
dnsmasq will respond for that host. Wonderful! Problem: now I'm getting
wildly different MAC addresses. It's like dnsmasq is reading the files
in /etc/dnsmasq-hosts.d and ignoring the /etc/ethers file. Is this
expected behavior? A bug? I know that specifying a DIRECTORY instead of
a file for the dhcp-hostsfile is kind of a new feature. (For my
purposes, I'd prefer a directory because it's possible that several
processes might want to write files at the same time. It's easy to avoid
concurrency problems by putting files with unique names in a directory
(named after MAC or hostname or UUIDs, etc).)




My guess is that dnsmasq is failing to integrate the information from 
/etc/ethers and the dnsmasq-host.d file into a single coherent record. 
There are various heuristics in the code to do that for common 
situations, but since there no real primary key, it difficult to do it 
generally. Do you merge the settings for a MAC address. for and IP 
address, for a hostname?


The simplest solution is probably to abandon /etc/ethers, and put all 
the information in one place in the files in /etc/dnsmasq-hosts.d  It;s 
fine to keep what you have and add IP addresses and/or hostnames to that.


 01:02:03:04:05:06,set:install,1.2.3.4

Cheers,

Simon

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Always Ignore Client Identifier

2014-02-11 Thread Linux Luser
That makes sense. I may just do that. Since /etc/ethers and
/etc/dnsmasq-hosts.d would both be reread upon a SIGHUP signal, it seems
that there wouldn't be much of a difference either way, other than, as you
say, one way is more confusing than another.

Thanks again!
On Feb 11, 2014 5:36 AM, Simon Kelley si...@thekelleys.org.uk wrote:

 On 08/02/14 17:42, Linux Luser wrote:

 dhcp-ignore-clid might just work for the long-term. But I ended up
 playing around a bit more and I've managed to isolate the part of my
 config that I believe triggers the problem. Maybe this can be fixed
 without a dhcp-ignore-clid option?

 When I set a host's MAC address and IP association in /etc/ethers (with
 the read-ethers option on of course) and that same host's IP address to
 hostname association in /etc/hosts, I am able to get a consistent IP,
 whether or not that same host is using PXE boot, the Debian installer
 (where it send the vendor-id as d-i, which shouldn't matter in this
 case) or boots to its own image on the drive. It is consistent, that is,
 until I implement a trick that I wanted to use so I could whitelist
 hosts for PXEboot. That's when it got inconsistent and I would end up
 with a brand new IP address for PXE and usually another brand new one
 when the host boot into it's own OS. I could only get the IP that I had
 set in /etc/ethers if I restarted dnsmasq on the server. Otherwise the
 host would receive the same WRONG IP over and over for each renewal.

 Here's the config I had BEFORE implementing a PXEboot whitelist:

 domain-needed
 bogus-priv
 log-dhcp

 domain=mydomain
 local=/mydomain/
 server=8.8.8.8
 server=8.8.4.4

 interface=eth0
 except-interface=eth1

 expand-hosts
 read-ethers

 dhcp-range=tag:known,set:controller,10.1.0.1,10.1.255.254,2h
 dhcp-range=tag:known,set:device,10.2.0.1,10.2.255.254,2h
 dhcp-option=option:router,10.0.0.1

 enable-tftp
 tftp-root=/tftpboot
 dhcp-boot=pxelinux.0


 Now, I'll add the lines which allow me to use a directory of files for
 dhcp-host commands:

 dhcp-vendorclass=pxe,PXEClient
 dhcp-ignore=tag:pxe,tag:!install
 dhcp-hostsfile=/etc/dnsmasq-hosts.d


 Inside of /etc/dnsmasq-hosts.d then I can put files that contain lines
 like this one:

 01:02:03:04:05:06,set:install

 ... and send a SIGHUP to dnsmasq process. After this, the host with that
 MAC address gets the tag install and instead of ignoring PXEboot,
 dnsmasq will respond for that host. Wonderful! Problem: now I'm getting
 wildly different MAC addresses. It's like dnsmasq is reading the files
 in /etc/dnsmasq-hosts.d and ignoring the /etc/ethers file. Is this
 expected behavior? A bug? I know that specifying a DIRECTORY instead of
 a file for the dhcp-hostsfile is kind of a new feature. (For my
 purposes, I'd prefer a directory because it's possible that several
 processes might want to write files at the same time. It's easy to avoid
 concurrency problems by putting files with unique names in a directory
 (named after MAC or hostname or UUIDs, etc).)



 My guess is that dnsmasq is failing to integrate the information from
 /etc/ethers and the dnsmasq-host.d file into a single coherent record.
 There are various heuristics in the code to do that for common situations,
 but since there no real primary key, it difficult to do it generally. Do
 you merge the settings for a MAC address. for and IP address, for a
 hostname?

 The simplest solution is probably to abandon /etc/ethers, and put all the
 information in one place in the files in /etc/dnsmasq-hosts.d  It;s fine to
 keep what you have and add IP addresses and/or hostnames to that.

  01:02:03:04:05:06,set:install,1.2.3.4

 Cheers,

 Simon

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Always Ignore Client Identifier

2014-02-08 Thread Linux Luser
Correction: I'm getting wildly different IP addresses not wildly
different MAC addresses.


On Sat, Feb 8, 2014 at 9:42 AM, Linux Luser linuxlu...@gmail.com wrote:

 dhcp-ignore-clid might just work for the long-term. But I ended up
 playing around a bit more and I've managed to isolate the part of my config
 that I believe triggers the problem. Maybe this can be fixed without a
 dhcp-ignore-clid option?

 When I set a host's MAC address and IP association in /etc/ethers (with
 the read-ethers option on of course) and that same host's IP address to
 hostname association in /etc/hosts, I am able to get a consistent IP,
 whether or not that same host is using PXE boot, the Debian installer
 (where it send the vendor-id as d-i, which shouldn't matter in this case)
 or boots to its own image on the drive. It is consistent, that is, until I
 implement a trick that I wanted to use so I could whitelist hosts for
 PXEboot. That's when it got inconsistent and I would end up with a brand
 new IP address for PXE and usually another brand new one when the host boot
 into it's own OS. I could only get the IP that I had set in /etc/ethers if
 I restarted dnsmasq on the server. Otherwise the host would receive the
 same WRONG IP over and over for each renewal.

 Here's the config I had BEFORE implementing a PXEboot whitelist:

 domain-needed
 bogus-priv
 log-dhcp

 domain=mydomain
 local=/mydomain/
 server=8.8.8.8
 server=8.8.4.4

 interface=eth0
 except-interface=eth1

 expand-hosts
 read-ethers

 dhcp-range=tag:known,set:controller,10.1.0.1,10.1.255.254,2h
 dhcp-range=tag:known,set:device,10.2.0.1,10.2.255.254,2h
 dhcp-option=option:router,10.0.0.1

 enable-tftp
 tftp-root=/tftpboot
 dhcp-boot=pxelinux.0


 Now, I'll add the lines which allow me to use a directory of files for
 dhcp-host commands:

 dhcp-vendorclass=pxe,PXEClient
 dhcp-ignore=tag:pxe,tag:!install
 dhcp-hostsfile=/etc/dnsmasq-hosts.d


 Inside of /etc/dnsmasq-hosts.d then I can put files that contain lines
 like this one:

 01:02:03:04:05:06,set:install

 ... and send a SIGHUP to dnsmasq process. After this, the host with that
 MAC address gets the tag install and instead of ignoring PXEboot, dnsmasq
 will respond for that host. Wonderful! Problem: now I'm getting wildly
 different MAC addresses. It's like dnsmasq is reading the files in
 /etc/dnsmasq-hosts.d and ignoring the /etc/ethers file. Is this expected
 behavior? A bug? I know that specifying a DIRECTORY instead of a file for
 the dhcp-hostsfile is kind of a new feature. (For my purposes, I'd prefer a
 directory because it's possible that several processes might want to write
 files at the same time. It's easy to avoid concurrency problems by putting
 files with unique names in a directory (named after MAC or hostname or
 UUIDs, etc).)


 FYI, I'm using version 2.59 (comes with Debian wheezy). Thanks for any
 help!



 On Fri, Jan 31, 2014 at 1:48 PM, Simon Kelley si...@thekelleys.org.ukwrote:

 On 31/01/14 16:25, Linux Luser wrote:

 dhcp-ignore-names is concerned about the hostname, correct? I am
 interested in the client identifier option sent in the DHCPREQUEST.
 Ignoring this field would break RCF2131 (and probably some people's
 networks!) but in my particular case, it may spare me some problems.


 I understand, I'm proposing a new option, dhcp-ignore-clid, analogous to
 the existing dhcp-ignore-names.



 Maybe if I could selectively revoke leases, that would work. Could I do
 this? I'm sure that dnsmasq keeps an internal cache, so that would have
 to be flushed for a particular lease.


 There is a utility in contrib/wrt in the source distribution, and a
 binary in the Debiann package of dnsmasq, for releasing a specific lease
 from the command-line.


 On Jan 30, 2014 2:08 AM, Simon Kelley si...@thekelleys.org.uk
 mailto:si...@thekelleys.org.uk wrote:

 On 29/01/14 18:04, Linux Luser wrote:

 We have a pretty tightly-controlled private network environment
 which
 we've configured to have a 1-to-1-to-1 relationship between
 client MAC
 address, hostnames and IP addresses. Apart from guest IP
 ranges, we
 have control over when clients get added to the network. Thus,
 we can
 detect duplicate MAC addresses before it becomes an issue.

 In this setup, we can't need or want to use the client
 identifier
 option of DHCP. In fact, it becomes a problem when we start doing
 PXELinux installs, where a different client id gets sets during
 a remote
 install session, then when the install is complete and the new
 OS boots
 up, it gets a different IP address (because dnsmasq still knows
 about
 the lease it gave that same machine only 10 minutes ago!).

 To get rid of this issue, we now supply a dhcp-host option to
 dnsmasq
 each time we want to do a remote reinstall. The option looks
 something
 like this:
 

Re: [Dnsmasq-discuss] Always Ignore Client Identifier

2014-01-31 Thread Linux Luser
dhcp-ignore-names is concerned about the hostname, correct? I am interested
in the client identifier option sent in the DHCPREQUEST. Ignoring this
field would break RCF2131 (and probably some people's networks!) but in my
particular case, it may spare me some problems.

Maybe if I could selectively revoke leases, that would work. Could I do
this? I'm sure that dnsmasq keeps an internal cache, so that would have to
be flushed for a particular lease.
On Jan 30, 2014 2:08 AM, Simon Kelley si...@thekelleys.org.uk wrote:

 On 29/01/14 18:04, Linux Luser wrote:

 We have a pretty tightly-controlled private network environment which
 we've configured to have a 1-to-1-to-1 relationship between client MAC
 address, hostnames and IP addresses. Apart from guest IP ranges, we
 have control over when clients get added to the network. Thus, we can
 detect duplicate MAC addresses before it becomes an issue.

 In this setup, we can't need or want to use the client identifier
 option of DHCP. In fact, it becomes a problem when we start doing
 PXELinux installs, where a different client id gets sets during a remote
 install session, then when the install is complete and the new OS boots
 up, it gets a different IP address (because dnsmasq still knows about
 the lease it gave that same machine only 10 minutes ago!).

 To get rid of this issue, we now supply a dhcp-host option to dnsmasq
 each time we want to do a remote reinstall. The option looks something
 like this:
 dhcp-host=MAC addr,id:*,hostname,IP addr,set:install

 This works, since the id:* part tells dnsmasq to ignore the client ID
 in favor of the MAC address. But now to my question. Can this be done
 for ALL DHCP requests? Is there a global identify-by-mac-only option?
 If not, would you be willing to entertain the idea. I know many others
 have done this for some time now, using other DHCP server software, so I
 know it's possible and there doesn't seem to be any ill effects of this.#


 There isn't a global option to do this, but there is precedent, in the
 form of --dhcp-ignore-names for adding it, and actually that's something
 more useful, since the tag system allows the setting to be applied to
 classes of clients (which could, of course, be all clients)


 Maybe this is not a good idea? Like I said, we have a fairly controlled
 environment, so it would work for us. I could see how this would be
 unnecessary for common setups, though. Or environments that have many
 VMs running on a single host and simply bridge their network interface
 may want to use the client identifier option so each VM gets a unique
 IP even if they're running on the same machine or t But it would be nice
 to
 have a greater level of control over this.


 Thanks for your time. And GREAT piece of software, by the way. dnsmasq
 is a HUGE time saver and makes changing configurations straight-forward.
 Do you accept donations? :)


 Donations by Paypal to si...@thekelleys.org.uk are always welcome, or you
 could commission me to add new features. I'm available for that on a
 consultancy basis, cheaper for stuff which goes back into the dnsmasq GPL
 codebase, more expensive for proprietary code.



 Cheers,

 Simon.



 --
 daV.e


 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Always Ignore Client Identifier

2014-01-31 Thread Simon Kelley

On 31/01/14 16:25, Linux Luser wrote:

dhcp-ignore-names is concerned about the hostname, correct? I am
interested in the client identifier option sent in the DHCPREQUEST.
Ignoring this field would break RCF2131 (and probably some people's
networks!) but in my particular case, it may spare me some problems.


I understand, I'm proposing a new option, dhcp-ignore-clid, analogous to 
the existing dhcp-ignore-names.




Maybe if I could selectively revoke leases, that would work. Could I do
this? I'm sure that dnsmasq keeps an internal cache, so that would have
to be flushed for a particular lease.


There is a utility in contrib/wrt in the source distribution, and a 
binary in the Debiann package of dnsmasq, for releasing a specific lease 
from the command-line.




On Jan 30, 2014 2:08 AM, Simon Kelley si...@thekelleys.org.uk
mailto:si...@thekelleys.org.uk wrote:

On 29/01/14 18:04, Linux Luser wrote:

We have a pretty tightly-controlled private network environment
which
we've configured to have a 1-to-1-to-1 relationship between
client MAC
address, hostnames and IP addresses. Apart from guest IP
ranges, we
have control over when clients get added to the network. Thus,
we can
detect duplicate MAC addresses before it becomes an issue.

In this setup, we can't need or want to use the client identifier
option of DHCP. In fact, it becomes a problem when we start doing
PXELinux installs, where a different client id gets sets during
a remote
install session, then when the install is complete and the new
OS boots
up, it gets a different IP address (because dnsmasq still knows
about
the lease it gave that same machine only 10 minutes ago!).

To get rid of this issue, we now supply a dhcp-host option to
dnsmasq
each time we want to do a remote reinstall. The option looks
something
like this:
dhcp-host=MAC addr,id:*,hostname,IP addr,set:install

This works, since the id:* part tells dnsmasq to ignore the
client ID
in favor of the MAC address. But now to my question. Can this be
done
for ALL DHCP requests? Is there a global identify-by-mac-only
option?
If not, would you be willing to entertain the idea. I know many
others
have done this for some time now, using other DHCP server
software, so I
know it's possible and there doesn't seem to be any ill effects
of this.#


There isn't a global option to do this, but there is precedent, in
the form of --dhcp-ignore-names for adding it, and actually that's
something more useful, since the tag system allows the setting to be
applied to classes of clients (which could, of course, be all clients)


Maybe this is not a good idea? Like I said, we have a fairly
controlled
environment, so it would work for us. I could see how this would be
unnecessary for common setups, though. Or environments that have
many
VMs running on a single host and simply bridge their network
interface
may want to use the client identifier option so each VM gets a
unique
IP even if they're running on the same machine or t But it would
be nice to
have a greater level of control over this.


Thanks for your time. And GREAT piece of software, by the way.
dnsmasq
is a HUGE time saver and makes changing configurations
straight-forward.
Do you accept donations? :)


Donations by Paypal to si...@thekelleys.org.uk
mailto:si...@thekelleys.org.uk are always welcome, or you could
commission me to add new features. I'm available for that on a
consultancy basis, cheaper for stuff which goes back into the
dnsmasq GPL codebase, more expensive for proprietary code.



Cheers,

Simon.



--
daV.e


_
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.__thekelleys.org.uk
mailto:Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



_
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.__thekelleys.org.uk
mailto:Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.__uk/mailman/listinfo/dnsmasq-__discuss
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Always Ignore Client Identifier

2014-01-30 Thread Simon Kelley

On 29/01/14 18:04, Linux Luser wrote:

We have a pretty tightly-controlled private network environment which
we've configured to have a 1-to-1-to-1 relationship between client MAC
address, hostnames and IP addresses. Apart from guest IP ranges, we
have control over when clients get added to the network. Thus, we can
detect duplicate MAC addresses before it becomes an issue.

In this setup, we can't need or want to use the client identifier
option of DHCP. In fact, it becomes a problem when we start doing
PXELinux installs, where a different client id gets sets during a remote
install session, then when the install is complete and the new OS boots
up, it gets a different IP address (because dnsmasq still knows about
the lease it gave that same machine only 10 minutes ago!).

To get rid of this issue, we now supply a dhcp-host option to dnsmasq
each time we want to do a remote reinstall. The option looks something
like this:
dhcp-host=MAC addr,id:*,hostname,IP addr,set:install

This works, since the id:* part tells dnsmasq to ignore the client ID
in favor of the MAC address. But now to my question. Can this be done
for ALL DHCP requests? Is there a global identify-by-mac-only option?
If not, would you be willing to entertain the idea. I know many others
have done this for some time now, using other DHCP server software, so I
know it's possible and there doesn't seem to be any ill effects of this.#


There isn't a global option to do this, but there is precedent, in the 
form of --dhcp-ignore-names for adding it, and actually that's something 
more useful, since the tag system allows the setting to be applied to 
classes of clients (which could, of course, be all clients)




Maybe this is not a good idea? Like I said, we have a fairly controlled
environment, so it would work for us. I could see how this would be
unnecessary for common setups, though. Or environments that have many
VMs running on a single host and simply bridge their network interface
may want to use the client identifier option so each VM gets a unique
IP even if they're running on the same machine or t But it would be nice to
have a greater level of control over this.


Thanks for your time. And GREAT piece of software, by the way. dnsmasq
is a HUGE time saver and makes changing configurations straight-forward.
Do you accept donations? :)


Donations by Paypal to si...@thekelleys.org.uk are always welcome, or 
you could commission me to add new features. I'm available for that on a 
consultancy basis, cheaper for stuff which goes back into the dnsmasq 
GPL codebase, more expensive for proprietary code.




Cheers,

Simon.




--
daV.e


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Always Ignore Client Identifier

2014-01-29 Thread Linux Luser
We have a pretty tightly-controlled private network environment which we've
configured to have a 1-to-1-to-1 relationship between client MAC address,
hostnames and IP addresses. Apart from guest IP ranges, we have control
over when clients get added to the network. Thus, we can detect duplicate
MAC addresses before it becomes an issue.

In this setup, we can't need or want to use the client identifier option
of DHCP. In fact, it becomes a problem when we start doing PXELinux
installs, where a different client id gets sets during a remote install
session, then when the install is complete and the new OS boots up, it gets
a different IP address (because dnsmasq still knows about the lease it gave
that same machine only 10 minutes ago!).

To get rid of this issue, we now supply a dhcp-host option to dnsmasq each
time we want to do a remote reinstall. The option looks something like this:
dhcp-host=MAC addr,id:*,hostname,IP addr,set:install

This works, since the id:* part tells dnsmasq to ignore the client ID in
favor of the MAC address. But now to my question. Can this be done for ALL
DHCP requests? Is there a global identify-by-mac-only option? If not,
would you be willing to entertain the idea. I know many others have done
this for some time now, using other DHCP server software, so I know it's
possible and there doesn't seem to be any ill effects of this.

Maybe this is not a good idea? Like I said, we have a fairly controlled
environment, so it would work for us. I could see how this would be
unnecessary for common setups, though. Or environments that have many VMs
running on a single host and simply bridge their network interface may want
to use the client identifier option so each VM gets a unique IP even if
they're running on the same machine. But it would be nice to have a greater
level of control over this.


Thanks for your time. And GREAT piece of software, by the way. dnsmasq is a
HUGE time saver and makes changing configurations straight-forward. Do you
accept donations? :)


-- 
daV.e
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss