Als kleine, zuverlässige und einfach zu konfigurierende Firewall die auch einem schon betagten Rechner nochmal zu Amt und Würde verhilft, ist IPFire eine gute Wahl.

Leider hat die auf den ersten Blick einfache Konfiguration den Nachteil, daß manche Szenarien über die Oberfläche nicht abgebildet werden können, weil für die gewünschte Funktionalität keine entsprechenden Konfigurationsdialoge zur Verfügung stehen.

In diesem Fall können die Einstellungen der Firewall aber mittels SSH-Zugang in der Datei “/etc/sysconfig/firewall.local” vorgenommen werden.

Zugriff von rot auf grün anhand der IP-Adressen

Den Zugriff eines Rechners aus dem roten Netz auf einen Rechner im grünen Netz kann normalerweise mittels Portforwarding erledigt werden. In der Oberfläche ist es allerdings nicht möglich, den Quell- oder Zielport für verschiedene IP-Adressen mehrfach zu vergeben, so daß das Szenario, daß ein Rechner aus dem roten Netz auf den gleichen Port auf mehreren Rechnern im grünen Netz zugreifen darf, nicht konfigurierbar ist.

Die Zuweisung über die “firewall.local” kann wie folgt vorgenommen werden

/sbin/iptables -A CUSTOMFORWARD -s <Quell-IP> -d <Ziel-IP> -i red0 -o green0 -j ACCEPT

eine Einschränkung der Ports ist über die Parameter “–sport <Quell-Port(s)>” sowie “–dport <Ziel-Port(s)” möglich, bei denen als Werte entweder ein einzelner Port oder ein Bereich angegeben werden kann.

Nach außen ursprüngliche IP beibehalten

Da NAT ein integraler Bestandteil von IPFire ist, kann diese(s) auch nicht abgeschaltet werden. Es besteht aber die Möglichkeit, einem Paket nach Behandlung durch IPFire wieder seine ursprüngliche Quell-IP zuzuweisen:

/sbin/iptables -t nat -I CUSTOMPOSTROUTING -p all -s <Quell-IP> -j SNAT --to-source <Quell-IP>

Für jede Regel, die im Bereich “start” der “firewall.local” eingetragen wird, sollte eine zugehörige Lösch-Regel im Bereich “stop” hinterlegt werdem.

Einen guten Einstieg in das Thema “iptables” bietet das “IPTABLES HOWTO” von Dirk Bender, etwas ausführlicher ist “Linux Firewalls Using iptables” von Linux Home Networking.

Keine Ahnung, mit welchen Einstellungen die Entwickler bei Mozilla arbeiten, unter einem Standard-Windows 7 sieht Thunderbird 5 jedenfalls nicht sehr benutzbar aus:

Ähnlich wie bei Firefox lässt sich aber das Aussehen mittels der Datei “userChrome.css” modifizieren (ggf. muß die Datei erst angelegt werden), die im “chrome”-Ordner innerhalb des Thunderbird-Profils abgelegt wird. Durch Hinzufügen von

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

toolbox {
 background-color: #eef3fa !important;
}

.tabmail-strip {
 background-color: #eef3fa !important;
}

#folderTree {
 background-color: #ffffff !important;
}

ändert sich z.B. das Aussehen wie folgt:

Der letzte Eintrag “#folderTree” sorgt dafür, daß der Hintergrund der Ordnerhierarchie wieder in reinem Weiß erstrahlt.

Ein guter Einstieg in Modifikationen mittels “userChrome.css” findet sich in der Knowledge Base von Mozillazine.

Nachtrag 12.Juli 2011:

Je nach Profil kann es sein, daß nicht nur die Datei “userChrome.css” angelegt werden muß, sondern auch der sie enthaltende “chrome”-Ordner. Dieser wird im Hauptordner des Thunderbird-Profils benötigt, also in

%APPDATA%\Thunderbird\Profiles\<Profilname>\

Nachtrag 27.Juli 2011:

Mit ein paar zusätzlichen Zeilen ist auch eine Hervorhebung des Drag & Drop-Zielordners möglich.

Ein aus dem “non-free” repository nachinstalliertes SUN Java Runtime Environment lief bis auf eine ärgerliche Ausname wie gewünscht: bei jedem Versuch der Netzwerk-Kommunikation scheiterte Java mit der Fehlermeldung “Das Netzwerk ist nicht erreichbar”, obwohl alle anderen Applikationen wie erwartet kommunizieren durften.

Die Behebung des Fehlers findet sich in einem Artikel auf debianforum.de - in der Datei “/etc/sysctl.d/bindv6only.conf” ist die Konfigurationseinstellung

net.ipv6.bindv6only

vom standardmäßigen Wert “1” auf “0” zu ändern, dann kommuniziert auch Java.

(Nicht nur) Beim Arbeiten mit localhost kann es nerven, wenn Firefox meint, der URL “http://localhost” noch ein paar zusätzliche Buchstaben verpassen zu müssen und beharrlich versucht, die Adresse “http://www.localhost.com” zu öffnen.

In den Optionen ist kein Schalter vorgesehen, mit dem die automatische Ergänzung abgeschaltet werden könnte, mittels der erweiterten Einstellungen unter “about:config” lässt sich das unerwünschte Verhalten aber mit einem einfachen Doppelklick auf die Einstellung

browser.fixup.alternate.enabled

unterbinden - oder wahlweise mittels der anderen “browser.fixup.alternate”-Parameter in sinnvollere Bahnen lenken.

Sollen Exif-Daten vorhandener Bild-Dateien geändert werden, so ist - wie so oft im adminstrativen Alltag - PERL ein hilfreiches Werkzeug.

Folgendes Skript schnappt sich alle “JPG”-Dateien im aktuellen Verzeichnis und setzt deren Aufnahmedatum auf den 01.09.2004 9:22:57 Uhr.

use strict;
use warnings;
use Image::ExifTool;

my (@files, $file, $image, $success);

opendir(DIR, '.');
@files = readdir(DIR);
closedir(DIR);

foreach $file (@files) {

 next if $file !~ /\.jpg$/i;

 print "processing file '$file'\n";

 my $image = new Image::ExifTool;

 $image->SetNewValue('DateTimeOriginal', '2004:09:01 09:22:57');
 $success = $image->WriteInfo($file, '_' . $file);

 die 'Error: \'' . $image->GetValue('Error') . '\'' if ! $success;
}

Die komplette Doku zu Image::ExifTool findet sich im CPAN. Wer mutig ist (oder ein Backup hat), kann den zweiten Parameter bei WriteInfo auch weglassen - die Quelldatei wird dann direkt überschrieben.