Replacing Big SaaS - How to cut the Google, Apple, Dropbox, Microsoft, ... cords

With a Prism and Snowden inspired kick in the backside I finally got around to establishing some autonomy from the Big Boys with respect to email, contacts, calendar, network storage/sync and other common personal use SaaSs.  No rocket science here, just a consolidation of lots of "which one is best for me" research, "follow the tutorial" efforts and Google and log file problems/solutions to explain how to install, configure and maintain the types of services you get "for free" from Google, Apple, Dropbox and the rest.

This article is an overview of how to accomplish replacing the important Big SaaS, it is not a detailed step-by-step with every command listed.  I reference a number of other web pages and tutorials to help with the harder parts.

Overview

Here is a basic overview of the substitutions:

Service	Before	After
Hosting and OS	Google, Apple, Microsoft, Yahoo, ...	Digital Ocean "Droplets" Linux
Email	Google, Apple, Microsoft, Yahoo, ...	postfix, dovecot
Contacts	Google, Apple	davical
Calendar	Google, Apple	davical
Network storage and sync	Dropbox, Copy, Google Drive	ownCloud

The aspirational criteria I had for the substitutions were:

• Open source
• Supported with apt-get or similar installer with an up-to-date stable version available
• At least some recent community activity and support
• Positive reviews, particularly as versus their popular commercial alternatives
• Free or close to it
• Targeted solutions, not one package that is providing many services (e.g., MS Exchange vs Postfix)

It's also important to keep in mind that these solutions generally won't be as good as their popular commercial alternatives where armies of developers and systems administrators support them and taking advantage of big economies of scale and underpricing.  To take this path you're going to forfeit convenience, better usability, rock solid systems and uptime, macro level security, and "free" pricing for greater privacy and control.

Lastly, there are many more areas that could be substituted and I've not done or written these up yet - I note at least some of them at the bottom of article.

What's Required From You

You have to be able to do the following to get this working:

• Basic Unix shell commands and configuration file editing
• Willingness to read various tutorials and how-tos and be able to google for the rest
• Willingness to pay $5 per month for hosting and another $1 per month for backups
• Accept having a total data footprint of 15GB or less (or be willing to pay for more storage)
• A basic understanding of SSL certificates is useful

1. Create an SSH key

Follow Digital Ocean's tutorial to create your own key.

2. Have a domain name ready to use

There are many companies that offer domain registration.

3. Hosting

Set up an account with Digital Ocean (digitalocean.com).  Their basic IaaS virtual server ("Droplet") is cheap, plenty performant for our uses here and their management and provisioning interface is pleasantly usable.

Buy the cheapest cheapest droplet at $5 per month (1 CPU, 512MB RAM, 20GB Disk, 1TB transfer).  This will provide plenty of horsepower and space for the average user.

