Marc Richter's Weblog

Archiv für die Kategorie „Technik“

So wurde mein Blog letztens von einem guten Kumpel bezeichnet – und recht hat der Sack auch noch
Ich gelobe (wie immer ;D ) Besserung und fange mal mit einem technischen Artikel an. Diese kommen hier in letzter Zeit viel zu kurz und ich neige immer mehr dazu, alles im Kopf haben zu wollen, da ich mir die Zeit zum aufschreiben einfach nicht nehme. Stattdessen landet hier nur so ein privat-Blödsinn … Ich erkläre hiermit das Ziel, diesem Blog wieder einen Schwerpunkt auf die IT und technische Hintergründe zu legen – bin selbst gespannt …

Beginnen möchte ich mit einem super geilen Tipp.

Ich verwende, wie wohl die meisten Linuxer auf der Welt auch, seit Jahr und Tag GNU bzip2 und GNU gzip zur Kompression von Daten auf der Shell. Was mir jedoch heute das erste Mal aufgefallen ist, ist das diese beiden Programme nur einen einzigen Core aktueller Multi-Core CPUs zu 100% auslasten, und die restlichen brach liegen. Gerade bei der Kompression von Daten dreht sich alles um die Leistungsfähigkeit des Prozessors – eine der wenigen Ausnahmen in meinem Arbeitsalltag, wo die Festplatten mal nicht der Flaschenhals sind. Von daher ist diese Verschwendung in der heutigen Okta-Core – Zeit schon ziemlich maßgeblich für manche Vorgänge, wie z.B. beim (De-)Komprimieren von MySQL Dumps, ISO Images von DVDs, Logfilerotation, etc.

Ich habe also etwas recherchiert und bin zunächst auf pbzip2 gestoßen; einem Re-Write des GNU bzip2 Programmes, welches Multicores unterstützt.
Hiermit hatte ich aber zunächst nur eine Lösung für bzip2, also suchte ich weiter.

Schließlich stieß ich auf einen guten, alten Bekannten, den in seiner GUI – Form sicherlich auch Nicht-Linuxer kennen: 7zip ! Kurzbeschreibung: 7zip ist ein freies Programm (GNU LGPL) für nahezu alle gängigen Betriebssysteme, welches sowohl nahezu alle gängigen Archivformate und Kompressionsalgorithmen beherrscht, sowie auch ein eigenes Format mitsamt Algorithmus mit sich bringt, welches in vielen Situationen sogar eine höhere Kompressionsrate erreicht als bzip2 (durchschnittlich etwa 50-70% höher als ZIP!).
Dieses beherrscht nicht nur die Archivformate 7z, zip, gzip, bzip2, tar und rar (beim reinen entpacken unterstützt es zudem sogar noch: ARJ, CAB, CHM, CPIO, CramFS, DEB, DMG, FAT, HFS, ISO, LZH, LZMA, MBR, MSI, NSIS, NTFS, RAR, RPM, SquashFS, UDF, VHD, WIM, XAR und Z) , sondern auch Multi-Threading und ist somit die perfekte Lösung für Multicores. Es liegt beispielsweise im Ubuntu Lucid Lynx (10.04) Repository unter den Namen “p7zip”, “p7zip-full” und “p7zip-rar” vor und kann somit ganz normal und einfach installiert werden.

Ich habe damit heute mal einen schnellen Test gemacht. Diese zahlen stammen von einem Quad-Core System, auf welchem neben diesen Tests auch meine ganz normale Arbeitsumgebung ausgeführt wird, also bitte dizzed mich nicht wegen “lamer”Ergebnisse

Testbeschreibung

Ich habe das ISO Image kubuntu-9.10-alternate-i386.iso von einem Kubuntu – Mirror herunter geladen. Dieses werde ich mit dem bzip2 Algorithmus zunächst mit GNU bzip2 und 7zip auf höchster Kompressionsstufe (9) komprimieren. Diesen Prozess messe ich mit dem Linux-Tool “time”. Anschließend entpacke ich beide Varianten mit GNU bzip2 und erzeuge für die Ergebnisse einen MD5 Hash, um die Kompatibilität mit der Refferenzimplementation sicher zu stellen.

