ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP

Hinweis: Dieser Artikel behandelt die Einrichtung von ownCloud 8 unter Ubuntu Server 15.10. Es gibt einen Nachfolge-Artikel, der die Installation von ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt beschreibt.

Cloud-Dienste sind eine nützliche Sache: Dateien, Termine oder Kontakte können mittels der Cloud über mehrere Geräte synchronisiert werden – vom Desktop-Rechner bis hin zum Smartphone. Dienste wie DropBox, OneDrive und Co. sind dabei allerdings keine Option für Leute, die hohen Wert auf Privatsphäre legen und ihre Daten Dritten gegenüber nicht preisgeben wollen. Wer dennoch nicht auf die Bequemlichkeit von Cloud-Diensten verzichten möchte, für den stellt die Open-Source-Lösung ownCloud eine echte Alternative dar – die Cloud zum Selberbasteln.

Dieser Artikel zeigt die Einrichtung von ownCloud auf Ubuntu Server mittels nginx, MariaDB und PHP.

Auch wenn für die Installation und Konfiguration viele einzelne Schritte notwendig sind, habe ich mich dabei bemüht, immer auch ein wenig Hintergrundinformationen in den Artikel mit einfließen zu lassen, so dass auch ein Linux-Neuling nicht überfordert sein sollte.
Der Beitrag ist daher recht umfangreich, allerdings findet man am Ende des Artikels eine Checkliste zum Download, in der noch einmal sämtliche Schritte zusammengefasst sind, die für die Installation von ownCloud notwendig sind.

Update 28.11.2015: Der Artikel wurde komplett überarbeitet, so dass nun die aktuellsten Programmversionen zum Einsatz kommen und ebenfalls die damit verbundenen Änderungen erläutert werden. Dies betrifft v.a. die Einrichtung von Redis für das Transactional File Locking von ownCloud.

Update 24.12.2015: Hinweis auf Let’s Encrypt zur Erzeugung von SSL-/TLS-Zertifikaten hinzugefügt. Die Notwendigkeit, selbst signierte Zertifikate zu verwenden, ist somit nicht mehr gegeben. Die Anleitung zum erzeugen von selbst signierten Zertifikaten wurde dennoch nicht aus dem Artikel entfernt, falls Let’s Encrypt nicht zum Einsatz kommen soll.

Update 20.05.2016: Hinweis auf den neuen Artikel (ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt) hinzugefügt.

Zielsetzung

Der Artikel wurde mit folgender Zielsetzung geschrieben:

• Installation von ownCloud unter Linux (Ubuntu Server 15.10) mit nginx, MariaDB und PHP
• Erhöhte Sicherheit (PHP-Konfiguration, SSL, ownCloud-Konfiguration laut ownCloud Server Administration Manual)
• Verschlüsselte Verbindung zur ownCloud über das lokale Netzwerk als auch über das Internet (DynDNS)
• ownCloud soll in einem Unterverzeichnis des Webservers liegen, d.h. nicht über myserver.dyndns.org, sondern über myserver.dyndns.org/owncloud erreichbar sein. Dies macht es möglich, dass mehrere Webseiten über die gleiche Domain gehostet werden können.
• Im Administrator-Bereich von ownCloud sollen keine Warnungen angezeigt werden

Alle Schritte sind mit folgenden Programmversionen getestet. Da die Entwicklung von ownCloud noch im Fluss ist, kann es passieren, dass einige Schritte des Tutorials angepasst werden müssen, wenn andere Programmversionen zum Einsatz kommen.

• Ubuntu 15.10 („Wily Werewolf“)
• nginx 1.9.7
• MariaDB 10.0.22
• PHP 5.6.11
• ownCloud 8.2.1

Exkurs: Der LEMP Stack: Linux, nginx, MySQL/MariaDB, PHP

Manch einer wird sich nun fragen, warum dieser Artikel so umfangreich ist. Dies liegt darin begründet, dass ich zur Installation nicht auf die offiziellen ownCloud-Pakete zurück greife, da hier immer automatisch Apache und MySQL neben ownCloud selbst installiert werden. Ich wähle hier einen anderen Weg…

Lange Zeit galt der sog. LAMP Stack (Linux, Apache, MySQL und PHP) als Standard, wenn es darum ging, dynamische Webseiten zu hosten.

Dieser Artikel zeigt jedoch die Installation und Einrichtung von ownCloud auf einem LEMP Stack: Linux als Betriebssystem (in diesem Fall Ubuntu Server), nginx (sprich: Engine-X) als Webserver, MariaDB als Datenbank und PHP als Skriptsprache für dynamische Inhalte.
Durch die Verwendung dieser alternativen Programme ist daher einiges an Handarbeit notwendig, weil vieles manuell installiert und konfiguriert werden muss. Jedoch bietet der Einsatz von nginx und MariaDB handfeste Vorteile:

• nginx arbeitet generell ressourcenschonender als Apache. Dies liegt z.T. darin begründet, dass Apache bei neuen Verbindungen neue Prozesse bzw. Threads erzeugt, um diese Connections abzuarbeiten. Dies ist besonders bei vielen gleichzeitigen Verbindungen sehr speicherintensiv. nginx hingegen arbeitet mit einer konfigurierbaren Anzahl an Threads, die sämtliche Verbindungen asynchron bearbeiten.
  Somit ist nginx deutlich im Vorteil, wenn viele gleichzeitige Verbindungen bestehen (was bei einer private gehosteten Cloud-Umgebung weniger oft der Falls ein dürfte) oder die Hardware-Ressourcen begrenzt sind, was beispielsweise bei einem Raspberry Pi der Fall ist.
• MariaDB ging aus einem Fork von MySQL hervor. Nach der Übernahme von MySQL durch Sun bzw. Oracle dauert es mitunter sehr lange, bis Änderungen oder Patches in die MySQL-Pakete übernommen werden. Außerdem ist unklar, wie Oracle die Entwicklung von MySQL in Zukunft vorantreiben wird.
  MariaDB ist dabei ein 1:1-Ersatz für MySQL (sog. drop-in replacement), d.h. sämtliche von MySQL bekannten Befehle, Schnittstellen und Tools sind auch unter MariaDB verwendbar.
  Seit Ende 2012 haben etliche Linux-Distributionen MySQL durch MariaDB als Standard-Datenbanksystem ersetzt. MariaDB macht momentan einen sehr zukunftssicheren Eindruck, daher fiel die Wahl auf MariaDB als Datenbanksystem. Da MariaDB ein 1:1-Ersatz für MySQL ist, kann man natürlich auch MySQL verwenden. Die Schritte zur Einrichtung von ownCloud sind im Grunde genommen dieselben.

Voraussetzungen

Betriebssystem/Hardware

Der Artikel beschreibt die Einrichtung von ownCloud auf einem neu installiertem Ubuntu Server 15.10 („Wily Werewolf“). Für einen eigenen Home-Server bietet sich v.a. die Verwendung einer LTS-Version (Long Term Support) von Ubuntu an. Zum Zeitpunkt als der Artikel verfasst wurde, war dies 14.04 („Trusty Tahr“). Allerdings habe ich mich aus zwei Gründen hier bewusst für die Version 15.10 (nicht LTS) entschieden:

• Bessere Unterstützung durch Hyper-V: Ich verwende für den Artikel eine virtuelle Maschine unter Windows Server 2012 R2 mit Hyper-V (die Installation von Ubuntu Server mit den Besonderheiten bzgl. Hyper-V beschreibt der Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten). Laut Microsoft (siehe TechNet-Artikel) werden mehr Hyper-V Features unter Ubuntu 15.04 unterstützt, als noch mit 14.04.
• Aktualisierte Pakete unter 15.10: Einige Pakete (wie beispielsweise php5-apcu) liegen unter Ubuntu 14.04 noch in älteren Versionen vor, die nicht voll mit ownCloud kompatibel sind. Dies führt meist zu Warnungen im Administrator-Bereich von ownCloud oder verminderter Performance. Einzige Lösung wäre hier, die aktuellste Programmversion manuell zu kompilieren und einzubinden.

Generell ist die eingesetzte Linux-Distribution allerdings unerheblich. Die Installation von ownCloud und den benötigten Komponenten funktioniert auf anderen Distributionen identisch.

Auch die verwendete Server-Hardware spielt im Wesentlichen keine Rolle. Alle Schritte des Artikels können auch angewendet werden, wenn beispielsweise ein Raspberry Pi (Affiliate Link) mit Raspbian als Betriebssystem oder ein Intel NUC (Affiliate Link) mit Debian zum Einsatz kommt.

Zugriff per SSH

Für die Installation und Einrichtung des Linux-Servers empfiehlt sich der Zugriff per SSH (z.B. mit PuTTY). Eine genauere Beschreibung hierzu findet mal ebenfalls im Artikel Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten.

DynDNS

Damit die ownCloud-Installation später auch über das Internet verfügbar ist, muss der Router per DynDNS zu erreichen sein. Ohne DynDNS ändert sich in den meisten Fällen die (externe) IP des Routers nach einer Zwangstrennung (in der Regel alle 24 Stunden). Es gibt hier eine große Auswahl an DynDNS-Anbietern – sowohl kostenlose, als auch Anbieter, die sich ihren Dienst bezahlen lassen.

Im Rahmen dieses Artikels gehe ich davon aus, dass die URL, unter der ownCloud später erreichbar sein soll myserver.dyndns.org/owncloud lautet. Zu beachten ist hier, dass ownCloud in einem Unterverzeichnis liegt (/owncloud). Dazu später mehr.

Arbeiten mit Root-Rechten

Bevor es losgeht noch ein letzter Hinweis: So gut wie alle nachfolgend aufgeführten Befehle erfordern Root-Rechte. Damit nicht vor jedem Befehl ein sudo eingegeben werden muss, arbeite ich bei der Einrichtung des Rechners mit dauerhaften Root-Rechten. Diese erlangt man über den Befehl:

sudo -s

Am Ende sollte man sich dann mit exit wieder abmelden. Ein dauerhaftes Arbeiten mit Root-Rechten ist aus Gründen der Sicherheit nicht empfohlen.

Nun kann es aber losgehen…

Updates einspielen

Zunächst einmal bringen wir den Recher auf den neusten Stand und starten ihn anschließend neu:

apt-get update 
apt-get upgrade -V 
reboot

Hinweis zum Parameter -V bei apt-get upgrade: Mittels dieses Parameters werden zusätzliche Versions-Informationen über die installierten Pakete und die zur Verfügung stehenden Updates angezeigt. Dieser Parameter ist eigentlich immer empfehlenswert, besonders wenn man ein bereits laufendes System aktualisieren möchte. Hier sollte man immer genau darauf achten, was bei einem Upgrade passiert.

Statische IP-Adresse zuweisen

Mit einem frisch installierten Linux bekommt der Rechner in den meisten Fällen durch den Router eine dynamische IP per DHCP. Für den vereinfachten Zugriff empfiehlt es sich jedoch, eine statische IP-Adresse zu verwenden. Dazu muss folgende Konfigurations-Datei bearbeitet werden:

nano /etc/network/interfaces

Hier sind alle Netzwerkkarten aufgelistet. eth0 ist dabei die primäre Netzwerkkarte. Hier passen wird den Eintrag entsprechend an. In diesem Beispiel gehe ich davon aus, dass der verwendete Router die IP 192.168.178.1 hat und der Linux-Rechner die statische IP 192.168.178.20 haben soll.

auto eth0
iface eth0 inet static
address 192.168.178.20
netmask 255.255.255.0
network 192.168.178.0
broadcast 192.168.178.255
gateway 192.168.178.1
dns-nameservers 192.168.178.1

Nach einem Neustart des Rechners ist dieser fortan immer unter der IP 192.168.178.20 zu erreichen.

Programm-Installation

Bevor ownCloud installiert werden kann, muss zunächst einmal der Webserver, MariaDB und PHP installiert werden.

nginx installieren

In den Paketquellen von Ubuntu 15.10 ist noch die recht alte Version 1.9.3 von nginx vorhanden. Um eine aktuellere Version installieren zu können, muss das nginx-Repository direkt in die Paketquellen aufgenommen werden.

Dazu muss zunächst einmal der Schlüssel des nginx-Repositories im System bekannt gemacht werden. Ohne diesen Befehl werden bei der Installation der aktuellen nginx-Version Warnungen angezeigt.

wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -

Anschließend werden die Paketquellen hinzugefügt:

nano /etc/apt/sources.list

Wir ergänzen die Datei am Ende mit:

# Nginx (Mainline)
deb http://nginx.org/packages/mainline/ubuntu/ wily nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ wily nginx

Hinweis: Ich nehme hier die Mainline-Version von nginx. Diese stellt den aktuellen Entwicklungszweig dar und gilt als stabil. Es gibt darüber hinaus noch den Stable-Entwicklungszweig. Wie der Name zwar vermuten lässt, ist dieser Zweig allerdings nicht unbedingt stabiler als der Mainline-Zweig, sondern nur Feature-Stable. Konkret bedeutet dies, dass hier keine neuen Features mehr implementiert werden und auch nur noch wichtige Bugfixes nachgeliefert werden – siehe nginx-Blogbeitrag (How Branch Renumbering Works). Ein anderer Beitrag aus dem nginx-Blog empfiehlt explizit die Verwendung des Mainline-Zweigs.

Nach dem Hinzufügen der Paketquellen folgt die eigentliche Installation von nginx:

apt-get update 
apt-get install nginx

Die Installation des Webservers kann getestet werden, indem man die IP des Rechners im Browser aufruft:

MariaDB installieren

Für die aktuelle Version von MariaDB ist ein ähnliches Vorgehen wie schon bei nginx empfehlenswert. Die MariaDB-Homepage liefert dazu ein praktisches Repository Configuration Tool. Hier die notwendigen Schritte:

Zunächst fügen wir den Key-Server für MariaDB hinzu:

apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db

Dann werden die Paketquellen hinzugefügt:

nano /etc/apt/sources.list

Folgende Zeilen fügen wir am Ende der Datei hinzu:

# MariaDB 10.0 repository list - created 2015-09-15 15:17 UTC
# http://mariadb.org/mariadb/repositories/
deb [arch=amd64,i386] http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.0/ubuntu wily main
deb-src http://ftp.hosteurope.de/mirror/mariadb.org/repo/10.0/ubuntu wily main

Nun kann die Datenbank installiert werden:

apt-get update 
apt-get install mariadb-server

Während der Installation wird man dazu aufgefordert, ein Passwort für den Root-Zugriff anzugeben. Man sollte diesen Schritt nicht überspringen und ein ausreichend sicheres Passwort wählen:

PHP installieren

Bevor nun ownCloud installiert werden kann, muss noch die Installation von PHP mit allen für ownCloud benötigten Paketen durchgeführt werden. Die ownCloud-Dokumentation listet dafür alle benötigten Pakete auf. Einige dieser Pakete werden nur benötigt, wenn spezielle Features von ownCloud zum Einsatz kommen sollen.

Für den Anfang reicht die Installation folgender Pakete für PHP:

apt-get update 
apt-get install php5-fpm php5-gd php5-json php5-mysql php5-curl php5-intl php5-mcrypt php5-imagick php5-apcu

Wenn später weitere Pakete benötigt werden, können diese jederzeit nachinstalliert werden.

Konfiguration des Servers

Nach der Installation der benötigten Programme werden diese anschließend konfiguriert.

SSL-Zertifikat

Bevor die Konfiguration von nginx angegangen wird, sollte zunächst einmal ein SSL-Zertifikat generiert werden: Die ownCloud-Instanz soll später per HTTPS erreichbar sein, damit sämtliche Datenübertragungen verschlüsselt ablaufen. Dazu wird ein SSL-Zertifikat benötigt. Dies kann man über eine Zertifizierungsstelle anfordern (die meisten Webhoster bieten ebenso SSL-Zertifikate an). Allerdings werden hier z.T. sehr hohe Preise verlangt.

SSL-Zertifikat generieren (Let’s Encrypt)

Seit Anfang Dezember ist allerdings das Projekt Let’s Encrypt in der öffentlichen Beta-Phase. Mit Hilfe dieses Programms (dem sog. Client) ist es nun einfach möglich, SSL-/TLS-Zertifikate zu erzeugen. Der goße Vorteil an diesen Zertifikaten ist, dass alle gängigen Browser diese als vertrauenswürdig einstufen. Damit entfällt die Notwendigkeit, ein selbst signiertes Zertifikat auf dem Client-Rechner/Mobilgerät installieren zu müssen, damit keine für den Benutzer abschreckende Warnung beim Zugriff auf die ownCloud angezeigt wird.

Wie Zertifikate über Let’s Encrypt erzeugt und in nginx eingebunden werden können, habe ich in einem weiteren Artikel detailliert beschrieben: HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx. Im Folgenden gehe ich davon aus, dass ein Zertifikat verwendet wird, welches über Let’s Encrypt erzeugt wurde.

Hinweis: Im Rahmen dieser Anleitung gehe ich immer von der Verwendung einer DynDNS-Domain aus. Beim Einsatz von Let’s Encrypt zur Erstellung eigener Zertifikate kann es bei DynDNS-Domains zu Problemen kommen, wenn bereits zu viele Leute Zertifikate für die spezielle DynDNS-Second-Level-Domain erzeugt haben. Eine genauere Beschreibung der Problematik und ein eleganter Lösungsansatz ist im Artikel HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx zu finden.

Nach der Erzeugung der Zertifikate liegen die dazugehörigen Dateien in folgendem Verzeichnis: /etc/letsencrypt/live/myserver.dyndns.org

• cert.pem: Das öffentliche Zertifikat in Reinform
• chain.pem: Öffentliches Zertifikat aus der sog. Keychain
• fullchain.pem: entspricht cert.pem + chain.pem
• privkey.pem: Privates Zertifikat

Selbst signiertes Zertifikat erstellen

Der Vollständigkeit halber, hier noch die Vorgehensweise, wenn doch ein selbst signiertes Zertifikat zum Einsatz kommen soll. Wer sich die Zertifikate über Let’s Encrypt erzeugt hat, kann den folgenden Abschnitt überspringen.

Zunächst erzeugen wir ein Verzeichnis, welches die SSL-Zertifikate beinhaltet, die nginx verwenden soll:

mkdir -p /etc/nginx/ssl

Anschließend wird das SSL-Zertifikat über folgenden Befehl generiert.

openssl req -new -x509 -days 365 -nodes -out /etc/nginx/ssl/certificate.crt -keyout /etc/nginx/ssl/certificate.key

Man wird dann dazu aufgefordert, einige Angaben (z.B. zum Standort) zu machen. Prinzipiell ist es hier nicht zwingend notwendig, dass diese Eingaben auch stimmen. Wichtig ist nur, dass die URL, unter der der ownCloud-Server später erreichbar sein soll, unter Common Name angegeben wird (besonders, wenn später der Zugriff auch mit einem Windows Phone erfolgen soll). Wie bereits erwähnt, verwende ich im Rahmen des Artikels die URL myserver.dyndns.org.

Erweiterte Sicherheit: Diffie-Hellman-Parameter

Um die Sicherheit noch weiter zu erhöhen, sind auch noch sog. Diffie-Hellman-Parameter zu generieren. Dies sorgt für eine sichere Verschlüsselung, die ansonsten nicht mit immer garantiert werden kann. Mehr Informationen zu diesem Thema sind hier zu finden (englisch): Guide to Deploying Diffie-Hellman for TLS

Dies sollte immer ausgeführt werden, ganz gleich, ob ein selbst signiertes Zertifikat, oder ein Zertifikat von Let’s Encrypt zum Einsatz kommt.

openssl dhparam -out /etc/nginx/ssl/dhparams.pem 2048

