Kategorie: bla bla bla

Hinweis:
Der heutige Beitrag wird zeitversetzt ausgestrahlt und wurde um alle Aufrufe zu Straftaten wie Körperverletzung, Sachbeschädigung und Mord sowie beleidigende Sprache bereinigt.

Die *piep* *piep* von dem großen Telekommunikationsunternehmen *piep*, die sollten man *piep* *piep* *piep*. Die *piep* haben unsere Kundendaten bei einer *piep* Datenbereinigung gelöscht, mit der *piep* Begründung, wir seien kein *piep* Telefoniekunde mehr bei denen – das sind *piep*, wir sind schon *piep* zwei Jahre bei denen keine *piep* Telefoniekunden mehr. Nachdem die *piep* Anlage nur per *piep* Ferwartung aus deren *piep* Servicecentern konfigurierbar ist haben wir jetzt *piep* 10 kg Schrott an der Wand hängen.Die ganzen *piep* sollte man *piep* und *piep* und anschließend *piep* um dann auf das Grab zu *piep*. Nur meinem – hoffentlich temporären – Mangel an strategischen Waffensystemen ist es zu verdanken, dass deren *piep* Zentrale und ganz Bonn überhaupt noch auf der *piep* Erdscheibe verweilt.

PS Weiß jemand wie man eine Octopus E30 (müßte baugleich zur Siemens HiCom 180 sein) lokal konfiguriert und ggf das Kennwort hackt?

Update: ist baugleich zu einer HiCom 118E

Diese Melodie- und Textfragmente schwirren mir gerade durch den Kopf.

Vorgestern noch habe ich die Telekom gelobt, heute ist alles schon wieder vergessen – das CallCenter in Schleswig-Holstein ist nicht mehr erreichbar.

Bisher kam ich da so ran, dass ich über die 01805-1990 anrief und beim Sprachcomputer die Telefonanlangebezeichnung angab – die war dann unbekannt, aber von dem Mensch, der sich dann meldete wurde ich ohne Probleme weiterverbunden.

Und jetzt auf einmal kommt auf der 1990 direkt ein Berater (auch so ein Euphemismus), der natürlich keine Ahnung hat, wie das weiterverbinden funktioniert – und schon war ich im lustigsten Hotline-Sumpf und drehte eine Stunde lang bürokratische Schleifen.

Zwischenstand: Angeblich gibt es unsere Kundennummer nicht, es würde mal recherchiert werden, dies „könne aber ein paar Tage dauern“. Ich könnte kotzen – der Business-T-Punkt Freiburg hatte natürlich auch nur den AB an, hoffentlich fällt mein hinterlassener Spruch nicht unter Beleidigung…

Unsere Telefonanlage ist ein Saurier – das sie nicht mit Kohle betrieben wird ist noch das einzige. Die technische Hotline der Telekom hat so einen Sprachcomputer vorgeschaltet, dem man den Name der Anlage sagen soll, um direkt zum richtigen Callcenter* durchgestellt zu werden – “Octopus E 30“ wird von dem Spracherkennungssystem als Eingabe nicht akzeptiert…

Wegen dieser Anlage war ich heute im Büro, keiner weiß so ganz genau, wieviele interne Leitungen auf welche Dose geschaltet sind, so saß ich dann mit einem System-, einem Analog- und einem ISDN-Telefon vor dem Patchfeld und habe durchprobiert: Wir haben 19 Systemanschlüsse, 4 Analogleitungen und einen internen S0-Bus…Leider ist jetzt nur einer dieser Systemtelefon-Anschlüsse frei und bis Oktober benötige ich 2 weitere Leitungen.

Mit viel Glück habe ich die Dokumentation der Anlage (irgendwo auf der Telekomseite, an sich nicht zugänglich außer über eine wirre Kombination von Suchbegriffen) richtig interpretiert, dann hat unsere Telefonanlage 22 Systemanschlüssse, davon 2 * 8 auf Erweiterungskarten sowie 6 direkt auf der Hauptplatine – aber das kläre ich nächste Woche, die Octopus-Hotline ist am Wochenende nicht besetzt und dann geht nur der strunzdoofe normale Support dran.

*) Hier mal ein Lob für die Telekomiker: Das Supportcenter für Octopus-Telefonanlagen irgendwo in Schleswig-Holstein ist großartig: Netter Dialekt (ich höre diesen nordischen Singsang einfach gerne…) und absolut kompetent.