You might select "Amsterdam" as your region if you thought that might provide a safer environment for your data as opposed to hosting that is based in the USA (Digital Ocean's other sites are in New York and San Francisco).

Select OS "Ubuntu 12.04 x64".  You could probably safely use the newer versions, I've just not moved up to them yet.

Install the SSH certificate you created in step 1.

Enable "VirtIO" if you want.  Whatever it is.

After your new virtual server is created, activate automatic backups for it.  They may only be taken about once per week but they're a bargain at $1 per month.

Set up your new domain name to point to your new droplet IP address.  Digital Ocean's DNS interface is easier than godaddy's.  Configure your domain to use Digital Ocean's DNS.

NOTE: The only thing I don't like about Digital Ocean for hosting is there is no apparent way to cost effectively scale just disk size.  I'd like to keep the memory and CPU of the smallest instance but then easily scale up disk space.  Replacing network storage and big IMAP email archives will exceed the 20GB limit for "power" users.  There are plenty of other providers and some allow a low-performance-high-disk-space specification.  However, among the usual suspects like Amazon and Rackspace along with a number of others I found googling around, I didn't find any in the same price range as Digital Ocean.  Maybe Digital Ocean will add the feature of cost effectively adding disk space only in the future.

4. Basics

Verify you can log in as root using ssh and the ssh certificate you created.

Restrict root login to only allow certificate based logins.

Create a new user that you'll use to do most work from here forward.

Enable new user for sudo use.

Install zsh (or your preferred shell if its not already present) and make it your default shell.  Update your login shell preferences.

Create/deploy another ssh certificate for the new user you've created.

Install ntp.

Install iptables as your firewall.  Digital Ocean has a good tutorial. 

5. Supporting applications

Before we get to the applications we want, we have to install their supporting applications.

Install postgres - used by davical

Install MySQL - used by ownCloud

Install Apache and PHP - used by almost everything

Install phppgadmin - used to administer the Postgres / davical database

Install phpmyadmin - used to administer the MySQL / ownCloud database

6. Create a free SSL Certificate and install it

The certificate will be used by a number of services we install.

Use this tutorial at arstechnica to create a free Class 1 SSL certificate with startssl.com.

Tips:

• startssl.com creates an S/MIME and authentication certificate and automatically installs in your browser.  You might want to save the authentication certificate someplace secure.
• Certificate only good for one year - just remember you need to renew it each year (all your services dependant on a valid SSL cert will stop working when cert expires)

7. Email

Note: I don't typically use webmail, so I didn't bother installing a webmail service.

Install postfix - see Digital Ocean tutorial

Install dovecot - also see Digital Ocean tutorial, my user comments on dovecot

Update DNS MX record.

Adjust iptables firewall settings - see Digital Ocean tutorial

Tips:

• I found "apt-get install mail-stack-delivery" did the heavy lifting for me here.
• Make sure you un/comment out exactly what you want in /etc/postfix/master.cf
• Increased value of mail_max_userip_connections from 10 to 30 in /etc/dovecot/conf.d/01-mail-stack-delivery.conf due to an IMAP error limit popping up in OS X mail.
• Digital Ocean has subsequently created a tutorial for iRedMail - looks easier to set up and includes a webmail interface

Note: not added in spam filtering yet.

8. Contacts and Calendar

Install davical.

I looked at and discounted the following:

• calendarserver - depends on extended file attributes; apt-get exists but doesn't appear to be maintained
• radicale - no backoffice, feels too barebones
• baikai - No apt-get; synology's choice for their sync app
• ownCloud - ownCloud already looks bloated

9. Network storage and sync

Install ownCloud.

The goal here is secure and pervasively available files.  Like Dropbox and the paid version of BoxCryptor - both of which are closed source and therefore non-starters with my stated criteria.

You can create an encrypted filesystem on your main OS, ideally once that can be used by several OSs and place the system in ownCloud network synced storage.  When choosing an filesystem, it's important that the encrypted filesystem is in separate files or some type of chunks, not one big blob (like truecrypt) as big blobs don't sync well when you have concurrent clients syncing.  Ideally you want a filesystem that encrypts file names, content, and inode structures separately in small efficient pieces.  While interesting, I'm seeing enough limitations and sync problems with OS X's encrypted sparse bundle approach that I don't recommend it (use EncFS if you can; else use BoxCryptor even though its closed source).

iOS and Android Support

The above approach is fully supported by iOS and Android devices using standard protocols:

• Managing email via Secure IMAP
• Sending mail via Secure SMTP
• Calendar via calDav over https
• Contacts via cardDav over https
• Network storage and sync via ownCloud iOS/Android apps; runs over over https

This probably goes without saying, but assume you'll lose your device at some point.  Think about what is on the device and how easy it is to access it.  Do you use a PIN with a self-destruct after so many incorrect entries?  Do you have logins and passwords in Contacts or Notes files?

Maintenance Notes

You will have to renew your startssl.com security certificate each year.

Spin up the occasional backup on another droplet to verify backups and the restore process works.

Security Notes

Nothing is 100% secure.  The approach I've presented here has two big problems:

• Hoards of security specialists at the big companies will collectively know more about security than you or I ever will.  Security exploits of fairly new and not widely used applications like ownCloud and davical are possible.  You're therefore effectively trading off having thousands of staff at the big SaaS providers or the government having access to your data vs relying on common sense security basics to stay safe.  In this case, we've done the basics:
• We're running the iptables firewall with only the bare minimum of ports open
• All coms over SSL
• We're not storing the actual data on the server in an encrypted format.  Ideally we'd use an encrypted filesystem on the server so that the hosting provider couldn't snoop disk data.  Of course, decrypting "on the fly" as applications access the encrypted disk is also a risk, but without using your own secured physical server you are stuck with that problem.

I've not yet installed openvpn.  Could switch access to potentially vulnerable apps like Davical's backoffice, phpmyadmin, phppgadmin to VPN only access.  I did add in .htaccess/.htpasswd files across the backoffices for slightly better security.

Lastly, this is pretty obvious, but use long passwords with lots of variation between passwords and a mix of letters (upper/lower), numbers, and symbols.

Conclusion 

Google, Apple, Dropbox and others provide a great no/low cost option for services like email, personal information management and network storage.  Signing up for an account with Google is a lot easier and cheaper than the approach outlined above.  You get most of these services "for free".  So if the thought of Google, Apple, Dropbox and others reading your emails and documents and enabling governments to do likewise doesn't bother you at all, then by all means use their free services.

However, if you think you have a right to personal information privacy without business and governments having the ability to read it then you might want to consider implementation of the approach in this tutorial.

What have I missed and what has worked well for you?

Nipping at Dropbox's heels

There is a real resurgence of cloud storage taking place since Dropbox first launched some years ago and quickly rose above (and for the most part crushed) its competition at the time.  I'm going to highlight what I thought was going on earlier in the year, what's happened since then, and then highlight two new services.

Earlier this year I wrote about p2p file sharing as a threat to Dropbox, particularly the Cubby service.  The problem is, Cubby got their pricing model wrong (you have to pay for DirectSync, their p2p product) and haven't changed it.  Too bad for them, they'll never compete successfully with Dropbox in this way.  I don't expect them to disappear any time soon, but I do expect them to idle along as a bit player in the cloud storage space.  However, if they switched their Directsync feature into their "Basic" (freemium) package and focused on a pay model of central mirrored/subset storage for backup and faster syncs of critical data, it could still be a different story.  But probably not for much longer.

I also looked at BitTorrent Sync earlier this year.  I had various issues with it and while I like it, and ultimately lost trust in it due to regularly disappearing files from a folder I had under test between several machines.  I no longer use it although in the right circumstances I might still use it (e.g., mirroring a lot of content between multiple locations for a limited duration and easily verifiable results).  I continue to think that BT Sync will remain in the tech fringes for now - they will continue to be hampered by the need for a central server (is the server really secure?!), shared secrets approach (who can see my secrets and my files?!) and lack of open source (what am I really installing on my box?!)

Two interesting things have happened since then in the cloud storage world:

1. A new service called Copy has been making the rounds.  The good news is that you receive 20GB up front (if you activate your account through a referral link; otherwise you receive 15GB for direct signups).  This is 10x more space than Dropbox's upfront free 2GB of space.  I'm using Copy a lot now rather than Dropbox.  Copy has built their own infrastructure rather than using Amazon's AWS as Dropbox has done, I'm assuming that's given them much better cost structures and allows for this much greater level of freemium marketing. After a few weeks of testing, I switched to using it actively.  I've now been using it for a few months, no issues.  [Disclosure: If you click the links above you get 20GB rather than 15GB because its a referral and yes I get free space for the referral - thank you very much!] [Postnote: Warning! See comment below]
2. On the p2p storage side I stumbled on ownCloud.  I have it running on my own cloud IaaS server (Digital Ocean - working great and dirt cheap at $5 per month for a basic server instance) and have a few nodes connected to it.  It feels clunkier than Dropbox and Copy, but it does seem to work and most importantly, it's free! I'm testing it now and haven't switched to using it as a primary cloud file store yet.  [Note: I've only used at as network storage, not for Contacts and other features.]

