Aus dem Rechenzentrum

Einer meiner engeren Geschäftspartner klagte mir sein Leid: Eine seiner Mitarbeiterinnen verhält sich sowohl ihm als auch ihren Kollegen gegenüber ziemlich unangemessen, bemängelt stets die Fehler anderer, obwohl ihr selbst unterlaufen, lässt gemeinschaftliche Arbeiten (mal Geschirr in der Büroküche spülen) grundsätzlich liegen … und auf einen dezenten Rüffel ihres Chefs hin sagte sie frei heraus, ihr Verhältnis zu ihm sei so kumpelhaft, da könne sie ihn nicht wirklich als Autorität ansehen.

Ich habe das zunächst für ein ganz typisches Spannungsfeld gehalten: Niemand will einen herrischen Chef, der nur brüllt und maßregelt, aber wenn es gar zu kumpelhaft wird und Hierarchien zu sehr verschwimmen, ist das weder gut fürs Geschäft noch fürs persönliche Miteinander. Im Grunde geht es hier aber eher darum, dass der Respekt verlorengegangen scheint. Ich rede hier nicht von einem Respekt seinem Brötchengeber gegenüber, denn Respekt, der aus Hierarchien entsteht, ist Murks. Ich rede von dem Respekt, mit dem man jedem begegnen sollte: Dem Kunden genauso wie dem Kollegen genauso wie dem Chef. Mich muss niemand respektieren, weil ich ein Gehalt bezahle: Dafür bekomme ich bereits die Arbeitsleistung des jeweiligen Angestellten. Als Chef das letzte Wort zu haben ist für mich kein Privileg, das ich mir mit finanziellen Leistungen erkaufe, sondern eine Übereinkunft zum Vorteil beider: Schließlich muss ich bei Problemen letzten Endes nicht nur für meine Leistungen, sondern auch für die meiner Mitarbeiter den Kopf hinhalten. Das ist der Luxus eines Angestellten: Es läuft zwar nicht immer so, wie er es selber gerne hätte, aber er muss dafür auch nicht geradestehen. Solange man das Gros der Entscheidungen seines Chefs teilt, ist man deshalb ja nicht weniger am richtigen Platz.

Was bleibt: Respekt muss. Nicht wegen des Gelds, sondern weil Zusammenarbeit zwischen Arbeitgeber und Arbeitnehmer nun mal so funktioniert – nur so, wie ich meine. Ich sehe kein Problem darin, mit meinen Angestellten auch durchaus freundschaftliche Verhältnisse zu haben, ohne dabei Respekt einzubüßen. Letztlich liegt es ja auch am Verhalten eines Angestellten, ob der Chef „den Chef raushängen lassen“ muss, oder ob das eigene Verhalten dazu beiträgt, eine kollegiale Atmosphäre trotz formal ja bestehender Hierarchien zu begünstigen.

Wenn wie im Fall meines Geschäftspartners die Respektlosigkeit allerdings so weit geht, dass selbst die Kollegen nicht mehr mit der fraglichen Person in einem Büro sitzen wollen und noch dazu auch die Flapsigkeit Kunden gegenüber Überhand nimmt, dann ist Handeln gefragt. Sozialer Umgang mit anderen ist nicht optional, und selbst noch so umfangreiche Sachkenntnis im Job kann mangelnde Umgangsformen ausgleichen. Kein Unternehmen, egal wie groß, verträgt derart belastende Störfaktoren. Im konkreten Fall wird es wohl nur noch ein einziges deutliches Gespräch geben, an dessen Änderung dann entweder Einsicht stehen wird – oder eine Kündigung.

Schon erstaunlich, was man heutzutage so ganz ohne Aufforderung und vor allem auch ohne Altersverifikation aufs Handy geschickt bekommt. Um dieses Blog jugendfrei zu halten, graue ich mal lieber die nach meinem Empfinden pornografischen Passagen aus:

"********* Stewardess durchreist mit Inlandflügen die Republik-suche Unterschlupf! ***** *** zur Belohnung+****, ******, **********, ****! sms GEIL 1,49EUR/SMS"

