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

Montag, 30. Mai 2016

Lustige VPN-Verbindungen (Ergänzung)

Bei weiteren Versuchen gelingt es mit Xubuntu 14.04, einen VPN-Tunnel zur Fritzbox aufzubauen. Out of the box. Mit Slackware nicht. Nanu?

Um dem Grund auf die Spur zu kommen, versuche ich es auf der Commandline, damit der NetworkManager-Überbau verschwindet. Also eine Datei /etc/vpnc/fritzbox.conf angelegt und entsprechend https://talk.maemo.org/showthread.php?t=92338 mit angepassten Werten befüllt.

vpnc --debug 3 /etc/vpnc/fritzbox.conf

funktioniert auf Anhieb in Ubuntu. Mit Slackware-current:

   PARSING PAYLOAD type: 00 (ISAKMP_PAYLOAD_NONE)
   PARSE_OK
vpnc: vpnc.c:1164: lifetime_ike_process: Assertion `0' failed.
Aborted


Berühmte letzte Worte. Einziger Unterschied ist die verwendete vpnc-Version.

Ubuntu: vpnc version 0.5.3r512
Slackware: vpnc version 0.5.3

Zur Fehlermeldung ist der Suchmaschinen-Output leider sehr dürftig.

Nachtrag:
Im Slackware-Forum auf Linuxquestions (http://www.linuxquestions.org/questions/slackware-14/) kam 2 Stunden nach Meldung bereits ein neues SBo-Paket von ponce - mit dem funktioniert es. Version 0.5.3-r550.

Freitag, 27. Mai 2016

Lustige VPN-Verbindungen

Da habe ich mir doch vor ein paar Tagen eine andere Fritzbox gegönnt, und weil ich von der 7170 weiß, dass sie ein etwas besseres DSL-Modem hat und ich gerade eine günstig im Netz fand, schlug ich also zu und brachte das gute alte Schätzchen online. Ok, zugegeben, das Modell reißt niemanden vom Hocker, aber darum geht's nicht und es läuft wunderbar, so what. Mit meiner leicht gestörten CuDA zum HVT jedenfalls kommt sie besser zurecht als eine 7390.

Jetzt gehe ich also daran, die VPN-Verbindung für meinen Androiden einzurichten, und hier wird's interessant.

Zur Fritzbox werden IPsec-Verbindungen mit Pre-shared Key aufgebaut. Die Existenz von VPN-Clients, die das unterstützen, hält sich in überschaubaren Grenzen. Bei Android kommt üblicherweise schon ein Client mit dem ROM.

LG G2 mit Orion OS 2.3 (Marshmallow, Android 6.0.1):
Der Login klappt tadellos. Alles weitere leider nicht.

LG P700 mit Mahdi Rom 2.8 von 20141012 (Kitkat, Android 4.4.4):
Der Login klappt tadellos. Alles weitere leider nicht.

"Alles weitere leider nicht" bedeutet, mehr als die eigene LAN-Adresse kann ich nicht erreichen.

Lustigerweise funktionierte das mit der Fritzbox 7390, die ich vorher hatte, bis zuletzt wunderbar out of the box.

Ein Blick in die Netzwerkkonfiguration bei aufgebauter VPN-Verbindung lässt schon etwas erahnen:

u0_a85@android:/ $ ip a
26: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
link/none
inet 172.16.1.51/32 scope global tun0
u0_a85@android:/ $ ip r
10.173.0.0/16 dev wlan0 proto kernel scope link src 10.173.10.58
u0_a85@android:/


Man beachte die sonderbare Netzmaske /32 und eine fehlende Route in mein LAN.

Es gibt aber einen VPN-Client, mit dem die Geschichte funktioniert: VpnCilla. Hiermit sieht die Konfiguration besser aus:

u0_a85@android:/ $ ip a
24: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1356 qdisc pfifo_fast state UNKNOWN qlen 500
link/none
inet 172.16.1.51/24 scope global tun0
u0_a85@android:/ $ ip r
10.173.0.0/16 dev wlan0 proto kernel scope link src 10.173.10.58
172.16.1.0/24 dev tun0 proto kernel scope link src 172.16.1.51
u0_a85@android:/ $


Da ist die Netzmaske endlich richtig und es gibt eine Route ins LAN.

Auf dem P700 bekomme ich das VPN mit dem VPNC Widget vom gleichen Autor Matthias Meier zum Laufen. Außerdem fällt auf, dass beide Handys nach einem vergeblichen Versuch mit dem ROM-Client erst einen Neustart brauchen, damit es mit VpnCilla/VPNC Widget klappt. Ohne vorherigem Neustart können die beiden VPN-Clients weder die Netzmaske noch die Route richtig setzen. Lustige VPN-Verbindungen!

Mittwoch, 25. Mai 2016

mhddfs mit Google Drives

Auf der Suche nach einer Möglichkeit, mehrere Google Drives unter dem gleichen Mountpoint einzuhängen, bin ich auf mhddfs gestoßen. Mit mhddfs (multi hdd file system) ist es ganz leicht, 2 Pfade zusammen zu mounten:

mhddfs pfad1,pfad2 pfad3

In pfad3 liegen dann alle Dateien und Verzeichnisse aus pfad1 und pfad2 nebeneinander.

user@owncloud:~$ mount | grep google
google-drive-ocamlfuse on /mnt/googledrive1 type fuse.google-drive-ocamlfuse (rw,nosuid,nodev,user=apache)
google-drive-ocamlfuse on /mnt/googledrive2 type fuse.google-drive-ocamlfuse (rw,nosuid,nodev,user=apache)
/mnt/googledrive1;/mnt/googledrive2 on /var/www/owncloud-data/gdrive1 type fuse.mhddfs (rw,nosuid,nodev,user=apache)
user@owncloud:~$


Auch Operationen wie disk usage funktionieren auf diesem Mountpoint. mhddfs ist also ideal, um mehrere kleine Drives wie ein großes Drive zu verwenden.

Freitag, 20. Mai 2016

sslserver environment für Lets Encrypt

Der sslserver hat auf meinem Server folgende Umgebung (in /var/qmail/ssl/env):

SSL_USER=ssl
SSL_GROUP=ssl
SSL_DIR="/var/qmail/ssl"
SSL_CHROOT="$SSL_DIR"
CERTFILE="/etc/letsencrypt/live/<my domain>/cert.pem"
CERTCHAINFILE="/etc/letsencrypt/live/<my domain>/fullchain.pem"
KEYFILE="/etc/letsencrypt/live/<my domain>/privkey.pem"
DHFILE="/etc/httpd/extra/dhparam.pem"
CIPHERS="ALL:!LOW:!SSLv2:!EXP:!aNULL:!eNULL:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!DSS:!RC4"
SSL_UID=`id -u $SSL_USER`
if [ $? -ne 0 ] ; then echo "No such user '$SSL_USER'" >&2 ; exit; fi
SSL_GID=`id -g $SSL_USER`
if [ $? -ne 0 ] ; then echo "No such group '$SSL_GROUP'" >&2 ; exit; fi
export SSL_UID SSL_GID SSL_CHROOT
export CERTFILE CERTCHAINFILE KEYFILE DHFILE CIPHERS


Wesentliche Quelle dafür ist die Seite http://www.fehcom.de/qmail/smtptls.html von Dr. Erwin Hoffmann, wie man unschwer erkennt. dhparam.pem wird einmalig extra angelegt (wird für den Webserver ja auch benötigt).

Lets Encrypt Skript v0.2

Das Skript zur Erneuerung des Zertifikats auf meinem Owncloud-Server sieht so aus:

#!/bin/bash
/bin/bash /etc/rc.d/rc.httpd stop
/sbin/shorewall save
/sbin/shorewall open all <my server ip> tcp 80
/sbin/shorewall open all <my server ip> tcp 443
/usr/bin/letsencrypt certonly --keep --rsa-key-size 4096 -d <my domain>
/sbin/shorewall restore
/bin/bash /etc/rc.d/rc.httpd start
if [ /service/qmail-smtps/supervise/control -ot /etc/letsencrypt/live/<my domain>/cert.pem ]; then
  echo "Restarting QMail with new cert"
  /usr/local/bin/svc -t /service/qmail-pop3ds
  /usr/local/bin/svc -t /service/qmail-smtps
  /usr/local/bin/svc -t /service/qmail-smtpd
fi


Mit der --keep-Option werden die Zertifikate erst dann erneuert, wenn sie dafür "reif" sind. Die --rsa-key-size kann eigentlich raus, sie wurde nur initial benötigt. Das Skript liegt unter /etc/cron.weekly.

Ich habe mir im Laufe der Jahre angewöhnt, in Shellskripten immer mit absoluten Pfaden zu arbeiten, denn es ist nicht anzunehmen, dass jeder User den gleichen PATH hat. Und sicherer ist es auch.

Qmail bekommt den Zertifikatswechsel natürlich ebenfalls mitgeteilt.

Montag, 9. Mai 2016

LG G2 D802 mit Cyanogenmod 13 und Problemen mit WLAN

"Eigentlich" ist Cyanogenmod (CM) ja ein cooles Custom Rom. Wer von den aufgezwungenen Hersteller-Apps genervt ist, greift zu Root, Recovery und Custom Rom. Mein Wechsel auf Android Marshmallow mit meinem LG G2 fand Ende Januar statt und war in erster Linie eine Reaktion auf die Sicherheitslücken in älteren Versionen. Leider liefert LG aber kein Marshmallow für sein G2 aus, daher kam sowieso nur ein Custom Rom in Frage, und das einzig Verfügbare war eben CM-13.

Dumm nur, dass mit dem Wechsel auf CM-13 ein Bug in Erscheinung trat, der harmlos aussieht, aber recht unangenehm ist und der die WLAN-Verbindung (Wifi im englischen Sprachraum) abbrechen lässt. Im Logcat sieht man das:

04-17 18:51:01.576  1896  1896 I wpa_supplicant: wlan0: WPA: Group rekeying completed with AA:BB:CC:DD:EE:FF [GTK=CCMP]
04-17 18:51:01.589  1896  1896 I wpa_supplicant: wlan0: CTRL-EVENT-DISCONNECTED bssid=AA:BB:CC:DD:EE:FF reason=3 locally_generated=1
04-17 18:51:01.630  1896  1896 I wpa_supplicant: p2p0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
04-17 18:51:01.638   241   860 D CommandListener: Clearing all IP addresses on wlan0
04-17 18:51:01.641   241   860 D CommandListener: Setting iface cfg
04-17 18:51:01.643  3000  4438 V NativeCrypto: Read error: ssl=0x997db000: I/O error during system call, Connection timed out
04-17 18:51:01.651  3000  4438 V NativeCrypto: SSL shutdown failed: ssl=0x997db000: I/O error during system call, Broken pipe
04-17 18:51:01.658  3000  4438 E GCM     : Wifi connection closed with errorCode 20
04-17 18:51:01.659  1004  1929 D ConnectivityService: reportNetworkConnectivity(132, false) by 10012
04-17 18:51:01.670  1004  1772 D ConnectivityService: NetworkAgentInfo [WIFI () - 132] validation failed
04-17 18:51:01.670  1004  1772 D ConnectivityService: notifyType CAP_CHANGED for NetworkAgentInfo [WIFI () - 132]
04-17 18:51:01.671  1004  1772 D ConnectivityService: sendStickyBroadcast: action=android.net.conn.INET_CONDITION_ACTION
04-17 18:51:01.680  2508  2508 D TelephonyProvider: subIdString = 1 subId = 1
04-17 18:51:01.725  1004  1772 D ConnectivityService: NetworkAgentInfo [WIFI () - 132] EVENT_NETWORK_INFO_CHANGED, going from CONNECTED to DISCONNECTED


Die erste Zeile zeigt noch, dass gerade erfolgreich ein neuer Key für die WLAN-Verbindung zwischen Router und Endgerät ausgetauscht wurde. Danach geht die Verbindung verloren, das Handy verwirft das WLAN und schaltet kurz danach auf teure mobile Daten um. Teuer im Sinne von Strom- und Datenverbrauch.

Der Bug ist bis heute nicht erfolgreich beseitigt worden und er betrifft nicht nur Cyanogenmod -  auf einigen Google-Handys mit Original-Android ist er ebenfalls (siehe https://code.google.com/p/android/issues/detail?id=196035).

Glücklicherweise gibt es seit Kurzem eine Alternative - Orion OS (siehe http://forum.xda-developers.com/lg-g2/development-d802/rom-orionlp-1-5-t3192311). Ich habe es vor 2 Wochen installiert und siehe da - ohne WLAN-Bug. Dafür aber (unter anderem) mit Bluetooth-Bug. Da ich Bluetooth seltener benötige als WLAN, kann ich damit besser leben. Aber dennoch wäre es gut, wenn die anderen Android-Versionen den WLAN-Bug auch loswürden.

NetworkManager 1.2

Ein dummes Gesicht habe ich am Wochenende gemacht, als ich meinen Desktop mit Slackware current durch ein Update des Network Managers auf 1.2 offline legte.
Und zwar nachhaltig. Einträge wie "autoconnect=true" in der Konfig unter /etc/NetworkManager/system-connections/eth0 haben ihn nicht die Bohne interessiert, entweder blieb das Interface down oder /etc/resolv.conf blieb leer.

Gelöst habe ich das Problem schließlich durch ein "netconfig", dem Setup-Script von Slackware, dem ich explizit nochmal alles neu mitgab. Vermutlich wäre ich mit einer statischen Konfig ohne Networkmanager besser gefahren, zumal kein WLAN mit im Spiel ist und noch nicht einmal DHCP, aber da ich das gleiche Problem neulich schon in ähnlicher Weise mit einer WLAN-Verbindung hatte, wollte ich der Sache einfach mal weiter auf den Grund gehen.

Einen großen Vorteil hat NetworkManager selbst bei statischen Konfigs: er lässt sich sehr leicht um Skripte erweitern, die einem nach erfolgreichem Link-Aufbau Netzlaufwerke mounten. Wer Google Drives nach einem Reboot automounten will, wird möglicherweise wissen, wie sinnvoll das ist.

Projekt: owncloud-Server

Eine kleine VM bei einem externen Hoster
  • mit Slackware64 current
  • mit owncloud source-Installation
  • mit SSL-Zertifikat
  • logischerweise mit Firewall
  • ssh-Zugang vom Büro
  • mounten von Google Drives
  • zusätzlich nutzbar als Mail Server
ist das aktuelle Zentrum meiner Experimente. Der Server läuft inzwischen. Die wesentlichen Fakten:

  • Owncloud 8.2.4 (stable tree)
  • Let's Encrypt-Zertifikate
  • Öffentlich nur für Email erreichbar
  • NetQmail-1.0.6 als MTA mit vpopmail/mysql und QmailAdmin
  • ssh-Zugang mit Google Authenticator als 2. Faktor
  • 2 Google Drives gemountet mit ocamlfuse
Nachdem ich vor einem Jahr damit begonnen hatte, nutzte ich zunächst ein kostenfreies StartSSL-Zertifikat. Als dieses dann ablief, wurde es lustig, denn zum StartSSL-Zugang erhält man ein Client-Zertifikat, mit dem man sein Server-Zertifikat verwalten kann - das Client-Zertifikat läuft aber ebenfalls ab und eine Option, dieses zu verlängern, kann man lange vergeblich suchen. Da war der Wechsel zu Let's Encrypt keine Frage mehr.