Nahezu alles in und um Linux ist mit irgendwelchen Konfigurationsdateien verbunden. Manche Dinge werden einmal – unter Umständen sogar automatisch von der entsprechenden Paketverwaltung – konfiguriert, andere Dinge müssen laufend gepflegt und erweitert werden.

SubVersion ist ein sogenanntes Revisionsverwaltungssystem das eigentlich für die Verwaltung von Quelltexten von Programmen gedacht ist.

Es eignet sich aber auch hervorragend dazu um Konfigurations Dateien und Verzeichnisse damit zu verwalten und vorallem auf einen anderen Rechner zu sichern. Außerdem hält es einen dazu an jede Änderung zu kommentieren.

Repository (am SubVersion Server) erzeugen:

svnadmin create Name

Ein bestehendes Verzeichnis mit dem Repository verbinden:

cd Konfigurationsverzeichnis
svn --username “Dein Username” co http://Host/Name .

Bestehende Dateien in das Repository aufnehmen:

svn add *.conf
svn add this.ext that.ext db.*

Dateien einchecken:

svn ci

Abgesehen von der Datensicherung hat man damit auch die Möglichkeit ein komplettes Konfigurationsverzeichnis auf einem anderen Rechner zu exportieren und in der Folge synchron zu halten.

Der Grund ist ein 6TB Raid an einem Apfel, daß als Sicherungs-Store herhalten soll.

Apple hats kaputt gemacht.

Das HFS oder OS X kann nämlich keine Hard-Links, oder zumindest können die Commandline-Tools cp und ln keine erzeugen, obwohl einige man-pages das Gegenteil behaupten. Aber vielleicht sind diese Hinweise auch nur übersehene BSD-Überbleibsel. Genau darauf bauen aber meine shell-scripts auf.

Jetzt neue Scripts zu schreiben ist mir aber zu blöd, vorallem wenn der Vorteil der durch den Hard-Link Trick entsteht sowieso nicht zu erreichen ist. Also habe ich mich ein wenig umgesehen und bin bei bacula gelandet.

Bacula arbeitet im Kern mit drei Services bzw. Daemons. Alle drei können auf einer, zwei, drei mehreren (verschiedenen) Maschinen laufen.

• Director – Das ist sozusagen der Chef. Er steuert jeweils mindestens einen der folgenden Daemons.
• File-Daemon – Läuft auf allen Maschinen die was zu sichern haben.
• Storage-Daemon – Läuft auf allen Maschinen, die was auf ein Sicherungs-Medium schreiben können.

Bacula läuft grundsätzlich einmal unter Linux. Es gibt zwar einen Windows Port, aber die Homepage sagt selber, daß man dort nur der File-Daemon, oder besser gesagt File-Service laufen lassen sollte. Für Apples OS X gibt es auch etwas namens Fink, daß so etwas wie eine Debian Umgebung in OS X einbaut. Zumindest habe ich das auf die Schnelle so verstanden. Vielleicht kann man es mit cygwin unter Windows vergleichen. Mal sehen – was ich da noch herausfinde.

Im Augenblick schaut der Plan so aus, daß ich auf einer Linux-Kiste einen Samba- oder NFS-Share des Apfels mounte und meine Backups einfach dort hin schreibe. Sollte ich den Storage-Daemon direkt am Apfel zum laufen bekomme, noch besser, aber im Moment muß ich mit der Krücke leben.

Soweit der Plan – Jetzt zum Test.

Dazu habe ich meine VirtualBox-Debian-Installation 3x geklont und mit einem internen Netzwerk¹ verbunden. Die Debian Minimal-Installation kommt ohne weiteres mit 128MB aus und 5 Maschinen (zum Testen habe ich die virtuelle W2K und SuSE dazugenommen) bringen meine Kiste zwar ein wenig zum stottern, laufen aber noch problemlos.

Bacula geht in der Default-Konfiguration zwar davon aus, daß man auf eine Platte, genauer ein temporäres Verzeichnis sichert, behandelt das aber im Grunde genommen wie ein Band. Das hat mehrere unangenehme Nebeneffekte:

• Alle Sicherungen, sowohl Folgesicherungen von der gleichen Maschine, wie auch die anderer Maschinen landen in einer Datei. Das ist mir irgendwie zu gefährlich. Ich will nicht irgendwann mit einem 6TB großen File dastehen. Außerdem will man vielleicht einmal eine Sicherung nochmals wo anders hinkopieren.
• Die Sicherungen werden nacheinander ausgeführt. Bei Bändern ist das einfach so, aber ich sichere auf eine, eigentlich auf einen ganzen Haufen Platten. Da soll das Ding das Netz dicht machen und schauen, daß die Daten wegkommen.

Ohne all zu sehr in die Details zu gehen sind beide Probleme leicht zu lösen. Als erstes definiert man am Director und am Storage-Daemon für jede zu sichernde Maschine ein seperates Storage-Device. Dadurch könnten alle gleichzeitig sichern. Dann definiert man für jede zu sichernde Maschine zumindest einen eigenen Pool und sagt dem Ding, daß es jedesmal auf ein neues Medium, also eine neue Datei schreiben soll. Zumindest, weil man, wenn man so wie ich Tages-, Wochen- und Monatsicherungen haben will, 3 Pools für jede zu sichernde Maschine braucht. Die Tagessicherungen werden 14 Tage, die Wochensicherungen 10 Wochen, und die Monatsicherungen 2 Jahre aufbewahrt.

Was mich jetzt wirklich interessiert ist wie ich die Daten wieder zurückbekomme. Aber das heb’ ich mir für morgen auf. 16 Stunden bacula sind genug.

1. Virtualbox Bezeichnung für ein virtuelles Netzwerk zwischen mehreren virtuellen Maschinen

Keine Ahnung was das genau macht, aber jetzt geht auch mein Communicator. Auf die Idee bin ich nicht gekommen, daß es da noch was gibt, was ich im Nokia einfach nicht einstellen kann. Die Google-Suche ergab damals auch nicht, weshalb ich mich einfach damit abfand.

Bei der Suche nach keywords aus der Xandros-Config des eeePC wurde ich dann aber fündig und nachdem ich es richtig eingestellt hatte ging’s. Auch mit dem Communicator.

Test – kennt nur 1GB, läuft aber.

Das Problem ist bekannt, aus irgendeinem Grund kennt der Original-Kernel nur ein GB.

Den Kernel zu tauschen ist ein wenig aufwendig, da er auf einer seperaten Partition liegt auf die man im normalen Betrieb nichts schreiben kann.

1. Kernel holen
2. Kernel auspacken!
3. Im Single-User Mode hochfahren.
4. Platten mounten.
5. Kernel kopieren.
6. /boot/grub/menu.lst editieren.
7. Platten unmounten!
8. Neustart!

Genaue Anleitungen gibts sowohl in Deutsch wie auch (nona) in Englisch in der allwissenden Müllhalde. Das Fette stand allerdings nicht dabei, weshalb ich es eben fett gemacht habe.

Cool, wenn man Firefox, Thunderbird, OpenOffice Writer, Calc und Impress offen hat und trotzdem noch 68% RAM frei sind.

• Normaler KDE Desktop.
• Bluetooth (via USB-Dongle)
• Surft auch über’s Handy.
• Kennt einige zusätzliche Repositories.
• Regelt den Lüfter temperaturabhängig.

Außerdem hab’ ich ein halbwegs gewohntes Environment.

• Thunderbird.
• Firefox mit GSpace- und GMail Plugins. Dummerweise stellt Google mein geliebtes Google-Browser-Sync Plugin ein und ich kann es nicht mehr downloaden.
• Picasa.
• VLC.
• OpenOffice.

Außerdem habe ich mir einen (WLAN-)Router bestellt in den ich meine A1-PCMCIA-Karte reinstecken kann. D.h. im Leger gibts in Zunkunft bei Bedarf auch Wireless LAN.

Und welche RAMs ich brauche weiß ich auch schon.

Im Büro angekommen, nachdem ich den Schirm getauscht hatte, öffnete ich die Schachtel, die gerade ein wenig größer als ein Telefonbuch ist. Darin fand ich folgendes:

• 920g eeePC
• Akku
• Steckernetzteil
• Neopren-Tasche
• Schnellstart-Anleitung
• Handheft
• DVD
• Werbung

Die Geschichte mit den Akkus kennt man ja von anderen Laptops, also einpflanzen, Anstecken, einschalten.

Als erstes fragt er mich wer ich bin und nach einem Passwort und ob er mich beim Einschalten automatisch anmelden darf. Kurz danach meldete sich der Xandros-Desktop. Der wiederum ist in Tabs für die verschiedenen Anwendungsgruppen (Internet, Spiele, Multimedia, etc.) organisiert. So etwas wie ein Start-Menü gibt es nicht.

Einiges der Anwendungsfülle sind in Wirklichkeit nur Bookmarks, die mithilfe von Firefox entsprechende Webapplikationen (Wikipedia, Google-Docs, etc.) starten. Aber es gibt auch ein OpenOffice, Amarok, Pidgin, usw.. Die entsprechenden Icons sind aber nicht mit dem tatsächlichen Namen der Applikation versehen sondern wurden in der Regel nach Ihrer Funktion benannt. So heisst der Amarok z.B. Musik-Manager.

Mein Wireless-LAN wurde sofort gefunden und Testweise habe ich gleich einmal mein GMail Konto aufgemacht um zu sehen wie schnell der Firefox auf diesem Baby die Seite rendert. Überraschend flott! Youtube im Vollbild-Modus, auch kein Problem.

Das Ding hat:

• 3 USB-Anschlüsse
• Slot für SD und MMC Karten.
• Webcam
• Anschlüsse für Microphon und Kopfhörer
• LAN
• VGA
• Microphon
• Status-LEDs
• Reset-Taste
• Ein/Aus Taste
• Touchpad mit einer Wippe für linke und rechte Maustaste.

Der 7″ Schirm (800×480), hat wie alle zu kleinen Bildschirme eine hervorragende Bildqualität.. Das Touchpad ist mit der größe einer Sondermarke ein wenig klein, lässt sich aber gut bedienen. Einzig auf den Klick-Klopfer reagiert etwas unsensibel.

Klappt man das Ding im Betrieb zu, geht es in den Schlummer-Modus. Beim Aufwachen, muß man aber das WLAN wieder auswählen und aktivieren. Dafür steht der Rechner immer noch in den Programmen in denen man war.
Eine Shell bekommt man mit Ctrl-Alt-T.

USB und SD-Medien werden im Home eingebunden und zeigen für jede auf dem Medium vorhande Partition ein Verzeichnis an.

Schade, daß das Ding keinen Line-Out hat. In Verbindung mit einer 2,5″ USB-Platte und ordentlichen Brüllwürfeln, wäre das die perfekte Musicbox für unterwegs. Die eingebauten Lautsprecher sind naturgemäß etwas lahm.

Bluetooth fehlt! Damit könnte man jedes moderne Händy zum surfen mißbrauchen. So ist man auf vorhandene Infrastrukur angewiesen oder muß eben einen USB-Zumpel mitnehmen.

XP könnte ich installieren, werde ich aber nicht. Wenn schon, dann eher Debian. Aber im Augenblick bin ich mit dem Xandros eigentlich zufrieden. Einzig, bei manchen Applikations-Dialogen (z.B. Firefox Einstellungen), ist der Schirm vertikal zu klein wodurch man das untere Ende des Fensters nicht mehr sieht.

Der Paketmanager ist depeneinfach und fast schon zu übersichtlich. Wie robust er ist wird sich weisen.

Auf jeden Fall ein nettes Spielzeug. Folgendes möchte ausprobieren:

• USB-Bluetooth Adapter zum surfen.
• Falls das nicht geht, USB-Zumpel.

Was für einen Sinn hätte so ein wirklich portables Gerät, wenn es dann nicht ohne fremde Hilfe in’s Netz kommt.

Der Artikel OpenLDAP on Debian ist ausführlich und funktioniert ganz einfach.

Vor der Anwendung sollte man ihn und vor allem die Kommentare einmal durchlesen.

Genialer weise funktioniert das Ganze wirklich! Ganz im Gegensatz zu YaST Modulen die einem mit einer Konfiguration im Regen stehen lassen, die ganz einfach nicht funktionieren kann.

• Aliase wie “la”, “ll”, “md”, “rd”, “..” und “…”.
• Shortcuts wie “rcapache” anstelle von “/etc/init.d/apache”.
• Das das ~/bin Verzeichnis, so ferne es existiert im PATH ist.

Da geht am Anfang einmal gar nix… Möchte man meinen.

Stimmt nicht ganz. Für root geht nix. Für normale User ist die Umgebung schon etwas freundlicher. Debian geht einfach davon aus, daß root eben zu Recht root ist und schon weiß wie er sich seine Betriebssystem-Umgebung zurecht bastelt.

apt-get install bash-doc

Liefert dann auch noch gleich einen Haufen netter Beispiele in’s /usr/share/doc/bash/examples. Sowas wie den IKEA-Katalog für Commandline-Junkies.

Das ist die eine Seite der Medaille.

Die Andere ist das Problem ist, daß manche Tastenkombinationen nicht so funktionieren, wie ich es gewöhnt bin. Das lässt sich durch einen teilweisen Import der /etc/inputrc aus der letzten SuSE beheben.

Die Shortcuts sind relativ einfach zu lösen. Das geht mit einem Shell-script, daß im init.rd nach allen ausführbaren Dateien sucht, einen ganzen Haufen rausfiltert und dann die entsprechend benannten symbolischen Links im /usr/local/bin erzeugt. Das Ding muß ich halt immer wieder einmal anwerfen, wenn ein Service dazugekommen ist.

Vielleicht lehne ich mich jetzt ja ein wenig weit aus dem Fenster. Aber das ist vielleicht einer der Gründe, warum sich Dinge wie der SLES verkaufen. Nicht jeder Administrator hat Lust sich mit den Innereien der bash herum zuschlagen. Der hat einfach den klaren Auftrag einen Service wie Mail oder Web zum Laufen zu bringen. Aber wenn man die Wahl zwischen der Bequemlichkeit einer SuSE SLES Commandline und dem rohen Gerüst einer Debian-Bash hat, verstehe ich warum die Leute ihren Brötchengeber hemmungslos Geld ausgeben lassen. Natürlich hat ein SLES noch andere Vorteile… Bestimmt – ich bin mir ganz sicher – sagen ja alle… Nur ich habe sie noch nicht gefunden. Hab’ aber auch nicht danach gesucht.

Fazit:

Will man es sich auf einer neuen Debian Installation gemütlich machen, kann man entweder /usr/share/doc/bash(/examples) durchkauen, oder nur hemmungslos bei einer einem bequemen erscheinenden Installation klauen. Die Ansatzpunkte sind /etc/bash.bashrc(.local) und /etc/inputrc.

Die von den subversion empfohlene Methode einen entsprechenden Server zu betreiben ist die Variante über http und webDAV.

Soweit bin ich aber noch nicht.

1. Ist die Apache Installation zwar eine meiner geringsten Sorgen, aber definitiv eine mit dem meisten Konfigurationsaufwand. Also etwas, daß ich ganz bestimmt subversion anvertrauen möchte.
2. Ist die Konfiguration von den entsprechenden Apache Modulen svn und dav doch noch ziemliches Neuland für mich. Also auch etwas, daß ich ganz sicher lieber unter subversions Aufsicht machen würde.

Aber egal, es gibt ja noch den svnserve. Dummerweise nichts, was nach einem startscript á la /etc/init.d/svnserve aussieht. Die Debian Doku in /usr/share/doc/subversion verweist freundlich auf das subversion-Buch (das eh frei und offen im InterNetz liegt), aber was wenn ich gerade kein InterNetz habe? Ok, daß ist ein Problem der Weltanschauung.

Da ich bei den Repositories nicht mit mehr als 2 Millionen Zugriffen pro Stunde rechne, entscheide ich mich dafür den svnserve über xinetd zu starten. Damit kann ich auch gleich einschränken welche Rechner darauf zugreifen können.

service svn { socket_type = stream protocol = tcp user = svn wait = no disable = no server = /usr/bin/svnserve server_args = -i -r /srv/svn/ port = 3690 }

Der User svn ist ein system user und kann sich so gar nicht anmelden. xinetd durchstarten und mit telnet ausprobieren, eh klar.

Jetzt kommt das richtige Herzflattern.

Natürlich will ich auch mein /etc unter subversion verwalten. Dazu braucht es erst einmal ein entsprechendes repository.

cd /SVNROOT<br /> svnadmin create MYetc

Ok, jetzt muß das etc einmal in das repository eingecheckt werden.

cd /etc<br /> svn import svn file:///SVNROOT/MYetc<br /> cd /<br /> tar -czvf etc.tar.gz etc

Panik!

rm -r etc
mkdir etc
cd etc
svn checkout svn://localhost/MYetc .
ls -l

Pheew! Alles wieder da. Das /etc.tar.gz hebe ich mir trotzdem an einem sicheren Ort auf.

Skurriles Detail am Rande:

Debians Idee von subversion verwendet nano als Standard-Editor. Also in meiner Welt verwendet jeder der sich eine Debian antut entweder vi(m) oder Emacs. So was einfaches wie nano könnte ja jeder bedienen.