Datenroaming from Hell

Ich bin demnächst ein paar Tage in Polen und möchte gerne auf Internet auf dem Smartphone nicht verzichten. Ich habe also bei T-Mobile (meinem Mobilfunkprovider) geschaut, wie ich im Ausland ins Internet komme, ohne meine Organe verkaufen zu müssen.

Roaming_-_günstig_im_Ausland_telefonieren_und_surfen___Telekom

Der Standardtarif („In allen Tarifen voreingestellt“) ist indiskutabel. Wer das verbrochen hat, verdient einen besonderen Platz in der Hölle.

Da ich nicht ganz eine Woche in Polen bin, fiel mein Blick zuerst auf den „Travel&Surf“-Tarif für 7 Tage. Aber 150 MB für 7 Tage für 15€ ist einfach nur lachhaft. Die 150 MB würden vielleicht für einen Tag reichen. Und der Preis ist ist völlig inakzeptabel. (0,10€/MB)

Ich habe zum Schluß die Flat für 20€ genommen. Da wird mein monatliches Inklusiv-Volumen verwendet. In Deutschland bin ich meist in irgendwelchen WLANs eingebucht, und verbrauche mein Inklusiv-Volumen kaum, es bleibt also ausreichend Volumen über. Die 20€ sind immer noch horrend, aber alle Alternativen sind noch schlimmer.

Sollte ich demnächst wieder öfters Polen sein, werde ich mich nach Prepaid-Optionen direkt in Polen umschauen müssen.

Minimalistische Firewall-Regeln auf 1&1 Cloud Server

Beim Wechsel von meinem „alten“ 1&1 Dynamic Cloud Server auf einen neuen 1&1 Cloud Server (man beachte die Abwesenheit des Wortes „Dynamic“) habe ich mich gewundert, wieso Email-Versand und -Empfang nicht funktionieren wollte. Nach langer und vergeblicher Suche in Plesk fand ich die Ursache im 1&1 Cloud Panel.

Im Panel finden sich unter Netzwerk -> Firewall-Richtlinien zwei Default-Richtlinien. Die Richtlinie für Linux läßt gerade mal SSH (Port 22), HTTP(S) (Port 80 und 443) und Plesk (8443 und 8447) zu. Erst als ich hier noch SMTP (Port 25), Submission (Port 587) und IMAPS (Port 993) in die Richtlinie aufgenommen habe, funktionierten Emails wie gewohnt.

 

SSH-Agent für Authentizierung mit sudo verwenden

Pam-ssh-agent-auth ist ein PAM-Modul, um SSH-Schlüssel für die Authentizierung mit sudo zu verwenden. Das ständige eintippen des Passwortes kann auf die Dauer lästig werden, aber die authentizierung ganz abzuschalten fühlt sich auch irgendwie falsch an. Dieses Modul stellt einen guten Kompromiß dar.

Installation

Die Installation ist auf CentOS 7 (und CentOS 6) ist recht einfach, da das Modul einfach mit yum installiert werden kann:

yum install pam_ssh_agent_auth

Konfiguration

Nach der Installation sind noch ein paar Anpassungen notwendig, damit das Modul mit sudo verwendet wird. Die Umgebungsvariable SSH_AUTH_SOCK muß von sudo erhalten bleiben. Hierzu muß in der sudoers-Datei (mit visudo bearbeiten) folgende Zeile ergänzt werden: (Die Datei enthält bereits einige env_keep-Zeilen. Diese sollte einfach hinter die anderen env_keep-Zeilen angehängt werden.)

Defaults    env_keep += "SSH_AUTH_SOCK"

Jetzt muß noch PAM auch das Modul für sudo verwenden. In der /etc/pam.d/sudo-Datei muß am Anfang (nach der Zeile mit #%PAM-1.0) folgende Zeile eingefügt werden:

auth       sufficient   pam_ssh_agent_auth.so file=%h/.ssh/authorized_keys

Damit ist die ganze Konfiguration abgeschlossen.

Test

Um zu Testen, ob das nun funktioniert, sollte man sich mit einem SSH-Schlüssel auf der Maschine anmelden und dann mit erst sudo -k möglicherweise noch gecachte Login-Daten aus sudo löschen und dann mit sudo -l schauen, was sudo einem erlaubt.

Sollte sudo unerwartet trotzdem nach dem Passwort fragen, kann man in der /var/log/secure nach Hinweisen für das Problem suchen. In meinem Fall hatte ich schlichtweg vergessen, den SSH-Agent beim SSH-Login weiterzuleiten (-A von der Kommandozeile oder ForwardAgent yes in der ~/.ssh/config.

TIL Kosher Salz ist nicht Salz was koscher ist

In vielen Rezepten im Internet wird als Zutat oft „Kosher Salz“ (im engl. kosher salt) verlangt. Als nicht-Jude fragte ich mich, ob es normales nicht-koscheres Salz auch tut.

Stellt sich heraus, das Salz trägt den Namen nicht, weil es kosher ist. (Das ist Salz sowieso immer) Dieses Salz wird zum Koschern von Fleisch verwendet, und trägt deshalb diesen Namen. Das Salz an sich ist nur grob gemahlenes Salz ohne Zusatzstoffe.

Zum Nachkochen von Rezepten aus dem Internet tut es also ganz normales groben Steinsalz auch.

Waiting for root device

Bei meinem Late 2007er iMac wollte ich ein neues System installieren, nachdem die Festplatte den Geist aufgegeben hatte. Neue Festplatte eingebaut und einen mit createinstallmedia erstellten USB-Stick eingestöpselt. Der Bootvorgang endete immer mit dem Verbotszeichen. Booten im Verbose-Mode (⌘-V) endete immer mit „Still waiting for root device“.

Das Problem lag anscheinend am USB-Stick. Nachdem ich das Install-Medium auf einem anderen USB-Stick geschrieben habe, hat der iMac anstandslos gebootet und ich konnte das System installieren.

YubiKey NEO mit Debian

Und wenn der YubiKey NEO unter Debian nicht als Kartenleser erkannt wird, fehlen in der /etc/libccid_Info.plist vermutlich ein paar Einträge. Das dazugehörige diff sieht so aus:

--- /etc/libccid_Info.plist.backup 2014-11-10 20:53:41.000000000 +0100
+++ /etc/libccid_Info.plist 2014-11-10 21:05:38.000000000 +0100
@@ -325,6 +325,8 @@
<string>0x08C3</string>
<string>0x08C3</string>
<string>0x15E1</string>
+ <string>0x1050</string>
+ <string>0x1050</string>
</array>

<key>ifdProductID</key>
@@ -550,6 +552,8 @@
<string>0x0401</string>
<string>0x0402</string>
<string>0x2007</string>
+ <string>0x0111</string>
+ <string>0x0112</string>
</array>

<key>ifdFriendlyName</key>
@@ -775,6 +779,8 @@
<string>Precise Biometrics Precise 250 MC</string>
<string>Precise Biometrics Precise 200 MC</string>
<string>RSA RSA SecurID (R) Authenticator</string>
+ <string>YubiKey NEO Composite</string>
+ <string>YubiKey NEO CCID</string>
</array>

<key>Copyright</key>

RFID-Reader mit Debian

Wenn der RFID-Reader (in meinem Fall der ACR122) unter Debian einfach nicht funktionieren will, obwohl der Kernel anzeigt, daß er das Gerät gefunden hat. Und der pcscd ähnliche Meldungen ausspuckt:

00410836 ccid_usb.c:645:OpenUSBByName() Can't claim interface 001/008: Device or resource busy

Dann nimmt vermutlich das falsche Kernel-Modul das Gerät unter beschlag. Folgendes half bei mir, den RFID-Reader endlich zum Leben zu erwecken. In /etc/modprobe.d/rfid-blacklist.conf (Datei anlegen, da sie standardmäßig nicht existiert) folgende Zeilen einfügen:

blacklist pn533
blacklist nfc

Raspberry Pi als C64-Emulator

Der Raspberry Pi ist ein vielseitiges Gerät. Während mein erster Raspberry Pi seine Arbeit als NTP-Server mit GPS verrichtet, habe ich versucht auf dem zweiten einen C64-Emulator zum laufen zu bringen. Der Anfang war ein wenig holprig, aber zum Schluß habe ich es geschafft.

Mein erster Versuch war einfach mit dem Standalone VICE, wie in „how to install/run C64 emulator VICE on your PiMAME“. Der Emulator funktionierte bestens, ich konnte ihm jedoch keinen Ton entlocken. Bei der Suche nach einer Lösung stieß ich auf ChameleonPI, ein fertiges Disk-Image mit einem Haufen an Emulatoren und einer hübschen grafischen Oberfläche. Die Installation ist denkbar einfach. Auf dem Mac beschränkte es sich im Grunde auf:

diskutil list  # Devicenamen der SD-Karte rausfinden (bei mir /dev/disk3)
diskutil unmountDisk /dev/disk3  # SD-Karte unmounten
sudo dd bs=1m if=chameleon.v032.img of=/dev/rdisk3  # Achtung, raw disk verwenden!
diskutil unmountDisk /dev/disk3  # Nochmal auswerfen, weil OS X sie automatisch gemountet hat

Nach dem Start wurde ich von einem netten Menü zur Auswahl des Emulators begrüßt. Der USB-Joystick funktionierte auch und sogar der Ton schien zu funktionieren. (Zumindest im Menü). Ich habe zum Test ein Disketten-Image auf den Pi kopiert und wurde erneut enttäuscht. Kein Ton. Obwohl ich ALSA als Sound-System eingestellt habe, bliebt der Emulator stumm. Erst ein Post im Raspberry-Pi-Forum von Frank Buß brachte mich auf die Lösung. Die Firmware des Pi mußte aktualisiert werden. Zum Glück war das nicht weiter schwer:

sudo apt-get install rpi-update
sudo rpi-update

Nach dem Reboot funktionierte dann der Sound auch im C64-Emulator.

Bei meinen Versuchen mit diversen Spielen mußte ich dann noch feststellen, daß es gelegentlich etwas ruckelte. Ich habe meinen Pi aus diesem Grunde auf 900 MHz übertaktet, was das Problem bei mir behob.