Best practice for network configuration

[Christopher Browne]

On Thu, Jun 30, 2011 at 8:08 PM, Robert Brockway
<robert-5LEc/6Zm6xCUd8a0hrldnti2O/JbrIOy at public.gmane.org> wrote:
> On Mon, 27 Jun 2011, Christopher Browne wrote:
>
>> But that being said, I don't like the idea terribly much.
>
> Me either.  If you want to centralise management of your servers something
> like puppet is probably a better idea.  At least it fails safe - ie if
> puppet falls over then you just can't update your servers until you restart
> it but they will continue to function in the mean time.
>
> I note that you mentioned cfengine laster in your post.

I used to be "cfengine partisan," and haven't actually grown into any
liking of Puppet, but am a little more agnostic once the author
decided that the *real* version of CFEngine ("Nova") was to be a
proprietary thing, with the consequence that any new features that
crop up that are deeply good are left out of the "community edition."

"Fail safe" is something that's pretty natural for just about any
pull-based configuration management system.  It sure is nice if an
"outage" of the central controller merely means you don't get updates
for a while, as opposed to having your brains scooped out.

>> 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.
>
> This argument can be generalised as "Functioning of these servers at this
> time is irrelevant as their principal reason for being does not currently
> apply".

Certainly

> People sometimes use it as a justificiation for not properly separating
> nameservers too.

I once saw this break down for the PostgreSQL project; a few years
ago, they had an outage because the effectively authoritative pair of
DNS servers were a little too close together.  (They had, and still do
have, ~4 NS records; at the time, two were primary, and when they got
deranged, the other two were neither up to date nor particularly
manageable.)

People that are serious about DNS availability seem to prefer having
permutations of:
a) Not just one flavour of DNS server (e.g. - multiple of BIND, NSD, ...)
b) Have NS records in multiple zones, so you're not vulnerable to one
registry operator "oopsing" you.  Thus, multiple of (com|net),
(org|info|...others that Afilias are involved with), and perhaps some
of (ca|uk|de|us|fr|jp)
c) DNS servers not all in one ((legal|geographic) region|data centre)

How much paranoia/redundancy to have is a good question without any
single correct answer.

if your web server's on one box in one data centre, then you lose
little by depending on DNS servers sitting in the same subnet, which
heads back to the same "moot point" about DHCP.

> I've never liked this argument.  I think this argument has some flaws:
>
> (1) That you fully understand every function this server performs.  You
> haven't forgotten any of them.

I suspect that this may one may be in flux.  With the ease of
deploying virtual machines, it increasingly makes sense to deploy 15
services by setting up 15 VMs, each running a single service.  If they
all happen to run on one physical box, that's great; they may be
distributed across hardware with little difficulty.

(On the other hand, VMs also make it practical to take that mouldering
old box running a long-out-of-support version of Mandrake with an
unenumerated set of services that nobody knows much about, and that
they're all too scared to touch, and keep it running.)

> (2) Failure or partial-failure of this server won't have worse outcomes than
> if it continued to run without anyone using it.
>
> I know you're not endorsing this.  It was just a fine time to mention what I
> consider to be a logical trap that many sysadmins and architects are falling
> in to :)
>
> Cheers,

Always a fun discussion.
-- 
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