This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 472710 - fix cronie MTA requirements
fix cronie MTA requirements
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cronie (Show other bugs)
14
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
: Reopened
Depends On: 548843
Blocks: F14Blocker/F14FinalBlocker SOAS-4
  Show dependency treegraph
 
Reported: 2008-11-23 18:39 EST by Peter Robinson
Modified: 2010-08-09 03:34 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-09 03:34:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peter Robinson 2008-11-23 18:39:49 EST
by adding sendmail as a MTA requirement it pulls in exim which in turn pulls in perl. perl adds around 40 meg. Would it be possible to use a mail delivery agent such as /bin/mail which is slightly more lightweight. This dep tree adds over 10% to the size of OLPC
Comment 1 Patrice Dumas 2008-11-23 19:16:43 EST
If cronie really needs a MTA, then you'll end up with either exim, sendmail or postfix, which I doubt you want on the OLPC. If cronie only requires local delivery, there are 2 possibilities

1. I could add a subpackage to esmtp, such that esmtp does local delivery (through procmail) and the OLPC could then put this package in comps.

The requires having an agreement that 
* cronie needs local delivery
* a virtual provides for local mail delivery is useful

then /usr/sbin/sendmail could be used.

2. /bin/mail could be used, but I am not sure that it really does local delivery itself or through /usr/sbin/sendmail.
Comment 2 Jon Stanley 2008-11-23 22:06:55 EST
Triaged - a few comments here too.

I think that cronie *does* need local delivery, but vixie-cron did not require any sort of MTA (therefore I guess that delivery of cron messages was not guaranteed).

I think that delivery of cron messages is important, so I think that item 1 is fulfilled.  Item 2, OTOH, would require a rebuild of all MTA's (admittedly not many) to provide this requirement.

It looks like mailx (/bin/mail) uses /usr/sbin/sendmail from looking at the code (I'm not the best C guy):

                if ((cp = value("sendmail")) != NOSTR)
                        cp = expand(cp);
                else
                        cp = _PATH_SENDMAIL;
                execv(cp, namelist);

So I think that the benefit of item 2 outweighs the negative, so in the end, I think that's probably what we should go with.
Comment 3 Tomas Mraz 2008-11-24 04:02:10 EST
Cronie needs local delivery as the status e-mails go to local accounts. It uses /usr/sbin/sendmail so the current requirement on /usr/sbin/sendmail seems to be OK. So what is the problem? BTW sendmail package is only 2Mbytes and doesn't require perl.
Comment 4 Patrice Dumas 2008-11-24 04:09:41 EST
(In reply to comment #2)
> Triaged - a few comments here too.
>
> I think that cronie *does* need local delivery, but vixie-cron did not require
> any sort of MTA (therefore I guess that delivery of cron messages was not
> guaranteed).

Yep. Although sendmail was in a comps (maybe in @base) such that it was installed in the default case, and I guess that even if not, exim was pulled as a /usr/sbin/sendmail provides for some other packages, at least for fedora.

> I think that delivery of cron messages is important, so I think that item 1 is
> fulfilled.

Marcela, is it your opinion?

> Item 2, OTOH, would require a rebuild of all MTA's (admittedly not
> many) to provide this requirement.

There are 3 MTA, and esmtp could also provide local delivery.

> It looks like mailx (/bin/mail) uses /usr/sbin/sendmail from looking at the
> code (I'm not the best C guy)

As far as I can tell /bin/mail doesn't requires /usr/sbin/sendmail, though, in my opinion, it should. In the end using /usr/sbin/sendmail with local delivery is indeed better.
Comment 5 Patrice Dumas 2008-11-24 04:10:57 EST
(In reply to comment #3)
> Cronie needs local delivery as the status e-mails go to local accounts. It uses
> /usr/sbin/sendmail so the current requirement on /usr/sbin/sendmail seems to be
> OK. So what is the problem? BTW sendmail package is only 2Mbytes and doesn't
> require perl.

Many other packages than sendmail provides /usr/sbin/sendmail, the real MTA, but also esmtp, ssmtp.
Comment 6 Peter Robinson 2008-11-24 04:17:32 EST
Well given that it never seems to have required any form of mail delivery until the Requires was updated in September if it was an issue I suspect it would have been picked up by now.

Also in the default configuration I suspect that we only email to root which is a local mail account. If someone wanted external mail delivery I suspect they could work it out that a MTA would be required, and in that case would likely have been installed by something else, which I know we shouldn't take as a given, but as we've only just started depending on it I suspect has worked up until now.

procmail is probably actually better than mail now I think of it (or what ever is the default local delivery agent) but neither of them have a dependency on either /usr/sbin/sendmail or the sendmail package.
Comment 7 Marcela Mašláňová 2008-11-24 04:33:37 EST
> Yep. Although sendmail was in a comps (maybe in @base) such that it was
> installed in the default case, and I guess that even if not, exim was pulled as
> a /usr/sbin/sendmail provides for some other packages, at least for fedora.
> 
> > I think that delivery of cron messages is important, so I think that item 1 is
> > fulfilled.
> 
> Marcela, is it your opinion?
> 
Yes, it is.
Comment 8 Marcela Mašláňová 2008-11-24 04:40:59 EST
(In reply to comment #6)
> Well given that it never seems to have required any form of mail delivery until
> the Requires was updated in September if it was an issue I suspect it would
> have been picked up by now.
> 
Some people found this missing requirement as a bug. Adding requirement on /usr/sbin/sendmail should lead to some MTA. I assumed all MTA own /usr/sbin/sendmail, which should provide user's favourite application.
Comment 9 Tomas Mraz 2008-11-24 04:42:28 EST
(In reply to comment #6)
> Well given that it never seems to have required any form of mail delivery until
> the Requires was updated in September if it was an issue I suspect it would
> have been picked up by now.
> 
> Also in the default configuration I suspect that we only email to root which is
> a local mail account. If someone wanted external mail delivery I suspect they
> could work it out that a MTA would be required, and in that case would likely
> have been installed by something else, which I know we shouldn't take as a
> given, but as we've only just started depending on it I suspect has worked up
> until now.
> 
> procmail is probably actually better than mail now I think of it (or what ever
> is the default local delivery agent) but neither of them have a dependency on
> either /usr/sbin/sendmail or the sendmail package.

That it did not explicitely require /usr/bin/sendmail before was a bug. And procmail does not need /usr/sbin/sendmail, because it does the local delivery itself.

Ideally there should exist a simple /usr/bin/sendmail which would know only local delivery and remote delivery through a relay. And actually esmtp+procmail does that. So what's missing is a default configuration for esmtp to use procmail as MDA.
Comment 10 Peter Robinson 2008-11-24 04:45:25 EST
> Some people found this missing requirement as a bug. Adding requirement on
> /usr/sbin/sendmail should lead to some MTA. I assumed all MTA own
> /usr/sbin/sendmail, which should provide user's favourite application.

Or if you don't want or specify a MTA it pulls the first one in the list which provides sendmail which happens to be exim. Exim in turn pulls in perl.
Comment 11 Peter Robinson 2008-11-24 04:51:55 EST
> That it did not explicitely require /usr/bin/sendmail before was a bug. And
> procmail does not need /usr/sbin/sendmail, because it does the local delivery
> itself.
> 
> Ideally there should exist a simple /usr/bin/sendmail which would know only
> local delivery and remote delivery through a relay. And actually esmtp+procmail
> does that. So what's missing is a default configuration for esmtp to use
> procmail as MDA.

ssmtp is even smaller (51K vs 47+62K that makes up esmtp + libesmtp).
Comment 12 Patrice Dumas 2008-11-24 05:00:43 EST
(In reply to comment #11)

> ssmtp is even smaller (51K vs 47+62K that makes up esmtp + libesmtp).

As far as I can tell it doesn't provide local delivery.
Comment 13 Tomas Mraz 2008-11-24 05:03:09 EST
(In reply to comment #10)
> > Some people found this missing requirement as a bug. Adding requirement on
> > /usr/sbin/sendmail should lead to some MTA. I assumed all MTA own
> > /usr/sbin/sendmail, which should provide user's favourite application.
> 
> Or if you don't want or specify a MTA it pulls the first one in the list which
> provides sendmail which happens to be exim. Exim in turn pulls in perl.
You'll have to put sendmail or whatever else in OLPC comps then. cronie cannot specify a concrete MTA as requirement.
Comment 14 Patrice Dumas 2008-11-24 05:15:48 EST
What about
  mail(local)
for the virtual provides corresponding with local delivery?
Comment 15 Patrice Dumas 2008-11-24 09:55:40 EST
I have rebuilt esmtp in F11 with local delivery support in 
esmtp-local-delivery
subpackage, with a virtual provides mail(local)  

So you can use esmtp-local-delivery, which brings in
  esmtp + libesmtp + procmail
instead of a full-blown MTA as a cronie dependency in OLPC (and maybe in
fedora).

Somebody should fill bugs for mail(local) addition to the MTAs, exim, sendmail and postfix.
Comment 16 Bug Zapper 2008-11-26 00:49:54 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Miroslav Lichvar 2008-12-02 07:48:33 EST
Patrice, how exactly does mail(local) differ from /usr/sbin/sendmail?

If mail(local) is added to exim, postfix, sendmail, we will be exactly where we were before, or not?

Also, esmtp+procmail will work only for root process, which might be good enough for cronie, but some other daemons are running with dropped privileges.
Comment 18 Patrice Dumas 2008-12-02 08:13:48 EST
(In reply to comment #17)
> Patrice, how exactly does mail(local) differ from /usr/sbin/sendmail?

It means local delivery is possible and enabled in the default case.

/usr/sbin/sendmail means that the application can send mail using a 
compatible command line.

> If mail(local) is added to exim, postfix, sendmail, we will be exactly where we
> were before, or not?

No, since esmtp+procmail also provides it.

> Also, esmtp+procmail will work only for root process, which might be good
> enough for cronie, but some other daemons are running with dropped privileges.

I don't really get that. Do you mean that exim, postfix and sendmail cannot 
deliver locally to the root account?
Comment 19 Miroslav Lichvar 2008-12-02 08:35:01 EST
(In reply to comment #18)
> > Patrice, how exactly does mail(local) differ from /usr/sbin/sendmail?
> 
> It means local delivery is possible and enabled in the default case.
> 
> /usr/sbin/sendmail means that the application can send mail using a 
> compatible command line.

And that's what cronie uses when sending mail.

> > If mail(local) is added to exim, postfix, sendmail, we will be exactly where we
> > were before, or not?
> 
> No, since esmtp+procmail also provides it.

esmtp provides also /usr/sbin/sendmail.

> > Also, esmtp+procmail will work only for root process, which might be good
> > enough for cronie, but some other daemons are running with dropped privileges.
> 
> I don't really get that. Do you mean that exim, postfix and sendmail cannot 
> deliver locally to the root account?

No, esmtp+procmail can't deliver mail to root when executed under non-root account, something has to have permissions for writing to /var/spool/mail.
Comment 20 Patrice Dumas 2008-12-02 09:06:15 EST
(In reply to comment #19)
> (In reply to comment #18)
> > > Patrice, how exactly does mail(local) differ from /usr/sbin/sendmail?
> > 
> > It means local delivery is possible and enabled in the default case.
> > 
> > /usr/sbin/sendmail means that the application can send mail using a 
> > compatible command line.
> 
> And that's what cronie uses when sending mail.

Indeed.

> > > If mail(local) is added to exim, postfix, sendmail, we will be exactly where we
> > > were before, or not?
> > 
> > No, since esmtp+procmail also provides it.
> 
> esmtp provides also /usr/sbin/sendmail.

Indeed, but ssmtp also provides it. And msmtp could. Though both don't do local delivery.

> No, esmtp+procmail can't deliver mail to root when executed under non-root
> account, something has to have permissions for writing to /var/spool/mail.

Sure. Maybe it may deliver mail if the mailbox already exists. I also remember that procmail could be setuid root for that reason. 

But you are right that mail(local) semantic is in fact:

It means local delivery, at least when running as root, is possible and enabled in the default case.
Comment 21 Marcela Mašláňová 2008-12-15 07:27:02 EST
I'd like to close it, because this is problem of (send)mail. This should be discussed and solved in separate bugzilla or at mailing list.
Comment 22 Peter Robinson 2008-12-15 09:10:36 EST
I agree it should probably be discussed on a mailing list rather than in bugzilla but if that is the case I don't see why it needs a separate bug and by doing so you lose the discussion to date on this bug. I'd like to keep it open for tracking the particular cronie issue. Any objections?
Comment 23 Marcela Mašláňová 2008-12-15 09:19:55 EST
What will be tracking in cronie? I thought for me is this problem fixed by Requires: /usr/sbin/sendmail. All MTA should provide correct files and some of the interested party should fix this or at least reassign this ;-)
Comment 24 Peter Robinson 2008-12-15 09:25:23 EST
I actually don't think it should need/depend on an entire MTA, as an option yes, but not require.
Comment 25 Patrice Dumas 2008-12-15 11:57:16 EST
(In reply to comment #23)
> What will be tracking in cronie? I thought for me is this problem fixed by
> Requires: /usr/sbin/sendmail. All MTA should provide correct files and some of
> the interested party should fix this or at least reassign this ;-)

Nope, it is plain wrong. esmtp and ssmtp provides /usr/sbin/sendmail but do not offer local delivery. Local deliver corresponds with mail(local).

/usr/sbin/sendmail:
the application can send mail using a compatible command line.

mail(local):
Local delivery, at least when running as root, is possible and enabled in the default case.
Comment 26 Peter Robinson 2008-12-15 15:46:34 EST
> /usr/sbin/sendmail:
> the application can send mail using a compatible command line.
> 
> mail(local):
> Local delivery, at least when running as root, is possible and enabled in the
> default case.

So cronie should specify "Requires: mail(local)" as the minimum?
Comment 27 Patrice Dumas 2008-12-15 16:57:55 EST
(In reply to comment #26)
> > /usr/sbin/sendmail:
> > the application can send mail using a compatible command line.
> > 
> > mail(local):
> > Local delivery, at least when running as root, is possible and enabled in the
> > default case.
> 
> So cronie should specify "Requires: mail(local)" as the minimum?

Exactly. 

And before, this Provides should be added to packages that provides 'Local delivery, at least when running as root, is possible and enabled in the default case.'

It is already in the esmtp subpackage I talked about, now it is missing from the 3 MTA (exim, postfix, sendmail). I don't think any other package provides local delivery.
Comment 28 Peter Robinson 2008-12-16 06:34:34 EST
Reopening for cronie to "Requires: mail(local)" rather than /usr/sbin/sendmail.
Comment 29 Miroslav Lichvar 2008-12-16 06:50:03 EST
I think this should be discussed at fedora-devel first.
Comment 30 Peter Robinson 2008-12-16 07:04:02 EST
Yep, just bought it up here http://www.redhat.com/archives/fedora-devel-list/2008-December/msg01660.html but may be a bit off topic
Comment 31 Tomas Mraz 2008-12-16 07:18:07 EST
I do not agree that mail(local) makes the situation much better. You can for example have a situation where ssmtp would be just good enough - on cluster all the mail from the cluster nodes could go to a central mail hub where the local accounts would reside and the users could read the mail.

So I still think that requiring just /usr/sbin/sendmail is perfectly correct.
Comment 32 Patrice Dumas 2008-12-16 08:43:09 EST
See Comment #7. 

If local delivery is not needed, then indeed /usr/sbin/sendmail requires is good enough, and the mail(local) stuff is unuseful (at least until another package needs local delivery).
Comment 33 Bug Zapper 2009-11-18 03:56:50 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 34 Patrice Dumas 2009-11-18 06:39:12 EST
Retargetting rawhide.
Comment 35 Will Woods 2009-12-18 14:38:40 EST
See also bug 548843, which contains patches to allow crond to send job output to syslog instead of using sendmail.
Comment 36 Bug Zapper 2010-03-15 08:10:34 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 37 Peter Robinson 2010-06-29 17:21:27 EDT
Updating to rawhide and adding it as a blocker on F-14. Its been discussed now for 18 months so its time to have it fixed in time for its 2nd birthday.
Comment 38 Marcela Mašláňová 2010-07-01 08:59:34 EDT
I can happily close it. This should be opened on sendmails packages.
Comment 39 Peter Robinson 2010-07-01 15:45:36 EDT
(In reply to comment #38)
> I can happily close it. This should be opened on sendmails packages.    

Umm, no, the package still depends on /usr/sbin/sendmail

Default it should log to syslog now the package has the ability to do that and remove the dependency on sendmail.
Comment 40 Steve Grubb 2010-07-01 16:29:55 EDT
Syslog is not the place I want personal cron jobs to go to. How would I be able to read the results? There is a -m option that can be used to send mail to any program. All that's needed is someone to write a small script to do local mail delivery.
Comment 41 Will Woods 2010-07-01 17:01:06 EDT
The default case should not involve local mail delivery.

If you're adding personal cron jobs *and* you aren't the local system administrator, you're not the default case anymore. Just install sendmail or whichever MTA you like best.
Comment 42 Tomas Mraz 2010-07-01 17:25:53 EDT
So what about changing cronie this way:
1. remove the dependency on /usr/sbin/sendmail from the package
2. if /usr/sbin/sendmail is installed, use it for delivery
3. if not fall back to syslog as if -s is passed instead of giving an error
Comment 43 Will Woods 2010-07-02 12:32:42 EDT
That sounds perfect to me. 

For #3 I think you'd still probably want to emit a warning/info message at startup (or on the first attempt to use sendmail) - something like "no /usr/bin/sendmail, sending job output to syslog". This should help avoid confusion about where job output is going.
Comment 44 Marcela Mašláňová 2010-07-07 01:21:22 EDT
(In reply to comment #42)
> So what about changing cronie this way:
> 1. remove the dependency on /usr/sbin/sendmail from the package
> 2. if /usr/sbin/sendmail is installed, use it for delivery
> 3. if not fall back to syslog as if -s is passed instead of giving an error    

Sounds great. I'll implement it into next release of cronie.
Comment 45 Marcela Mašláňová 2010-07-07 01:36:17 EDT
(In reply to comment #43)
> That sounds perfect to me. 
> 
> For #3 I think you'd still probably want to emit a warning/info message at
> startup (or on the first attempt to use sendmail) - something like "no
> /usr/bin/sendmail, sending job output to syslog". This should help avoid
> confusion about where job output is going.    

Sure. Warning will be needed.
Comment 46 Marcela Mašláňová 2010-07-12 10:28:35 EDT
Fixed in upstream as 5ec2135180c577918c1e1356aad4c67fbb4f832f. It will be fixed with next release of cronie in rawhide.
Comment 47 Bug Zapper 2010-07-30 06:33:34 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 48 Peter Robinson 2010-07-30 08:18:18 EDT
(In reply to comment #46)
> Fixed in upstream as 5ec2135180c577918c1e1356aad4c67fbb4f832f. It will be fixed
> with next release of cronie in rawhide.    

What is the state of getting the next version of cronie into F-14/rawhide?
Comment 49 Marcela Mašláňová 2010-08-03 08:29:56 EDT
Will be fixed in cronie-1.4.5-1.fc14.
Comment 50 Peter Robinson 2010-08-07 11:14:20 EDT
Re-opening. cronie 1.4.5-1 still depends on sendmail at least in the rpm
Comment 51 Marcela Mašláňová 2010-08-09 03:34:51 EDT
Thanks. Removed in 1.4.5-2.

Note You need to log in before you can comment on or make changes to this bug.