Netz - Rettung - Recht

Ein weiteres nettes Feature von git sind die Möglichkeiten, die git archive bietet. So läßt sich der Inhalt eines git-Repositories leicht in ein tar-File packen, bspw. für ein Release.

Voraussetzung dafür ist beim Zugriff über git-daemon, daß der entsprechende Service aktiviert ist; für das Debian-Paket bedeutet das die Erweiterung des Aufrufs in /etc/sv/git-daemon/run um den Parameter "--enable=upload-archive".

Dann aber kann mit einem Aufruf wie

git archive --format=tar --remote=git://git.domain.example/$REPO.git --prefix=$PREFIX/ $TAG | gzip > $REPO.tar.gz

aus dem Repository $REPO.git dessen Inhalt bei Commit (oder an der Spitze des Branches, oder an dem Tag) $TAG in eine .tar.gz-Datei gepackt werden, wobei die Dateien ein $PREFIX vorangestellt bekommen.

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-2.17/ 2.17 | gzip > myprog-2.17.tar.gz

erzeugt also aus dem Repository myprog.git in der mit "2.17" getaggten Version eine Datei myprog-2.17.tar.gz, die alle im Repository enthaltenen Dateien mit dem Verzeichnis-Präfix "myprog-2.17/" enthält.

Das ganze läßt sich noch etwas aufpeppen, wenn man bspw. bestimmte Dateien (.gitignore, ...) aus dem Repository nicht im Tarball haben möchte und/oder noch andere Änderungen vornehmen will, wie bspw. die Erzeugung eines README aus der eingebetteten POD-Dokumentation:

Und schließlich kann man auf diese Weise auch nur eine einzelne Datei aus dem Repository extrahieren:

git archive --format=tar --remote=git://git.domain.example/repository.git master beispiel.txt | tar xf -

extrahiert die Datei beispiel.txt aus der Spitze des Branches master des Repositorys repository.git.

Ich finde das alles ausgesprochen praktisch.

Wie am Wochenende schon angekündigt, habe ich yapfaq in den letzten Tagen etwas weiterbearbeitet. Version 0.6 (bzw., aufgrund einiger kleiner Fehler im ersten Release, Version 0.6.2) enthält neben einigen kleineren Änderungen vor allem folgende Erweiterungen:

Variabler Expires:-Header

Die bisherige Version hat einen Expires:-Header von drei Monaten gesetzt; dieser Wert ist nunmehr konfigurierbar.

Kommandozeilen-Parameter

yapfaq nimmt jetzt einige Kommandozeilen-Parameter entgegen. So können mittels "-v" Informationen über den Programmablauf ausgegeben werden; mit dem Parameter "-f" kann die Abarbeitung auf die genannte FAQ beschränkt werden, yapfaq arbeitet dann also nicht alle FAQs ab. Außerdem kann mit "-p" das Posten aller - oder einer - FAQ(s) erzwungen werden, auch wenn diese eigentlich noch nicht fällig ist; am sinnvollsten ist das im Zusammenhang mit "-f". Die Parameter "-d" und "-t" ermöglichen Tests: "-d" führt zu einem reinen Simulationslauf, bei dem nichts gepostet wird, so daß bspw. getestet werden kann, welche FAQs zum Posten anstehen würden. "-t" ermöglicht es, die FAQ nicht in die eigentlich vorgesehene(n) Gruppe(n) zu posten, sondern stattdessen in eine Testgruppe oder auf die Konsole auszugeben, um zu prüfen, wie ein Posting aussehen würde.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

Perl bietet eine recht interessante und bequeme Art, die Dokumentation zu einem Script oder Modul in den Programmcode einzubetten: POD, "plain old documentation".

Dieses Format ermöglicht es, die Dokumentation jeweils beim Code einzubetten oder doch zumindest am Ende des Programmcodes in derselben Datei zu speichern. Diese Dokumentation kann dann mittels perldoc angezeigt oder mit Hilfe von entsprechenden Tools in andere Formate - Klartext, HTML, man pages etc. - konvertiert werden, so daß die Dokumentation aus dem Sourcecode selbst erzeugt werden kann.

Mehr Informationen dazu:

• perlpod man page
• perldoc man page
• podlators (translators from POD to text and nroff from Russ Allbery)
• pod2text man page
• pod2html man page
  

Nachdem ich mich jetzt bereits einige Wochen mit git auseinandersetze, ist es vielleicht einmal Zeit für ein Fazit. Ich mag mir kein fachkundiges Urteil über git erlauben; dazu fehlt mir der wirkliche Vergleich mit anderen Versionsverwaltungssystemen und die Erfahrung mit (gemeinsamer) Softwareentwicklung, und letztlich auch der wirklich "fortgeschrittene" Umgang mit git. Ich denke aber, daß ich - obschon ich git bisher "solo" nutze, also zu seinen Stärken und Schwächen bei der Zusammenarbeit selbst nichts sagen kann - durchaus einige Punkte benennen kann, die mir an git gut gefallen.

Da wäre auf den ersten Blick bereits die Verzeichnisstruktur: wo SVN mich mit trunk, tags und branches verwirrt, gibt es bei git ein Verzeichnis .git, und das war’s.

Auch zunächst eher eine Äußerlichkeit, aber sehr bequem, ist die Möglichkeit, mit git "offline" zu arbeiten. Bei git wird die Arbeitskopie nicht aus einem zentralen Repository ausgecheckt; vielmehr wird das zentrale Repository im Normalfall komplett kopiert und steht mir dann auch offline mit der gesamten Versionsgeschichte zur Verfügung. Das ermöglicht es überdies, neben einem "offiziellen" Repository - das im Netz steht - beliebig viele "inoffizielle" Repositories vorzuhalten. Änderungen kann ich so zunächst nur in meiner Kopie des Repositories vornehmen (und sie ggf. auf andere eigene Rechner spiegeln und auch mit anderen Entwicklern austauschen) und sie erst dann veröffentlichen, wenn ich sie für veröffentlichungsreif halte. So kann ich bspw. immer nur bestimmte Zweige meines Entwicklungsrepositories in ein öffentliches Repository übertragen und andere, an denen ich noch bastele, nicht veröffentlichen.

Das problemlose Anlegen von Kopien (Zweigen, branches) ist aus meiner Sicht ein weiterer Vorteil; ein Entwicklungszweig (branch) ist trivial und schnell angelegt und ebenso schnell auch wieder entfernt. Das ermöglich ein schmerzloses Ausprobieren von Änderungen jeder Art; man kann für jede Idee einfach einmal schnell einen neuen Zweig anlegen, sie ausprobieren und dann ggf. verwerfen oder auf Eis legen kann - oder in die "eigentliche" Entwicklungslinie übernehmen. Auch lassen sich so verschiedene Ideen einfach in verschiedenen Branches entwickeln und dann jederzeit direkt in den Hauptzweig übernehmen, oder man kann sie erst noch etwas "köcheln" lassen; daneben können verschiedene Entwicklungsstränge bspw. für eine geplante neue Version und für Bugfixes älterer Versionen nebeneinander laufen.

Ergänzend dazu fasziniert mich die Möglichkeit, meine Commits nachträglich nachzubessern und neu zu sortieren. Die Möglichkeit fraktionierter Commits hatte ich bereits angesprochen; außerdem kann ich jederzeit per interaktivem rebase einzelne Commits zusammenfassen. Oder ich setze einfach nur den Index auf eine alte Version zurück, so daß ich dann die Änderungen in der aktuellen Arbeitskopie gegenüber diesem alten Zustand neu einchecken kann, auch in einzelnen Teilen. In diese Reihe gehört auch die Möglichkeit, mein lokales Repository - oder einzelne Entwicklungszweige darin - immer wieder neu auf den aktuellen Stand des "offiziellen" Repositories - oder des Hauptentwicklungszweiges - aufsetzen zu lassen. All das ermöglicht es - auch zusammen mit dem leichten Anlegen neuer branches - auf der einen Seite, nahezu beliebig "herumzuspielen" und dabei dem Motto "Commit early, commit often" zu folgen, auf der anderern Seite aber später, wenn das Feature gereift ist, eine logische Abfolge von einzelnen Patches zu committen, die die ganzen Sackgassen und Fehlversuche auslässt und möglichst einfach nachzuvollziehen ist.

