[owncloud-devel] Devel Digest, Vol 24, Issue 17

Alexey Volkov alexey at onmydisk.com
Tue Dec 15 13:59:37 GMT 2015


Hi Petros,

What do you think of merging two our solutions? We have a minimal OS built
manually with Buildroot, this part is not covered good enough and redis is
definitely superior here. But the networking part is less resource hungry
since we do not need http/php on board, we run our lightweight "back-end"
 which performs FUSE file operations over the SSL channel. It runs also on
v1 boards. Filesystem is mounted on server,  ownCloud "sees" it as local
file system :)

Yes, user should trust the service, but we can make WD- or even
community-controlled service like https://<uid>.pidrive.org or whatever.
User just registers at service, types the board id under the user's
profile, and that is all - ownCloud GUI with your data hosted on your RPi.
And also PCs are supported, so user can access all his data in a single
entry point.  We work hard to bring up p2p cross-mounting capabilities in
v2 of our protocol to avoid relaying data through the server.

As I told, we have a prototype working, but such hot things like multiple
boards support, host OS updates, data backup are not implemented yet.

What do you think?


2015-12-15 10:41 GMT+01:00 <devel-request at owncloud.org>:

> Send Devel mailing list submissions to
>         devel at owncloud.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mailman.owncloud.org/mailman/listinfo/devel
> or, via email, send a message with subject or body 'help' to
>         devel-request at owncloud.org
>
> You can reach the person managing the list at
>         devel-owner at owncloud.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Devel digest..."
>
>
> Today's Topics:
>
>    1.  Western Digital Proposal (Michal Hrusecky)
>    2.  WD Challenge Proposal -  archlinux/btrfs/docker/avahi/rsync
>       (Petros Angelatos)
>    3.  Wester Digital Appliance (Christian Rost)
>    4. Re:  WD Challenge Proposal -
>       archlinux/btrfs/docker/avahi/rsync (Daniel Hansson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Dec 2015 09:01:21 +0100
> From: Michal Hrusecky <michal at hrusecky.net>
> To: devel at owncloud.org
> Subject: [owncloud-devel] Western Digital Proposal
> Message-ID: <20151215080121.GK3623 at workbook.ipv6.hrusecky.net>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> I would like to enter Western Digital contest :-) Here is my proposal of
> what I would do with PiDrive. I would create openSUSE based image for it
> with ownCloud setup and few extra features.
>
> One feature I really like to have integrated in the image is movie
> playback. So you can connect your PiDrive to your TV and via web browser
> play movies stored on your drive. I have some alpha version of the
> application running at home[1], so would integrate it, maybe extend it
> and test it on PiDrive.
>
> I would also play with avahi to publish some information about the
> PiDrive on the network. I played with it long time ago, I know there is
> plenty of stuff you can publish, but not really sure what makes sense,
> so would need to reiterate on that, in theory some computers should be
> able to autodiscover the PiDrive afterwards.
>
> Other feature I would like to include is to set it up in a way that
> there will be also some other access at least to the local files. What
> I'm thinking about is ftp server sharing users database and allowing
> direct access to the files. Or maybe localhost mounted wdfs exported via
> ftp/ssh so rsync would be possible. But this needs some experimenting
> and probably some configuration via web interface.
>
> Doing some samba shares/publish name over samba would be great, but have
> only limited experience with samba and have no windows machine to test
> against, so I can try after the stuff mentioned before, but can't
> promise given limited time and experience.
>
> What do you think?
>
> [1]
> http://michal.hrusecky.net/2015/10/introducing-octv-owncloud-arm-old-tv/
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Dec 2015 00:29:15 -0800
> From: Petros Angelatos <petrosagg at resin.io>
> To: devel at owncloud.org
> Subject: [owncloud-devel] WD Challenge Proposal -
>         archlinux/btrfs/docker/avahi/rsync
> Message-ID:
>         <
> CAM1WBjK5jh9rXnSbZ68ZMho4vDT1UCs72EagnQSd-OKRQSy-Lw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 15 Dec 2015 10:40:49 +0100
> From: Christian Rost <rost at b1-systems.de>
> To: devel at owncloud.org
> Subject: [owncloud-devel] Wester Digital Appliance
> Message-ID: <566FE021.40200 at b1-systems.de>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> a few days ago I read the blog on owncloud.org about the
> WD-ownCloud-Appliance and was really excited to read all the proposals.
>
> First a few words about myself. I'm Christian, Linux Consultant and
> Trainer at B1 Systems, located near Ingolstadt, Germany. I did a few
> ownCloud Projects so I know the Software and the code.
>
> Well, I decided to write my thought down because in my humble opionon
> this should keept as simple as possible, so everybody all over the
> world, no matter what experience should be able to buy the parts and use
> it without knowing anything about ownCloud / linux and all the other
> parts behind the GUI.
>
> As in the blog mentioned there is already an image which can be used but
> there is manual coniguration with keyboard / tv needed.
>
> So the goal is to do this automatically.
>
> Why not using this image and create a simple webconfig tool where the
> user can submit all necessary information. And a confiurationscript or
> configurationsoftware (puppet etc.) will take care that everything is
> configured in a proper way?
>
> After initial boot the user connect the Pi to TV/Screen and get a
> message like "please open browser and got to 192.168..... to start
> webconfig tool" or we develop a small tool which can autodiscover the
> webconfig tool and open a browser on the users notebook to start the
> webconiguration.
>
> This webconfig tool can configure for example (not limited to):
> - Apache
>   - SSL (let's encrypt etc)
>   - SSL renew cert
> - mySQL
>   - my.cnf
>   - Backup
> - php.ini
> - dynDNS
> - ownCloud
>   - Config Backup
> - AntiVirus for ownCloud (clamav) (not sure if performance is enough)
> - Username / Password for HostOS
> - Automated Updates (Host OS) (ownCloud via updater)
> - firewall
> - UPNP (to open Port on Router) (not sure if this is not too risky)
> - much much more
>
> After initial configuration the webconfig tool can reside on the system
> but is now protected via username / password so nobody can reset /
> reconfigure the system.
>
> But to implement and test everything above We need a lot of time so
> let's start small and simple like owncloud did. Let's create a great
> solution, easy to use for everybody.
>
> What do you think?
>
> This proposal is not an application for a dev-kit ( I already have a few
> raspies)
>
> Cheers,
>
>  Christian
>
> --
> Christian Rost
> Linux Consultant & Trainer
>
> B1 Systems GmbH
> Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 213 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://mailman.owncloud.org/pipermail/devel/attachments/20151215/025acab0/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 15 Dec 2015 10:41:50 +0100
> From: Daniel Hansson <enoch85 at gmail.com>
> To: List for Developers of ownCloud <devel at owncloud.org>
> Subject: Re: [owncloud-devel] WD Challenge Proposal -
>         archlinux/btrfs/docker/avahi/rsync
> Message-ID: <566FE05E.60700 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> 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
>
>
> End of Devel Digest, Vol 24, Issue 17
> *************************************
>



-- 
Kind regards / Lep pozdrav / С уважением,
Alexey Volkov,
founder of On My Disk
https://onmydisk.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.owncloud.org/pipermail/devel/attachments/20151215/58b09792/attachment-0001.html>


More information about the Devel mailing list