[Dnsmasq-discuss] Ideas for handing out "per blade" information
ranceh at gmail.com
Fri Oct 23 16:34:28 BST 2009
On Thu, Oct 22, 2009 at 5:18 PM, Paul Smith <psmith at gnu.org> wrote:
> So, suppose I wanted to provide some location information in the DHCP
> response packet: something like rack number + chassis number + slot
> number etc. Say a sequence of N integers. I checked the DHCP RFCs and
> didn't find a DHCP option that seemed appropriate. I'd prefer to do
> this in the most standards-compliant way possible: anyone have a
> suggestion for a good option to use?
>> There's no way to change this information completely dynamically. You
>> can however put all the dhcp-host information into a file and point at
>> that file with --dhcp-hostsfile, similarly with options and
>> dhcp-optsfile. Unlike a general configuration, these files _are_
>> re-read when dnsmasq gets SIGHUP.
> I guess I need to set up a cronjob or something to do this. I can
> imagine, though, that the latency between when you put a new board in,
> and when the information is available to dnsmasq to respond properly to
> DHCP requests from that board, could become a source of frustration.
> I'll just have to code the board to continue to do DHCP requests until
> it gets back a response containing the location information I need, or
> Thanks for your help!
I have an idea that may help with part of this problem. Ived used
this idea successfully with many other projects so theres no reason
why this wont work for you.
Keep in mind that this is designed to replace the cron job idea of
regular updates. This idea triggers updates only when needed.
<background> I originally found this while looking for a way to tell a
mail filter server about new email addresses changes as they occured
and not whenever a cron job got around to running.
Run a looping script that creates a named pipe, such that if the pipe
ever dies the script doesnt exit but instead creates the pipe again
(yes its an infinite loop, be careful). Run a second script that
watches that named pipe for input. The pipe-watcher script will
trigger a third script. This third script will then update a dnsmasq
configuration file, and send dnsmasq a SIGHUP or whatever other signal
it needs to send.
The three script model here is a little cumbersome, but very modular
and its able to be used in an amazing variety of ways. Let me know if
you are interested in pursuing something like this, and I can point
you in the right direction to make it happen.
As to your other question about making dnsmasq happy and following the
standards as closely as possible, keep reading, Im sure Simon or
someone else on this list who is much better at the dhcp protocol
level can help you come up with something that sense.
More information about the Dnsmasq-discuss