install.sh

[David Lee]

On Tue, 9 Mar 2004, John Rudd wrote:

> So, what exactly does install.sh do?

Good question.  In fact, in the light of your later comments, it is two
subtly different questions:

1. What does it do now on Redhat Linux (and systems that already use it)?

2. What differences would it make/involve/force on other systems (that
   don't yet use it)?

> I tend to shove mailscanner into /opt/mailscanner-$VERSION and work on
> it there until I'm ready to put it into production.  When that's ready,
> I remove the symlink "/opt/mailscanner" and point it at the new version
> (so I keep the old one around so I can fall back to it if there's a
> problem).

That's exactly what I, too, do on our Solaris systems.  But we both also
have to do more than that.  We need to check, grab, build and install the
various pre-requisite perl modules.  We have to check cron jobs.  We have
to check "/etc/init.d" things.  We have to check "/etc/default" things.
All this is manual and, let's face it, potentially error-prone (in the
"pilot (i.e. my) error" sense).

When I was persuaded (reluctantly, I might add!) to begin to migrate
towards Redhat (alongside our existing Solaris) I came to realise how much
easier such maintenance tends to be on Redhat.

This isn't necessarily because of differences between RH and Solaris as
systems.  Rather it is because additional software for RH sometimes comes
prebuilt as packages (rpms), whereas this tends not to happen for Solaris
etc., where one needs to use the old manual "configure/make/test/install".
(How I wish software packagers who produce RPMs would also produce Solaris
PKGs.  But I digress...)

Of course, there is a measure of trust involved.  Would I rather trust a
prebuilt "install.sh", or my own "configure/make/test/install cycle"?  We
still need to consider that on a case-by-case basis.  In the case of
MailScanner, I trust (through experience) Julian's "install.sh" for RH.

> I do NOT disable the /etc/init.d/sendmail and /etc/rc?.d/???sendmail
> scripts, I just have them invoke the 2 sendmails.  I also don't use any
> form of MailScanner rc script (though, if it would stick to only
> starting and killing mailscanner, I might start using it).

On Solaris, I've come unstuck with MailScanner because various upgrades
have sometimes required (I later discovered via debug/slog etc.!) changes
to the details in "/etc/init.d/sendmail" or similar.  By contrast MS's
"install.sh" seems to get it right, and to do so swiftly, cleanly and
efficiently.

I used to be very much pro-Solaris, pro-"configure/make/test/install".
But I'm slowly coming round to appreciate the ease (from trusted sources)
of prebuilt "install.sh" behaviour.  Especially in something as complex as
MailScanner (with its perl pre-requisites, /etc/init.d interactions,
/etc/default interactions, cron jobs, etc.).

Indeed because of the tedium of doing this on Solaris, we have often been
running way out-of-date versions of MS.

Returning to your "work on it there until I'm ready to put it into
production".

That exactly what I had to do (and still have to do) on our Solaris
MailScanner installations.  By contrast, on our RH installations, because
I trust the packaged "install.sh" mechanism, I simply shut down MS on our
least-preferred-MX machine, run "install.sh", do a few sanity checks, then
restart.  After that's been going and monitored for a while, I then repeat
it on our preferred-MX machines.  Much more comfortable and productive.

> If install.sh doesn't give me the option to do things that way, without
> modifying the script, then I would be unlikely to use it at all.  Which
> means I wouldn't want it to be mandatory, either (which seems to be the
> impression I'm getting about the install.sh script for the rpm
> distribution, because a lot of answers start out "run the install.sh
> script").

But now you seem to be in favour of a well-written, trusted "install.sh".
The above reads "a lot of problems arise when people bypass install.sh".
And recall that many of those problems aren't in MS itself but in its
interactions with other system components, e.g. perl modules.  In other
"install.sh prevents many problems arising in the first place".

Myself, I used to be a hardened "configure/make/test/install" advocate.
But I'm coming round to the view (each case on its merits, of course) of
recognising the value of an "install.sh".  And in the case of MS, my RH
("install.sh") vs. Solaris ("configure/make/test/install") experience is
now heavily in favour of the "install.sh" option (for us, at our site).

Hope that helps, John.

Best wishes.

--

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 334 2752                  U.K.                  :