Van den Hof Linux Engineering

BetterBe B.V.

2024-06-01T02:00:00+02:00

BetterBe provides an API/SaaS solution to the leading automotive companies like Alphabet, Arval, DirectLease etc for calculating complex automotive leasing products. At BetterBe I implemented Terraform to manage the on-premise Rancher kubernetes clusters on both bare-metal hardware, using Foreman, and virtual machines using Harvester.

TenneT TSO

2022-06-01T02:00:00+02:00

TenneT is a leading European grid operator, committed to providing a secure and reliable supply of electricity 24 hours a day, 365 days a year. My job at TenneT was to implement Terraform to manage the on-premise Rancher kubernetes clusters for various applications.

RAMLAB

2021-02-01T10:15:00+01:00

RAMLAB created a system to utilize a welding robot to 3D print metal parts on demand. Cool stuff. The hardware needed to support this, is powered by inhouse developed software.

My job as a Linux Engineer was to enable RAMLAB to automatically roll out these new hardware systems with as little human interaction as possible. We achieved this by utilizing MAAS (Ubuntu server deployments), Ansible (AWX), SSH authentication, JIRA Asset Management and some Google Cloud resources. By connecting all the API’s we were able to automate installations from beginning to end.

I4Networks

2020-02-01T10:15:00+01:00

I4Networks is constantly improving their customer services, by automating as much as possible (and thereby eliminating human error) and making use of Cloud resources whenever possible. By deploying apps serverless (using Google Cloud Run), they can focus on developing applications instead of hosting and maintaining secure environments.

With automation, configuration changes are as easy as creating a Pull Request and merging.

Ultimaker

2019-02-01T10:15:00+01:00

Ultimaker creates the best 3D-printers in the world. These printers are manageable through the cloud, enable you to monitor, start, stop and duplicate print jobs and much more, from anywhere. As a Cloud Operations Engineer my main job was to help Ultimaker bring their Cloud Infrastructure to a higher standard.

I achieved this by creating an infrastructure-as-code setup and ensuring all the Google Cloud Platform resources were described in Terraform code. Next, building applications was streamlined using Docker, docker-compose and GitHub Actions. Built docker images were pushed to the Google Container Registry, after which our GitOps implementation would detect the new images and deploy them on the relevant clusters automatically using custom Helm charts.

To be able to replace the entire infrastructure with zero downtime, we migrated local MongoDB databases to MongoDB Atlas to get rid of the last bit of stateful data in the clusters.

I implemented the Istio Service Mesh for detailed insights into the performance of our clusters, ratelimiting and to be able to do canary / A-B / green-blue deployments.

I made it possible for developers to show their new features to stakeholders, by launching ‘lab environments’ on Google Cloud Run, using a custom made GitHub Action.

Refactory

2018-04-30T11:15:00+02:00

Refactory is an early adopter of the latest and greatest DevOps technologies. Because of this, they are able to quickly and efficiently help many customers overcome seemingly difficult and complex problems.

I helped Refactory to update their Ansible playbooks and roles to new and higher standards, therefor increasing scalability and maintainability. The playbooks will now be automatically checked whether they conform to the Coding Style guidelines aswell as valid syntax. A number of custom rules were developed in Python.

I also extended the playbooks to be able to run PHP applications with dedicated user accounts and roll out new websites automatically. Additionally, servers can now be updated automatically and will export statistics to Prometheus.

Xolphin

2018-04-04T11:15:00+02:00

Xolphin uses a number of different websites to sell their SSL products. They wanted to switch from using Apache to Nginx, and in the process, implement a method to better maintain and more easily roll out additional websites. I have converted their existing Apache configuration to nginx virtualhosts, which are deployed using Ansible. A simple YAML configuration file is now used to describe the virtualhost and, if applicable, any settings that deviate from the defaults.

Obviously the entire setup can first be tested locally using Vagrant.

The ansible playbooks will:

ensure the unix users and groups exist
generate new Diffie-Hellman parameters (if needed)
create documentroots with proper permissions and ownerships
ensure the nginx virtualhost configurations
configure PHP-FPM pools per user

