Technik

... 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!

Es gibt ja die tollsten Musik-Player da draußen, einige davon mag ich auch sehr gerne - z.B. amaroK....

Aber meistens scheitert es daran, dass all diese Programme "Client-Only" sind und der Spass verloren geht, wenn man sie auf dem Laptop haben will und dementsprechend entweder Kabel hinter sich herziehen muss oder auf diese wirklich kleinen blechernden Lautsprecher angewiesen ist.

Heute habe ich mal einen wirklich alten Laptop rausgekramt (Pentium I, 266 MHz, 32 MB Ram, 4,8 GB HDD) das 4 Jahre alte Linux gebootet, ihn unters Sofa gestellt und die Lautsprecher an die Soundkarte gesteckt. Kurz noch schnell

cat *.mp3 | ssh laptop-ip "mpg123 -"

auf meinem Gerät ausgeführt und kabellos Musik genossen. Primitiv, aber tut genau so wie ich es mag...

Ich habe in den letzten Tagen ein paar (interne) Webseiten von einem Webserver auf einen anderen Umgezogen.

Das ist jetzt nichts besonderes und geht mir auch immer leichter von der Hand, jedoch hat sich dieses Mal eine längst verworfene Idee wieder an die Oberfläche gegraben. Vor ca. anderthalb Jahren meinte mein Helferlein mal, ob man nicht Umzüge von Webpräsenzen automatisieren kann. Darmals war meine Antwort dazu noch ein klares "Nein", doch so langsam verfestigt sich in meinem Kopf ein Plan, wie man so einen Umzug zumindest intern bewerkstelligen kann...

... eigentlich kein großes Ding und richtig leicht zu realisieren... Wie konnte ich das nur jemals verneinen?! :hmm:

Weitergesponnen wäre es noch toll Präsenzen von extern nach intern (und leider Gottes bzw. meinetwegen auch umgekehrt) umziehen zu können. Das hingegen ist noch weite Zukunftsmusik. Zumindest erstere Idee werde ich wohl die Tage mal angehen...

Heute Abend bin ich mal ein wenig über die Webserver gestreift und habe ein wenig aufgeräumt...

Es ist schon erstaunlich, wieviele "Karteileichen" sich in einem Jahr (oder seitdem ich das letzte Mal geputzt habe) ergeben. Zum Teil erstaunlich, was ich da aus den letzten Ecken der Festplatten und Datenbanken gezogen habe... Bei einigen Sachen habe ich mich echt gefragt, warum das noch so wie vom Kunden gewünscht funktioniert hat.

... wobei letzteres natürlich die Hauptsache ist - es muss funktionieren. Dennoch tut ein wenig Aufräumen niemandem weh und auch das Gefühl, wenn man nachher via SSH über die Webserver läuft ist ein ganz anderes... Ganz frisch und aufgeräumt - kurzum: GUT!

Nachdem mir mein Helferlein schon monatelang mit Anonymisierungsdiensten wie z.B. TOR in den Ohren lag, meldete sich vorgestern total unabhängig davon ein Kunde zu Wort und versuchte mit TOR als Dienstleistung schmackhaft zu machen.

Nun, wir haben das ganze ein wenig durchgesprochen und vorerst ad acta gelegt. Ich glaube nicht, dass sich damit Geld verdienen lässt geschweige denn, dass sich die daraus resultierenden Kosten decken lassen - was aber nicht heißen soll, dass die Geschichte vom Tisch ist.

Spielereien, wie das stellen eines Exit-Nodes kommen sowieso nicht in Frage. Allerhöchstens mal "Man-In-The-Middle" spielen um die Idee ein wenig zu fördern - die ja eigentlich gar nicht mal schlecht wäre, würde es nicht diese finsteren Individuen geben, die meinen sowas ausnutzen zu müssen (was natürlich nur eine Minderheit ist, aber auch Minderheiten darf man nicht vergessen )

Nun ja, das Resultat des vorgestrigen Abends war dann, dass ich meinem Helferlein ein wenig Traffic (im dreistelligen GB-Bereich) zur Verfügung gestellt habe und er sich jetzt mal ganz unverbindlich austoben darf. Allein schon die daraus entstehende Erfahrung ist ja schon was wert

