Archiv der Kategorie: Restmüll

Alles, was sonst nicht passt

Otto Waalkes – Grund zum feiern, Lyrics in Englisch

Da aktuell durch ein für viele wohl eher unverständliches Video das Interesse am Klassiker „Grund zum feiern“ von „Otto Waalkes“ geweckt wurde wollte ich die Bedeutung der „weisen Worte“ auch den Mitbürgern, welche nur englisch sprechen, nicht vorenthalten. Da das Netz keine brauchbare Übersetzung lieferte dann halt hier…

Currently the classic „Grund zum feiern“ by „Otto Waalkes“ is getting some interes because of a for most people somewhat incomprehensible video.  I liked to share these wise words also with people not speaking German but could not find a descend translation – so here it is…

  • Faber Krönung (sparkling wine)
  • Deinhard Lila (sparkling wine)
  • Grappa (pomace brandy)
  • Calvados (apple brandy)
  • tequila
  • Asbach Uralt (brandy)
  • Spätburgunder (Pinot Noir, red wine)
  • Vermouth (fortified wine) and
  • Pernod (distilled anise beverage).
  • Poire Williams (brandy)
  • Dujardin (Cognac)
  • Hennessy (Cognac)
  • Rémy Martin (Cognac)
  • Fernet Branca (bitter herbal liqueur)
  • Underberg (digestif bitter)
  • Port Wine (fortified wine) and
  • Bordeaux (wine)
  • Johnnie Walker (whiskey)
  • Jägermeister (liquor)
  • Amaretto (liquor)
  • Keller Geister (sparkling wine)
  • Scharlachberg (wine) and
  • Doppelkorn (liquor).
  • The whole thing now again from the start.
  • We have reason to celebrate.
  • No one can still run but we can still booze.
  • We have reason to celebrate.
  • Even if we feel like vomiting, bring the next bucket.
  • Bommerlunder (Akvavit)
  • Ballentine’s (scotch whiskey)
  • today it’s all the same to us.
  • Pear brandy and
  • cider
  • We really pour in everything.

 

  • whiskey sweet and
  • whiskey sour
  • main thing is we’re getting more drunk
  • Rammazotti (amaro)
  • Ratzeputz (Schnaps) and
  • a bottle of rum
  • Gin (spirit)
  • Campari (liqueur)
  • Grand Marnier (liqueur)
  • finally the skull hurts
  • With Doornkaat (liquor) and
  • Mariacron (brandy)
  • into delirium.
  • Klosterfrau Melissengeist (kind of high-alcohol-medicine)
  • or however the stuff is called
  • Kölnisch Wasser (aka 4711, perfume)
  • Pitralon (aftershave)
  • we do not burp it, we are vomiting it already.
  • We have reasons to puke
  • even if it erodes the guts
  • it spends us warmth
  • We have reason to celebrate
  • Our death-bed will:
  • Even higher alcohol level.

SSD-Killer: Another one bites the dust

Es ist wieder so weit: Ich habe die nächste Cache-SSD meines Speichersystems getötet. Nach etwas über einem Jahr (375 Tage) hat nun eine Toshiba THNSNJ128GCSU das Zeitliche gesegnet und damit den Wert der Vorherigen Mushkin Chronos sogar unterboten. Etwas überraschend, da Toshiba eher im Business-Umfeld aktiv ist und Mushkin eher ins Low-Cost-Umfeld zielt. Interessanterweise sind Raw_Read_Error_Rate und Reallocated_Sector_Ct beide auf 0, lediglich der nur spärlich dokumentierte Wert 169 (Total bad block count?) meldet FAILING_NOW – nachdem er sich von 0 auf 1 änderte, also komplett ohne Ankündigung. Positiv: Immerhin blockiert die SSD nur Schreibzugriffe, das Lesen/Sichern der bestehenden Daten ist also noch problemlos möglich.

Nächster Kandidat ist eine 850 Evo – mal schauen, ob diese das nächste Jahr durchhält.

CTS-Eventim: Offenes WLAN? Dann verkaufen wir nichts.

In öffentlichen WLAN surfen ist praktisch: Man kann unterwegs schnell noch $Dinge erledigen oder Wartezeiten produktiv nutzen. Da an diesen Einrichtungen jedoch viele Menschen gleichzeitig den selben Anschluss nutzen haben viele Anbieter solche Einrichtungen genauer im Blick: Um automatisierten Missbrauch zu vermeiden müssen häufig CAPTCHAS ausgefüllt werden (hallo, CloudFlare) oder die Nutzung von Seitenteilen (oder auch der ganzen Seite) ist nur noch mit einem bestehenden Benutzerkonto möglich. Diese Gängeleien sind ärgerlich, aber dazu werde ich später noch einen Artikel schreiben.

Wie oben schon geschrieben: Gängeleien. Man ist genervt, löst das CAPTCHA oder meldet sich an und weiter geht es. Bisher. Im ewigen Kampf Verkäufer gegen mögliche Kunden setzt der „Eintrittskartenverkauf“ CTS-Eventim einen drauf: Deren Webseite liefert bei der Nutzung von Diensten wie öffentlichen WLANs – oder auch einigen Internetprovidern mit DSLite – nur ein formloses „Access Denied“. Keine Erklärung, kein CAPTCHA, kein Weiterkommen.

Da dies kaum im Sinne des Verkäufers sein konnte kontaktierte ich den Betreiber. Mal davon abgesehen, dass eine Erklärung wohl keinem weh täte sollte ich als registrierter Kunde, der in der Vergangenheit schon öfter bestellte, doch mein Geld loswerden können, oder?

Weit gefehlt: Um Fairness zu waren müsse man diese Blockade beibehalten. Es können ja Bots kommen.

wir verfolgen eine Politik der Gerechtigkeit für unsere Kunden: Der gerechten Verteilung von Tickets sowie der Sicherheit unserer Portale räumen wir höchste Priorität ein. Daher möchten wir Reservierungs- und Buchungsbots, die für gewöhnlich Anonymisierungsdienste nutzen, von unseren Portalen fern halten. Wenn Sie also Ticketreservierungen und Buchungen ohne Aufwand und Störung durchführen möchten, bitten wir Sie, keine Anonymisierungsdienste dafür zu verwenden. Wir danken für Ihr Verständnis.

Warum man dann jedoch alle ausschließt und nicht nur versucht Bots zu verhindern bleibt wohl ein Geheimnis. Da ich die  verallgemeinerung und damit generelle Gleichstellung von gemeinsam genutzten Internetanschlüssen und „bösen“ Anonymisierungsdiensten aber ohnehin sehr zweifelhaft finde werde ich zukünftige Bestellungen an andere Dienstleister vergeben.

Outlook Anywhere & Co über Apache als Reverse Proxy

Microsoft Exchange ist ein in kleinen und mittelständischen Firmen verbreiteter Mail/Groupware-Server, welcher sich durch grafische Verwaltbarkeit und gute Integration mit den Office-Produkten des Herstellers auszeichnet. Aus Sicherheitsgründen kann es Sinn machen diesen Server nicht direkt ins Internet zu setzen, sondern die eingehenden Anfragen über ein vorgeschaltetes System zumindest grob filtern zu lassen. Ähnliches hatte ich für Webseiten bereits im Artikel „Apache als Reverse Proxy“ vorgestellt.

Exchange geht natürlich wieder eigene Wege – es werden viele Hardcoded-Pfade und ungewöhnliche Protokolltricks genutzt, welche entsprechend umgesetzt werden müssen. Hier gehe ich von einem Exchange-Server aus, welcher bereits vollständig für Zugriffe eingerichtet ist. Als Reverse Proxy kommt Apache 2.4.x zum Einsatz, Clients sind verschiedene Mobilgeräte (Android, iOS, Windows Phone) sowie Outlook 2013. Extern erreichbar ist der Proxy unter „mail.adlerweb.info„, der interne Server ist als „exchange1.lan.adlerweb.info“ bekannt.

Erster Schritt: OWA & Co.

OWA (Outlook Web Access) und OMA (Outlook Mobile Access) sind HTTP-basierte Browseroberflächen für den Postfachzugriff, vergleichbar mit den üblichen Webmailern vieler Anbieter. Da diese im Prinzip nur Webseiten sind ist die Konfiguration schnell erledigt. Zu beachten ist, dass Apache bei den URLs auf Groß- und Kleinschreibung achtet, wer also technikferne Benutzer hat sollte ggf. passend vorsorgen. Mit diesen Zeilen ist der Abruf per Browser schon mal möglich.

Zwieiter Schritt: Sonstiges

Es folgen weitere HTTP-Resourcen, welche keine spezielle Konfiguration benötigen. Dies umfasst z.B. öffentliche Ressourcen oder die Webseite zur Kennwortänderung

Schritt 3: Auto-Discovery

Outlook nutzt eine fixe URL um Hinweise zur Selbstkonfiguration zu erhalten. Wer dies nutzt kann auch hier eine einfache HTTP-Weiterleitung bemühen:

Schritt 4: Active Sync

Mobilgeräte verwenden häufig das „ActiveSync“-Protokoll. Im Prinzip auch HTTP, allerdings können einige Anforderungen den Exchange-Server ins Schwitzen bringen. Um hier den Apache nicht ungeduldig werden zu lassen wird der Timeout auf 5 Minuten erhöht.

Schritt 5: RPC

Zuletzt folgt „das Monster“: Outlook selbst. Der Outlook-Client ist in der Lage seine RPC-Pakete über HTTP zu tunneln. Leider hält sich Microsoft hier (wie üblich) nicht an die gängigen Standards. Normalerweise wird eine HTTP-Verbindung geöffnet, der Request übermittelt und die Antwort empfangen. Outlook hingegen baut gleich 2 Verbindungen auf – auf einer wird gesagt „ich habe 1GB Daten“, dann werden 100 Byte als Anfrage gesendet und auf der Zweiten die Antwort erwartet. Da die 100 Byte weit von den angekündigten 1GB entfernt sind und die Info, dass nur ein Teil gesendet wird, seitens Outlook fehlt, wartet der Apache brav auf den Rest, Outlook sendet aber nichts ohne Antwort. Deadlock. Timeout.

Apache selbst geht hier den Weg namens „Pech gehabt„. Da die Microsoft-Methode viel Angriffsfläche bietet und nicht den Standards entspricht ist eine Nutzung offiziell nicht vorgesehen. Auch scheint Microsoft diese Standardverletzung patentiert zu haben, wer also etwas passendes Implementiert könnte ein böses Erwachen erleben. Ist man trotzdem nicht abgeschreckt und möchte Outlook weiterhin nutzen muss ein Addon Abhilfe schaffen: mod_proxy_msrpc. Für Arch Linux ist es jetzt im aktuellen AUR zu finden, alle Anderen können es mit wenigen Zeilen bauen:

Der Zielpfad der letzten Zeile kann sich je nach Distro unterscheiden. Debian/Ubuntu und Gentoo nutzen /usr/lib/apache2/modules/. In der httpd.conf muss analog der anderen Module auch dieses geladen werden:

Im VHost selbst leiten wir den virtuellen RPC-Ordner passend weiter und weisen das neue Modul an den Protokollmurks zuzulassen:

Schritt 6: Achja, TLS

Noch ein Hinweis für alle, die auf moderne Verschlüsselung setzen: Vergesst es. Outlook 2013 unterstützt lediglich TLS1.0 sowie SHA1, entsprechend alte Algorithmen müssen also erlaubt sein.

Quellen:

Der Hacker und die sieben Admins

Es war einmal eine Gruppe von Admins, welche sich morgens um 11 nach langer Nacht zum Ruhen ins Büro begaben. Sie setzten sich und sahen gleich, dass jemand da gewesen war. Der Erste fing an zu fragen:

„Wer hat auf meinem Program Files geschrieben?“

Der Zweite fragte:

„Wer hat von meiner password.txt gelesen?“

Der Dritte fragte.

„Wer hat mein CD-Laufwerk geöffnet?“

Der Vierte:

„Wer hat meinen Desktophintergrund geändert?“

Der Fünfte:

„Wer hat meinen Admin-Konto genutzt?“

Der Sechste:

„Wer hat meinen Postausgang gefüllt?“

und der Siebente fragte:

„Wer hat das Trollface gedruckt?“

Wie die Admins also gefragt hatten, sahen sie sich nach ihren Gehaltszahlungen um, und fragten:

„Wer hat sich auf unseren Banken angemeldet?“

bis auf den Siebenten, der fragte nicht so, sondern:

„Wo ist mein Geld?“,

denn da bediente sich der Hacker.

So, neuer Kernel fertig – weiter im Programm ;)

Linux als iSCSI-Target

iSCSI ermöglicht es entfernte Festplatten über Ethernet an einen Rechner anzubinden. Hierbei kümmert sich nicht wie bei CIFS/NFS/… der Zielrechner um die Dateiverwaltung, sondern der Client behandelt die Festplatte wie eine lokal eingebaute – incl. Partitionierung, Dateisystem & Co. Ethernet ist hierbei zwar nicht die schnellste Lösung, jedoch erheblich günstiger und flexibler als professionelle Lösungen wie Fibre-Channel.

Ich nutze ein System auf Basis von Arch Linux, welches eine Partition an einen anderern Rechner bereitstellen soll. Im iSCSI-Jargon nennt sich dies „Target“, der Client „Initiator“. Zur Verwaltung unter Arch nutze ich die Free-Branch des LIO targetcli, dies ist im AUR zu finden.

Im ersten Schritt starten wir das iSCSI-System. Hierbei werden die nötigen Module geladen und ggf. zuvor definierte Geräte exportiert.

Nun starten wir das Management-Tool. Es stellt eine eigene Konsole zur Verfügung. Erst wird die Festplatte mit einem internen Namen verknüpft. Ich nutze hier zur besseren Übersicht den Partitionsnamen

Im Anschluss erstellen wir eine „Target Portal Group“ (=Konfigurationsspeicher für das iSCSI-Target) samt passendem „IQN“ (=iSCSI-Adresse). Letztere wird im nächsten Schritt benötigt, mit ls kann man bei allen Schritten die aktuelle Konfiguration anzeigen lassen.

nun registrieren wir die zuvor bekanntgemachte Festplatte als LUN (=logischer Speicher)

Nun erstellen wir das Portal selbst (=legen einen Server an), erlauben die Adresse des Initiators, welche man am Client nachschlagen kann, und legen Benutzername und Kennwort fest

Zuletzt wird die Konfiguration gespeichert. Das iSCSI-Target ist nun nutzbar.

Sinnvollerweise sollta man target noch mit einem „systemctl enable target“ beim Systemstart automatisch starten lassen.

Des Admins 10 Gebote

Ich bin root, dein Admin, der dir den Rechner eingerichtet hat.

  1. Du sollst neben mir keine anderen Admins haben. Du sollst dir kein Bild von jenem machen, was der Admin an Tätigkeiten ausübt. Du sollst nicht zweifeln an seinen Entscheidungen, denn das Firmennetz des Allmächtigen ist nicht dein Heimrechner. Du sollst dich nicht vor anderen Admins niederwerfen und dich nicht verpflichten, ihnen deinen Addressbuch freizugeben.
  2. Du sollst den Namen des roots, deines Admins, nicht missbrauchen; denn der root lässt den nicht ungestraft, der seinen Namen missbraucht.
  3. Gedenke des Sabbats: Halte ihn heilig. Sechs Tage darfst du schaffen und jede Arbeit tun. Der siebte Tag ist ein Ruhetag, denn dort wird der Admin seine Updates einspielen und möchte nicht gestört werden.
  4. Ehre dine Gruppenrichtlinie und deinen Virenscanner, damit du lange arbeitest an dem Rechner, den der root, dein Admin, dir gibt.
  5. Du sollst nicht rooten.
  6. Du sollst nicht die Richtlinie brechen.
  7. Du sollst nicht Raubkopieren.
  8. Du sollst nicht falsch gegen deinen Nächsten aussagen, denn das Log wird jene strafen.
  9. Du sollst nicht nach dem Rechner deines Nächsten verlangen, nach seinem Handy oder seinem Tablet, seiner Tastatur oder seinem Monitor oder nach irgendetwas, das deinem Nächsten gehört, denn der Admin hat auch so schon genug zu tun und weiß um deine Klagen.
    So achte Allzeit auf diese Gebote und erfreue dich an der Arbeit, welche du durch des Admins Schöpfung erledigen kannst. Ist sie erledigt so ziehe hinaus aus der Knechtschaft des Büros, kehre zurück zu Heim und Familie, wende dich deinen Privatgeräten zu und habe Spaß am Gerät. Enter.

    (Ist gcc jetzt fertig? Noch mehr blöde Ideen aus dem Chat vertrag ich nicht ;))

[Linux] Der Zufall und warum Cryptofunktionen manchmal ewig dauern

Wer schon einmal auf einem Embedded-System wie Router oder einer VM versucht hat einen geheimen Schlüssel unter Linux zu erzeugen wird das kennen: Es dauert ewig. Schuld daran ist nicht nur die meist spartanische Leistung des Prozessors, sondern auch die Art, mit welcher Linux seine Zufallsdaten erzeugt.

Wie Zufällig darf es denn sein?

Holen wir mal etwas aus: Viele Verschlüsselungen benötigen – beispielsweise zur Erstellung von Schlüsseln – Zufallswerte. Leider ist ein PC mit seinen An-Aus recht vorhersagbar und das genaue Gegenteil von Zufall. Um trotzdem verschlüsseln zu können kommen Pseudozufallsgeneratoren zum Einsatz. Diese verwenden meist schlecht vorhersagbare Quellen um eine hohe Qualität der Zufallszahlen zu erreichen – also eine Zahl, deren Herleitung man möglichst später nicht mehr nachvollziehen kann. Quelle kann Beispielsweise das Rauschen eines Gerätes, vergleichbar mit einem zu laut eingestellten Eingangs einer Soundkarte, sein.

Von vollen und von leeren Pools

Unter Linux kümmert sich der Kernel selbst um die Sammlung dieses Zufalls, diesen verwaltet er im Entropiepool. Üblicherweise werden maximal 4096 Bit vorgehalten, den aktuellen Füllstand kann man unter /proc/sys/kernel/random/entropy_avail einsehen. Um Zufallszahlen zu erhalten gibt es nun zwei Geräte mit den selben Aufgaben, aber wichtigen Unterschieden:

/dev/random stellt die Daten aus dem Pool zur Verfügung und dabei sicher, dass die Daten eine gewisse Qualität haben. Das bedeutet allerdings auch, dass – wenn die 4096bit aufgebraucht sind – das Lesen so lange pausiert wird, bis neue Zufallswerte vorliegen. Das ist Ideal für Verschlüsselungen und andere kritische Bereiche in denen sensible Daten behandelt werden sollen. Gleichzeitig heißt es auch, dass Systeme mit geringer Nutzung entsprechend lange zum Lesen benötigen. Häufig wird empfohlen für Fesplatten- oder Netzlast zu sorgen oder Maus und Tastatur intensiv zu nutzen um zusätzlichen Zufall zu generieren, ob dies tatsächlich auch für den Linux RNG hilft oder nur einen Placeboeffekt darstellt ist mir nicht bekannt.

/dev/urandom stellt die selben Daten bereit, blockiert allerdings nicht. Hierbei macht man sich eine Eigenheit eines Zufalls zu Nutze: Die Zufallswerte sind nicht wie ein Treibstoff, der durch Nutzung verbrannt wird, sondern eher das geschriebene Wort eines Füllers. Ist die Quelle des Zufalls langsam erschöpft, also die Tinte fast leer, sieht das Geschriebene nicht mehr schön aus, ist aber immer noch deutlich besser als Nichts. Je länger man jedoch mit leerer Patrone schreibt, desto schlechter wird das Ergenis. Aber zurück: Ist der Pool also leer werden die übrigen Daten nochmal in die Mangel genommen und neu gemischt um zumindest irgendwas zu haben. Ganz nach dem Motto: Egal wie, es kommt etwas raus. Die Qualität der herauspurzelnden Werte ist – wie oben schon angerissen – nicht garantiert, vor allem bei leerem Pool und wenig Aktivität steigt die Gefahr, dass die Werte nachvollziehbar werden. Für wichtige Crypto sollte man urandom entsprechend nicht benutzen, reicht aber „etwas Zufall“ aus – beispielsweise um Werte für ein Spiel oder das testen einer Festplatte zu erhalten – ist man hier richtig und kann viel Zeit sparen. Auch kann es als „letzter Ausweg“ genutzt werden, wenn Zeit wichtiger ist als Sicherheit – oder soll der Kunde des Onlineshops mehrere Minuten beim Laden warten, weil grade der Pool leer ist?

Programmdiktatur

Während man als Programmierer die Wahl zwischen den Qualitäten hat ist man als Nutzer meist den Entscheidungen des Programmierers ausgeliefert. Dies macht auch meist Sinn, beispielsweise wenn das Cryptoprotokoll auf dem blockierenden /dev/random beharrt. Arbeitet man jedoch beispielsweise auf einem Testsystem und muss hunderte Schlüssel erzeugen, die ohnehin nur unwichtige Testdaten verarbeiten, wäre ein umschalten auf /dev/urandom hilfreich. Sicher, man könnte den Symlink verbiegen, aber wirklich schön ist das nicht.

Mittelweg Füllhilfen

Eine Lösung kann ein zusätzlicher Zufallsgenerator sein, welcher als weitere Quelle die Füllung des Entropiepools beschleunigen kann. Eine Möglichkeit ist es – wenn vorhanden – die Hardware zu bemühen. Viele aktuelle Rechner haben einen Zusallsgenerator eingebaut, beispielsweise unterstützen Intel-CPUs mit DRNG entsprechende funktionen oder auch das vielfach verbaute TPM-Modul kann hierzu verwendet werden. Nutzer von QEmu können mit virtio_rng auch virtuelle Rechner versorgen. Nutzbar machen lässt sich dies über den rngd, welcher als Dienst gestartet die Vermittlung übernimmt und meist in einem Paket namens rng-tools o.Ä. zu finden ist. Die Gefahr, dass die Hardwareimplementierung eine Lücke hat besteht natürlich immer, denn diese Quellen sind meist fest verdrahtet und Lücken im Algorithmus können nicht „weggepatched“ werden. Auch liegen die Details der Implementierung häufig nicht offen, sodass die Qualität der Zahlen nicht prüfbar ist. Um hier zumindest ein grundsätzliches Fallnetz zu ziehen wird rngd in der Standardeinstellung nur anteilmäßig zur Generierung der Zahlen genutzt.

Steht keine Hardware zur Verfügung, beispielsweise in vielen VM-Umgebungen, ist es auch in Software möglich. Der bekannteste Vertreter ist hierbei haveged. Hierbei wird sich zu nutze gemacht, dass der Prozessor intern einige Operationen durchführt, welche nicht vorhersagbar erscheinen. Der Vorteil: Diese Quelle ist auf jedem Rechner verfügbar – vom normalen PC bis hin zum kleinsten Router. Problem: Nicht jeder Prozessor ist „gleich zufällig“, ob die Qualität also hoch ist lässt sich nur schwer bestimmen.

Pest oder Cholera?

Welchen Weg man wählt, dass muss man für sich selbst entscheiden. Lange Wartezeiten ergeben zwar meist eine höhere Sicherheit, aber in der heutigen Zeit zählen all zu oft andere Werte. Viele Nutzer sind nicht bereit ihen Komfort für Sicherheit zu opfern. Ein Hardware-RNG kann – wenn vorhanden und man der Quelle genug vertraut – eine große Hilfe sein. Auch Software ist als Ausweg eine Option. Am Ende lässt sich Zufall jedoch nie testen, die Qualität der einzelnene Lösungen ist also nur schwer zu bewerten. Am Ende ist es meist eine gute Idee mehrere Quellen zu nutzen und so den Zufall des Zufalls nicht ganz dem Zufall zu überlassen.

Liveblog: Telefonlos

Es ist mal wieder soweit: Telefon weg. Nun bin ich in der glücklichen Situation noch einen echten Telefonanschluss zu besitzen, entsprechend sind solche Ausfälle eher selten. Also schauen wir uns diesen Sonderfall mal an.

  • 13:10 – Das Monitoring vermeldet eine Störung der DSL-Verbindung.  Kein sonderliches Problem, da sie nur als Backup fungiert. Lediglich ein paar Statistikseiten sind extern nicht erreichbar.
  • 14:50 – Vor Ort. DSL-Modem hat keinen Sync. Reboot tut gut, alles scheint wieder in Betrieb.
  • 18:30 – Eingehendes Ticket: Festnetztelefonie gestört. Great.
  • 18:45 – erste Prüfung: ISDN hat kein Sync, NTBA zeigt keine LED
  • Weitere Prüfung: Keine Speisespannung am Übergabepunkt – oder kurz: Ich wars nicht ;)
  • 19:15 – Eröffnung eines Tickets bei der DTAG. Zumindest nach mehreren Versuchen. Spracheingabe an Telefoncomputern über ländliche Mobilfunknetze funktioniert nicht wirklich.
  • Info der Hotline: Mehrere Störungen im Umfeld, scheint eine Störung des Verteilers zu sein
  • 20:00 – Rückmeldung der DTAG: Techniker wird Samstag zwischen 8:00 und 16:00 sich die Vermittlungsstelle anschauen
  • Nachts – Irgendwann muss die Spannung wieder angekommen sein
  • 11:00 – Techniker vor Ort. Funktioniert natürlich alles. Nochmal durchmessen, alles OK. Als Bonus gibt es für die in die Jahre gekommene Netzabschlussdose eine neue mit Prüfabschluss.
  • 11:01 – TK-Anlage wieder angeklemmt, eingehendes Telefonat. Timing.

Fassen wir zusammen: Auch  heute noch ist die Telekom in der Lage Störungen schnell und ohne Umwege zu beseitigen. Schade, dass es nicht immer so funktioniert.

Info: GAD wechselt Zertifikate

Kunden der GAD (also vieler Volks- und Raiffeisenbank) erhalten seit einigen Tagen bei der Nutzung von FinTS (also Banking-Software) die Meldung, dass man sich wegen eines ominösen Updates beim Softwareanbieter nach einem Update erkundigen soll. Auf Nachfrage heißt es, dass lediglich die Sicherheitszertifikate erneuert werden – FinTS wird weiter in Version 3.0 betrieben.