installing lsb requires postfix

I have tried to install the "lsb" package on Karmic and postfix still gets automatically installed. So this bug is not fixed for Karmic.

Launchpad Bug Tracker wrote:
> Is it normal (and absolutely necessary) that when one installs lsb, postfix is pulled at the same time from the requirement ?
> Installing a daemon is not something that trivial from a security point of view and there are many case where lsb might be needed on a machine where postfix is useless.

The LSB includes the "sendmail" command, which must be present. One way
to provide this command is to install a full MTA, such as postfix.

There are a few "light" mailers that also provide the sendmail command.
 I tend to use "ssmtp" on systems that don't need a full MTA.

This was discussed several times already (also see upstream bug). One workaround is to only depend on a particular lsb submodule.

However, the entire idea of requiring an MTA is pretty impractical. A cripped MTA like nullmailer would basically just send mails to /dev/null, and a real MTA like postfix is a potential security hole.

The actual flaw here is that it encourages applications to rely on being able to send local mail, forget about it, and assume that the user actually read it.

Thanks for the hint, Jeff. I have now run

sudo apt-get install ssmtp

and postfix got smoothly replaced by ssmtp, without lsb or any package from OpenPrinting being uninstalled. Having a look at the files contained in ssmtp with

dpkg -L ssmtp

shows that there is no daemon (No file in /etc/init.d/).

Now the only problem is that we must make the use of ssmtp automatic, so that postfix does not get installed when a user tries to install an LSB package, especially a manufacturer-supplied printer driver.

First, ssmtp needs top be moved into main, a MIR (Main Inclusion Request) needs to be posted. In addition it needs to be added to the CDs, but it is very small:

till@till-laptop:~/printing/openprinting/website$ dpkg -p ssmtp | grep -i size
Installed-Size: 8
Size: 54436
till@till-laptop:~/printing/openprinting/website$ ls -l /var/cache/apt/archives/ssmtp_2.62-3ubuntu1_amd64.deb
-rw-r--r-- 1 root root 54436 2009-05-04 23:07 /var/cache/apt/archives/ssmtp_2.62-3ubuntu1_amd64.deb
till@till-laptop:~/printing/openprinting/website$

Perhaps one can even remove postfix from the desktop CDs (if it is there).

As a next step a prioritization needs to be done, so that the virtual package mail-transport-agent pulls ssmtp by default.

Till Kamppeter [2009-06-12 14:54 -0000]:
> Now the only problem is that we must make the use of ssmtp automatic, so
> that postfix does not get installed when a user tries to install an LSB
> package, especially a manufacturer-supplied printer driver.

As I pointed out, I'd object to that. We did such a thing in the past
(ship a cripped MTA by default), and people didn't like us for that.

The LSB requirement was certainly not written with the idea in mind to
swallow all input to sendmail into a big black hole.

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

If we cannot get rid of postfix being pulled by the installation of the lsb package, can we at least make the postfix installation completely automatic? Currently when one installs postfix, it asks the user which kind of mail server he wants to have. Users do not know what to answer there, as they usually have installed some application program or printer driver. I would suggest that postfix simply installs with the local-only configuration in such a case.

Martin Pitt wrote:
> The actual flaw here is that it encourages applications to rely on being
> able to send local mail, forget about it, and assume that the user
> actually read it.

The requirement is actually an effect, not a cause, of that
encouragement. We've got 20+ years of history behind the sendmail
expectation, and many apps that predate the LSB and even Linux which
expect it.

Martin Pitt wrote:
> As I pointed out, I'd object to that. We did such a thing in the past
> (ship a cripped MTA by default), and people didn't like us for that.
>
> The LSB requirement was certainly not written with the idea in mind to
> swallow all input to sendmail into a big black hole.

No, but ssmtp is neither a full MTA nor a "black hole". It requires
less configuration than postfix. It may not be the ideal solution, but
it may represent an improvement.

