Wohnzimmerhostblogger

Huch... Schon wieder Freitag! Ich hätte schwören können heute wäre noch Donnerstag.

Dann ein schönes Wochenende, alle zusammen!

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.

Ein Kunde experimentiert gerade mit Git und WebDAV. Für uns natürlich nicht ganz uninteressant, da wir ohnehin bereits schwache Tendenzen in diese Richtung haben.

Wie ich heute morgen im Jabber-Support online ging erhielt ich zwei Nachrichten von ihm:

[Kunde,  18:44] hm also git kommt mit dem webdav nicht zurecht
[Kunde,  22:36] webdav mit git funktioniert jetzt gut
[Support, 8:47] Entscheid Dich mal!

Berücksichtigt man den zeitlichen Abstand zwischen den Nachrichten ist es wohl weniger merkwürdig, aber sie beide auf einmal zu bekommen wir schon recht amüsant. Die Zeichen für Git stehen also gut und ich hoffe ich kann den Kunden animieren mal ein HowTo für unser Wiki zu schreiben.

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:

Bei einer routinemäßigen Kontrolle unserer Bankauszüge musste mir heute folgender "Betreff" einer Überweisung auffallen:

KUNDENNUMMER
XXX
RECHNUNGSNUMMER
XXXXXXXXXX
BERND, KANNST DU BITTE MEIN
E ANSCHRIFT IN
XXXXXXX NN -
NNNNN XXXXXX AENDERN$
DANKE SCHONMAL
VIELE GRUESSE
AUS DEM XXXXXLAND
XXX XXXXXXXXX.,&-/+*$&$%&$

:eek:

Das Bundesverfassungsgericht hat gerade eben die Vorratsdatenspeicherung in ihrer aktuellen Form für verfassungswiedrig befunden und die speichernden Unternhemen aufgeforder diese Daten unverzüglich zu löschen.

Ich denke heute ist ein guter Tag für unser aller Privatsphäre

So fängt der Montag doch super an:

Lieber Herr Holzmüller,

vielen lieben Dank für die schnelle Antwort. Sie sind mein Held!

(Aus der Mail eines Kunden)

Mit dem neuen Rechenzentrum hier in Stuttgart scheint einiges überflüssig und leichter geworden zu sein:

Meine kleine Werkstatt direkt neben meinem Arbeitsplatz zum Beispiel. Wo früher noch ein lärmender Server zur Wartung heimgeholt wurde und noch zwei Räume weiter zu hören war herrscht nun Stille.

Die Maschinen kommen nun direkt ins Rechenzentrum und werden dort mit dem IP-KVM verkabelt. Die weitere Konfiguration passiert dann meistens aus einem nahegelegenen Coffee-Shop. Dank "Virtual Media" ist auch das CD-Rom "einlegen" und "wechseln" aus der Ferne kein Thema mehr. Praktisch!

Ein Kunde wollte Anfang vergangener Woche seine Domain zu einem anderen Provider umziehen. Aus Sicherheitsgründen haben wir nach einer "vorgangsbezogenen Unterschrift" verlangt - wenn ich mir das Kündigungsprozedere bei einigen Marktbegleitern vorstelle, dann ist das wohl noch mehr als milde.

Jedoch habe ich seitdem nichts mehr vom Kunden gehört, auf Nachfrage per E-Mail wurde auch nicht reagiert. :hmm:
Ich bin echt versucht dort einmal persönlich anzurufen - selbst wenn ich letzten Endes hier einer Kündigung hinterhertelefone, so gehört es wohl doch zum guten Ton. Sollte es wirklich der Wille des Kunden sein, so wird er es sich auch nicht anders überlegt haben...