Wohnzimmerhostblogger

So ein Blog verleitet natürlich dazu nur gutes über das eigene Geschäft zu schreiben und sich vielleicht das eine oder andere Mal mit Kunden-Aussagen zu schmücken. Es gibt aber so Momente, da ist es auch wichtig einfach die nackte Wahrheit zu schreiben und auch kritische Stimmen zu Worte kommen zu lassen:

Ich möchte mich jetzt mal richtig beschweren bei euch. So könnt ihr doch nicht weitermachen. Das geht so nicht.

ICH HABE EINE SPAM E-MAIL ERHALTEN!!! Und das ganze auch noch an meinem Geburtstag (was für ein Zufall).

Das ist die erste Spam Mail die durchgekommen ist, und das, obwohl ich schon seit fast 2 Jahren Kunden bei euch bin.

Ich habe fast alles getan habe um SPAM zu erhalten:

• E-Mailadresse auf der Website veröffentlicht
• In Foren benutzt
• In Newsletter angemeldet

Ich war schon kurz davor mich auf http://www.spamfan.de/subscribe.php einzutragen!

Beim ersten Absatz und in Anbetracht der vielen Großbuchtstaben habe ich schon richtig Angst bekommen...

Nachdem uns gestern Abend ein recht aufgeregter Kunde kontaktiert hat und ich bei meinen bisherigen Recherchen nichts herausfinden konnte dachte ich, ich stelle die Frage einfach mal direkt:

Weiß jemand, was mit dem deutsch-türkischen Webhosting-Dienstleister karaboga/MediaOn.com (nicht .de!) passiert ist?

Es ist doch wirklich unfassbar...

Das Stromsparen ging so kräftig weiter dass unser Strom-Lieferant erneut unsere Vorauszahlung gesenkt hat, nimmt man die letzten beiden Rückzahlungen nun zusammen, so sind die Hardwarekosten wieder drinnen :eek: Einfach unglaublich!

Ich habe heute überraschenderweise Post von der Deutschen Bahn bekommen.

Ein wenig die Stirn runzelnd, ob da vielleicht irgendwas bei der Abbuchung passiert sei o.ä., öffnete ich den Brief und fand ein Entschuldigungsschreiben für den vergangenen Winter mit seinen vielen betrieblichen Störungen vor, "die mich als Vielfahrer bestimmt auch betroffen haben und höchst unbefriedigend waren". Man entschuldigte sich für die Umstände und berichtete auch gleich, was man dagegen unternommen hat. Als "Goodie" gab es noch ein paar bahn.bonus-Punkte, die ich z.B. für eine Freifahrt einlösen kann.

Liebe Deutsche Bahn, man mag ja geteilter Meinung darüber sein wer denn Schuld ist, wenn im Winter Weichen einfrieren und kein Zug darüber fahren kann. Auch ihr hättet ggf. euer Hauptaugenmerk nicht unbedingt auf den Börsengang richten müssen, aber mal im Ernst: Ich bin und war auch den ganzen Winter über zufrieden. Mit der Bahn hab ich schon so viel Stress gespart, das können die eine oder andere Verspätung nicht wieder gut machen. Im Gegenteil: Sitzt man länger im Zug, kann man auch länger arbeiten. Im Auto im Stau wäre das wohl kaum denkbar.

Trotzdem vielen Dank für das Schreiben.

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