Eigentlich ist das OpenSync-Projekt ja eine tolle Sache, deren Konzept ich toll finde. Grundlegend schaut es so aus, dass man eine Bibliothek, die so genannte libopensync, benoetigt. Darauf aufbauend kann man sich dann Plugins zur Synchronisation wie z.B. fuer Sunbird, Evolution, SyncML etc. installieren. Angesprochen wird das ganze dann entweder ueber eine grafische Oberflaeche oder ein Shellprogramm.

Allerdings ist das Projekt noch recht jung und das merkt man. Ich habe nun bisher 3 Versuche gestartet die Software auf meinem Notebook unter Arch Linux zum Laufen zu bringen. Geplant war eine Synchronisation des Kalenders meines Mobiltelefons mit einem WebDAV-Share auf dem eine iCal-Datei liegt.

Installation:

Versuch 1

Installieren der libopensync mittels pacman und dann Kompilieren der Plugins mit PKGBUILDs aus dem Arch User Repository. Hier sind die Versionen des SyncML- und Sunbird-Plugins aus AUR allerdings inkompatibel zur Version 0.36 die pacman installiert hat. Also das war schonmal nichts.

Versuch 2:

Installation ueber modifizierte PKGBUILDs, die sich die Sourcen aus dem Subversion-Repository holen. Ergebnis: Libopensync, das SyncML-Plugin und das File-Plugin kompilieren. Leider ist im Subversion-Repository kein aktuelles Sunbird-Plugin enthalten und das Shellprogramm erkennt das Fileplugin nicht. Somit war nichtmal ein Synchronisationstest moeglich.

Versuch 3:

Nun habe ich probiert mir meine PKGBUILDs so umgebaut, dass fuer alle notwendigen Pakete eine aeltere Version (0.22) verwendet wird. Ergebnis: Alles notwendige kompiliert korrekt, nur das absolut notwendige SyncML-Plugin nicht. Anscheinend hatte das Plugin Probleme mit der Version 0.4.6 der libsyncml, die ich installiert hatte. Nach einem Downgrade auf 0.4.5 kompiliert das Paket sauber durch. Auch das Kompilieren der Version 0.22 des Shellprogramms msynctool funktioniert. Ist doch zumindest mal was.

Vorbereitungen:

Also mal kucken, ob auch alle Plugins erkannt werden:

Konfiguration :

Nach diesem Krampf bin ich, wie in diesem Howto beschrieben, vorgegangen. Zuerst wird ein Profil zum Backup der Daten, die auf dem Handy liegen, angelegt:

Danach sollte man bluetooth starten. Bei meinem Thinkpad erledigt dies das folgende Script, dass ueber eine Tastenkombination gestartet wird:

Nun mal kucken, ob das Handy gefunden wird:

 hcitool scan
Scanning ...
    00:11:XX:XX:XX:XX  WolleRosekaufe?

Bei 00:11:XX:XX:XX:XX handelt es sich um die Bluetoothadresse des Handys diese hier wurde annonymisiert.

Anschliessend kann man mit spdtool ein paar Informationen ueber das Telefon ergattern. Eine Eingabe von "sdptool browse 00:11:XX:XX:XX:XX " sollte unter anderem etwas in der Art liefern:

Service Name: SyncMLClient
Service RecHandle: 0x1000b
Service Class ID List:
  UUID 128: 00000002-0000-1000-8000-0002ee000002
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 11
  "OBEX" (0x0008)

Konfiguration des Datei-Plugins:

Startet man nun mit "msynctool --configure filenokia 1" die Konfiguration, kann man eine XML-Datei mit Hilfe von vi(m) editieren. Diese sollte folgenden Inhalt haben:

Konfiguration des SyncML-Plugins:

Ist dies erledigt, kann der SyncML-Client mit "msynctool --configure filenokia 2" konfiguriert werden:

Validieren laesst sich das Ganze mit "msynctool --showgroup filenokia".

Achtung: Da es unter Umstaenden zu Datenverlust kommen kann, sollte man seine Kontakte und wichtige Daten zuvor auf eine Speicherkarte sichern, damit man die im Falle eines Fehlers wieder herstellen kann.

Synchronisation:

Der eigentliche Sync-Vorgang laesst sich mit "msynctool --sync filenokia" anstossen. Mit dieser Konfiguration laesst sich nun das Adressbuch etc. als Backup auf die Festplatte synchronisieren. Bei mir hat super funktioniert.

Thunderbird/Sunbird/WebDAV-Kalender:

Synchronisation in einzelne Dateien ist ja ganz ok, aber eigentlich will man ja auch mit den Dateien arbeiten und zumindest seinen Kalender auf das Handy uebertragen. Hierfuer nutze ich das Sunbird-Plugin. Um dieses zu nutzen, legt man zuerst ein neues Profil an:

Nun kann man man wieder heraus finden, welches Plugin unter welchem Punkt zu konfigurieren ist:

msynctool --showgroup nokiasun 
Groupname: nokiasun
Member 2: sunbird-sync
    No Configuration found: Member has not been configured
Member 1: syncml-obex-client
    No Configuration found: Member has not been configured

Konfiguration des SyncML-Plugins:

Bei der Konfiguration mit "msynctool --configure nokiasun 1" kann der selbe Eintrag wie weiter oben beim SyncML-Plugin verwendet werden:

Konfiguration des Sunbird-Plugins:

Hier fuehrt man "msynctool --configure nokiasun 2" aus und traegt seinen WebDAV-Share samt Zugangsdaten ein. Da das Passwort im Klartext vorliegt, sollte man ~/.opensync eventuell speziell sichern, damit kein anderer Benutzer des Rechners Zugriff darauf erhaellt. Da meine Festplatte sowieso verschluesselt ist, werde ich darauf nicht weiter eingehen.

Hier kann man nun auch mit "msynctool --sync nokiasun" die Synchronisation starten.

Fazit:

Das beschriebene Setup funktioniert zwar prinzipiell aber man merkt stark, dass OpenSync noch stark weiterentwickelt werden muss. Die von mir verwendete Version ist auch nicht mehr die neuste aber leider funktioniert das Sunbird-Plugin bei anderen nicht. Das Synchronisieren sollte zwar prinzipiell moeglich sein, doch haengt der Vorgang bei einer direkten Synchronisation sehr oft. Ich habe bessere Ergebnisse erzielt als ich eine dritte Gruppe bestehend aus dem File-Plugin aus der ersten Gruppe und dem Sunbird-Plugin der zweiten Gruppe angelegt habe. Die Synchronisation ueber den Umweg WebDAV <=> File <=> Handy funktioniert, im Gegensatz zum direkten Abgleich, meistens.

