Cloud Data Manager

Cohesity Deployment

The Model 9 Cloud Data Manager on Cohesity Marketplace documentation


Step 1: Obtain a license key

Open a license request in the Model9 service portal.

The output of the z/OS command “D M=CPU” is required.

Step 2: Download the Model9 files

Create an NFS Cohesity view

The Model9 configuration and meta-data files should reside on a Cohesity view, defined as NFS only.

The name of this view must be set to model9home (case sensitive).

Mount the NFS

Mount the nfs share on a Linux machine and configure initial settings:

# Change user to root
sudo su -
# Mount the model9home cohesity view
mkdir -p /data/model9/nfs
mount cohesity.ip.addr:/model9home /data/model9/nfs/
# Set the model9 target installation path
export MODEL9_HOME=/data/model9/nfs

Upload the Cohesity zip installation file to the nfs share mount point (for example: /data/model9/nfs) in binary mode:

Unzip the installation file

Use a linux server to mount the newly created view and unzip the uploaded installation zip file:

# Change user to root
sudo su -
# Change the directory to $MODEL9_HOME
# Unzip the server’s installation file, on Linux issue:
Optional: Replace the default self-signed certificate

The base installation provides a self-signed certificate for encrypting access to the Model9 user interface. See Generate a self-signed certificate on how to replace the default certificate for the WEB UI. Communications between the Model9 Server and the Model9 Agent are encrypted by default and further action should only be taken if site certificates are preferred.

Step 3: Edit the parameters file

The model9-local.yml file residing in the $MODEL9_HOME/conf/ path contains some of the default parameters. The main section is model9 (lower-case) and all parameters must be indented under the model9 title. Only hard spaces can be used to indent the hierarchies within the parameter file.

    licenseKey: null
        name: "<ip_address>"
        port: <port>
# model9-data
#  s3
            api.s3.v4signatures: true
#           no.verify.ssl: true
            url: https://cohesity:3000
            userid: <object store access key>
            password: <object store secret>
# The dataSource tag should start from first column and not under model9 tag
    user: postgres
    password: model9
    url: jdbc:postgresql://





A valid Model9 license key as obtained in the prerequisites section. When using multiple keys for multiple CPCs, specify one of the keys in the server’s yml file. The server-initiated actions are carried out by the agent using its own defined license. The license key specified for the server is used for displaying a message regarding the upcoming expiration of the license



The agent running on z/OS which verifies the UI login credentials, hostname, IP address and port number. Specifying a distributed virtual IP address (Distributed VIPA) can provide high availability by allowing the use of agent groups and multiple agents. See the Administrator and User Guide for more details.


Container/bucket name



URL address of local or remote object storage, both HTTP and HTTPS** are supported



Access key to object storage



Secret key to object storage


The object storage api name. Default: s3



Set this parameter to true in addition to specifying s3.



when using the https protocol, whether to avoid ssl certificate verifications. Using HTTPS for the object storage URL parameter enables Data-in-Flight encryption. Default: true



Update the postgresql address to point to localhost (i.e.


Step 4: Edit the environment configuration file

The file residing in the $MODEL9_HOME/conf/ path contains some of the default parameters.

Update the timezone setting according to the server location.

Step 5: Start the Model9 management server

Go to the Apps section in the Cohesity UI, and click on the Run App button located next to the loaded application:


Grant permission to access the NFS view created for Model9 (The view name is model9home).


Click on Run App to start the application.

Generate a self-signed certificate


This step is optional

The default Model9 installation provides a self-signed web certificate. This certificate is used to encrypt the web information passed between your browser and the Model9 management server.

It is strongly recommended to generate a site-defined certificate to accommodate production-level workloads. Contact your security administrator if you wish to generate such a certificate.

You can also generate your own self-signed certificate to avoid browser security notifications.

Verify the server has a valid hostname

Issue the following command:

hostname -s
Generate self-signed keys

Issue the following commands. The parameters are described below:

cd $MODEL9_HOME/keys
keytool -genkey -alias tomcat -keystore $(hostname -s)_web_self_signed_keystore.p12 -storetype pkcs12 -storepass <password> -keyalg RSA -ext SAN=dns:<server_dns>,ip:<server_ip> -dname "cn=<BackupServer>, ou=Java, o=Model9, c=IL" -validity 3650
chown root:root $(hostname -s)_web_self_signed_keystore.p12
chmod 600 $(hostname -s)_web_self_signed_keystore.p12
keytool -exportcert  -alias tomcat -keystore $(hostname -s)_web_self_signed_keystore.p12 -storetype pkcs12 -storepass <password> -file $(hostname -s)_web_self_signed.cer

Edit the following parameters:




The keystore password


The server DNS name (optional)


The server IP address


The certificate common name: edit according to site standards

When not specifying <server_dns> remove the dns: section from the command.

Update your workstation

Add the exported certificate (.cer file) to your local workstation trusted CA according to site standards and security policies.

Update the server

If a site certificate or new self-signed certificate was created, update the server configuration file by adding the following line:

vi $MODEL9_HOME/conf/connectorHttpsModel9.xml

Update the keystoreFile, keystorePass, keyAlias and keyPass settings to match the information provided by the security administrator, as shown in the following example:

<Connector port="443" protocol="org.apache.coyote.http11.Http11Protocol"
     maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
     keystoreType="PKCS12" keystorePass="changeit" keyAlias="tomcat"
     clientAuth="false" sslProtocol="TLS" />

Java strictly follows the HTTPS specification for server identity (RFC 2818, Section 3.1) and IP address verification. When using a host name, it is possible to fall back to the Common Name in the Subject DN of the server certificate instead of using the Subject Alternative Name. However, when using an IP address, there must be a Subject Alternative Name entry - IP address, not a DNS name - in the certificate.