please deactivate services by default!

[Patrice Dumas]

On Thu, Sep 25, 2008 at 06:10:39PM -0500, Matthew Woehlke wrote:
>
>> And I am not playing game with people data,
>
> If local mail suddenly went to /dev/null, and I didn't realize that, you  
> /would/ be playing with my data.

Not suddenly. Between releases and marked in release notes.

>> cron now requires /usr/sbin/sendmail, which is enough in my opinion.
>
> Well then... say so :-). Yesterday would have been a nice time :-).

I said it much before when I listed what dependend on what and what
provided what. But it is not what you want. You want to have local
delivery working in the default case. In order to achieve your goal:

1) we could add a new virtual provides, like
 Requires: mail(local-delivery)
 meaning that the software directly or indirectly provides
 /usr/sbin/sendmail and is configured to do local delivery in the default
 case. exim, postfix and sendmail could then provide that, and even a
 package installing /etc/esmtp.conf with local mail delivered through
 procmail condfigured, depending on procmail and esmtp.
2) we could say that the MTA virtual provides means provides
 /usr/sbin/sendmail, server(smtp), aliases, and the same than
 mail(local-delivery), and have cron depend on MTA. exim, postfix or
 sendmail would then be selected
3) we could change the meaning of the /usr/sbin/sendmail provides, and
 require that it is the same than mail(local-delivery). In that case 
 ssmtp could not provide it anymore since it cannot do local delivery.
4) to select the default program that provides /usr/sbin/sendmail we
 could make sure that it is a program that provides
 mail(local-delivery).

I think that all those are wrong. In my opinion 4) should be considered
when choosing the default programs, but should only be one of the
element to consider when selecting the default application.

> Well, I feel it's a regression for people relying on the previous  
> default; especially if they don't realize anything has changed.

They should read release notes.

> Point of clarification: would installing cron restore the old behavior?  
> (That is, working local mail delivery...) If so, well, it will be hard  
> to set up cron-based backups when cron isn't installed, so effectively  
> 'yum install cronie' will get things working the way they always did.

Unless I am wrong cronie is in the default package set, and so it drags
in /usr/sbin/sendmail dependency. If there is no package in the default
set already providing it, exim would be choosen since the shortest name
wins. But maybe there is a package in th edefault set that provides
/usr/sbin/sendmail.

> Well, obviously I disagree that there is anything wrong with the current  
> local mail behavior for non-root.

It is not wrong, but it is arbitrary. I think that local mail delivery
should not be granted. If the package that that provides
/usr/sbin/sendmail delivers mail locally, then fine, if it doesn't, then
fine too. And, still in my opinion, the upsteram conf should be
followed.

> The whole point has been, don't break things until the mechanism to  
> handle the fallout is in place. Sounds like we've decided to do that.

Maybe what should be done for F10 could be to choose a
/usr/sbin/sendmail provider that is a full blown MTA, and discuss what
functionnalities should the default package providing /usr/sbin/sendmail
have. But it would certainly lead to the same debate.

>> But a random app that provides
>> /usr/sbin/sendmail would also be right, even if it doesn't do local
>> delivery.
>
> ...not this, unless said MTA is reasonably assured to deliver cron's  
> mail, as per my definition (above) of "reliable".

Well, my opinion is that how reliable the /usr/sbin/sendmail is should
be left to the user installing it, or to the default /usr/sbin/sendmail 
provider decision and not be tight to the previous use case.

--
Pat