Till Kamppeter [2009-06-12 17:15 -0000]:
> If we cannot get rid of postfix being pulled by the installation of the
> lsb package, can we at least make the postfix installation completely
> automatic? Currently when one installs postfix, it asks the user which
> kind of mail server he wants to have. Users do not know what to answer
> there, as they usually have installed some application program or
> printer driver. I would suggest that postfix simply installs with the
> local-only configuration in such a case.

It is a possibility, but if you just hit "no configuration" (the
default), it won't ask further questions. If we skip the entire
debconf interface by default, we would make it much harder for people
who actually want to set up a mail server.

Jeff Licquia [2009-06-12 17:43 -0000]:
> No, but ssmtp is neither a full MTA nor a "black hole". It requires
> less configuration than postfix.

Not really. It takes the same number of questions to tell postfix or
ssmtp to just relay your mail to <email address hidden>. The "I
installed acroread.deb and it asks me for my mail setup?" confusion
is the same either way.

But if I do "sudo apt-get install ssmtp" I get no question asked. So if the lsb package pulled by acroread.deb pulls ssmtp, the user does not get asked any question and can use acroread.

Till Kamppeter [2009-06-12 18:21 -0000]:
> But if I do "sudo apt-get install ssmtp" I get no question asked. So if
> the lsb package pulled by acroread.deb pulls ssmtp, the user does not
> get asked any question and can use acroread.

Right, but that's exactly my point: Then you have a sendmail command
with broken and undefined behaviour, which breaks applications which
actually do use sendmail.

I'm amazed that it hasn't crossed anyone's mind that the LSB mind be hopelessly backward thinking, when it expects sendmail to be present upon every system. In honesty, too many of the LSB specification's elements point to a fixed-IP network built of traditional UNIX hosts. That paradigm hasn't been anywhere close to representing real life Internet usage of average Joe Buntu desktop user or of other non-server Linux usage cases for a long time.

We need to find a solution here so that the desktop user can install printer drivers and modern desktop applications (they both do not send local e-mail) without getting questions asked.

Why does one not distinguish between a server and a desktop. On a server one installs postfix as it is now and on a desktop one either installs postfix non-interactively (local-only configuration) or ssmtp.

We need the possibility to easily drop applications and printer drivers on a modern desktop machine, which is usually connected to the Internet via a NAT router (which has a dynamic IP into the internet and gives IPs to the local network vis DHCP or Zeroconf) and sending mail is mamaged by an external service on the internet.

Martin-Éric Racine wrote:
> I'm amazed that it hasn't crossed anyone's mind that the LSB mind be
> hopelessly backward thinking, when it expects sendmail to be present
> upon every system. In honesty, too many of the LSB specification's
> elements point to a fixed-IP network built of traditional UNIX hosts.
> That paradigm hasn't been anywhere close to representing real life
> Internet usage of average Joe Buntu desktop user or of other non-server
> Linux usage cases for a long time.

The sendmail spec in the LSB is an interface: nothing more. It does not
have to be a full MTA any more than, say, printf(3) must be a kernel
interface.

We have shopped around the idea of dropping sendmail, and met with
strong opposition from many of our ISVs. People rely on sendmail being
there today.

If Ubuntu is not happy with postfix as their default implementation of
the sendmail interface, we invite them to choose a lightweight
alternative. I believe several are even provided in Ubuntu already;
they certainly are provided in Debian, and could easily be pulled in. I
have personally had good luck with ssmtp; although it requires some
configuration, the burden is not nearly as high as with postfix.

Alternatively, you're free to explore a better standard interface for
sending mail than sendmail, and getting ISVs on board with it. Apart
from our deprecation policy, we're not married to the specific sendmail
interface. As long as ISVs are happy with the functionality they're
provided, we can change it.

What about splitting the LSB, for example defining in the LSB (not only in Ubuntu) subspecs like lsb-common, lsb-server, lsb-desktop, lsb-print, ...? Then I would let the printer drivers depend on lsb-print and not on lsb, then only lsb-common (lsb-print depends on it) and lsb-print would be pulled. lsb-server (which requires sendmail) is not needed then. A server app from an ISV which must be capable to send out e-mail notificationsbut not able to print would depend on lsb-server. WDYT?

