Technik

Folgendes blogge ich eigentlich nur, weil ich bei Google mal gegen die vielen vielen Einträge mit "reassigndev" anstinken will

Das Problem:
XEN wirft beim Booten einer VM den Fehler "Error: <pci-bus-id>: non-page-aligned MMIO BAR found" und verweigert den Start einer virtuellen Maschine in die ein PCI-Device durchgereicht wird. Der Grund hierfür sind "unsaubere" Speicher-Bereiche, die nicht an einer 4KB-Grenze beginnen, ganz einfach unter /proc/iomem zu sehen, wenn der Range nicht mit "0xNNNNN000" beginnt.

Das zweite Problem:
Gibt man die Fehlermeldung bei Google ein, wird man jede Menge hilfreiche Tipps bekommen, es mit dem Kernel-Parametern "reassign_dev=<pci-bus-id>[,...]" und "reassign_resources" - ich bin mir auch sicher, dass die wirklich gut funktionieren. Auf einem alten Kernel.

Die Lösung:
Die Lösung ist recht einfach, aber war für mich schwer zu finden. Irgendwann ist dieser Parameter schlichtweg umbenannt bzw. aufgeräumt worden. Den selben Effekt kann man nun erreichen, indem man stattdessen einfach ein "pci=resource_alignment=<pci-bus-id>" in den Kernel-Parametern angibt.

Im Kernel-Log sieht das bei Erfolg dan btw. so aus:

pci 0000:05:00.0: reg 10 32bit mmio: [0xfebffc00-0xfebffdff]
pci 0000:05:00.0: Disabling memory decoding and releasing memory resources.
pci 0000:05:00.0: Rounding up size of resource #0 to 0x1000.

Ich habe mich mal wieder bestechen lassen...

Ein Kunde, der seinen Online-Shop bei uns betreibt, wollte das sein Shop automatisch in den SSL-verschlüsselten Modus wechselt, sobald ein (virtuelles) Verzeichnis aufgerufen wird, und fragte uns ob man da nicht was einfaches realisieren kann.

Wenn man es genau nimmt, bieten wir so etwas ähnliches schon eine halbe Ewigkeit an: Ist eine Webseite mit einem SSL-Zertifikat ausgestattet, so kann der Kunde bereits bei uns im Kundeninterface auswählen, ob die Webseite "verschlüsselt und unverschlüsselt" oder "nur verschlüsselt" existiert. Den gesunden Mittelweg gibt es natürlich auch noch: Optional können alle unverschlüsselten Anfragen auf die SSL-Verbindung umgeleitet werden.

Unser Kunde wollte dann aber doch lieber ein "hybrides Setup" ohne viel dafür tun zu müssen. Hat er auch eigentlich recht mit, denn bestimmt nicht alle Informationen sind so relevant als das sie den Prozessor in Sachen Verschlüsselung belasten müssen (wobei diese Wertung natürlich dem Kunden obliegt).

Dank einer kleinen Aufmerksamkeit seitens des Kunden, gibt es nun also die Möglichkeit unter der "Zugriffskontrolle" für "Verzeichnisse" die Option "SSL erzwingen" auszuwählen und so nur Anfragen für ein bestimmtes Unterverzeichnis auf dem Webserver in den verschlüsselten Modus zu katapultieren.

Eigentlich auch sinnvoll und wie ich sagen muss: Ein wirklich leckeres Feature!

Heimlich, still und leise haben wir vergangenen Montag den Bereich "Webserver" bei uns im Kundeninterface überarbeitet. An und für sich ist das relativ unspektakulär, denn oberflächlich hat sich zunächst rein gar nichts geändert, wir haben lediglich den darunter liegenden Code komplett überarbeitet.

Die eigentliche Änderung kam dann am Mittwoch hinzu: Wir haben unser SVN-Backend aufgeräumt und auf etwas solidere Beine gestellt.

So musste man bis dort hin einen "Kurznamen" für ein Verzeichnis eintragen, wenn man dort ein SVN-Repository erstellen bzw. verwenden wollte. Deassoziieren konnte man das Repository aber löschen war unmöglich und ein Tippfehler produzierte theoretisch Chaos auf dem Server (im Sinne von vielen ungenutzten Repositories). Allzu wohl gefühlt habe ich mich damit nie.

Das neue System führt nun eine etwas striktere Verwaltung ein. Ein SVN-Repository muss bevor sie verwendet werden kann erst in einer neuen Maske angelegt werden. Danach kann sie bequem per Drop-Down ausgewählt werden. Neu hinzu gekommen ist die Möglichkeit ein Repository nicht nur via WebDAV (und mod_svn) zugänglich zu machen sondern sie auch als Arbeitskopie direkt auf dem Webserver zu nutzen. Natürlich lassen sich Repositories nun auch komfortabel löschen, sobald man sie nicht mehr braucht. Darüber hinaus verschafft unser Kundeninterface einen kleinen Überblick über die Historie des SVNs.

Gegenwärtig arbeiten wir noch an einem RSS-Feed für die Repositories und an E-Mail-Berichten. Wenn da draußen noch weitere Ideen rumschwirren - immer her damit!

Ich versuche mir gerade anzugewöhnen überall (wo es möglich ist) nur einfache Anführungszeichen in unserem PHP-Code zu verwenden.

Die Erklärung hierfür ist relativ einfach: PHP verarbeitet dieses String (naiv getestet) ca. doppelt so schnell wie die in doppelten Anführungszeichen. So Geschichten wie Variablen in Strings einbetten sind bei uns sowieso weitesgehend tabu.

Ein Kunde hatte vergangene Woche ein Problem mit einer SVN-Repository im Root seiner Domain. Zugegebenermaßen war er der erste Kunde, der versucht hat eine SVN-Repository genau dort anzulegen - abgesehen von uns selbst, aber wir stellen in dieser Sache eine Art Sonderfall dar (mehr dazu später).

Ein Auschecken funktionierte hier ohne Probleme, sobald er aber einen Commit versuchte, schlug dieser mit einem "Dokument nicht gefunden"-Fehler (404) fehl. Die gemeldete URL hierbei war immer "/wbl/eine_art_hash/eine_nummer". Sehr merkwürdig!

Nach ein wenig hin und her checkte ich die Repository selbst aus und versuchte auch mal einen Commit während ich mit den HTTP-Traffic genau anschaute. Die übertragene URL sah mit "//!svn/wbl/eine_art_hash/eine_nummer" eigentlich ganz richtig aus und es erschien mir spontan ein sehr sehr merkwürdiger Fehler innerhalb des Webservers bei uns zu sein.

Bei genauerem hinschauen, genauer war ich gerade im Sourcecode von apr-util unterwegs, fiel mir auf, dass der Webserver das "//" am Anfang als einen Hinweis auf ein "Authority Component" (RFC 2396, 3.2) ansieht und das folgende "!svn" genau so auswertet. So kam dann auch die URL für die "Dokument nicht gefunden"-Meldung zustande.

In meinen Augen liegt der Fehler hierbei im SVN-Client wobei zwischen 1.5 und 1.6 alle Versionen betroffen sind. Ich habe dennoch einen Workaround bei uns entwickelt, der "//!svn" einfach nicht als ein "Authority Component" ansieht und als Pfad auf dem Webserver weiterverarbeitet.

Ich wollte auch immer schon mal im subversion-Paket nach dem Fehler (sofern es denn einer ist) suchen, aber dazu fehlt mir gerade beim besten Willen die Zeit. Der Grund warum der Fehler bei unserer eigenen SVN-Repository noch nicht auftrat ist denkbar einfach: Dort wird nur nach "/trunk" und "/branches" commited und die Verzeichnisse wurden angelegt, als die Repository noch nicht im Root einer Domain leg :eek: