Startup sequence

[Chris Miller]

Hi Simon,

Thanks for considering my question.

Yes, I am trying to configure my dhcp server with dhcp -- it is only partly
frivolous and it turns out to be an interesting bootstrap question.  Don't
worry; I won't waste anyone's time with pointless arguments or feature
demands and debates.  Part of the exercise is to increase my understanding
how these things fit together.  What possible justification would I have to
try to configure the dhcp server with  dhcp?  Let me see if I can explain
it.

What is the least amount of statically configured infrastructure required?
And can *all* such static configuration live in one place?

The answer, so far, is that *all* static configuration cannot be in one
place because, for example, elements that are not dhcp clients -- like
appliances -- will still have their configuration in their own little
memories and dns will still have to be manually configured (maybe... stay
tuned).  But can I minimize the dispersion?  Can I collect it all in either
dhcp or dns?  Unknown.  dhcp updates dns and not the other way around, so
dhcpd.conf is my only candidate.

It is difficult to see a way to avoid duplicating certain classes of element
in both dhcp and dns -- for example the static elements.  I want them in
dhcpd.conf so I don't accidentally re-use the address and I need them in dns
so those elements are addressable by various client tools -- ping, httpd,
telnet, ssh, ...  If only dhcpd would do dns updates on static leases.  Hey,
wait a minute!  It does!  :-)  

Not so fast, Chris, -- that's a question of timing.  Does the dns update
happen at dhcpd start up or does the update happen when a client requests a
lease?  That seems to be a fair question of understanding that I can
reasonably pose.  Can anybody tell me?

Since, I am considering static leases, there may not be a client making the
request, and even if there is a client making the request, the integrity of
dns is not compromised with a static A and PTR being constantly maintained
for this host.  Despite admonitions that the "update-static-leases" flag is
problematic, it seems that it is the perfect tool for this job.  I recognize
at least one little problem -- the sa will have to remove the entry from dns
if the static lease ever moves, but it is an imperfect world, and I don't
see that as disqualifying -- it would have to be done anyway regardless of
how the A and PTR got there in the first place

O.K, one little feature discussion.  Sorry.  Thanks for indulging me.


Chris.

Fill what's empty, empty what's full, and scratch where it itches.
Life is a journey, not a destination ...




 

> -----Original Message-----
> From: dhcp-users-bounce at isc.org 
> [mailto:dhcp-users-bounce at isc.org] On Behalf Of Simon Hobson
> Sent: Wednesday, November 15, 2006 11:58 PM
> To: dhcp-users at isc.org
> Subject: RE: Startup sequence
> 
> After your first message I was about to write back and 
> suggest that you appear to be using dhcp to configure itself, 
> and this is the first time I've heard of someone trying this.
> 
> Then you confirmed it.
> 
> I find myself asking why you want to go through all these 
> hoops when you can (and in fact have found out, MUST) also 
> configure it manually. It creates all sorts of issues, like :
> 
> If you don't configure /etc/resolv.conf then you can't 
> resolve and dns names in your dhcpd config, and therefore 
> dhcpd can't start, so you can't configure resolv.conf by dhcp 
> - and probably a few other dependencies as well.
> 
> 
> Naturally, the dhcp server cannot start if it cannot 
> determine what subnet it is in - without that information it 
> is not able to function correctly.
>