Skylar One (SL1) 12.3.15 Release Notes

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

The Skylar One12.3.15 release includes new versions of the Linux and Windows agents, improvements to the system upgrade process, updates to the data that can be exported to Skylar AI, and package updates to improve security and system performance. It also addresses numerous issues from previous releases.

These release notes provide a comprehensive list of the features, enhancements, and addressed issues that are included in the Skylar One12.3.15 release.

To view the updates that are included in previous Skylar One releases, see the following release notes:

• 12.3.0
• 12.3.1
• 12.3.2
• 12.3.3
• 12.3.4
• 12.3.5
• 12.3.6
• 12.3.7
• 12.3.8
• 12.3.9
• 12.3.10
• 12.3.11
• 12.3.12
• 12.3.13
• 12.3.14

AP2 version 8.16.1-45 (Halwa.03) is installed by default in Skylar One12.3.15.

Before You Proceed

As of version 12.2.0, Skylar One no longer supports deployment on Oracle Linux 7 (OL7). Users who are upgrading from a version of Skylar One that runs on OL7 must first upgrade to Skylar One 12.1.2 and then convert all appliances to OL8 before they can upgrade to 12.2.0 or later. For more information, see the Supported Upgrade Paths section.

If you are planning to consume Skylar One 12.3.15, be advised of the following:

• The 12.3.15 release is available only as a patch.

• The validated upgrade paths to version 12.3.15 are outlined below. Be advised that you can perform upgrades from one minor version to any later minor version within the 12.3.x series. However, as with all updates, ScienceLogic strongly recommends that you perform such upgrades in a test environment before implementing the upgrades in production environments.

  The following are the validated upgrade paths:

  • 12.3.14 > 12.3.15

  • 12.3.10 > 12.3.15

  • 12.3.0 > 12.3.15

If you are upgrading from a version prior to 12.2.3, then after upgrading Skylar One, you must also upgrade MariaDB 10.4.x to version 10.6.18. Failure to perform this MariaDB upgrade can cause major functionality issues in Skylar One.

• 12.2.x and 12.3.x STIG-compliant users can upgrade to this release via one of the supported upgrade paths so long as you have not consumed or upgraded to the 12.3.0 STIG release. If you previously deployed or upgraded to 12.3.0 STIG, you cannot upgrade to 12.3.15 STIG due to a known technical issue. If this scenario impacts you, contact your ScienceLogic account manager for more details.

• If you are on an 11.x MUD system, you cannot upgrade directly to this release; you must first follow the approved conversion process from 11.x MUD to 12.2.1.1 STIG and then upgrade to 12.3.15 STIG. For more information, see the section on STIG Support.

• AWS deployments that are using Aurora 3 can upgrade to this release. If you are currently deployed using Aurora 2, you can upgrade to this release but you must perform a post-upgrade Aurora 2 to 3 conversion.

• 12.3.15 adds a new, post-update cleanup script that removes old patch bundles to free space on the Database Server. This cleanup process can increase upgrade time during the first run, especially on systems with a large number of older patch bundles. To reduce upgrade time, you can pre-clean older patches before upgrading. For more information, see the section on System Update Enhancements.

• Skylar One 12.3.15 is Department of Defense Information Network (DoDIN)-certified.

For more information, see the Important Upgrade Notes and Known Issues sections.

New Features and Enhancements in Skylar One12.3.15

This section describes the new features and enhancements that are included in Skylar One12.3.15.

Agent

• Skylar One version 12.3.15 includes Linux Agent v198, which was previously pinned to version 12.3.14, and Windows Agent v160, which includes the following enhancements since v155 was pinned to Skylar One 12.3.14:

  • Windows Agent v158:

    • Resolved an issue where Windows Server CPU usage could spike to 100% when Dynamic Applications and the SiloAgent service ran simultaneously. (Cases: 00616696, 00617152)

      Windows Agent v158 resolves a defect that was found in versions 156 and 157 that could result in the agent being uninstalled. For this reason, you should not install those versions and instead upgrade to Windows Agent v158 or later.

  • Windows Agent v159:

    • Addressed an issue where the Windows Agent incorrectly reported 100% utilization on memory, file system, and other metrics after upgrading to a newer agent version. (Case: 00632042)

  • Windows Agent v160:

    • Resolved a memory leak in the Windows SiloAgent service where memory consumption increased over time until the agent was restarted. (Case: 00653462)

    • Improved Windows Agent log monitoring to better handle log rotation and file truncation.

    • Added support for sending notices from the Windows Agent to Skylar One in scenarios where the agent installation or upgrade fails.

