Skip to content

Der Berg ist wieder am alten Platz

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.

Ausbleibende Rückmeldungen

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: Authentifizierung gegen MySQL-Datenbank

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

Munin: Limits und Notifications

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.

Heureka, das Netz ist da!

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.

news.szaf.org: neues Peering

Ü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!

Manchmal ist es wie verhext :-/

*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 mit Passwortschutz

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

Git-Repositories mit gitosis und gitweb (Debian Lenny)

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

news.szaf.org: Hierarchien ergänzt

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.

Manche sind lernfähig ...

… 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.

Massenpostings

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.

git

Nein, nicht "igitt"! Git. (iGit wäre vermutlich die Apple-Variante.)

Nachdem gestern Russ Albery auf meine Frage, in welchem Format denn Änderungen für das control.ctl (siehe dazu auch meinen vorigen Beitrag) am besten eingereicht werden sollten, mit

Anyone who’s really inspired can send me Git patches against the repository at git://git.eyrie.org/usenet/control.git, of course. :-)

geantwortet hatte, war mein Ehrgeiz geweckt; schließlich plane ich nach Abschluss meiner "Forschungen" über die deutschsprachigen Regionalhierarchien eine Zusammenstellung der dann vermutlich eher umfangreichen Änderungen einzureichen, und warum sollte ich das dann nicht direkt richtig professionell versuchen? Außerdem wollte ich mich seit Jahren immer schon mal wieder mit Versionsverwaltungssystemen beschäftigen, bin aber bisher nie über die eher theoretischen Konzepte - konkret von SVN - herausgekommen. Warum also nicht jetzt einen neuen Versuch wagen?

Daher habe ich etwas gegoogelt, mir git heruntergeladen (naja, genauer gesagt das passende Debian-Paket git-core installiert), das Repository ausgecheckt und festgestellt, daß das eigentlich eine recht einfache Sache zu sein scheint. Mal gucken, wie ich dann auch tatsächlich damit zurechtkomme. :-) Bevor es soweit ist, dürften ja auch noch einige Recherchen anstehen (und der Versuch, die Ergebnisse praktikabel zusammenzustellen und zu präsentieren; meine erste Idee, eine statische HTML-Seite zu bauen, hat sich jedenfalls eindeutig nicht bewährt).

Deutschsprachige regionale Usenet-Hierarchien

Wenn’s mal wieder etwas länger dauert …

Im Zusammenhang mit den geplanten Auffrischungsarbeiten an meinem Newsserver wollte ich auch mal die dort geführten Hierarchien abgleichen und vielleicht auch etwas erweitern; dabei stolperte ich dann ja, wie bereits geschildert, über die "List of Usenet public managed hierarchies", und nachdem dort Lücken bezüglich einiger deutschsprachiger Hierarchien auftauchten, brachte mich das auf den Gedanken, "mal eben" die notwendigen Ergänzungen vorzunehmen. Das sollte ja schnell gemacht sein - schließlich stammen die ganzen deutschsprachigen kleinen und regionalen Hierarchien aus den Anfangszeiten des deutschen Usenets, meistens aus einem universitären oder Vereins-Umfeld, und sind daher vermutlich gut gepflegt, mit kanonischen Listen der existierenden Newsgroups ("checkgroups"), dazugehörigen Webseiten usw. usf., wie ich das beispielsweise von der Karlsruher Regionalhierarchie "ka.*" kannte.

To make a long story short: mitnichten.

Ich sitze jetzt bereits seit letztem Jahr (und damit bald eine gute Woche) daran, mir einen Überblick zu verschaffen, und weiß inzwischen, daß einerseits leider nur noch die wenigsten "kleinen" Hierarchien überhaupt noch aktiv sind, und daß andererseits so Dinge wie Gruppenlisten, Einrichtungsregeln, digital signierte Steuernachrichten etc. pp. in der guten alten Zeit offenbar keine besondere Rolle gespielt haben. Oft genug sind bspw. die Webseiten der früher zum "Individual Network" gehörenden Vereine nicht mehr existent, oder das Angebot - und die Domain - wurde an einen Nachfolger abgegeben, der zwar noch im Internetzugangsgeschäft tätig ist, aber mit Usenet nichts mehr am Hut hat, oder sie wurde "vor kurzem" (bspw. 1998 oder so) aktualisiert. Dementsprechend ist das Web in den meisten Fällen eine sehr schlechte Informationsquelle, aber auch das Usenet und die Newsgroups der jeweiligen Hierarchien erweisen sich nicht direkt als Goldgruben, denn auch dort ist von geposteten Gruppenlisten oder ähnlichen administrativen Dokumenten wenig zu sehen, oder man liest nur davon, daß vor Jahren bereits der bisherige Verantwortliche sein Amt aufgegeben hat und ein Nachfolger nicht in Sicht ist. Der Gruppenbestand variiert teilweise von Server zu Server, und manche Hierarchien scheinen ein "Geisterdasein" zu führen, da die Gruppen zwar auf vielen Servern eingerichtet sind (oft wohl als Folge von Kristian Köhntopps "Regio"-Paket aus der Zeit, als er selbst einen Newsserver betrieb und vielen Neueinsteigern als erster Peer unter die Arme griff), aber die eigentlichen, ursprünglichen "Kernserver" gar nicht mehr existent sind (oder die Gruppen jedenfalls nicht mehr mit ihnen gepeert werden).

Inzwischen habe ich aber sozusagen Blut geleckt und finde es umso wichtiger, für diejenigen, die daran interessiert sind, diese regionale Vielfalt - und sei es nur als wehmütige Erinnerung an die Anfangszeiten des deutschen Netzes - zu erhalten und die wenigen nicht aktiven Hierarchien zu verteilen und zu fördern, die notwendigen Informationen zur Verfügung zu stellen. Ich werde also weiter sammeln und auch aktiv nachforschen und dann das Ergebnis meiner Nachforschungen in geeigneter Weise zusammenstellen. Stay tuned!