upgrade without affecting "legacy" server?

Discussion in 'Plesk Automation Suggestions and Feedback' started by GregHL, Apr 9, 2014.

  1. GregHL

    GregHL Mega Poster

    we have one server don't want to touch the php on - how can we upgrade our PPA cluster and leave the one server alone - or at least exclude it from upgrading PHP/mySQL/Apache?
  2. Andrey Dobrenko

    Andrey Dobrenko Odin Team


    First of all, PPA management and slave nodes are updated centrally and step by step. If at least one server is not updated properly, then, cluster is in inconsistency state, because part of software is updated, the others are not. Therefore, to prevent such situations, PPA upgrader verifies slave nodes availability, system requirements, misconfiguration and etc and doesn't start upgrade of cluster if one of the node is not accessible or meet requirements by some reasons. Otherwise, it's easy to get broken PPA. So, all nodes are should be always up-to-date w/ PPA management node server.

    What you call legacy server? What OS is used? Probably, you mean how to prevent upgrade PHP because have custom PHP version and don't want to use system PHP provided by OS vendor. it's another case and you are able to skip the updates of specific RPM packages by means of YUM config file modification - just exclude packages needed to not be upgraded. By the way, in PPA 11.5, have a feature to register custom PHP handler and assign this to webspaces. No needs to replace system PHP. Just create and build custom PHP handler and register this one in PPA.

    Additionally, it's quite risky to not apply latest updates from OS vendor. Many security bugs are being fixed and your server can be easy vulnerable if you use not up-to-date software.
  3. JamesJames

    JamesJames Kilo Poster


    The behaviour you described, sounds too idealistic. There are often many servers that we or the customers never wanted to be touched / patched / fixed for whatever reason. There needs to be a way to upgrade only certain selected servers or at the very least exclude certain servers from the "blanket upgrade".

    In Hsphere we can do an upgrade / patch on only one server by using a command like

    U3.60 hspackages ips=xxx.xx.xx.xx

    this will upgrade just one server without affecting all others. If you have 100+ servers, you don't want an issue suddenly affecting ALL your servers and customers. We want to be able to test the patch / update on a select few servers (maybe even a server without a live customer) before rolling it out on all the servers.

    The ability to exclude certain servers, or ideally ONLY upgrade / patch certain servers is very important in hosts with lots of servers to avoid nightmare situations.
  4. Andrey Dobrenko

    Andrey Dobrenko Odin Team


    Let me clarify a little bit the situation around service node updating. Mostly, PPA updates include improvements and bug fixes for Panel itself and rarely we touch slave servers. It happened because PPA (in compare of H-sphere) installs only low-level backend utilities on service nodes to configure hosting, create files and directories, sys. users, to start or stop services and other low-level operations. In that case, all business logic, UI and provisioning tasks are executed on PPA management node - on a central server. In general, PPA backend is pretty much stable and we very rarely a) update utilities which are responsible for applying changes on backend, b) rarely make changes in vhost structure and etc.. It doesn't mean that we never touch nodes, sure, we do this, and if it's happened, update actions are executed on management node for all servers at once. The situation you described and that's being used in H-sphere is questionable for me and maybe dangerous. Because it's easy to get a situation when UPDATED management node may be incompatible w/ not-updated (old) service nodes and any activities in Panel can break hosting configuration on old servers at all.

  5. Andrey Dobrenko

    Andrey Dobrenko Odin Team

    It's a duplicated message.

Share This Page