For solving this problem in Ubuntu, we should really find a non-interactive solution based on postfix or ssmtp. This would solve the problem once for users who do not need the MTA, as users who install an LSB-based printer driver or desktop application and users who really need an MTA are ususally server admins or developers who know that they need to configure the MTA in order to use it,

This is nothing to do with the postfix package.

This was discussed to death with upstream in https://lists.linux-foundation.org/pipermail/lsb-discuss/2009-June/006031.html . I don't think they'll move away from this silly requirement.

So what we could on on the Ubuntu side is to default to a "invalid-m-t-a" package which implements /usr/bin/sendmail as "exit 1", and if people actually need an MTA, they can pick and install one.

pitti, we should do it this way, but we do not create a new source package for it. Let us create a binary package named "invalid-mta" as part of the "lsb" source package and make sure that it is installed with priority when installing "lsb" and no MTA is installed.

Attached is a debdiff for the "lsb" package to add the "lsb-invalid-mta" binary package. This package provides a fake /usr/bin/sendmail which simply errors out when getting called. A warning message on stderr will make the user aware that he needs to install an MTA if he wants to use the sendmail command.

The debdiff fixes also an additional bug: The LSB from version 3.2 on requires the printing environment of lsb-printing. Therefore I have moved lsb-printing into the "Depends:" of the "lsb" binary package.

Till, there are a few things which need fixing:

 - changelog indendation is wrong (line 10 ff)
 - sendmail needs to go into /usr/sbin/
 - lsb-invalid-mta needs to conflict to mail-transport-agent (see postfix for example)

Of course this is an utter hack, but from my POV it looks okay under the given restrictions.

Martin Pitt wrote:
> So what we could on on the Ubuntu side is to default to a
> "invalid-m-t-a" package which implements /usr/bin/sendmail as "exit 1",
> and if people actually need an MTA, they can pick and install one.

My only request: exit -1 instead of exit 1, per the spec:

http://refspecs.linuxfoundation.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/baselib-sendmail-1.html

pitti, fixing the changelog and the /usr/sbin/sendmail are no problem.

For lsb-invalid-mta I have now bothe a Provides and a Conflicts on mail-transport-agent. The Provides is needed to satisfy bsd-mailx as this package requires mail-transport-agent and is required by mailx which is required by lsb. I have tested installing the new lsb-invalid-mta end even that it conflicts with itself it installs correctly.

New debdiff attached.

Jeff, the "exit" command seems not to support -1:

till@till:~/ubuntu/lsb$ /usr/sbin/sendmail ; echo $?
Please install an MTA on this system if you want to use sendmail!
exit: 3: Illegal number: -1
2
till@till:~/ubuntu/lsb$

Till Kamppeter [2010-02-23 9:05 -0000]:
> I have tested installing the new lsb-invalid-mta end even that it
> conflicts with itself it installs correctly.

This is a special case with combining Conflicts:/Provides:, and is
meant to be used for exactly this use case: "Ensure that only one
package is installed which provides this":

  http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Till Kamppeter [2010-02-23 9:11 -0000]:
> Jeff, the "exit" command seems not to support -1:

"exit 255" in shell will do the equivalent. Or rather, "exit(-1)" in C
is equivalent to "exit(255)", since the exit code is a byte.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Jeff, thank you for reporting this. I have corrected it in the new attached debdiff.

pitti, thanks for the hint with the exit code.

This bug was fixed in the package lsb - 4.0-0ubuntu8

---------------
lsb (4.0-0ubuntu8) lucid; urgency=low

  * sendmail, debian/control, debian/rules, debian/lsb-invalid-mta.dirs:
    Added new binary package "lsb-invalid-mta" containing a fake
    /usr/sbin/sendmail so that the installation of LSB packages does not
    pull in an MTA any more, which once adds awkward configuration questions
    to the installation process and second adds an often unnneeded daemon to
    the system (LP: #141641).

  * debian/control: The LSB requires the printing environment already
    since version 3.2. Made lsb-printing required by the "lsb" package
    not only suggested (LP: #386128).
 -- Till Kamppeter <email address hidden> Mon, 22 Feb 2010 23:50:49 +0100