Simon Szustkowski

Ein Blog über alles, was mir gerade so durch den Kopf geht

Dec 2, 2015 - IT

Owncloud muss sterben

…damit wir leben können.

Dabei fing es so gut an. Ich habe einen Webserver mit nicht gerade kleinem Speicher, und dachte mir, ich könnte da ja mal eine Owncloud-Instanz installieren, um damit mal rumzuspielen. Also habe ich mir die Doku mal durchgelesen, die leider sehr Apache-based ist, aber es gibt auch eine Sektion für die Konfiguration von nginx. Sogar ein eigenes Repository für Debian sollte es geben. Also alles knorke.

Ich habe also, wie in der Doku steht einen eigenen User und eine eigene Datenbank in meiner MariaDB angelegt, und wollte dann das Paket über deren Repository installieren. Erster Fail: Das Owncloud-Paket für Debian möchte erst einmal den Apache Webserver installieren, und das ohne Rücksicht auf Verluste.

Danke, nein. Ich nutze den nginx, und bin sehr zufrieden damit. Also manuelle Installation. Runtergeladen, nginx konfiguriert, und die URL aufgerufen, damit ich den Installationsassistenten starten konnte. Dabei habe ich den nginx erstmal nur auf normales, unverschlüsseltes HTTP konfiguriert. Ist ja erstmal alles nur intern, TLS würde ich dann irgendwann mal nachrüsten. Der Installationsassistent macht einen ganz guten Eindruck, man muss die Logindaten für den neu anzulegenden Owncloud-User anlegen, sowie die vorher spezifizierten Datenbank-Logindaten. Das klappte aber alles irgendwie nicht, im Errorlog von Owncloud stand, dass der Datenbank-User nicht angelegt werden könne. Hä? Ich hatte ihn doch angelegt. Lösung im Internet war: Gib mal deine Root-Zugangsdaten in die Maske ein. Ja nun. Tolles Pferd. Seine Root-Zugangsdaten in ein PHP-Script füttern, was sonstwas damit anstellen könnte. Egal, no risk, no fun. Und voilá: Zweiter Fail: Obwohl die Doku was anderes behauptet, legt der Installer die Datenbank-User und die Datenbank selbst automatisch an. Man hat keine Kontrolle, wie der User oder die Datenbank heißen soll, noch, wie das Passwort aussehen soll. Existiert der User oder die Datenbank schon, schmiert der Installer kommentarlos mit einem Error 500 ab.

Nunja. Schon ziemlich angepisst wollte ich mich dann mal einloggen. Die Userdaten zur Datenbankverbindung kann ich ja später noch modifizieren. Also, auf zur Login-Seite, Zugangsdaten eingegeben, zack, Error 500. Das Logfile meines nginx meldet einen 302-Redirect auf ein Ziel, was nicht existieren würde. Also mal im Logfile von Owncloud selbst nachgucken. Und was da steht, lässt mich laut auflachen. Dritter Fail: Obwohl der gesamte Owncloud-Ordner zum Debuggen auf chmod 777 steht, steht im Errorlog von Owncloud “Could not create error.log - Permission denied”. Dass genau dieser Fehler allerdings auch im Errorlog steht, was laut sich selbst gar nicht existieren dürfte, scheint in der Logik der Owncloud-Entwickler total plausibel zu sein.

Getestet, und rausgefunden: Der Login-Button im Anmeldeformular hat offenbar einen hardcoded HTTPS-Link. Da ich den Owncloud-Vhost aber erstmal ohne HTTPS konfiguriert habe, läuft der Redirect ins Leere, und die Session schmiert ab. Ein sanftes Hinweisen der Admins auf die Vorzüge von HTTPS in allen Ehren, aber ich möchte meine Software bitte so sicher oder unsicher konfigurieren, wie ich es selbst möchte. Vierter Fail: Nicht nur im Login-Formular, sondern auch an vielen anderen Stellen hat Owncloud hardcoded HTTPS-Links, und ist auf einem non-TLS-Host de facto unbenutzbar.

Fest steht: Ich habe lang nicht mehr so eine Dreckssoftware in meinen Fingern gehabt, und wer weiß, was da noch für Bugs und UX-fails drin stecken. Ich hingegen reihe mich mit Freuden in die Riege derjenigen ein, die diesen Müll mit Inbrunst verachten.