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

Technical Advisories for Disaster Recovery for Dell

Introduction​

This page summarizes currently relevant technical advisories for Superna Disaster Recovery (DR) Edition for Dell PowerScale. Advisories tied to product releases that are no longer supported are not reproduced here; contact Superna Support if you need historical advisory detail for an end-of-support release.

note

Advisories for the shared Eyeglass appliance OS, Log4j, and ECA/Vault Agent components — which also apply to Data Security and AirGap — are documented centrally on Appliance & Security Advisories rather than repeated here.

Failover and Replication Advisories​

Duplicate Exports Created on Target Cluster (1.5.0/1.5.1)​

An issue in releases 1.5.0 and 1.5.1 could create duplicate exports on the target cluster under certain conditions, such as poor connectivity between Eyeglass and the PowerScale cluster. This did not affect release 1.4.8. Installations using exports should not run 1.5.0 or 1.5.1. Resolved in 1.5.2.

Incomplete PowerScale PAPI Response May Delete Configuration Objects​

If the PowerScale PAPI becomes unresponsive while Eyeglass is collecting configuration data (for example, returning 503 Service Unavailable), Eyeglass may see an empty inventory for the objects it could not retrieve. If this occurs during a scheduled Configuration Replication cycle, it can result in deletion of configuration objects (such as NFS exports or SMB shares) on the target cluster — a subsequent cycle with a correct PAPI response recreates them. If it occurs during an assisted failover, it can result in deletion of missing configuration objects on both clusters, since the target cluster becomes the active cluster after failover. Current releases include defensive code that guards against this condition; if you are planning a controlled failover on an older release, confirm you are running at least 1.5.4 or later, which blocks PowerScale PAPI errors from impacting a successful failover.

Set SyncIQ Policies to Manual Schedule Before Failover​

Follow Dell best practice and set SyncIQ policies to manual schedule before any failover: a sync job and a failover job cannot run simultaneously, and a scheduled sync running during failover will cause the failover attempt to fail. In release 1.6, a window existed where scheduled policies did not have their schedule removed in time to prevent this; this was resolved in 1.6.3, which caches and removes schedules at the start of a failover and reapplies them at the end.

Open Files Detection Limited to the System Access Zone​

