Dienstag, 21. Juni 2016

Cyanogenmod 13 und der WLAN-Bug (located)

Der Bug wurde am 18. Juni zumindest eingekreist. Der IpReachabilityMonitor verursacht die WLAN-Abbrüche. Bleibt er ausgeschaltet, verschwinden die Abbrüche. Thank you Cyanogenmod.

Es bleibt abzuwarten, wie der Android-Hersteller damit umgehen wird. Wir verfolgen weiter aufmerksam den Thread.

Freitag, 17. Juni 2016

Networkmanager mountet Cloud-Drives und startet Apache

Ein geordnetes Hochfahren der Resourcen in der richtigen Reihenfolge sorgt für weniger Fehler und reproduzierbare Systemzustände. Wenn ich einen Cloud Storage in meinem Owncloud-Server benutzen möchte, ist die richtige Reihenfolge:

1. Netzwerkinterface starten
2. Cloud Storage mounten
3. Webserver starten

Eine mögliche Lösung dafür bietet Networkmanager. Eigentlich sind mir solche Überbauten nicht so sympathisch, weil sie zusätzliche Fehlerquellen darstellen und schwerer zu debuggen sind, aber sie bieten eben auch mal Vorteile. Früher hätte ich gesagt, wozu in aller Welt sollte ich Networkmanager mit einer statischen IP-Adresse verwenden??

In Networkmanager lassen sich Skripte ereignisabhängig starten. Der einfachste Fall ist ein Skript, nachdem eth0 in Betrieb gegangen ist. Wenn dieses Skript erst den Cloud Storage mountet und dann den Webserver startet, bin ich schon am Ziel. Das Skript gehört ins Verzeichnis /etc/Networkmanager/dispatcher.d/ und ist hier ein ausführbares Bashskript mit dem wohlklingenden Namen 00-webdav:

#!/bin/bash
#
#mount webdav drives and start apache after network came up
#

IF=$1
STATUS=$2
case "$STATUS" in
    up)
    logger -s "NM dispatcher script $IF up triggered"
    if [ "$IF" = "eth0" ]; then
        su apache -l -c "mount /var/ocd/user1/files/webdav1/"
        su apache -l -c "mount /var/ocd/user2/files/webdav2/"
        /bin/bash /etc/rc.d/rc.httpd start
    fi
    ;;
    down)
    logger -s "NM dispatcher script $IF down triggered"
    if [ "$IF" = "eth0" ]; then
        su apache -l -c "umount /var/ocd/user1/files/webdav1/"
        su apache -l -c "umount /var/ocd/user2/files/webdav2/"
        /bin/bash /etc/rc.d/rc.httpd stop
    fi
    ;;
    pre-up)
    logger -s "NM dispatcher script $IF pre-up triggered"
    #command3
    ;;
    post-down)
    logger -s "NM dispatcher script $IF post-down triggered"
    #command4
    ;;
    *)
    logger -s "NM dispatcher script $IF $STATUS triggered"
    #command5
    ;;
esac


Die unteren Fälle sind nur zum Debuggen geeignet und ohne weiteren Zweck.

Das Startskript rc.httpd unter /etc/rc.d ist nicht ausführbar, um einen Frühstart des Webservers zu verhindern. And oh yes, i simply love BSD-style init system ;-)

Die (u)mount-Befehle funktionieren natürlich nur mit entsprechenden Einträgen in /etc/fstab. Die WebDAV-Mounts werden vom Apache-User gemountet:

https://webdav.cloud.de    /var/ocd/user1/files/webdav1    davfs    noauto,user,uid=80,gid=80 0 0
https://webdav.cloud.de    /var/ocd/user2/files/webdav2    davfs    noauto,user,uid=80,gid=80 0 0


Das funktioniert wunderbar. Das Skript fängt allerdings keine Fehler beim Mount ab und muss dafür natürlich noch erweitert werden, aber im Prinzip ist das erstmal ausreichend. Wenn Owncloud ohne gemounteten Cloud-Storage hochkommt, könnte das unangenehme Folgen für den betroffenen User haben.

Mittwoch, 15. Juni 2016

Fehler mit gemounteten Google Drives

Die Erfahrung zeigt, dass ein mit google-drive-ocamlfuse gemountetes Drive bislang nicht wirklich gut nutzbar ist. Solange man das Google Drive nur als Ablage für verschlüsselte Owncloud-Files verwendet, funktioniert das einigermaßen, solange man bei der Performance mal ein Auge zudrückt. Aber wenn es an den Versuch geht, ein Drive zu evakuieren oder normale Dateioperationen auszuführen, offenbaren sich die Probleme:

apache@oc:/var/ocd/googledrive1$ cp /var/log/httpd/access_log .
cp: failed to close './access_log': Device or resource busy
apache@oc:/var/ocd/googledrive1$


Das ist blöd. Mit rsync funktioniert es auch nicht. Wenn man also versucht, das vorher eingerichtete mhddfs-Konstrukt mit 2 Google Drives zu verkleinern, indem man alles auf ein Drive verschiebt, wird man scheitern.

Aber Owncloud bietet einem User die Möglichkeit, Google Drives direkt als externen Storage unter den persönlichen Einstellungen einzubinden.

Wunderbar, dachte ich. Sobald ich aber (mit Version 8.2.5 und 9.0.2) die Verschlüsselung für den externen Storage einschaltete, konnte ich die Dateien nicht mehr herunterladen. Im Browser wurden sie zwar noch angezeigt, öffnen konnte ich sie aber nicht mehr. Ohne serverseitige Verschlüsselung klappte das, aber wer will schon seine Files unverschlüsselt extern lagern?

Freitag, 3. Juni 2016