msec 1.6 was released on July 8th, and appears to have added a new feature that stops services with tcp sockets that aren't whitelisted. Neither the release notes nor the man pages describe how to add a service to the whitelist to that msec will stop killing off my spam filter every morning.
For English, I find http://gitweb.mageia.org/software/msec/tree/src/msec/man.py But I don't understand how it works, because I don't know what the "doc strings of the functions" are. (On a side note: for me, the "\\fB" "\\fR" tags are shown when I see the English man page, which is annoying.) Assigning to all packagers collectively, because there is no registered maintainer for msec. (Weird: I do find translated manpages in http://gitweb.mageia.org/software/msec/tree/man but they're very old .... the man page I get with "LC_ALL=C man msec" contains much more information than the Dutch version that is opened by default on my computer. There is nothing in http://gitweb.mageia.org/software/msec/tree/po/msec.pot about man.py... CC'ing i18n-bugs for that)
CC: (none) => geiger.david68210, i18n-bugs, marja11, thierry.vignaudAssignee: bugsquad => pkg-bugs
Hello, Do you mean 1.16 release? There is no new feature with this release. It is only a bug fix in gui to allow to add exception. The behaviour you observe is not linked to the update. I don't say that there is no bug. @Marja Man pages are not in translation strings. It can be an enhancement, but this is not the aim of of its bug report.
CC: (none) => yves.brungard_mageia
When 1.16 was released, sec started killing my amavisd process every morning. The man pages don't describe this behavior. When I added "amavisd" to /etc/security/msec/server.local the behavior stopped, but I don't see any directives that control the behavior, neither is the purpose or syntax of the server.local file defined.
Hi Daniel, Thank you for having taken the needed time to report this issue! Did this bug get fixed? If so, please change its status to RESOLVED - FIXED If it didn't and you still need the same workaround, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues. If you haven't seen that this bug got fixed in Mga5, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set Version to Cauldron and add MGA6TOO on the Whiteboard. Thanks, Marja
Assignee: pkg-bugs => mageiatools
It doesn't appear that this is happening in Mageia 6 with msec 2.6. One of the upgrades replaced the server.local file and amavisd is no longer listed, so that does not appear to be killing off that process. I had a cron-job that was running at 06:00 every morning to restart amavisd - I've just disabled it, so I will check tomorrow to see if it continues to operate without the restart.
(In reply to Daniel McDonald from comment #5) > It doesn't appear that this is happening in Mageia 6 with msec 2.6. One of > the upgrades replaced the server.local file and amavisd is no longer listed, > so that does not appear to be killing off that process. > > I had a cron-job that was running at 06:00 every morning to restart amavisd > - I've just disabled it, so I will check tomorrow to see if it continues to > operate without the restart. Thanks for the reply. I assume it did indeed continue to operate, because you would have added a comment here next day if it didn't. So closing this report as OLD, because we don't need to keep it for Mga6 and Mga5 is no longer supported.
Status: NEW => RESOLVEDResolution: (none) => OLD