Hello, I am about to hit a hard deadline for an Ubuntu 20.04 LTS server. In my intentions, I'd go on and install ispconfig3-stable-3.1.tar.gz created by @till He made it known and available on this thread. My question is: once 3.1.16 is out, will I be able to upgrade from ispconfig3-stable-3.1.tar.gz in the same simple way I used to upgrade from 3.1.15p2 to 3.1.15p3 and similar? Another question: will that server be able to join my current multi-server setup, as 2nd web server (only)? My multi-server setup is all made off Ubuntu 18.04 machines and I created it after I bought the manual with the instructions. Thanks in advance
Yes, but you must update all machines to 3.1dev before you add that new slave and I'm not sure if that's such a good idea for production systems.
Hello again, @till , Your reply has revealed something that is worth investigating. In the PDF manual, I don't think it says the upgrade sequence required to update ISPConfig on multi-server setup. I have a webserver + ISPConfig admin, 1 mail server, 1 database server and 2 DNS servers. Only the webserver has Apache, that's why I put the ISPConfig scripts in there. If ISPConfig must be the same version on all the servers, how do I update it (one server at a time I guess) in order not to break my multi-server? Do I run the update script on the webserver + ISPConfig admin machine first? And then? Which order should I follow? Thanks in advance. Dario F.
I guess the master is the web server (I have only one for now) that also is where I login to the ISPConfig panel, right? Do I have to use the System => Remote Actions => Do ISPConfig-Update link or do I SSH on each server and update ISPConfig from the console?
The update script states "Note: Update all slave servers, before you update master server.". Is this incorrect?
This would be good to know! I really don't want to lose my whole servers cluster because of such a small "detail".
Both ways are possible and have their pros and cons. Personally I prefer to update the master first now, we should consider changing the info in the update script.
If you update a master to the current git-stable and a slave webserver not, that would cause problems with e.g. site backups, right?
You potentially cause problems anywhere schema or client/server interactions change; with the current git-stable having some restructuring and significant changes in backups, yes that would likely create a problem/mess. But even things like adding a column to a table will break master->slave propogations, as the slave doesn't have the new column, so inserting/updating data fails. I've seen those happen; I don't remember first-hand problems caused by upgrading slaves first, but I would expect you could have similar problems, eg. if a slave server made a backup and tried to insert the status/record into the master db when done, it could wreck with schema changes and such. I'd also expect the "reconfigure database permissions in master" step of the update could fail if you do the slave first (trying to set permissions for a table that doesn't exist in the master, etc.). Another good example from current git-stable is the changes in how php versions are tracked; whether you upgrade a slave or the master first, things are going to break if you don't update the other as well. Aside from schema changes, there could potentially be changes to server plugin events that would be inconsistent due to the available data, or even new events defined. On ways to improve this, ultimately when slaves talk to the master via remote api rather than mysql, keep in mind the ability to check both the ispconfig version, as well as (and more importantly) add a version number passed in each remote api function, so that new requirements and "breaking" changes to an api method interface can be versioned, and things can fail (to act) in a predictable way, with a log message stating such. Supporting older/multiple versions of a method could sometimes be done if there were a use case for it. One other thought with the above is to maybe add a flag/state to each server (via the api and local db), so that when an upgrade begins it can be marked, and other actions (for and from that server) could be suspended until the upgrade completes.
@jesse explained the coreb problem, when the database schema does not match, then all kinds of operations can fail. I recommend to enable maintenance mode on the master before you start updating the servers in a multiserver setup, this ensures that customers can not do changes until all systems are on the same version again.
The ISPConfig update instructions in https://www.faqforge.com/linux/controlpanels/ispconfig3/how-to-update-ispconfig-3/ should be amended to include this info. i.e. for multiserver setups turn on maintenance mode on master, update master first, and after all slaves are updated turn off maintenance mode.
And on update, show "Enable maintenance mode and update your master server first. Then update all slave servers, and disable maintenance mode when the updates are done."
