PingDirectory

Pre-installation considerations

After you have unzipped the PingDirectory server distribution file, you might want to carry out the following functions depending on your deployment requirements:

Custom schema elements

If your deployment uses custom schema elements in a custom schema file (for example, 98-schema.ldif), you can do one of the following:

  • Copy your custom schema file to the config/schema directory before running setup.

  • Copy your custom schema file to the config/schema directory after setup and restart the server. If replication is enabled, the restart will result in the schema replicating to other servers in the replication topology.

  • Use the Schema Editor after setup. If replication is enabled, schema definitions added through the Schema Editor will replicate to all servers in the replication topology without the need for a server restart.

Certificates

If you are setting up a new machine instance, copy your keystore and truststore files to the <server-root>/config directory before running setup. The keystore and truststore passwords can be placed, in clear text, in corresponding keystore.pin and truststore.pin files in <server-root>/config.

Encryption passphrase

You can enable encryption for directory data, backups, LDIF exports, and log files during setup by providing or generating an encryption key with a passphrase.

Locations

Location names are used to define a grouping of PingDirectory server products based on physical proximity. For example, a location is most often associated with a single data center location. During the installation, assign a location to each server for optimal inter-server behavior. The location assigned to a server within Global Configuration can be referenced by components within the server as well as processes external to the server to satisfy "local" versus "remote" decisions used in replication, load balancing, and failover.

Validate ACIs

Many directory servers accept invalid access control instructions (ACIs) because of a less restrictive application of ACIs. For example, if a Sun/Oracle server encounters an access control rule that it cannot parse, then it will simply ignore it without any warning, and the server might not offer the intended access protection. Rather than unexpectedly exposing sensitive data, PingDirectory rejects any ACIs that it cannot interpret, which ensures data access is properly limited as intended, but it can cause problems when migrating data with existing access control rules to a PingDirectory server. If you are migrating from a Sun/Oracle deployment to a PingDirectory server, the PingDirectory server provides a validate-acis tool in the bin directory (UNIX or Linux systems) or bat directory (Windows systems) that identifies any ACI syntax problems before migrating data. For more information, see Validating ACIs before migrating data.

Each server deployment requires an execution of setup. Duplicating a server-root is not supported. The installation of the server doesn’t write or require any data outside of the server-root directory.

After you run the setup tool, do not copy the server-root to another location or system to duplicate the installation, because this isn’t a supported method of deployment. If a host or file system change is needed, you can move the server-root to another host or disk location.