Dieser Text ist überholt und nicht mehr aktuell. Ich nutze bereits seit Mitte 2010 TortoiseGit nicht mehr. Eine Anleitung für die Installation von git for Windows, dem Nachfolger von msysgit, zusammen mit plink aus dem Putty-Paket findet sich auf meinen Webseiten.

Bereits Anfang Januar hatte ich von Git berichtet und danach geschildert, wie man Git-Repositories mit gitosis und gitweb, offen wie auch paßwortgeschützt, aufsetzen kann. Seitdem habe ich eine ganze Reihe Projekte in Git-Repositories eingecheckt und gewöhne mich immer mehr an die Arbeit mit Git, zumeist allerdings unter Windows (weil ich auf Laptop wie auch Desktoprechnern unter Windows arbeite).

Dazu verwende ich TortoiseGit, eine Portierung des recht bekannten (und gelobten) TortoiseSVN, und zugleich Git on Windows (msysgit), das ohnehin als Voraussetzung für die Verwendung von TortoiseGit heruntergeladen werden muß. Beide ergänzen sich, wie ich finde, recht gut. TortoiseGit ermöglicht eine einfache Definition des Remote Repository und elegante Lösungen für die Darstellung von Diffs und Merges, ganz zu schweigen von der grafischen Darstellung des Dateistatus im Explorer; die Git-Bash und GitTk aus msysgit hingegen sind m.E. optimal für Branching und (inkrementielle) Commits sowie für die Darstellung der History. Störend allenfalls, daß die Tools teilweise - trotz der einigermaßen großzügigen Ausstattung an Rechenleistung und RAM - arg langsam wirken. Insgesamt aber, wie ich finde, eine sehr bequeme Lösung.

Es gibt eine ganze Reihe von Lösungen, um FAQs automatisiert und regelmäßig ins Usenet zu posten:

Zum einen kann man dafür auto-faq von Ian Kluft und Paul W. Schleck nutzen, ein Perl-Script, das ich seit Ende der Neunziger für das automatische Posten diverser FAQs verwende. Es besteht aus einer Konfigurationsdatei, in der für jede FAQ definiert wird, wie sie nach wo gepostet wird. Die einzelnen FAQs sind als Textdateien abgelegt, über die Konfigurationsdatei werden die einzelnen Header und Pseudo-Header festgelegt; Message-IDs, Expires:- und Supersedes:-Header werden automatisch erzeugt. Gepostet werden die FAQs, deren Namen bei Aufruf des Scripts übergeben werden; das läßt sich via cron automatisieren, wobei für jede FAQ ein eigener crontab-Eintrag benötigt wird. auto-faq bietet einen ganzen Haufen an Optionen, hat aber den Nachteil, zum Posten zwingend inews - aus dem INN-Paket - oder vergleichbare Tools zu verwenden; außerdem bietet es eine Unzahl von Funktionen, namentlich auch zum Posten vielteiliger FAQs, die aber - jedenfalls für mich - keine Relevanz hatten. Und auto-faq wurde 1992 entwickelt und hat seit 1999, also seit über 10 Jahren, keine Änderung mehr erfahren …

Eine Alternative dazu stellt postfaq von Russ Allbery dar, gleichfalls in Perl implementiert. postfaq verfolgt ein anderes Konzept: hinterlegt in einer Textdatei wird hier nicht nur der Body der FAQs, sondern das komplette Posting einschließlich aller Headerzeilen. Konsequenterweise wird eine gesonderte Konfigurationsdatei nicht benötigt. Auch postfaq erzeugt die notwendigen Headerzeilen und postet die beim Aufruf angegebenen FAQs, was via cron automatisiert werden kann; es benötigt dazu aber keine externen Programme wie inews o.ä. Es wird aktiv gepflegt (letzte Änderung 2008).

