A Day In The Cloud – Connecting The iPad To The Cloud

Introduction

We’ve all seen how much Apple loves the cloud and heard about their plans to finally tackle cloud storage. But that’s not here now, nor will it be an open system when it does appear. Let’s face it: anything Apple does about the cloud, it’s going to do on its own terms. Then they will tell the fanboys it’s because nobody has done the cloud right until Apple did.

Thankfully all is not lost for those of us with the knowledge and will to do something about it. Today’s Day In The Cloud is about getting the cloud into the iPad in a way that lets you leverage whatever service you want. There are a number of things to do to achieve this, so let’s get to work.

Requirements

I’m going to assume you have some things already in place, i.e.

• A home file server, preferably running OS X or Linux. This guide should work for Windows as well, but was written based on my home setup, which uses a Mac Mini.
• A cloud storage account that ties into the file system on a computer. I used Dropbox because I currently pay for it. But SugarSync might be a better option, if you aren’t already hooked on a particular service.
• A decent Internet connection, with at least 1 Mbps upload or faster being ideal. 768 Kbps upload (typical on DSL) is the bare minimum, and will make transferring larger files take too long.
• A router that supports PPTP VPN. This can also work with any router by using port forwarding. But VPN provides security without a lot of server configuration hassles, and PPTP is easy to set up. I have used both pfSense and Astaro, but any of the major distributions should work.
• An understanding of how web servers work, specifically the Apache Web Server.
• A comfort level with the command line. Windows users should be able to avoid the CLI entirely, but I make no guarantees.

You can see from this list that this procedure isn’t for everyone. But the results are worth it, if you’re up for the challenge.

The WebDAV Server

WebDAV was originally designed as an extension to standard HTTP to get over the hurdle of using FTP to update websites. WebDAV is engineered to allow multiple users to concurrently access the same fileset without stepping on each other’s toes.

WebDAV has surprisingly good support for iOS. Apple’s Pages on the iPad has native support for WebDAV and is what I use when I’m writing articles while traveling without my laptop. There are also some good free apps, and even better paid apps that are WebDAV clients allowing you to download, edit files and re-upload files.

So let’s get down to business with configuration. I’m assuming you’ve already installed Apache’s HTTPd (hereon called the web server) if your system requires it, and can at least browse to http://localhost and view the test page. If you’re using Windows and need to install Apache, go grab it from here and run through the installer. If you’re on Linux, I’ll just expect you’re knowledgeable enough to keep up .

And just in case you want to use IIS, just Google IIS WebDAV. There are plenty of articles for the different versions of IIS. It will work just the same.

Enable WebDAV

Setting up WebDAV couldn’t be easier. Once you have Apache installed and working (on OS X, make sure you enable Web Sharing in System Preferences -> Sharing), you can just edit the single httpd.conf file to enable it. Now on many modern *nixes, like OS X and Ubuntu, that file has been split apart and uses includes to try to keep the individual files manageable.

On OS X, the first file we need is /etc/apache2/httpd.conf. Edit this using your particular editor of choice. I’m a vi guy, so my command would look like sudo vi httpd.conf. Sudo is needed since everything is owned by root in /etc.

Once you’re in the file, search for the line that looks like the following:

LoadModule dav_module libexec/apache2/mod_dav.so

