Eines der vielen Indieweb-Plugins für WordPress implementiert ActivityPub, ein noch recht junges Protokoll um Inhalte zu erzeugen, zu aktualisieren und zu löschen und das dann zwischen föderierten Servern auszutauschen.
Also habe ich meine Friendica-Identität mit meiner WordPress-Identität befreundet.
Nachdem ich ein halbes Jahr mit Hugo unterwegs war, bin ich jetzt wieder bei WordPress gelandet. Eigentlich fand ich das Konzept von Hugo richtig gut: statischen Content erzeugen, hochladen und keinen Gedanken mehr an Sicherheitslöcher verschwenden.
Eigentlich. Tatsächlich war es mir zu umständlich. Oder vielleicht bin ich ja auch durch die jahrelange Benutzung von WordPress versaut.
Den Ausschlag gab letztlich mein steigendes Interesse am Indieweb. Und da ist ein statischer Sitegenerator dann doch nicht so gut geeignet.
Mal schauen, was mich im Indieweb so erwartet…
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 .
makeIn 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 0x00In 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 00Leider 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 bcDann 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.
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-commonDas 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
scaldra.net erblickte 2005 das Licht der Welt als WordPress-Blog, zunächst als Experiment um herauszufinden wie das alles so funktioniert und um einen Artikel für das Linux-Magazin zu schreiben.
Bis 2016 befüllte ich das Blog, meist mit eher privaten Inhalten und in den letzten Jahren immer seltener. Anfang 2017 ließ ich es dann aus der Öffentlichkeit verschwinden und staunte, wie unglaublich lange die Inhalte noch bei Google abgerufen werden konnten. Google vergisst wirklich ungern.
Jetzt ist das Blog wieder da. Es wird anders sein, verwendet Hugo statt WordPress und ist auf maximale Privacy ausgelegt … etwas, worüber ich mir 2005 noch gar keine Gedanken gemacht hatte.
Ansonsten gilt
Blogge das, was du selbst gerne lesen würdest
Der Plan ist, dass es hier viel um Software und das Internet gehen wird. Aber plan kommt aus dem Lateinischen und heißt platt. Da das Leben aber vielfältig ist, könnte es zu Überraschungen kommen.
Und warum die Zitrone?
Weil ich sie vor ein paar Jahren selbst gemalt habe. Und sie ist bis heute mein größtes Bild : 1 qm.
