On 04/08/2007 11:08 PM, Ville Skyttä wrote:
Hello,
Are the meanings of Provides: MTA and Provides: smtpdaemon documented
somewhere, or can someone tell with confidence what they mean/imply?
I thought that a Provides: smtpdaemon would mean a service that runs a local
SMTP service daemon and Provides: MTA something sendmail command line
compatible that can send mail; filed some bugs, but it appears that there are
some disagreement over their purposes.
https://bugzilla.redhat.com/235594
https://bugzilla.redhat.com/235596
https://bugzilla.redhat.com/188400
Unless they already are, these things should be documented somewhere. I
started http://fedoraproject.org/wiki/VilleSkytt%C3%A4/VirtualProvides to
collect info - feel free to comment and add info and whatever is missing.
Note to readers: this mail should be seen as a continuation for
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235596#c5 . However
I feel it is more appropiate to bring it to the list since it touches
the problem of ssmtp (which I maintain).
Just for the practical problem, let me explain what my needs were
and the reason for which ssmtp provides smtpdaemon. For a start, one
needs to know that (especially since the era when sendmail exhibited the
nice remote root exploits) I hate keeping daemons running unless they do
something useful and I will definitely do my best to not run a mail
daemon on several dozens/hundreds machines just to be able to receive
alerts from them. And no, relaying from time to time an alert like "hard
disk X is defective", "/dev/md1 failed" or a daily log does not qualify
as something useful for usage of a full blown MTA. Please also think of
small devices (like in embedded routers without a hard disk, but
everything on a compact flash or a USB stick) which just need to relay
their status and/or alerts.
The start of the story were mdadm (and hdparm which is just slightly
different). The mdadm package requires smtpdaemon. According to my tests
(via strings /sbin/mdadm), what mdadm really needs is to be able to use
"/usr/sbin/sendmail -t". By default, hdparm needs to be able to run the
"mail" command (it does have the ability to call a custom script, but I
am talking about the defaults) which in turn will call sendmail too.
Now, let's see in turn each one of the packages which provide
smtpdaemon:
- sendmail (as provided by the sendmail package): not sure about the
newer version 'cause I haven't used for more then 3 years, but "back in
the old days", the daemon did not really need to be started in order to
send mail from the command line,
- postfix will queue but NOT deliver the messages as long the daemons
are not started,
- ssmtp does not include a daemon at all, but will happily deliver the
message the instant it is called,
- AFAIK, esmtp will perform the job just like ssmtp does, but does not
provide smtpdaemon,
- cannot speak for exim, as I have used it only for 3 days and that was
6 years ago during my sendmail era.
So, for this particular case what I (mind that I did not say we)
really need is just a sendmail-like command line program which is able
to relay the mails without running a daemon on the machines where the
program runs. And that is more or less all that is needed (give or take
authentication and ssl). Sendmail fits the bill, but is very large (once
again: think of a total storage of 256/512 MB MB); postfix does NOT fit
the bill because it must have a running daemon (and is large, too...);
ssmtp and esmtp do fit the bill, but they would not be picked at install
time (not even via a kickstart file) unless they provide smtpdaemon. In
other words, ssmtp is the perfect tool for my need, but I could not
install it cleanly INSTEAD of sendmail/exim/postfix because mdadm
requires smtpdaemon. So
- sendmail and postfix provide MTA, /usr/sbin/sendmail and smtpdaemon,
but in my case none of them fits the bill (I do not want a running
daemon, both are very large);
- esmtp only provides /usr/sbin/sendmail, so it is not seen by mdadm as
a suitable Provides
- ssmtp provides everything that sendmail provides, and this on purpose
(to allow it to be used instead of sendmail); being a send-only
application, probably ssmtp should NOT provide smtpdaemon, but otherwise
it could not be used as a drop-in replacement for postfix/sendmail.
As far as I can see, the clean solution would be to have mdadm (and
smartd) require /usr/sbin/sendmail (paranthesis: smartd comes from
kernel-utils, which does not require any mailing features and just fails
happily if there is none installed; and mail -- which is used by smartd
-- comes from mailx which uses sendmail but does not require it) and
drop Provides: smtpdaemon from ssmtp. But until mdadm is fixed, dropping
smtpdaemon as Provides would lead to the above mentioned problem. I
could of course maintain my own local repo with a customized version,
but it would not be available to all the admins I have persuaded to go
"my way", not to mention that I do not feel comfortable overriding the
official package unless a very very special need exists which can not be
accommodated by upstream. And this ends my talk about smtpdaemon. [*]
As of MTA... In the summary and in the description esmtp and ssmtp
both define themselves as MTA, despite none of them being able to
process queues or receive mails. Patrice decided that esmtp should not
provide either MTA or smtpdaemon, just /usr/sbin/sendmail. To say the
truth, I would not have started using (and later on, packaging) ssmtp in
the first place if I would have been able to use esmtp directly as a
sendmail drop-in replacement.
[*] I assume that from the very beginning the correct solution would
have been to file a bug against mdadm, not making ssmtp provide
smtpdaemon. In my defense I can only say that at the time I did not even
think at mdadm as having a wrong Requires, I thought that was the normal
way (core packagers know best, don't they ?) and that this was the
feature that ssmtp should provide, too.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
