Howtos

HDCP ist das Verfahren, mit dem HDMI-Signale verschlüsselt sind. Die ganze Technologie soll als "Kopierschutz" dienen, was an sich schon blödsinnig ist, bei digitalen Medien aber auch systembedingt gar nicht funktionieren kann. Die Industrie versucht mit HDCP einfach nur den Zugang zum Signal zu erschweren, verhindern kann sie nichts. Isotopp hat das schon mal ganz anschaulich für das Internet erklärt, und es gilt für jedes digitale Signal: Irgendwo wird es genutzt, also fällt es auch irgendwo unverschlüsselt heraus.

Im Zweifel aus dem Bildschirm.

Statt dass man die Daten direkt auf dem PC abgreift, holt man sie sich eben auf der Consumer-Hardware hinter dem Chip ab, der die Entschlüsselung macht. Das ist in einigen Fällen offenbar eine einfache Lötarbeit, der verlinkte Artikel zeigt, wie es geht.

Somit bleibt zwar eine Hürde, die die breite Masse nicht mehr überspringen kann. Vergleichsweise niedrig ist sie jedoch für Leute, die mit krimineller Absicht Urheberrechte verletzen, aber auch für Vernunftbegabte, die schlichtweg keine Lust haben, sich in der Nutzung eines Mediums, für das sie bezahlt haben, übermäßig (und damit eigentlich auch dem Geiste des Urheberrechts zuwiderlaufend) einschränken zu lassen. Vom erhöhten Stromverbrauch durch die unsinnige Verschlüsselung ganz zu schweigen.

Das Abgreifen des unverschlüsselten HDMI-Signals funktioniert vermutlich bei solchen Fernsehern, die "Fast HDMI switching" beherrschen, direkt hinter dem HDMI-4-Wege-Umschaltchip. 8 Leitungen müssen mit etwas Geschick an dünne Beinchen angelötet werden.

Wer hin und wieder mit SSH tunnelt, kennt längliche Eingaben wie ssh -p1234 -L60777:userkiste1:8080 root@mainserver.example.com.

Gut, das könnte man mit beliebigen weiteren Optionen auch in ein Script packen, aber eigentlich gehören die Parameter in eine Konfigurationsdatei. Dass man Port und zu verwendendes Keyfile problemlos in der ~/.ssh/config eintragen kann, ist bekannt, weniger jedoch die Verwendung eines Aliases und die Möglichkeit, den Tunnel fest einzustellen. Das geht so:

Host main-tunnel
Hostname mainserver.example.com
Port 1234
User root
LocalForward 1234 userkiste1:8080
IdentityFile ~/.ssh/id_mainserver


Danach genügt es, einfach ssh main-tunnel einzugeben. (Mit Tab-Completion fällt das ganze dann vielleicht sogar zu ssh m- zusammen.)

Dieser Komfort ist es, denn ich an der Linux-Welt mag.

(Ja, SSH ist ein BSD-Projekt, ich weiß...)

Der Mailman-ssls-Patch vom 18.07.2009 enthält Fehler. Mails können unverschlüsselt versandt werden, wenn der Schlüssel des Empfängers ungültig ist, obwohl im das Webinterface "Force" (erzwingen) ausgewählt wurde. Außerdem können Administratoren keine Schlüssel austauschen, beim Austragen eines Mitglieds wird der alte Schlüssel nicht gelöscht. Die ersten beiden Fehler sind mit dem folgenden Patch gegen das hier verlinkte Sourcecode-Paket leicht zu beheben:

"Mailman-ssls 2.1.12 kleinere Bugfixes" ... »

In diesem Eintrag zu Mailman-ssls ist der gepatchte Code in Version 2.1.11 verlinkt.
Hier nun die neue Version: mailman-ssls-2.1.12.tar.bz2 herunterladen.

Und noch zwei Ergänzungen:

• Ich würde beim configure-Durchlauf noch --with-mail-gid=nogroup anhängen, um Ausführungsproblemen vorzubeugen.

• Unbedingt beachten: Nur die englischen Templates der Weboberfläche wurden gepatcht. Die deutsche Oberfläche erlaubt es nicht, öffentliche Schlüssel der Listenteilnehmer einzutragen, und Mailman-ssls treibt Admins, die es auf anderen Wegen versuchen, in den Wahnsinn.

Das Plugin pidgin-microblog ermöglicht Abruf und Senden von Twitter-Nachrichten in Pidgin. Als Debian-Paket ist es nicht verfügbar, aber die Ubuntu-Version funktioniert.

Man trägt in /etc/apt/sources.list eine zusätzliche Zeile ein:

deb http://ppa.launchpad.net/sugree/ppa/ubuntu jaunty main

