View previous topic :: View next topic |
Author |
Message |
Perdignus n00b
Joined: 29 Mar 2013 Posts: 42
|
Posted: Tue Jul 28, 2020 12:21 am Post subject: [SOLVED] Amavisd /var/amavis/quarantine Folder now a file? |
|
|
Just upgraded to mail-filter/amavisd-new 2.12.0-r3 and what used to be a folder "/var/amavis/quarantine" is now a file. I used to be able to see the individually banned or SPAM tagged emails in this folder but now it's just a single file.
How does amavisd-release work with this file now? Is this new file that used to be a folder an expected new change or is it perhaps a bug?
Last edited by Perdignus on Fri Jul 31, 2020 9:44 pm; edited 1 time in total |
|
Back to top |
|
|
Perdignus n00b
Joined: 29 Mar 2013 Posts: 42
|
Posted: Tue Jul 28, 2020 12:31 am Post subject: |
|
|
I downgraded back to 2.11.1-r3 and the old behavior of /var/amavis/quarantine being a folder with banned and SPAM tagged emails is now back. |
|
Back to top |
|
|
Perdignus n00b
Joined: 29 Mar 2013 Posts: 42
|
Posted: Fri Jul 31, 2020 9:50 pm Post subject: |
|
|
Turns out the new version has been moved to /var/lib/amavishome and nothing should be in /var/amavis anymore. There is a note after the 2.12.0-r3 upgrade to move all files and folders from /var/amavis to /var/lib/amavishome and then delete /var/amavis but I either missed or disregarded that the first time through.
There are still quite a few remarked lines in the default /etc/amavisd.config that point to /var/amavis but after unremarking them and changing them all to /var/lib/amavishome I was able to start the daemon and banned, quarantined and SPAM tagged emails were placed in /var/lib/amavishome/quarantine and ended up as individual files again.
The only last thing I had to do was to change line 90 of /usr/sbin/amavisd-release to point to /var/lib/amavishome/amavisd.sock instead of /var/amavis/amavisd.sock. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 21867
|
Posted: Fri Jul 31, 2020 11:35 pm Post subject: |
|
|
Perdignus wrote: | The only last thing I had to do was to change line 90 of /usr/sbin/amavisd-release to point to /var/lib/amavishome/amavisd.sock instead of /var/amavis/amavisd.sock. | That sounds like a bug to me. The program should be installed to work with the recommended configuration settings. You wrote that the preferred location is now /var/lib/amavishome, so in my opinion, /usr/sbin/amavisd-release ought to either look there or read a configuration file that tells it where to look. |
|
Back to top |
|
|
Perdignus n00b
Joined: 29 Mar 2013 Posts: 42
|
Posted: Sat Aug 01, 2020 12:44 am Post subject: |
|
|
Hu wrote: | Perdignus wrote: | The only last thing I had to do was to change line 90 of /usr/sbin/amavisd-release to point to /var/lib/amavishome/amavisd.sock instead of /var/amavis/amavisd.sock. | That sounds like a bug to me. The program should be installed to work with the recommended configuration settings. You wrote that the preferred location is now /var/lib/amavishome, so in my opinion, /usr/sbin/amavisd-release ought to either look there or read a configuration file that tells it where to look. |
I don't disagree with you Hu, but I did file a bug report and it was rejected. You can read through it here if you like:
https://bugs.gentoo.org/734796 |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 21867
|
Posted: Sat Aug 01, 2020 4:17 pm Post subject: |
|
|
The comments in that bug suggest, but do not directly state, that you could have a working setup if you revert your change to /usr/sbin/amavisd-release and instead make some unspecified change to the configuration file in /etc. Is that correct? Can you get a working configuration that way? If so, it is annoying to the user that the defaults are inconsistent, but is arguably not a bug. If the only way to make this work is to patch the script, then I would support my prior statement. I think it is poor practice to have an installation that is expected not to work at all without configuration. It's fine if it requires some configuration to get optimal results, but it ought to be able to do some useful work with the default install, unless users would clearly understand that there is no reasonable default possible because use cases are too varied. |
|
Back to top |
|
|
|