Zugriffsberechtigungen für Zertifikat-Dateien setzen

Aus Sicherheitsgründen sollten nun noch die Zugriffsberechtigungen auf die Zertifikat-Dateien eingeschränkt werden:

chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/cert.pem
chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/chain.pem
chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/fullchain.pem
chmod 600 /etc/letsencrypt/live/myserver.dyndns.org/privkey.pem

Bei einem selbst signierten Zertifikat lauten die Befehle wie folgt:

chmod 600 /etc/nginx/ssl/certificate.crt
chmod 600 /etc/nginx/ssl/certificate.key
chmod 600 /etc/nginx/ssl/dhparams.pem

Konfiguration nginx

Wenn das SSL-Zertifikat bereit steht, geht es nun an die Konfiguration des Webservers. nginx muss an einigen Stellen angepasst werden, um einen sicheren und reibungslosen Betrieb sicher zu stellen.

Webroot anlegen

Das Root-Verzeichnis unseres Webservers soll in /var/www liegen. Dieses Verzeichnis muss neu angelegt werden und mit den entsprechenden Rechten für den Webserver-Benutzer ausgestattet werden. Das gleiche gilt für das Datenverzeichnis von ownCloud, welches wir hier auch gleich mit anlegen können. Zu beachten ist dabei, dass sich aus Sicherheitsgründen das Datenverzeichnis der Cloud außerhalb des Webroots befinden sollte.

mkdir -p /var/www
mkdir -p /var/oc_data
chown -R www-data:www-data /var/www
chown -R www-data:www-data /var/oc_data

Allgemeine nginx-Konfiguration anpassen

Es folgt die allgemeine Anpassung der nginx-Konfiguration:

nano /etc/nginx/nginx.conf

Hier muss der Benutzer angegeben werden, unter dem der Webserver laufen soll (user). Ebenfalls sollte die Anzahl der Threads angepasst werden, mit dem nginx die Verbindungen abarbeitet (worker_processes). Wird hier auto angegeben, wird pro CPU-Kern ein Thread angelegt. An dieser Stelle kann auch noch gleich die nginx-Versionsinformation entfernt werden, die z.B. auf Fehlerseiten angezeigt wird (server_tokens).
Die komplette nginx.conf sieht somit folgendermaßen aus (Änderungen sind markiert):

