SL1 Hollywood 12.2.1.2 Release Notes

SL1 no longer supports the legacy version of Data Pull. You will need to update all of your SL1 appliances to version 12.2.1.2, including your Data Collectors and Message Collectors, to avoid potential data loss. When all appliances are successfully upgraded to 12.2.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 Hollywood 12.2.1.2 release includes a major update to Data Pull, changes to the order in which SL1 appliances are upgraded, multiple package updates to improve security and system performance, and more.

These release notes provide a comprehensive list of the features, enhancements, and addressed issues that are included in the SL1 Hollywood 12.2.1.2 release.

To view the features, enhancements, and addressed issues that are included in previous SL1 Hollywood releases, see the following release notes:

• 12.2.0
• 12.2.1.1

New Features and Enhancements in SL1 Hollywood 12.2.1.2

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.2.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.2.1.2, including your Data Collectors and Message Collectors, to avoid potential data loss. When all appliances are successfully upgraded to 12.2.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.

Platform and Security

• SL1 version 12.2.1.2 includes multiple package updates to improve security and system performance. Among other things, these package updates include the following security updates that address known critical and high vulnerabilities: ELSA-2023-7549, ELSA-2024-3138, ELSA-2023-2951, ELSA-2023-3349, ELSA-2023-3847, ELSA-2023-4517, ELSA-2023-5244, ELSA-2023-12839, ELSA-2023-7077, ELSA-2024-12069, ELSA-2024-12169, ELSA-2024-12187, ELSA-2024-0897, ELSA-2024-12266, ELSA-2024-1607.

System Upgrade

• 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.

Recently Deprecated Features

12.2.0

The 12.2.0 release deprecates the following PowerPack and removes it from the ISO:

• Google Base Pack

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

12.1.0

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

• 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

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

• In addition to the PowerPacks listed above, the "VMware: vSphere Base Pack" PowerPack has been removed from the 12.2.1.2 ISO due to a known issue. It is still available for SL1 systems that upgrade to 12.2.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

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

Upgrading SL1

You can consume SL1 12.2.1.2 only if you are upgrading from version 12.2.0 or earlier. If you are performing a fresh installation of SL1, you must use 12.2.1.1.

For a detailed overview of SL1, see the Introduction to SL1 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.

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 Hollywood 12.2.1.2

This section includes important notes for upgrading existing SL1 systems to the Hollywood 12.2.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.2.1.2.

Supported Upgrade Paths

The SL1 12.1.1, 11.1.0, and 10.1.0 releases all included major updates that you must consume before you can upgrade to 12.2.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.2.1.2.

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

• 12.2.x or 12.1.x to 12.2.1.2 and already on OL8
• 12.1.x or 11.x to 12.2.1.2 but not yet on OL8
• 10.x to 12.2.1.2
• 8.x to 12.2.1.2

See the sections below for additional details.

Upgrade Path 1: 12.2.0 or 12.1.x to 12.2.1.2 and already on OL8

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

You cannot upgrade from SL1 12.1.2 to 12.2.1.2.

To do so:

1. Download the 12.2.1.2 patch file from the ScienceLogic Support site.
2. In SL1, go to the System Updates page (System > Tools > Updates) and import the 12.2.1.2 patch file.
3. When the 12.2.1.2 patch has an Import Status of "Complete," stage the update.
4. Run the pre-upgrade check to ensure all pre-deployment criteria are met.
5. Deploy the SL1 12.2.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.
6. Upgrade MariaDB on your SL1 appliances to MariaDB 10.4.31.

The SL1 stack will reboot after upgrading MariaDB.

 

Upgrade Path 2: 12.1.x or 11.x to 12.2.1.2 but not yet on OL8

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

• 12.1.0.2 or 12.1.1 (running on OL7)
• 11.x

You cannot upgrade from SL1 12.1.2 to 12.2.1.2.

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

1. If you have not already done so, download and import version 12.1.0.2 to your SL1 system. Otherwise, if you are already running SL1 12.1.0.2, you can skip to step 2.

   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.

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

