Bernds Blog

Heute stieß ich auf eine Merkwürdigkeit: Die Partition /var/log war zu über der Hälfte voll, mit du -hsc /var/log/* waren aber nur ein paar MB belegt. Die Ursache war uns klar, das Problem hatten wir schonmal: Ein Programm hat eine Datei noch geöffnet, die aber bereits gelöscht ist. So wird Speicherplatz belegt, man findet aber keine Datei dazu.

Als Lösung war mit bisher nur bekannt, das Programm mittels lsof /var/log/| grep deleted zu identifizieren und neu zu starten, damit es die Datei-Handles aufgibt und die gelöschten Dateien wirklich gelöscht sind. In diesem Fall war es aber der MySQL-Server und wir hatten grade einen leistungsintensiven Import am Laufen, so dass mir das Risiko zu hoch war, den MySQL-Server neu zu starten bzw. ein SIGHUP zu senden. Gleichzeitig war aber die Gefahr groß, dass die Platte vollläuft, bevor der Import abgeschlossen ist.

Als praktisch hat sich dann das Werkzeug truncate erwiesen. Das kürzt eine offene Datei auf eine feste Größe und schiebt den Dateizeiger ebenfalls auf diese Position. Damit kann man eine Datei leeren ohne dass der andere Prozess sein File-Handle schließen muss: truncate -s0 /proc/19580/fd/11

Gestern haben wir bei schokokeks.org die MySQL-Server auf die aktuelle Version 5.5 aktualisiert. Der Regelbetrieb war schnell wieder hergestellt, doch heute früh entdeckte ich eine unscheinbare Fehlermeldung im Backup:

ERROR 1457 (HY000): Routine [...] konnte nicht geladen werden. Die Tabelle mysql.proc fehlt, ist beschädigt, oder enthält fehlerhaften Daten (interner Code: -6)

Eine Stored-Procedure konnte also nicht verarbeitet werden. Die genannte Tabelle mysql.proc existierte aber und sah plausibel aus. In der Tabelle war auch die gesuchte Routine enthalten.

Die Lösung war, dass ein recht komplexes SQL-Statement in dieser Routine in den Augen von MySQL 5.5 ungültig war. Und zwar befanden sich "SQL_NO_CACHE"-Markierungen bei allen SELECT-Statements in diesem Query. Diese Markierungen sollen verhindern dass das Ergebnis dieses SELECT imm Query-Cache abgespeichert wird. Ich hatte die nie selbst definiert, MySQL hat die immer automatisch hinzugefügt.

Nun sind diese Markierungen bei UNION-Queries nur noch beim ersten SELECT erlaubt und bei Subqueries gar nicht mehr. Nachdem ich die Routine mit dieser Änderung neu angelegt hatte, funktionierte der Zugriff darauf wieder.

Schade, dass MySQL hier über eine Sache stolpert, die der Parser einer alten Version selbstständig hinzugefügt hat. Und dass dann nicht wenigstens die Fehlermeldung aussagekräftiger ist ("contains invalid SQL" oder sowas).

Die Tage kam bei schokokeks.org die Notwendigkeit nach einem zusätzlichen Server auf, der nichts anderes machen sollte als Backups von einigen bestehenden Maschinen entgegen zu nehmen. Der Server soll als virtuelles Gastsystem betrieben werden, da die erwartete Last minimal ausfällt. Da wir stets versuchen, IPv4-Adressen nicht zu vergeuden, wollte ich diesen Server als IPv6-only-System in Betrieb stellen.

Das hat grundsätzlich gut geklappt, es gab aber einige Stellen die (für mich unerwarteter Weise) Probleme bereitet haben.

1. OpenVPN kann nicht über IPv6. Mit der Version 2.3 soll das angeblich anders werden, die gibt es aber bisher noch nicht. Meine Lösung war, dass ich eine private IPv4-Adresse eingerichtet habe, die der physikalische Server auf einen anderen Server routet, der ebenfalls eine passende private IPv4-Adresse hat. Dadurch kann OpenVPN über diese IPv4-Verbindung kommunizieren.


2. Die normalen Gentoo-Mirror-Dienste beachten kein IPv6 und liefern im Round-Robin einfach irgendwas zurück, was ich dann nicht aufrufen kann. :( Die Lösung war, gezielt SYNC-Server und Distfiles-Mirror einzutragen die IPv6-Verbindung liefern. Die Listen gibt es hier (sync-Mirrors) und hier (Distfiles-Server). Jeweils die mit Sternchen sind IPv6-fähig.


3. Wir betreiben normalerweise lokale DNS-Resolver auf jedem Server. Für diesen speziellen Zweck ist das okay, aber man kann halt nur Namen auflösen, die auch über IPv6-fähige DNS-Server angeboten werden. IPv6-Paradebeispiel Heise online geht z.B. nicht, da deren DNS-Server keine IPv6-Adressen haben. Um etwas mehr Möglichkeiten zu haben, kann der Google-Public-DNS benutzt werden: 2001:4860:4860::8888.

Letztlich ist OpenVPN der einzige Grund, dass auf der Maschine überhaupt eine IPv4-Adresse eingerichtet ist. Und das soll sich ja angeblich mit dem nächsten Release, für das bereits ein RC angeboten wird, ändern. Ich bin jedenfalls gespannt.

Unsere normalen Serverdienste betreiben wir schon seit Jahren im Dualstack. Vor einigen Wochen wurde der Linux-Default-Resolver auch so geändert, dass er IPv6 bevorzugt, da hatten wir ein Localhost-Problem (Zugriffe auf localhost kamen dann von ::1 und nicht mehr von 127.0.0.1, da mussten einige Konfigurationen angepasst werden). Aber ansonsten bereitet uns der Dualstack-Betrieb keine Schwierigkeiten.

Nach meinen ersten Gehversuchen mit eigenen OSM-Karte auf meinem neuen Garmin-Navi wollte ich unbedingt auch Höhenlinien verfügbar haben. Die Höhenlinien werden üblicherweise aus den SRTM-Daten der NASA gewonnen. Es gibt auch Software, die diese Daten nach OSM konvertiert, aber das ist leider eine Windows-Software, die bei mir folglich nicht läuft.

Zudem ist es etwas unpraktisch, wenn sich jeder die Rohdaten runterladen muss un die dann selbst konvertiert. Ich habe daher auf der OSM-Mailingliste nach jemandem gefragt, der einen entsprechenden Bereich konvertiert und das Ergebnis dann bei dem besten Provider der Welt auf den Mirror-Server gelegt:
http://mirror.schokokeks.org/OpenStreetMap/SRTM/

Dort befinden sich (im entsprechenden Unterverzeichnis) die Daten in 10-Höhenmeter-Auflösung oder in 25-Höhenmeter-Auflösung.

Dank und Ehre gebührt Stefan Dettenhofer, der die Dateien erzeugt hat und im Original anbietet, wenn auch nur über eine Kabel-Deutschland-Flatrate.
Bei ihm gibt es aber eine schöne Übersicht über die verfügbaren Kacheln.

UPDATE (2011-01-09): Ich meine mich zu erinnern dass ich neulich gelesen habe dass es jetzt mehrere Anbieter von SRTM für OSM gibt. Ich habe die Dateien vom oben genannten Mirror entfernt.

Heute fiel mir eine sehr unschöne Sache bei .org-Domains auf. Registriert man eine solche Domain und setzt Nameserver-Einträge, die ebenfalls unter .org laufen, dann ruft die .org-Registry die IP-Adressen dieser Nameserver ab und speichert die. Diese werden dann zusammen mit der NS-Antwort als "Additional Section" an den anfragenden Client übertragen.

Das Ganze ist eine eigentlich nette Service-Leistung und klingt auf den ersten Blick plausibel.

Das Problem beginnt allerdings dann, wenn sich die IP-Adressen der Nameserver ändern. Bei uns wurde einer der drei Name-Server vor über einem halben Jahr entfernt und ein zweiter letzte Woche. Die .org-nameserver liefern aber noch immer unbeeindruckt die alten Adressen aus. Das führt dazu, dass unsere .org-Domains ohne unser Wissen jetzt nicht mehr nur schlecht sondern sogar sehr schlecht erreichbar waren.
Durch eine Änderung der Nameserver kann man erreichen, dass diese IP-Adressen neu angefragt werden. Wie man diesen Vorgang für die einmal irgendwann eingetragenen DNS-Server-Namen macht, ist mir schleierhaft.

Ich hatte mir heute den Tag über Gedanken über ein mögliches DoS-Angriffs-Szenario gemacht, aber kein wirkliches gefunden. Ich hab aber immer noch das Gefühl, dass man das DoS'en kann.

Die Webhostlist (ja, ohne Link. Jeder kann .de dahinter setzen, wenn er will) ist ein Web-Portal, auf dem Angebote von Providern und Gesuche von zukünftigen Kunden zusammen finden sollen. Ein ganz normaler Preisvergleich bzw. Kleinanzeigenmarkt.

Dafür gibt es zwei Kanäle: Das Angebotlisting, in dem jeder Provider seine Angebote einstellt und Kunden nach diversen Kriterien suchen können auf der einen Seite und das Forum auf der anderen Seite. Im Forum stellt ein Kunde seine Anforderungen ein und Provider können mit einem Angebot antworten. nicht selten führt das zu skurrilen Dingen wie "Suche Webspace mit Feature foobar." mit der Antwort "biete das zwar nicht an, aber vielleicht ja was anderes was dich interessiert".

Als wichtige Bemerkung sei noch eingeführt, dass Provider bei Webhostlist unterschiedlichen Status haben können. Ungeprüft ist man immer als erstes. Wenn man dann viel Geld zahlt (ich weiß viel ist relativ), wird man Geprüfter Provider. Dazu muss man eigentlich nichts weiter machen als Geld zu zahlen. Zahlt man dann noch mehr Geld, wird man sogar Premium-Provider. Bisher war der Mehrwert darauf begrenzt, dass neben den Angeboten ein hübsches goldenes Emblem gezeigt wurde, das dem Kunden versichert, dass der Provider auch wirklich Geld an Webhostlist gezahlt hat.

Die zahlenden Provider haben sich (mittlerweile erfolgreich) beschwert, dass das Geldausgeben nur für ein hübsches Bildchen vielleicht nicht ganz gerechtfertigt ist.

Daraufhin wurde folgendes Umgestellt:
Wer ein Gesuch in das Forum einstellt, muss Daten-Striptease betreiben. Webhostlist fordert eine vollständige Adressangabe, anfangs sogar zwingend mit Telefonnummer. Gleichzeitig kann der Suchende auswählen, welcher Provider-Typus seine Daten und sein Gesuch sehen kann. Standardeinstellung ist (*Tusch*) zahlender Geprüfter Provider.
Die Webhostlist begründet das unter dem Applaus einiger zahlender Provider damit, dass man ja auf seriöse Geschäftsbeziehungen setze und daher die Angabe einer Identität verlangt werden könne. Zudem möchten Anbieter auch wissen, wem sie eventuell kein Angebot mehr machen möchten, wenn die den Namen schon kennen. Nun ja.
Ein Foren-Teilnehmer hat das treffend umschrieben mit der Pflicht, bei jedem Geschäft einer Einkaufspassage immer vor jedem Betrachten des Schaufensters eine Visitenkarte abgeben zu müssen.

Klar, so schlägt man zwei Fliegen mit einer Klappe: Es wird für alle Datenkraken-Provider sehr interessant, viel oder sehr viel Geld an Webhostlist zu zahlen, denn dafür bekommt man jetzt zuverlässig neue Adressen für seine Verbraucherinformationen. Webhostlist bekommt also mehr zahlende Kunden. Auf der anderen Seite werden die Adressen ja gespeichert und somit reiht sich Webhostlist nahtlos in die Liste der in den letzten Jahren stark an Wert gestiegenen Unternehmen mit vielen "Benutzerprofilen", in welcher Form auch immer.

Die vielen Forums-Beiträge, die diese Regelung als kompletten Unsinn bezeichnet haben, wurden konsequent ignoriert, was natürlich auch irgendwie aussagt, dass diese Regelung wohl nicht mit guten Argumenten belegt werden kann.

Die komplett sinnbefreite Kompromisslösung, die jetzt angestrebt wird (oder schon implementiert ist), sieht vor, dass der Anbieter erst nach Abgabe eines Angebots die Kontaktdaten des Interessenden sieht. Wie man das überhaupt irgendwie begründen kann, ist mir noch nicht eingefallen.



Als weitere Veränderung (da weiß ich aber nicht seit wann) gibt es bei der Suche nach Webhosting-Tarifen jetzt auch keine Möglichkeit, die nicht-zahlenden Provider überhaupt anzuzeigen. Erst nach Erhalt der Ergebnis-Liste kann man die Suchergebnisse auf nicht-zahlende Provider ausdehnen. Und diese Einstellung springt meiner Erfahrung nach manchmal etwas willkürlich wieder auf die Standardeinstellung zurück.

Was ich damit sagen will: Jeder, der über Webhostlist einen Provider sucht, sollte sich darüber im Klaren sein, dass er immer erstmal nur Angebote von Firmen bekommt, die der Webhostlist Geld bezahlt haben. Auch wenn die Webhostlist sich nach außen als kostenlos für beide Seiten kommuniziert. Und dass im Forum nun die Angabe falscher Daten zur Regel wird, ist (denke ich) auch klar.

Nachdem ich jetzt doch von einigen Leuten weiß, die meinen greylisting-Filter bei sich einsetzen, kann ich das auch grade mal hier announcen... ;-)

Es gibt davon eine neue Version. Es gibt einen ziemlichen Bruch, es wird jetzt MySQL anstelle von SQLite als Backend benutzt. Das liegt daran, dass ich vor habe, eine selektive Whitelist (»Mails an diese Adresse bitte in den nächsten 10 Minuten nicht greylisten«) für unsere Kunden zu ermöglichen. Dazu muss es eine gemeinsame Datenbank für das webinterface und das greylisting geben, was hiermit geschehen ist.

Die offizielle Release-Seite enthält auch ein detaillierteres Change-Log.

Peinlicherweise habe ich erst ein paar Minuten nach dem Release festgestellt, dass die neue Version von courier, für die ich grade ein ebuild erstellt habe, eine kleine API-Änderung hat. ich habe mit einem Bugfix-Release der Version 2.0.1 darauf reagiert.

Wer einen Account auf einem Server hat, dem kommt ab und zu das Verlangen, sich in der Fremde einfach mal dort einzuloggen um eine vertraute Umgebung vorzufinden. Seit es um den perfekt konfigurierten »mutt« zu benutzen, schnell im »screen« dem laufenden »irssi« zu zu schauen oder einfach um eine vorher dort hinterlegte Datei zu lesen.

Praktisch ist es natürlich gefährlich, sich von einem nicht vertrauenswürdigen Rechner auf einem Server einzuloggen. Bei der Eingabe des Passwortes auf einem fremden Rechner besteht immer die Gefahr, dass ein böswilliger Admin, ein Schäuble oder die Werbeindustrie einfach alle Tastendrücke aufzeichnet und damit sehr einfach das Passwort für den sicher geglaubten Account erhält.

Um diesem Problem generisch, also für alle fremden Rechner brauchbar zu begegnen, gibt es Einmalpasswörter. Mit diesem Verfahren (das in etwa den TANs vom PIN/TAN-Onlinebanking nahe kommt), gibt es eine Liste von Passwörtern, die jeweils nur einmal gültig sind. Sind die verbraucht, sind sie ungültig.

Unter unixoiden Systemen hat sich dafür das S/Key-System einen Namen gemacht. Es läuft auf den meisten Plattformen und lässt sich sauber z.B. mit PAM einbinden. Das Verfahren ist sehr transparent und die Einmalpasswörter lassen sich mit dem challenge, das vom Server beim Login genannt wird auch extern berechnen. So braucht man keine Papier-Liste mitnehmen sondern kann z.B. mit einem Java-fähigen Handy die Einmalpasswörter (auf einem vertrauenwürdigen Gerät) errechnen lassen.

Sehr edel das ganze, daher haben wir das auch gleich auf schokokeks.org eingebaut. Als Anleitung verweise ich hier mal auf unseren Wiki-Artikel zu Einmalpasswörtern.

Sei noch erwähnt, dass es mehrere Möglichkeiten gibt, S/Key unter SSH zu benutzen. SSH bringt eine solche Funktionalität selbst mit (Gentoo-USE-Flag skey) und es gibt alternativ dazu das PAM-Modul pam_skey.

Wir haben uns für letztere Variante entschieden, da die SSH-Lösung für den Benutzer weniger transparent ist. Bei SSH wird erst nach dem normalen Passwort gefragt und wenn dies leer oder falsch ist, dann wird nach dem S/Key-Einmalpasswort gefragt.

Bei pam_skey dagegen wird, sofern der Benutzer skey für sich aktiviert hat, gleich nach »S/Key response or system password« gefragt. Ist skey für den Benutzer nicht aktiviert, wird das PAM-Modul einfach übergangen und das normale Passwort abgefragt.

Mit unserer Firma bin auch ich direkt von der Vorratsdatenspeicheurng betroffen. Bei allem Aktivismus und berechtigter Kritik an der ganzen Sache, darf man aber meines Erachtens trotzdem die geltenden Gesetze nicht einfach ignorieren sondern jetzt, da das alles gilt, muss man es auch erst einmal beachten. Natürlich in der Hoffnung, dass das Bundesverfassungsgericht das alles wieder kippt.

Ich habe heute ungelogen einen Tag damit verbracht, das "Gesetz zur Neuregelung der Telekommunikationsüberwachung und anderer verdeckter Ermittlungsmaßnahmen sowie zur Umsetzung der Richtlinie 2006/24/EG vom 21. Dezember 2007" zu finden, zu lesen, die Bezüge zu recherchieren, herauszufunden was uns als E-Mail-Provider betrifft und das alles zu verstehen.

Ich möchte gerne die stellen aus den Gesetzen zitieren, die ich persönlich als einschlägig betrachte. ausdrücklich möchte ich darum bitten, dass jeder, der irgend etwas anders verstanden hat, also denkt, ich hätte etwas falsch aufgefasst oder übersehen, mir das bitte mitteilt. Zudem ist hoffentlich klar, dass von mir zu diesem Thema gegebene Kommentare jeglicher juristischer Sachkunde entbehren und die Gesetzes-Auszüge sich nicht eignen um sich darauf zu verlassen. das ist hier keine Rechtsberatung und so, klar.

ich verlinke an einigen Stellen zu www.gesetze-im-internet.de. Dort ist jetzt momentan noch die alte, nicht mehr gültige Version der Gesetze zu begutachten, das eignet sich aber gut um das Fließtext-Diff in oben verlinkter PDF-Datei darauf anzuwenden.

*pust* [...] *hust*, *röchel*
Wow, ist das eingestaubt hier. Sorry, war anderweitig beschäftigt.

Fabians Blog-Eintrag von neulich möchte ich glatt mal aufgreifen.

Wenn mein Jabber-Status (der auch meistens stimmt!) auf Away bzw. N/A steht, dann bin ich nicht da. Manchmal setze ich den den Status auch von Hand auf DnD oder N/A. Auch dann bin ich zwar oft physisch am Rechner aber eben nicht gewillt, mich mental auf leichte Konversation einzustellen. Meistens arbeite ich irgend etwas. :)

Wenn mein Status also nicht auf Online steht, dann steht es jedem frei, mir dennoch Nachrichten zukommen zu lassen. Ob ich gleich oder später darauf antworte, hängt aber maßgeblich vom Inhalt ab. Auf ein »hi« ohne weiteren Content werde ich in der Regel 3 Stunden später nicht mehr antworten. Auch wenn ich beschäftigt bin, unterbreche ich meine Arbeit normal frühestens für eine Antwort auf die Nachricht nach dem »hi«. Und wer einen komplexen oder wichtigen Sachverhalt zu sagen hat, der ist in der Regel sowieso mit E-Mail oder gar Bugtracker besser bedient, denn nur da sind die Sachen eine gewisse Zeit später immer noch da.

Das jetzt nicht akut auf einen oder wenige Fälle bezogen, ich denke viele könnten sich angesprochen fühlen. Es ist eher eine allgemeine Feststellung, dass sich Leute offenbar wenig Gedanken machen, wie das auf mich wirkt, wenn ich zurück an den Rechner komme und 10 mal »hi« ohne weiteren Inhalt vorfinde.