user  www-data www-data;
worker_processes auto;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    server_tokens off;

    include /etc/nginx/conf.d/*.conf;
}

Default-Seite deaktivieren

nginx ist nach der Installation so konfiguriert, dass eine sog. Default-Seite aktiv ist. Diese sieht man beim Aufruf mit dem Browser (siehe oben). Da diese Default-Seite nur dazu gedacht ist, die initiale nginx-Installation zu testen, kann diese deaktiviert werden.
Dazu wird die entsprechende Konfigurations-Datei umbenannt (nginx lädt nur die Konfigurations-Dateien, die mit .conf enden). Nach dem Neustarten von nginx wird diese Default-Seite nicht mehr im Browser angezeigt.

mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.disabled 
service nginx restart

Virtuellen Host für ownCloud anlegen

Nachdem wir bereits die Default-Seite deaktiviert haben, ist es nun an der Zeit, einen neuen virtuellen Host für ownCloud anzulegen, d.h. eine neue Konfigurations-Datei für nginx. Ich habe mich dazu entschieden, ownCloud nicht im Webroot (myserver.dyndns.org) laufen zu lassen, sondern in einem Unterverzeichnis (myserver.dyndns.org/owncloud). Dies hat den Vorteil, dass man auch mehrere Websites auf dem gleichen Webserver mit nur einem virtuellen Host laufen lassen kann.

Leider wird in Tutorials zu diesem Thema immer nur die von ownCloud vorgeschlagene nginx-Konfiguration übernommen und nur leicht abgeändert. Für einen Zugriff über ein Unterverzeichnis sind hier allerdings viele Anpassungen notwendig.

Zunächst legen wir eine neue nginx-Konfiguration an. Ich benenne diese immer wie die URL, unter der der Server später erreichbar sein soll:

nano /etc/nginx/conf.d/myserver.dyndns.org.conf

Der komplette Inhalt dieser Datei sieht dann folgendermaßen aus:

upstream php-handler {
  server unix:/var/run/php5-fpm.sock;
  }

server {
  listen 80;
  server_name myserver.dyndns.org 192.168.178.20;
  # enforce https
  return 301 https://$server_name$request_uri;
  }

server {
  listen 443 ssl;
  server_name myserver.dyndns.org 192.168.178.20;

  ssl_certificate /etc/letsencrypt/live/myserver.dyndns.org/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/myserver.dyndns.org/privkey.pem;
  
  # Bei einem selbst signierten Zertifikat:
  #ssl_certificate /etc/nginx/ssl/certificate.crt;
  #ssl_certificate_key /etc/nginx/ssl/certificate.key;

  # Add headers to serve security related headers
  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;

  ssl_dhparam /etc/nginx/ssl/dhparams.pem;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

  # Path to the root of your installation
  root /var/www/;
  
  index index.php index.html;

  # General PHP handler  
  location ~ \.php$ {
   include fastcgi_params;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   fastcgi_param HTTPS on;
   fastcgi_pass php-handler;
   }
   
   #
   # ownCloud
   #   
   rewrite ^/owncloud/caldav(.*)$ /owncloud/remote.php/caldav$1 redirect;
   rewrite ^/owncloud/carddav(.*)$ /owncloud/remote.php/carddav$1 redirect;
   rewrite ^/owncloud/webdav(.*)$ /owncloud/remote.php/webdav$1 redirect;
   
   location /owncloud {
    # set max upload size
    client_max_body_size 513M;

    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;
    
    error_page 403 /owncloud/core/templates/403.php;
    error_page 404 /owncloud/core/templates/404.php;
	
    # The following 2 rules are only needed with webfinger
    rewrite ^/owncloud/.well-known/host-meta /owncloud/public.php?service=host-meta last;
    rewrite ^/owncloud/.well-known/host-meta.json /owncloud/public.php?service=host-meta-json last;
    rewrite ^/owncloud/.well-known/carddav /owncloud/remote.php/carddav/ redirect;
    rewrite ^/owncloud/.well-known/caldav /owncloud/remote.php/caldav/ redirect;
	
    rewrite ^(/owncloud/core/doc/[^\/]+/)$ /owncloud/$1/index.html;
	
    try_files $uri $uri/ /owncloud/index.php;

     # ownCloud specific PHP handler
     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 php-handler;
      fastcgi_read_timeout 300;
      fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/oc_data:/dev/urandom";
     }
   }  
   
   location = /owncloud/robots.txt {
    allow all;
    log_not_found off;
    access_log off;
   }
	
   location ~ ^/owncloud/(?:\.htaccess|data|config|db_structure\.xml|README){
    deny all;
   }
	
   # Optional: set long EXPIRES header on static assets
   location ~* ^/owncloud(/.+\.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf))$ {
    expires 30d;
    # Optional: Don't log access to assets
    access_log off;
   }
}

Noch ein paar Erläuterungen zu dieser Konfiguration:

• Der Zugriff auf die Cloud erfolgt immer verschlüsselt per HTTPS. Dafür sorgt der erste Server-Block. Hier werden sämtliche unverschlüsselte Verbindungen an den zweiten Server-Block weitergegeben, der per HTTPS zu erreichen ist.
• Mit

  server_name

  werden die Domains (oder IP-Adressen) angegeben, auf die der entsprechende Server-Block reagieren soll. In unserem Fall „bedient“ der Server die Domain myserver.dyndns.org (Zugriff aus dem Internet). Ebenfalls wird hier die IP-Adresse des Rechners angegeben, so dass der Webserver auch unter dieser Adresse im lokalen Netzwerk erreichbar ist.

• Es folgt die Einbindung des soeben erstellten SSL-Zertifikates.
• Die

  add_header

  Anweisungen sind für die erhöhte Sicherheit notwendig. Ohne diese Einträge werden später Warnungen im Admin-Bereich von ownCloud angezeigt.

• Anschließend werden die zuvor erzeugten Diffie-Hellman-Parameter eingebunden.
• Der erste Handler für PHP ist für alles außerhalb vom Verzeichnis /owncloud zuständig. Ich habe mich hier für zwei getrennte PHP-Handler entschieden, da dem ownCloud-PHP-Handler weitere Parameter übergeben werden.
• Es folgt die Konfiguration für das Verzeichnis /ownCloud. Diese ist an die vorgeschlagene nginx-Konfiguration der ownCloud-Dokumentation angelehnt, wurde aber dahingehend angepasst, dass ownCloud in einem Unterverzeichnis (myserver.dyndns.org/owncloud) installiert wird.
• Der ownCloud-spezifische PHP-Handler beinhaltet mehr Parameter als der allgemeine PHP-Handler (s.o.). Wichtig ist hier, dass durch

  fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/oc_data:/dev/urandom";

  der Wert

  open_basedir

  aus der php.ini überschrieben wird. ownCloud bekommt hiermit Zugriff auf Webroot, das tmp-Verzeichnis, das Datenverzeichnis und die virtuelle Gerätedatei /dev/urandom, die einen Zufallszahlen-Generator für ownCloud bereitstellt.

Nun sollte der nginx Webserver neu gestartet werden, damit die neue Konfiguration auch geladen wird. Der zuvor aufgeführte Befehl testet diese Konfiguration zunächst. Falls irgendetwas nicht stimmen sollte (z.B. auf Grund eines Tippfehlers), wird dies hier angezeigt.

nginx -t 
service nginx restart

Konfiguration MariaDB

MariaDB ist nach der Installation noch nicht für maximale Sicherheit konfiguriert. Dies holen wir nun mit folgendem Befehl nach:

mysql_secure_installation

Da bereits ein Root-Passwort während der Installation vergeben wurde, muss dies nicht mehr geändert werden. Alle anderen Fragen sollte man allerdings mit Ja (y) beantworten.

Ebenfalls muss die Datenbank-Konfiguration angepasst werden:

nano /etc/mysql/my.cnf

Im Abschnitt [mysqld] muss hier folgender Eintrag zu finden sein, ansonsten wird das ownCloud-Setup später auf Fehler laufen:

binlog_format = MIXED

MariaDB sollte nach diesen Änderungen anschließend neu gestartet werden:

service mysql restart

Konfiguration PHP

Es folgt die Konfiguration von PHP, um einen sicheren Zugriff auf ownCloud zu ermöglichen.

Zunächst wird die php.ini für den FastCGI Process Manager (fpm) angepasst. Über fpm kommuniziert nginx mit PHP:

nano /etc/php5/fpm/php.ini

Folgende Werte sollten hier angepasst werden:

• post_max_size = 513M

  Wird zusammen mit dem nächsten Wert für den Upload von großen Dateien benötigt.

• upload_max_filesize = 513M

• cgi.fix_pathinfo = 0

  Wird von nginx benötigt

• open_basedir = /var/www/:/tmp/

  Schränkt den Zugriff von PHP auf das Webroot- und das temporäre Verzeichnis ein. Dadurch kann PHP auf sonst keine Dateien des Systems zugreifen oder diese verändern.

Neben fpm kann PHP auch über die Kommandozeile aufgerufen werden. Dies wird später für den ownCloud-Cron-Job benötigt. Hier erfolgt die Konfiguration in einer anderen Datei:

nano /etc/php5/cli/php.ini

• cgi.fix_pathinfo = 0

  siehe oben.

• open_basedir = /var/www/:/tmp/:/var/oc_data

  Schränkt die oben erwähnt den Zugriff von PHP ein. Zusätzlich wird hier das Datenverzeichnis von ownCloud mit angegeben, da dies außerhalb des Webroots liegt.

• apc.enable_cli = 1

  Wird benötigt, damit der Cron-Job von ownCloud später auch vom Caching Gebrauch machen kann. Ohne diesen Eintrag ist der Cron-Job nicht lauffähig.

Wenn das Verzeichnis /etc/php5/cli nicht vorhanden sein sollte, fehlt vermutlich das Paket php5-cli. Eigentlich sollte dieses bereits als Abhängigkeit der anderen php-Pakete mit installiert worden sein. Falls dieses Paket dennoch fehlen sollte, muss dieses nun nachinstalliert werden:

apt-get install php5-cli

Die letzte Anpassung für PHP erfolgt in der sog. Pool-Konfiguration (fpm definiert einen Pool, der alle PHP-Anweisungen behandelt):

nano /etc/php5/fpm/pool.d/www.conf

Hier sucht man nach dem Eintrag Pass environment variables like LD_LIBRARY_PATH. ALL &VARIABLES are taken from the current environment. Hier sind die Kommentare (Semikolon) bei allen Einträgen zu entfernen, die mit env beginnen. Ohne diese Änderung wird ownCloud später eine Warnung im Admin-Bereich anzeigen, dass keine Umgebungs-Variablen definiert sind.

Mit einem Neustart von PHP werden die Änderungen übernommen:

service php5-fpm restart

Einrichtung ownCloud

Nachdem nun Webserver, Datenbank und PHP soweit konfiguriert sind, geht es nun endlich an die Installation von ownCloud.

Download

Zunächst einmal braucht man den Download-Link zur aktuellen ownCloud-Version: Auf der ownCloud-Homepage klickt man auf Download und wählt dann unter Punkt 1 (Download ownCloud) wiederum den Button Download. Nun werden Links zum direkten Download als .tar.bz2 oder .zip Datei angezeigt. Fährt man mit der Maus über einen Link, wird das Ziel im unteren Teil des Browserfensters angezeigt.

Nun kann man auf dem Linux-Rechner das entsprechende Archiv herunterladen und in das Web-Verzeichnis entpacken. Anschließend kann das Archiv wieder gelöscht werden:

wget https://download.owncloud.org/community/owncloud-8.2.1.tar.bz2 
tar –xjf owncloud-8.2.1.tar.bz2 –C /var/www 
rm owncloud-8.2.1.tar.bz2

Nun werden noch einmal explizit die Rechte für das ownCloud-Verzeichnis und das dazugehörige Datenverzeichnis gesetzt. Ansonsten beschwert sich das Setup später über fehlende Schreibrechte.

chown -R www-data:www-data /var/www/owncloud 
chown -R www-data:www-data /var/oc_data

Datenbank anlegen

Bevor das ownCloud-Setup über den Browser aufgerufen wird, muss noch eine Datenbank speziell für ownCloud angelegt werden. Dies wird in der Kommandozeile von MariaDB  erledigt, die mit Root-Rechten aufgerufen wird (das Passwort ist dabei das bei der Installation vergebene Root-Passwort):

mysql -u root -p

Nun werden die Datenbank und ein eigener Datenbank-Benutzer angelegt. Durch die Angabe localhost kann der Zugriff auf die Datenbank nur vom lokalen Rechner aus erfolgen. Als Passwort sollte hier wieder ein sicheres Passwort verwendet werden.

create database owncloud_db;
create user owncloud_user@localhost identified by 'MeInPasSw0rT';
grant all privileges on owncloud_db.* to owncloud_user@localhost;
flush privileges;
exit;

ownCloud Setup

Nach diesen Vorbereitungen kann das ownCloud Setup aufgerufen werden. Dazu einfach im Browser die Adresse https://192.168.178.20/owncloud eingeben.

Wenn ein selbst signiertes Zertifikat zum Einsatz kommt, folgt zunächst eine Warnung, dass das verwendete Zertifikat nicht überprüft werden kann. Diese Meldung kann ignoriert werden (Mit dieser Website fortfahren (nicht empfohlen) – die genaue Meldung ist abhängig vom verwendeten Browser), da es sich ja um ein selbst signiertes Zertifikat handelt. Wenn das Zertifikat über Let’s Encrypt erzeugt wurde, betrachtet der Browser dieses als vertrauenswürdig und zeigt dementsprechend auch keine Warnung an.

Zur Ersteinrichtung wird zunächst einmal ein Administrator-Konto angelegt. Der Benutzername ist hierbei frei wählbar. Besonders wichtig ist hier die Wahl eines sicheren Passwortes, da die Login-Seite der Cloud später öffentlich über das Internet erreichbar sein wird. Darüber hinaus wird der Pfad zum Datenverzeichnis abgefragt (/var/oc_data). Die Angaben zur Datenbank-Verbindung entsprechen der zuvor angelegten Datenbank. Mit einem Klick auf Installation abschließen wird die Einrichtung nach einem kurzen Moment abgeschlossen.

Hinweis: Falls beim ersten Aufruf der ownCloud oder nach dem Klick auf Installation abschließen Fehlermeldungen angezeigt werden, dann sollten die zuvor durchgeführten Schritte noch einmal kontrolliert werden. Meistens liegt dies dann an fehlenden Schreibrechten im Webroot- oder Datenverzeichnisses. Ebenso bricht das Setup mit einer Meldung ab, wenn das binlog_format von MariaDB nicht auf MIXED geändert wurde.

Anpassung der ownCloud-Konfiguration

Damit ist das Setup zunächst abgeschlossen und die eigene Cloud kann verwendet werden. Dennoch sollte man die nochmals die Konfiguration kontrollieren und ggf. anpassen:

nano /var/www/owncloud/config/config.php

Vertrauenswürdige Domains

Momentan greifen wir noch über die lokale IP-Adresse auf die Cloud zu. Damit der Zugriff später auch über die (öffentliche) DynDNS-Domain möglich ist, muss diese zu den vertrauenswürdigen Domains hinzugefügt werden:

 array (
    0 => '192.168.178.20',
    1 => 'myserver.dyndns.org',
  ),

Zeitzone einstellen

Optional kann hier gleich die Zeitzone angepasst werden. Dies betrifft v.a. die Logeinträge der ownCloud.

'logtimezone' => 'Europe/Berlin',

Warnungen im Admin-Bereich

Nach der Anpassung der Konfiguration sollte man sich nun als Administrator anmelden und einen Blick in den Admin-Bereich der ownCloud werfen: Benutzername (rechts oben) > Administration. In diesem Bereich gibt ownCloud Warnungen aus, wenn irgendetwas an der Konfiguration oder den Zugriffsrechten nicht passt.

In unserem Fall sollten nun zwei Warnungen ausgegeben werden:

• Transactional file locking is using the database as locking backend, for best performance it’s advised to configure a memcache for locking. See the documentation for more information.
• Es wurde kein PHP Memory Cache konfiguriert. Konfiguriere zur Erhöhung der Leistungsfähigkeit, soweit verfügbar, einen Memory Cache. Weitere Informationen finden Sie in unserer Dokumentation.

Beide Warnungen stellen dabei keinen Fehler in der Installation dar, sondern weisen lediglich darauf hin, dass die Performance der ownCloud-Installation mit weiteren Schritten verbessert werden kann. Gerade bei Installationen, auf die nur wenige Benutzer zugreifen, kann man diese Warnungen auch ignorieren. Im Folgenden wird die ownCloud-Installation dennoch angepasst, so dass keine Warnung mehr im Administrations-Bereich angezeigt wird.

Verwendung von PHP Memory Cache

Das Problem, welches den PHP Memory Cache betrifft, ist dabei recht schnell zu lösen. Dazu muss noch einmal die ownCloud-Konfiguration angepasst werden:

nano /var/www/owncloud/config/config.php

Hier aktivieren wir lediglich den PHP Memory Cache. Voraussetzung ist hierfür, dass das Paket php5-apcu bei der Installation der PHP-Pakete mit installiert wurde (s.o.).

'memcache.local' => '\OC\Memcache\APCu',

Transactional File Locking

Die weitere Warnung betrifft das sog. Transactional File Locking: Wenn ein Benutzer gerade eine Datei bearbeitet, sollte diese für die anderen Benutzer gesperrt sein. Dieses Locking wird standardmäßig über die Datenbank realisiert, was allerdings nicht besonders performant ist.
ownCloud bietet aber auch die Möglichkeit, dieses Locking über eine spezielle In-Memory-Datenbank zu realisieren: Dabei kommt die No-SQL-Datenbank Redis zum Einsatz.

Vor den folgenden Schritten sollte kontrolliert werden, ob unter den ownCloud-Apps die File Locking App zu finden ist. In diesem Fall muss diese App deaktiviert werden, weil ich die beiden Locking-Mechansimen ansonsten gegenseitig aussperren.

Anschließend müssen zunächst einmal die fehlenden Pakete nachinstalliert werden:

apt-get install php5-redis redis-server

Nach der Installation muss die Redis-Konfiguration angepasst werden, damit ownCloud diese Datenbank verwenden kann:

nano /etc/redis/redis.conf

Da die ownCloud-Installation nur auf einem Rechner läuft, ist die generelle Empfehlung, Redis für die Verwendung von Unix-Sockets zu konfigurieren. Dazu sind zwei Zeilen in der Konfiguration anzupassen:

unixsocket /var/run/redis/redis.sock 
unixsocketperm 770

Besonders wichtig ist hier das Setzen der korrekten Berechtigung, damit der Webserver-User (unter dem die ownCloud-Instanz läuft) den entsprechenden Unix-Socket verwenden kann.

Anschließend kann die Konfigurations-Datei gespeichert werden. Nun muss nur noch der Webserver-User (in unserem Fall www-data) in die Gruppe der Redis-Benutzer hinzugefügt werden. Wird dieser Schritt nicht ausgeführt, kann ownCloud später nicht auf Redis zugreifen und man erhält bei jedem Datei-Zugriff eine Fehlermeldung (redis went away).

usermod -a -G redis www-data

Der letzte Schritt stellt wieder die Anpassung der ownCloud-Konfiguration dar, damit für das File Locking Redis verwendet wird. Dazu einfach folgende Zeile in die config.php eintragen:

  'filelocking.enabled' => 'true',
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
     'host' => '/var/run/redis/redis.sock',
     'port' => 0,
     'timeout' => 0.0,
      ),

Unter host muss der zuvor beschriebene Unix-Socket angegeben werden.

Nach diesen Schritten sollten die Warnungen im ownCloud-Adminbereich verschwunden sein. Dennoch empfehle ich, die Verwendung von Redis sofort noch einmal zu testen, da bei einer falschen Konfiguration keine Warnung o.ä. angezeigt wird. Dazu einfach unter Dateien eine neue Text-Datei erstellen und anschließend speichern. Fall dabei keine Fehlermeldung bzgl. Redis angezeigt wird, ist die Konfiguration fehlerfrei.

Abschließend noch einmal die komplette Konfigurations-Datei von ownCloud. instanceid, passwortsalt und secret habe ich hier entfernt, diese sollten nach dem Setup nicht mehr verändert werden. Alle anderen Änderungen, die soeben durchgeführt wurden, sind markiert:

<?php
$CONFIG = array (
  'instanceid' => '...',
  'passwordsalt' => '...',
  'secret' => '...',
  'trusted_domains' => 
  array (
    0 => '192.168.178.20',
    1 => 'myserver.dyndns.org',
  ),
  'datadirectory' => '/var/oc_data',
  'overwrite.cli.url' => 'https://192.168.178.20/owncloud',
  'dbtype' => 'mysql',
  'version' => '8.2.1.4',
  'dbname' => 'owncloud_db',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'owncloud_user',
  'dbpassword' => 'MeInPasSw0rT',
  'logtimezone' => 'Europe/Berlin',
  'installed' => true,
  'memcache.local' => '\OC\Memcache\APCu',
  'filelocking.enabled' => 'true',
  'memcache.locking' => '\OC\Memcache\Redis',
  'redis' => array(
    'host' => '/var/run/redis/redis.sock',
    'port' => 0,
    'timeout' => 0.0,
   ),
);

Weitere Warnung im Admin-Bereich

Sollten nun noch weitere Warnungen im Bereich Administration der ownCloud angezeigt werden, so liegt vermutlich ein genereller Fehler bei der Konfiguration vor. Dazu gibt es eine Seite in der ownCloud-Dokumentation, die die Warnungen und deren Ursachen genau beschreibt: Warnings on Admin Page

Zugriffsrechte anpassen

Nach der Installation von ownCloud sollten die Datei-/Verzeichnis-Berechtigungen aus Sicherheitsgründen noch einmal explizit gesetzt werden. Dies geschieht durch folgende Befehle:

find /var/www/owncloud/ -type f -print0 | xargs -0 chmod 0640
find /var/www/owncloud/ -type d -print0 | xargs -0 chmod 0750
chown -R root:www-data /var/www/owncloud/
chown -R www-data:www-data /var/www/owncloud/apps/
chown -R www-data:www-data /var/www/owncloud/config/
chown -R www-data:www-data /var/www/owncloud/themes/
chown -R www-data:www-data /var/oc_data/
chown root:www-data /var/www/owncloud/.htaccess
chown root:www-data /var/www/owncloud/data/.htaccess
chmod 0644 /var/www/owncloud/.htaccess
chmod 0644 /var/oc_data/.htaccess

Dabei kann es sein, dass die Datei /var/oc_data/.htaccess nicht existiert und eine entsprechende Fehlermeldung ausgegeben wird. Dies kann jedoch ignoriert werden.

ownCloud Cronjob einrichten

Standardmäßig werden Hintergrundaufgaben, die in regelmäßigen Abständen erledigt werden müssen, von ownCloud über AJAX ausgeführt. D.h. dass diese Hintergrundaufgaben immer dann ausgeführt werden, wenn ein Benutzer angemeldet ist und eine Seite geladen wird. Dies ist jedoch nicht sehr performant und es bietet sich daher an, diese Hintergrundaufgaben per Cron erledigen zu lassen.

Dieser Schritt ist nicht zwingend notwendig, empfiehlt sich aber besonders beim Einsatz eines Raspberry Pi oder ähnlich schwacher Hardware, da die Ausführung per Cron viel ressourcenschonender ist.

Dazu legen wir einen neuen Cronjob für den Webserver-Benutzer an:

crontab -u www-data -e

Wenn das System nachfragt, wie wir die Datei bearbeiten möchten, wählt man am besten den bekannten Editor nano. Folgendes wird nun am Ende der Datei eingefügt:

*/15 * * * * php -f /var/www/owncloud/cron.php > /dev/null 2>&1

