Planning the deployment
LiquidFiles is server software, like a web or mail server, and needs to be installed somewhere where it can run 24x7 to function properly.
A typical production installation of LiquidFiles looks like this:
The LiquidFiles appliance is typically deployed in a DMZ, next to your mail and web server. For normal usage, it will also need to be reachable from the Internet.
For test installations, you can deploy LiquidFiles on pretty much any system, including running on VMware or similar virtualization platforms on your Mac or PC. Please beware though that similarly to a web server, LiquidFiles needs to be running and connected for anyone to be able to download any files from it.
LiquidFiles is a virtual appliance, meaning that it will come ready with it's own operating system, all the required components and the application itself. It is not possible to install LiquidFiles on an already running and installed system. It needs to be installed as a separate server. It aims to be as flexible as possible, and you have three basic installation options.
Just like any server, you can use the downloadable ISO image to burn a CD and install on pretty much any available physical server.
This installation option is likely to provide the maximum performance as there's no other resources competing with the available resources (CPU, memory and disks).
All data is kept within your environment for maximum security and performance.
This is the most popular installation option. Using your existing VMware, Microsoft Hyper-V, Citrix Xen or similar virtual platform, you can install LiquidFiles as another virtual server.
While the performance is not going to be as great as a dedicated physical server, in the overwhelmingly majority of cases it's going to be adequate performance and you will get the typical virtual server benefits of sharing physical server space, power, cooling, etc.
All data is kept within your environment for maximum security and performance.
If you want to use the benefits of running LiquidFiles in the Cloud, you can either deploy LiquidFiles in any of the available Amazon AWS or Microsoft Azure data centres, or deploy in any other cloud server provider that offers you to run your own virtual system where you can install your own system using an ISO image.
Performance and Security is going to be similar to your other virtual servers in your chosen cloud provider.
The following table outlines the network connections that the LiquidFiles requires to operate (IP addresses assumed to be as in the network diagram above).
|Protocol / Function
|80 & 443
|http and https is allowed from anywhere. This is how all files are uploaded and downloaded and all normal user interaction is via http or https.
|The appliance needs DNS to function properly.
|any / email relay server
|The appliance needs to send emails, either via an email relay server or directly to the Internet.
|The appliance downloads updates over https. Please see the table below for a list of specific URLs that are being used.
|Use specific management ip's if you can for ssh access to the appliance.
|If LDAP authentication is enabled, the appliance needs connections to the LDAP server.
|any / ntp server
|If NTP time synchronisation is enabled, if NTP pool authentication is enabled the destination needs to be any.
|If you have enabled Emaildrops.
|If you have configured FTPdrops and wish to use FTP.
|If you have configured FTPdrops and wish to use SFTP/SCP.
In most cases, if deployed behind a firewall or similar, you will also need to configure the firewall for address translation — translating a public address to the private 10.0.2.10 address. You will also mostly certain need to configure DNS so that a published DNS points to the public ip address of the Filetransfer appliance.
Restricting outgoing https
The following table outlines all connections where LiquidFiles is using when connecting to the Internet.
|When installing/renewing licenses, the LiquidFiles system will validate its license with the license details stored at https://license.liquidfiles.com. Also, when performing updates, LiquidFiles will check available updates from https://license.liquidfiles.com.
|Any LiquidFiles, System, AV Updates or Hotfixes will be downloaded from https://updates.liquidfiles.com.
Please note that https://updates.liquidfiles.com is using Amazon Cloudfront (global geo-caching). You will not be able to restrict this to specific IP addresses.
|If you have enabled GeoIP lookups, the LiquidFiles system will lookup IP → GeoIP locations to https://geoip.liquidfiles.com.
|If you need to send Support Information (diagnostic information sometimes requested by LiquidFiles support), this will be sent from the LiquidFiles system to https://files.liquidfiles.com/.
|If you need to enable the Support Connection (when requested by LiquidFiles support), this will establish a connection on TCP Port 443 to access.liquidfiles.com. Please note that eventhough this is using TCP Port 443, it is not using HTTPs so if you are using any content inspecting firewall or similar, you may need to disable HTTPs checking for the support connection to be able to be established.
The table above is accurate for LiquidFiles system v3.5 and above. In LiquidFiles v3.4 and below, random CentOS, Epel and ClamAV mirrors was used to download updates. In LiquidFiles v3.4 and below, you will not be able to restrict updates to only certain URLs. Please update to LiquidFiles v3.5 and then you can add the restrictions listed above if required.
If required, you can also configure a Proxy in Admin → System → Network and that will make all outgoing connections use the proxy instead of going direct.
Some organisations like to use different names for internal and external resources, giving resources like LiquidFiles names like liquidfiles.company.com and liquidfiles.local for external and internal use respectively, just like they would if LiquidFiles was an intranet application.
LiquidFiles is a little bit different from most other applications though as it sends email referencing itself (something a webmail system for instance never would do). And one of the key architectural decisions with LiquidFiles is — don't break how emails normally work. Consider the following message:
From: <firstname.lastname@example.org> To: <email@example.com> CC: <firstname.lastname@example.org> Subject: You're fired Homer, you're fired. Here's a link to your letter of dismissal: https://liquidfiles.powerplant.com/message/6Q6U1D9LynIrcxmD0SrN0r
If we assume that email@example.com and firstname.lastname@example.org are internal users and email@example.com is external. If we sent a link with the URL to the LiquidFiles system as https://liquidfiles.local, firstname.lastname@example.org would not be able to reach it. If we split the email and sent individual emails to email@example.com and firstname.lastname@example.org with links to https://liquidfiles.local and email@example.com with a link to https://liquidfiles.powerplant.com, none of the receipients would see who else is copied on the message, one of the key functions of the email header. We therefore have to send the same email to everyone.
Our only workable option is to make the same name resolvable and reachable from everywhere. In this example that would be: liquidfiles.powerplant.com.
Depending on our infrastructure, this could be accomplished by:
- Making sure that the public ip address for the LiquidFiles system is routable everywhere
- Use split view/dual DNS to either provide the external or internal ip address for the LiquidFiles system depending on the location of the user.
In most cases, split view or dual DNS configuration is the preferable option. This will enable you to use an external ip address for liquidfiles.company.com for external users, and an internal ip address for internal users. If we use the same ip address both internally and externally, we often end up having to address translate external addresses when trying to make them reachable in a DMZ from internal addresses. But whatever method you are comfortable with, as long as you can use the same name (liquidfiles.company.com) from anywhere, it really doesn't matter how you achieve it.
Another thing that often causes issues, primarily with test installations in large enterprises, is delivering emails.
LiquidFiles has two options when delivering emails:
- Direct delivery — use DNS to lookup the mail server for each recipient and deliver the email directly with SMTP. This is the same functionality as any email server on the Internet would use to send emails.
- Use an Email relay server — send all emails to a configured email relay server. Let the email relay server deliver all emails on behalf of the LiquidFiles system.
The reason why this sometimes can be challenging is that with 1) connections from the inside out is often firewalled in large enterprises, so the LiquidFiles system can't connect to the required SMTP servers and deliver the emails. And with 2) the typical email server configuration does not permit the unrestricted email relaying LiquidFiles requires.
To expand on the latter. When the LiquidFiles system sends an email, the email header looks something like this:
From: <firstname.lastname@example.org> To: <email@example.com> CC: <firstname.lastname@example.org> Subject: You're fired
But could just as easily be:
From: <email@example.com> To: <firstname.lastname@example.org> CC: <email@example.com> Subject: What took you so long?
The From field is going to be the email address of the user who is sending the message in LiquidFiles and the To, CC and BCC fields are going to be whatever the logged in user has entered. Usually the From field is what's causing issues as it can be an internal user (like firstname.lastname@example.org above) or an external user (email@example.com). We can therefore not place any limitations on either the From or the To field.
If we compare this how the email header looks when sending from something like Outlook. In Outlook the From field is always going to be the same. In most email servers, the user will have to authenticate to relay (send) the email and when they authenticate, they have to send as the user they authenticated as. So if the email above was composed by firstname.lastname@example.org using Outlook to send through his local Ms Exchange server, Outlook would authenticate as email@example.com and allow him to send the email. But firstname.lastname@example.org could not authenticate as email@example.com and then enter firstname.lastname@example.org in the From field. The email server would not permit this.
If we instead compare the LiquidFiles email to how say a NAS server email alert email looks. This is again different in that the To field is always the same. In the email server we can configure emails to always be allowed to something like email@example.com so that all devices that sends monitoring emails can send them to this address.
And this is where it is sometimes difficult to test LiquidFiles in environments that are locked down. LiquidFiles needs to be permitted to send emails From anyone and To anyone. This is of course unless you are building a strict internal system, in which case you can limit to only be permitted From and To the specific addresses you permit. But in the overwhelmingly majority of cases, you will have to permit the LiquidFiles system to send From anyone and To anyone.
There are typically two options to achieve this when using the email relay option:
- Configure the email server you are relaying through to permit the ip address of the LiquidFiles system unrestricted email relay permissions.
- Configure a user in the email server (firstname.lastname@example.org) unrestricted email relay permissions in the mail server.
In both cases, please refer to your email server configuration for instructions how to configure unrestricted email relaying for the LiquidFiles system.
The only other option is to not use an internal email server to relay the emails and instead use a public available email relay service like ElasticEmail. Mandrill (by the same company as Mailchimp) is a service specifically built to relay emails from system like LiquidFiles. In case of a strict locked down network, you would only need to open connections from the ip address of the LiquidFiles system to smtp.mandrillapp.com instead of permitting unrestricted SMTP access, or change the configuration of your mail server. So this may well be the simplest option.
If you run into problems with email delivery, please see the Troubleshooting Email Delivery article.
Please continue on the System Requirements page.