3.3.1 is basically finished, so that's what's in the development branch at the moment is already most likely 3.3.1; I have to do some final tests today before I release it.
It's great that Ispconig now runs on Debian 13. This installer script: "Perfect Server Automated ISPConfig 3 Installation on Debian 11 and Debian 12, Ubuntu 22.04 and Ubuntu 24.04" Does it also work on Debian 13?
Yes. I'll have to change the title of the article, will do that later today. Thanks for bringing this to my attention.
Not without some quirks. Like using --use-php=8.4 instead of default Like resolving dns issues that are introduce while using dhcp Manualy fixing permission of .php-fcgi-stater Other than that I dont see much of the issue, still testing
This will be done by the installer in the next version when system is being used. These are issues specific to your base system setup only. I tested the installer on different clean Debian 13 systems from various cloud hosters, and your issues do not appear there; ISPConfig works fine out of the box. Nonetheless, I will check your reports.
I'm testing it on https:// cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.3.0-amd64-netinst.iso Which is official Debian iso If ISPConfig supports cloud flavored distro it's ok, but there is no info about it anyway, while claiming it support Debian 13 I would assume it as official version, not flavored one. This was never an issue with older versions but thanks for clarification, but I did not use ispconfig few years so many that changed.
Which is fine. But your base setup should have a working name resolve setup, which you can install using netinst iso too. The packages are resolvconf or systemd-resolved. ISPConfig supports the standard distribution and cloud-flavored ones. Btw. my tests were not on cloud flavored ones That a server is in the cloud does not necessarily mean it's a cloud-flavored distro. Claiming we require a cloud-favoured distro just because ISPConfig needs resolvconf on your system is quite funny, though. ISPConfig supports cloud-based and not cloud-based distributions. I nowhere claimed it supports cloud-based distributions only. But you might keep not using ISPConfig and save us a lot of time.
Default configuration is DHCP with working dns, but as soon as ispconfig is installing (it does that by downloading it via wget - which proves that dns is working) it throw error mid install that resolvconf -u return unexpected results, btw. systemd-resolved which include resolvconf does not support -u parameter so autoinstaller is assuming something because it try to run -u there. That wasn't a bit issue, I handled it in no time and that information can be in an easy way added to guide and/or autoinstaller, but to have it added someone had to feedback if not commit that information. No was was saying anything about resolvconf per se, more about wrong perminissions for php file thats suexec throw error about 755 vs 775, that asside any big cloud provider that provide you with debian installation does it with cloud flavor - because other why it would be plain stupid resource wise. But looks it was communication error from me. Looks like you are unable to check ispconfig autoinstaller on a clean official installation that you installed by installer and not by vm-template. Thats why it looks like it even more important for me to do it over and over and raport back to you what are my finding. But also I will try to test it against clean cloud official image (genericcloud flavor, https:// cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2 ) but I love that blue old CLI installer on iso, never leave ! If you say so You did not claim that, you claimed that you only test it on cloud hosters platforms that don't allow you to install clean official iso but allow you to pick their own flavor template vm machine. Then again you claim that Debian 13 is fully supported, yet any feedback that claim otherwise (or point issues) you mock with bad base setup and local (user) issues. If installing clean official debian 13 iso on a system results in 100% same issues with ISPConfig then it maybe a local (user/mine) issue or maybe it's issue with being fully supported because clean not tempered system act in a different way. I recall that install ispconfig on debian 7,8,9 weren't as straightforward ( all those guides were god send) as it is now days thanks to dedications, testing and maybe (or not) user feedback as someone had to put time and effort to go step by step. And thanks to that autoinstaller does now it itself, and I understand that testing on "one-click-install-os" is great way to test things with or without user interaction. By fixing stuff you get your time saved more. Let just agree that both of us need to just keep on keeping on, have a great day
