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

[andre999]

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.

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.

>> 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.
It might be better than making it a require of only msec.

In sum, as long as by mga2, mta is required and msec no longer sends 
alerts by default, that works for me.
But I still think that it would be better to implement it as an update 
before.  (For the reasons indicated above.)

-- 
André