Schlagwort-Archive: owncloud

Release upgrade auf Ubuntu 16.04.1

Eine Sammlung an Notizen zum release upgrade von 14.04 LTS auf 16.04.1 LTS oder: Was alles zerbrach, wie es zu heilen war und was noch ungelöst verbleibt.

phpMyAdmin

Schon während des Upgrades konnte das Paket phpmyadmin für Xenial nicht konfiguriert werden. Die angezeigten Fehlermeldungen verwiesen auf dieses Problem, das sich allerdings im Zuge des Upgrades nicht rund umsetzen ließen. Also blieb phpmyadmin unkonfiguriert.

Unter Xenial habe ich mir mit apt-get purge phpmyadmin ; apt-get install phpmyadmin das Paket frisch an Bord geholt.

Begrüßt wurde ich dann von einer schier unendlichen Anzahl von Deprecation Notices nach dem Muster

Deprecation Notice in ./../php/php-gettext/streams.php#48
Methods with the same name as their class will not be constructors in a future version of PHP; StringReader has a deprecated constructor

Backtrace

./../php/php-gettext/gettext.inc#41: require()
./libraries/select_lang.lib.php#477: require_once(./../php/php-gettext/gettext.inc)
./libraries/common.inc.php#569: require(./libraries/select_lang.lib.php)
./phpmyadmin.css.php#14: require_once(./libraries/common.inc.php)

Weder gettext noch mbstring (wie in einigen Threads zum Problem behauptet) lösten das Problem. Dieser Hinweis war für mich der richtige:

error_reporting = E_ALL & ~E_DEPRECATED

Pydio

Pydio meinte, es hätte unter Xenial keine MySQL Verbindung mehr. Das Problem ist wohl bekannt, die Lösung sieht bei mir so in der $PYDIOINSTALLDIR/data/plugins/boot.conf/bootstrap.json aus:

    "DIBI_PRECONFIGURATION":{
      "mysql_username":"pydiodbuser",
      "mysql_password":"pydiodbpasswort",
      "mysql_host":"localhost",
      "mysql_driver":"mysql",
      "mysql_database":"pydiodbname",
      "group_switch_value":"mysql",
      "mysql_use_mysqli":"true"
    }

Danach läuft auch ein Update auf die nächste Pydio-Version reibungslos durch.

ownCloud

ownCloud startete nicht mehr, weil einerseits memcache nicht funktionierte (unter php7 eigentlich nicht verwunderlich) und weil die PHP Module php-zip, php-memcached, php-redis und php-curl fehlten. Die waren zwar unter Trusty schon einmal an Bord, aber gingen im Laufe des Upgrades wohl verloren. Ich sollte an dieser Stelle wohl eh umsteigen auf APCu.

DokuWiki

Viele Plugins von Dokuwiki werfen mit Fehlermeldungen im Muster

PHP Warning:  Declaration of syntax_plugin_gcalendar::render($mode, &$renderer, $indata) should be compatible with DokuWiki_Syntax_Plugin::render($format, Doku_Renderer $renderer, $data) in /pfad/zu/dokuwiki/lib/plugins/gcalendar/syntax.php on line 0
PHP Warning:  Declaration of syntax_plugin_include_div::handle($match, $state, $pos, &$handler) should be compatible with DokuWiki_Syntax_Plugin::handle($match, $state, $pos, Doku_Handler $handler) in /pfad/zu/dokuwiki/lib/plugins/include/syntax/div.php on line 0, referer: https://www.domain.tld

nach dem Apachen. Hier half es, alle Plugins neu zu installieren, auch wenn diese nicht als mögliches Update von DokuWiki angezeigt wurden.

opendkim

Die Rechte auf /etc/postfix/dkim.key lagen bei root.root und verhinderten den Start von opendkim. Ein chown opendkim dkim.key stellt das richtig.

fail2ban

