SL1 Golden Gate 12.1.2 Release Notes

ScienceLogic strongly recommends that you review the installation and upgrade instructions, important notes about upgrading SL1, and known issues for this release before installing or upgrading to SL1 12.1.2.

As of version 12.1.2, SL1 no longer supports the legacy version of Data Pull. You will need to update all of your SL1 appliances to version 12.1.2, including your Data Collectors and Message Collectors, to avoid potential data loss. When all appliances are successfully upgraded to 12.1.2, SL1 will automatically deprecate legacy Data Pull. If you do not update SL1 appliances after 60 days, the data on those appliances will be lost, and you will need to redeploy the appliances.

The SL1 Golden Gate 12.1.2 release includes a major update to Data Pull, adds the ability to convert SL1 Message Collectors and Data Collectors to Oracle Linux 8, introduces Aurora 3.04.0 support for new AWS SL1 deployments, and much more.

These release notes provide a list of the features, enhancements, and addressed issues that are included in the SL1 Golden Gate 12.1.2 release.

To view a list of updates that were included in previous 12.1.x releases, see the following release notes:

New Features and Enhancements in SL1 Golden Gate 12.1.2

Authentication

  • Updated the default maximum number of simultaneous user sessions to 20,000.

Data Collection

  • Updated data collection storage objects to use JSON and deprecated the legacy version of Data Pull, the process by which SL1 Database Servers retrieve collected data from Data Collectors and Message Collectors. This deprecation is automatic when you upgrade your SL1 appliances to 12.1.2.

    • As of version 12.1.2, SL1 no longer supports the legacy version of Data Pull. You will need to update all of your SL1 appliances to version 12.1.2, including your Data Collectors and Message Collectors, to avoid potential data loss. When all appliances are successfully upgraded to 12.1.2, SL1 will automatically deprecate legacy Data Pull. If you do not update SL1 appliances after 60 days, the data on those appliances will be lost, and you will need to redeploy the appliances.

  • As part of the change to Data Pull, the "Enterprise Database: Collector Data Pull" processes were updated to process JSON messages.
  • A new admin notification now appears on the Appliance Manager page (System > Settings > Appliances) if you have appliances that are not yet upgraded to 12.1.2 that warns you to upgrade all appliances or risk losing data.

Deployment

  • For new deployments of SL1 12.1.2, the root partition has been increased from 10 GB to 20 GB and now uses GPT as the default partitioning scheme.
  • New SL1 12.1.2 deployments on AWS now utilize Aurora 3.04.0 (MySQL 8.0) and RDS R7g, and users who are currently deployed on Aurora 2.x (MySQL 5.7) are able to upgrade to this newer version as well. This deployment method has the option to support input/output (I/O)-optimized clusters.

Devices

  • When looking for device relationships, when data is collected from CDP or LLDP, if no match occurs between the device name and the collected name, SL1 will now perform an additional comparison with a device attribute.
  • Component identifiers, which can be defined in the collection objects of Dynamic Applications and enable SL1 to create and monitor component devices, are now included in the list of PowerPack-related fields that are not updated if you have the Enable Selective PowerPack Field Protection checkbox selected on the Behavior Settings page (System > Settings > Behavior).

Logging

  • The Session ID column was removed from the Access Sessions page (System > Monitor > Access Logs).

PowerPacks

  • When creating or editing a PowerPack, a new SHA-256 Checksum column now appears on the Compiled PowerPacks modal (System > Manage > PowerPacks > wrench icon > Build/Export).
  • SL1 12.1.2 includes "ScienceLogic Support Pack" PowerPack v107.

Security

  • 12.1.2 includes multiple package updates to improve security and system performance. Among these package updates are an upgrade to Kafka 3.6.0 and Kubernetes 1.29.

System Upgrade

  • Added the ability to convert SL1 Message Collectors and Data Collectors to Oracle Linux 8 (OL8) from Database Servers and Data Engines.

    For more information about converting your Message Collectors and Data Collectors to OL8, see the Important Upgrade Notes for SL1 Golden Gate 12.1.2 section of these release notes. For complete instructions, see the OL8 Conversion Resource Center on the ScienceLogic Support portal, which includes links to resources such as the Oracle Linux 8 Conversion Guide.

  • When upgrading SL1, Database Server and Data Engine appliances are now deployed first. Data Collector and Message Collector appliances are blocked from upgrading until the upgrades for Database Servers and Data Engines are complete.
  • When upgrading a data engine from Oracle Linux 7 (OL7) to OL8, a new precheck step verifies that load balancers and target groups are defined as expected to ensure that playbook executions pass successfully.
  • A new Platform column displays on the Appliance Manager page (System > Settings > Appliances) and on the Appliance List modal (System > Tools > Update > Appliance List) to indicate the current operating system and platform versions for your SL1 appliances. Potential values include el7 for appliances running on Oracle Linux 7 (OL7), el8 for appliances running on OL8, NULL, or Unknown. The platform value is highlighted when the primary Database Server is not running on the same platform version as the other appliances in the system.

Issues Addressed in SL1 Golden Gate 12.1.2

Agent

  • The directory /var/log/jmx-collector that is created by the agent installer now has permissions 774, while the log file within that directory has permissions 666. Additionally, the /var/log/scilogd.log file also has permissions 774. If you uninstall the agent, you should ensure that the /var/log/jmx-collector and /tmp/scilog directories are removed, as well as the /var/log/scilogd.log file. (Case: 00414437) (Jira ID: EM-63094)
  • Addressed an issue that was causing the SL1 agent to not correctly report when new network devices were added. With this update, Windows interfaces will now show the adapter name instead of the adapter GUID. (Case: 00399443) (Jira ID: AP-2723)
  • Resolved an issue that was causing the agent-vitals-interface-processor to terminate collection without completing (SIGTERM). (Case: 00412704) (Jira ID: EM-62907)
  • Ensured that the Linux and AIX agents properly return process information if the user running the agent is a non-root user. (Case: 00374670) (Jira ID: EM-61304)
  • Addressed an issue to ensure that the ability to disable agent data collection and set various maintenance modes works as intended on agent-monitored devices. (Case: 00386937) (Jira ID: EM-61726)

Business Services

  • Business service names with special characters now display correctly in debug messages and no longer result in unhandled exceptions on the event engine. (Cases: 00423483, 00424038) (Jira ID: EM-63687)

