04 January, 2016

Use ownCloud provided Packages, then VM, then Zip, no distro packages.

Last week I wrote a blog about why running an old ownCloud release isn't more stable and you should upgrade. There are many ways to install, run and upgrade ownCloud. What is best depends on your situation but some general rules of thumb can be given.

Use ownCloud Provided Packages If You Can

The best solution from a security and stability point of view are the official ownCloud packages, provided you have the basic know-how needed to run your own Linux server.

Packages give you the advantage of a relatively clean and easy upgrade process, with the ownCloud team taking care of any special steps which have to be taken. The upgrade itself will still have to be kicked off by the system administrator (see our latest update) but you won't risk forgetting to remove old files, correcting file permissions and so on.

We do not recommend using distribution packages, for several reasons:

  •  First, there will inevitably be a lag between what distributions ship and what we make available.
  •  Second, it happens that distributions don't grab the right code (like relying on a git tag rather than final zip files) or miss changes in dependencies which can break installations.
  •  Third, many distributions are reluctant to upgrade to newer ownCloud releases, which means you can get stuck on older versions. While security fixes are often still back ported, being on, say, ownCloud 7.0.4+dfsg-4~deb8u3 means you have missed out on many ownCloud fixes and improvements. And of course, they continue to ship major server releases and ownCloud client versions until long after we've abandoned them.
  •  Four. Not offering the latest ownCloud bugfix version also means upgrading can become a tricky problem: we recommend to upgrade to the latest bugfix version in a series before upgrading to the next for a reason. ownCloud 7.0.12 will contain bugfixes related to the upgrade to 8.0.x, fixes for problems you might run in to when you try to upgrade from your distribution's older bugfix release to a new major release. On top of that, our upgrade code looks at the ownCloud version to know how to upgrade - good luck if you run a Frankenstein version. Also, we don't support skipping ownCloud releases on upgrade. So once you're ready to upgrade your distribution with ownCloud 7.0.ancient to a new distro with ownCloud 8.2.shiny, well, it won't work.
  • Last but not least. The distribution packagers try to do weird shit, shoehorning ownCloud (and other web apps) into their rules made for C/C++ apps. You'll find packagers trying to move the ownCloud configuration php file out into the /etc folder or split up ownCloud core in separate packages because we maintain some external components as part of our setup. Of course, this breaks in beautifully surprising ways and provides few if any of the benefits they are hunting for. It is also a performance issue. And problems will only get bigger with the upcoming code integrity checker.

I blogged on owncloud.org about the issues with distribution packages (and the distribution model in general) earlier.
"the misguided policy of not updating to even bug fix releases which some distributions have is nothing but harmful for users"
The last of the five points, distributions struggling with projects which don't fit their rules, leads to things like Iceweasel. If you're new to the world of Linux distributions, this is a tale you'll love: on Debian and perhaps soon, Fedora, Firefox is named Iceweasel. Debian does not want to update software because "that would break stuff", instead, they forked Firefox to backport security issues. I'll leave it up to you to decide how secure it is to have packagers 'maintain' software long after the project itself has moved on...

Of course, it also leads to changes coming in big chunks - we've learned that users adapt to changes far better and easier if they come small and regular. That is why mobile apps and many websites introduce changes in an Agile way. ownCloud and linux desktop KDE also increased their release speed for this reason.

I understand the reasons behind the rules and sometimes it has a pay-off which is worth the extra effort. But, as always when things are taken to an extreme, it is now blocking distributions from adapting to 2016 and onwards. The result is that technologies like Docker and the sandboxed apps the GNOME and systemd teams are working on will make much of the distributions irrelevant. A future distro will be a small base on which you run some kind of application image which comes with its dependencies built in. Is that the most secure solution, perfectly disk-space or memory efficient? Perhaps not. But by chasing perfection, distributions failed to attain good-enough.

Anyhow, enough rambling, let's talk about what to do if packages don't work for you.

Use a VM if a Server is Hard

Not everybody is comfortable on the Linux command line and while there is excellent documentation on running and securing a Linux server, it might make perfect sense to go for the Virtual Machine option. Since ownCloud 8.1 we've provided official ownCloud VM images and there are also several third party images available. This way, you get a server installation which has been set up by our experts to be secure out of the box. Upgrading and responding to immediate security threats is still in your hands but we've done what we can to make it easy.

Use Zip Files or Installer if all else fails

On some systems, like cheap hosting or a NAS, your control over the system simply does not extend to the installation of packages or running a Virtual Machine. Then, the zip files (or, for convenience, the installer) are your last resort. While the zip file is easy to use ("just extract and go"), it requires special upgrade attention which might discourage you from staying up to date. And that introduces a security risk! Also, doing the upgrade process from the web UI has limitations and risks on large installations.

Now you've learned why you should upgrade your ownCloud and what installation method to use. Time to get started!