.. _upgrading-from-18.1.3-to-19.3.2:
Upgrading from VOSS-4-UC 18.1.3 to 19.3.2
==========================================
.. _19.3.2|EKB-5461:
.. note::
* While system upgrade takes approximately two hours
at a single site, this may vary in accordance with your topology, number of
devices and subscribers. Adjust your upgrade maintenance window
to allow for your configuration.
You can follow the progress on the GUI transaction list.
* The ``screen`` command can be used - see: :ref:`using-screen`
The upgrade process is in two stages:
1. :ref:`18.3.1-to-19.2.1-ISO-Upgrade`
2. :ref:`19.2.1-to-19.3.2-Delta-Bundle-Upgrade`
.. important::
The process in this document only applies for the *full* upgrade
from 18.3.1 to 19.3.2, and cannot be used for the upgrade to
intermediate versions. Refer to the upgrade documents accompanying
individual releases for intermediate version upgrades.
Note:
* For each stage, the required upgrade files need to be downloaded.
* A database filesystem conversion is required during the second, delta bundle upgrade.
.. _18.3.1-to-19.2.1-ISO-Upgrade:
.. rst-class:: chapter-with-expand
18.3.1 to 19.2.1 ISO Upgrade
----------------------------
Upgrade a Multinode Environment with the ISO and Template
.. note::
* When upgrading from CUCDM 11.5.3 Patch Bundle 2 or VOSS-4-UC 18.1 Patch Bundle 2
and earlier, re-import specified CUC models according to your current version.
Refer to the final upgrade procedure step.
.. _18.1.3-19.2.1-Download-Files-and-Check-ISO:
Download Files and Check
...........................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+---------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=================================================================================+====================+
| | |
| VOSS SFTP server: ``secure.voss-solutions.com`` | |
| | |
| Download: | |
| | |
| * ``platform-install-19.2.1-1570776653.iso`` and | |
| * ``V4UC-19.2.1.280-build-14.template`` from the VOSS SFTP server. | |
| | |
| | |
| * Transfer the ``.iso`` file to the ``media/`` folder of the primary node. | |
| * Transfer the ``.template`` file to the ``media/`` folder of the primary node. | |
| | |
| Two transfer options: | |
| | .. raw:: html |
| Either using SFTP: | |
| | |
| | <div><input |
| * **sftp platform@<unified_node_hostname>** | type='checkbox' |
| | id='done' |
| * **cd media** | name='done' |
| | unchecked> |
| * **put <upgrade_iso_file>** | <label |
| | for='isdone'> |
| * **put <upgrade_template_file>** | Done</label> |
| | </div> |
| | |
| | |
| Or using SCP: | |
| | |
| | |
| * **scp <upgrade_iso_file> platform@<unified_node_ip_address>:~/media** | |
| | |
| * **scp <upgrade_template_file> platform@<unified_node_ip_address>:~/media** | |
| | |
| | |
| Verify that the ``.iso`` image and ``.template`` file copied: | |
| | |
| | |
| * **ls -l media/** | |
| | |
| | |
| Verify that the original ``.sha256`` checksums on the | |
| SFTP server match. | |
| | |
| | |
| * **system checksum media/<upgrade_iso_file>** | |
| | |
| ``Checksum: <ISO SHA256>`` | |
| | |
| * **system checksum media/<upgrade_template_file>** | |
| | |
| ``Checksum: <Template SHA256>`` | |
| | |
| See values below. | |
+---------------------------------------------------------------------------------+--------------------+
* ISO SHA256: ``b2d1c5df04d0791d0de3d8d4aa2b3d1d9b62ea1d1df3bd61967a0dfa7836f985``
* Template SHA256: ``249fd0b1d797fdbebba03c136211ae1f7a79ea309f3049546b0152698586f9fa``
.. _18.1.3-19.2.1-Schedules-Transactions-Version-Check:
Schedules, Transactions and Version Check
..................................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+----------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+==============================================================================================+====================+
| Turn off any scheduled imports to prevent syncs triggering part way through the upgrade. | |
| Two options are available: | |
| | |
| Individually for each job: | |
| | |
| 1. Log in on the GUI as a high level administrator above Provider level. | |
| 2. Select the **Scheduling** menu to view scheduled jobs. | |
| 3. Click each scheduled job. On the Base tab, uncheck the **Activate** check box. | |
| | |
| Mass modify: | |
| | |
| 1. On the GUI, export scheduled syncs into a bulk load sheet. | .. raw:: html |
| 2. Modify the schedule settings to de-activate scheduled syncs. | |
| 3. Import the sheet. | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
+----------------------------------------------------------------------------------------------+--------------------+
| Check for running imports. Either wait for them to complete or cancel them: | |
| | |
| 1. Log in on the GUI as a high level administrator above Provider level. | |
| 2. Select the **Transaction** menu to view transactions. | |
| 3. Filter the **Action** column: | |
| | |
| a. Choose **Status** as "Processing" and then choose each **Action** | |
| that starts with "Import", for example, "Import Unity Connection". | |
| b. Click **Search** and confirm there are no results. | |
| c. If there are transactions to cancel, select them and click **Cancel**. | |
| | |
| | .. raw:: html |
| | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
+----------------------------------------------------------------------------------------------+--------------------+
| Record the current version information. This is required for upgrade troubleshooting. | |
| | |
| * Log in on the GUI and record the information contained in the **About > Extended Version** | .. raw:: html |
| | |
| :: | <div><input |
| | type='checkbox' |
| Release 18.1.75 | id='done' |
| Platform 11.5.3-1521045619 | name='done' |
| Version 116.0 | unchecked> |
| Build no 1558 | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
+----------------------------------------------------------------------------------------------+--------------------+
.. _18.1.3-19.2.1-Pre-Upgrade-Security-Health-Steps:
Pre-Upgrade, Security and Health Steps
...............................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-----------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=========================================================================================+====================+
| Verify that the primary node is the active primary node at the time of upgrade. | |
| | |
| **database config** | .. raw:: html |
| | |
| Ensure that the node on which the installation will be initiated has the ``stateStr`` | <div><input |
| parameter set to **PRIMARY** and has the **highest** ``priority`` **number** | type='checkbox' |
| (highest priority number could vary depending on cluster layout). | id='done' |
| | name='done' |
| Example output :: | unchecked> |
| | <label |
| <ip address>:27020: | for='isdone'> |
| priority: <number> | Done</label> |
| stateStr: PRIMARY | </div> |
| storageEngine: WiredTiger | |
| | |
| Validate the system health. | |
| On the Primary Unified Node, verify cluster connectivity and health: | |
| | |
| * **cluster status** | |
| | |
| * From VOSS-4-UC 19.1.1 onwards: | |
| | |
| **cluster check** | |
| | |
| * Prior to VOSS-4-UC 19.1.1: | |
| | |
| **diag disk** | |
| | |
| If there is any sign of the paths below are over 80% full, a clean-up is needed, | |
| for example to avoid risk of full logs occurring during upgrade. | |
| Clean-up steps are indicated next to the paths: | |
| | |
| :: | |
| | |
| / (call support if over 80%) | |
| /var/log (run: log purge) | |
| /opt/platform (remove any unnecessary files from /media directory) | |
| /tmp (reboot) | |
| | |
| | |
| On the Primary Unified Node, verify there are no pending Security Updates on any of the | |
| nodes: | |
| | |
| * **cluster run all security check** | |
| | |
+-----------------------------------------------------------------------------------------+--------------------+
| Shutdown servers and take snapshots from VMWare and then start all servers: | |
| | |
| Use VMware snapshots. Consider the following: | |
| | |
| | .. raw:: html |
| * VOSS cannot guarantee that a VMware snapshot can be used to successfully | |
| restore VOSS-4-UC or any Cisco HCS Management application. If you cannot | <div><input |
| restore the application from a snapshot, your only recourse is to reinstall | type='checkbox' |
| the application. | id='done' |
| * When the backup is complete and you do not need the VMware snapshot for | name='done' |
| restore activities, delete the snapshot immediately to preserve LUN space. | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| * **cluster run notme system shutdown** | </div> |
| | |
| followed by: | |
| | |
| **system shutdown** | |
| | |
| Log into VMWare and take snapshots of all unified nodes and all web proxies. | |
| | |
| After snapshots, restart the servers: | |
| | |
| * Power up the servers via VMWare. | |
| | |
| Optional: If a backup is required in addition to the snapshot, use the | |
| **backup add <location-name>** and | |
| **backup create <location-name>** commands. For details, refer to the Platform Guide. | |
| | |
+-----------------------------------------------------------------------------------------+--------------------+
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-----------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=========================================================================================+====================+
| Before upgrading, check all services, nodes and weights for the cluster: | |
| | |
| Make sure no services are stopped/broken. The message 'suspended waiting for mongo' | |
| is normal on the fresh unified nodes. | |
| | |
| | |
| * **cluster run all app status** | |
| | |
| | |
| Make sure all application nodes show 3 or 5 nodes. | |
| | |
| | |
| * **cluster run application cluster list** | |
| | |
| | |
| Check that the database weights are set. It is *critical* to ensure the weights are set | |
| before upgrading a cluster. | |
| | |
| | .. raw:: html |
| * **cluster run application database weight list** | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| Example output: | name='done' |
| | unchecked> |
| :: | <label |
| | for='isdone'> |
| | Done</label> |
| 172.29.21.240: | </div> |
| weight: 80 | |
| 172.29.21.241: | |
| weight: 70 | |
| 172.29.21.243: | |
| weight: 60 | |
| 172.29.21.244: | |
| weight: 50 | |
| | |
| | |
| Verify the primary node in the primary site and ensure no nodes are in the | |
| 'recovering' state (``stateStr`` is not ``RECOVERING``). On the primary node: | |
| | |
| | |
| * **database config** | |
| | |
| | |
+-----------------------------------------------------------------------------------------+--------------------+
.. _18.1.3-19.2.1-upgrade-ISO:
Upgrade
...........................
.. note::
By default, the cluster upgrade is carried out in parallel on all nodes and without any
backup in order to provide a fast upgrade. For backwards compatibility, this command
is the same as for example **cluster upgrade <upgrade_iso_file> backup none fast**.
Use the **cluster upgrade <upgrade_iso_file> serial** command if the VMware host is under load.
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+---------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=======================================================================================+====================+
| From VOSS-4-UC 18.1 or CUCDM 11.5.3 onwards, it is recommended that the upgrade steps | |
| are run in a terminal opened with the **screen** command and to use a log file. | |
| See: :ref:`using-screen`. | |
| | |
| On the primary unified node: | |
| | |
| | |
| * **screen** | .. raw:: html |
| | |
| | |
| * **cluster upgrade media/<upgrade_iso_file>** | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+---------------------------------------------------------------------------------------+--------------------+
.. _18.1.3-19.2.1-Post-Upgrade-Security-Health-Steps:
Post-Upgrade, Security and Health Steps
................................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+--------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+======================================================================================+====================+
| On the primary unified node, verify the cluster status: | |
| | |
| * **cluster status** | .. raw:: html |
| * From VOSS-4-UC 19.1.1 onwards, also run: **cluster check** | |
| * If any of the above commands show errors, check for further details to assist | <div><input |
| with troubleshooting: | type='checkbox' |
| | id='done' |
| **cluster run all diag health** | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+--------------------------------------------------------------------------------------+--------------------+
| If upgrade is successful, the screen session can be closed by typing **exit** in the | |
| screen terminal. If errors occurred, keep the screen terminal | |
| open for troubleshooting purposes and contact VOSS support. | .. raw:: html |
| | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+--------------------------------------------------------------------------------------+--------------------+
| Complete all the security updates. | |
| | |
| | .. raw:: html |
| * **cluster run all security update** | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| Note: If the system reboots, do not carry out the next manual reboot step. | unchecked> |
| When upgrading from pre-19.1.1, an automatic reboot should be expected. | <label |
| | for='isdone'> |
| Manual reboot *only if security updates needed to be applied*: | Done</label> |
| | </div> |
| * **cluster run notme system reboot** | |
| | |
| If node messages: ``<node name> failed with timeout`` are displayed, | |
| these can be ignored. | |
| | |
| * **system reboot** | |
| | |
| | |
| Since all services will be stopped, this takes some time. | |
| | |
+--------------------------------------------------------------------------------------+--------------------+
.. _18.1.3-19.2.1-Database-Schema-Upgrade:
Database Schema Upgrade
................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+---------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=======================================================================================+====================+
| From VOSS-4-UC 18.1 or CUCDM 11.5.3 onwards, it is recommended that the upgrade steps | |
| are run in a terminal opened with the **screen** command. | |
| | |
| On the primary unified node: | |
| | .. raw:: html |
| * **screen** | |
| | <div><input |
| * **voss upgrade_db** | type='checkbox' |
| Append ``--force`` for no prompt or type ``y`` for yes to confirm this command. | id='done' |
| | name='done' |
| Check cluster status | unchecked> |
| | <label |
| * **cluster status** | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+---------------------------------------------------------------------------------------+--------------------+
.. _18.1.3-19.2.1-Template-Upgrade-ISO:
Template Upgrade
...................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+---------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=======================================================================================+====================+
| From VOSS-4-UC 18.1 or CUCDM 11.5.3 onwards, it is recommended that the upgrade steps | |
| are run in a terminal opened with the **screen** command. | |
| | |
| On the primary unified node: | |
| | .. raw:: html |
| * **screen** | |
| | <div><input |
| * **app template media/<VOSS-4-UC.template>** | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+---------------------------------------------------------------------------------------+--------------------+
The following message appears:
::
Running the DB-query to find the current environment's
existing solution deployment config...
* Python functions are deployed
* System artifacts are imported.
The template upgrade automatically detects the deployment mode: "Enterprise",
"Provider with HCM-F" or "Provider without HCM-F".
A message displays according to the selected deployment type.
Check for one of the messages below:
::
Importing EnterpriseOverlay.json
Importing ProviderOverlay_Hcmf.json ...
Importing ProviderOverlay_Decoupled.json ...
The template install automatically restarts necessary applications. If a cluster is detected,
the installation propagates changes throughout the cluster.
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+==========================================================================================+====================+
| | |
| Review the output from the **app template** command and confirm that the upgrade message | .. raw:: html |
| appears: | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
+------------------------------------------------------------------------------------------+--------------------+
::
Deployment summary of PREVIOUS template solution
(i.e. BEFORE upgrade):
-------------------------------------------------
Product: [PRODUCT]
Version: [PREVIOUS PRODUCT RELEASE]
Iteration-version: [PREVIOUS ITERATION]
Platform-version: [PREVIOUS PLATFORM VERSION]
This is followed by updated product and version details:
::
Deployment summary of UPDATED template solution
(i.e. current values after installation):
-----------------------------------------------
Product: [PRODUCT]
Version: [UPDATED PRODUCT RELEASE]
Iteration-version: [UPDATED ITERATION]
Platform-version: [UPDATED PLATFORM VERSION]
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=====================================================================================+====================+
| | |
| | .. raw:: html |
| | |
| * If no errors are indicated, make a backup or snapshot. | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+-------------------------------------------------------------------------------------+--------------------+
| | |
| | .. raw:: html |
| | |
| For an unsupported upgrade path, the install script stops with the message: | <div><input |
| | type='checkbox' |
| | id='done' |
| :: | name='done' |
| | unchecked> |
| | <label |
| Upgrade failed due to unsupported upgrade path. | for='isdone'> |
| Please log in as sysadmin | Done</label> |
| and see Transaction logs for more detail. | </div> |
| | |
| You can restore to the backup or revert to the VM snapshot made before the upgrade. | |
| | |
| | |
+-------------------------------------------------------------------------------------+--------------------+
| | |
| | .. raw:: html |
| If there are errors for another reason, the install script stops with a | |
| failure message listing the problem. Contact VOSS support. | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+-------------------------------------------------------------------------------------+--------------------+
| | |
| | .. raw:: html |
| Verify the ``extra_functions`` have the *same checksum* across the cluster. | |
| | <div><input |
| * **cluster run application voss get_extra_functions_version -c** | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+-------------------------------------------------------------------------------------+--------------------+
| Post upgrade migrations: | |
| | |
| On a single node of a cluster, run: | .. raw:: html |
| | |
| * **voss post-upgrade-migrations** | <div><input |
| | type='checkbox' |
| | id='done' |
| Data migrations that are not critical to system operation can have significant | name='done' |
| execution time at scale. These need to be performed after the primary upgrade, | unchecked> |
| allowing the migration to proceed whilst the system is in use - thereby limiting | <label |
| upgrade windows. | for='isdone'> |
| | Done</label> |
| A transaction is queued on VOSS-4-UC and its progress is displayed as it executes. | </div> |
| | |
+-------------------------------------------------------------------------------------+--------------------+
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+---------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=================================+====================+
| | |
| Check cluster status and health | .. raw:: html |
| | |
| * **cluster status** | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+---------------------------------+--------------------+
.. _18.1.3-19.2.1-Post-Template-Upgrade-Tasks:
Post Template Upgrade Tasks
....................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+===========================================================================================+====================+
| Verify the upgrade: | .. raw:: html |
| | |
| Log in on the GUI and check the information contained in the **About > Extended Version** | |
| menu. Confirm that versions have upgraded. | <div><input |
| | type='checkbox' |
| * **Release** should show 19.2.1 | id='done' |
| * **Platform Version** should show 19.2.1 | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
+-------------------------------------------------------------------------------------------+--------------------+
| | .. raw:: html |
| | |
| | <div><input |
| * Check themes on all roles are set correctly | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+-------------------------------------------------------------------------------------------+--------------------+
.. _18.1.3-19.2.1-Release-specific-updates:
Release Specific Updates
.................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-------------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=================================================================================================+====================+
| When upgrading from CUCDM 11.5.3 Patch Bundle 2 or VOSS-4-UC 18.1 Patch Bundle 2 and earlier, | |
| re-import the following from all CUCM devices, since this upgrade deleted obsolete CUC timezone | |
| codes from the VOSS-4-UC database: | |
| | |
| * CUC models: | .. raw:: html |
| | |
| ``device/cuc/TimeZone`` | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| Note: | unchecked> |
| | <label |
| This is a once off data migration step. If this was performed previously when upgrading | for='isdone'> |
| to 19.1.x, then it does not have to be repeated. | Done</label> |
| | </div> |
+-------------------------------------------------------------------------------------------------+--------------------+
| After upgrading, obtain and install the following patch according to its accompanying MOP file: | |
| | |
| * **Server Name**: ``secure.voss-solutions.com`` | .. raw:: html |
| * **Path**: ``/software/voss4uc/releases/Release-19.2.1`` | |
| * **Patch Directory**: ``Update_CUC_Localization_patch`` | <div><input |
| * **Patch File**: ``Update_CUC_Localization_patch.script`` | type='checkbox' |
| * **MOP File**: ``MOP-Update_CUC_Localization.pdf`` | id='done' |
| | name='done' |
| | unchecked> |
| Note: | <label |
| | for='isdone'> |
| This is a once off data migration step. If this was performed previously when upgrading | Done</label> |
| to 19.1.x, then it does not have to be repeated. | </div> |
| | |
+-------------------------------------------------------------------------------------------------+--------------------+
| Re-import the following from all CUCM devices: | |
| | |
| * CUCM models: | .. raw:: html |
| | |
| ``device/cucm/PhoneType`` | <div><input |
| | type='checkbox' |
| For steps to create a custom data sync, refer to the chapter on Data Sync | id='done' |
| in the Core Feature Guide. | name='done' |
| | unchecked> |
| | <label |
| Note: | for='isdone'> |
| | Done</label> |
| This is a once off data migration step. If this was performed previously when upgrading | </div> |
| to 19.1.x, then it does not have to be repeated. | |
+-------------------------------------------------------------------------------------------------+--------------------+
| On VOSS-4-UC 18.1, an enhancement populates the E164 Inventory field on Directory Numbers (DNs) | |
| when associating E164 numbers to DNs. In order to populate the E164 field for existing | |
| associations, please execute the workflow: ``FixINIPostUpgradePWF``. | .. raw:: html |
| This will populate the E164 Field on the DN. | |
| | <div><input |
| To run the workflow, login with ``tdkadmin``, select the hierarchy to run the workflow at, e.g. | type='checkbox' |
| Provider, and then execute the workflow. This can be run at lower hierarchy levels | id='done' |
| as well for a phased migration approach, e.g. at Customer level. | unchecked> |
| The task can be performed by partners who have access to the ``tdkadmin`` user account. | <label |
| Alternatively, contact your VOSS Account Manager/Support representative for assistance. | for='isdone'> |
| | Done</label> |
| Usage: Select the desired hierarchy, find and Execute the workflow named | </div> |
| ``FixINIPostUpgradePWF``. | |
| | |
+-------------------------------------------------------------------------------------------------+--------------------+
.. _18.1.3-19.2.1-Log-Files-Error-Checks:
Log Files and Error Checks
....................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+----------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+==================================================================================+====================+
| Inspect the output of the command line interface for upgrade errors, | .. raw:: html |
| for example ``File import failed!`` or ``Failed to execute command``. | |
| | |
| Use the **log view** command to view any log files indicated in the error | |
| messages, for example, run the command if the following message appears: | <div><input |
| | type='checkbox' |
| :: | id='done' |
| | name='done' |
| For more information refer to the execution log file with | unchecked> |
| 'log view platform/execute.log' | <label |
| | for='isdone'> |
| For example, if it is required send all the install log files in the ``install`` | Done</label> |
| directory to an SFTP server: | </div> |
| | |
| * **log send sftp://x.x.x.x install** | |
| | |
+----------------------------------------------------------------------------------+--------------------+
| | .. raw:: html |
| Log in on the GUI as system level administrator, go to | |
| **Administration Tools > Transaction** and inspect the transactions | <div><input |
| list for errors. | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+----------------------------------------------------------------------------------+--------------------+
.. _19.2.1-to-19.3.2-Delta-Bundle-Upgrade:
.. rst-class:: chapter-with-expand
19.2.1 to 19.3.2 Delta Bundle Upgrade
------------------------------------------
Upgrade a Multinode Environment with the Delta Bundle
.. _19.2.1-19.3.2-Download-Files-and-Check-script:
Download Files and Check
..........................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+--------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+======================================================================================+====================+
| | |
| VOSS SFTP server: ``secure.voss-solutions.com`` | |
| | |
| Download: | |
| | |
| * ``19.3.2-Delta-Bundle.script`` | |
| from the VOSS SFTP server. | |
| | |
| Two file transfer options: | .. raw:: html |
| | |
| Either using SFTP: | |
| | |
| | <div><input |
| * **sftp platform@<primary_unified_node_hostname>** | type='checkbox' |
| | id='done' |
| * **cd media** | name='done' |
| | unchecked> |
| * **put <XXX-Delta-Bundle.script>** | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
| Or using SCP: | |
| | |
| | |
| * **scp <XXX-Delta-Bundle.script> platform@<primary_unified_node_hostname>:~/media** | |
| | |
| | |
| | |
| On the primary Unified node, verify that the ``.script`` file copied: | |
| | |
| | |
| * **ls -l media/** | |
| | |
| | |
| On the primary Unified node, verify that the original ``.sha256`` checksums on the | |
| SFTP server match. | |
| | |
| | |
| * **system checksum media/<XXX-Delta-Bundle.script>** | |
| | |
| ``Checksum: <Bundle SHA256>`` | |
| | |
| See below for SHA256. | |
+--------------------------------------------------------------------------------------+--------------------+
* Bundle SHA256: ``01c06d4b6c3abf9f6fc45339aa4fbd59431bb38a1a37368cc1f2132d50b295c3``
.. _19.2.1-19.3.2-Schedules-Transactions-Version-Check:
Version Check
..................................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+----------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+==============================================================================================+====================+
| Record the current version information. This is required for upgrade troubleshooting. | |
| | |
| * Log in on the GUI and record the information contained in the **About > Extended Version** | .. raw:: html |
| | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
+----------------------------------------------------------------------------------------------+--------------------+
.. _19.2.1-19.3.2-Pre-Upgrade-Security-Health-Steps:
Pre-Upgrade, Security and Health Steps
...............................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-----------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=========================================================================================+====================+
| Verify that the primary node is the active primary node at the time of upgrade. | |
| | .. raw:: html |
| **database config** | |
| | <div><input |
| Ensure that the node on which the installation will be initiated has the ``stateStr`` | type='checkbox' |
| parameter set to **PRIMARY** and has the **highest** ``priority`` **number** | id='done' |
| (highest priority number could vary depending on cluster layout). | name='done' |
| | unchecked> |
| Example output :: | <label |
| | for='isdone'> |
| <ip address>:27020: | Done</label> |
| priority: <number> | </div> |
| stateStr: PRIMARY | |
| storageEngine: WiredTiger | |
| | |
| Validate the system health. | |
| | |
| On the Primary Unified Node, verify cluster connectivity: | |
| | |
| * **cluster status** | |
| | |
| On each node verify network connectivity, disk status and NTP. | |
| | |
| | |
| * **cluster check** | |
| | |
| If there is any sign of the paths below are over 80% full, a clean-up is needed | |
| to avoid risk of for example full logs occurring during upgrade. | |
| Clean-up steps are indicated next to the paths: | |
| | |
| :: | |
| | |
| / (call support if over 80%) | |
| /var/log (run: log purge) | |
| /opt/platform (remove any unnecessary files from /media directory) | |
| /tmp (reboot) | |
| | |
| | |
| On the Primary Unified Node, verify there are no pending Security Updates on any of the | |
| nodes: | |
| | |
| * **cluster run all security check** | |
| | |
+-----------------------------------------------------------------------------------------+--------------------+
| Shutdown servers and take snapshots from VMWare | |
| and then power on all servers, starting with the primary: | |
| | |
| Use VMware snapshots. Consider the following: | |
| | .. raw:: html |
| * VOSS cannot guarantee that a VMware snapshot can be used to successfully | |
| restore VOSS-4-UC or any Cisco HCS Management application. If you cannot | <div><input |
| restore the application from a snapshot, your only recourse is to reinstall | type='checkbox' |
| the application. | id='done' |
| * When the backup is complete and you do not need the VMware snapshot for | name='done' |
| restore activities, delete the snapshot immediately to preserve LUN space. | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| * **cluster run notme system shutdown --force && system shutdown --force** | </div> |
| | |
| | |
| Log into VMWare and take snapshots of all unified nodes and all web proxies. | |
| | |
| After snapshots, restart the servers: | |
| | |
| * Power up the servers via VMWare. | |
| | |
| Optional: If a backup is required in addition to the snapshot, use the | |
| **backup add <location-name>** and | |
| **backup create <location-name>** commands. For details, refer to the Platform Guide. | |
| | |
| | |
+-----------------------------------------------------------------------------------------+--------------------+
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-----------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=========================================================================================+====================+
| Before upgrading, check all services, nodes and weights for the cluster: | |
| | |
| Make sure no services are stopped/broken. The message 'suspended waiting for mongo' | |
| is normal on the fresh unified nodes. | |
| | |
| | |
| * **cluster run all app status** | |
| | |
| | |
| Make sure all application nodes show 3 or 5 nodes. | |
| | |
| | |
| * **cluster run application cluster list** | |
| | |
| | |
| Check that the database weights are set. It is *critical* to ensure the weights are set | |
| before upgrading a cluster. | |
| | |
| | .. raw:: html |
| * **cluster run application database weight list** | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| Example output: | name='done' |
| | unchecked> |
| :: | <label |
| | for='isdone'> |
| | Done</label> |
| 172.29.21.240: | </div> |
| weight: 80 | |
| 172.29.21.241: | |
| weight: 70 | |
| 172.29.21.243: | |
| weight: 60 | |
| 172.29.21.244: | |
| weight: 50 | |
| | |
| | |
| Verify the primary node in the primary site and ensure no nodes are in the | |
| 'recovering' state (``stateStr`` is not ``RECOVERING``). On the primary node: | |
| | |
| | |
| * **database config** | |
| | |
| | |
+-----------------------------------------------------------------------------------------+--------------------+
.. _19.2.1-19.3.2-upgrade-Script:
Upgrade
...........................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=================================================+====================+
| On the primary unified node, use ``screen`` | |
| and a log file - see: :ref:`using-screen`. | |
| | |
| * **screen** | .. raw:: html |
| | |
| Run (optionally with command parameters below): | |
| | |
| * **app install media/<script_file>** | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+-------------------------------------------------+--------------------+
.. _19.2.1-19.3.2-Post-Upgrade-Security-Health-Steps:
Post-Upgrade, Security and Health Steps
................................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+--------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+======================================================================================+====================+
| On the primary unified node, verify the cluster status: | |
| | |
| * **cluster status** | .. raw:: html |
| * **cluster check** | |
| * If any of the above commands show errors, check for further details to assist | |
| with troubleshooting: | |
| | <div><input |
| **cluster run all diag health** | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+--------------------------------------------------------------------------------------+--------------------+
| If upgrade is successful, the screen session can be closed by typing **exit** in the | |
| screen terminal. If errors occurred, keep the screen terminal | |
| open for troubleshooting purposes and contact VOSS support. | .. raw:: html |
| | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+--------------------------------------------------------------------------------------+--------------------+
| Check for needed security updates. On the primary node, run: | |
| | |
| * **cluster run all security check** | |
| | |
| If one or more updates are required for any node, run on the primary Unified node: | |
| | |
| | |
| | .. raw:: html |
| * **cluster run all security update** | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| Note: *if the system reboots, do not carry out the next manual reboot step*. | unchecked> |
| | <label |
| Manual reboot *only if security updates needed to be applied*: | for='isdone'> |
| | Done</label> |
| | </div> |
| * **cluster run notme system reboot** | |
| | |
| | |
| If node messages: ``<node name> failed with timeout`` are displayed, | |
| these can be ignored. | |
| | |
| | |
| * **system reboot** | |
| | |
| | |
| Since all services will be stopped, this takes some time. | |
| | |
| | |
+--------------------------------------------------------------------------------------+--------------------+
.. _19.2.1-19.3.2-Wired-Tiger:
Database Filesystem Conversion
.......................................
.. important::
This step is to be carried out *only if* you have not converted the file system before.
To check if the step is *not* required:
1. Run **database config** and ensure that
the storage engine for *all database nodes* shows as
``storageEngine: WiredTiger``.
#. Run **drives list** and ensure that the LVM storage shows for
*all converted database nodes* under ``Volume Groups``.
The **database convert_drive** command provides parameters
that allow for a flexible upgrade schedule in order to limit
system downtime.
When the **database convert_drive** command is run, the ``voss-deviceapi``
service will be stopped first and started after completion. The command
should therefore be run during a maintenance window while there are no
running transactions.
The procedure and commands in this step depend on:
* your topology
* latency between data centers
* upgrade maintenance windows - **Window 1** to **Window 3** represent chosen maintenance windows.
For the Database Filesystem Conversion step below, *first* inspect the table below
for guidance on the commands to run according to your configuration and preferences.
* Run all commands on the primary unified node:
* Ensure states of database nodes are not DOWN - otherwise the command will fail:
**database config** (``stateStr`` is not ``DOWN``)
* Ensure database weights are set and there is 1 maximum weight - otherwise the command will fail:
**database weight list** (one ``weight`` value is maximum)
* For 2 and 3 maintenance windows: after the upgrade (prior to Windows 2 and 3), only nodes with converted drives will generate valid backups.
For example, if the primary drive is converted, backups from the primary node can be used to restore the database.
If there is a database failover to the highest weight secondary node that was not converted,
it will not be possible for backups to be generated on that secondary node until the drive is converted.
.. note::
The **database convert_drive** command can also be run on a single node only by running the following command
and parameter from the specific node: **database convert_drive standalone**. This option can for example be used
for performance reasons in cases where a node is in a remote location.
.. tabularcolumns:: |p{1.5cm}|p{1.2cm}|p{1.2cm}|p{1.2cm}|p{6.5cm}|p{4cm}|
+-----------+----------+----------+-----------+--------------------------------------------------+----------------------------------------------------+
| Topology | Window 1 | Window 2 | Window 3 | Commands (DC = valid data center name) | Description |
+===========+==========+==========+===========+==================================================+====================================================+
| multinode | Y | | | **database convert_drive secondary all** | Recommended for a system with latency < 10ms. |
| | | | | | |
| | | | | **database convert_drive primary** | |
+-----------+----------+----------+-----------+--------------------------------------------------+----------------------------------------------------+
| multinode | Y | Y | | Window 1: | Can be used for a system with latency < or > 10ms. |
| | | | | | |
| | | | | **database convert_drive primary** | Allows for smaller maintenance windows. |
| | | | | | |
| | | | | Window 2: | Cluster is not available during maintenance. |
| | | | | | |
| | | | | **database convert_drive secondary all** | |
+-----------+----------+----------+-----------+--------------------------------------------------+----------------------------------------------------+
| multinode | Y | Y | Y | Window 1: | Can be used for a system with latency > 10ms. |
| | | | | | |
| | | | | **database convert_drive primary** | Allows for smaller maintenance windows. |
| | | | | | |
| | | | | Window 2: | Cluster is not available during maintenance. |
| | | | | | |
| | | | | **database convert_drive secondary <first DC>** | |
| | | | | | |
| | | | | Window 3: | |
| | | | | | |
| | | | | **database convert_drive secondary <second DC>** | |
+-----------+----------+----------+-----------+--------------------------------------------------+----------------------------------------------------+
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+===========================================================================================+====================+
| Database Filesystem Conversion step | |
| | .. raw:: html |
| Shut down all the nodes. Since all services will be stopped, this takes some time. | |
| | <div><input |
| * **cluster run notme system shutdown --force && system shutdown --force** | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| Create a VMWare snapshot for all the unified servers so that the system can easily | for='isdone'> |
| be reverted in the case of a conversion error. | Done</label> |
| Boot all the systems in VMWare. | </div> |
| | |
| * Run the **convert_drive** command *with parameters according to the table above*. | |
| | |
| Wait until it completes successfully. | |
| | |
| * **database config** | |
| | |
| Ensure that the storage engine for *all converted database nodes* shows as | |
| ``storageEngine: WiredTiger`` | |
| | |
| * **drives list** | |
| | |
| Ensure that the LVM storage shows for *all converted database nodes* under | |
| ``Volume Groups`` | |
| | |
| In the example below, ``dbroot/dm-0`` shows under ``Volume Groups``, ``Logical volumes`` | |
| | |
| :: | |
| | |
| $ drives list | |
| Used disks and mountpoints: | |
| sdc1 - services:backups | |
| dm-0 - mongodb:dbroot | |
| | |
| Unused disks: | |
| none - if disks have been hot-mounted, it may be necessary to reboot the system | |
| | |
| Unused mountpoints: | |
| services:SWAPSPACE | |
| | |
| Volume Groups | |
| voss - 10.0 GB free, 60.0 GB total | |
| Physical volumes: | |
| sdd1 | |
| Logical volumes: | |
| dbroot/dm-0 - 50.0 GB | |
| | |
+-------------------------------------------------------------------------------------------+--------------------+
.. _19.2.1-19.3.2-Post-Template-Upgrade-Tasks:
Post Template Upgrade Tasks
....................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+===========================================================================================+====================+
| Verify the upgrade: | .. raw:: html |
| | |
| Log in on the GUI and check the information contained in the **About > Extended Version** | |
| menu. Confirm that versions have upgraded: | <div><input |
| | type='checkbox' |
| * **Release** should show 19.3.2 | id='done' |
| * **Platform Version** should show 19.3.2 | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| If your web browser cannot open the user interface, clear your browser cache before | </div> |
| trying to open the interface again. | |
| | |
+-------------------------------------------------------------------------------------------+--------------------+
.. _19.2.1-19.3.2-Restore_Schedules:
Restore Schedules
..........................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+---------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+=================================================================================+====================+
| Re-enable scheduled imports if any were disabled prior to the upgrade. | |
| Two options are available: | |
| | |
| Individually for each job: | |
| | |
| 1. Log in on the GUI as a high level administrator above Provider level. | |
| 2. Select the **Scheduling** menu to view scheduled jobs. | |
| 3. Click each scheduled job. On the Base tab, check the **Activate** check box. | |
| | |
| Mass modify: | |
| | |
| 1. Modify the exported sheet of schedules to activate scheduled syncs. | |
| 2. Import the bulk load sheet. | .. raw:: html |
| | |
| | <div><input |
| | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
| | |
+---------------------------------------------------------------------------------+--------------------+
.. 19.2.1-19.3.2-PBR-install-option:
Phone Based Registration Feature Installation (Optional)
...........................................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+-------------------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+===========================================================================================+====================+
| If the phone based registration feature is required, you will need to download the latest | |
| Phone Based Registration install script to all unified nodes before continuing with the | |
| installation steps below in order to install the latest version. | |
| | |
| The required files can be located on the secure downloads server under: | .. raw:: html |
| | |
| ``/software/voss4uc/releases/Release-19.3.2/pbr`` | <div><input |
| | type='checkbox' |
| Refer to the accompanying document `MOP-PBR-19.3.2.pdf`. | id='done' |
| | name='done' |
| Note that a full service restart is initiated on initial startup of the PBR web | unchecked> |
| service on each VOSS-4-UC unified node. | <label |
| | for='isdone'> |
| Verify the downloaded script: | Done</label> |
| | </div> |
| ``phone-based-registration_install-19.3.2.script`` | |
| | |
| with the accompanying SHA256 file: | |
| | |
| ``phone-based-registration_install-19.3.2.script.sha256`` | |
| | |
| * *On a cluster*: | |
| | |
| 1. Run the following command on all unified nodes in serial: | |
| | |
| ``app install media/phone-based-registration_install-19.3.2.script --force`` | |
| | |
| #. Run the following command on the primary node: | |
| | |
| ``cluster provision --force`` | |
| | |
| | |
| * *On a standalone system*: | |
| | |
| 1. Run the following command on the unified node: | |
| | |
| ``app install media/phone-based-registration_install-19.3.2.script --force`` | |
| | |
| | |
| #. Run the following command: | |
| | |
| ``system provision --force`` | |
| | |
| | |
| | |
| The PBR web service is assigned the same web weights | |
| as the ``selfservice`` and ``voss-deviceapi`` service. | |
| For example, when running **web weight list** from | |
| a web proxy, the output should be similar to the example | |
| below: | |
| | |
| | |
| :: | |
| | |
| platform@VOSS-WP-1:~$ web weight list | |
| Default service weights | |
| | |
| upstreamservers: | |
| phonebasedreg: | |
| phoneservices: | |
| 192.168.100.10:443: 0 | |
| 192.168.100.3:443: 1 | |
| 192.168.100.4:443: 1 | |
| 192.168.100.5:443: 1 | |
| 192.168.100.6:443: 1 | |
| 192.168.100.9:443: 0 | |
| voss-deviceapi: | |
| selfservice: | |
| 192.168.100.10:443: 0 | |
| 192.168.100.3:443: 1 | |
| 192.168.100.4:443: 1 | |
| 192.168.100.5:443: 1 | |
| 192.168.100.6:443: 1 | |
| 192.168.100.9:443: 0 | |
| voss-deviceapi: | |
| 192.168.100.10:443: 0 | |
| 192.168.100.3:443: 1 | |
| 192.168.100.4:443: 1 | |
| 192.168.100.5:443: 1 | |
| 192.168.100.6:443: 1 | |
| 192.168.100.9:443: 0 | |
| | |
+-------------------------------------------------------------------------------------------+--------------------+
.. _19.2.1-19.3.2-Log-Files-Error-Checks:
Log Files and Error Checks
....................................
.. tabularcolumns:: |p{13.5cm}|p{4cm}|
+----------------------------------------------------------------------------------+--------------------+
| Description and Steps | Notes and Status |
+==================================================================================+====================+
| Inspect the output of the command line interface for upgrade errors. | .. raw:: html |
| | |
| Use the **log view** command to view any log files indicated in the error | |
| messages, for example, run the command if the following message appears: | <div><input |
| | type='checkbox' |
| :: | id='done' |
| | name='done' |
| For more information refer to the execution log file with | unchecked> |
| 'log view platform/execute.log' | <label |
| | for='isdone'> |
| For example, if it is required send all the install log files in the ``install`` | Done</label> |
| directory to an SFTP server: | </div> |
| | |
| * **log send sftp://x.x.x.x install** | |
| | |
+----------------------------------------------------------------------------------+--------------------+
| | .. raw:: html |
| Log in on the GUI as system level administrator, go to | |
| **Administration Tools > Transaction** and inspect the transactions | <div><input |
| list for errors. | type='checkbox' |
| | id='done' |
| | name='done' |
| | unchecked> |
| | <label |
| | for='isdone'> |
| | Done</label> |
| | </div> |
| | |
+----------------------------------------------------------------------------------+--------------------+
.. _using-screen:
Notes on the ``screen`` command
===============================
From VOSS-4-UC 18.1 or CUCDM 11.5.3 onwards, the standard **screen**
command should be used where indicated, and
the `reconnect` parameter is available if needed:
* **screen** - start a new session
* **screen -ls** - show sessions already available
* **screen -r [screen PID]** - reconnect to a disconnected session
We recommend using the **screen**
command to avoid failures if the connection is interrupted whilst
running the command. If the connection is interrupted whilst running
the command in ``screen`` then the session can be retrieved by first
listing the sessions PID currently running in screen:
**screen -ls**, and then reconnecting to the session using
**screen -r [screen PID]**.
The version of **screen** used in VOSS-4-UC also supports the creation of a
log file. If long-running commands will be run, the log file
captures screen console output up to the session timeout.
A message shows:
::
timed out waiting for input: auto-logout
To create a screen log file:
1. Run **screen** and wait for screen to open.
2. Press **<Ctrl>-a** then **:** (colon). This will enter screen command mode
at the bottom of the console.
3. Create your screen logfile in the ``media/`` directory:
a. In screen command mode, type **logfile media/<screen-logfilename>.log**
#. Press **<Enter>**
#. Press **<Ctrl>-a** and then **H** to start writing to the log file
#. Run your commands.
If the **screen** session times out, you can obtain console output from
the log file, for example:
**$ sftp platform@<host>:media/<screen-logfilename>.log**