Last thing to note - I've given up on BoxCryptor and moved on to using an OS X Extended/Journaled 256 bit AES, sparse bundle disk format on each of these cloud services.  I've had to give up multi-platform access that came with BoxCryptor but on the positive side I'm not paying a yearly subscription to BoxCryptor and I have filename encryption as well.  I'm currently testing volumes in Dropbox, Copy, Google Drive and ownCloud, so far so good with all of them. [Postnote: read comments for a pain point on this approach].

So that's how things look in August 2013 for best practices in cloud storage:

• Use Copy.  It works.  Much more storage for free.  Good for non-technical folks.  Or just keep using Dropbox if you have enough storage with them and/or don't mind paying for your storage.  [Postnote: Warning! See comment below]
• If you're technical enough, use ownCloud on your own server.  It looks viable for a do-it-yourself if that's important to you and it's opensource as well.
• If you're technical enough, value security, and don't need multi-platform access to your files, use an encrypted multi-file filesystem like OS X's sparse bundle format to store your folders and files [Postnote: see comments].

A Closer Look at BitTorrent's SyncApp

A few hours after publishing my previous blog article on p2p File Sharing - a Dropbox Killer?, I was very proactively contacted by Kos Lissounov, in charge of development for BitTorrent Sync.  I received a SyncApp tester invite and was able to test-run the product on three devices in a sync group (2x OS X, 1x Windows 7).  Kos and I also had a good and professional back-and-forth of emails and he provided thoughtful answers and comments.  It wasn't my intent to dive down the rabbit hole with SyncApp and BitTorrent security models, but some hours later...

