Tag Archives: HowTo

Branches und Merges mit Subversion 1.5

Nachdem letzte Woche der RC 5 von Subversion 1.5 veröffentlicht wurde, beschreibt Ben Collins-Sussman heute in seinem Blog ganz kurz das Feature von Subversion 1.5, auf das viele warten. Subversion 1.5 behält selbst ein Auge auf Branches und Merges und macht das Arbeiten mit Branches damit um einiges leichter. Er demonstriert dies an einem beispielhaften Arbeitsablauf:

1. Make a branch for your experimental work:

$ svn cp trunkURL branchURL
$ svn switch branchURL

2. Work on the branch for a while:

# ...edit files
$ svn commit
# ...edit files
$ svn commit

3. Sync your branch with the trunk, so it doesn’t fall behind:

$ svn merge trunkURL
--- Merging r3452 through r3580 into '.':
U button.c
U integer.c

$ svn commit

4. Repeat the prior two steps until you’re done coding.
5. Merge your branch back into the trunk:

$ svn switch trunkURL
$ svn merge --reintegrate branchURL
--- Merging differences between repository URLs into '.':
U button.c
U integer.c

$ svn commit
6. Go have a beer, and live in fear of feature branches no more.

Wenn man bedenkt, wie aufwändig manuelles Merging bei Subversion vorher war, könnte das jetzt kaum einfacher sein. Man musste in den Commit-Messages die Revisionsnummern mitloggen und aufpassen auch ja die richtigen Sachen von einem Branch in den anderen zu tun. Jetzt brauch man sich um die Revisionsnummern nicht mehr kümmern, das wird alles wegfallen, super coole Sache!

Flexibles Issue Tracking mit roundup

Fuer den Einsatz in der Firma suche ich derzeit ein Bug- und Issue-Tracking-System. Nicht ausschliesslich fuer unsere Engineeringabteilung, sondern auch fuer die Jungs vom Service, die die Hilfeschreie entgegennehmen, wenn der Kunde (fliegendes Personal, und damit extrem ungeduldig) ausnahmsweise mal nicht von der Runway wegkommt.

Eins ist klar: Es muss Open-Source sein. Zum einen will ich nicht erst eine ellenlange Begruendung fuer die Finanzbuchhaltung schreiben, warum sie bitte schoen n+1 Euro fuer eine Software ausgeben sollen, deren Nutzen fuer die Firma sie ohnehin (wieder mal) nicht korrekt quantifizieren koennen. Zum anderen will ich nicht erst mit m+1 Vertrieblern von irgendwelchen Softwarebuden quatschen, die mir ihre “Marktfuehrer”-Loesung aufschwatzen wollen. Aber noch viel wichtiger: Ich will schnell mal eben was aendern koennen, wenn das Tagesgeschaeft es notwendig macht!

Also dann, Wikipedia ist mein Freund, und auf in die taktische Aufklaerung auf dem Softwarefeld: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems listet einen ganzen Wald von Optionen auf. Neben dem eierlegenden Wollmilchborstenviehmoloch “Bugzilla” existieren viele nette kleinere Systeme, die zwar nicht so dick auftragen, die dafuer aber umso schneller und wartbarer sind und fuer deren man Evaluierung man nicht erst im RDBMS herumfuhrwerken muss (bravo!). Web- und Email-Frontends sind anscheinend per stiller Konvention ohnehin ueberall dabei (wobei ich das Email-Frontend derzeit ueberhaupt nicht brauch’).

