Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
tutorial:adm:server_os_updates [2019/12/16 13:42]
fiserp [Things to consider]
tutorial:adm:server_os_updates [2019/12/16 14:09]
fiserp [Things to consider]
Line 15: Line 15:
     * LRTs run usually at night so it is not entirely necessary to stop the IdM, but you have to make sure you have enough time to perform the patching (and possible rollback) before jobs start to execute.     * LRTs run usually at night so it is not entirely necessary to stop the IdM, but you have to make sure you have enough time to perform the patching (and possible rollback) before jobs start to execute.
     * Restarting IdM cancels the LRT that was currently running, LRT **will not pick up automatically** after IdM goes up again.     * Restarting IdM cancels the LRT that was currently running, LRT **will not pick up automatically** after IdM goes up again.
 +  * Impact on end systems connected to IdM
 +    * There is no direct impact on other systems.
 +    * There **may be** some impact on connections the IdM makes in order to manage end systems.
 +      * Some end systems use SSL-secured form of communication and IdM needs to have their certificate in its Java truststore. If the truststore was improperly configured and gets regenerated (i.e. due to ``ca-certificates`` package update), all extra certificates are lost making SSL connections to end systems fail. This should not happen because IdM should use its own, explicitly created and configured, truststore.
 +      * Some end systems that are connected via WinRM. The WinRM library uses Python and some of Python's libraries come from the OS packages. Upgrading those packages system-wide has **possibly** an impact on the way the WinRM/Python works.
   * Impact on OS   * Impact on OS
-    * OS may seemingly not boot after the updates (boot or network issues, SSHd/RDP daemon issues). We recommend to have complete backup of ``/boot`` and ``/etc`` directories. Out-of-band access to a machine is a must. +    * OS may seemingly not boot after the updates (boot or network issues, SSHd/RDP daemon issues). We recommend to have complete backup of ``/boot`` and ``/etc`` directories. Out-of-band access to a machine is a must. In case of virtualized environment, making a snapshot is a way to go
-    * In our deployments, we use mainly RHEL/CentOS (sometimes Debian) and Windows OSes. If you deploy IdM accordingly (tutorials [[https://wiki.czechidm.com/doku.php?id=start&do=search&q=server+prep|here]] and [[https://wiki.czechidm.com/doku.php?id=start&do=search&q=idm+installation|here]], OS updates are generally painless.+    * In our deployments, we use mainly RHEL/CentOS (sometimes Debian) and Windows OSes. If you deploy IdM accordingly (tutorials [[https://wiki.czechidm.com/doku.php?id=start&do=search&q=server+prep|here]] and [[https://wiki.czechidm.com/doku.php?id=start&do=search&q=idm+installation|here]]), OS updates are generally painless.
     * Packages from OS that IdM deployment uses     * Packages from OS that IdM deployment uses
-      * Java (openjdk package referenced through ``/usr/lib/...`` and therefore through ``/etc/alternatives/...``). Java patchset may be updated, bud the version should stay the same (e.g. update ``1.8u27->1.8u90`` is OK, but update ``Java8->Java9`` is not).+      * Java (java binary referenced through ``/usr/lib/...`` and therefore through ``/etc/alternatives/...``). Java patchset may be updated, but the version should stay the same (e.g. update ``1.8u27->1.8u90`` is OK, but update ``Java8->Java9`` is not).
       * PostgreSQL is installed generally from OS or PGDG repositories and is considered pretty stable. Updating package when PostgreSQL version stays the same is OK. Updating PostgreSQL version (e.g. ``9.6->10``) should be OK, but we recommend at least to make a backup of IdM database (in case you have to rollback the previous PostgreSQL version).       * PostgreSQL is installed generally from OS or PGDG repositories and is considered pretty stable. Updating package when PostgreSQL version stays the same is OK. Updating PostgreSQL version (e.g. ``9.6->10``) should be OK, but we recommend at least to make a backup of IdM database (in case you have to rollback the previous PostgreSQL version).
       * Apache HTTPD. Deployment should be stable and no special care is needed. We recommend to have a backup of vhost configuration.       * Apache HTTPD. Deployment should be stable and no special care is needed. We recommend to have a backup of vhost configuration.
 +    * Windows-based installations have all deployment components installed by-hand and therefore are not really susceptible to break by OS updates. But this also means you have to update all deployment components manually.
  • by fiserp