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

Wed Oct 19 17:36:06 CEST 2011

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