Die jail.local musste ich komplett überarbeiten. Der Hintergrund scheint zu sein, dass die Pfade für die Logs der einzelnen Dienste aus der jail.local bei Trusty unter Xenial nicht mehr stimmten: Einige nutzen jetzt systemd, andere schreiben weiterhin in ihren herkömmlichen Logpfad.

Außerdem zeigten sich die von mir aktivierten Apache jails extrem empfindlich gegenüber Arbeiten im Backend von DokuWiki, so lange dieses Fehlermeldungen rund um PHP7 wirft. Nach nur wenigen Klicks sperrte mich mein Server komplett aus und am Ende des Tages (und auf Grund einer von mir einst hoch festgelegten bantime) half nur der Boot mit einem über die Hetznerkonsole gestarteten Notfalllinux.

 

Redis Server und HSTS für ownCloud

Im Backend vermeldete ownCloud schon längere Zeit, dass es einen funktionierenden PHP Memory Cache vermisse. Bisher war mir das relativ egal, weil ich nicht viele Dateien und auch nicht viele Nutzer/innen hatte. Das hatte sich in den letzten Wochen und Monaten aber gründlich geändert, so dass ich bei drei meiner oC Installationen tätig werden musste. Nach dem Update auf oC 8.2.2 und Dank etwas freier Zeit ging ich das Problem endlich an.

APC und APCu waren zwar bei allen Servern an Bord, aber unter Ubuntu 14.04 und PHP5 „zu alt“. Ich probierte es mit Redis. Hier ist das PHP5 Modul von Ubuntu 14.04 zwar ebenfalls zu alt, aber es gibt in den PECL Repositories einfach zu installierenden Ersatz.

Ein

dpkg -l | grep php5-redis

klärt, ob ein solches PHP Modul installiert ist. Wenn ja, dann muss dieses zuerst runter vom Server. Danach kann der Redis Server an Bord:

apt-get install redis-server

Ein Blick in

/etc/redis/redis.conf

sollte ergeben, dass Redis an 127.0.0.1 lauscht und somit nicht von außen zu erreichen ist. Wer sich nicht sicher ist, kann von außen mit telnet nachsehen. Weiter sollte ein

service redis-server status

zeigen, dass der Redis-Server auch läuft.

Um PECL nutzen zu können benötigen wir noch die folgenden Pakete

apt-get install php-pear php5-dev

Wer, wie ich hier, Horde5 über PEAR bezieht, hat die Pakete schon. Ein

pecl install redis

bringt dann ein frischeres php Modul für Redis an Bord. Am Ende der Installation weißt PECL darauf hin, dass dieses Modul der vorhandenen PHP Umgebung bekannt gegeben werden muss. Da hilft

echo 'extension=redis.so' > /etc/php5/mods-available/redis.ini
php5enmod redis
service apache2 restart

Dann wird der Memory Cache ownCloud in

/pfad/zu/owncloud/config/config.php

bekannt gegeben, indem der folgenden Code ans Ende gehängt wird (vor die letzte schließende Klammer):

  'memcache.local' => '\\OC\\Memcache\\Redis',
  'filelocking.enabled' => 'true',
  'memcache.distributed' => '\\OC\\Memcache\\Redis',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
    array (
      'host' => 'localhost',
      'port' => 6379,
      'timeout' => 0,
      'dbindex' => 0,
     ),

Im Backend von ownCloud herrscht nun etwas mehr Ruhe.

Was ownCloud leider nicht überprüft ist, ob es überhaupt über HTTP zu erreichen ist. Es schimpft immer über eine fehlende HSTS Konfiguration, bis eine solche eingerichtet ist.

Das ist mit

a2enmod headers

und dem Eintrag

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"

für die ownCloud Domain dann nach einem Neustart des Apachen auch erledigt, hat aber Nebenwirkungen: HTTP Verbindungen sind hiermit für die gesamte Domain ab dem ersten Aufruf über HTTPS für den Client-Browser erledigt. Muss man wollen.

Geholfen beim Einrichten haben mir die folgenden empfehlenswerten Quellen: 1, 2, 3, 4

