Best practice for network configuration

Christopher Browne cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Mon Jun 27 21:03:45 UTC 2011


On Mon, Jun 27, 2011 at 4:08 PM, William Muriithi
<william.muriithi-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> Pals,
>
> I recently came across a bunch of servers that uses DHCP for IP
> assignment and I found this really strange.  I have googled on what is
> recommended method on google and I do not seem to get anything
> authoritative.
>
> Would anyone out there no of any reason why it would be recommended to
> use DHCP on servers?  Is anybody out there using such a setup and what
> triggered you to take that route?

Well, if you have a *lot* of servers, and they are pretty
interchangeable, such that you might assign them to different purposes
dynamically at boot time, then this would be pretty enormously useful
as an assignment mechanism.

Also, if you have a goodly bunch of servers, and would like to assign
network information in a centralized fashion, then, again, DHCP is a
pretty decent way to get started with that task.

Using DHCP minimizes the amount of local configuration that needs to
exist, which is pretty nice if you have the proverbial "lots of
servers" to manage.

But that being said, I don't like the idea terribly much.

1.  Minimization of local configuration information + central
management means that the central server is a potential Single Point
of Failure.  If the DHCP server is, for any reason, inaccessible, that
server will remain mute.

Of course, this might be a moot point if the death of DHCP means that
there aren't any clients coherently connected to the network.

2.  Is it likely that you'll have a bunch of servers where you won't
determine what they're configured to do until they connect to the
network and ask?  I wouldn't think this happens much...

3.  This solution only addresses a small set of things, as DHCP services:
 a) Network address
 b) DNS resolution information
 c) Possibly a "time sync for free"

A server will do a lot more than that, so, if I'm centrally managing
services, I'd rather debate over options that can readily deploy
arbitrarily larger amounts of configuration.

LDAP tends to be the "better way" to deploy lots of configuration,
albeit with the caveat that any time I fight with LDAP, I find myself
wishing that, instead, I had set up the project of poking my eyes out
with a spoon, as that sounds like more fun than setting up LDAP.

The alternative that involves "less poking out of eyes" is to use
something like CFEngine to pull and use configuration data that is
drawn from a central place.  By separating "pull" and "use," CFEngine
is likely to allow that server to do something at least vaguely
coherent if there's a network partition that leaves the server unable
to consult its master configuration source.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list