Gestern erhielt ich per E-Mail eine Antwort auf meine nach dem scheinbaren Serverausfall vor gut einer Woche gestellte Anfrage an den Support meines Providers (gefolgt von einer Entwarnung meinerseits, daß das System wieder zur Verfügung steht), die mich mit Hinweisen beglückte, wie ich einen möglichen Hardwareschaden eingrenzen könne. kopfkratz Offenbar hat man da immer noch nicht gemerkt, daß es sich um keinen Ausfall, sondern einen Serverumzug handelte. Das schockiert mich jetzt doch etwas.
Nachdem ich inzwischen einmal systematisch die vorgenommenen Änderungen geprüft habe, bin ich im übrigen einigermaßen versöhnt (von der fehlenden Ankündigung, die wohl durch interne Kommunikationsprobleme beim Anbieter bedingt ist, einmal abgesehen). Alt scheinen bei der Maschine nur noch die Platten zu sein; der Server hat einen schnelleren Prozessor und doppelt so viel RAM bekommen, außerdem ist eine serielle Konsole angeschlossen (vermutlich hat man also nur die Platten umgeklemmt). Offenbar standardmäßig hat man dann einen neuen Kernel eingespielt und damit verbundene Konfigurationsänderungen (von /dev/hdX zu /dev/sdX und bzgl. der seriellen Konsole) vorgenommen, um sicherzugehen, daß die neue Hardware angesteuert werden kann (ursprünglich war die Maschine mit einem Debian Sarge oder Etch initialisiert worden); inzwischen habe ich den Kernel wieder durch den Debian-Kernel ersetzt, und alles läuft.
Dennoch: ich hätte lieber eine Vorwarnung vorher und/oder eine Erläuterung der Vorgehensweise hinterher gehabt, und das habe ich auch - hoffentlich hinreichend deutlich - per Feedbackformular kundgetan.
Für den Fall, daß der eine oder die andere es - genau wie ich - bisher nicht mitbekommen hat: die Registrierungsstelle für die Top-Level-Domain .de (DENIC) fordert seit Anfang Februar für alle Domainübertragungen verbindlich das bereits Ende 2008 als Alternative eingeführte AuthInfo-Verfahren; die frühere Lösung wird nicht mehr akzeptiert.
Traditionell liefen Domainübertragungen an einen anderen Provider in der Weise ab, daß der neue Provider die DENIC beauftragte, die Domain an ihn zu übertragen, DENIC dann beim alten Provider anfragte, ob das in Ordnung ist, und dieser dann zustimmte (ACK) oder ablehnte (NACK); im Falle einer Ablehnung konnte er noch eine verspätete Zustimmung (late ACK) nachschieben. Der organisatorisch-rechtliche Hintergrund dieser technischen Lösung war dergestalt, daß der neue Provider natürlich nur bei Vorliegen eines Auftrags tätig werden durfte und der alte Provider vor einer Zustimmung zu prüfen hatte, ob ihm eine schriftliche Zustimmung seines Kunden vorlag. Dieser Prozeß ging gerne schief, insbesondere dann, wenn einer der beteiligten Reseller zum einen selbst kein DENIC-Mitglied war und zum anderen die entsprechenden Prozesse nicht recht im Griff hatte.
Das nunmehr noch alleinig mögliche AuthInfo-Verfahren basiert darauf, daß der alte Provider für jede Domain ein verschlüsseltes Paßwort bei der DENIC hinterlegt und auf Wunsch an seinen Kunden mitteilt. Dieses Paßwort muß der neue Provider zusammen mit der Übernahmeanforderung für die Domain an die DENIC senden; stimmt das Paßwort, erfolgt die Übertragung, stimmt es nicht, erfolgt sie nicht. Eine Domainübernahme kann also nur noch erfolgen, wenn der Kunde bei seinem bisherigen Anbieter ein Paßwort bei der DENIC hinterlegen und sich zusenden läßt und dieses dann seinem neuen Provider mitteilt. Das sollte zum einen einfacher, zum anderen sicherer sein (aber man muß wissen, wie es geht und daß es nur so noch geht).
Daniel war in den letzten Tagen so nett, meine Rechner in sein Nagios mitaufzunehmen, so daß die dort angebotenen Dienste in der Überwachung mit drin sind und ich bei Ausfällen eine Benachrichtigung per E-Mail (und dann teilweise auch per SMS) erhalte. Gestern abend war ich dann auch gerade zu Bett gegangen, als nacheinander mehrere SMS eintrudelten, die einen Ausfall meines privaten Servers meldeten. Also bin ich erschrocken noch einmal aufgestanden und habe mir die Sache angesehen: die Maschine war tatsächlich nicht erreichbar, und zu meiner Überraschung stand auch das über das Webinterface des Providers steuerbare "Rettungssystem" - eine Möglichkeit, in ein Minimalsystem zu booten und sich die Maschine mal näher anzusehen - nicht zur Verfügung. Nach gut einer Stunde Bastelei habe ich eine eilige E-Mail an die Hotline geschrieben und wollte gerade wieder zu Bett gehen, als die nächsten SMS eintrudelten, die meldeten, das System sei wieder verfügbar, was allerdings nur teilweise zutraf.
Inzwischen scheint alles wieder gut zu sein, und ein kurzer Blick auf das System - nach einer ebenso kurzen Nacht - hat den Verdacht bestätigt, den ich heute nacht dann schon hatte: es handelte sich um keinen Ausfall, sondern eine geplante Wartung bzw. einen Umzug der Maschine! Den hatte man mir im vergangenen November (!) bereits mit einigen Wochen Vorlauf angekündigt, die Wartung wurde aber nie durchgeführt, und Rückfragen beim Support ergaben auch nur, daß die Maschine eigentlich hätte umgezogen werden sollen, man sich das auch nicht erklären könne, mir aber Bescheid geben würde, wenn man das nachhole. Offenbar hat man das aber vergessen (oder verwechselt meinen Server mit dem eines anderen Kunden …), so daß es dann zu dieser überraschenden Downtime kam.
Im übrigen ist es bei der Downtime nicht geblieben; man hat sich offenbar zu der Maschine (eigentlich ein Miet- oder auch sog. "Rootserver", der vom Kunden, also mir, selbst gepflegt wird) Zugang verschafft und etliche Konfigurationsänderungen vorgenommen (u.a. auch eine Änderung, die alle 5 Minuten stapelweise Fehlermeldungen ins Logfile schreibt) und einen anderen Kernel installiert. Der Hintergrund scheint zu sein, daß die Maschine nicht (nur) umgezogen wurde, sondern nunmehr auch eine im ursprünglichen Vertrag nicht vorgesehene serielle Konsole erhalten hat. Grundsätzlich ist so etwas ja nett, aber daß man einfach an Kernel und Konfiguration herumschraubt (ohne wissen zu können, welche Änderungen ich vielleicht in Kernel und Userland vorgenommen habe und ohne mich über die seitens des Supports vorgenommenen Änderungen zu informieren), finde ich nicht so wirklich prickelnd. 
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! 
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!
*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*
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
Wie ich bereits schrieb, habe ich mich in den letzten Tagen etwas näher mit dem Versionskontrollsystem (VCS, oder auch SCM für "Source-Code-Management") git beschäftigt. Das macht natürlich nur bedingt Spaß - und Sinn -, wenn die Repositories nur auf dem heimischen Rechner liegen; um wirklich universal auf sie zugreifen zu können und auch die Zusammenarbeit mit anderen zu ermöglichen, sollten die Repositories irgendwo im Netz stehen, und eine nette Weboberfläche, die auch einen Zugriff über den Browser - ohne weitere Software - ermöglicht, um den aktuellen Stand der Bearbeitung zu sehen, Commits zu prüfen und ggf. einen Snapshot zu ziehen, wäre auch nicht schlecht.
Um mir die Anlage von Repositories und das Zusammenspiel mit den anderen Komponenten zu erleichtern und auch für erweiterte Anforderungen wie verschiedene Zugriffsrechte für die jeweiligen Repositories gerüstet zu sein, habe ich mich für die Verwaltung der Repositories für gitosis entschieden; als Weboberfläche will ich gitweb nutzen, und für den Zugriff via git dann git-daemon. Installiert habe ich dazu die jeweiligen Pakete aus Debian Lenny bzw. den Debian-Backports.
"Git-Repositories mit gitosis und gitweb (Debian Lenny)" vollständig lesen
Inzwischen bin ich - zwei bis drei Wochen später - endlich wieder da angekommen, wo ich eigentlich letztes Jahr zwischen den Feiertagen angefangen hatte: bei der Konfiguration meines Newsservers bzw. dem dort geführten Gruppenbestand, dessen Konsolidierung mich dann ja auf längere Ausflüge in die Welt der deutschsprachigen Regionalhierarchien geführt hat.
Nunmehr sollen die Früchte dieser Arbeit geerntet werden, insofern habe ich nun nicht nur die Gruppenlisten der von mir geführten Hierarchien (soweit erforderlich) berichtigt und einige tote Gruppen entfernt, sondern mich auch entschlossen, welche weiteren Hierarchien ich führen möchte, namentlich Länder- bzw. sprachbezogene Hierarchien und "special interest"-Hierarchien wie bspw. linux.*. Nach entsprechenden Vorbereitungen habe ich diese Wünsche inzwischen an meine Peers kommuniziert, und die entsprechenden Feeds sind jetzt bereits umgestellt. So steht dem erweiterten Gruppenangebot auf news.szaf.org nichts mehr im Wege. Einen all.all-Feed möchte ich aber dennoch nicht haben; wozu bei meiner sehr kleinen Nutzerbasis ungezählte Hierarchien führen und Postings durchschieben, die hier kein Mensch brauchen kann?
Gleichermaßen bin ich am Sammeln von Peers nicht interessiert; das erhöht letztlich nur den Aufwand, ohne die Newsversorgung zwingend zu verbessern; je nach Abuse-Management kann es sie sogar verschlechtern. Und mein Ziel beim Betrieb eines Newsservers ist nicht in erster Linie ein Platz unter den ersten auf TOP1000.org. 
Dennoch freue ich mich, mit Telefonica einen weiteren großen Peeringpartner dazugewonnen zu haben.
… andere sind es weniger.
Ich hatte bereits im vergangenen Jahr berichtet, wie wenig zuverlässig E-Mail als Medium mittlerweile oft ist, dann aber positiv überrascht zur Kenntnis nehmen dürfen, wie vergleichsweise schnell auch ein großer Anbieter wie Ebay auf entsprechende Hinweise reagiert und die (gar nicht im Ernst erwarteten) notwendigen Änderungen an seinen Mailsystemen vornimmt. Nunmehr kann ich berichten, daß andere Anbieter zwar dasselbe Problem haben, aber die Reaktion leider nicht immer gleich kompetent ist. Vodafone versendet E-Mails nämlich gleichfalls mit nicht existenten Absendern; mein entsprechender Hinweis wurde schnell, aber leider nur so beantwortet:
Guten Tag Herr Hochstein,
Ihr Hinweis hilft uns, Fehler zu erkennen und uns zu verbessern. Vielen Dank dafür. Leider können wir in diesem Fall keinen weiteren Support
leisten. Eine Änderung des Absenders bei automatischen
Bestätigungen ist nicht angedacht.
Sicherlich werden Ihre User keine Problemne haben, wenn sie Ihnen Mails über ihr Vodafone-MobileMail Postfach versenden.
Den ersten Absatz verstehe ich, auch wenn er mir inhaltlich nicht gefällt, aber, ganz ehrlich: was der zweite Absatz mir sagen will, ist mir schleierhaft. *kopfkratz* Am Problem der mit ungültigem Absender versandten automatisierten Bestätigungen geht diese Antwort doch völlig vorbei.
Nein, ich bin nicht unter die Spammer gegangen, aber ich habe mittlerweile den ersten Schub Postings mit der Bitte um Prüfung und ggf. Ergänzung der bei DE-Regio zusammengestellten Daten über die jeweiligen Usenet-Hierarchien versandt, die letztlich alle ähnlich aussehen; ich hoffe auf möglichst viele Rückmeldungen. Einen entsprechenden Hinweis habe ich auch nach de.comm.provider.usenet gepostet. Vielleicht führt ja alleine schon das Erfassen und Zusammenstellen des derzeitigen Status da und dort zu einer gewissen Belebung? Sicherlich werde ich auch die eine oder andere Newsgroup zusätzlich abonnieren. Mal schauen.