3. Import the SL1 12.1.1 update. To do so, you must do one of the following:

   • If you have already deployed SL1 12.1.0.2, you can import the 12.1.1 update from the System Updates page (System > Tools > Updates) in SL1. When the 12.1.1 patch has an Import Status of "Complete," proceed to step 8.

   • If you have not deployed SL1 12.1.0.2, you must import the 12.1.1 update using the command line interface. Proceed to step 4.

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

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

6. 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.

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

8. Run the pre-upgrade check, put your appliances in maintenance mode, then stage and deploy the SL1 12.1.1 update.

9. Upgrade your SL1 appliances to MariaDB 10.4.29.

   If you were previously running SL1 12.1.0 or 12.1.0.2 and had already upgraded your SL1 appliances to MariaDB 10.4.29, you can skip this step.

10. Begin the OL8 operating system conversion. For more information, see the OL8 Conversion Resource Center on the ScienceLogic Support portal, which includes links to the Conversion Guide with full conversion steps.

    As part of this conversion, you will need to re-ISO your SL1 Database Server, Data Collectors, and Message Collectors. After you do so, they will be running on OL8 and MariaDB 10.4.28.

11. Upgrade to SL1 version 12.2.1.2.

12. Upgrade your SL1 appliances to MariaDB 10.4.31.

    The SL1 stack will reboot after upgrading MariaDB.

 

Upgrade Path 3: 10.x to 12.2.1.2

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

• 11.x, which included a conversion of all PHP code to PHP 7
• 12.1.0.2, which included changes to the siloupdate-manager service
• 12.1.1, which is a prerequisite for converting to Oracle Linux 8 (OL8)

You must then convert your SL1 operating system to OL8.

Therefore, if you are currently running version 10.x, then the upgrade to SL1 version 12.2.1.2 might require multiple maintenance windows:

1. Upgrade to SL1 version 11.x.

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

   The SL1 stack will reboot after upgrading MariaDB.

3. Follow the steps in the section 11.x or 12.1.x to 12.2.1.2 but not yet on OL8.

Before upgrading from SL1 10.x to 11.x, consult the appropriate 11.x release notes or contact ScienceLogic Support to confirm that the upgrade paths between those two versions is supported.

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

 

Upgrade Path 4: 8.x to 12.2.1.2

If you are currently running a version of SL1 8.x, you must first upgrade to the following releases prior to upgrading to 12.2.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.x, which included a conversion of all PHP code to PHP 7
• 12.1.0.2, which included changes to the siloupdate-manager service
• 12.1.1, which is a prerequisite for converting to Oracle Linux 8 (OL8)

You must then convert your SL1 operating system to OL8.

Therefore, if you are currently running version 8.14.x or earlier, then the upgrade to SL1 version 12.2.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. Upgrade to SL1 version 10.x.
4. Upgrade to the MariaDB version that corresponds to that SL1 release.
5. Upgrade to SL1 version 11.x.
6. Upgrade to the MariaDB version that corresponds to that SL1 release.
7. Follow the steps in the section 11.x or 12.1.x to 12.2.1.2 but not yet on OL8.

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.

Unsupported Upgrade Paths

Users who have not yet deployed or upgraded to an SL1 version that is running on Oracle Linux 8 (OL8) cannot upgrade to SL1 12.2.1.2.

Additionally, you cannot upgrade from SL1 12.1.2 to 12.2.1.2.

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.

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.2.1.2 (Upgrade only)	10.4.31	Yes
12.2.1.1 (ISO only)	10.4.31	N/A
12.2.0	10.4.31	Yes
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.1	10.4.28	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.1	10.4.28	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

Adjusting Maximum User Sessions

The SL1 12.1.1 release set the maximum number of simultaneous user sessions to 300. With this change, some users have received an "HTTP Response code was 429 (Too Many Requests)" error in SL1. If you receive this error, you can adjust the USER_MAX_SESSIONS value in /opt/em7/nextui/nextui.conf to increase the maximum value. To do so:

1. SSH into the SL1 appliance and log in as user em7admin.

2. At the command line, open the nextui.conf file in the vi editor:

   sudo vi /opt/em7/nextui/nextui.conf

3. In the NextUI configuration file, set a new value for USER_MAX_SESSIONS, such as USER_MAX_SESSIONS=1000 for 1,000 concurrent user sessions.

