Aus dem Leben eines Szlauszafs

Privat versichert zu sein hat so einige Vorteile, aber auch zumindest einen Nachteil: man muß sich nicht nur einmal im Jahr mit der Steuererklärung herumschlagen (Tag des Grauens!), sondern auch noch mindestens ebenso oft mit der Einreichung der Rechnungen bei der Beihilfestelle und ggf. auch der Krankenversicherung. Insbesondere wenn wie bei mir im vergangenen Jahr über viele Monate Zahnarzttermin auf Zahnarzttermin folgte kommt da allerdings ein hübsches Sümmchen zusammen, das zur Erstattung ansteht; noch nicht ganz ein fünfstelliger Betrag, aber es geht summa summarum doch sehr deutlich in diese Richtung, insofern war es höchste Zeit, sich wieder einmal hinzusetzen und die Abrechnung zu machen. Damit wäre dann auch das Wochenende - mit Server“reparatur” und Rechnungssammlung - konstruktiv verbracht.

*seufz* Seit gestern ist zwar der heimische Server wieder ordentlich im Betrieb, dafür bekam ich gerade die Nachricht,  daß meine mich seit bestimmt 15 Jahren treu begleitende Armbanduhr offenbar ihre beste Zeit hinter sich hat; sie blieb nämlich nicht wegen einer leeren Batterie stehen, sondern aufgrund eines Defekts, und die Reparatur wäre teurer als der Neupreis. Nur habe ich mich inzwischen so an sie gewöhnt, daß ich auf der einen Seite eigentlich gar keine neue Uhr haben möchte, auf der anderen Seite steht eine “richtig gute” Armbanduhr schon lange auf der Liste der Dinge, über die ich mich, “wenn mal Zeit ist”, informieren und dann ggf. käuflich erwerben möchte. Da stehen - teilweise seit mehreren Jahren - aber auch andere Dinge drauf, Computer, Autos, ... Ich sehe auch momentan nicht, daß ich in nächster Zeit insofern zu einer Entscheidung kommen würde. Das spricht dann also doch eher für eine Reparatur.

Momentan viel entscheidender ist für mich allerdings die Frage, was ich denn mache, bis ich wieder - auf welchem Wege auch immer - eine funktionsfähige Uhr habe; denn natürlich weisen alle hier noch herumliegenden Uhrmodelle allesamt eine leere Batterie auf. Werde ich also wohl in den nächsten Tage öfters mal das Handy zücken müssen, um die aktuelle Zeit zu erfahren (und dabei komme ich doch sowieso schon chronisch zu spät!).

Ich hatte vor knapp zwei Wochen über die provisorische Lösung meines Netzwerkproblems berichtet. Heute kann ich endgültig Vollzug melden: der Berg, will sagen, der Server ist mitsamt Peripherie wieder an seinen alten Platz zurückgerollt und dort angeschlossen, und die Connectivity hat ein provisorisch verlegtes Patchkabel wiederhergestellt. Works for me, und alles andere machen wir dann mal (viel) später.

Gerne wird ja von der Servicewüste Deutschland gesprochen, wobei oft weniger der gebotene Service als vielmehr die überzogenen Ansprüche der Kunden das Problem sind. Manchmal geht’s aber auch umgekehrt: berechtigte, ja notwendige Beschwerden unterbleiben, und so bleiben dann auch Probleme unentdeckt.

So ging es mir mit der von mir angebotenen Schreiberliste der Newsgroup de.etc.notfallrettung; zu der sollte man sich als interessierter Teilnehmer einfach online anmelden können. Nur funktionierte das nicht. Und zwar nicht erst seit gestern nicht, sondern schon seit über einem Jahr nicht - die letzte erfolgreiche Anmeldung datierte aus 2008. Und der eine oder andere hat es offensichtlich versucht, festgestellt, daß es nicht funktioniert (die notwendige Bestätigungsmail wurde nicht erzeugt bzw. enthielt keinen validen Bestätigungscode), und dementsprechend ... mit den Schultern gezuckt und nichts getan. Weil’s ihm egal war? Weil er den Fehler bei sich suchte? Weil er mich nicht belästigen wollte? Weil er sich dachte, ich vergeude doch nicht meine Zeit mit funktionsuntüchtiger Software? Oder weil keine geeignete Kontaktmöglichkeit zu finden war? Ich weiß es nicht - Fakt ist nur, daß sich bis jetzt nie jemand gemeldet hat. Und nachdem jetzt dankenswerterweise (zwar keine Beschwerde, aber) eine Nachfrage kam, war der Fehler recht schnell zu finden und zu beheben.

Jetzt tut wieder alles - aber auch freiwillige Angebote können nur funktionieren, wenn (sie jemand testet und) bei Fehlern jemand Bescheid gibt.

Also: mehr Feedback, bitte!

Wie ich vor anderthalb Wochen schrieb, fehlte meiner Beschreibung der Funktionsweise des Newsservers INN noch der Teil über Expire; namentlich deshalb, weil mir die Funktionsweise selbst nicht hinreichend klar war. Inzwischen habe ich aber, so denke ich, dank der hilfreichen Erläuterungen in de.comm.software.newsserver den notwendigen Durchblick gewonnen und die Beschreibung entsprechend ergänzt.

Eigentlich hatte ich ja gehofft, daß wir für dieses Jahr den Winter überstanden und Schneefall, Eisglätte und diese ganzen Wetterunbilden hinter uns gelassen hätten- doch ganz im Gegenteil, heute hat es uns noch einmal richtig erwischt. Und natürlich muß ich genau heute für eine Projektpräsentation ins schöne Rottenburg ... was eigentlich kein Problem gewesen wäre, wenn nicht ausgerechnet wenige hundert Meter vor der entsprechenden Autobahnausfahrt direkt eine ganze Reihe Autos ineinander gefahren wäre und einen wunderbaren Stau verursacht hätte, der mir letztendlich eine gute Dreiviertelstunde Verspätung (über die wetter- und fahrbahnzustandsbedingte Verzögerung hinaus) eingebracht hat. Nachdem ich dann aber einmal da war, ließ sich ein Gutteil der Zeit (dank reichlich kalkulierter Puffer) wieder aufholen, und wir haben mit einer knappen halben Stunde Verspätung dann endlich begonnen.

Dafür lief die Präsentation gut, und nachdem das nicht die einzige, sondern die erste von vieren ist (die übrigen werden auch in den kommenden Tagen stattfinden), kann es beim nächsten Mal organisatorisch ja nur besser werden.

INN bietet vielfältige Möglichkeiten der Benutzerauthentifizierung an. Wenn man einer größeren Anzahl von Benutzern einen Zugang einräumen will, bietet es sich an, die notwendigen Daten - Benutzerkennung, Paßwort, etc. - in einer Datenbank zu halten, bspw. in einer MySQL-Datenbank.

Eine denkbare Lösung dafür, die neben Benutzerkennung und Paßwort auch Namen und E-Mail-Adresse des Benutzers erfaßt sowie ein Flag für aktive/inaktive Benutzer und eine Trennung nach verschiedenen Zugriffsstufen kennt sowie den Zeitpunkt des letzten Logins festhält, möchte ich hier vorstellen. Dazu gehört über das hier vorgestellte Script für den INN hinaus natürlich noch ein passendes (Web-)Interface, mit dem Benutzer angelegt und gelöscht sowie Paßworte geändert werden können etc.

Die Datenbankstruktur sieht folgendermaßen aus:

CREATE TABLE IF NOT EXISTS `users` (
  `userid` int(11) NOT NULL auto_increment,
  `user` varchar(16) collate latin1_bin NOT NULL default ‘’,
  `password` varchar(16) collate latin1_bin NOT NULL default ‘’,
  `active` tinyint(1) NOT NULL default ‘1’,
  `username` varchar(60) collate latin1_bin default NULL,
  `usermail` varchar(60) collate latin1_bin default NULL,
  `domain` varchar(40) collate latin1_bin default ‘<EDITME>’,
  `llo` date default NULL,
  PRIMARY KEY  (`userid`),
  UNIQUE KEY `user` (`user`)
);

Die Felder sollten weitgehend selbsterklärend sein; “llo” steht für “last logged in”.

Eines muß ich von den Basteleien aus der letzten Woche bzw. vom Sonntag noch nachtragen: ich habe bei meinem vor ungefähr einem Jahr installierten Munin die Mailbenachrichtigungen aktiviert und die Limits für “warning” und “critical” entsprechend angepasst, soweit das erforderlich war. Jetzt werde ich über Probleme ggf. alle 5 Minuten - nach jedem Munin-Poll - per E-Mail informiert.

Die Konfiguration ist hinreichend einfach. Zunächst sind die Benachrichtigungen auf dem zentralen Munin-Host im globalen Bereich der /etc/munin/munin.conf zu konfigurieren, für Benachrichtigungen per E-Mail bspw. so:

contact.thomas.command mail -s “Munin notification ${var:host}” thomas@provider.example
contact.thomas.always_send warning critical

Es können verschiedene Benachrichtigungsziele (Kontakte) definiert werden, wenn bspw. je nach Host unterschiedliche Ansprechpartner zu benachrichtigen sind; hier habe ich das Ziel “thomas” konfiguriert durch Angabe eines Betreffs und einer Zieladresse und der Zustände, bei denen Benachrichtigungen versandt werden sollen.

Danach können pro Host(gruppe) die zu verständigenden Kontakte definiert werden:

[host.domain.example]
contacts thomas

Zu verwenden ist natürlich einer der zuvor definierten Kontakte, hier eben “thomas”. An diesen Kontakt werden dann die entsprechenden Benachrichtigungen versandt.

Sinnvollerweise sollten - ebenfalls pro Host - die nicht passend gesetzten oder gar aufgrund von Konfigurationsproblemen völlig unsinnig gesetzten Limits korrigiert werden durch Einfügen von Zeilen wie

sensors_temp.temp2.warning 55
sensors_temp.temp2.critical 65

oder ähnlich. Wo Handlungsbedarf besteht, erkennt man ganz einfach am Mailbombardement nach der Aktivierung der Benachrichtigungen.

Natürlich können Benachrichtigungen nicht nur per E-Mail versandt werden. Für die Einzelheiten verweise ich auf die Munin-Dokumentation.

Mittlerweile schreiben wir schon Mittwoch in der ersten Arbeitswoche, aber ich habe es erst jetzt geschafft, die Zeit für einen Abstecher zu dem kranken Server zu erübrigen. Die Diagnose war kurz und schmerzhaft: das Netzwerkkabel hat es hinter sich. Als Interimslösung bietet es sich an, einfach mal ein Kabel lose über den Flur zu verlegen, bis jemand Zeit hat, sich der Sache richtig anzunehmen. Doch auch insofern bleibt mein Glück mir treu: Netzwerkkabel einzupacken hatte ich natürlich vergessen, und die vorhandenen Exemplare sind für den angedachten Zweck alle zu kurz.

*seufz* (Das wird bald noch zu meiner häufigsten Äußerung hier.)

Insofern mußte ich mich wieder einmal an das alte Wort vom Berg, der sich - mangels Bewegungsfreude des Propheten - zu ebendiesem zu bewegen hatte, halten: ich habe den Server aus seiner Abstellkammer einfach (samt Monitor und USV) zur nächsten funktionsfähigen Netzwerkdose gerollt und da wieder ans Netz gehängt. Das bedeutet, daß es zwar keinen Zugriff auf den Drucker gibt, aber den nutzt derzeit eh niemand, und wenigstens ist die Maschine jetzt wieder voll funktionsfähig. Außerdem habe ich direkt eine Großmenge Patchkabel in diversen Längen und Formen geordert, die mich dann bei meinem nächsten Besuch in der alten Heimat hoffentlich erwarten werden, und dann zieht die Kiste zurück in ihr Kämmerchen.

Über allem anderen nicht zu vergessen: ich habe jetzt auch mit Viktor Kafkes visyn.net ein Peering aufgesetzt. Viktor bietet praktischerweise via GUP seinen Peers die Möglichkeit an, den Feed selbst zu konfigurieren und neue Gruppen aufzunehmen bzw. alte Gruppen zu streichen. Das ist wirklich praktisch, wenn man mal (ggf. testweise) eine neue (Teil-)Hierarchie ins Peering aufnehmen möchte, ohne alle Peers deshalb anmailen zu müssen.

Danke für das Peering!