Re: inetd Enhancements

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I am sympathetic, but a directory of fragments is very thin syntactic
> sugar over having it all in a file.

True...and false.  It's not all that thin, because...

> It does mean that "update this file if it hasn't changed" is likely
> to work on each fragment, rather than failing on something which is a
> textual collision but not a semantic one.

...there *are* significant substantive differences.

> If what you object to is programs coming with default configs that
> are active without the admin passing a test, then please say that.

Not quite.  It's not about the admin having to pass a test in order to
be one of the elite who get to use $PACKAGE.  (I know that's going
beyond what you actually wrote; it's approximately what I suspect a lot
of people will read into what you wrote, whether you meant it or not.)
It's more that I don't like automated administration of the "I'm going
to put all these pieces in what I fondly hope are the correct places
and hide it all from the admin" sort.  Never have, and I think I may
have finally identified what bothers me about it.  This has bothered me
for some time, because "I don't like automated admin" isn't accurate or
complete - I, like many (most?) admins, automate admin tasks and see
nothing wrong with doing so.

What bothers me about this kind of automated admin is that, instead of
being transparent and encouraging understanding, it is opaque and
encourages ignorance and lack of understanding.  Indeed, in the more
extreme cases, it actively gets in the way of an admin who wants to
understand what's going on.  (I've seen automated software install
procedures so opaque the easiest way to figure out what they actually
do is to run them in a union-mounted chroot and, afterwards, pull it
apart and look at the upper layer - or do the install on a scratch
system and compare it with the original.)

> Making the config less fragile about things that are textual but not
> semantic merge conflicts isn't the core problem,

No, *that* isn't a problem at all.  That's not the effect that bothers
me.  That effect is a good one.

The problem is that the mechanism used to achieve that - sharding the
config into one file per package or conceptual service - also supports,
even encourages, the "just trust the installer (updater, maintenance
program, whatever) and don't worry your pretty little head about what
we're doing to your system" kind of automated administration, and
*that*, I believe, *is* a problem.  It's a philosophical problem in
that it gets in the way of understanding, which gets in the way of
fixing things when the break (they always do, eventually).  It's a
practical problem in that such procedures tend to explode when faced
with a system that isn't exactly what they're designed for - and they
often are opaque enough that there is nothing for even a _good_
sysadmin to fall back on as a manual substitute.  It's a security
disaster in that it's surrendering control of what should be your
system to someone else, someone who usually has very different
priorities from you.

If someone manages to come up with a way to achieve the merge
robustness that doesn't support and/or encourage that sort of automated
administration, I will quite likely wholeheartedly support it - but I
will also be astonished, because I haven't even heard of, much less
seen, any such.

> and we shouldn't not do that because of concern it might be abused.
> That would be like banning cars because they might be used in a bank
> robbery.

If there were no other uses for cars, or they were minor enough, that
might be an appropriate reaction.  Indeed, we do do the analog in some
cases (details vary by jurisdiction, but you'll have trouble finding
one that doesn't do something analogous in some cases).

This is a tradeoff.  There is a benefit (isolating per-service
configuration) and a drawback (automation at the expense of
transparency and understandability).  I think the drawbacks are the
greater; complicating it is that I suspect the drawbacks usually aren't
noticed by the proponents of such schemes.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B