Jetzt hast Du schon so lange bei mir gewohnt, den Tag mit mir verbracht, bist gewachsen, hast Dich weiterentwickelt und bist durch höhen und tiefen gegangen. Doch nun ist Deine Zeit gekommen.

Ich packe Dich in eine kleine Kiste aus Pappe. Nicht zu eng sollst Du es haben, aber weich gepolstert sollst Du sein. Schon bald gehst Du auf Deine zweite große Reise, denn Du bist alt genug Dein Elternhaus zu verlassen. Deine Schonfrist ist vorbei, es ist an der Zeit in die weite Welt hinaus zu laufen, sich einen Job und eine eigene Wohnung zu suchen.

Eine Freundin wirst Du da draußen wohl nicht finden - zumindest vorerst nicht - aber einen guten Freund, der schon sehnsüchtig auf Dich wartet.

Lieber Leonardo, ich wünsche Dir alles Gute und viel Erfolg für Dein zukünftiges Webserver-Leben!

Sooo... Jetzt nur noch das Klebeband suchen und das Päckchen zu machen

Es war mal wieder eine dieser nächtlichen Aktionen...

Gestern Abend habe ich mich hingesetzt, den Editor aufgemacht und ein Programm geschrieben, das Shell spielt. Also nicht direkt eine Shell, sondern vielmehr ein Programm, das alles bereit stellt (stellen soll), was man so benötigt um SCP bzw. SFTP zu betreiben.

Dateien via SCP empfangen geht bereits. Heute wirds wohl noch lernen Dateien zu senden und dann schau ich mir noch SFTP an...

Grund dafür ist, dass alle mir bekannten SCP/SFTP-Implementationen nicht wirklich in unser Sicherheitskonzept passen und/oder einen recht großen und dreckigen Implementationsaufwand mit sich bringen - also im ganzen nichts, worauf ich bereit wäre mich einzulassen.

Ach ja: Weil ich es schon Ewigkeiten nicht mehr getan habe, habe ich das Programm gleich mal in Ada 95 implementiert - wie schnell man so eine Sprache vergessen kann...

Ich arbeite gerade an einer neuen Version des "internen" Backups...

Die Grundidee war die Backups der Server ein wenig "chaotischer" zu streuen. Momentan werden die Backups auf einem einzelnen Server abgelegt, was zumindest in Sachen Backups ein "Single Point of Failure" darstellt. Das System abschaffen werde ich bestimmt nicht, aber die Idee, dass die Server auch unter sich ihre Backups austauschen, finde ich gar nicht mal so schlecht.

Es ist quasi ein Peer-to-peer-Backup-System, bei dem jeder Webserver sich einen benachbartes System aussucht und auch dort seine Backup-Daten ablegt. Speicherplatz ist sowieso mehr als genug vorhanden, warum den dann nicht für ein wenig redundanz benutzen?

Ob ich den Gedanken wirklich eines Tages in die Realität umsetzen werde steht allerdings noch in den Sternen. Immerhin könnte auch mal ein Webserver kompromittiert werden und dann hat der Angreifer gleich die Daten von (mindestens) zwei Maschinen :hmm: Wobei selbiges natürlich auch für den Backupserver gilt...

Wer kennt die Frage nicht? "Wo bin ich gerade eigentlich?" und das dazu gehörige "Was muss ich tun um ins Internet zu kommen?".

Mit der Frage an sich habe ich mich schon vor mehr als 5 Jahren beschäftigt und sie beschäftigt mich heute immernoch - aber schon lange nicht mehr so sehr wie darmals, eigentlich nur noch ein kleines bisschen. Das konkrete Problem war (und ist) wenn man mehrere Arbeitsplätze hat, bzw. sich in mehreren Netzwerken rumtreibt, muss es dort nicht immer einen Dienst wie DHCP geben oder er tut nicht immer das was er soll, sodass man fast dazu genötigt wird Hand anzulegen.