Tuxis Internet Engineering

2017-03-07T10:15:00+01:00

Tuxis asked me to develop Ansible playbooks that would roll out and configure Sensu across their various platforms. I developed this locally using Vagrant, I started with a basic server and client and basic checks. From there I expanded the monitoring with more complicated checks and notification methods.

Using the ansible playbooks, you can easily subscribe to sensu checks or add your own.

IJsvogel Retail

2017-01-09T10:15:00+01:00

As DevOps Architect Online, I supported a number of teams in the IJsvogel Retail organisation, the corporation behind Pets Place and Boerenbond.

I was responsible for the day-to-day operations revolving around the ecommerce platform built on Magento 2 - running on Amazon Web Services behind Varnish caching servers.

This included troubleshooting issues and reporting these to the correct suppliers, such as Payment Service Providers (Buckaroo), Magento 2 developers (50x Solutions), iOS/Android developers (Egeniq) or the Delivery Management Software provider Paazl. Together with the Online Business team I was responsible for Scrum sprint planning and project prioritization.

I also helped introduce a Customers Loyalty program (VIP Club) consisting of iOS and Android mobile apps built by Egeniq, the ecommerce website and a CRM platform built by The Valley.

Avisi BV

2016-06-20T16:15:00+02:00

As a DevOps engineer, I’ve been tasked to setup a new fully automated platform. Customers will be able to request a dedicated, Atlassian-stack based DTAP environment in a private cloud. Other tools like Jenkins and Rundeck may be added to the stack. I developed a Python tool that reads configuration from Puppet Hiera and consequently creates the necessary virtual machines in a VMware vCloud environment. It will also configure a private LAN for the customer as well as networking (SNAT) and firewalling rules. The public internet facing proxy servers, running nginx, will receive a signal to update their configuration. Aside from creating the DTAP environment, documentation and instructions for maintenance and provisioning new customers must be created. A follow-up project consists of migrating current customers to a new, private cloud.

Other software used:

Vagrant
PostgreSQL
OpenDJ (LDAP server)

Protecting your servers against ImageTragick (CVE-2016-3714) and CVE-2016-5118 using Ansible

2016-06-02T16:00:00+02:00

On May 3rd, details were published about a vulnerability in ImageMagick (CVE-2016-3714), allowing remote code execution if you process user submitted images. Exploits for this vulnerability are being used in the wild.

The following ansible playbook may be used to apply the policy file mitigation discussed on that website. If the server(s) you wish to protect has a policy.xml file in a different location, be sure to modify the with_items list of the first task.

Update 2nd of June: on May 29th, another vulnerability was disclosed regarding ImageMagick. This vulnerability was assigned CVE-2016-5118. It is possible to execute shell commands by using a pipe in the file open syntax. The playbook below has been modified to protect agains this vulnerability as well, with special thanks to Henk-Jan Agteresch.

Note: Updated packages have been released that fix this vulnerability for Ubuntu and Debian. The updated packages make the policy.xml file change unnecessary (but it wont hurt either).

---
- hosts: all
  become: true
  gather_facts: false

  tasks:
    - name: find out what the default policy.xml location is
      command: convert -list policy
      register: convert_policy
      failed_when: false
      changed_when: false

    - set_fact:
        default_convert_policy: "{{ convert_policy.stdout_lines[1]|regex_replace(\"Path: (.*)\", \"\\1\")}}"
      when: "'Path' in convert_policy.stdout"

    - name: check which policy.xml exists
      stat:
        path: "{{ item }}"
      with_items:
        - "{{ default_convert_policy|default(\"/etc/ImageMagick/policy.xml\") }}"
        - /etc/ImageMagick-6/policy.xml
        - /etc/ImageMagick-7/policy.xml
        - /usr/local/etc/ImageMagick/policy.xml
        - /usr/local/etc/ImageMagick-6/policy.xml
        - /usr/local/etc/ImageMagick-7/policy.xml
      register: policy_xml

    - name: for every policy.xml that exists ensure lines are in the config
      lineinfile:
        dest: "{{ item.0.item }}"
        insertbefore: "</policymap>"
        line: "{{ item.1 }}"
      with_nested:
        - "{{ policy_xml.results }}"
        - ['  <policy domain="coder" rights="none" pattern="EPHEMERAL" />',
           '  <policy domain="coder" rights="none" pattern="URL" />',
           '  <policy domain="coder" rights="none" pattern="HTTPS" />',
           '  <policy domain="coder" rights="none" pattern="MVG" />',
           '  <policy domain="coder" rights="none" pattern="MSL" />',
           '  <policy domain="path" rights="none" pattern="|*" />',
          ]
      when: item.0.stat.exists

To execute the playbook, save it in a file called imagetragick.yml and execute it using ansible-playbook:

$ ansible-playbook imagetragick.yml

Applying two-factor authentication to SSH logins with Duo Security

2016-05-19T16:00:00+02:00

Adding Two Factor Authentication to your server is a great way to increase security. After doing research on a number of different implemententations for getting two-factor authentication enabled on SSH login sessions, I came to the conclusion Duo Security is the easiest to setup and most mature of the available solutions. Other solutions are Google Authenticator and Authy. Google Authenticator is not an option if you want to add multiple SSH keys to a single user (i.e. root) - it requires seperate user accounts. I discarded Authy as an option because it breaks scp, required typing over a 7-digit code every time you log in, I could not login to the site using Safari and text messages were sent twice each time.

This guide aims to get you up and running with Duo Security as quickly as possible. The quickest way would be to run the ansible playbook at the bottom of this guide, but I suggest following the guide step by step to ensure that you know what you are doing (and what the playbook does). Note: It is also possible to configure Duo with PAM, but this is a little more complex. For now I will focus on getting the login_duo program to work, but we will compile and install the Duo Unix package with PAM support should you want to use it later.

Getting an Integration and Security key

To use Duo Security, you need two keys: an Integration and a security key. These will be used in the configuration files below. To get the keys, create an application in the Duo Security Admin dashboard.

Install Duo Security dependencies

The Duo Security login binary depends on the PAM and OpenSSL library development headers. On Debian and Ubuntu the packages are called libpam0g-dev and libssl-dev and can be installed by executing:

$ sudo apt-get install libpam0g-dev libssl-dev

On RedHat-based systems install the pam-devel and openssl-devel packages:

$ sudo yum install pam-devel openssl-devel

Download the Duo Security unix source

Download and unpack the latest version of the Duo Security unix source code:

$ wget https://dl.duosecurity.com/duo_unix-latest.tar.gz
$ tar xzvf duo_unix-latest.tar.gz

Install the Duo Security binaries

Configure, compile and install the Duo Security binaries:

$ cd duo_unix-1.9.18
$ ./configure --prefix=/usr --with-pam
$ make
$ sudo make install

Configure /etc/duo/login_duo.conf

Make sure the /etc/duo/login_duo.conf file consists of the following lines:

[duo]
ikey = {{ duo_integration_key }}
skey = {{ duo_secret_key }}
host = {{ duo_api_host }}
pushinfo = yes
failmode = secure
autopush = yes

Replace the three values in double curly brackets with your own information. Notice the three other settings: pushinfo = yes makes duo send additional information to the authenticator client, such as which IP is trying to SSH into the server. failmode = secure indicates we do not want you to be able to log in if Duo Security is unavailable or in maintenance. autopush = yes means we will automatically receive a push message to our phone, instead of having to choose an authentication method from a menu.

Configure /etc/duo/pam_duo.conf

Symlink the /etc/duo/login_duo.conf file to /etc/duo/pam_duo.conf. As stated previously, we will not be using PAM, but if you decide you want to use Duo with PAM, follow this guide.

$ sudo ln -s /etc/duo/login_duo.conf /etc/duo/pam_duo.conf

Configure SSH

Now that the Duo program is configured, we will configure SSH to use it. To do this, all you need to do is modify your authorized_keys file to invoke the login_duo binary for every public key you wish to enable it for:

command="/usr/sbin/login_duo" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDlEJbk7t/XSl7EABuKHZgRuipHJ3bDKMurZxeMaJA5P7ZwmESqcsjccCT9Ep2HF21LhnWIfMWFKv+cyzmhhkRLOmFuGcHB7vZH5RGVjncChzwJx7uOVOkajk/ECJDZdh8gdUdUC8BXe3OkdiojgakiEMhx8/5m0u1WLGLf2jIun4efXORlTK3HRoNBwk5aLUTtehnssELXczeLtMdpeIjCl8iZww0v2zD9FqkUvwd+DkGw4ijtADjH0UA/p6uaS8wV9Tu1FwfiM3yrnQrRT2x/vWNNaqiWZbBYnL2Gr+jpeJeSuFsN2uB6HaTbAt2BP/kZvdszt91Q7ixpe3htdLpv7DaRcxfh7OfkpjJ8+9eZ9iqrqxDWhK1SQyFWKnncQAQgca4FksmmFM7K7RuXwTx09kaCOwQkFpnu+rAMKUVjKiJuy7GdszgZczpz/3xDFisgD/+myBx2ITkhtPTLeadVKyTyp/0Plb03UWOcGOhNdUna/QrT8ZSPQrVH3ejEk8uPcYmv/mEYVqLBlauB+E6CIkYRpraGZySfk+9sKcFnZPC++D61jCXqU3eofZG2QK69pdn25cZlihAdCy4FpHDJ8Fd5V1w8Pmy2SxpVehggnQe0S4N0cIcnpRr0JaE7k6al429LLMPBcWKzo4pnGp9ugvuicDckp7Hem2MgeUR+vw== rvdhof

This will execute the login_duo binary when you use this public key to login to the server. If the username of the account you are logging in to does not match your Duo account name, specify it with the -f username option:

command="/usr/sbin/login_duo -f rvdhof" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDlEJbk7t/XSl7EABuKHZgRuipHJ3bDKMurZxeMaJA5P7ZwmESqcsjccCT9Ep2HF21LhnWIfMWFKv+cyzmhhkRLOmFuGcHB7vZH5RGVjncChzwJx7uOVOkajk/ECJDZdh8gdUdUC8BXe3OkdiojgakiEMhx8/5m0u1WLGLf2jIun4efXORlTK3HRoNBwk5aLUTtehnssELXczeLtMdpeIjCl8iZww0v2zD9FqkUvwd+DkGw4ijtADjH0UA/p6uaS8wV9Tu1FwfiM3yrnQrRT2x/vWNNaqiWZbBYnL2Gr+jpeJeSuFsN2uB6HaTbAt2BP/kZvdszt91Q7ixpe3htdLpv7DaRcxfh7OfkpjJ8+9eZ9iqrqxDWhK1SQyFWKnncQAQgca4FksmmFM7K7RuXwTx09kaCOwQkFpnu+rAMKUVjKiJuy7GdszgZczpz/3xDFisgD/+myBx2ITkhtPTLeadVKyTyp/0Plb03UWOcGOhNdUna/QrT8ZSPQrVH3ejEk8uPcYmv/mEYVqLBlauB+E6CIkYRpraGZySfk+9sKcFnZPC++D61jCXqU3eofZG2QK69pdn25cZlihAdCy4FpHDJ8Fd5V1w8Pmy2SxpVehggnQe0S4N0cIcnpRr0JaE7k6al429LLMPBcWKzo4pnGp9ugvuicDckp7Hem2MgeUR+vw== rvdhof

Thats it! If you followed the steps in this guide, the next time you log in to your server with SSH, you will be asked to confirm the login:

Ricks-MacBook-Pro:~ rick$ ssh rick@vps01
Enter passphrase for key '/Users/rick/.ssh/id_rsa':
Autopushing login request to phone...

You will now get a Push Message on your phone:

After tapping the big green button, you will be logged in:

Success. Logging you in...
rick@vps01:~$

Ansible Playbook

Note: the following will only work on Debian based servers.

