Hi all, I'll try to keep the question easy: I think I've run myself into some kind of trap - hope it's not a dead-end street: I have a multiserver setup of 12 machines with a single master - 4 machines are still on Debian Jessie (8), the others on Buster (10) - at least two of them I cannot currently upgrade due to user requirements (no use arguing there ) Anyway, I'm on ISPconfig 3.1.15p3 and would want to go to current stable 3.2.11p1 - I'd also like to at least upgrade the master and 1-2 clients to latest stable Debian release in the process. Now, Jessie isn't listed on ISPconfig's compatibility list any longer and also I can't see how I can upgrade all machines in one go anytime soon. Therefore: - is it possible to upgrade just the master and maybe 1 or 2 clients and leave the others as-is for the time being? What are the changes of anything breaking in the process? - alternatively - has anybody tested the current stable version of ISPconfig on Jessie which would allow me to first pull up all boxes to current ISPconfig stable release and then take care of any OS upgrades whenever there is time? Actually I'd prefer to do option 2 if it is safe to do so, esp. since I eventually upgraded a machine with a backport of PHP 8.1, subsequently breaking some ISPconfig background tasks (needed to force them to use the php7 cli in order to keep on working) - the other way around (tasks breaking because of horribly outdated PHP version on Jessie) would be just as unfortunate... Thanks a lot, Gereon
There will be database compatibility problems when nodes are on different ISPConfig versions. I think the latest version would work on Jessie, but I'm not sure and we can not give any guarantees. (just wondering, why is Jessie required exactly?)
Long story short, we have some users running terribly outdated web apps that rely on the ancient MariaDB, PHP and Perl versions coming with Jessie - I can't see myself upgrading the OS only to then downgrade these specific items again - esp. as I figure PHP might be the limiting factor for newer ISPconfig versions in the first place. I am seriously considering moving some of these apps to docker containers that could then keep running on upgraded machines, but that's going to be a different story. To get back to the issue at hand - I don't assume I could take one of the Jessie slaves out of the setup and reinstall ISPconfig as a standalone master just for testing purposes? (I am retiring one of the machines as the user is migrating to an entirely new software that doesn't need to be controlled via ISPconfig - so it would be a perfect lab rat) - if I wanted to do that, would I just drop the DB schema on the client and delete /usr/local/ispconfig and install from scratch or is there some kind of uninstaller I should use? On the master side I know it's enough to just delete the client entries.
Forgot: Regarding database compatibility problems, are you saying DB changes in newer versions are not necessarily downward compatible? (i.e. older clients connecting to updated master DB may have issues querying items) - or are slaves actually running updates to dbispconfig master DB that could fail due to changed DB structure?
This won't work as the newly installed ISPConfig would be empty, none of the existing sites or other config would get recognized. What might work but s a lot of work might be this: 1) Backup dbispconfig on the slave, just to be able to restore it if needed. And better do a full backup of the system that you can restore. 2) Dump dbispconfig on master and import it on the slave. 3) If the slave has no GUI, you will have to configure it manually by creating the ispconfig vhost and ispconfig.conf file. Edit both config.inc.php files and remove the master database login details so this node stops connecting to master. Then you might have to run an ispconfig update an let the updater finish the GUI configuration, it should do that if it finds the GUI vhost files and symlinks. 3) Now you must clean the database by removing all websites and email domains not belonging to that slave (or leave them there if you don't mind that they are shown on that system). But I have not tested this, so there is no guarantee that this works.
Thanks, Till, that's actually what I would expect - I don't mind an empty ISPconfig, I just want to see that the installation runs through and it is usable afterwards. Like I said, that Jessie box is going to be deconfigured anyway, so it's just meant to be a lab rat for an ISPconfig install on Jessie. If it works, I'll run the upgrade on the whole remaining setup (of course after doing backups, I'm not like swimming in the piranha pool with a bleeding nose ) - if it doesn't, I'll have to figure out how to upgrade the remaining Jessie boxes - _or_ (and there I appreciate your suggestion) I'll take the one or two Jessie boxes that absolutely cannot be upgraded and convert them into standalone instances following your advice. So either way, this has helped me to plan the next steps - thanks a lot and enjoy the rest of the Sunday
Ok as a followup to my question - I finally got a test box cleared with Debian 8.11 installed and the ISPconfig installer ran just fine - UI displays all right, so I think I can safely take the next step in getting my setup up-to-date. Thanks for the help on this matter
