please deactivate services by default!

[Patrice Dumas]

On Thu, Sep 25, 2008 at 04:04:41PM -0500, Matthew Woehlke wrote:
>
> ...you still need to let them know there is something they need to do,  
> that they never had to do before (which in itself has Irate User 
> potential).

Those who read those mails are not regular users. They are power users.
They should control their setups.

> And I strongly disagree with changing from 'something that always worked  
> before' to 'nothing, with potentially catastrophic consequences if you  
> don't know that we removed functionality' being a good idea.

I disagree on the 'always worked' part. It did something, sure but it
didn't 'worked', at least not for most use cases.

> Obviously, I do :-). You're "removing" a feature I depend on. It would  
> be one thing if you have a way to ensure that I know this has been done  
> so that I can re-enable it. You apparently feel differently.

I don't feel differently. It is what releases notes are for.

> ...because so far I haven't heard that you've ensured people depending  
> on this will know they have to do something special, now. And, as I've  
> pointed out, that lack of knowledge can have severe consequences.

Release notes are for those kind of changes.

> Because - ok, I told myself I wouldn't, but I'm going to pull out the  
> Big Gun now - if Red Hat did this, and I lost data because of it, I'd be  
> filing a lawsuit. Seriously. You're talking about playing games with  
> people's data, and I don't take that lightly.

It is fedora here, not Red Hat. I am in no way affiliated with Red Hat.
If you want to have sendmail installed in RHEL this is not the right
thread. And I am not playing game with people data, if you really care
about root mail being delivered locally you should willingly enable it,
and shouldn't rely on the default configuration of some application
(on a clean install).

> And I don't understand why we're still having this conversation. Several  
> suggestions (that, to me at least, seem perfectly reasonable) have  
> already been suggested. Something in anaconda or firstboot would be best  
> (ideally, you could configure things like if you want logwatch at all),  
> that would make sure you either get a local mail MTA, or are required to  
> click through the Big Scary Warning about the Dire Consequences if you  
> elect not to run one. 

I agree on this point, having something integrated would be nice.

> Or make cron require an MTA. Or possibly both.

cron now requires /usr/sbin/sendmail, which is enough in my opinion.

> I'm willing to blame it on user negligence if they knowingly choose not  
> to have an MTA, or purposefully circumvent cron's normal use thereof. I  
> *don't* consider it acceptable for the default cron setup to be changed  
> from one that (IMO) is effective, to one that silently discards output  
> in a way that the user may not even be aware that there is a problem.

The user could only be aware if he modified /etc/aliases anyway, so
there is no such regression. But this is not the real problem here. The
problem is that the distribution settled to a specific default that is
not generic and effective only in some cases. I think that no default
would be better.

> Why is that so hard to understand?

I do understand that you want backward compatibility for a feature that
you find important. I think there is nothing wrong with that, and
indeed, breaking past stuff is bad. However, breaking backward
compatibility is also needed when something was done wrong and badly
designed and yet made its way in the distro. Having a MTA like sendmail
installed in the default case and started as a daemon was wrong.

> (I happen to disagree, but that's me... Unless you're only talking about  
> the daemon(smtp) part, and not the MTA part that handles local mail.)

I am mostly talking about the server(smtp) part. But also about local
delivery. At least something lighter should be used (maybe a wrapper
script around procmail?). But a random app that provides
/usr/sbin/sendmail would also be right, even if it doesn't do local
delivery.

>> Well it should not be changed within a release, nor by updates, but I 
>> would find it normal to have it broken by clean installs (with release 
>> notes, if possible).
>
> Who reads release notes? :-)

Those who understand that things need to change sometime to be better
designed, even if it is at the expense of their past habits.

--
Pat