A bit more than 6 years ago (already), I wrote a series of blogs about the silent install of some standard Documentum component. It included things from the binaries, the Docbroker (Connection Broker), the Repositories (both Primary and Remote), D2 and finally xPlore (binaries, Dsearch and IndexAgent). As of today, the principle is still the same for these components. Of course, the exact list of parameters might have changed a bit for some of them, like new parameters being added, but in essence, it’s still accurate.
I also worked with the silent install of several other components such as the Documentum BPM / xCP, the Life Sciences Suite (LSTMF / LSQM / LSRD / LSSSV or the complete LSS bundle) or the IDS (Interactive Delivery Services) but I didn’t write blogs about it. If you would be interested, don’t hesitate to ask and I will see if I can write something about it. In this one, I will share my view on the Silent install process of the OTDS (OpenText Directory Services), as it’s the new standard for user management in OpenText products.
I. Properties file
So, let’s start right away with the preparation of the properties file:
[tomcat@otds_01 ~]$ vi /tmp/otds_silent.properties
[tomcat@otds_01 ~]$ cat /tmp/otds_silent.properties
[Setup]
Id=OTDS
Version=24.4.0.4503
Patch=0
Basedir=/opt/workspace
Configfile=/opt/workspace/setup.xml
Action=Install
Log=/opt/workspace/otds-installer.log
Instance=1
Feature=All
[Property]
INST_GROUP=tomcat
INST_USER=tomcat
INSTALL_DIR=/app/app_data/otds
TOMCAT_DIR=/app/tomcat
PRIMARY_FQDN=otds-0.domain.com
ISREPLICA_TOPOLOGY=0
IMPORT_DATA=0
OTDS_PASS=otdsAdm1nP4ss+w0rd
ENCRYPTION_KEY=
MIGRATION_OPENDJ_URL=
MIGRATION_OPENDJ_PASSWORD=otdsAdm1nP4ss+w0rd
JDBC_CONNECTION_STRING=jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db1_hostname.domain.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=otds_svc.domain.com)))
JDBC_USERNAME=OTDS
JDBC_PASSWORD=jdbcP4ss+w0rd
[tomcat@otds_01 ~]$
II. Setup section
First, there is a “Setup” section in the silent install properties file, with values that aren’t really related to the OTDS installation but more about the current environment / binaries to be used. In any cases, here is a short description of the “Setup” section properties:
- Id: The component to be installed, should match the value of “Id” from the “setup.xml” file
- Version: Matches the value of “Version” from the “setup.xml” file
- Patch: Matches the value of “Patch” from the “setup.xml” file
- Basedir: The path of the base folder where the OTDS installation package (e.g. OTDS-2440-LNX.tar) has been extracted to. This path needs to contain the folders “lib”, “OTDS” and “tools”
- Configfile: The path of the “setup.xml” file that contains the details of what needs to be done
- Action: Either “Install” to install a new OTDS where there is none, “Upgrade” to upgrade an existing version to a newer one or “Modify” to uninstall the local OTDS (needs to be using the same version that was installed, you cannot uninstall using newer binaries)
- Log: The path of the log file that will be generated by the execution of the installer
- Instance: Standard OT installer details, not really used by OTDS and mostly for the Windows installer part apparently.
- Feature: Standard OT installer details, not really used by OTDS and mostly for the Windows installer part apparently. OTDS doesn’t support anything else than “All”
I’m not sure why we would need to specify both the Basedir AND Configfile as the “setup.xml” will be present inside the Basedir if you took the OTDS installation package. Maybe it’s just a convenience for OpenText, to be able to use the same installer/binaries with multiple “setup.xml” files, but anyway… Same thing for the “Id”, “Version” and “Patch” parameters, all these details can be found inside the “setup.xml” file, for which we define the Configfile parameter. Therefore, the OTDS installer could just fetch these details by itself from the setup.xml file. I guess it’s not smart enough to do that, so you need to do it by yourself otherwise the installer will complain about it.
III. Property section
Then, there is a “Property” section in the silent install properties file, which really controls the OTDS installation details. Here is a short description of the “Property” section properties:
- INST_GROUP: Name of the OS Group that will be used for group ownership of OTDS files (e.g.: primary group of the user running the Tomcat process)
- INST_USER: Name of the OS User that will be used for user ownership of OTDS files (e.g.: user running the Tomcat process)
- INSTALL_DIR: The path of the base folder where OTDS will put its data. That will include the OTDS config folder (with “otds.properties”) and the different application files (WEB-INF, META-INF and other jsp/js/html files). When installing OTDS like that, there won’t be any WAR files deployed on the webapps folder of Tomcat. The WAR content will be exploded/extracted and available in this INSTALL_DIR location and Tomcat will run these web applications by loading their “Context” inside the $CATALINA_HOME/conf/Catalina/localhost/otds*.xml files
- TOMCAT_DIR: The path of the Tomcat install base, which is usually $CATALINA_HOME
- PRIMARY_FQDN: The Fully Qualified Domain Name of the local host. Even if it says Primary, in case of replicated setup, you can set the local host only, as the HA setup is handled by the DB itself in recent versions of OTDS (without OpenDJ)
- ISREPLICA_TOPOLOGY: A value of “0” indicates the installation to be done is a Primary and a value of “1” is for a replica
- IMPORT_DATA: A value of “0” indicates to NOT import any data (from a previous OTDS version on OpenDJ (and not a Database)) and a value of “1” will ask you further questions about the OpenDJ URL and password to be used
- OTDS_PASS: Password to be defined for the OTDS admin account. Only asked if it’s for a Primary initial installation (i.e. no previous local install, not a replica and no previous import)
- ENCRYPTION_KEY: Specify the Data Encryption Key that was used for this environment. Only asked if there is no local install and if it’s a replica or a primary that requires an import. The value to be used here (e.g. in case of replica install) can be found on the Primary installation as the property “directory.bootstrap.CryptSecret” of the OTDS config file ($INSTALL_DIR/config/otds.properties)
- MIGRATION_OPENDJ_URL: OpenDJ URL to be used to connect to previous version of OTDS in case import is required on a primary installation
- MIGRATION_OPENDJ_PASSWORD: OpenDJ password to be used to connect to previous version of OTDS in case import is required on a primary installation
- JDBC_CONNECTION_STRING: Database JDBC Connection String to be used to connect to the OTDS Database
- JDBC_USERNAME: Database username to be used to connect to the OTDS Database
- JDBC_PASSWORD: Database password to be used to connect to the OTDS Database
Most parameters are only needed for a fresh local installation and further upgrades will re-use initial properties.
IV. Execution
Once the properties file is ready, you can install the OTDS in silent using the following command:
[tomcat@otds_01 ~]$ /opt/workspace/setup -qbi -rf /tmp/otds_silent.properties
OpenText Directory Services 24.4.0
------------------------------------------------------------------------------
OpenText Directory Services
------------------------------------------------------------------------------
Installing OpenText Directory Services Component
Please wait .
Installation of OpenText Directory Services Component OK
Installation completed. Results:
OpenText Directory Services Component OK
Installation finished.
[tomcat@otds_01 ~]$
You now know how to do a silent install of OTDS, but that’s only the tip of the iceberg. The next step is then to configure it, as you will need to create the user partitions (synchronized or not), passwords policies, resources, access roles, etc. If you are already familiar with the OTDS, then you can automate the configuration pieces using the REST-API, but that won’t be covered in this blog.