LL#14 – Liebes Logbuch…
Hinter den Kulissen von U8 wird weiterhin fleißig an Komponenten geschraubt, darunter “Marvin”: Das wird der Teil sein, der künftig den Stand der Accountkonfiguration hält, per API ansprechbar ist und daraus Configs für die Dienste auf den Hosts generiert. Inzwischen konnten hier auch erste Last-Tests gefahren werden, damit er auch mit mehreren zehntausend Accounts gut performt.
Unsere Social-Media-Aktivität verschiebt sich mehr und mehr zu Mastodon - nicht nur, weil wir selbst das gerne wollen, sondern auch, weil ihr, unsere Nautis, das gerne wollt. Der Großteil des Supports läuft schon dort, und initiative Tweets bekommen dort viel mehr Interaktionen. Nur gibt es ein Problem: Mit einem Team auf diesem Weg Support zu machen, bedingt fast zwingend, irgendeine Art von Tool einzusetzen, das sicherstellt, dass Anfragen nicht untergehen, dass sie zeitnah bearbeitet werden, und auch: dass sie nicht von mehreren bearbeitet werden. Derzeit setzen wir dafür SocialHub ein. Das leistete uns für Twitter gute Dienste; dessen Mastodon-Support ist aber dezent gesagt problembelastet - und außerdem ist es wirklich teuer. Wir wollen mit eurem Geld aber sorgsam umgehen, und da Twitter nun auch nicht nur das Logo der X.Org Foundation abgekupfert hat, sondern auch seinem API-Support ein Preisschild verpasst hat, bei dem wir mit den Ohren schlackern, gehen wir nun einen anderen Weg und schreiben uns kurzerhand unser eigenes Tool zur strukturierten Bearbeitung von Toots. Ein automatischer Import von Toots tut bereits, und sie können dann von Mitgliedern im Team übernommen (= für andere gesperrt), beantwortet und erledigt werden. Tatsächlich läuft sogar schon ein bisschen realer Support darüber, und wenn’s gut läuft, können wir damit eine externe Abhängigkeit zum Ende dieses Jahres loswerden…
Schon lustig, dass man sich manchmal selbst überholt. Ganz früher haben wir unser Monitoring mit Icinga 1 gemacht, und da auch durchaus nicht immer alles direkt hübsch und ordentlich gemacht, sondern hier und da auch ganz schön gefrickelt. Es war dann klar, dass wir auf Icinga 2 migrieren - und da haben wir schon viel neu gemacht, wobei einer der größten Schritte gewesen sein dürfte, eine Anbindung an unser Netbox hinzukriegen: So brauchte dann nur noch im Netbox eine VM als “U7” geflaggt zu werden, und schon hat sie automatisch entsprechendes Monitoring im Icinga 2 bekommen. Parallel dazu haben wir angefangen, die ganzen kruden Altlasten aus Icinga 1 in Icinga 2 zu migrieren, und dieser Prozess dauerte… lange. Nun gehen auch wir mit der Zeit, und das inzwischen auch nicht mehr so neue “new kid on the block” ist Prometheus mit Grafana und Alertmanager. Das eh nun schon sauber strukturierte U7-Monitoring darauf zu migrieren war eher easy, und so kam es zu der absurden Situation, dass wir Icinga 2 schon wieder abgeschafft haben - bevor alle Checks aus Icinga 1 vollständig dorthin integriert waren. Nun haben wir also ein moderndes Monitoring und für einige Altlasten noch ein Monitoring, das als seeehr legacy bezeichnet werden muss. Aber auch hier kam nun nochmal Fahrt rein und wir gehen mit der ganz groben Harke durch und implementieren mehr und mehr Basis-Checks für Legacy-Hosts in Prometheus, damit das Ende des alten Icinga 1 nun wirklich näherrückt.
Nachdem wir ja nun vor schon recht langer Zeit auch Kreditkartenzahlung via Stripe mit ins Portfolio der Zahlungsmethoden aufgenommen haben, sind wir nun erstmalig auch in etwas größerem Umfang mit den damit verbundenen Problemen in Kontakt gekommen, konkret mit einer ganzen Reihe von Aufladungen, die offenbar mit gestohlenen Kreditkarten getätigt worden sind (für Accounts, die dann fröhlich Spam und Phishing betrieben haben). Die Accounts selbst waren dann schnell dichtgemacht, aber nun geht’s eben auch damit weiter, dass es Disputes gab - und das ist ein Problem, denn ein Dispute kostet pauschal 20€, es sei denn, wir “beweisen”, dass die Kreditkartenzahlung legitim war - wie auch immer das gehen soll. In diesem Zuge fallen immer mehr Absonderlichkeiten auf: Wusstet ihr beispielsweise, dass ein Institut selbst dann, wenn der CVC-Code falsch eingegeben wurde, eine Zahlung dennoch aufgrund irgendwelcher Umstände als legitim durchgehen lassen kann? Wir jedenfalls wussten das nicht. Und wir haben absurde Situationen debuggen müssen, wo Geld wegen einer falschen CVC vom Institut an die zahlende Person zurückerstattet wurde - aber seitens Stripe war dabei nichts zu sehen; das Geld wurde uns nicht wieder weggenommen. (Inzwischen haben wir eine Regel gebaut, die eine Zahlung bei falscher CVC auf jeden Fall ablehnt, damit hier gar keine obskuren Fälle entstehen können.) Und dann wird’s aber ganz besonders lustig: Beispielsweise bezahlt jemand in US-Dollar, wir bekommen den Betrag in Euro, und wenn die Zahlung aber storniert/zurückgebucht wird, bekommt der Zahlende den identischen Betrag in US-Dollar zurück, was je nach Wechselkurs dafür sorgt, dass wir mehr zurückzahlen müssen als wir überhaupt bekommen haben - plus noch die Dispute-Gebühr obendrauf. Soll heißen, es gibt zumindest Teilaspekte an Kreditkartenzahlung, die wirklich keine Freude machen und denen sich eigentlich nur begegnen lässt, wenn man immer und überall 3D-Secure anfordert. Aber selbst das ist keine Garantie, denn manche Kartennetzwerke erlauben nicht mal dann, wenn 3D-Secure angefordert wurde, einen Übergang des Zahlungsrisikos vom Händler auf den Kunden… und das wurmt dann irgendwie doch ein bisschen. Aber auf jeden Fall: Immerhin ist es jetzt auf unserer Seite automatisiert, dass bei Disputes automatisch der betreffende Betrag - also ggf. ein anderer als der Aufladebetrag, wenn nicht in Euro aufgeladen wurde - wieder abgebucht wird und auch die Dispute-Gebühr dem Account in Rechnung gestellt wird. Das ist im Grund nur eine Formalität, denn Hand aufs Herz, wer seinen Account mit einer gestohlenen Kreditkarte auflädt, der hat damit ohnehin nur Schindluder getrieben und ist ihn schon deswegen los. ;-)
Soviel für heute, bis in Bälde!
J.