On 10/22/2014 03:51 PM, Barry Shein wrote:
I wish I had a nickel for every time I started to implement something
in bash/sh, used it a while, and quickly realized I needed something
like perl and had to rewrite the whole thing.
Barry, you've been around a long time, and these words are pearls of wisdom.
This seems to be the reasoning behind replacing the spaghetti known as
'initscripts' currently written in sh with something written in a real
programming language. Upstart and systemd are both responses to the
inflexible spaghetti now lurking in the initscript system, of which the
pile steaming in /etc/init.d is but a part.
Sure, one can insist on charging forward in sh but at some point it
becomes, as Ken Thompson so eloquently put it on another topic
entirely, like kicking a dead whale down the beach.
This seems to be the attitude of the systemd developers, although
they're not as eloquent as Thompson in saying it. But I remember being
just as abrasive, just on a smaller scale, myself.......
Now, I've read the arguments, and I am squarely in the 'do one thing and
do it well' camp. But, let's turn that on its head, shall we? Why oh
why do we want every single package to implement its own initscript and
possibly do it poorly? Wouldn't it be a case of 'do one thing well' if
one could do away with executable shell code in each individual package
that is going to run as root? Wouldn't it be more 'do one thing well'
if you had a 'super' inetd setup that can start services in a better way
than with individually packaged (by different packagers in most cases)
shell scripts that are going to run as root? Shouldn't the
initialization logic, which is 'one thing that needs doing' be in one
container and not thousands?
Now, I say that having been a packager for a largish RPM package several
years ago. I waded the morass of the various packages' initscripts;
each packager was responsible for their own script, and it was a big
mess with initscripts doing potentially dangerous things (mine included;
to clear it up, I maintained the PostgreSQL packages for the PostgreSQL
upstream project from 1999 to 2004). Ever since 1999 there have been
issues with distributed initialization logic (that runs as *root* no
less) under hundreds of different packagers' control. It was and is a
kludge of the kludgiest sort.
Having a single executable program interpret a thousand config files
written by a hundred packagers is orders of magnitude better,
security-wise, than having thousands of executable (as *root*) scripts
written by hundreds of different packagers, in my experienced opinion.
If anything, having all initialization executable code in one monolithic
package very closely monitored by several developers (and, well, for
this purpose 'developers with attitudes' might not be the worst thing in
the world) is more secure. It *is* a smaller attack surface than the
feeping creaturism found in the typical /etc/init.d directory. And
Barry's pearl of wisdom above most definitely applies to /etc/rc.sysinit
and its cousin /etc/rc.local.
Now, as much as I dislike this magnitude of change, it seems to me that
systemd actually is more inline with the traditional Unix philosophy
than the current initialization system is. But I always reserve the
right to be wrong. And I am definitely not fond of the attitudes of the
various systemd developers; systemd assuredly has its shortcomings. But
it *is* here to stay, at least in RHEL-land, for at least the next ten
years.
Having said that, if you want to use Upstart, by all means use Upstart;
RHEL6 (and rebuilds) will have Upstart until 2020. So you're covered
for quite a while yet, if you use CentOS, Scientific Linux, or another
RHEL6 rebuild (or actual RHEL6).
And for those who bugle that systemd will be the 'end of unix as we know
it' I just have one thing to trumpet:
"Death of Internet Predicted. Film at Eleven."