Test mit GNU bzip2

root@archangel:~# time bzip2 ~mr/Downloads/ISO_Images/kubuntu-9.10-alternate-i386.iso -c -9 > bzip2.bz2

real    2m41.266s
user    2m29.250s
sys     0m1.400s

Test mit 7zip

root@archangel:~# time 7z a -tbzip2 -o. bzip2_7z.bz2 ~mr/Downloads/ISO_Images/kubuntu-9.10-alternate-i386.iso

7-Zip 9.04 beta  Copyright (c) 1999-2009 Igor Pavlov  2009-05-30
p7zip Version 9.04 (locale=de_DE.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)
Scanning

Creating archive bzip2_7z.bz2

Compressing  kubuntu-9.10-alternate-i386.iso

Everything is Ok

real    1m17.121s
user    4m6.090s
sys     0m1.420s

Auswertung

Ich habe dabei mit “htop -d 1″ die CPU Auslastung beobachtet: Bei GNU bzip2 wurde erwartungsgemäß nur einer der 4 Cores zu 100% ausgelastet. Mit 7zip tatsächlich alle 4!

Das Ergebnis dieser Kompressionen war nahezu identisch. Nur ca 2 kb (bei einer Eingangsgröße von rund 700 MB) Abweichung war feststellbar, was ich für vernachlässigbar halte. Die MD5 Sums der mit GNU bzip2 entpackten Archive war identisch; die GNU bzip2 Kompatibilität des durch 7zip erzeugten Archives ist also gegeben.

Wie die obigen Zahlen zeigen, war 7zip ziemlich genau doppelt so schnell, wie die GNU bzip2 Refferenzimplementation. Ich hätte zwar mehr erwartet, jedoch wird ziemlich viel für die Threadverwaltung aufgewendet werden müsen.

Dasselbe lässt sich nun natürlich auch mit GNU gzip erreichen – Zahlen spare ich mir mal. Das kann jeder selbst mal messen

Hallo zusammen!

… boah – so lange nichts geschrieben … peinlich! Egal, einfach ran an den Speck

Ich habe letztens erst eine interessante Entdeckung gemacht: Der Google Chrome – Browser installiert sich unter Windows standardmäßig in jedes einzelne Userprofil, statt einmalig global in den Programme – Ordner! Das bedeutet, das jeder User des PC rund 250 MB Speicherplatz nur für diesen Browser verschwendet. Das hört sich in der heutigen Zeit zwar wenig an, jedoch wird das ganze spätestens dann brisant, wenn der PC Teil einer Domäne ist und Roaming Profiles verwendet werden. Nicht nur das so 250 MB teuren Serverspeichers verschwendet werden (mal ganz abgesehen von dem ganzen unnützen Overhead für Backups und ähnliches), sondern es verlängert die Zeit zum ab- und anmelden enorm, ebenso, wie das gesamte Netzwerk mit diesem unnützen Traffic belastet wird.

Speicherverbrauch des Google Chrome Browsers im Userprofil

Seltsamerweise bekommt man auf so ziemlich jedem Wege nur diesen blöden Installer, der das ganze auf diese Art und Weise installiert. Umgehen kann man das ganze nur mit einem Trick: Man läd stattdessen die so genannte “Enterprise Edition” herunter, die als MSI – Paket angeboten wird und einem die Wahl über den Installationsort lässt. Diese kann hier kostenlos heruntergeladen werden.

Spart Speicherplatz und Euer Admin wird es Euch danken

Irgendwie sind wir Menschen ja schon bei Zeiten etwas komisch gestrickt: Wir wollen uns zum Beispiel ein neues Auto kaufen, sind uns den Vorzügen der Neuanschaffung völlig bewusst und wägen das Für und Wider dieser Entscheidung sorgfältig ab. Doch wenn wir uns schließlich zu diesem Schritt entschlossen haben und uns vom alten Wagen trennen sollen, werden wir sentimental und lassen uns von Emotionen plagen, die einem fast das Gefühl geben man gibt ein lieb gewonnenes Familienmitglied in fremde Hände, bzw. gibt ihm den Gnadenschuss. Vergessen sind plötzlich die letzten vierstelligen Rechnungen für Verschleißreparaturen; wir haben ein schlechtes Gewissen gegenüber einer Sache und empfinden sogar Trauer. Da hilft einem auch die Erkenntnis, wie unsinnig solche Gefühle sind, nicht wirklich weiter.

Ähnliches habe ich eben beim letzten einloggen in die alte “Zoosau” empfunden. zoosau.de war meine erste, eigene Domain. Ich habe sie seit 2003, also inzwischen über 7 Jahre. Zunächst lief sie ca. 2 oder 3 Jahre auf einem vServer von “Server4You”. Bereits für diesen Server bürgerte sich der Name “die Zoosau” ein. “Ich lad’s dir nachher auf die Zoosau!” – Solche und ähnliche Sätze machten dann im IRC Stammchannel und der Berufsschule die Runde. Dieser Name hat sich inzwischen sogar im professionellen Umfeld meiner Arbeitsstelle etabliert – jeder weiß was gemeint ist und keinem Stößt dieser Name mehr sauer auf.
Auf diesem vServer stieß ich jedoch sehr schnell an dessen Grenzen. Schließlich konnte man ja nichtmal einen neuen Kernel kompilieren, da dieser mit closed source – Patches versehen war um auf der Virtualisierungsplattform laufen zu können. Sofern man seinen Server ordnungsgemäß gewartet und aktualisiert hat, füllten die Updates auch schnell ca. 1/4 der gesamten Festplattenkapazität, da die zugrunde liegende Virtualisierungsplattform nur “originale” Dateien nicht von dem zur Verfügung stehenden Speicherplatz abgezogen hat. Kaum hat man ein Paket aktualisiert, war dieser Speicherplatz auf einmal “mehr” belegt. Hat ein Paket von 1 MB Größe also ein älteres von 1 MB Größe überschrieben und hatte man zuvor … sagen wir 100 MB frei, so hatte man nach diesem Update nur noch 99 MB frei. Klingt komisch, war aber so!
Seit ca. 2006 bis heute bestand also “die Zoosau” in der aktuellen Form eines Debian 4.0 Servers auf echter (wenn auch alter) Hardware. Was zunächst als reine Homepage-Maschine begonnen hat, hat sich auf diesem System schnell zu einer immer weiter wachsenden Spielwiese entwickelt, auf der ich ungeheuer viel gelernt habe. Jeden Tag kam ein wenig mehr zum Funktionsportfolio hinzu. Zu Mails, die per fetchmail auf den Server von meinen Freemail-Accounts geholt und gesammelt wurden, kamen schnell eigene Mailaccounts auf dem Server, die direkt angesteuert werden konnten. Zum lesen der Mails auf der Shell kamen schnell die Möglichkeiten diese per IMAP und Webmailer zu lesen. Ein Spamfilter, Datenbanken, Backupsysteme (dessen Konzept ich auf der Bacula Konferenz 2009 in Köln sogar als Gastredner präsentieren durfte (Präsentationsunterlagen Bacula Konferenz 2009 von Marc Richter fa. Marketing Factory Consulting GmbH – Punkt “Vorstellung der Lösung für extern gehostete (z.B. vServer) mit FTP – Backupspace”)), Monitoring der Last, Zugriffsstatistiken, etc. sollten folgen. Alle diese Themen konnte ich hier nicht nur nach 0815 – Schema “mal eben installieren” sondern konnte mir stets die Zeit lassen, diese Programme wirklich zu verstehen; sowohl was die Funktion, wie auch was die Bedienung und Implementation angeht.
Um es kurz zu machen: In diesem System steckt mein ganzes KnowHow und auch ein Teil Herzblut. Fast alles was ich heute kann, habe ich hier gelernt. Zudem stellt es für mich so eine Art IT-Utopia dar, welches mir stets zum Vorbild und als Maßstab für weitere Systeme gereicht. In den nunmehr über 4 Jahren Dauerbetrieb komme ich (ohne die jüngsten Migrations-Downtimes) auf weniger als 2 Stunden kummulierte Ausfallzeit, trotz stetigem basteln im Hintergrund.

Inzwischen laufen insgesamt 8 produktive Seiten auf diesem Server. Mit allen Metadiensten wie Statistiken, Backups, etc. lief das System jedoch schon lange auf einer durchschnittlichen Load von ca. 0,8 . Zudem boten neue Server-Pakete für denselben Preis schlichtweg inzwischen … mehr: mehr Platz, mehr Inklusivtraffic, mehrere CPU-Kerne, schnellere CPU-Kerne, mehr RAM, etc. Last but not Least ist Debian 4.0 stable ja nun nicht mehr der jüngste Kandidat auf dem Markt, so das ich immer öfter, um an aktuellere Versionen einer Software zu kommen, händisch kompilieren musste. Und mit jedem Paket, welches ich so jenseits des Paketmanagements warten musste, wuchs der Aufwand, da man ja trotzdem auf aktuelle Sicherheitsprobleme Rücksicht nehmen muss (jajaja, man kann ja auch das testing oder unstable – Release nehmen oder gar mischen. Habe ich aber nie gute Erfahrungen mit gemacht).

Als ich mich eben um ca. 19.43 Uhr auf der alten Zoosau eingelogged habe, hatte ich schon ein komisches Gefühl und schlechtes Gewissen, da ich wusste, das ich das System, was mir jahrelang treue Dienste geleistet hat und auf dem ich eine Menge Spaß hatte, gleich binnen Sekunden zerstören werde.
Einmal eingelogged, habe ich zunächst alle persönlichen Daten gelöscht. Anschließend habe ich um 19.47 Uhr folgende “Schleife-of-Death” losgetreten:

while [ 1 -gt 0 ]; do
dd if=/dev/urandom of=/dev/hda
done