Platform and Security

• Skylar One version 12.3.15 includes package updates to improve security and system performance.

Skylar AI

• Optimized configuration data queries in the metadata exporter.

System Update

• The System Update Logs modal now highlights staging, pre-upgrade, and deployment log entries based on their defined severity rather than pattern matching the log text. This removes false positives, clarifies failure and success states, and gives you better visibility into the deployment process to aid in troubleshooting.

• Added a post-update script to clean up old patch bundles, which increases the amount of free space in the Database Server. During upgrades, the system will retain only the two most recent patches and remove all older ones.

  This cleanup process might increase total deployment time for the initial cleanup when upgrading to Skylar One version 12.3.15, particularly on systems with a large number of older patch bundles. It takes approximately three to four minutes to clean up each patch; therefore, if you have 15 older patches that must be removed, for example, that can take an additional 45 to 60 minutes. To reduce upgrade time, you can optionally pre-clean older patches before upgrading using the command siloupdate clear patches on the active Database Server.

Issues Addressed in Skylar One12.3.15

This section describes the issues that were addressed in Skylar One12.3.15.

Access Control

• Ensured that users can view records for their assigned organizations on the Device Processes (Devices > Processes) and Windows Services (Devices > Services) pages in the classic user interface. (Case: 00544862) (Jira ID: EM-78970)

Agent

• The agent summary period is now set to a default of 60 seconds, with the option to change it to up to 300 seconds. (Cases: 00589019, 00589175) (Jira ID: EM-78064)

• Improved the resilience of Windows CPU and disk data collection so the aggregator service is less likely to run out of memory. (Case: 00616233) (Jira ID: EM-78721)

• Improved Responder Ingress handling so that it correctly obtains endpoints for services and avoids repeated “Error obtaining Endpoints for Service” messages. (Jira ID: EM-78710)

Credential Management and Discovery

• Changing a device's default SNMP Read credential now updates all associated Dynamic Applications on all Skylar One Collectors promptly, rather than taking an hour or more and causing failed collections. (Case: 00565997) (Jira ID: EM-77443)

• Ensured that Dynamic Application discovery works as intended even when debugging on processes is enabled. (Case: 00653864) (Jira ID: EM-79729)

• Added support for IPv4z and IPv6z interface types during discovery to ensure these address types are interpreted and discovered correctly. (Case: 00634036) (Jira ID: EM-79512)

Data Collection and Retention

• Resolved an issue where the master_dev.device_interfaces database table was being updated during data collection even when the interface data had not changed, resulting in unnecessary database write load. (Case: 00624048) (Jira ID: EM-79461)

• Resolved an issue where the daily maintenance process would halt the pruning of expired data after it encountered an exception. (Case: 00619712) (Jira ID: EM-79102)

• Reduced the load time for the Device Processes page (Registry > Devices > Processes) in the classic user interface in AWS environments. (Case: 00613590) (Jira ID: EM-78960)

• Resolved an issue that caused a "Too Many Open Files" event and system log message on the Enterprise Database Collector Task Manager. (Case: 00613184) (Jira ID: EM-78660)

• Reduced database churn by optimizing how SNMPv3 engine IDs are stored. (Case: 00605594) (Jira ID: EM-79104)

• Resolved an issue that caused missing Interface bandwidth collections if you enabled Interface index change detection in the device class settings of a device and the device had the same MAC address across multiple interfaces. (Case: 00524126) (Jira ID: EM-75060)

• Concurrent PowerShell collection now handles blank Windows credential passwords gracefully by raising device-level events and continuing collections for devices with valid credentials, instead of halting all concurrent PowerShell processing when an empty password is encountered. (Jira ID: EM-60525)

Deployment and Configuration

• Addressed an issue on STIG-compliant systems where the fapolicyd service interfered with the RPM database, causing deployment commands to become unresponsive. (Jira ID: EM-76568)

• Improved the deployment process to ensure that post-update failures on Database Server appliances are correctly detected. This update prevents the system from incorrectly marking a deployment as successful when an appliance has failed to update. (Jira ID: EM-80236)

Device Management

• Improved the hourly IP address cleanup task so it no longer causes load spikes on the Database Server. (Case: 00626066) (Jira ID: EM-79101)

Enterprise Key Management Service

• Resolved an issue that caused the firstboot script to never complete if you re-ran firstboot on an already initialized system in some EKMS configurations. (Jira ID: SLS-1958)

Events

• Addressed an issue that caused the Event Engine to crash due to a problematic character in the in_internal.messages database table. (Case: 00656764) (Jira ID: EM-79952)

