Host configuration

[Frank Sweetser]

Jeffrey Hutzelman wrote:

>> Well, at a minimum, it's quite difficult to manage your DHCP server
>> infrastructure that way =)
> 
> Sure; you want to manually configure at least a couple of DHCP servers, if 
> not all of them.  For a particularly large network, it is likely the case 
> that even most DHCP servers should also be DHCP clients; the number of 
> machines that actually need static configuration should be very small.
> 
>> Personally, my preference would be to use static IP configuration, and
>> then leave all of the other buttons and knobs up to a more flexible
>> configuration management system
> 
> How about "most of the other buttons and knobs".  IP addresses, 
> nameservers, and other things that depend on what network segment you 
> happen to be attached to are better managed via DHCP.  It's hard to use 
> puppet or a GPO to change a machine's default router at exactly the time 
> the machine moves to a new subnet.

If you're in an environment where your servers move around a lot, sure, then
DHCP on them makes more sense.  Our servers move very rarely, and we're
sufficiently centralized that a lot of those settings (DNS, NTP, etc) don't
really vary from one subnet to another, so the extra service dependency isn't
worth it for us.  One man's holy grail is another's worst nightmare, depending
on the demands and resources.

Of course, that said, you can easily use puppet and DHCP at the same time,
giving you the best of both worlds.  If you have a sufficiently flexible
registration system, like, oh say, CMU NetReg, you could even use that as the
master data source for puppet configuration, at least for some of the more
volatile elements, such as mapping configuration policies to hosts.

> I can't imagine running a facility of any noticeable size with static 
> configuration.  Actually, I can, but only because we used to do so, many 

Just to clarify, I'd only ever propose having a quite small percentage of your
infrastructure configured statically.  Exactly what that percentage is is
probably most dependent on how much manpower you've got.

> years ago.  Of course, that was in the days when every machine at Carnegie 
> Mellon had the same netmask and default router (world's largest flat 
> bridged Ethernet, and proud of it!).  I can't imagine transitioning from 
> that to the network architecture we have today without dynamic 
> configuration.

Heh... been there, done that, think I still have the t-shirt around here
somewhere.  We did the transition using some hacked up scripts to generate
DHCP configs instead of BOOTP configs, and a split brain network architecture
that would make a network engineer cry.  We eventually switched over to CMU
NetReg, and life is far easier now =)

> These days, we use static configuration only for DHCP and DNS servers, 
> machines too old and broken to run DHCP, and a handful of services that we 
> want to be able to boot without waiting for DHCP, solely to reduce the 
> startup time after a cold shutdown.
> 
>> There's nothing quite so much fun as creating a
>> circular service dependency between two servers, where neither one may be
>> turned on until the other is fully booted...
> 
> Nonsense.  The fun part is discovering such a dependency during a cold 
> start and figuring out how to manually resolve it, all without any of the 
> normal infrastructure available.  :-)

Hmm... with a little copy editing, I'd bet you could get a decent selling
shirt on thinkgeek with that on it =)

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC