Soeben habe ich eine neue Version 0.8.1 von yapfaq released, die im Vergleich zur bisherigen Version 0.7 nur noch vergleichsweise kleine Änderungen aufweist:
PGP-/GPG-Support entfernt
Die Unterstützung für das Signieren von Postings ist ersatzlos entfallen. Es bestehen ausreichende Möglichkeiten, dies extern zu lösen, bspw. über tinews.pl; daher gibt es keinen Anlaß, den dort enthaltenen Code in yapfaq zu duplizieren. Seit der letzten Version ist der Aufruf - bspw. - von tinews.pl direkt aus yapfaq heraus möglich.
Konfiguration
Die in der Konfigurationsdatei yapfaq.cfg mögliche Definition des Schemas für die Erzeugung der Message-ID kann jetzt auch einen Platzhalter für einen Unix-Timestamp enthalten.
Außerdem kann die in der letzten Version hinzugefügte Möglichkeit, zum Posten ein externes Programm zu verwenden, nunmehr auch in der Konfigurationsdatei .yapfaqrc definiert werden, nicht nur über den Kommandozeilenparameter "-s".
Kleinere Änderungen und Fehlerbehebung
In der Konfigurationsdatei yapfaq.cfg wurden optionale Einstellungen als solche gekennzeichnet und auskommentiert, außerdem die Optionen mit einheitlichen Erläuterungen als Kommentar versehen.
Die Dokumentation wurde um bisher fehlende Optionen und die Erläuterung der voranstehenden ergänzt. Außerdem enthält sie jetzt Links zum Git-Repository und zum Bugtracker.
Die aktuelle Version steht jeweils auf meiner Downloadseite
zur Verfügung.
Update: Nachdem Version 0.8 nicht lauffähig war, ist dieser Fehler in Version 0.8.1 behoben.
Es scheint wie verhext: Nachdem es gestern die DENIC glücklich geschafft hat, den Großteil des deutsch(sprachig)en Netzes offline zu schalten, hat sich heute einer der größten deutschen Provider bemüht, zu beweisen, daß er das auch hinbekommt. 1&1 (United Internet), die nicht nur einer der größten Webspace- und Mietserveranbieter in Deutschland sein dürfte, sondern auch eine beträchtliche Rolle als Anbieter von Internetzugängen (DSL) und Internettelefonie (VoIP, SIP) spielt und zudem mit GMX und web.de die beiden vermutlich größten Freemaildienste betreibt, hatte Schwierigkeiten mit einem zentralen Router, mit der Folge, daß alle diese Dienste aus bestimmten Netzsegmenten nicht zugänglich waren, unter anderem von Strato aus und aus den Einwahlnetzen von Alice und - teilweise - der Deutschen Telekom AG.
Überraschend finde ich, daß man das Problem wohl erst mit knapp einstündiger Verspätung bemerkt - oder erst dann das Social-Media-Team aktiviert - hat. Kurz danach war der Spuk dann auch wieder vorbei.
Mit dem gestrigen Nameserver-Ausfall hatte das Problem aber - ersichtlich - nichts zu tun.
Am gestrigen Tage war ein guter Teil des deutschsprachigen Internets nicht erreichbar, weil die Nameserver der DENIC fehlerhaft arbeiteten. Aber was genau war passiert?
Grundlagen des DNS
Zunächst eine - verkürzte und oberflächliche - Einführung in die Grundlagen des Domain Name Systems (DNS).
Allen mit dem Internet verbundenen Rechnern - seien es Web- oder Mailserver oder der heimische Rechner zuhause, mit dem man "online geht" - ist eine numerische IP-Adresse zugewiesen, die auf technischer Ebene genutzt wird, um mit einem dieser Rechner zu kommunizieren. Weil es aber u.a. ausgesprochen unpraktisch ist, sich mehrere Milliarden Nummern zu merken, benutzt man in der Regel nicht die IP-Adresse eines Rechners, sondern einen Namen; dieser Name muß aber von der verwendeten Software wieder in die zugehörige IP-Adresse umgesetzt werden. Zu diesem Zweck kann die zu einem Namen gehörende Adresse bei einem DNS-Server abgefragt werden.
Um die Last der ungezählten Abfragen zu verteilen und die Vielzahl der bestehenden Domains und Rechnernamen handhabbar zu machen, aber auch, um die Verantwortung für Domains delegieren zu können, ist das DNS hierarchisch organisiert. Jeder DNS-Server muß (nur) die festen IP-Adressen der sog. Root-Nameserver kennen; alle weiteren notwendigen Auskünfte erhält er durch rekursive Anfragen bei den jeweils zuständigen Nameservern. Nehmen wir an, es wird die IP-Adresse für den Rechner www.th-h.de gesucht. Ein DNS-Server würde zunächst bei einem der Root-Nameserver nachfragen, wer denn für die Top-Level-Domain ".de" zuständig ist; der Root-Nameserver würde ihn dann an einen der Nameserver der DENIC verweisen. Unser DNS-Server fragt jetzt einen dieser Nameserver, wer denn für "th-h.de" zuständig sein mag, und erhält dann als Antwort die Nameserver meines Providers. Diese wiederum fragt er dann nach "www.th-h.de" und erhält schließlich die korrekte IP-Adresse.
Soweit der grundsätzliche Ablauf. Hinzu kommt, daß Rechner von Endbenutzern üblicherweise diese rekursiven Abfragen nicht selbst vornehmen; ihnen sind vielmehr ein oder mehrere DNS-Server des jeweiligen Providers zugewiesen, denen sie ihre Fragen stellen. Diese DNS-Server übernehmen dann einerseits den Aufwand der rekursiven Abfragen und speichern andererseits die Antworten für eine gewisse Zeit zwischen, um bei neuen Anfragen nach genau diesem Hostnamen ohne erneute Abfrage sofort antworten zu können.
"Das .de-Internet steht still, auch wenn DENIC das nicht will" vollständig lesen