Auf dem Server setzte ich Debian Linux als Betriebssystem und duplicity als Backup-Software ein. Dieses Backuptool verschlüsselt die Backups mit GPG-Schlüssel, somit braucht man eine intakte (vorzugsweise unixartige) Systemumgebung und den GPG-Schlüssel, mit dem das Backuparchiv erstellt wurde. Meine Herausforderung war nun, die auf einem Linux-Server erstellten Backup-Archive auf dem Mac wieder auszupacken, um die wiederhergestellten Git-Repositories auf einen anderen Server zu verschieben.

Duplicity bekommt man mit Homebrew in Sekundenstelle installiert, ebenso das Skript duply, ein Wrapper für duplicity, der die Konfiguration und Bedienung extrem vereinfacht.

sudo brew install duplicity
sudo brew install duply

nun braucht man die duply-Konfiguration, lag auf dem Server unter /etc/duplyund kann auf dem Mac in ~/.duplyabgelegt werden. Ich nenne das Backup-Set mal “gitrepo”, das Backup-Set liegt in ~/backups. Es muss noch in der Datei ~/.duply/gitrepo/conf der Pfad zu den Backup-Ordnern geändert werden, z.B.

TARGET='file:///var/backups/duply/gitrepo/'

in

TARGET='file:///Users/drue/backups/gitrepo/'

Nun kann man die Wiederherstellung starten, der GPG-Schlüssel-ID und das Passwort steht in der Duply-Konfiguration. In diesem Beispiel soll das Backup ins Verszeichnis ~/gitrepo wiederhergestellt werden.

$ duply gitrepo restore ~/gitrepo
Start duply v1.5.4, time is 2012-02-03 16:11:46.
Using profile '/Users/drue/.duply/gitrepo'.
Using installed duplicity version 0.6.17, gpg 1.4.11 (Home: ~/.gnupg).
Autoset first GPG_KEY entry '09ABCDEF' as signing key.
Test - Encrypt to 09ABCDEF & Sign with 09ABCDEF (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.17084.1328281906_*'(OK)
 
--- Start running command RESTORE at 16:11:47.000 ---
Max open files of 120 is too low, should be >= 1024.
Use 'ulimit -n 1024' or higher to correct.
 
16:11:47.000 Task 'RESTORE' failed with exit code '37'.

OK, es ist eben kein Server. Duplicity beklagt, dass die Höchstgrenze gleichzeitig geöffneter Dateien mit 120 zu gering ist. Das lässt sich mit

ulimit -n 1024

auf jedem unixartigen System hochsetzen. Ein alternatives mac-spezifisches Kommando ist

launchctl limit 1024 10240

Nun ein weiterer Versuch:

drue@ain:~$ duply gitrepo restore ~/gitrepo
Start duply v1.5.4, time is 2012-02-03 16:10:32.
Using profile '/Users/drue/.duply/gitrepo'.
Using installed duplicity version 0.6.17, gpg 1.4.11 (Home: ~/.gnupg).
Autoset first GPG_KEY entry '09ABCDEF' as signing key.
Test - Encrypt to 09ABCDEF & Sign with 09ABCDEF (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.16860.1328281836_*'(OK)
 
--- Start running command RESTORE at 16:10:36.000 ---
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20110910T232302Z.sigtar.gpg to local cache.
Traceback (most recent call last):
  File "/usr/local/bin/duplicity", line 1377, in <module>
    with_tempdir(main)
  File "/usr/local/bin/duplicity", line 1370, in with_tempdir
    fn()
  File "/usr/local/bin/duplicity", line 1246, in main
    sync_archive(decrypt)
  File "/usr/local/bin/duplicity", line 1059, in sync_archive
    copy_to_local(fn)
  File "/usr/local/bin/duplicity", line 1008, in copy_to_local
    tdp.move(globals.archive_dir.append(loc_name))
  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 617, in move
    self.copy(new_path)
  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 443, in copy
    self.copy_attribs(other)
  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 448, in copy_attribs
    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))
  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/util.py", line 65, in maybe_ignore_errors
    return fn()
  File "/usr/local/Cellar/duplicity/0.6.17/libexec/duplicity/path.py", line 448, in <lambda>
    util.maybe_ignore_errors(lambda: os.chown(other.name, self.stat.st_uid, self.stat.st_gid))
OSError: [Errno 1] Operation not permitted: '/Users/drue/.cache/duplicity/duply_gitrepo/duplicity-full-signatures.20110910T232302Z.sigtar.gz'

An dieser Stelle habe ich aufgehört, mein Glück mit Duply zu veruchen, da es abbricht, weil es ein paar erweiterte Dateiattribute nicht setzen kann. Beim nächsten Versuch habe ich mir das eigentliche Duplicity-Kommando gesucht und im Ubuntu-Hilfe-Wiki gefunden. Wenn man das GPG-Passwort nicht in der Umgebungsvariable PASSPHRASE hinterlegt, wird man bei der Ausführung des Kommandos duplicity restore ... erfragt.

export PASSPHRASE=SomeLongGeneratedHardToCrackKey
duplicity restore file:///Users/drue/duply/gitrepo/ gitrepo
unset PASSPHRASE

Nun kommt noch immer diese Fehlermeldungen:

...
Error '[Errno 1] Operation not permitted: 'gitrepo/repositories/image_server.git/objects/45'' processing .
...

Das Kommando aber läuft durch. Ich hatte meine Git-Repositories zurück und habe sie mittlerweile funktionierend und an neuer Location wieder am Start.

Epilog

Den Beitrag habe ich geschrieben, um alle im Netz verstreut liegenden Infos zusammenzutragen und den Suchmaschinen zu den Fehlermeldungen die passenden Beschreibungen zu liefern. ;)
Ein wichtige Lehre ist wiedermal: Hast Du alle Daten zur Hand, die Du zur Wiederherstellung brauchst. In diesem Fall waren das der GPG-Schlüssel, das zugehörige Kennwort und natürlich ein möglichst aktuelles und konsistentes Backup.

Hätte die Wiederherstellung auf dem Mac nicht funktioniert, wäre der nächste Programmpunkt, eine Jiffybox mit Debian Linux einzurichten, die Backups auf diesen vServer zu transferieren und mit nahezu identischer Systemumgebung ausgepackt. Hätte aber ein paar Stunden länger gedauert.

“Multisite” ist eine raffinierte Funktion, um mehrere Drupal-Websites aus einer Codebasis zu betreiben: Im Webserver werden mehrere Domainnamen auf das selbe Drupal-Installationsvverzeichnis konfiguriert. Beim Seitenaufruf ermittelt Drupal den Domainnamen zum Request, sucht im Ordner sites/ den passenden Ordner mit den Konfigurationsdaten. Wenn es für die gesuchte Domain keinen Ordner gibt, dann wird im Ordner sites/default/ nachgesehen. Die im Konfigurationsordner vorhandene Datei settings.php enthält unter anderem die nötigen Datenbank-Informationen und Drupal liefert mit den in der Datenbank abgelegten Daten schließlich die Webseite aus. Eine detaillierte Beschreibung zu Multisites liefert das Handbuch auf drupal.org sowie die Linkliste am Podcastbeitrag.

Diese Funktion war ein unverzichtbares Hilfsmittel, als Festplattenkapazität auf dem Server kostbar war und FTP die einzige administrative Zugriffsmöglichkeit auf den Server war: Bei der Installation einer neuen Website braucht man nur einen neuen Konfigurationsordner anlegen, die settings.phpdorthin kopieren und anpassen und eine neue Datenbank befüllen. Beim Update eines Moduls kopiert man die von drupal.org heruntergeladene Modulversion per FTP auf den Server und ruft für jede Website die Updatefunktion im Browser auf. Und genau diese Arbeitserleichterng ist das Problem mit Multisites: Nach dem Austauschen der Moduldateien muss man sofort die Datenbank-Updates auf allen Websites durchführen. Das kann natürlich einige Zeit dauern, und so lange sind unter Umständen (bis zu n-1) Websites dieser Multisite-Installation zerbrochen. Und man muss darauf vertrauen, dass das Modul-Update keine der Websites “zerbricht” — also gleich noch testen, was wiederum wieder viel Zeit beansprucht. Und wie geht man vor, wenn nun Eine der Multisites nach dem Update nicht mehr funktioniert? Viel Handbareit und eine erstmal zerbrochene Website bleiben zurück.

Seit rund 3 Jahren betreibe ich (fast) alle meine Drupal-Sites auf Webhostings, bei denen ich mich per ssh auf dem Server einloggen und die Websites administrieren kann. Bei den großen Anbietern bekommt man solch ein Hosting ab ~10 Euro je Monat. Alternativ dazu kann man sich für den Preis auch einen vServer klicken. Ich bin großer uberspace-Fanboy, dort bekommt man ein Webhosting mit ssh-Zugang (und sehr vielem mehr) für den Preis, den mit das Angebot wert ist. Ich folge mittlerweile der Empfehlung der Betreiber und habe für jede Website einen eigenen Uberspace (also ein eigenes Benutzerkonto auf einem der Uberspace-Server), weil auch die E-Mail-Konfiguration per Uberspace erfolgt und ich so jedem Kunden problemlos Ssh-Zugang zu “seinem” Uberspace geben kann.

Nun fragt Ihr vielleicht, wie viel mehr Zeit ich für ein so verteiltes Hosting investieren muss? Deshalb hier noch ein paar Ausführungen dazu. Ich bin bekanntermaßen begeistert von drush, dem Kommandozeilenwerkzeug für Drupal. Natürlich ist drushauf allen Uberspaces installiert. Ich pflege eine Vorlage für ~/.drush auf meinem lokalen Rechner und die wird — zusammen mit weiteren Konfigurationsdateien — in jeden neuen Uberspace kopiert. Aktualisierung des Setups ist auch schnell getan:

cd ~/uberspace_template   
for i in $(uberspaces)   
do
  echo "*** $i ***"
  rsync -var . $i:
done

Das $(uberspaces) habe ich kürzlich beschrieben.

Auf dem Uberspace kann ich nun mit drush schnell ein Backup der Website machen, Module aktualisieren und ein fälliges Update in Sekundenschnelle auf einer Kopie der produktiven Website testen.

drush rsync @live @test   
drush sql-sync @live @test
drush @test up views
# und nun Testen
drush @live bam-backup
drush @live up views

Details dazu und den obligatorischen Hinweis auf environment_indicator.module findet Ihr in dem frühren Blogbeitrag.

Um herauszufinden, welche meiner Drupal-Installationen von einem nötgen Update betroffen sind, läuft dieses Sktipt von meinem lokalen Rechner aus:

for i in $(uberspaces)
do
  echo "*** $i ***"
  ssh $i "find /var/www/virtual/$i -type f -name modulname.module"
done

Um es noch einfacher zu haben, habe ich alle Dateien aliases.drushrc.php vom Server auf meinen lokalen Rechner kopiert und den Namen des Uberspaces als Prefix vorangestellt

for i in $(uberspaces)
do
  echo "*** $i ***"
  scp $i:.drush/aliases.drushrc.php ~/.drush/$i.aliases.drushrc.php 
done

Dann noch die Paramater remote-hostund remote-user in den Aliases ergänzen und ich kann vom lokalen Rechner aus Drush-Kommandos auf dem Uberspace ausführen, ohne mich vorher dort anmelden zu müssen:

drush @uberspacename.live st

Das vergangene halbe Jahr seit meinem Umzug zu uberspace.de mit strengen Separation aller Websites auf eigene Benutzerkonten (Accounts) hat gezeigt, dass dieser Workflow robust ist und mit drush, git, komfortablem Backup auf Systemebene und all den anderen Helferlein keinen Mehraufwand gegenüber einem eigenen Server mit allen Websites unter /var/www bringt. Dafür aber Zuverlässigkeit der Plattform, schnell durchgeführte Drupal-Updates und einen freigestellten Linux-Admin.

Nun bin ich auf Deine Meinung gespannt. Wie administrierst Du Deine Drupal-Sites? Was für Hosting-Pakete favorisierst Du wie passt Dein Provider zu Dir? Und: Nutzt Du noch Multisites und ich habe irgend ein cooles Feature aus den Augen verloren?

Ich hatte Gelegenheit zu einem Selbsttest, als ich kürzlich mein Macbook wegen eines Hardwaredefekts – nur für mich überraschend? – im Apple Store zurück lassen musste. Ich reaktivierte mein Linux-Notebook und legte los. Wichtig war mir, schnell wieder eine funktionierende Arbeitsumgebung einzurichten.

• Mein iPod und iPad wurden regelmäßig mit dem Mac synchronisiert. Adressbuch, Kalender und so waren also auf aktuellem Stand und weiterhin gut nutzbar. Damit habe ich mich am Linux-Desktop nicht beschäfftigt.
• Dank Mails auf dem IMAP-Server hatte ich mit Thunderbird schnell wieder Zugriff auf die Mails. Auf dessen Adressbuch konnte ich verzichten: wenn ich eine Adresse brauchte, habe ich sie schnell in einer früheren Mail im Gesendet-Ordner gefunden.
• Für die Arbeit brauche ich Firefox, Netbeans, OpenOffice und ein gutes Terminal – alles da.
• Aktuelle Projekt- und Konfigurationsdaten habe ich mir aus dem wöchentlichen Mac-Backup von der Backup-Festplatte (USB) kopiert. Das klappt mit Linux im Lesezugriff auf Apples HFS-Dateisystem sehr gut.
• Auf Fotos in der Aperture-Bibliothek kann man ganz gut zugreifen, wenn man weiß, wonach man sucht, da die Aperture-Metadaten fehlen. Aber der Import der Bilder aus dem Backup nach Digikam macht sie nutzbar.
• Meine Dokumente liegen auf dem Mac in einem verschlüsselten Sparsebundle. An die kam ich ohne Mac OS nicht heran. Zum Glück hat mir ein Freund dann mal seinen Mac geliehen und ich habe mir die notwendigen Dateien aus dem USB-Backup kopiert. (Dafür habe ich die Software auf seinem Mac gleich mal aktualisiert. Win-Win :)

Insgesamt ein ganz gutes Ergebnis. Nur für das Sparsebunde werde ich mir noch was überlegen müssen. Ich will mal probieren, ob ein Truecrypt-Container sich ähnlich reibungslos ins Mac OS integrieren lässt und so eine plattformübergreifende Alternative darstellt.

Man kann von meinem Anwendungsfall leicht abstrahieren und eine andere Betriebssystem-Kombi für die Notlösung wählen. Mit einem Windows-PC als Interimslösung wäre der temporäre Rechnerverlust sicher schmerzlicher spürbar gewesen. Wichtig ist jedoch, einen Plan zu haben.

PS: Allerdings wollte ich mich die ganze Zeit nicht mehr mit der Qualität und dem Bedienkomfort der Anwendungen auf dem Linux-Desktop anfreunden. Das Jahr des Linux-Desktops liegt wohl noch in weiter Zukunft.

Anmerkung: Den Beitrag hatte ich im Frühjahr geschrieben, aber aus den Augen verloren. Als nun mein Kollege Thomas drei Wochen ohne Mac auskommen musste, kam er mir wieder in den Sinn.

VirtualBox schafft 16GB RAM, mehr ist nicht enstellbar und nicht spezifiziert. Läuft, aber das reicht nicht für das Preprocessing. Eine Anfrage im VirtualBox Forum ergab, dass es wohl einen Patch für das Heraufsetzen der RAM-Grenze gibt, aber das ganze auf der angealterten RHEL5-Plattform nicht trivial ist und letztlich nach stundenlangem Compilieren auch fehl schlug.

Auf Anfrage teilte mir vmWare mit, dass ihr vShpere das kann, ich aber die Befürchtung hatte, dass die Software so tief in das System reingreift, dass danach nichts mehr von dem Rechenknecht übrig ist, und die nVidia-Dualhead-Grafikkarte mit closed Source Treiber und andere Spezialitäten auch nicht mehr funktionieren.

Und mitten in der Depression hatte ich die Idee, mir die VirtualBox-Konfigurationsdatei des Windows-Gastes zunehmen und dort statt der 16GB eben 64GB RAM einzutragen. Klappte. Und beim ersten Testlauf hat der Windows-Gast auch mehr als 30GB Speicher belegt. Und lief ohne Absturz durch. Nun stehen noch ein paar ausführlichere Tests mit dem FEM-Preprozessor an, aber es sieht aktuell gut aus. Und das Problem der RAM-Begrenzung scheint auch nur virtuell zu sein.

Update: Ein ausführlicher test hat nun ergeben, dass Windows die 64GB RAM wahrnimmt und sie laut Taskmanager auch nutzt, aber das trotzdem nicht korrekt funktioniert. Jedenfalls ist der Windows-Gast (erwartungsgemäß) instabil und hat auch einmal den Neustart des Hosts erfordert. Schade! Fazit: Rollback.

Nun nahm ich mir vorgestern ein herumliegendes T41 und installierte Ubuntu-9.04 und das lief erwartungsgemäß super. Also wagte ich mich erneut ran und aktualisierte mein Notebook. Und wieder fror mir der Desktop ein und der X-Server brauchte alle Rechenleistung für sich. Aber diesmal fand ich die Lösung im Ubuntu Bugtracker. Man muss/sollte bei “betagten ATI-Karten vom XAA- zum EXA-Treiber wechseln

Im Ergebnis ist es ein klitzekleiner hack in der xorg.conf:

Section "Device"
    Identifier      "Configured Video Device"
EndSection

wird zu

Section "Device"
    Identifier      "Configured Video Device"
    Option "AccelDFS" "on"
    Option "AccelMethod" "XAA"
    Option "MigrationHeuristic" "smart" # "greedy" works well also
    Option "EnablePageFlip" "on"
    Option "EnableDepthMoves" "on"
    Option "ColorTiling" "on"
    Option "FBTexPercent" "0"
    Option "RenderAccel" "on"
EndSection

und alles ist wieder gut!

Wenn ich meine Drupal-Instanzen und Postfächer erst mal übertragen habe, werde ich mir drush mal genauer ansehen und das Drupal-Multisite-Hosting in Augenschein nehmen. Ich freu mich drauf!

Im Moment habe ich das Gefühl, eine Tür zu einer ganz neuen Welt aufgestoßen zu haben. Und frage mich: Warum erst jetzt? ;)

Mittlerweile habe ich ein volles Laufwerk C: (Allein für einen Lotus Domino Administrator gehen inkl. Mail-Datenbank ~1GB “verloren”). Nun war Handeln angesagt. Leider ist es m.E. nicht möglich, eine virtuelle Festplattendatei (VDI) mit VirtualBox-Bordmitteln zu vergrößern. Aber das war kein Problem.

Ich legt ein neues VDI-File mit 10GB Platz an (dynamisch wachsend), holte mir die [GRML-Live CD (medium)](http://grml.org/download/) und legte eine neue virtuelle Maschine an. Diese bootet von dem LiveCD-Image und bindet das bisherige Windows-VDI-File (als /dev/sda) sowie das neu angelegte VDI-File (als /dev/sdb) als Festplatten ein. Diese virtuelle Maschine wird gestartet und dann im GRML-Linux der Inhalt der bisherigen “Platte” au die neue “Platte” kopiert:

dd if=/dev/sda of=/dev/sdb bs=512

Nach ~15min war das erledigt. Nun kann der virtuelle GRML-Rechner wieder heruntergefahren werden.
Nun muss die Partition in der neuen virtuellen Festplatte noch vergrößert werden.

Als nächstes habe ich also die neue Platte zu dem bestehenden virtuellen Windows-PC als “Primary Slave” hinzugefügt und die virtuelle Maschine gestartet. Nun eine DOS-Box im virtuellen Rechner öffnen und mit diskpart die Partition vergrößern:


c:>diskpart
diskpart> select disk 1
diskpart> select volume 2
diskpart> extend
...
diskpart> exit


Nun kann der virtuelle Windows-Rechner herunter gefahren werden. Das bisherige VDI-File wird ausgehängt und statt dessen das Neue als “Primary Master” angemeldet.
Fertig.

PS: Ich hätte statt der GRML-LiveCD natürlich auch eine [GParted-LiveCD](http://gparted.sourceforge.net/livecd.php) nehmen können und mir damit die Basteleien mit diskpart erspart. Allerdings hinterlässt GParted ein modifiziertes NTFS-Image mit dem Dirty-Flag und beim nächsten Windows-Start spring checkdisk an. Und ob ich das Ganze dann in 30min geschafft hätte…

Am 30.10. wurde erwartungsgemäß die neu Ubuntu-Version 8.10 freigegeben, und damit auch der KDE-Ableger Kubuntu. Und weil das Upgrade als einfach beschrieben wurde und ich am Donnerstag Abend gerade online war, habe ich es gleich mal ausprobiert. Zeit für ein Backup blieb da nicht…

2 Stunden später war das Notebook aktualisiert. Damit hatte ich nicht gerechnet – am ersten Tag einer neuen Release ist meist der Ansturm so groß, dass man kein Paket herunter geladen bekommt. Da hat das Release-Team schon mal gute Arbeit gemacht!

Meine Erwartungen an das Release waren/sind groß:

• Erste offizielle KDE4-Release (ich hatte vorher schon Kubuntu 8.04 mit KDE4-Remix laufen und freute mich auf “KDE4-Only”)
• Ein wirklich aktueller Linux-Kernel (2.6.27, neuer geht derzeit gar nicht!)
• OpenOffice.org 3.0
• verbesserter Network-Manager
• Amarok2
• Besser funktionierende Kontact-Suite

• VirtualBox 2.0

Zu allererst: Der reine KDE4-Desktop fühlt sich schon besser an, als das KDE3/KDE4-Mischmasch der letzten Wochen. Allein dass es nur noch eine KWallet-Version für alle Anwendungen gibt ist eine Freude. Die Desktop-Effekte (Compiz) habe ich deaktiviert, mein betagtes Notebook danke es mir mit weniger Lüfterlärm ;-)

Das Upgrade lief nahezu reibungsfrei ab. Der aktuelle Kernel wurde allerdings nicht mit installiert, statt dessen konnte ich “nur” mit 2.6.25 booten. Das kam daher, dass ich das Pakets “linux-image-386” installiert habe, der neuest Kernel ist jedoch nur als “linux-image-generic” verfügbar. Nachdem ich also dieses Paket nachinstalliert habe, war ich aktuellst.

Nach dem Upgrade hatte ich allerdings kein WLAN mehr. Der network-Manager wurde ziemlich erweitert (las ich) und ich habe ihn nicht mehr dazu bewegen können, eine WPA-PSK-Verbindung zu meinem Router aufzubauen. Nach einiger Bastelei habe ich beschlossen, den Network-Manager zu deinstallieren und mich auf die GUI-freie Konfiguration kit /etc/network/interfaces zu stürzen. Mit der Beschreibung im wiki.ubuntuusers.de war das auch nicht soooo schwer. Nun läuft das wieder.

OpenOffice in Version 3 hat es leider nicht mehr in die Distribution geschafft, da sich der Freigabetermin von OpenOffice 3 verzögert hatte und zu wenig Zeit zum Testen blieb. Schade! Aber im wiki.ubuntuusers.de gibt es auch eine Anleitung zum zwischenzeitlichen Aktualisieren, da schon ein paar Entwickler die passenden Pakete generiert haben.

VirtualBox2 ist in der aktuellen Release enthalten und beim ersten Aufruf des Programmes wurden die Konfigurationen meiner virtuellen Maschinen automatisch in das neue Format übernommen. Auch die Kernelmodule passen – sie wurden dem kernel bei Update automatisch (!) via dkms untergeschoben. Total abgefahren, dieser Mechanismus!

Amarok2 ist auch leider noch nicht fertig, ich werde mich brav in Geduld üben und hoffen, dass es vielleicht in KDE4.2 und Kubuntu 9.04 (?) enthalten sein wird!

Nun stehen noch Tests der aktualisierten Kontact-Suite (ein Personal Information Manager, PIM) aus. Und hoffentlich finde ich endlich einen eleganten Weg, meinen Palm mit Kontact zu synchroniseren.

Fazit

Nach zwei Tagen mit dem Kubuntu 8.10 sind die Überraschungen nicht sooo groß (da ich KDE4 schon im Einsatz hatte) , aber die KDE4-Migration ist für mich nahezu und erfolgreich abgeschlossen. Und das Upgrade als solches war reibungsarm und so nachahmenswert.

So habe ich mir ein kleines Skript gebaut, welches genau das erleichtert. Es liegt bei mir im Verzeichnis ~/bin/, die Applikationen werden entweder mit dem Paketmanager installiert oder liegen unterhalb des Verzeichnisses ~/Apps/.

Das Standard-Verhalten des Eclipse-Starters wird durch die Umgebungsvariablen

• $ECLIPSE_HOME (zeigt auf das Eclipse-Installationsverzeichnis, Vorgabe ~/Apps/eclipse),
• $JAVA_HOME (zeigt auf das Java JRE-Installationsverzeichnis) und

• $PROJECTS_HOME (zeigt au den Eclipse-Workspace, Vorgabe ~/workspace)

vorgegeben.

Hier die (minimalistische) Hilfeseite:

My universal Eclipse starter v0.2
Supports easy combination of JRE, Eclipse and workspace to
launch an Eclipse session
  -e DIR, --eclipse=DIR    The eclipse installation directory
                           (defaults to the contents of $ECLIPSE_HOME)
  -j DIR, --jre=DIR        The JDK installation directory
                           (defaults to the contents of $JAVA_HOME)
  -w DIR, --workspace=DIR  The workspace
                           (defaults to the contents of $PROJECTS_HOME
                           or ~/workspace)
  -v, --verbose            Print settings before launching eclipse
  -h, --help               This help

Und dann einfach Eclipse starten:

$ eclipse   # startet bei mir Eclipse 3.4 mit Java5 im Workspace ~/projekte
$ eclipse -e ~/Apps/eclipse-3.2 -j ~/Apps/j2sdk1.4.2_17 # startet 'ne alte Kombi
$ eclipse -w ~/another-workspace # nimmt E3.4, Java5 und einen anderen Workspace

Fertig.

Sie hilft immer und zuverlässig, wenn wiedermal ein Rechner zu analysieren oder zu reparieren ist, wenn es in einem Netzwerk Probleme gibt oder ich einfach eine Linux-Shell oder einen Perl-Interpreter brauche, um Arbeiten auch in "GUI only"-Umgebungen schnell an einer Konsole fertig zu bekommen.

So saß ich heute vor einem etwas betagten Windows98-Rechner und hatte ein paar Hundert MB Daten auf einen daneben stehenden WindwosXP-Rechner zu transferieren. Der Win98-Rechner hatte Floppy- und Zip-Laufwerk, ISDN-Karte und USB-Steckplatz, aber keine Treiber für einn Vanilla-USB-Stick. Der WinXP-Rechner konnte mit all den Schnittstellen nix anfangen. Und ein Null-Model-Kabel ist auch nicht mehr Stand der Technik…

Mit GRML hatte ich all die Daten binnen 10 Minuten auf dem USB-Stick und nach weiteren 10 Minuten war der ganze Datentransfer erledigt. Klasse!

PS: Auf der GRML-Hompage gibts auch ‘nen Spenden-Knopf. Ich habe mich schon mal durchgeklickt :-)