Dies sorgt dafür, dass die Hintergrundarbeiten alle 15 Minuten ausgeführt werden.

Damit diese Aktivitäten nun nicht doppelt (per AJAX und per Cron) ausgeführt werden, muss man noch im Admin-Bereich von ownCloud unter dem Punkt Cron die Einstellung AJAX auf Cron ändern.

Weitere Konfiguration der ownCloud

Damit ist die Einrichtung der ownCloud abgeschlossen. Alle weiteren Schritte zur Konfiguration (z.B. die serverseitige Verschlüsselung) hängt vom individuellen Einsatzzweck ab. Dazu verweise ich hier auf das offizielle Administrations-Handbuch von ownCloud.

Abschluss-Arbeiten: Port-Forwarding und Zertifikat installieren

ownCloud ist nun installiert und einsatzbereit. Es fehlen nur noch zwei Schritte, damit die persönliche Cloud auch über das Internet erreichbar ist und beim Zugriff keine Warnungen mehr von Browser ausgegeben werden.

Port-Forwarding einrichten

Bisher ist die ownCloud-Installation nur im lokalen Netzwerk erreichbar. Damit man auch aus dem Internet darauf zugreifen kann, muss nun noch eine Weiterleitung der entsprechenden Ports 80 (für HTTP) und 443 (HTTPS) im Router eingerichtet werden. Das Vorgehen dazu unterscheidet sich von Router zu Router. Hier das beispielhafte Vorgehen bei einer FritzBox:

