Introduction
These step-by-step instructions do not apply to libraries whose Sierra system is hosted by Innovative, as Sierra upgrades for those libraries are performed by Innovative staff as part of the hosting service. These instructions are intended to guide library or IT administrators through the process of upgrading their on-premises Sierra system to the current version, using the Sierra application’s self-upgrade function.
Self-upgrade from one Sierra version to another does not require any Linux command line manipulation, but local administrators of on-premises systems may need to use their command line access to check that operating system, network access, and repository access requirements are met before invoking the function. The self-upgrade function is implemented by a combination of shell scripts and Ansible plays, and are initiated by the menu selection Upgrade system software in Sierra’s Admin Corner menu.
The Upgrade system software function enables libraries to upgrade their Innovative software from Sierra 5.3 or higher to the current version, Sierra May 2026 Release (6.6). Earlier releases of Sierra cannot be self-upgraded to the current release due to differences in the Operating System requirements of those earlier Sierra releases versus the current release. If your Sierra Release 5.3 to Release 6.1 system is still running Red Hat or Oracle Linux 7, please take note of the Operating System requirements below, and the need to separately upgrade to Red Hat or Oracle Linux 8 before upgrading Sierra.
There is no system-down time during the Preparation Phase, so staff can continue to work. The system will not be available during the Commit Phase.
Operating System Requirements
Sierra 6.6 requires that the both the application and database servers use the same operating system version, which can be one of the following:
- Red Hat 8 or Oracle Linux 8
- Red Hat 9 or Oracle Linux 9
If your system is running an earlier Linux version it will be necessary to upgrade the operating system before the application upgrade can proceed. Contact your Innovative sales consultant for appropriate services to support performing that upgrade, and complete that operating system upgrade before attempting to update Sierra. Single version operating system updates, such as Red Hat or Oracle 7 to Red Hat or Oracle 8 can usually be performed in-place (the LEAPP method) on the same physical or virtual server instance, other starting versions or multiple version increments can be more complex.
Network Access Requirements
Self-upgrade checks and updates Sierra OS level dependencies as needed, and then downloads and installs an updated version of the Sierra application from Innovative’s servers. Before you invoke the menu driven self-upgrade function, you should use your command line access to confirm that the self-upgrade process will have access to all of these remote resources, so that the dependency and other updates will succeed:
-
Linux OS Repositories via HTTP / 80 and HTTPS / 443 – Access to the Linux OS vendor’s standard base operating system repositories (typically BaseOS and AppStream) must be provided to allow self-upgrade to dynamically update or install RPM packages as needed to meet the incoming Sierra version dependencies. This includes both network access and any necessary setup to access those repositories, including pre-registration of server instances if applicable, and should be done before self-upgrade of Sierra is attempted (See Note 1)
-
Host upgrade.iii.com via SSH / 22 – Network access on TCP Port 22 (SSH/SFTP) to host upgrade.iii.com, a control element and fallback file source for the self-upgrade, must be permitted
-
Amazon Web Services *.amazonaws.com via HTTP / 80 and HTTPS / 443 – Network access for HTTP and HTTPS must be provided to access CSDirect-managed upgrade content hosted on Amazon S3 (enabled at the start of each phase by entering passkey obtained from https://csdirect.iii.com/custconv-aws) and the innovative RPM package repository described further below in Meeting OS Package Dependencies (special repo and new dependency RPM), which is also hosted on Amazon S3
-
Ansible Galaxy collection hub via HTTP / 80 and HTTPS / 443 – Access to this resource must be permitted because the Ansible plays incorporated in Sierra upgrade rely on some community modules which may not always be present on the server, and in that event will automatically be fetched from the public https://galaxy.ansible.com collection hub
In previous Sierra releases, access to a number of additional repositories was requested, including Extra Packages for Enterprise Linux (EPEL), and Server Optional Packages, and others. Although it should not interfere with the self-upgrade process if these or other repositories are defined and enabled during upgrade for other reasons, these additional repositories beyond the vendor base operating system are no longer required.
Meeting OS Package Dependencies (special repo and new dependency RPM)
For each new Sierra software version to install and run on a library-supplied on-premises physical or virtual server instance, certain RPM-based packages must be present. Nearly all of these packages are supplied directly from the OS distribution vendor’s standard BaseOS repositories, but a few such as packages related to the RabbitMQ messaging system and its Erlang dependencies must be supplied by other means. Each Sierra release strives to reduce these non-BaseOS dependencies, to be sure the local administrator has a clear list, and to make provision as simple as possible. In the past, this was done through documentation and instruction, this new release introduces for the first time a dependency RPM file to simplify management, and continues the practice of providing a live repository to serve the packages. This recent change is summarized below:
| Sierra Version | How is dependency list provided? | How are dependent packages managed? | Notes |
|---|---|---|---|
| New with Sierra May 2026 Release (6.6), and forward. | New RPM packages sierra-depends-app and sierra-depends-db define dependencies, and are accessible in the normally disabled repository iii-sierra-product. No action is needed by the local administrator to install or maintain the packages, but they can be queried or examined with yum/dnf like any other package to summarize Sierra’s needs. | Sierra upgrade processes perform yum/dnf update to the sierra-depends package for app or db server role for the incoming Sierra version as part of upgrade, Sierra dependencies are then represented and protected by that installed package for life of that Sierra release. | The iii-product-repo must be disabled at all times except when automatically enabled by Sierra during upgrade events to avoid unintended Sierra changes when general OS updates are done by “dnf update”. To examine contents of repo, use the “--enablerepo=iii-product-repo” argument in individual yum/dnf commands . |
| Earlier Sierra Versions | Documentation provided as support publication, for manual review. | Sierra upgrade processes install/update packages by name, some constrained by versionlock, and assume that special repos such as EPEL are active, requiring administrator action. Direct access to specific publisher repos was required until release 5.3. No ongoing protection against changes to Sierra-dependency packages once installed. | Recent Sierra releases had reduced total packages and need for publisher repo access by use of Innovative repo, but was still hard for local administrators to follow the several changes, leaving legacy setups unnecessarily complicated. |
Local SSH Connection to Initiate and Manage Upgrade
To access the Admin Corner menu which includes Upgrade system software, you need a local SSH connection to the system, and a preshared key set up. You may use the free PuTTY SSH program or the SSH client of your choice. See the Sierra WebHelp for instructions on generating and downloading a private key to access the system via SSH to reach the Admin Corner menu with the upgrade option.
Upgrade Procedure Stages
The upgrade procedure consists of:
Preparation Phase — Complete a full backup within 24 hours of beginning the upgrade, authorize a user to perform the upgrade, and initiate the upgrade, which will perform a number of pre-checks such as for free disk space, and then proceed with non-disruptive upgrade steps, while users continue to use the system. If your server does not have enough disk space for the new software, or if you run into other reported errors, appropriate messages will be given, and you will work with Innovative Help Desk staff to expand storage or address other errors, and then re-attempt until the preparation steps complete fully. In scheduling the day/time for your upgrade preparation and commit, allow sufficient time between the prep and commit steps to work with Help Desk if needed to resolve prep issues.
Commit Phase — When possible after preparation is complete, inform users system will be unavailable, re-enter the upgrade function, and request to continue. This will restart the system in maintenance mode, after which you will reconnect with a special code to continue through the software upgrade process. When the upgrade completes (can take several hours), you will be prompted to reboot and begin running Sierra 6.6.
The Upgrade Checklist lists each step of the upgrade procedure. Use the checklist to ensure that you complete all of the necessary steps.