Besonderen Gefallen habe ich an Roundup gefunden, der ist nicht nur sehr flink, sondern vor allem sehr vielseitig. Eine der Uebersetzungen von Roundup aus dem Englischen ist “Razzia”, und dem Namen macht das kleine Softwarepaket alle Ehre: Neben PostgreSQL und MySQL kann Roundup auch mit sqlite umgehen, das macht das Testen sehr bequem; es bringt seinen eigenen Webserver mit, fuehlt sich aber im mod_python-erweiterten Apache2 genauso daheim; es laesst sich als Bugtracker, Trouble-Ticket-System, ToDo-Liste, persoenliche Zeiterfassung und sogar als Kaffeemaschine konfigurieren. Okay, die Kaffeemaschine ist jetzt gelogen, aber ich wette, lange dauert’s nicht mehr, dann gibt’s auch das! Nettes Feature: Pro Eintrag in die Issue Liste wird eine kleine Mailingliste angelegt, so dass alle Beteiligten/Interessenten ohne viel Aufwand verfolgen koennen, wie sich ein Problem seiner Loesung naehert.

Am besten gefaellt mir bei der Arbeit mit Roundup die Dokumentation, die mit Beispielen nicht geizt, wie man unkompliziert Erweiterungen am Datenbankschema und an den Eingabemasken und Ansichten vornehmen kann: http://roundup.sourceforge.net/doc-1.0/customizing.html. Die Beispiele wirken allesamt wie direkt aus der Praxis entnommen und geben selbst einem Python-Laien wie mir in kuerzester Zeit das Gefuehl, die Dinge wirklich in der Hand zu haben. Innerhalb eines Tages ist es mir gelungen, einen Protoypen zu basteln, in den wir exemplarisch mal ein paar der Bugs der letzten Wochen eingetragen haben. Der Tag Arbeit schliesst eine Customization der CSS-Stylesheets auf unsere Firmen-CI genauso mit ein, wie das Erstellen von automatisierten Reports ueber den Lebenszyklus von Kundenanfragen und Fehlermeldungen fuer die Geschaeftsleitung. Und demnaechst wird auch die Serviceabteilung angebunden, kann ja nicht laenger als einen Tag dauern. ;-)

Fazit: Ich frage mich, warum ich mir ueberhaupt andere Systeme angeschaut und nicht stattdessen gleich Roundup genommen habe. Hier finde ich alles, was ich brauche, um meinen Job zu erledigen, ohne viel Zeit von den Hauptaufgaben abzuzwacken. Ich wuenschte, es waer immer so einfach! Und ich komme von meinem Vorurteilen ueber Python weg, der Produktivitaetsgewinn macht die infantile Syntax locker wieder wett. ;-)

Grub auf mehreren Festplatten

Leute spielen mit Eisenbahnen, sammeln Briefmarken oder züchten Rosen. Ich probiere neue Betriebssysteme aus und pflege verschiedene Installationen für den einen oder anderen Zweck. In einem Testrechner sind hier drei Festplatten verbaut, alles alte Dinger, aber genug Platz für mehrere Betriebssysteme.

In diesem speziellen Fall sind auf der ersten Platte (80 GB) Windows 98 und XP installiert sowie ein Ubuntu und ein Eisfair-1. Auf der zweiten Platte (40 GB) residiert ganz allein ein Debian Etch als Host für Xen und last but not least ist auf der dritten Platte (4 GB) noch Platz für eine Beta-Version von Eisfair-2. Wäre nur die erste Platte eingebaut, hätte ich kein Problem. Ubuntu benutzt Grub und Grub erkennt bei der Installation andere Systeme. Ubuntu selbst und das Eisfair-1 von der ersten Platte starten ohne Probleme, Ubuntu hat die Hand auf dem Bootloader und aktualisiert bei Kernel-Updates seine eigenen Einträge. Die beiden Windosen lassen sich über chainloader ebenfalls problemlos booten.

Interessant wird es mit Betriebssystemen auf den anderen beiden Platten. Die bringen für gewöhnlich ihren eigenen Bootloader mit und verwalten die entsprechenden Einträge bei Kernel-Updates oder ähnlichem auch selbst. Der neue Eisfair-Installer schreibt sich in den MBR der Platte, wo das System landet, in dem Fall die dritte Platte hdc. Debian lässt einem da mehr Freiheit, aber in Frage kommen im Prinzip nur der MBR von der zweiten Platte (hdb) oder direkt die Bootpartition /dev/hdb1. Will ich die Systeme booten, kann ich natürlich die Namen, Orte und Optionen der Kernel von Hand bei jedem Update in die Grub-Konfiguration des Ubuntu auf hda eintragen, aber das ist mir ehrlich gesagt zu umständlich.

Die nächste Möglichkeit ist der bereits erwähnte chainloader. Ja, aber… der funktioniert nur, wenn z.B. Debian seinen Bootloader an den Anfang einer Partition und nicht in den MBR schreibt. Ich habe es nicht hinbekommen, mit dem chainloader sozusagen den MBR einer anderen Platte zu starten. Klar, ich könnte jedesmal ins BIOS und die Bootplatte umstellen, aber das ist mir dann auch zu umständlich.

Heute habe ich eine weitere Möglichkeit herausgefunden. Es ist aus dem Grub-Menü heraus möglich, eine andere Grub-Config zu laden. Anstatt eines langen Eintrags mit kernel usw. reicht dann folgendes:

title       hdb: Debian
configfile  (hd1,0)/grub/menu.lst

Trage ich das bei den zusätzlichen Systemen in die /boot/grub/menu.lst meines Ubuntu ein, kann ich ganz locker die menu.lst laden, die unter der Fuchtel des Debian auf der zweiten Platte steht. Umgekehrt geht’s natürlich auch, so dass ich munter hin und her springen kann, auch zu dem Grub vom Eisfair-2 oder zurück zum Debian-Bootmenü und von da wieder zum Bootmenü vom Ubuntu und wenn ich dann vom Umherspringen in meinen Grub-Menüs genug habe, boote ich einfach das System, das ich will.

Subversion Relocate mit Eclipse und TortoiseSVN

Wir sind vor einigen Tagen mit unserem Projekt IMPULS von Sourceforge auf unseren eigenen, diesen Webserver umgezogen. Das heißt, wir haben nicht nur die Homepage migriert und ein Trac eingerichtet, sondern auch das Subversion-Repo verschoben. Für ausgecheckte Working Copies ist dann ein sogenannte Relocate fällig. In Verbindung mit Eclipse kann man da auf die Nase fallen.

Subversion mit Eclipse ist eigentlich erstmal kein Problem. Es gibt Subclipse und da funktionieren Checkout, Update, Commit usw. wunderbar. Rechtsklick auf auf’s Projekt, »Team« angeklickt und los geht’s – leider ohne Relocate. Wenn ich das jetzt einfach außerhalb von Eclipse machen würde, zerschieße ich mein Projekt, weil in den Projekteinstellungen der Pfad auf’s Repository vermerkt ist. Es gibt aber eine Lösung. Zunächst vergewissern wir uns, welche URL grad für das Projekt angegeben ist:

Subversion Pfad in Projekteinstellungen

Hier ist also noch der alte Pfad des Repos bei Sourceforge eingetragen. Der nächste Schritt in der Punkt »Disconnect« im bereits erwähnten Menü »Team«. Draufklicken und dann kommt folgender Dialog. Dort bestätigt man mit der Option, die Subversion-Dateien zu behalten.

Disconnect im Menü »Team« von Eclipse

Dann kommt das eigentliche Relocate. Das geschieht unter Windows am einfachsten mit TortoiseSVN, wie im folgenden Bild zu sehen ist. Natürlich kann man hier auch die Kommandozeilenversion von Subversion benutzen, wenn man grad kein TortoiseSVN zur Hand hat. Wie das geht, steht im Subversion-Buch.

Relocate mit TortoiseSVN

Der letzte Schritt besteht darin, dem Projekt in Eclipse wieder beizubringen, dass es eigentlich ein mit Subversion verwaltetes ist. Dazu wieder ein Rechtsklick auf das Projekt und im Menü »Team« den Punkt »Share« und dann natürlich »SVN«. Subclipse erkennt, dass es sich bereits um eine korrekte Working Copy handelt und übernimmt den richtigen Pfad aus Schritt drei. Nur noch einmal den folgenden Dialog abnicken und fertig ist die Laube.

Subversion Working Copy Eclipse wieder bekannt machen

Ausgabeprofil »LaTeX => HTML« für TeXnicCenter

Angenommen ich möchte ein LaTeX-Dokument mit tex4ht in HTML umwandeln und benutze TeXnicCenter als Editor für das eigentliche Dokument. Da liegt es nahe, sich ein passendes Ausgabeprofil zu basteln, so dass man direkt aus TeXnicCenter die gewünschte Ausgabe produzieren kann. Man muss dabei aber aufpassen, was für Optionen man htlatex.exe mitgibt. Die folgenden zwei Screenshots illustrieren funktionierende Einstellungen.

Ideal wäre natürlich, wenn nicht jedesmal ein neuer Tab im Firefox aufgemacht werden würde, wenn man im TeXnicCenter F5 drückt, sondern der alte aktualisiert/ersetzt würde. Wenn da jemand einen Tipp hätte, wie man das realisieren kann, würde ich mich freuen.

Nicht das gesamte System verschlüsseln

Nach etwas oberflächlicher Recherche bin ich der Meinung, das Internet quillt über von Anleitungen zur Verschlüsselung ganzer Partitionen, ja ganzer Rechner (bis auf den MBR), mit allen Auswüchsen, die man sich denken kann und auch noch Motivationen und Begründungen dazu. Verschlüsselung der root-Partition, LVM auf einem verschlüsselten physical volume, verschlüsselte logical volumes in ansonsten unverschlüsselten LVM Dingern, das ganze noch mit und ohne RAID oder mit /boot noch auf dem USB-Stick, wahlweise mit Keyfiles oder herkömmlichen Passwörtern usw. Die Ansätze zur Verschlüsselung sind ähnlich vielfältig: dm-crypt mit und ohne luks, das klassische loop-aes oder truecrypt, um nur einige zu nennen.

Ich will einfach nur unter Debian Lenny eine Datenpartition verschlüsseln, kein RAID, kein LVM, boot-, root- und swap-Partition dürfen auch unverschlüsselt bleiben und das ganze am besten ohne einen eigenen Kernel kompilieren zu müssen und ohne Installation mit Live-CD oder sonstigen Spielerchen.

Ich habe also HowTos, Tutorials und manpages gewälzt und die Wahl fiel auf dm-crypt mit luks. Das ist aktuell, es ist alles bei Debian schon dabei und der Kernel muss nich neu kompiliert werden. Kurz noch die Grundvorraussetzungen hier: /boot auf CF-Karte als hda1, root-Partition ist hdd1 und swap hdd2, die Daten sollen alle auf hdd3 landen. Die ganze Einrichtung spielt sich mit root-Rechten ab, da wir nicht bei Ubuntu sind, einfach als root einloggen dafür! Die ersten Schritte bestehen darin, die nötigen Kernel-Module zu laden und das Programm cryptsetup zu installieren:

modprobe aes
modprobe dm-crypt
modprobe dm-mod
aptitude install cryptsetup

Die Partition, die verschlüsselt werden soll, darf nicht gemountet sein, ein Mountpoint sollte für später vorhanden sein, einfach das gewünschte Verzeichnis anlegen. Bei mir wird das /mnt/data sein. Als nächstes wird die Partition für die Verschlüsselung vorbereitet und geöffnet, quasi dem Device-Mapper bekannt gemacht. An diesem Punkt bitte darauf achten, dass alle Daten, die sich noch auf /dev/hdd3 befinden, danach unwiederbringlich verloren sind.

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/hdd3
cryptsetup luksOpen /dev/hdd3 data

Beim ersten Aufruf wird nach einem Kennwort gefragt, das später als Schlüssel dient. Der zweite Aufruf öffnet sozusagen die verschlüsselte Partition, daher ist das Kennwort nochmal einzugeben. Jetzt kann man über /dev/mapper/data auf die verschlüsselte Partition zugreifen. Der erste Schritt: formatieren. Ich habe das ganze mit einer etwa 227 GB großen Partition und einem Pentium 133 getan. In der Zeit kann man ganz entspannt Kaffee kochen, trinken, die Kaffeemaschine sauber machen, Pizza backen, Pizza essen, den Ofen sauber machen…

mkfs.ext3 -v -L DATA /dev/mapper/data

Mounten klappt von Hand dann schonmal. Jetzt soll es noch so eingerichtet werden, dass die Partition auch beim Boot gemountet wird. Dazu werden die nötigen Kernelmodule, die vorhin von Hand geladen wurden in /etc/initramfs-tools/modules/ eintragen. Das sind

aes
dm-crypt
dm-mod
sha256

Danach nochmal die initrd neu bauen lassen mit

update-initramfs -u -k all

Als nächstes wird die /etc/fstab angepasst. Dort einfach /dev/hdd3 durch /dev/mapper/data ersetzen oder die Zeile neu anlegen. Weiterhin ist es noch nötig, die Datei /etc/crypttab anzupassen:

data /dev/hdd3 none luks,retry=1,cipher=aes-cbc-essiv:sha256

Das war’s. Das ist alles, mehr ist nicht zu tun. Beim booten wird man nach dem Passwort gefragt, der Rest läuft wie gewohnt. Noch ein Wort zur Performance: da nur die Datenpartition verschlüsselt ist, machen sich natürlich nur Zugriffe darauf bemerkbar. Kopieren mit rsync+ssh lastet den Rechner voll aus, das war vorher auch schon so, da ssh hier den Prozessor bereits zu voller Auslastung treibt. Mit zusätzlicher Verschlüsselung der Datenpartition sieht das in top dann so aus, als würden ssh und kcryptd/0 zu ungefähr gleichen Teilen für die CPU-Last verantwortlich sein. Mehr Aussagen kann ich dann machen, wenn die Daten wieder zurückgeschrieben sind, morgen oder übermorgen…

Alter schützt vor Treibern nicht

Mein aktuelles Bastelprojekt ist ein alter Rechner. Eingebaut ist ein Pentium mit 133 MHz, ein wenig EDO-RAM, eine alte Soundkarte vom Typ Terratec Base 1, 3com Netzwerkkarte und eine große Festplatte, auf der Daten gesichert werden. Für Konsole reicht das gut hin und Musik kann er auch abspielen. Installiert hatte ich Debian Etch.

Die Kiste hängt an einem 17″-Röhrenmonitor, eine Konsole mit 80×25 Zeichen ist nett, aber 800×600 Pixel sind locker drin – immerhin 100×37 Zeichen. Damit lässt sich gut chatten, für E-Mails ist genug Platz und auch im Midnight Commander steigt die Übersicht. Das ganze steht und fällt mit dem dafür nötigen Betrieb der Grafikkarte im Framebuffer-Modus. Bei neuen Karten geht das leicht über den VESA-Treiber, einfach vga=789 an die Kernel-Optionen von Grub angehängt und fertig. Leider ist in dem Rechner eine alte S3 Trio64V+ eingebaut und die unterstützt der VESA-Treiber nicht.

Zum Glück gibt es noch andere Framebuffer-Treiber. Bei der ersten Recherche im Netz stellte sich aber Ernüchterung ein. S3 nur für PPC oder Amiga, warum auch immer. Dann stieß ich auf eine erst ein paar Monate alte Neuigkeit. Da hatte doch tatsächlich jemand für Kernel 2.6.21 noch einen neuen Treiber für die Karte geschrieben. Ich finde das reichlich bemerkenswert, schließlich reden wir hier von einer Grafikkarte aus den späten Neunzigern!

Der Ehrgeiz war geweckt, jetzt galt es das Ding zum Laufen zu bringen. Zunächst schaute ich, was nach Debian Etch an Kernel-Versionen bereit stand. Der aktuelle Testing-Zweig bringt 2.6.22 mit, also machte ich ein Dist-Upgrade von Etch nach Lenny. Das war nicht weiter aufregend, allerdings noch nicht alles. Um den Treiber jetzt auch zu benutzen waren (als root!) folgende Schritte notwendig:

  • s3fb in die Datei /etc/initramfs-tools/modules eintragen
  • update-initramfs -u -k all
  • in /boot/grub/menu.lst die entsprechende Zeile wie folgt ändern:
    # defoptions=video=s3fb:800x600@85

Anschließend neu booten und freuen. Der Rechner läuft tatsächlich mit Framebuffer-Konsole auf S3 Trio64V+.

happy

Backup auf DVD-RAM

Ich hatte am Sonnabend an den Build-Skripten für meine Eisfair-Pakete geschraubt. Sonnabend ist auch einer von zwei Tagen in der Woche, wo mein Heimserver Backups macht, die ich für gewöhnlich auf DVD-RAM kopiere. Da das immer die gleichen Arbeitsabläufe sind und ich gerade drin steckte im Programmieren, hab ich mir für das Backup ein kleines Skript geschrieben, das diese Arbeitsabläufe auf den Aufruf des Skriptes zusammenfasst. Das Skript mal gekürzt:

#!/bin/sh
. /var/install/include/eislib
mecho -info "Mounting DVD..."
mount -t udf /dev/cdrom /cdrom
mecho -info "Removing old backup..."
rm -f /cdrom/backup-zip/*
rm -f /cdrom/svn/*
mecho -info "Getting free space from DVD... "
DVDFREEMB=`df --block-size=M | awk '//dev/cdrom/ {print $4}'
    | sed -e 's/(^[0-9]*).*/1/'`
mecho -info "Getting size of home dir backup..."
cd /mnt/data/backup/backup-zip/cron
CUMBUSIZE=0
for i in `ls -l --block-size=M | awk '/home_1/ {print $5}'
    | sed -e 's/(^[0-9]*).*/1/'`
do
	CUMBUSIZE=`expr $CUMBUSIZE + $i`
done
cd /mnt/data/backup
SVNSIZE=`du --block-size=M -s svn/ | cut -f1
    | sed -e 's/(^[0-9]*).*/1/'`
CUMBUSIZE=`expr $CUMBUSIZE + $SVNSIZE + 25`	# sicherheitsfaktor
if [ $CUMBUSIZE -gt $DVDFREEMB ]
then
	mecho -error "Backup is $CUMBUSIZE MB but only $DVDFREEMB MB are free on DVD. Aborting..."
	exit 1
else
	mecho -info "Backup is $CUMBUSIZE MB and $DVDFREEMB MB are free on DVD. Continuing..."
fi
# script continues with copying, cutting off here...

Das Debuggen wurde mir in diesem Fall künstlich erschwert, weil meine eine DVD-RAM allem Anschein nach jetzt kaputt ist. Das Backup selbst dauerte doppelt so lang wie normal mit diversen Fehlermeldungen vom UDF-Dateisystem im Syslog und bei der letzten Datei wurde wider Erwarten abgebrochen mit der Meldung es sei nicht genug Platz auf dem Datenträger. Mehrfaches Neuformatieren hat nichts gebracht. Das ist eine beinahe schockierende Erkenntnis, gelten DVD-RAM-Medien doch als wesentlich sicherer für Backups als herkömmliche DVD±RW. Das Backup lief mit einem frischen Medium dann in einer guten Stunde durch.

Eine andere Sache ist das Skript selbst nochmal. Ich lasse mir von den unterschiedlichen Tools Speicherplatz in Megabyte ausgeben, d.h. die Angaben sind beispielsweise “512M”, also immer eine Zahl mit dem “M” dahinter. Mangels tiefergehender Kenntnisse in awk jage ich das weiter an sed wo ich dann mit einem regulären Ausdruck alles hinter den Ziffern entferne. Das ist ja nun schlechter Stil, normalerweise sollte awk das direkt selbst machen können, d.h. in die geschweiften Klammern muss nicht nur “print” rein…
Wenn jemand eine Idee hat, wie das zu bewerkstelligen ist, bitte ich Euch es mich wissen zu lassen!