Für die IT-interne Call-Verwaltung wollen wir schon seit längerem ein Ticketing-System einführen – auf das Funktionsmonster OTRS habe ich allerdings kein Bock, wir haben hier genau vier IT-Menschen und nicht so extrem viele Calls, das sich das System rechnet.

Näher anschauen werde ich mir Bugzilla, einerseits natürlich aus Faulheit: Die Applikation wird von etlichen Projekten genutzt, damit habe ich schon mal deutlich weniger Lernaufwand. Andererseits paßt es auch ganz gut zu den Anforderungen – es hat eine simple Oberfläche, die Mailunterstützung ist einwandfrei und der Kategorienbaum kann ziemlich genau unserer selbstgestrickten QS-DB nachgebaut werden, dies ist insbesonders deshalb wichtig, weil später auch die ganzen CRs für die Programmierer über das neue System laufen sollen – was bisher eben in der eigenen PHP-Applikation abgebildet wurde.

Klar – Bugzilla hat eigentlich eine andere Zielsetzung, aber ich denke das könnte den Ansprüchen hier gut entsprechen.

Hat irgendwer da draußen sonst noch Vorschläge für eine Ticket-Verwaltung? Die Anforderungen sind ungefähr so:

• minimaler Installations- und Administrationsaufwand
• Konfigurierbarer Auswahlbaum für die Zuordnung eines Calls / Ticket / Bugs / CRs
• Benutzergruppenverwaltung mit unterschiedlichen Rechten
• Zugang über einen Browser

Gestern wurde unser neues Drucksystem geliefert – eine Kiste von Develop (kennt jemand die Firma?) – im Endausbau wird das Teil für uns drucken, faxen, scannen, lochen und heften und zwei alte Geräte ersetzen.

Einmal das alte Drucksystem von Kyocera Mita, ein S/W-System, auch mit Finisher, Fax und Scan-Funktion sowie einen Farblaser von HP.

Bei den Seitepreisen werden wir ca 50 – 75 % Einsparungen haben – allerdings nur, wenn nicht plötzlich mehr farbig als jetzt gedruckt wird, mal schauen wie das so wird.

Einziges echtes Manko an diesen großen Abteilungsdruckern ist tatsächlich das Scannen im Netzwerk auf einen Terminalserver – der Kyocera hat so eine komische Helfer-Applikation, der Kopierer sendet die Scans per TCP/IP zu einem Host und die Applikation nimmt dann das Zeug entgegen und speichert es in ein Verzeichnis. Recht dumm für eine Multiuser-Umgebung. Das läßt sich so umgehen, dass dieses Applikation unter local-admin-Rechten ausgeführt wird und entsprechend der Scan-User-ID in die Home-Verzeichnisse verteilt wird – somit dämlich zu warten, es ist notwendig die Userzuordnung auf beiden Seiten zu verwalten.

Die Develop-Maschine kann nun angeblich direkt in SMB-Freigaben reinschreiben – mal schauen wie das sich dann so anfühlt und ob es besser zu administrieren ist…

Der Datenbank-Serverumzug hat tatsächlich funktioniert, nur ein paar Klitzekleinigkeiten zu fixen.

Seltsam.

Vista ist doof.

Anscheinend kappt Vista Verbindungen auf Port 80, die nicht genau dem HTTP-Standard entsprechen – was ziemlich unangenehm ist, die Dokumentationssoftware ist eben so.

Wirklich nachvollziehen konnte ich das Problem nicht, was aber auch daran liegt, dass unser Fallback-DSL seit Anfang der Woche gestört ist – seit heute synchronisiert sich das Modem gar nicht mehr. Na, mal schauen, glücklicherweise haben wir noch einen Zugang über einen anderen Port, der von Vista unangetastet bleibt, draußen im Feld müssen die Administratoren dann nur diesen einen Port freigeben.

Was lange währt wird endlich gut – nach langem Nörgeln und Quengeln meinerseits wurde die „strategische Entscheidung“ gefällt, jetzt doch vollständig auf Thin Clients umzusteigen. Bei uns im „Innendienst“ arbeiten praktisch alle schon auf einem Windows 2003 Terminalserver, die Desktopkisten sind praktisch nur dumme Terminals – für mich eben mit deutlich mehr Administrationsaufwand und erheblich höheren Energiekosten.