and make sure it’s not commented out (with a # in front).

The next line we need looks like this on OS X:

Include /private/etc/apache2/extra/httpd-dav.conf

It should be towards the bottom of the file, and is disabled by default. Enable it, and we’re done in httpd.conf!

WebDAV Configuration

Next, we need to edit that httpd-dav.conf file we just enabled. Since we’re already in the apache2 directory, just change directory into the extra directory, and edit that file, remembering to sudo again. On OS X, the default file should look like this:

#
# Distributed authoring and versioning (WebDAV)
#
# Required modules: mod_dav, mod_dav_fs, mod_setenvif, mod_alias
# mod_auth_digest, mod_authn_file
#
# The following example gives DAV write access to a directory called
# "uploads" under the ServerRoot directory.
#
# The User/Group specified in httpd.conf needs to have write permissions
# on the directory where the DavLockDB is placed and on any directory where
# "Dav On" is specified.
DavLockDB "/usr/var/DavLock"
Alias /uploads "/usr/uploads"
<Directory "/usr/uploads">
Dav On
Order Allow,Deny
Allow from all
AuthType Digest
AuthName DAV-upload
# You can use the htdigest program to create the password database:
# htdigest -c "/usr/user.passwd" DAV-upload admin
AuthUserFile "/usr/user.passwd"
AuthDigestProvider file
# Allow universal read-access, but writes are restricted
# to the admin user.
<LimitExcept GET OPTIONS>
require user admin
</LimitExcept>
</Directory> 

You can go ahead and delete everything after the DavLockDB “/usr/var/DavLock” line.

As noted in the Requirements, you should already have a cloud storage provider account, because we’re going to need some information from it shortly. If you’re not set up, go do that now, because next we’re going to edit httpd-dav.conf to point to a folder associated with your cloud provider.

Here’s what my configuration wound up looking like (added after the DavLockDB “/usr/var/DavLock” line):

Alias /dropdav "/Users/*USERNAME*/Dropbox"
<Directory "/Users/*USERNAME*/Dropbox">
Dav On
Order Allow,Deny
Allow from all
AuthType Basic
AuthName WebDAV-Realm
AuthUserFile "/usr/webdav.passwd"
<LimitExcept GET OPTIONS>
require user *USERNAME*
</LimitExcept>
</Directory> 

Explanation time! Anywhere you see *USERNAME*, replace it with your true username on your computer. On Linux, you can replace /Users/ with /home/ in most cases. Windows Vista & 7 also use /Users/ although you might have to use C:\Users\… in order to get Apache to traverse the path correctly.

The alias line makes it so http://localhost/dropdav will traverse the file structure correctly to your cloud folder, without you having to type the path in, or jump through a bunch of configuration hoops.

The stuff between the Directory tags sets up all of what we need to get WebDAV working. As you might have noticed, I switched the AuthType to Basic from Digest, due to compatibility issues with some programs and Digest.

Apples’ Pages supposedly doesn’t have this problem. But since I connect over a VPN, having passwords sent in clear text isn’t an issue.

If you are going the port-forwarding route, keep the Digest option and follow the instructions in the original file to create the username / password file.

Speaking of usernames and passwords, that’s it there in the AuthUserFile directive. I left it in its default place to keep it away from other OS X users on the system. But on Linux, you might want to find a better hiding spot since a lot of stuff lives in /usr/.

Finally, we require the username to be used inside the <LimitExcept> tags. That username must exist in the password file.

Final Setup

Now that we’re done setting up the web server, let’s set up all the dependencies. First we need to create a username and pasword:

sudo htpasswd -c /usr/webdav.passwd *USERNAME*
New password:
Re-type new password: Adding password for user *USERNAME*

Next we need to create the directory that will house the WebDAV server required files:

sudo mkdir -p /usr/var

Next we need to set up permissions. This is a two step process, first on the command line using the following:

sudo chown -R www:www /usr/var sudo chgrp www /usr/webdav.passwd

followed by setting the Dropbox directory so the webserver has read/write access to it. This will differ for each system. I’ve shown the GUI tool in OS X:

I’ve given everyone read and write access. This gives the web server complete access to your Dropbox folder. Don’t forget to click the gear icon and apply to enclosed items if you have existing items already. Newly created folders will inherit these permissions.

Trial Run

Now it’s time to really try out the system. In OS X, go into System Preferences->Sharing and toggle the Web Sharing checkbox, or execute the following command:

sudo apachectl graceful

to restart Apache and make it pick up all the changes.

Once there, you should be able to go to http://localhost/dropdav/ in your favorite web browser and get an error like the screen shot below:

The Forbidden error is because most web browsers won’t send the proper credentials to the WebDAV server, so you can’t view the file list.

You’ll need an actual client to access the WebDAV share. On OS X, you can use Cyberduck, or simply use Finder by opening a new window, and clicking Go in the top bar, followed by Connect to Server. Type in http://localhost/dropdav/ and it will either use information found in your keychain or ask for a password.

Windows folks can give NetDrive a shot for WebDAV connectivity, but I haven’t tried it.

Conclusion

We now have a WebDAV server pointing at (in my case) a Dropbox cloud folder that is accessible over the local network, and also a PPTP VPN or the web if you choose to port forward the server to your public IP address. In either of those cases, I’d recommend setting up DynDNS in pfSense so that you will have a simple URL to VPN to.

All that remains is downloading a WebDAV client on your iPad or iPhone and connecting. I’ve had good luck with WebDAV Navigator. But there are a few other solutions as well. Pages also supports WebDAV natively, so if you just want to edit documents, that might be a way to go. Any resulting changes will be immediately cloud stored.

This exercise shows that Apple’s closed system makes it really tough to do something simple like access your own files in the cloud. Android isn’t much better if you want to use cloud providers other than Google. But it is better at letting applications share and back up data.

It will be interesting to see how it pans out this year when Honeycomb becomes more widely available (and less buggy) giving Android tablets their first real tablet OS.