Aufgetretene Fehler:

• haengenbleiben von msynctool waehrend der Synchronisation
• Probleme bei Eintraegen die sich wiederholen
• Probleme bei vielen Eintraegen im Kalender (ausmisten des Kalenders erforderlich)
• teilweise treten Terminkonflikte auf wo gar keine sind

Was noch nicht geht:

• Synchronisieren des Adressbuchs
• Synchronisieren der Todo-Liste aus Lightning
• problemloses synchronisieren

Alles in allem, bin ich nun froh ueberhaupt eine Moeglichkeit zu haben ab und zu den Kalender abzugleichen. Nun habe ich wenigstens wichtige Geburts- und Feiertage im Handy gespeichert. So wie ich gehoert habe, ist die aktuelle Version 0.3X sowieso nur fuer Entwickler gedacht und laut der Opensync-Website wird momentan stark an Version 0.40 gearbeitet. Darum bin ich noch der Hoffnung, dass sich dieses Projekt in absehbarer Zeit wirklich benutztbar wird und ohne grosses Frickeln installiert werden kann. Bis dahin bin ich zumindest mit der bisherigen Loesung zufrieden.

Weiterfuehrende Links:

• http://blog.dukanovic.com/?p=5
• http://opensync.org/
• http://wiki.ubuntuusers.de/OpenSync/Plugin-Sunbird

Gerade bin ich auf ein Tool gestossen, mit dem man sehr schoen beliebige Programme auf Linux fernsteuern kann. Es hoert auf den Namen anyremote.
Fuer das fernsteuern benoetigt man ein Geraet, dass man per Bluetooth oder Infrarot ansprechen kann und am PC einen Empfaenger. In meinem Fall dient als "Fernbedienung" mein Mobiltelefon, ein in die Jahre gekommenes Nokia 6630 und der eingebaute Bluetooth-Chip meines Thinkpads. Demnaechst werde ich das Ganze noch auf meinem Desktop mit einem D-Link Stick testen.
Ich habe mit die Software mit Hilfe des PKGBUILDs aus dem AUR kompiliert und installiert. Fuer andere Distributionen als Arch Linux gibt es vielleicht vorgefertigte Pakete oder man muss sich das Programm selbst kompilieren. Fuer Handys mit Java-Runtime gibt es dann das Programm zum download.
Ist die Software sowohl auf dem PC als auch auf dem Handy installiert, kann man bei beiden Bluetooth einschalten. Ueberpruefen, ob das Handy in Reichweite ist, kann man mit "hcitool scan". Bei meinem Bluetooth-Stick musste ich diesen noch mit "hciconfig -a hci0 up" aktivieren.
Wenn das alles funktioniert hat, kann man als User z.B. mit
anyremote -f /usr/share/anyremote/cfg-data/Server-mode/xine.cfg
den anyremote-Server fuer xine starten. Nun kann man, nach dem Verbinden, mit der Java-Software auf dem Handy grundlegende Funtkionen wie laut/leise, Pause, Vollbild etc. vom Handy aus steuern. Wichtig ist allerdings im Falle xine, dass xine mit der Option "-n" im Netzwerkmodus gestartet wird. Sonst funktionieren die xine-remote Kommandos nicht, die anyremote nutzt.
Ausser xine gibt es noch genug andere vorgefertigte Konfigurationen, die man nutzen kann wie zum Beispiel fuer Amarok, Xmms, Kmplayer, Rythmbox, MythTV etc.
Ich werde das Tool in Zukunft jedenfalls oefter nutzen.

Vorwort:

Vielen werden grosse Teiles dieses Howtos wohl bekannt vorkommen. Mittlerweile sind schon ein paar Monate vergangen, seit ich das letzte cryptsetup-LUKS Howto geschrieben habe. Ich habe mir hier beim Ueberarbeiten auch mehr Zeit genommen als beim eigentlichen Howto.
Eigentlich war noch ein Howto zum Verschluesseln aller Partitionen geplant, aber ich habe nun erstmal beschlossen das bestehende zu erweitern. Dieses hatte noch ein paar Macken und daher bin ich der Meinung, dass es sich lohnt es nochmals zu ueberarbeiten und neue Erkenntnisse einfliessen zu lassen. Ein paar Rechtschreibfehler wurden nebenbei auch korrigiert.
Ausserdem war, je nach System, auf technischer Seite zu viel Handarbeit beim Backup notwendig. Ich habe mir Gedanken gemacht, wie man die Vorgaenge der Verschluesselung moeglichst einfach automatisieren koennte und zum Entschluss gekommen, dass udev-Regeln, ein Eintrag in der /etc/fstab und die Arbeit mit zusaetzlichen Keyfiles das Ganze weitgehend optimieren und automatisieren koennen.

Das Howto:

Das Backup wichtig ist und die vorhandenen Daten auf einem Computer prinzipiell immer den Wert einer zusaetzlichen Festplatte uebersteigen, sollte wohl den meisten klar sein. Wer mit seinem PC arbeitet und damit vielleicht sogar sein Geld verdient kann sicherlich bestaetigen von was ich rede. Auch bei privaten Daten bin ich der Meinung, dass sich eine Sicherung lohnt.
Allerdings ist eine externe Festplatte auch ein Sicherheitsrisiko: Prinzipiell koennte jeder die Festplatte an seinen PC anschliessen und haette Zugriff auf alle gespeicherten Daten. Dieses Problem laesst sich mit der Verschluesselug der betroffenen Daten loesen - wenn man bereit ist einen etwas geringeren Datendurchsatz in Kauf zu nehmen. Doch ganz ehrlich: Wer legt bei einer Sicherungsfestplatte schon einen hoeheren Wert auf ein paar MB/s mehr Datendurchsatz wenn die Daten dafuer nicht gegen unbefugten Zugriff geschuetzt sind?

Vorbereitung

Zuerst muss im Kernel dm_mod und dm_cypt sowie aktiviert sein. Dies ist bei den meisten Distributionen sowieso der Fall. Bei einem selbst gebauten Kernel benoetigt man folgende Optionen:

Device Drivers  --->
Multi-device support (RAID and LVM)  --->
    [*] Multiple devices driver support (RAID and LVM)
    <>   RAID support
    <M>   Device mapper support
    <M>    Crypt target support

Cryptographic options  --->
  --- Cryptographic API
   <M>   SHA256 digest algorithm
   <M>   Blowfish cipher algorithm
   <M>   AES cipher algorithms (i586)

Zusaetzlich benoetigt man noch cryptsetup-LUKS. Dieses wird wird bei den meisten Distributionen ueber das Paketmanagement installiert werden koennen. Im Fall von Arch Linux waere das mit pacman moeglich:

pacman -S cryptsetup

Bei anderen Distributionen heisst das Paket entweder auch cryptsetup oder cryptsetup-luks. Dieses laesst sich dann mit apt, yum, portage etc. problemlos nachinstallieren. Wichtig ist nur, dass die notwendigen Kernelmodule vorhanden sind.

Ist cryptsetup-luks installiert, sollte man die Daten auf der zu verwendeten Festplatte zerstoeren. Also nicht nur loeschen oder die Festplatte neu formatieren, denn da besteht immer noch die Moeglichkeit, dass sich die Daten teilweise wiederherstellen lassen. Einen guten Artikel zum Loeschen von Daten findet man bei pro-linux.

Wird eine neue, ungebrauchte Festplatte verwendet, kann dieser Schritt uebersprungen werden.

Fuer die meisten duerfte hier dd das Tool der wahl sein. /dev/sdc1 ist in diesem Fall das Device ueber das ich meine Backupplatte anspreche. Welches das ist, sollte man genau (!!) wissen, da es sonst zu boesen Ueberraschungen in Verbindung mit den folgenden Aufrufen kommen koennte. Wer also kein Lust hat aus Versehen die falsche Platte zu loeschen, sollte hier lieber mehrfach pruefen.

Mit dd kann man die Festplatte sowohl mit Zufallswerten wie im ersten Aufruf oder mit Nullen wie im zweiten Aufruf ueberschreiben. Letzteres ist schneller aber dafuer unsicherer.

dd if=/dev/urandom of=/dev/sdc1

dd if=/dev/zero of=/dev/sdc1

dev/sdc1 ist hierbei das Device der verwendeten Festplatte. Ich empfehle hierzu die Manpage von DD. Alternativ kann man auch mit dem Befehl shred arbeiten. Hier gibt "-n" die Anzahl der Vorgaenge an. In diesem Fall wird die Platte 10x ueberschrieben:

shred -fv -n 10 /dev/sdc1

Verschluesseln:

Ist die Festplatte sauber, kann man mit sie cryptsetup formatieren:

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sdc1

Hiermit wird eine AES-Verschluesselung, SHA256 Hashes, ESSIV in Verbindung mit einem 256-Bit Schluessel verwendet.
Die Option "-s" gibt die Laenge des Schluessels an und die Option "-y" fordert den User auf eine Passphrase zu waehlen. Alternativ kann man mit "-d" auch ein Keyfile statt der Passphrase verwenden.
Weitere Optionen findet man in der Manpage.

Nun legt man sein Crypto-Device an:

cryptsetup luksOpen /dev/sdc1 backup

An dieser Stelle wird man nach der Passphrase gefragt, die man beim Formatieren eingegeben hat. Verwendet man ein Keyfile, muss man dieses ebenfalls mit "--key-file" angeben.
Der Befehl legt ein neues Device unter /dev/mapper an. In unserem Fall /dev/mapper/backup. Dieses kann man nun wie ein normales Blockdevice formatieren, mounten und beschreiben. Die Ver- und Entschluesselung laeuft transparent im Hintergrund ab.

Formatieren:

mkfs.ext3 /dev/mapper/backup

Mounten:

mount -t ext3 /dev/mapper/backup /mnt/tmp

Alle Daten die man in /mnt/tmp speichert, landen nun verschluesselt auf der Platte.
Will man die Platte wieder abhaengen geht man folgernder massen vor:

Festplatte unmounten:

umount /mnt/tmp

Un danach Crypto-Device schliessen:

cryptsetup luksClose /dev/mapper/backup

Jeder der jetzt auf die Daten der Festplatte zugreifen will, braucht die Passphrase bzw. das Keyfile.

Automation

Um diese komplette Prozedur nicht jedes mal aufs neue ausfuehren zu muessen, kann man das ganze auch automatisieren. Waere ja Unsinn, wenn man die ganzen Sachen von Hand ausfuehren muesste, wenn man die Moeglichkeiten hat dies mit ein paar Kniffen weitgehend zu automatisieren.

Vorerst lege ich noch einen Eintrag in der /etc/fstab fuer das Backupsystem an:

/dev/mapper/backup   /backup        ext3  noatime,noauto,noexec         0  0

Dann lege ich ebenfalls mit dd ein 256Bit grosses Keyfile an. Da bei mir das root-Filesystem verschluesselt ist, kann ich den Schluessel, der fuer die Backup-Festplatte gebraucht wird, auf diesem ablegen. Ist dies nicht der Fall, sollte aus Sicherheitsgruenden eher weiter mit einer Passphrase gearbeitet werden. Eine Alternative waere es, das Keyfile zu erstellen und nun mit GPG zu ver/entschluesseln. Darauf moechte ich allerdings nicht weiter eingehen. Also wird das Keyfile nun erstmal erstellt:

dd if=/dev/urandom of=/etc/crypto/backuphdd.key bs=256 count=1

Nun muss cryptsetup-luks noch Bescheid wissen, dass sowohl die Passphrase als auch das Keyfile verwendet werden kann:

cryptsetup luksAddKey /dev/sdc1 /etc/crypto/backuphdd.key

War dies Erfolgreich schaut das ganze etwa so aus:

Enter any LUKS passphrase:                    
key slot 0 unlocked.
Command successful.

Jetzt kann mal testweise auf die Platte zugegriffen werden:

cryptsetup luksOpen /dev/sdb1 backup --key-file /etc/crypto/backuphdd.key

Und siehe da: "key slot 1 unlocked.". Es musste also keine Passphrase eingegeben werden. Somit ist schonmal der erste Schritt der Automation vollstaendig. Nun kann das Crypto-Device wieder ausgehaengt werden:

cryptsetup luksClose backup

Allerdings steht man nun vor einem Problem: Wechselnde Device-Nodes. Bei USB-Datentraegern unterscheiden sich, je nach Reihenfolge in der sie eingesteckt werden, die Devices ueber die man die Platte ansprechen kann. Zudem ist ja erwuenscht, dass beim Einstecken der Festplatte automatisch mit dem Keyfile das crypto-Device erstellt wird. Danach soll die Platte, ebenfalls automatisch, gemountet werden. Somit hat man nichts weiter zu tun als die Platte einzustecken und man kann sofort darauf zugreifen, obwohl sie komplett verschluesselt ist.

Alles was dazu gebraucht wird ist udev und eine Regel.

Also brauche ich, wie beim vorherigen Udev-Howto beschrieben, erstmal ein Identifikationsmerkmal mit dem ich die Festplatte von anderen unterscheiden kann:

udevinfo -a -p `udevinfo -q path -n /dev/sdc` | grep ATTRS{serial}
    ATTRS{serial}=="1234567898253894C400000123456789"
    ATTRS{serial}=="0000:00:1d.7"

Nun wird mit diesen Infos eine Udev-Regel erstellt. In meinem Fall lege ich dazu die Datei /etc/udev/rules.d/00.rules an.

ACTION=="add", BUS=="usb", ATTRS{serial}=="1234567898253894C400000123456789", KERNEL=="sd?1", NAME="%k", SYMLINK+="ext/backup", GROUP="storage", RUN+="/etc/crypto/scripts/backuphdd", ENV{ACTION}="add"

Mit diesen Regeln wird ein Symlink fuer die Festplatte auf /dev/ext/backup erstellt. Da man die Festplatte beim Einstecken im Normalfall einhaengen moechte, wird das Script /etc/crypto/scripts/backuphdd beim Einstecken gestartet. Dieses Script schaut folgendermassen aus:

Dieses Script pausiert kurz, legt dann das mit Hilfe des Keyfiles das Cryptodevice an und haengt die Platte am richtigen Punkt ein. Somit wird die Festplatte nun sofort beim Anstecken automatisiert eingehaengt. An diesem Punkt ist es auch kein Problem weitere Aktionen ins Script einzubinden. So koennte zum Beispiel nach dem Mounten auch automatisch ein Backup loslaufen.

Backupsystem

Fuer die eigentlichen Backups kommt bei mir rsnaphot zum Einsatz. Dies ist ein Perl-Script welches auf rsync basiert und in der Lage ist sowohl Vollbackups als auch inkrementelle Sicherungen auf Festplatten oder entfernte Rechner durchzufuehren. Zudem laesst es sich vernuenftig konfigurieren.

rsnapshot is a filesystem snapshot utility for making backups of local and remote systems. Using rsync and hard links, it is possible to keep multiple, full backups instantly available. The disk space required is just a little more than the space of one full backup, plus incrementals.

Installieren kann man das Ganze unter Arch Linux mit "pacman -S rsnapshot".

Ein ausfuehrliches Howto findet man auf der offiziellen Seite. Ich moechte hier eher auf die Automation in Verbindung mit der verschluesselten Festplatte eingehen. Hier werden die Optionen in der /etc/rsnapshot.conf festgelegt:

Hier muessen zwischen cmd_[pre|post]exec und dem eigentlichen Befehl TABs und keine Leerzeichen stehen, da rsnapshot seinen Dienst verweigert wenn letztere eingesetzt wurden. Im beschriebenen Fall wurde die Festplatte schon automatisch eingehaengt. Also kann man das preexec-Kommando auslassen. Im postexec-Kommando muss das Cryptodevice zuerst ausgehaengt und dann wieder geschlossen werden, vorrausgesetzt man will die Festplatte nach dem erfolgreichen Backup einfach wieder abziehen.

Nun ein finaler Testlauf:

[root@wopr:~]# rsnapshot hourly
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.

Nachdem das Backup also moeglichst automatisiert und sicher vonstatten geht, kann man nun seine wichtigen Daten regelmaessig sichern und ist in der Lage boesem Datenverlust vorzubeugen. Wer nun immer noch der Meinung ist, dass er kein Backup braucht, ist selbst schuld.

Weiterfuehrende Links:

• DM-Crypt im Gentoo-Wiki
• DM-Crypt im Ubuntuusers-Wiki
• Luks Website
• weiteres DM-Crypt Howto
• LUKS encrypted Root im Archwiki
• Erstellen der udev-Regeln
• rsnapshot howto

Wichtig:

Ich uebernehme keine Verantwortung fuer Datenverlust oder sonstige Verluste. Ihr solltet euch beim Durchfuehren dieses Howtos, insbesondere beim Loeschen und Formatieren absolut sicher sein was ihr tut. Vor allem solltet ihr genau pruefen, dass ihr das richtige Device verwendet und sich auf der Platte keine wichtigen Daten befinden!

Hilfestellung:

Ich habe das beschriebene Setup bei mir am Laufen und soweit funtioniert es auch. Einziges Manko: Wenn das Script ueber den Udev-Event aufgerufen wird, dauert es ca. 5min bis die Platte eingehaengt ist. Ruft man das Script von Hand auf, dauert es ein paar Sekunden. Vielleicht kann mir ja hier einer der Leser beim Debuggen helfen.

Eigentlich bin ich gerade beim Ueberarbeiten meines Artikels ueber die verschluesselte Backup-Festplatte aber da ich fuer weitgehende Automation ein festes Device brauche, schiebe ich hier etwas udev-Kram ein.
Mit udev ist es moeglich bestimmten Geraeten feste Devices zuzuweisen um diese fest ansprechen zu koennen. Bei USB- Festplatten und Sticks entscheidet zum Beispiel die Reihenfolge in der die Geraete eingeteckt wurde welches Device sie bekommen. So koennte die USB-Platte /dev/sda, /dev/sdb etc. sein.
Um einen Vorgang aber komplett zu automatisieren ist es notwendig ein festes Device zu kennen das man ansprechen kann. Soll so zum Beispiel ein Script die Festplatte automatisch mounten um ein Backup auszufuehren, sollte man das Script nicht jedes mal umschreiben muessen wenn sich das Device geaendert hat. Solche Regeln kann man mit udev recht einfach erstellen.
Um eine Regel zu erstellen, werden ein paar Infos zum Geraet gebraucht. Um es eindeutig identifizieren zu koennen wird eine ID gebraucht. Diese erhaellt man mit diesem Befehl:
udevinfo -a -p udevinfo -q path -n /dev/sdb | grep ATTRS{serial} ATTRS{serial}=="1234567898253894C400000123456789"
Wobei /dev/sdb das derzeitige Device der Festplatte ist. Die Seriennummer wurde absichtlich verfaelscht.
Weitere Infos, die man nutzen kann waeren zum Beispiel die Produktbezeichnung:
udevinfo -a -p udevinfo -q path -n /dev/sdb | grep ATTRS{product} ATTRS{product}=="USB TO IDE" ATTRS{product}=="EHCI Host Controller"
Ich nutze hier nur die Serial. Damit lassen sich nun lustige Regeln erstellen.
Da ich das urspruengliche Device behalten will und nur einen Link darauf moechte, habe ich die Datei /etc/udev/rules.d/00.rules mit folgendem Inhalt erstellt:
# pfleidis own Rules BUS=="usb", ATTRS{serial}=="1234567898253894C400000123456789", KERNEL=="sd?1", NAME="%k", SYMLINK+="ext/usbhdd", GROUP="storage"
Hiermit sollte beim Einstecken ein Symlink /dev/ext/usbhdd erstellt werden, der auf das urspruengliche Device zeigt. Nun wird die Platte ausgesteckt und wieder eingesteckt und siehe da:
ls -la /dev/ext/usbhdd lrwxrwxrwx 1 root root 7 2007-05-30 20:53 /dev/ext/usbhdd -> ../sdb1
Nun kann man die USB-Festplatte dauerhaft mit /dev/ext/usbhdd ansprechen, ohne dass man das eigentliche Device kennen muss. Das macht auch die Automation fuer Backups etc. sehr viel einfacher, da man hier in Scripten mit einem festen Device arbeiten kann. Das selbe gillt nun natuerlich auch fuer die /etc/fstab. Spaeter werde ich dann noch Regeln erstellen um die Platte automatisch per Keyfile zu entschluesseln und einzuhaengen. Somit kann man diesen Vorgang komplett automatisieren.
Erklaerungen zu den Befehlen oder weiterfuehrende Optionen koennt ihr aus den folgenden Links und den Manpages entnehmen. Da ist das ganze etwas genauer erklaert.
Weiterfuehrende Links: http://de.gentoo-wiki.com/UdevRules http://wiki.archlinux.org/index.php/Udev http://www.linuxforen.de/forums/showthread.php?t=178406 http://wiki.archlinux.org/index.php/Usingudevtomapmultipleentriestoa_device

Achtung: Eine neuere Version dieses Artikel findet ihr hier

Das Backup wichtig ist und die vorhandenen Daten auf einem Computer prinzipiell immer den Wert einer zusaetzlichen Festplatte uebersteigen, sollte wohl den meisten klar sein.
Allerdings ist eine externe Festplatte auch ein Sicherheitsrisiko. Prinzipiell koennte jeder die Festplatte an seien PC anschliessen und haette Zugriff auf alle gespeicherten Daten. Dieses Problem laesst sich mit der Verschluesselug der betroffenen Daten loesen - wenn man bereit ist einen etwas geringeren Datendurchsatz in Kauf zu nehmen.
In der letzten Woche war ich nicht gerade untaetig. Ich habe zuerst mal meine Backup-Festplatte verschluesselt und das ganze dann in rsnapshot automatisiert.
Hier kommt mal ein kleines Howto dazu:
Vorbereitung
Zuerst muss im Kernel dmmod und dmcypt aktiviert sein. Dies ist bei den meisten Distributionen sowieso der Fall. Bei einem selbst gebauten Kernel benoetigt man folgende Optionen:

Device Drivers ---> Multi-device support (RAID and LVM) ---> [*] Multiple devices driver support (RAID and LVM) <> RAID support <M> Device mapper support <M> Crypt target support
Cryptographic options ---> --- Cryptographic API <M> SHA256 digest algorithm <M> Blowfish cipher algorithm <M> AES cipher algorithms (i586)
Zusaetzlich wird noch cryptsetup-LUKS benoetigt.
Danach werden die Daten auf der Festplatte zerstoert:
dd if=/dev/urandom of=/dev/sdc1
oder wer es schneller und dafuer etwas unsicherer will:
dd if=/dev/zero of=/dev/sdc1
/dev/sdc1 ist hierbei das Device der verwendeten Festplatte. Bei ersten Befehl wird die Festplatte oder Partition mit Zufallswerten ueberschrieben. Beim zweiten mit Nullen. Ich empfehle hierzu die Manpage von DD. Alternativ kann man auch mit dem Befehl shred arbeiten. Hier ist ein lesenswerter Artikel dazu.
Verschluesseln
Ist die Festplatte sauber, kann man mit sie cryptsetup formatieren:
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sdc1
Hiermit wird eine AES-Verschluesselung, SHA256 Hashes, ESSIV in Verbindung mit einem 256-Bit Schluessel verwendet.
Die Option "-s" gibt die Laenge des Schluessels an und die Option "-y" fordert den User auf eine Passphrase zu waehlen. Alternativ kann man mit "-d" auch ein Keyfile statt der Passphrase verwenden.
Weitere Optionen findet man in der Manpage.
Nun legt man sein Crypto-Device an:
cryptsetup luksOpen /dev/sdc1 backup
An dieser Stelle wird man nach der Passphrase gefragt, die man beim Formatieren eingegeben hat. Verwendet man ein Keyfile, muss man dieses ebenfalls mit "--key-file" angeben.
Der Befehl legt ein neues Device unter /dev/mapper an. In unserem Fall /dev/mapper/backup. Dieses kann man nun wie ein normales Blockdevice formatieren, mounten und beschreiben. Die Ver- und Entschluesselung laeuft transparent im Hintergrund ab.
Formatieren: mkfs.ext3 /dev/mapper/backup
Mounten: mount -t ext3 /dev/mapper/backup /mnt/tmp
Alle Daten die man nun in /mnt/tmp speichert, landen verschluesselt auf der Platte.
Will man die Platte wieder abhaengen geht man folgernder massen vor:
Festplatte unmounten: umount /mnt/tmp
Un danach Crypto-Device schliessen: cryptsetup luksClose /dev/mapper/backup
Jeder der jetzt auf die Daten der Festplatte zugreifen will, braucht die Passphrase bzw. das Keyfile.
Automation
Um diese komplette Prozedur nicht jedes mal aufs neue ausfuehren zu muessen, kann man das ganze auch automatisieren. Zuerst lege ich einen Eintrag in der /etc/fstab an:
/dev/mapper/backup /backup ext3 noatime,data=ordered,noauto,noexec 0 0
Danach kommen die Optionen in der /etc/rsnapshot.conf:

# cmdpostexec /bin/umount /backup && /bin/sleep 1 && /bin/cryptsetup luksClose backup
Hier muessen zwischen cmd[pre|post]exec und dem eigentlichen Befehl TABs und keine Leerzeichen stehen, da rsnapshot seinen Dienst verweigert wenn letztere dort stehen.
Nun ein finaler Testlauf:

[root@wopr:~]# rsnapshot hourly Enter LUKS passphrase: key slot 0 unlocked. Command successful.

Weiterfuehrende Links:

• DM-Crypt im Gentoo-Wiki
• DM-Crypt im Ubuntuusers-Wiki
• Luks Website
• weiteres DM-Crypt Howto

Aus diesem Thread sind ein paar interessante Funktionen und Lösungsvorschläge zur sicheren und Komfortablen Verwendung von OpenSSH hervorgegangen.

Zuerst kann man in der ~/.ssh/config Optionen fuer bestimmte Server definieren:

Host Foo
  HostName foo.domain.org
  User foobar
  Port 2222
Host Bar
  HostName bar.otherdomain.org
  User baron
  Port 3333
  ForwardAgent yes
  IdentityFile ~/.ssh/id_bar

Weitere Optionen gibt es hier oder mit "man ssh_config"

Nun kann man mit "ssh Foo" oder "ssh Bar" direkt die Verbindung aufbauen ohne fuer jeden die kompletten Optionen angeben zu müssen. Wenn man per SSH auf vielen unterschiedlichen Rechnern unterwegs ist, wird man diese Funktionalität zu schätzen lernen.

Um dies per Autovervollständigung in der ZSH zu nutzen, genügt folgendes in der Config:

hosts=(`cat $HOME/.ssh/config | egrep '^Host.*' | sed "s/^Host[ ]*\(.*\)$/\1/"`)
zstyle '*' hosts $hosts

Um die Vorzüge von OpenSSH voll auszunutzen, sollte man mit Public-Keys arbeiten und den passenden Private-Key mit einer Passphrease sichern. Wie das geht, kann man hier nachlesen.

Damit man die Passphrase nicht bei jeder SSH-Session neu eingeben muss, ist der Key-Agent zu empfehlen. Ein kleines Script, dass automatisiert den Key-Agent startet funktioniert auch super:

function prepare_ssh {
  if [[ -z $SSH_AUTH_SOCK ]]; then
    eval `ssh-agent`
  fi
  NEEDEDID=`cat ~/.ssh/id_rsa.pub | cut -d' ' -f1-2`
  HAVEID=`ssh-add -L | cut -d' ' -f1-2`
  echo "$HAVEID" | grep "$NEEDEDID" > /dev/null
  if [[ ! $? -eq 0 ]];then
    ssh-add
  fi
  unset NEEDEDID
  unset HAVEID
}

Nun kann man mit "prepare_ssh" den Key-Agent starten und muss nur noch beim Starten des Scripts die Passphrase eingeben.

Zum Schluss muessen wir noch dem Server beibringen, dass er unser Keyfile akzeptieren soll. Normalerweise verwendet man hierzu den Befehl ssh-copy-id. Aug Systemen, auf denen dieser Befehl nicht verfügbar ist, gibt ist hier ein Script, welches diese Funktionalität nachrüstet:

function putsshkey {
  cat ~/.ssh/id_rsa.pub | ssh $1 "mkdir -p ~/.ssh; \
  chmod 700 ~/.ssh; \
  cat - >>~/.ssh/authorized_keys; \
  chmod 600 ~/.ssh/authorized_keys"
}

Hiermit kann man seinen Public-Key mit "putsshkey user@host" einfach übertragen.

Ich arbeite hier mit einem RSA-Key. Falls ein DSA-Key verwendet wird, sollte man den Dateinamen anpassen. Also ~/.ssh/id_rsa.pub duch ~/.ssh/id_dsa.pub ersetzen.

Wenn man mit grep passende Ausdruecke farbig markieren will, kann man das einfach mit einem Alias erledigen:
alias grep='grep --color=auto'
Die Ausgabe sieht dann ungefaehr so aus:

Wem das Rot nicht gefaellt, der kann mir "export GREPCOLOR=31" das ganze z.B. Gruen faerben. Andere Farbcodes kann man auch mal ausprobieren.
Ein anderer sinnvoller Alias waere die selbe Option fuer ls.
alias ls='ls --color=auto'

Hier ist deutlich zu sehen, dass normale Dateien, Ordner und die eine ausfuehrbare Datei in anderen Farben dargestellt werden. Will man diese Farben aendern, hilft einem ein "man dircolors" weiter. In /etc/DIRCOLORS liegt die Konfiguration dafuer.
Fabiges highlighting bei vim ist mit ":syntax on" wohl recht bekannt. Bei less bekommt man dies mit der Option "-r" hin:
alias less='less -r'

Wer diese Aliase und Optionen dauerhaft uebernehmen will, benutzt die Konfigurationsdatei der Shell dafuer. Also die ".zshrc", ".bashrc" oder ".bashprofile". Man kann das ganze natuerlich auch in andere Dateien auslagern und diese in den Konfigurationsdateien laden:
# Aliases if [ -f ~/.zsh/aliases ]; then source ~/.zsh/aliases else print "Note: ~/.zsh/aliases is unavailable." fi
Oli hatte in den Kommentaren noch den Vorschlag mit man und most. Das ganze funktioniert super:
Mit alias man=’man -P most’ kann man die man-Pages auch kolorisieren. Most muß man zumindest bei FreeBSD installieren via portinstall most. Unter Linux installiert man das ganze mit dem entsprechenden Paketmanager.
man=’man -P most’
Also ich fuer meinen Teil finde highlighting auch bei der Arbeit mit der Shell sehr sinnvoll, da es einem hilft den Ueberblick zu behalten.
Anmerkung: Dies gillt nur fuer die GNU Versionen der Programme ls, grep und less. Diese Aliase werden mit anderen Derivaten dieser Tools nicht funktionieren. Vielen Dank an Doomshammer fuer den Hinweis.

Da nun allenorts der Kontrollwahn losbricht, und mich das wie gesagt aufregt, habe ich nun beschlossen ein kleines Howto ueber die Verwendung des freien Onion Routing Dienstes TOR in Verbindung mit Instant Messaging und anderen Anwendungen zu schreiben.

Was TOR ist, klaert der erste Satz im Wikipedia-Eintrag

Tor ist ein anonymisierendes Netzwerk für TCP-Verbindungen. Es anonymisiert Web-Browsing, Instant Messaging, IRC, SSH, E-Mail, P2P und mehr. Damit soll der Nutzer vor der Analyse seines Datenverkehrs geschützt werden.

Also kommen wir zu einer Basisinstallation unter unixartigen Systemen. Ich gehe hier nur auf Debian, Archlinux und die Installation ueber den Quellcode ein.

Die Pakete fuer Windows, MacOS und die gaengigsten Linux-Distributionen gibt es hier. Wenn die eigene Distribution nicht dabei sein sollte, ist selbstverstaendlich auch der Quellcode zum Selbstkompilieren verfuegbar. Allgemein kann man sagen, dass wie so oft mit dem bekannten Dreisatz "./configure && make && make install" installiert wird.

Will man das ganze auf ArchLinux laufen lassen, genuegt ein "pacman -S tor" um TOR incl. einer passenden Grundkonfiguration zu installieren. Bei Debian genuegt ein "apt-get install tor".

Diejenigen, die sich TOR selbst kompiliert haben, sollten folgenden Anweisungen (als root) folgen:

Die eigentliche Konfiguration ist denkbar einfach: Man muss nur die Konfigurationsdatei in "/usr/local/etc/tor/torrc" erstellen. Es wird eine Beispieldatei, die fuer den lokalen Betrieb vorkonfiguriert ist, mitgeliefert. Sie liegt per Default in "/usr/local/etc/tor/torrc.sample". Diese Datei kann man einfach kopieren:

cp /usr/local/etc/tor/torrc.sample /usr/local/etc/tor/torrc

Bei Debian und Archlinux liegen die Konfigurationsdateien in "/etc/tor" und bei der Installation via Quellcode wie bereits gesagt in "/usr/local Somit waere nun die Grundkonfiguration fuer TOR abgeschlossen und kann als User mit dem Befehl "tor" gestartet werden. Bei vielen Distributionen werden zusaetzlich noch Start/Stop-Scripts mitgeliefert. Unter Debian und vielen anderen Distris ist dies unter "/etc/init.d/tor" zu finden. Bei Archlinux unter "/etc/rc.d/tor". Das ganze wird dann wie bei init-Scripten ueblich mit "/etc/init.d/tor start" gestartet mit stop angehalten und mit restart neugestartet.

TOR lauscht mit dieser Konfiguration nur lokal auf Port 9050. Fuer eine erweiterte Konfiguration sollte man sich mal die Dokumentation ansehen.

Da viele Anwendungen Domains nicht per SOCKS aufloesen koennen, wird noch Privoxy benoetigt. Dies ist notwendig, da man sonst ja DNS-Anfragen zurueck verfolgen koennte.

Die Installation sollte bei so ziemlich jeder Distribution reibungslos ueber das Paketmanagement laufen.
Als Beispiel waere unter Ubuntu/Debian "apt-get install privoxy" oder unter ArchLinux "pacman -S privoxy". Wie man das ganze auf dem Quellcode installiert erfaehrt man hier.

Die Konfiguration ist ebenfalls recht einfach und wird in meinem Fall in "/etc/privoxy/config" vorgenommen.
Zunaechst sollten wir das logging von Privoxy abschalten, da die Logfiles schnell sehr gross werden koennen. Dies geschieht, indem man folgende Zeile auskommentiert. Hiezu setzt man einfach eine Raute (#) vor folgende Zeilen.

jarfile jarfile in #jarfile jarfile

und

Im jarfile wuerden ansonsten abgefangene Cookies und im logfile die Zugriffe gespeichert.

Dann sollte Privoxy noch wissen, dass er die Anfragen an ihn gesendet werden, an TOR weiterleitet. Hierzu sollte man die folgende Zeile in die Konfigurationsdatei einfuegen:

forward-socks4a / localhost:9050 .

Somit waere auch privoxy fuer den lokalen Betrieb konfiguriert. Mit "/etc/[init.d oder rc.d]/privoxy start" kann man Privoxy nun starten. Privoxy lauscht per default auf Port 8118.

Was nun noch zu tun ist, ist folgendes: Man muss in der Anwendung, in der man TOR nutzen moechte den Proxy eintragen. Fuer Mozilla Firefox und Thunderbird gibt es dafuer eine Erweiterung namens Torbutton, die die Einstellungen vornimmt und mit der man auf Knopfdruck die Einstellungen aendern kann. Ebenfalls zu empfehlen waere hierzu die sehr coole Erweiterung Foxyproxy mit der es moeglich ist bestimmte Domains mittels Wildcards und Regulaeren Ausdruecken ueber TOR zu schicken.

Bei manueller Konfiguration sollte man Privoxy als HTTP/SSL-Proxy eintragen und TOR als Socks Proxy. Das ganze sollte dan ungefaehr so aussehen:

.

Um zu erfahren, ob man wirklich mit Tor unterwegs ist, kann man http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1 und http://www.proxydetect.com nutzen.

Da mir die Verbindung ueber TOR allerdings zum Surfen etwas zu langsam ist, nutze ich das ganze mittels Torbutton im Thunderbird und zum Chatten ueber Jabber.

Da mein Jabber-Client ebenfalls Domains nicht via SOCKS aufloesen kann, habe ich hier drei Workarounds parat, mit denen das ganze funktionieren sollte. Die genaue Konfiguration koennt ihr der Dokumentation entnehmen.

1. Wenn der Jabber-Server Verbindungen ueber Port 443(HTTPS) zulaesst, kann man die Verbindungen ueber Privoxy laufen lassen (also localhost:8118 als HTTP-Proxy)
2. Man kann die IP-Adresse des Jabber-Servers einmalig aufloesen und im Client eintragen. Hier wird dann TOR als SOCKS-Proxy eingetragen (also localhost:9050)
3. Man kann die Adressen lokal aufloesen, indem man sie manuell in die /etc/hosts eintraegt. Der Rest waere hier wie bei 2.

Fuer andere Anwendungen sollte man sich mal dieses Howto anschaun. Ist sehr hilfreich.

Weiteres:

Um Programme, die per Default keine Proxyunterstuetzung mitbringen, zu "torifizieren", eignet sich das mitgelieferte torify script ganz gut. Um eine SSH-Verbindung ueber TOR aufzubaun reicht ein

torify ssh user@host

Fuer *BSD gibts hier ein gutes Howto fuer trans-proxy-tor.

Ein weiteres nettes Zusatztool ist Vidalia. Dies ist ein grafisches Frontend fuer TOR. So siehts aus.

Fuer Verbesserungsvorschlaege und Tipps zu weiteren sinnvollen Anwendungen bin ich selbstverstaendlich offen.

Weiterfuehrende Links:

• TOR Website
• torify Howtoanderes TOR Howto
• Sicher und anonym im Internet mit Proxys
• Selber Zwiebeln - Anonymität selbst gemacht
• Howto: TOR unter Windows

Ein sehr praktsches Tool um Audio-CDs als Ogg-vorbis, mp3, FLAC etc. einzurippen ist grip. Eigentlich ist es nur ein Frontend fuer cdparanoia, lame, vorbis-tools und viele weitere.
Das Programm benoetigt die verwendeten Tools sowie ein paar Gnome-Libs und laesst sich bei meinem ArchLinux problemlos ueber das Paketmanagement installieren.
Die Hilfe und die Dokumentation taugen was und so dauert es nur ein paar Minuten, bis man loslegen kann seine (nicht kopiergeschuetzten) Audio-CDs einzulesen. Vor allem die Funktion anhand einer CDDB wie Freedb Songtitel, Name des Albums, Interpret und andere wichtige Informationen aus dem Netz zu laden und in Dateinamen und ID3-Tags einfliessen zu lassen, ist sehr praktisch.
Alles in allem ein sehr gutes Tool.
Ich habe hiermit darauf hingewiesen, dass es nicht erlaubt ist, den Kopierschutz von CDs zu umgehen. Falls das trotzdem jemand macht, kann ich nichts dafuer und entziehe mich hiermit jeglicher Verantwortung.

Da gewisse Menschen ja Probleme mit Online Werbung zu haben scheinen, hier mal eine kleine Zusammenfassung um Werbung beim Surfen zu vermeiden.

• Mozilla Firefox oder Seamonkey installieren
• Adblock Plus und Adblock Filterset.G Updater installieren
• Jetzt kann man sich noch zusaetzliche Filterlisten importieren
• Und wenn das immer noch nicht reicht: Regex lernen und Filter selbst definieren. Hier steht wie es geht.

Nachdem mein Notebook mal wieder defekt war, hatte ich folgendes Problem: Das MCAfee Teil auf dem Geschaeftsnotebook sperrt mir Port 6667 und ich habe keine Rechte dies zu aendern. Also ist keine Verbindung ins IRC moeglich.

Also was tun? Entweder auf cgi::irc oder einen Bouncer zurueckgreifen, der nicht auf Port 6667 laeuft.

Ich hatte zum Glueck ein paar Wochen davor einen Blog-Beitrag ueber shroudBNC gelesen und beschlossen diesen zu verwenden. Zum einen wegen der SSL-Unterstuetzung und zum anderen, weil es gleich ein schoenes Webinterface dazu gibt.

Die Installation ist denkbar einfach und wird in der README recht gut erklaert. Alternativ, kann man natuerlich dieses Howto verwenden.

Wer SSL-Unterstuetzung moechte, sollte sich vorher einen SSL-Key und ein Zertifikat generieren.

openssl genrsa -des3 -out sbnc.key 1024
openssl req -new -x509 -days 600 -key sbnc.key -out sbnc.crt

Fuer naehere Infos sollte man die README.ssl und die man-Page von openssl befragen.

Die globale Konfigurationsdatei liegt direkt im sbnc Verzeichnis und heisst sbnc.conf und die Konfigs der User liegen im Verzeichnis sbnc/users und lassen sich dort editieren.

Wer nun noch ein Webinterface moechte, kann dies mit Hilfe dieses Howtos tun.

Da ich gerade keinen ssl-faehigen IRC-Client zur Hand habe, konnte ich dieses Feature noch nicht testen, aber der Rest funktioniert prima.

Wer kennt das Problem nicht:

Man will sich ins Netz zu Hause einwaehlen um schnell irgendwas zu machen oder man will kurzzeitig Daten ueber eine verschluesselte Verbindung schicken. VPN ist dafuer meistens zu aufwendig und wird auch von manchen Firewalls nicht zugelasen. Da zumindest manche Firewalls (z.B. Uni, Schule ...) SSH zulassen, ist recht einfach moeglich, bestimmte Verbindungen ins Heimnetz oder auf andere Server ueber einen SSH Tunnel zu leiten.

Grundvorraussetzung: Man braucht am anderen Ende einen SSH Server. In meinem Fall verwende ich OpenSSH.

ssh user@server -L [lokaler Port]:[entfernter Host]:[entfernter Port]

Beispiel: Man will kurzzeitig Daten. die ueber eine unverschluesselte HTTP-Verbindung laufen, verschluesselt uebertragen:

ssh user@server -L 12345:localhost:80

In diesem Beispiel verbindet man sich ueber den SSH-Tunnel auf den Server und von dort aus auf localhost:80 (also auf den Webserver, der auf dem Host laeuft). Will man nun ueber den Tunnel auf den Server, verbindet man sich auf "localhost:12345" und somit laeuft die Verbindung ueber den Tunnel. Die "man-Page" von SSH ist hierbei wie immer sehr hilfreich. So ist ez z.B. noch mit der Option "-C" moeglich die Verbindung komprimieren um Traffic zu sparen.

Anmerkung: Ich uebernehme keine Verantwortung wenn jemand dieses kleine Howto dazu verwendet geblockte Protokolle durch eine Firmenfirewall zu tunneln und moechte hiermit anmerken, dass dies ein Verstoss gegen die Security Policy der Firma darstellt! Ich persoenlich bevorzuge die Verwendung von Tunneln zur kurzzeitigen Uebertragung kritischer Daten.

Ich weis nicht, ob das schon bekannt ist, aber mir ist ist beim Stoebern in der Firefox config der Eintrag "network.protocol-handler.app.*" aufgefallen. Nach etwas rumprobieren bin ich dann auf die Funktionsweise dieses Eintrags gekommen und konnte die Erkentnisse auch produktiv nutzen.
Also: Per default kann Firefox z.B. mit Links auf Protokolle wie irc:// oder magnet:// und auch feed:// nichts anfangen.
Wer das aendern will, sollte folgendermassen vorgehen:
Man oeffnet mit "about:config" in der Adressleiste die Firefox config Dann filtert man die Eintraege am besten nach "network.protocol." um das ganze uebersichtlicher zu machen
Hierbei sind 3 Eintraege von Bedeutung:

network.protocol-handler.app.[protocol] (String)
network.protocol-handler.external.[protocol] (Boolean)
network.protocol-handler.warn-external.[protocol] (Boolean)

Hierbei entspricht [protocol] dem Protokoll das angesprochen werden soll, also z.B. "irc". Ein gueltiger Eintrag wuede folgendermassen aussehen:
network.protocol-handler.app.irc
Nun zur Bedeutung. Beim ersten handelt es sich im einen String (eine Zeichenkette). Hier wird definiert welches Programm mit dem Protokoll verknuepft werden soll.
Beim zeiten handelt es sich um eine boolsche Variable die also nur die Werte "true" und "false" annehmen kann. Diese regelt, ob z.B. auf den Klick auf einen irc:// Link reagiert werden soll oder nicht. Wenn was passieren soll, sollte die Variable auf "true" stehen.
Der dritte Eintrag ist weniger wichtig, da er automatisch vom System aneglegt wird (sofern die anderen beiden korrekt gesetzt wurden). Er bestimmt ob der User gewarnt werden soll wenn er auf einen Link klickt, der ein externes Programm anspricht.

Der weitere Ablauf sollte nun eigentlich klar sein. Man legt mit Rechtsklick-->NEW die Eintraege an und probiert dann ob es funktioniert. Ob es letzendlich wirklich funktioniert, haengt davon ab, ob das verwendete Programm mit den Parametern klarkommt die ihm vom Firefox uebergeben werden.
Es ist so z.B. auch moeglich das Pogramm fuer die Verarbeitung von "mailto:" Links zu aendern. Hier muss man nur den Wert bei "app" aendern, da die Eintraege schon angelegt sind.
Soweit so gut, ich hoffe dass der Eintrag ein paar Leuten hilft.