The OneFS open-files API used by DR Assistant (the pre-2.15.0 name for today's Failover Wizard) to display open files only returns files open in the System Access Zone. Other Access Zones with open files are not returned, so the open-files list in DR Assistant cannot be relied on to determine open files in non-System Access Zones. No OneFS fix is available for this limitation; the feature was removed as of release 1.8.1 with no planned replacement.

PowerScale CSRF Authentication Requires SSIP Instead of FQDN/SmartConnect​

PowerScale does not support multi-node cluster-aware CSRF sessions for authentication and is not compatible with a cluster added to Eyeglass by SmartConnect FQDN — this is a known limitation of PowerScale's CSRF implementation, not a Superna defect. Supporting CSRF on PowerScale requires settings that disable basic HTTPS authentication in favor of session-token authentication, which in turn requires Eyeglass to reach the cluster using the SSIP (the static per-node IP in the management/system Access Zone) rather than an FQDN. There is no functional impact if a cluster was already added by SSIP — this only affects clusters still added by FQDN.

If a cluster was added to Eyeglass by FQDN (check via Inventory → right-click the cluster → Edit), migrate it to SSIP:

  1. Open the Jobs window and record the current state (enabled/disabled) of every job for the affected cluster in every section — you'll need this to restore configuration afterward.
  2. Right-click the cluster in Inventory and select Delete.
  3. Re-add the cluster using its SSIP (not FQDN) in the system Access Zone, with the same Eyeglass service account credentials. If migrating multiple clusters, add them all before submitting the inventory job.
  4. Open Jobs → Running Jobs and wait for the initial inventory job to complete.
  5. On the Job Definition tab, re-enable all jobs to match the state you recorded in step 1 — including re-enabling DFS mode if it was in use. Use bulk actions to re-enable multiple jobs at once.
  6. Wait 5 minutes, then confirm all jobs show green. Open a support case if any job shows an error.

Uncontrolled Failover Fails When a Cluster Is Added by FQDN​

Affects releases earlier than 1.8.1. If a PowerScale cluster was added to Eyeglass using its FQDN, an uncontrolled failover attempted while the source cluster is unreachable fails with an error similar to "Cannot find associated source network element for zone." Upgrade to 1.8.1 or later, which resolves this. As a workaround on earlier releases, edit /etc/hosts on the Eyeglass appliance before the uncontrolled failover to add a static entry resolving the source cluster's FQDN to a node IP from the subnet where that FQDN is provisioned.

DR Dashboard Failed Over Status Display Issue (1.9, 1.9.1)​

On releases 1.9 and 1.9.1, the DR Dashboard's Zone Readiness view may not show the Failed Over status for the currently inactive cluster. This is a display issue only — it does not affect the ability to fail over from the active cluster, and it is not possible to initiate a failover from the inactive cluster regardless. Policy Readiness and DFS Readiness views correctly display the Failed Over status in the interim; you can also confirm the active cluster for a given policy from those views. Resolved in release 1.9.2.

Config Sync May Skip Steps on Error​

Affects releases newer than 1.9.4. If an object cannot be synced during Configuration Replication, remaining objects in that sync cycle are not attempted, which can leave SMB shares and exports unsynced to the DR cluster. Clearing the underlying error allows all pending changes to sync successfully on the next cycle. Resolved in release 2.5.3; a patch was also made available for 2.5.2.

SMB Data Integrity Corner Case Can Leave Deny-Everyone Permission on Shares​

Normal configuration sync runs every 5 minutes and, in a rare corner case, may detect and replicate the Deny-Everyone permission used by the SMB Data Integrity failover feature to the DR cluster before that deny is removed by the failover process. If this occurs, some SMB shares may be left with a Deny-Everyone permission blocking access after failover — remove the permission manually on the affected shares to resolve it. To avoid the corner case when using SMB Data Integrity, disable the Configuration Replication job before failover (igls admin schedules set --id Replication --enabled false) and re-enable it after failover completes. Resolved in build 2.5.4-18275 and later.

Failover Scenarios That Can Delay Step Execution (2.5.6 Patch 1)​

Certain scenarios can cause a timeout-related delay before a failover job begins executing its steps. Addressed in the 2.5.6 Patch 1 release — upgrade using the standard offline upgrade procedure, or open a support case for assistance.

Config Only Migration Job Deletes Shares and Exports on the Destination Access Zone​

In release 2.5.6 build 84 and earlier, a Config Only Migration job runs in mirror mode by default, which removes any configuration data on the destination path that overlaps or does not match the source — including shares or exports you may have manually recreated to work around this. A later patch changes the default to merge mode, which preserves existing destination configuration and copies only new configuration from the source. Because a Config Only Migration job runs on the regular Configuration Replication cycle, delete the job if you are affected by this issue rather than leaving it enabled, since it will re-delete recreated shares/exports on its next run.

OneFS Fails to Create Quotas With Corrupt Source Configuration​

During failover, a quota with corrupt or invalid configuration on the source cluster (for example, a quota with both Advisory and Advisory Threshold percentage set) is blocked by OneFS from being created on the target cluster, and appears as a quota error in the Eyeglass failover log. Contact Dell for troubleshooting the corrupt quota configuration on the source cluster. OneFS RUP 9.2.1.22 or OneFS 9.4.0.13 and later include a disabled-by-default workaround: after applying the patch or upgrading, run isi_gconfig -t quota-config pscale_135273_chicken_switch=true as root and restart the PAPI process on all nodes.

OneFS isi status Command May Fail to Release RAM​

Eyeglass periodically runs the OneFS isi status CLI command on a schedule to collect per-node usage data. A OneFS bug can cause this command to fail to exit and release memory cleanly, which — because Eyeglass calls it repeatedly — can progressively consume additional RAM on PowerScale nodes over time. There is no loss of DR functionality if you apply the workaround below; you may see an alarm about incomplete CLI data in the interim, which can be ignored.

To prevent this, disable the two isi status sudoers entries used by Eyeglass:

  1. SSH to the PowerScale cluster as an administrative user.

  2. Edit the sudoers file: isi_visudo.

  3. Comment out (prefix with #) these two lines:

    eyeglass ALL=(ALL) NOPASSWD: /usr/bin/isi_for_array isi status*
    eyeglass ALL=(ALL) NOPASSWD: /usr/bin/isi status*

  4. Save and exit (:wq).

Security Advisories​

Eyeglass REST API Unauthenticated Access​

Affected an API token authentication check on Eyeglass DR, Ransomware Defender, Easy Auditor, and Performance Auditor builds from 2.5.9-22219 through 2.5.11-23110: a request using a token that did not match any authorized token could still reach REST API routes. There was no risk to data on PowerScale or to any Eyeglass product configuration. The issue is resolved in build 2.5.11-23111 and later. If you are running an affected build, upgrade to a current release.

Vulnerable OpenSSH Version (CVE-2024-6409)​

A vulnerable OpenSSH package has been identified on appliance OpenSUSE versions older than 15.4. If your Eyeglass appliance OS is older than 15.5, upgrade the appliance OS to 15.5 or later.

Docker AuthZ Plugin Regression (CVE-2024-41110)​

This vulnerability applies only to environments using the Docker AuthZ plugin. Superna DR Edition does not use this plugin and is not affected.

Grafana Vulnerabilities (CVE-2024-1442, CVE-2024-1313)​

Per Grafana's own advisories, these vulnerabilities do not affect Grafana version 11, which is the version used in current Superna products.

xz/liblzma Supply Chain Vulnerability (CVE-2024-3094)​

Superna appliances use packages from the openSUSE Leap distribution, which was not affected by this supply-chain compromise.

openSUSE Security Vulnerabilities (CVE-2024-21626, CVE-2024-23651, CVE-2024-23652, CVE-2024-23653)​

These vulnerabilities affect openSUSE 15.4 and earlier. Upgrade the appliance OS to 15.5 or later and apply current OS patches.

tip

The appliance defaults to weekly automatic critical patches and security updates when it has internet access. Confirm your appliance OS version and patch level regularly, and prioritize the OS upgrade recommendations above if your appliance is running an older openSUSE release.

See Also​

  • Release Notes – Version history, compatibility matrices, and upgrade-relevant known issues.
  • Upgrade Guide – Upgrade considerations for Superna DR Edition.