Da bleibt wohl nicht viel über … :’(
Tut mir irgendwie in der Seele weh. Zumal wenn ich sehe, das das ganze inzwischen schon 1 Stunde, 23 Minuten läuft und das System immer noch tapfer auf Pings reagiert.

Abschied von der alten Zoosau - h1322702

1: Hier läuft die “Schleife of Death”
2: Hier antwortet das System immer noch tapfer auf Pings
3: Im Schatten der alten Zoosau, steht hier bereits die neue Zoosau Gewehr bei Fuß

Schon blöd – selbst wenn man sich das Auto, was unmittelbar nach dem eigenen vom Band gerollt ist, als Ersatz für das eigene kauft, fühlt man sich dennoch darin fremd und merkt, das es nicht dasselbe ist.
Ich habe jetzt alle Dienste übertragen, alle Dateien kopiert. Ja, sogar funktionieren tut alles. Schneller als vorher. Und dennoch fällt mir der Abschied schwer.

Naja, nun ist’s eh zu spät.
Auf zum letzten Shutdown – sofern das System den überhaupt noch hinbekommt

Ich dachte lange Zeit das Verhalten von WordPress, nach einem Klick auf “automatisch aktualisieren” (Siehe Bild 1 – “automatisch aktualisieren ohne korrekte Rechte“) einen Dialog einzublenden, in dem man FTP-Zugangsdaten eingeben muss um das zuvor am PC heruntergeladene ZIP-Archiv mit der neuen Pluginversion auf seinen Server hochzuladen (Siehe Bild 2 – “FTP-Abfragemaske”), seie der Standard und die einzige Methode, die diese Funktion anbietet, um ein Plugin auf eine neue Version zu aktualisieren. War für mich natürlich extrem blöd, da ich gar keinen FTP Dienst hier auf meinem Server benötige. Was ich hoch- und herunterladen möchte, transferiere ich per SCP. Ein Einfallstor weniger, deutlich sicherer da von Haus aus verschlüsselt und solche Features wie Up-/Downloadquota benötige ich ohnehin nicht.

automatisch aktualisieren ohne korrekte Rechte

FTP-Abfragemaske

Das dieses die einzige Methode ist ist jedoch garnicht der Fall! Ja, nicht einmal um die Standardvariante handelt es sich; das ganze ist schon eine Fallback-Funktion. Hat man sein WordPress richtig konfiguriert, wird man garnicht nach FTP Zugangsdaten gefragt, sondern WordPress läd die Datei selbstständig von der WordPress-Seite des Plugins herunter, deaktiviert es, überschreibt die alte Version mit der neuen und aktiviert diese anschließend wieder. Es hält sich somit an seine eigenen Empfehlungen und könnte komfortabler nicht sein.

Warum klappt es jedoch bei so vielen nicht und wieso können einem auf Nachfrage die meisten Experten nichtmal sagen warum beim einen das Autoupdate und beim anderen die FTP-Datenabfrage kommt? Die Antwort auf die zweite Frage habe ich selber nicht parat, aber die Antwort auf die erste versuche ich im folgendem zu geben und versuche das ganze so leicht verständlich wie möglich zu halten.

Der Webserver ist an sich auch nur ein Programm, welches als ein bestimmter User läuft. Der Webserver darf also auch immer nur auf genau die Ressourcen zugreifen (und mit den entsprechenden Rechten), wie es ein User auf der Shell, der als dieser User angemeldet ist, auch dürfte. Als welcher User/Gruppe der Webserver laufen soll, legt man beispielsweise beim Apache mit den Optionen “User” und “Group” fest. Im folgenden gehe ich exemplarisch davon aus, das es sich hierbei bei beidem um “apache2″ handelt.
Dementsprechend muss ein Verzeichnis in dem der Webserver Dateien ablegen, verändern oder entfernen soll, auch mit den entsprechenden Rechten für diesen User versehen werden. Für WordPress’ Plugins wäre dieses das Verzeichnis “wp-content/plugins/“. Selbstverständlich muss der User apache2 in diesem, sowie dessen Unterverzeichnisse für Dateien mindestens 644 und für Verzeichnisse mindestens 755 Rechte haben. Selbiges gilt jedoch natürlich für alle anderen Verzeichnisse, in denen der Webserver Daten ändern können muss, wie “wp-content/themes” oder “wp-content/uploads” gleichermaßen.
Jedoch war dieses immer schon so bei mir, und dennoch habe ich den zuvor genannten FTP-Datenabfrage – Dialog erhalten.

Der Knackpunkt ist, das die Datei “wp-admin/update.php” dem User gehören muss, als der der Webserver läuft. Es genügt nicht das dieser User einfach sämtliche benötigten Rechte auf diese Datei haben muss, sie muss ihm tatsächlich gehören! Einen durch Berechtigungen gerechtfertigten Grund hierfür gibt es nicht, die Routine ist schlichtweg so programmiert. Selbstverständlich könnte man dieses Stück Code verändern, nur muss man das dann nach jedem Core – Update wiederholen. Grundsätzlich lässt man von sowas die Finger!

Ist also beides gegeben, passende lese-/schreibrechte in den genannten Verzeichnissen, sowie das Eigentumsrecht auf die Datei “wp-admin/update.php“, funktioniert es auch mit dem auto-Update!

Funktionierendes WordPress Plugin-Auto-Update

Vielen Dank an dieser Stelle an Stefan David, der auf seinem Blog-Beitrag nach Monaten als einziger in der Lage war, dieses Phänomen mal aufzudröseln!

ALTA !!!

Der neue Server ist up und ich entjungfere ihn mal direkt mit einem “LECK MICH AM ARSCH – WARUM???” – Blogeintrag.

Ich sitze auf der Arbeit, richte, wie ich es sicher schon dutzende Male gemacht habe, ein Heartbeat mit DRBD ein und sehe (erstmals unter Lucid Lynx) folgendes beim starten einer Filesystem-Ressource im Log:

…
ResourceManager[8524]:  2010/08/11_20:39:08 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd1 /server/data/nfs reiserfs defaults,acl,rw start
Filesystem[8840]:       2010/08/11_20:39:08 INFO: Running start for /dev/drbd1 on /server/data/nfs
FATAL: Module scsi_hostadapter not found.
…

Worauf lässt es sich zurückführen? Man lese und staune:

Zitat aus Datei “/usr/lib/ocf/resource.d/heartbeat/Filesystem”, Zeilen 404 bis 408:

if [ "X${HOSTOS}" != "XOpenBSD" ];then
# Insert SCSI module
# TODO: This probably should go away. Why should the filesystem
# RA magically load a kernel module?
$MODPROBE scsi_hostadapter >/dev/null

So, Masterfrage: Was passiert, wenn ein Kernel das Modul scsi_hostadapter nicht oder nicht als Modul kompiliert hat (so wie es, nebenbei bemerkt, beim Standardkernel von Lucid Lynx (2.6.32-24-server) der Fall ist)? Riiiiiiiiiiiiichtig: Hier wird ein Exitcode ungleich 0 generiert, und Heartbeat denkt die ganze Aktion ist fehlgeschlagen.

Das ganze lässt sich also durch auskommentieren der Zeile 408 (“$MODPROBE scsi_hostadapter >/dev/null”) beheben.

12.08.2010 – UPDATE: Scheinbar hatte ich das gestern fehlinterpretiert. Es wird zwar die “FATAL: Module scsi_hostadapter not found.” – Meldung ausgegeben, jedoch hat dieses doch keine Auswirkungen auf den Errorcode des gesamten Scriptes. Dann lag das gestern an was anderes … gnaaaahr

Endlich ist es soweit und ich halte mein vorbestelltes “StarCraft 2 – Wings of Liberty” in den Händen!

Mein frisch ausgepacktes StarCraft 2

… moment mal: was freue ich mich eigentlich so? Kann ich es spielen? NEIN! Warum? Blizzard geht, wie so viele andere Spielehersteller in letzter Zeit, ebenfalls den Weg der Onlinepflicht. Und zwar nicht nur für die Kämpfe gegen andere Spieler über’s Internet, ja, nichtmal nur ausgedehnt auf den Soloplayermodus: Nichtmal installieren kann man das ganze ohne Verbindung zum Battle.net!
Ansich auch gerade noch zu verschmerzen. Aber was denken die sich tolles aus?? “Hey, schicken wir die Spiele doch schonmal raus, aber die Server fahren wir erst heute nacht um 0:01 Uhr hoch!“.

StarCraft2 - Noch nicht ...

Ich werd’ wahnsinnig!! Was soll der Scheiß??
Wenn’s genauso reibungslos läuft wie beim Start von Assassins Creed 2, sind die Server um 0:10 Uhr auch gleich wieder off, “weil mit _SO_ einem Andrang ja keiner rechnen konnte“. … ne, wieso auch verkaufte Spiele in Summe zu Vorbestellungen in Zusammenhang mit Spielern, die sich zum Server verbinden könnten setzen?

Und wenn die “offizielle” Version genauso lange installiert wie die Beta-Version, muss ich um 6 dann eh los zur Arbeit. …

Naja, ich werde berichten

Der Server, auf dem unter vielen anderen Seiten und Diensten, auch dieses Blog hier läuft, wird in den kommenden Tagen umgezogen. Zum einen sagt mir die aktuelle Linux-Distribution nicht mehr zu, zum anderen bietet mein Provider nach über 4 Jahren, in denen dieser Server in der aktuellen Form bereits besteht, für’s gleiche Geld inzwischen Server mit der doppelten Leistung und Ausstattung an. Die Gelegenheit ist also günstig.

Aktuell bereite ich im Hintergrund bereits das neue System vor. Wenn dieses soweit finalisiert wurde, wird es eine mehr oder weniger kurze Downtime geben, in der die Seiten umziehen. Entgegen dem professionellen Seitenhosting kann ich mir auf diesen Privatseiten ja bequem den Luxus gönnen und sagen: “It’s done, when it’s done!”

Ich weiß, das diese Seite mal nicht erreichbar sein könnte, trifft tausende da draußen schwer. .. , aber die Berufsehre gebietet es mir irgendwie diese erste Downtime über mehr als 5 Minuten überhaupt nach über 4 Jahren als geplant anzukündigen

Heute, ein Tag wie jeder andere. Zumindest bis mein Chef ankam
Ich ahnte nichts, aber nachdem er mir, wie alle anderen Kollegen übrigens auch, zum Geburtstag gratulierte, meinte er nur “Ich hab’ sogar ‘nen Geschenk für Dich! Komm mal mit…“. … OK: Es kommt kein Schweinkram ;D : Er überreichte mir ganz beiläufig sein “altes” Motorola Milestone als Diensthandy! Er hatte das zwar schonmal angekündigt, aber ich dachte eigentlich, das sei ein Scherz.

Motorola Milestone

Ich bin jetzt natürlich seelig und freue/fürchte mich vor den nächsten Wochen, wo ich wie ein genickstarrer Zombie diese für mich neue Plattform bis ins letzte Detail erkunden kann ;D

Stilgerecht ist dieser Betrag natürlich umgehend mit der WordPress App entstanden

HA! Endlich was cooles herausgefunden!

Seit langem ärgere ich mich, das die deutsche Rechtschreibprüfung für den Thunderbird Mailclient nur für Versionen bis 2.0.0.* funktioniert, obwohl der Thunderbird 3.0 ja nun schon Monatelang veröffentlicht ist. Heute habe ich durch diesen Eintrag eine Lösung hierzu gefunden!

Diese *.xpi – Pakte sind simple, umbenannte ZIP – Archive. Sie lassen sich einfach entpacken. Anschließend kann man einfach mit einem Texteditor die Tags “<em:maxVersion>2.0.0.*</em:maxVersion>” in der Datei install.rdf in 3.0.* abändern. Anschließend erstellt man nur wieder ein ZIP Archiv aus den Daten die vorher auch in dem Archiv gewesen sind und benennt es wieder in *.xpi um.

Fertig!

Ich habe das Paket für die alte und neue deutsche Rechtschreibung schonmal hier vorbereitet. Ihr könnt es gerne herunterladen und installieren.

Hinweis: Da Thunderbird und Firefox dummerweise dieselbe Dateierweiterung für Ihre Extensions nutzen, versucht der Firefox die Rechtschreib-Extension bei einem Linksklick auf den obigen Link zu installieren. Bitte klickt daher mit rechts darauf und wählt “Ziel speichern unter …“. Anschließend könnt ihr die Extension dann im Thunderbird wie gehabt installieren.

Ich war auf der CeBit! Das ganze wurde inklusive Fahrt und Verpflegung von meiner Firma bezahlt. Um es kurz zu machen: Wenn die irgendwann einmal irgendwo … sagen wir: In Duisburg oder Bochum, also: in der Nähe, stattfinden sollte und ich gerade rein GARNICHTS anderes vorhaben sollte, würde ich in Erwägung ziehen diese Messe noch einmal zu besuchen. Aber Hannover? No Way – Die Messe ist Mega langweilig. Neben zig No-Name China-Ständen stehen da nur noch langweilige 0815 – Stände. Keinerlei Innovationen, ja: Nichtmal echter Herstellerkontakt ist dort möglich.

Ich interessiere mich zum Beispiel für vertikal montierbare PDUs für unsere Server-Racks. Klingt komisch, ist aber so! Die Leute von APC, die da vor Ort waren konnten mir die simpelsten Fragen nicht beantworten. Aber OK: Sie haben mir angeboten diese Fragen gezielt weiterzuleiten (an der Hotline waren sie ebenfalls überfragt) und sich bei mir zu melden. Ähnliches habe ich auch mit anderen Herstellern gemacht – das wird hier keinesfalls ein APC – Exklusives negativ-Ranking. Und ein paar Tage nach Messeende bekommt man nur eine Standard-Spammail “Sie haben uns auf der CeBit besucht – schön! Besuchen Sie doch mal unsere Homepage. ….”

Ich brauch da nie wieder hin. Weder privat noch geschäftlich. Außer Spesen nichts gewesen …