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

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
+