DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP

ownCloud Logo

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:

Nginx läuft auf dem Server

Nginx läuft auf dem Server

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:

Root-Passwort für MariaDB vergeben

Root-Passwort für MariaDB vergeben

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.

SSL-Zertifikat generieren

SSL-Zertifikat generieren

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.

Absichern der MariaDB-Installation

Absichern der MariaDB-Installation

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.

Download-Link für ownCloud

Download-Link für ownCloud

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.

Browser-Warnung wegen selbst signiertem Zertifikat

Browser-Warnung wegen selbst signiertem Zertifikat

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.

ownCloud Setup

ownCloud Setup

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.

Warnungen im Admin-Bereich der ownCloud

Warnungen im Admin-Bereich der ownCloud

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.

Umstellung von AJAX auf Cron

Umstellung von AJAX auf Cron

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
FritzBox: Portfreigabe für HTTP Port 80

FritzBox: Portfreigabe für HTTP 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.

Zertifikat-Warnung im Internet Explorer

Zertifikat-Warnung im Internet Explorer

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.

Installation des Zertifikats

Installation des Zertifikats

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

Links

, , , , , , , , , ,

Kommentare: 91

  • RMTX99 sagt:

    Hey,

    habe komischerweise die Datei nano /etc/php5/cli/php.ini nicht, auch das Verzeichnis cli nicht … woran kann das liegen?

  • RMTX99 sagt:

    Außerdem kriege ich die Fehlermeldung dass das verzeichnis /var/www/owncloud nicht gefunden werden konnte wenn ich die Rechte vergebe, irgendeine idee? achja .. die maria db repositorie hat sich heute geändert, wenn du das anpassen möchtest ;)

  • RMTX99 sagt:

    mein erster Kommentar scheint nicht abgeschickt worden zu sein:

    ich habe weder folgende datei nano /etc/php5/cli/php.ini noch das verzeichnis cli, irgendeine idee woran das liegen könnte?

  • RMTX99 sagt:

    Habe das Problem selber gelöst, dir fehlt bei der installation der Pakete das Paket php5-cli odeR?

    • Jan sagt:

      Hallo RMTX99,

      schon das Paket php5-fpm bringt das Paket php5-cli eigentlich als Abhängigkeit mit (siehe Ubuntu Paketinformation). Daher müsste php5-cli nicht noch einmal explizit installiert werden. Hast du vielleicht die Pakete ohne Abhängigkeiten installiert?

      Wenn bei dir das Verzeichnis /var/www/owncloud nicht gefunden werden kann, überprüfe doch mal bitte, ob dieses Verzeichnis existiert: cd /var/www/ und dann ein ls. Wenn das ownCloud-Archiv an eine andere Stelle entpackt wurde, müssen die Verzeichnisse in allen folgenden Skripts angepasst werden.

      Das mit dem MariaDB-Repository werde ich anpassen, danke für den Hinweis!

      Gruß,
      Jan

  • Jan sagt:

    Habe aus aktuellem Anlass nun den kompletten Artikel überarbeitet, so dass nun die aktuellsten Programmversionen zum Einsatz kommen.
    Insbesondere wird nun die Installation und Einrichtung von Redis erläutert, welches ownCloud für das Transactional File Locking verwendet.

    Die Checkliste zum Download wurde ebenfalls entsprechend angepasst.

    Falls noch irgendetwas fehlen sollte, bitte einfach einen kurzen Hinweis in den Kommentaren hinterlassen.

    Gruß,
    Jan

  • Josef sagt:

    Hallo,

    wie ändert man die Zugriffsrechte, wenn man ein Update von OwnCloud machen möchte?
    Es kommt eine Fehlermeldung, dass der Server keine Schreibrechte hat. Ist durch die Anpassung der Zugriffsrechte auch logisch, allerdings weiß ich nicht wie man diese ändert, um das Update über OwnCloud starten zu können..

    Schonmal vielen Dank für die Anleitung :)

    • Jan sagt:

      Hallo Josef,

      ja, für ein Update müssen die Zugriffrechte wieder angepasst (gelockert) werden. Dafür einfach vor dem Update ein chown –R www-data:www-data /var/www/owncloud durchführen, dann hat der Webserver-Benutzer (unter dem die ownCloud ausgeführt wird) wieder die erforderlichen Schreibrechte.
      Nach dem Update dann aber daran denken, die Zugriffsrechte aus Sicherheitsgründen wieder anzupassen wie im Artikel beschrieben. Dazu kann man die auszuführenden Befehle auch einfach in ein Skript packen. Dies macht die ganze Sache dann auch für das nächste Update wesentlich einfacher.

      Gruß,
      Jan

    • Jan sagt:

      @Josef:
      Da ein ownCloud-Update in der hier vorgestellten Konfiguration etwas aufwendiger ist und meine Antwort auf deine Frage etwas knapp ausgefallen ist, habe ich dazu einen gesonderten Artikel verfasst: ownCloud Updates richtig durchführen
      Hier sollten alle Fragen rund ums Update geklärt werden.

      Gruß,
      Jan

  • RMTX99 sagt:

    Hey,

    bei mir läuft es jetzt auch …
    für das PHP Memory Caching muss man unter ubuntu 14.04 auf jeden Fall die neue Version installieren, für den Fall dass da jemand Probleme mit hat.

    Ich habe nun nur noch ein Problem mit Redis. Ich bekomme nämlich die Fehlermeldungen

    Redis ist in einer älteren Version als 2.2.5 installiert, aus Stabilitäts- und Geschwindigkeitsgründen wird ein Update auf eine neuere Redis-Version empfohlen.
    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.

    … die Konfiguration passt soweit, aber ich habe diese besagt app die man deaktivieren soll nicht gefunden (weder unter aktiviert noch unter deaktiviert), kann es an der app liegen dass die noch irgendwo schlummert? weil sonst würde ich doch die zweite fehlermeldung nicht mehr bekommen oder?

    Viele Grüße
    RMTX99

    • Jan sagt:

      Hallo RMTX99,

      genau aus diesem Grund habe ich mich gegen Ubuntu 14.04 LTS entschieden, auch wenn es eigentlich sinnvoller wäre, hier auf eine LTS-Version zu setzen.
      Unter 14.04 ist das Paket php5-apcu zu alt, d.h. wird von ownCloud nicht unterstützt. Es wird mindestens APCu 4.06 benötigt. Hier hilft es nur, manuell eine neuere Version zu installieren. Das Vorgehen dazu ist hier recht gut beschrieben.

      Gleiches Problem bei Redis. Hier sollte dieser Artikel weiterhelfen.

      Wenn die File Locking App nicht angezeigt wird, ist alles in Ordnung. Bei einer frischen 8.2 Installation wird diese App gar nicht mehr mit installiert.
      Bei mir war sie noch vorhanden, weil ich von einer älteren ownCloud-Version upgedatet hatte.

      Gruß,
      Jan

  • Wimmer Günther sagt:

    Ich wollte mich mal für deine sehr Ausführliche Anleitung bedanken !
    Super Arbeit kann ich nur Sagen !
    Das sollte auch mal gesagt werden ;-)

    Ich habe es nach der Anleitung installiert und habe keine Probleme ….:-)

  • xander1709 sagt:

    Mir ist bei der Anpassung der Config /etc/nginx/conf.d/myserver.dyndns.org.conf nicht ganz klar, was alles auf meine persönlichen Einstellungen abgeändert werde muss. Die DNS und IP ist klar. Wie komme ich jedoch an zB ssl_ciphers. Ich kann ja schlecht ein C&P machen.

    Auf die Default-Seite nginx zu kommen ging noch, jedoch nach Installation von Owncloud hatte ich keinen Zugriff mehr auf /owncloud (mittels IP).

    Ebenso habe ich bei der Anpassung der /etc/php5/cli/php.ini vergeblich den Einstellung apc.enable_cli gefunden.

    Kann jemand ahnen, wo bei mir was falsch gelaufen ist oder etwas fehlt?

    • Jan sagt:

      Hallo xander1709,

      doch, im Prinzip kannst du Copy&Paste bei der myserver.dyndns.org.conf Datei machen. ;)
      Die Anpassungen, die du dann nur noch kontrollieren/anpassen musst:
      – evtl. den Dateinamen anpassen, damit der zu deiner Domain passt (optional)
      – den Pad bei ssl_certificate und ssl_certificate_key, falls du die Zertifikate woanders hin generiert hast
      – den Inhalt von ssl_ciphers habe ich von hier übernommen: Guide to Deploying Diffie-Hellman for TLS. Dies sollte eine sichere Ausgangsbasis darstellen.

      Wenn du keinen Zugriff auf die ownCloud nach der Installation hast, dann ist liegt das meist an der nginx-Site-Config: Hier darauf achten, dass die IP/Domain und der Port passt und dass root-Verzeichnis und location-Verzeichnis korrekt sind (also auf existierende Verzeichnisse zeigen).

      Wenn apc.enable_cli in der php.ini Dateien nicht vorhanden ist, dann einfach am Ende der jeweiligen Datei hinzufügen.

      Wenn es bei dir dann immer noch nicht klappen sollte, dann schick mir doch mal bitte eine conf-Datei per Mail, dann schau ich da gern mal drüber.

      Gruß,
      Jan

  • Bernd sagt:

    Hallo,

    ein wirklich klasse Anleitung!!!!!!

    Ich hätte eine Frage, was müsste ich ändern, damit dass Ganze auch ohne SSL Zertifikat funktioniert.
    Denn ich möchte die Owncloud hinter einer Sophos betreiben, diese soll das SSL handlich übernehmen.

    z.B.

    Fritzbox Port –> 12345 zur Sophos Webserverprotection Port 12345 –> routing zum echten Webserver z.B Port 80
    wäre soetwas möglich?

    bzw. in einer Installation mit Apache2 kann man beim abändern der .htaccess die Dateigrößenbeschränkung ändern. hier funktioniert das leider nicht.

    eine kleinigkeit würde ich mir noch wünschen:
    es gibt ein neues Addon in dem man Libreoffice im Web nutzen kann.
    Ich würde mcih sehr freunen wenn dazu eine Anleitung kommen würde :)
    https://apps.owncloud.com/content/show.php/LibreOffice+Online?content=174455

    Vielen Dank

    • Jan sagt:

      Hallo Bernd,

      danke für das Lob!

      Ehrlich gesagt habe ich keinerlei Erfahrung mit Sophos Webserverprotection. Wenn das SSL-Handling hier ordnungsgemäß übernommen wird, kannst du den Webserver auch ohne SSL auf Port 80 betreiben. Dazu müsste in der nginx Config-Datei (myserver.dyndns.org.conf) alles ownCloud-relevante (also alles ab der Zeile root /var/www/;) in den ersten Server-Block (der auf Port 80 lauscht) gepackt werden. Die Zeile return 301 https://$server_name$request_uri; (Weiterleitung auf den HTTPS-Server-Block) müsstest du dann natürlich entfernen.
      Allerdings sind die sicherheitsrelevanten Erweiterungen in der Config (add_header…) nicht umsonst da. All diese Sachen müsste dann die Sophos Webserverprotection übernehmen.

      Zur .htaccess: nginx kennt keine .htaccess, daher kann man hier auch keine Anpassungen vornehmen. Die Dateigrößenbeschränkung beim Upload setzt du wie beschrieben in der php.ini.

      Das LibreOffice Addon klingt interessant, v.a. weil auch MS Office Dokumente unterstützt werden. Wenn ich die Zeit finde, schaue ich mir das vielleicht mal näher an.

      Gruß,
      Jan

  • Bernd sagt:

    Hallo,

    Danke für die Antwort!
    Ich hoffe du findest Zeit ein kleines Tutorial anzufertigen :)

    Gruß Bernd

  • RMTX99 sagt:

    Hi,

    ich bins nochmal.

    Könntest du mir eine kurze checkliste geben, was ich alles berücksichtigen müsste wenn ich eine weitere Sub Domain machen wollen würde?

    Wäre super hilfreich für mich :)
    Viele Dank
    RMTX99

    • Jan sagt:

      Hallo RMTX99,

      das ist relativ einfach: angenommen, du willst neben meinedomain.de/owncloud noch phpMyAdmin aufsetzen, welches dann unter meinedomain.de/phpmyadmin erreichbar sein soll. Hier reicht es eigentlich bereits aus, einen Ordner phpmyadmin unter deinem Webroot zu erstellen (auf der gleichen Ebene wie der Ordner owncloud). Diese Subdomain dürfte dann auch bereits über den Browser auffindbar sein (nicht vergessen, nach einer Änderung der Config nginx neu zu starten).

      Falls die Anwendung, die auf der zweiten Subdomain laufen soll, weitere Änderungen und Anpassungen benötigt (wie dies ja bei ownCloud der Fall ist), dann muss noch ein zusätzlicher location-Block im Server-Block aufgenommen werden, der dann diese Subdomin-spezifischen Anpassungen enthält. Als Beispiel:

      location /phpmyadmin {
      # Nur als Beispiel: Zusätzlicher Passwort-Schutz (Basic Auth)
      auth_basic "Resticted";
      auth_basic_user_file /etc/nginx/.htpasswd
      }

      Das müsste es dann prinzipiell schon gewesen sein.

      Gruß,
      Jan

  • RMTX99 sagt:

    Hi,

    danke für deine Antwort genau um PHP my admin geht es auch …
    ich habe es mir schon so gedacht wie du es beschrieben hast und mit wordpress getestet, das klappt auch. PHP My Admin installiert man ja jedoch über apt-get und da weiß ich nicht wie ich das Paket einbinde.

    • Jan sagt:

      Hallo RMTX99,

      mit phpMyAdmin kenne ich mich nicht so recht aus (zumindest, was die Installation angeht).
      Auf den ersten Blick findest du jedoch hier eine recht gute Anleitung. Knackpunkt ist hierbei wohl der „Trick“ mit dem symbloischen Link, damit nginx Zugriff auf phpMyAdmin hat.

      Gruß,
      Jan

  • RMTX99 sagt:

    Hi Jan,

    probiere ich nachher direkt aus :) danke!

  • RMTX99 sagt:

    Ok die Anleitung hat irgendwie nicht so ganz hingehauen.

    habe es jetz über wget einfach von der homepage bezogen ins gewünschte subdomain verzeichnis extrahiert und tada es geht ;)

    danke :D

  • RMTX99 sagt:

    Habe doch nochmal ne Frage.

    Und zwar haben wir ja keines sites available datei sondern immer die jeweiligen Konfigurations Dateien im conf.d ordner. Wie schaffe ich das dann mit der Passwort Authentifikation? Ich habe das jetzt stumpf in die konfigurationsdatei für phpmyadmin gepackt aber das klappt nicht…

    • Jan sagt:

      Hallo RMTX99,

      für Basic Auth musst du eine codierte Passwort-Datei generieren lassen. Dazu gibt es hier einen guten Artikel. Damit konnte habe ich auch schon ein Basic Auth bei nginx umgesetzt.

      Ach ja: wunder dich bitte nicht, wenn beine Website die kommenden Tage temporär offline ist, ist wechsle gerade den Webspace-Anbieter. Man weiß ja nie, ob das alles reibungslos über die Bühne geht.

      Gruß,
      Jan

  • RMTX99 sagt:

    Hm okay. Läuft noch nicht, muss ich nochmal weiter schauen.

    Kannst du mir sagen wieso du für deinen Webserver die Einzelnen Subdomains mehr oder weniger in conf.d konfigurierst und nicht (wie in anderen Tutorials) alles untereinander in der Sites-Available Konfiguration zusammenfasst? :)

  • RMTX99 sagt:

    Hi nochmal,

    habe 2. Fragen, und zwar:

    1. Wieso legst du (im gegensatz zu allen anderen Tutorials) für jede Subdomain eine einzelne Konfigurationsdatei in conf.d an und nicht alle server Blöcke untereinander in der sites-available? Ist das nur der Übersichtshalber oder welchen Hintergrund hat das?

    2. Kannst du mir vielleicht auch beim Portforwarding helfen… Ich hab da so n Speedport W724V indem ich die TCP Port 80 und 443 weiterleite auf meinen Server allerdings klappt das nicht. Als DynDNS Anbieter habe ich no-ip.com; ich weiß nicht ob dir das was sagt. Man kann dort sowohl hosts als auch Domains anlegen. Ich habe einen Host angelegt und meinen Server damit verknüpft. Müsste ich eine Domain anlegen und Sie mit meinem Server verknüpfen?

    Gruß,
    RMTX99

    • Jan sagt:

      Hallo RMTX99,

      Zu 1: Ja, z.T. auch der Übersichtlichkeit wegen. V.a. kannst du mit getrennten Config-Dateien eine Website/Subdomain sehr schnell aktivieren/deaktivieren, indem du nur die Datei umbenennst (meinedomnain.de.conf -> meinedomain.de.conf.disabled) und nginx neu startest.
      Wenn dir das lieber ist, kannst du auch alle Inhalte in eine einzige Config-Datei packen.

      Zu 2: Habe keine Erfahrung mit no-ip.com, daher nur Vermutung. Angenommen keine Seite soll unter mysite.no-ip.com erreichbar sein. Die 2nd Level Domain (also no-ip.com) – was man normalerweise als „Domain“ bezeichnet, gehört dem DynDNS-Anbieter. Darauf hast du keinen Einfluss. mysite.no-ip.com ist dann eine Subdomain von no-ip.com. Diese Subdomain kannst du normalerweise bei einem DynDNS-Anbieter anlegen und musst diese dann in deinem Router anmelden. Welche URL und Zugangsdaten du dann in deinem Router angeben musst, dass ist meiner Erfahrung nach von Anbieter zu Anbieter unterschiedlich. Daher kann ich dir hier leider auch keinen konreten Tipp geben.
      Wenn es absolut nicht klappt, dann probier noch mal einen anderen DynDNS-Anbieter aus.

      Gruß,
      Jan

  • Bernd sagt:

    Hallo,

    kann es sein, dass es mit dieser Installationsmethode Probleme bei der App Auswahl gibt.
    ich wollte die Storagechart 2- und die Tasks- App installieren.
    Diese sind über das Webinterface aber nicht auffinbar.

    Gruß Rocker

  • RMTX99 sagt:

    Hi Jan,

    danke dir für deine Antwort!
    Kannst du mir einen anderen DynDNS Anbieter empfehlen?

    VG RMTX99

  • Jan sagt:

    Ich habe den Artikel noch einmal überarbeitet: Nun empfehle ich die Erzeugung des SSL-/TLS-Zertifikats mittels Let’s Encrypt.
    Die Beschreibung bezgl. selbst signierten Zertifikaten habe ich dennoch im Artikel gelassen, falls jemand ein Let’s Encrypt verwenden will/kann.

  • peete sagt:

    hallo bekomme immer diese Meldung
    Das Schreiben in das „config“-Verzeichnis ist nicht möglich!
    Dies kann normalerweise behoben werden, indem dem Webserver Schreibzugriff auf das Konfigurationsverzeichnis gegeben wird.
    was mache ich falsch?

    • Jan sagt:

      Hallo peete,

      bei welchem Schritt tritt der Fehler bei dir auf? Beim Zugriff auf die ownCloud config.php?
      Der Webserver-Benutzer (www-data) braucht dazu Zugriffsrechte auf die config.php. Normalerweise erreicht man dies mit chown -R www-data:www-data /var/www/owncloud/config/ (siehe Zugriffsrechte anpassen im Artikel).

  • Nico sagt:

    Hallo Jan,

    ich möchte mich hier nur einmal in aller Ausführlichkeit für den wirklich tollen Artikel bedanken.
    Inzwischen läuft bei mir das genannte Setup auf einem RaspberryPi2. Auch wenn gerade das manuelle Installieren des Webservers und der Datenbank bei mir einige Probleme verursacht haben, konnte ich durch die Nutzung der in den Paketquellen verfügbaren Versionen eine komplette Installation durchführen.

    Zwei Fragen habe ich allerdings noch:

    1. Ich habe den let’s Encrypt – Client lokal ausgeführt und das Zertifikat erstellen lassen. Leider habe ich die lokale Adresse nicht mit einbezogen, sodass mir bei einem lokalen Zugriff weiter eine Warnung angezeigt wird.
    Kann ich das Zertifikat nachträglich noch um die lokale Adresse erweitern?

    2. Wie ist es im Nachgang möglich, eine aktuellere Version des Webservers/ der Datenbank einzupflegen?

    Danke dir noch einmal für deine Hilfe :)

    Gruß,
    Nico

    • Jan sagt:

      Hallo Nico,

      zunächst einmal danke für das Lob, so etwas hört man gern!

      1. Let’s Encrypt verifiziert deinen Webserver ja durch einen externen Zugriff durch die Let’s Encrypt-Server. Diese wissen natürlich nichts von der lokalen Adresse (IP) und haben darauf auch keinen Zugriff. Prinzipiell kann man daher mit Let’s Encrypt nur Zertifikate für Server erzeugen, die (öffentlich) im Internet erreichbar sind. Beim Zugriff auf deine Cloud über die lokale Adresse musst du daher wohl oder übel mit der Browser-Warnung leben.

      2. Welche Versionen von Webserver/Datenbank installiert werden, hängt von den Paketquellen ab. Egal, ob du die offiziellen Paketquellen verwendest, oder die sources.list (wie im Artikel beschrieben) erweitert hast, das Update erfolgt immer über apt-get update && apt-get upgrade.

      Gruß,
      Jan

  • Jan sagt:

    Hallo peete,

    bei welchem Schritt tritt der Fehler bei dir auf? Beim Zugriff auf die ownCloud config.php?
    Der Webserver-Benutzer (www-data) braucht dazu Zugriffsrechte auf die config.php. Normalerweise erreicht man dies mit chown -R www-data:www-data /var/www/owncloud/config/ (siehe Zugriffsrechte anpassen im Artikel).

  • peete sagt:

    Eine Fragen habe ich noch
    wie das Datenverzeichnis Owncloud auf z.B. eine andere Festplatte umziehen kann.

1 2

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.