Changes

• The required version of Java was changed from 1.8 to 11. Package dependencies will install the appropriate JDK automatically and it is not necessary to install the JDK manually. (CLOUD-3654 and CLOUD-3208)

• RHEL 8 and compatible Linux distributions are now supported. While RHEL 7 is still supported, it is recommended that RHEL 8 or equivalent is used as RHEL 7 will be end-of-life in mid-2024. CLOUD-3575)

• A new audit log format was introduced (version 4). The default log version has also been changed to 4. To continue using audit log version 3, set [debug]auditLogVersion to “3”. The new field layout is documented at Gateway Audit Logging (CLOUD-3881 and CLOUD-3690)

• Fixed a bug which caused a malformed S3 multipart complete response under certain failure conditions. (CLOUD-3654)

• The default for [gateway] multipartSpoolDir has changed from /var/spool/cloudgateway/ to a subdirectory underneath /var/spool/caringo/cloudgateway/. (CLOUD-3862)

• Fixed a bug in which an empty bucket that has object locking enabled prevented the deletion of the containing domain. (CLOUD-3847)

• The master key is now stored with replicas=16 to provide additional resilience in the face of downed Storage nodes. (CLOUD-3810)

• S3 “requestPayment” requests are now recognized and return 501 Not Implemented response instead of a bucket listing. (CLOUD-3679)

• Fixed a bug in which disabling object locking on a bucket would incorrectly disable versioning as well. (CLOUD-3673)

• Hybrid Cloud requests against a proxy (such as haproxy) running on the Gateway host would fail but now work. (CLOUD-3670)

• The TCP accept queue length is now configurable. This configuration item should be left unset unless directed to by support. (CLOUD-3643)

• Restricted permissions on the swarmlifecycle.cfg configuration file, and loosened permissions on the configuration samples directory. (CLOUD-3635)

• Gateway would sometimes fail to recover from all Storage nodes being down without a restart. It now will recover and resume normal operation once nodes return. (CLOUD-3589)

• Gateway now prevents internal headers related to object locking from being written via S3. (CLOUD-3588)

• Before Gateway 8.0.0, SCSP and Portal did not allow a bucket with object locking to be deleted, even if it is empty. It had to be deleted by an S3 client e.g. using "rclone purge" to delete all objects and versions. (CLOUD-3516)

• Fixed error 403 SignatureDoesNotMatch with s3cmd and rclone when the S3 endpoint includes a non-default HTTP (80) or HTTPS (443) port. (CLOUD-3340)

Upgrade Impacts

See Upgrading Gateway to upgrade from a version of Gateway 6 or 7. See Upgrading from Gateway 5.x, 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:

See Content Gateway 7 Release Notes and Content Gateway 6 Release Notes 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 not compatible with Linux PAM modules that depend on interactive validation operations such as OTP or biometric scanners.

• Gateway SCSP and Portal do not allow a bucket with object locking to be deleted, even if it is empty. It must be deleted by an S3 client, e.g., using "rclone purge" to delete all objects and versions. (CLOUD-3516)

See Content Gateway 7 Release Notes and Content Gateway 6 Release Notes for known issues from prior releases that are still applicable, apart from those appearing above as fixed.