Freitag, 3. November 2017

Nextcloud als Docker Container updaten

Der richtige Weg, ein Update einer Nextcloud-Installation im Docker Container  vorzunehmen, besteht nicht einfach nur darin, das Docker Image zu löschen und neu zu pullen. Zwar wird dann das neue Image gestartet (was mit docker inspect gut zu sehen ist), aber in der Versions-Info von Nextcloud erscheint dann immer noch die alte Version, weil im Config-Pfad die Datei version.php nicht verändert wurde. Diese liegt nämlich üblicherweise in einen Volume, das man dem Container mitgibt. Dort findet bei einer Erstinstallation die Initialisierung statt, aber nicht bei einem Update des Images.

Der richtige Weg besteht darin, ein neues Volume für den Config-Pfad anzulegen, die config.php hineinzukopieren und dann den Container mit dem neuen Volume zu starten.

Hier am Beispiel eines Updates von linuxserver/nextcloud 12.0.2 auf 12.0.3, wobei das neue Image bereits gepullt wurde:

root@oc:/home/aa/docker-nextcloud/nextcloud# mkdir -p config-12.0.3/www/nextcloud/config/
root@oc:/home/aa/docker-nextcloud/nextcloud# cp config/www/nextcloud/config/config.php config-12.0.3/www/nextcloud/config/config.php
root@oc:/home/aa/docker-nextcloud/nextcloud# chown -R 911:911 config-12.0.3/
root@oc:/home/aa/docker-nextcloud/nextcloud# ls -al
total 24
drwxr-xr-x  6 aa  users 4096 Nov  3 15:06 ./
drwxr-xr-x  4 aa  users 4096 Sep 19 20:10 ../
drwxr-xr-x  6 911   911 4096 Sep 19 20:12 config/
drwxr-xr-x  3 911   911 4096 Nov  3 15:06 config-12.0.3/
drwxrwx--- 12 911   911 4096 Nov  3 14:54 data/
drwxr-xr-x  5 999   999 4096 Nov  3 14:56 db/
root@oc:/home/aa/docker-nextcloud/nextcloud# ls -al config-12.0.3/www/nextcloud/config/
total 12
drwxr-xr-x 2 911 911 4096 Nov  3 15:07 ./
drwxr-xr-x 3 911 911 4096 Nov  3 15:06 ../
-rw-r----- 1 911 911 1097 Nov  3 15:07 config.php
root@oc:/home/aa/docker-nextcloud/nextcloud#

root@oc:/home/aa/docker-nextcloud/nextcloud# mv config config-12.0.2
root@oc:/home/aa/docker-nextcloud/nextcloud# mv config-12.0.3 config
root@oc:/home/aa/docker-nextcloud/nextcloud# ls -la
total 24
drwxr-xr-x  6 aa  users 4096 Nov  3 15:10 ./
drwxr-xr-x  4 aa  users 4096 Sep 19 20:10 ../
drwxr-xr-x  3 911   911 4096 Nov  3 15:06 config/
drwxr-xr-x  6 911   911 4096 Sep 19 20:12 config-12.0.2/
drwxrwx--- 12 911   911 4096 Nov  3 14:54 data/
drwxr-xr-x  5 999   999 4096 Nov  3 15:10 db/
root@oc:/home/aa/docker-nextcloud/nextcloud# logout

aa@oc:~/docker-nextcloud$ docker-compose up -d
Creating network "dockernextcloud_default" with the default driver
Creating dockernextcloud_letsencrypt_1 ...
Creating dockernextcloud_db_1 ...
Creating dockernextcloud_nextcloud_1 ...
Creating dockernextcloud_letsencrypt_1
Creating dockernextcloud_db_1
Creating dockernextcloud_letsencrypt_1 ... done
Creating dockernextcloud_nginx_1 ...
Creating dockernextcloud_nginx_1 ... done

aa@oc:~/docker-nextcloud$ 

Die Pfadangaben sind im docker-compose.yml und daher hier nicht sichtbar. Loggt man sich dann wieder auf der Weboberfläche ein, bekommt man die Update-Begrüßung zu sehen, die man auch von Standalone-Installationen kennt. Hier wird dann ggf. das DB-Schema auf Stand gebracht, Apps aktualisiert und auch die übigen Dateien im Config-Pfad inklusive version.php mit den richtigen Inhalten angelegt.

Freitag, 2. Dezember 2016

Qmail Spamcontrol mit Vpopmail, qmailadmin und Catchall Accounts

Wenn man mit seiner Qmail-Installation Emails für mehr als eine Domain empfängt, möchte man möglicherweise auch Catchall-Accounts verwenden. Catchall-Accounts haben den Vorteil, dass man nicht für jede Adresse, die man mal verwenden möchte, gleich einen kompletten Alias (oder gar einen vollwertigen Account) anlegen muss. Es reicht, einen Catchall-Account zu verwenden, in dem alles ankommt. Meistens ist das der Postmaster-Account.

Nun ist es aber durch die Spamcontrol Recipients Extension nicht mehr ganz so trivial, denn ein einfaches Anklicken des Catchall-Buttons in Qmailadmin reicht nicht aus.

Zusätzlich zum Catchall-Button ist ein Eintrag in control/recipients nötig:

!catchall-domain.com
users/recipients.cdb

Dieser Eintrag verhindert, dass eine weitere Empfängerüberprüfung stattfindet und Emails für alle Usernamen angenommen werden. Danach greift die Vpopmail-Logik und sorgt für die Zustellung an den Postmaster-Account.

Freitag, 8. Juli 2016

Linksys WRT54GL mit OpenWrt Backfire 10.03.1, DynDNS

Der als reiner WLAN-Router genutzte Linksys soll aus dem LAN heraus DynDNS-Updates machen. Was die Sache so einfach macht, ist die URL-Abfrage bei api.ipify.org:

root@OpenWrt:~# cat /etc/config/ddns
config 'service' 'myddns'
    option 'enabled' '1'
    option 'use_syslog' '1'
    option 'use_logfile' '1'
    option 'interface' 'wan'
    option 'domain' 'alp5.ddnss.de'
    option 'username' 'beta256'
    option 'password' 'secret'
    option 'force_unit' 'hours'
    option 'check_unit' 'minutes'
    option 'ip_source' 'web'
    option 'ip_url' 'http://api.ipify.org'
    option 'update_url' 'http://ddnss.de/upd.php?key=67ba047b1d8abcd0aad826b2aa080ca7&host=alp5.ddnss.de'
    option 'force_interval' '24'
    option 'check_interval' '5' 



Wenn der alte Linksys auch sonst keine Empfehlung für schnellere Internetverbindungen sein kann, aber das hier macht er definitiv besser als eine Fritzbox 7170. Die Fritzbox wartet auf eine neue IP auf dem WAN-Interface, bevor sie was tut, und als reiner WLAN-Router kann sie darauf lange warten...

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