Skylar Automation (formerly PowerFlow) version 3.3.0 rebrands PowerFlow to Skylar Automation, rebrands powerflowcontrol (pfctl) to skyautocontrol, updates the user interface of the SyncPacks page, and addresses multiple issues.
Features
This section covers the features that are included in Skylar Automation Platform version 3.3.0:
-
PowerFlow is now Skylar Automation. With this release, ScienceLogic has rebranded PowerFlow to Skylar Automation. You will notice this rebranding throughout the platform. This change, as well as similar branding changes to the other products offered by ScienceLogic, reflects ScienceLogic's commitment to delivering intelligence that accelerates outcomes through service-centric observability, AI-driven operations, and intelligent automation. For more information, see the ScienceLogic website (https://sciencelogic.com/platform/overview).
-
The powerflowcontrol (pfctl) command-line utility has been rebranded to skyautocontrol (skyautoctl) as part of the rebrand from PowerFlow to Skylar Automation. All of the older pfctl and iservicecontrol commands still function.
-
Updated the user interface of the SyncPacks page in Skylar Automation to improve clarity around the installed version of SyncPacks:
-
Updated the Active Version column to Installed Version
-
Updated the Change Active Version option in the Actions menu to Change Installed Version
-
-
Skylar Automation v3.3.0 includes package updates to improve security and system performance. Among other things, these updates address critical vulnerability CVE-2025-49844.
-
Updated Skylar Automation to prevent search engines from indexing Skylar Automation systems by default, improving system privacy and reducing the risk of external exposure.
-
Updated the Redis service to Redis 7.4.6.
-
The following images are included in this release of Skylar Automation:
- registry.scilo.tools/sciencelogic/sa-api:rhel3.3.0
- registry.scilo.tools/sciencelogic/sa-couchbase:6.6.0-15
- registry.scilo.tools/sciencelogic/sa-dex:2.37.1-12
- registry.scilo.tools/sciencelogic/sa-worker:rhel3.3.0
- registry.scilo.tools/sciencelogic/sa-gui:3.3.0
- registry.scilo.tools/sciencelogic/sa-pypi:6.3.1-16
- registry.scilo.tools/sciencelogic/sa-rabbit:3.8.35-8
- registry.scilo.tools/sciencelogic/sa-redis:7.4.6-0
Issues Addressed
The following issues were addressed in this release:
-
Improved stability when using the broker_load_from_backend feature. Skylar Automation steprunner services now handle missing task bodies in Redis more effectively. If a task's payload has been evicted from Redis, the worker will mark the task as failed instead of hanging. This keeps the worker healthy and allows other tasks in the queue to process normally. (Cases: 00554106, 00554534)
-
In some Dex OIDC connector configurations used for Skylar Automation authentication, the email claim may not be provided. Previously, this caused endpoints that relied on the current user identity to fail, showing 500 errors. Now, when the email is missing, Skylar Automation uses the username to identify the user. This ensures widgets, favorites, and related features work correctly by consistently associating data with the authenticated user, even when the email claim is unavailable. (Case: 00524073)
-
Updated the Skylar Automation backup application to clean up the staging directories inside the steprunner containers and to ensure that if the backup fails to copy to a remote system, the temporary files do not hang in the system. (Case: 00513115)
-
Improved error handling to provide more information about why the graphical user interface is not displaying the SystemHealth diagram after logging into Skylar Automation. (Case: 00467441)
-
Addressed an issue that prevented the "Timed Removal" application from running.
System Requirements
The Skylar Automation platform does not have a specific minimum required version for SL1 or AP2. However, certain SyncPacks for Skylar Automation have minimum version dependencies, which are listed on the Dependencies for Skylar Automation SyncPacks page.
Ports
The following table lists the Skylar Automation ingress requirements:
| Source | Port | Purpose |
|
SL1 host |
443 |
SL1 run book actions and connections to Skylar Automation |
|
User client |
3141 |
Devpi access |
|
User client |
443 |
Skylar Automation API |
|
User client |
5556 |
Dex Server: enable authentication for Skylar Automation |
|
User client |
8091 |
Couchbase Dashboard |
|
User client |
15672 |
RabbitMQ Dashboard |
|
User client |
22 |
SSH access |
The following table lists the Skylar Automation egress requirements:
| Destination | Port | Purpose |
|
SL1 host |
7706 |
Connecting Skylar Automation to SL1Database Server |
|
SL1 host |
443 |
Connecting Skylar Automation to SL1 API |
Additional Considerations
Review the following list of considerations and settings before installing Skylar Automation:
- ScienceLogic highly recommends that you disable all firewall session-limiting policies. Firewalls will drop HTTPS requests, which results in data loss.
- Starting with PowerFlow version 3.0.0, the minimum storage size for the initial partitions is 75 GB. Anything less will cause the automated installation to stop and wait for user input. You can use the tmux application to navigate to the other panes and view the logs. In addition, at 100 GB and above, Skylar Automation will no longer allocate all of the storage space, so you will need to allocate the rest of the space based on your specific needs.
- Skylar Automation clusters do not support vMotion or snapshots while the cluster is running. Performing a vMotion or snapshot on a running Skylar Automation cluster will cause network interrupts between nodes, and will render clusters inoperable.
- The site administrator is responsible for configuring the host, hardware, and virtualization configuration for the Skylar Automation server or cluster. If you are running a cluster in a VMware environment, be sure to install open-vm-tools and disable vMotion.
- You can configure one or more SL1 systems to use Skylar Automation to sync with a single instance of a third-party application like ServiceNow or Cherwell. You cannot configure one SL1 system to use Skylar Automation to sync with multiple instances of a third-party application like ServiceNow or Cherwell. The relationship between SL1 and the third-party application can be either one-to-one or many-to-one, but not one-to-many.
- The default internal network used by Skylar Automation services is 172.21.0.0/16. Please ensure that this range does not conflict with any other IP addresses on your network. If needed, you can change this subnet in the docker-compose.yml file.
- The latest Oracle Linux 8 (OL8) versions are delivered in the Skylar Automation ISO, and the latest package updates are included in Skylar Automation Docker images.
- The OL8 automated upgrade scripts are deprecated with version 3.2.0 of PowerFlow.
- When upgrading Skylar Automation using the RPM, be advised that you must remove the stack before deploying, as a new policy was added to the Skylar Automation policy configurations in the /etc/iservices/casbinpolicy.csv file.
- For new platform deployments and upgrades, always run skyautocontrol healthcheck and autoheal actions after the stack is deployed (or redeployed in upgrade scenarios).
For more information about system requirements for your Skylar Automation environment, see the System Requirements page at the ScienceLogic Support site at https://support.sciencelogic.com/s/system-requirements.
Known Issues
This release contains the following known issues:
-
If a report is deleted, the link to the report might remain in the Reports list until you navigate away and return, or if you refresh the page.
-
The journald volatile storage takes part of the memory based on the environment memory size, which might cause undesired behavior in environments where the memory is highly used by Skylar Automation services. Skylar Automation uses journald volatile storage, which means that all logs are kept only in memory. (Case: 00347339)
-
To check the size of journal logs on a single Skylar Automation node, run the following command:
du -sh /run/log/journal
You can clear logs with the following command (this is automatically done when you run the healthcheck action):
journalctl --vacuum-time=7d
You can also configure journald logs settings by using the following command to enforce small size and time limits:
sudo sed -i -e '/RuntimeMaxUse=/s/.*/RuntimeMaxUse=800M/' -e '/MaxRetentionSec/s/.*/MaxRetentionSec=2week/' /etc/systemd/journald.conf && sudo systemctl restart systemd-journald
Skylar Automation updates journald volatile limits to the following values, which can be changed if you want retain fewer or more logs:
RuntimeMaxUse=800M
MaxRetentionSec=2week
-
When upgrading to Couchbase version 6.6.0 (PowerFlow later than 2.6.0) from PowerFlow versions earlier than 2.6.0, the number of documents in the logs bucket could make the upgrade take longer, as a namespace upgrade is needed. ScienceLogic recommends that you flush the logs bucket if there are more than 300,000 documents that are taking up close to 2 GB of space in every node. Flushing the logs bucket will speed up the upgrade process. Otherwise, migrating a logs bucket of that size would take two to three minutes per node.
Run the following command to flush the logs bucket after the Skylar Automation RPM is installed, but before redeploying the Skylar Automation Stack:
pfctl --host <hostname><username>:<password> node-action --action flush_logs_bucket
Alternately, you can flush the logs bucket manually using the Couchbase user interface.
-
If you get the "Error: No such option: --version Did you mean --json?" error message when running the pfctl --version command, you might have an older version of pfctl that was installed as a different user. To resolve this, be sure to install the powerflowcontrol (pfctl) utility version 3.0.7 or later as root with sudo, and remove any other versions installed by other users (isadmin or ec2-user): (Case: 00360512)
su isadmin
pip3 uninstall -y iservicecontrol
- The Workflow Health and Interconnectivity widget on the Skylar Automation Control Tower page displays diagrams for Skylar Automation applications and SyncPacks that have been deleted. To work around this issue, run the "Skylar Automation Control Tower HealthCheck" application or wait for the next scheduled run of the application.
- If your Skylar automation system uses self-signed certificates, you will need to manually accept the certificate before you can upload SyncPacks. Go to https://<IP address of Skylar Automation>:3141/isadmin, accept the certificate, and then log into Skylar Automation. After you log in, you will be able to upload SyncPacks.
- The latest tag does not exist after the initial ISO installation. This situation only affects users with custom services that point to the latest tag. To work around this issue, run the tag latest script manually after running the ./pull_start_iservices.sh command:
python /opt/iservices/scripts/system_updates/tag_latest.py /opt/iservices/scripts/docker-compose.yml
Installing or Upgrading Skylar Automation
For detailed steps about installing or upgrading to this version of Skylar Automation, see Installing and Configuring Skylar Automation.
All Skylar Automation (formerly PowerFlow) platform releases are suitable for both Military Unique Deployment (MUD) and non-MUD systems.
You should always upgrade to the most recent release of Skylar Automation.