To run all the above commands (except for configuring SSH) on one or more servers using Ansible, save the following as a .yml file:

---
- hosts: test

  vars:
    - duo_url: "https://dl.duosecurity.com/duo_unix-latest.tar.gz"
    - duo_version: "1.9.18"

  vars_prompt:
    - name: duo_integration_key
      prompt: Duo integration key
      private: false
    - name: duo_secret_key
      prompt: Duo secret key
      private: false
    - name: duo_api_host
      prompt: Duo API host
      private: false

  tasks:
    - name: install dependencies
      apt:
        name: "{{ item }}"
        update_cache: true
        cache_valid_time: 86400
      with_items:
        - libpam0g-dev
        - libssl-dev

    - name: download duosecurity
      get_url:
        url: "{{ duo_url }}"
        dest: /usr/src/duo_unix-latest.tar.gz

    - name: unpack it
      unarchive:
        src: /usr/src/duo_unix-latest.tar.gz
        dest: /usr/src/
        copy: false

    - name: configure duo
      command: ./configure --prefix=/usr --with-pam
      args:
        chdir: /usr/src/duo_unix-{{ duo_version }}
        creates: /usr/src/duo_unix-{{ duo_version }}/Makefile

    - name: compile duo
      command: make -j{{ ansible_processor_cores }}
      args:
        chdir: /usr/src/duo_unix-{{ duo_version }}
        creates: /usr/src/duo_unix-{{ duo_version }}/login_duo/login_duo

    - name: install duo
      command: make install
      args:
        chdir: /usr/src/duo_unix-{{ duo_version }}

    - name: configure login_duo.conf
      template:
        src: login_duo.conf.j2
        dest: /etc/duo/login_duo.conf

    - name: configure pam_duo.conf
      template:
        src: login_duo.conf.j2
        dest: /etc/duo/pam_duo.conf

Save the following file as templates/login_duo.conf.j2:

[duo]
ikey = {{ duo_integration_key }}
skey = {{ duo_secret_key }}
host = {{ duo_api_host }}
pushinfo = yes
failmode = secure
autopush = yes

You can now run the playbook:

ansible-playbook -i <your inventory file> playbook.yml

It will prompt you for the needed Duo variables and do everything else automatically. This makes it easy to deploy Duo on multiple servers simultaneously!

Running ownCloud on DirectAdmin server with Nginx and PHP-FPM

2016-05-12T16:00:00+02:00

If you’re like me, you want the ease of use of a commonly known Control Panel for your own server. We all know how to configure Postfix, Dovecot, MySQL, nginx etc., but when it comes to the day-to-day operating of a server on which you might give out accounts to family members and friends, you just want to click a button to create room for a website and e-mail accounts, give them their username and password and get on with the more fun stuff.

So you have chosen DirectAdmin as your Control Panel, and because you are like me, you have quickly replaced Apache with nginx (if only because it’s what the cool kids use these days) and mod_php with PHP-FPM.

Now you want to do something actually useful with your server, so why not host your very own file storage cloud? In comes ownCloud. ownCloud has been the de-facto “Be your own Dropbox” software for a number of years now and keeps growing in popularity. Unfortunately, getting it to run well on nginx and PHP-FPM can be somewhat of a challenge, and using DirectAdmin can make it even more difficult because of the way configuration files are generated.

So enough with the smalltalk, here are the nitty-gritty details on what steps you need to take to get ownCloud running succesfully on your DirectAdmin nginx server. This guide requires you to have root access to your DirectAdmin server. Well, if you have a well-willing webhost, you might ask them to apply the nginx and php-fpm customizations. But I’m guessing there aren’t that many DirectAdmin webhosts that use nginx and PHP-FPM (yet!).

Subdirectory or subdomain?

First, you’ll need to decide if you’re going to run ownCloud from a subdomain or a subdirectory. In this guide I’ll assume you’ve chosen to run ownCloud on a subdomain, called “owncloud.yourdomain.com”. Ofcourse you’re free to choose to run ownCloud in a subdirectory, but you’ll have to modify the steps in this guide accordingly. If you can, create the subdomain as a new domain in your DirectAdmin account. This helps when you’re going to protect your ownCloud installation with an SSL certificate if you’re not in possession of a wildcard SSL certificate for your domain.

