On Wed, Dec 10, 2008 at 10:12:09AM -0500, James Carlson wrote:
> Ceri Davies writes:
> > On Tue, Dec 09, 2008 at 04:27:41PM -0800, Danek Duvall wrote:
> > > The whole point is that just about every program which doesn't build in
> > > its
> > > own mail transmission code calls /usr/lib/sendmail with a standard set of
> > > options. Given that, you can put a glorified commandline processor at
> > > /usr/lib/sendmail (or /usr/sbin/sendmail, whatev) which then forks off the
> > > appropriate / configured "real" MTA.
> >
> > That's exactly what this case proposes. I've preserved
> > /usr/sbin/sendmail because I don't really know what it's doing there.
> > I don't want to call the mailwrapper binary /usr/sbin/sendmail because
> > it would probably end up being removed by anyone trying to replace
> > sendmail.
>
> I don't think we need to try to code around people who deliberately
> damage their systems. Especially so when the attempt here is
> unsuccessful -- if someone does munge /usr/lib/sendmail, the new
> "mailwrapper" won't be referenced at all because existing programs use
> the /usr/lib/sendmail path explicitly, so having the mailwrapper bits
> rotating around on the disk unused won't actually fix anything.
>
> A big +1 for delivering a wrapper in place of /usr/lib/sendmail, but
> not for the introduction of a new /usr/sbin/mailwrapper binary -- it
> seems exceedingly unlikely that anybody would ever use that new
> pathname, so it'd serve no purpose.
>
> I _think_ your idea here was to allow for a way to people to "fix"
> their systems after having damaged them. But such a way already
> exists -- just reinstall the package. We even include packaging tools
> to detect when packaged bits are damaged in the first place. We don't
> need to squirrel away binaries in unused areas "in case" someone needs
> to recover them.
Hmm, no, that's not what I was trying to do. I'm trying to avoid anyone
having a WTF? moment when they find yet another pathname for sendmail in
/usr/lib that it looks like they'll have to do something with.
I'm specifically trying to make it easy to swap out sendmail, and I
think that for anyone unaware of mailwrapper's presence that ls output such
as the following:
lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq -> ../sbin/mailwrapper
lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/sbin/newaliases -> mailwrapper
lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/sbin/sendmail -> mailwrapper
lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/lib/sendmail ->
../sbin/mailwrapper
-r-xr-xr-x 1 root mail 12396 Nov 25 13:44 /usr/sbin/mailwrapper
is more instructive and self-descriptive than:
lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/mailq -> /usr/lib/sendmail
lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/bin/newaliases ->
/usr/lib/sendmail
lrwxrwxrwx 1 root root 21 Nov 25 13:44 /usr/sbin/sendmail ->
/usr/lib/sendmail
-r-xr-xr-x 1 root mail 12396 Nov 25 13:44 /usr/lib/sendmail
The second gives no clue as to what is going on, while the first should
at least get folk thinking about firing up a manual for mailwrapper.
Ceri
--
That must be wonderful! I don't understand it at all.
-- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081210/4671f607/attachment.bin>
