Netz - Rettung - Recht

An manche Dinge gewöhnt man sich einfach - konkret unter anderem daran, im Falle eines Falles nicht nur über den üblichen Kfz-Verbandkasten oder ein paar Pflaster, pardon, Wundschnellverbände aus der Hausapotheke zu verfügen, sondern auch über eine etwas erweiterte Notfallausrüstung. Allerdings braucht man so etwas üblicherweise jahrelang nicht, und Medizinprodukte haben mit Arzneimitteln gemein, (überraschend schnell) ihr Verfalldatum zu erreichen. Wie fast schon befürchtet war das dann auch mal wieder der Fall, und zwar so gründlich, daß kein einziges Medizinprodukt oder Arzneimittel mehr verwendbar war (und der Großteil hatte sein Verfalldatum schon vor 2010 erreicht).

Also habe ich bereits letztes Jahr mal den Bestand durchgesehen und die nötigen Bestellungen aufgegeben; nach einem heutigen Besuch bei der Apotheke habe ich dann auch die letzten fehlenden Bestandteile aktualisiert und muß mir jetzt mindestens 2-3 Jahre keine Gedanken mehr machen.

Letztes Jahr hatte mich am Abend des letzten Urlaubstag ein Ausfall meines heimischen Servers erwischt; Ursache war ein Defekt des Netzwerkkabels, das vor Zeiten einmal der Einfachheit halber über den Dachboden verlegt worden war. Ursache unklar, obwohl aus meiner Sicht bereits damals schon viel für den Einzug eines Mitbewohners dort oben und dessen Verantwortlichkeit gesprochen hat. Danach ist die Sache etwas im Sande verlaufen.

Gelöst ist das Problem aber offensichtlich nicht, denn was auch immer die Ursache ist, sie breitet sich aus: seit heute hat auch mein dort noch vorhandener Desktoprechner kein Netz mehr. Auch dort liegt’s am Netzwerkkabel. Mag ja sein, daß die Kabel damals vor gut 10 Jahren einfach schlecht verlegt wurden und nun allmählich ausfallen, aber irgendwie mag ich daran als Ursache nicht so recht glauben … Ärgerlich ist’s ursachenunabhängig allemal, vor allem, weil dort oben auch die Telefonkabel verlegt sind. Nun denn, we’ll see.

Über die Einrichtung des Monitoring-Tools Munin habe ich bereits vor 2 Jahren geschrieben. Mittlerweile habe ich meine Installation aus den Debian-Backports auf die Version 1.4.5 geupdatet, die deutlich ressourcenhungriger zu sein scheint; überdies sind mittlerweile auch mehr Hosts durch Munin zu überwachen. Beides führte zu einer spürbaren Grundlast auf dem (älteren) System, das bislang den Munin-Server darstellte; daher habe ich Munin nunmehr auf eine andere Maschine umgezogen, was deutlich sichtbare Performance-Verbesserungen gebracht hat, die sich schon in einer Laufzeitverkürzung darstellen.

Bei dem Umzug sollten aber auf jeden Fall die bereits erstellten Statistiken aus den letzten beiden Jahren erhalten bleiben, um nicht komplett von vorne beginnen zu müssen. Eigentlich sollte ja nichts leichter als das sein: Munin auf dem neuen Rechner installieren, die Konfiguration des alten Systems übernehmen, das neue System auf allen Nodes für den Abruf freischalten, testen, dann die gesammelten Daten auf dem alten Rechner packen, auf den neuen transferieren und dort wieder auspacken, Munin auf dem alten Rechner anhalten, fertig. Ungefähr so geht das auch tatsächlich - wenn denn diebeiden Systeme dieselbe Architektur haben. Wenn aber der alte Rechner ein 32bit-System ist und der neue ein 64bit-System, dann sind die erzeugten RRD-Dateien nicht kompatibel. Autsch. Aber auch dafür gibt es glücklicherweise eine Lösung, die ich einem alten Eintrag aus dem Cacti-Forum abgeschaut habe.

"Munin auf einen anderen Host umziehen" vollständig lesen

Es gibt Dinge, die macht man nicht gerne und schiebt sie vor sich her. Und wenn man sie dann doch erledigt, ärgert man sich über sich selbst, weil das alles eigentlich überraschend schnell ging. Und man nimmt sich vor, nächstes Mal direkt damit anzufangen. Und beim nächsten Mal - im nächsten Jahr - kommt erst etwas dazwischen, und dann hat man gaaaar keine Zeit und gaaaar keine Lust, und man schiebt sie vor sich her, und … Genau.

Die alljährliche Steuererklärung ist - für mich - eines dieser Dinge, obwohl ich in den letzten Jahrzehnten darin eigentlich genug Routine erworben haben sollte. Und nachdem das letzte Jahr sich als besonders anstrengendes solches erwies, stand diese Aufgabe immer noch aus (mit allen Konsequenzen, die das so zu haben pflegt).

Ich kann aber nunmehr stolz verkünden: jetzt nicht mehr. Ich habe mich endlich ausreichend motivieren können, die Ablage zu ordnen, Belege zu sammeln und die notwendigen Eingaben in den diebischen Rabenvogel zu tippen, so daß die Steuererklärung 2009 nun fertig ist - und weil man diesen Elan nutzen soll, habe ich gleich dasselbe für 2010 gemacht, soweit die erforderlichen Belege schon vorhanden sind. Der Rest wird sich dann wirklich schnell erledingen lassen, und so bin ich guter Hoffnung, es in diesem gerade angefangenen Jahr vielleicht (seit Menschengedenken zum ersten Mal) wieder zu schaffen, die Erklärung innerhalb der vorgesehenen Frist abzugeben.

Vor einem guten Jahr habe ich angefangen, mich um lokale und regionale Hierarchien in Deutschland bzw. dann im deutschsprachigen Raum zu kümmern und die entsprechenden Informationen zusammenzutragen; zunächst im Zusammenhang mit der Sortierung meines Newsservers, dann aber, weil ich festgestellte hatte, daß es für viele dieser Hierarchien keine aktuellen Daten (mehr) gibt, erst recht nicht an einem Platz zusammengetragen. Die entsprechenden Informationen habe ich dann unter DE-Regio auf meiner Homepage zusammengestellt, eine Liste nach news.lists.misc  gepostet und das generische control.ctl beim ISC aktualisieren lassen.

Danach sind die entsprechenden Bemühungen aus Zeitmangel leider weitgehend eingeschlafen. Ich möchte, wenn möglich, die vor einem Jahr angefangene Arbeit nun vollenden oder wenigstens fortführen, und habe als ersten Schritt die entsprechenden Seiten aus meiner Homepage in ein eigenes Projekt de-regio ausgegliedert und die Seiten komplett übersetzt. Geplant ist ergänzend zu der Datenbank ein Wiki für weitere Informationen - bspw. Geschichte und Geschichten der entsprechenden Hierarchie -, die Komplettierung der Übersicht und das Ausbügeln verbliebener Fehler.

Drucken ist eine Standardaufgabe - Scannen auch. Heutzutage gibt es dafür bereits Multifunktionsgeräte, die in der Regel Drucken und Scannen und in Kombination dieser beiden Funktionen auch kopieren können; teilweise beherrschen sie auch das Faxen.

Nicht immer aber hat man eines dieser Multifunktionsgeräte zur Verfügung, sondern hat nur Scanner und Drucker; oder man hat ein Multifunktionsgerät, aber es druckt nicht; oder man hat ein Multifunktionsgerät, will aber die Druckfunktion nicht nutzen, weil es sich bspw. um einen Tintenstrahldrucker handelt und der Ausdruck dort sowohl langsamer als auch teurer ist als auf dem gleichfalls vorhandenen Laserdrucker. In diesem Fall kann man dennoch Dokumente einscannen und danach dann ausdrucken. Sehr bequem ist es aber, wenn man dazu ein Tool hat, was das automatisiert.

iCopy ist ein solches Windows-Tool. Es erlaubt die Auswahl des zu verwendenden Scanners und Druckers und weitere Konfigurationseinstellungen - in der Regel genügt der Default -, und danach muß man nur noch auf den Kopierknopf klicken. Der Scanner scannt, und sobald das Bild eingescannt ist, druckt der Drucker es aus. Voilà. Selbst ohne automatischen Einzug am Scanner kann man so schnell und effizient einen ganzen Stapel Kopien anfertigen: Original einlegen, Abdeckung am Scanner schließen, Kopiertaste in iCopy anklicken, nach dem Scan das Original gegen das nächste tauschen, während der Drucker druckt, lather, rinse, repeat.

iCopy ist open source, aktuell ist derzeit Version 1.48 vom 05.01.2011.

Niemand will Backup. Alle wollen Restore.

(Kristian Köhntopp zitiert einen Vertriebler - Fachbegriffe der Informatik #125)

Regelmäßige Backups sind wichtig und auch durch redundante Systeme wie RAIDs nicht zu ersetzen; ganz abgesehen davon, daß bei einem RAID 1 gerne die - meistens ja zum selben Zeitpunkt wie die erste in Betrieb genommene - zweite Platte beim notwendigen Rebuild zusammenbricht, schützt ein RAID auch nur gegen Datenverlust durch Ausfall einer Festplatte, aber weder gegen versehentliches oder böswilliges Löschen, Überschreiben oder Verändern von Daten, noch kann es gegen einen fatalen Schaden des gesamten Systems (Brand, Diebstahl, …) schützen. Backups sollten daher

• regelmäßig durchgeführt werden,
• versioniert sein (so daß man einen längeren Zeitraum zurückgehen kann) und
  
• off-site transferiert werden können.

Zumindest dann, wenn man keine Kontrolle über die Infrastruktur hat, auf der die Backups gespeichert und über die sie transportiert werden, sollten Backups auch verschlüsselt sein. Diese letzte Anforderung ist typisch für sog. "Rootserver", also Mietserver, zu denen bei üblichen Angeboten auch ein sog. "Backupspace", also Speicherplatz auf einem Storage gehört, auf den zumeist nur per (unverschlüsseltem) FTP zugegriffen werden kann. Selbst wenn man dem Provider und seinen Mitarbeitern vertraut, kann man nicht ausschließen, daß auch Dritte - andere Kunden, … - zumindest den unverschlüsselten Datenverkehr zwischen dem zu sichernden Server und dem Storage "belauschen" können. Wenn man seine Backups also unverschlüsselt überspielt, kann die gesamte Konfiguration samt aller Paßworte usw. usf. mitgelesen werden.

Schließlich gibt es eine letzte Anforderung für sinnvolle Backups: sie sollten, einmal eingerichtet, möglichst wenig Aufwand bedeuten, optimalerweise automatisiert sein, denn nur dann werden sie auch wirklich regelmäßig durchgeführt.

Alle zuvor genannten Anforderungen erfüllt das Tool duplicity, für das die c’t bereits anno 2006 ein Frontend namens ftplicity entwickelt hat, das nunmehr unter dem Namen duply weiterentwickelt wird. duply unterscheidet sich u.a. dadurch von ftplicity, daß es nicht nur die Konfiguration der Übertragung via FTP unterstützt, sondern auch auf anderem Weg (was dann auch die Namensänderung erklärt).

duplicity sichert Dateien und Verzeichnisse in (nicht gepackte!) tar-Archive, verschlüsselt diese vermittels GnuPG und überträgt die Sicherungen in kleinen Häppchen auf verschiedenen Wegen (lokal, FTP, SCP, rsync, …) auf das Sicherungsmedium; dabei werden inkrementielle Backups über den rsync-Algorithmus erstellt, d.h. nicht alle veränderten Dateien gesichert, sondern ggf. nur ein diff, was wiederum Platz und Bandbreite spart. duplicity dürfte in den meisten Distributionen paketiert sein, duply ist es in Debian ab Squeeze, kann aber in jedem Fall trivial installiert werden.

"Backup mit duply und duplicity" vollständig lesen

Auf der Suche nach einem Tool zur Erstellung von Diagrammen (bspw. Netzwerkdiagrammen etc. pp.) unter Windows, das nicht Visio heißt und vor allem nicht in dessen preislichen Regionen rangiert, bin ich auf das Freeware-Programm yED gestoßen, das mir schon recht gut gefällt. Was mir noch etwas fehlt sind passende Symbole (Shapes), derzeit namentlich für Netzwerkdiagramme und am besten optisch passend zu den bereits vorhandenen. Ein Musterdiagramm könnte bspw. so aussehen:

 

Das Symbol für den Router ist aber schon nicht so richtig passend, Laptops hat’s bisher auch nicht, usw. usf.

Wenn jemand noch bessere Software im Angebot hat, nehme ich natürlich auch Hinweise darauf gerne entgegen.

Bei meiner Arbeit mit git stehe ich immer wieder vor der Frage, ob man dieses oder jenes damit nicht einfach machen können müßte. Meistens lautet die Antwort auf diese Frage "ja", aber teilweise muß man schon etwas googeln, um diese Antwort zu finden. Daher möchte ich ab und an kleine ergoogelte Wissensschnippsel mit der Leserschaft teilen; vielleicht steht ja noch einmal jemand anderes vor demelben Problem (und überdies sind deutschsprachige Informationen zu git nicht so wirklich umfänglich vorhanden).

Git über SSH und mehrere SSH-Keys pro Host

Mehr eine allgemeine SSH-Frage, aber da sie sich mir im Zusammenhang mit git gestellt hat …

Ein beliebter Zugriffsweg auf Git-Repositories ist der über SSH, insbesondere, wenn es auch um einen schreibenden Zugang geht und man diesen authentifizieren will. Zu diesem Zweck kann man sich den passenden SSH-Schlüssel für den Zugriff auf das Git-Repository über die SSH-Konfiguration definieren, bspw. durch einen Eintrag in ~/.ssh/config wie den folgenden:

Host git.example.org
Port 2022
IdentityFile ~/.ssh/gitkey

SSH-Zugriffe auf den Server "git.example.org"  erfolgen also auf Port 2022 (statt 22) und unter Verwendung des Schlüssels "gitkey". Der Git-Zugriff via SSH berücksichtigt diese Einstellungen dann automatisch.

Was aber tun, wenn man von demselben Client mit mehreren verschiedenen SSH-Schlüsseln auf denselben Server zugreifen muß, wie es insbesondere bei der Verwendung von Tools wie gitosis auf der Serverseite vorkommen kann? Dieselbe Frage stellt sich natürlich, wenn man sich neben dem Zugriff auf ein Git-Repository auch ganz normal per SSH auf dem Server einloggen können will. Auf die obige Art und Weise läßt sich nur ein Key für den Zugriff auf "git.example.org" vordefinieren - und will man wirklich immer einen abweichenden Schlüssel per Option angeben? Eine Lösung wäre die Vergabe von weiteren CNAMEs im DNS für git.example.org, aber das skaliert auf die Dauer auch nicht.

Die einfachste Lösung dafür bieten Aliase direkt in der SSH-Konfiguration, wie das Git-Wiki empfiehlt:

Host private.example.com
    User myname
    Hostname git.example.com
    IdentityFile ~/.ssh/private-identity
Host public.example.com
    User groupname
    Hostname git.example.com
    IdentityFile ~/.ssh/public-identity

Auf diese Art und Weise kann man denselben Server mit zwei verschiedenen Konfigurationen ansprechen.

"Tips und Tricks für den Umgang mit git" vollständig lesen

Als Hobby-Admin *räusper* lernt man ständig dazu. Bekannt und bewußt war mir schon, daß nach (Sicherheits-)Updates von Bibliotheken, die von verschiedenen Programmen genutzt werden (man denken an OpenSSL), die entsprechenden laufenden Prozesse neu gestartet werden müssen, weil sie nur dann die dynamisch geladenen Bibliotheken neu laden und zuvor mit der alten Version arbeiten, was insbesondere bei sicherheitsrelevanten Updates nicht besonders hilfreich ist. Bisher ging ich allerdings (blauäugig) davon aus, daß die Paketverwaltung das schon richten wird. Durch einen Beitrag von Paul Wise in der Debian-Developer-Mailingliste wurde mir nun bewußt, daß das - jedenfalls / auch unter Debian - nicht der Fall ist, die betreffenden Dienste also manuell neu gestartet werden müssen.

Hilfreich ist in diesem Zusammenhang das im Paket debian-goodies enthaltene Tool checkrestart, das überprüft, welche laufenden Prozesse noch auf Dateien zugreifen, die mittlerweile gelöscht wurden, und diese auflistet (zusammen mit ggf. vorhandenen init-Scripts, um die Dienste neu zu starten).

Wer (digitale) Fotos - in welcher Menge, Häufigkeit und Qualität auch immer - macht, der kennt das Problem, sie online verfügbar zu machen. Gut, das eigentliche Problem ist die Überwindung der eigenen Faulheit und das Auswählen, Sortieren, Umbenennen und ggf. Kommentieren einmal wirklich anzugehen, aber man möchte dazu auch die entsprechende, möglichst einfach verwendbare, aber alle notwendigen Funktionen bietende Software haben.

Man kann dazu Web-2.0-Dienste wie flickr nutzen, aber nicht jeder möchte das, sei es, daß man solchen Diensten generell nicht traut und/oder die Software lieber selbst installieren möchte, sei es, daß man am "Sharing" von Fotos gar nicht interessiert ist, sondern den Zugriff potentiell nur wenigen ermöglichen möchte. Insoweit habe ich dann schon einiges durch: mehr schlecht als recht selbst gebaute Implementationen für die Webseiten meiner Hilfsorganisation oder einer Newsgroup (seit ~ 2002), dann für meine private Homepage (ebenfalls seit ~ 2002) mig, ein sehr einfaches Script (auch deshalb, weil man von den Platzhirschen wie Gallery nicht viel Gutes über die Sicherheit hörte), und seit Anfang 2008 (nach dem Erhalt meiner neuen Kamera Weihnachten 2007) auch eine Gallery-2-Instanz, mit der ich allerdings nie so recht angefreundet hatte (zumal bis zu einem Kurzurlaub 2008 zurück noch Bilder zum Sortieren und Hochladen im Backlog liegen - siehe die einleitenden Worte zu diesem Artikel ). Während ich jetzt darüber nachdachte, ob sich nicht ein Update auf Gallery 3 anbietet, bekam ich den weisen Rat, mir doch einmal piwigo anzusehen.

Und das hat mich überzeugt. Zumindest dann, wenn man eine Fotogalerie-Applikation nur für sich selbst ohne ausgefeiltes Benutzermanagement für mehrere Fotografen braucht (und wie oft teilt man sich eine Galerie wirklich zu mehreren?), ist piwigo eine tolle Lösung. Installation und Konfiguration sind einfach (Voraussetzungen: PHP und mySQL), wenn man das Prinzip einmal begriffen hat, der Upload ist übers Web wie auch einfach per FTP möglich, Thumbnails werden erstellt, Benutzer können in vorgegebene Rechtegruppen (Gast, Bekannter, Freund, Familie, …) oder in Nutzergruppen eingeteilt werden, und für Alben bzw. Fotos lassen sich dann die entsprechenden Zugriffsrechte setzen. Fotos lassen sich nicht nur in Alben, sondern in Kategorien zusammenfassen und zugleich noch beliebig taggen; der Benutzer kann sich die Fotos nach Kategorien oder Tags oder nach dem Kalender oder sonstwie anzeigen lassen, bekommt dabei aber immer nur die Fotos oder Kategorien zu sehen, für die er entsprechende Rechte hat. Außerdem gibt es eine Reihe vorgefertigter, recht ansehnlicher Skins.

Mir gefällt’s jedenfalls, und ich habe den heutigen Tag dann im wesentlichen dazu genutzt, aus den drei oder vier vorgenannten Quellen der letzten 10 Jahre die dort vorhandenen Fotos in einer Galerie zusammenzuführen und dann den Rest zu löschen. So gesehen also wie gestern ein weiterer Tag des Räumens und Sortierens.

Stand der gestrige Tag unter dem Zeichen des Umherschiebens von Papier und Geräten, so waren heute Dateien dran.

Meine "IT-Landschaft", wenn man dieses bombastische Wort dafür verwenden darf, ist - wie man so schön sagt - organisch gewachsen und dementsprechend dysfunktional. Früher[tm] saß ich an meinem (einen) Rechner, machte ab und an mal ein Backup, und alles war gut. Neuer Rechner, Kopieren der Daten, voila. Dann begann ich vor knapp 10 Jahren damit, zusätzlich einen Laptop zu nutzen, zuerst nur im Haus, um via WLAN unabhängig vom Arbeitsplatz zu werden, dann aber als täglicher Pendler vor allem auf dem Hin- und Rückweg zur und von der Arbeit. Damit stellte sich dann bald das Problem, wie man die beiden Rechner miteinander synchronisiert - eine Frage, auf die weder Windows (damals Windows 2000) noch der von mir genutzte Mail- und Newsreader Agent (denn das war und ist das meiste, was ich mobil so tue) besonders hilfreiche Antworten zur Verfügung hatten, zumal dann, wenn man auf dem Laptop aus Platz- und Sicherungsgründen nur die aktuellen E-Mails und die Newsgroups-Beiträge der letzten Tage/Wochen hat. Die erste "Lösung" dafür war, News und Mail im wesentlichen auf dem Laptop zu betreiben, die Mails nach Abruf nicht zu löschen und auf dem Desktoprechner dann jeden Abend die Postings und Mails des Tages nochmals (diesmal endgültig) abzurufen und (jahresweise) zu archivieren. Die Outbox vom Laptop ab und an rüberkopieren (und dort löschen), und alles funktionierte, mehr oder weniger, mit einigermaßen vertretbarem Aufwand.

"Digitale Archivalien" vollständig lesen

Nach einer arbeitsamen Woche tauchte heute plötzlich ein so gar nicht vorgesehener Eintrag auf meiner ToDo-Liste auf: Ich erhielt nämlich die Anregung, ich könne bei meiner ganzen Bastelei und Räumerei ja auch einmal zur Abwechslung etwas Sinnvolles tun und den vor vielen (!) Jahren günstig erhaltenen Farbtintenstrahler samt Scannereinheit endlich einmal anschließen, nachdem er mehrere Jahren in der alten und nun auch wieder mehrere Jahre in der neuen Wohnung Staub gefangen hat. Meine vorsichtige Anregung, es wäre doch viel besser, moderner und toller, stattdessen einfach gleich einen neuen Farblaserdrucker als Multifunktionsgerät zu kaufen wurde ohne weitere Aussprache abgelehnt, also habe ich mich dem Schicksal gefügt und meines Amtes gewaltet. Weil ich dann schon einmal dabei war, habe ich den (vorhandenen) Laserdrucker dann direkt ans andere Ende des langen Schreibtischs umgestellt und das "neue" Gerät umgesetzt, dabei diverse Papierstapel an andere Plätze geräumt ("Ablage machen" steht auch noch prominent auf der ToDo-Liste) und nach einigem hin und her dann auch Treiber und passende Software gefunden, um das Gerät in Betrieb zu nehmen.

Danach habe ich dann stundenlang damit gekämpft, den bisher problemlos funktionierenden Laserdrucker wieder in Betrieb zu nehmen … aber jetzt dürfte alles gut sein. Dann noch schnell eine neue Tonereinheit für den Laser bestellen (denn die bisherige versagt jetzt auch nach Schütteln den Dienst) und Farb- und Schwarzpatronen für den Tintenstrahler, damit man damit vielleicht nicht nur scannen, sondern auch wieder drucken kann, und jetzt kann ich wieder zu den Dingen zurückkehren, die auch wirklich auf dem Plan stehen.

(War aber auch mal Zeit, das endlich zu erledigen.)

Update vom 12.01.2011: Die Tintenpatronen sind jetzt da und eingesetzt, meinen Nagel habe ich mir abgebrochen *seufz*, und der Drucker (übrigens ein Canon MP360) spuckt immer noch nur weißes Papier aus. Vermutlich hat der Druckkopf den jahrelangen Stillstand nicht verkfraftet, das soll eine Krankheit dieser Geräte sein, wie man liest. Wasser half auch nicht, also werde ich das Projekt "kaputt ist er nun schon, schlimmer kann’s also kaum werden, und wo ich jetzt Tinte gekauft habe, will ich auch drucken" demnächst mal mit Alkohol fortsetzen. Wenn das alles nicht hilft, kann ich ja meiner Anregung noch einmal näher treten.

Update vom 15.01.2011: Auch das Einlegen der Druckköpfe in Alkohol hat eine Verbesserung nur insofern gebracht, als jetzt ein leichter Rot-Schleier ausgedruckt wird … Also bleibt es erstmal bei einer Nutzung als Scanner, und alles weitere sehen wir später.

Schon 2010 hatten wir es im März und April zweimal geschafft, jeweils zu einem Spielenachmittag einzuladen; im späteren Verlauf des Jahres hat dann allerdings wieder der Zeitmangel die Oberhand gewonnen, so daß es zu keiner Wiederholung kam. Heute waren wir dann zur Abwechslung bei Rince eingeladen und haben dort in netter Runde zu sechst erst mit einer Partie "Small World" begonnen, dann mit "Unter Geiern" fortgesetzt und schließlich mit einem Spiel "Finstere Flure" abgeschlossen.

Sehr schön war’s, leider sind solche Nachmittage immer viel zu kurz (aber morgen heißt es noch einmal früh aufstehen …).

Wie im letzten Jahr habe ich auch dieses Jahr, um nicht ganz aus der Übung zu kommen, in meinem Urlaub eine Pause eingebaut, und werde diese Woche arbeiten. Dankenswerterweise sind das ja hier im Süden nur vier Tage, und danach kann ich noch einige Tage Urlaub genießen, bevor es wieder "richtig" losgeht.

In diesem Sinne: bis nächste Woche!