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

Wed Oct 19 11:01:23 CEST 2011

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