Technik

Vor fast zwei Jahren hatten wir aus Sicherheitsgründen den externen Zugriff auf unsere MySQL-Datenbanken gesperrt. Ich behaupte einfach mal, dass das MySQL-Protokoll irgendwie zu unsicher erschien, um bedenkenlos einen Port damit ins Internet offen zu haben.

Wir hatten schon darmals den Plan als Ersatz für den nun nicht mehr offenen Port eine Art "Dial in" anzubieten, damit unsere Kunden nach wie vor von außen auf die Datenbanken können. Nur irgendwie hat sich nie jemand bis zum Ende darum gekümmert, was wohl auch an der eher geringen Nachfrage lag - bis gestern.

Nicht, dass die Nachfrage hier rapide angestiegen wäre, aber irgendwie wollte ich dieses Thema mal vom Tisch haben und habe endlich auf Basis von OpenVPN einen Server-Dialin realisiert. Im Prinzip war es auch nur das zusammenstecken oder modifizieren von ohnehin bereits vorhandenen Komponenten.

Gegenwärtig kommt das neue System erst auf einem Webserver zum Einsatz und ist Clientseitig vielleicht noch nicht allzu komfortabel, wird aber dennoch bereits von einem Kunden getestet. Wer auch will: Einfach melden!

Wir haben Anfang der Woche ein lang anstehendes Update für die bei uns eingesetzten PHP-Versionen durchgeführt. Die neue Standard-Version ist nun 5.2.13, ganz neu hinzugekommen (wobei schon sehr lange in der Testumgebung) ist 5.3.2.

Kunden, die bereits auf einer 5.2.x-Version laufen, werden wir in den kommenden Tagen automatisch auf 5.2.13 upgraden. Alle anderen oder jeder, der gerne PHP 5.3 ausprobieren mag, darf sich gerne an unseren Support wenden.

Nachdem es bekanntlich letzte Woche Mittwoch massive Probleme mit der .de-Zone gab, haben wir uns entschlossen unsere Nameserver nicht mehr nur auf einer einzelnen Domain zu betreiben.

Wenn man es genau nimmt, waren unsere Nameserver gar nicht von dem Ausfall betroffen, denn sie liefen ausschließlich auf einer .info-Domain. Allerdings kann man ja nie wissen ob dort nicht mal ähnliches passiert. Seit gestern betreiben wir unsere Nameserver nun auf einer .net-, einer .de- und einer .eu-Domain - die .info-Domain ist lustigerweise komplett rausgefallen, die passte nicht mehr so gut in die "CI" der Nameserver

Momentan scheint es seitens der DeNIC irgendwelche Probleme mit den Nameservern zu geben...

Ich weiß noch nichts genaueres, aber sollte die eine oder andere .de-Domain gerade mal nicht funktionieren: Ruhe bewahren, die sind noch da

Ich bin heute morgen etwas fasziniert, wie sehr man sich aufregen kann, dass man geschlagene 10 Meter laufen muss wenn Wake-on-LAN auf einer Workstation ausnahmsweise mal nicht funktioniert und man den Einschalt-Knopf manuell betätigen mus.

Wir haben seit zwei Wochen im Rechenzentrum Stuttgart eine IPv6-Spielwiese.

Eine "Spielwiese" aus vielerlei Gründen: Zum einen bietet unser Rechenzentrums-Dienstleister nativ noch kein IPv6 an und zum anderen ist unser System noch recht IPv4-lastig. Da uns aber der IPv6-Support für Q3 2010 versprochen wurde (das war u.a. im Anforderungskatalog für die Rechenzentrumssuche) wollen wir uns so langsam darauf vorbereiten.

Um den normalen Betrieb nicht zu beeinflussen und das Maximum an "Spieltrieb" walten zu lassen, führen wir den Traffic über eine komplett vom Produktiv-Betrieb abgeschirmte Infrastruktur und die produktiven Webserver spielen natürlich auch nicht mit - man weiß ja nie

Das erste was im Zusammenhang mit IPv6 bei uns aufgeflammt ist war übrigends eine Zuneigung für "Hexspeak".

1. April, Stuttgart. Der Internet-Dienstleister "tiggersWelt.net" stellte heute morgen während einer groß angelegten Presse-Veranstaltung ein neues bahnbrechendes Produkt vor, das die Internet-Nutzung in Zukunft besonders in der Politik revolutionieren sollte:

