AppSuite:UpdatingOXPackages: Difference between revisions
No edit summary |
|||
| Line 32: | Line 32: | ||
=== On Debian based distributions === | === On Debian based distributions === | ||
==== Debian Stretch ==== | ==== Debian Stretch ==== | ||
Revision as of 11:52, 4 August 2020
Synopsys: This article describes how to update OX App Suite packages from one service pack to another.
Warnings
Before we begin, here are several things that you should keep in mind:
- If you are updating a cluster, please do it one node after the other. Turn the node off, update, turn it on again, make sure it works in the cluster. Have a look here, too: Upgrading a single node
- If you don't have a cluster of OX nodes, then your complete installation needs to be taken down temporarily.
- Please update the backend before the frontend.
- Please do not restart Open-Xchange during the database update. A database update can happen after installing minor or major updates. As soon as the first user tries to log in to the system or if any provisioning action is done, this update starts.
Upgrading to 7.10.0
- OX App Suite v7.10.0 introduces significant changes regarding the underlying MySQL database system that require special attention in case of upgrades from former versions. Please read AppSuite:7_10_Database_Migration carefully to familiarize with the details, implications and our proposed upgrade path.
- v7.10.0 also requires OpenJDK 8. To update or install v7.10.0 on Debian Jessie, follow these instructions.
How to get updates?
OX App Suite updates can be accessed by customers with a valid license.
In addition, you need to configure the OXReportClient.
Updating OX App Suite Packages
Installing Updates
A new service pack usually introduces new packages and requires configuration changes. To get all required new packages and configuration changes, the following must be done when installing updates.
(Please, keep the warning about backend updates before frontend updates in mind)
On Debian based distributions
Debian Stretch
Add the following entry to /etc/apt/sources.list.d/open-xchange.list
deb http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/stable/appsuiteui/updates/DebianStretch/ / deb http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/stable/backend/updates/DebianStretch /
Then run
$ apt-get update $ apt-get dist-upgrade
Important: In case you are asked in the process if you would like to replace a configuration with the default delivered in the updated package please DO NOT replace but KEEP your existing configuration. In case something needs to be changed mandatorily this will be handled and modified by scripts which run after package installation automatically.
If you want to see, what apt-get is going to do without actually doing it, you can run:
$ apt-get dist-upgrade -s
After the new packages are installed, the open-xchange process needs a restart:
$ /etc/init.d/open-xchange restart
Debian Buster (valid from v7.10.3)
Add the following entry to /etc/apt/sources.list.d/open-xchange.list
deb http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/stable/appsuiteui/updates/DebianBuster/ / deb http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/stable/backend/updates/DebianBuster /
Then run
$ apt-get update $ apt-get dist-upgrade
Important: In case you are asked in the process if you would like to replace a configuration with the default delivered in the updated package please DO NOT replace but KEEP your existing configuration. In case something needs to be changed mandatorily this will be handled and modified by scripts which run after package installation automatically.
If you want to see, what apt-get is going to do without actually doing it, you can run:
$ apt-get dist-upgrade -s
After the new packages are installed, the open-xchange process needs a restart:
$ /etc/init.d/open-xchange restart
On RPM based distributions
RHEL7/CentOS7
Add the following entries to /etc/yum.repos.d/ox.repo:
[ox-updates-appsuiteui] name=Open-Xchange Updates baseurl=http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/stable/appsuiteui/updates/RHEL7/ gpgkey=http://software.open-xchange.com/oxbuildkey.pub enabled=1 gpgcheck=1 metadata_expire=0m [ox-updates-backend] name=Open-Xchange Updates baseurl=http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/stable/backend/updates/RHEL7/ gpgkey=http://software.open-xchange.com/oxbuildkey.pub enabled=1 gpgcheck=1 metadata_expire=0m
and run
$ yum update
$ yum upgrade
After the new packages are installed, the open-xchange process needs a restart:
$ /etc/init.d/open-xchange restart
(Please, keep the warning about database updates in mind)
Updating OX App Suite Packages for older versions
Installing Updates
A new service pack usually introduces new packages and requires configuration changes. To get all required new packages and configuration changes, the following must be done when installing updates.
(Please, keep the warning about frontend updates before backend updates in mind)
On Debian based distributions
If you want to update an older version of Open-Xchange App Suite to the latest maintenance release, add the following entry to /etc/apt/sources.list.d/open-xchange.list. Replace VERSION with the version you are using (e.g. 7.10.3). See AppSuite:Version_Support_Commitment for the currently supported versions. Also, make sure that your repository configuration points at the versioned base installation repositories (instead of using the stable symlink.)
deb http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/appsuiteui/updates/DebianStretch/ / deb http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/backend/updates/DebianStretch /
Then run
$ apt-get update $ apt-get dist-upgrade
If you want to see, what apt-get is going to do without actually doing it, you can run:
$ apt-get dist-upgrade -s
After the new packages are installed, the open-xchange process needs a restart:
$ /etc/init.d/open-xchange restart
On RPM based distributions
RHEL6/CentOS6 (valid until v7.10.3)
If you want to update an older version of Open-Xchange App Suite to the latest maintenance release, add the following entry to /etc/yum.repos.d/ox.repo. Replace VERSION with the version you are using (e.g. 7.10.3). See AppSuite:Version_Support_Committment for the currently supported versions. Also, make sure that your repository configuration points at the versioned base installation repositories (instead of using the stable symlink.)
[ox-updates-appsuiteui] name=Open-Xchange Updates baseurl=http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/appsuiteui/updates/RHEL6/ gpgkey=http://software.open-xchange.com/oxbuildkey.pub enabled=1 gpgcheck=1 metadata_expire=0m [ox-updates-backend] name=Open-Xchange Updates baseurl=http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/backend/updates/RHEL6/ gpgkey=http://software.open-xchange.com/oxbuildkey.pub enabled=1 gpgcheck=1 metadata_expire=0m
and run
$ yum update
$ yum upgrade
After the new packages are installed, the open-xchange process needs a restart:
$ /etc/init.d/open-xchange restart
(Please, keep the warning about database updates in mind)
RHEL7/CentOS7
If you want to update an older version of Open-Xchange App Suite to the latest maintenance release, add the following entry to /etc/yum.repos.d/ox.repo. Replace VERSION with the version you are using (e.g. 7.10.3). See AppSuite:Version_Support_Committment for the currently supported versions. Also, make sure that your repository configuration points at the versioned base installation repositories (instead of using the stable symlink.)
[ox-updates-appsuiteui] name=Open-Xchange Updates baseurl=http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/appsuiteui/updates/RHEL7/ gpgkey=http://software.open-xchange.com/oxbuildkey.pub enabled=1 gpgcheck=1 metadata_expire=0m [ox-updates-backend] name=Open-Xchange Updates baseurl=http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/backend/updates/RHEL7/ gpgkey=http://software.open-xchange.com/oxbuildkey.pub enabled=1 gpgcheck=1 metadata_expire=0m
and run
$ yum update
$ yum upgrade
After the new packages are installed, the open-xchange process needs a restart:
$ /etc/init.d/open-xchange restart
(Please, keep the warning about database updates in mind)
SLES 12 (valid until v7.10.3)
If you want to update an older version of Open-Xchange App Suite to the latest maintenance release, add the following entry to the repository list. Replace VERSION with the version you are using (e.g. 7.4.2, 7.6.0). See AppSuite:Version_Support_Committment for the currently supported versions. Also, make sure that your repository configuration points at the versioned base installation repositories (instead of using the stable symlink.)
$ zypper ar http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/appsuiteui/updates/SLE_12/ OXAPPSUITEUIUPDATES $ zypper ar http://CUSTOMERID:PASSWORD@software.open-xchange.com/products/appsuite/VERSION/backend/updates/SLE_12/ OXBACKENDUPDATES
and run
$ zypper dup -r OXAPPSUITEUIUPDATES $ zypper dup -r OXBACKENDUPDATES
You might need to run
$ zypper ref
to update the repository metadata before running zypper up.
After the new packages are installed, the open-xchange process needs a restart:
$ rcopen-xchange restart
(Please, keep the warning about database updates in mind.
Updating UI plugins
If you update only UI plugins without simultaneously upgrading the core UI packages to a new version, you need to perform an additional step after the update to make the changes visible to users.
The package open-xchange-appsuite contains a timestamp which is different in each version. The JavaScript UI in every user's browser will reload all cached code and data whenever this value changes. Since this value does not change when updating only plugin packages, the value must be changed manually with the following command:
$ /opt/open-xchange/sbin/touch-appsuite --timestamp=20170101.123400
If you only have one OX node, the parameter --timestamp can be omitted. It defaults to the current UTC time anyway.
When updating a cluster, the command must use the same timestamp value on every node. Otherwise, browsers will clear their cache and re-download the entire UI code every time load balancer sends them to a different node (i.e. on almost every login). This is also why the timestamps can't be updated automatically: a node doesn't know which value other nodes will pick, which of them are part of the same update, etc.
The quickest way to obtain a value for the timestamp parameter is to run the command with the parameter -h. It will then print a help message with the current time as an example. For automation, you can use the output of
date -u +%Y%m%d.%H%M%S
Again: this value must be computed once, and then the same value must be used on every node in the cluster.
This step can be performed on each node separately after each node has been updated, or on all nodes at once after all nodes have been updated. If Apache has its own set of dedicated nodes, the touch-appsuite call must be performed on the web server nodes, after all corresponding <plugin>-static packages have been updated.