TEMPer mit ID 413d:2107

Ich hatte eigentlich etwas ganz einfaches vor: an meinen RasPi einen Temperatursensor anschliessen und mal längere Zeit das Auf und Ab der Temperatur in unserer Wohnung beobachten. Passend erschien mir der TEMPer: er ist preiswert und es gibt Unterstützung für Linux (allerdings nicht vom Hersteller, der liefert nur eine recht grottige Windows-Software mit).

Als das Ding ein paar Tage nach der Bestellung aus China eintrudelte, schaute ich mir erst mal an, was ich da habe.

lsusb lieferte

[...]
Bus 001 Device 005: ID 413d:2107  
[...]

Das war schon mal eine USB-ID, die für dieses Ding eher ungewöhnlich war. Das versprach nichts Gutes.

Die grundlegenden Treiber finden sich auf https://github.com/signal11/hidapi und müssen selbst kompiliert werden. Das ist zwar dort noch mal alles gut beschrieben, aber hier noch mal meine Zusammenfassung:

Erst das Repository klonen …

git clone git://github.com/signal11/hidapi.git

… dann die Voraussetzungen für das spätere Kompilieren installieren …

sudo apt-get install libudev-dev libusb-1.0-0-dev libfox-1.6-dev autotools-dev autoconf automake libtool

… und die Build-Schritte durchführen

./bootstrap
./configure
make
sudo make install  

An dieser Stelle ist man leider noch nicht fertig, es braucht für die Temperatursensoren noch ein zweites Projekt, das sich auf https://github.com/edorfaus/TEMPered befinden

Und wieder das Repository klonen (parallel zum hidapi-Projekt; das vereinfacht die folgenden Schritte) …

git clone https://github.com/edorfaus/TEMPered.git

… dann die Voraussetzungen für das spätere Kompilieren installieren …

sudo apt install cmake

… und zum Schluss die Build-Schritte durchführen

cmake .
make

In utils liegt jetzt hid-query, mit dem man die verbundenen Devices auflisten kann:

hid-query -e
/dev/hidraw0 : 413d:2107 interface 0 : (null) (null)
/dev/hidraw1 : 413d:2107 interface 1 : (null) (null)

Um herauszufinden, wie man an die Werte kommt, sendet man nacheinander an die beiden Devices (hier hidraw0 und hidraw1) eine entsprechende Aufforderung

sudo hid-query /dev/hidraw0 0x01 0x80 0x33 0x01 0x00 0x00 0x00 0x00

In meinem Fall „hing“ der Request bei dem einen Device und gab für das andere die folgende Antwort:

Writing data (9 bytes):
         00 01 80 33   01 00 00 00   00
​
Response from device (8 bytes):
         80 80 0b ab   4e 20 00 00

Leider kennt tempered diese Version des Sticks noch nicht. Da ich zu faul war mich in den C-Code einzuarbeiten, habe ich aus den diversen Postings zu den Issues auf github mir den Code zu einem kleinen Bash-Skript herausgeholt, das zusammen Human_Interface_Device hid-query die aktuelle Temperatur ausgibt. Dazu muß ggf. erst noch bc installiert werden:

sudo apt install bc

Dann braucht es nur noch ein kleines Skript …

#!/bin/bash
OFFSET=0.0
OUTLINE=`sudo hid-query /dev/hidraw1 0x01 0x80 0x33 0x01 0x00 0x00 0x00 0x00|grep -A1 ^Response|tail -1`
OUTNUM=`echo $OUTLINE|sed -e 's/^[^0-9a-f]*[0-9a-f][0-9a-f] [0-9a-f][0-9a-f] \([0-9a-f][0-9a-f]\) \([0-9a-f][0-9a-f]\) .*$/0x\1\2/'`
HEX4=${OUTNUM:2:4}
DVAL=$(( 16#$HEX4 ))
bc <<< "scale=2; $DVAL/100 - $OFFSET"

… und man hat die aktuelle Temperatur … fast. Denn zunächst muss man das Ergebnis noch mit einem guten Thermometer vergleichen, dann der Stick hat ein konstantes Offset zur realen Temperatur. Sobald man die Differenz kennt sollte die 0.0 im Skript angepasst werden.

Noch ein Hinweis zum Schluss: Der Stick sollte nicht direkt an einem Rechner betrieben werden, sondern per Verlängerungskabel etwas Abstand haben. Sonst beheizt der Rechner den Stick und die Messungen sind sinnlos.


Unerwünschtes rpcbind

Es ist wirklich doof, wenn man von seinem Webhoster (in meinem Fall netcup) eine Mail vom CERT Bund weitergeleitet bekommt, in dem die Rede von einem möglichen Sicherheitsrisiko auf dem eigenen Server ist. Genauer gesagt ging es um diesen Scan:

Log:
"asn","ip","timestamp","rpc_response"
[...]
​
"197540","46.38.233.137","2018-08-06 04:21:33","100000 4 111/udp; 100000 3 111/udp; 100000 2 111/udp; 100000 4 111/udp; 100000 3 111/udp; 100000 2 111/udp;"
​
[...]

Er zeigt, dass rcpbind offen nach außen ist. Damit könnte mein Rechner für DDoS-Reflection-Angriffe missbraucht werden.

Also erst mal schnell auf der Maschine gescannt:

root@somesystem:~# netstat -anp | grep LISTEN 
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      31653/mysqld        
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      653/rpcbind         
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      6169/systemd-resolv 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      832/sshd            
tcp6       0      0 :::111                  :::*                    LISTEN      653/rpcbind         
tcp6       0      0 :::80                   :::*                    LISTEN      899/apache2         
tcp6       0      0 :::22                   :::*                    LISTEN      832/sshd            
tcp6       0      0 :::443                  :::*                    LISTEN      899/apache2 

Und tatsächlich: da ist ein rcpbind, der da nichts zu suchen hat. Er ist da reingeraten, als ich vor ein paar Wochen meinen Server neu installiert habe und die Daten auf einem externen NFS-Mount zwischenlagerte. Dazu hatte ich nur nfs-common installiert, also nur den NFS-Client, nicht den Server. Und nur letzterer braucht rpcbind. Aber durch die Abhängigkeitsstuktur von nfs-common hatte ich da plötzlich ein Sicherheitsproblem durch ein rpcbind, das ich gar nicht bemerkt hatte.

In meinem Fall war die Lösung simpel.

apt remove nfs-common

Das deinstallierte automatisch libnfsidmap2, libtirpc1 und rpcbind.

Der nächste Scan sah besser aus

root@somesystem:~# netstat -anp | grep LISTEN
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      31653/mysqld        
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      6169/systemd-resolv 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      832/sshd            
tcp6       0      0 :::80                   :::*                    LISTEN      899/apache2         
tcp6       0      0 :::22                   :::*                    LISTEN      832/sshd            
tcp6       0      0 :::443                  :::*                    LISTEN      899/apache2         
​

Fazit: als Abschluss nach einer Neuinstallation immer netstat -anp | grep LISTEN durchführen


Dokuwiki als privates Wiki

Vor ein paar Jahren habe ich angefangen allerlei Notizen elektronisch zu sammeln. Dafür habe ich meist selbst entwickelte Programme benutzt, die zwar funktionierten, aber nie so ganz das boten, was ich gerne hätte. Letztlich ertappte ich mich immer wieder dabei, dass ich mehr an den Werkzeugen bastelte, als sie zu benutzen. Nicht so wirklich ideal. Andererseits habe ich im Laufe der Zeit einen interessanten Streifzug durch allerlei Software-Technologien gemacht. Auch nett. Aber irgendwann war Schluß mit lustig und eine dauerhaft benutzbare Lösung musste her: Dokuwiki

Warum Dokuwiki?

Letztlich war die Entscheidung für Dokuwiki völlig subjektiv, aber für mich sprachen ein paar gute Gründe dafür:

  • es ist simpel: keine Datenbank, nur PHP und Textfiles. Mediawiki wirkt dagegen wie ein Sumo-Ringer
  • es hat eine API. Ich mag Sachen mit einer API
  • man kann es gut mit Plugins und Themes an die eigenen Bedürfnisse anpassen
  • und noch ein ganz gewichtiger Grund: ich habe es schon seit ein paar Jahren für einige Dokumentationen im Einsatz

Import

Out-of-the-Box sieht die Editierung in Dokuwiki so aus:

Da ich der einzige Bearbeiter des Wikis bin, möchte ich auf die freundliche Ermahnung nur Verbesserungen beizutragen verzichten. Dadurch gewinne ich wertvollen Platz auf dem Bildschirm, wenn ich unterwegs vom Telefon aus editiere (das kommt häufig vor). Ich habe dazu etwas rüde den Inhalt von inc/lang/de-informal/edit.txt gelöscht. Hält nur bis zum nächsten Update.

Die zweite Sache, die ich nicht brauche, ist die kurze Notiz bei Änderungen. Ich benutze sie nie und auch sie kostet wieder Platz. Auch da war ich wenig zimperlich und habe einfach lib/styles/screen.css um die folgende Anweisung erweitert.

.dokuwiki .editBar .summary {
    display: inline;
    visibility: hidden;
}

Und schon sieht die ganze Seite aufgeräumter aus ….

… vor allem unterwegs auf dem Smartphone.

Irgendwann baue ich das dann mal nachhaltig.

Mobile Nutzung

Mir persönlich gefällt für die mobile Nutzung das Standardtheme von Dokuwiki am Besten. Es ist vielleicht nicht besonders stylisch, aber sehr praktisch. Um die Nutzung unterwegs noch zu verbessern, läuft auf meinem Smartphone WebApps aus dem FDroid-Store. So lässt sich das Wiki fast wie eine App benutzen (jedenfalls solange man Online ist)


Wolkenwechsel: von owncloud 8 zu Nextcloud 10

Statt ownCloud, das mich seit einigen Jahren ohne große Probleme begleitet hat, werkelt seit heute eine Nextcloud für mich. Ich war einfach neugierig und fand den Schritt von Frank Karlitschek zu mehr Offenheit hin sehr sympathisch.

In der Praxis bedeutete das:

  • Erst mal ein Backup
  • Alles, bis auf den Datenordner und den Configordner wegräumen
  • Dann zunächst Nextcloud 9 einspielen und die Aktualisierung durchführen (besser an der Commandline, wenn man nicht in blöde Browsertimeouts laufen will). Der Download der Version 9 ist nicht ganz leicht zu finden. Deshalb hier der Link in das Downloadverzeichnis
  • Hat man das erfolgreich hinter sich gebracht kommt noch einmal das gleiche Spiel mit Nextcloud 10. Ohne den Zwischenschritt scheint es im Moment nicht zu gehen.
  • Die diversen Clientprogramme von ownCloud auf Nextcloud umstellen. Dabei scheint aber der Unterschied noch nicht so immens zu sein, denn unter Linux benutze ich nach wie vor den ownCloud-Client, denn Nextcloud bietet die Linux-Software nur als Quellcode an. Aber ich hatte keine Lust selber zu compilieren

Der Android-Client hat gleich einen Absprung in DAVdroid, der die Server-URL und den User schon vor befüllt. Fast. Es fehlt am Ende der URL ein /remote.php/dav. Dann lassen sich auch Termine, Aufgaben und Kontakte angenehm teilen.

Die Cloudlösung heißt bei mir übrigens ganz neutral Wolke


Aquaris E4 rooten

Root-Zugriff für das eigene Handy zu erlangen ist seit Lollipop nicht mehr ganz so einfach, denn im Hintergrund arbeitet jetzt ein SE Linux, das gegen Angriffe recht gut gewappnet ist. Aber glücklicherweise gibt es für die Smartphones von bq eine sichere Möglichkeit dennoch den Root-Zugriff zu erlangen. Im Gegensatz zu obskuren chinesischen Programmen, die irgendetwas nicht nachvollziehbares zur Laufzeit machen,gibt es auch eine „saubere“ Methode. Dazu wird das Recovery-System durch die Version von TWRP ausgetauscht, in dieses Recovery-System gebootet und das führt dann die Änderungen an dem zu diesem Zeitpunkt inaktiven SE Linux durch.

Dazu lädt man sich das Flash-Toolherunter und installiert es nach dieser Anleitung. Dann holt man sich noch die neueste Firmware und entpackt sie. Der letzte Schritt vor dem eigentliche Flash-Vorgang besteht nun darin das „Scatter-File“ der Firmware und das von TWRP heruntergeladene und in „recovery.img“ umbenannte File in Directory zu kopieren. Dann wird das ausgeschaltete Smartphone geflasht. In Spanisch lässt sich das hier nachlesen.

Abschließend muss man nur noch in das Recovery System booten (Vol+Up + Power gedrückt halten und die entsprechenden Fragen von TWRP passen beantworten.

Leider ist bq nur ein kleinerer Hersteller, so dass es keine reine AOSP Version gibt – wie CyanogenMod, aber immerhin hat man nach diesem kleinen Eingriff etwas mehr Kontrolle über das Smartphone.

Vermutlich wird diese Root-Methode auch für die anderen Aquaris-Telefone.


bq Aquaris E4 und Ubuntu

Nachdem ich mein Geeksphone Zero nach knapp vier Jahren in Rente geschickt habe (die aktuellen Apps sind einfach zu fett für das kleine Teil), laufe ich jetzt mit einem bq Aquaris E4 durch die Gegend. Ein kleiner Stolperstein ergab sich beim Ankoppeln an mein Notebook mit Kubuntu: Es poppte in der Geräteüberwachung nicht auf.

Des Rätsels Lösung ist mit einem kurzen tail -f /var/log/syslog gefunden: das Device ist noch unbekannt. Also schnappt man sich die relevante Zeile aus dem tail

Feb 19 08:52:22 localhost kernel: [ 3218.368966] usb 1-4.2.3: New USB device found, idVendor=2a47, idProduct=2008

und ergänzt mit der passenden Vendor- und Product-ID die /lib/udev/rules.d/69-libmtp.rules (zuständig für das Media Transfer Protocol)

#Aquaris E4
ATTR{idVendor}=="2a47", ATTR{idProduct}=="2008", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"

Und schon klappt es auch mit dem Filezugriff


Fujitsu Siemens Amilo pa1510 + Ubuntu 14.04

Mein alter Fujitsu Siemens Amilo pa1510 ist mittlerweile sieben Jahre alt, funktioniert aber immer noch ganz ordentlich. Aber es war mal an der Zeit für ein Facelifting. Damit alles etwas leichtgewichtiger wird, läuft er jetzt mit Xubuntu 14.04 Trusty Tahr.
Es läuft alles ganz prima, nur der mittlerweile vier Jahre alte Bug bei der Ansteuerung des Atheros 2413 ist immer noch da. Aber da er sich leicht beheben ließ, stellte er kein wirkliches Problem dar.

Jetzt bin ich neugierig, wie lange die Kiste noch durchhält.


Android ohne Google

Als eine der Konsequenzen aus dem NSA-Skandal läuft mein kleines Geeksphone jetzt mit Android, aber ohne Google. Dazu brauchte es einige Bastelei und es funktioniert nicht (jedenfalls in dem Umfang, den ich brauche) allein mit freien Quellen.

Die freien Apps stammen alle von F-Droid:

Ein paar Apps habe ich direkt vom Hersteller

  • BlueFire Reader eBook-Reader, der auch DRM-geschützte Dokumente lesen kann (brauche ich für die EBooks aus der Bücherei)
  • Öffi Braucht man als Pendler einfach
  • Titanium Backup Ordentliches App-Backup
  • Heise Online News von Heise (nach der App muss man etwas suchen)

Das reichte leider nicht für meine Bedürfnisse. Also mussten noch ein paar unfreie Apps her, aber ohne, dass ich dem App-Store-Betreiber (aka Google) gleich die Kontrolle über mein Gerät geben muss. Da blieb eigentlich nur Androidpit.

  • CardDAV Sync Synchronisierung von Kontakten
  • CalDAV Sync Synchronisierung von Terminen und Todos
  • Contact Editor Editor für Kontakte (der eingebaute Kontakteditor von Android spielte mit CardDAV Sync leider nicht zusammen)

Damit lassen sich jetzt Mails, Termine, Todos und Dateien synchronisieren, ich kann Bücher lesen, chatten, Nahverkehrsauskünfte bekommen und habe Kartennavigation. Mehr brauche ich nicht.

Aber da ist noch das Backend, denn das sollte natürlich auch nicht bei Google liegen. Dank eines eigenen V-Servers kein so großes Problem:

Auf dem Weg zu dieser Konstellation habe ich auch noch einiges anderes ausprobiert. So war die Idee alles auf meinem Raspberry Pi zu hosten eher knifflig, denn man müsste dafür noch im internen WLAN am DNS rumfeilen. Mühsam.

Die CardDAV und CalDAV Sachen hätte ich auch mit aCal machen können, aber aCal ist etwas zickig und träge in der Bedienung. Ähnliches gilt im Backend für die Groupware Horde; für mich einfach überdimensioniert.

Nachtrag 26.9.2013:
Da mich interessierte, mit wem sich mein Handy denn so unterhält, habe ich mal OS Monitor installiert und mir regelmäßig die offenen Verbindungen anzeigen lassen. Normalerweise gingen die – wie erwartet – zu meinem eigenen Server. Aber Überraschung: ab und zu ging auch mal etwas zu Google von irgendeinem Systemservice. Des Rätsel Lösung war naheliegend: solange Ortung per WLAN eingeschaltet ist fragt das Handy Google, wo es gerade ist. Kann man abschalten, aber ich gehe erst mal davon aus, dass es keine große Sicherheitslücke ist.