• Die Erweiterte Ansicht muss aktiv sein (erster Punkt der unteren Menüleiste).
• Unter Internet > Freigaben klicken wir auf den Button Neue Portfreigabe.
• Portfreigabe aktiv für: Andere Anwendungen
• Protokoll: TCP
• von Port: 80
• bis Port: 80
• an Computer: <Name des Rechners, auf dem ownCloud läuft>
• an Port: 80

Das gleiche muss nun noch für den TCP Port 443 wiederholt werden, damit der Zugriff auch per HTTPS möglich ist.

Ebenfalls muss in der Konfiguration des Routers die Anmeldung an den DynDNS-Dienst konfiguriert sein, damit dieser dann über die DynDNS-Adresse (in diesem Beispiel myserver.dyndns.org) erreicht werden kann.

Zertifikat installieren (nur bei selbst signierten Zertifikaten)

Der folgende Abschnitt muss nur beachtet werden, wenn ein selbst signiertes SSL-Zertifikat zum Einsatz kommt. Wenn – wie empfohlen – ein Zertifikat über Let’s Encrypt generiert wurde, betrachten moderne Browser dieses als vertrauenswürdig und zeigen daher auch keine Warnung beim Zugriff auf die ownCloud an.

Bisher gibt der Browser beim Zugriff auf ownCloud eine Warnung aus, dass das benutzte Zertifikat nicht bekannt ist. Da es sich hierbei um ein selbst signiertes Zertifikat handelt, kann der Browser dies ja auch nicht kennen. Damit diese Warnung nicht mehr angezeigt wird, ist es daher notwendig, dass das Zertifikat auf dem Rechner installiert wird. Hierbei sei erwähnt, dass dies ein optionaler Schritt ist: Unabhängig davon, ob das Zertifikat installiert ist oder nicht, die gesamte Kommunikation mit der Cloud läuft verschlüsselt ab.