Inbound Messaging

• Improved handling of unused or unparsable email headers so inbound email messages using Oracle UTL_MAIL packages are processed correctly. (Case: 00604327) (Jira ID: EM-78456)

Internal Collections

• Resolved an issue where interface data was not collected for tunnel or other interfaces without a physical address, despite interface index change detection being enabled for the device class. (Case: 00595591) (Jira ID: EM-78360)

Monitoring Policies

• The HTTP Auth Username:Password and Proxy Username:Password authentication fields are no longer returned in the API results for Web Content monitoring policies. However, you can still add or update these fields using the API as you did previously. In addition, a new Clear saved credential checkbox was added to both of those fields on the Web Content Policy editor modal. Selecting these checkboxes clears any credentials saved for those fields. If a credential exists for either field, it now displays as a series of asterisks. (Case: 00646372) (Jira ID: EM-79598)

Platform and Security

• Reduced interface data export message size to improve delivery reliability while preserving successful export and storage of Gen 3 agent interface metrics. (Case: 00613904) (Jira ID: EM-78679)

PowerPack Management

• Resolved an issue on the PowerPack Manager page (System > Monitoring > PowerPacks) that prevented successful filtering of Dynamic Applications by name while editing a PowerPack. (Jira ID: EM-79219)

Reporting

• Ensured that interface aliases are included when exporting "Interface Usage" reports. (Cases: 00520575, 00525158) (Jira ID: EM-79127)

Schedule Management

• Addressed an issue where non-recurring schedules created via the REST API did not display an end date in the Schedule Manager page (Preferences > Account > Schedule) when used with ServiceNow change requests. (Case: 00609709) (Jira ID: EM-78690)

Skylar AI

• Optimized metadata exporter queries against large Dynamic Application tables, significantly reducing export times and database load. (Case: 00623628) (Jira ID: EM-79051)

• Ensured Skylar AI features remain enabled after a High Availability failover event without manual intervention. (Jira ID: EM-78849)

System Update

• Resolved an issue that resulted in 12.3.x upgrades failing due to PowerPack encryption failures. (Case: 00600682) (Jira ID: EM-78255)

• Addressed an issue where the patch hook failed to update on remote appliances when concurrent patch import was enabled, which could later result in failed deployments. (Case: 00641315) (Jira ID: EM-79475)

• Addressed an issue that caused deployment to sometimes stall during a batched system update due to the system reporting conflicting deployment status. (Jira ID: EM-74366)

• Adjusted the system update staging rules so appliances that fail patch hook are excluded only when running MariaDB 10.4.x. This reduces the chances for upgrades being blocked and the need for workaround measures on appliances running newer versions of MariaDB. (Jira ID: EM-78116)

• Resolved an issue that caused "no space left on device" errors when importing a patch bundle with use_concurrent_import enabled. (Jira ID: EM-79357)

• Addressed an issue where manually running siloupdate refresh-appliance with an explicit -m <mid> option updated the Skylar One versions for appliances, even if the appliances had incomplete or failed deployment. (Jira ID: EM-77914)

• Addressed an issue with the MariaDB upgrade script that incorrectly identified major version upgrades, such as 10.6.x to 10.11.x, as minor updates. (Jira ID: EM-80235)

• Ensured the package installation now correctly identifies and maintains the appropriate platform version, preventing repository mismatches and post-update failures. (Jira ID: EM-79203)

• Improved the deployment process to ensure that post-update failures on Database Server appliances are correctly detected. This update prevents the system from incorrectly marking a deployment as successful when an appliance has failed to update. (Jira ID: EM-80219)

• Resolved an issue where appliances initially marked as unavailable would still be incorrectly triggered for deployment after a database upgrade. (Jira ID: EM-78477)

Topology

• Improved device topology suppression to avoid increased load for every event the system processes. (Case: 00622624) (Jira ID: EM-79022)

Recently Deprecated Features

PowerPacks

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

The 12.3.1 release removed the following PowerPack from the Skylar One ISO:

• SL1: System Upgrade Assessment

The 12.3.0 release deprecated the following PowerPacks and removed them from the Skylar One ISO:

• Blackberry Custom Reports
• Cisco: Wireless
• EM7 Base Themes
• OpenStack
• ScienceLogic Integration Service/PowerFlow Monitoring
• ScienceLogic Rules Engine Events
• VMware: vSphere Base Pack, versions 306 and 307

Upgrading Skylar One

You can consume Skylar One 12.3.15 only if you are upgrading from an earlier Skylar One version that supports upgrades to this release. There is no ISO version for version 12.3.15.

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

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

Skylar One Extended Architecture

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

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

Important Upgrade Notes for Skylar One12.3.15

This section includes important notes for upgrading existing Skylar One systems to the 12.3.15 release.

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

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

Supported Upgrade Paths

The validated upgrade paths to version 12.3.15 are outlined below. Be advised that you can perform upgrades from one minor version to any later minor version within the 12.3.x series. However, as with all updates, ScienceLogic strongly recommends that you perform such upgrades in a test environment before implementing the upgrades in production environments.

The following are the validated upgrade paths:

• 12.3.14 > 12.3.15

• 12.3.10 > 12.3.15

• 12.3.0 > 12.3.15

For more information about supported upgrade paths for Skylar One releases, see the Skylar One Recommended Upgrade Paths section in the System Administration manual.

Pre-Import Script for Upgrade Efficiency

Beginning with 12.3.10, the system update import experience was improved to make it faster and more efficient by allowing you to run concurrent imports. This feature is not enabled by default. To enable it, download the patch bundle you want to import, then run the following script:

silo_mysql -e "INSERT INTO master.system_settings_patcher (param, value, description) VALUES ('use_concurrent_import', 1, 'Use concurrent patch import');"

After running the script, you can start the import process.

STIG Support

STIG-compliant users can deploy this release.

12.2.x and 12.3.x STIG-compliant users can upgrade to this release via one of the support upgrade paths so long as you have not consumed or upgraded to the 12.3.0 STIG release. If you previously deployed or upgraded to 12.3.0 STIG, you cannot upgrade to 12.3.15 STIG due to a known technical issue. If this scenario impacts you, contact your ScienceLogic account manager for more details.

Users who are currently on an 11.x MUD system cannot upgrade directly to this release. 11.x MUD customers should follow the 11.3 MUD conversion to 12.2.1.1 STIG re-ISO migration path; this process is documented in the ScienceLogic OL8 MUD Conversion Guide. (Ask your ScienceLogic contact for this manual.) Once you are on 12.2.1.1 STIG, you can upgrade to later STIG releases, including this release.

When deploying a STIG-compliant 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.

Aurora 3 Support

AWS deployments that are using Aurora 3 can upgrade to Skylar One (SL1) 12.3.15. If you are currently deployed using Aurora 2, you can upgrade to Skylar One (SL1) 12.3.15 but must perform a post-upgrade Aurora 2 to 3 conversion. If you are on a SaaS-hosted AWS deployment, the ScienceLogic SRE team will complete this conversion. If you are on a customer-hosted AWS deployment, you must complete this conversion, with additional steps in the section on Updating Skylar One in the System Administration manual. Contact ScienceLogic Professional Services if you need assistance.

Upgrading MariaDB and Rebooting Skylar One

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

If you are upgrading from a version prior to 12.2.3, then after upgrading Skylar One, you must also upgrade MariaDB 10.4.x to version 10.6.18. Failure to perform this MariaDB upgrade can cause major functionality issues in Skylar One.

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

Skylar One Release	Required MariaDB Version	Requires Appliance Reboot?
12.3.15 (Upgrade only)	10.6.18	Yes
12.3.14 (Upgrade only)	10.6.18	Yes
12.3.13 (Upgrade only)	10.6.18	Yes
12.3.12 (Upgrade only)	10.6.18	Yes
12.3.11	10.6.18	Yes
12.3.10 (Upgrade only)	10.6.18	Yes
12.3.9 (Upgrade only)	10.6.18	Yes
12.3.8 (Upgrade only)	10.6.18	Yes
12.3.7	10.6.18	Yes
12.3.6 (Upgrade only)	10.6.18	Yes
12.3.5 (Upgrade only)	10.6.18	Yes
12.3.4 (Upgrade only)	10.6.18	Yes
12.3.3 (Upgrade only)	10.6.18	Yes
12.3.2 (Upgrade only)	10.6.18	Yes
12.3.1	10.6.18	Yes
12.3.0	10.6.18	Yes

Clearing Skylar One Cache Post-Upgrade

After upgrading to version 12.3.15, you should clear your system cache to remove cached items from Skylar One (SL1) and prevent several potential issues that can occur post-upgrade due to caching. To do so, go to Misc > Clear SL1 Cache.

Required Ports

Beginning with SL1 12.2.0, if you have a firewall between your Database Server, data engine, and Administration Portal appliances, you should open TCP port 8200 to facilitate communication between those appliances.

For a full list of ports that must be open on each Skylar One (SL1) appliance, see the section on Required Ports for Skylar One in the Installation and Initial Configuration manual.

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 switched to Python 3 with the 12.3.0 release. However, ScienceLogic will still include Python 2 in parallel with Python 3 on the 12.3.x line.

Python 3.9 Execution Environment Support Deprecation

Users who currently use Python 3.9 execution environments for Dynamic Applications and Run Book Automations are advised that the Skylar One 12.3.0 release removed support for Python 3.9 and added support for Python 3.11. For more information, see the section Important Notes on Creating ScienceLogic Libraries in the ScienceLogic Libraries and Execution Environments manual.

Use of tmux When Using SSH

Starting with Skylar One (SL1) version 12.3.4, the tmux utility is disabled by default if you are on a non-STIG deployment and access a Skylar One (SL1) system using SSH. This is a change in behavior from versions 12.2.1.1 through 12.3.3, where the tmux utility was enabled by default.

If you are on a STIG-compliant Skylar One (SL1) deployment, the tmux utility is enabled by default. ScienceLogic encourages non-STIG users to enable the tmux utility as well.

The utility, which is a terminal multiplexer that enables a number of terminals to be created, accessed, and controlled from a single screen, strengthens session-control mechanisms and aligns with industry-wide security practices.

If tmux is enabled, sessions are automatically locked after 15 minutes of idleness or if an unclean SSH disconnect or dropped SSH connection occurs. Upon login, Skylar One (SL1) checks for and attaches any detached tmux session if it finds them; otherwise, it starts a new session.

The utility also facilitates advanced features like scroll-back buffering with search, built-in clipboarding, multiple sessions and panes, detaching or attaching sessions, and session supervision or sharing.

To enable the tmux utility in non-STIG deployments: 

1. Either go to the console of the Skylar One (SL1) appliance or use SSH to access the appliance.

2. Open a shell session on the server.

3. Type the following at the command line to edit the silo.conf file:

   sudo visilo

4. Change the following line in the [OS_HARDENING] section of the file to enable tmux:

   TMUX = true

   If the [OS_HARDENING] heading does not already exist in the silo.conf file, you must add that immediately above the TMUX = true setting.

5. Save and quit the file. (:wq).

6. Log out of Skylar One (SL1) and then log back in. The tmux utility is now enabled.

For more information about tmux shortcuts and usage, see https://tmuxcheatsheet.com/.

System Update Notes

• Skylar One updates overwrite changes to the configuration file /opt/em7/nextui/nextui.env. (For more details, see 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.
• ScienceLogic recommends that you run backups of your Skylar One system before performing a system update.
• The Skylar One 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 Skylar One (SL1) releases during a maintenance window.
• The Skylar One (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.
• When upgrading a large number of Skylar One 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 Skylar One" chapter of the System Administration manual.
• When upgrading Skylar One 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.

Known Issues for Skylar One12.3.15

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

The following known issues exist for Skylar One 12.3.15:

System Upgrade

• 12.2.x and 12.3.x STIG-compliant users can upgrade to this release via one of the supported upgrade paths so long as you have not consumed or upgraded to the 12.3.0 STIG release. If you previously deployed or upgraded to 12.3.0 STIG, you cannot upgrade to 12.3.15 STIG due to a known technical issue. If this scenario impacts you, contact your ScienceLogic account manager for more details. (Jira ID: EM-74235)
• In systems that have consumed a large number of Skylar One patch imports, the master_filestore.storage_system_patch database table might grow too large in size. If this occurs, then when you attempt to log in to Skylar One, you will be unable to do so and will instead receive an error message stating "The table 'organizations_log' is full" if logging in via the default user interface (AP2), or without an error message if logging in via the classic user interface. To address this issue, you should clean up any previous patch import files after deploying a new version on your Skylar One stack. (Jira ID: EM-75727)
• During deployment, the siloupdate-deploy-local service might display the following log messages, although in both cases, the deployment task still ultimately completes:
  • On primary databases, it displays "Failed to enqueue storage object. Error: 'charmap' codec can't encode…" in journalctl. (Jira ID: EM-78481)
  • On secondary databases, it displays "ERROR 2002 (HY000): Can't connect to MySQL server on '127.0.0.1' (115)" in journalctl from the sl-otelcol post-install scriptlet. (Jira ID: EM-78479)
• If MariaDB has an interruption during the postupdate process, the deployment is initially marked as failed. After MariaDB becomes available again, the Version Update will re-run and the appliance deployment will be marked as complete. (Jira ID: EM-78499)

Authentication

• A known issue might prevent the system from automatically logging out inactive users after the defined login expiry period. (Jira ID: SLS-1933)
• A known issue with session cache management might cause Skylar One to log you out unexpectedly, or prevent you from logging in again after a recent session. If you experience either issue, you can work around it by clearing the cache of your web browser before you log into the Skylar One user interface. For more information, see https://support.sciencelogic.com/s/article/13701. (Jira ID: SLUI-21011)
• The Single Instance Login setting, which can be set on the Behavior Settings page (System > Settings > Behavior), is not working as designed for user accounts that utilize ASCII ADFS authentication. (Jira IDs: SLS-1559)

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)

Credential Management and Discovery

• The Search box that displays when creating a new credential during unguided discovery does not work. (Jira ID: SLUI-20777)
• 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)
• When selecting two or more SNMP credentials to discover a device, if the first credential with the lower ID number contains incorrect information and the second credential with a higher ID number contains the correct information, the discovery logs will not be able to get an SNMP response. (Cases: 00289639, 00292649, 00422558) (Jira ID: EM-39681)

Dashboards

• Classic dashboard reports cannot be scheduled. Attempting to do so results in a "report is blank" error appearing in the system log. (Jira ID: EM-61778)

Device Management

• The ability to assign an icon to a device from the Devices page by clicking the Actions button (ellipsis menu) for that device and selecting Assign Icon is not working as intended. (Jira ID: SLUI-19763)

Discovery

• When discovering an Skylar One appliance using SNMP v2 or v3 credentials, you might see one or both of the following unhandled exceptions in the system log: "UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)" and "TypeError: Incorrect padding". (Jira ID: EM-74484)

Enterprise Key Management Service (EKMS)

• The sl-vaultmngt service might start before EKMS has been initialized. (Jira ID: SLS-1944)
• Configuration backups do not include the master.vault_token table, so restoring from a config backup will not restore EKMS token data. Users who depend on full database restores for recovery should ensure this information is backed up by other means. (Jira ID: SLS-1948)

Events and Alerts

• Skylar One might not generate a "Healthy" event for events that are remediated during a maintenance window. If this occurs, you can clear the event manually. (Jira ID: EM-74713)
• You might experience an issue where device log maintenance mode alerts do not have the correct Event ID or might be missing the Event ID entirely. (Jira ID: EM-74052)

High Availability and Disaster Recovery

• In disaster recovery configurations, virtual IPs might not transition when promoting a secondary node to a primary node. (Jira ID: EM-76091)

Licensing

• You might encounter a "License record not found" critical event after an appliance's IP address changes, due to the Event Engine using the former IP address to verify the appliance's license information. If this occurs, log in to the appliance using SSH and restart the "EM7 Core: Event Processing Engine" process by running the following command:

  sudo systemctl restart em7_event

  (Jira ID: EM-74134)

Logging

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

PowerPacks

• When installing or importing a PowerPack, you might not be able to adjust the PowerPack's embedded license or license key type. (Jira IDs: EM-71507, EM-72515, EM-72716)

Skylar AI

• The sl-otelcol-mgmt.py script shows blank values for the sl-otelcol, em7-platform-core, and nextui versions when connecting to Skylar AI, making it unclear which versions are actually installed, even though the status output reports the versions correctly. (Jira ID: EM-78655)
• Supplying an open telemetry collector endpoint URL with a trailing slash can cause the endpoint to be rejected or fail validation. As a workaround, remove any trailing slash from the URL before saving. (Jira ID: EM-77859)

System Tools

• On the OID Browser page (System > Tools > OID Browser), the Where Symbolic is like drop-down option for the Search where field might not work as intended. (Jira ID: EM-74326)

User Interface

• In the default Skylar One user interface (AP2), the End User License Agreement (EULA) page might not display as intended for new user accounts. Conversely, it might display on pages that were iframed from the classic user interface, even after the user agrees to the EULA. This issue is occurring for ADFS, CAC, and AD authentication methods. (Jira IDs: EM-67851, SLS-1932)
• In the default user interface (AP2), when opening the Account Permissions page (Registry > Accounts > User Accounts > wrench icon) for an existing user account, the Theme/Brand drop-down field does not initially display on the page. To work around this issue, refresh the page. (Jira ID: EM-76478)
• 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-72370)
• The Access Keys page (System > Manage > Access Keys) might not count administrator users in the value displayed in the # Aligned Users column. To work around this issue, go to the Account Permissions page (Registry > Accounts > User Accounts > wrench icon) for the administrator users and re-save their permissions. (Jira ID: EM-74241)
• When you bulk-select multiple event policies to align with a run book automation policy, additional event policies that you did not select might become aligned with that automation policy as well. (Jira ID: EM-70690)
• In the classic user interface, the filter for Edit Date is not working as intended on the Inbound Email page (Registry > Events > Inbound Email). (Jira ID: EM-75291)

 

Known Issues Resolved in Available Releases

Several known issues that are present in 12.3.15 are resolved in other releases that are currently available.

Issues Fixed in Skylar One 12.5.1

• The following known issues impacting this release are fixed if you upgrade to Skylar One 12.5.1 or later:
  • The post_update script might show errors referencing scripts in incorrect directories. For more information, see https://support.sciencelogic.com/s/article/16189. (Case: 00481367) (Jira ID: EM-71361)
  • The use of a percentage character (%) in a password will prevent firstboot from completing. (Jira ID: EM-72924)
  • SNMP v3 default authentication sometimes fails on new Message Collectors. For more information, see https://support.sciencelogic.com/s/article/16042. (Case: 00482414) (Jira ID: EM-71374)
  • If you attempt to reset your Skylar One password from the default user interface (AP2), the email link that is provided will direct you to the incorrect page.(Jira IDs: SLS-1544)
  • 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)
  • The "Support: Configuration File Validation" and "Support: Appliance Validation" Dynamic Applications in the "ScienceLogic Support Pack" PowerPack contain SQL queries with the keyword "function", which is a reserved keyword in MySQL 8.0. Because of this, you might see unhandled exceptions relating to those Dynamic Applications. This issue is fixed in version 109 of the PowerPack, which is included in Skylar One 12.5.1. (Jira ID: EM-72266)
  • In the classic user interface, when a user is required to reset their password, the new password fields appear far above where they normally would appear. (Jira ID: EM-74342)
  • In STIG deployments, the DashSL1 column does not display on the PowerPack Manager page (System > Manage > PowerPacks). (Case: 00465085) (Jira ID: EM-66815)
  • On the Organizations page (Registry > Accounts > Organizations), the filter-while-you-type feature is not working as intended in the Skylar AI Status column. (Jira ID: EM-71414)

Issues Fixed in Skylar One 12.5.20

• The following known issues impacting this release are fixed if you upgrade to Skylar One 12.5.20 or later:
  • After deploying or upgrading to Skylar One 12.3.15, you might not be able to log in to the Web Configuration Utility or port 7700. To resolve this issue, reboot the Data Engine or restart the em7_sladmin service. (Jira ID: EM-78175)
  • After updating, you might experience a large number of nameless component devices or a large number of logs indicating that component devices cannot be created or updated because no mapping types are defined. (Case: 00584214) (Jira ID: EM-77898)
  • On Skylar One systems with healthy EKMS installations enabled on a passive node, or in systems where EKMS is disabled altogether, the slsctl health_check might mistakenly return a failure value. (Jira IDs: SLS-1404)
  • The System Uptime object ID (OID) form can be saved even when required fields are missing (null), despite showing an error. This might result in incomplete or invalid OID entries. (Jira ID: EM-77844)
  • You might encounter an issue where the Device Investigator is missing the options to add device vitals panels for CPU, Memory, or Swap. (Jira ID: EM-76034)
  • Clicking the printer icon to print a report on either the Device Processes page (Devices > Processes) or Windows Services page (Devices > Services) results in a blank page appearing rather than a modal of report options. To work around this issue, go to the Classic Devices page (Devices > Classic Devices), click the bar graph icon for the device you want to print a processes or services report for, select either the Process tab or Services tab, and then click the printer icon. (Case: 00503774) (Jira ID: EM-73062)
  • On the Admin Processes page (System > Settings > Admin Processes), the Runtime Offset column does not display any values. You can view the runtime offset value by editing the process. (Case: 00506663) (Jira ID: EM-73218)
  • Any user with basic privileges who has the access hooks EVT_SUPPRESSION_ADDREM, EVT_SUPPRESSION_REG_PAGE, and EVT_MANAGER_REG_PAGE assigned to their user profile can delete event suppressions regardless of their organization membership. (Jira ID: EM-72912)
  • A new, non-administrator user that has all of the Reporting access keys aligned to their user account cannot create a new scheduler or see the archived reports. (Jira ID: EM-72259)
  • After upgrading to 12.3.2 or later, custom themes and logos might not display on classic user interface pages. To work around this issue, clear the cache of your web browser. (Case: 00503523) (Jira ID: EM-72921)
  • You cannot monitor Windows devices with IPv6 addresses using WMI. You can use PowerShell or SNMP to monitor Windows devices that work with IPv6. (Jira ID: EM-73384)

Issues Fixed in AP2 Ice Pop

• The following known issues impacting this release are fixed if you upgrade to the AP2 8.17.23-45 (Ice Pop) release or later after upgrading to 12.3.15, or if you upgrade to Skylar One 12.5.1 or later:
  • You cannot enable TLS verification through the user interface or the API. To address this issue, update the master.system_settings_general database table by setting value=1 where param='require_tls_verification';. (Jira ID: SLS-1500)
  • On the Events tab of the Device Investigator, Skylar AI-cleared events cannot be found if you filter for an Event Source of Skylar AI in the Cleared Events tab. (Jira ID: SLUI-20889)
  • The Classic Maps page fails to load properly whenever you attempt to log in to the default user interface (AP2) without accepting the End-User License Agreement (EULA). To work around this issue, create a "Grant All" user account, then sign in to AP2 with the newly created account. (Jira ID: SLUI-20801)
  • Password reset emails direct users to the classic Skylar One user interface even when the password reset was requested from the default Skylar One user interface (AP2). (Case: 00458525) (Jira ID: SLUI-20939)

Issues Fixed in AP2 Jelly Bean

• The following known issues impacting this release are fixed if you upgrade to the AP2 version 8.18.43-81 (Jelly Bean) release or later after upgrading to 12.3.15, or if you upgrade to Skylar One 12.5.1 or later:
  • If you deploy Skylar One Global Manager with SAML single sign-on authentication, you might experience an issue where the Global Manager stack cannot access data from its child stacks if Enterprise Key Management Service (EKMS) encryption was disabled on the Global Manager system, resulting in the following error message: "Stack <#> <IP address> results excluded. Consider disabling it. Reason: Response code 401 (Unauthorized)." To work around this issue, EKMS should be enabled for the Global Manager stack. It can be enabled or disabled for the child stacks. (Jira ID: SLUI-21476)
  • If you attempt to duplicate a business, IT, or device service but that service includes organizations you do not have access to, you will receive an error message. (Jira ID: SLUI-20008)
  • The Skylar Analytics Summary panel is displaying an error on Skylar AI-sourced events. (Jira ID: SLUI-22087)

Issues Fixed in AP2 Key Lime Pie

• The following known issue impacting this release is fixed if you upgrade to the AP2 version 8.20.2-72 (Key Lime Pie) release or later after upgrading to 12.3.15, or if you upgrade to Skylar One 12.5.1 or later:
  • In ISO deployments, on the guided discovery pages, bullet points might appear as â¢. A fix for this issue is included in an upcoming release. (Jira ID: SLUI-20614)

Issues Fixed in AP2 Lokma

• The following known issue impacting this release is fixed if you upgrade to the AP2 version 8.20.70-45 (Lokma) release or later after upgrading to 12.3.15, or if you upgrade to Skylar One 12.5.1 or later:
  • Dashboard auto-refreshing is not keeping user sessions active, even when the Page Auto-Refresh Keeps User Session Active field is set to Enabled on the Behavior Settings page (System > Settings> Behavior). For more information, see https://support.sciencelogic.com/s/article/16930. (Case: 00503563) (Jira ID: SLUI-21787)

Issues Fixed in AP2 Nougat

• The following known issue impacting this release is fixed if you upgrade to the AP2 version 8.29.41 (Nougat) release or later after upgrading to 12.3.15, or if you upgrade to Skylar One 12.5.20 or later:
  • If you are running AP2 version 8.26.4-45 (Mochi), you might experience a "red bell" error on the Credentials page, indicating that the page cannot load. This occurs when a credential GUID length is less than 32 characters. To work around this issue, recreate the credential with the incorrect GUID length, realign all impacted Dynamic Applications and Run Book Automations to that new credential, and then delete the original credential. (Cases: 00568449, 00568858) (Jira ID: EM-77246)

Issues Fixed in AP2 Opera Cake

• The following known issue impacting this release is fixed if you upgrade to the AP2 version 8.34.20 (Opera Cake) release or later after upgrading to 12.3.15, or if you upgrade to Skylar One 12.5.20 or later:

  • For business services that have their RCA Options field enabled, and has had a child service removed, Skylar One 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.

Issues Fixed in AP2 Quesito

• The following known issue impacting this release is fixed if you upgrade to the AP2 version 9.13.1-14 (Quesito) release or later after upgrading to 12.3.15:

  • In systems with Skylar AI enabled, the sorting feature for columns on the Anomaly Detection page only sorts by the data currently displaying on the page, which might not include all anomaly detection data. (Jira ID: SLUI-22523)