Ich behelfe mir da immer mit einem kleinen Bash-Skript, der versucht das Netzwerk zu "erraten" und das Interface dementsprechend konfiguriert. Gerade eben hab ich das Tool mal Probehalber in unser SVN geschickt und auf einem Server aktiviert. Bisher funktioniert alles sehr gut... Ich bin mal gespannt, wie sich das Tool schlägt, wenn die Maschine demnächst ins Rechenzentrum wandert - wäre zu toll, wenn die Theorie auch in der Praxis tut...

Hinter verschlossenen Türen läuft gerade zusammen mit ein paar Kunden der Beta-Test eines neuen Produktes, was den Plänen zur Folge am 1. April kommen soll (nein, das ist kein Scherz ).

Die Authentifikation für den neuen Dienst geschieht über die normalen Benutzerkonten und mittels einer SSL-Zertifikat-Infrastruktur, für die ich quasi einzig und allein mal diesen Skript geschrieben habe. Nun ist jedes Programm nur maximal so klug wie die Summe derer, die es geschrieben haben, und derer, die es bedienen. Zumindest letzteres war bei mir wohl zum scheitern verdammt.

Nachdem ich die ersten Zertifikate fehlerhaft ausgestellt hatte und diese gestern ungültig wurden - was ich dank meines Helferleins glücklicherweise letzte Woche schon bemerkt habe - sollte es am Freitag neue Zertifikate für die Tester geben.

Gab es auch! Und eigentlich waren sie perfekt... Alles stimmte - bis auf dass die gewählte Struktur mit dem eingesetzten Programm inkompatibel war... :eek:
Damn it!

In der Nacht von Freitag auf Samstag hat es dann aber doch noch funktioniert und mittlerweile können die Zertifikate bequem via Kundeninterface und SSL-verschlüsselt heruntergeladen werden. (Für die Neugierigen: Suchen hat keinen Zweck )

... aber es ist schon traurig, dass ich doch wirklich 3 Anläufe gebraucht habe... :hmm:

Mein Helferlein ist mitunter wahrlich paranoid. aber das ist nichtmals schlecht. Es ist immer sehr gut eine Mischung verschiedener Charaktere im Unternehmen zu haben. Ich bin der jenige, der mit neuen Ideen nach vorne prescht, er ist der jenige, der mich ggf. ausbremst oder meine Ideen mit ein paar Sicherheitsrelevanten Features ergänzt.

So sitzen wir - selten, aber es kommt vor - abende lang bei dem einen oder anderen Glas Bier zusammen und tüffteln Features aus oder denken einfach über schon vorhandenes nach. Vor ein paar Wochen war es in etwa (ganz genau erinnere ich mich dank des Alkohols wohl nicht mehr) folgendes:

Was ist der Nachteil an IMAP-Mailboxen?

Richtig! Mails liegen in der Regel unverschlüsselt auf dem Server. An und für sich ist das ja in Ordnung - solange die Maschine nicht kompromittiert wird oder der Admin einen persönlichen Greul gegen den Mailbox-Inhaber hat (okay, letzteres würde ich für unseren Laden mal ausschließen, aber es passt!)

An eine Lösung dieses "Problemes" hat wahrscheinlich noch kaum jemand einen Gedanken verschwendet. Mein Gedanke war ja mal ausgehende Mails automatisch via GPG (meinetwegen auch S/MIME) zu verschlüsseln - aber auf die Idee zu kommen eingehende Mails mit dem Public Key des Empfängers zu bearbeiten - dafür brauche ich schon mein Helferlein und eine Menge Bier.

Es macht auf jeden Fall Sinn, denn ein Maximum an Sicherheit ist niemals falsch und als Geek-Feature nicht zu verachten. Ich bin mal gespannt ob das Feedback gibt :hmm:

Da ich mittlerweile recht häufig bei Starbucks sitze, arbeite und nebenbei Kaffee trinke, habe ich das ganze gestern mal mit einer statischen Internet-IP honoriert...

So hieß es heute morgen das erste Mal beim Login auf einem der Server:

~ #> ssh [...]
tiggersWelt.net SSH. Welcome!
Password:
Last login: Thu Mar  8 10:46:32 2007 from starbucks.[...].tiggersystems.info
Have a lot of fun...
~ #>

Das schöne ist ja, dass ich die IP-Adresse überall mit hin nehmen kann, sie ist eigentlich nur durch ihren Hostnamen an Starbucks gebunden...