Upgrade Consideration
Important consideration for upgrading to this version of PingDataGovernance Server:
-
If you are updating a multi-server topology from PingDataGovernance 7.0.x to 8.0.0.1, you must use the
--skipMirroredSubtreeUpdateTask
option for the updater or the update fails. Alternatively, you can uninstall all but one of the servers to retain the base configuration, update the standalone server, install fresh servers on the new version, and add them back to the topology with the peer options. However, using the--skipMirroredSubtreeUpdateTask
option is the recommended path.
Critical Fixes
This release of the Data Governance Server addresses critical issues from earlier versions. Update all affected servers appropriately.
- Addressed an issue that could lead to slow, off-heap memory growth. This only
occurred on servers whose
cn=Version,cn=monitor
entry was retrieved frequently.- Fixed in: 8.1.0.0
- Introduced in: 5.2.0.0
- Support identifiers: DS-41301
- The following enhancements were made to the topology manager to make it easier
to diagnose connection errors:
- Added monitoring information for all the failed outbound connections (including the time since it ha been failing and the last error message seen when the failure occurred) from a server to one of its configured peers and the number of failed outbound connections.
- Added alarms/alerts for when a server fails to connect to a peer server within a configured grace period.
- Fixed in: 7.3.0.0
- Introduced in: 7.0.0.0
- Support identifiers: DS-38334 SF#00655578
- The topology manager now raises a
mirrored-subtree-manager-connection-asymmetry
alarm when a server can establish outbound connections to its peer servers but those peer servers cannot establish connections back to the server within the configured grace period. The alarm is cleared as soon as there is connection symmetry.- Fixed in: 7.3.0.0
- Introduced in: 7.0.0.0
- Support identifiers: DS-38344 SF#00655578
- Fixed two issues in which the server could have exposed some clear-text passwords in files
on the server file system.
- When creating an encrypted backup of the alarms, alerts, configuration, encryption settings, schema, tasks, or trust store backends, the password used to generate the encryption key (which may have been obtained from an encryption settings definition) could have been inadvertently written into the backup descriptor.
- When running certain command-line tools with an argument instructing the tool to read a
password from a file, the password contained in that file could have
been written into the server's tool invocation log instead of the path
to that file. Affected tools include backup,
create-initial-config,
ldappasswordmodify,
manage-tasks, manage-topology,
reload-http-connection-handler-certificates,
remove-defunct-server,
restore, rotate-log, and
stop-server. Other tools are not affected. Also
note that this only includes passwords contained in files that were
provided as command-line arguments; passwords included in the
tools.properties file, or in a file referenced
from tools.properties, would not have been exposed.
In each of these cases, the files would have been written with permissions that make their contents only accessible to the system account used to run the server. Further, while administrative passwords might have been exposed in the tool invocation log, neither the passwords for regular users, nor any other data from their entries, should have been affected. We have introduced new automated tests to help ensure that such incidents do not occur in the future.
We recommend changing any administrative passwords you fear might have been compromised as a result of this issue. If you are concerned that the passphrase for an encryption settings definition might have been exposed, then we recommend creating a new encryption settings definition that is preferred for all subsequent encryption operations. You also might want to re-encrypt or destroy any existing backups, LDIF exports, or other data encrypted with a compromised key, and you might want to sanitize or destroy any existing tool invocation log files that might contain clear-text passwords.
- Fixed in: 7.3.0.0
- Introduced in: 7.0.0.0
- Support identifiers: DS-38897 DS-38908
Known Issues/Workarounds
The following item is a known issue in the current version of PingDataGovernance Server:
-
The internal SCIM interface in the BrokerContext class of the Server SDK has been deprecated. It will be removed in a future version of the product. Extensions that need to interact with the SCIM service should use an HTTP client SDK or other means.
Resolved Issues
The following issues have been resolved with this release of PingDataGovernance.
Ticket ID | Description |
---|---|
DS-40532 |
Added a |
DS-40767, DS-41229 |
Fixed an issue in which a PingDataGovernance Server could return
an HTTP 500 error while logging the policy decision response if
using these items:
Also, the Policy Decision Logger now records external policy decisions to the policy decision log as a single line for easier use with the Policy Administration GUI Log Visualizer. |
DS-40980 |
PingDataGovernance Server no longer prevents a server with an expired license from restarting. |
DS-41087 |
The Policy Administration GUI now includes decision evaluation details in the decision-audit.log by default. With this change, policy writers can visualize decisions by copying and pasting the JSON into the Log Visualizer. |
DS-41301 |
Addressed an issue that could lead to slow, off-heap memory
growth. This only occurred on servers whose
|