4. Save your changes and restart the NextUI service:

   sudo systemctl restart nextui

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

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 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.2.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

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.2.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

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.2.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.2.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.2.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.2.1.2:

• Cisco: UC VOS Applications v110

Monitoring Windows with WMI

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.2.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

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.2.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":

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:

phonehome status

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

phonehome token <ID from step 3>

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

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:

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.2.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

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 later versions.
• During the upgrade to 11.x, 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

For more information on upgrading from 10.2.x or earlier, see the section on the 10.x to 12.2.1.2 upgrade path.

Upgrading from Version 8.14.x or Earlier

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 upgrading to later releases.

For more information on upgrading from 8.14.x or earlier, see the section on the 8.x to 12.2.1.2 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.2.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 Hollywood 12.2.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 Hollywood 12.2.1.2:

• For this release, STIG-compliant upgrades are available for SL1 12.2.1.2 for users who consumed the 12.2.1.1 STIG-compliant ISO. However, users upgrading from the previous release might experience issues importing the patch file via the command line. Instead, you should import the patch file using the System Updates page (System > Tools > Updates) in the user interface. (Jira ID: EM-66220)

  When deploying a STIG-compliant configuration—also known as a military unique deployment (MUD) configuration—port 7700, the Web Configuration Utility, and the Database Tool page are all disabled. In addition, concurrent PowerShell, concurrent SNMP, and concurrent network interface collection are not supported for these deployments.

• When upgrading SL1 on AWS stacks, you might receive an error message that the Data Engines failed to patch correctly. If this occurs, re-run the pre-upgrade tests and then run the patch again; this should result in the Data Engines updating correctly and the correct version then being reflected on the Appliance Manager page (System > Settings > Appliances).

• After upgrading, to ensure proper data collection, you should go to the Appliance Manager page (System > Settings > Appliances), locate one of the Data Collector or Message Collector appliances, and click the lightning bolt icon to force configuration push for that appliance.

• A known issue is causing the directory /var/lib/em7/update/patch_hook/.rpmdb to be missing from ISO systems. For more information, including a resolution for this issue, see: https://support.sciencelogic.com/s/article/13541. (Jira ID: EM-63105)

• 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)

• When upgrading a large number of SL1 appliances, you might encounter an issue where the deployment summary shows that deployment timed out for many of the appliances but, upon further inspection, you discover that the appliances actually deployed correctly. This is due to a lag in the deployment status reaching the Database Server after the default timeout value of 3600 seconds (1 hour). If you check back later, the issue should fix itself. If you would rather work around this issue, you can increase the timeout value. For instructions, see the section on Adjusting the Timeout for Slow Connections in the "Updating SL1" chapter of the System Administration manual. (Jira IDs: EM-59433, EM-62316)

• After updating your Database Server and/or Administration Portal passwords using the Web Configuration Utility on port 7700, you might experience an "Unexpected end of JSON input" error when you attempt to log in to the default SL1 user interface (AP2). To work around this issue, use SSH to access the Administration Portal and run the following commands as "sudo", replacing <password> with the appropriate password:

  sl1-config -y -q silo CENTRAL dbuser clientdbuser

  sl1-config -y -q silo CENTRAL dbpasswd <password>

  sl1-config -y -q silo CENTRAL ap_user apuser

  sl1-config -y -q silo CENTRAL ap_pass <password>

  (Jira ID: EM-64285)

• After upgrading to 12.2.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

     (Jira IDs: EM-66508, EM-66487)

• Some SL1 collectors that have been upgraded to 12.2.x have experienced filesystems at or near 100%. (Jira ID: EM-62372)
  

• Some upgraded 12.2.x instances do not have api_expanded option listed for the eventmanager in the silo.conf file, which in turn is causing Zebrium events to not trigger in SL1. To work around this issue:

  1. Either go to the console of the SL1 appliance or use SSH to access the SL1 appliance.

  2. Open a shell session on the server.

  3. Type the following at the command line:

     sudo visilo

  4. Locate the line for "eventmanager" and update it to include "api_expanded". For example:

     eventmanager = internal,api,dynamic,syslog,trap,api_expanded

  5. To save your changes and exit the file, enter :wq and then confirm that you want to save.

  (Jira ID: SLUI-18754)