Seit einiger Zeit nutzt einer meiner eher anstrengenden Kunden als Anwendertest einen HP Thin Client – basierend auf einem AMD Geode-Prozessor mit einem von HP angepaßten Debian 3.1. Die Einrichtung war simpel – etwas rumspielen mit den Terminalclient-Einstellungen, damit der USB-Port direkt als Laufwerk auf dem Remote-Desktop eingebunden wird und fertig.

Lange Rede, kurzer Sinn: Weitere 11 von den Boxen sind bestellt, mit einem Händler meines Vertrauens* habe ich einen Lieferabruf vereinbart, die ersten drei kommen diese Woche noch, die anderen kann ich kurzfristig und in beliebiger Stückelung bei denen abrufen.

Bis auf IT, einen Arbeitsplatz für Scans und einer Person des Managements (die ihren Desktop nicht hergeben will…) sind dann bald alle stationären Arbeitsplätze praktisch wartungsfrei und hoffentlich durch meine User unkaputtbar.

*) *hüstel*, mit dem Consultant-Arm dieses Systemhause hatte ich nämlich bei einem anderen Arbeitgeber ziemlich Probleme…

Ich habe mich heute stundenlang mit VPNs rumgeärgert – eines ist blöder als das andere.

Aber zur Ausgangslage: In unserer Groupware-Applikation ist ein Bug, der angeblich gar nicht da ist – behaupten meine Progger. Da wir keine Lust mehr haben, uns damit rumzuschlagen sollen jetzt die Verursacher dieses Käfers mit ihrem Tomcat direkt auf unsere Test-Datenbank losgehen, wofür ich beauftragt wurde denen einen VPN-Zugang zur Verfügung zu stellen.

Auf der Firewall-Appliane läuft dazu ein pptp-Daemon, der bugbelastete Nachbau eines sicherheitszerfressenen Originals – klingt komisch, ist aber so. Nun hat jedoch der unter Linux nutzbare pptp-Client bei Kernel 2.6.15+ irgendwelche obskuren Probleme – der Tunnel läßt sich öffnen, aber idiotischerweise keine Daten drüber schicken, ein tcpdump auf Clientseite zeigt schön alle abgehenden Pakete, die vom pptp auch eifrig als verschickt gezählt werden, aber auf der anderen Seite kommt nichts an – elektronisches Nirvana vom feinsten.

Der prinzipiell auch laufenden IPSec-Tunnel mit OpenSWAN hat mir die letzten Nerven* geraubt – das ist so eine Netzwerktechnik, welche ich _nie_ begreifen werde.

Der für mich gefunden Workaround besteht jetzt aus einem simplen ssh-Tunnel – an sich brauchen die drüben nur Zugriff auf den MySQL-Port 3306, der kann auch ganz simpel an localhost gebunden werden, was dann in fertig so aussieht:

ssh user@ssh-host -L [localport]:remote-server:[remoteport]

Das ganze ist dann am Ende so, als würde der auf dem Remote-Port angebotene Dienst der im Firmennetzwerk stehenden Box auf 127.0.0.1** laufen – alles in allem sehr praktisch, hoffentlich reicht das erst mal aus, auf weitere VPN-Stunden habe ich _keine_ Lust.

* Ich bin ein Nervivor – ich lebe von meinen Nerven
** Die optimale Adresse um Remote-Exploits zu testen

Bei uns im Serverraum hat eine der Wasserleitung anscheinend eine defekte Lötstelle – glücklicherweise tropfte das _genau_ zwischen Kabelschacht und Rackschrank runter, 3 cm weiter links und es hätte direkt in eine Steckerleiste gekleckert.

So weit so schlecht.

Die vom Hausmeister (Facility Manager?) geschickten Handwerker waren dann mal wieder Spezialisten ersten Ranges – meine Einwände, mit durchsifften Zwischenboden-Platten direkt über meiner Hardware zu hantieren wurden ignoriert und mit dem Argument „wir legen dann einfach was drüber“ weggewischt – als guter Mensch hoffe ich jetzt für die, dass sie gut versichert sind, sobald sie morgen früh das defekte Rohrstück austauschen.

Na ja, mal abwarten was da noch so kommt, ich hoffe einfach mal die haben heute den richtigen Hahn abgedreht und es kommt auf jeden Fall kein Wasser nach…