This appendix provides information about the Oracle Communications Calendar Server configuration scripts.
The init-config script enables you to perform an initial configuration of your Calendar Server deployment. Table C-1 describes the init-config options.
| Option | Description |
|---|---|
|
-f statefile_name |
Uses the statefile_name for setting input values. Use the DavserverCfgDefaults.properties file as an example. |
|
-i hostname |
Uses hostname as the FQDN of the current host. |
|
-l |
Uses the name returned by the /bin/hostname command for name of host. /bin/hostname must return an FQDN. |
|
-s |
Performs a silent initial configuration, requires the -f option. |
|
-S statefile_name |
Saves state of init-config script input to a named statefile_name. |
|
-v |
Enables verbose mode. |
|
-W |
Use this option for WebLogic Server. It is applicable for the initial configuration. Note: If you do not use this option, GlassFish Server is used as the default application server. |
When you configure Calendar Server for the first time with Oracle WebLogic Server in a secure mode, run the extractSSLArgs.sh script. This script validates the SSL configuration details in Oracle WebLogic Server and stores the valid details in a format that is required by Calendar Server for all future deployments and processing.
The following table lists the options for validating and storing Oracle WebLogic Server SSL details.
Table C-2 WebLogic Server Options
| Option | Description |
|---|---|
|
-u |
WebLogic Server Administrator User ID |
|
-p |
WebLogic Server Administrator User Password |
|
-l |
WebLogic Server Administrator URL t3|t3s://FQDN:Weblogic AdminServer (SSL|NonSSL)Port For example, t3://hostname.com:7001 Or t3s://hostname.com:7002 |
|
-r |
Runtime directory under which /config/davadmin.properties file resides. For example, /var/opt/sun/comms/davserver/config/davadmin.properties. You can use this option only on the existing Calendar Server deployment which is already running on WebLogic Server. Use this option if WebLogic Server's keystore settings are modified after Calendar Server is deployed and those settings have to be updated on Calendar Server Configuration. |
Validate the SSL and Keystore configurations on WebLogic Server setup
Perform the steps in the "Installing and Configuring WebLogic Server" section to set up WebLogic Server in a secure mode.
Keep the configuration details of WebLogic Server handy.
To validate and store Oracle WebLogic Server SSL details for Calendar Server in a secure mode:
Open a new terminal and prepare the terminal by sourcing the setDomainEnv.sh script of the Oracle WebLogic Server domain:
cd Weblogic_Domain/bin
source ./setDomainEnv.sh OR . ./setDomainEnv.sh
Set the WLST_PROPERTIES environment variable depending on the selected Oracle WebLogic Server keystore configuration.
If the CustomIdentityandCustomTrust keystore option is configured as the Oracle WebLogic Server keystore configuration, set the WLST_PROPERTIES variable to:
export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust , -Dweblogic.security.CustomTrustKeyStoreFileName=Weblogic_Domain/mytrust.jks"
where Weblogic_Domain/mytrust.jks is the location of truststore file location.
If the CustomIdentityandJavaStandardTrust keystore option is configured as the Oracle WebLogic Server keystore configuration, set the WLST_PROPERTIES variable to:
export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=JavaStandardTrust"
Run the extractSSLArgs.sh bash shell script extractSSLArgs.sh which is available under the Calendar Server installed location: Calendar_Server_Installedlocation/sbin:
sh ./extractSSLArgs.sh -u weblogic_admin_user -p weblogic_admin_user_password -l t3s://weblogic_server_host:SSL_port
If the execution of the script is successful, it creates .wls_sslargs under the configuration directory of your Oracle WebLogic Server domain. You can verify the creation of .wls_sslargs by navigating to the Weblogic_Domain/config directory.
If you modify keystore settings of the in-production WebLogic Server on which Calendar Server is deployed, you must update the previously supplied SSL Keystore details on Calendar Server. By using the extractSSLArgs.sh -r option, you can update the keystore information.
Ensure that WebLogic Server Keystore and SSL configurations are modified and you have the latest configuration details.
Open a new terminal and prepare the terminal by sourcing the setDomainEnv.sh script of the Oracle WebLogic Server domain:
cd Weblogic_Domain/bin
source ./setDomainEnv.sh OR . ./setDomainEnv.sh
Set the WLST_PROPERTIES environment variable. See step 2 in "Running the Script for a Fresh Installation". Ensure to enter the latest keystore details.
Run the following script:
sh ./extractSSLArgs.sh -u weblogic_admin_user -p weblogic_admin_user_password -l t3s://weblogic_server_host:SSL_port -r davserver_runtime_dir
For example,
sh extractSSLArgs.sh -u weblogic -p weblogic123 -l t3s://myhost.domain.com:7002 -r /var/opt/sun/comms/davserver
Restart WebLogic Server.
Weblogic_Domain/config/.wls_sslargs and davserver_runtime_dir/config/davadmin.properties files are updated according to the Keystore modifications performed on WebLogic Server.
Note:
CalendarServer_home/config/ contains the davadmin.properties file. CLI davadmin utility of the product uses the davadmin.properties file. Therefore, any modifications performed on WebLogic Server for keystore settings must reflect in the davadmin.properties file.Calendar Server ships with Perl scripts to prepare a new database installation. You can use these scripts instead of manually preparing a new database installation.
The config-mysql script prepares a new MySQL installation for use with Calendar Server.
Caution:
If you already have a running instance of MySQL server, read the following information carefully before using this script.config-mysql [options]
Table C-3 describes the config-mysql options:
Table C-3 config-mysql Options
| Option | Description |
|---|---|
|
--help | -? |
Prints help. |
|
--calendar | -c |
Configures the calendar database. |
|
--ischedule | -i |
Configures the ischedule database. |
|
--server | -s |
Configures the MySQL server instance. |
|
--user | -u |
Creates the MySQL database user. |
To set up a new MySQL Server instance, and the default back end and iSchedule back end:
config-mysql -s -u -c -i
To set up a MySQL Server instance on an additional host, and a new calendar back end:
config-mysql -s -u -c
To set up just a new calendar back end on any existing instance:
config-mysql -c
The config-mysql script creates a minimal instance configuration in the /etc/my.cnf file for use with the Calendar Server database.
To run the config-mysql script:
Copy the config-mysql and Util.pm scripts from a machine where Calendar Server is installed to the machine where MySQL is installed.
Both scripts are located in the CalendarServer_home/tools/unsupported/bin directory.
On the machine where MySQL is installed, as root, launch the config-mysql script with options -s, -u, -c, and -i.
The script creates a log file in the /tmp directory with a name such as config-mysql_YYYYMMDDHHMMSS.log.
If you receive a message that the script has found existing instance configuration in the /etc/my.cnf file, enter yes to overwrite the existing instance configuration, or no to exit.
Enter the instance data directory.
If you choose a directory that already exists, the script assumes that it belongs to an existing MySQL instance and that it might contain useful data. If that's not the case and you want to use that directory, remove the directory first.
Enter the MySQL root user password, and enter again to confirm.
Enter the db user, password (once more to confirm), calendar db name, and iSchedule db name.
The script then outputs the list of tasks to be performed and asks you to confirm before proceeding.
Enter y to proceed.
The script performs the following steps:
Stops the running MySQL instance.
This step is run regardless of whether an instance is running. You might see the following message, which you can safely ignore:
ERROR! MySQL server PID file could not be found!
Runs the mysql_install_db command to create the instance data directory specified in Step 3.
Creates a minimal /etc/my.cnf file for the instance.
Copies the mysql.server script to the system startup and shutdown directory.
Starts the MySQL server by using the configuration in the /etc/my.cnf file.
Uses the mysqladmin script to change the root password specified in Step 5.
Runs mysql_secure_installation script to secure the newly created MySQL instance.
When the script asks for the existing root password, use the one from Step 5 and answer no to the question "Change the root password? [Y/n]."
One of the tasks in the mysql_secure_installation script is to change the root password (because a fresh instance has a blank root password).
The last step is for the script to create the calendar database, iSchedule database, and database user by using the mysql tool.
The config-oracle script prepares a running Oracle Database instance for use with Calendar Server. The config-oracle script is supported by Oracle Database 11g Release 2 and Oracle Database 12c, not pluggable (non-CDB).
Note:
You cannot use the config-oracle script for an Oracle Database 12c container database (that is, one that uses a pluggable database). Instead, you must manually prepare an Oracle Database 12c container database for use with Calendar Server. See "Preparing Oracle Database 12c Container Database" for more information.Before running this script, ensure that you have run the oraenv or coraenv script. The script creates a log file in the /tmp directory with a name such as config-oracle_YYYYMMDDHHMMSS.log.
config-oracle [options]
Table C-4 describes the config-oracle options:
Table C-4 config-oracle Options
| Option | Description |
|---|---|
|
--help | -? |
Prints help. |
|
--calendar | -c |
Configures the calendar database. |
|
--ischedule | -i |
Configures the iSchedule database. |
To set up the default back end and iSchedule database:
config-oracle -c -i
To set up an additional calendar back end:
config-oracle -c
To run the config-oracle script:
Copy the config-oracle and Util.pm scripts from a machine where Calendar Server is installed to the machine where Oracle Database is installed.
Both scripts are located in the CalendarServer_home/tools/unsupported/bin directory.
On the machine where Oracle Database is installed, as root, enter the following command:
config-oracle -c -i
Enter the Oracle SYS user password.
Enter the calendar db user name and password, and iSchedule db user name and password.
The script outputs the list of tasks to be performed.
Enter Y to proceed.
The script creates the calendar and iSchedule database users and schemas.
Use the populate-davuniqueid script if you initially selected the nsUniqueId attribute as the unique identifier for your Calendar Server deployment. The populate-davuniqueid script populates calendar users and resources in LDAP with the davUniqueId schema element, introduced in Calendar Server 7 Update 3. It copies the value of nsUniqueId to davUniqueId, thus preserving references in the calendar database. The davUniqueId attribute is subsequently used as the value for the Calendar Server davcore.uriinfo.permanentuniqueid configuration parameter. Calendar Server requires a unique identifier in the form of an LDAP attribute whose value is used to map each calendar entry (in the LDAP Directory Server) to a unique account in the calendar database (the MySQL Server or Oracle Database that stores Calendar Server data). The unique identifier links various entries from different database tables for a user and resource. You must use a unique identifier, and one that does not change, for user and resource entries stored in LDAP.
Note:
The problem with using the nsUniqueId attribute for this purpose is that if the user or resource LDAP entry is deleted and re-created in LDAP, the new entry has a different nsUniqueId value. See "Changing the User Unique Identifier" for more information on the problems with using nsUniqueId.populate-davuniqueid [ -h host ] [ -p port ] [ -D user ] [ -w pass | -j passfile ] [ -b base ] [ -f filter ] [ -o outfile ] [ -O ] [ -x ] [ -v ] [ -? ]
Table C-5 describes the populate-davuniqueid options:
Table C-5 populate-davuniqueid Options
| Option | Description | Default Value |
|---|---|---|
|
-h host |
Specifies the Directory Server host |
No default value. |
|
-p port |
Specifies the Directory Server port |
389 |
|
-D user |
Specifies the Directory Server bind user |
No default value. |
|
[ -w pass | -j passfile ] (The -j option is preferred, as the password is not specified on the command line.) |
Specifies either the Directory Server bind password or a password file storing the directory user password |
No default value. |
|
-b base |
Specifies the Directory base to carry out the search |
No default value. |
|
-f filter |
Specifies the LDAP search filter |
"(|(objectclass=inetorgperson)(objectclass=inetresource)(objectclass=groupofuniquenames)(objectclass=groupofurls)(objectclass=inetmailgroup))" |
|
-o outfile |
Specifies the output file name |
No default value. |
|
-O |
Specifies to add the davEntity object class to the LDAP entry |
No default value. |
|
-x |
Automatically runs the ldapmodify command on the output file |
No default value. |
|
-v |
Specifies verbose debugging |
No default value. |
|
-? |
Displays the usage help text |
No default value. |
The populate-davuniqueid script prompts you to type all options with the exception of port and filter, if you do not specify them. If not specified, port has a default value of 389 and filter has the value "(|(objectclass=icscalendaruser)(objectclass=icscalendarresource)(objectclass=groupofuniquenames)(objectclass=groupofurls)(objectclass=inetmailgroup))". All LDAP entries matching filter, starting from the search base, that have a missing davUniqueId field are output to the outfile file in the form of an LDAP modification operation. You can then examine the outfile content before running it through an ldapmodify command, Alternately, you can do so automatically by using the -x option.
These examples show different scenarios for running the populate-davuniqueid script.
To add the davuniqueid attribute to all Calendar Server users:
Run the populate-davuniqueid script and output the changes to a file, sample.txt.
/opt/sun/comms/davserver/sbin/populate-davuniqueid -h host1.us.example.com -D "cn=Directory Manager" -b o=isp -o sample.txt Directory user bind password: Please check the following information Directory host: host1.us.example.com Directory port: 389 Directory user bind DN: cn=Directory Manager Directory user bind password: as specified Directory search base: o=isp Directory search filter: (|(objectclass=icscalendaruser)(objectclass=icscalendarresource)) Output to: sample.txt Add daventity objectclass: no Load output LDIF automatically: no Do you want to continue (y/n)?: y sample.txt is created. Please examine content and run ldapmodify on it.
Examine the sample.txt file. It should resemble the following:
dn: uid=calmaster63, ou=People, o=us.example.com,o=isp changetype: modify add: davuniqueid davuniqueid: e5cb6c08-dd5811e1-80f5ce3b-d63ea23a
As long as there is no error, run the ldapmodify command to add davUniqueId to all Oracle Communications Calendar Server users, or run the following command:
/opt/sun/comms/davserver/sbin/populate-davuniqueid -h host1.us.example.com -D "cn=Directory Manager" -b o=isp -o sample.txt -x Directory user bind password:
To add the daventity object class and davuniqueid attribute to all Calendar Server 6 users:
Run the populate-davuniqueid script and output the changes to a file, test.txt.
/opt/sun/comms/davserver/sbin/populate-davuniqueid -h host2.us.example.com -D "cn=Directory Manager" -b o=isp -o test.txt -O Directory user bind password: Please check the following information Directory host: host2.us.example.com Directory port: 389 Directory user bind DN: cn=Directory Manager Directory user bind password: as specified Directory search base: o=isp Directory search filter: (|(objectclass=icscalendaruser)(objectclass=icscalendarresource)) Output to: test.txt Add daventity objectclass: yes Load output LDIF automatically: no Do you want to continue (y/n)?: y test.txt is created. Please examine content and run ldapmodify on it.
Examine the test.txt file. It should resemble the following:
dn: uid=user3,ou=People,o=domain3.com,o=isp changetype: modify add: objectclass objectclass: daventity - add: davuniqueid davuniqueid: ff22a401-e52011e1-80f5ce3b-d63ea23a
As long as there is no error, run the ldapmodify command to add davEntity and davUniqueId to all Calendar Server 6 users, or run the following command:
/opt/sun/comms/davserver/sbin/populate-davuniqueid -h host2.us.example.com -D "cn=Directory Manager" -b o=isp -o test.txt -O -x Directory user bind password: