B comm_dssetup.pl Reference

This appendix provides information about the Oracle Communications Delegated Administrator comm_dssetup.pl script. You must prepare your Oracle Directory Server Enterprise Edition (Directory Server) hosts by running the comm_dssetup.pl before you install and configure Delegated Administrator.

About the comm_dssetup.pl Script

This section provides information you need to understand before running the comm_dssetup.pl script.

The comm_dssetup.pl script performs the following steps:

  1. Prompts you for your deployment's Directory Server and schema information.

    For a list of the specific information this step requests, see "Information Needed to Run the comm_dssetup.pl Script."

  2. Generates a shell script and LDIF file from the information that you supply that is used to modify the Directory Server LDAP.

  3. Runs the generated shell script and modifies your Directory Server.

At the end of each step, the comm_dssetup.pl script prompts you to continue. No changes are made to the Directory Server LDAP until the last step.

Directory Server Considerations for the comm_dssetup.pl Script

When running the comm_dssetup.pl script, consider the following points.

  • comm_dssetup.pl configures local Directory Server instances, and thus you must:

    • Install the comm_dssetup.pl script on every host on which a Directory Server instance resides.

    • Run the comm_dssetup.pl script on the same host as your Directory Server. The tool runs locally for a specific instance (specified by path of Directory Server or path of instance).

  • You can run the comm_dssetup.pl script against any Directory Server instance on the local host. If you have multiple Directory Information Trees (DITs) on one host, you can maintain and update one installation of comm_dssetup.pl, and apply it to every Directory Server instance on the host.

  • comm_dssetup.pl must configure every Directory Server instance for the same DIT. This assumes that:

    • A Directory Server has already been installed, configured, and is running before you launch the comm_dssetup.pl script.

    • When adding an additional Directory Server host (such as a replica), at a future date, you must run the comm_dssetup.pl script against it, too.

  • If you have customized your Directory Server, the following considerations might apply:

    • If you have indexed some attributes, you might have to reindex those attributes after running the comm_dssetup.pl script.

    • If you have added other LDIF files (schema definitions), they should not be affected, so no action should be necessary. However, back up your custom schema definition files before running the comm_dssetup.pl script.

      The comm_dssetup.pl script backs up old schema files to the /var/tmp/dssetup_timestamp/save directory.

    • For all Directory Server customizations, including the first two just listed, stop the comm_dssetup.pl script after it generates the script and before it actually updates the LDAP directory. Then inspect the script to evaluate how its proposed actions affect your LDAP directory. Take whatever actions you think necessary to protect your customizations before running the script against your Directory Server.

Information Needed to Run the comm_dssetup.pl Script

Table B-1 describes the information about your deployment that you need to gather before running the comm_dssetup.pl script.

Table B-1 comm_dssetup.pl Information

Information Item Needed Default Value

Directory Server root path name

The default depends on the Directory Server version detected. The comm_dssetup.pl script does attempt to heuristically determine the value.

Which instance of Directory Server to use? (if more than one)

The default depends on the Directory Server version detected. The comm_dssetup.pl script does attempt to heuristically determine the value.

Directory Manager Distinguished Name (DN)

"cn=Directory Manager"

Directory Manager's Password

NA

Directory Server being used for user/group data? (yes), or configuration data only? (no)

yes

User and group root suffix (if yes to previous question)

The default depends on what is detected. The comm_dssetup.pl script does attempt to heuristically determine the value.

Schema version? (pick one of the following):

  • 1 - Schema 1

  • 1.5 - Schema 2 Compatibility Mode

  • 2 - Schema 2 Native Mode

For more information on how to choose a schema, see "About the comm_dssetup.pl Script Schema Choices." If you have one version of the schema installed and want to upgrade to a higher level, refer to Sun Java System Communications Services 6 2005Q4 Schema Migration Guide before running the script.

2

However, if you run comm_dssetup.pl again, it defaults to the value that you chose the previous time.

If you choose Schema 1 or 1.5, you need a DC tree. If the DC tree does not yet exist, the comm_dssetup.pl script creates only the root suffix node, its does not create the rest of the DC tree. You must create the rest of your DC tree yourself.

o=internet

However, if you run comm_dssetup.pl again, it defaults to the value that you chose the previous time.


About the Directory Server Root Path Name and Instance

The comm_dssetup.pl script prompts you for both the Directory Server root path and the Directory Server instance. The script then combines these two items into an absolute path name to the Directory Server instance. For example, if your Directory Server instance resides under the /var/opt/sun/directory/slapd-varrius directory, then you specify /var/opt/sun/directory for the Directory Server root path and slapd-varrius for the Directory Server instance.

The reason for having two comm_dssetup.pl prompts to specify one absolute path is historical. Prior to Directory Server 6, Directory Server had the concept of a "server root" under which all Directory Server instances (as well as the Directory Server binaries) resided. After Directory Server 6, the concept of the "server root" was removed. Directory Server instances (as well as the Directory Server binaries) do not all have to reside under a single umbrella "server root" directory.

About the comm_dssetup.pl Script Schema Choices

Delegated Administrator supports the following schema choices:

  • LDAP Schema 2 native mode

    Corresponds to comm_dssetup.pl script schema version choice 2. This is the default for a fresh installation.

  • LDAP Schema 1

    Corresponds to the comm_dssetup.pl script schema version choice 1.

  • LDAP Schema 2 compatibility mode

    Corresponds to comm_dssetup.pl script schema version choice 1.5.

About LDAP Schema 2

LDAP Schema 2 is a set of provisioning definitions that describes the types of information that can be stored as entries by using the Directory Server LDAP.

The native mode uses search templates to search the Directory Server LDAP. Once the domain is found by using the domain search template, the user or group search templates are used to find a specific user or group.

You should use native mode if you are installing Delegated Administrator for the first time and you do not have other applications in your deployment that are dependent on a two-tree provisioning model.

Note:

If you have an existing deployment that uses Schema 1, and you want to integrate other Communications Suite products, you should migrate your directory to Schema 2. Refer to Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for information on how to migrate from LDAP Schema version 1 to LDAP Schema version 2.

About LDAP Schema 1

LDAP Schema 1 is a provisioning schema that consists of both an Organization Tree and a DC Tree. In Schema 1, when a search is conducted for user or group entries, it looks at the user's or group's domain node in the DC Tree and extracts the value of the inetDomainBaseDN attribute. This attribute holds a DN reference to the organization subtree containing the actual user or group entry.

About LDAP Schema 2 Compatibility Mode

Schema 2 compatibility mode is an interim mode between Schema 1 and Schema 2 native mode. Schema 2 compatibility mode supports both schemas and enables you to retain the existing two-tree design you already have.

Use Schema 2 Compatibility if you have existing applications that require Schema 1, but you also need functionality that requires Schema 2.

Note:

Schema 2 compatibility mode is provided as a convenience in migrating to the Schema 2 Native mode. Do not use Schema 2 compatibility mode as your final schema choice. The migration process from Schema 1 to Schema 2 compatibility mode and then finally to Schema 2 native mode is more complex that simply migrating from Schema 1 to Schema 2 native mode. See Sun Java System Communications Services 6 2005Q4 Schema Migration Guide for more information.

Attribute Indexes Created by the comm_dssetup.pl Script

Attribute indexes improve the performance of search algorithms. The comm_dssetup.pl script offers you the choice to index attributes.

Table B-2 lists all the attributes the comm_dssetup.pl script indexes, grouped by suffix category. It also lists the type of indexes created for each attribute. For more information about Directory Server indexing, see the Directory Server documentation at:

http://docs.oracle.com/cd/E20295_01/index.htm

Table B-2 Attributes Indexed by comm_dssetup.pl

Suffix Attributes Indexed Type of Indexes Added

User/Group

mail

pres, eq, approx, sub

User/Group

mailAlternateAddress

pres, eq, approx, sub

User/Group

mailEquivalentAddress

pres, eq, approx, sub

User/Group

mailUserStatus

pres, eq

User/Group

member

eq

User/Group

ou

pres

User/Group

cosspecifier

pres

User/Group

groupid

pres, eq, sub

User/Group

icsCalendar

pres, eq, approx, sub

User/Group

icsCalendarOwned

pres, eq, approx, sub

User/Group

uniqueMember

eq

User/Group

memberOf

eq, sub

User/Group

cn

eq

User/Group

mgrpUniqueId

eq

User/Group

deleted

pres, eq

User/Group

davuniqueid

pres, eq

User/Group

inetCos

eq

User/Group (additional for Schema 2)

inetDomainBaseDN

pres, eq

User/Group (additional for Schema 2)

sunPreferredDomain

pres, eq

User/Group (additional for Schema 2)

associatedDomain

pres, eq

User/Group (additional for Schema 2)

o

pres, eq

User/Group (additional for Schema 2)

mailDomainStatus

pres, eq

User/Group (additional for Schema 2)

