Creating a Backup Connection Using the Secure Client

The Secure Client is a proxy server that you need to set up and run to backup data to HPE Cloud Backup. You can download the Secure Client by clicking Download Secure Client in the Backup Stores window.

The Secure Client is packaged as a ZIP file that consists of the following files:

  • The Secure Client binary.
  • A YAML configuration file for the client
  • A certificate for use by the client
  • The private key for the certificate
  • The Certificate Authority (CA) for the certificate
  • A Readme file.
  • A license agreement file

Prerequisites

The following are the prerequisites for running the Secure Client.

  • Any Linux OS running in a physical or virtual machine
  • A 2.0GHz CPU with 4 Cores (minimum)
  • 8 GB of RAM (minimum)

If multiple client processes are being run on the same machine, ensure that each instance has a dedicated IP address. Reuse of IP addresses between clients is not supported as reusing IPs will cause problems during backups. A secure client can use multiple IP addresses in cases where the secure client needs to be accessible from multiple locations.

Make sure that you increase memory and CPU resources if you are running multiple clients on the same machine and that configuration files, certificates and private keys are not re-used between different clients. To avoid confusion, it is recommended that you store each secure client and associated files in separate folders and that you provide each with a meaningful name, such as the name of the backup store.

Setting Up the Secure Client

To set up the Secure Client, complete the following steps:

  1. Download the Secure Client Zip from HPE CV Backup if you have not already done so.
  2. Extract the following files from the ZIP:
    • The client binary.
    • The client configuration file.
    • The certificate file.
    • The private key file
    • The CA file
  3. Create a new user to run the secure client by running the following command:

    sudo useradd secureclient
    

    The client should not be run as the root user.

  4. Ensure the files have the following file permissions set. To do this, run the following command:

    sudo chmod MODE FILE
    

    where FILE is the path to the file being altered.

    • Client binary: 755

    • Client configuration file: 644

    • Client certificate: 644

    • CA file: 644

    • Private key: 600

  5. Using chown, change the ownership of the following files to the user created in step 3. To do this, run the following command:

    sudo chown secureclient:secureclient FILE
    

    where FILE is the path to the file being altered.

    • Client binary

    • Client configuration file

    • Client certificate

    • CA file

    • Private Key

  6. Place the client binary, configuration, certificate, CA and private key in a dedicated folder owned by the user created in step 3. To do this, run the following command:

    sudo mkdir -p /opt/cloudvolumes
    

    followed by:

    sudo chown -R secureclient:secureclient /opt/cloudvolumes
    
  7. Ensure ports 9386, 9387 and 9388 are open in your firewall using a tool such as nmap.

You can run the client using an init system, such as systemd. If using an init system, ensure that the process will be restarted on exit. The following example systemd service can be created as /etc/systemd/system/secure-client.service".

Example systemd service:

[Unit]
Description=HPE CloudVolumes Backup service client
After=network.target

[Service]
User=secureclient
Type=exec
ExecStart=/opt/cloudvolumes/secure_client --config /opt/cloudvolumes/secure_client_config.yaml
Restart=always
RestartSec=10s
LimitNOFILE=40000

[Install]
WantedBy=multi-user.target

In the above example, a dedicated directory owned by the secureclient user has been created as /opt/cloudvolumes. This folder contains the client binary, configuration file, certificate, private key and CA. In this case, the logs output by the client will be collected by systemd and viewable using sudo journalctl -u secure-client.service

If you are not using an init system, refer to the Using the Secure Client section for information on how to manage logs.

Configuration

The YAML configuration file contains the following properties, which might need to be modified when the client is being run via an init system.

  • ca: The path to the CA file
  • cert: The path to the certificate file
  • key: The path to the private key file

These paths can either be absolute or relative to the location the client is being executed from.

The YAML file also contains the following properties that should not need to be modified. They are listed here for completeness:

  • target1: The address and port to send traffic for StoreOnce Catalyst command sessions
  • target2: The address and port to send traffic for StoreOnce Catalyst data sessions
  • source1: The address and port to listen on for StoreOnce Catalyst command sessions
  • source2: The address and port to listen on for StoreOnce Catalyst data sessions

Generally, the address to listen on should always be 0.0.0.0. The port for Catalyst command sessions and data sessions are 9387 and 9388 respectively.

Using the Secure Client

If you are using an init system, you can start the client using the usual commands. For example, in the example systemd service listed above, if the name is "secure-client.service", the command would be:

$ sudo systemctl enable secure-client
$ sudo systemctl start secure-client

If you are not using an init system, navigate to the directory containing the client and run it as the user that you created to run the client:

$ sudo su secureclient
$ ./secure_client

To ensure that logs do not fill up the machine running the secure client, it is recommended to use the "--log" option and use logrotate to ensure that the logs do not fill up the machine it is running on. For example:

$ ./secure_client --log /var/log/cloudvolumes/secure_client.log

This requires that /var/log/cloudvolumes is a folder owned by the secureclient user. To add log rotation, create the following as /etc/logrotate.d/secure_client:

/var/log/cloudvolumes/secure_client.log {
    rotate 4
    weekly
    copytruncate
    compress
    missingok
    notifempty
}

Earlier versions of this documentation did not have the copytruncate option in the log rotation configuration. If this option is added to an existing log rotation configuration, the secure client should be restarted as well. Wait until there is a period with no backups or Catalyst Copies running to do this. If using systemd, restarting the service can be done using:

sudo systemctl restart secure-client

Once this file has been created, ensure it is owned by the root user:

sudo chown root:root /etc/logrotate.d/secure_client

Configuring your ISV Backup Application

After you have set up and have started the Secure Client, complete the following steps to configure your ISV backup application to connect with HPE CV Backup.

  1. Log into your ISV backup application.
  2. Follow the process in your backup application to add an HPE StoreOnce appliance as a backup store.
    • When prompted for the appliance address or IP, enter the Secure Client IP or address.
    • When prompted for credentials, enter the User ID and password that you received when you created your HPE CV Backup Store.

Certificate Renewal

The TTL on the certificate and private key provided in the ZIP file is 90 days. After 30 days, the client will attempt to renew these, storing the old files under "NAME.bak", where "NAME" is the original name of the certificate or private key. The CA is not changed by the renewal process.

Assuming the certificates are eligible for renewal, the renewal will be performed on start up and every 24 hours after. If the certificates have expired, automatic renewal will not be possible. They will need to be reissued from the HPE Cloud Volumes Backup site (https://cloudvolumes.hpe.com) instead.

If certificate renewal fails, check that the file permissions and owner for the certificate and private key have been set correctly as detailed in the setup section. If you suspect that the certificate has expired, you can verifiy using openssl as follows:

$ openssl x509 -in NAME.crt -text -noout

Where NAME.crt is the path to the certificate file. The expiry of the certificate can be found under the validity section as demonstrated below:

  • Validity

    Not Before: Mar 20 14:45:26 2020 GMT

    Not After : Jun 18 14:45:55 2020 GMT

If the server is within its validity period, also ensure that the date and time are correct on your machine using the "date" command. It is recommended that you use an NTP client to avoid issues with incorrect time on your machine. Most Linux distributions have "ntpd" available for this, although newer distributions may come with "chronyd" instead.

If there is a concern that the wrong certificate is being used, the common name (CN) can be verified using the same "openssl" command as above. The CN will be within the subject field in the format "<prefix>.<store-name>.<store-id>.<suffix>" The value of "store-name" should match the name of the backup store the secure client is used for.

Upgrading the Secure Client

As new versions become available, the client will attempt to upgrade itself to that version. The previous version is stored as "NAME.bak", where "NAME" is the original name of the client binary. Updates are checked for on start up and every 24 hours after and are downloaded from the HPE Cloud Volumes service.

If upgrading fails, check that the owner of the client has been set correctly as detailed in Setting up the Secure Client section..