As Dovecot is the major issue in transition what is the best strategy for a heavy email Bookworm ISPConfig server: * Upgrade ISPConfig to 3.3.1 and then upgrade Bookworm to Trixie rather than upgrading to Trixie first? * In another thread it was suggested you should run the ispconfig_upgrade.sh script again after Trixie upgrade. Is this correct? What should I check to see the Dovecot config has been transformed correctly? TIA
You must always update the OS first and then ISPConfig, see other update guides for e.g. Debian 11 to 12, as ISPConfig writes the config files based on the OS. if you would update ISPConfig first, you get a Debian 12 config again and not a Debian 13 config. If email works, it was updated correctly. If you still have dovecot 2.3 config, dovecot won't even start. But if I were you, I would wait until we test the upgrade and publish the upgrade guides.
can't tell if that would work, because on a clean trixie panel does error 500, php8.4-imap is missing so you cannot use system php, only sury, and you have to install systemd-resolved before running install script because it will failed to resolvconf, so yeah definitly wait. And I will start with bookworm
You seem to be installing a new system, but hijacked two other unrelated threads about upgrading Debian 12 to 13. Panel works fine on Trixie; Sury is used by default. So you must have actively chosen to not use it. So the simple solution for your issue is just not explicitly enforce system PHP but use the default instead. You can still limit the number of installed PHP versions. It's fine here; I didn't have to install it. Any working base install should have the ability to resolve names and use resolvconf command. I won't recommend doing that. However, you can make yourself more work if you want. Instead, just install it with default options on an empty but fully working base system (with networking and working name resolution), and you will see everything is working fine.
according to --help default is system so --use-php=system is default; if there is hack for debian13 that does not go that route, then sorry for not knowing that - I used --use-php=8.4 as recommended somehere here by if I recall you, which works fine and does not throw error while installing php8.4-imap ok thats probably my fault, by configuring static IP on ISPConfig I resolved this issue also there is openresoly. Just because I understand you are not a simple end-user I once again had time to reinstall Debian13 from minimal net cd, installed ispconfig with: wget -O - https :// get . ispconfig . org | sh -s -- --use-php=8.4 --monit [email protected] And as soon as it get installed and I go to ip:8080 I see Internal Error 500 in webpage. I wanted to make issue on gitlab but im waiting for approve because I would also like to use trixie were ever I can. Edit /var/log/ispconfig/httpd/<my.fqdn>/access.log 10.4.1.98 - - [29/Jan/2026:23:10:56 +0100] "GET / HTTP/2.0" 500 654 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0" /var/log/apache2/error.log [Thu Jan 29 23:10:56.206259 2026] [fcgid:warn] [pid 56438:tid 56458] (104)Connection reset by peer: [remote 10.4.1.98:42506] mod_fcgid: error reading data from FastCGI server [Thu Jan 29 23:10:56.206285 2026] [core:error] [pid 56438:tid 56458] [remote 10.4.1.98:42506] End of script output before headers: index.php edit 2: I see that apache2 has enabled php8.4-fpm.conf, yet there is no pool in 8.4-fpm/pool.d/ ? maybe thats the issue ? rspamd at 8081 works fine, webmail at 8080 also does work fine, edit3: while digging more I found that monit also has issue: [2026-01-29T22:10:52+0000] error : Unix socket /var/run/php/php8.4-fpm.sock connection error -- Permission denied [2026-01-29T22:10:52+0000] error : 'php8.4-fpm' failed protocol test [DEFAULT] at /var/run/php/php8.4-fpm.sock -- Cannot create unix socket for /var/run/php/php8.4-fpm.sock [2026-01-29T22:10:52+0000] info : 'php8.4-fpm' trying to restart [2026-01-29T22:10:52+0000] info : 'php8.4-fpm' stop: '/usr/bin/systemctl stop php8.4-fpm' [2026-01-29T22:10:52+0000] info : 'php8.4-fpm' start: '/usr/bin/systemctl start php8.4-fpm' Looks like permissions are www-data srw-rw---- 1 www-data www-data 0 Jan 29 23:48 php8.4-fpm.sock Unsure if thats correct as this is the default www. conf in pool.d edit4: another find in /var/log/syslog 2026-01-29T23:45:06.525830+01:00 ispconfig2 mariadbd[56144]: 2026-01-29 23:45:06 262 [Warning] Aborted connection 262 to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (This connection closed normally without authentication) 2026-01-29T23:45:06.526101+01:00 ispconfig2 mariadbd[56144]: 2026-01-29 23:45:06 263 [Warning] Aborted connection 263 to db: 'unconnected' user: 'unauthenticated' host: 'localhost' (This connection closed normally without authentication) I even redownloaded debian-13-net-iso as I was using 13.1 and now use the latest (which is no different because it installed the latest from net anyway, but just saying) edit5: I found out that ['php_ini_path_apache'] = '/etc/php/8.4/apache2/php.ini' is not there, its not there because : libapache2-mod-php8.4 is not installed, sadly installing it and enabling does not resolve this. edit6: I can access http : // ip :8080/robots.txt but even if I add test.php with info that also does not work, so its something with php for that vhost SOLUTION: It looks like there is issue with setting right permissions on a /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter It should be 755 but is 775. to edit it you have to unlock the file: chattr -i /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter chmow 755 /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter
