Installing and Configuring the Software Services Director

Introduction

To install and configure a software form-factor Services Director, follow the instructions in the following sections:

Prerequisites.

Configuring the MySQL Database for the Services Director.

Either refer to Installing and Configuring the Services Director on Ubuntu or Installing and Configuring the Services Director on RHEL/CentOS.

Installing the Services Director Software License.

To install an externally-deployed Traffic Manager with minimal supporting resources, refer to Adding Resources Using the REST API.

Starting and Stopping the Services Director.

To add user authentication to your Services Director (either vTM user authentication or Services Director user authentication), you will need to:

Review the user authentication material in the Services Director Getting Started Guide.

Create any required authenticators, refer to authenticator Resource.

Create any required permission groups, refer to permission_group Resource.

Create any required access profiles (vTM user authentication only), refer to access_profile Resource.

If you want to install and configure a Services Director Virtual Appliance (VA), see the Services Director Getting Started Guide.

Prerequisites

The Services Director supports the following:

Operating system: Ubuntu 18.04 (x86_64), RHEL/CentOS 6 (x86_64)

Ivanti recommends that the Services Director machines and any instance hosts all use either Ubuntu or RHEL/CentOS.

Database: MySQL 5.7

Required Linux Packages

Make sure the following Linux packages are installed before you start the installation process. The packages differ according to the operating system you are using.

Ubuntu 18.04 (64 bit)	RHEL/CentOS 6 (64 bit)
mysql-common	mysql
libmysqlclient20	glibc-devel (v2.12 or later)
mysql-client-5.7 and mysql-client-core-5.7	Python Argparse (required for an instance host)
OpenSSL (latest version for OS)	OpenSSL (latest version for OS)
libldap (v2.4 or later)	openldap (v2.4 or later)

The latest version of OpenSSL is essential for security purposes.

You must install and configure all software, including the Services Director, as superuser or a user account with administrator or equivalent access permissions.

Hardware Requirements

The Services Director requires the following hardware.

Hardware	Requirement
CPU	Intel Xeon / AMD Opteron
Minimum Memory	2 GB
Minimum Disk Space	10 GB (plus additional disk space for metering logs depending on number of instances metered)

Software and License Requirements

To install the Services Director, you need the following software and licenses:

MySQL Database Server - The Services Director uses a MySQL database to store inventory data and other items relating to the deployment of your Traffic Manager instances. You must install and configure MySQL on your required platform. This must be accessible to Services Director using the configured credentials at the host and port specified. Consult the MySQL documentation for your platform to do this.

Mail Server - The Services Director uses email to alert you of certain error conditions (for example, running low on log disk space). You must set up and provide SMTP mail server connection details to the Services Director for correct operation. The Services Director does not support SMTP connections that require authentication.

Services Director Licenses - Before starting the first Services Director in a cluster of Services Directors, you must place a valid license key file in the INSTALLROOT/licenses directory. New licenses are automatically added to the database as they are discovered. The Services Director license is automatically copied to the inventory database after communication is established. A newly installed Services Director instance that is configured to use an existing inventory database containing valid license keys uses those keys to operate after it has started.

Ivanti recommends that you install all subsequent Services Director licenses via the REST API’s controller_license_key resource. For details, see controller_license Resource.

Required Services Director Files

To install the Services Director, you need the following files:

SSL Certificate/Key - The SSL certificate and key are used by the Services Director REST API to enable authentication of the Service Controller when it is being accessed by remote clients. An important client is the Traffic Manager FLA license, which requires that you generate a self-signed SSL certificate and key (or equivalent compatible certificate and key).

You must place these files on an accessible location in your infrastructure. For details, see Generating a Self-Signed SSL Server Certificate.

Required Traffic Manager Files

The Services Director requires a set of external Traffic Manager files to deploy Traffic Manager instances:

Traffic Manager Image - The Traffic Manager image (that is, its tarball file) is required to create Traffic Manager instances in the Services Director.

You must place this in the Source File Location that you provide when you install the Services Director.

Traffic Manager FLA License - The Traffic Manager FLA license is required to create instances in the Services Director.

You must place this in the Source File Location that you provide when you install the Services Director.

These external files are not part of the initial Services Director installation. You might require different versions of the Traffic Manager, and the license files are customized for each Services Director deployment in conjunction with your support provider.

You use the Services Director REST API to create an inventory of resources for the Traffic Manager image and its license files. The REST API does not import the actual files and does not, by default, verify that the files are present. For detailed information about checking the status of REST API resources, see Using the REST API to Check Status.

Services Director User Types

Within the Services Director, there are these types of users:

MySQL Database User - When you create the inventory database required by the Services Director, you create a MySQL user that has access to the database. Ivanti recommends you create a specific Services Director user rather than using the database root user. You supply the name and password of this user when you install the Services Director so that it can access the database that you have pre-created. These credentials are recorded in the Services Director configuration file. See Configuring the MySQL Database for the Services Director.

The Services Director Linux User - The Services Director software is run under a Linux user account. By default, this is the root user.

The Services Director REST API User - To make Services Director REST API requests you must specify credentials for an admin user. This user is stored within the Services Director inventory database. You can create additional Services Director users or change the password using the REST API.

Traffic Manager Instance Host User - When the Services Director carries out actions on its designated instance host, it does so by means of passwordless SSH access. You must create these users and provide credentials so that the Services Director can communicate with each instance host. Typically, you create this user as root, although you can specify in the REST API resource the name of the user for each host.

Traffic Manager Admin and Service Users - see Users in Deployed Traffic Manager Instances and Users in Externally-Deployed Traffic Manager Instances.

Users in Deployed Traffic Manager Instances

When you deploy a Traffic Manager instance, the Services Director creates two default user accounts within the instance:

admin - The administrative user for this instance, with full access to all features and capabilities.

service - The service user, with privileges restricted to those required for service creation and management. That is, no system wide privileges.

You can change the password for each of these user accounts by updating the relevant password property in the instance resource.

Ivanti strongly recommends that you do not provide admin user credentials to end-tenant users. You can safely provide the service user credentials, provided that the privileges for this account have not been altered from their default settings.

Users in Externally-Deployed Traffic Manager Instances

When you register an Externally-deployed Traffic Manager instance with the Services Director, it is not mandatory for the user to supply service user credentials.

Ivanti recommends that you specify a username and password for an existing admin user when deploying an externally-deployed instance. This admin user (and a specified rest_address ) for the instance resource enables monitoring of the externally-deployed instance, and provides access to its REST API proxy.

Ivanti strongly recommends that you do not provide admin user credentials to end-tenant users.

Required Configuration Parameters

The Services Director installation prompts you to provide values for parameters used in setting up the software. Make sure you have access to all required information before you start the installation process.

The following table lists the required parameters to install the Services Director.

Parameter	Description
Database Host	The hostname or IP address of the server running the MySQL database server.
Database Port	The port number of the server running the MySQL database server.
Database Name	The name of the MySQL database used as the inventory database.
Database User	The name of a MySQL user authorized to use the inventory database. This username, along with the corresponding password, is used internally by the Services Director to access the MySQL database.
Database User Password	The password of the MySQL user. This password is used internally by the Services Director to access the MySQL database.
API Server Port	The number of the port on which the Services Director listens for REST API requests.
SSL Certificate File	The full path and filename of the certificate file to use for HTTPS connections to the REST API.
SSL Private Key File	The full path and filename of the private key file to use for HTTPS connections to the REST API.
Client Request Thread Pool Size	The maximum number of threads used for Services Director REST requests. This parameter limits the number of possible simultaneous HTTP requests.
Action Thread Pool Size	The maximum number of threads used for actions such as deploying, starting, and stopping Traffic Manager instances. Ivanti recommends that you set Action Thread Pool Size and Monitor Thread Pool Size such that the sum of both is no greater than the MySQL maximum connections limit. If you have other applications that query the same MySQL database, you must make allowances for these additional connection requirements in your calculations.
Monitor Thread Pool Size	The maximum number of threads used to monitor Traffic Manager instances and other Services Directors. If you experience warnings about overdue monitoring actions, increase this value. Ivanti recommends that you set Action Thread Pool Size and Monitor Thread Pool Size such that the sum of both is no greater than the MySQL maximum connections limit. If you have other applications that query the same MySQL database, you must make allowances for these additional connection requirements in your calculations.
Source File Location	The name of a directory accessible by the Services Director in which the Traffic Manager image and license files are placed.
Log Output Location	The name of a directory accessible by the Services Director server in which log files and metering log files are placed.
Alert Message Email Addresses	A list of one or more email addresses to which warnings are sent in case of problems. You can also configure the "From" e-mail address of alert e-mails. This address can be set in INSTALLROOT/conf/email_config.txt , in the common section, as from_address. The symbol "$fqdn" will be replaced by the fully-qualified domain name of the instance host, or an IP address where Universal Licensing is used. The other sections in this file should not normally be modified. For Services Director installs on AWS it is likely that you will need to change this setting to be an address that is resolvable to the instance's public IP.
SMTP Relay Host	The hostname or IP address of the SMTP server used to send warnings.
SMTP Relay Port	The port number of the SMTP server used to send warnings.

You must configure the hostname of each Services Director server in your local DNS settings so that all Traffic Manager instances can correctly resolve the addresses of all Services Director servers.

Configuring the MySQL Database for the Services Director

These instructions assume you have already installed the MySQL server. For detailed instructions on installing the MySQL server, see the MySQL documentation for your platform.

You must create an empty MySQL database with an associated user account for use with the Services Director.

The Services Director requires information about the MySQL database during the installation process. Ivanti recommends that you note the database name and the username and password before you start the installation process. For detail information about required installation parameters, see Required Configuration Parameters.

You can install the database on the same host as the Services Director if required.

You must configure the privilege settings for the MySQL user account to allow access to the database from all IP addresses (or at a minimum the IP addresses of the machines on which you install the Services Director).

To Create a MySQL Database with Access to all IP Addresses

To create a MySQL database named (for example) ssc with a user named (for example) ssc , execute the following SQL commands:

CREATE DATABASE ssc;
CREATE USER 'ssc'@'localhost' IDENTIFIED BY '<YOUR PW>';
GRANT ALL ON ssc.* TO 'ssc'@'%' IDENTIFIED BY '<YOUR PW>' \
WITH GRANT OPTION;
FLUSH PRIVILEGES;

Exit the MySQL monitor program.

Configuring the MySQL Database for Remote Availability

To allow two Services Directors to be placed in a cluster of Services Directors, the MySQL database must be set up to allow remote access. An example outlining one approach is below.

To Allow Database Access from a Remote IP Address on Ubuntu

Open the my.cnf configuration file (for example: /etc/mysql/my.cnf ) in any text editor.

Set the option bind-address to the public IP address of the MySQL server

Close and save the file.

Restart the MySQL daemon, at the system prompt, enter:

$ service mysql restart

To Allow Database Access from a Remote IP Address on RHEL/CentOS

Open the my.cnf configuration file (for example: /etc/mysql/my.cnf ) in any text editor.

Set the option bind-address to the public IP address of the MySQL server

Close and save the file.

Restart the MySQL daemon, at the system prompt, enter:

$ service mysqld restart

Installing and Configuring the Services Director on Ubuntu

For Ubuntu hosts, the Services Director software is provided in the form of a Debian package.

For Ubuntu installations using Linux Containers (LXC), Ivanti recommends LXC v0.7.5.

recommends that the Services Director machines and any instance hosts all use either Ubuntu or RHEL/CentOS.

recommends that you plan your LXC container deployment strategy before installing the Services Director to ensure adequate system resource availability. For more information about LXC, see the configuration and management instructions supplied with your Linux distribution.

To Install the Services Director on Ubuntu

As super user, use the standard dpkg command to install the Services Director. At the system prompt, enter:

$ dpkg -i services-director_19.1_amd64.deb

You are prompted for several configuration parameters. For detailed information, see Required Configuration Parameters.

In the event of a failure that leaves the package in a half-installed state, restart the process as follows:

$ dpkg -P --force-all riverbed-ssc

To initialize the software, execute the configuration script. At the system prompt, enter:

$ /opt/riverbed_ssc_19.1/bin/configure_ssc –liveconfigonly

You are prompted for the REST API administrative username and password. This login is the administrative user for the Services Director REST API using HTTP authorization. The configuration script validates whether you have configured all the required directories. The script also populates the contents of the Services Director database.

The initial installation is complete. You can change the configuration parameters after the initial installation by re-running the configuration script.

To Change the Configuration Parameters

At the system prompt, enter:

$ configure_ssc

For your changes to take effect, restart the Services Director. At the system prompt, enter:

$ service ssc stop
$ service ssc start

To Re-Enter Configuration Parameters

At the system prompt, enter:

$ dpkg-reconfigure riverbed-ssc

Login Settings

You can view and modify login settings for the Services Director in the /api/tmcm/2.9/settings/security resource. For details, see Using the ServURI Root Partsices Director REST API.

You set login settings for the Services Director as follows:

max_login_attempts - The maximum number of failed Services Director login attempts for a user. This has a default of zero, which indicates that there is no maximum.

user_lockout_duration_minutes - A suspension lockout duration (in minutes). If the max_login_attempts threshold limit is reached, the suspension duration lockout is applied. This has a default of 1 minute, and a maximum of 1440 minutes (equal to one day).

Installing and Configuring the Services Director on RHEL/CentOS

For an RHEL/CentOS host, the Services Director software is provided as an RPM package.

For RHEL/CentOS installations using Linux Containers (LXC), Ivanti recommends LXC v0.7.5.

recommends that the Services Director machines and any instance hosts all use either Ubuntu or RHEL/CentOS.

By default, RHEL/CentOS has more restrictive iptables rules than Ubuntu. These iptables rules must be amended to enable access to Services Directors and Instance Hosts, either on all or selected ports. For example, to configure an ssh port for an Instance Host.

To Install the Services Director on RHEL/CentOS

If it is not already installed, install the GNU C Library. At the system prompt, enter:

$ yum install glibc-devel

At the system prompt, enter:

$ rpm -i services-director-19.1-0.x86_64.rpm

After installation, configure the Services Director software using the configuration script. At the system prompt, enter:

$ /opt/riverbed-ssc/bin/configure_ssc

You are prompted for several configuration parameters. For detailed information, see Required Configuration Parameters.

To Change the Configuration Parameters

To change configuration parameters after the initial installation, at the system prompt, enter:

$ /opt/riverbed-ssc/bin/configure_ssc

For your changes to take effect, restart the Services Director. At the system prompt, enter:

$ service stop ssc
$ service start ssc

Configuring a RHEL/CentOS Instance Host

For a RHEL/CentOS instance host, since the default Python version is 2.6, you must install the Python Argparse module.

On a Services Director instance host, enter:

$ yum install python-setuptools
$ easy_install argparse

Login Settings

You can view and modify login settings for the Services Director in the /api/tmcm/2.9/settings/security resource. For details, see Using the ServURI Root Partsices Director REST API.

You set login settings for the Services Director as follows:

max_login_attempts - The maximum number of failed Services Director login attempts for a user. This has a default of zero, which indicates that there is no maximum.

user_lockout_duration_minutes - A suspension lockout duration (in minutes). If the max_login_attempts threshold limit is reached, the suspension duration lockout is applied. This has a default of 1 minute, and a maximum of 1440 minutes (equal to one day).

Installing the Services Director Software License

Your license file must be readable by the Services Director Linux user. For detailed information about Services Director licenses, see Managing Services Director Licensing.

To Install the Services Director License for the First Services Director

Place the licenses on an accessible location in your infrastructure. For details about obtaining your license keys, see Retrieving Ivanti vTM and Services Director Product Licenses.

Copy a Services Director license file containing the license key to the INSTALLROOT/licenses directory. The Services Director scans the directory for changes at start up and at daily intervals. New licenses are automatically added to the database as they are discovered.

To confirm that you have correctly installed your license, run the Services Director software manually. Any problems with the license will result in error messages being displayed on the command line. For detailed information about running the Services Director manually, see Starting and Stopping the Services Director.

If the Services Director shuts down due to a licensing failure, the start and end dates of any decoded licenses are added as a warning to the event log.

To Install Services Director Licenses Once the First Services Director is Running

After you have installed your licenses and started the Services Director for the first time, you can use the REST API to update existing licenses and install new licenses.

POST /api/tmcm/2.9/controller_license_key HTTP/1.1 XX1-RSSC123456-3E33-3E3A-5-0123-4567-89AB

Creating Licensing Reports

The licensing decode tool (license_decode ) produces a detailed report for all your license keys, including invalid ones. The license decode tool is part of the Services Director installation package; it is stored under the INSTALLROOT/bin/ directory.

Invalid license keys might be malformed or might have a dependency on a missing Services Director license key. For license keys listed as invalid, verify that the associated Services Director license key is present.

To create a licensing report, enter the following command at the prompt:

$ license_decode <KEY1> <KEY2> <KEY3>

You can decode multiple license keys by specifying each one in a space-separated argument list.

Adding Resources Using the REST API

For a minimal installation of Services Director with one or more externally-deployed Virtual Traffic Manager (vTM) instances, you must add a Feature Pack resource and an Owner resource to the Services Director, and then start adding vTMs.

The section that follows describes a basic installation of Feature Pack, Owner and vTM instance resources, based on the following assumptions:

The Services Director is licensed and running.

You are using Universal licensing for your vTM instances.

You are using externally-deployed vTM instances, each of which has an enabled REST API.

You are using standard ports for all operations. That is, 9090 for GUI, 9070 for REST, 161 for SNMP, and so on.

You are not using instance-level authentication.

For a more detailed explanation of vTM deployment, refer to Registering Externally-Deployed Traffic Managers.

The examples in this section use CURL statements, but these can be adapted to suit your preferred way of accessing the REST API.

Create a Feature Pack using the REST API. For example:

$ curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u admin:password -d '{"stm_sku":"STM-300","excluded":""}' https://localhost:8100/api/tmcm/2.9/feature_pack/STM_300_FP

In this example, a Feature Pack called "STM_300_FP" is created. This makes use of the "STM-300" SKU, excluding no features. For details of Feature Pack resources, refer to feature_pack Resource.

When this command completes, a result is displayed. For example:

{"info": "", "status": "Active", "stm_sku": "STM-300", "add_on_skus": [], "excluded": ""}

You may need to create additional Feature Packs for different vTM instances.

Create an Owner resource using the REST API. For example:

$ curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u admin:password -X POST -d '{"tag":"MegaCorp"}' https://localhost:8100/api/tmcm/2.9/owner/

In this example, an Owner called "MegaCorp" is created. For details of Owner resources, refer to owner Resource.

When this command completes, a result is displayed. For example:

{"instances": [], "secret": "tt6YHDgj", "tag": "MegaCorp", "clusters": [], "timezone": "Etc/UTC", "email_address": "", "owner_id": "Owner-BILV-LIKP-UOL2-DKFV"}

You may need to create additional Owners for different vTM instances.

Register an externally-deployed vTM instance ("vtm-01.cam.demo.com" in this example) with a POST request. This uses the "STM_300_FP" Feature Pack from step 1:

$ curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u admin:password -X POST -d '{"status":"Active","stm_feature_pack":"STM_300_FP","owner":"MegaCorp","management_address":"vtm-01.cam.demo.com","bandwidth":1000,"rest_enabled":true, "admin_username":"admin","admin_password":"password","tag":"MyRegisteredVTM"}' https://localhost:8100/api/tmcm/2.9/instance?managed=false

In this example, the instance is Active, and has its REST API enabled. For details of instance resources, refer to instance Resource.

When this command completes, a result is displayed. For example:

{"status": "Active", "config_options": "", "managed": false, "cpu_usage": "", "license_name": "universal_v4", "rest_address": "vtm-01.cam.demo.com:9070", "container_configuration_json": {}, "snmp_address": "vtm-01.cam.demo.com:161", "creation_date": "2016-11-30 15:06:43", "bandwidth": 1000,"tag": "MyRegisteredVTM", "cluster_id": "Cluster-RUZX-APUA-9XUF-9DXH", "container_name": "", "owner": "Owner-BILV-LIKP-UOL2-DKFV", "service_username": "", "service_password": "", "config_options_json": {},"admin_username": "admin", "instance_id": "Instance-HBBH-57JR-MHG0-60UL", "stm_feature_pack": "STM_300_FP","stm_version": "", "host_name": "", "management_address": "vtm-01.cam.demo.com", "container_configuration": "","rest_enabled": true, "ui_address": "vtm-01.cam.demo.com:9090", "admin_password": "password"}

The cluster property is the retrieved cluster ID of the vTM. The owner property is set to the ID of the Owner resource rather than its tag.

The instance will have a license installed and will begin making licensing requests.

(Optional) Check the license for the instance at any point with the REST API. You can use either the instance's ID or tag. For example:

$ curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u admin:password https://localhost:8100/api/tmcm/2.9/instance/Instance-HBBH-57JR-MHG0-60UL

$ curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u admin:password https://localhost:8100/api/tmcm/2.9/instance/MyRegisteredVTM

(Optional) Extract the monitoring information for the instance at any point with the REST API. You can use either the instance's ID or tag. For example:

$ curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u admin:password https://localhost:8100/api/tmcm/2.9/monitoring/instance/Instance-HBBH-57JR-MHG0-60UL

$ curl -k --basic -H "Content-Type: application/json" -H "Accept: application/json" -u admin:password https://localhost:8100/api/tmcm/2.9/monitoring/instance/MyRegisteredVTM

Starting and Stopping the Services Director

You must select the appropriate method of running the Services Director depending on the status of your Services Director installation:

Manual - If you are running the Services Director for the first time or if you are having problems with your Services Director at start up, run the Services Director manually to see additional diagnostic messages on the command line.

Systemd - For an established and normally operating Services Director installation, run the Services Director as a systemd service.

Manually Starting the Services Director Software

At the prompt, enter:

$ run_ssc_server [-v/--version]

-v or --version - Displays the current version and build number of the Services Director software, but does not start the server.

Manually starting the Services Director provides output and startup messages that you can use to identify and resolve Services Director system configuration issues.

To perform a controlled shutdown of the Services Director from this state, you must press Ctrl+C.

Starting the Services Director as a Service (Normal Operation)

At the prompt, enter:

$ service start ssc

Stopping the Services Director Running as an Upstart Service

At the prompt, enter:

$ service stop ssc

Upgrading the Services Director on Ubuntu

For Ubuntu hosts, the Services Director software is provided in the form of a Debian package.

You can upgrade the Services Director software using the following procedure.

This procedure causes a loss of service from your Services Director deployment, although you should schedule the upgrade for a time of least interruption to your end users.

Earlier versions of the Services Director used an environment variable called $SSCHOME to refer to the software installation directory. This is now deprecated. Before upgrading the Services Director to the latest version, you must make sure that this variable is unset.

To support the encryption of stored passwords for Traffic Manager instances, Services Director encrypts passwords during the upgrade of the Virtual Appliance. A default master password of master1M@ is used to do this. It is strongly recommended that you update the master password after an upgrade. For a software install, this step is performed automatically after the package upgrade when configure_ssc --liveconfigonly is performed. This command prompts you to replace the default master password.

At the prompt, enter:

$ dpkg -i services-director_19.1_amd64.deb

This stops the Services Director software but does not restart it.

Ensure that the INSTALLROOT/licenses directory contains the correct license files, including any licenses for Bandwidth Packs.

At the prompt, enter:

$ /opt/riverbed_ssc_19.1/bin/configure_ssc --liveconfigonly

This command makes backward-compatible changes to the Services Director database, and prompts you to replace the default master password master1M@ that was assigned during the upgrade.

At the prompt, enter:

$ service start ssc

Confirm that the Services Director has not shut down due to licensing issues and that the software has started by issuing a GET request via the Services Director REST API.

Upgrading the Services Director on RHEL/CentOS

For an RHEL/CentOS host, the Services Director software is provided as an RPM package. For RHEL/CentOS installations using Linux Containers (LXC), Ivanti recommends LXC v0.7.5.

You can upgrade the Services Director software using the following procedure.

This procedure causes a loss of service from your Services Director deployment, although you should schedule the upgrade for a time of least interruption to your end users.

To support the encryption of stored passwords for Traffic Manager instances, Services Director encrypts passwords during the upgrade of the Virtual Appliance. A default master password of master1M@ is used to do this. It is strongly recommended that you update the master password after an upgrade. For a software install, this step is performed automatically after the package upgrade when configure_ssc is performed. This command prompts you to replace the default master password.

At the prompt, enter:

$ rpm -U services-director-19.1-0.x86_64.rpm

This stops the Services Director software but does not restart it.

Make sure the INSTALLROOT/licenses directory contains the correct license files, including any licenses for Bandwidth Packs.

At the prompt, enter:

$ /opt/riverbed-ssc/bin/configure_ssc

This command makes backward-compatible changes to the Services Director database, and prompts you to replace the default master password (master1M@ ) that was assigned during the upgrade.

At the prompt, enter:

$ service start ssc

To confirm that the Services Director has not shut down due to licensing issues and that the software has started by issuing a GET request via the Services Director REST API.

Upgrading Clustered Services Directors

Part of the upgrade process for a Services Director is to apply changes to the inventory database schema, in order to support additional features in newer versions. Since clustered Services Directors share the same inventory database, upgrades of these clustered Services Directors must be carefully sequenced to ensure that:

inventory records are not locked during the upgrade of the database schema, as this will cause the upgrade to fail.

once the database schema has been upgraded, changes made to the inventory by remaining pre-upgrade Services Directors are avoided.

To support these goals, it is recommended that the following sequence is used:

Before starting the upgrade, select one Services Director in your Services Director cluster as the upgrade master. This Services Director will be upgraded first and will be responsible for applying changes to the database schema.

Stop the other Services Director in the Services Director cluster.

Upgrade the upgrade master as instructed in Upgrading the Services Director on Ubuntu, and restart this Services Director once the upgrade is complete.

Deactivation of the upgrade master Services Director may cause instances to briefly enter the licensing grace period (six weeks), but they will return to normal operation once the upgrade master is restarted.

Upgrade the second Services Director in the cluster as instructed in Upgrading the Services Director on Ubuntu, and restart this Services Director once the upgrade is complete.

Repeat step 4 until all clustered Services Directors are upgraded.

Downgrading the Services Director on Ubuntu

For Ubuntu hosts, the Services Director software is provided in the form of a Debian package.

To revert to the previous software version in a cluster of Services Directors, follow this procedure on all Services Directors in turn.

At the prompt, enter:

$ service stop ssc

At the prompt, enter:

$ dpkg --force-downgrade -i services-director_18.2_amd64.deb

--force-downgrade - Downgrades to the desired software version. In this example, version 18.2. This includes a database schema downgrade.

Make sure that the INSTALLROOT/licenses directory in your downgraded software installation contain the required license keys compatible with the downgraded version of the Services Director.

At the prompt, enter:

$ sudo INSTALLROOT/bin/configure_ssc --liveconfigonly

At the prompt, enter:

$ service start ssc

Downgrading the Services Director on RHEL/CentOS

For an RHEL/CentOS host, the Services Director software is provided as an RPM package. For RHEL/CentOS installations using Linux Containers (LXC), Ivanti recommends LXC v0.7.5.

To revert to the previous software version in a cluster of Services Directors, follow this procedure on all Services Directors in turn.

At the prompt, enter:

$ service stop ssc

If you intend to revert to version 2.4 or earlier, enter the following command:

Do not use this command if you intend to revert to version 2.5 or later.

$ /opt/riverbed-ssc/bin/configure_ssc --liveconfigonly --to_version=2.1

--to_version=2.1 - Specifies the downgrade version. In this example, version 2.1. This includes a database schema downgrade.

You will be asked if you want to add another REST API user. You can add a user, but this is not needed for the downgrade process.

For all versions, enter:

$ rpm -U --oldpackage riverbed-ssc-2.1-0.x86_64.rpm

--oldpackage - Downgrades to the desired software version. In this example, 2.1.

Make sure that the INSTALLROOT/licenses directory in your downgraded software installation contain the required license keys compatible with the downgraded version of the Services Director.

At the prompt, enter:

$ sudo INSTALLROOT/bin/configure_ssc --liveconfigonly

At the prompt, enter:

$ service start ssc