parent
2fc3af6a86
commit
586cfe40d6
5 changed files with 70 additions and 49 deletions
|
@ -2,20 +2,28 @@
|
|||
|
||||
== Upgrading the {project_name} server
|
||||
|
||||
Follow these guidelines to be sure the server upgrade is successful:
|
||||
|
||||
* Test the upgrade in a non-production environment first to prevent any installation issues in production,
|
||||
* Upgrade the {project_name} server before upgrading the adapters. Also ensure the upgraded server is functional in production before upgrading adapters.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
The steps covered in this section are the default upgrade procedure, and may not always be possible due to manual changes required to the configuration guide.
|
||||
|
||||
Please refer to the migration changes for details on the version you are upgrading to.
|
||||
This upgrade procedure may require modification due to manual changes that are specific to your installation. For details on manual changes that might affect the upgrade, see xref:release_changes[Release-specific changes].
|
||||
====
|
||||
|
||||
It is important that you upgrade {project_name} server before upgrading the adapters.
|
||||
ifeval::[{project_product}==true]
|
||||
Upgrade the server from a xref:upgrade-zip[ZIP file] or an xref:rpm-upgrade[RPM] based on the method you had used for installation.
|
||||
|
||||
[id="upgrade-zip"]
|
||||
=== Upgrading the server from a ZIP file
|
||||
endif::[]
|
||||
|
||||
.Prerequisites
|
||||
* Handle any open transactions and delete the data/tx-object-store/ transaction directory.
|
||||
|
||||
.Procedure
|
||||
. Download the new server archive
|
||||
. Download the new server archive.
|
||||
. Move the downloaded archive to the desired location.
|
||||
. Extract the archive. This step installs a clean instance of the latest {project_name} release.
|
||||
. For standalone installations, copy the `{project_dirref}/standalone/` directory from the previous installation over the
|
||||
|
@ -30,32 +38,19 @@ NOTE:
|
|||
Files in the bin directory should not be overwritten by the files from previous versions. Changes should be made manually.
|
||||
|
||||
. Copy any custom modules that have been added to the modules directory.
|
||||
. Run the applicable upgrade script below.
|
||||
|
||||
[id="upgrade-script"]
|
||||
== Run the server upgrade script
|
||||
|
||||
Based on your previous installation, run the appropriate upgrade script that applies to your situation:
|
||||
|
||||
ifeval::[{project_product}==true]
|
||||
* xref:rpm-upgrade[RPM distribution]
|
||||
endif::[]
|
||||
* xref:standalone-mode[Standalone mode]
|
||||
* xref:standalone-ha[Standalone high availability mode]
|
||||
* xref:domain-mode[Domain mode]
|
||||
* xref:domain-clustered[Domain-clustered mode]
|
||||
. Continue with the section, xref:upgrade-script[Running the server upgrade script].
|
||||
|
||||
ifeval::[{project_product}==true]
|
||||
|
||||
[id="rpm-upgrade"]
|
||||
=== Run the RPM distribution script
|
||||
=== Upgrading the server from an RPM
|
||||
|
||||
.Prerequisites
|
||||
* Handle any open transactions and delete the /var/opt/rh/rh-sso7/lib/keycloak/standalone/data/tx-object-store/ transaction directory.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Make sure you have subscribed to the proper repositories containing JBOSS EAP and {project_name}.
|
||||
. Subscribe to the proper repositories containing JBOSS EAP and {project_name}.
|
||||
+
|
||||
For Red Hat Enterprise Linux 7:
|
||||
+
|
||||
|
@ -65,22 +60,43 @@ For Red Hat Enterprise Linux 8:
|
|||
+
|
||||
subscription-manager repos --enable=rh-sso-7.5-for-rhel-8-x86_64-rpms
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
To disable older product repositories for both JBOSS EAP and {project_name} use:
|
||||
|
||||
subscription-manager repos --disable=<OLDER_PRODUCT_REPO>
|
||||
. Disable older product repositories for both JBOSS EAP and {project_name}:
|
||||
|
||||
To check the repositories use:
|
||||
subscription-manager repos --disable=jb-eap-7.3-for-rhel-8-x86_64-rpms
|
||||
subscription-manager repos --disable=rh-sso-7.4-for-rhel-8-x86_64-rpms
|
||||
|
||||
yum repolist
|
||||
====
|
||||
. The RPM upgrade process will not replace any of your modified configuration files, and will instead create .rpmnew files for the default configuration of the new {project_name} version.
|
||||
. Check the list of repositories:
|
||||
|
||||
dnf repolist
|
||||
|
||||
Updating Subscription Management repositories.
|
||||
repo id repo name
|
||||
rh-sso-7.5-for-rhel-8-x86_64-rpms Single Sign-On 7.5 for RHEL 8 x86_64 (RPMs)
|
||||
rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
|
||||
rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
|
||||
|
||||
. Back up any modified configuration files and custom modules.
|
||||
|
||||
. Remove packages for RH-SSO 7.4.
|
||||
+
|
||||
To activate any new features in the new release, such as new subsystems, you must manually merge each .rpmnew file into your existing configuration files
|
||||
Normally the old packages are removed by `dnf upgrade`. However, the RH-SSO 7.5 packages use a format that conflicts with files handled by the JBoss EAP 7.3 package. Therefore, the RH-SSO 7.4 and JBoss EAP 7.3 packages must be removed.
|
||||
+
|
||||
dnf remove --exclude java-1.8.0-openjdk rh-sso7-keycloak
|
||||
+
|
||||
Removing of java-1.8.0-openjdk is unnecessary, but this step saves the additional download of the same set of related packages later in the procedure.
|
||||
|
||||
. Install the new version of RH-SSO.
|
||||
+
|
||||
dnf groupinstall rh-sso7
|
||||
+
|
||||
dnf install rh-sso7-keycloak-15.0.2-3.redhat_00002.1.el8sso rh-sso7-keycloak-server-15.0.2-3.redhat_00002.1.el8sso
|
||||
|
||||
. To activate any new features in the new release, such as new subsystems, you must manually merge each backup configuration file into your existing configuration files.
|
||||
|
||||
. Copy any custom modules that have been added to the modules directory.
|
||||
. Run the applicable upgrade script as described below.
|
||||
|
||||
. Continue with the section, xref:upgrade-script[Running the server upgrade script].
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
|
@ -90,8 +106,19 @@ To activate any new features in the new release, such as new subsystems, you mus
|
|||
|
||||
Use it when calling migration scripts below.
|
||||
====
|
||||
|
||||
endif::[]
|
||||
|
||||
[id="upgrade-script"]
|
||||
== Running the server upgrade script
|
||||
|
||||
Based on your previous installation, run the appropriate upgrade script that applies to your situation:
|
||||
|
||||
* xref:standalone-mode[Standalone mode]
|
||||
* xref:standalone-ha[Standalone high availability mode]
|
||||
* xref:domain-mode[Domain mode]
|
||||
* xref:domain-clustered[Domain-clustered mode]
|
||||
|
||||
[id="standalone-mode"]
|
||||
=== Running the Standalone Mode upgrade script
|
||||
|
||||
|
|
|
@ -2,26 +2,20 @@
|
|||
|
||||
== Preparing for upgrading
|
||||
|
||||
Before you upgrade, be aware of the order in which you need to perform the upgrade steps. Also note potential issues
|
||||
that can occur within the upgrade process. In general, you must upgrade {project_name} server first, and then upgrade
|
||||
the adapters.
|
||||
Before you upgrade, be aware of the order in which you need to perform the upgrade steps. In particular, be sure to upgrade {project_name} server before you upgrade the adapters.
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
In a minor upgrade of {project_name}, all user sessions are lost. After the upgrade, all users will have to log in again.
|
||||
====
|
||||
|
||||
.Prerequisites
|
||||
* Prior to applying the upgrade, handle any open transactions and delete the data/tx-object-store/ transaction directory.
|
||||
|
||||
.Procedure
|
||||
. Back up the old installation (configuration, themes, and so on).
|
||||
. Back up the database. For detailed information on how to back up the database, see the documentation for the relational
|
||||
database you are using.
|
||||
. Upgrade {project_name} server.
|
||||
* Testing the upgrade in a non-production environment first, to prevent any installation issues from being exposed in
|
||||
production, is a best practice.
|
||||
* Be aware that after the upgrade the database will no longer be compatible with the old server
|
||||
* Ensure the upgraded server is functional before upgrading adapters in production.
|
||||
. Back up the database using instructions in the documentation for your relational
|
||||
database.
|
||||
. Upgrade the {project_name} server.
|
||||
+
|
||||
The database will no longer be compatible with the old server after the upgrade.
|
||||
. If you need to revert the upgrade, first restore the old installation, and then restore the database from the backup copy.
|
||||
. Upgrade the adapters.
|
||||
|
||||
|
|
|
@ -1,8 +1,10 @@
|
|||
[[_release_changes]]
|
||||
== Changes
|
||||
[id="release_changes"]
|
||||
|
||||
== Release-specific changes
|
||||
|
||||
Review these changes carefully before upgrading.
|
||||
|
||||
|
||||
include::changes-75.adoc[leveloffset=1]
|
||||
include::changes-74.adoc[leveloffset=1]
|
||||
include::changes-73.adoc[leveloffset=1]
|
||||
|
|
|
@ -51,7 +51,7 @@ You can migrate to Red Hat Single Sign-On, the supported Red Hat product, from K
|
|||
|
||||
.Prerequisites
|
||||
|
||||
* To learn about new features before the upgrade, review the xref:_release_changes[changes].
|
||||
* To learn about new features before the upgrade, review the xref:release_changes[changes].
|
||||
* Verify that you have installed the correct version of Keycloak as a starting point. To migrate to Red Hat Single Sign-On {project_versionDoc}, you need Keycloak {keycloak_upgrade_version}.
|
||||
|
||||
.Procedure
|
||||
|
|
|
@ -27,6 +27,4 @@ include::../migrate_themes.adoc[leveloffset=2]
|
|||
include::patching-zip-installation.adoc[leveloffset=3]
|
||||
include::patching-rpm-installation.adoc[leveloffset=3]include::patching_maven_repo.adoc[leveloffset=3]
|
||||
|
||||
== Upgrading {project_name} adapters
|
||||
|
||||
include::../upgrade_adapters.adoc[leveloffset=1]
|
||||
|
|
Loading…
Reference in a new issue