[Mageia-dev] [RFC] msec (nail) can't send reports to local users accounts - require an MTA?

Anne nicolas ennael at mageia.org
Wed Oct 19 17:51:56 CEST 2011


2011/10/19 Florian Hubold <doktor5000 at arcor.de>:
> Am 19.10.2011 11:01, schrieb nicolas vigier:
>>
>> On Wed, 19 Oct 2011, andre999 wrote:
>>
>>> nicolas vigier a écrit :
>>>>
>>>> On Tue, 18 Oct 2011, andre999 wrote:
>>>>
>>>>> Balcaen John a écrit :
>>>>>
>>>>>> Le lundi 17 octobre 2011 16:39:14 nicolas vigier a écrit :
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>>> I think that :
>>>>>>>    - changing the default configuration in an update is wrong. If
>>>>>>> it's
>>>>>>>      better that msec do not send emails by default, I think this
>>>>>>> change
>>>>>>>      should be done in cauldron only, maybe with some note about this
>>>>>>> change
>>>>>>>      in the release notes for Mageia 2.
>>>>>>>
>>>>>>>
>>>>>> Agree.
>>>>>>
>>>>> A question : wouldn't changing the default in _both_ cauldron and an
>>>>> update
>>>>> to mga1 be acceptable ?
>>>>>
>>>> I think stable updates should not change defaults.
>>>>
>>>>
>>>>> Since I really think that sending messages silently to dead.letter,
>>>>> gradually filling up the disk is a bug.  (When I first discovered the
>>>>> problem on my system a few years ago, dead.letter used about 1G of disk
>>>>> space in my root partition.)
>>>>> That is what happens with the default setting, if an MTA is not
>>>>> installed.
>>>>> At the default settings with an MTA installed, the root mailbox
>>>>> gradually
>>>>> fills up the disk, if it is not emptied.  And a less informed user is
>>>>> unlikely to realise this.
>>>>>
>>>>> So it seems to me that as a minimum, the default should be changed to
>>>>> _not_
>>>>> send alert emails.  Since the status is visible on the main msec
>>>>> screen,
>>>>> informed users should have no problem appropriately adjusting the
>>>>> setting.
>>>>>
>>>>> To deal with the potential problem of users who use the email alert
>>>>> feature
>>>>> having it deactivated by the update, we only need a warning in the
>>>>> update,
>>>>> as often occurs for other packages.
>>>>>
>>>> Updates should not require manual changes. And not everybody read the
>>>> update logs from urpmi. People can expect important changes when
>>>> upgrading
>>>> to a new version of the distribution, and that's why there is release
>>>> notes to explain the important changes, but not for stable updates.
>>>>
>>> Personally I am much more likely to notice the update log message from
>>> urpmi than everything in the release notes.  I make a point of reading
>>> the
>>> former, which necessarily affect an application that I have installed.
>>> Most of the release notes comments are either painfully obvious, or
>>> affect
>>> something that I don't have installed or don't care about, so I tend to
>>> miss many details until I run into a problem.
>>> In this particular case, the problem would be not getting msec
>>> notifications.
>>
>> People should not expect an update to change something that has been the
>> default for years. This kind of change should be done for a new release
>> of the distribution, not in updates. If you don't read the release
>> notes when doing upgrade changing important things, but always read
>> urpmi logs of updates that are supposed to have minimal changes, then
>> you're doing something wrong, but I hope not everybody does that.
>>
>>> Although I realise that in general it would be better to avoid
>>> significant
>>> changes in updates, in this case I think that most users would be better
>>> served by this change being introduced in an update, rather than in a
>>> release.
>>
>> So you want to break something for some user, to improve it for some
>> others ?
>>
>> This has been the default for years. I don't see any reason to urgently
>> change this with an update.
>>
>>>>> Something like "If you use the msec alert emails, please verify that
>>>>> the
>>>>> alerts are still active."  Note that if the user has ever explicitly
>>>>> set
>>>>> alerts, they would be still active.
>>>>>
>>> I was mistaken.  But editing /etc/security/msec/security.conf to add the
>>> line "MAIL_WARN=yes" will protect from a default of "MAIL_WARN=no".
>>> (Tested.)
>>>
>>>>> This potential problem would exist even if the next update for the user
>>>>> is
>>>>> mga2.
>>>>> However, if the update is on mga2 (from changes in cauldron), wouldn't
>>>>> the
>>>>> change in defaults be less visible ?
>>>>>
>>> [...]
>>>>>
>>>>> According to documentation, dma is only active if no other MTA is
>>>>> installed.
>>>>> (I don't know if the priority is what causes this.)
>>>>> So at worst dma would be a (very small) harmless extra install, at best
>>>>> it
>>>>> would ensure the ability for local delivery.
>>>>>
>>>> Then dma could be installed by default on mageia 2, this would fix the
>>>> problem for all programs using the sendmail command, not only msec,
>>>> without adding a require on dma.
>>>>
>>> That would work, as long as it is a "require" of Mageia 2.
>>
>> Not a require, but installed by default. And msec should have a require
>> on sendmail-command.
>>
>>
> So to make this clear for Mageia 1 we keep msec as it currently is, not
> changing
> anything and for Cauldron should i already add Requires: sendmail-command?
>
>
> BTW: Would have been nice if you would have dropped your opinion earlier in
> the
> thread, that would have saved much email noise and you would have prevented
> quite some investigative work which got in there IMHO ...

Would be nice if you keep in mind here is volunteer and may not have
time to answer every threads straight away ;)



-- 
Anne
http://www.mageia.org


More information about the Mageia-dev mailing list