Deprecation

The following are deprecated and likely to be removed in a future release:

  • The previous format for password file options is deprecated. The options remain supported until removal, but are now hidden in online help. This affects the following options:

    Deprecated FormUse This Form
    --bindPasswordFile--bindPassword:file
    --deploymentKeyPasswordFile--deploymentKeyPassword:file
    --keyStorePasswordFile--keyStorePassword:file
    --monitorUserPasswordFile--monitorUserPassword:file
    --rootUserPasswordFile--rootUserPassword:file
    --trustStorePasswordFile--trustStorePassword:file

The following are deprecated since DS 7.0.0 and likely to be removed in a future release:

  • Support for SNMP.

    DS software provides better options for monitoring servers, including support for Prometheus, Graphite, LDAP, and JMX. For details, see the Monitoring Guide.

    DS server software also includes a sample monitoring dashboard for Prometheus and Grafana, which is described in opendj/samples/grafana/README.md.

  • The "pwdValidatorPolicy" object class.

    For subentry password policies, use the object classes derived from "ds-pwp-validator" instead.

  • Reversible password storage schemes, and the cn=admin data base DN and adminData backend used to support them. This includes the following password storage schemes:

    • 3DES

    • AES

    • Blowfish

    • RC4

  • The HTTP monitoring endpoint, /admin/monitor.

    Use /metrics/api or /metrics/prometheus instead.

  • LDAP metrics:

    • ds-mon-approx-oldest-change-not-synchronized

    • ds-mon-approximate-delay

    • ds-mon-missing-changes

  • Prometheus metrics:

    • ds_replication_changelog_connected_replicas_approx_oldest_change_not_synchronized_seconds

    • ds_replication_changelog_connected_replicas_approximate_delay_seconds

    • ds_replication_changelog_connected_replicas_missing_changes

    Note

    In mixed topologies, a directory server version 6 or earlier connected to a replication server version 6.5 or later cannot consume messages about other servers going offline. The monitoring framework reflects this as a delay on the directory server that could not consume the message.

    The delay is calculated correctly again once all servers in the topology are upgraded to at least version 6.5, or when the offline server comes back online and has seen a change to directory data.

    Monitor replication delay instead of using the deprecated metrics. For details, see "Replication Delay (LDAP)" or "Replication Delay (Prometheus)".

Read a different version of :