Nach einigem hin und her ist es nun endlich soweit:

Taxbird 0.18 erblickt die Welt (die Jahresversion 2012)

Die Jahresversion von Taxbird für 2012 (0.17) ist nun nahezu fertig.  Soweit ist die Release auch schon da.  Allerdings fiel mir – leider nachdem ich die Pakete für Debian testing & unstable in 32- und 64-bit-Version gebaut hatte – auf, dass diese in Debian stable nicht kompiliert werden kann :’(

Grund dafür ist ein fehlendes #include der Datei sys/stat.h.  Auf den neueren Systemen wird diese offensichtlich durch weitere Header-Dateien indirekt inkludiert – bzw. bei der letzten Version durch die Gnome-Header, die inzwischen nicht mehr benötigt/verwendet werden.

Falls jemand einen ersten Blick auf die Version 0.17 werfen will, findet die o.g. Pakete in meinem Taxbird PPA für Debian. Ubuntu Pakete für Natty gibt’s im Ubuntu PPA.

Ich habe heute auch – wie gestern schon angekündigt – ein Debian PPA eingerichtet.  Momentan ist dort die libgeier 0.13 (2012-fähig) für Debian Squezze (i386 & amd64), Wheezy (nur amd64) und Sid (nur amd64) verfügbar.

Das PPA ist unter http://ppa.brokenpipe.de/ verfügbar.  Dort finden sich auch die notwendigen Einträge für die /etc/apt/sources.list.

Nachdem sich das Jahr 2011 wieder dem Ende zu neigt, war es langsam wieder an der Zeit, wieder ein paar Stunden für das Taxbird-Projekt zu finden, um dieses für das Jahr 2012 fit zu machen.

Auf der Mailingliste hatte im August jemand nach einer Version ohne Gnome-Abhängigkeit gefragt… eine gute Frage.  Warum eigentlich die Abhängigkeit zu Gnome?  Konkret kann ich mich nicht mehr daran erinnern, die erste Release ist immerhin schon stolze sechs Jahre her – der Export erfolgt jedoch unter Verwendung des GnomeDruid-Widgets.  Wie sich rausstellte – und so auch der Vorschlag in besagter Mail – gibt es eine neuere Alternative: GtkAssistant.  Der GnomeDruid ist inzwischen deprecated.

Wie sich nach etwas googelei herausstellte, soll die libgnomeui komplett eingestampft werden.  Das heißt auch, dass das ebenfalls verwendete GnomeFileEntry mittelfristig nicht mehr zur Verfügung stehen wird.  Bleiben noch das Hauptfenster (GnomeApp) und der Info-Dialog (GnomeAbout) – dafür gibt’s natürlich auch in Gtk+ Alternativen.  Auch die für die Oberflächenbeschreibung verwendete libglade ist inzwischen deprecated, so auch hier: Migration auf die Alternative GtkBuilder.

Kurzum, das Ganze ist dann etwas ausgeartet, aus wenigen Stunden wurden nun fast zwei Tage.  Aber jetzt ist Taxbird wieder frischer und vorallem leichtgewichtiger, statt dem ganzen Gnome, Bonobo Rattenschwanz braucht’s jetzt nur noch ein halbwegs aktuelles Gtk+ nebst GtkHTML 3.14.

Zumindest libgeier gibt’s jetzt schonmal in Version 0.13, die mit dem Jahr 2012 zurecht kommt.  Taxbird wird in aktualisierter Version dann in Kürze folgen.

Nachdem es in der Vergangenheit immer wieder Probleme mit der Verfügbarkeit von libgeier & taxbird Paketen gegeben hat, habe ich mich entschlossen künftig selbst Debian & Ubuntu Pakete für die gängigen Versionen zu erstellen und weiter zu pflegen.  Die Debian-Pakete werde ich selbst hosten, da es hier keinen brauchbaren PPA-Service zu geben scheint.  Zwecks Ubuntu-Paketen habe ich im Launchpad ein eigenes Taxbird PPA eröffnet.  Dort liegt bereits die libgeier in Version 0.13 für Lucid, Maverick, Natty und Oneiric, jeweils für i386 und amd64.  Taxbird wird folgen, sobald die 0.17-er das Licht der Welt erblickt hat.

Jeder der schonmal an einer Web-Applikation gebastelt hat, kennt das Problem, dass identische Inhalte einmal serverseitig (also beispielsweise in Common Lisp) und einmal clientseitig (dynamisch per JavaScript) ausgeliefert werden sollen.  Ersteres geschieht regelmäßig beim Laden der Seite, letzteres ist praktisch, wenn die Seite dynamisch ergänzt werden soll.

In Cookie-DB ist genau dies bei den Zutaten- und Tag-Listen der Fall (hier symbolisch mit zwei Blöcken):

… wenn der Anwender beispielsweise einem Tag durch Klick auf einen der Links eine Punktzahl verpasst, wird das Tag automatisch der Tags-Seite hinzugefügt.  Viele greifen hier wohl zu einem XHR und Fragen den zusätzlichen Block beim Server an, streng genommen ist dies hierfür jedoch nicht erforderlich.  Vielmehr wäre die erheblich schickere Lösung ja die, den HTML-Block einmal per Common Lisp zu erzeugen, einmal per JavaScript.  Das macht natürlich nur dann Sinn, wenn dadurch keine Redundanz im Code entsteht – und da hören die üblichen Sprachen dann auf…

… nicht so jedoch Common Lisp in Kombination mit dem JavaScript-Compiler Parenscript. Letzterer versteht sich nämlich auf die gleiche Markup (zugegeben mit kleinen Inkompatibilitäten) wie CL-WHO.  Die Idee besteht nun darin, die HTML-Blöcke durch Makros zu erzeugen, diese dann in JavaScript-Code zu erzeugen und an den Client mit auszuliefern.

Dass dies wie gewollt funktioniert, brauchen wir eine Ausgangsbasis, auf die der “kombinierte Codeabschnitt” aufbauen kann:

(defmacro who (&body body)
  `(with-html-output-to-string (*standard-output* nil :prologue nil :indent nil)
     ,@body))

(defpsmacro who (&body body)
  `(who-ps-html ,@body))

(defmacro strcat (&rest strings)
  `(concatenate 'string ,@strings))

(defpsmacro strcat (&rest strings)
  `(+ ,@strings))

… mit dem üblichen defmacro entsteht das Makro für den LISP-Compiler, mit defpsmacro die entsprechende Variante für den JavaScript Compiler.  Das Makro who umschließt letztlich einfach nur CL-WHO Markup.  Die Funktion strcat kennt jeder aus C, hier schlicht eine Abstraktion um mehrere Zeichenfolgen zusammenzufügen.  In CL mittels der Funktion concatenate, in JavaScript werden die Zeichenfolgen schlicht addiert.

Mit diesem Fundament können wir uns an das Makro wagen, das den bezeichneten Block ausgibt:

(defmacro+ps write-ingopts (ing-id ing-name)
  `(who
     (:p :class "ingopts"
         :data-id ,ing-id
         :data-name ,ing-name
     ;; [...]

(defmacro+ps write-ingrow (id name score)
  `(who
     (:div :id (strcat "ingrow-" (princ-to-string ,id))
           :class (concatenate 'string "ingline state-"
                                (cond
                                 ((<= ,score -500) "use")
                                 ((< ,score 0) "like")
                                 ((= ,score 0) "neutral")
                                 ((< ,score 500) "omit")
                                 ((< ,score 5000) "na")
                                 (t "never")))
           (:span :class "ingname"
                  (str ,name))
           (str (write-ingopts ,id ,name))
           (:p :class "ingscore"
               (str (strcat "(score: " (princ-to-string ,score) ")"))))))

… langer Rede kurzer Sinn, wir definieren diesmal mit defmacro+ps ein Makro (hier letztlich write-ingrow), das in CL-WHO Markup beschreibt, wie der Block aussehen soll. defmacro+ps definiert das Makro, wie der Name eigentlich schon sagt, sowohl im Common Lisp als auch im Parenscript Kontext.  Gleich zu Beginn verwenden die Makros das eingangs definierte Makro who, welches nun in LISP und Parenscript zu verschiedenem Code evaluiert … in LISP eben zu dem benötigten with-html-output-to-string Aufruf, in Parenscript zu who-ps-html.

Um den Code in LISP zu verwenden, können wir das Makro ganz einfach im CL-WHO Kontext verwenden (im Falle der Tags-Seite also einfach über die Liste der gewählten Tags iterieren und die Blöcke zum Client schieben):

          (:div :id "tabs-tag" :class "tags"
                (dolist (j (session-value 'pref-tags))
                  (str (write-ingrow (cookie::id (car j))
                                     (cookie::name (car j))
                                     (cdr j)))))

… soweit so gut.

Aber auch mit Parenscript kann das Makro einfach verwendet werden:

    (:script :type "text/javascript"
             (str
              (ps
                ;; [...]
                (defun rebind-events ()
                  ($$rebind ("a.ingopt" "click")
                    (let* ((score ((@ ($ this) data) "score"))
                           (pa ((@ ($ this) parent)))
                           (ing-id ((@ pa data) "id"))
                           (ing-name ((@ pa data) "name"))
                           (ing-html (write-ingrow ing-id ing-name score))
                           (ing-el ($ (strcat "#ingrow-" ing-id)))
                           (is-tag ((@ ((@ ($ this) parents)) has-class) "tags")))

                      (if (@ ing-el length)
                          ((@ ing-el replace-with) ing-html)
                          ((@ ($ (if is-tag "#tabs-tag" "#tabs-ing")) append) ing-html)))))

… indem wir uns zuerst die erforderlichen Parameter zusammen klauben (hier score, ing-id und ing-name) und anschließend einfach write-ingrow aufrufen und das Ergebnis ing-html zuweisen.

Wer all dies in Aktion sehen möchte, kann einen Blick auf Cookie DB werfen.  Der Quellcode findet sich in meinem Github Repository.  Oben beschriebenes dort in der Datei frontend.lisp.

Ich habe wieder ein wenig Zeit gefunden (bzw. dafür frei geräumt), mich um die Idee mit der Rezeptdatenbank “Cookie DB” zu kümmern.

Wie zuletzt im Januar beschrieben, besteht die Idee eine Rezeptsammlung zu erstellen, die auf Grund verschiedener Faktoren (persönliche Favoriten, verfügbare Zutaten, zuletzt gekochte Rezepte, usf.) die einzelnen Rezepte gewichtet und danach sortiert anzeigt, resp. so Vorschläge macht, was diesmal gekocht werden könnte.  Die erste Version hatte ein relativ kleines Datenbankschema und ein schnell zusammengezimmertes Kommandozeilen-Interface.

Es zeigte sich bereits im Januar, dass dieser Ansatz etwas zu kurz griff.  Nachteile waren insbesondere,

• ein zu kleines Datenbankschema, das keine Zubereitungstexte und Bilder enthielt
• keine Mengenangaben in der Rezepte-Zutaten-Tabelle
• keine Unterstützung von Tags, wie bspw. “Hauptspeise” (was zu teils seltsamen Vorschlägen führte)
• nicht Freundin-kompatible Benutzerführung

… deswegen beschloss ich das Datenbankschema zu überarbeiten und die Oberfläche komplett neu zu konzipieren.

Die Datenbank fußt weiter auf SQLite 3, jetzt jedoch mit deutlich erweitertem Schema.  Soll heißen Lang- und Kurzbeschreibung, Bilder und Tags sind jetzt ebenso an Bord wie erweiterte Angaben zu den Rezepte-Zutaten-Beziehungen.  Die Benutzerinteraktion soll via mehrbenutzerfähiger Weboberfläche erfolgen.  Nachdem das Projekt in Common Lisp (ich verwende SBCL) verfasst ist, fiel die Wahl auf den Webserver Hunchentoot in Kombination mit dem HTML Toolkit CL-WHO.  Serverseitig verwende ich weiter CSS-Lite und den LISP nach JavaScript Compiler Parenscript.  Für die Clientseite habe ich mich für jQuery entschieden, bzw. insbesondere auch jQuery UI, welches der Anwendung bspw. das zentrale Tab-Widget schenkt.

Für die Konzeption als Web-Anwendung habe ich mich primär deswegen entschieden, weil hierin meines Erachtens die Zukunft liegt.  Nachdem sich seit der Version 8 bzw. 9 selbst der Internet Explorer relativ gut an die einschlägigen Standards hält, sind Web-Anwendungen in meinen Augen das Mittel der Wahl um möglichst plattformunabhängig zu entwickeln.  Zudem bestechen diese durch gute Verfügbarkeit.  Einen JavaScript-fähigen Browser hat inzwischen fast jeder auf seinem Handy, bzw. jeder auf seinem PC greifbar.  Damit steht der Rezeptsuche auch von unterwegs nichts mehr im Wege.  Auch bestehen keine Hürden hinsichtlich Installation (wie Taxbird immer wieder zeigt führt das Veröffentlichen eines Quelltext-Pakets noch lange nicht zu Paketen in jeder gängigen Distribution) und man braucht sich keine Gedanken bzgl. der Synchronisation der Daten von einem Rechner zum anderen zu machen.  (den Datenschutzaspekt des Themas “ich packe alles in die Cloud” mal außen vor gelassen)

An sich befürworte ich immer die Trennung der Applikationslogik vom Frontend durch das Einziehen einer REST-Zwischenschicht — also dass auf die eigentliche Applikation erstmal eine REST-Schnittstelle aufsetzt und das HTML-Frontend dann mit der REST-Schnittstelle spricht.  Dies hat meines Erachtens den Scharm, dass einerseits eine REST-Schnittstelle verfügbar ist (was ich immer cool finde) und zudem das HTML-Frontend zwangsweise von der Datenbank getrennt ist (sprich dass da auch bei größter Versuchung kein SQL-Statement reingemurkst werden kann).  Letzteres sollte zu deutlich saubereren Schnittstellen im Inneren der Anwendung führen.

Nachdem mir nicht so recht einfallen wollte, was man mit einer REST-Schnittstelle auf eine Rezeptdatenbank anstellen könnte (außer diese einfacher kopieren zu können), habe ich den Ansatz aber erstmal sein lassen.  Außerdem ist für mich Common Lisp und Hunchentoot selbst noch so neu, dass das Projekt Lehrstoff genug bietet.  So kann ich die REST-API immer noch einziehen bzw. andocken, LISP ist da ja flexibel genug…

Eigentlich war ja von Anfang an klar, dass es nicht bei dem Lauschangriff auf DBus mittels C-Code bleibt, das Crosskompilieren ist schlichtweg einfach zu lästig im Umgang mit dem N900.  Nach nur wenigen Stunden der Rätselei (zugegeben, ich kann nicht wirklich gut Python, aber die Auswirkung hierauf dürfte eher marginal sein) wie das Python-DBus Modul im Innersten wohl funktioniert, hier jetzt die Lösung wie man die Desktop-Benachrichtigungen in einem Skript abfangen und weiterverbarbeiten kann:

import gobject
import dbus
from dbus.mainloop.glib import DBusGMainLoop

def msg_filter(_bus, msg):
    if msg.get_member() != "Notify": return
    args = msg.get_args_list()
    print "%s:%s" % (args[3], args[4])

if __name__ == '__main__':
    DBusGMainLoop(set_as_default = True)
    bus = dbus.SessionBus()
    bus.add_match_string("type='method_call',interface='org.freedesktop.Notifications'")
    bus.add_message_filter(msg_filter)
    gobject.MainLoop().run()

… nennen wir das Kind notify-spy, Lizent GPLv3+

… nachdem man schon mit den folgenden, wenigen Zeichen Notifications auf dem geliebten Nerdphone N900 einblenden kann:

#!/usr/bin/env python
import dbus
if __name__ == '__main__':
    bus = dbus.SessionBus()
    remote_object = bus.get_object("org.freedesktop.Notifications", "/org/freedesktop/Notifications")
    iface = dbus.Interface(remote_object, "org.freedesktop.Notifications")
    iface.Notify('', 0, '', 'Hallo', 'ruf mich an!', [], [], -1)

kam auf dem zerties.org-Treff heutgestern die Frage auf, wie schwer es wohl sei, eine Nachricht, die an den Desktop Notification Daemon geht (org.freedesktop.Notifications.Notify) abzufangen und zusätzlich selbst weiter zu verarbeiten.  Die Idee ist hier, dass man die Nachricht vorlesen lassen könnte, wenn man bspw. im Auto sitzt.  Ist dann doch eher unpraktisch, wenn man nur mitbekommt, dass das Handy in der Tasche vibriert.

Wie man das mit Python implementieren könnte habe ich bis jetzt noch nicht herausgefunden, daher habe ich mir den Code von dbus-monitor geschnappt und das Gewünschte noch dazugefrickelt, das Kind heißt jetzt notify-listen als Pendant zu notify-send aus dem Paket libnotify-bin.

Damit sind die ersten Hürden im Umgang mit DBus genommen.  Ich habe ja noch das Ziel den von mir selbst reporteten Bug in telepathy-sofia-sip zu fixen … aber das ist ja ein komplexes Monster aus DBus und GStreamer…

… alle Jahre wieder das gleiche Thema, ich muss irgendwie die Zeit zusammen kratzen um Taxbird an’s neue Jahr anzupassen. Manchmal frage ich mich ja wofür, aber ich hab’ schon zu viel in das Projekt investiert, als dass ich’s jetzt aufgeben möchte. Umgekehrt interessiert mich das Steuerrecht momentan nicht mehr wirklich und das eigentliche Ziel, die Einkommensteuererklärung irgendwann unterstützen zu können, gerät ja eher in weitere Ferne …

Codename ist diesmal “no milk today”, in Anspielung auf die völlig absurde Regelung der Umsatzbesteuerung verschiedener Milchen (lt. Duden ist übrigens sowohl Milche als auch Milchen als Pluralform zulässig):

• Frauenmilch(sic!): 0% gem. § 4 Nr. 17 a) UStG
• Kuhmilch: 7% gem. § 12 Abs. 2 Nr. 1 UStG i.V.m. Anlage 2 Nr. 4
• Soja-/Reis-/Hafermilch: 19% gem. § 12 Abs. 1 UStG

Hoffen wir mal, dass da demnächst mal mehr Wert auf Gerechtigkeit gelegt wird – hauptsach’ die Milchindustrie wurde wieder gefördert …

Schon lange vor gehabt, jetzt endlich wahr geworden — Stop-Motion Videos “drehen” …

Seht hier welch tolles Werk wir, d.h. vier Mitglieder der LUG Ansbach, geschaffen haben:

… das war dann unser “Meisterstück”, vorher sind noch paar Versuchsvideos entstanden. Mal sehen, schmeckt jedenfalls nach mehr

Nachdem ich die Idee schon ein paar Wochen mit mir herumgetragen habe, habe ich jetzt vor wenigen Tagen damit begonnen mir ein Tool zur Verwaltung von Rezepten zu erstellen. Die Idee ist, dass das nicht nur eine stupide Liste ist, sondern dass auf Grund der Datenbank in Kombination mit den Listen “Favorit”, “Zutat da, muss aber weg”, “Zutat nicht da” (inkl. aktuell nicht beschaffbar) und “Rezepte der letzten Tage” die Rezepte automagisch gescored werden, vulgo aktiv Vorschläge machen.

Das Projekt (bzw. dessen Anfänge) findet sich inzwischen unter https://github.com/stesie/cookiedb auf Github.

Entwickelt wird das Ganze in Common Lisp, momentan gibt’s nur ein teilfertiges Backend.  Frontend wird zunächst wohl eine Kommandozeilenoberfläche.  Nach ersten Erfahrungen dann evtl. eine mehrnutzerfähige Weboberfläche, mal sehen

von einem Arbeitskollegen (Jochen) habe ich folgendes besondere Weihnachtgeschenk bekommen:

… eine Glaskugel. Wenn die Kommunikation mit $Kunde sich wieder etwas schwieriger gestaltet

Danke!

Die Homepage des Taxbird-Projekts erstrahlt im neuen Gewand, … ebenfalls mit WordPress 3.0. Vorbei die Zeit von mit GNU m4 gebastelten HTML-Seiten

Nachdem mein Skript zum Erzeugen eines RSS-Feeds von german-bash.org schon eine Weile nicht mehr funktionierte, hier wieder eine aktualisierte Version … Website-Scraping ist einfach keine Lösung, schade, dass die nativ nicht RSS anbieten. Naja, besser als jeden Tag auf die Seite gehen und feststellen, dass nur ein Quote ist und Werbung gucken, …

#! /bin/sed -nf
#
# Generate RSS-Feed from http://www.german-bash.org/action/latest
#
# Copyright (C) 2008,2011 by Stefan Siegl <stesie@brokenpipe.de>
# License: GPLv3+
#
/<html/ { c\
<?xml version="1.0" encoding="utf-8"?>\
<rss version="2.0">\
  <channel>\
      <title>GBO Quotes</title>\
      <description>german-bash.org - Die neuesten Zitate</description>\
      <language>de-de</language>
p
}
/<span class="id"><a title="Zeige Zitat/ { s|^[^0-9]*\([0-9]\+\).*|<item>\
  <title>GBO Quote \1</title>\
  <link>http://www.german-bash.org/\1</link>\
  <description><![CDATA[\
  <p>|; p
}
/<div class="zitat">$/ { :quoteloop
  n
  /<span class="quote_zeile">/ {
    /<\/span>/!n
    s|<[^>]*>||g; s|^[ \t]*||; s|$| <br />|; p; bquoteloop
  }
  c </p>\
]]></description></item>
}
/<\/html/ { c </channel></rss>
  p
}

… und dann einfach

wget -U "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100618 Iceweasel/3.5.9 (like Firefox/3.5.9)" -q -O- "http://www.german-bash.org/action/latest" | gbo-to-rss

… oder so ähnlich. Der User-Agent WGet geht nicht, der ist nämlich böse, oder so …

Hurra! Das Projekt Kopete SILC, das zugegeben jetzt eine ganze Weile brach lag, hat einen neuen Mitstreiter gefunden: Conrad Hoffmann

Er hat zwischenzeitlich das Projekt bei Gitorius registriert und auch ein paar Bugs gefixt, siehe die Kopete SILC Projektseite dort.

Für den Moment bleibt es noch bei der alten Kopete SILC Homepage, kann aber sein, dass diese auch in Kürze ein neues zu Hause findet

hier ein besonderes Schmankerl aus dem Internet:

… nachdem es wohl wirklich keinen Sinn macht, sondern nur der eigenen Bequemlichkeit geschuldet ist, bin ich auch dazu übergegangen, meine Rechner sowohl zu Hause als auch auf der Arbeit abzuschalten. Hoffen wir mal, dass es dabei bleibt und nicht der Schweinehund wieder zuschlägt.

by Nigel Upchurch on Vimeo.

… gefunden auf dem Weg zur ICMP5 in der Nähe von Münchsteinach, bzw. Neustadt/Aisch.

Seit einigen Tagen schwirrte jetzt schon der Gedanke in meinem Kopf, Daten auf Basis der PLZ-Leitregion (d.h. anhand der ersten zwei Ziffern der PLZ) grafisch dar bzw. gegenüber zustellen. Hier stellen sich prinzipiell zwei Probleme:

• die Darstellung macht nur im Rahmen eines Quotientens Sinn. Im einfachsten Fall kann das bspw. schlicht die Retourenquote sein.  Komplizierter wird es, wenn die Zahl der Einwohner der Leitregion berücksichtigt werden soll. Fündig wurde ich hier bei OpenGeoDB, einem Projekt, das Geo-Daten auf Wikibasis zusammenträgt. U.a. sind auf Gemeindeebene auch PLZ und Einwohnerzahlen gepflegt. Letztlich mussten diese “nur” akkumuliert und abgespeichert werden: geodb_zipregions.sql
• letztlich bedarf es noch einer Bibliothek, die die einzelnen Regionen in Form einer Karte darstellen kann.  Eine solche konnte ich jedoch auch nach langer Suche nicht auftun.  Was einem fehlt macht man kurzer Hand selbst.  Hier ist das Ergebnis: PLZ-Regionenkarte im SVG-Format, die pro Leitregion einen Pfad enthält, dessen ID dem Schema plzXX folgt.

Hier das obligatorische Beispiel:

Happy hacking!

This work is licensed under a Creative Commons Attribution 3.0 Germany License.

Update

Ich bin jetzt noch über das Projekt pyGeoDb gestolpert, das u.a. genau das kann, was ich gebraucht habe: beliebige Postleitzahlen bzw. -regionen in einer Karte markieren. Hierzu werden die Daten aus der openGeoDB mit OSM-Daten kombiniert und ausgegeben. Die Pfade sind ziemlich detailgetreu und das resultierende SVG dementsprechend groß. Das Ergebnis kann sich aber ebenfalls sehen lassen:

Das SVG zu dieser Grafik findet sich als geomaphq.svg.gz.

Wer kennt das Problem nicht, man sitzt irgendwo mit dem Laptop und hat keinen VPN-Zugang, möchte aber doch einmal kurz per SSH auf eine Maschine, die man nicht unmittelbar erreichen kann. Die Lösung zu dem Problem heißt multihop bzw. stacked SSH. Im Internet finden sich auch gleich mehrere Anleitungen, die Beste, die ich gefunden habe, ist wohl diese: http://www-e.uni-magdeburg.de/jschulen/ssh-proxy.html

Die ssh-Versionen sind überall aktuell genug, dass der Ansatz ohne netcat ebenfalls funktioniert.  Hier der Auszug aus meiner .ssh/config:

Host _dest
  HostName dest.somewhere.private
  User sts
  ProxyCommand ssh -A gateway -W %h:%p

Host gateway
  Hostname gateway.dyndns.org
  user sts

Ich verwende im ProxyCommand die ssh-Option -A, die dafür sorgt, dass das innere SSH auf den SSH-Agent am lokalen Rechner zugreifen kann. Das will man natürlich nur verwenden, wenn man das Gateway unter Kontrolle hat!

Nachdem der Verbindungsaufbau logischerweise auf diese Art noch länger dauert, bietet es sich i.d.R. an, dass weitere SSH-Aufrufe sich die bereits bestehende Sitzung teilen. Das geht ebenfalls recht simpel:

Host *
  ControlMaster auto
  ControlPath ~/.ssh/tmp/%h_%p_%r

… mir wurde bei der Gelegenheit wieder klar, SSH kann erheblich mehr, als man ihm immer wieder zutraut und ein Blick in die Manpage ist das Ding allemal wert.

… so der Titel des Liedes der Damsels of Dorkington, das mir jetzt schon eine ganze Weile im Kopf herum schwirrt.

Einfach immer wieder lustig und wert angesehen zu werden.

… und das grüne Viech (Handpuppe oder wie auch immer) was man da am Anfang sieht find’ ich ja nur noch geil.  Wer weiß, wo es sowas gibt, möge es mir bitte sagen.  Oder zum Geburtstag schenken, oder oder …

Es war mal wieder so weit, ein neues System zum Veröffentlichen von mehr oder weniger sinnbefreiten Dingen musste her. Das bisher zur Veröffentlichung verwendete zerties.org Wiki hatte zugegebenermaßen seinen Charme, aber 100 %-ig glücklich war ich damit auch nie, ein Blog lässt sich damit schlicht nicht sonderlich gut abbilden. Zu dem Zeitpunkt wollte ich auch kein Blog mehr. Dennoch muss ich zugeben, dass das chronolgische, artikelweise Veröffentlichen auch etwas für sich hat. Letztlich sollte es damit selbst mir gelingen, eine gewisse Struktur in das Geschehen hier zu bringen …

Gehen wir davon aus, dass künftig auch öfter wieder ein neuer Eintrag entsteht als zuletzt im Wiki.  Die Bedienung könnte zumindest nicht einfacher sein  … wer nicht schon nachgesehen hat, es handelt sich um ein WordPress in der Version 3.0.