sunOrganizationAlias

pres, eq

DC Tree (for Schema 1)

inetDomainBaseDN

pres, eq

DC Tree (for Schema 1)

mailDomainStatus

pres, eq

DC Tree (for Schema 1)

inetCanonicalDomainName

pres, eq

Personal Address Book (PAB) (o=pab)

Note: For old Address Book

memberOfManagedGroup

pres, eq

Personal Address Book (PAB) (o=pab)

Note: For old Address Book

memberOfPAB

pres, eq

Personal Address Book (PAB) (o=pab)

Note: For old Address Book

memberOfPABGroup

pres,eq

Personal Address Book (PAB) (o=pab)

Note: For old Address Book

un

eq

New PAB (o=PiServerDb)

displayname

pres, eq, sub

New PAB (o=PiServerDb)

MemberOfPiBook

eq

New PAB (o=PiServerDb)

MemberofPiGroup

eq

o=mlusers for future mailserv feature

mail

eq

o=mlusers for future mailserv feature

mlsubListIdentifier

eq

o=mlusers for future mailserv feature

mlsubMail

eq


To add additional indexes on your own, see the Directory Server documentation.

Running the comm_dssetup.pl Script

You can run the comm_dssetup.pl script in either interactive or silent mode.

Running the comm_dssetup.pl Script in Silent Mode

To run the comm_dssetup.pl script in silent mode:

  1. On the host where Directory Server is installed, log in as or become the superuser (root).

  2. Start Directory Server, if necessary.

  3. Change to the directory where you installed or copied the Directory Server Setup comm_dssetup.pl script.

  4. Run the script followed by the silent mode options.

    All options are required. For more information, see "Silent Mode Options."

    /usr/bin/perl comm_dssetup.pl
    [ -i yes | no ] [ -R yes | no ] [ -c DirectoryServerRoot ]
    [ -d DirectoryInstance ] [ -r DCTreeSuffix ] 
    [ -u UserGroupSuffix ] [ -s yes | no ] [ -D DirectoryManagerDN ]
    [ -j DirectoryManagerPasswordFile ] [ -b yes | no ] 
    [ -t 1 | 1.5 | 2 ] [ -m yes | no ] [-S PathtoSchemaFiles ]
    

    The script creates the following LDIF file and shell script to update the LDAP indexes and schema:

    • /var/tmp/dssetup_timestamp/dssetup.ldif

    • /var/tmp/dssetup_timestamp/dssetup.sh

  5. If you answered no to the -R and -m options, you need to manually run the dssetup.sh script that was created.

    If you answered yes to the -R and -m options, the dssetup.sh script is run automatically.

Silent Mode Options

Table B-3 describes the comm_dssetup.pl silent mode options.

Table B-3 comm_dssetup.pl Silent Mode Options

Option and Argument Description

-i yes |no

Specifies whether to configure new indexes.

yes - Add new Directory Server indexes.

no - Do not add indexes.

-R yes | no

Specifies whether to reindex automatically.

yes - Reindex without prompting the user.

no - Do not reindex without prompting the user.

The -m option must also be specified for yes for the -R option to take effect.

-c DirectoryServerRoot

Specifies the Directory Server root path, for example, /var/opt/sun/directory.

-d DirectoryInstance

Specifies the Directory Server instance subdirectory under the Directory Server root path, for example, slapd-varrius.

-r DCTreeSuffix

Specifies the DC tree root suffix (for Schema 1 and Schema 2 compatibility modes only), for example, o=internet.

-u UserGroupSuffix

Specifies the user and group root suffix, for example, o=usergroup.

-s yes | no

Specifies whether to update the schema.

yes - Update the schema.

no - Do not update schema.

-D DirectoryManagerDN

Specifies the Directory Manager Distinguished Name (DN), for example, "cn=Directory Manager". The value must be enclosed by double quotation marks (" ") to enable the comm_dssetup.pl script to interpret a value with a space correctly.

-j DirectoryManagerPasswordFile

Specifies the file containing the Directory Manager DN password.

-b yes | no

Specifies to use this Directory Server for users and groups.

yes - Use this directory to store both configuration and user group data.

no - Use this directory to store only configuration data.

-t 1 | 1.5 | 2

Specifies the schema version.

-m yes | no

Specifies whether to modify the Directory Server.

yes - Modify the Directory Server without prompting the user.

no - Do not modify the Directory Server without prompting the user.

-S PathtoSchemaFiles

Specifies the path to the directory where the schema files are located for example, ./schema.