netzhure.de

Mehr zur Warnung an alle Leser: Ich bin gerade dabei mal ein Punkte auf der Todo-Liste für diesen Blog abzuarbeiten:

• Umstieg von Kategorien auf Tags - die Kategorie-Feeds funktionieren nun nicht mehr, dafür gibt es einzelne für jeden Tags. Erstmal wurden aber Kategorien 1:1 nach Tags umgezogen. Eventuell kann hier der RSS-Feed an manchen Stellen durchdrehen und alte Artikel neu ausliefern.
• Die Blogroll wurde abgeschaltet, nachdem ich nun recht lange schon von bloglines weg war und auf meine eigene Installation von Tiny Tiny RSS setze, war diese auch nicht mehr unbedingt aktuell. Desweiteren halte ich bei der mittlerweile gegebenen Größe eine eventuelle Untergliederung nicht für falsch, genauso wie eine stärkere Vorselektion. Mal schauen wie ich dies Umsetzen kann.
• Irgendwie hatte ich drei Punkte im Kopf. Den dritten habe ich auch mal angelegt. Nur der Inhalt ist mir entfallen.

Ich hatte gerade die Anforderung, dass ein Server an bestimmte Clients die Existenz von einigen Domains verschweigen muss, den Rest aber als forwarder normal aufzulösen hat.

Nach ein bisschen gefrickel habe ich rausbekommen, dass es garnicht so schwer ist:

Eigentlich braucht man nur einen "Ich weiß von Nix"-View, und einen zweiten, der passend die Anfragen aufteilt:

view "nix" {
    match-clients {127.0.0.1/8};
};
view "zensiert {
    recursion yes;
    zone "mustnotbeleaked.example.com" {
        type forward;
        forward only; // verhindert, dass er bei der nicht erfolgten antwort den forwarder unten befragt
        forwarders {
            127.0.0.1;
        };
    };
    forwarders {
        192.168.1.1; // der eigentliche nameserver
    };
};

Und wer sich jetzt wundert, weshalb man das nicht einfach per ACL verbietet - die Antwort sieht anders aus, jenachdem, ob ein SERVFAIL (u.a. per ACL verboten) oder ein NXDOMAIN (die Domain gibt es nicht) geschickt wird, und somit ist der ACL-Fall recht einfach zu detektieren.

Als ich einen Eintrag beim Wohnzimmerhostblogger gelesen habe, musste ich schon schlucken.

Dieser Bug ist seit über einem Jahr offen, und das PHP-Team meint es wäre nicht ihr Problem. Kurz zusammengefasst: Unter *IX findet der Zugriff auf eigentlich alles über sogenannte File-Deskriptoren (kurz FD) statt. Wenn Apache als Webserver läuft, hat er nun also einen File-Deskriptor für die IP und den Port, auf dem er lauscht, offen. Damit weiß das Betriebssystem, wohin es Anfragen weiterleiten muss, und der Apache hat eine Art Eingangskanal für die Anfragen. Ein Apache-Modul, so zum Beispiel PHP, hat automatisch als Teil von Apache auch Zugriff auf diese ganzen FDs.

Wenn aus PHP heraus nun ein Programm gestartet wird, sollten diesem diese FDs aber nicht zur Verfügung gestellt werden. PHP räumt hier aber in keiner Weise auf, so dass ein über PHP (mittels system(), exec() oder eines der diversen anderen Kommandos) gestartetes Programm auf diesen FD auch zugreifen kann. Und nicht nur das, es kann ihn sogar übernehmen!

Konkret heisst das, sobald man auf einem System Dateien hochladen kann, kann man damit ein PHP-Skript und ein kleines Programm hochladen. Dieses Programm wird nun über PHP gestartet, und schnappt sich die FDs vom Apache. Und kann nun zum Beispiel Web-Server spielen, ohne dass es von außen zu bemerken ist. Und damit auf den verbreiteten Shared-Hosting-Systemen, die viele Kundenpräsenzen mit einem Apache bedienen, auch die Anfragen an alle anderen Kunden sich unter den Nagel reißen. Und nicht nur das, auf alle Log- und sonstigen Dateien die der Apache offen hat (eventuell auch SSL-Zertifikate o.ä.) kann damit zugegriffen werden

Und nun stellt sich PHP da hin und meint, es wäre nicht ihr Problem. Von mir aus, dann sollten sie sich aber im Zuge einer Behebung doch selber darum sorgen, dass es im Apache oder wo auch immer sie meinen dass das Problem eigentlich herkommt, geschlossen wird. Wie gut, dass ich weder den Apache als Webserver noch PHP als Modul einsetze, da besteht dieses Problem nämlich nicht.

