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".
"INN: Authentifizierung gegen MySQL-Datenbank" vollständig lesen
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 <em>thomas</em>
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!
Heute hat Russ control-archive 1.3.0 releast, und die von mir letzte Woche submitteten Patches sind alle aufgenommen worden. Sehr schön! 
Außerdem wurde das Paket so weit aufgebohrt, daß auch Vermerke zu Hierarchien und entsprechende Sonderfälle jetzt aufgenommen werden können. Ich kann also, sobald ich wieder einmal Zeit finde (haha!), entsprechende Hinweise zu maintainten Hierarchien nachschieben und für die Hierarchien ohne Maintainter ggf. Änderungen des Gruppenbestands direkt zur Aufnahme in das generische active/newsgroups melden. Dann hätten wir wenigstens die deutsch(sprachig)en Hierarchien dort so weit wie möglich up-to-date.
Heute war nach meinem - langen - Urlaub der erste Arbeitstag, und ich fürchte, bereits jetzt vorhersagen zu können, daß ich auch in diesem Jahr zumindest auf absehbare Zeit zur Umsetzung irgendwelcher größeren Projekte nicht mehr kommen werde. Aber ich werd’s zumindest versuchen, und vielleicht schaffe ich es ja zum Februar hin, auch dieses Blog hier mal wieder auf den aktuellen Stand zu bringen. Derzeit sind leider weder die Einträge aus dem vergangenen Jahr noch die aus dem Januar veröffentlichungsreif. 
Update: "Bis" Februar hat es nicht geklappt, aber immerhin "bis Ende März". Die noch fehlenden Einträge vor allem aus dem Januar, aber auch aus dem Februar werden sukzessive (mehrere täglich) nachgeliefert, zugleich mit den "aktuellen" Einträgen (die allerdings wieder eine eher langsame Frequenz haben werden).
*tiefseufz* Murphy ist wirklich ein teuflisch fieser Kerl.
Jetzt hatte ich - mit Unterbrechungen - mehrere Wochen Urlaub. Heute ist der letzte Abend. Ab morgen geht es wieder richtig los. Und ausgerechnet heute abend entscheidet sich mein Homeserver, an dessen Standort ich mich nicht mehr regelmäßig aufhalte, dazu, Mucken zu machen. Will sagen: er ist nicht mehr erreichbar, und die Versuche, daran auf telefonischem Wege etwas zu ändern, ergeben nur, daß er offensichtlich ernsthafte Netzwerkprobleme hat - der Ethernet-Link ist offenbar tot oder jedenfalls zu nichts mehr zu gebrauchen. :-/ Das heißt, für die nächsten Tage bin ich von News und Mail weitgehend abgeschnitten, ganz abgesehen davon, daß mich so etwas gerne mental ziemlich blockiert. Dabei hatte ich damals, im Sommer letzten Jahres, eigentlich gehofft, die Probleme an der Netzwerkkarte isoliert und behoben zu haben. Dem war aber offenbar nicht so - entweder hat es jetzt auch die zweite NIC gerissen (eher unwahrscheinlich), oder das Kabel hat einen Schlag weg. Letzteres wäre am unangenehmsten, denn mit dem Verlegen von Netzwerkkabeln habe ich mich noch nie beschäftigt. *seufz*
Der Urlaub neigt sich endgültig seinem Ende zu, und - leider - ist die Todo-Liste, insbesondere hinsichtlich angedachter größerer Projekte, die man abends oder am Wochenende (zumindest bei meiner derzeitigen zeitlichen Belastung) nicht sinnvoll angehen kann, nicht merklich geschrumpft. Stattdessen habe ich mich (ungeplant) auf die Datensammlung zu Usenet-Hierarchien und danach dann auf den Umgang mit git konzentriert und am Ende eine ganze Reihe Dinge umgesetzt, die auf der ToDo-Liste eigentlich gar nicht vorkamen.
Nachdem Newsserver in den letzten Wochen eine so große Rolle gespielt haben ist es jetzt zum Abschluss nur recht und billig, wenn ich (nach mehrjähriger Pause) meine Seite zur Funktionsweise des INN endlich um die noch fehlenden Teile ergänze; umso mehr, als ich meine Webseiten mittlerweile in ein git-Repository eingecheckt habe und daher auch den Umgang damit üben kann, insbesondere, was fraktionierte Commits betrifft. Das ist eine sehr nette Sache: man nimmt eine Reihe unterschiedlicher Änderungen vor, die nichts miteinander zu tun haben - bspw. eine Ergänzung der INN-Beschreibung auf der einen Seite und Richtigstellungen/Tippfehlerkorrekturen, über die man zufällig stolpert, auf der anderen -, und kann diese Änderungen aber selektiv committen, bspw. zuerst nur die Ergänzungen, dann die Änderungen, dann die Rechtschreibfehler. Das macht die Commits übersichtlicher und ggf. auch leichter zu reverten, weil man nur logisch zusammengehörendes auch zusammen committet, ohne daß man beim Editieren darauf achten müßte.
Ich kann also hiermit verkünden, daß ich die Abschnitte über Steuernachrichten (control.ctl), Filter und Reader-Authentifizierung sowie eine recht umfangreiche Linksammlung ergänzt habe. Fehlen nur noch Erläuterungen zum Expire, aber das muß ich erst einmal selbst verstehen.
Update 2010-01-26: Inzwischen steht auch die Erläuterung zum Expire online. Die Seite ist damit - endlich! - fast fünf Jahre nach ihrer ersten Erstellung komplettiert. Ich hoffe, sie hilft dem einen oder anderen (vermißt wurden die fehlenden Teile allerdings offensichtlich nicht, wenn man nach dem erhaltenen Feedback über die Jahre geht …).
gitweb ist, wie vorgestern beschrieben, eine schöne Sache - aber nicht immer will man seine Repositories jedermann zugänglich machen. Schön wäre es doch, wenn man die Möglichkeit hätte, auch den Zugriff auf gitweb an eine Anmeldung zu koppeln und so nur für befugte Benutzer zu erlauben. Eine Möglichkeit dazu will ich nachstehend schildern, orientiert an einem Beitrag im Blog von Leho Kraav.
Weitere, vielleicht hilfreiche Anregungen dazu kann man ergoogeln, bspw.
u.a.
"gitweb mit Passwortschutz" vollständig lesen