Netz - Rettung - Recht

Eigentlich bin ich mit Rechnern ja gut versorgt, aber in den letzten Wochen reifte in mir dennoch der Entschluß, noch einmal Zuwachs für den Rechnerzoo zu beschaffen - ein Netbook sollte es sein, für alle die Fälle, in denen ich meinen treuen Laptop (mit dem ich sehr zufrieden bin) nicht mitschleppen will, bspw. für Vorträge oder Präsentationen, für Besprechungen, in denen man die Unterlagen in elektronischer Form mitführen möchte, und vielleicht auch ab und an einmal unterwegs, wenn sich das bewährt. Die Akku-Laufzeit sollte nicht zu gering sein, ansonsten brauchte ich erst etwas Zeit, um meine Wünsche formulieren zu können.

Die Auswahl erwies sich als sehr groß, Umfragen und die Bitte um Beratung im vertrauten Kreise förderten alle möglichen Varianten zutage: Asus, Dell Latitude, Samsung, HP … Am vergangenen Wochenende klangen dann sowohl der Rechner von Samsung (gute Testberichte) als auch der kleine Dell Latitude ganz verlockend, zumal es letzteren auch mit Ubuntu Linux und farbigem Cover geben sollte. Vielleicht könnte das mein erster Linux-Rechner werden? Doch mit dem Webkonfigurator von Dell wurde ich nicht warm; nicht nur war der Preis recht knackig, auch wollte man mir immer nur ein schwarzes Modell verkaufen, und ich hatte mich doch inzwischen darauf festgelegt, daß es rot sein sollte, das Objekt der Begierde. Daher habe ich mich kurzentschlossen umentschieden und bin bei der Aufgabe meiner Bestellung der Fa. Lenove treu geblieben.

Heute konnte ich dann Firefly aus dem Gewahrsam der Post befreien, auspacken und kurz testen - bisher gefällt mir die Neuerwerbung sehr gut. Jetzt fehlt nur noch etwas Zeit und Ruhe, um alles nach meinem Geschmack einzurichten …

Viele werden Nagios, das Monitoringsystem, kennen, manche werden es auch nutzen. Für die letzteren mag nagstamon eine hilfreiche Ergänzung darstellen: ein kleines Icon im Systray oder als "schwebende" Statusleiste auf dem Desktop, das entweder in knallgrün "OK" verkündet oder einen Warnton von sich gibt und die Farbe nach gelb, rot oder schwarz wechselt, wenn Systeme ausgefallen sind. Im letzteren Fall läßt sich durch Deuten mit dem Mauszeiger ein Panel ausklappen, auf dem die Nagios-Warnungen dargestellt werden und weitere Informationen abrufbar sind. So hat man den Status seiner Systeme immer übersichtlich dargestellt und im Falle eines Falles alle notwendigen Informationen zur Hand.

nagstamon kann mehrere Nagios-Server abrufen und erhält seine Informationen durch regelmäßiges Polling (Standard: minütlich) der status.cgi-Seite der jeweiligen Nagios-Installation.

Wem nagstamon nicht zusagt, dem gefällt stattdessen vielleicht ein vergleichbares Firefox-Plugin, das ähnliche Arbeit leistet.

Dieser Tage stellte ich fest, daß mein Heimserver die letzten Wochen sein Backup nicht per FTP auf die Sicherungsplatte schieben konnte. Nachdem ich am Freitagabend mal wieder in den früher heimischen Gefilden weilte, wollte ich das Problem schnell mal beheben. Allerdings scheiterte der Einstieg in die Problembehebung schon daran, daß mein Laptop zwar das WLAN fand, aber keine IP-Adresse zugeteilt bekam. Das Problem gibt es manchmal, also habe ich halt den Desktoprechner hochgefahren, um von da aus mal auf die Servermaschine zu gucken. Der kam allerdings auch nicht richtig hoch, sondern brauchte sehr lange für den Boot … was daran lag, daß er auch keine IP-Adresse bekam.

Also habe ich mal den Monitor "am Gerät" angeknipst und festgestellt, daß der Server korrekt lief, aber keinerlei DCHP-Einträge im Log sind. Offenbar ist also das Problem mit der Netzwerkverkabelung viel schlimmer als befürchtet: nicht nur, daß der Server selbst keine funktionsfähige Netzwerkverbindung mehr hat (seit dem letzten Ausfall ist er durch lose durch die Räume verlegtes Kabel angebunden), sondern jetzt sind offenbar auch die anderen Kabel angeknackst.

Eine gute halbe Stunde und mehr später bin ich ratlos: egal welche provisorische Verkabelungen ich durch die Gegend ziehe, es wird nicht besser - DHCP-Verkehr kommt einfach nicht am Server an, das Logfile bleibt leer. Dabei hatte ich den DHCP-Server sogar restartet. Auch ein erneuter Restart ändert nichts, produziert noch nicht einmal Logeinträge. Was an und für sich ja komisch ist. Und irgendwie läuft auch kein DHCP-Server. Genau genommen finde ich auch gar keinen DHCP-Server …

"Die meiste Arbeit macht man sich selbst" vollständig lesen

Dieses Wochenende hat endlich geklappt (was nicht mein Verdienst war): bei uns hat sich eine sogar gar nicht so kleine Runde zu einem Spielenachmittag zusammengefunden. Nachdem gestern abend schon eine Runde Galaxy Trucker zu zweit gespielt wurde, war heute vormittag dann zum ersten Mal eine Partie Dominion dran, gleichfalls zu zweit. Richtig rund ging es dann aber erst am späteren Nachmittag, als wir mit bis zu sechs Spielern - gut, nicht alle gleichzeitig aktiv - Space Alert gespielt haben. Eine tolle Sache, und ich glaube, ich habe meine Sache als Kommunikationsdingsda gar nicht so schlecht gemacht.

Jedenfalls haben wir am Ende eines langen Nachmittages direkt für den April eine Fortsetzung verabredet. So soll das sein!

Die DB ist fies. Schickt sie mir doch einfach eine für den Monat März gültige "Schnupper-BahnCard First" zu, mit der ich meine BahnCard 50 (2. Klasse) auch für eine 50%ige Ermäßigung für Fahrscheine der 1. Klasse verwenden kann. Und, zertifiziertes Luxusszaf das ich bin, kann ich da natürlich nicht "nein" zu sagen, und bin heute dann in der 1. Klasse des altbekannten IC in die alte Heimat zurückgefahren. *seufz*

Aber schön war’s schon …

Vor etwas mehr als einem Monat berichtete ich, daß meine treue Armbanduhr - der ich gerade das ich-weiß-nicht-wievielte neue Armband spendiert hatte - sich entschieden hatte, treulos den Dienst zu quittieren.

Schon aus Zeitmangel hatte ich mich entschieden, sie - für nicht wenig Geld - instandsetzen zu lassen. Heute kann ich froh mitteilen, daß sie (generalüberholt) wieder zurück ist. In Zukunft habe ich also wieder eine Entschuldigung weniger, um zu spät zu kommen.

Das Bundesverfassungsgericht hat heute entschieden, daß die Vorschriften über die sog. Vorratsdatenspeicherung von Telekommunikationsdaten grundgesetzwidrig und damit nichtig sind.

So schockierend wie das zunächst klingt ergibt eine kurze Durchsicht der Urteilsgründe (ich hoffe, später noch mehr Zeit zu einer ausführlicheren Auseinandersetzung damit zu finden) jedoch ein etwas differenzierteres Bild; auch die Pressemitteilung des Gerichts ist sicherlich mit Bedacht "Konkrete Ausgestaltung der Vorratsdatenspeicherung nicht verfassungsgemäß" betitelt.

Das Bundesverfassungsgericht hat zunächst festgestellt, daß eine Vorratsdatenspeicherung in der bisher gesetzlich geregelten Art und Weise trotz aller dagegen vorgebrachten Argumente im Grundsatz verfassungsgemäß ist, soweit der Zugriff auf diese Daten nur zur Verfolgung gravierender Straftaten bzw. zur Abwehr entsprechend gravierender und hinreichend konkret gewordener Gefahren erfolgen darf; die nunmehr umrissenen Grenzen entsprechen im wesentlichen dem Inhalt der einstweiligen Anordnungen des Gerichts. Darüber hinaus fordert das Bundesverfassungsgericht bereits im Gesetz ausreichende Vorgaben zur Sicherstellung eines hohen Standards bei der Datensicherheit; daneben stehen weitere Erwägungen zur Frage der verdeckten Erhebung der Verkehrsdaten und zu erweiterten Benachrichtigungspflichten. Schließlich erteilt das Bundesverfassungsgericht der Behauptung eine Absage, daß die Finanzierung der notwendigen Umsetzungsmaßnahmen durch die Verpflichteten, also die Anbieter, selbst nicht der Verfassung entspreche.

Insgesamt also eine wohlabgewogene Entscheidung, die man nicht in allen Punkten teilen muß, aber mit der man leben kann. Unverständlich aber die mit der denkbar knappsten Mehrheit getroffene Entscheidung des Senats, die verfassungswidrigen Vorschriften über die konkrete Umsetzung für nichtig zu erklären, ohne dem Gesetzgeber die Möglichkeit zu geben, binnen einer kurzen Frist nach den Vorgaben des BVerfG nachzubessern. Diese Entscheidung ist nicht nur wegen der gravierenden Folgen für die Möglichkeit zur Verfolgung schwerer und schwerster Straftaten - von der Gefahrenabwehr will ich nicht zuletzt aufgrund mangelnder Kenntnis des Bereichs gar nicht sprechen -, sondern auch deshalb umso schwerer nachvollziehbar, weil das BVerfG sich in gewisser Weise in Widerspruch zu seinen eigenen einstweiligen Anordnungen setzt. Nachdem es festgestellt hat, daß die Regelungen im wesentlichen verfassungskonform sind, hätten m.E. genau die auch in den einstweiligen Anordnungen genannten Gründen dafür gesprochen, die bisherigen Regelungen im dort genannten Umfang bis auf weiteres in Kraft zu belassen, wie auch die Sondervoten betonen.

Nun ist also die Bundesregierung gefordert, sehr zeitnah eine Neuregelung entsprechend der Vorgaben des Bundesverfassungsgerichts zu treffen. Es steht dringend zu hoffen, dass allerspätestens bis zum Jahresende eine solche Neuregelung in Kraft tritt.

Zu bedauern sind die Provider, die erst unter erheblichem Aufwand (und Kosten!) eine Vorratsdatenspeicherung umsetzen mussten, diese jetzt - wieder mit erheblichem Aufwand! - deaktivieren müssen, um sie dann demnächst wieder - mit aufgrund der erhöhten Datenschutzanforderungen noch höherem Aufwand - wieder einzuführen. Auch denen gibt das höchste deutsche Gericht mit seiner heutigen Entscheidung letztlich Steine statt Brot.

Heute gegen Mittag kam es in Stuttgart in einem Geschäftshaus an der Urbanstraße Ecke Charlottenstraße zu einem Brand, der zu erheblichen Verkehrsbehinderungen führte, wie die Presse berichtet. Ich muß gestehen, davon erst abends etwas mitbekommen zu haben, obwohl ich zu dieser Zeit ganz in der Nähe eine Schulung gehalten habe. Zwar war mir aufgefallen, daß überproportional viel Sondersignal zu hören war und irgendwann am späten Vormittag auch ein Hubschrauber schräg über dem Justizviertel stand; auch hatte ich mich über den starken Verkehr auf der Olgastraße - einschließlich einiger Lastkraftwagen, die da eigentlich gar nicht so recht durchkamen - gewundert (und geärgert), aber von dem Brand selbst erfuhr ich erst später, und die Ausmaße wurden mir erst bewußt, als spät abends noch auf dem Heimweg die stadteinwärts führende Fahrspur der Charlottenstraße (immerhin dreispurig) voll gesperrt und mit Einsatzfahrzeugen der Feuerwehr zugestellt war, einschließlich einer mobilen Einsatzleitung, gekennzeichnet durch das am Mast ausgefahrene rote Blinklicht.

Glücklicherweise gab es keine Personenschäden (und am nächsten Morgen auch keine erheblichen Verkehrsbehinderungen mehr).

Uiuiuiuiuiuiui, hier weht es inzwischen aber auch ganz schön! Sturmtief "Xynthia" will offenbar keine halben Sachen machen … und ich darf dafür irgendwelchen losen Teilen von unserem Balkon nachjagen, die den Abflug gemacht haben. Aber immerhin bin nicht ich derjenige, der mitten im Sturm beschlossen hat, den Hof zu kehren, weil eine Große Kehrwoche schließlich ordentlich erledigt werden muß.

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.

"Was mir an git gefällt" vollständig lesen

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.

Wie ich bereits letzten Monat erwähnte, beabsichtigte ich die Liste der "German (language) regional hierarchies" zukünftig automatisiert nach news.lists.misc zu posten. Zu diesem Zweck habe ich jetzt ein wildes Shellscript gebastelt, das die aktuelle Liste, wie schon beschrieben, in zwei Teilen herunterlädt, um Einleitung, Überleitung und Ende ergänzt, prüft, ob sich seit dem letzten Download eine Änderung ergeben hat und postet das Ergebnis dann - vermittels yapfaq - nach news.lists.misc. Bisher scheint das recht gut zu funktionieren.