So erhalten am 11. April 2008 von der Kurzwahl 83213 – übrigens eine Woche, nachdem ich bereits über eine vergleichbare SMS der selben Absenderkennung Beschwerde beim Betreiber der earnmobile GmbH, Dortmund, eingelegt habe. Mich erstaunt in der Tat, dass „in unserer heutigen, schnelllebigen Zeit“ (hält eigentlich irgendjemand ein Copyright auf diese abgedroschene Phrase?) ausgerechnet ein Telekommunikationsunternehmen es nicht für nötig hält, binnen einer Woche auch nur eine Sperrung vorzunehmen, geschweige denn eine Auskunft nach dem Bundesdatenschutzgesetz zu erteilen?

Nach der neuerlichen SMS hatte ich genug. Beschwerde beim Netzbetreiber mit dem Ziel der Abschaltung der Kurzwahl aufgrund des Verstoßes gegen den unterzeichneten Verhaltenskodex sowie Beschwerde an die Freiwillige Selbstkontrolle Multimedia-Diensteanbieter (FSM) wegen Verstoß gegen den Jugendschutz. So nicht, Freunde.

Wer browserbasiert viel mit Fotos (Flickr, Google Images, Facebook, MySpace, …) arbeitet und PicLens noch nicht kennt – unbedingt mal anschauen. Ja, ich weiß, nur Spielerei, aber selbst mich als nicht sonderlich Apple-affinem Typen (und dreimal darf man raten, woran die Optik erinnert) spricht die Ästhetik sehr an. Leider nur für Windows und MacOS X, aber diese Systeme sollen hier und da ja auch noch den einen oder anderen Nutzer haben.

Jetzt arbeiten wir schon seit vielen Jahren kaum noch mit traditionellen Passwörtern, sondern sind auf SSH-Keys umgestiegen. Im Rahmen eines Wartungsvertrags für einen dedizierten Server haben wir die vereinbarten Arbeiten durchgeführt, bis der Kunde verwundert fragte, wer uns denn das neue root-Passwort mitgeteilt habe. Nun ja: Niemand eben. Aus diesem Grund mal eine kleine Zusammenstellung von praktischen Links insbesondere für Windows-Nutzer (unter Linux und MacOS X ist die Nutzung von SSH ja ohnehin eher verbreitet):

Auf der Website von PuTTY bekommt man neben dem SSH-Client selbst auch einen Schlüsselgenerator für SSH-Key sowie einen optionalen SSH-Agent zum Cachen der entschlüsselten Keys. Kai Billen hat eine gute deutsche Anleitung für alles verfasst. Noch Fragen?

… eine E-Mail mit dem Betreff mit einem freundlichen „Bitte um Erklärung“ beginnen, um dann am Ende der Mail bei einem pöbelnden „Das ist ja echt das Letzte!“ anzukommen, als ob ich der Bitte um Erklärung bereits irgendwie mit einer für den Kunden nicht zufriedenstellenden Antwort nachgekommen sei? Letztlich hat der Kunde schlicht und einfach Daten aus einer statistischen Kurzdarstellung (die nebenbei mit einem Hinweis untertitelt ist, dass es sich nur um Schätzwerte handelt und nur die Abrechnung maßgeblich sei) missverstanden und wähnte sich direkt als Opfer eines Betrugs. Was sind das für Menschen?

In solchen Fällen bin ich mir dann nicht zu schade, unter meine (sachlich und freundlich gehaltene) Antwort noch einen knappen Hinweis zu setzen, dass ich doch freundlich darum bitte, von Pöbeleien künftig Abstand zu nehmen – zumindest, bevor die Fakten nicht auf dem Tisch liegen. Wer als Kunde wie ein König behandelt werden will, sollte auch die dafür notwendige Würde an den Tag legen.

Aus dem Support:

guten mrgen willi,meine telefonie ist gestern vollkommen abgestürzt,jetzt
wird die vollkommen neu aufgebaut und wenn die fertig ist,komme ich wieder
rein,würdest du bitte mal von der technik den weg zu mir überprüfen
lassen,denn das relais schliesst nicht wenn ich telefoniert habe ,wählt
während des telefonats irgendwo nochmal jemand und der von der telekom meint
das kommt von wo anders und das betrifft auch nur die leitung mit der ich
über den chat telef.aber das habe ich nicht gesagt,die anderen leitungen
sind in ordnung

