RE: [ITP] Sendmail 8.14.9

["Pierre A. Humblet" <Pierre.Humblet@ieee.org>]

> -----Original Message-----
> From: Corinna Vinschen
> Sent: Thursday, August 28, 2014 12:00
> 
> On Aug 28 12:27, Corinna Vinschen wrote:
> > On Aug 27 11:16, Pierre A. Humblet wrote:
> > > > From:  Corinna Vinschen
> > > > Anyway, to have some working example, here's how Fedora does it:
> > > >
> > > > The binaries, or symlinks to the actual binaries are called:
> > > >
> > > >   /usr/sbin/sendmail.sendmail
> > > >   /usr/bin/mailq.sendmail
> > > >   /usr/bin/newaliases.sendmail
> > > >
> > > >   /usr/sbin/sendmail.exim
> > > >   /usr/bin/mailq.exim
> > > >   /usr/bin/newaliases.exim
> > > >
> > > >   /usr/sbin/sendmail.postfix
> > > >   /usr/bin/mailq.postfix
> > > >   /usr/bin/newaliases.postfix
> > > >
> > > >   [analog for other MTAs]
> > > >
> > > > Sendmail, mailq, newalias (etc.) are alternatives symlinks:
> > > >
> > > >   /usr/sbin/sendmail -> /etc/alternatives/mta
> > > >   /usr/bin/mailq -> /etc/alternatives/mta-mailq
> > > >   /usr/bin/newaliases -> /etc/alternatives/mta-newaliases
> > > >
> > > > And in /etc/alternatives are the symlinks to the actual binaries,
> > > > as configured by postinstall or the user:
> > > >
> > > >   /etc/alternatives/mta -> /usr/sbin/sendmail.exim
> > > >   /etc/alternatives/mta-mailq -> /usr/bin/mailq.exim
> > > >   /etc/alternatives/mta-newaliases -> /usr/bin/newaliases.exim
> > > >
> > > > In fact, there are more than these three symlinks, mainly to rmail
> > > > and to the man pages for the aforementioned binaries.
> > > >
> > > > Maybe we can shamelessly borrow this scheme?!?
> > > >
> > >
> > > I am fine with the idea, except that I don’t see the need for things
> > > such as /usr/sbin/sendmail.exim The executables can be installed in
> > > the current locations (/usr/bin for exim) and symbolic links such as
> > > /etc/alternatives/mta can point directly to the executables.
> >
> > That's ok, I guess.
> >
> > > Also it
> > > looks like we don't need to use the alternatives package itself,
> > > although we reuse the /etc/alternatives directory and naming scheme
> > >
> > > Below is what I would do in the MTA postinstall and -config files,
> > > using mailq as an example I am assuming that /usr/bin/mailq will not
> > > be created by setup.
> > >
> > > In the postinstall:
> > > If /usr/bin/mailq is a symbolic link NOT already pointing to
> > > /etc/alternatives/mta-mailq {
> > >            create a symbolic link /etc/alternative/mta-mailq pointing to
> /usr/bin/mailq's target
> > >            replace the target of /usr/bin/mailq to
> > > /etc/alternatives/mta-mailq } else if /usr/bin/mailq is a file {
> > >            rename /usr/bin/mailq to /usr/bin/mailq.somemta
> > >           create a symbolic link /etc/alternatives/mta-mailq pointing to
> /usr/bin/mailq.somemta
> > >           create a symbolic link /usr/bin/mailq to
> > > /etc/alternatives/mta-mailq
> 
> This part won't work as expected btw.  If the sendmail package installs the
> actual binaries under the names reserved for the symlinks to the user-
> defined MTA tools, then you change the installation.
> 
> Consider what happens when you have an exim installation and deliberately
> or accidentally install sendmail:  It will overwrite your symlinks and break a
> perfectly fine exim installation.
> 
> Same when uninstalling: Assuming you have exim and sendmail installed,
> with the symlinks pointing to exim, then you uninstall the sendmail package.
> Setup will remove the symlinks but the "mailq.somemta"
> binaries will stay in /usr/bin since setup doesn't know about them.
> 
> I think the right thing to do would be to install either renamed binaries, as
> Fedora does it, or to keep the names and install the binaries into some
> different directory (perhaps something like
> /usr/lib/sendmail/bin) and symlink to this dir.

I was assuming that from now on no package would ever install /usr/bin/mailq (etc). Only postinstalls would create it. 
With that assumption, I don't understand what you mean but I may not have given enough info.

The stuff in the postinstall is only meant for the transition phase when /usr/bin/mailq (etc) is NOT pointing to /etc/alternatives/mta-mailq.

Today the only Cywin package creating /usr/bin/mailq is exim, AFAIK. It is a symlink pointing to /usr/bin/exim. If an updated exim is installed before sendmail, setup should have removed the old /usr/bin/mailq, a new one will be created in the postinstall as outlined and things will be OK.

If for some reason the old one is not removed (or if sendmail is installed before exim is reinstalled), /usr/bin/mailq will be set to point to /etc/alternatives/mta-mailq, which be set to point to /usr/bin/exim. So the exim installation is OK.

The case where /usr/bin/mailq is a file is only meant to cover the case where a user has compiled and installed some package (not through setup) that contains a binary /usr/bin/mailq. It would be renamed to mailq.somemta, not breaking anything.

But you are right that there is a flaw: if sendmail is installed before exim is updated, the sendmail postinstall will have created the new link, eventually pointing to exim. Exim would keep working fine. The user could then (during sendmail-config)  change the link to point to sendmail. If the user then uninstalls exim the /usr/bin/mailq link will be deleted (I presume), breaking sendmail.

Note that if exim was updated (instead of uninstalled), /usr/bin/mailq would also be deleted but the exim postinstall would create a new link to /etc/alternatives/mta-mailq. As that symlink already points to the sendmail.mailq the sendmail installation would be OK.
I don't see how we can handle the bad case. Renaming binaries won't help. 

Breaking mailq or newaliases doesn't bother me much as people using them should be able to handle the problem. I am more concerned by changes to the /usr/sbin/sendmail symlink, which is used by 3rd party programs. However is was not created by setup and thus the flaw discussed above does not exist.

Pierre