Den Faxabruf für das Internet.

Bernd Holzmüller, Geschäftsführer von tiggersWelt.net, erklärte, das man in der Vergangenheit recht oft von der diskriminierten Masse der sog. "Internet-Ausdrucker" gehört habe und man nun auch die individuellen Bedürfnisse dieser Menschen befriedigen wollte. Das junge Unternehmen bietet ab sofort unter der Telefonnummer 0711 / 550 425 97 einen Faxabruf für das Internet an. Die Probleme die beim Eingeben der Internet-Adresse entstehen habe man ganz einfach gelöst. Der Kunde muss lediglich die einzelnen Zeichen der URL durch die Position im Alphabet wiedergeben und hinten an die Telefonnummer anhängen, d.h. www.tiggerswelt.net wäre z.B. unter 0711 / 550 425 97 232323 * 2009070705181923051220 * 140520 erreichbar. Ein weiterer Mitarbeiter des Unternehmens sagte hierzu: "Die meisten Menschen der Zielgruppe haben ja eh mehr als genug Zeit um so lange Telefonnummern einzutippen, im Zweifel haben sie ja noch ihre Sekretärin".

Allerdings verlief der Start des Produktes wesentlich besser als erwartet, sodass die Internet-Anbindung bereits jetzt überlastet ist und es zu Problemen mit der Adressauflösung und der Faxzustellung kommen kann.

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:

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!

Wir haben immer mal wieder Support-Anfragen die sich auf nicht funktionierende "externe Domains" beziehen, also Domainnamen die nicht von uns verwaltet werden sondern die wir nur für unsere Kunden auf den Webservern verwalten.

Besonders jetzt, wo wir unser Rechenzentrum wechseln, häufen sich diese Probleme - was zugegebenermaßen auch mitunter an unserer Datenbank liegt, die nicht immer weiß, ob nun unsere Nameserver verwendet werden oder nicht. Daher haben wir am Wochenende einen neuen Dienst eingeführt, der als "extern" markierte Domains regelmäßig prüft und den Inhaber auf eventuelle Unstimmigkeiten hinweist:

Hallo Bernd,

wir haben die Einstellungen der bei uns für Dich konfigurierten "externen Domains" und die dazugehörigen Webserver überprüft und dabei folgende Abweichungen festgestellt:

deinedomain.de:
 Erwartet: AAA.BBB.CCC.DDD
 Aktuell:  DDD.EEE.FFF.GGG

deineanderedomain.de:
 Erwartet: AAA.BBB.CCC.DDD
 Aktuell:  ZZZ.YYY.AAA.DDD

Bitte überprüfe die Abweichungen und stelle bei Bedarf bei Deinem Domainanbieter die DNS-Daten auf die "erwarteten Einstellungen" um.

Bei weiteren Fragen kannst Du unseren Support gerne über unsere E-Mail-Adresse support@tiggerswelt.net erreichen.


Mit freundlichen Grüßen aus Stuttgart,

Ihr tiggersWelt.net-Team

Produktiv ist der Dienst gestern Abend das erste mal gelaufen - und es gab auch prompt nur positives Feedback dazu

Wir haben heute morgen ein neues Feature für unser E-Mail-System in den Produktiv-Status überführt:

Ab sofort können E-Mail-Adressen oder ganze Domains (via Catch-All) auf einen anderen Mailserver unter der selben Domain weitergeleitet werden.

Die Spezialität in unserer Implementation liegt darin, dass es auch für einzelne E-Mail-Adressen funktioniert und man nicht pauschal ganze Domains weiterleitet. Wer sich jetzt fragt, warum wir solche Szenarien erlauben - ganz einfach: auf Kundenwunsch hin! Wobei es nicht ganz trivial war diese Funktionalität neben den üblichen "virtuellen Aliassen" in Postfix hinzubiegen. Letzten Endes sind drei neue Dictionaries hinzu gekommen, das eine zum Taggen der E-Mail, das andere zum bestimmen der Ziel-Route und das letzte um den Tag wieder zu entfernen. Klingt verrückt? Ist es aber nicht und funktionieren tut es richtig gut

Ich bin mal gespannt, ob und welcher Akzeptanz sich das neue Feature erfreut. Neben den üblichen anfragenden Verdächtigen hätte ich immerhin schon direkt einen Neukunden im Schlepptau.