Configuring for Aspera on Cloud

To add an IBM Aspera High-Speed Transfer Server as a node to Aspera on Cloud, it must be configured for the Aspera Node API, which Aspera on Cloud uses to connect to the node, retrieve file system information, and initiate transfers. Requests to the Node API are authenticated with Node API credentials (a node username and password) that are associated with a local system account. All transfers and system operations on the node that are intiated through Aspera on Cloud are run under the system account.

To add a server as an Aspera on Cloud node, you create the system user on the server, configure the system user as an Aspera transfer user, associate the transfer user with a node username and password, and configure the server to work with Aspera on Cloud. Aspera on Cloud users access the Node API and Aspera on Cloud nodes using access keys, which are created on the server or in the Aspera on Cloud UI.

System Requirements:

High-Speed Transfer Server version 3.7.4 or later (3.8.0 or later strongly recommended).
The public DNS name of the system must be accessible from all internal and external clients, as well as the computer itself.
The system clock is synchronized with an NTP server. See your OS documentation for instructions.
Valid SSL certificates that are in .pem format and that are signed by a globally recognized Certificate Authority. For more information, see Installing SSL Certificates.

Set Up and Configure a Transfer User

Create a system user.
Restrict user permissions with aspshell.
By default, all system users can establish a FASP connection and are only restricted by file permissions. Restrict the user's file operations by assigning them to use aspshell, which permits only the following operations:
- Running Aspera uploads and downloads to or from this computer.
- Establishing connections in the application.
- Browsing, listing, creating, renaming, or deleting contents.
These instructions explain one way to change a user account or active directory user account so that it uses the aspshell; there may be other ways to do so on your system.
Run the following command to change the user login shell to aspshell:
```
# sudo usermod -s /bin/aspshell username
```
Confirm that the user's shell updated by running the following command and looking for /bin/aspshell at the end of the output:
```
# grep username /etc/passwd
username:x:501:501:...:/home/username:/bin/aspshell
```
Note: If you use OpenSSH, sssd, and Active Directory for authentication: To make aspshell the default shell for all domain users, first set up a local account for server administration because this change affects all domain users. Then open /etc/sssd/sssd.conf and change default_shell from /bin/bash to /bin/aspshell.
Ensure that the user has read and write privileges to the local directories or mounts that Aspera must access.

Set a file restriction for the user, rather than a docroot.

The file restriction allows access only to the specified storage. To set a docroot restriction, run the following command:

# asconfigurator -x "set_user_data;user_name,username;file_restriction,|path"

Where the "|" is a delimiter, and the restriction path syntax depends on the storage:

Storage Type	Format Example
local storage	For Unix-like OS: specific folder: file:////`folder`/* drive root: file:////* For Windows OS: specific folder: file:///c%3A/`folder`/* drive root: file:///c*
Amazon S3 and IBM Cloud Object Storage - S3	s3://*
Azure	azu://*
Azure Files	azure-files://*
Azure Data Lake Storage	adl://*
Swift	swift://*
Alibaba Cloud	oss://*
Google Cloud	gs://*
HDFS	hdfs://*

For example, to set a restriction for xfer to S3 storage, the command is as follows:

# asconfigurator -x "set_user_data;user_name,xfer;file_restriction,|s3://*"

