Finding sendmail during configure

Russ Allbery rra at stanford.edu
Thu Sep 4 19:29:12 UTC 2003


Forrest J Cavalier <mibsoft at epix.net> writes:

> INN 2.3.0 and previous behavior did exactly what the comments from INN
> 2.3.0 said:

> dnl The sendmail code takes this philosophy:  We assume that there are some
> dnl sites which don't have sendmail in the path for a reason, whatever that
> dnl may be.  And we also assume that there are some of those sites which
> dnl don't want us to automatically pick one from a likely place.  So we
> dnl detect it, then search for it, but then notify the human.

Right, this philosophy makes no sense to me.  I've never seen any other
software package work this way, and I think it violates the principle of
least surprise.  It seems to be making the assumption that it's normal for
sendmail to be on the user's path and if it's not, something odd is going
on.  This assumption is clearly false; sendmail is normally found in
either /usr/sbin or /usr/lib, neither of which are on the default user
path.

> So, if sendmail is at /usr/lib it would have printed a message such as:

>   sendmail was found at /usr/lib/sendmail.  If this is correct, re-run
>   with --with-sendmail=/usr/lib/sendmail.

> I think that INN 2.3.0 behavior satisfies (at least in spirit) what Bill
> Sellers wanted when he wrote:

>> Unless the are unresolved dependencies, it should work.  On a Solaris 8
>> system, sendmail is installed by default via Solaris in /usr/lib, and
>> configure should pick up on it.  If someone else needs to override
>> this, thenthey should use --with-sendmail.  I think this will all boil
>> down to a preference or philosophy.

I don't see how, particularly given that it's exactly this behavior that
Bill was complaining about in the first place.  :)

> The "people who know enough to be concerned" are a fraction of those who
> install INN.  Is it a service to the rest (the majority) to silently
> pick a sendmail which is not trusted to be in the installer's path?
> Consider that there are plenty of sites which have a junior admin using
> a root account set up by policy or a senior admin who carefully picked
> what was in the path.

How many sites do you think there are who have a sendmail in /usr/sbin or
/usr/lib that they don't want to use?  (Are there *any* sites like this?
Such a setup would cause no end of problems on a regular basis with pretty
much all free software and quite a bit of commercial software.)

How many sites do you think there are that have some random program named
sendmail on the path of the regular user account of someone who might
compile INN?

I find it extremely likely that the second number is significantly larger
than the first, given that looking for sendmail along the path is unusual
and it's a fairly obvious name for some random little script.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list