Release Notes
This version of Waarp Gateway is the first major version released in 1 year. During this time we have added a large number of features, optimizations and fixes.
The update is, as always, highly recommended.
Main changes
Support for FTP and FTPS protocols
Waarp Gateway 0.9.0 adds support for FTP and FTPS protocols, in addition to the protocols already supported (R66, SFTP, HTTP, and HTTPS). Both active and passive modes are supported for data transfer. Implicit and explicit modes are supported for FTPS.
Support for these protocols has some limitations. Please refer to the documentation to learn more.
Authentication methods
Depending on the protocols, Waarp Gateway supports authentication by password, by public key, by certificate, and/or by client certificate.
These different methods have been grouped into authentication methods. The same possibilities are available, but the configuration of local and remote account authentication is now uniform and is done in the same way regardless of the method chosen.
This consolidation also provides a more solid basis for adding new authentication methods in the future.
Client configuration
In Waarp Gateway, the configuration of protocol servers to manage incoming connections can already be managed server by server according to the possibilities offered by the protocols (encryption algorithms, etc.). These possibilities were not possible for outgoing connections (Gateway client part).
From this version 0.9.0 of Waarp Gateway, clients must be created and configured before undertaking any transfers. This therefore offers many advantages, particularly in terms of security (global deactivation of a compromised algorithm for all outgoing transfers, etc.), other features will also be added in the future.
Updating the AES encryption key
For security reasons, all passwords are encrypted in the database (these are protected even in the event of a database compromise).
Passwords for connecting to remote servers are AES encrypted, using a key saved on disk. If this key is compromised, a new key must be generated and the passwords must be reheated with the new key.
This operation can now be automated with the new waarp-gatewayd change-aes-passphrase command, which automatically updates all affected passwords.
Preparing cloud storage media
Cloud storage support (Amazon S3, Microsoft Azure, Google Cloud Platform, etc.) required some preparatory work to enable the use of remote or local storage seamlessly.
This work is now completed and connectors to the different Cloud storage providers will be added in a future version.
List of Changes
New features
#399 Added an authentication cache, which significantly improves performance when a large number of transfer requests are made at the same time by a small number of partners.
#132 Added support for FTP and FTPS protocols to the gateway. It is now possible to perform client and server transfers with this protocol. Given the particular operation of this protocol, it is advisable to read the section specifying the implementation details of the protocol before using it.
#389 Added the waarp-gatewayd change-aes-passphrase command to change the AES passphrase used by the Gateway to encrypt remote passwords in the database (see the command documentation for more details).
#289 Certificates and passwords are replaced by the more generic "authentication methods", making it easier to add new forms of authentication. Also added “authentication authorities” allowing the authentication of certain types of partners to be delegated to a trusted third party. For more information see the chapter on authentication .
Adding or removing TLS certificates to a transfer agent no longer requires a restart of the service in question for the changes to take effect.
Updating the services (servers or clients) of the gateway now automatically causes a restart of the service in question, so that the new configuration is taken into account. Please note: this will interrupt all transfers in progress on the service in question, so it is not recommended to restart a service if transfers are in progress on it.
Client, server and partner protocol configurations are now separated from each other, so that they can (when necessary) have different options. See the protocol configuration chapter for more details.
#332 Materialization of transfer clients. The gateway's transfer clients are no longer created on the fly when transfers start, they must now have been created beforehand. Therefore, initializing a new transfer now requires specifying which client to use to execute this transfer. For convenience, for existing installations, a default client will be created for each protocol in use during gateway migration.
Added the disabled enable/disable option to the localAgent local server JSON object in the import/export file. It is therefore now possible to specify whether an imported server should be activated or deactivated.
#392 Addition of the copyInfo and info arguments to the TRANSFER task allowing respectively to copy the transfer info from the previous transfer, and to define new transfer info . For more information, see the TRANSFER task documentation .
#379 Added support for cloud instances to replace local disk for storing transfer files. See the cloud section for more details on the implementation of the different instance types, and the folder management section for more details on their use.
Fixes
#398 SSH public keys using the rsa-sha2-256 and rsa-sha2-512 algorithms are now correctly accepted by the SFTP client when connecting to a partner. Previously, these algorithms were incorrectly refused by the gateway's SFTP client despite the fact that they were supported.
#391 Passwords for R66 local servers are now exported in clear text (like the rest of the non-hash passwords).
The default folders (specified in the configuration file) created by the gateway now have permissions 740 instead of 744.
In the case where the gateway database is shared, the transfer partners are no longer common to all instances using the database. In fact, each gateway instance now has its own directory of partners, independent of those of the other instances sharing the database. When migrating the gateway, to avoid possible incompatibility problems, all partners existing ones as well as their children (remote accounts, certificates, etc.) will be duplicated between all known gateway instances using the database.
Newly created local servers are now enabled by default instead of being disabled as was previously the case.
Note : The term “enabled” here should not be confused with “running ” . Servers will not be automatically started immediately after creation. However, they will be started the next time Gateway is launched.
Transfer information transmitted via HTTP(S) is now taken into account in tasks.
Transfer info override values in tasks are no longer overridden by their JSON representation. This had the effect of string values being substituted with quotes (“). From now on, information transfers are replaced by their raw textual representation.
Impairments
In the case where the gateway database is shared, the transfer partners are no longer common to all instances using the database. In fact, each gateway instance now has its own directory of partners, independent of those of the other instances sharing the database.
Comments