This appendix provides information about the Oracle Communications Calendar Server 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 Calendar Server.
This section provides information you need to understand before running the comm_dssetup.pl script.
The comm_dssetup.pl script performs the following steps:
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".
Generates a shell script and LDIF file from the information that you supply that is used to modify the Directory Server LDAP.
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.
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.
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):
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. |
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 (and the Directory Server binaries) resided. After Directory Server 6, the concept of the "server root" was removed. Directory Server instances (and the Directory Server binaries) do not all have to reside under a single umbrella "server root" directory.
Calendar Server 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.
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 Calendar Server 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.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.
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 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 |
|
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 |
|
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.
You can run the comm_dssetup.pl script in either interactive or silent mode. Interactive mode is described in "Running the comm_dssetup.pl Script in Interactive Mode".
To run the comm_dssetup.pl script in silent mode:
On the host where Directory Server is installed, log in as or become the superuser (root).
Start Directory Server, if necessary.
Change to the directory where you installed or copied the Directory Server Setup comm_dssetup.pl script.
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
If you answered no
to the -R and -m options, you must manually run the comm_dssetup.sh script that was created.
If you answered yes
to the -R and -m options, the dssetup.sh script is run automatically.
Table B-3 table 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. |