Hat jemand eine Idee, was der oder die Fragende will? Irgendjemand? Hallo..?

Verbrauchern ist die Rechtslage in der Regel bekannt: Was man online bestellt, kann man innerhalb von 14 Tagen sang- und klanglos zurückgeben. So weit, so gut; insbesondere als Verbraucher begrüße ich diese Regelung, und als Anbieter kann man, so finde ich, damit leben.

Nun gibt es aber Leistungen, die exklusiv für einen Kunden erbracht werden: Insbesondere Domains. Die registrieren wir im Kundenauftrag, und dann sind sie eben da – unwiderruflich, denn der Registrierungsstelle gegenüber haben wir kein 14-tägiges Rückgaberecht, immerhin sind wir kein Verbraucher. Nun kommt es aber durchaus vor, dass ein Kunde sich bei der Domainbestellung „vertippt“ hat (ja, im Ernst!) und gerne eine andere Domain möchte. Als Anbieter ist man da erstmal angeschmiert, denn rein rechtlich gesehen hat der Kunde ja jedes Recht, die bestellte Domain einfach ohne Angabe von Gründen zurückzugeben. Als Anbieter bleibt man hingegen auf den Kosten sitzen – eine unbefriedigende Situation, wie sicher auch jeder Verbraucher nachvollziehen kann, den im Unterschied zu einem Laserdrucker, einem Schreibtischstuhl oder einem Eimer Farbe kann der Anbieter den zurückgegebenen Artikel ja nicht einfach jemand anderem andrehen.

Mein Kunde selfHOST setzt daher schon seit längerem auf eine ganz pragmatische Lösung: Entweder, der Kunde verzichtet ausdrücklich auf sein Widerrufsrecht (in dem er einen lehrreichen Text liest und sein Einverständnis mit einem Klick auf einen deutlich beschrifteten Button kundtut), oder – ja, im Ernst, die Domainbestellung wird 14 Tage lang in der Warteschleife gehalten und erst dann getätigt, wenn die gesetzliche Rückgabefrist verstrichen ist. Der Kunde wird über das Vorgehen informiert und hat während der 14 Tage jederzeit die Möglichkeit, zu sagen: Ja, ich verzichte auf mein Widerrufsrecht; mach’s mir sofort.

Nun hat Ludwig dazu noch den durchaus interessanten Law Podcasting aufgetan, der sich in einer Folge mit genau dieser Frage beschäftigt. Anhören!

Zugegeben: Wir arbeiten zwar in einem gehobenen Hosting-Segment, allerdings nicht im Enterprise- oder Hochsicherheitsbereich. Und schließlich geht es hier um Maschinen, die zwar unserer Kontrolle unterstehen, die aber nicht uns gehören, so dass letztlich der Kundenwunsch den Ausschlag gibt, was zu tun ist. Im konkreten Fall ging es um eine Maschine, deren root-Zugang kompromittiert wurde. Das ist extrem selten, immerhin pflegen wir die unserer Betreuung unterstehenden Maschinen gut, so dass Sicherheitslücken in als root laufenden Diensten so gut wie nie zum Tragen kommen, bevor das Update eingespielt ist – aber „so gut wie nie“ ist eben nicht „nie“.

Dem Kundenwunsch entsprechend sollte die Maschine allerdings nicht vollständig geplättet und neu aufgesetzt werden, sondern (nach Schließung der Sicherheitslücke) lediglich gesäubert werden. Das ist an sich auch unproblematisch, da wir Prüfsummen aller ausführbaren Programme erstellen und somit Kompromittierungen im Allgemeinen gut erkennen können, sofern sie nicht so weit gehen, dass Kernelmodule installiert werden, die ein Rootkit vollständig verbergen. Wir kennen in einem solchen Fall aber letztlich auch unsere Grenzen, sprich, wir sind Webhoster und keine Security-Leute. Dieses Feld überlassen wir lieber Leuten, die sich damit auskennen, so wie wir uns in unseren Dingen gut auskennen. Nun, wie gesagt, die Maschine wurde nach Kundenwunsch und nach unserem besten Wissen und Gewissen gesäubert und ging kurz darauf wieder in Betrieb.

Warum dann allerdings die Maschine wenige Tage später erneut kompromittiert wurde, war uns zunächst ein Rätsel, zumal sich an der installierten Software keine Lücken mehr zeigten.

