Technik

Wir haben vor einiger Zeit heimlich, still und leise in der PHP-Bibliothek die hinter unserem Kundeninterface sitzt i18n- bzw. genauer gettext-Unterstützung eingebaut und setzen folglich die entsprechenden Locales in der Programmumgebung wie LC_MESSAGES oder LC_ALL. Dabei ist es dann recht schnell zu Problemen mit einen wie auch Softwaremodulen von Drittherstellern gekommen.

Konkreter Hintergrund: Immer wenn ein float-Wert (also eine Dezimalzahl mit Komma) als String ausgegeben werden sollte, wurden auch hier die entsprechenden Locales angewendet. Natürlich weiß ich, wie man das umgehen kann, aber u.U. ist das durchaus gewollt - außer man will z.B. ein Excel-Worksheet per PHP-Software generieren. Da macht ein float-Wert, der mit einem Komma "getrennt" ist wahnsinnig schnell Probleme.

Wir haben daher die interne Richtlinie ausgegeben für "Zahlen, die nicht direkt von Menschen gelesen werden sollen sondern für die Interaktion mit Software-Schnittstellen gedacht sind" stets die PHP-Funktion number_format() zu verwenden ist. Mich würde freuen, wenn andere Entwickler das auch so handhaben, bei den Bibliotheken die wir gepatched haben, sind die Änderungen auch schon weitergegeben worden.

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