Temperaturen

Das Thema hatte ich ja noch aus der wandboard-Aktion offen. Da der Server direkt an der Wand zum Wohnzimmer steht, habe ich einfach zwei USB-Sticks gekauft, einen davon mit Messfuehler an etwa 30cm Kabel, dazu noch einen passiven USB-Hub und das Ganze ans Wandboard gesteckt. Den Temperatur-Fuehler natuerlich durch die Wand ins Wohnzimmer.

Die Temperatur-Fuehler finden sich unter den Stichwort “temper usb” und kosten so um die 10 EUR pro Stueck. Die noetige Software findet sich in diversen Varianten unter der Bezeichnung “pcsensor” auf github. Da ich ja mehrere Sticks habe, habe ich mir eine Variante gesucht, die das auch unterstuetzt: https://github.com/padelt/pcsensor-temper.git

Ein munin-plugin war auch wiedermal kein Problem und schon entstanden schöne Graphen. Ganz besondere Graphen: die Temperaturen in meiner Wohnung schwanken doch erheblich musste ich festellen, um gut 5 Grad innerhalb weniger Minuten. Vor allem wunderbar synchron: wurdes es im Arbeitszimmer kalt, so wurde es im Wohnzimmer warm. Und umgekehrt. (Man muss wissen, dass das ganze Rechner-Geraffel im Arbeitszimmer in einer Ecke steht, dort es natuergemaess immer schön warm, während im Wohnzimmer nur Abends geheizt wird). Anscheinend tauschen die beiden Sticks ab und an ihre Anzeigen. Das kann natuerlich nicht sein, also mal geforscht und folgende Nettigkeit gefunden:


Feb 13 15:10:01 wandboard CRON[6959]: (munin) CMD (if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi)
Feb 13 15:10:20 wandboard kernel: [2244286.093234] usb 2-1.4: USB disconnect, device number 61
Feb 13 15:10:20 wandboard kernel: [2244286.465417] usb 2-1.4: new low speed USB device number 63 using fsl-ehci
Feb 13 15:10:20 wandboard kernel: [2244286.608508] input: RDing TEMPerV1.4 as /devices/platform/fsl-ehci.1/usb2/2-1/2-1.4/2-1.4:1.0/input/input58

Also munin läuft los und daraufhin verliert der temper-Stick den Kontakt und muss neu initialisiert werden. Offenbar verändert sich dabei auch die Reihenfolge, in der die Devices von der libusb gefunden werden. Dem pcsensor gebe ich aber nur eine Nummerierung mit.

Problem erkannt, aber wie lösen. Ich habe eine ganze Weile auf die Ausgabe von lsusb gestarrt, erst ein diff brachte die Lösung: im Feld iProduct unterscheiden sich beide Sticks durch ein char. Was ein Glück. Also pcsensor schnell gepatcht: https://github.com/valpo/pcsensor-temper: pcsensor -s findet jetzt den richtigen Stick.

Übrigends kann man in der libusb-1.0 schauen, an welchem Port ein device sitzt, laut doc soll sich dieser Wert nie ändern. pcsensor nutzt leider noch libusb-0.1, dort habe ich sowas nicht gefunden. Und portieren ging auch nicht – das Ubuntu auf dem wandboard hat zwar eine libusb-1.0, aber die ist entweder völlig veraltert oder kaputt. Da das Problem für mich gelöst ist, habe ich die Sache erstmal auf Eis gelegt, wer eine Portierung braucht kann sich ja melden.

Bleibt noch das Problem mit dem usb-reset – in solchen Fällen bekommt man natürlich statt eines Wertes nur eine Fehlermeldung vom device. Also noch schnell das munin-plugin angepasst (if in doubt use brute force):

#!/bin/bash
case $1 in
config)
cat <<'EOM'
graph_title External temperature (living room)
graph_vlabel temperature temperature.label C
temperature.warning 30
temperature.critical 35
EOM
exit 0;;
esac

printf "temperature.value "
tmp="xUSBx"
while [[ $tmp =~ .*(USB|not).* ]]; do
tmp="$(/usr/local/bin/pcsensor -sTEMPerV1.4 -cm 2>&1 | head -n1)"
done
echo $tmp

Das tut es erstmal.

Wandboard

Sheeva hat einen Nachfolger bekommen: es ist ein Wandboard. Der erste Eindruck: das Ding kommt liebevoll verpackt, die Pappschachtel ziert das Wandboard-Logo, die Seiten sind mit den Pin-Belegungen der Platine verziert, alles macht einen echt netten Eindruck. Auspacken, Aufbauen, Ubuntu aufspielen – alles völlig problemlos und in wenigen Minuten erledigt.
Der zweite Eindruck:
root@wandboard:~# time echo "scale=5000; a(1)*4" | bc -l > /dev/null
real 2m16.782s
root@sheeva:~# time echo "scale=5000; a(1)*4" | bc -l > /dev/null
real 2m6.163s
Das Ding ist ja langsamer als sein Vorgänger. Ein leichter Anflug von Enttäuschung…

