On Sun, Nov 22, 2020 at 02:21:24PM -0500, Mouse wrote:
> > [...], but I DO like that it eases and therefore promotes IaC,
> > programmatic configuration.
>
> That's exactly what I don't like about it. It leads, fairly directly,
> to admins who don't really understand their systems. This is fine
> (well, -ish) as long as all goes well, but it falls over
> catastrophically when things break. Fujinaka-san concretized it well:
>
> > WHICH ONE OF THESE *%*( FILES IS THE ONE I NEED TO EDIT TO GET SSH
> > WORKING AGAIN? ALL OF THEM? $*%)()!!!
>
> This, of course, is not an issue if the admin really understands the
> setup - but it will, sooner or later, become an issue if not.
>
> Of course, any setup can ultimately be understood. But the more
> complexity there is, the harder that is to do; and the more automation
> is provided by someone else, the more it encourages administration
> without understanding - in extreme cases it actively obstructs
> administration *with* understanding. (While I haven't seen it often, I
> have seen people asking about underlying mechanisms answered with,
> basically, "just use the automated tool". While there is a place for
> automation, using it as a substitute for understanding is, in my
> opinion, a disaster in the making.)
>
If the principle of a directory included was to be adopted why not adopt
the same organization as rc.d? inetd.conf having variables indicating if
the services are too be run and with which parameters à la rc.conf. In
this case, it will be organized but an existing principle will be
applied easing the understanding because there will not be another rule
but an exception less.
But this doesn't address the problem of the compatibility except that
the migration could probably be scripted.
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
