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.

Selecting platform

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.

Network Connections

The following table outlines the network connections that the LiquidFiles requires to operate (IP addresses assumed to be as in the network diagram above).

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.

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.

DNS Considerations

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: <burns@powerplant.com>
To: <homer@powerplant.com>
CC: <kent.brockman@news.com>
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 burns@powerplant.com and homer@powerplant.com are internal users and kent.brockman@news.com is external. If we sent a link with the URL to the LiquidFiles system as https://liquidfiles.local, kent.brockman@news.com would not be able to reach it. If we split the email and sent individual emails to burns@powerplant.com and homer@powerplant.com with links to https://liquidfiles.local and kent.brockman@news.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.

Email Considerations

Another thing that often causes issues, primarily with test installations in large enterprises, is delivering emails.

LiquidFiles has two options when delivering emails:

1. 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.
2. 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: <burns@powerplant.com>
To: <homer@powerplant.com>
CC: <kent.brockman@news.com>
Subject: You're fired

But could just as easily be:

From: <kent.brockman@news.com>
To: <burns@powerplant.com>
CC: <homer@powerplant.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 burns@powerplant.com above) or an external user (kent.brockman@news.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 burns@powerplant.com using Outlook to send through his local Ms Exchange server, Outlook would authenticate as burns@powerplant.com and allow him to send the email. But burns@powerplant.com could not authenticate as burns@powerplant.com and then enter kent.brockman@news.com 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 alerts@company.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 (liquidfilesrelay@company.com) 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.