Konfiguration soll fast genau wie beim Sheeva sein: sslh multiplexer für den Zugriff von aussen, owncloud, dns/dhcp. Dazu kommt jetzt noch imap, tiny rss und munin.

Um es gleich vorweg zu nehmen: die erste Enttäuschung ist längst vorbei, die Zahlen oben stimmen schon, aber es sind halt 4 CPUs da – es ist zwar nie schnell, aber es steht auch nie. Auf der Kommandozeile kann man flüssig tippen, Webseiten laden ganz ordentlich. Zusammen mit den 2GB Memory konnte ich dadurch lighttp durch apache, sqlite durch mysql ersetzen. Ist schon ein gewisser Komfortgewinn – letztere kommen meist schon vorkonfiguriert, das spart doch einiges an Arbeit.

sslh

Das entspricht im Wesentlichen meiner vorigen Beschreibung. Aufpassen muss man vor allem beim apachen: Zugriff von aussen per sslh sehen im apachen immer wie Zugriffe von localhost aus. Wenn man also (nicht ganz unüblich) den apachen so konfiguriert, dass er im Heimnetz alles erlaubt und nur von aussen Passwörter verlangt oder blockiert – dann hebelt sslh diesen Schutz aus.

Owncloud

Muss man nichts mehr zu sagen, Installation (das Ubuntu-Paket) und Betrieb sind ja inzwischen völlig problemfrei. Auch dank apache und mysql (mit lighttpd+ssl und sqlite war es doch etwas hakelig).

Imap

Auch hier den dovecot von Ubuntu installiert. Einzige Anpassung: ich habe von pam auf lokale user-db umgestellt. Das Email-Passwort hinterlegt man ja doch in jedem Email-Programm, mit einem ssh-passwort gehe ich dann doch etwas pfleglicher um. Und so haben Imap-User/Passwörter halt nichts mit den shell accounts zu tun.

DNS/DHCP

Hier wieder dnsmasq in der gleichen Konfiguration wie auf Sheeva. Hat sich bewährt, der dhcp-server soll ja weiterhin den ghost wecken sobald ein Mediaplayer eingeschaltet wird.

Munin

Endlich mal was Neues. Auf sheeva habe ich so eine Art Monitoring mit ein paar Scripten gebastelt. Nun gibt es eine echte Lösung. Auch hier einfach die Ubuntu-Standard-Installation genommen, einzige Anpassung ist das Monitoring des ghost über die FritzBox:

ghostmon_py-week

Sonstiges

Tiny rss läuft noch nicht. Dafür habe ich jetzt endlich die UPS ans Monitoring gehängt. Gut zu wissen: wenn ghost läuft habe ich so um die 17min, wenn nicht sind es entspannte 35min.

Speicherauslastung ist entspannt:

memory-week

(zum Vergleich: der Sheeva hat 512MB).

Ein paar USB-Temperaturfühler habe ich hier noch rumliegen, die muss ich noch anschliessen. Aber wandboard hat auch einen internen Fühler:

temperature-week

Wie man deutlich sieht, steht mein Arbeitszimmer unter der Woche ungeheizt rum – und auch die CPU ist nicht wirklich gefordert. Es sind also noch Resourcen frei, da wird mir sicher noch was einfallen…

Encrypted Home manuell auspacken

Nach einem Upgrade meines Servers habe ich auch gleich eine aktuelle OpenSuse (hier: 13.1) installiert. Danach wollte ich meine alten Daten aus dem /home auf einer anderen Platte umziehen. Nun nutze ich encrypted home – in dem Fall wird das eigentliche Home-Verzeichnis in einer Image-Datei abgelegt, der Schlüssel für diese Datei liegt in einer key-Datei. Beim Einloggen wird wird das daraus ein Home-Verzeichnis – alles ganz automatisch. Klappt auch vorzüglich für mein neues Home, aber wie komme ich nun an mein altes Home? 

Als erstes schauen wir mal, wie das alte Home verschlüsselt ist: das steht in der /etc/security/pam_mount.conf.xml. In meinem Fal l findet sich dort die Zeile: 

<volume fstype=”crypt” user=”mathias” path=”/home/mathias.img” fskeypath=”/home/mathias.key” fskeycipher=”aes-256-cbc” fskeyhash=”md5″ cipher=”aes-cbc-essiv:sha256″ options=”loop” mountpoint=”/home/mathias”/>

Damit können wir das alte Image decrypten: 

openssl aes-256-cbc -d -in mathias.key | cryptsetup luksOpen mathias.img mathiasold_home

Openssl bekommt den Algorithmus, welchen wir aus der pam_mount.conf.xml haben, und die Key-Datei. Cryptsetup bekommt die Image-Datei. Nun sollte unter /dev/mapper/ eine Datei mathiasold_home liegen – die können wir mounten: 

mount /dev/mapper/mathiasold_home /home/mathiasold