Host configuration

[David W. Hankins]

On Thu, Feb 14, 2008 at 03:39:50PM -0500, Frank Sweetser wrote:
> The *simplest* (not necessarily best, especially in all circumstances - just
> the simplest) solution is to flat out avoid requiring DHCP on a small number
> of core servers that must be brought up to provide essential services (login
> authentication, DNS, etc).

Yes, precisely.  It is also simplest to flat out avoid requiring
ethernet autonegotiation on a small number of core servers and all
inter-switch links that must be brought up to provide essential
services.

In either scenario you're hosed if it goes horribly wrong, whether
it's a cascading failure or not.

> > Let us characterize DHCP in this particular use case as a dynamic
> > process that reaches a fixed (or semi-fixed) ends.  This is a
> > redundant operation.  Redundant operations introduce complexities;
> > more components of the system may fail ("unknown flaws").  The
> > conclusion is to remove the redundancy to avoid phonecalls at 3 am.
> 
> On the other hand, throwing out all the damned machines in the first place
> would save a lot of time and effort =)

=)

Note the reason this is funny is because it is at the expense of the
operation, and not at the expense of redundances in the operation.

> In the end, you have to balance the
> TCO of each piece against the benefit.  A 10 desktop and 1 server network
> doesn't need multiple top end routers and load balancers, while a low cost
> SOHO router has virtually no benefit to a company with tens of thousands of nodes.

Whether you choose an expensive or inexpensive cog is irrelevant to
whether or not that cog is redundant.

You either need a cog, and select one of appropriate cost, or you do
not need one at all.

> Bringing the DHCP server up first may result in processes looking for files
> that aren't there and trying to look up hostnames from DNS that isn't
> answering.  If that DNS server won't boot without DHCP, you've dug yourself
> into a nice little hole.  It's quite available, you just have be aware of the

And similarly, if you can't get net at all because your link is
misnegotiated, you won't even be able to look for the files that
aren't there.

I really don't see a difference except that you've postulated a
complicated failure mode where a simple one will do.  The DHCP
client software may simply not initialize properly.  External
dependencies never need to enter into it.

> > Fourth, use DHCP client identification to match the individual
> > service.  In this way, the hard drive inside a server, with its
> > generated (RFC3942) or configured client id, consistently identifies
> > itself for resources like dynamic DNS, and its IPv4 addresses.
> 
> Maybe I've missed something here, but I don't see how a choice of client
> identifier would make a difference.

So that a node in a server-farm can have its hardware forklift
upgraded without any appreciable changes; no new address, no mucking
about with dns DHCID mismatches.

It's just good advice, rather pointless if all forklift upgrades are
entirely new servers in the farm (never just swapping disks and
therefore services to new gear).

> On the other hand, as soon as you need to beyond the simple key-value pairs
> that happen to be supported by the relevant DHCP clients, you're pretty much
> out of luck.  DHCP won't help you much if you need to manage user accounts,
> enable/disable services, or install a package.

It is true that objects that are an orange tend to remain an orange.

In this sense, I am not predisposed to refuse to eat an orange merely
because it is not an apple, and while both give vitamins only apples
keep the doctor away (similarly to cloves of garlic and vampires).

In the same sense, I am unconcerned that there are things you can't
do with DHCP.  I can do the things I can't do with DHCP with something
else, and continuing to do the things we do with DHCP is handy since
it works so pervasively I don't have to be concerned with...getting
apples down the gobs of everyone in my facility.

> Likewise, there's no
> authentication,

Again, let us remind ourselves that IETF DHCP is not ISC DHCP.  Just
because ISC DHCP has not implemented RFC 3118 does not mean it does
not exist.

> minimal extensibility,

RFC 3942's authors and fans would find that ironic.  There has been,
I think it can be said truthfully, far too much extensibility to DHCP
such that we had to make less and try to focus the extensions into
scalable channels (VIVSO/VSIO).

> no audit trail or notifications of what actions were taken,

I dunno man, we log everything.  Too much, it has been said, and some
folks want us to start omitting certain data so they don't keep
identifying information lying around.

> or ability to push
> out updates rather than waiting for the client to pull.

Understanding again that IETF DHCP is not ISC DHCP (no reconfigure
extensions support).

Note that I haven't heard of many ISC DHCP users who have been unable
to cope with the lack of reconfigure extensions by simply planning
ahead before reconfiguration events to lower leasetimes.  Admittedly,
it would be better if we could lower just the renew times for a server
farm, but there you have it.

> Once you get past a handful of relatively trivial settings, DHCP just won't
> cut it anymore, and you need to bring in different code designed to handle
> that kind of automation instead.

So, instead of using an existing tool to perform a task, the solution
is to increase the scope of a new tool's construction to sufficiently
overlap, and then deploy the new tool upon all systems.

As you said, TCO is an issue, and it's up to you to do what you want.

But I don't see how any of this can be said to have been derived from
a consistent definition.  It's all just comfort and style.

Personally I find the whole thing frustrating.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins