Configure the server from the command line
The following references describe the server settings that can be configured for HSTS by using the command line or directly editing the HSTS configuration file, aspera.conf .
aspera.conf - WebSocket configuration The <server> section of aspera.conf can be used to configure the server to use the WebSocket protocol over HTTPS instead of SSH. The ascp client uses HTTPS for WebSocket only. However, the WebSocket server can be configured to use HTTP as long as a proxy is being used to stop the HTTPS server endpoint.aspera.conf - Authorization configuration The settings in the <authorization> section of aspera.conf include transfer permissions and token configuration. Tokens are used by Aspera® web applications to authorize transfers between Aspera® clients and servers.aspera.conf - Transfer configuration The settings in the <transfer> section of aspera.conf include: bandwidth control, transfer protocol options, content encryption requirements, encryption-at-rest, and inline validation.Controlling bandwidth usage with virtual links from the command line FASP® transfers attempt to transfer at the maximum transfer rate available. However, too many simultaneous transfers can overwhelm your storage or leave little bandwidth available for other network activity. To set a bandwidth cap on the total bandwidth that is used by incoming or outgoing transfer sessions initiated by all users, groups, or sets of specific users, set up a virtual link (Vlink).Setting the global bandwidth from the command line Global bandwidth usage by incoming and outgoing transfers can be configured from the command line by creating Vlinks that are applied to all users.Increasing transfer performance by using an RTT Predictor FASP® transfers use delay-based congestion control to dynamically adjust the transfer rate in response to network congestion, as measured by round-trip time (RTT). As a result, FASP® transfer stability is sensitive to feedback delay; increases in feedback delay decrease FASP® transfer stability and throughput. Transfer performance can be improved by using two experimental configuration options, an RTT predictor and a dynamic target queuing.aspera.conf - File system configuration The settings in the <file_system> section of aspera.conf include the docroot, file permissions, file handling, filters, checksum reporting, and growing files. The absolute path, or docroot, is the area of the file system that is accessible to an Aspera transfer user. The default empty value allows access to the entire file system. You can set one global docroot and then further restrict access to the file system by group or individual user. aspera.conf - Transfer server configuration The settings in the <central_server> section of aspera.conf include the network and port that asperacentral uses to process transfer requests and how to manage the asperacentral database.aspera.conf - Filters to include and exclude files For example, on Windows™ FAT or NTFS (or directories) to transfer by indicating which to skip or include based on name matching. When no filtering rules are specified by the client, ascp transfers all source files in the transfer list.Server-Side Encryption-at-Rest (EAR) When files are uploaded from an Aspera client to HSTS , server-side encryption-at-rest (EAR) saves files on disk in an encrypted state. When downloaded from HSTS , server-side EAR first decrypts files automatically, and then the transferred files are written to the client's disk in an unencrypted state.Reporting checksums File checksums are useful for troubleshooting file corruption to determine at what point in the transfer file corruption occurred. Aspera® servers can report source file checksums that are calculated in real time during transfer and then sent from the source to the destination.Server logging configuration for ascp and ascp4 Server transfer logs are stored in the default location, rotated once they are 10 MB, and log at log level. For ascp transfers, you can configure a different default log directory, log size, number of logs, and logging intensity on the server, and apply these settings globally or to specific users. For Ascp4 transfers, you can configure a default log size (Ascp4 does not support user-specific logging settings). These settings do not affect IBM Aspera Sync logging, which is configured in a different section. Out-of-transfer file validation Out-of-transfer file validation is run as soon as the client uploads a file to HSTS . The transfer is reported as complete and then the validation is run. The validation script uses the Aspera® Reliable Query API to retrieve the list of files to validate and update the file status during validation. The transfer user who is transferring files to the server must be associated with Node API user credentials to use the API. These instructions describe how to associate a transfer user with Node API user credentials, create a validation script, and configure the server to use out-of-transfer file validation on files that it receives from specific transfer users, groups, or globally. Inline file validation If an executable file that contains malicious code is uploaded to the server, the malicious code can later be run by an external product that integrates with an Aspera® product. Inline file validation is a feature that enables file content to be validated while the file is in transit, and when the transfer is complete. The validation check can be made with a REST call to an external URL. The mode of validation used (URL) and the timing of the check are set in the Aspera server GUI or aspera.conf .Inline file validation with URI Inline file validation with URI can be customized to filter which files are validated.