So soll Software *nicht* sein

Mein Mailarchivierungssystem ist seit dem 19. Dezember offline, das ist aber auch eben erst aufgefallen als ich „mal schnell“ eine bestimmte EMail aus dem Archiv benötigte.

Die Software für die Mailarchivierung ist a) gut b) als „pro“-Version recht teuer c) defacto auf einer ziemlich lazy zusammengestellter Ansammlung von unterschiedlichen Tools gegründet.

Nach viel suchen habe ich die Logfiles gefunden (nein, sie waren nicht in /var/log) und die sahen in etwa so aus:


Dec 31, 2015 3:29:53 AM org.apache.tomcat.util.digester.Digester fatalError

SEVERE: Parse Fatal Error at line 1 column 1: Premature end of file.
org.xml.sax.SAXParseException: Premature end of file.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1663)
at org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:402)
at org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:103)
at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source)
at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
at rg.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:113)
at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:137)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:109)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:81)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:703)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)

Dec 31, 2015 3:29:53 AM org.apache.naming.NamingContext lookup
WARNING: Unexpected exception resolving reference
org.xml.sax.SAXParseException: Premature end of file.
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1663)
at org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:402)
at org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:103)
at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source)
at org.apache.naming.NamingContext.lookup(NamingContext.java:793)
at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
at org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:113)
at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:137)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:109)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:81)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:703)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Dec 31, 2015 3:29:53 AM org.apache.catalina.mbeans.GlobalResourcesLifecycleListener createMBeans
SEVERE: Exception processing Global JNDI Resources
javax.naming.NamingException: Premature end of file.
at org.apache.naming.NamingContext.lookup(NamingContext.java:805)
at org.apache.naming.NamingContext.lookup(NamingContext.java:140)
at org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:113)
at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:137)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:109)
at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:81)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:703)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Aus dem Stackdump entnehme ich, dass der Programmierer an irgendeiner Stelle eine XML-Datei lesen möchte und das nicht funktionierte.

Es gibt an dieser Stelle drei Megafails:

  • erstens verlässt sich der Programmierer blind darauf, dass die Datei auswertbar ist und hat keine Vorsorge für den Fall getroffen, dass irgendwas nicht funktioniert.
  • zweitens haben sich die Programmierer des Appservers blind darauf verlassen, dass der Programmierer „in der höheren Ebene“ dafür sorgt, dass die fehlerhafte Datei mit Pfad und Name ins Logfile kommt
  • drittens haben solche kompletten Stacktraces nur was im Debugmode im Logfile zu suchen – entweder kommt eine ordentliche Fehlermeldung der Sorte „hier genau klemmts“ oder man kann den Kram auf den Einzeiler „keine Ahnung was los ist“ reduzieren.

    Den Fehler habe ich durch Induktion gefunden: Da weder Programm noch Konfigurationsdateien seit 4 Jahren angefasst wurden kann nur eine Datei kaputt sein, die Programmintern erzeugt wurde. Typischerweise dann, wenn Tool „A“ eine XML-Datei für Tool „B“ bereitstellt (eigentlich eine recht altväterliche Vorgehensweise, aber ….)

    Und da intern viel mit XML-Dateien gearbeitet wird, musste ich nur nach *.xml|*.XML an den Stellen suchen, wo die Software sich gewöhnlich verewigt.

    Und Tatsache – da war eine dieser „temporär erzeugten“ Zwischendateien. Im Source wird das wahrscheinlich so ausgesehen haben: „Wenns die Zwischendatei schon gibt, dann mache weiter“.

    Dumm ist nur, dass diese Zwischendatei leer war – erfahrene Programmierer haben an kritischen Stellen *immer* Prüfungen drin wie zb. „ist die Datei grösser als 0 Byte“ und „Ist die Datei grundsätzlich Parsbar“

  • Der Weihnachtsgruss…

    Meine Frau hat einen Weihnachtsgruss ins E-Mail Postfach bekommen.

    Als erfahrene Anwenderin kam es ihr komisch vor, dass in der Email irgendwas von „Download, um anzuschauen“ stand und hat es mir weitergeleitet.

    „To:“ = eine meiner Frau unbekannte Adresse.

    Der Anhang war eine *.docx in der ein Macro den voreingestellten Browser aufrief um einen Link auf drive.google.com aufzurufen.

    Ich habe den Link in einer besonders abgeschotteten Umgebung aufgerufen um festzustellen, dass da nur ein Foto des „gesichtsmässig bekannten Absenders“ dranhängt. Ob da jetzt Dritte noch irgendeinen Exploit eingebaut haben, will ich gar nicht wissen – habe die Mail hier und bei meiner Frau gelöscht.

    Mir ist es allerdings ein Rätsel, wie es die Computerunerfahrene Absenderin geschafft hat eine Email zu erzeugen die als Anhang eine Word-Datei hat die einen automatisch ausgeführten Link enthält mit dem ein Bild von Google-Drive heruntergeladen werden soll.

    VoIP über alles – „Erleben, was verbindet.“

    Der Grund, warum ich Donnerstag vergebens auf den Techniker gewartet habe: jemand kluges hat herausgefunden dass die Digitalisierungsbox Standard nicht die Ursache sein kann sondern die dahinterhängende ISDN Telefonanlage.

    Nach gut 14 Tagen ein erstaunliches Ergebnis, das habe ich am Abend des Donnerstags auch herausgefunden und dem Kunden eine Mail geschickt mal die Kabel raus-rein sowie das AEG-Prinzip (Ausschalten-Einschalten-Geht) auf die alte TK-Anlage anzuwenden.

    Und siehe da – ich bekam am morgen zu einer frühen Unzeit den Anruf, dass wieder alles geht und die Info, dass in 30min ein Techniker kommt. Nämlich jemand, der die Telefonanlage flickt.

    Da will ich nicht nachstehen und mal flugs Dusche, Frühstück und Hinfahrt in einem (wie ich das alles in 30min bei 40min Anfahrtszeit geschafft habe bleibt Firmengeheimnis).

    Am gelösten Problem konnte der Kollege Techniker nix machen, aber er schob die analoge Frankiermaschine auf den verbleibenden ISDN-Kanal mit dem Ergebnis dass es auch nicht besser wurde.

    Aber er klemmte sich gehörig dahinter, diskutierte mit dem Frankiermaschinenherstellersupport und das Ergebnis war… es kam per Mail eine Software mit der man die Frankiermaschine über USB an einen PC ankoten kann.

    Das hätte ich vor 4 Wochen gebraucht und nicht jetzt erst.

    Bis auf paar Kleinigkeiten (nach dem Softwareupdate der heiligen „Digitalisierungsbox Standard“ wurde bei der Umsetzung der eingehenden Anrufe mal wieder nicht die ONKZ rausgefiltert) lief erstmal alles glatt.

    Paar Tage später stellte sich heraus, dass sich die Digbox bei IPv6 als DNS-Server im Netz vordrängelte. Grössere Konfusion, nix ging mehr. Konnte aber auch behoben werden.

    Bleibt nur noch die Umleitung der zweiten Rufnummer des Kunden auf eine Least-Cost-Nummer die in der alten TK-Anlage so seltsam konfiguriert wurde dass sie nur unter bestimmten Umständen und eher zufällig wirksam wurde. Keiner weiss woher diese Umleitung kommt, aber ein ziemlich genervter Callcentermitarbeiter bei Vodafone erklärte wie man das los wird: Schriftliche Kündigung bei Vodafone mit der Bitte um eine schriftliche Kündigungsbestätigung die der Kunde dann nach Bonn zur Telekom schicken muss um die Rufumleitung zu Vodafone zu kappen.

    Ich wette ne Kiste Bier, dass der umgekehrte Weg (also Einstieg in das Least-Cost-Routing) einfacher war.

    VoIP über alles – nun wirds lustig …

    Leider kann die Frankiermaschine immer noch nicht stabilen Kontakt zur Heimat aufnehmen. Anscheinend mag sie nicht die Umsetzung „Analog -> Octopus -> ISDN -> VoIP“.„…

    Das war am Donnerstag 10. September 2015.

    Der Kunde wollte den Techniker am folgenden Freitag nochmal bitten vorbeizuschauen – aber dann kam irgendwas dort dazwischen und am Montag, 14. September ging das Telefon nicht mehr.

    Sofort Störung gemeldet, das sieht dann so aus:
    stoerung1Wer warum storniert hat ist nicht ersichtlich – der Kunde war es jedenfalls nicht.

    Die nächste Meldung (7 Tage hinter der Entstörfrist gemäss T-Com AGB) war anscheinend eine Problemverlagerung:
    stoerung2

    „Spass“ hat der Kunde auf jeden Fall: seine eingehenden Anrufe landen wieder auf dem Mobiltelefon der Seniorchefin und das ist ein Prepaid-Vertrag. Raustelefonieren über die Anlage geht auch nicht, also wird auch hier das Mobiltelefon genutzt – alle 3 Tage wird die Karte neu mit 50 EUR aufgeladen.

    So.. und was macht unsere Störung in der Zwischenzeit? 2 Tage nach Meldung hat man die Wunderbox „Digitalisierungsbox Standard“ als Übeltäter ausgemacht und die Sache am 24.09 mit einem Besuch erledigt.
    stoerung3
    Dieser Eintrag entspringt allerdings dem Wunschdenken der Deutschen Telekom, in Wirklichkeit passierte nämlich was ganz anderes: Frau N., die gute Seele des Kunden und Allroundtalent, telefonierte sich die Finger wund und wurde von Pontius zu Pilatus verbunden bis ihr jemand den Tip gab, in Bonn bei der Beschwerdestelle anzurufen (immer noch mit dem Prepaid Handy!) die das alles brav aufgenommen hatten und die ultimative Lösung fand – nämlich den Kunden wieder an die Störungsstelle weiterzuverbinden. Nach 10 Tagen Gefechten mit endlosen Warteschleifen und überforderten Callcenter-Mitarbeitern verlagerte sich das Duell „Kunde vs. T-Com“ in die E-Mail.

    Kann alles nicht so schwierig sein“ dachte ich mir, als mir der Kunde sein Leid klagte.

    Also mal die Rufnummer aus der Email (sie endet mit „…0060“) angerufen.

    Technischer Service der Deutschen Telekom Frankfurt, welche Rufnummer? Ah – ja, wir vereinbaren sofort einen Termin. Wann passts? Morgen ab 10 Uhr? Prima – der Techniker kommt Donnerstag (24.09.2015) zwischen 10 und 14 Uhr vorbei. Er soll Sie vorher anrufen? Gerne, geben Sie mir die Rufnummer. Schönen Tag noch!

    Also meine Termine am Donnertag umgeschichtet und an diesem Tag brav gewartet, dass sich der Techniker meldet.

    10 Uhr … nichts.
    11 Uhr … nichts.
    12 Uhr … auch nichts.
    13 Uhr … der Kollege ist bestimmt nun in der Mittagspause
    14 Uhr … nichts.

    Also nochmal die gleiche Nummer angerufen und plötzlich landete ich nicht mehr in beim Technischen Service in Frankfurt sondern bei einem Kollegen in Würzburg der nur Lancom-Router macht. Der war zwar auch verblüfft dass ich dort am Vortag jemanden am Rohr hatte Termine macht – aber er war sehr Hilfsbereit und hat den vermissten Techniker per E-Mail eskaliert.

    Jedenfalls wurde die Störung am gleichen Tag um 17.38 Uhr als „beseitigt – viel Spaß mit unseren Produkten!“ abgehakt.

    Telefon? Geht immer noch nicht.

    Recht verwunderlich finde ich die letzte Meldung im Auftragssystem:
    stoerung4

    „Störung“ vom 17.09 (also letzte Woche Donnerstag), letzte „Änderung“ zeitgleich mit der „Erledigung“ der Störung der Digitalisierungsbox Standard – nun ist die Octopus (die alte ISDN-Telefonanlage) der Störenfried.

    Nachdem ich vorhin selber auf die Gesamtkonfiguration geschaut habe, bin ich zum gleichen Resultat gekommen: Die Anrufe via VoIP kommen an, finden aber an der Oktopus keinen „Abnehmer“. Vermutlich ist da irgendein Kabel lose oder die Anlage hat sich weggehangen (wir erinnern uns: vor der Störung war ein Telekom-Techniker am werkeln).

    Irritierend finde ich nur: Wie hat das die Telekom herausgefunden? Dazu müssten die selber auf der „Digitalisierungsbox Standard“ gewesen sein oder (im einfachsten Fall) ins Logfile der Box geschaut haben wärend ein Anruf aufgebaut wurde.

    Da ist was nicht ganz Koscher…

    Doch – ist es, doch dazu mehr im nächsten Beitrag.

    VoIP über alles – 2 Monate später…

    Gleicher Kunde, immer noch ein Drama.

    Was passierte am Tag „X“ der Umstellung?

    Ich habe vorher nochmal alle Unterlagen gesichtet, die irgendwie mit der Telekom zu tun haben und fehlendes nachgefordert, recherchiert, ausprobiert – denn der Vertriebler der DTAG hat mir recht deutlich zu verstehen gegeben, dass eine Rückabwicklung nicht passieren wird.

    Um 11 Uhr rief mich der Inhaber via Mobiltelefon an und sprach „Jetzt geht gar nichts mehr“. Kein Internet, keine Telefonie, keine Alarmanlage…..

    Also erstmal im Kundencenter der Telekom eingeloggt und alle Rufnummern auf das Mobiltelefon der Seniorchefin umgeleitet welches nun das zentrale Telefon war.

    Danach den Kasten mit der Telefonverkabelung geöffnet. Problem bei der Sache: IP-Krams und Telefonie sind zwar nur 50cm voneinander entfernt, aber die Wand dazwischen wurde um die bestehende Infrastruktur gezimmert sodass es nicht möglich war mal eben bestehende ISDN-Kabel wegzumachen und durch Ethernetkabel zu ersetzen. Zum Glück hab ich im Fundus genügend lange Strippen herumliegen um drumherum zu verlegen – mein Kunde muss jetzt halt mal mit einem Kabelverhau und Panzertape auf dem Boden leben.

    Nachdem alles vorbereitet war, habe ich die ominöse „Telekom Standard Digitalisierungsbox “ ausgepackt, grob verkabelt und mich im Webinterface der Kiste eingeloggt. Gemäss Beschreibung soll die Umstellung von ISDN auf VoIP ganz einfach sein: Die Zauberkiste weiss zu welchem Kunden sie gehört und zieht sich alle Daten für die Migration aus dem Netz herunter. Links einfach in die DSL-Buchse und rechts den S0-Ausgang mit der bestehenden ISDN-Telefonanlage verbinden – fertig.

    In der Praxis hat sich der Setup-Assistent erstmal verheddert und mich mit meinen Sorgen alleine gelassen.

    Erika Fuchs legte Daniel Düsentrieb schon die Worte „Dem Ingeniör ist nichts zu schwör“ in den Mund – also Ärmel hochkrempeln und mal vom „Assistenten“ in den „Experten-Modus“ geschaltet. Und da sah man recht deutlich, dass die „Standard Digitalisierungsbox“ ihre Wurzeln in einer „Bianca“ von VEB Funkwerk (später Funkwerk AG, nun „bintec elmeg GmbH“ hat). Ich liebe diese Router weil sie einfach alles können – aber wenn man nur alle paar Jahre damit zu tun hat, wirds schwierig.

    Aber die Telekom lässt mich ja nicht alleine. Den Vertriebler um Hilfe angebettelt der völlig entnervt sagte „Vor einer Woche kann kein Techniker bei Ihnen sein – wir haben schon tausende Kunden umgestellt und es gab noch NIEEEEE Probleme!“. Zum Glück steht im Beipackzettel „Zu den Risiken und Nebenwirkungen befragen sie unter der Rufnummer 08xxx einen Kollegen der Ihnen bei der Einrichtung hilft.“

    Per Try&Error hab ich es zumindest geschafft, mit der Anlage beim Kunden rauszutelefonieren zu können. Hotline angerufen, 20min warten, endlich. „Hallo Kollegin! Ich bin beim gemeinsamen Kunden ’sowieso GmbH‘ und komme mit der ‚Standard Digitalisierungsbox‘ nicht zurecht. Ob Sie mir kurz helfen könnten?“ „Ja gerne – um welches Gerät geht es denn?“ „Standard Digitalisierungsbox“ „Und das haben Sie von uns bekommen?“ „Ja – steht fett ‚Telekom‘ drauf“.

    Nach weiteren 15min „Welche Lämpchen blinken? Nein – das Gerät kenne ich nicht, ich frage mal die Kollegen“ musste die Dame passen – eine „Standard Digitalisierungsbox“ ist im Konzern nicht bekannt (auch nicht bei den Kollegen, welche den Installationsflyer erstellt haben – da ist von einem Speedport-Router die Rede).

    Also Schlachtplan erstellt: Internet geht, die Standleitung zum Mutterkonzern ist weg, Telefonie ausgehend ok aber eingehend nur über das Mobiltelefon der Seniorchefin. Mal ne Nacht drüber schlafen und schauen…

    Am Abend habe ich noch versucht, eine Anleitung für diese ominöse Box zu bekommen. Die ist zwar vorhanden, scheint aber von einer bestehenden Bintec-Box kopiert zu sein und endet genau dort wo es spannend ist – nämlich beim Übergang von VoIP auf eine Telekom Octopus F.

    Am nächsten Tag mal bei Clara-Net angerufen, die sind nämlich für die Standleitung zum Konzern zuständig. Dort wurde ich verdammt herzlich empfangen und getröstet, weil die nämlich ständig mit den Folgen der DTAG-Vertriebsversprechen „Umstellung auf VoIP ist ganz einfach“ zu tun haben. Die Alternativen waren: 1) gemeinsames „frickeln“ bis man wieder den alten Zustand einer Shared-Line (DSL Telekom + ClaraNet Standleitung über eine Leitung) hinbekommt oder einfach 10 EUR mehr im Monat zahlen und die ClaraNet Leitung über einen separaten DSL-Anschluss der Telekom laufen zu lassen. Ich habe mal für den Kunden für letzteres Entschieden, also Papierkrieg wiedermal.

    Die Wunderbox der Telekom tats aber immer noch nicht so recht. Zwar habe ich mich über Nacht nochmal in VoIP eingelesen, aber irgendwie finde ich für die Beschreibungen aus dem Internet keine Entsprechung in dieser Kiste.

    Alles von vorne. Die „Standard Digitalisierungsbox“ komplett zurückgesetzt, Assistent neu gestartet, wieder nichts. Nochmal das Logging neu konfiguriert damit ich eine Chance habe zu sehen was da läuft. Ewig auf die Logfiles gestarrt. Rufe kommen rein, landen aber nicht auf der Anlage.

    Raus aus dem Büro mal eine rauchen. Plötzlich klingelt das Telefon bei der Auftragsannahme – irgendein Anrufer ist durchgekommen. Aber warum? Mitarbeiterin befragt – das war einer aus dem Ort. Schnell zum Rechner gerannt – leider ist das Event schon aus den Logfiles herausgefallen.

    Die Mitarbeiter gebeten, mal Bekannte im Ort anzurufen damit die mal in der Firma anrufen – klappt. Schnell das Laptop aufgeklappt eine griechische Kollegin gebeten hier anzurufen – klappt auch. Heureka! Da ist irgendwas mit der Rufnummernumsetzung verkehrt.

    Nach Mühsamen durchklicken aller Menuepunkte und aller Untermenuepunkte sowie ihrer Karteikartenreiter habe ich herausgefunden, dass der Setup-Assistent dort versäumte die in fast allen Fällen übermittelte „Ortsnetzkennziffer“ (also die Ortsvorwahl) abzuschneiden. Damit gab es keine Übereinstimmung mit der MSN (also die eigentliche Rufnummer der Firma).

    So langsam habe ich verstanden, was die Kollegen Entwickler da an den verschiedensten Menuepunkten haben wollen. Die Syntax für einen weiteren Eintrag habe ich mehr erraten als gewusst, die Dokus gaben dazu auch nur spärlich was her – aber danach funktionierte es.

    Alles dokumentiert und einen Reset der Box durchgeführt um das nochmal zu validieren – wäre schade wenn gut 20 Stunden Arbeit in den Orkus gehen.

    Nach einer kleinen Ewigkeit des „Warten, Bangen, Hoffen“ konnte ich auf die „Standard Digitalisierungsbox“ wieder zugreifen – und die hat auch gleich ein Update der Firmware angefordert. Danach wurde der Setup-Assistent gestartet, der auf dem Niveau eines Kindergarten-Quiz paar Angaben wollte. Am Ende gabs einen Neustart und alles funktionierte.

    Jeder andere wäre jetztanimalische Schreie des Wahnsinns ausstossend nackt durch die Wetterau gelaufen, ich habs einfach nur mit einem Achselzucken quittiert dass mich die Deutsche Telekom wieder 2 Tage meines Lebens gekostet hat.

    Nach ’ner Woche kam noch die Standleitung von ClaraNet. Ich kann mich an den Termin gar nicht mehr so recht erinnern. Techniker-Kollege von der Telekom hat ne Dose dafür gesetzt, gemessen. Vorkonfigurierten Router von ClaraNet angeschlossen, hat sich alles problemlos integriert und die Standleitung war wieder da. Mir blieb „nur“ noch die Aufgabe, die ganzen neuen Router und Anschlüsse in den recht schmalen Platz an der Wand im Chefbüro hinter der Abdeckung zu integrieren – aber das klappte auch.

    Was nach 2 Monaten übergeblieben ist: eine teure, neu angeschaffte Frankiermaschine die leider noch Analog „nach hause telefonieren“ muss um das Guthaben aufzuladen. Das ist mir leider erst sehr spät nach der Umstellaktion zugetragen worden und somit darf ich über endlose Warteschleifen bei der Telekom einen Techniker bestellen – welcher mittlerweile da war (Stand gestern) und auch alles brav angeschlossen hat.

    Leider kann die Frankiermaschine immer noch nicht stabilen Kontakt zur Heimat aufnehmen. Anscheinend mag sie nicht die Umsetzung „Analog -> Octopus -> ISDN -> VoIP“.

    Da muss wohl nochmal jemand ran – und zwar jemand von der Telekom und das auch auf Kulanz, sonst werde ich Böse.

    PS: Meine eigene Firma ist da besser dran. Wir sind hier in einer Ecke, wo es die Telekom nicht so eilig hat mit der Umstellung von ISDN auf VoIP und wir hängen bereits am Breitband von M-Net. Nur noch paar Rechner hier laufen bewusst über die Telekom und wenn ich eine Idee habe, welche Telefonkonsole ich für VoIP hier ins Büro stelle ist die Telekom komplett weg.

    Denn M-Net ist (noch….) ein vergleichsweise kleines Unternehmen und für mich wesentlich kuscheliger im Fall wenns mal klemmt.

    VoIP über alles

    Jede Telefonbude möchte im Moment so schnell wie möglich ISDN und das alte Analoge Telefon loswerden und durch moderne VoIP-Anschlüsse ersetzen.

    Im Prinzip geht die Migration für Anwender schmerzfrei über die Bühne und ist sogar von Vorteil: statt Strippengewirr steht nun ein Router in der Ecke, an den sich Laptop, Tablet und Smartphone via WLAN und die Telefone über DECT verbinden.

    Schwieriger wird es, wenn beim Anwender „heftigst“ ISDN genutzt wird. Also mehrere NTBAs um mehrere Anrufe entgegen zu nehmen (oder herauszutelefonieren), spezielle Router für DSL-Standleitungen, ISDN-Telefonanlagen, Alarmanlagen signalisieren melden sich auch gerne über den D-Kanal von ISDN und so weiter.

    Um ein länger existierendes Unternehmen auf VOIP umzustellen ist natürlich erstmal eine Bestandsaufnahme zu machen. Dazu eignen sich bevorzugt alle Eingangsrechnungen, die irgendwie nach Telekommunikationsunternehmen „riechen“. So manche „Das ist nur Handy!“-Rechnung hat sich als ausgewachsene Standleitung entpuppt und die „keine Ahnung, was das für eine Rufnummer ist“ wurde für Fernwartung gebraucht.

    Aber die Strategen der Deutschen Telekom sind ja alle klug: die geben ihren Callcenter Agents im Direktvertrieb keinerlei Informationen über den Kundenvertrag sondern deklarieren alles als „Omma Liesel auf dem Lande“. Und so können die Mitarbeiter dort unbelastet von irgendwelchen möglichen Nebenwirkungen selbst Geschäftskunden mit „alles kein Problem, alles wird schneller und billiger“ zur Bestellung von VoIP überzeugen.

    Fack you, Telekom – den Scheiss habt ihr schon wieder mit einem meiner Kunden durchgezogen deren Infrastruktur komplett mit Sensoren, Alarmanlage, Standleitung und Telefonanlage von ISDN abhängig ist.

    Ich kann es nicht deutlich genug sagen: Telefonie und Internet laufen meisstens über die gleiche Leitung, wenn sich beim einen was ändert ist das andere meisstens auch betroffen (und wenn es nur in einer kleinen Ecke ist die nicht sofort auffällt).

    Mein erster betroffener Kunde letztes Jahr hat mir die Umstellung auf „alles viel besser, schneller, billiger“-VoIP erst dann gebeichtet, als das Telefon auf dem gesamten Gelände schon 1 Tag nicht mehr nutzbar war und musste dann 6 Geschäftstage damit leben, dass alle eingehenden Telefonate halt auf dem Firmenmobiltelefon mit viel Kratzen und Bratzeln ankamen (AWS extern sei Dank!)

    Weitere Kunden haben zum Glück vorher Rücksprache gehalten.

    Im aktuellen Fall wurde es mir immerhin 1 Tag vorher gebeichtet – ich konnte nur anraten sofort bei der Telekom anzurufen um das Rückgängig zu machen. Im Idealfall passiert morgen nichts, im schlechtesten Fall dauert es wieder 1 Woche bis alles auf den Ursprungszustand zurückgesetzt wurde.

    Für ein Unternehmen, welches auf eingehende Telefonanrufe reagieren muss, kann das der Tod bedeuten.

    Seufz


    Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
    ------------------------------------------------------------------------------
    u0 RAID-5 VERIFYING - 37% 64K 2095.44 ON ON

    VPort Status Unit Size Type Phy Encl-Slot Model
    ------------------------------------------------------------------------------
    p0 OK u0 931.51 GB SATA 0 - ST31000340NS
    p1 OK u0 931.51 GB SATA 1 - ST31000340NS
    p2 OK u0 1.82 TB SATA 2 - WDC WD2003FYYS-02W0
    p3 OK u0 698.63 GB SATA 3 - ST3750640NS

    Jeder echte Admin bricht hier in Tränen aus – was für eine Verschwendung.

    Kopf-Tisch

    Nehmen wir mal an, der Firmenname eines eurer Kunden lautet „Knochenbrecher“. Und jene Firma soll nun über paar Umwege ihre Bestellungen digital irgendwo einwerfen.

    Ihr bekommt folgende Information:

    Production
    Server Address: sftp.trading.example.com
    Port Number : 22
    User Name : KNOCHENBECHER
    Password : password

    und versucht exakt mit diesen Informationen auf den Server zu connecten (das mit dem Passwort hab ich genau so aus der Mail übernommen).

    Fehlermeldung, kein Connect.

    Ratet mal wo der Fehler steckt…

    Bergmännischer Abbau von Altlasten

    Manchmal ist EDV auch eine rußgeschwängerte Dreckecke …

    vorher

    … die Bergmännisch im laufenden Betrieb mit nur 2 Minuten Downtime …

    bergmann

    … in Ordnung gebracht werden kann.

    nachher

    Den Rest mach ich dann nächste Woche wenn ich herausgefunden habe, für was die ganzen Netzwerkkabel gut sind.

    Tip: Bei solchen Sachen Handwerkerleisten von Bachmann an die Wand schrauben.

    Gut ist…

    Gut ist, wenn der Distributor zeitgenau nochmal einen Karton Raspberry PI B+ ins Büro wirft.

    Schlecht ist, wenn man den PI B+ als Grundlage für weitere Projekte nimmt und am Tag der Lieferung die wesentlich leistungsfähigere Version 2 auf dem Markt ist.

    Und ganz schlecht ist, wenn die RaspberryPI-Webseite (wo man sich die aktuellsten Daten laden kann) aufgrund des Ansturms down ist und man die 5 Stunden dafür geplante Zeit nun was anderes machen darf.