I'm pleased to say that the "pre-alpha" version of BitTorrent SyncApp worked fine for it's main purpose at this point - quickly move around lots of files and data between a specific group of devices.  In particular, bringing a third device into the share group (all on same LAN and nicely linked together - no need to hit the cloud to download files) during my tests ran even faster with two sources of data available to bring the third device into sync.

However, to clarify the key assumption I had when writing the p2p File Sharing - a Dropbox Killer? article:  Can p2p sync replace my day-to-day use of Dropbox, but with unlimited data and at much less cost or for free?  Implicit in that assumption were all the usual points of comparison in the back of my mind: features (vs Dropbox), Just Works (stable), cheaper (for big data sets under sync), faster, more reliable, better usability, more secure, etc.

Based on this, here are a few additional comments about Bit Torrent SyncApp:

1. Empty folders are not synced.  Per Kos, this deficit is recognised and will be added.
2. Version conflicts are simply ignored.  However, rather than warning or in any way indicating a conflict, the client just silently ignores the conflicted file.  Version conflict management is apparently tough to implement.  I don't think any type of merge function is required, but I do think a visual warning and changing file names to highlight the conflict is.  Just imagine the issues trying to unpick file conflicts inside of BoxCryptor's "Package" folder with silent failure and removal of a single file from synchronisation...
3. Their is no API yet.  One could imagine an app simply accessing SyncApp folders via the filesystem on bigger devices (no API required) and using a secret to access a set of folders/files on a mobile device via an API.
4. Usability is generally a big deficit.  Features like iconic representation of sync state (as done by Dropbox) in a Finder and File Explorer window aren't present.
5. A "relay" server is required to connect devices via shared "secrets" if the devices are not on the same network and if the peers haven't otherwise previously communicated with each other.  Of course, if one device is a phone or laptop with regularly changing network parameters (on the move between networks), the relay will have to be used to link up the devices.

Items 1 and 2 above for me are showstoppers if my use case is to replace Dropbox with SyncApp.  Items 3 and 4 are painful, but might be tolerated for awhile.  Item 5's relays and "secrets" is tricky to judge because I don't fully understand the security implications.  Let's drill into relays and secrets a bit more.

Relays are a key enabler of the BitTorrent SyncApp approach.  They perform the following functions:

1. Recommend (not approve if I understand the protocol correctly) the sync of a folder/file set between devices by seeing identical encrypted secrets and recommending the two devices sync with each other.  The two devices must still directly authenticate each other (without the relay involved) - the specifics of this authentication are unknown to me.
2. Facilitate/broker communication between devices that can't otherwise discover or communicate with each other that have the same secret - deal with firewall issues just as BitTorrent clients do today.
3. Relay (SHA256 encrypted) information between two devices if the two devices can't otherwise send information between each each other.

Relays do not see any unencrypted data.  They do see and manage SHA256 encrypted "secrets".  Relays store all their information in memory, nothing is persisted to disk.  If the relay goes down then the secret relationship between devices may have to be rebuilt (depends on the device to device access and what specific functions the relay was required for in a given setup).

The concept of the shared "secret" is interesting.  It is a way to enable devices to join in a group to share content.  It has a similar feel to a Bluetooth PIN that is asserted by one device and entered by the other to allow communications between them.  Each folder (and subordinate folders and files) has a unique secret.  Relays (for now a public/shared one run by BitTorrent) are used to coordinate devices with the same secret that can't otherwise find and/or communicate with each other.

I can see two security holes with the "secret" approach:

1. A secret could be sniffed from the wire and used by a malicious SyncApp client to attempt to join a group of devices with the same secret.
2. The relay manager (for now the BitTorrent company) could manually insert malicious devices into the relay's device management system.

