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 15:26]
fiserp [Solving issues] 		tutorial:adm:server_os_updates [2019/12/17 07:36]
fiserp [Things to consider]
Line 10: Line 10:
   * Impact on users   * Impact on users
     * IdM is often deployed as a self-service portal for users. You should plan the downtime such that minimal number of users is affected.     * IdM is often deployed as a self-service portal for users. You should plan the downtime such that minimal number of users is affected.
-    * Users may make changes in the IdM that start some long running tasks (e.g. automatic roles changes). Those tasks are executed asynchronously and may be running even if the user who started the task has already logged off. +    * Users may make changes in the IdM that start some long running tasks (e.g. automatic roles changes, bulk role assignments, etc.). Those tasks are executed asynchronously and may be running even if the user who started the task has already logged off. 
-  * Impact on IdM batch jobs (long running tasks - LRT)+  * Impact on long running tasks (LRT)
     * IdM has internal cron that schedules LRT jobs. To make things safe, no job should be running when you are doing the update. The safest way to achieve this is to stop the IdM service before applying updates.     * IdM has internal cron that schedules LRT jobs. To make things safe, no job should be running when you are doing the update. The safest way to achieve this is to stop the IdM service before applying updates.
     * 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.
Line 74: Line 74:
 ==== Solving issues ==== ==== Solving issues ====
 For maintenance actions, it is necessary to: For maintenance actions, it is necessary to:
-  * Know how long each task will take.+  * Know how long each task will take and to measure the task duration when actually performing them.
     * If tasks take longer than expected, you know if you can match the maintenance window or not.     * If tasks take longer than expected, you know if you can match the maintenance window or not.
   * Know how long the whole maintenance will take (maintenance time **MT**).   * Know how long the whole maintenance will take (maintenance time **MT**).
Line 86: Line 86:
  
 Fortunately, in most cases it simply means restoring the snapshot of the virtual machine. After restoring the snapshot, you have to perform tests (with test use-cases) to confirm the rollback was performed correctly. Fortunately, in most cases it simply means restoring the snapshot of the virtual machine. After restoring the snapshot, you have to perform tests (with test use-cases) to confirm the rollback was performed correctly.
-In more complicated cases, restoring the IdM database or application WAR may be the way.+Minor issues can be generally resolved with the help of ``/boot`` and ``/etc`` backups you created before updating the OS. 
 + 
 +If IdM installation gets hit, you can debug the configuration or restore it from periodic backup. Since IdM is not installed from OS packages, this basically never happens.
  • by fiserp