Das folgende Vorgehen bezieht sich auf Windows-Rechner. Auf anderen Betriebssystemen ist hier ein anderes Vorgehen notwendig.
Am besten führt man die Schritte mit dem Internet Explorer aus, da auf diese Weise das Zertifikat systemweit installiert wird und jeder andere Browser das Zertifikat ebenso akzeptieren wird.

Dazu starten wir den Internet Explorer mit Administrator-Rechten (wichtig!) und rufen die URL der ownCloud-Installation auf. Die Zertifikat-Warnung wird ignoriert. Nun wird die Adressleiste des Browsers rot gefärbt. Wir klicken hier auf Zertifikatfehler und anschließend auf Zertifikate anzeigen.

Nun öffnet sich ein Fenster mit Informationen zum Zertifikat. Man klickt hier nun auf den Button Zertifikat installieren…

Es öffnet sich der Assistent zur Zertifikat-Installation. Hier wählt man im ersten Schritt Lokaler Computer als Speicherort. Anschließend wählt man Alle Zertifikate im folgenden Speicher speichern und gibt hier den Ordner Vertrauenswürdige Stammzertifizierungsstellen an.

Durch einem Klick auf Weiter und Fertig stellen wird das Zertifikat installiert.

Nach einem Neustart des Browsers wird das Zertifikat nun ohne Warnung akzeptiert (nicht nur vom Internet Explorer, sondern auch von anderen auf dem Rechner installierten Browsern, wie z.B. Chrome).

Download Checkliste

Hier noch einmal eine Zusammenfassung aller zur Installation benötigten Schritte als PDF. Dieses Dokument verzichtet auf die Erklärungen und Hintergrundinformationen des Artikels, sondern listet nur alle verwendeten Befehle und Eingaben hintereinander auf. Somit ist es vielmehr eine Checkliste, die einfach abgearbeitet werden kann.

Download Checkliste

Der Mühe Lohn

Wenn alle Schritte dieses doch recht langen Artikels abgearbeitet wurden, hat man nicht nur eine sichere und performante ownCloud-Installation, die auch mühelos auf einem Raspberry Pi läuft, sondern behält v.a. die Hoheit über seine eigenen Daten.

Ich selbst habe viel Zeit investieren müssen, um die Prozedur der Installation und Konfiguration soweit zu optimieren, dass ownCloud nun optimal läuft. Ich hoffe, dass ich dem einen oder anderen mit diesem Artikel etwas Zeit zum Suchen und Rumprobieren ersparen kann. Falls es dennoch Unklarheiten oder Verbesserungsvorschläge gibt, schreibt mir diese einfach in die Kommentare. Ich versuche euch dann soweit wie möglich weiter zu helfen.

Weiterführende Artikel

• Ubuntu Server als Hyper-V Gastsystem installieren und optimal einrichten
• ownCloud Updates richtig durchführen
• HTTPS für alle: SSL-Zertifikate mit Let’s Encrypt und nginx

Links

• Cloud Computing (Wikipedia)
• Offizielle ownCloud Homepage
• Offizielle nginx Homepage (englisch)
• nginx Wiki mit vielen Anleitungen und Beispielen (englisch)
• Offizielle MariaDB Homepage (englisch)
• Offizielle PHP Homepage (englsich)
• ownCloud Server Administration Manual (englisch)
• Offizielle Redis Homepage (englisch)
• Let’s Encrpyt Homepage (englisch)

Ähnliche Artikel:

ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban