»Wuala« (gesprochen »Voilà«), ein Kollege hatte mich bekehrt, mir hier einen Account zu holen und ich muss sagen, dass ich doch recht begeistert bin von dem Service. »Wuala« ist quasi eine Online-Festplatte, ähnlich wie »Dropbox«. Der Unterschied liegt aber in der Art, wie auf die Daten zugegriffen wird. Bei der »Dropbox« wird auf der Festplatte ein Ordner angelegt. Alles was dort rein kopiert wird, wird automatisch auf einen zentralen Server kopiert und zwischen diesen beiden Orten synchronisiert. Ich habe den Dienst damals hauptsächlich genutzt, um Dateien mit meinem Android-Smartphone auszutauschen. Mittlerweile hat »Wuala« diese Aufgabe übernommen. Anders als bei »Dropbox« wird hier direkt auf die Online-Festplatte zugegriffen. Gut es gibt für den schnelleren Zugriff auf diese Daten einen in der Größe einstellbaren Caching-Bereich auf der lokalen Festplatte, im Prinzip aber werden die Daten direkt online gespeichert. Laut FAQ verschlüsselt »Wuala«die Daten bereits im Client und lädt die Datei dann, gestückelt in Fragmente, an unterschiedliche Orte hoch. 1GB bekommt hier jeder zu Anfang, wer meinen Promocode nutzt startet mit 2GB. Im Internet sind weitere Codes erhältlich, mit denen man sein Kontingent nach der Anmeldung noch weiter erweitern kann (einfach mal googlen). Gibt man noch einen Bereich seiner Festplatte für andere Nutzer frei und hält den eigenen PC mind. 4 Std. am Tag online, so bekommt man anteilig noch weiteren Speicherplatz zugeordnet. Eine schöne Idee wie ich finde.

Jetzt aber zu dem eigentlichen Vorhaben. Was die Verschlüsselung der Daten angeht, so muss man dem vertrauen, was die Macher von »Wuala« auf ihrer Seite versprechen. Die Software ist leider Closed-Source. Und genau hier liegt das Vertrauensproblem. Annähernd private oder sogar vertrauliche Daten würde ich hier nicht ablegen. Jetzt ist der Speicherplatz aber nach einiger Zeit so weit gewachsen, dass man ihn durchaus auch für das Backup von Daten nutzen könnte. Also einfach noch eine eigene Verschlüsselungsebene implementieren hab ich mir gedacht. Hier gibt es sicher viele Möglichkeiten, wenn es aber noch einigermaßen performant sein soll, fällt z.B. »TrueCrypt« raus. Es muss irgendetwas her, was auf Dateibasis verschlüsselt. Unter »Ubuntu Linux« ist hier  »eCryptfs« zum Standard geworden, um z.B. das Home-Verzeichnis zu verschlüsseln. Ich hab es genutzt, um einen Bereich in meinem Home-Verzeichnis zu verschlüsseln, und die verschlüsselten Daten dann auf »Wuala« zu synchronisieren. Hierbei direkt auf dem »WualaDrive« zu arbeiten hat leider nicht funktioniert. Trotzdem ist es eine, wie ich finde, recht schöne Lösung.

Installation und Initialisierung von eCryptfs

Als erste schaffen wir die Grundvoraussetzungen. Unter »Ubuntu Linux« wird »eCryptfs« wie folgt installiert.

sudo apt-get install ecryptfs-utils keyutils

Wer nicht vor hat, »OpenSSL« und zusätzlich zu der Passphrase einen Key für die Verschlüsselung zu benutzen, kann die »keyutils« auch weglassen. In diesem einfachen Beispiel wird das Paket nicht benötigt.

Im Home-Verzeichnis werden nun die beiden für »eCryptfs« benötigten Verzeichnisse eingerichtet.

mkdir ~/.WualaDrive-Secret
mkdir ~/WualaDrive-Secret

Im ersteren Verzeichnis liegen später die verschlüsselten Daten, letzteres bietet Zugriff auf die selbigen. Wer »eCryptfs« bereits genutzt hat wird sich an dieser Stelle fragen, warum 2 verschiedene Verzeichnisse genutzt werden. Die Antwort ist einfach: Wir wollen sicher gehen, dass »Wuala« nicht versehentlich die unverschlüsselten Daten synchronisiert.

Nun wird die Verschlüsselung eingerichtet:

sudo mount -t ecryptfs ~/.WualaDrive-Secret ~/WualaDrive-Secret

Nun wird die Passphrase vergeben, also quasi das Passwort, mit dem die Daten verschlüsselt werden. Hier solltet ihr euch z.B. einen Satz ausdenken und diesen z.B. mit Sonderzeichen und Zahlen verfeinern. Wichtig aber ist, dass diese Passphrase bei jedem mounten des verschlüsselten Bereichs eingegeben werden muss. Die Komplexität sollte also in Abhängigkeit von der Wichtigkeit der Daten bestimmt werden.

Passphrase: [HIER DEINE PASSPHRASE EINGEBEN]

An dieser Stelle wird der Verschlüsselungsalgorithmus ausgewählt, »AES« ist hier eine gute Wahl.

Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded)
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
4) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
5) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]: [ENTER FUER AES]

Ebenfalls in Abhängigkeit von der Wichtigkeit der Daten wird hier die Keysize bestimmt. Wer hier glaub mehr ist mehr, findet in diesem Dokument möglicherweise eine wichtige Entscheidungshilfe (danke an j-zero an dieser Stelle). Wir wählen hier also 16 Bytes, sprich eine 128bit AES-Verschlüsselung.

Select key bytes:
1) 16
2) 32
3) 24
Selection [16]: [ENTER FUER 16 BYTES, SPRICH 128bit KEYSIZE]

Folgendes hab ich auch nicht verstanden, glaube aber es handelt sich hierbei um eine Textdatei, in der wir unsere Passphrases übergeben können. Unsicher, wollen wir nicht, also »n«.

Enable plaintext passthrough (y/n) [n]:

Sollen die Dateinamen ebenfalls mit verschlüsselt werden? Aber »ja«.

Enable filename encryption (y/n) [n]: y

Nun werden uns die Optionen angezeigt, mit denen das Verzeichnis gemountet wird. Die Signaturen bitte merken und ebenfalls die Optionen, solltet ihr hier von meinem Beispiel abgewichen sein.

Filename Encryption Key (FNEK) Signature [xxxxxxxxxxxxxxxx]:
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=xxxxxxxxxxxxxxxx
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=xxxxxxxxxxxxxxxx
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Bei dem ersten Mount bekommt ihr hier diese Warnung. Dies ist völlig normal, da die Verschlüsselung vorher ja noch nicht aktiv war. Wir wollen also mit den oben genannten Optionen weitermachen.

Would you like to proceed with the mount (yes/no)? : yes

Fertig, die Ausgabe von »mount« sollte nun folgendes mit ausgeben.

Nach dem Anlegen von ein paar Testdateien unter ~/WualaDrive-Secret/ sollten sich die Verzeichnisse wie folgt präsentieren.

 Synchronisierung mit Wuala

Die Synchronisierung ist unter »Wuala« recht schnell eingerichtet. Wie wollen hier natürlich nur den verschlüsselten Ordner hochladen.

• Wuala öffnen
• Im Menü “Ansicht” den Punkt  “Sync Überblick” auswählen oder einfach STRG+F9 drücken
• Rechts auf das grüne “+” (Neuen Sync-Ordner anlegen)
• “Lokaler Ordner” ist der versteckte Ordner (bei mir /home/carsten/.WualaDrive-Secret) . Unter Gnome mit STRG+H ggf. die Anzeige von versteckten Dateien aktivieren
• “Ordner in Wuala” wird automatisch generiert und kann so übernommen werden

Fertig, die Synchronisierung kann nun auf jeden beliebigen weiteren Linux-Rechner, auf dem »Wuala« im Einsatz ist, übernommen werden.

Mounten und unmounten von eCryptfs

Das Mounten kann im Grunde wieder jedesmal genauso durchgeführt werden, wie auch das Einrichten weiter oben beschrieben wurde. Um sich aber nicht jedesmal durch die vielen Abfragen kämpfen zu müssen, können diese Optionen bei dem Mount mit übergeben werden. Ihr erinnert euch und habt eure Optionen vorhin doch sicher notiert? Wenn ihr meine Optionen übernommen habt, müsst ihr nur die Signatur austauschen.

Um das Ganze etwas zu beschleunigen habe ich mir für das Mounten/unmounten folgendes Script angelegt.

Der Aufruf »mountSecret.sh« hängt das verschlüsselte Laufwerk ein, fragt ggf. zuerst nach dem Sudo-Passwort und hinterher nach der Passphrase. Um das Laufwerk hinterher wieder auszuhängen reicht der Aufruf »mountSecret.sh stop« oder »mountSecret.sh unmount«.

Nun wünsche ich viel Spaß mit »Wuala«. Wenn ihr noch keinen Account habt und euch anmelden wollt, nutzt, wie oben schon erwähnt, meinen Promocode. Ihr startet automatisch mit 2GB anstatt 1GB.

Mich nervt es eigentlich schon seit langem, doch in letzter Zeit kommt es immer häufiger vor, dass meine iPod/Radio-Kombination im Auto mit aktueller Musik nicht mehr klar kommt. Viele Tracks sind dermaßen übersteuert, dass ein Hören nicht mehr möglich macht. Die Anlage zu Hause kommt mit dem Pegel klar, daher habe ich es lange ignoriert, im Auto höre ich zumeist sowieso nur Radio.

Jetzt aber bin ich aber zufällig auf diesen sehr interessanten Artikel gestoßen. Er bestätigt meine Beobachtung und zeigt in einem YouTUBE-Video noch eindrucksvoll, was wir als Konsument hier eigentlich für einen Müll vorgesetzt bekommen. In dem Artikel ist eigentlich schon alles gesagt, so dass ich hier nicht weiter drauf eingehen möchte.

Wer trotz allem noch im Besitz übersteuerter Musik ist, findet in »MP3Gain« möglicherweise einen neuen Freund und glaubt mir, Ihr seid es. Mit »MP3Gain« können einzelne Tracks oder ganze Ordner per Knopfdruck auf z.B. 89,0dB normalisiert werden. Unglaublich, dass die meisten Tracks an die 100db herankommen (siehe Screenshot).

»AACGAIN« stellt ein Kommandozeilentool zur Verfügung um AAC-Dateien zu bearbeiten, »iGain« soll das Ganze in »iTunes« integrieren, wobei ich nicht weiß, ob das mit der aktuellen iTunes-Version noch immer funktioniert. Letztere beide Tools wurden von mir noch nicht getestet, Feedback hierzu ist wie immer natürlich gerne erwünscht

Vorsicht ist geboten, wenn versucht wird die Boot-Partition eines »Windows Server 2008« größer zu ziehen. Als ich heute auf einer frisch eingerichteten VM die Festplatte von 30 auf 80GB vergrößert hatte und die Partition mit dem »Acronis Disk Director 10« angepasst hatte, meldet sich der »Windows-Start-Manager« mit der Fehlermeldung:

Datei: \Windows\system32\winload.exe
Status: 0xc000025
Info: Der ausgewählte Eintrag konnte nicht geladen werden, da die Anwendung fehlt oder beschädigt ist.

Problem ist hierbei möglicherweise eine Signatur, die durch den Fremdeingriff zerstört wird. Ganz klar ist mir der technische Hintergrund hierbei aber noch nicht – weitere Informationen sind an dieser Stelle erwünscht, sollte sie jemand liefern können. Über die Windows-CD lässt sich dieses Problem glücklicherweise aber über die »Eingabeaufforderung« der »Computerreparaturoption« folgendemaßen beheben:

Nachzulesen ist das Problem ebenfalls in Matthew Cosier’s Blog. Weitere Details hierzu sind in den folgenden Screenshots zu erkennen:

[Show as slideshow]

Update 2010-01-14: Der gleiche Fehler unter Windows 7

Heute ist mir meine Windows 7 Sandbox zu klein geworden. Eine Vergrößerung der Boot-Partition, ebenfalls mit »Acronis Disk Director 10«, brachte unter »Windows Seven« das gleiche Problem. Auch hier aber hilft ein kurzes Booten der Installations-CD und die »Computerreparaturoption«, um das Problem in den Griff zu bekommen. Anders als bei dem »Windows Server 2008« aber erkennt die Reparatur direkt, dass ein Problem besteht und fragt, ob es behoben werden soll. Man spart sich also die Tipparbeit Ein Tipp von j-zero war die Nutzung von »GParted« für die Partitionsänderungen. Der nächste Versuch wird also mit Hilfer einer »Ubuntu Desktop CD« durchgeführt (hier ist »GParted« direkt aufrufbar). Sollte die kostenlose Software hier tatsächlich wieder einmal die Nase vorn haben?

Per »sa-update« wurde (ich glaube noch am 1.1.2010 selbst) ein entsprechendes Update veröffentlicht, welches die falsche RegEx ersetzt:

Alt:

Neu:

Wer einmal genau guckt sieht, dass wir uns nach diesem tollen »Patch« am 1.1.2020 wieder sprechen, sollten wir zu diesem Zeitpunkt noch die gleiche Technologie nutzen. Im Bugreport aber war zu lesen, dass nun ja 1 Jahrzehnt Zeit ist, das Problem endgültig zu fixen, wir sind gespannt.

Heise ist am 1.1.2010 noch von einem GMX-Problem ausgegangen, hatte dies in einem späteren Update aber korrigiert. Im Forum wurde mit Recht darauf hingewiesen, dass das im Nachhinein schlecht gewählte Topic viele Spamassassin-Nutzer nur durch Zufall auf den Artikel hat aufmerksam werden lassen.

Weiteres Problem unter Ubuntu- und Debian-Systemen

Ich persönlich hatte auf 2 Ubuntu Hardy-Systemen noch das Problem, dass die mit »sa-update« aktualisieren Regeln nicht aktiviert wurden. Grund hierfür scheint gewesen zu sein, dass Ubuntu (und dies betrifft natürlich genauso auch Debian-Systeme) unter /usr/share/spamassassin noch die Regeln vom Auslieferungszustand liegen hat. Diese können gefahrlos entfernt werden, vorher natürlich ein Backup anlegen. »sa-update« legt seine neuen Dateien unter /var/lib/spamassassin/3.002004 ab. In der Datei
/var/lib/spamassassin/3.002004/updates_spamassassin_org/72_active.cf
kann auch kontrolliert werden, ob die oben genannte RegEx erfolgreich aktualisiert wurde.

Wer „sa-update“ bis jetzt noch gar nicht konfiguriert hatte findet unter http://saupdates.openprotect.com/ ein gutes Howto.

Zugegeben war der Windows Server 2003 etwas in Vergessenheit geraten und sehr lange schon nicht mit Updates versorgt, ich kann also nicht sagen, welches hier schuld gewesen ist. Begründung und Lösung wird in diesem ebenfalls sehr alten Bug Report beschrieben. Kurz zusammengefasst liegt das Problem möglicherweise daran, dass bei der Abfrage eines Benutzers mehrere Referenzen zurückgeliefert werden. Umgangen werden kann dies, indem man etwas später erst in den Baum einsteigt, z.B. nur in der OU sucht, in der auch die Benutzer liegen:

Sollte dies nicht möglich sein, weil man z.B. in mehreren OUs suchen möchte oder muss, so kann man seine » AuthLDAPURL« auf den »Global Catalog« verlegen, hier werden die bösen Referenzen nicht mit zurückgeliefert. Ob der Port 3268 offen ist, verrät ein »nmap«, hier ein Auszug der normalen LDAP-Ports und der des »Global Catalog«:

Sind Port 3268 und 3269 nicht offen, so wird hier erklärt, wie der »Global Catalog« erstellt wird.

Tauscht man den Port 389 also einfach gegen 3268, so kann man wieder problemlos das gesamte Verzeichnis durchsuchen:

Für mich funktionieren beiden Lösungen, ich bleibe nun aber bei der Nutzung des »Global Catalog«.

Im aktuellen Entwicklerzweig bzw. in der zukünftigen Apache-Version (wohl aber erst in Apache 2.3?) scheint es hier über die Option »authldapmaxsubgroupdepth« aber endlich eine Möglichkeit zu geben, wie die Dokumentation zeigt. Ich hab meine Gruppenstruktur in diesem speziellen Fall jetzt erst einmal flach aufgebaut und werde die Option vielleicht später einmal testen. Sollte hier schon jemand Erfahrungen gemacht haben, bin ich über jeden kurzen Kommentar dankbar.

Wer einen 3. Monitor an sein System anschließen möchte, musste bisher zu teuren Grafikkarten mit entsprechenden Ausgängen greifen oder, wenn Monitor 2 und 3 nicht simultan benötigt werden, einen VGA- bzw. DVI-Umschalter benutzen. Ersteres hatte ich liegen und benutzte es bisher, um von meinem 2. Monitor auf den LCD-TV umzuschalten, wenn dort Inhalte wiedergegeben werden sollten. Die DVI-Variante ist in der Anschaffung nicht ganz günstig, so dass ich aus diesem Grund bisher nicht umgerüstet habe.

Jetzt ist mir zum Testen ein »USB 2.0 to DVI – VGA – HDMI Adapter« von der Firma DeLOCK in die Hände gefallen, den ich heute auch direkt einmal ausprobieren musste. CD rein geschmissen, zur Auswahl stand ein Treiber in der Version 4.50 und 4.60. Neuer ist besser, also Version 4.60 installiert – aber was ist das? Mein Betriebssystem wird nicht unterstützt. Na gut, wer die RC von Windows 7 einsetzt, muss mit solchen Dingen natürlich rechnen. Auf der Webseite des Herstellers ist der neueste Treiber mit Version 2.51 gelabelt, immerhin steht aber auch hier geschrieben, dass Windows Vista unterstützt wird. Nachdem der Treiber die alte Version entfernt und sich selber im System verewigt hat, möchte er einen Neustart des Systems, na wenn es hilft doch gerne. Nach dem Reboot, als der Treiber initialisiert, wird ein kleines Fenster unten rechts im Systray eingeblendet: Ein Hinweis auf die Website http://www.displaylink.com/ auf der es aktualisierte Treiber zum Download geben soll. Muss ich erst die ältere(?) Treiberversion von der Hersteller-Website installieren, um diesen Hinweis zu bekommen? Aber tatsächlich gibt es dort die Download-Möglichkeit eines Windows 7-Treibers, zwar mit dem Vermerk, dass es sich hier noch um eine Alpha-Version handelt, aber genauso wünsch ich mir das doch. Einen Reboot später steht der neue Anschluss zur Verfügung, sogar performanter als erwartet. Selbst HD-Filme in 1080p lassen sich dort abspielen, einzig die Aero-Effekte von Windows hacken ein kleines bisschen.

Das Gerät ist für ca. EUR 80,- im Handel erhältlich und wird mit einem Mini-USB-Kabel, einem DVI auf VGA- und einem DVI auf HDMI-Adapter ausgeliefert. Ich bin zufrieden und überlege nun, ob ich mir ein Solches bestelle, das Testgerät steht mir leider nur noch über das Wochenende zur Verfügung.

[Show as slideshow]

Auf einem »Hosteurope VPS Linux L 2.0« habe ich in den letzten Wochen begonnen, einen Shop auf Basis von »Magento Commerce« (Version 1.3.2.2) einzurichten. Ab und zu stolpert man hier über Erfahrungsberichte: Um Magento ernsthaft nutzen zu können, muß ein dedizierter Server eingesetzt werden. Beim Einrichten hab’ ich mich hier tatsächlich auch schon über die bis zu 10 Sekunden langen Ladezeiten geärgert. Ganz egal, ob man sich im Backend befindet oder das Frontend laden lässt, der auch schon etwas ältere VPS ist einfach zu schwach. Ausgestattet ist der »Hosteurope VPS Linux L 2.0« mit 2x Intel Pentium 4 2.80GHz und bescheidenen 256MB zugesichertem RAM, dynamisch, so sagt es Hosteurope, kann etwas mehr zugeordnet werden.

Gestern nun habe ich ein Upgrade auf den »Hosteurope Virtual Server Linux XL 3.0« durchgeführt. Hier werkeln 2 Intel Pentium D 3.00GHz mit 512MB zugesichertem RAM. Der Pentium D hat mich gestern schon enttäuscht gucken lassen, ein XEON hätte mich hier wohl eher freudig gestimmt. Da ein Versionsupgrade bei Hosteurope über eine Parallelbereitstellung realisiert wird (nagelneuer Server, neue IP, nach 7 Tagen wird der alte Server dann abgeschaltet, siehe Hosteurope-FAQ), kann ich die beiden VMs nun direkt gegenüberstellen. Auf die verschienen Systeme, Kernel, Apache- und PHP-Versionen möchte ich jetzt nicht eingehen, das sprengt hier den Rahmen.

Gestestet wurde über den Apache-internen Benchmark namens »ab«, hier wurde jeweils lokal, auf der jeweiligen VM, folgender Aufruf getätigt:

10 Anfragen, 2 zur gleichen Zeit. Aufgerufen wird eine Übersichtsseite mit 5 Produkten, das Caching für Magento ist noch komplett ausgeschaltet. Auf dem alten VPS benötigten die Anfragen insgesamt 56 Sekunden (Ø 10s/Seite), der Neue schafft die Anfragen in 19,5 Sekunden (Ø 4s/Seite). Die exakten Testergebnisse sind in den Screenshots zu erkennen. Dies ist erst einmal akzeptabel, nach oben bietet Hosteurope noch eine weitere Ausbaustufe (XXL), das Magento Caching dürfte auch noch etwas Besserung bringen. Bei stark frequentierten Magento-Shops wird vermutlich wirklich ein dedizierter Server nötig.

[Show as slideshow]

Zeile 1 macht einen Redirect, schreibt die URI im Webbrowser direkt um, wenn kein Slash hinter den Aufruf gehängt wird.
In Zeile 2 dann der eigentliche »ProxyPass«-Ersatz, zu erkennen an dem Flag »[P]«. Hier werden alle Aufrufe von »/unterordner« an den zuständigen, internen Webserver weitergeleitet.
Der »ProxyPassReverse« in Zeile 3 kann meiner Erkenntnis nach nicht durch »mod_rewrite« ersetzt werden. Er wird benötigt um den HTTP-Header bei 3xx-Statuscodes entsprechend anzupassen. Dies kommt zwar nur sehr selten vor, ich setze diesen Eintrag der Vollständigkeit halber aber für jede Weiterleitung.