Technik

Ich brauchte ein Dokument von einem Kunden schriftlich... Hier ist der Weg, den das Dokument auf seinem Weg zu mir nehmen musste:

1. Der Kunde verfasst das Dokument an seinem PC
2. Er druckt es aus
3. Er unterschreibt es
4. Er scannt es als PDF ein
5. ... und schickt es via Internet an sein Fax-Gateway
6. Der Faxgateway ruft mein Faxgerät an und schickt das Fax raus
7. Mein Fax nimmt das Fax entgegen und wandelt es in eine PDF-Datei um
8. Ich bekomme die PDF-Datei in meine Mailbox

Eigentlich überflüssig zu erwähnen, dass unser Fax ca. 8 Meter weiter von hier steht und das das Fax zwischen Schritt 7 und 8 nochmal einige hundert Kilometer durch das Internet zurücklegt...

Der liebe Kunde meinte eben dann auch, dass man von Schritt 4 auch hätte gleich zu Schritt 8 springen können. Stimmt, das steht sogar in unseren AGB so!

Nachdem ich vorgestern ein wenig genötigt war an einem Webserver (softwaretechnisch) rumzuschrauben und auch ein wenig C schreiben musste, bin ich in eine regelrechte Sucht verfallen.

Ich habe die letzten zwei Tage nur noch C-schreibend verbracht, primär habe ich ein paar schon lange gewünschte Verbesserungen im Bezug auf die Behandlung von FastCGI-Prozessen umgesetzt und ein neues Modul für die Datenbank-gestützte Benutzer-Authentifikation via Apache fast fertig geschrieben... Ich bin gespannt, was da noch alles folgen wird

Faszinierend war ja auch, dass ich in diesen zwei Tagen meinen alten C-Stil komplett überdacht habe... Gehört wohl dazu, aber nicht, dass C noch irgendwann einmal zu meinen üblichen Lieblingssprachen gehört... :eek:

Ich hab in der letzten Zeit ja eine Menge Serendipities installiert... Wenn ich in Gedanken nachzähle komme ich bestimmt auf ca. 18 Installationen seit den Ostertagen... (Wobei nicht alle jeweils für einen einzelnen Kunden waren)

Mir ist dabei mal aufgefallen, dass ich immer zwischen zwei Varianten hin und her tendiere: Auf der einen Seite die Installation im "Root" der Domain (so wie hier) und auf der anderen Seite die Installation in einem Unterverzeichnis "/blog" (so wie anderswo). Sofern für letztere Variante nicht einschlägige und vorher kommunizierte Gründe gibt, entscheide ich das anscheinend immer ganz rein intuitiv und wähle eine der beiden Varianten total unbewusst. Im Falle des Unterverzeichnisses wird dann auch - total im Wahn - eine Weiterleitung im Root-Verzeichnis der Domain angelegt...

Wirklich Gedanken habe ich mir wie gesagt noch nie darüber gemacht... Es ist bisher einfach immer passiert...

Jetzt wo ich mal darüber nachdenke, denke ich aber, dass das Unterverzeichnis die bessere Wahl ist - obwohl ich mit der anderen Variante eher liebäugeln würde. Sie lässt dem Kunden doch irgendwo mehr Freiraum für die Installation von anderen Anwendungen oder das Hochladen von Dateien außerhalb des Blogs... Stimmt man mir zu? Was würdet ihr (auch aus Kundensicht) bevorzugen?

... diesmal auf Linux...

Vergangene Woche hab ich mich mal aus gegebenem Anlass nach Finanzsoftware umgeschaut. Refernzprodukt hierfür ist sicherlich StarMoney, was sogar als Version für Linux angeboten wird. Wer nach der Überschrift weiterliest, erkennt allerdings sofort, dass es sich hierbei weniger um eine Version für Linux handelt als um eine "Linux-freundliche" Version

Genutzt wird hier nämlich Wine - und bei der Installation sogar "Schweinereien" wie der Internet Explorer und Konsorten installiert...

Einfach wegklicken!

"Fehler einfach wegklicken" (sinngemäß)

Typisch Windows...

Ich überlege gerade, ob ich nicht unsere PHP-Version um SVN-Bindings zu erweitern...

Grundsätzlich macht es jetzt wohl noch keinen Sinn - mangels Nachfrage, aber wer weiß schon, wie sich das entwickelt
Außerdem wollte ich immer schon mal so ein Online-SVN-Browser auf PHP-Basis...

