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

Wed Oct 19 07:16:57 CEST 2011

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é
+
+