Credentials

  • SNMP credentials created in previous SL1 releases should now work for discovery and collection after upgrading to this release. (Case: 00429754) (Jira ID: EM-64236

Data Collection and Retention

  • Resolved an issue with the collector group load-balancing function in the Collector Task Manager process (em7_ctaskman), which was causing unhandled exception errors to occur when debug was enabled and devices needed to be assigned to Data Collectors. (Case: 00422820) (Jira ID: EM-63658)
  • The Concurrent SNMP service now properly handles SNMP v3 reports from agents without restarting and leaving a core file. (Case: 00354170) (Jira ID: EM-58928)
  • Addressed an issue that was causing the critical availability process to generate unhandled exception errors. (Case: 0403316) (Jira ID: EM-62788)
  • Resolved an issue where the daily maintenance process started in debug mode despite turning it off. (EM-59121)
  • Addressed an issue that was causing collection to fail on the "OSPF Neighbors Configuration" Dynamic Application, which is included in the "Generic Switch/Router MIB Support" PowerPack, due to a malformed object ID. (Case: 00321241) (Jira ID: EM-56941)

Devices

  • You can no longer delete a device class if it is aligned to a device. (Case: 00310455) (Jira ID: EM-55203)
  • Devices will no longer exit maintenance mode when belonging to a maintenance window comprising two sequential device schedules. (Case: 00258995) (Jira ID: EM-51742)
  • SL1 schedules for devices and device groups that have the same end times no longer result in a device remaining in maintenance beyond the end time. (Case: 00321089) (Jira ID: EM-56165)
  • Ensured that thresholds for Dynamic Applications aligned to a device show up in the device's Thresholds tab as expected. (Case: 00416990) (Jira ID: EM-63393)

Discovery

  • SNMP and device discovery no longer collect the SNMP v3 SysEngineId object ID (.1.3.6.1.6.3.10.2.1.1.0) from SNMP v1- or v2-configured devices, to address an issue that was causing SNMP collection to terminate without completing (SIGTERM). (Case: 00346960) (Jira ID: EM-63288)
  • Resolved an issue that caused network interfaces to be removed unexpectedly during nightly discovery due to SNMP timeouts or other errors. (Cases: 00387067, 00401470) (Jira ID: EM-61728)

Events

  • Resolved an issue where the system was creating events for devices in dynamic groups that were configured under event policy suppression in SL1 version 12.1.1. (Case: 00437366) (Jira ID: EM-64988)
  • Addressed an issue that prevented suppressed devices from adhering to suppression rules, which was resulting in randomly generated events. (Cases: 00414433, 00418039; 00418682) (Jira ID: EM-63432)

High-Availability and Disaster Recovery

  • Resolved an issue with high-availability configurations that prevented the secondary node from properly taking over after stopping pacemaker on the primary node. (Case: 00436449) (Jira ID: EM-64934)

Inbound Messaging

  • Made updates to ensure that SNMP trap OID translation works as intended. (Case: 00415585) (EM-63204)

Logging

  • Addressed an issue with nginx log rotation. (Case: 00393276) (Jira ID: EM-62020)

Monitoring Policies

  • When a user sets a sub-template for a Log Monitoring Policy in a Device Template, the name will no longer include the prefix "Test:". (Case: 00414429) (Jira ID: EM-63945)
  • Resolved an issue that caused Windows agent log file monitoring policies that use single slashes to randomly apply. (Cases: 00399531, 00431078) (Jira ID: EM-62278)

Platform

  • Updated some log levels and messages to more quickly identify errors with the "Enterprise Database: Collector Config Push" process (config_push.py). In addition, added two new configuration options for configuration push. Both of these options can be set in the [CONFIG_PUSH] section of the /etc/silo.conf file, although neither of them should need to be configured by default, and should be updated only if you are experiencing issues with configuration push:
    • The "worker_type" value can be set to either "thread", which is the default setting, or "process".
    • The "worker_retry_count" value can be set to specify how many times a worker thread should try to restart before making no further attempts. The default value is "3". (Case: 00355214) (Jira ID: EM-58999)
  • Resolved an issue that prevented AWS instances from initializing completely. (Case: 00370727) (Jira ID: EM-61404)
  • Added a signal handler to the builder processes to prevent unnecessary "signal 15" errors with the Enterprise Database: Collector Config Push process. (Case: 00394147) (Jira ID: EM-62216)

Reports

  • Ensured that reports generated on SaaS SL1 instances reflect the correct data. (Cases: 00308648, 00379163) (EM-55956, EM-55468)

Run Book Automations

  • Run Book automation notification icons now display as intended for cleared events. (Case: 00426605) (Jira ID: EM-63990)

Subscription Billing

  • Addressed an issue to ensure data delivery to ScienceLogic generates proper billing. (Case: 00415301) (Jira ID: PTEL-1795)
  • Collector groups (CUGs) that currently have no aligned Data Collectors will be converted to virtual CUGs upon upgrading to SL1 12.1.2 to ensure they are treated as non-billable as intended. This addresses an issue that was causing CUGs that were created in the default user interface (AP2) but had no aligned Data Collectors to be treated as non-virtual CUGs. (Jira ID: EM-64199)
  • Addressed an issue that prevented newly created Bandwidth Billing policies from showing any collected data in the performance graph or interface billing report after upgrading to 12.1 or later. (Case: 00411921) (EM-62873

System Update

  • Resolved several different issues involving the silo-migrate and silo-cluster-install scripts that were impacting the ability to upgrade SL1 from Oracle Linux 7 (OL7) to OL8. (Cases: 00402078, 00409233, 00412929, 00428562, 00429762) (Jira IDs: EM-62571, EM-62957, EM-63129, EM-64174, EM-64247)
  • The system_status.sh script was updated to address false-positive MariaDB version mismatch errors. (Case: 00407870) (Jira IDs: EM-62549, EM-64185)
  • Resolved an issue that was causing coro_config to fail after upgrading to SL1 12.1.1. (Cases: 00412482, 00415150) (Jira ID: EM-62888)
  • Updated the Cluster Resource Manager (CRM) template to ensure the crm-template-update script can properly update Pacemaker configurations of 12.x Oracle Linux 7 (OL7) high-availability (HA), disaster recovery (DR), and HA+DR stacks. (Case: 00402349) (Jira ID: EM-62440)

Recently Deprecated Features

12.1.0

  • The 12.1.0 release deprecates the following PowerPack and removes them from the ISO:

If you are upgrading from a previous version of SL1, the 12.1.2 upgrade will not remove any existing PowerPacks. The PowerPacks listed below are still available for download from the PowerPacks Support page.

  • 3Com Device Classes Base Pack
  • Alcatel-Lucent Base Pack
  • Alteon Monitoring Base Pack
  • APC Base Pack
  • AskEM7 Query Widgets
  • Attachmate Device Classes Base Pack
  • Avaya Base Pack
  • Avocent Base Pack
  • Blue Coat Monitoring Base Pack
  • Brocade: Base Pack
  • Citrix Monitoring Base Pack
  • Citrix: Xen
  • Danaher Device Classes Base Pack
  • DEC Device Classes Base Pack
  • Dell EMC: Isilon
  • Dell EMC: Unity
  • Dell EMC: VMAX and PowerMax Unisphere API
  • Dell OM Base Pack
  • Dell PowerConnect Base Pack
  • Dell PowerVault Event Policies
  • D-Link Device Classes Base Pack
  • EMC: VMAX
  • EMC: VNX
  • Empire Device Classes Base Pack
  • Enterasys Device Classes Base Pack
  • Extreme Base Pack
  • Fluke Networks
  • Force 10 Monitoring
  • Fortinet Base Pack
  • Foundry Base Pack
  • Google Base Pack
  • Hitachi Base Pack
  • HP-ISM Base Pack
  • HP Pro Curve Base Pack
  • HP-UX Base Pack
  • Intel Base Pack
  • Konica Minolta Base Pack
  • LANCOM Systems Device Classes
  • Lannair Device Classes
  • Lantronix Device Classes
  • Liebert Monitoring Base Pack
  • Linksys Device Classes
  • McAfee Monitoring
  • MIB-2 Base Pack
  • Microsoft: Azure Classic
  • Motorola Device Classes
  • NetBotz Base Pack
  • NetScout Systems Device Classes
  • Netscreen Base Pack
  • Nokia Base Pack
  • Printer Base Pack
  • Riverbed Monitoring
  • SMI-S: Array
  • SNMP Research Base Pack
  • UCD-SNMP Base Pack
  • VMware: vSphere Reports
  • Vyatta
  • Xerox Base Pack
  • In addition to the PowerPacks listed above, the "VMware: vSphere Base Pack" PowerPack has been removed from the 12.1.2 ISO due to a known issue. It is still available for SL1 systems that upgrade to 12.1.2 from an earlier release.
  • With the PHP updates that were made in SL1 11.1.0, the classic SL1 Global Manager was supported only up to the 10.2.x line. Because the 10.2.x release line has now reached end of life, the Classic Global Manager manual was deprecated from docs.sciencelogic.com.

11.3.0

  • The 11.3.0 release deprecated the following PowerPack and removed it from the ISO:
  • SL1: Concurrent PowerShell Monitor

Installing and Upgrading SL1

For a detailed overview of SL1, see the Introduction to SL1 manual.

For detailed instructions on performing a new installation of SL1, see the Installation and Initial Configuration manual.

For detailed instructions on upgrading SL1, see the section on Updating SL1 in the System Administration manual and the upgrade notes that are included in this document.

ScienceLogic strongly recommends that you review the Known Issues for SL1 (https://support.sciencelogic.com/s/known-issues#sort=relevancy) before installing a new update.

For known issues specific to this release, see the Known Issues section of this document.

SL1 Extended Architecture

For existing on-premises deployments of SL1 Extended Architecture, see the section on Upgrading SL1 Extended Architecture in the System Administration manual for upgrade instructions. For help with technical issues, contact ScienceLogic Customer Support.

 New installations of SL1 Extended Architecture are available only on SaaS deployments.

 

Important Upgrade Notes for SL1 Golden Gate 12.1.2

This section includes important notes for upgrading existing SL1 systems to the Golden Gate 12.1.2 release.

Unless otherwise stated, the information in this section applies to all users who are upgrading from previous SL1 versions.

ScienceLogic strongly recommends that you review these upgrade notes in their entirety before upgrading to version 12.1.2.

For detailed instructions on planning an upgrade, best practices for upgrades, and executing an upgrade, see the section on Upgrading SL1 in the System Administration manual.

Supported Upgrade Paths

Previous SL1 releases included major updates that you must first consume before you can upgrade to 12.1.2, if you have not done so already.

Therefore, depending on the version of SL1 that you are currently running, you might be required to upgrade to one or more earlier versions of SL1 before you can upgrade to 12.1.2.

You can upgrade to SL1 12.1.2 using one of the following upgrade paths:

See the sections below for additional details.

 

Upgrade Path 1: 12.1.x to 12.1.2 and all appliances are already on OL8

If you are currently on SL1 12.1.0.2 or 12.1.1 and your entire SL1 stack is already running on Oracle Linux 8 (OL8), you can upgrade directly to version 12.1.2.

Changes to how execution environments deploy in SL1 version 12.1.2 causes some execution environments to no longer work properly post-upgrade, which in turn can cause multiple PowerPacks to not run after you upgrade. For the 12.1.2 release, you should download and install the "SL1: Execution Environment Check" v100 PowerPack and follow the steps in the section Checking Your SL1 Execution Environments Before You Upgrade to ensure that your execution environments and PowerPacks will continue to work as intended post-upgrade. This PowerPack can be run on SL1 versions 11.3.1 to 12.1.2, so ScienceLogic recommends performing this check before you upgrade to 12.1.2.

To upgrade to version 12.1.2 from version 12.1.0.2 or 12.1.1:

  1. Check your SL1 Execution Environments.
  2. Download the 12.1.2 patch file from the ScienceLogic Support site.
  3. In SL1, go to the System Updates page (System > Tools > Updates) and import the 12.1.2 patch file.
  4. When the 12.1.2 patch has an Import Status of "Complete," stage the update.
  5. Run the pre-upgrade check to ensure all pre-deployment criteria are met.
  6. Deploy the SL1 12.1.2 update to your SL1 Database Server, Administration Portal, and/or Data Engine appliances. SL1 will then automatically deploy the update to your Message Collectors and Data Collectors.
  7. Upgrade MariaDB on your SL1 appliances to MariaDB 10.4.31.

    8. The SL1 stack will reboot after upgrading MariaDB.

  8. Optionally, you can also choose to upgrade the SL1 user interface to AP2 version 8.7.96 (French Toast).

 

Upgrade Path 2: 12.1.1 to 12.1.2 and currently running in mixed mode

If you are currently running SL1 12.1.1 in "mixed mode," where your Database Server, Administration Portal, and/or Data Engine have already been converted to Oracle Linux 8 (OL8) but your Message Collectors and Data Collectors are still running on OL7, you must follow the steps outlined in this section.

Before beginning this process, ScienceLogic strongly recommends that you review the Oracle Linux 8 Conversion Guide, which can be found on the OL8 Conversion Resource Center on the ScienceLogic Support portal. The Oracle Linux 8 Conversion Guide includes full conversion instructions based on your SL1 configuration.

Changes to how execution environments deploy in SL1 version 12.1.2 causes some execution environments to no longer work properly post-upgrade, which in turn can cause multiple PowerPacks to not run after you upgrade. For the 12.1.2 release, you should download and install the "SL1: Execution Environment Check" v100 PowerPack and follow the steps in the section Checking Your SL1 Execution Environments Before You Upgrade to ensure that your execution environments and PowerPacks will continue to work as intended post-upgrade. This PowerPack can be run on SL1 versions 11.3.1 to 12.1.2, so ScienceLogic recommends performing this check before you upgrade to 12.1.2.

To upgrade your SL1 system to 12.1.2 and convert your remaining SL1 appliances to OL8, you must complete the following tasks in order:

  1. Check your SL1 Execution Environments.

  2. Download the 12.1.2 patch file from the ScienceLogic Support site.

  3. In SL1, go to the System Updates page (System > Tools > Updates) and import the 12.1.2 patch file.

  4. When the 12.1.2 patch has an Import Status of "Complete," stage the update.

  5. Run the pre-upgrade check to ensure all pre-deployment criteria are met.

  6. Deploy the SL1 12.1.2 update to your SL1 Database Server, Administration Portal, and/or Data Engine appliances.

  7. Upgrade MariaDB on your SL1 appliances to MariaDB 10.4.31.

    If you experience an issue where the MariaDB upgrade is initially unsuccessful, with a "Preupgrade checks failed" message appearing in the log, attempt to run the MariaDB upgrade a second time. This typically fixes the issue.

    If the MariaDB upgrade fails while trying to pull the epel repository from any SL1 appliance, you can disable the repository by editing /etc/yum.repos.d/epel.repo and setting enabled=0 in the file. Then run the MariaDB upgrade again.

    The SL1 stack will reboot after upgrading MariaDB.

  8. On each Database Server, Administration Portal, and/or Data Engine appliance, upgrade the SL1 user interface to AP2 version 8.7.96 (French Toast). This version of AP2 includes an option that you will need to run the OL8 conversion process for your SL1 Message Collector and Data Collector appliances.

  9. After AP2 version 8.7.96 (French Toast) is installed, ensure that the libem7 IPC service is running.

  10. Using SSH to access your Database Server or Data Engine, enable the siloupdate-dist-upgrade.service.

  11. Copy the 12.1.2 OL8 ISO file to the Database Server or Data Engine, upload that ISO file to the filestore, and then set and stage the image.

  12. If you are currently deploying SL1 using Aurora 2 RDS (MySQL 5.7), upgrade to Aurora 3 RDS (MySQL 8.0). Otherwise, you can skip this step.

    For assistance upgrading to Aurora 3 RDS (MySQL 8.0), contact ScienceLogic Support.

  13. Begin the OL8 operating system conversion for your Message Collector and Data Collector appliances. For more information, see the OL8 Conversion Resource Center on the ScienceLogic Support portal, which includes links to the Oracle Linux 8 Conversion Guide with full conversion steps for this process. You will use the Collector Groups page (Manage > Collector Groups) in SL1 to convert the Message Collectors and Data Collectors to OL8.

    Before proceeding further, you should ensure that your Message Collector and Data Collectors have more than 90 GB of hard disk space and at least 6 GB of RAM. If the Message Collector or Data Collector does not have 90 GB or more of hard disk space, you should increase the disk size to the 90 GB minimum to ensure that you can use the OL8 conversion utility. If you do not, you will need to re-ISO the collector appliance instead.

    ScienceLogic also highly recommends that you enable failover for your collector groups that will be impacted by upgrading to 12.1.2 and converting to OL8. For more information on enabling failover, see the section on Collector Groups in the System Administration manual.

    During this process, MariaDB will be upgraded to 10.4.31 on your Message Collectors and Data Collectors.

    If you experience an issue where the MariaDB upgrade is initially unsuccessful, with a "Preupgrade checks failed" message appearing in the log, attempt to run the MariaDB upgrade a second time. This typically fixes the issue.

    When converting AWS SL1 collectors to Oracle Linux 8 (OL8), you might experience an issue where the collectors stop in the middle of the conversion and do not restart automatically, leaving the conversion process hanging. If this occurs, you can go into the AWS console and restart the collector manually.

    After upgrading all of your SL1 appliances to 12.1.2 and converting all appliances to Oracle Linux 8, a known issue might cause the MariaDB field for your appliances to be highlighted on the Appliance Manager page (System > Settings > Appliances) in SL1. If the appliances are showing the correct MariaDB version of 10.4.31, this highlighting can be safely ignored.

 

Upgrade Path 3: 12.1.x or 11.x to 12.1.2 and converting all appliances to OL8

If you are currently running one of the following versions of SL1 and you want to upgrade to SL1 12.1.2 and convert all of your SL1 appliances to OL8, you must follow the steps outlined in this section:

  • 12.1.x (with all appliances running on OL7)
  • 11.x

Changes to how execution environments deploy in SL1 version 12.1.2 causes some execution environments to no longer work properly post-upgrade, which in turn can cause multiple PowerPacks to not run after you upgrade. For the 12.1.2 release, you should download and install the "SL1: Execution Environment Check" v100 PowerPack and follow the steps in the section Checking Your SL1 Execution Environments Before You Upgrade to ensure that your execution environments and PowerPacks will continue to work as intended post-upgrade. This PowerPack can be run on SL1 versions 11.3.1 to 12.1.2, so ScienceLogic recommends performing this check before you upgrade to 12.1.2, so long as you're currently on version 11.3.1 or later.

To upgrade your SL1 system to 12.1.2 and convert all of your SL1 appliances to OL8, you must complete the following tasks in order:

  1. If you are currently running a version of SL1 prior to 11.3.0, you must first download, import, stage, and deploy version 11.3.x. Otherwise, if you are already running SL1 11.3.x or later, you can proceed to step 3.

  2. After upgrading to 11.3.x, you must upgrade MariaDB on your SL1 appliances to the MariaDB version that corresponds to that SL1 release.

    The SL1 stack will reboot after upgrading MariaDB.

  3. Check your SL1 Execution Environments.

  4. If you are running a version of SL1 prior to 12.1.0.2, you must download and import version 12.1.0.2 to your SL1 system. Otherwise, if you are already running SL1 12.1.0.2 or 12.1.1, you can proceed to step 5.

    You do not need to stage or deploy the 12.1.0.2 update; you just need to import it. As part of this import process, you will need to pause for 30 minutes so the import process can import an RPM file.

  5. Download the 12.1.2 patch file from the ScienceLogic Support site.

  6. Import the SL1 12.1.2 update. To do so, you must do one of the following:

    • If you were running a version of SL1 prior to SL1 12.1.0.2 and have not deployed 12.1.0.2 or 12.1.1, you must import the 12.1.2 update using the command line interface. Proceed to step 7.

    • If you have already deployed SL1 12.1.0.2 or 12.1.1, then in SL1, go to the System Updates page (System > Tools > Updates) and import the 12.1.2 patch file. When the 12.1.2 patch has an Import Status of "Complete," proceed to step 11.

  7. SSH in to your primary Database Server or All-in-One Appliance and ensure that you have at least 7GB of free space on the partition where the patch file will be uploaded.

  8. Upload the patch file to your primary Database Server or All-in-One Appliance. Write down the file path of the patch file.

  9. Use the following command to import the patch file on to your primary Database Server or All-in-One Appliance:

    siloupdate import-patch <file path to patch file>

    where you replace <file path to patch file> with the file path you wrote down in the previous step.

    It will take several minutes for this command to complete.

  10. When the command completes, log in to SL1 and go to the System Updates page (System > Tools > Updates). Confirm that the 12.1.2 patch is listed and that it has an Import Status of "Complete."

  11. Stage the update.

  12. Run the pre-upgrade check to ensure all pre-deployment criteria are met.

  13. Deploy the SL1 12.1.2 update to your SL1 Database Server, Administration Portal, and/or Data Engine appliances.

  14. Upgrade MariaDB on your SL1 appliances to MariaDB 10.4.29.

    If you experience an issue where the MariaDB upgrade is initially unsuccessful, with a "Preupgrade checks failed" message appearing in the log, attempt to run the MariaDB upgrade a second time. This typically fixes the issue.

    If the MariaDB upgrade fails while trying to pull the epel repository from any SL1 appliance, you can disable the repository by editing /etc/yum.repos.d/epel.repo and setting enabled=0 in the file. Then run the MariaDB upgrade again.

    The SL1 stack will reboot after upgrading MariaDB.

  15. On each Database Server, Administration Portal, and/or Data Engine appliance, upgrade the SL1 user interface to AP2 version 8.7.96 (French Toast). This version of AP2 includes an option that you will need to run the OL8 conversion process for your SL1 Message Collector and Data Collector appliances.

  16. After AP2 version 8.7.96 (French Toast) is installed, ensure that the libem7 IPC service is running.

  17. Using SSH to access your Database Server or Data Engine, enable the siloupdate-dist-upgrade.service.

  18. Copy the 12.1.2 OL8 ISO file to the Database Server or Data Engine, upload that ISO file to the filestore, and then set and stage the image.

  19. If you are currently deploying SL1 using Aurora 2 RDS (MySQL 5.7), upgrade to Aurora 3 RDS (MySQL 8.0). Otherwise, you can skip this step.

    For assistance upgrading to Aurora 3 RDS (MySQL 8.0), contact ScienceLogic Support.

  20. Begin the OL8 operating system conversion for your Database Server, Administration Portal, and/or Data Engine appliances. For more information, see the OL8 Conversion Resource Center on the ScienceLogic Support portal, which includes links to the Oracle Linux 8 Conversion Guide with full conversion steps for this process. You will use the Collector Groups page (Manage > Collector Groups) in SL1 to convert the Message Collectors and Data Collectors to OL8.

    Before proceeding further, you should ensure that your Message Collector and Data Collectors have more than 90 GB of hard disk space and at least 6 GB of RAM. If the Message Collector or Data Collector does not have 90 GB or more of hard disk space, you should increase the disk size to the 90 GB minimum to ensure that you can use the OL8 conversion utility. If you do not, you will need to re-ISO the collector appliance instead.

    ScienceLogic also highly recommends that you enable failover for your collector groups that will be impacted by upgrading to 12.1.2 and converting to OL8. For more information on enabling failover, see the section on Collector Groups in the System Administration manual.

    During this process, MariaDB will be upgraded to 10.4.31 on your Database Server, Administration Portal, and/or Data Engine appliances.

    If you experience an issue where the MariaDB upgrade is initially unsuccessful, with a "Preupgrade checks failed" message appearing in the log, attempt to run the MariaDB upgrade a second time. This typically fixes the issue.

    When converting AWS SL1 collectors to Oracle Linux 8 (OL8), you might experience an issue where the collectors stop in the middle of the conversion and do not restart automatically, leaving the conversion process hanging. If this occurs, you can go into the AWS console and restart the collector manually.

    After upgrading all of your SL1 appliances to 12.1.2 and converting all appliances to Oracle Linux 8, a known issue might cause the MariaDB field for your appliances to be highlighted on the Appliance Manager page (System > Settings > Appliances) in SL1. If the appliances are showing the correct MariaDB version of 10.4.31, this highlighting can be safely ignored.

    You might experience an issue where the spool service is disconnected after the Database Server conversion to OL8. If this occurs, after the conversion, you can use SSH to access the Database Server and use the following command to restart the spool service:

    sudo systemctl restart siloupdate-spool.service

    Not doing so might cause you to experience an error while performing the OL8 conversion for your collector appliances.

 

Upgrade Path 4: 12.1.x or 11.x to 12.1.2 and remaining on OL7

All customers must upgrade to SL1 version 12.1.1 or later and convert to OL8 by October 31, 2024, or before upgrading to SL1 version 12.2.x. If you take no action, all older SL1 systems with OL7 will continue to run, but ScienceLogic will not support them and the systems might not be secure.

Changes to how execution environments deploy in SL1 version 12.1.2 causes some execution environments to no longer work properly post-upgrade, which in turn can cause multiple PowerPacks to not run after you upgrade. For the 12.1.2 release, you should download and install the "SL1: Execution Environment Check" v100 PowerPack and follow the steps in the section Checking Your SL1 Execution Environments Before You Upgrade to ensure that your execution environments and PowerPacks will continue to work as intended post-upgrade. This PowerPack can be run on SL1 versions 11.3.1 to 12.1.2, so ScienceLogic recommends performing this check before you upgrade to 12.1.2, so long as you're currently on version 11.3.1 or later.

If you are currently running one of the following versions of SL1 and you do not want to convert your operating system to Oracle Linux 8 (OL8), you must follow the steps outlined in this section:

  • 12.1.x (with all appliances running on OL7)
  • 11.x

To upgrade your SL1 system and remain on OL7, you must complete the following tasks in order:

  1. If you are currently running a version of SL1 prior to 11.3.x, you must first download, import, stage, and deploy version 11.3.x. Otherwise, if you are already running SL1 11.3.x or later, you can proceed to step 3.

  2. After upgrading to 11.3.x, you must upgrade MariaDB on your SL1 appliances to the MariaDB version that corresponds to that SL1 release.

    The SL1 stack will reboot after upgrading MariaDB.

  3. Check your SL1 Execution Environments.

  4. If you are running a version of SL1 prior to 12.1.0.2, you must download and import version 12.1.0.2 to your SL1 system. Otherwise, if you are already running SL1 12.1.0.2 or 12.1.1, you can skip to step 5.

    You do not need to stage or deploy the 12.1.0.2 update; you just need to import it. As part of this import process, you will need to pause for 30 minutes so the import process can import an RPM file.

  5. Download the 12.1.2 patch file from the ScienceLogic Support site.

  6. Import the SL1 12.1.2 update. To do so, you must do one of the following:

    • If you have already deployed SL1 12.1.0.2 or 12.1.1, then in SL1, go to the System Updates page (System > Tools > Updates) and import the 12.1.2 patch file. When the 12.1.2 patch has an Import Status of "Complete," proceed to step 11.

    • If you were running a version of SL1 prior to SL1 12.1.0.2 and have not deployed 12.1.0.2, you must import the 12.1.2 update using the command line interface. Proceed to step 7.

  7. SSH in to your primary Database Server or All-in-One Appliance and ensure that you have at least 7GB of free space on the partition where the patch file will be uploaded.

  8. Upload the patch file to your primary Database Server or All-in-One Appliance. Write down the file path of the patch file.

  9. Use the following command to import the patch file on to your primary Database Server or All-in-One Appliance:

    siloupdate import-patch <file path to patch file>

    where you replace <file path to patch file> with the file path you wrote down in the previous step.

    It will take several minutes for this command to complete.

  10. When the command completes, log in to SL1 and go to the System Updates page (System > Tools > Updates). Confirm that the 12.1.2 patch is listed and that it has an Import Status of "Complete."

  11. Stage and deploy the SL1 12.1.2 update.

  12. Upgrade your SL1 appliances to MariaDB 10.4.29.

    If you were previously running a previous 12.1.x release and had already upgraded your SL1 appliances to MariaDB 10.4.29, you can skip this step.

  13. Optionally, you can also choose to upgrade the SL1 user interface to AP2 version 8.7.96 (French Toast).

 

Upgrade Path 5: 8.x or 10.x to 12.1.2

If you are currently running a version of SL1 8.x or 10.x, you must first upgrade to the following releases prior to upgrading to 12.1.2, depending on your current version:

  • 8.12.x, which included a new system update tool.
  • 10.x, which included an upgrade from MariaDB 10.1 to MariaDB 10.4.
  • 11.3.x, which included a conversion of all PHP code to PHP 7.

Because of these changes, as well as changes made to the siloupdate-manager service in 12.1.0.2, if you are currently running version 10.x or earlier, then the upgrade to SL1 version 12.1.2 might require multiple maintenance windows:

  1. If you are on a version of SL1 prior to 8.12.x, upgrade to version 8.12.x. Otherwise, skip to step 3.

  2. If you are upgrading to SL1 8.12.0, upgrade to the MariaDB version 10.1.38; if you are upgrading to SL1 8.12.1 or 8.12.2, upgrade to MariaDB 10.1.40.

    The SL1 stack will reboot after upgrading MariaDB.

  3. If you are on a version of SL1 prior to 10.x, upgrade to version 10.x. Otherwise, skip to step 5.

  4. Upgrade to the MariaDB version that corresponds to that SL1 release.

    The SL1 stack will reboot after upgrading MariaDB.

  5. If you are on a version of SL1 prior to 11.3.x, upgrade to version 11.3.x.

  6. Upgrade to the MariaDB version that corresponds to that SL1 release.

    The SL1 stack will reboot after upgrading MariaDB.

  7. Follow the remaining steps in one of the following sections, based on whether you are converting to OL8 or remaining on OL7:

Before upgrading between SL1 versions, consult the appropriate release notes or contact ScienceLogic Support to ensure that the upgrade paths between those versions are supported.

For additional important notes, see the section on Upgrading from Version 8.14.x or Earlier.

For additional information about the PHP conversion and its impact, see the section on PHP Updates.

 

Upgrading MariaDB and Rebooting SL1

Some SL1 versions include important security updates. To apply these updates, you must upgrade MariaDB and then reboot all SL1 appliances.

For instructions on updating MariaDB or rebooting the SL1 system, see the section on Updating SL1 in the System Administration manual.

If you would like assistance in planning an upgrade path that meets your security needs while minimizing downtime, please contact your Customer Success Manager.

The following table specifies the required MariaDB version for each SL1 version and which SL1 updates require you to reboot all SL1 appliances:

SL1 Release Required MariaDB Version Requires Appliance Reboot?
12.1.2 (OL8) 10.4.31 Yes
12.1.2 (OL7) 10.4.29 Yes
12.1.1 (OL8) 10.4.28 Yes
12.1.1 (OL7) 10.4.29 Yes
12.1.0.2 ISO (OL8) 10.4.28 N/A
12.1.0.2 Upgrade (OL7) 10.4.29 Yes
11.3.2 10.4.28 Yes
11.3.1 10.4.28 Yes
11.3.0 10.4.26 Yes
11.2.4 10.4.28 Yes
11.2.3 10.4.28 Yes
11.2.2 10.4.26 Yes
11.2.0 10.4.24 Yes
11.1.6.1 10.4.28 Yes
11.1.6 10.4.28 Yes
11.1.5 10.4.26 Yes
11.1.4 10.4.26 Yes
11.1.3 10.4.25 Yes
11.1.2 10.4.24 Yes
11.1.1 10.4.22 Yes
11.1.0 10.4.20 Yes
10.2.7 10.4.27 Yes
10.2.6.1 10.4.26 Yes
10.2.6 10.4.26 Yes
10.2.5 10.4.22 Yes
10.2.4.1 10.4.22 Yes
10.2.4 10.4.22 Yes
10.2.3 10.4.21 Yes
10.2.2 10.4.18 Yes
10.2.1 10.4.18 Yes
10.2.0 10.4.18 Yes
10.1.8.1 10.4.21 Yes
10.1.8 10.4.21 No
10.1.7 10.4.18 No
10.1.6 10.4.18 Yes
10.1.5 10.4.12 Yes
10.1.4 10.4.12 Yes
10.1.3 10.4.12 Yes
10.1.2 10.4.12 No
10.1.1 10.4.12 Yes
10.1.0 10.4.12 Yes

Checking for SL1 Execution Environments That Will Not Run in 12.1.2

All Snippet Dynamic Applications include a linked execution environment that includes any libraries needed for the snippet to run. SL1 version 12.1.2 includes a change to better isolate these environments, so one bad library does not break other Dynamic Applications.

However, these changes in SL1 12.1.2 cause some execution environments to no longer work properly after upgrading to 12.1.2, which in turn can cause multiple PowerPacks that use those problematic execution environments to not run after you upgrade.

For more information about the specific issues that can cause an execution environment in SL1 12.1.2 to not deploy or function correctly post-upgrade, see the following knowledge base article: https://support.sciencelogic.com/s/article/15301

For the 12.1.2 release, you should download and install the latest version of the "SL1: Execution Environment Check" PowerPack, which includes a Dynamic Application that can be used to detect execution environments that will fail to deploy or fail to work after they are deployed.

This PowerPack can be run on SL1 versions 11.3.1 to 12.1.2, so ScienceLogic recommends performing this check before you upgrade to 12.1.2, so long as you're currently on version 11.3.1 or later.

To check your execution environments, follow the instructions in this section.

Step 1: Installing the "SL1: Execution Environment Check" v100 PowerPack

To install the "SL1: Execution Environment Check" PowerPack, perform the following steps:

  1. Ensure that you are running a version of SL1 between 11.3.1 and 12.1.2.
  2. From the PowerPacks page (Product Downloads > PowerPacks & SyncPacks) at the ScienceLogic Support Site, search for and download the latest version of the "SL1: Execution Environment Check" PowerPack.
  3. In SL1, go to the PowerPacks page (System > Manage > PowerPacks).
  4. Click the Actions menu and choose Import PowerPack. The Import PowerPack modal appears.
  5. Click Browse and navigate to the "SL1: Execution Environment Check" PowerPack file that you downloaded in step 2.
  6. Select the PowerPack file and click Import. The PowerPack Installer modal displays a list of the PowerPack contents.
  7. Click Install. The PowerPack is added to the PowerPack Manager page.

Step 2: Checking for Problematic Execution Environments

After you have installed the "SL1: Execution Environment Check" PowerPack, you must create a virtual device on which you can run the Dynamic Application that is included in the PowerPack, and then review the data collected from that Dynamic Application to determine which execution environments might not run properly in SL1 12.1.2.

To do so:

  1. Go to the Device Manager page (Devices > Device Manager).

  2. Click the Actions button and select Create Virtual Device from the menu. The Virtual Device modal page appears.

  3. Enter values in the following fields:

    • Device Name. Enter a name for the device.

    • Organization. Select the organization for this device.

    • Device Class. Select any device class.

    • Collector. Select a collector group.

      The Dynamic Application you will need to run on the virtual device will fully use one CPU core while it is running. Therefore, ScienceLogic recommends selecting a collector group that is not already overloaded, as doing so could impact data collection.

  4. Click Add to create the virtual device.

  5. You must now manually align the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application, which was included in the PowerPack, to your new virtual device. To do so, go to the Devices page (Devices > Devices).

  6. Locate your new virtual device and click its name to open the Device Investigator.

  7. In the Device Investigator, click the Collections tab.

  8. Click the Edit button at the top of the page, then click the Align Dynamic App button.

  9. In the Align Dynamic Application modal, click Choose Dynamic Application.

  10. Locate the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application and click Select.

  11. In the Align Dynamic Application modal, de-select the Use Device SNMP Credential checkbox. Click the Choose Credential option that appears.

  12. Select any credential except the default SNMP credential, and click Select.

  13. Click Align Dynamic App to align the Dynamic Application with the virtual device. The Dynamic Application appears on the Collections tab.

  14. On the Collections tab, click the Poll Frequency value for the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application. A sidebar opens where you can edit the Dynamic Application properties.

  15. In the Poll Frequency field, select 15 minutes, and then click Save.

  16. Wait at least 15 minutes for collection to run.

  17. From the Device Investigator, click the Configs tab and check results from the collection. This page shows the results of the collection from the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application, and indicates the following information for each execution environment:

    • Environment GUID. The execution environment's globally unique identifier.

    • Environment Name. The name of the execution environment.

    • Deploys? Indicates whether the execution environment will deploy successfully on SL1 12.1.2.

    • Script Runs? Indicates whether the execution environment will be able to run Dynamic Applications successfully in SL1 12.1.2.

  18. For each environment that has a "No" value in the Deploys? or Script Runs? columns, SL1 will trigger an event that appears on the Events page as well as on the Events tab of the Device Investigator for the virtual device you created.

After noting which execution environments have a "No" value in the Deploys? or Script Runs? columns, you should change the polling frequency for the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application to 24 hours, so the Dynamic Application stops performing collection every 15 minutes. To do so, go to the Devices page and locate the virtual device you previously created. Click its name to open the Device Investigator, and then click the Collections tab. Click Edit, and then click the Poll Frequency value for the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application. On the sidebar that opens, change the Poll Frequency value to 24 hours, and then click Save.

Step 3: Resolving Problematic Execution Environments

If the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application indicated that you have problematic execution environments, see the following knowledge base article for resolution steps: https://support.sciencelogic.com/s/article/15301

When you are finished resolving these issues and you have confirmed that all execution environments are updated properly, you should disable the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application. To do so, go to the Dynamic Applications Manager page (System > Manage > Dynamic Applications) and locate the "SL1: Execution Environment Check (12.1.2, 12.3.0)" Dynamic Application. Click its wrench icon. On the Dynamic Applications Properties Editor modal, in the Operational State field, select Disabled. Then click Save.

Obtaining a ScienceLogic Key for Agent RPM Packages

As of SL1 version 12.1.1, RPM installer packages are now signed. Therefore, when installing an RPM package, you might receive a warning message similar to the following one if the RPM store does not contain ScienceLogic's public GPG key:

warning: all silo-agent-x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 3a6131f6: NOKEY

To address or prevent this warning, you can obtain the ScienceLogic key and then add it to the RPM store. To do so:

  1. Go to https://keys.openpgp.org/search?q=devops%40sciencelogic.com.
  2. Download the key.

  3. Import the key into the RPM store using the following command:

    rpm --import <file name>

Validating Agent TLS Connections to the SL1 Streamer Service

As of SL1 12.1.1, customers who use the SL1 Gen 3 agent with on-premises Extended Architecture systems have the option to turn on TLS certificate validation when deploying the Streamer service. This provides additional security to confirm that the agent's connection to SL1 is valid.

To enable this TLS validation, the extended cluster must be configured with a valid TLS certificate and the "requireTls" setting in the Streamer helm chart must be set to "true" when deploying the Streamer, such as in the following command:

helm upgrade --version 1.2.13 streamer sl1/sl1-streamer -f output-files/steamer-values.yml --set requireTls=true

If you update this setting, the Streamer pods will restart and the agent will download the new configuration upon its next communication with the cluster.

This TLS validation is currently disabled by default for on-premises Extended Architecture deployments.

If you want to enable this feature, it is important to first ensure that the Streamer end point that is provided via the URLFRONT installation option is configured with a valid TLS certificate. If the agent is configured to validate the TLS connection but the cluster it is trying to communicate with does not have a valid TLS certificate, the agent will be unable to communicate with that cluster.

If this occurs, you can disable the validation by updating the Streamer deployment to disable the "requireTls" setting, updating the scilog.conf file to remove or alter the "RequireWebCert true" line, and then restarting the agent.

This feature can be enabled on SaaS SL1 deployments by submitting a Service Request case to the SRE queue at the ScienceLogic Support site at https://support.sciencelogic.com/s/, or by contacting your ScienceLogic customer service manager.

System Update Notes

  • SL1 updates overwrite changes to the configuration file /opt/em7/nextui/nextui.env. This is a known issue. (For more details, see https://support.sciencelogic.com/s/article/1161 and https://support.sciencelogic.com/s/article/1423.) ScienceLogic recommends that you back up this file before applying an update and then reapply your changes to this file.
  • The SL1 user interface will be unavailable intermittently during system update.
  • During the normal system update process, multiple processes are stopped and restarted. This might result in missed polls, gaps in data, and/or unexpected errors. ScienceLogic recommends that you always install SL1 releases during a maintenance window.
  • The SL1 system update process starts a background process that can perform any required post-upgrade tasks. The post-patch update process is automatically stopped after 24 hours. However, depending on the size of your database as well as the version from which you are upgrading, the post-upgrade tasks can take several days to perform. If the post-patch update process is stopped after 24 hours, the process will automatically re-start and continue processing from the point at which it was stopped. If you see an event that indicates the post-patch update process was stopped, you do not need to contact ScienceLogic support for assistance until you see the same event for three consecutive days.

Verifying PowerPack Version Compatibility

Before consuming SL1 12.1.2, please verify whether any PowerPacks currently running on your system are newer than the PowerPacks included in this release.

If the PowerPack on your system is newer than the one included with this release, you might see spurious error messages.

To avoid spurious error messages:

  1. Before installing the SL1 update, go to the Device Components page (Registry > Devices > Device Components).
  2. Find each root device associated with the PowerPacks you do not want to update and select their checkboxes.
  3. Click the Select Action field and choose Change Collection State: Disabled (recursive), and then click the Go button.
  4. Wait five minutes after disabling collection.
  5. Install the SL1 update.
  6. After the SL1 update is complete, go to the Device Components page (Registry > Devices > Device Components).
  7. Select the checkbox for all affected root devices.
  8. Click the Select Action field and choose Change Collection State: Enabled (recursive), and then click the Go button.

Future Python 2 Support Deprecation

Prior to SL1 11.3.0, all Dynamic Application snippets, Execution Environments, Run Book Actions, and ScienceLogic Libraries utilized Python 2.

With the introduction of Python 3 support in 11.3.0, ScienceLogic announced its intent to deprecate support for Python 2 in a future release. The core SL1 platform will switch to Python 3 with the 12.3.0 (Ibiza) release.

However, ScienceLogic will still include Python 2 in parallel with Python 3 until the 12.5.0 (Juneau) release, slated for release in Q2 2025, at which point it will be completely removed from SL1. At that time, customers still using Python 2 in any custom content—including customer-created PowerPacks—will be unable to update to the 12.5.0 (Juneau) release until their custom code is Python 3-compatible.

For more information, see the Python 3 Resource Center on the ScienceLogic Support site, as well as this knowledge base article: https://support.sciencelogic.com/s/article/12014.

Global Manager Deployment

When deploying or upgrading Global Manager systems, the Global Manager stack and all of its child stacks must run on the same SL1 build version, as well as the same versions of AP2 and Oracle Linux.

SSH Collector Removal

This section applies to users who are upgrading from SL1 11.3.x or earlier. If you are upgrading from SL1 12.1.0 or later, you can ignore this section.

The SSH Collector container was removed from SL1 in version 12.1.0. To support this change, the "Data Collection: SSH Collector" process is no longer available in new installations of SL1 as of 12.1.0 or later.

If you are upgrading to 12.1.2 from an earlier release and you were previously using the SSH Collector, you must reboot any Data Collectors that were previously using the "Data Collection: SSH Collector" process. After upgrading SL1, you can go to the Appliance Manager page (System > Settings > Appliances) to determine which appliances might require a reboot.

Required PowerPack Updates

This section applies to users who are upgrading from SL1 11.2.x or earlier. If you are upgrading from SL1 11.3.0 or later, you can ignore this section.

Required Version Updates

If you are using the following PowerPacks and you are upgrading from SL1 11.2.x or earlier, you must upgrade to the specified minimum supported versions before upgrading to SL1 version 12.1.2:

  • Cisco: ACI v112
  • Cisco: AppDynamics v102
  • Cisco: Cloud Services Platform v107
  • Cisco: Viptela v104
  • Datacenter Advanced Enrichment Actions v106
  • Dynatrace v105
  • HTTP Action Type v103
  • IBM: DB2 v104
  • Kubernetes v104
  • Linux: Base Pack v105
  • Linux SSH Automation v104
  • Microsoft: Azure v115
  • Microsoft: Office 365 v106
  • NetApp: Base Pack v106
  • Oracle: MySQL v102
  • VMware Automation v102
  • Windows PowerShell Automation v104

Earlier versions of these PowerPacks will not prevent SL1 version 12.1.2 from installing or operating, but they might not operate as expected after the SL1 upgrade due to technical incompatibilities.

Required Credential Updates

Some PowerPacks require you to update their credentials before you upgrade to version 11.2.0 or later. Therefore, if you are using one of the following PowerPacks and are upgrading from a version of SL1 prior to 11.2.0, you must edit an HTTP header in the credential before you upgrade to version 12.1.2:

  • Cisco: ACI Multisite
  • CouchBase
  • Dell: EMC VMAX
  • Google: Cloud Platform
  • LayerX: Appliance Monitoring
  • ScienceLogic: PowerFlow
  • PowerPacks built using the REST PowerPack

To edit the credential HTTP header: 

  1. Go to the Credentials page (Manage > Credentials).
  2. Locate the credential you created, then click its Actions icon and select Edit/Test.
  3. Find the "Content-Type: application/json" HTTP header, then remove the space in the HTTP header so that the new header reads "Content-Type:application/json".
  4. Repeat step 3 for any other HTTP header entries in the credential.
  5. Click Save & Close.
  6. Repeat these steps for any other credential relating to the PowerPacks in the list above.

Required Updates for Users Running Amazon RDS (Aurora MySQL 5.7)

If you are using Amazon RDS (Aurora MySQL 5.7) with SL1 and are upgrading from a version of SL1 prior to 11.2.0, then you must update to the following PowerPack versions before installing SL1 version 12.1.2:

  • Cisco: UC VOS Applications v110

Monitoring Windows with WMI

This section applies to users who are upgrading from the following releases:

  • SL1 11.1.0 through 11.1.2
  • Any SL1 release prior to 10.2.5

If you are upgrading from the following releases, you can ignore this section: 

  • 11.2.0 and later
  • 11.1.3 or a later 11.1.x version
  • 10.2.5 or a later 10.2.x version

SL1 versions 11.2.0, 11.1.3, and 10.2.5 included a new WMI client in response to Microsoft security updates. This change enables WMI Dynamic Applications to collect data from hardened Windows servers, but also has a major impact on system scalability.

This change significantly decreases the number of Microsoft Windows servers that can be supported on each Data Collector in your SL1 system. Users who need to monitor Windows devices using WMI should analyze their system resources and capacity before upgrading to 12.1.2. For guidance about sizing, see the updated Collector Sizing guidelines for WMI endpoints.

To avoid this impact, ScienceLogic recommends using SNMP collection for two-core Windows servers and PowerShell collection for four-core Windows servers. For more information, see this Support Knowledge Base article.

Pre-Upgrade Test for PhoneHome Database Servers

This section applies to users who are upgrading from SL1 11.1.x or earlier and have an existing PhoneHome configuration. If you are upgrading from SL1 11.2.0 or later or you do not have a pre-11.2.0 PhoneHome configuration, you can ignore this section.

SL1 version 11.2.0 included a new pre-upgrade test that checks for existing PhoneHome Database Servers.

This pre-upgrade test looks for PhoneHome token IDs inside the /home/phonehome0/config.json file and fails if the value of the token ID field is less than or equal to "0". In previous versions of SL1, the primary PhoneHome Database was not self-registered with a token, causing it to have an ID of "0".

Therefore, if you are upgrading from version 11.1.x or earlier and you have a PhoneHome configuration, then you must perform these one-time manual configuration steps on all Database Servers in your PhoneHome configuration prior to upgrading to SL1 version 12.1.2:

  1. Log in to the console of the Database Server or use SSH to access the server.
  2. To determine if all of your PhoneHome Database Servers are registered, type the following command and check if any have an ID value of "0":

    3. cat /home/phonehome0/config.json

  3. If a PhoneHome Database Server has an ID value of "0", type the following command and locate the ID of the current appliance:

    4. phonehome status

  4. Type the following command and locate the PhoneHome token:

    5. phonehome token <ID from step 3>

  5. Type the following command to register the PhoneHome token:

    6. phonehome register <token from step 4>

  6. Repeat steps 3-5 for all PhoneHome Database Servers that have an ID value of "0".
  7. Type the following command to ensure that all of your PhoneHome Database Servers are synced:

    8. phonehome sync

  8. Repeat step 2 and confirm that all Database Servers have ID values greater than "0".

Do not attempt to upgrade to 12.1.2 until all pre-upgrade tests are successful on all PhoneHome Database Servers.

The PhoneHome server process runs as an unprivileged user that will not be able to bind to a privileged port (1-1023). Therefore, when you choose a custom port, you must choose port 1024 or higher.

PHP Updates

This section applies to users who are upgrading from SL1 10.2.x or earlier. If you are upgrading from SL1 11.1.0 or later, you can ignore this section.

In SL1 version 11.1.0, all PHP code was converted to PHP 7. Therefore, if you are upgrading from a version of SL1 prior to 11.1.0, please note the following:

  • If you are upgrading from a version of SL1 prior to 11.1.0, you must first upgrade to an 11.x version of SL1 before you can upgrade to 12.1.0.
  • During the upgrade to 12.1.2, the user interface will be unavailable for several minutes.
  • Versions of Global Manager prior to 11.1.0 will not work with SL1 11.1.0 or later.
  • Web Proxy Services will not work in SL1 11.1.0 or later.
  • PowerPacks built in SL1 version 11.1.0 and later releases cannot be imported into previous versions of SL1. However, PowerPacks built in releases prior to 11.1.0 can be imported into 11.1.0 and later.
  • If you have created custom content in PHP, see this page for notes on backward compatibility: https://www.php.net/manual/en/migration70.incompatible.php

Upgrading from Version 8.14.x or Earlier

This section applies to users who are upgrading from SL1 8.14.x or earlier. If you are upgrading from SL1 10.1.0 or later, you can ignore this section.

SL1 version 10.1.0 included an upgrade from MariaDB 10.1 to MariaDB 10.4. Because of this upgrade, if you are currently running SL1 8.14.x or earlier, you must first upgrade to a 10.x release and the version of MariaDB that corresponds to that release, and then upgrade to an 11.x release and its corresponding version, before you can upgrade to SL1 12.1.0.

For more information on upgrading from 8.14.x or earlier, see the section on the 8.x to 12.1.0 upgrade path.

In addition, if you are upgrading from 8.1.4.x or earlier, you should also be aware of the following updates before deploying 12.1.2:

  • As of version 10.1.0, SL1 no longer includes Flash.
  • As of SL1 8.12.2, ScienceLogic no longer updates the help that appears when you click the [Guide] button that appears in the classic user interface. Instead, you can click the Help button at the top of each page. Doing so opens a Help topic about that page. From that topic, you can then click a link to view additional information in the product documentation at docs.sciencelogic.com in a new browser window.
  • As of SL1 8.10.0, SL1 does not support Data Collectors and Message Collectors running the CentOS operating system. If your system includes Data Collectors and Message Collectors running the CentOS operating system, contact your Customer Success Manager for details on upgrading Data Collectors and Message Collectors to Oracle Linux before installing the latest SL1 version.
  • To download updates for previous SL1 versions that have reached their End-of-Life date and are no longer supported by ScienceLogic, contact ScienceLogic Support or a designated Customer Success Manager to get the update files.

 

Known Issues for SL1 Golden Gate 12.1.2

ScienceLogic strongly recommends that you review all Known Issues for SL1. For more information, see https://support.sciencelogic.com/s/known-issues#sort=relevancy.

The following known issues exist for SL1 Golden Gate 12.1.2:

  • The option to enable a Military Unique Deployment (MUD) configuration is not available for SL1 12.1.x installations or upgrades. (Jira ID: EM-57752)

  • Changes to how execution environments deploy in SL1 version 12.1.2 causes some execution environments to no longer work properly post-upgrade, which in turn can cause multiple PowerPacks to not run after you upgrade. For the 12.1.2 release, you should download and install the "SL1: Execution Environment Check" v100 PowerPack and follow the steps in the section Checking Your SL1 Execution Environments Before You Upgrade to ensure that your execution environments and PowerPacks will continue to work as intended post-upgrade. This PowerPack can be run on SL1 versions 11.3.1 to 12.1.2, so ScienceLogic recommends performing this check before you upgrade to 12.1.2, so long as you're currently on version 11.3.1 or later. (Jira ID: EM-66529)

  • When upgrading to 12.1.2, an appliance might abruptly stop showing deployment logs and eventually time out. To work around this issue, use SSH to access the appliance and use the following command to remove the pause file:

    rm -f /tmp/.proc_mgr_pause

    You can then run the deployment again. (Jira ID: EM-65803)

  • When upgrading a large number of SL1 appliances, you might encounter an issue where the initial deployment fails after one hour on larger stacks. Alternatively, the deployment summary might show that deployment timed out for many of the appliances but, upon further inspection, you discover that the appliances actually deployed correctly. The latter is due to a known issue that is causing a lag in the deployment status reaching the Database Server after the default timeout value of 3600 seconds (1 hour). For either of these issues, you can increase the timeout value and, if need be, redeploy the patch. For instructions, see the section on Adjusting the Timeout for Slow Connections in the "Updating SL1" chapter of the System Administration manual. (Jira ID: EM-66059)

  • When upgrading to 12.1.2 and converting your appliances to Oracle Linux 8, as part of the MariaDB upgrade process, you might experience an issue where the MariaDB upgrade is initially unsuccessful, with a "Preupgrade checks failed" message appearing in the log. If this occurs, attempt to run the MariaDB upgrade a second time. This typically fixes the issue. (Jira ID: EM-65834)

  • If you are upgrading to 12.1.2 and converting all of your SL1 appliances to Oracle Linux 8, then post-upgrade and post-conversion, all of your SL1 appliances should have a MariaDB version of 10.4.31. However, a known issue might cause the MariaDB field for your appliances to be highlighted on the Appliance Manager page (System > Settings > Appliances) in SL1. If the appliances are showing the correct MariaDB version of 10.4.31, this highlighting can be safely ignored. (Jira ID: EM-66003)

  • The preupgrade expiry check might fail for Database Servers that utilize out-of-the-box licenses, even when the license is set to expire after the configured expiration period. This issue does not impact appliances that use licenses procured from ScienceLogic. For more information, including a workaround for this issue, see: https://support.sciencelogic.com/s/article/12914. (Jira ID: EM-61746)

  • If your SL1 system is running Windows 2008 or Windows 2012, and you are using PowerShell collections that have the Encrypted field set to Yes in the credentials, those collections will stop working. For more information, see Users with Windows 2008 R2 Servers or Windows 2012 Servers in the SL1 Product Documentation. (Jira ID: EM-61204)

  • After installing or upgrading to SL1 12.1.2, each time the system status script (system_status.sh) runs, you might notice that error/traceback messages appear stemming from the SL1 siloupdate service. These messages can be safely ignored. For more information, see: https://support.sciencelogic.com/s/article/11591. (Jira ID: EM-59277)

  • If you are converting your SL1 stack to Oracle Linux 8 (OL8), you might experience an issue where the spool service is disconnected after the Database Server conversion to OL8, which in turn causes an error while performing the OL8 conversion for your collector appliances. To work around this, you can use SSH to access your Database Server after it has been converted to OL8 and use the following command to restart the spool service:

    sudo systemctl restart siloupdate-spool.service

    (Jira ID: EM-66136)

  • When converting AWS SL1 collectors to Oracle Linux 8 (OL8), you might experience an issue where the collectors stop in the middle of the conversion and do not restart automatically, leaving the conversion process hanging. If this occurs, you can go into the AWS console and restart the collector manually. (Jira ID: EM-66138)

  • After upgrading to 12.1.2, you might experience an issue where the Enterprise Key Management Service (EKMS) for your SL1 system is unable to start because it is still encrypted upon startup.

    To check for this issue, use SSH to access your SL1 Database Server and run the following command:

    sudo cat /tmp/vault_conf.yml

    If the file is clear text, then this issue does not impact you, and you can ignore the rest of this known issue.

    If the file is not clear text, then EKMS is still encrypted and you will need to perform the following workaround steps:

    1. Decrypt the vault file:

      sudo slsctl config --file /etc/sl_vault/vault_conf.yml --key /etc/sl_vault/encryption_key --decrypt

    2. Run the command a second time to decrypt the file again, as this issue is caused by a double encryption.

    3. Remove the previous configuration file:

      sudo rm -rf /tmp/vault_conf.yml /opt/em7/services/sl_vault/config/hcl/vault.hcl

    4. Restart the sl_vault service:

      sudo systemctl start sl_vault

  • In a high-availability (HA) or an HA and disaster recovery (DR) cluster running on Oracle Linux 7 versions of SL1, when rebooting the secondary HA node, the cluster might fail over or have a service interruption. To resolve this issue:

    1. Run the following command on each HA node:

      sudo chkconfig drbdproxy off

    2. Check that drbdproxy is off for all run levels:

      sudo chkconfig --list drbdproxy

    For more information, see https://support.sciencelogic.com/s/article/13278. (Jira ID: EM-62517)

  • In AWS Extended Architecture upgrade deployments, the active Data Engine might display a banner message that indicates there is no active database after a failover has been performed. If there appear to be no other issues and everything otherwise seems to be working as expected, check the database for the following file: /data.local/tmp/motd.pid. If that file exists, delete it and wait for motd to run again. After it runs again, you can log out and log back in. The banner message should no longer appear. (Jira ID: EM-59194)

  • When deploying SL1 on AWS using the 12.1.2 AMI, you must take additional manual steps to set up the "clientdbuser" password in MariaDB. This requires you to edit the /etc/silo.conf file. If you do not, you will not be able to access the user interface and a banner message about the database password not being set will appear after you log in to the appliance using SSH. For additional details about this issue, see: https://support.sciencelogic.com/s/article/9875. (Jira IDs: EM-55919, EM-55493)

  • A known issue might cause high swap usage in excess of 95% to be observed on appliance types running SL1 12.1.x and Oracle Linux 8. This impacts all appliance types, but is most frequently observed on Database Servers or appliances that are under heavy memory pressure. For more information about this issue, including a workaround, see: https://support.sciencelogic.com/s/article/11598.

  • On new installations of SL1 12.1.2, an issue is installing an outdated version of the "Support: File System" Dynamic Application that is included with the "ScienceLogic Support Pack" PowerPack. To fix this issue, reinstall the "ScienceLogic Support Pack." (Jira ID: EM-66118)

  • A known issue is causing virtual collector groups (VCUGs) to incorrectly be reported as billable. This issue is fixed in AP2 version 8.7.96 (French Toast). If you experience this, ScienceLogic recommends upgrading your appliances to that version. (Jira ID: EM-64128)

  • In some cases, after you create or override device relationships in maps in the default user interface (AP2), the GraphQL relatedNodes operation is returning NULL rather than retrieving the relationship as expected. (Jira ID: SLUI-19786)

  • Devices that have anomaly detection disabled might incorrectly appear on the Anomalies tab for device services. (Jira ID: EM-62884)

  • There is a known issue impacting users who upgrade from SL1 11.3.x to 12.1.x that might cause events of only one severity type to appear on the Events page. When a user filters on a specific event severity in 11.3.x and then upgrades to 12.1.0, SL1 maintains that event severity filter choice and you cannot clear it from the user interface. To work around this issue for all users, go to the Database Tool page (System > Tools > DB Tool) and enter the following SQL query:

    DELETE FROM master.user_preference WHERE preference_id = 'event.filter.severity';

    This issue does not impact the Event Console page in the classic user interface.

    For more information, see: https://support.sciencelogic.com/s/article/11753.

  • A known issue might cause several log configuration files to conflict, which could cause you to see errors for the sl_vault and slsctl logs or potentially block log rotation in some cases, depending on the order in which the files are executed. To work around this issue, delete the config files ~sl_vault and ~slsctl. (Jira IDs: SLS-1105, EM-62134)

  • When using the SNMP Public V2 credential to discover devices, you might see an unhandled exception in the system log near the end of the discovery session, despite the devices being discovered successfully. (Jira ID: EM-59380)

  • Post-upgrade, some previously installed PowerPacks in your system might become read-only.

  • The "Average Task Time" metric from the Dynamic Applications listed below is not accurate in SL1 12.1.2 and later 12.1.x releases. It only includes the time of one step and is dramatically shorter than the full task it's intended to measure. It does provide accurate results in SL1 12.2.0 and later releases.

    • LF Data Pull: Storage Tasks

    • MF Data Pull: Storage Tasks

    • HF Data Pull: Storage Tasks

      (Jira ID: EM-66238)

  • If you are using the "Amazon Web Services (AWS)" PowerPack and you have an AWS device class description with one or more special characters, SL1 will generate duplicate devices for that device class. For example, device duplication occurred with an AWS device class that had "São Paulo" in the Description field (the "ã" is considered a "special character"). This situation occurs only on on-premises OL7 SL1 systems, not OL8 systems. To work around this issue, go to the Device Classes page (System > Customize > Device Classes) in SL1 and remove any special characters in the Description field for that device class, such as changing the "ã" to an "a". (Jira ID: EM-66460)

  • "VMware: vSphere Base Pack" PowerPack v306 and v307 are not compatible with SL1 deployments that are running on Oracle Linux 8 (OL8). This incompatibility was addressed in v308 of the PowerPack. (Jira ID: SOL-24062)

  • When discovering new Linux devices using "Linux Base Pack" v108, the reclassification of the device fails; devices will remain classified as pingable devices rather than Linux devices. This issue does not impact existing devices that have already been classified. A fix for this issue is included with v110 of the PowerPack. For more information, see: https://support.sciencelogic.com/s/article/11501. (Jira ID: SOL-24346)

  • In new installations of SL1 12.1.2, the "EM7 Web Server" PowerPack that is normally installed by default is not being installed. You can manually install this PowerPack after SL1 has been installed and configured. For instructions, see the section on Installing a PowerPack in the PowerPacks manual. This issue does not impact SL1 instances that have been upgraded from earlier releases. (Jira ID: SOL-24609)

  • A known issue is causing reports with an HTML output format to not properly generate. To work around this issue, restart the php-fpm service by running the following command:

    sudo systemctl restart php-fpm

    (Jira ID: EM-66052)

  • You cannot delete a PowerPack that has a PowerShell credential. To work around this issue, delete all PowerShell credentials from that PowerPack, and then delete the PowerPack. (Jira ID: EM-53453)

  • Due to a known issue, SaaS users are unable to view the Classic Dashboards Widgets page or add, edit, or delete classic dashboard widgets. This does not impact dashboard widgets in the default user interface (AP2) or non-SaaS users. (Jira ID: EM-65902)

  • If your logged in user session expires and you reopen SL1 in a new tab and attempt to log back in within that new tab, the page that says you have been logged off might appear. If this occurs, click Log Back In and try again. (Jira ID: SLUI-20330)

  • If you repeatedly sign in and out of SL1 in a short period of time, you might receive an error that temporarily prevents you from signing back in due to a caching issue. If this occurs, you can try one of the following workarounds:

    • Wait 5 minutes before attempting to sign in again.

    • Set caching for SL1 sessions to 0. Doing so avoids the issue by effectively turning off session caching, but this might result in performance issues or issues with Global Manager.

    • Sign in using the classic SL1 user interface.

    For additional details about this issue, see https://support.sciencelogic.com/s/article/9715. (Jira ID: SLUI-15357)

  • If you use CAC with LDAP/AD, then you must define an LDAP service account with permissions that allow the service account to query LDAP before configuring CAC. (Case: 00207174) (Jira ID: EM-46948)