Kategorie: IT

Today I installed signal-cli to send messages from an Ubuntu server to the signal messenger on my cellphone. Everything worked fine, installation, user registration and verification. I did all this with my own (low privilege) user account.

As the next step I wanted to send messages with PHP by calling the signal-cli binary with system(). Therefore the Apache-user www-data needs to have the information about the registered signal account. It is stored in my own user’s home directory in ~/.local/share/signal-cli. There is a sub-directory called data, it contains one file for each registered phone number (the filename is the phone number). I copied the directory „data“ to a place where apache can find it (let’s say /opt/signal-cli/data). Then I tried to send messages with a command like this:

/usr/local/bin/signal-cli --config /opt/signal-cli/data -u +49123456789 send -m 'Hello World' +49987654321

That does not work, the error message will be „User is not registered.“

It took a while until I noticed my mistake: The config parameter should only be the basic directory for the signal configuration. There signal-cli expects a subdirectory „data“. So the right way to call signal-cli is this:

/usr/local/bin/signal-cli --config /opt/signal-cli -u +49123456789 send -m 'Hello World' +49987654321

Dieser Blog-Eintrag beschreibt ein paar kleine Problem, die man haben kann, wenn man mit dem Handy oder Tablet auf die Inhalte eines Servers im lokalen Netzwerk zugreifen und dabei den externen Hostnamen verwenden will.

Wenn man ein Webserver zu hause hat, dann hat man für diesen in der Regel auch einen externen Hostnamen, damit dieser aus dem Internet über diesen Hostnamen erreichbar ist (z.B. meinserver.example.com). So kann man dann von unterwegs zum Beispiel auf OwnCloud, NextCloud, E-Mails oder was auch immer zugreifen. Dafür gibt es ja diverse Möglichkeiten, z.B. über DynDNS Service oder für Besitzer einer FritzBox über MyFritz. Wenn man zu hause ist (also im eignen LAN/WLAN) sollte dieser Zugriff natürlich auch einwandfrei funktionieren. Damit meine ich, dass man den Server auch intern über seinen Hostnamen erreicht und diese Verbindung ausschließlich über das interne Netz erfolgt. Das hat dann diverse Vorteile:

• SSL-Zertifikate für verschlüsselte Verbindungen (z.B. von Let’s Encrypt), können auch im eigenen Netz verwendet werden. Diese Zertifikate sind für den externen Hostname ausgestellt, also z.B. meinserver.example.com. Würde man intern über einen anderen Hostnamen oder die lokale IP-Adresse zugreifen, würde der Browser eine Fehlermeldung wegen dem ungültigen Hostnamen anzeigen (Firefox: SSL_ERROR_BAD_CERT_DOMAIN).
• Man braucht am Mobilgeräte keine zwei Konfigurationen für interne und externe Zugriffe, z.B. für Datei-Synchronisation oder automatische Backups.
• Man kann Dienste nutzen, die nur im lokalen Netz zur Verfügung gestellt werden und die extern nicht erreichbar sein sollen (z.B. die Smart-Home-Steuerung).
• Lokale Zugriffe sind deutlich schneller, dazu gleich mehr.

Mir sind dabei ein paar Probleme aufgefallen, deren Lösung ich hier kurz beschreiben möchte.

Das erste Problem ist mir bei OwnCloud aufgefallen. Über die App „FolderSync“ wollte ich von meinem Handy Backups auf OwnCoud sichern (über WebDav). Das war allerdings unglaublich langsam. Bei NextCloud war es das gleiche Problem. Auch andere Sync-Apps hatten das Problem. Wenn ich von meinem PC über WebDav Dateien auf OwnCloud oder NextCloud kopiert habe, war es schnell. Es musste also etwas mit der Verbindung von Handy zum Server zu tun haben. Die Logfiles vom Webserver haben mich dann auf die Ursache gebracht: Die Android-Geräte haben sich mit einer externen IP-Adresse zum Server verbunden. Wie kommt es dazu?

1. Das Mobilgerät erhält seine IP-Adresse, Gateway und DNS-Server über DHCP vom Router (in meinem Fall eine Fritzbox). DNS-Server ist der Router.
2. Beim Verbindungsaufbau zu meinserver.example.com fragt das Mobilgerät seinen DNS-Server (den Router) nach der IP-Adresse.
3. Der Router kennt nur den internen Namen des Servers und fragt daher bei einem externen DNS-Servern nach.
4. Dieser liefert die externe IP-Adresse zurück, die man momentan hat.
5. Das Mobilgerät macht den Verbindungaufbau über die externe IP-Adresse. Damit verlässt sämtlicher Netzwerktraffic erst das lokale Netz, geht zum ersten Router des Providers und geht dann wieder zurück über den eigenen Router ins lokale Netz.

Ich musste also den Mobilgeräten irgendwie beibringen, dass der externe Hostname über die interne IP-Adresse viel schneller erreichbar ist als über die externe IP. Die einfachste Möglichkeit wäre eigentlich, wenn man den Hostname des Servers direkt am Router einstellen könnte. Dann könnte der die Frage nach der IP direkt beantworten. Zumindest die FritzBox kann das aber nicht, weil im Hostname keine Punkte erlaubt sind. Die Lösung war für mich DNSMASQ, ein kleiner DNS-Server, der am Server installiert wird und der die Frage nach seinem Hostname direkt mit seiner lokalen IP beantwortet (Testen unter Linux z.B. mit dig @meinserver meinserver.example.com, die Antwort sollte die lokale IP-Adresse sein, z.B. 192.168.0.2). Über die FritzBox kann man festlegen, dass alle Geräte, die ihre Netzwerkeinstellungen per DHCP erhalten, einen bestimmten DNS-Server nutzen sollen. Dort einfach die lokale IP-Adresse des Servers eintragen, auf dem DNSMASQ läuft (zweiter DNS-Server wird die FritzBox selbst).

Das zweite Problem hatte ich nach der Umstellung auf VDSL: Mit der neuen FritzBox 7560 hat das alles nicht mehr funktioniert, obwohl es noch so konfiguriert war, wie zuvor. Zumindest dachte ich das. Sämtliche Android-Mobilgeräte nutzten wieder die externe IP-Adresse. Mit den Apps „Ping & DNS“ und „DNS Debugger“ hab ich dann auch den Grund dafür gefunden: Über die neue FritzBox haben die Mobilgeräte IPv6-Netzwerkadressen erhalten und damit auch den eignen DNS-Server ignoriert. Die Lösung war in diesem Fall ganz einfach: IPv6 in der FritzBox abschalten und schon funktioniert es wieder wie zuvor.

Wenn man unter Android HTML-Dateien auf der SD-Karte hat, kann man diese über den Datei-Explorer nur in der HTML-Anzeige öffnen. Damit kann man aber nicht viel machen, z.B. keine anderen lokal verlinkten Dateien öffnen. Es gibt leider keine Möglichkeit, eine HTML-Datei direkt aus dem Explorer in Chrome zu öffnen, ohne eine App dafür zu installieren. Die App „Open in Browser“ kann das angeblich, ich hab das aber nicht getestet.

Es gibt aber eine einfache Möglichkeit, eine HTML-Datei in Chrome zu öffnen. Man muss nur die lokale URI wissen und einmal eingeben. Das kann man sich für später dann einfach als Lesezeichen speichern. Hier ein Beispiel: Wenn die Datei index.html auf der SD-Karte im Unter-Verzeichnis my_documents/test liegt (komplette URI: /storage/emulated/sdcard/my_documents/test/index.html), dann muss man folgendes in die Adresszeile von Chrome eingeben:

file:///sdcard/my_documents/test/index.html

Wichtig sind die drei „/“ hinter file:, wenn man hier (wie normalerweise üblich) nur zwei Slashes angibt, bekommt man die Meldung „Der Zugriff auf die Datei wurde verweigert“ (ERR_ACCESS_DENIED).

Ich nutze das für einige HTML-Dateien, die untereinander verlinkt sind und die regelmäßig mit FolderSync auf mein Mobiltelefon kopiert werden. Somit hab ich die Daten auch offline verfügbar. Und die Links von einer HTML-Datei zur nächsten funktionieren auch.

Getestet unter Android 7.1.1, vermutlich geht das mit früheren Versionen genauso.

Since a few days I had a problem on my Ubuntu machine that I use at home: After logging in, the system showed a warning, that /tmp was nearly full. Checking it with df -h showed that over 95% of 10 gigabyte were used. But sudo du -hs /tmp/ showed that only 5 megabyte were used by files. /tmp has it’s own partition and uses the XFS filesystem. On askubuntu.com and serverfault.com I found some promising problem descriptions and possible solutions, but none of them fit for me. Finally xfs_repair solved the problem. For this you need to unmount /tmp, so I did this:

• Edit /etc/fstab so that the tmp-partition will not be mounted on next boot (put „#“ at the beginning of the line that mounts /tmp)
• Reboot, /tmp is now part of the root filesystem /.
• Call sudo xfs_repair /dev/sdxY (replace sdxY by whatever your tmp-partition is).
• Mount the partition somewhere temporarily (for example /mnt/tmp) and check with df -h if this solved the problem.
• Edit /etc/fstab again to reactivate the tmp-partition. Then reboot and check again.

Heute habe ich versucht eine paar Funksteckdosen von REV Ritter mit einem 433MHz Sendermodul (FS1000A) und einem Banana Pi zu schalten. Mit einem Raspberry Pi sollte es genauso funktionieren. Die Steckdosen mit der Artikelnummer 00834514 gibt es für ca. 15 Euro in Baumärkten oder bei Amazon (3 Steckdosen und eine Fernbedienung). Im Gegensatz zu meinen anderen Funksteckdosen von Mumbi (m-AFS102) kann man bei den REV-Steckdosen die Funk-Kennung nicht selbst einstellen. Man muss also zuerst mal ermitteln, welche Daten die Fernbedienung sendet. Dazu habe ich das Empfängermodul (XY-MK-5V) angeschlossen (VCC auf Pin 1, GND auf Pin 6, DATA auf Pin 12), die Software pilight nach dieser Anleitung installiert und den Service mit service pilight start gestartet. Dann einfach pilight-receive aufrufen, auf eine Taste der Fernbedienung drücken und die Ausgaben prüfen. Bei mir sah das ungefähr so aus:


{
"message": {
"id": 12345678,
"unit": 15,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch",
"uuid": "0000-01-23-45-1234ab",
"repeats": 2
}


Der gleiche Message-Block wurde mehrmals wiederholt, abwechselnd mit den Protokollen arctech_switch und arctech_contact. Zum Senden hab ich das Empfänger-Modul entfernt und das Sender-Modul angeschlossen (VCC auf Pin 1, GND auf Pin 6, DATA auf Pin 11). Jetzt musste ich nur noch das passende Protokoll finden, denn pilight-send hat kein offensichtlich passendes Protokoll angeboten. Funktioniert hat es dann mit dem Protokoll kaku_screen. Mit folgendem Befehl konnte ich dann die Steckdosen schalten:


# An
pilight-send -p kaku_screen -u 15 -i 12345678 -t
# Aus
pilight-send -p kaku_screen -u 15 -i 12345678 -f