Kategorien
bla bla bla

Auf der Suche nach dem Ticket

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
Kategorien
bla bla bla

In Farbe und bunt

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…

Kategorien
bla bla bla

Huch?!?

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

Seltsam.

Kategorien
bla bla bla

Schlechte Aussichten

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.

Kategorien
bla bla bla

ein schöner Tag

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…

Kategorien
bla bla bla

Voll Panne, Ne

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

Kategorien
bla bla bla

Handwerker und so

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…

Kategorien
bla bla bla

Kategorien: Datenpflege, Softwareprogrammierung

Das im Titel genannte waren dann die beiden großen Blöcke heute in meiner Arbeitszeiterfassung – von dem restlichen Drumherum wie nervigen Toner-Verkäufern die anrufen, Kunden die nicht mit Firewalls umgehen können und Finanzlern, die kein Gefühl für Softwarepreise und Dauer von Softwareprojekten haben.

Aber egal.

Kategorien
bla bla bla

VerZIPt und zugenäht

Unsere Programmierer haben uns eine neue Version der Groupware als ZIP zugesendet – an sich das Standardprozedere.

Ging nur alles nicht.

Einige der Java-Servlets zum Einspielen von neuen Datenbankversionen funktionierten nicht, die Tomcat-Logs waren vollgestopft mit Exceptions von SAX. Der Programmierer hat mich ziemlich lange durch die Gegend gescheucht, mit der Argumentation: Bei mir geht alles, es muß an deiner Serverkonfiguration liegen – und da ich Fehler eher bei mir suche habe ich auch lange rumgewühlt.

Nach einiger Zeit bin ich dann auf das Problem gestoßen: Der SAX-Parser verlangt für die HTML-Templates valide Dateien, die geschickten waren das nur dummerweise nicht, es war noch Kruscht nach dem </html> mit drin, was angeprangert wurde und zu den Abbrüchen führte. Der Coder schob es dann auf ein Problem beim packen und ich bin massiv beeindruckt: Ich kann mit den handelsüblichen Packern nicht so umgehen, dass ein korruptes Archiv ensteht und beim entpacken keine Checksum-Fehler auflaufen.

Wo läßt sich so etwas lernen?

Kategorien
bla bla bla

Kopf -> Tisch

1:
mov ecx,50
mov tisch,kopf
loop 1

So, jetzt geht es mir besser…