LDAPs von ownCloud auf LD-Server

Nicht nur die Anbindung des LD-Servers an eine externe DokuWiki Installation, sondern auch an ein externes ownCloud funktioniert über LDAPs und lässt sich wie folgt einrichten:

Der erste Schritt ist vom OC-Administrator vorzunehmen, der im Backend die LDAP App einschalten muss. Weiter muss auf dem ownCloud-Server auch php5-ldap installiert sein und in der folgenden Datei die Prüfung auf Zertifikate abgeschaltet werden, wenn man intern auf dem LD-Server für den eigenen LDAP nur selbst-signierte Zertifikate einsetzt (was in den meisten Fällen zutreffen dürfte – leider):

# /etc/ldap/ldap.conf

TLS_REQCERT allow

Als OC-Administrator lässt sich dann unter dem Menü-Eintrag /Administration die restliche Konfiguration vornehmen.

ocldap-server

In der Server-Registerkarte ist die URL (besser: IP) für den LD-Server zu hinterlegen. Danach klickt man einmal in Benutzer-DN, trägt aber nix ein, klickt einmal in Passwort, trägt aber nix ein und schreibt dann die DN Angaben in das letzte Feld. Bei BelWü-Kunden dürfte es sich hierbei um einen Eintrag in der folgenden Form handeln:

dc=schulkuerzel,dc=stadt,dc=schule-bw,dc=de

Dann klickt man auf Fortsetzen – wie auch bei allen anderen folgenden Registerkarten.

ocldap-userfilter

In der Nutzer-Filter-Registerkarte sollte inetOrgPerson vorausgewählt sein und ownCloud auch gleich alle internen Benutzer (und Workstations etc.) finden. Im Bild oben sind dies 1008 Benutzer. Das sind etwas viele, die sich anmelden dürften, weswegen man Beschränkungen vornehmen sollte. Im Folgenden beschränke ich die Nutzung für die Gruppe der Lehrer/innen.

ocldap-loginfilter

Die Beschränkung erfolgt schon bei der Anmeldung: Nur Mitglieder der Gruppe teacher werden akzeptiert. Die entscheidende Funktion wird durch vorauswählbare Einträge nicht scharf schaltbar, weshalb man selbst den Original-Filter bearbeiten muss, so dass dieser am Ende wie folgt aussieht:

(&(|(objectclass=inetOrgPerson))(|(ldRole=teacher))(|(uid=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid))(|(cn=%uid))))

Hinzugefügt wurde in die Voreinstellungen ein

(|(ldRole=teacher))

ocldap-groupfilter

Der Gruppen-Filter von ownCloud bezieht sich nämlich nicht auf die Benutzerrechte im Anmeldekontext, sondern lediglich auf das Recht, innerhalb von ownCloud Gruppen bilden zu dürfen.

Was bei der Arbeit auf jeden Fall hilft, ist einmal auf dem LD-Server mit tshark zu gucken, ob überhaupt LDAPs Anfragen ankommen.

tshark -i extern port 636

Weiter macht es Sinn mit

tail -f /var/www/owncloud/data/owncloud.log

zu verfolgen, was alles bei den Anmeldeversuchen schief läuft. Man braucht mindestens einen Lehreraccount und einen Schüleraccount zum Testen – sonst wird man irre. Auch darf man damit rechnen, dass man mehrfach

service apache2 restart

auf dem ownCloud Server benötigt, weil sich dieser an den Einstellungen verschluckt hat. Das kann man gut in der owncloud.log verfolgen: Sollte diese im Sekundenabstand mit Zeilen gefüllt werden, die ungefähr diese Angaben enthalten, dann ist es mal wieder Zeit für einen Apache Restart und einen erneuten Versuch im OC-Backend:

{"app":"user_ldap","message":"Configuration Error (prefix ): Not a single Base DN given.","level":2,"time":"2014-12-19T16:50:15+00:00"}
{"app":"user_ldap","message":"Configuration Error (prefix ): login filter does not contain %uid place holder.","level":2,"time":"2014-12-19T16:50:15+00:00"}

Wer das alles für seine Linuxmuster.net Lösung haben will, wird im Wiki fündig. Wie immer sind die freien Schulserver-Lösungen bei der Dokumentation von Sonderwünschen und Erweiterungen vorbildlich.

ownCloud Passwort

An der Zickigkeit von ownCloud auf Debian hat sich auch mit dem Upgrade auf die Version 6 wenig geändert. Während auf meinen Ubuntuservern das Upgrade schon immer einfach durchlief, maulte ownCloud mit der gleichen Berechenbarkeit am Ende eines jeden Upgrades auf einem Debian rum, dass das Passwort mindestens eines Benutzers nicht mehr funktioniere etc. pp. Meist lag es am Inhalt der .htaccess Dateien im ownCloud Ordner gepaart mit Firefox und seiner für mich schwer durchschaubaren Cache Verwaltung, die mir hier dazwischen kamen. Da half dann oft die Nutzung von Rekonq – oder eben Anpassungen der .htaccess Files. Heute wollte alles nicht helfen – der Bug saß wo anders (und ich weiß noch nicht wo). Also sah ich mich gezwungen, den Versuch eines Passwort Resets für den Benutzer admin auszuprobieren – was mit phpMyAdmin einfach umgesetzt werden kann.

ocusers

Die Tabelle oc_users auswählen und dort beim gewünschten Benutzer – hier: admin – auf „Edit“ klicken.

adminpw

SHA1 auswählen und das neue Passwort im Klartext eingeben. Durch Klick auf GO speichern. Das Passwort für den Benutzer liegt nun ungesalzen in der Datenbank! Deswegen folgt der nächste Schritt.

oc_personal

An ownCloud anmelden (was funktionieren wird) und nach Klick auf den Benutzernamen (rechts oben) zum Passwort-ändern Dialog von ownCloud navigieren. Dort das so eben gesetzte und ein neues Passwort eingeben.

Nur dieser letzte Schritt stellt sicher, dass das Passwort für diesen Benutzer auch gesalzen in der Datenbank landet, was eine kurze Kontrolle in phpMyAdmin auch bestätigt.

OwnCloud zickt

oc_zickt1

OwnCloud zickt seit Version 5.x vermehrt rum:

Erstens mag es keine Connections mit mehreren Clients gleichzeitig. Das führt regelmäßig dazu, dass *conflict* Dateien angelegt werden, obwohl sich an der Dateiversion überhaupt nichts verändert hat. Dies ist leider auch der Fall, wenn alle beteiligten Endgeräte sowie der Server gegenüber dem gleichen Server per NTP ihre Uhrzeit holen. Der Bug sitzt demnach tiefer im System.

owncloud_resourcenfresser

Zweites: Der OwnCloud-Sync-Client frisst so lange an den Ressourcen, bis es sich selbst als dysfunct nach Zombieland abmeldet. Schießt man den Prozess noch rechtzeitig ab, sinken umgehend CPU- und RAM-Last wieder beinahe auf Normalmaß.

Der Screenshot von meinem Arbeitsplatzrechner oben zeigt jedoch ein leider typisches Phänomen. Wirkliches Normalmaß wäre das hier:

kein_oc

Zu swappen hat mein Quadcore mit 8GB RAM nämlich eigentlich nichts.

Da selbst nach Beendigung eines amoklaufenden OwnCloud-Prozesses noch „etwas hängen“ bleibt, vermute ich auch hier dickere Probleme. Die OwnCloud-Foren sind zumindest voll von Menschen, die ähnliche Erfahrungen machen.

CSync konnte keine lock-Datei erstellen

ownCloud 1.2.0_001

Die meiste Zeit bin ich mit der Kombination OwnCloud 4.5.x Server und 1.2.x Client zufrieden: Es läuft. Die Synchronisation mit Android wie auch mit allen Endgeräten klappt.

ownCloud 1.2.0_002

