Es gibt einen Wechsel auf der Position des Blogsystems. Aus dem Spiel geht die Nummer 9 Serendipity. Neu im Spiel ist der Spieler mit der Nummer 8 Octopress.

Warum

Lasst uns analysieren, was der Grund für den Wechsel ist. Auf der einen Seite steht mit Serendipity ein Blogsystem, dass sehr umfangreich, mit Plugins leicht erweiterbar und einfach zu handhaben ist. Auf der anderen Seite steht Octopress. Ein System, das in Ruby geschrieben ist und mit Jekyll auf dem heimischen Rechner statische HTML-Seiten generiert und diese dann automatisch auf den Server schiebt. Das hat den Vorteil, dass es im Hintergrung keine Datenbank und nichts braucht, außer einen Webserver. Da die Seiten statisch sind, und keine zur Laufzeit auf Scripten wie PHP generierten Seiten, sollten sie auch schneller sein und auf dem Server weniger Rechenleistung verbraten. Auch besteht die Gefahr von Sicherheitslücken wie SQL-Injections nicht, da im Hintergrund keine Datenbank ihr Werk verrichtet.

Wie

Die Installation von octopress auf dem eigenen (Gentoo-)System ist recht einfach. Ruby sollte eigentlich schon auf dem System laufen und via

~ # eselect ruby list
Available Ruby profiles:
  [1]   ruby18 (with Rubygems)
  [2]   ruby19 (with Rubygems) *

sollte man überprüfen, ob Version 1.9 von Ruby läuft. Wenn nicht mit, in meinem Fall,

~ # eselect ruby set 2

die richtige Version wählen.
Wenn die Vorraussetzungen gegeben sind, kann man sich das octopress git auf seinen Rechner clonen:

~ % git clone git://github.com/imathis/octopress.git octopress

Im Ordner octopress liegt jetzt das ganze Blogsystem.
Nun muss man noch ein paar kleinere Abhängigkeiten installieren:

~ # gem install bundler

Im Gemfile des octopress musste ich noch 3 Abhängigkeiten eintragen, damit später alles sauber baut:

gem 'json'
gem 'execjs'
gem 'therubyracer'

Anschließend kann man mit

~ % cd octopress/
~ % bundle install

die Abhängigkeiten noch installieren.
Nun noch mit

~ % rake install

das Standardtheme installieren und schon kann man anfangen zu schreiben.

Umstieg

Da ich bisher noch nicht zu viele Blogeinträge habe, konnte ich die ohne Probleme von Hand in das neue System überführen. Dazu legt man einfach mit

~ % rake new_post[name_des_posts]

einen neuen Post an. Im Header können verschiedene Einstellungen wie die Tags oder das Datum verändert werden. Dann einfach den Text in die Datei kopiert und mit Markdown die Formatierung so hinbiegen, dass es wieder schick aussieht. Praktischerweise kann man den aktuellen Stand mit

~ % rake preview

im Browser unter der Adresse 127.0.0.1:4000 immer schön kontrollieren.

Wenn man mit allem zufrieden ist, muss man nur noch in der Rakefile den ssh-Zugang einrichten und via

~ % rake generate
~ % rake deploy

die Html-Seiten generieren und hochladen…

…and reanimate it.

Vorgeschichte

Ich wollte auf meinem Gentoo-Notebook in einem LV ein weiteres Gentoo-System installieren um xbmc mal ein wenig auszuprobieren. Geht natürlich wunderbar aus dem laufenden System heraus. Dazu fängt man ganz gemütlich mit einem simplen

~ # mount /dev/vg/genbmc /mnt/genbmc

an. Dann noch kurz mit

~ # cd /mnt/genbmc

ins Verzeichnis wechseln und schon kann es losgehen.

Der Mord

Weiter geht es ganz gemütlich nach Handbuch

~ # tar xvjpf stage3-amd64-20121013.tar.bz2

Dann noch schnell den portage-Snapshot auspacken

~ # tar xvjf stage3-amd64-20121013.tar.bz2 -C usr/

Mist, falsch. Naja, war ja noch nicht so viel, also fangen wir noch mal an. Kurz das falsch ausgepackte löschen

~ # rm -fr /usr

Und dann habe ich nach ca 2 Sekunden gemerkt, dass ich diesen Befehl wohl etwas falsch eingetippt habe… WAAAAAAAAHHHHHHHHHHHH!!! ALARM!!!
Natürlich hab ich das dann gleich mal mit ^c abgebrochen. Aber das macht auch nicht mehr den riesen Unterschied. Jedenfalls hab ich ja eh grad ein Stage3 da, also kann man damit auch arbeiten. Und hier kommt auch schon der zweite Fehler. Anstatt einfach nur das /usr auszupacken und an die richtige Stelle zu kopieren, kam ich auf die Idee

~ # tar xvjpf stage3-amd64-20121013.tar.bz2 -C /

Hab ich dann aber auch wieder mit ^c abgebrochen, als mir dann kam, dass ja auch /etc und der ganze andere Kram dabei überschrieben werden. Naja, was soll ich sagen. Der Zustand meines Systems war relativ total am Ars…
Hab dann erstmal rebootet, weil ich ja in einem weiteren LV noch ein gentoo hatte, bei dem ich mal hardened mit SELinux ausprobieren wollte, was auch in einem passenden Zustand sein sollte um bis in eine Bash zu booten, aus der ich problemlos die Schritte zum wiederbeleben meines normalen Systems ausführen kann. Beim booten ist mir dann allerdings aufgefallen, dass ich wohl bei dieser hardened-LV wohl noch kein root-Passwort gesetzt habe, da ich bisher da alles aus dem chroot gemacht habe. Mein zerstörtes System hat ja dummerweise auch kein root-Passwort mehr, da die /etc/shadow aus dem stage3 überschrieben wurde und daher nun relativ leer ist.
Was macht man nun, wenn man grad keinen USB-Stick mit GRML Codename “Schluchtenscheißer” oder “Knecht Rootrecht” oder wie die aktuelle Version gerade heißt, zur Hand hat? Naja, man hat ja noch einen bootfähigen Kernel in der Boot-Partition rumliegen, den man mit init=/bin/bash mal booten könnte. Blöd nur, wenn das ganze in einer Kernel-Panic endet. Und zwar egal mit welcher der 6 Kernel-Versionen, die da liegen, ich es versuche. Zum Glück lag da auch noch ein Arch-Linux Kernel meiner alten Installation inkl passender initrd rum. Mit diesem Kernel ist es mit dann tatsächlich gelungen in die hardened-LV mit init=/bin/bash zu booten und da ein root-Passwort zu setzen. Hab dann auch erstmal wieder ein sauberes /usr aus dem Stage3 in mein System kopiert und hab da per chroot auch ein root-Passwort gesetzt.

Diagnose

Ein reboot in mein System zeigte dann die kompletten Ausmaße der Zerstörung. Die /var/lib/portage/world war leer. Kam also anscheinend aus dem stage3. Hostname, Zeitzone und der ganze Kram aus der /etc waren natürlich auch weg. Dummerweise auch die make.conf. Aber das ist ja alles recht einfach wieder zurück zu holen.

Operation “unkill it”

Wenn man eh alles neu installiert, kann man auch gleich zu einer neueren gcc-Version wechseln, die mit -march=btver1 -mtune=btver1 meinen Prozessor auch direkt von Haus aus unterstützt. Wenn man dann noch seine Logs hat, ist regenworld ein richtig cooles Tool, welches aus den Portage-Logs, wie der Name schon sagt, die World-File wieder erstellt. Da ich nicht genau wusste, was alles noch vorhanden ist und ich auch nicht genau nachschauen wollte, hab ich mal unter /var/db/pkg alles gelöscht was da vorhanden ist.
Danach kann man mit

~ # emerge -eav system

das Grundsystem super in einen geordneten Zustand zurück führen. Da meine CPU auf einer Skala von SMART bis Bugatti Veyron so ca auf Schildkröte einzuordnen ist, hab ich danach erstmal wieder distcc installiert und aktiviert um mit der Unterstützung der sechs Kerne keine 3 Jahre für ein

~ # emerge -av world 

zu brauchen.

Fazit

Was soll ich sagen. Nach einer langen Nacht des Emergens läuft alles wieder so wie es soll. Und was lernen wir daraus? DO NOT EVER USE rm -fr WITH RELATIVE PATHS!!! Hätte ich ganz gemütlich

~ # rm -fr /mnt/genbmc/usr

geschrieben hätte der ganze Müll nicht passieren können… Aber da ich ja eh mal den gcc updaten wollte und dann auch gleich alles mit den neuen Flags kompilieren wollte, ist ja eigentlich gar nichts passiert…