Configure the transfer user for token authorization.
```
# asconfigurator -x "set_user_data;user_name,xfer;authorization_transfer_in_value,token;authorization_transfer_out_value,token;token_encryption_key,key"
```
Aspera recommends that the key be a random string of at least 20 characters.
Assign the SSH public key associated with IBM Aspera Connect to xfer.
IBM Aspera Connect uses the default Aspera key pair. Run the following commands to create the .ssh directory, copy the default public key into that directory and rename it authorized_keys, and set permissions on the file, run the following commands:
```
$ mkdir /home/xfer/.ssh
$ cp /opt/aspera/var/aspera_tokenauth_id_rsa.pub /home/xfer/.ssh/authorized_keys
$ chmod 700 /home/xfer/.ssh
$ chmod 600 /home/xfer/.ssh/authorized_keys
$ chown -R xfer:xfer /home/xfer/.ssh
```
Create a node username and associate it with the system user xfer.
Run the following command with root or administrator permissions:
```
# /opt/aspera/bin/asnodeadmin  -a -u node_user -p node_user_passwd -x xfer
```
For example:
```
# /opt/aspera/bin/asnodeadmin  -a -u nuser-001 -p 472830x4n -x xfer
```
Note: The node username password must meet the password requirements set in Aspera on Cloud.
List the node usernames to confirm that your command was successful.
```
# /opt/aspera/bin/asnodeadmin -l
```

Configure the Server as a Aspera on Cloud Node

Configure the entitlement, if you do not have a separate license for the server.
Run the following commands to start the ALEE service, restart the Aspera NodeD service, and register your entitlement:
```
# /opt/aspera/bin/asalee-config.sh enable
# systemctl restart asperanoded
# /opt/aspera/bin/alee-admin register customer_ID entitlement_ID
```

If you configured an entitlement on your server and are behind a strict firewall, whitelist the IP addresses that are used by the ALEE service.

The ALEE service uses the SafeNet environment to manage and recognize entitlements, including the following components and their domain names:

Name	Domain Name
Sentinel Cloud yellow pages services	yps-ws.sentinelcloud.com
Sentinel Cloud backend	pdx02-cloud.prod.sentinelcloud.com

The IP addresses associated with these domain names change every few months. To retrieve the IP addresses, run the following commands:

# dig +short yps-ws.sentinelcloud.com
# dig +short pdx02-cloud.prod.sentinelcloud.com

Ensure SSHD is running on port 33001.
For information on configuring TCP ports, see Securing Your SSH Server. You must also manually configure the <WEB> section of aspera.conf; see the IBM Aspera High-Speed Transfer Server Admin Guide: Configuring Your Web UI Settings.
Configure a file extenstion to identify files that are still being transferred.
To set an extension for files that are partially transferred, such as .partial, run the following command:
```
# asconfigurator -x "set_node_data;partial_file_suffix,.partial"
```
The extension is removed once the file transfer is complete.
Enable activity logging and activity event reporting by running the following command:
```
# asconfigurator -x "set_server_data;activity_logging,true;activity_event_logging,true"
```
Configure the HTTPS service to use port 443 by running the following command:
```
# asconfigurator -x "set_server_data;https_port,443"
```
Note: Aspera strongly recommends adding an Nginx reverse proxy in front of asperanoded (described in the following section), in which case the HTTPS port is set back to 9092.
Enable recursive counts by running the following command:
```
# asconfigurator -x "set_server_data;files_recursive_counts_workers,value"
```
For value, enter a number from one to eight. Lower values (one or two) result in slower updates but less load on Redis. Higher values (four to eight) increase the load on Redis and the machine should have twice as many cores. Aspera recommends starting with a value of five, and adjusting if needed.

If your Redis database is very large and you set a high number of recursive counts workers, you may encounter out-of-memory problems. To avoid this issue, increase the time between background Redis save events and number of key changes by running the following command:
```
# asconfigurator -x "set_server_data;db_config_save,time key_changes"
```
The default value is 900 1, which sets the background save schedule for every 15 minutes (900 seconds) if at least one key changes. To set this change, you must shut down the Redis database (it is restarted in the next step) by running the following command with root or Administrator privileges:
```
# /opt/aspera/bin/asnodeadmin --db-shutdown
```
Restart the Aspera Central, Aspera NodeD, and Aspera HTTPD services.
Run the following command in a Terminal window to restart asperacentral:
```
# systemctl restart asperacentral
```
or for Linux systems that use init.d:
```
# service asperacentral restart
```
Run the following commands to restart asperanoded:
```
# systemctl restart asperanoded
```
or for Linux systems that use init.d:
```
# service asperanoded restart
```
Run the following commands to restart asperahttpd:
```
# systemctl restart asperahttpd
```
or for Linux systems that use init.d:
```
# service asperahttpd restart
```

Install the Files Node Search Service

The Files node search service enables on-premises servers to report storage usage and Node API events to Aspera on Cloud admins in the Aspera on Cloud UI.

Updates

The installation package is provided as a tarball that is periodically updated. Aspera recommends that you check for updates every 30 days. To upgrade the service, download the updated tarball and run the installation script, as described in the first two steps of the following instructions.

Prerequisites

The server must have High-Speed Transfer Server version 3.7.3 or higher.
Installing the service requires sudo privileges on the server.
The server's firewall must allow HTTPS outbound connections on TCP port 443 to elasticsearch.asperafiles.com (on the same IP address as asperafiles.com).
Java version 8 or higher must be available in your PATH.
jq version 1.5 or higher. The service installer will install jq if it is not already on the server.

These instructions assume that you are installing the Files node search service on the server that is running High-Speed Transfer Server. If your configuration differs, contact your Aspera support representative.

Download the Files node search installation script onto the server.
```
# curl -o files-node-search-install.sh https://whale.asperasoft.com/files-node-search-install.sh
```
If your server does not have WAN access, see "Install on a server with no WAN access," which follows these instructions.
Download, install, and start the service by running the installation script.
```
# sudo bash ./files-node-search-install.sh [--user node_user]
```
The service requires the same Node API credentials that are used to add the node and initiate transfers in Aspera on Cloud. You can enter the node username with --user and enter the password at the prompt, and these credentials are added to the service's configuration file. If you do not set the node user in this step, you must manually add the node user and password to the Files node search service configuration file (described in a later step).
Confirm that the service started.
The Files node search service starts automatically. To confirm, run the following command:
```
# /opt/aspera/files-node-search/etc/init.d/files-node-search status
```
The output should show the service as RUNNING.

You can start and stop the service by using the same command and replacing "status" with "start" or "stop".
Edit the configuration file, if required.
Open /opt/aspera/files-node-search/etc/files-node-search.conf for editing.
The file contains two sections, one for Elasticsearch and one for Node. Do not change the Elasticsearch settings. Edit the node settings as needed. In particular, if you did not enter a Node API username and password, replace node_user and node_user_password with the correct node credentials. The node user should be the same one that is used to add the node and initiate transfers in Aspera on Cloud.
```
#Elasticsearch
elasticsearch.ext.host=elasticsearch.asperafiles.com
elasticsearch.ext.port=443
elasticsearch.ext.scheme=https
 
#Node
node.initial.delay.seconds=60
node.runtime.interval.seconds=300
node.crawler.user=node_user
node.crawler.password=node_user_password
node.http.scheme=http
node.http.host=localhost
node.http.port=9091
```
Save your changes and close the file.

If you changed files-node-search.conf, restart the service to activate your changes.

# /opt/aspera/files-node-search/etc/init.d/files-node-search stop
# /opt/aspera/files-node-search/etc/init.d/files-node-search start

Logging

Files node search service logs are found in /opt/aspera/files-node-search/var/log/current.

Uninstall the Files node search service

Run the following commands to stop the service and remove the directory containing the application:

# /opt/aspera/files-node-search/etc/init.d/files-node-search stop
# rm -rf /opt/aspera/files-node-search

Install on a server with no WAN access

If you need to install the Files node search service on a server that does not allow WAN access to install packages, install the service on a server that does have WAN access and then copy the tarball to the server without WAN access, as follows:

On the server with WAN access, download and install the service.

# curl -o files-node-search-install.sh https://whale.asperasoft.com/files-node-search-install.sh
# sudo bash ./files-node-search-install.sh

Stop the service then copy the tarball to the server without WAN access. If you do not need the service on the server with WAN access, you can delete the files-node-search directory.
```
# /opt/aspera/files-node-search/etc/init.d/files-node-search stop
# scp /opt/aspera/files-node-search/tmp/files-node-search-version.tar.gz user@server_ip:/tmp/files-node-search-version.tar.gz
# rm -rf /opt/aspera/files-node-search
```
On the server without WAN access, create the files-node-search directory and copy the tarball into it.
```
# mkdir -p /opt/aspera/files-node-search/tmp
# cp /tmp/files-node-search-version.tar.gz /opt/aspera/files-node-search/tmp/
```

Untar the tarball.

# tar xzf /opt/aspera/files-node-search/tmp/files-node-search-version.tar.gz -C /opt/aspera/files-node-search --strip-components 1

Set the node username and password in /opt/aspera/files-node-search/etc/files-node-search.conf.

Start the service.

# /opt/aspera/files-node/search/etc/init.d/files-node-search start

Securing the Aspera NodeD Service Behind a Proxy

If your Aspera server must expose the Aspera NodeD service to the internet, such as when setting it up as a Aspera on Cloud node, Aspera recommends protecting it with a reverse proxy. Normally, asperanoded runs on port 9092, but nodes that are added to Aspera on Cloud must have asperanoded run on port 443, the standard HTTPS port for secure browser access. Configuring a reverse proxy in front of asperanoded provides additional protection (such as against DOS attacks) and resource handling for requests to the node's 443 port.

The following instructions describe how to set up Nginx as a reverse proxy and require that you have valid, CA-signed SSL certificates in .pem format for the server. Other reverse proxies might be supported on your server.

Set up a system user with Node API credentials on your server.
For instructions, see Node API Setup.
Download and install Nginx.

Configure the HTTPS port for the NodeD service.

# asconfigurator -x "set_server_data;listen,127.0.0.1:9092;https_port,9092"

Open the Nginx configuration file in a text editor.
Open /etc/nginx/nginx.conf and ensure the following include directive is present in the http section. If it is not present, add it to the file:
```
http {
…
include /etc/nginx/conf.d/*.conf;
}
```
Create a file named aspera_node_proxy.conf and save it in the following location:
/etc/nginx/conf.d/aspera_node_proxy.conf

Paste the following content into aspera_node_proxy.conf:

#
# Aspera configuration - reverse proxy for asperanoded
#
server {
       listen 443;
       server_name your.servername.com;
       ssl_certificate /opt/aspera/etc/aspera_server_cert.pem;
       ssl_certificate_key /opt/aspera/etc/aspera_server_key.pem;

       ssl on;
       ssl_session_cache builtin:1000 shared:SSL:10m;
       ssl_protocols TLSv1.2;
       ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS;
       ssl_prefer_server_ciphers on;

       access_log          /var/log/nginx/node-api.access.log;

       location / {
           proxy_pass https://127.0.0.1:9092;
           proxy_read_timeout 60;
           proxy_redirect https://127.0.0.1:9092 https://your.servername.com;

           proxy_set_header Host               $host:$server_port;
           proxy_set_header X-Real-IP          $remote_addr;
           proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto  $scheme;
       }
}

Replace your.servername.com with your server's domain name. The SSL certificate must include any intermediate certificates, as described in Installing SSL Certificates.

Restart the Aspera NodeD service.
Run the following commands to restart asperanoded:
```
# systemctl restart asperanoded
```
or for Linux systems that use init.d:
```
# service asperanoded restart
```
Restart Nginx.
```
# service nginx restart
```

Adding the Node to Aspera on Cloud

Once you have created a system user on the server, configured the user for Aspera, associated it with a node username, configured the server, and verified your SSL certificates, you may add it as a node in the Aspera on Cloud UI. In the process you are asked for an existing access key and secret, or you can create a new one. If you prefer to manually create an access key on the server, see the instructions in Access Key Authentication.