Und eine weitere Möglichkeit ist yapfaq ("yet another postfaq"), ein Script von Marc Brockschmidt, das ich vor etlichen Jahren bereits einmal angetestet hatte, jetzt aber nirgendwo mehr wiedergefunden habe. Marc war aber dankenswerterweise so nett, mir die aktuelle Version (letzte Änderung: Februar 2003) zu überlassen; ich plane, yapfaq noch ein wenig für meine Zwecke zu bearbeiten und weiter zu entwickeln, as time permits. Einstweilen steht yapfaq über ein Git-Repository zur Verfügung.

yapfaq arbeitet grundsätzlich vergleichbar zu auto-faq: in einer zentralen Konfigurationsdatei wird definiert, welche FAQs in welchen Abständen wohin gepostet werden sollen. Die einzelnen FAQs sind als Textdateien abgelegt, wobei die Header durch das Script beim Posten gesetzt und ergänzt werden. Im Unterschied zu auto-faq postet yapfaq aber nicht nur eine bestimme FAQ, sondern alle FAQs, die "dran" sind, die also zuletzt vor - mindestens - dem definierten Zeitraum gepostet wurden. Es ist also nicht notwendig, für jede FAQ einen eigenen crontab-Eintrag zu definieren; vielmehr kann man yapfaq einfach täglich aufrufen, und jede FAQ wird dann gepostet, soweit sie "fällig" ist.

Nachtrag: Stärkere CPU.

Gestern erhielt ich per E-Mail eine Antwort auf meine nach dem scheinbaren Serverausfall vor gut einer Woche gestellte Anfrage an den Support meines Providers (gefolgt von einer Entwarnung meinerseits, daß das System wieder zur Verfügung steht), die mich mit Hinweisen beglückte, wie ich einen möglichen Hardwareschaden eingrenzen könne. kopfkratz Offenbar hat man da immer noch nicht gemerkt, daß es sich um keinen Ausfall, sondern einen Serverumzug handelte. Das schockiert mich jetzt doch etwas.

Nachtrag: RAM-Verdoppelung.

Nachdem ich inzwischen einmal systematisch die vorgenommenen Änderungen geprüft habe, bin ich im übrigen einigermaßen versöhnt (von der fehlenden Ankündigung, die wohl durch interne Kommunikationsprobleme beim Anbieter bedingt ist, einmal abgesehen). Alt scheinen bei der Maschine nur noch die Platten zu sein; der Server hat einen schnelleren Prozessor und doppelt so viel RAM bekommen, außerdem ist eine serielle Konsole angeschlossen (vermutlich hat man also nur die Platten umgeklemmt). Offenbar standardmäßig hat man dann einen neuen Kernel eingespielt und damit verbundene Konfigurationsänderungen (von /dev/hdX zu /dev/sdX und bzgl. der seriellen Konsole) vorgenommen, um sicherzugehen, daß die neue Hardware angesteuert werden kann (ursprünglich war die Maschine mit einem Debian Sarge oder Etch initialisiert worden); inzwischen habe ich den Kernel wieder durch den Debian-Kernel ersetzt, und alles läuft.

Dennoch: ich hätte lieber eine Vorwarnung vorher und/oder eine Erläuterung der Vorgehensweise hinterher gehabt, und das habe ich auch - hoffentlich hinreichend deutlich - per Feedbackformular kundgetan.

Für den Fall, daß der eine oder die andere es - genau wie ich - bisher nicht mitbekommen hat: die Registrierungsstelle für die Top-Level-Domain .de (DENIC) fordert seit Anfang Februar für alle Domainübertragungen verbindlich das bereits Ende 2008 als Alternative eingeführte AuthInfo-Verfahren; die frühere Lösung wird nicht mehr akzeptiert.

Traditionell liefen Domainübertragungen an einen anderen Provider in der Weise ab, daß der neue Provider die DENIC beauftragte, die Domain an ihn zu übertragen, DENIC dann beim alten Provider anfragte, ob das in Ordnung ist, und dieser dann zustimmte (ACK) oder ablehnte (NACK); im Falle einer Ablehnung konnte er noch eine verspätete Zustimmung (late ACK) nachschieben. Der organisatorisch-rechtliche Hintergrund dieser technischen Lösung war dergestalt, daß der neue Provider natürlich nur bei Vorliegen eines Auftrags tätig werden durfte und der alte Provider vor einer Zustimmung zu prüfen hatte, ob ihm eine schriftliche Zustimmung seines Kunden vorlag. Dieser Prozeß ging gerne schief, insbesondere dann, wenn einer der beteiligten Reseller zum einen selbst kein DENIC-Mitglied war und zum anderen die entsprechenden Prozesse nicht recht im Griff hatte.

Das nunmehr noch alleinig mögliche AuthInfo-Verfahren basiert darauf, daß der alte Provider für jede Domain ein verschlüsseltes Paßwort bei der DENIC hinterlegt und auf Wunsch an seinen Kunden mitteilt. Dieses Paßwort muß der neue Provider zusammen mit der Übernahmeanforderung für die Domain an die DENIC senden; stimmt das Paßwort, erfolgt die Übertragung, stimmt es nicht, erfolgt sie nicht. Eine Domainübernahme kann also nur noch erfolgen, wenn der Kunde bei seinem bisherigen Anbieter ein Paßwort bei der DENIC hinterlegen und sich zusenden läßt und dieses dann seinem neuen Provider mitteilt. Das sollte zum einen einfacher, zum anderen sicherer sein (aber man muß wissen, wie es geht und daß es nur so noch geht).

Daniel war in den letzten Tagen so nett, meine Rechner in sein Nagios mitaufzunehmen, so daß die dort angebotenen Dienste in der Überwachung mit drin sind und ich bei Ausfällen eine Benachrichtigung per E-Mail (und dann teilweise auch per SMS) erhalte. Gestern abend war ich dann auch gerade zu Bett gegangen, als nacheinander mehrere SMS eintrudelten, die einen Ausfall meines privaten Servers meldeten. Also bin ich erschrocken noch einmal aufgestanden und habe mir die Sache angesehen: die Maschine war tatsächlich nicht erreichbar, und zu meiner Überraschung stand auch das über das Webinterface des Providers steuerbare "Rettungssystem" - eine Möglichkeit, in ein Minimalsystem zu booten und sich die Maschine mal näher anzusehen - nicht zur Verfügung. Nach gut einer Stunde Bastelei habe ich eine eilige E-Mail an die Hotline geschrieben und wollte gerade wieder zu Bett gehen, als die nächsten SMS eintrudelten, die meldeten, das System sei wieder verfügbar, was allerdings nur teilweise zutraf.

Inzwischen scheint alles wieder gut zu sein, und ein kurzer Blick auf das System - nach einer ebenso kurzen Nacht - hat den Verdacht bestätigt, den ich heute nacht dann schon hatte: es handelte sich um keinen Ausfall, sondern eine geplante Wartung bzw. einen Umzug der Maschine! Den hatte man mir im vergangenen November (!) bereits mit einigen Wochen Vorlauf angekündigt, die Wartung wurde aber nie durchgeführt, und Rückfragen beim Support ergaben auch nur, daß die Maschine eigentlich hätte umgezogen werden sollen, man sich das auch nicht erklären könne, mir aber Bescheid geben würde, wenn man das nachhole. Offenbar hat man das aber vergessen (oder verwechselt meinen Server mit dem eines anderen Kunden …), so daß es dann zu dieser überraschenden Downtime kam.

Im übrigen ist es bei der Downtime nicht geblieben; man hat sich offenbar zu der Maschine (eigentlich ein Miet- oder auch sog. "Rootserver", der vom Kunden, also mir, selbst gepflegt wird) Zugang verschafft und etliche Konfigurationsänderungen vorgenommen (u.a. auch eine Änderung, die alle 5 Minuten stapelweise Fehlermeldungen ins Logfile schreibt) und einen anderen Kernel installiert. Der Hintergrund scheint zu sein, daß die Maschine nicht (nur) umgezogen wurde, sondern nunmehr auch eine im ursprünglichen Vertrag nicht vorgesehene serielle Konsole erhalten hat. Grundsätzlich ist so etwas ja nett, aber daß man einfach an Kernel und Konfiguration herumschraubt (ohne wissen zu können, welche Änderungen ich vielleicht in Kernel und Userland vorgenommen habe und ohne mich über die seitens des Supports vorgenommenen Änderungen zu informieren), finde ich nicht so wirklich prickelnd.