Ein anderes Feature-Request musste ich heute leider mangels Durchführbarkeit abschmiettern Auch trotz Bestechungsversuch...

Allein für die verschlüsselte Inbox müssen wir von unserer Seite her einige Public Keys der Kunden vorhalten - was kein Problem darstellt. Aber eigentlich wäre es schade, diese große (neue) Datensammel- und -vorhaltemaschine nur für den Zweck zur E-Mail-Verschlüsselung zu gebrauchen. Da muss doch ein wenig mehr Potential dahinter stecken...

Mit einem Kunden, der vor einiger Zeit mit GnuPG experimentierte, habe ich so die Idee entwickelt Kunden eine Art Download-Seite anzubieten - natürlich macht das nur (immernoch begrenzt) Sinn, weil diese SSL-Verschlüsselt und offiziell signiert ist. Natürlich gibt es genug Möglichkeiten seinen Key irgendwo auf einem Keyserver zu hinterlegen, aber es scheint auch in Mode zu sein, seine Keys parallel dazu auf einen Webserver hochzuladen... Wer letzteres nicht sein lassen will, solls dann doch zumindest SSL-geschützt und komfortabel über unser Kundeninterface tun

Alle Informationen zu Domains und vHosts werden bei uns zentral in einer Datenbank abgelegt, von der aus die Einstellungen (sofern verändert) regelmäßig auf die Server repliziert werden. Das System stammt im Prinzip noch aus unseren (darmals "meinen") ersten Tagen und ist seitdem enorm gewachsen - was früher recht statisch Apache's vHost-Einträge verwaltete macht heute wirklich alles

Da ist es kein Wunder, dass einige Bereiche der Datenbank mit der Zeit etwas schwerfällig oder unflexibel geworden sind, so braucht der Deamon, der die Apache-Konfiguration generiert auf einigen Webservern zwischen 5 und 10 Minuten zur Ausführung und isst in dieser Zeit nicht gerade wenig Ressourcen. Das schreit geradezu nach einem neuen System...

... an dem wir auch wirklich gerade arbeiten. Es führt eine Art ToDo-Liste ein, aus der die Server sich ihre Aufgaben individuell heraussuchen und abarbeiten. Ganz nebenbei bekommt jede Maschine - ähnlich wie bei SVN - eine Revisionsnummer, sodass immer ersichtlich ist, welcher Server gerade welchen Status hat, was enorme Vorteile für z.B. das Multihoming von Webseiten oder auch einfach nur (das Multihoming) von Kunden in sich birgt.

Parallel dazu strukturieren wir das Dateisystem ein wenig um, sodass das neu schreiben von Konfigurationsdateien, aber auch das entfernen von Kunden aus dem System einfacher gestalten wird (ich glaube ich erwähnte es bereits). Die richtig aufwendigen Aufgaben wie z.B. aufräumen, kann diese Liste allerdings noch nicht übernehmen, das wird in Zukunft wohl nur noch ein oder zweimal am Tag stattfinden.

Lustig nur, dass sowohl mein Helferlein wie auch ich spontan das selbe Systemdesign im Kopf hatten - auch Gegensätze denken eben mal gleich

Nachdem die Feature-Idee hier vielleicht nicht so viele Vorteile bieten mag, wie es auf den ersten Blick klingt, kommt sie nun doch. Allein schon aus Prinzip, denn auch der geneigte Leser wird schon mitbekommen haben, dass sich bei uns im Bereich des Datenschutzes gerade viel bewegt. So gibt es im (internen) Wiki auch schon eine endlos lange Seite, die sich mit dem Thema auseinandersetzt und versucht zu ermitteln, welche Daten es bei uns gibt und wie man diese effektiv schützen kann.

Es mag komisch klingen, aber ein Stück weit fühlte ich mich gestern auch ein wenig im Namen unserer Kunden auf der Demo unterwegs - vielleicht verbuche ich es dann auch als Dienstreise Überhaupt kann wohl niemand ernsthaft mehr behaupten, Datenschutz ginge ihn nichts an oder man hätte nichts zu verbergen. Letzteres trift sicherlich in fast 110% der Fälle zu, dennoch sollte es anderen Menschen nicht unbedingt möglich gemacht werden auf die eigenen Daten (welcher Art auch immer) zugriff zu erlangen. Und so hoffe, jeden von euch auf der nächsten Demo begrüßen zu dürfen

Im Bezug auf die Möglichkeit die Inbox zu verschlüsseln habe ich gerade eben erste Testprogramme geschrieben, die noch etwas statisch eingehende Mails verschlüsseln und ablegen können - und die das auch kompatibel tun (das größte Problem, wenn ich etwas implementiere ). Dabei ist es mir mittlerweile eigentlich völlig egal, was auf dem Weg zu uns mit der Mail passieren könnte. Priorität hat hier eindeutig die Tatsache, dass unser Stall sauber bleibt und auch auf Dauer ein Maxiumum an Schutz bietet.

... eine Lastschrift fahren...

Wie heute morgen vorbereitet, habe ich gerade meine erste DTA-Datei mit zwei Testdatensätzen generiert, in der ich ausschließlich von meinen eigenen Konten Geld eingezogen habe.

War total Unproblematisch und hat garantiert funktioniert

Jetzt kann ich anfangen mich den wahrlich schwierigen Themen zu widmen - zum Beispiel das Formular für die Einzugsermächtigung (was ich leider nur offline anbieten werde )

Ich bereite gerade die Einführung des Lastschriftverfahren zum Begleichen von Hosting-Rechnungen vor.

In diesem Zusammenhang habe ich mich heute morgen per Telefon recht lange von meiner "Hausbank" beraten lassen und auch ein paar Fragen zu DTA-Dateien gestellt. In der Schnittstelle die ich mir mal zu Gemüte geführt habe, wurde so schön zwischen DEBIT und CREDIT unterschieden, allerdings war mir und auch meinem Gegenüber nicht ganz klar, was genau jetzt was definiert.

Nach ein wenig Wühlen im Code, stellte sich raus, dass CREDIT den Schlüssel G und DEBIT den Schlüssel L repräsentiert, wo die Vermutung nahe liegt, dass das eine für Gutschrift und das andere für Lastschrift steht - zumal DTA ein rein deutsches Format ist. Da wir uns aber nicht ganz sicher waren, ob es wirklich so ist, hat mein Gegenüber noch ein wenig nachgeforscht und mich nach nur 10 Minuten nochmal zurückgerufen - mit dem Ergebnis: Es stimmt natürlich!

Ganz nebenbei: Ich habe mich auch heute wieder das ganze Gespräch über wohl und ernst genommen gefühlt und die Beratung war sehr kompetent. Einer der vielen Gründe, warum meine Lieblingsbank auch in Zukunft knapp 450 KM weit weg sein wird...

Ich habe mich gerade eben mal ein wenig mit APC beschäftigt, nachdem ich feststellen musste, dass ich ihn vergangene Woche in einer (eigenen) Konfigurationsdatei ausversehen aktiviert hatte und er jede Menge Abstürze verursacht hat.

Mein letzter Stand der Dinge war, dass PHP + FastCGI + APC keine gute Wahl ist, doch nachdem ich eben ein wenig das SHM-Segment für APC erweitert habe, macht er momentan einen recht stabilen Eindruck. Ich bin mal gespannt, wie er sich schlägt, auf jeden Fall ist meine Testumgebung in der letzten Stunde nicht einmal gesegfaulted - was sehr a-typisch für meine APC-Erfahrungen ist

Gestern brauchte ein Kunde dringend ein paar Daten aus den Zugriffsprotokollen der Webserver. Genaueres dazu weiß ich nicht, aber es ging wohl um einen drohenden Rechtsstreit.

Ausschließlich für solch einen Fall halten wir die Protokolle noch eine Weile für den Kunden vor bis sie dann endgültig im Nirvana verschwinden. Ich kenne mindestens eine Hand voll Kunden, die da im Falle von Missbrauch sehr drauf angewiesen sein könnten.

Wie das nun mal bei mir so ist, hinterlässt alles seine Spuren bei mir im Kopf und ich fange an gedanklich damit zu arbeiten. Nicht zuletzt meinem Helferlein ist es zu verdanken, dass es hierbei gestern auch der Fall war - was aber in eine eher andere Richtung als der auslösende Fall ging.

Wir haben gestern über die Möglichkeiten nachgedacht, wie wir unseren Kunden eine "individuelle anonymisierung" ihrer Daten anbieten können ohne dabei wichtige bzw. für uns als Hoster relevante Informationen zu verlieren. Wenn alles gut läuft, können Kunden in ca. 2 - 3 Monaten im (dann neuen) Webserver-Editor ihre Domains anonymisieren.

Welch Fortschritt für den Datenschutz!