OwnCloud mit nginx und MariaDB auf Debian Jessie
8. August 2017 um 13:32 Uhr von Atari-Frosch
Ja, ich könnte für Dateien, die ich einzelnen Personen oder Gruppen weitergeben will, einen FTP-Server aufsetzen. Die mochte ich aber noch nie. Oder, wie ich es die letzten Jahre gemacht habe, weiterhin die jeweilige Datei in ein temporäres Verzeichnis auf meinen Webserver schieben und dann den Link weitergeben. Aber irgendwie ist das so noch nicht das Wahre. Außerdem hoste ich noch jemanden, der auch so eine Datei-Austausch-Möglichkeit braucht, aber nicht mit einer Shell umgehen kann. So landete ich schließlich bei OwnCloud.
(Ob das die optimale Webanwendung für meinen Fall ist, NextCloud oder Seafile vielleicht besser wären usw., diskutiere ich hier nicht; das soll jeder für sich selbst entscheiden.)
Die in der Überschrift genannte Kombination ist allerdings etwas tricky; ich suchte und probierte jedenfalls ein paar Stunden lang herum, bis alles lief, und dabei unterliefen mir auch noch so ein paar eigene Fehler. Das waren die Haken:
OwnCloud ist in Debian 8.x (Jessie) in den Repositories, allerdings in der Version 7. Das ist denn doch ein bißchen zu alt, denn die Vanilla-Version ist bei 10.0.2. In Debian 9 (Stretch) ist OwnCloud dagegen überhaupt nicht mehr vertreten. Aus dem Umfeld der Debian-Maintainer ist zu vernehmen, daß man in Verhandlungen stehe, das für spätere Versionen wieder zu ändern. Ich selbst habe bisher keine meiner Debian-Installationen auf Stretch hochgezogen, weil ich, freundlich ausgedrückt, kein Interesse an systemd habe und befürchte, daß ich in Stretch noch mehr Abhängigkeiten nicht mehr erfüllen kann, weil ich systemd überall gepinnt habe. Also:
- Debian GNU/Linux 8 Jessie
- nginx 1.6.2
- PHP 5.6.30 und php5-fpm 5.6.30
- MariaDB 10.0.31 aus dem MariaDB-Repo
- OwnCloud 10.0.2 als ZIP direkt von der Website
OwnCloud herunterladen und in ein geeignetes Verzeichnis entpacken: Klar, kein Thema. Aber dann: OwnCloud ist total verliebt in den Apachen, jedenfalls gibt es offiziell keine Vorkonfiguration für nginx. In Debian Jessie ist die Verknüpfung noch deutlicher, da hat OwnCloud eine feste Abhängigkeit von apache2. Es gibt immerhin eine Konfigurationsdatei aus der OwnCloud-Community, wenn auch nur für die Version 9 und damit nicht super-aktuell: nginx Example Configurations. Damit konnte ich schonmal anfangen.
Zu beachten ist dabei diese Option:
fastcgi_request_buffering off; #Available since nginx 1.7.11
Da ich einen nginx 1.6.2 im Einsatz habe, muß diese Zeile auskommentiert werden, weil nginx sich sonst weigert, einen Reload durchzuführen. Diese Angabe kann er halt einfach noch nicht interpretieren.
Außerdem wollte ich mir zum Testen (ja, manchmal bin ich faul) kein Self-Signed Cert bauen, um gleich SSL benutzen zu können – da ich die Gewohnheit habe, für jeden Dienst eine eigene Subdomain einzurichten, kann ich natürlich nicht das Zertifikat für die eigentliche Domain (statische Website) mitbenutzen, sondern muß für jede dieser Subdomains ein eigenes erstellen.
Für SSL/https benutze ich ja seit Februar Let's Encrypt, aber um da ein erstes Zertifikat zu bekommen, muß erstmal alles für http konfiguriert sein und die (Sub-)Domain im DNS stehen. Ich konnte also nicht, wie dort im Beispiel vorgegeben, alle Zugriffe direkt zwangsweise auf Port 443 umbiegen; zunächst mußte auch Port 80 bzw. generell http möglich sein. Daher habe ich mir diese Konfiguration ein wenig angepaßt, alles auf einen separaten Port gelegt und den Zwang zu SSL sowie den SSL-Teil komplett auskommentiert, um erstmal in Ruhe alles einzurichten. Die Subdomain habe ich mir lokal in /etc/hosts eingetragen – DNS zu Fuß. 😉
Trotzdem mußte ich an dieser angepaßten Konfiguration noch ein wenig herumschrauben, bis nginx nicht nur generell einverstanden war, sondern auch tatsächlich den grafischen Installer auslieferte. Das lag insbesondere daran, daß ich oben beim upstream-handler übersehen hatte, daß php5-fpm nicht, wie sonst bei mir konfiguriert, über den Socket geht, sondern über TCP. Da habe ich den Weg über TCP gelöscht und auf den Socket umgestellt (kaum macht man's richtig … Ihr kennt das).
Diese vorübergehende Konfiguration sah dann so aus:
upstream php-handler {
server unix:/run/php5-fpm.sock;
}
server {
listen 81;
root /srv/$OwnCloud-Verzeichnis;
server_name wolke.atari-frosch.de;
charset utf8;
access_log = $Log-Pfad/access.log;
error_log = $Log-Pfad/error.log;
# set max upload size
client_max_body_size 512M;
fastcgi_buffers 64 4K;
# Disable gzip to avoid the removal of the ETag header
gzip off;
error_page 403 /core/templates/403.php;
error_page 404 /core/templates/404.php;
# This location block is for the LetsEncrypt authentication.
location ^~ /.well-known {
root /srv/$OwnCloud-Verzeichnis;
autoindex off;
index index.html;
try_files $uri $uri/ =404;
}
location / {
rewrite ^ /index.php$uri;
}
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
return 404;
}
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
return 404;
}
location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-
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 modHeadersAvailable true;
fastcgi_param front_controller_active true;
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
# fastcgi_request_buffering off; #Available since nginx 1.7.11
}
location ~ ^/(?:updater|ocs-provider)(?:$|/) {
try_files $uri $uri/ =404;
index index.php;
}
location ~* \.(?:css|js)$ {
try_files $uri /index.php$uri$is_args$args;
add_header Cache-Control "public, max-age=7200";
# Add headers to serve security related headers (It is intended to
# have those duplicated to the ones above)
# Before enabling Strict-Transport-Security headers please read into
# this topic first.
#add_header Strict-Transport-Security "max-age=15552000;
# includeSubDomains";
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;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
}
location ~* \.(?:svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$ {
try_files $uri /index.php$uri$is_args$args;
}
# enforce https
# return 301 https://$server_name$request_uri;
}
Bei der Fehlersuche stieß ich auch noch auf diese Anleitung bei „My Digital Hobby“, die zwar generell für mich eher ungeeignet ist, weil dort von einer Installation in einem LAN ausgegangen wird (was viele Sicherheits-Features unnötig macht). Dort wird allerdings die MySQL-Datenbank angelegt, bevor der grafische Installer benutzt wird. Das habe ich denn auch mal noch gemacht. Die OwnCloud-Dokumentation erwähnt das nicht (oder ich habe es übersehen). Immerhin kann es nicht schaden.
Nebenbei gelernt: In MySQL/MariaDB kann man einen neuen User damit anlegen, daß man ihm die Privilegien für eine Datenbank einräumt und ein Paßwort dazuliefert. Das wußte ich auch noch nicht; bisher hatte ich den User mit Paßwort immer vorher angelegt, dann die Datenbank erzeugt und dem neuen User in einem dritten Schritt die Privilegien dafür eingeräumt. Es sind dafür also offenbar nur zwei Schritte nötig.
Die Installer von Webanwendungen sind ja nicht einheitlich, was das Anlegen der Datenbank angeht. Für WordPress muß man die Datenbank vorher erzeugen, für MediaWiki zum Beispiel aber nicht, da passiert das im Laufe der Installation. Das klingt bequemer, allerdings muß man dafür der Webanwendung das root-Paßwort für MySQL verraten. Das will man ja vielleicht auch nicht unbedingt.
Nach den Korrekturen in der nginx-Konfiguration und der neu angelegten Datenbank hatte ich dann also endlich den grafischen Installer im Browser. Es wäre aber zu einfach gewesen, hätte dann schon alles funktioniert …
Als erstes meckerte mich der Installer nach dem Ausfüllen aller Felder an, er könne nicht ins Datenverzeichnis schreiben bzw. dieses nicht anlegen. Gemeint ist das Verzeichnis, in welchem die hochgeladenen Dateien gespeichert werden. Das muß bzw. sollte nicht unbedingt identisch sein mit dem Document Root von OwnCloud und ist es bei mir auch nicht. Ich hatte zwar ein solches Verzeichnis angelegt und dem Installer auch vorgegeben, aber das mußte noch die richtigen Dateirechte bekommen. Genauso wie die Dateien der Anwendung selbst muß das Verzeichnis User und Gruppe www-data gehören. Das war ja einfach. Also, zu einfach.
Die nächste Fehlermeldung machte mir deutlich mehr zu schaffen. Das liegt auch daran, daß ich nicht dauernd MySQL/MariaDB konfiguriere und ich das jetzt nicht gerade aus dem FF beherrsche. Der OwnCloud-Installer beschwerte sich nämlich über eine Einstellung für die binären Logs von MariaDB, genauer über die Variable binlog_format. Für diese gibt es drei Einstellungen: STATEMENT, ROW und MIXED – genaueres hier. In diesem Teil der Doku findet sich aber kein Hinweis darauf, wo man das wie in die Konfiguration eintragen muß. Da heißt es nur, das sei ein Kommandozeilen-Parameter. Nur startet man seine Datenbank-Software ja nicht unbedingt an der Kommandozeile, sondern automatisch beim Start des Systems, ergo muß die Angabe irgendwo in eine Konfigurationsdatei.
Ich brauchte tatsächlich „etwas“ länger, bis ich diesen Teil der Dokumentation fand: MariaDB: Server System Variables (zweite Überschrift, „Setting Server System Variables“). Und nachdem ich verstanden hatte, daß der Wert hinter dem Parameter in Anführungszeichen geschrieben werden muß, konnte der Installer endlich die Installation durchziehen. Puh. Manchmal steh ich ja echt auf'm Netzwerkkabel. 😉
Nachdem also grundsätzlich alles lief und ich schon ein bißchen mit der Oberfläche von OwnCloud herumgespielt hatte, wurde es Zeit, das ganze „offiziell“ zu machen. Und damit: Ein ordentliches Zertifikat zu beschaffen. Und hierbei schaffte ich es, Dinge so richtig falsch zu machen. 😉
Erster Fehler: Ich hatte zwischen Grundinstallation und den Softlink zur VHost-Konfiguration erst nochmal aus /etc/nginx/sites-enabled/ gelöscht, sicherheitshalber, weil ich wußte, daß ich erstmal ein paar Tage nicht dazu kommen würde, weiterzumachen. Und dann wunderte ich mich, warum CertBot einen 405 geliefert bekam (Logfiles lesen half) … ja, da sind wir schon wieder beim „kaum macht man's richtig“. Dann nur noch die nginx-Konfiguration auf SSL umbauen und den Zugriff zwangsweise auf Port 443 umbiegen, fertig.
Naja, fast.
Zweiter Fehler: Ich hatte ja anfangs gezeigt, daß ich die Installation erstmal auf Port 81 gelegt hatte. Das wurde in der OwnCloud-eigenen Konfiguration config/config.php als „trusted domain“ fest eingetragen. Somit war dieselbe Domain auf dem Standard-Port nicht mehr „trusted“. OwnCloud beschwerte sich bei Aufruf darüber, und ich mußte das in der genannten Datei noch ändern, bevor ich wieder rein durfte.
Dritter Fehler – eigentlich nur so nebenbei, der hinderte immerhin weder nginx noch OwnCloud am Arbeiten: Das nginx-Log für die Site wurde nämlich nicht geschrieben. Ja, Frosch, wenn man nginx-Konfigurationen schreibt, gehört zwischen Statement und Wert kein Gleichheitszeichen. nginx meldet das nicht als Fehler beim Reload, sondern schreibt es nur in sein eigenes error_log. Nunja, überflüssige Zeichen entfernt, und schon kann nginx auch loggen.
Daneben noch gelernt: CertBot (Let's Encrypt) weigert sich, ein Zertifikat für eine Subdomain auszustellen, wenn für die Subdomain im DNS kein A-Record eingetragen ist. So weit so gut und vermutlich nicht mal so falsch. Das Problem dabei: Der Hinweis auf den A-Record wird im Fall eines Fehlers auch dann ausgegeben, wenn der A-Record vorhanden ist und der Fehler eigentlich woanders liegt (hier: Fehlercode 405 vom Webserver. Sozusagen standardmäßig sicherheitshalber. Das kann schon etwas verwirren und auf die falsche Fährte führen.
Aber ich denke mal, meine nächste OwnCloud-Installation geht dann schneller. 😉
11. August 2017 at 20:38
Zu deinem Echo Problem: Du brauchst Mumble Client’s mit lokaler Echounterdrückung … meiner Wissens gibt es die aber leider nur für Windoof und nicht als Open Source.
… über PulsAudio kann man glaube ich auch eine lokale Echounterdrückung erreichen (auch Nachhall Unterdrückung genannt) … aber frag mich nicht wie, ich hab es noch nie gemacht.
Bei der Echo Unterdrückung wird im Prinzip das Signal das auf die Lautsprecher ausgegeben wird mit einer um 180 Grad verschobenen Phase mit dem Mikrofon Signal gemischt, damit löscht sich das was das Mikrofon von den eigenen Lautsprechern hört aus. Soweit die Theorie, das Problem ist dass sich Schall nicht mit unendlicher Geschwindigkeit ausbreitet, die Aufnahme also immer etwas verzögert ist. Man muss also das ausgegebene Signal erst etwas verzögern bevor man es zum Mikrofon Signal mischen kann. Die genaue Verzögerung ist aber leider nicht trivial zu ermitteln.