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 correspondingkeystore.pin
andtruststore.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 thebin
directory (UNIX or Linux systems) orbat
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 After you run the |