DirX Directory Files

The DirX Directory environment variable ini file specifies the settings for DirX Directory environment variables used by all DirX Directory processes.

The location for the dirxenv.ini file is:

install_path/conf

In the ini file, comment lines begin with the hash tag character (#) in the first column and are ignored.

To set the value of an environment variable, specify the line in the following format:

where name specifies the name and value the value of the environment variable.

To un-set the value of an environment variable, specify the line in the following format:

where name specifies the name of the environment variable.

Specify one line per environment variable. All set and un-set lines must start at the first column. The wildcard characters * and ?, and placeholders like $PATH are prohibited.

At startup time, all DirX Directory processes read this ini file. All environment variables specified in this file overwrite a previously set value.

A template file is installed when installing DirX Directory.

Map object identifiers (internal identifiers) of directory attributes to attribute names and abbreviations.You can then use these names and abbreviations to specify the objects in the dirxcp and dirxadm commands. dirxauddecode uses the abbreviation files to replace objectidentifiers with user friendly abbreviations or names.

The DirX Directory abbreviation file dirxabbr:

The DirX Directory abbreviation files dirxabbr and dirxabbr-ext*:

This reference page describes the format of the abbreviation files dirxabbr and dirxabbr-ext* files. These files consist of:

An empty OID or Attribute Definition Block must be indicated by curly brackets (\{}).

Lines starting with the character # are comment lines and therefore ignored.

The abbreviation file dirxabbr is installed together with the DirX Directory product. It contains the data of the DirX Directory default DSA schema. Project-specific enhancements can also be defined in the dirxabbr file, but we recommend creating project-specific abbreviation file(s) to avoid having to re-insert your project-specific enhancements into the dirxabbr file after a new installation (for example, when upgrading to a newer DirX Directory product version. The syntax for the filename of a project-specific dirxabbr file is:

for example, dirxabbr-ext-meta, dirxabbr-ext-security (where meta and security indicate different projects).

When DirX Directory clients like dirxcp or dirxadm are started, they first read the dirxabbr file and then all files with a filename starting with the string dirxabbr-ext. Files with the filename dirxabbr followed by an extension (.*extension) - for example, *dirxabbr.old - are not read.

The default location for the abbreviation files is:

You can override the default location or specify a set of abbreviation files by setting the DIRX_ABBR_FILE environment variable to the full pathname of the file(s). (See chapter titled DirX Directory Environment Variables for details.) When setting this environment variable, only the specified abbreviation files are read by DirX Directory clients.

For a complete listing of the file contents of the dirxabbr file, refer to the installed file. The examples below illustrate only the format of the file sections and subsections.

The OID definition block maps between OIDs and abbreviations. It has the following syntax:

This block contains mappings for

The syntax is relevant only for matching rules when used in the extensible filter match. In the following OID definition block tables, if syntax is not relevant, a dash (-) is supplied in the Syntax column.

The LDAP_name is relevant only for object classes. In the following OID definition block tables, if LDAP name is not relevant, a dash (-) is supplied in the LDAP Name column.

The Attribute Definition Block contains information about the following attributes

It has the following syntax:

where:

abbreviation

Full_name

OID

Syntax

Equality_matching_rule

Ordering_matching_rule

LDAP_attribute_name_list

Abbreviation, full_name and LDAP_attribute_name_list can be adapted to your requirements.

OID, syntax, equalitymatching_rule, and _ordering_matching_rule should not be changed.

For attributes with a syntax of OBJECT_ID, enter one of the following:

For attributes with a syntax of ATTR_TYPE, enter either:

The following block contains information about the syntax of structured attributes. It maps between structured attribute components and their abbreviations. The syntax is

where:

struct_syntax is the syntax of the structured attribute. For each component, the following information is provided:

The following example lists the contents of the project specific abbreviation file
dirxabbr-ext.DirXIdentity. This file specifies the object classes and attribute types used by the DirX Identity meta controller metacp.

The LDAP server configuration file, used by an LDAP server, defines the LDAP server’s own address and the DSAs (Directory System Agents) the LDAP server accesses.

The default location for the dirxldap.cfg LDAP server configuration file is:

install_path/ldap/conf

You can override the default location by setting the DIRX_CLCFG_FILE environment variable to the full path name of the file.

In the configuration file, comment lines begin with the hash tag character (#) in the first column and are ignored.

Other than comments, the file contains two types of lines, as follows:

The LDAP server address line starts with the word self (case insensitive), followed by the address of the LDAP server in valid PSAP address format.

The DSA address line consists of the name of a DSA followed by the address of the DSA in valid PSAP address format. Enclose the DSA name in quotation marks if it includes white space. Anything following and separated from the DSA address with a space is ignored. Specify one DSA address line for each DSA that the LDAP server is to contact. By default, only one DSA address line needs to be specified. If the LDAP server is to contact multiple DSAs, specify one DSA additional address line for each additional contact DSA.

If you use environment variables to override a dirxldap.cfg file entry and an error occurs (for example, if DIRX_CLCFG_FILE is set to a nonexistent path name or is incorrectly specified), DirX Directory reports the error, but makes no attempt to return to the overridden default. If errors occur, consult the exception log for a description of the error.

A primary LDAP server and one or more additional LDAP servers can be set up to run on a single machine. By default, all of these LDAP servers read their contact DSA information from the dirxldap.cfg file. To set up server-specific LDAP configuration files for individual LDAP servers, create the dirxldap.cfg file for the LDAP server and then append the filename extension .*subentry_name , where subentry_name is the common name used for the individual LDAP server’s configuration subentry; for example, *ldapConfig2. This is the same name as the one used in the process of configuring the additional LDAP server and the one that is specified in the
-n option to the dirxldapv3 command to start the additional LDAP server. So, for example, the server-specific LDAP configuration file name for an additional LDAP server named ldapConfig2 is dirxldap.cfg.ldapConfig2.

Note that the environment variable DIRX_LDAP_USE_SEPARATE_CLCFG_FILE must be set for the use of separate LDAP server-specific configuration files to take effect. If it is not set, all additional LDAP servers read their contact DSA information from dirxldap.cfg regardless of whether or not LDAP server-specific configuration files exist.

If the DIRX_CLCFG_FILE environment variable specifies a different location for the dirxldap.cfg file, all LDAP servers read the dirxldap.cfg file at the specified location instead of their LDAP server-specific files.

The HTTP Server configuration file, used by dirxhttp, defines all the parameters used by the HTTP Server, like log levels, SSL configuration, the IP and port of the LDAP Server, and so on.

The default location for the dirxhttp.cfg client directory configuration file is:

install_path/http/conf

Details of the format of the configuration files and the available options are available in the online documentation at https://<server_ip>:8443/dxd/ldap/v1/doc/dirxhttpcfg.html or open the local HTML file from install_path/http/doc/dirxhttpcfg.html.

The directory client configuration file, used by dirxcp, defines the DUA’s (Directory User Agent) own address and optionally the DSAs (Directory System Agents) and LDAP servers the DUA usually accesses.

The default location for the dirxcl.cfg client directory configuration file is:

install_path/client/conf

You can override the default location by setting the DIRX_CLCFG_FILE environment variable to the full path name of the file.

In the configuration file, comment lines begin with the hash tag character (#) in the first column and are ignored.

Other than comments, the file contains three types of lines, as follows:

The DUA address line starts with the word self (case insensitive), followed by the address of the DUA in valid PSAP address format.

A DSA address line consists of the name of a DSA followed by the address of the DSA in valid PSAP address format and the optional keyword DAP (as the protocol specification). The first DSA address line identifies the default DSA. Enclose the DSA name in quotation marks if it includes white space.

An LDAP server address line is specified in the following format:

name address protocol

where:

name

* is the symbolic name of the LDAP server. This name is the name to be specified in the obj bind command in the -server option. (See obj bind operation for details.)

address

where host or hostn is either an IP address or a DNS (domain name server) name and port or portn is a port number (<32767). 389 is used as the default port number.

If more than one real address is specified, an attempt is made to establish a connection using real addresses from left to right.

protocol

The first LDAP server address line identifies the default LDAP server.

Anything following and separated from the protocol specification in a DSA address line or an LDAP server address line with a space is ignored.

If the DUA accesses a DSA or LDAP server that is not specified in this file the server address must be specified in the obj bind command in the -psap option for a DSA or in the -address option for an LDAP server. (See obj bind operation for details.)

If LDAPv2 or LDAPv3 is specified in the -protocol option of an obj bind operation and no LDAP server address line is specified in the client configuration file dirxcl.cfg a bind to the local LDAP server listening to the default LDAP port 389 is established. (See obj bind operation for details.)

If you use environment variables to override a dirxcl.cfg file entry and an error occurs (for example, if DIRX_CLCFG_FILE is set to a nonexistent or incorrectly specified), DirX Directory reports the error, but makes no attempt to return to the overridden default. If errors occur, consult the exception log for a description of the error.

The key material files that are installed by default are intended for testing the SSL and SASL bind functionality of the DirX Directory LDAP server.The content of the files should be loaded into the respective attributes of the LDAP SSL configuration subentry.

The default location for the LDAP server key material is:

install_path/ldap/conf

The LDAP server’s full key material is contained in the PEM file named cert_ldapserver.pem.The content of this file can be loaded into the octet string attribute LDAP Own Keymaterial PEM of the LDAP SSL configuration subentry.

The file cert_ldapserver.der contains the LDAP server’s public key certificate in binary format.This file is intended to support the import of the LDAP server’s certificate into other key stores.

The file testCA.der contains the binary CA certificate of the CA that issued all the DirX Directory key material.It must be loaded into the LDAP Trusted CA Certs of the LDAP SSL configuration subentry.Testing SASL binds with the test user contained in the client certificate and key database files requires this step.

The file dirx_pkcs12.pwd contains the passphrase that protects the private key contained in the file cert_ldapserver.pem.

The SSL/TLS certificate database, used by dirxcp, defines the server and certificate authority (CA) certificates that the LDAP client (dirxcp) is to trust when authenticating a server during a bind operation with SSL/TLS enabled.

The default location for the cert8.db certificate database is:

install_path/client/conf

You can override the default location and file name by setting the DIRX_TRUSTED_CA environment variable to the full pathname of the file.

When an LDAP client connects to an LDAP server over SSL/TLS, the LDAP server authenticates itself by sending its certificate to the LDAP client. The LDAP client needs to determine whether or not the certificate authority (CA) that issued the certificate is trusted.

The LDAP client (dirxcp) uses the Mozilla SDK to implement SSL/TLS support. The security protocols and versions supported by the SDK are SSL V2 and SSL V3. The directory server supports SSL V3 and TLS V1. Consequently, if dirxcp connects to an LDAPv3 server, the two programs will agree on SSL V3 during the negotiation of the security protocol to use.

The Mozilla SDK API requires a certificate database to hold the CA certificate. The prerequisites for connecting over SSL are as follows:

When dirxcp sends an initial request to the secure LDAP server, the LDAP server sends its certificate back to dirxcp. dirxcp then determines which CA issued the LDAP server’s certificate and searches the certificate database (cert8.db) for the certificate of that CA.

If dirxcp cannot find a trusted certificate of the server or the issuer, it refuses to connect to the server. It also refuses to connect if the LDAP server’s certificate has expired or if the certificate extension restricts the usage to client usage only. The latter case applies if the LDAP server sends a browser certificate instead a server certificate.

The DirX Directory installation contains an example cert8.db file containing the CA certificate of the "Test CA" that issued all test key material. It includes also the user certificate for cn=mayer,ou=sales,o=my-company for the purpose of testing SASL binds.

dirxcp clients use the Mozilla LDAP SDK to implement the LDAP stub and the SSL Security support. To manipulate the certificate databases read by dirxcp, you need to use the utility program certutil provided as part of the SDK.

You may download the sources and binaries from the Mozilla Ftp Server

For a complete documentation on the certutil command line tool see

The key database, used by dirxcp when a SASL bind operation with the EXTERNAL mechanism is performed, contains the data required to access the private key that corresponds to the client certificate.

The default location for the key3.db key database is:

install_path/client/conf

You can override the default location and file name by setting the DIRX_KEY3DB_FILE environment variable to the full pathname of the file.

When an LDAP client (in this case, dirxcp) binds to an LDAP server (in this case, the DirX Directory server) using the ldap_sasl mechanism (see the obj bind description for details), dirxcp accesses:

Use the Mozilla command line tool certutil to add Client PSEs to the cert8.db database and to the key3.db key database files.

The DirX Directory installation contains an example key3.db file containing a private key for testing purposes for the user with the nickname "mayer".It is protected with the passphrase dirxdirx.See the description of the -sasl option of the dirxcp operation obj bind.

The DirX Directory installation contains an example cert8.db file containing the CA certificate of the "Test CA" that issued all test key material.It includes also the user certificate for cn=mayer,ou=sales,o=my-company for the purpose of testing SASL binds.

The encrypted IDM (IDMS) configuration file idmssl.cfg specifies the parameters for the SSL initialization that is needed to perform the X.500 protocols over IDMS, the encrypted variant of IDM.The *.pem and .pwd files contain the necessary key material.

Each DirX Directory process that uses IDMS has its own configuration file (idmssl.cfg) located in the respective conf folder:

If IDMS is enabled, the processes read the file at startup. To enable IDMS, the DirX Directory process’s own PSAP address must contain a DNS component with an SSLPORT subcomponent value greater than 0. The environment variable DIRX_OWN_PSAP specifies the own PSAP address for the DSA process, whereas the LDAP server and the DUA client (dirxcp) get their own PSAP addresses from the SELF entry in the dirxldap.cfg or dirxcl.cfg configuration files.

The settings are used for the lifetime of the process; that is, a restart is required for changes to the configuration file to take effect.

The idmssl.cfg file contains the pathnames of the key material files used by the SSL/TLS library and configuration options for the security protocol, ciphers, wait time and logging level.

In the configuration file, comment lines begin with the hash tag character (#) in the first column and are ignored. The format of all other lines is:

The following parameters (keyword) must be specified:

idm_ssl_own_pse_file

idm_ssl_pwd_file

idm_ssl_trusted_ca_cert_file

idm_ssl_protocol_min

idm_ssl_protocol_max

Both sides must share at least one common protocol version to establish an SSL connection.

SSLv3 is considered to be unsafe and therefore not supported.

idm_ssl_ciphers_list

idm_ssl_ciphers_suites

idm_ssl_io_timeout

idm_ssl_logging

The SNMPv2 trap configuration file, used by DirX Directory server processes (dirxdsa, dirxdsas, dirxldapv3), controls sending SNMPv2 traps if enabled (environment variable DIRX_SNMP=1).

The default location for the snmptraps.cfg configuration file is:

install_path/conf

You can override the default location and file name by setting the DIRX_SNMPTRAPS_CFG environment variable to the full pathname of the file. If this file does not exist, sending SNMPv2 traps is disabled.

DirX Directory installs a template for the configuration file at its default location. An update installation installs the file snmptraps.cfg.new. The installed file provides a complete list of traps that DirX Directory is able to send. You can turn each trap on or off by commenting or un-commenting its line. It is recommended not to delete lines without proper knowledge of their function.

Configure the following main sections by editing the configuration file as follows:

The SNMPv2-trap configuration file consists of the following sections:

Each section is described below.

See the configuration file installed under install_path/conf/dirx.

Monitoring DirX Directory with SNMPv2 Alarms in the Administration Guide, install_path/conf/snmptraps.cfg[.new], install_path/conf/DIRX-MIB.txt

The dirxauddecode configuration file, used by the dirxauddecode command, customizes the content of the output file when evaluating LDAP audit log files.

The dirxauddecode configuration file is an ASCII file that may contain assignments and must contain at least one common sequence.Sequences may contain commands.(The following sections describe how to specify assignments, sequences, and commands.) The format of the file is as follows:

Customizing the dirxauddecode output file may be useful, for example, to generate a suitable output file for further processing by statistical tools.

DirX Directory does not provide a default file or expect a specific name or location because it is optional to customize the dirxauddecode output file.

The name of the dirxauddecode configuration file is specified in the -F option of dirxauddecode.

Assignments specify separators for fields, records, and decimal numbers in the output file. Assignments must start with the % character at the first column of a new line. The syntax is:

where KEYWORD is one of the following keywords:

FIELDSEPARATOR

RECORDSEPARATOR

NUMERICDOT

The value must be enclosed in double quotes (").

Specify only one assignment per keyword per file. You can specify assignments at any line of the configuration file, but you cannot specify them inside sequences.

A sequence is a group of commands that specifies the output fields and their position in the output record. The syntax for a sequence is as follows:

Each sequence starts with *_SEQUENCENAME_ and ends with *-*_SEQUENCENAME_ where _SEQUENCENAME_ must be the same value. Specify the * and the - character in the first column of a new line. Specify only one sequence for a sequence name per file. Sequences can be empty. Specifying nested sequences is prohibited. (For a list of available commands, see the section Specifying Commands.)

Specify one of the following keywords for SEQUENCENAME:

COMMON

HEADER

FOOTER

Operation scope-specific commands are processed only if the audit log file record represents the corresponding operation; for example, an OPSEARCH sequence is processed only for search operation audit records. Operation scope-specific sequences are optional. Like all other sequences, they may be empty. You can specify operation scope-specific and common scope-specific commands. Specify one of the following names for operation scope-specific sequences:

OPABANDON

OPADD

OPBIND

OPCOMPARE

OPDELETE

OPEXTENDED

OPMODDN

OPMODIFY

OPOTHER[none] * Specifies commands performed for audit records of unexpected operations that cannot be identified. The specified commands can be of OPOTHER or COMMON specific scope.

OPRPC

OPSEARCH

OPUNBIND

OPUNKNOWN

When dirxauddecode evaluates an LDAP audit log file using the dirxauddecode configuration file, it performs the following process:

See the next section for information on how to specify commands inside a sequence.

dirxauddecode writes the operations to the output file in the same sequence as it reads it from the LDAP audit log file. That is, they are not guaranteed to be written in the same sequence as they were received by the LDAP server because the server writes an audit record after finishing the operation. For example, the LDAP server may log a long-lasting operation after a faster performed operation despite the fact that it received the long-lasting operation at an earlier date. (See also the dirxauddecode command reference page.)

A command specifies the data written to one field in the output file. The syntax for a command is as follows:

Each command starts with + character in the first column of a new line in the configuration file. Only one command can be specified per line. Commands can only be specified inside a sequence. (See the section Specifying Sequences for details.)

Each command generates a field in the output file. After writing an output field, dirxauddecode writes the field separator specified in the FIELDSEPARATOR assignment to the output file. After it processes all commands for an audit file record, dirxauddecode writes the record separator specified in the RECORDSEPARATOR assignment to the output file. (See the section Specifying Assignments for details.)

The following table lists all available commands together with their associated scope:

In the following example, the administrator:

The administrator may also specify other operation specific command sequences.

The dirxauddecode configuration file is as follows:

The header output may be as follows:

The common output for an operation may be as follows:

A search operation specific output appended to the common output above may be as follows:

Note that the common output and the operation specific output is written to a single record in the output file that is there is no line break inside one record.

The initial output may be as follows:

The syslog configuration files define the levels and messages that the DirX Directory processes pass to the Linux system log daemon.

Passing of messages to the Linux system log daemon is controlled by the specifications contained in the following files:

Which messages are passed to the Linux system log daemon is specified in the following format:

where

message_level

hexId

Blank lines and lines starting with the # character are ignored.

When DirX Directory is installed, default files disabling passing of messages are installed. These files may contain additional data for other purposes. It is prohibited to modify other lines than the specifications for passing logging messages.

In the following example, the DSA startup message with the identifier 0x45046cec, and all DSA messages of level fatal are passed to the Linux system log daemon.

The DirX Directory syslog configuration file install_path/dsa/conf/dirxlogflt.cfg contains the following lines:

The Linux file /etc/syslog.conf contains the following lines:

The Linux syslog daemon writes messages of level

Keep in mind that the example passes just messages to the files /data/qaee/tmp/syslog.err and /data/qaee/tmp/syslog.notice.

After starting DirX Directory, you will find the following DirX Directory server message:

You find no DirX Directory messages in the file /data/qaee/tmp/syslog.err because no fatal error occurred during DSA startup.

Logging in DirX Directory serves two purposes:

Nearly all DirX Directory components use the same type of logging; as a result, logging configuration is identical for nearly all DirX Directory components. When a process starts, it automatically reads the logging configuration, and, if configured to do so, starts logging. DirX Directory allows you to specify the kind of information to be logged and where this information is to be stored on disk. DirX Directory logging provides two sets of information that control logging:

You can configure logging to start when a process starts and you can enable and disable logging during runtime. You can isolate logging to one or more DirX Directory components; for example, you can select the memory management component (the ctx subcomponent of the dir component) to produce logging information and leave the remaining components out of the logging process. You can also control how much information is appended during logging, so that a function might just log its calling or conversely, present highly detailed information about all of the data it transfers. All of these features allow for a very detailed tracing of what happens inside the process, nearly as detailed as a debugger. On the other hand, if detailed trace logging is turned on and a lot of data is written, it may significantly impact execution speed. Consequently, you should always select what is to be logged.

Exception logging is different from normal logging. Exception messages help the administrator to get a quick overview of errors or other relevant events that occur during process execution. We recommend that you do not turn off exception logging, because it is rarely time-critical and may provide valuable information for ensuring continuous service.

Logging configuration files define the messages to be logged and how and where the logs should be written. Two types of messages can be logged:

Logging is controlled by the specifications contained in the following files:

When DirX Directory is installed, the following configuration files specifying default values are installed:

By default, log files are written to the following directories:

When a process starts, it reads its dirxlog.cfg file and sets trace logging levels, exception logging levels and output file paths to the settings in this file. By default, the processes only log exception messages (like warnings, notices or errors) and do not perform trace logging. There are two methods you can use to enable trace logging, for example, when you want to trace a certain problem:

We recommend using the second method (dirxlog.on and dirxadm log) if possible, because it omits unnecessary startup logs and does not require a process restart. (Remember that dirxlog.cfg is only read at process startup.)

You can override the default file name for the startup logging configuration file by setting the DIRX_LOGCFG_FILE environment variable to the full pathname of the file. You can modify the .on and .off files to define your desired logging parameters, and you can create additional files that function in a manner similar to the .on and .off files.

Use the logging configuration .on and .off files for trace logging as follows:

All logging configuration files consist of two sections. The first section defines trace logging, and the second defines exception logging. Each section is described below.

In the examples that follow, lines beginning with the hash tag character (#) are comment lines used to differentiate the trace logging section from the exception logging section.

The following is a sample dirxlog.cfg file.

The following is an example of a dirxlog.off file. Note that the first line of the file turns trace logging off for the dir and dba components.

sys log (dirxadm), sys nolog (dirxadm), ldap log (dirxadm), ldap nolog (dirxadm), progsvr log (dirxadm), progsvr nolog (dirxadm), dirxdumplog

Signature files named original_name*.sig* are supplied for all executables and dynamic libraries delivered with DirX. These signature files can be used to verify that the code has not been altered or corrupted since it was signed.

To perform the verification, use the verify.sh (Linux) or verify.bat (Windows) script in the folder install_path/signing and specify the full path of the public key for verification dxd_sign_public.pem on the command line. This public key is contained in the folder install_path/signing and can also be downloaded from the support portal.

The following example shows the usage and output of code-signing verification:

The DirX Directory service operates under license control and requires the presence of a valid license to run.The dirx.lic and dirx.lic.sig files are used by the DirX Directory service (DSA process) during its license validation procedure.They are located in:

install_path/conf

The dirx.lic file is a human-readable text file that describes the license agreement that you (the customer) have with the DirX Directory vendor for use of the DirX Directory product. The file contains parameters that define the agreed-upon terms and conditions for use, such as the license expiration date, the number of directory entries permitted, and the host names or IP addresses of machines that are allowed to run the service.

DirX Directory supplies a default “trial” dirx.lic file with restrictive parameter settings. The service uses this file for license control until you (optionally) replace it with a “perpetual” dirx.lic file that defines custom parameter settings negotiated between you and the DirX Directory vendor.

License control works as follows: at product installation, at each service startup, and daily on a running system, the service’s license validation procedure compares the settings in the dirx.lic file against the current installation and logs the results in the file install_path*/server/log/fatalDSA**. The action taken on a license violation depends on the type of violation and the license type.

You are allowed to read the dirx.lic file but you are not allowed to modify it.

The dirx.lic.sig file is a binary file generated from the dirx.lic file. The service’s license validation procedure uses this signature file at service startup and daily on a running system to verify that the dirx.lic file has not been tampered with or corrupted. See the section “Code Signing Files” in this chapter for more information on this type of file.

Trial license dirx.lic and dirx.lic.sig files are delivered with each DirX Directory release and are automatically installed into install_path*/conf*. Perpetual license dirx.lic and dirx.lic.sig files are issued by the DirX Directory vendor and must be manually installed by overwriting the trial dirx.lic and dirx.lic.sig files and then running the license validation procedure.

A DirX Directory upgrade installation installs the most recent trial dirx.lic and dirx.lic.sig files into install_path*/conf* unless it finds that these files are already present. In this case, it installs the most recent trial license files in the same directory as the existing license files with the names dirx.lic.new and dirx.lic.sig.new.

Note that the dirx.lic and dirx.lic.sig license files are not part of the regular backup procedure for a DirX Directory installation. You must back up these files manually.

For more information about license files and license types, how to obtain and install license files, and how license files are used in DirX Directory license validation, see the section “License Requirements” in the DirX Directory Release Notes.

The dirx.lic file consists of two types of lines: comment lines and parameter lines.

Comment lines begin with the hash tag character (#) in the first column and are ignored.

A parameter line defines a specific term of the license agreement.

Parameter lines consist of a keyword and a value. Keywords appear in the first column and are separated from the value by one or more space characters.

Parameters can appear in any order within the file.

Most parameters are mandatory; a few are optional. If an optional parameter is not present in the file, there is no restriction on what the parameter controls. For example, if the host_name or host_ip parameters are not present, the service is permitted to run on any machine in the customer environment.

create_date date

customer_email email_address

customer_name name

customer_project project_name

dirx_entries max_number_of_entries

host_ip address

host_name name

license_type trial | perpetual

product_name dirx_product_name

product_version_major number

product_version_minor number

signature_digest value

support_expiry_date date

Here is the template perpetual DirX Directory license file. It contains all the parameters that are available for use when creating a perpetual license. This file is not included with the DirX Directory installation.