Kos clarified that the secret is encoded via SHA256(SHA256(secret) - therefore the password (or "secret") is stretched but not salted.  Also that it would be possible to get a list of peers but in order to join a sync group you would have to decrypt the AES256 handshake with the peer with the key SHA256(secret).  Again, I don't know the details of the protocol that engages between the two devices to actually approve joining a sync group so actual joining may be blocked.

Regardless, I remain uncomfortable with the security provided by the "secret" approach as it is today without fully understanding the protocol and implications.  This is also a showstopper for me with respect to using SyncApp to replace Dropbox at least for sensitive information.

Kos indicated a "Should device X be allowed to join this group?" a challenge will be added to SyncApp in the future to help address security concerns.  People/companies can also run their own relays meaning that they can control everything for their sync groups.  However, I think without a central service (relay or otherwise) to provide authentication and authorisation for users, devices, and secrets the product will remain limited from a usability and security perspective.  The Bit Torrent company's obsession with fully distributed, no-master, p2p approaches may really limit long-term market acceptance due to usability and security limitations.  I believe it will also limit their ability to see product adoption beyond a technical community (in which it may excel, just as it has with BitTorrent itself) and in turn be unable to monitize the product.  Even if BitTorrent did put in a central auth server (and even nominally charge for it to make money), would it be trusted given their brand position?  This is where products and companies like Cubby and Skype may have an advantage.

Even more than before, after this review of BitSync I think services like Dropbox, Box.Net, and Skydrive will struggle to compete with p2p sync as their whole business model is tied up in users consuming and paying for cloud disk space.

One use case for which BitTorrent SyncApp excels today is for a fairly technical user to simply keep a group of media files in sync, for example a photo archive on your laptop while you're on vacation being synced (automatically backed up when you have an Internet connection) to a PC running at home.    None of the above issues hold back adoption of SyncApp today for this use case.  In fact, switching to SyncApp for bulk media and other big files (e.g., install images, video, audio) and using Dropbox just for docs and simple workgroup collaboration is a good possibility for me once I'm comfortable SyncApp is sufficiently stable and Just Works.  Of course, even if SyncApp or another similar p2p product closes the feature gap with Dropbox, I still couldn't eliminate Dropbox completely because their first mover advantage is incredible and they are really bedded into the Way the Internet Works now.

If SyncApp can get past their "must be p2p only with no central auth server and keep track of nothing" view of the world and add in some of the features I've covered in this entry, I think it could become a viable Dropbox killer and be meaningful part of a "post cloud" Internet world.

Tightening the Definition of SaaS and Cloud

I've recently been exposed to two vendors offering "cloud" and "SaaS" options to replace two in-house legacy enterprise/corporate (not customer facing production) systems.

In this process, I connected some mental dots that there are really a few flavors of SaaS, and the distinction is quite important with respect to enterprise architecture.

The two service offerings can be roughly thought of in this way:

• The offerings were touted as SaaS and cloud
• New software that is better than our current in-house legacy systems (regardless of whether we host or they are "in the cloud")
• The software is hosted by the software provider, unknown what type of "cloud" IaaS is under that provider, if any (perhaps just virtualization in their own DC).
• The software instance is spun up by the provider specifically for us.  It is a copy of the software, dedicated to us.
• The software can be extended a lot - add-on modules can be activated through configuration changes, bespoke modules/code can be added.  Kinda-sorta like a pick-and-mix or evolving PaaS model
• Software upgrades must be rolled out with associated consideration of any bespoke changes that have been made.
• Security restricted to only be available within your corporate intranet
• Flat monthly rate per user charging model with volume (# of users) price breaks

As the two service reviews went on, the dots finally connected, and I realized I had been *marketed* too more effectively than I'd like to admit.

The above isn't "cloud" or SaaS, at least not with the definition I'm going to take here.  It is actually a hosted managed service offering (MSP or ASP).  At best it's a halfway-house to cloud and SaaS.  All you've really done with this approach is shift some techops and infrastructure responsibilities from in-house to the service provider and reduced your in-house economies of scale (assuming you have to maintain those skills).

For something to be a cloud/SaaS offering in my terms, here is what it needs to be:

• Public Internet facing
• One centralized installation shared by many customers
• Powering the service is an IaaS
• Can quickly scale up/down with virtually no cost to make the change (costs changing proportional to increased/decreased usage)
• Horizontal fault tolerance design (HW redundancy becomes irrelevant)
• Focused offering
• Service addresses a specific functional requirement, it isn't an omnibus offering
• Vibrant user community making suggestions of how to improve the product
• Quick time to market for new features
• Strong product management and vision
• Product improvements put live appear immediately for all customers
• One exception: "beta" version may be option in by the customer, but certainly under the customer, not vendor, control  
• No rolling upgrades for each customer once a new release is ready
• A complete set of APIs ("API as a storefront")
• Almost all functionality available via the application is available via API
• Well documented
• Hardened (API security, rate limits, et al)
• Ready for mash-up integration with other focused offerings
• Usage based billing
• Proportional to amount of computation, storage, and connectivity you use (IaaS transparency)
• Additionally factoring in the value of the SaaS itself
• No billing related to seats, users, or CPU cores

In noting the difference between the two, I'm not advocating one or the other.  The choice of course depends on circumstances and strategy.  I'm also making no effort to address the common enterprise concerns of cloud such as security, data ownership, and business continuity.  However, I do have a very strong view which way the IT world is going and given the choice, I know which I'd select.