Immer mal wieder zickt das Client-Programm aber rum und teilt mit:

CSync konnte keine lock-Datei erstellen.

Was bisher geholfen hat, war ein Klick auf /Anhalten. Dann die vorhandene lock Datei schlicht löschen

rm /home/username/.local/share/data/ownCloud/lock

und den Client durch Klick auf /Fortsetzen wieder starten.

Owncloud Syncclient Update

… bei mir dauert das Auslesen der Owncloud Repos auf dem SuSE-Server Ewigkeiten – sonst scheint damit jedoch keiner ein Problem zu haben, zumindest finde ich im Netz nichts hierzu.

Da mir die Alternative – händisches Herunterladen der DEB Dateien aus dem Repo bei OpenSuSE – zu doof ist, hab ich mir gerade ein kleines und noch ziemlich dummes Script geschrieben, das mir die Arbeit auf allen meinen Rechnern abnimmt.


#!/bin/bash
# Vorhandene DEB Dateien löschen
rm /home/dirk/Downloads/owncloudclient/*.deb
# Architekturinformationen sammeln
ubuver=$(cut -f 2 -d " " /etc/issue | cut -f 1,2 -d ".")
ubuarch=$(uname -m | cut -f 2 -d "_")
# Verzeichnisauswahl auf OpenSuSE nach Architektur vorbereiten
if [ "$ubuarch" = "64" ] ; then
ubuarchdir=amd$ubuarch
else
ubuarchdir=i386
fi
# Download der aktuellen DEBs von OpenSuSE
wget http://download.opensuse.org/repositories/isv:/ownCloud:/devel/xUbuntu_$ubuver/$ubuarchdir/ -r -A deb --no-directories --level=2 -P /home/dirk/Downloads/owncloudclient/
# Installation der neuen Version
sudo dpkg -i /home/dirk/Downloads/owncloudclient/*.deb ;

Die ideale Lösung ist das nicht … aber besser als diese vermalledeite Warterei.

OwnCloud Task in Thunderbird kann nicht gelöscht werden

Seit mehreren Tagen nervt mich die Taskverwaltung in Thunderbird mit einem immer wieder auftauchenden Task, den ich schon mehrfach als gelöscht markiert hatte. Der Task wurde innerhalb einer meiner OwnCloud Instanzen angelegt und auch das Löschen dort brachte Thunderbird nicht auf Trab. Leider half auch eine Suche nach „thunderbird cannnot delete task“ wenig – auch wenn viele Menschen ähnliche Probleme mit dem Sogo Connector und mit Zimbra zu haben scheinen.

Was nun letztlich half war Folgendes: Auf der Registerkarte Tasks im Thunderbird ein Doppelklick auf den zickigen Kalender (Rechtsklick /Properties geht auch). Im dann auftauchenden Fensterchen im Feld „Offline Support“ das Häkchen rausmachen und die neuen Einstellungen mit OK bestätigen. Ein wenig warten, bis Thunderbird neu gesynct hat … und dann das Häkchen wieder reinsetzen.

Jetzt ist Ruhe.

OwnCloud Repo

Das OpenSuSE Repo für OwnCloud geht mir auf den Wecker. Es ist mehr als nur schnarchlangsam – die Aktualisierung dauert stellenweise 20 Minuten. In diesem Fall zieh ich mir die Dateien lieber händisch:

cd ~/Downloads/owncloud

wget -r „http://download.opensuse.org/repositories/isv:/ownCloud:/community/xUbuntu_12.04/i386/“ -l 1

… zumindest unter KDE. Unter Unity frisst wget die “ nicht und meckert „Schema fehlt“. Die Anführungszeichen müssen dann weggelassen werden.

cd owncloud/download.opensuse.org/repositories/isv\:/ownCloud\:/community/xUbuntu_12.04/i386/

sudo dpkg -i *.deb

sudo apt-get install -f

Schöner wäre es natürlich, wenn man sich ein lokales Repo hierfür anlegen würde – aber als schneller, dreckiger workaround reicht mir das.