Dieses Skript, in ~/.vim/plugin/dnstools.vim versenkt, bietet das Kommando DNSserial an, welches automatisch erkennt, ob man Serials im "1, 2, 3 style", "YYYYMMDD style" oder "YYYYMMDDN style" verwendet (so aus den Kommentaren geklaut) und dementsprechend die Serial passend erhöht.

Richtig komfortabel wird es aber erst durch ein

autocmd BufWritePre /etc/bind/m/* call DNSserial()

in der .vimrc, wodurch bei jedem Schreibaufruf auf eine Datei in /etc/bind/m/* (wo meine Master-Zonefiles liegen) das Skript aufgerufen wird. Nie mehr Inkonsistenzen zwischen Master und Slave durch versehentlich nicht hochgedrehte Serials!

Wer kennt das nicht, Handy ist zu langsam (GPRS) oder zu teuer (UMTS) und der einzige empfangbare Accespoint will auch noch bezahlt werden. Zumindest für klassischen Traffic, denn DNS lassen die meisten Hotspots durch. Und genau hier greift dns2tcp. Die Dokumenatation ist etwas lückenhaft, aber nachdem ich schon für GRML-Tips die Installation beschrieben habe, will ich dies hier auch nocheinmal tun:

Anders kann ich mir die nahezu sofortigen Antworten und Änderungen nicht erklären. Um 15:09 habe ich an die cmus-Mailingliste geschrieben, dass der weltbeste Musikplayer cmus durch ständige nanosleeps und damit verbundene Wakeups meine CPU aus dem Schlaf reißt. Damit verbringt sie weniger Zeit als eigentlich möglich im C3-State, in welchem sie schon sehr tief schläft und dementsprechend weniger Energie verbraucht, was meinem Laptop wieder zu längerer Laufzeit verhilft.

Um 16:43 kam schon die erste Antwort, insofern sehr gut klingend, als dass Timo, der Autor von cmus, selbst das Problem auch sieht:

cmus' threads use nanosleep() to sleep usually 50 ms and then check whether player status has changed etc. I know this is ugly and should be fixed. Some sleeps could be replaced with pthread_cond_wait() quite easily, I think. I'll see what I can do.

Kurz darauf kam auch schon der git-commit, in welchem die angekündigten Änderungen durchgeführt wurden.

Aber es sollte noch besser kommen, 18:11 kam noch eine Ergänzung. Die Änderungen die er vorhin commitet hat haben zu ein paar Verbesserungen geführt, aber das eigentliche Problem der Schleife und checks wird wohl auch verschwinden:

Some time ago I started rewriting player.c to request based (main thread just adds commands to a queue and the producer thread would do the real work) and used pthread_cond as much as possible. But code in the master branch has diverged quite a lot since then (replay gain etc.) and I wasn't sure if the rewrite would be useful so I let the code rot.

Now there's a good reason to starting working on the rewrite again. It takes some time until it's ready to be published. I probably create a new branch for it because the change is quite intrusive.

So machen Bugreporten Spass :D

Google Earth verwendet das proprietäre kml-Format, um Wegpunkte abzuspeichern, und bietet für verbreitetere Formate wie GPX nur in der kostenpflichtigen Version Unterstützung. Aber Dank gpsbabel ist das kein Problem: gpsbabel -i gpx -f $ROUTE_IN_GPX.gpx -o kml -F $ZIELDATEI_IN_KML.kml

Wer kein GPS-Empfänger hat, aber trotzdem gerne Routen erstellen würde, sollte mal unter http://www.wegeundpunkte.de/ vorbeischauen. Hier lassen sich auch GPX-Routen ohne Extrasoftware erstellen, so direkt und interaktiv im Browser.

SdK hat hier gerade für mich das fast unmögliche möglich gemacht: Ich habe an meinem Rechner zwei Bildschirme hängen, die an völlig anderen Stellen im Zimmer stehen, der eine am Schreibtisch, der zweite zum bequemen Videoschauen aus dem Bett. Daher wollte ich auch kein Xinerama verwenden, sondern "normalen" DualScreen-Betrieb haben. Das Problem war nun, dieses wunderbar beschissene Miststück von Treiber davon zu überzeugen, dass der LCD der primäre Monitor (auf dem ich mein entrance zum einloggen und dann auch den Windowmanager haben will) ist. Der Trick waren die "UseDisplayDevice"-Optionen in der Screen-Sektion, das Problem war die nicht nachvollziehbare Zuordnung von Monitor und config-direktiven, so dass immer mal wieder die Auflösungen vertauscht waren oder doch wieder der CRT als primärer Monitor verwendet wurde. Die Konfiguration, mit der es nach ca 2h Testen endlich tat, sieht nun folgendermaßen aus:

Durch URS wurde ich auf den Debian-Bugreport #413469 ion3: The package is outdated aufmerksam gemacht. Darin beschwert sich Tumov, der Programmierer hinter ion3, darüber, dass in Debian Stable eine veraltete Development-Version von ion3 enthalten ist, die doch bitte entfernt/geupdatet werden soll. Zwischenzeitlich überlegt er sogar, seine Lizenz um etwas wie das folgende zu erweitern:

I have been considering adding something like the following to the Ion3 license. If it is against the DFSG, well, the effect still be the intended.

---

This work, "Ion3", is licensed under the GNU Lesser General Public License (LGPL), reproduced below, extended with the following "Distributor timely response clause" (D).

D. Anyone distributing Ion3 in aggregate with other works, must within twenty-eight (28) days from the release of a new version of Ion3, either (A) upgrade the aggregate to include the new version, and cause the new version be installed when a user tries to install an unspecified version of Ion3, or upgrade Ion3 (from the aggregate); or (B) remove Ion3 from the aggregate, and notify users of the removal, when they try to upgrade the aggregate or Ion3 (from the aggregate) and have installed an old version of Ion3. (It is, however, not necessary to remove Ion3 from the user's computer; merely notify of its out-datedness.)

The requirements above on responses to user actions do not apply, if the user is not network-connected, or chooses to not use network upgrades, and is using physical distribution media.

This clause does not bind any rebranded derivative works, that can not be confused with Ion3: that is, any derivative work whose name can not be confused with "Ion3", and whose listed maintainer (in the README) is different from that of Ion3, may be distributed under the LGPL or GPL without this clause.

Ich habe mir vorhin mal eine halbe Stunde Zeit genommen, um bei meinem Drucker endlich die Ränder richtig nachzujustieren, denn auf OpenPrinting (ehemals linuxprinting.org) gibt es zwar PPDs für alle möglichen Geschwister meines Brother HL-2070N, aber nicht für ihn selbst. Somit wurde immer rechts, oben und links ein Stück des Ausdrucks abgeschnitten. Um nun für einen Drucker die passenden Margins zu bestimmen, gibt es ein kleines Programm alignmargins samt zugehöriger PostScript-Datei, mit welcher sich die benötigten Werte relativ schnell bestimmen lassen:

alignmargins - Program to adjust the margins and the centering when
	printing PostScript files on a printer set up with
	CUPS. Especially needed on PCL laser printers from other
	manufacturers than HP since the GhostScript PCL drivers are
	mainly tested on HP printers. To use it, follow simply the
	instructions on the screen. If it fails, adjust the paths in
	the beginning of the script (script written in Perl). The
	program saves the adjustments in the PPD file of the print
	queue (/etc/cups/ppd/.ppd) as an additional option
	(with which you can turn on and off your settings). It is
	recommended to use the improved alignment page "align.ps" (see
	above). Put "align.ps" into te same directory as
	"alignmargins" or into one of the directories listed in the
	"my $adjustmentpage = ..." in the script.

Wie schon berichtet, hat bei mir jede (Sub-)Domain ihr eigenes chroot. Daraus ergibt sich nun aber das (noch-nicht)-Problem, dass ich maximal 17 (Sub-)Domains (ein /28 IPv4 und die Standard-IP) verwenden kann. Daher habe ich seit heute einen weiteren lighty laufen, diesen aber als Reverse-Proxy, der je nach angefragtem Host die Anfrage an einen der anderen, auf localhost lauschenden lighty (wenn ich es mal brauchen sollte würden hierdurch auch Tomcat und andere Perversitäten gehen) weiterreicht.

Als besonderes Schmankerl fungiert er gleichzeitig noch als https-Verschlüssler. Ich habe mir hierzu bei CAcert ein Zertifikat mit mehreren SubAltNames, welches sämtliche Domains enthält, erzeugt. Mit diesem einen Zertifikat füttere ich nun nur den Proxy, und schon sind alle Seite hintendrann auch über https erreichbar!

Das genaue Setup dazu sieht wie folgt aus:

So, nun ist mein Blog also auch auf dem neuen Server angekommen. Dort läuft er nun schön brav in seinem eigenen chroot (über das genaue Setup und die Erfahrungen mit jailer und jailtool werde ich noch seperat Berichten), mit einem lighty anstatt Apache als Webserver und hoffentlich insgesamt mehr Performance.

Falls es irgendwo zu Problemen durch falsche Berechtigungen, die Rewrite-Regeln, 404ern oder sonstwas kommt, würde ich um eine kleine Nachricht biten...

Mal wieder etwas zum Thema Geekspielereien, diesmal mit einem Bild zum Einstieg:
Wir sehen einen Firefox, der bis auf die Menüleiste mehrfach sich selbst enthält. Und eigentlich war hier ein längerer Text hingeschrieben, nur habe ich für das Bild dann JavaScript aktiviert (so von wegen Bild einfügen per Mausklick für Tippfaule) und der Text war weg. Kurz zusammengefasst läuft das so: Das gesamte Userinterface des Firefox ist in XUL geschrieben, und das eigentliche Binary eine Art Parser für XUL. Mit chrome://browser/content/browser.xul als URL weise ich ihn einfach an, die Datei /browser/content/browser.xul aus dem Chrome-Directory, in meinem Fall also /usr/share/iceweasel/chrome/browser/content/browser/browser.xul, anzuzeigen. Und Firefox erkennt nun, dass dies xul-Code ist, und statt ihn mir anzuzeigen interpretiert er ihn.

Ja, manchmal Frage ich mich doch, was haben Leute geschluckt die sich sowas ausdenken wie das LAN an der Technischen Universität Darmstadt. Eigentlich dachte ich im ersten Moment, das sieht aus wie in Heidelberg oder Mannheim, man verbindet sich per WLAN, bekommt eine IP per DHCP und landet erstmal in einem "Toten Netz", welcher als Tor zur Außenwelt einen VPN-Server anbietet. Traditionellerweise einen von Cisco, sprich man kann sich seinen Netzwerkstack mit dem Originalclient total durcheinanderbringen, oder aber den vpnc verwenden und (fast) glücklich werden. Denn er unterstützt leider immernoch kein rekeying, so dass man im Normalfall nach 8h Connection rausfliegt.

So, der vpnc war Dank einer Infoseite der TUD problemlos einzurichten, aber dann war immer nach 5Minuten Ende der Verbindung. Aufgrund der Leasetime von 300s begann ich, den Fehler im DHCP-Umfeld zu suchen. Die Aktion war sehr amüsant, in ein paar Minuten sich möglichst viele Ausgaben übers IRC schicken lassen, nachdenken, und wenn die Verbindung das nächste mal steht Lösungsvorschläge unterbreiten, bis das ganze tat. Denn das Problem hatte nicht ich, sondern meine Freundin - und während der Vorlesung konnten wir schlecht telefonieren. Ausschlaggebend für die erste Verwunderung waren IP des DHCP-Servers sowie die Routen:

# dhclient ath0
[...]
DHCPACK from 130.83.156.7
[...]
# ip r l
130.83.84.0/23 dev ath0 proto kernel scope link src 130.83.84.164
default via 130.83.85.254 dev ath0

Dem technisch versierten Leser mag hier auffallen, dass der DHCP-Server nur über das Default-Gateway erreichbar ist. Diese Konstruktion läuft so schonmal nicht ohne Spezialkonstruktionen wie dhcp-relay, da der DHCPREQUEST immer an 255.255.255.255 geht, und somit nicht über das lokale Netz hinauskommt. Aber es läuft soweit noch - bis der vpnc gestartet wird. Denn dann sehen die Routen auf einmal folgendermaßen aus:
# ip r l
130.83.253.21 via 130.83.85.254 dev ath0 src 130.83.84.183 mtu 1500 advmss 1460 hoplimit 64
130.83.84.0/23 dev ath0 proto kernel scope link src 130.83.84.183
default dev tun0 scope link
Schön, die Default-Route geht nun durch das VPN. Eigentlich ist das so auch erwünscht, denn ohne VPN gibt es kein Internet. Allerdings ist nun auf einmal auch der DHCP-Server nicht mehr erreichbar. Und somit wird braverweise die IP nach Ablauf des Leases nicht mehr verwendet.

Wir hatten gestern den International Talk Like A Pirate Day. Und selbst wenn Kris ihn als unnötig abstempelt, scheint Linus Torvalds an ihm gefallen gefunden zu haben, so schreibt er im Changelog zum Kernel 2.6.18

Linux v2.6.18. Arrr!
Ahoy, all land-lubbers, test me out right smartly!