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

[Pekka Savola]

On Sat, 17 Feb 2001, Jim Knoble wrote:
> Remember also that in RHL-7.0 (and in FHS >= 2.0), the location of
> 'init.d' changes.  This looks more robust to me:
>
>   SSHD_FUNCTIONS=""
>   for i in \
>     /etc/init.d/sshd-functions \
>     /etc/rc.d/init.d/sshd-functions \
>   ; do
>     if [ -f "${i}" ]; then
>       SSHD_FUNCTIONS="${i}"
>       . "${SSHD_FUNCTIONS}"
>       break
>     fi
>   done
>   if [ -z "${SSHD_FUNCTIONS}" -o $? -ne 0 ]; then
>     exit 1
>   fi
>
> But it's rather complex.  Even this would be acceptable:
>
>   if [ -f /etc/init.d/sshd-functions ]; then
>     . /etc/init.d/sshd-functions
>   else
>     . /etc/rc.d/init.d/sshd-functions
>   fi
>   if [ $? -ne 0 ]; then
>     exit 1
>   fi

IMO this is rather unnecessary thing to worry about yet.  /etc/rc.d/init.d
work just great too, because of symlinks.  Those aren't going to be
removed any time soon I think.  No need to make this more complex than we
have to.

> The problem is with redefining the stock functions is that success()
> and failure() work slightly differently than the equivalent actions for
> RHL <= 5.2.
>
> That's why the my_success() and my_failure() functions i defined take
> an optional second argument, to make them Act The Right Way(R) for all
> RH releases.  In RHL-6.2, success() and failure() only care about their
> first argument ($1), and it , but there's no guarantee that Red Hat
> won't change the functions in the future.  Using our own functions
> avoids that potential problem.

It'd appear to me that your success()/failure() work differently from my
proposal only if success/failure haven't been provided by initscripts at
all.


My concern is this:  I wouldn't like a huge amount of development work
going into versions only very few people use.  There should be some sane
limit of backward compatibility.

That is, I'd like to be able to state:

At the moment, we only support Red Hat Linux 6.x (all errata installed)
and Red Hat Linux 7.x (all errata installed).

And when a new feature is added, I wouldn't like to have to consider what
might happen with a 3-year old system, where RPM is ancient, initscripts
doesn't support anything, etc.

Backward compatibility is OK, but
 1) it shouldn't affect "currently supported" versions
 2) it should be transparent

That is why I'd prefer redefinitions of "echo", "success" etc. functions
rather than new functions; those that have recent versions shouldn't use
these at all (there are always issues; what will happen if you want to
pass e.g. ssh-keygen -N '' to action or the like; you would be amazed at
the number of \'s required..)

-- 
Pekka Savola                  "Tell me of difficulties surmounted,
Netcore Oy                    not those you stumble over and fall"
Systems. Networks. Security.   -- Robert Jordan: A Crown of Swords