PATCH: make contrib/redhat/sshd.init work with older RH releases

[Jim Knoble]

Circa 2001-Feb-18 03:35:54 +0200 dixit Pekka Savola:

: On Sat, 17 Feb 2001, Jim Knoble wrote:
: [About /etc/rc.d/init.d/ vs. /etc/init.d/]
: > I disagree.  If you want to fix it properly at this time, this is
: > exactly the sort of thing to worry about.  Are you certain RH will
: > leave the compatibility symlink in RHL-7.1?  I'm not.
: 
: Yes.  It will be there.

How do you know?  Do you know if it will be there in 7.2?  8.0?  The
FHS >= 2.0 clearly states where init.d is supposed to live
(/etc/init.d), and RHL has a particularly poor track record at
providing real compatibility with prior releases.

: > Red Hat Linux 5.2 is no more obsolete than, say, NeXTstep 3.x or
: > 4.x, HP-UX-10.x, IRIX-5.x, SunOS-4.x, all of which are listed in
: > configure.in.
: 
: For most of these platforms, only something like 'add
: /usr/local/sbin/sshd in your rc.local' is given.  This is a more
: complex matter

Only because you're making it complex.  I gave a simple solution that
works.  You're the one who wants to rewrite everything from scratch.

: Also, the pace at where Linux vs e.g. Solaris is developing is quite
: different.  I don't think it's feasible to assume a Linux box
: installed 4 years ago will still be running non-upgraded; for
: commercial systems, this is probably rather commonplace.

Bullshit.  I know of four separate instances, right now off the top of
my head, where Red Hat Linux 5.2 or earlier is in place, functioning
perfectly, with no need to upgrade the entire system.  You only say
that Linux is developing at a faster pace because you think that
everyone downloads Red Hat Linux betas and moves to them as soon as
they're available.  If they want to continue using what they know
works, without extra cost-of-ownership involved in upgrading, then *let
them*, for goodness' sake!  It's not so difficult!

When i recently installed OpenSSH-2.3.0p1 on a Red Hat Linux 4.2 for a
friend of mine, the only thing that was necessary for me to do, besides
recompiling with --without-pam, was ... *FANFARE* modify sshd.init.
Leaving folks in that situation in the dust is ignorant, short-sighted,
and arrogant.

: > The solution i've proposed will work fine on Red Hat Linux 5.2, and
: > coincidentally on 4.2 as well, without posing any additional troubles
: > to 6.x, 7.0, or subsequent releases.
: 
: Well, it all boils down to this:  do we want to diverge from RH init
: scripts?

OpenSSH *already* diverges from recent RH init scripts, for goodness'
sake!  Where else is something like do_dsa_keygen() or do_rsa_keygen()
done?  Nowhere!  Where else is a daemon started without using the
daemon() function?  Virtually nowhere!

Conforming to the shoddy, half-ass style that most RH init scripts are
written in has never been a goal of mine.  Making things work properly
has been.

: Adding all kinds of 'my_success' etc. functions push toward complely
: separate scripts.

Huh?  It's not completely separate.  In fact, it's grafted into the
*provided* API, where that API exists, both for RHL >= 6.0 and for RHL
<= 5.2.

: I don't like it from the maintainability point of view.

Sorry?  If anything, what i've presented is *more* maintainable.  At
least it's immediately obvious what's been done, and what needs to be
done to maintain compatibility.  With your proposed solution, someone
modifying the file could easily be blissfully ignorant of any
compatibility needs and completely break things, then wonder why the
hell they don't work anymore weeks or months down the road.  For the
purpose of maintainability, obvious is better than pretty.

: If we want to support really old systems, it's probably better to just
: provide them a _very_ simple init script which would have worked even
: with RHL 3.0.3.  No fuss, nothing to maintain.
                 /^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                /
This is exactly the attitude i take issue with.  I provided a fix that
required no fuss, and no extra file to maintain ... it just worked, in
one file.  What's the problem with that?  You think it's not clean or
pretty enough?  Sorry if you feel that way, but making things work
across releases sometimes requires code that feels a little gritty.
That's life.

If you think that there's nothing extra to maintain, look at the
difference between sshd.init and sshd.init-5.x, and tell me why you
think sshd.init-5.x isn't in sore need of maintenance.  In particular,
tell me why you think that it's a good idea to neglect to generate a
host key at startup time when there's plenty of entropy available like
the folks running RHL-6.x or later get to do.

: Better than using a lot of time verifying every new bell & whistle
: that'd appear in newer init scripts, backporting them into earlier
: versions

Isn't that what developing a "portable" version of OpenSSH is all
about?

: and bloating what most people use.

Unless you can come up with a non-arbitrary quantitative definition of
"bloat", then please stop using that argument.  It's been a tired old
argument ever since processors became faster than 16 MHz and had
builtin MMUs and FPUs.  If you mean "it's not how i would like it to
look for my system", then please write that.

Pekka, i'm not trying to be belligerent, but you're pressing all my
hot-buttons.

-- 
jim knoble | jmknoble at jmknoble.cx | http://www.jmknoble.cx/