Die Lösung: Bei der vorherigen Kompromittierung hatten die Angreifer dem Systemuser games ein Passwort gegeben – und sich ganz trivial eingeloggt. Und aus eben diesem Grund sollte man Maschinen nach einer root-Kompromittierung im Regelfall immer plätten: Es ist praktisch ausgeschlossen, alles zu finden, was ein Angreifer installiert hat, egal wie gewissenhaft man vorgeht. Zugegeben: Ein Passwort auf einem User, der normalerweise keins hat (und damit auch keinen Login), war erschreckend trivial. Wir schämen uns – und setzen’s auf unsere Liste von Dingen, die nach einer root-Kompromittierung zu prüfen sind, sollte ein Neuaufsetzen der Maschine keine Option sein.

Für Berechnungen mit Datumsangaben setze ich üblicherweise auf Date::Calc. Es bekommt zwei Array aus je drei Werten (Jahr, Monat, Tag) als Parameter und liefert die Differenz ebenfalls als Array. Nun würde ich damit gerne berechnen, wie alt jemand ist. Da jemand, der 29 Jahre, 4 Monate und 15 Tage alt ist, effektiv nun mal einfach 29 ist, empfehlen entsprechenderweise auch etliche Foreneinträge, für die Berechnung des Alters doch einfach Delta_YMD zu benutzen und nur die Angabe der Jahre zu verwenden. Auf geht’s:

my @age = Delta_YMD( 1978, 12, 17, 2008, 04, 02 );
print join( ", ", @age ) . "\n";

Das Ergebnis überrascht:

30, -8, -15

Für Date::Calc bin ich also bereits über die Bioklippe gesprungen, obwohl es bis dahin noch mehrere Monate sind. Dafür wird ein interessantes Konzept negativer Monate und Tage eingesetzt. Na dankeschön, aus den jeweils drei Werten eines Array einfach dreimal die Differenz zu bilden, hätte ich auch ohne extra Modul hinbekommen.

Eine kurze Recherche im Netz brachte dann diesen Wrapper für Delta_YMD() zutage, mit dem sich das Problem lösen lässt. Vielleicht könnte auch das (nicht offiziell in CPAN enthaltene) Date::Calc::Age helfen. Hab’s aber noch nicht getestet.

Mit einem Geschäftspartner war für heute morgen eine Softwareumstellung angesetzt, mit genauem Zeitpunkt terminiert. Das betreffende System sollte angehalten werden, ich sollte einen Snapshot des Datenbestands erstellen, per Mail zur Weiterverarbeitung an den Partner senden und kurz darauf zum Reimport zurückerhalten.

Ich war pünktlich, und von daher mehr als verwundert, als der Kunde mich nach einer halben Stunde später anrief und fragte, wo denn nun endlich meine Mail bleiben würde, man würde dort händeringend darauf warten.

Einen Blick ins Maillogfile später lag die Antwort auf der Hand:

2008-03-31 11:14:06.883709500 new msg 7193385
2008-03-31 11:14:06.883715500 info msg 7193385: bytes 91721 from <{ABSENDER_ENTFERNT}> qp 5085 uid 501

2008-03-31 11:14:07.997494500 starting delivery 366420: msg 7193385 to remote {EMPFÄNGER_ENTFERNT}
2008-03-31 11:14:09.316835500 delivery 366420: deferral: {IP_ENTFERNT} does not like recipient./Remote host said: 451 4.7.1 Greylisting in action, please come back later/Giving up on {IP_ENTFERNT}./

2008-03-31 11:21:27.322965500 starting delivery 366796: msg 7193385 to remote {EMPFÄNGER_ENTFERNT}
2008-03-31 11:21:27.882470500 delivery 366796: deferral: {IP_ENTFERNT} does not like recipient./Remote host said: 451 4.7.1 Greylisting in action, please come back later/Giving up on {IP_ENTFERNT}./

Ich tendiere inzwischen immer mehr zu der Ansicht: Es sind gar nicht die Spammer, die das E-Mail-System kaputtmachen. Es sind wir selbst mit unseren bescheuerten „Gegenmaßnahmen“, die das Medium E-Mail immer unzuverlässiger werden lassen.