Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Upgrades

Before You Upgrade​

note
  • Contact Superna Support before upgrading the cluster to confirm compatibility between the target ECA and Eyeglass versions — Eyeglass and the ECA cluster must run the same version.
  • Upgrade assistance is a scheduled service and is not covered under 24/7 support. Review your EULA terms and conditions.
  • Always take a VM-level snapshot before any upgrade step, so you can roll back to the previous release if needed.

Two upgrade paths are available: a carrier-grade (rolling) upgrade with no downtime, and a standard upgrade that takes the cluster offline during the upgrade window.

Carrier-Grade Upgrade (No Downtime)​

Requires ECA release 2.5.8.2 or later.

  1. Log in to ECA node 1 and copy the upgrade run file to that node.

  2. Make the file executable:

    chmod 777 eca-xxxxx.run

  3. Run the upgrade with the rolling-upgrade flag:

    ./eca-xxxxx.run --rolling-upgrade

  4. Provide your credentials when prompted. Nodes are upgraded one at a time so that audit data ingestion and all ECA products continue operating throughout. The process manages all node upgrades and exits when complete, with all containers running the new code.

Standard Upgrade​

  1. Take a hypervisor-level VM snapshot of every ECA node — mandatory, to allow rollback if needed.

  2. Disable Data Security, Easy Auditor, and Performance Auditor before beginning:

    • Log in to ECA node 1.
    • Run ecactl cluster down.
    • Wait for the command to complete on all nodes.

  3. Upgrade the Eyeglass VM first. Eyeglass and the ECA cluster must be upgraded to the same version.

  4. Download the latest GA release for the ECA upgrade.

  5. Log in to ECA node 1. The cluster should already be down from step 2 — verify with:

    ecactl cluster status

    If containers are still running, stop them with ecactl cluster down and wait for it to complete on all nodes.

  6. Transfer the run file to node 1 (/home/ecaadmin), then run it:

    ssh ecaadmin@x.x.x.x
    cd /home/ecaadmin
    chmod +x ecaxxxxxxx.run
    ./ecaxxxxxxx.run

    Enter your credentials when prompted, wait for the installation to complete, and capture the upgrade log in case you need it for a support case.

  7. Bring the cluster back up:

    ecactl cluster exec "sudo systemctl enable --now zkcleanup.timer"
    ecactl cluster up

    Wait until all services start on every node. If errors occur, capture the upgrade log for a support case.

  8. Verify the upgrade. Log in to Eyeglass, open Manage Services, and confirm all ECA nodes show green and online. If a service shows a warning or is inactive, wait at least 5 minutes before opening a support case.

  9. Validate the pipeline using the Security Guard test (Data Security) or the Robo Audit feature (Easy Auditor) to confirm audit data ingestion is functioning correctly after the upgrade.

Migrating to a New ECA Cluster (OS Upgrade)​

To upgrade the underlying OpenSUSE OS version, deploy a new ECA cluster on the new OS and migrate the existing configuration to it, rather than upgrading the OS in place.

  1. Retrieve the existing cluster name and back up configuration files. Log in to ECA node 1 and run:

    cat /opt/superna/eca/eca-env-common.conf | grep ECA_CLUSTER_ID

    Use the returned value as the cluster name when deploying the new OVA. Copy the following files off node 1:

    • /opt/superna/eca/eca-env-common.conf
    • /opt/superna/eca/docker-compose.overrides.yml
    • /opt/superna/eca/conf/common/overrides/ThreatLevels.json
    • /opt/superna/eca/data/audit-nfs/auto.nfs
    note

    This procedure assumes IP addresses stay the same, so cluster NFS exports and firewall rules don't need to change.

  2. Deploy a new OVA using the latest OS version, with the same cluster name and IP addresses as the current cluster.

  3. Shut down the old cluster: run ecactl cluster down on node 1, wait for shutdown to finish, then power off the vApp in vCenter.

  4. Start the new cluster: power on the new vApp and ping each node's IP until all VMs respond — do not continue if any node doesn't respond.

  5. Restore the configuration files copied in step 1 onto node 1 of the new cluster, and recreate the audit mount directories on each node (/opt/superna/mnt/audit/<cluster GUID>/<cluster name>) for every cluster managed by this ECA cluster — the GUID and name are in the restored auto.nfs file.

  6. Restart autofs on each node and verify the mounts:

    ecactl cluster exec "sudo systemctl restart autofs"
    ecactl cluster exec "mount"

  7. Start the new cluster:

    ecactl cluster up

    Review the startup messages for errors.

Threat Hunting ML VM​

The ML VM is Kubernetes-based, not upgraded with the ECA .run installer above. Component updates (configuration changes or a new chart/image version) are applied per-component with Helm, from the ML module server:

  1. Update the relevant <component_name>-onprem-values.yaml file with the required changes.

  2. Apply the update:

    helm upgrade --install <component_name> chart-seed-ml/charts/<component_name> -n seed-ml --create-namespace -f <component_name>-onprem-values.yaml

    For example, to update the seedmlback component:

    helm upgrade --install seedmlback chart-seed-ml/charts/seedmlback -n seed-ml --create-namespace -f seedmlback-onprem-values.yaml

  3. Get the running pod name (including its generated ID):

    kubectl -n seed-ml get pods

  4. Restart the pod so it picks up the change — Kubernetes automatically recreates it with the updated configuration:

    kubectl -n seed-ml delete pod <pod_name_with_id>

Each values file maps to a specific set of components to restart:

YAML fileComponents to restart
clickhouse-onprem-values.yamlclickhouse
seedml-onprem-values.yamlml-data-exfiltration, inventory, pipelines
seedmlback-onprem-values.yamlui-ml, api-ml, service-ml-core
superset-onprem-values.yamlsuperset
note

This is the same Helm-based mechanism documented for the Threat Hunting module today — it applies to configuration updates and component version updates alike. See Threat Hunting Troubleshooting for restart and diagnostic commands used alongside an upgrade.

See also​