Will it be possible to upgrade from ispconfig3-stable-3.1.tar.gz to 3.1.16?

Discussion in 'General' started by dfumagalli, Aug 10, 2020.

  1. dfumagalli

    dfumagalli New Member


    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
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    dfumagalli likes this.
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
    dfumagalli likes this.
  4. dfumagalli

    dfumagalli New Member

    Thank you very much!
  5. dfumagalli

    dfumagalli New Member

    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.
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Start by updating the master and then update each slave system one after another.
    dfumagalli likes this.
  7. dfumagalli

    dfumagalli New Member

    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?
  8. till

    till Super Moderator Staff Member ISPConfig Developer


    By SSH on the shell with ispconfig_update.sh command.
  9. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    The update script states "Note: Update all slave servers, before you update master server.". Is this incorrect?
  10. dfumagalli

    dfumagalli New Member

    This would be good to know!
    I really don't want to lose my whole servers cluster because of such a small "detail".
  11. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

  12. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
  13. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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?
  14. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    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.
  15. till

    till Super Moderator Staff Member ISPConfig Developer

    @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.
  16. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    elmacus likes this.
  17. Th0m

    Th0m ISPConfig Developer Staff Member ISPConfig Developer

    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."

Share This Page