Und updatet die Paketlisten mit aptitude update, um dann mit aptitude install pidgin-microblog zu installieren. Voila.

Vorsichtshalber habe ich die Ubuntu-Quelle hinterher wieder auskommentiert.

Kristian Köhntopp erklärt schön einfach für Einsteiger, wie Procmail funktioniert.

Allerdings wird Procmail zunehmend unbeliebt. Eine einfachere Syntax hat Couriers Maildropfilter.

Ein Filter, der Mails, die nicht eine bestimmte Empfängeradresse tragen, in einen speziellen Ordner sortiert und alle anderen dorthin kopiert, sieht dort z.B. so aus:

if ( /^To:.*@datenritter.*/ || /^To:.*datenritter@mailhost.zuhause.local.*/ )
{
cc $HOME/Maildir/.komisches
to $HOME/Maildir
}
else
{
to $HOME/Maildir/.komisches
}

(Die to-Zeile im ersten Block kann man auch weglassen.)

Die Distribution Ubuntu dürfte mit ihrem Sinn für Benutzerfreundlichkeit wesentlich dazu beigetragen haben, dass sich der NetworkManager (Homepage), ursprünglich ein Projekt von Red Hat, durchgesetzt hat. Er konfiguriert Netzwerkschnittstellen automatisch und macht damit Linux-Notebooks eigentlich erst richtig benutzbar.

Die Idee, dass ein User die Netzwerkschnittstellen konfigurieren könnte, war der Linux-Welt lange Zeit fremd. Doch das Überall-Netz setzt sich durch und WLANs machen schnelle Wechsel erforderlich.

Zum Daemon gibt es grafische Helferlein, wie den KNetworkManager für KDE, mit denen auch Unbedarfte "mal eben schnell" den WLAN-Zugang einrichten können. Mittlerweile beherrscht er sogar VPNs.



Man versuche zum Vergleich, OpenVPN unter Windows für User ohne Administratorrechte aufzusetzen. Ein schlechter Scherz.

Dennoch ist es gut zu wissen, wie man dem NetworkManager bei Bedarf Einhalt gebietet, zum Beispiel wenn man sein VPN unabhängig eingerichtet hat. Denn der NetworkManager startet den DHCP-Client, wenn kein Server da ist, und ein auf der Konsole manuell konfiguriertes Interface setzt er schnell mal zurück.

Beispiele in der Dokumentation des Debian-Pakets erklären, welche Interfaces von NetworkManager kontrolliert werden, und welche nicht:

1.)
auto wlan0
iface wlan0 inet dhcp
-> This device is managed by NM.

1.a)
allow-hotplug eth0
iface eth0 inet dhcp
-> This device is managed by NM

2.)
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
-> This devices is *not* managed by NM because it has additional options.

3.)
iface wlan0 inet dhcp
-> This device is *not* managed by NM because it is not set to "auto".

4.)
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
-> This device is *not* managed by NM because it is configured as "static" and
has additional options.

5.)
Device is not listed in /etc/network/interfaces.
-> Device is managed by NM.

Da ein beispielsweise von OpenVPN erzeugtes TAP- oder TUN-Device normalerweise nicht in /etc/network/interfaces eingetragen ist, greift die Regel aus Beispiel 5, und der NetworkManager nimmt dem TAP-Device schnell wieder die IP weg, nachdem OpenVPN sie und die zugehörigen Netzwerk-Routen gesetzt hat.

Eine gleichzeitige manuelle Konfiguration gelingt hingegen, weil sie erst nach dem Eingriff stattfindet, und daher eine gewisse Zeit bestehen bleibt. Das Logfile von OpenVPN behauptet, alles sei ok. Die Verwirrung ist perfekt, der Administrator beißt wutentbrannt in die Tastatur.

Wenn man weiß, wie es geht, ist es einfach: Ein Eintrag iface tap0 inet manual in /etc/network/interfaces behebt das Problem. (Der NetworkManager sollte neu gestartet werden.) Das TAP-Device bleibt wie in Beispiel 3 unangetastet, das VPN funktioniert.

Wegen eines Fehlers beim Umkopieren eines großen Datenbestands sind mir die Änderungszeitstempel (modification time, mtime) abhanden gekommen. Ein weiterer guter Grund, ein Backup zu haben!

Um die Zeitstempel wiederherzustellen, ohne die Dateien selbst zu überschreiben, habe ich aus dem Backup eine Liste erzeugt, in der Dateipfade und Zeiten getrennt durch " #+# " gespeichert werden. Das geht z.B. mit stat, und zwar so:

#!/bin/sh

ifs_backup="$IFS"
TARGETDIR=/actual/place

find . | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
MODTIME=`stat -c %y "${DIRFILE}"|sed -s "s/\..*//"`
DIRFILE2="${TARGETDIR}"`echo -n "${DIRFILE}"|sed -s "s/^.//"`
echo "${DIRFILE2} #+# ${MODTIME}">> dirfilelist.txt
done


Die Einträge in dirfilelist.txt sehen dann etwa so aus:

/home/adorno/test/script.sh #+# 2009-06-06 15:23:00


Das folgende Script liest diese gespeicherten Daten und ändert die Dateien auf dem Zielsystem:

#!/bin/sh

ifs_backup="$IFS"

while true; do
COUNT=0
cat dirfilelist.txt | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
DIRFILE2=`echo "${DIRFILE}"|sed -s "s/\ #+#\ .*//"`
NEWMODTIME=`echo "${DIRFILE}"|sed -s "s/.*\ #+#\ //"`
if [ -e "${DIRFILE2}" ]; then
MODTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
touch -cm -d "${NEWMODTIME}" "${DIRFILE2}"
NEWTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
echo "${DIRFILE2} has modification time ${MODTIME}, changed to ${NEWMODTIME}. Result: ${NEWTIME}" >> mtimeset.log
COUNT=$COUNT + 1
else
echo ${DIRFILE2}" does not exist!" >> mtimeset_error.log
fi
if [ ${COUNT} -gt 10000 ]; then
echo "Deleting 10000 lines from dirfilelist.txt."
sed '10001,$w dirfilelist2.txt' dirfilelist.txt >/dev/null
mv dirfilelist2.txt dirfilelist.txt
break;
fi
done
done


Die äußere Schleife bewirkt, dass die Liste gleich um die abgearbeiteten Einträge (evtl. abzüglich einer Zeile zu wenig) bereinigt wird, verhindert aber, dass das Script terminiert. Man kann es also auch mal abbrechen, muss dafür aber die Logfiles im Auge behalten.

Die Scripte sind nicht unbedingt elegant, und natürlich gibt es viel Raum für Verbesserungen. Vor allem an der Geschwindigkeit lässt sich sicher noch etwas machen, wenn man z.B. Aufrufe von stat einspart.

Wie dem auch sei: Have a backup!

Für verschlüsselte Mailinglisten gibt es verschiedene Ansätze. Leicht ist das Leben, wenn man Mailman-ssls einsetzt. Die erweiterte Version kann all das, was die verbreitete Mailingslistensoftware Mailman auch kann, beherrscht zusätzlich aber diverse Verschlüsselungsfeatures.

Mails an die Liste werden nur noch mit dem Listenschlüssel verschlüsselt, Mailman-ssls entschlüsselt die Mails und verschlüsselt sie dann wieder für jeden Abonnenten einzeln. Nicht verschlüsselte Mails können abgelehnt werden, Empfänger ohne Schlüssel bekommen keine Kopie. Natürlich müssen die öffentlichen Schlüssel der Empfänger dem Server zur Verfügung stehen. Mailman-ssls hat dafür eine Verwaltungsfunktion.

Der große Vorteil von Mailman-ssls ist, dass die Listenteilnehmer nicht die Schlüssel aller anderen haben müssen oder gar selbst in ihren Mailprogrammen Listen pflegen. Den Komfortgewinn bezahlt man mit ein wenig Zentralismus, was auch ein Nachteil ist, denn der Server muss unbedingt absolut sicher sein, sonst könnten alle Listenmails offengelegt werden. Das heißt, er muss vor Hackerangriffen, aber auch vor physikalischem Zugriff sicher sein. Wie so oft läuft das schnell auf die Frage hinaus, ob man seinem Hoster vertraut, doch dies soll hier nicht diskutiert werden.

Erhalten bleibt auf jeden Fall der Vorteil, dass Mails auf der eigenen Festplatte verschlüsselt abgelegt bleiben, Angriffe gegen einzelne Teilnehmer einer Cryptoliste sind also nicht erfolgversprechender als sonst auch. Mailman-ssls führt aus Sicherheitsgründen standardmäßig kein Archiv und beherrscht OpenPGP-Schlüssel genauso wie X.509-Zertifikate.

Leider hat sich die Einrichtung auf einem Debian-System als etwas schwierig erwiesen, den weiten Weg zum Ziel fasse ich in diesem HowTo zusammen. "verschlüsselte Mailinglisten mit ... »

Farbige und (je nach Empfinden) besser lesbare Manpages erzeugt das Programm most:

apt-get install most

Dieses muss noch als tatsächlich zu verwendender Pager eingestellt werden:

update-alternatives --config pager

Dann sehen die Manpages so aus:



Gefunden bei linuxtoday.com.