On Monday, July 3, 2023 7:23:12 AM CEST William Kenworthy wrote: > Inline: > > On 3/7/23 12:52, J. Roeleveld wrote: > > On Sunday, July 2, 2023 4:16:54 AM CEST William Kenworthy wrote: > >> Hi all, > >> > >> I have been using a gentoo mail gateway for many years - its > >> currently > >> > >> running under LXC and is upgraded using a generic LXC "golden master" > >> image > >> with the various email related packages being installed and config files > >> copied across roughly a month or two apart. This is always a trial, > >> particularly with permissions and has become much worse with gentoo's > >> attempt at using the acct packages to manage user and group ID's. > > > > I actually find this easier to solve issues. What do you find difficult > > here? > Trying to interpret an error message that says "it cant connect" with no > detail as to why when started via the openrc service script - but it > works fine when started as the amavis user in debug mode. > > If I try and run it in debug mode from root it produces lots of perl > errors that do not occur with either the openrc service script or amavis > user: > > fetch_modules: error loading optional module Razor2/Client/Agent.pm: > Can't locate Getopt/Long.pm: lib/Getopt/Long.pm: Permission denied > at > /usr/lib64/perl5/vendor_perl/5.36/aarch64-linux-thread-multi/Razor2/Client/A > gent.pm line 15. > BEGIN failed--compilation aborted at > /usr/lib64/perl5/vendor_perl/5.36/aarch64-linux-thread-multi/Razor2/Client/A > gent.pm line 15. > Compilation failed in require at /usr/sbin/amavisd line 212. > fetch_modules: error loading optional module Mail/DKIM.pm: > Can't locate Mail/DKIM.pm: lib/Mail/DKIM.pm: Permission denied at > /usr/sbin/amavisd line 212. > fetch_modules: error loading optional module Mail/DKIM/Verifier.pm: > Can't locate Mail/DKIM/Verifier.pm: lib/Mail/DKIM/Verifier.pm: > Permission denied at /usr/sbin/amavisd line 212. > fetch_modules: error loading optional module Image/Info.pm: > Can't locate Image/Info.pm: lib/Image/Info.pm: Permission denied at > /usr/sbin/amavisd line 212. > fetch_modules: error loading optional module Image/Info/GIF.pm: > and many more!
Which USE-flags do you have? I only have "clamav spamassassin" (the other parts are implemented differently for me) As these are perl modules, did you try "perl-cleaner" to see if that fixes anything? > >> The latest problem driving me up the wall is amavis-new wouldn't start > >> after the upgrade. I have postfix sending email to port 1024 where > >> amavis is listening (this time required a new setting in amavisd.conf > >> not previously needed) but postfix now wont accept email back from > >> amavis on port 10025 so mail is mostly queued (some leaks at times - no > >> idea why). > > > > I assume you mean port 10024 ? > > NO, 10025 - postix is configured to send mail to amavis on 10024 for > scanning via clamav, and forward back to postix on 10025 where its > getting the error In your original email: " I have postfix sending email to port *1024* where " > - note that this configuration has been working for > over 20 years with the same basic configuration until now. I originally > set it up under a "mailuser" group ID and I am increasingly finding that > on startup I have to check files to make sure their permissions are > unchanged. From the reading I have done on this I am suspecting that > this latest version of amavis is trying to enforce "something" but not > telling me what - at this stage I suspect amavis is the root cause and > not postfix. Are you still using "mailuser" ? In " /etc/amavisd.conf ", what is configured for: $daemon_user = ... $daemon_group = ... > >> and what has thrown me: I can stop amavisd, then log in as user "amavis" > >> and run "amavisd -c /etc/amavisd.conf debug" then everything works as > >> intended! WHY? > > > > Does postfix start before or after amavis? > > The startup scripts start amavisd first, but there is no difference if I > manually start amavis after postfix (unless I run it as the amavis user) Ok, so when started as init-script, from root, it fails. when run as amavis, it works. Am wondering if the 2 settings mentioned above have something other then amavis. > >> I am preparing a new mail gateway LXC image as a clean install to try and > >> straighten out the underlying permissions, but a fix for my current > >> dilemma > >> would be appreciated! > > > > If a clean install works, I'd recommend a comparison between the 2 (start > > with a diff for both "/etc") to check the cause. > > Thats what I am working up to but I was hoping someone has seen this > before to save time - its going to be a couple of days before I can get > back to it. I haven't seen this myself, but I have used the default user and group since I set this up. -- Joost
