An sich verwende ich seit Jahren nur mehr shell-scripts zur Datensicherung aber die Umstände zwingen mich leider dazu mich nach einer Alternative umzusehen.

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 [↩]

Bei der WPA Verschlüsselung für WLANs gibt es zwei Arten des Pairings, AES und TKIP. D-Link verwendet bei den aktuellen Modellen per default AES, was der eeePC aber noch nicht kann. Deshalb geht es nur mit TKIP, was man am Access-Point bzw. Router umstellen muß.

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.

Mit dem neuen Kernel funktionierte auch der HUAWEI E160 vom Hofer mit der Yesss Karte auf Anhieb.

Vor einer Stunde gekauft (<€40,-) und läuft schon. Deckel aufschrauben, Riegel tauschen. zuschrauben.

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.

Nach einigen Stunden surfen und hacken habe ich das Ding jetzt soweit, daß ich mich ein wenig wohler fühle.

• 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.

Bei einer Kollegin ist der Bildschirm eingegangen, weshalb ich zum Saturn in der SCS düste um Ersatz zu besorgen. Auf der Suche nach geschultem Verkaufspersonal (ich wollte eigentlich einen Schirm mit eingebauten Lautsprechern) wanderte ich durch die Regale und da lag das kleine nette Teil über das wir im Freundeskreis schön öfter gesprochen hatten. Der Asus eeePC, in weis aber irgendwie nett. Da die Kontosituation es im Moment erlaubt und die veranschlagten € 279,- auch nicht die Welt sind, nahm ich das Ding mit.

Weiterlesen »

Hut ab!

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.

Nach (was weiß ich wievielen) Jahren SuSE, habe ich mich einfach an einige Dinge gewöhnt.

• 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.

Es hat sich in den letzten Jahren als recht praktisch erwiesen verschiedene Konfigurations-Dateien und andere Dinge in einem Versionskontrollsystem zu verwalten. Ich habe mich irgendwann für subversion entschieden und will auch auf meinem neuen Server einen entsprechenden service laufen lassen.

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.

Ich will eine LAMPe mit sendmail. Ich brauche keinen XServer, will aber xterm verwenden. Natürlich SSH und von einigen ganz bestimmten Rechnern aus auch telnet, damit ich falls notwendig den sshd durchstarten kann. Ich will eine Firewall, damit ich diverse Dictionary- und DOS-Attacken im Zaum halten kann.

Und ich will LDAP um meine User in allen Varianten dagegen zu authentisieren. Das das mit dem OpenLDAP der bei der 10er SuSE dabei ist nicht geht, ist der eigentlich Grund warum ich wiedereinmal bei Debian gelandet bin.

Hürden:

Nach der (hoffentlich erfolgreichen) Netzwerk-Installation, sollte man die CD aus der /etc/apt/Sources.list entfernen, da sonst die Paketverwaltung immer wieder darauf zugreifen will. Blöd wenn man sich nicht mehr vor Ort befindet um die CD einzulegen.

Damit sendmail auf was anderes als das Loopback Interface hört, muß man in der /etc/mail/sendmail.mc aus der Zeile “DAEMON_OTIONS(….” die Addr=127… Werte herausnehmen.

Obwohl eine /etc/inetd.conf existiert ist weder inetd noch xinetd installiert. Also xinetd nach-installieren. Um telnet über xinetd zu starten muß man den entsprechende Block aus dem /usr/share/doc/xinetd/examples/sample.conf.gz kopieren und die bind Adresse anpassen (z.B. IP von eth0).

Damit ein xterm überhaupt laufen kann, braucht es das Paket xbase-clients und einige Einstellungen in der /etc/ssh/sshd_config.

Unbequemlichkeiten:

Unmittelbar nach der Installation kann man mit less noch keine komprimierten Dateien ansehen. Zum Glück habe ich die komplette SuSE 10.0 Installation auf eine USB-Platte kopiert bevor ich mit der SuSE 11.0 und in der Folge der Debian Installation begonnen habe. Also konnte ich mir das /usr/bin/lessopen.sh und /usr/bin/lessclose.sh von der SuSE klauen und die entsprechenden Variablen in /etc/profile exportieren (LESSOPEN=”/usr/bin/lessopen.sh %s”, LESSCLOSE=”/usr/bin/lessclose.sh %s %s”.

Was wirklich nervt:

Die Pakete haben oft alle falsche Namen. Verständlich, nachvollziehbar, aber trotzdem Scheiße. Will man zum Beispiel den OpenLDAP Server installieren muß man das Paket slapd installieren. Stimmt schon, der eigentliche Server heißt ja auch so. Aber wenn man in aptitude danach sucht, kann man schon wahnsinnig werden. Das Ganze setzt sich natürlich fort, weil die Doku steht natürlich auch in /usr/share/doc/slapd und nicht in einem Verzeichnis wie openldap, *ldap* oder open*. Da suchst Dich auf einen Trottel…

Skurriles:

Die Standard-Installation bietet zwar den info Befehl, aber um die eigentlichen info-Dateien zu bekommen muß man erst in /etc/apt/sources.list die “non-free” Äste aktivieren und nach apt-get update das Paket texinfo-doc-nonfree installieren.

Fortsetzung folgt….