Apply custom httpd settings

In DirectAdmin, go to “Custom HTTPD Configurations” and click on the account you’re planning to use for ownCloud. Add these settings. These settings were taken from the ownCloud documentation for nginx. To get rid of the The "Strict-Transport-Security" header is not configured warning, uncomment the # add_header Strict-Transport-Security line, but pay heed to the warning.

# Add headers to serve security related headers
# Before enabling Strict-Transport-Security headers please read into this topic first.
# add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;

# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;

# Disable gzip to avoid the removal of the ETag header
gzip off;

# Uncomment if your server is build with the ngx_pagespeed module
# This module is currently not supported.
#pagespeed off;

index index.php;
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;

rewrite ^/.well-known/carddav /remote.php/carddav/ permanent;
rewrite ^/.well-known/caldav /remote.php/caldav/ permanent;

# The following 2 rules are only needed for the user_webfinger app.
# Uncomment it if you're planning to use this app.
#rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
#rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;

location = /robots.txt {
    allow all;
    log_not_found off;
    access_log off;
}

location ~ ^/(build|tests|config|lib|3rdparty|templates|data)/ {
    deny all;
}

location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
    deny all;
}

rewrite ^/remote/(.*) /remote.php last;
rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;

location ~ \.php(?:$|/) {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_param HTTPS on;
    fastcgi_param modHeadersAvailable true; #Avoid sending the security headers twice
    fastcgi_pass unix:/usr/local/php|PHP1_RELEASE|/sockets/|USER|.sock;

    fastcgi_intercept_errors on;
}

# Adding the cache control header for js and css files
# Make sure it is BELOW the location ~ \.php(?:$|/) { block
location ~* \.(?:css|js)$ {
    add_header Cache-Control "public, max-age=7200";
    # Add headers to serve security related headers
    # Before enabling Strict-Transport-Security headers please read into this topic first.
    # add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;";
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Robots-Tag none;
    # Optional: Don't log access to assets
    access_log off;
}

# Optional: Don't log access to other assets
location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|swf)$ {
    access_log off;
}

Customize the PHP-FPM template

In order to get rid of the The test with getenv("PATH") only returns an empty response warning, copy the file /usr/local/directadmin/data/templates/php-fpm.conf to /usr/local/directadmin/data/templates/custom/php-fpm.conf and add the following line:

env[PATH] = /usr/local/bin:/usr/bin:/bin

To get rid of the /dev/urandom is not readable by PHP warning, add /dev/urandom to the OPEN_BASEDIR_PATH variable:

|?OPEN_BASEDIR_PATH=`HOME`/:/tmp/:/var/tmp/:/usr/local/php`PHP_VER`/lib/:/usr/local/php54/lib/:/usr/local/php55/lib/:/usr/local/lib/php/:/dev/urandom|

After doing this, we need to regenerate the config files using ./build rewrite_confs, but we’ll save that for later.

Enable WebDAV HTTP request methods

To enable WebDAV functionality, we must copy /etc/nginx/webapps.conf to /usr/local/directadmin/custombuild/custom/nginx/conf:

mkdir -p /usr/local/directadmin/custombuild/custom/nginx/conf
cp /etc/nginx/webapps.conf /usr/local/directadmin/custombuild/custom/nginx/conf

Now change the following line in the file /usr/local/directadmin/custombuild/custom/nginx/conf/webapps.conf:

if ($request_method !~ ^(GET|HEAD|POST)$ ) {

To:

if ($request_method !~ ^(GET|HEAD|POST|PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$ ) {

Rewrite the configuration files

After making the above changes, go to /usr/local/directadmin/custombuild and execute the following command:

./build rewrite_confs

Beware: sometimes after the above command, nginx has failed to start up. If that is the case, simply run service nginx restart manually. Once this is done, you should have a fully operational ownCloud installation.

ImageTragick

2016-02-20T22:15:00+01:00