• On SL1 Oracle Linux 8 (OL8) appliances, after upgrading or after deploying a new HA, DR, or HA+DR stack, the following WARNING messages might appear when issuing commands using crm or any script/utility that utilizes crm, such as:

  WARNING: could not get the pacemaker version, bad installation?

  WARNING: list index out of range

  These warnings can be safely ignored. For more information, see: https://support.sciencelogic.com/s/article/14388. (Jira ID: EM-63091)

• 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.2.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)

• 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)

• 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. (Jira ID: EM-59269)

• 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)

• A known issue is causing PDF and XSLX Ticketing report types to fail to generate properly due to an OL8 incompatibility issue. For more information, see: https://support.sciencelogic.com/s/article/11649. (Jira IDs: EM-51131)

• After upgrading to 12.2.0, you might be unable to delete devices from the Devices page. If this occurs, you can work around this issue by deleting the device from the Device Manager page in either the current ("AP2") SL1 user interface (Devices > Device Manager) or the classic user interface (Registry > Devices > Device Manager), or you can delete the device from the Database Server. (Jira ID: EM-62874, Case: 00412497)

• The following known issues impact Business Services:

  • The Anomalies tab on the Service Investigator page for device services might incorrectly display devices that have anomaly detection disabled, rather than showing only those devices with anomaly detection enabled. (Jira ID: EM-62884)
  • Organizations must have at least one or more accounts assigned to them to ensure the relevant services are saved. (Jira ID: SLUI-17810)
  • For services that have their RCA Options field enabled, and has had a child service removed, SL1 will not compute the health, availability, and risk values until the Service Topology Engine returns an updated topology, which occurs every 5 minutes by default. (Jira ID: SLUI-18853)

  Before deleting child services in a 3-tier hierarchy, check if the parent service has the RCA Options field Enabled, then set this field to Disabled if it is not already.

• The SL1 12.1.1 release set the maximum number of simultaneous user sessions to 300. With this change, some users have received an "HTTP Response code was 429 (Too Many Requests)" error in SL1. For more information about this error, see the section on Adjusting Maximum User Sessions and https://support.sciencelogic.com/s/article/12971.

• In new installations of SL1 12.2.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)

• The "Oracle: Database" PowerPack v105 will not work on 12.2.1 because of a known issue regarding the Oracle client cx_oracle. This be will addressed in a future release. (Jira ID: EM-64241)

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

• When creating a template from a Business Service, you might receive an error if the number of constituents and maximum constituents are greater than the maximum number of policies, which has a default value of 100. To work around this issue, you must increase the maximum number of policies using a GraphQL mutation, replacing <increased value> with a larger numerical value such as "1000":

  mutation updateMaxValue{

  updateFeatureToggle(id: "system:BUSINESS_SERVICES_MAX_POLICIES", value: "<increased value>") {

  id

  value

  }

  }

  (Jira ID: SLUI-19654)

• When editing information about a collector group using the Collector Groups page (Manage > Collector Groups), when you click Save, SL1 might remove information about any Data Collectors aligned to that collector group, even if you did not make any such changes. To work around this issue, you can instead make changes to collector groups using the Collector Group Management page (System > Settings > Collector Groups). (Jira ID: SLUI-19657)

• The CyberArk credential gateway service integration is incompatible with SL1's Concurrent PowerShell feature. If you are using the CyberArk credential integration, you must have Concurrent PowerShell disabled. To disable Concurrent PowerShell, go to the Behavior Settings page (System > Settings > Behavior), ensure that the Enable Concurrent PowerShell Collection checkbox is not selected, and click Save. (Jira ID: EM-63205)

• The Expand and Contract buttons are not working as intended on the Dynamic Application Collections page (Devices > Device Manager > wrench icon > Collections). You can still expand and contract individual items on the page. (Jira ID: EM-64420)

• The Set as Home Page button on the Dashboards page is disabled for newly created dashboards and existing dashboards that were imported. (Jira ID: SLUI-19539)

• SSH/Key credential tests do not work in STIG-compliant configurations. (Jira ID: EM-64250)