[owncloud-devel] WD Challenge Proposal - archlinux/btrfs/docker/avahi/rsync

Morris Jobke morris at owncloud.com
Wed Dec 16 10:25:17 GMT 2015


I have to second Daniel here - really great proposal :)

Kudos to Petros :)

Morris

> Am 15.12.2015 um 10:41 schrieb Daniel Hansson <enoch85 at gmail.com>:
> 
> I must say, this was the best proposal yet. Great writeup!
> 
> /Daniel
> 
> On 2015-12-15 09:29, Petros Angelatos wrote:
>> Hi all,
>> 
>> This is a great initiative, I really like it. Having an easy way of
>> setting up something like this is key for adoption. I'm writing this
>> proposal because it coincided with my intentions of building an
>> OwnCloud setup on a Raspberry Pi so it seemed a good idea to share my
>> design.
>> 
>> A few words about myself. My name is Petros. I am a founder and CTO of
>> Resin.io, a platform that allows you to deploy and manage containers
>> on embedded devices. We've done work to support multiple SBCs and even
>> more beefy machines. Some of them are the Raspberry Pi {Zero,1,2},
>> ODROIDs, Intel Edison, and Intel NUCs. I have worked extensively with
>> linux, from embedded devices to servers, have experience in
>> networking, filsystems, systemd, Yocto linux, kernel configuration
>> etc. My language of choice is nodejs with which I have developed a
>> number of backend services. I'm also interested in security, privacy,
>> and keeping control of one's data, which is my main motivation behind
>> this project.
>> 
>> Overview
>> ========
>> 
>> The design consists of two parts.
>> 
>> 1. A very minimal host OS, whose job is to boot up the board, mount
>> partitions, start network services, setup clock etc
>> 2. A Docker container containing the OwnCloud application
>> 
>> Having the application in a Docker container means we can package all
>> the dependencies in it and be sure that it will run correctly. It also
>> makes updates a breeze since it's a matter of `docker pull` and
>> `docker run`. Finally, the OwnCloud Raspberry Pi image will not be
>> specific to this project. This means that someone with a Raspberry Pi
>> running Docker could easily add it without needed the host OS proposed
>> here.
>> 
>> All decisions bellow are made with the performance profile of the
>> Raspberry Pi 2 in mind.
>> 
>> Operating System
>> ----------------
>> 
>> The obvious choice for the Raspberry Pi would be the raspbian
>> operating system. However, I propose using ArchLinux ARM for this
>> project. There are a few reasons for this choice.
>> 
>> 1. Arch linux is very minimal which will help us achieving fast boot times
>> 2. Packages are updated constantly (rolling release)
>> 3. Includes a docker package in its official repos. Who likes random
>> pre-built binaries :)
>> 4. Familiarity with it since I've been using it for long time myself
>> on servers and laptops
>> 
>> Filesystem
>> ----------
>> 
>> For this setup, I propose using ext4 for the root partition that will
>> be on the SD card, and btrfs for the 1 TB hard disk that will hold the
>> data.
>> 
>> The reason for choosing btrfs is its checksum and snapshot support.
>> Since a lot and important data will be stored on this system, it is
>> vital to detect when the data went bad and repair them, even if a
>> single bit flipped [1]. Arch linux comes with systemd monthly timers
>> that scrub the btrfs partition and repair/report any corrupted data.
>> Additionally, btrfs snapshots can be used for easy, consistent
>> backups. First take a read-only snapshot of the data partition, rsync
>> it to the backup location, delete the snapshot.
>> 
>> As someone else on the mailing list mentioned, Raspberry Pis can
>> corrupt SD cards if the SD cards are poor quality and the Pi isn't
>> powered down properly. In order for this to be a reliable system the
>> power supply must not create any spikes or weird power input during
>> start up and power down. We don't want bits flipping on the SD card.
>> 
>> 
>> Setup without requiring the monitor/keyboard
>> --------------------------------------------
>> 
>> I think using Bonjour/mDNS technology here is a good solution for
>> configuring the device. Running avahi on boot will allow other clients
>> in the same local network to connect to the pi using a friendly domain
>> name like "owncloud.local". After that they can be presented with the
>> OwnCloud interface to complete the setup of their instance.
>> 
>> 
>> An image with a decent, modern PHP
>> ----------------------------------
>> 
>> We (at resin) have already ported a lot of the official Docker library
>> images to armv6, armv7 and i386 [2]. Fortunately, Docker has official
>> images for PHP[3] and OwnCloud[4] so those could be very easily added
>> in our set of standard images. This means that the Pi will be running
>> a modern PHP (5.6) with either fpm or apache2. I believe fpm will run
>> better on the Raspberry Pi but we should probably get some numbers
>> here.
>> 
>> Those Dockerfiles compile PHP from source so we'll have an as much
>> optimised build as possible.
>> 
>> 
>> Pre-configured caching
>> ----------------------
>> 
>> The Docker images come pre-configured with OPcache and APCu enabled.
>> Since this will be a single instance installation these look like good
>> defaults.
>> 
>> 
>> Fast database
>> -------------
>> 
>> Although PostgreSQL and MariaDB are considered faster then SQLite, I
>> think SQLite is a sensible choice here. My reasoning behind this is
>> that the there will generally be low load on the service, since it
>> will be serving ~1 user at home and that RAM on the Raspberry Pi isn't
>> much (1GB for RPi 2) so going with SQLite will leave some RAM for the
>> other essential parts of the system (like caches). Lastly, it makes
>> the software setup quite a bit simpler since again this is the default
>> configuration.
>> 
>> 
>> A built in backup tool
>> ----------------------
>> 
>> I would go for a simple solution here based on btrfs snapshots and
>> rsync. The target of the backups could be some secondary attached
>> storage device or even a remote rsync location. Using some of the more
>> advanced rsync flags, subsequent backups will only store changed files
>> on disk while at the same time being stand alone full backups [5]. A
>> cleanup job could always keep N backups in the past or even implement
>> a Grandfather-Father-Son scheme [6]. I've been using this method for
>> the past 6 months and works quite well.
>> 
>> 
>> 
>> Optional resin.io integration
>> =============================
>> 
>> Before I start, I'd like to acknowledge that using resin.io for this
>> project implies that you trust of your software and more importantly,
>> your data, to the platform. However, I believe there are some unique
>> benefits regarding UX when using it, so I would let an end user
>> consider the benefits and make an informed decision.
>> 
>> 
>> Operating System
>> ----------------
>> 
>> The operating system for resin.io devices is a custom built Yocto for
>> the specific board. This operating system is minimal with small
>> footprint and fine tuned to just bring up the hardware and start
>> running containers. Building a Yocto linux is a complex and time
>> consuming process, since it compiles every single package from source,
>> and this is the reason it wasn't the OS of choice above. But we take
>> of that. The source code for it is open source [7].
>> 
>> System and application updates
>> ------------------------------
>> 
>> Both host operating system updates and application updates are handled
>> by resin. Our OS images have a double root partition where one of them
>> is always active and the other one is inactive. When an update is
>> available it gets installed in the inactive partition, then a
>> bootloader switch is flipped and the board is rebooted. This ensures
>> that updates are atomic, there isn't a single moment where the device
>> is in a semi-updated state.
>> 
>> Application updates are even simpler. Simply `git push resin master` a
>> repo containing the OwnCloud Dockerfile to your application will
>> trigger a build in the cloud and the resulting image will be
>> downloaded on the device and the old one will be updated
>> automatically.
>> 
>> Device provision (WiFi)
>> -----------------------
>> 
>> In the case where someone wants to run his setup over WiFi, setting up
>> the credentials on a static image is cumbersome. For that reason (and
>> other configuration options) we have created a dynamic image maker.
>> Think about it as an HTTP endpoint that has some static operating
>> system images and then injects supplied configuration into them. Using
>> this method someone can specify his WiFi credentials when downloading
>> the image. Afterwards, when he powers up his device, the device will
>> connect automatically to the internet.
>> 
>> Access over the internet
>> ------------------------
>> 
>> When a device is online and connected to resin, it is possible to
>> reach it over the internet using a url in the form of
>> `https://<uuid>.resindevice.io`. Any request there will be forwarded
>> to port 80 on the device. This means that the OwnCloud installation
>> will be accessible from anywhere on the internet, not just the local
>> home network.
>> 
>> Note: Currently there is no bandwidth limit there but there might be
>> one in the future depending on the usage patterns we see.
>> 
>> Device status
>> -------------
>> 
>> There is always a device dashboard where the current version of the
>> code, status, and logs of the device are visible. Also, administrative
>> actions are possible like reboot and shutdown.
>> 
>> [1] http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/
>> [2] https://github.com/resin-io-library/base-images/tree/master/python
>> [3] https://github.com/docker-library/php/blob/master/5.6/fpm/Dockerfile
>> [4] https://github.com/docker-library/owncloud/blob/master/8.2/fpm/Dockerfile
>> [5] https://gist.github.com/petrosagg/b23cae56de981f51ca12
>> [6] https://en.wikipedia.org/wiki/Backup_rotation_scheme#Grandfather-father-son
>> [7] https://github.com/resin-io/meta-resin
>> 
>> Best,
>> Petros Angelatos
>> _______________________________________________
>> Devel mailing list
>> Devel at owncloud.org
>> http://mailman.owncloud.org/mailman/listinfo/devel
> 
> -- 
> 
> Best regards
> Daniel Hansson
> www.en0ch.se
> 
> _______________________________________________
> Devel mailing list
> Devel at owncloud.org
> http://mailman.owncloud.org/mailman/listinfo/devel

--
ownCloud GmbH - owncloud.com

Your Data, Your Cloud, Your Way!

ownCloud GmbH, GF: Markus Rex, Holger Dyroff, Frank Karlitschek
Schloßäckerstrasse 26a, 90443 Nürnberg, HRB 28050 (AG Nürnberg)




More information about the Devel mailing list