Content Gateway 8.1.2 Release

CentOS/RHEL 7 has reached its end of life (EOL), and yum commands on CentOS now fail with "Could not retrieve mirrorlist http://mirrorlist.centos.org/". While there is a workaround, please plan a migration to RockyLinux/RHEL 8.

Changes

  • Fixed a bug where a rare type of versioned delete failure could leave ghost entries in object listings resulting in later 404 errors when attempting to delete those nonexistent versions. (CLOUD-4079)

This fix affects only Gateways with object list caching enabled. Use list caching only under Support guidance.

Upgrade Impacts

See  to upgrade from a version of Gateway 6 or 7. See , if migrating from Elasticsearch 2.3.3 and Gateway 5.

Starting with Gateway 7.8, Elasticsearch 6.8.6 is no longer supported. Remain on Gateway 7.7 until the rolling upgrade from Elasticsearch 6.8.6 to 7.5.2 is completed.

Address the upgrade impacts for this and each prior version since the currently running version:

Impacts for 8.1.2

  • Version Requirements

    • Swarm Storage 14.1.0 or higher

    • Elasticsearch 7.5.2 or 7.17.9 (required with Swarm Storage 15.3 or higher)

    • Content UI 7.10.0

    • Storage UI 3.5.0

 

 

 

 

 

 

 

See and for impacts from prior releases.

Watch Items and Issues

These are known operational limitations that exist for Gateway.

  • When using the default RHEL/CentOS configuration of IPTABLES, traffic to the Gateway will be blocked unless action is taken to disable IPTABLES or to enable inbound traffic to the front-end protocol port(s).

  • Gateway is incompatible with Linux PAM modules that depend on interactive validation operations such as OTP or biometric scanners.

  • Gateway 8.0.4 must be restarted after creating a Search Feed to avoid the error: “ResourceUnavailableException: Application resource 'elasticsearch-storage_cluster' is unavailable”. This will be fixed in an upcoming release. (CLOUD-4003)

  • Gateway logs display a warning "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone". This is harmless and can be avoided by adding "xpack.security.enabled: false" to each Elasticsearch node's /etc/elasticsearch/elasticsearch.yml and doing a rolling restart . (SWAR-10260)

See and for known issues from prior releases that are still applicable, apart from those appearing above as fixed.

 

© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.