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...

Freitag, 1. Juli 2016

Endlich ist Slackware 14.2 erschienen! Glückwunsch an Patrick Volkerding und das ganze Team dahinter.

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.