Bullseye for ISPConfig

Hello,
@till
if that helps I finally ran into a problem with Postfix...
On two servers (So it can be reproduced) I now have this in the mail logs:

Code:

Sep  2 09:26:07 master3 postfix/lmtp[2921156]: B09454910402: to=<[email protected]>, relay=none, delay=2.3, delays=2.3/0.01/0/0, dsn=4.4.1, status=deferred (connect to 127.0.0.1[127.0.0.1]:10026: Connection refused)

Of course all services are up and running.

I unblocked the situation with this regularly launched command otherwise the mails get stuck in the postfix queue for a while ...

Code:

/usr/sbin/postsuper -r ALL && /usr/sbin/postqueue -f

Some parameters should having change in Postfix or Amavis between Buster and Bullseye.
I will now take the time to find out where ...

All best!

 

I upgraded a mail server tonight and had issues with amavisd-new not listening on 10026.

I ended up having to edit /etc/amavis/conf.d/20-debian_defaults and amend the line
$inet_socket_port = [10024]; # default listening socket
to
$inet_socket_port = [10024,10026]; # default listening socket

which the same as what is inserted into 50-user but was not being overridden.

 

Bonjour @cwispy!

It seems that fixes the problem, thanks for the tip! Well done!

I'm surprised that the variables in /etc/amavis/conf.d/50-user don't override those in 20-debian_default as they did in Buster ...
There must be a reason, the first to find won a chocolate!

 

Salut,

Yes, postfix, amavis, clamav. Multiple times. It doesn't help.

The mails are sent at the end, but sometimes after very long minutes / hours in the queue.
Chaoticly (i didn't found why...) from what I could see But not after restarting the services.

 

Hello,
The @cwispy solution #22 is fine!
Laurent.

 

You are right... I just realize it's not working...
I'll try right now with your solution!

 

Hello,

I can confirm on Debian Bullseye it's working perfectly on 3 installs (Ispconfig 3.2.5 - I haven't upgraded to 3.2.6 yet)

Code:

chown -R root:amavis /etc/amavis/
chmod 644 /etc/amavis/50-user~
chmod 644 /etc/amavis/conf.d/50-user
service amavis restart

Thanks @Jesse Norell

 

Hello Jesse,
You are right. It is safer... ;-)
On Debian by defaut it is 755 (rwxr-xr-x)
Thanks.

 

Just out of curiosity, has anyone noticed this error in the restart of Apache? https://www.howtoforge.com/community/threads/apache-restart-failed.87358/
I installed the 3.2.6 version, but stills need the workaround

 

These are my 2cents on the matter:

I had my test servers (1 master, 1 slave), running on Debian 10 and ISPC 3.2.1. I had used as guideline to install, as usual, the Perfect Server HowTo, with no amavis but rspamd, bind, apache, jailkit, roundcube with ispconfig plugins, from source, and, as suggested, phpmyadmin installed from source. To mimic my production servers, additional services such as postsrsd, postfwd2, postgrey, redis, and php packages from sury were installed using deb packages.

Bafore upgrading to Debian 11 I upgraded to ISPC 3.2.6 (and I used a modified template for postfix since I use services such as postfwd2 and postsrsd) on my slave and master servers (in this order), then, in that same order, I updated Debian 10 packages to latest, upgraded repositories for debian, rspamd and sury. Issued an apt-get update, checked for no errors, and apt-get dist-upgrade. Upgrading went smoothly, all questions about upgrading a config file were answered with a NO. After restarting, issued another apt-get update && apt-get dist-upgrade command, and after verifying which packages would be removed with an apt-get autoremove, I went for it.

After that I checked which php (php and php-cli) version were set default. Strangely, after the upgrade, they were php8 (I had it installed in Debian 10, but no default), so I changed to php7.4, which is default for Debian 11, even though I'm using sury packages and not debian's. I also had to modify my System->Additional PHP Versions in ISPC control panel to reflect the changes from Debian 10 default php to 11. There I also checked all system settings in ISPC control panel, everything but PHP settings (I decided the change the route to php 7.4, since it was kept to 7.3, as it was default in Debian 10), but everything else was in order.

To me this has been the cleanest upgrading procedure EVER. After creating a full hosting package for a test client (email with master and secondary MX servers, email account, alias email, apache+php+mysqldb+wp, web alias, ftp user, primary and secondary dns zones), both previous users and this new user assigned services run fine, no errors in logs. Though these are initial tests, not having differences in logs between debian versions give me good feelings about the upgrade.