Work

Für wen ein Ausfall zentraler Komponenten keine Option ist, betreibt solche Systeme üblicherweise in irgendeiner Art High-Availability mit Failover.

Dass der Betrieb eines solchen HA-Systems mitunter nicht trivial ist, weiß jeder, der schon mal ein solches System betrieben hat. Probleme wie Split-Brain Situationen wo beide Systeme denken sie müssten aktiv sein, können spaßig sein.

Aus diesem Grund ist es gerade wichtig, dass die Administration möglichst einfach ist. Auf meiner Arbeit bin ich für ein Cisco ASA Active/Standby HA System verantwortlich.
Eigentlich weiß ich ja, dass Cisco nur die Konfiguration synchronisiert. Gerade beim Aufspielen von neuen Software-Versionen merkt man, dass der Flashspeicher nur lokal ist und nicht repliziert wird. Nicht schlimm - man hat sich im Rahmen des Upgrades dran gewöhnt jede Box einzeln zu versorgen.

Dummerweise verwende ich seit einigen Wochen ein neues Feature: Anyconnect VPN. Dies ist ein schöner VPN-Client, der die üblichen Probleme von IPsec (und damit verbunden: IKE) löst. Neben der neueren IKE-Version gibt es auch die Möglichkeit den Traffic über den https Port zu schicken - dadurch kommt das Anyconnect VPN durch viele Firewalls durch.

Nun zum eigentlichen Problem: im Gegensatz zu vielen weiteren Features legt dieses Feature die Konfiguration als Dateien im Flash-Speicher ab. Die GUI zum Verwalten der ASA legt diese Dateien natürlich nur auf der aktiven Box ab. Das ganze funktioniert dann eine Weile gut - bis es aus irgendeinem Grund zu einem Failover kommt. Sofort werden keine Anyconnect-Verbindungen mehr von der neuen aktiven ASA akzeptiert und die Benutzer beschweren sich.

Unangenehm - und vor allem vermeidbar. Eigentlich ist es nicht so aufwändig Dateien im Megabyte-Bereich synchron zu halten. Gerade wenn solche Auswirkungen entscheiden, frage ich mich was den Hersteller hindert solch ein nützliches Feature einzubauen

Am heutigen Tag hat die "kleine" Cisco ASA 5520 gezeigt, dass sie nicht mehr unseren Netzwerkanforderungen am Fachbereich gerecht wird.

Einige Neuerungen am Fachbereich und steigende Erstsemesterzahlen sorgen für immer mehr Traffic. Der zentrale Fileserver am Fachbereich wird nun endlich intensiv genutzt und die Imageverteilung per Fog für Windows sowie FAI/Gosa für Linux sorgen für ordentliche Auslastung. Unser Hauptgebäude wurde in den Semesterferien mit neuen WLAN-Access Points ausgestattet und auf einmal sind die Sorgen aus den vergangenen Semester bezgl. lahmen WLAN vergessen. Durch die zusätzlichen Studierenden und den damit einhergehenden engeren Stundenplan (früher waren die Praktika schön verteilt, nun sind in den Hauptzeiten alle Labore gleichzeitig belegt) steigt die Last nur zusätzlich.

Glücklicherweise konnte ich mich vor einigen Monaten durchsetzen, Gelder beantragen und darf nun eine größere ASA bestellen. Schon beim ersten neuen Backbone-Switch mit 10Gb-Interface wurde ich fragend angeschaut. Nun kommt die 5585-10 mit 10Gbit-Interface (ok, die reine Firewallleistung liegt wohl bei 2-4 Gbit/s) dazu und auf einmal er gibt meine Planung hoffentlich für alle einen Sinn
Jetzt heißt es nur noch abwarten und die nächsten Wochen bis zur Lieferung durchhalten.

Irgendwie scheinen sich Cisco-Komponenten nicht so ganz mit VMWare zu vertragen.
Wer so ganz der Schuldige ist, weiß ich noch nicht. Jedenfalls scheint VMWare (zumindestens der Player) selbst bei einer Bridge-Netzwerkverbindung in die Pakete reinzupfuschen. Genauer: DHCP-Pakete werden modifiziert.
Während normalerweise bei einer Bridge die MAC-Adresse der virtuellen Maschine verwendet wird, wird das DHCP-Discover-Paket mit der MAC-Adresse des Hosts versendet. D.h. die MAC-Adresse auf Layer 2 stimmt nicht mit der Client-Adresse im DHCP-Paket auf Layer 7 überein. Eigentlich nicht so schlimm, wenn da nicht die Cisco-Geräte übel drauf reagieren würden.

Problem Nr 1
Die Cisco ASA meldet eine ARP Request collision:

Message: Received ARP request collision from x.y.45.150/0024.d700.0001 on interface WLAN with existing ARP entry x.y.45.150/000c.2900.0002

Allerdings ist alles korrekt - die virtuelle Maschine mit der MAC 000c.2900.0002 hat vom DHCP die x.y.45.150 zugeteilt bekommen und der Host (0024.d700.0001) eine völlig andere per DHCP.
Dieses Problem könnte man fast noch ignorieren - wenn nicht die Warnsysteme anschlagen würden und ein Ticket automatisch öffnen

Problem Nr 2
Das nächste Problem ist noch viel schlimmer. Diesmal ist nicht die Cisco ASA sondern ein Cisco Catalyst C3560-E die "störende" Komponente. Ohne DHCP-Snooping funktioniert alles wunderbar. Sobald man aber aus Sicherheitsgründen DHCP-Snooping aktiviert, bekommen virtuelle Maschinen keine DHCP-Antworten mehr. Das ganze völlig ohne Log-Eintrag oder irgendwelchen Hinweis vom Switch!

Erst Debugging vom DHCP Snooping zeigte mir den Fehler:

Nov 4 10:15:07.524: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/49)
Nov 4 10:15:07.524: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi0/49, MAC da: ffff.ffff.ffff, MAC sa: 0024.d700.0001, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 000c.2900.0002
Nov 4 10:15:07.524: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1402)
Nov 4 10:15:07.533: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/6)
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: client address lookup failed to locate client interface, retry lookup using packet mac DA: ffff.ffff.ffff
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 000c.2900.0002
Nov 4 10:15:07.533: DHCP_SNOOPING: process new DHCP packet, message type: DHCPOFFER, input interface: Gi0/6, MAC da: ffff.ffff.ffff, MAC sa: 001d.a2AA.BBCC, IP da: 255.255.255.255, IP sa: x.y.45.254, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: x.y.45.150, DHCP siaddr: 0.0.0.0, DHCP giaddr: x.y.45.254, DHCP chaddr: 000c.2900.0002
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: client address lookup failed to locate client interface, retry lookup using packet mac DA: ffff.ffff.ffff
Nov 4 10:15:07.533: DHCP_SNOOPING_SW: lookup packet destination port failed to get mat entry for mac: 000c.2900.0002
Nov 4 10:15:07.541: DHCP_SNOOPING: can't find output interface for dhcp reply. the message is dropped.

Man erkennt hier wunderbar, dass die MAC-Adresse beim DHCP-Discover unterschiedlich ist. Das Antwortpaket wird aber korrekterweise an 000c.2900.0002 geschickt. Diese MAC-Adresse ist dem Switch aber unbekannt, da ja bislang kein Paket mit der Absender-MAC am Switch einging...


Jetzt ist nur noch die Frage wie Cisco auf die beiden Bugs reagiert...

Manchmal fragt man sich wie es dazu kommen kann, dass manche Software ausgeliefert wird. Ich habe am Wochenende ein paar Switche auf den aktuellen Stand gebracht. Auf dem 3560-E lief das Upgrade auf 15.0(1) wunderbar. Nur der 2960G wollte nach dem Reload nicht mehr so recht - er war schlicht und einfach nicht mehr per SSH zu erreichen. Allerdings waren noch alle Rechner am Switch erreichbar. So habe ich bis zum heutigen Tag gewartet und mich per Konsolenkabel lokal verbunden.
Bei dem aktuellen Wetter war es sogar angenehm im kalten Serverraum zu sein

Nur statt dem erwarteten Loginprompt kam nur eine unangenehme Meldung:

%% Low on memory; try again later

Das ganze passiert kurz nach dem Booten. Das heißt wenn man schnell ist, ist ein Login per Konsole oder gar SSH möglich - nur später nicht mehr.

Fazit: Supportfall geöffnet und nun heißt es abwarten. Wofür zahlt man für den Servicevertrag viel Geld?

Zwar sind die Putzarbeiten mittlerweile vorbei, aber die Konsequenzen halten uns weiter auf Trab.

Einer der wichtigen Server steigt nun mit einem Speicherfehler aus. Ob der Fehler mit dem Staubbefall zusammenhängt ist noch offen. Wieder einmal bin ich aber froh, über Redundanz zu verfügen. Alle virtuellen Maschinen wurden live migriert und liefen somit ohne Probleme weiter

Nachdem ein Switch das Zeitliche gesegnet hat, zeigte sich wie sinnvoll und praktisch eine Versionierung und damit auch Backup von Konfigurationen ist.

Mit der Inbetriebnahme der neuen Cisco-Switches habe ich rancid am Fachbereich installiert. Automatisch alle paar Stunden werden von allen Cisco-Switches (sowie auch neuerdings die ASA Firewall) per Rancid die Konfiguration abgerufen und gespeichert.

Somit war die Recovery mit einem anderen Switch relativ leicht. Switch vom Schreibtisch per seriellen Konsolenkabel mit leerer Config starten, das Rancid-Repository aufrufen und alle wichtigen Zeilen übernehmen. Nur Kleinigkeiten wie Hostname und IP-Adresse müsste ich ändern und der Switch konnte in Betrieb gehen.
Leider gibt es nur drei Kleinigkeiten, die umständlich sind: zuerst einmal werden Passwörter von rancid sinnvollerweise nicht gespeichert, dasselbe gilt für die SNMPv3-Konfiguration - die SNMPv3-Benutzer werden nicht in der startup-config gespeichert sondern aus irgendwelchen Gründen abseits der normalen Konfiguration. Zuletzt gilt das auch für die VTP-Konfiguration..
Dennoch lohnt sich rancid, da der größte Umfang der Konfiguration einfach wiederhergestellt werden kann.

Wie berichtet wurden Ende letzter Woche alle Kabelverbindungen und sogar die Festplatten dokumentiert. Aufgrund der immensen Anzahl an Verbindungen dauerte das allein länger als einen Tag!





Heute könnte somit die eigentliche Reinigung starten. Natürlich wie immer unter Zeitdruck - eine parallel startende Lehrveranstaltung brauchte spätestens ab Dienstag einige (virtuellen) Maschinen.. Als wurden heute aus dem betroffenen Schrank alle Server ausgebaut, der Schrank in mühevoller Kleinarbeit gereinigt und der eine Server gereinigt sowie auch wieder eingebaut.
Direkt danach ging es an den Netzwerkschrank - ohne Netz bringt der gereinigte Server nichts
Das tragische ist, dass ich diesen Schrank erst in den letzten Monaten komplett neu verkabelt habe. Da ist es schmerzhaft die fast Hundert Kabel gezogen zu sehen:


Wenigstens sah es danach besser aus (beim zweiten Verkabeln macht man nicht dieselben Fehler wie davor):



Nur ein Switch hat scheinbar die Staubattacke nicht überlebt - nach der Reinigung wollte dieser nicht mehr ordentlich booten. Per lokaler Konsole war das Fehlerbild diffus:

Switch>show env all
TEMPERATURE is FAULTY

POWER is OK
RPS is NOT PRESENT

Erster Gedanke: Temperatursensor kaputt.
Zweiter Gedanke: warum heißt das Teil auf einmal Switch

Der nächste Schritt war das Beobachten des Bootens:

*Mar 1 00:03:01.697: %SYS-5-RELOAD: Reload requested by console. Reload reason: Reload command
Boot Sector Filesystem (bs) installed, fsid: 2
[..]
File "flash:/c2960-lanbasek9-mz.122-53.SE2/c2960-lanbasek9-mz.122-53.SE2.bin" uncompressed and installed, entry point: 0x3000 executing...
[..]
Checking for Bootloader upgrade.. not needed
POST: CPU MIC register Tests : Begin
POST: CPU MIC register Tests : End, Status Passed

POST: PortASIC Memory Tests : Begin
POST: PortASIC Memory Tests : End, Status Passed

POST: CPU MIC interface Loopback Tests : Begin
POST: CPU MIC interface Loopback Tests : End, Status Passed

POST: PortASIC RingLoopback Tests : Begin
POST: PortASIC RingLoopback Tests : End, Status Passed

POST: PortASIC CAM Subsystem Tests : Begin
HTD POST: Basic Test Failed
POST: POST Failed
POST: PortASIC CAM Subsystem Tests : End, Status Failed

POST: CAM test failed
POST Failed: disabling stack links and shutting down SDP

driver class subsystem initialization failed

Na toll - die Power-on Self Tests (POST) schlagen fehl

Im übrigen hat das lustige Konsequenzen.

!!! WARNING: The switch is not usable !!!
[..]
------------------ show mac-address-table count ------------------



Total Mac Address Space

00:03:28 UTC Mon Mar 1 1993: Unexpected exception to CPUvector 2000, PC = 6606D8
-Traceback= 6606D8 92618C 9226B0 922810 C0843C C0732C BEF068 539EFC 11BB59C 11B2028

Writing crashinfo to flash:/crashinfo_ext/crashinfo_ext_1

Na ja - morgen wird der Switch nochmal auseinander gebaut und vielleicht kann er ja wiederbelebt werden..
Wenigstens war es kein Backbone-Switch sondern "nur" ein einfacher Edge-Switch.

Nachdem ich schon vor einigen Wochen über die Bauarbeiten berichtet habe, gibt es nun wieder neues zu dem Thema.

Am Donnerstag hat mich fast der Schlag getroffen als ich den Serverraum betreten habe.. Mein Kollege war schon sehr ruhig aber man konnte spüren, dass was nicht stimmt
Im Rahmen der Einbauarbeiten der Klimaanlage haben die Handwerker scheinbar nochmals den Mauerdurchbruch vergrößert. Natürlich ohne dabei eine Staubschutzwand aufzustellen oder irgendwie sonst auf die Server zu achten.
Da die Ziegel der Außenwand rot sind, kann man sehr schön erkennen, wo sich der Staub überall abgesetzt hat. Als die Bilder gemacht wurden, war der Boden des Raums schon gestaubsaugt.
Die folgenden Bilder sind nicht für Admins mit zarten Nerven







Viele weitere Bilder sind in der Gallery der Fachschaft zu den Bauarbeiten D10 ab Seite 36 zu finden.


Am Freitag war dann der Gutachter der Versicherung vor Ort und nächste Woche kommt das Reinigungsteam - wohlgemerkt eine Spezialreinigung für Server. Dann wird wohl jedes Gerät einmal dokumentiert (Kabelverbindungen etc), abgebaut, gereinigt und wieder eingebaut und angeschlossen. Danach darf wahrscheinlich ein Techniker der jeweiligen Firma (Dell, Cisco bzw Pandacom) die Geräte begutachten damit der Supportvertrag erhalten bleibt...

Derzeit wird im öffentlichen Bereich viel saniert - Konjunkturpaket sei dank
Unter anderem wird hier der Serverraum des Fachbereichs einmal komplett verbessert. Statt herkömmlicher Klimaanlagen soll in Zukunft bei kalten Temperaturen mit Außenluft gekühlt werden. Dann gibt es noch Kleinigkeiten wie Brandschutz, vergrößerter Raum, Kabelführung über Trassen usw

Mit dem Blogeintrag werde ich das Projekt und die Probleme mit einigen Bildern erläutern. Die ganzen Bilder vom D10-Umbau finden sich in der Gallery der Fachschaft.

Da Bauarbeiten wie bekannt ein wenig staubig werden können, wurde also der Serverraum temporär geräumt (ein Hoch auf fahrbare Serverschränke ).
Zwischendrin stand dann nur noch ein angeblich gut eingepackter Netzwerkschrank in dem Raum:


Und es wurde staubig:



Nach einigem Ärger und etlichen Säuberungsversuchen mussten wir nun wieder in den Raum zurück - ein Serverraum für einen Fachbereich kann man halt nur mal in den Semesterferien umziehen.
Hier sieht man schön wie der Raum geputzt wurde und wie groß er nun wirkt.


Allerdings waren nicht wie nach Plan die Bauarbeiten in dem neuen altem Serverraum abgeschlossen. Neben dem Ärger mit dem zeitlichen Ablauf des Projekts kamen nun Bauarbeiten in einem produktiven Serverraum. Trotz Warnungen und Absprachen wurde weiterhin im Raum ohne oder mit wenig Staubschutz gearbeitet. Kurz vor Weihnachten ist das ganze dann eskaliert. Da wir im Nachbarraum mittlerweile unser Büro haben, bekommen wir es sofort mit wenn zum Beispiel eine Bohrmaschine im Serverraum benutzt wird. Kurz in den Serverraum reingeschaut steht dort ein Bauarbeiter mit der Bohrmaschine neben ihm, der gerade schnell versucht seine Spuren zu verwischen. Drauf angesprochen warum er keinen Staubsauger benutzt, hat er nur lamentiert und meinte es wäre ja nicht so wild...

Jetzt hat der Serverraum ein neues Schloss und wahrscheinlich müssen alle Server nun einmal gereinigt werden. Ich bin mal gespannt wer die Kosten dafür tragen muss.

Hier ein paar Bilder zur Verdeutlichung (der Raum war ja vorher komplett sauber):







Auch wenn ich in die Einteilung im IT-Grundschutz Katalog von "Staub, Verschmutzung" als "Höhere Gewalt" nicht teile, zeigt sich doch, dass man beim Betrieb eines Serverraums nicht nur die Server als Hard- und Software im Blick haben muss sondern auch das Umfeld. Mehr als Warnen und Absprachen treffen kann man als einfacher Angestellter aber auch nicht. So bleibt mir nur übrig zu hoffen, dass keine Festplatte oder gar ein Server ausfällt beziehungsweise stirbt.

Merke: auch heutzutage sollte man nicht nur den freien Speicherplatz einer Partition monitoren sondern auch die Anzahl freier Inodes..

Während auf dem einen Server mit über 700 GiB belegter Speicher "gerade mal" 7,6 Millionen Inodes in Verwendung sind, gingen auf einem anderen Server mit 100 GiB Partitionsgröße gerade die 6,5 Millionen Inodes aus.
Mir ist das in den letzten Jahren nicht mehr aufgetreten, so dass ich erstmal zweimal schauen musste warum keine Dateiuploads mehr funktionierten


Ab demnächst darf Nagios als Bigbrother nun auch die Inode-Anzahl überwachen...

In den letzten Tagen habe ich prototypisch eine neue Backbone-Struktur für den Fachbereich Informatik aufgebaut. Während früher pro Gebäude ein Backbone-Switch zuständig war und somit einen großen Single Point of Failure bot, soll in Zukunft ein redundantes System auch beim Ausfall eines Backbone-Switches den Betrieb am Laufen halten.

Während wir im Edge-Bereich allein durch die schiere Anzahl von benötigten Ports bzw Switches nur Linksys einsetzen, baut die neue Backbone auf "echten" Cisco Switches auf.
Jedes Labor und jeder Serverschrank wird dann später mit zwei 2 Gbit-Portchannel angebunden, so dass sowohl Redundanz als auch Durchsatz für zukünftige Anwendungen (ich sag nur Image-Verteilung) gegeben ist. Gleichzeitig sorgt RSTP bzw MSTP dafür, dass es zu keiner Schleife im Netz kommt.

Vereinfacht dargestellt:


Direkt nachdem der Prototype aufgebaut war, kamen aber die ersten Probleme:

%SW_MATM-4-MACFLAP_NOTIF: Host 001e.e500.ABCD in vlan 1234 is flapping between port PoX and port PoY

Der betroffene Host war die Managementschnittstelle des Linksys SRW2048 im passenden Management-VLAN. Dadurch konnte man den Switch nicht mehr erreichen... Alle anderen Hosts, die am Switch angeschlossen waren, funktionierenden allerdings weiterhin wunderbar.

In den da drauf folgenden Tagen nahm ich den Prototypen auseinander, baute von Port-Channel auf normale einfache Verbindung runter, bemühte Wireshark etc.
Gleichzeitig trat ich mit dem Linksys-Support in Kontakt und hoffte auf eine Lösung. Dieser erzählte mir dann erstmal, dass sie keine Catalyst zum Testen zur Verfügung haben - nur Linksys-Produkte...
Nach gut einem Moment wurde es mir zuviel mit dem Support und ich baute den gesamten Prototypen nochmal neu auf und bin kurz danach über die Ursache gestossen, die auch schon vorher per Wireshark-Trace zu sehen war: der Linksys schickt über ein vom Spanning-Tree blockiertes Interface ARP-Requests für seinen Standardgateway! Mit der Aussage festgenagelt, hat der Support dann endlich ein Dokument gefunden, dass dieses Problem beschreibt und mit einem Firmware-Update zu beheben ist.
Diese Firmware stand zwar schon vorher auf der Webseite zur Verfügung, aber kein Wort von dem Fehler. Obwohl dieser in der internen Datenbank aufgezeichnet war!

Mit einem Firmware-Upgrade läuft das Bäumchen jetzt korrekt und sobald unser Team Verstärkung durch mehr Personal bekommt, geht es ans Ausrollen

Seit einigen Tagen geistert ja die Idee der anonymen Bewerbungen durch die Politik.

Das ganze erinnert mich an meine Zeit als Studierender in einer Berufungskommission für eine neue Professorenstelle. Deswegen kenne ich auch die andere Seite einer Bewerbung - das Auswahlverfahren.

Aus genau diesem Grund aber bin ich so verwundert warum sich Interessengruppen noch nicht groß in die Diskussion über die anonymen Bewerbungen eingemischt haben.
Wie für jeden offensichtlich ist, herrscht an unserem Fachbereich ein Frauenmangel - sowohl bei den Mitarbeitern als auch bei den Professoren.

Wenn man diesen Mangel nun beheben möchte, muss man doch eigentlich mehr Frauen einstellen. Also quasi das Ungleichgewicht auf der aktuellen Beschäftigungsseite mit einem Vorteil für Frauen im Bewerbungsverfahren kompensieren (das gleiche gilt natürlich auch für andere Gruppen). Natürlich immer unter der Maßgabe der gleichen Qualifikation.
Aus genau diesem Grund kenne ich bei unseren Stellenausschreibungen folgenden Anhang:

An der Hochschule Darmstadt besteht ein Frauenförderplan. Im Rahmen der tatsächlichen Durchsetzung der Gleichberechtigung von Frauen und Männern und der gesetzlichen Maßgabe, die Unterrepräsentanz von Frauen innerhalb des Geltungsbereichs des Frauenförderplans zu beseitigen, ist die Hochschule Darmstadt an der Bewerbung von Frauen besonders interessiert.

Schwerbehinderte Bewerber/innen werden bei gleicher Qualifikation bevorzugt.

Sollte also ein solcher Ansatz auch bei uns an der Hochschule zum Einsatz kommen, würden auf einmal während der Sichtung alle Beauftragten ausgeschlossen werden. Vielleicht sogar ein angenehmer Aspekt, aber es würde die ganze Diskussion auf einen späteren Termin verlagern.
Vielleicht sogar noch schlimmer - wenn ich bei einer Frau eine Lücke im Lebenslauf finde ist das ok, aber bei einem Mann macht man sich schon Gedanken (sehr wenige nehmen ja Vaterschaftsurlaub). Welche Personaler würde dann nicht gleich alle Bewerbungen mit Lücken bei der Vorselektion rauswerfen? Und er muss nicht mal Angst vor der Frauenbeauftragten haben - immerhin kennt er das Geschlecht ja nicht und wirft auch Männer aus.

Außerdem halte ich das ganze nicht überall für praktikabel. Wenn ich eine Liste der Bewerber und die Hand bekomme, dann steht da bei Professoren ihr Promotionsthema. Das ist recht eindeutig und nicht so leicht zu anonymisieren. Die Prioritätenliste steht sowieso erst nachdem die Bewerbungsgespräche geführt wurden.

Somit ist die Forderung nach anonymen Bewerbungen (bzw. anonymen Bewerbungsverfahren) für mich nur eins: der Vorwurf man würde unfair selektieren. Abgesehen von Vitamin B was weiterhin möglich sein wird, ändert sich also in meinen Augen nicht viel. Das eigentliche Problem (zumindestens im akademischen Bereich bei naturwissenschaftlichen Fächern) ist doch ein anderes: wir haben viel zu wenige weibliche Absolventen oder gar schon viel zu wenige Studienanfängerinnen. So wundere ich mich nicht, dass sich zu wenige Frauen auf eine Professorenstelle bewerben.
Wenn dann die passende Qualifikation gegeben ist, habe ich nichts gegen eine weitere Professorin am Fachbereich

Wie überall kommt es bei mir auf der Arbeit auch vor, dass man sich nur noch an den Kopf greifen kann. Über das meiste darf ich leider nicht schreiben, so dass nur einzelne, gefilterte Artefakte ab und zu von mir gebloggt werden.

Heute mittag kam eine erwartete Lieferung an - Network Management Cards von APC. Mit diesen kleinen Einbaukarten kann man die USVs über das Netzwerk verwalten. Sehr nützlich wenn man viele USVs über mehrere Gebäude verteilt hat und nicht immer einen Server zur Hand der die USV über die serielle Konsole abfragen kann.

Nach dem üblichen Einbauprozedere (USV ausschalten und stromlos machen) stellte ich beim Konfigurieren fest, dass ich mich nicht an der Karte anmelden konnte. Standardmäßig kommt man mit apc/apc rein - nur diesmal nicht. Jedenfalls keine große Gedanken darüber gemacht und um schnell weitermachen zu können, die Passwort Reset Anleitung von APC gesucht. Kurz danach war ich auf die Karte verbunden und wunderte mich um so mehr. Im Gegensatz zu den bislang eingebauten Karten fand ich eine fertige Konfiguration unter einer alten Firmwareversion vor.

Die erste Karte meldete sich mit:

Name : V0299001
Contact : Itellium
Location : Detmold
Up Time : 0 Days 0 Hours 0 Minutes

und weiter mit folgender Netzwerkkonfiguration:

Network started. Manual settings are in use.
------------------------------------------------
System IP : 10.40.28.7
Subnet Mask : 255.255.252.0
Default Gateway : 10.40.31.254

Host Name : V0299001
Domain Name : karstadt.net

Bei einer zweiten Karte zeigte sich dasselbe Bild: eindeutig eine gebrauchte Karte.
Sehr interessant war dann ein Blick auf "About System":

Manufacture Date : 11/14/2003

Mit Blick auf diese Daten und Verkauf der Karten als "Bulk" kriegt der Händler jetzt Ärger.

Gerade habe ich mal wieder festgestellt wie schön früher die Server mit eigener, dedizierter Management-Netzwerkkarte waren. Halt echtes Out-Of-Band Management (OOB) - solange Strom da war, konnte man sich einloggen und den Server verwalten (was mit IPMI so alles machbar ist, findet man z.B. hier: "Managing Dell PowerEdge Servers using IPMItool").

Heutzutage haben die Server die ich benutze (Dell) ein IPMI-Modul, das über die die normale onBoard-Netzwerkkarte angesteuert wird. Nachdem der alte Treiber im 2.6.26er Kernel Probleme mit dem IPMI hatte, klappte nach einiger Zeit alles unter 2.6.32.

Nun wollte ich noch beide Netzwerkkarten bündeln - da ich nicht mehr vor dem Rechner stand, war natürlich die Überlegung dies über die IPMI Serial over LAN (SOL) Schnittstelle zu tun. Im Hinterkopf hatte ich: da kann ich ja die Netzwerkdevices runterfahren, weiterarbeiten und wieder als Linux-Bonding hochfahren.

Also SOL geöffnet:

ipmitool -I lanplus -a -U root -H sol activate

und angefangen zu arbeiten..

Leider war der Traum zu schön:

ifconfig eth0 down

... und der Server war nicht mehr erreichbar - inkl. IPMI SOL


Scheinbar fährt der Treiber bzw. Linux-Kernel die Netzwerkkarte so runter, dass kein IPMI mehr geht. Ein eingstelltes Failover auf die zweite NIC scheitert auch offensichtlich...


So arbeite ich dann erst morgen am Server weiter

Seit Anfang des Monats starten endlich die Bauarbeiten am Gebäude D10. Wer die letzten Wochen nicht mehr in der Hochschule war wird überrascht sein wie das ehemalige Druckergebäude mittlerweile aussieht:



Ich musste schon mein Büro räumen und hausiere gerade im InCarMultimedia-Labor. Leider ist es auch dort ein wenig lauter.
Ansonsten ist nur noch die Frage offen ob die Umbauarbeiten bis Vorlesungsanfang beendet sind - wenigstens im Bereich der Labore. Da der Haupteingang wohl nicht fertig sein wird, müssen die Studis immerhin schon mal einen großen Umweg machen - da sollten dann wenigstens die Labore nutzbar sein

Bei dieser Sache bin ich zweigespalten. Grundsätzlich bin ich jemand der gerne hilft - insbesondere wenn ich sehe, dass etwas schief läuft.
Irgendwann stellt man aber fest, dass diese Verhaltensweise gleich mehrfach kontraproduktiv ist.

Zuerst einmal stellt man fest, dass diejenigen, die Arbeit "wegschaffen", immer mehr Arbeit aufgehalst bekommen. Man könnte fast sagen, dass die Arbeit geradezu von denen angezogen wird.

Zum anderen ändert sich bei so einer Aufgabenverdrängung nichts am grundsätzlichen Problem. Selbst wenn man auf dieses Problem aufmerksam macht, wird die Arbeit aus Sicht der Vorgesetzten immer noch erledigt. Am Ende steht man selber noch als der Buhmann da weil man auf eigentlich offensichtliche Probleme aufmerksam macht.

Also kommt man - wie ich - irgendwann zum Entschluss, dass nicht immer alles so laufen muss wie es eigentlich könnte. Als ich das dann einem Professor erzählte, sagte er da draufhin "Glückwunsch - ich habe das erst später gelernt".

Eigentlich ist das schade - weil im Endeffekt kommt es fast immer zum Punkt Geld. Projekt XY wird gegen die Wand fahren und ein paar Tausend Euro Schaden verursachen?
"Nicht mein Zuständigkeitsbereich".. Diese Antwort fand ich früher immer blöd - jetzt kann ich sie verstehen. Solange man als Angestellter nicht den Anreiz hat das zu retten - warum sollte man es tun?
Natürlich ist das gerade in kleinen Firmen anders, aber sobald die Firma eine gewisse Größe erreicht wo der Chef nicht mehr alles überblicken kann, kann sowas schnell entstehen.

Dennoch tut es einfach weh wenn man manche Projekte sieht...

Seit fast 16 Monaten arbeite ich nun für die Hochschule Darmstadt am Fachbereich Informatik. Somit ist das Ende absehbar - die Stelle ist auf 2 Jahre befristet.

Die Frage, die sich nun stellt, ist einfach: was will ich danach machen. Hier geht es mehr darum was ich wirklich machen will und nicht was ich machen kann.

Immerhin gibt es ein paar Möglichkeiten. Zuerst einmal besteht die Option, dass die Stelle verlängert wird. Das ist aber abhängig von diversen Faktoren - insbesondere aber vom Sparzwang im Land Hessen. Das ist aber wiederrum kein Faktor ob ich das machen will. Ich weiß auf jeden Fall schon mal, dass ich auf Dauer nicht hier im öffentlichen Dienst glücklich werde. Momentan bin ich jedenfalls ein wenig gefrustet. Schon damals hat mir eine gute Freundin abgeraten in den öffentlichen Dienst zu gehen - mittlerweile weiß ich auch warum

Bei der Wahl einer anderen Anstellung besteht das Problem, dass ich weiterhin studieren werde. Zwar ist auch hier das Ende in Sicht, aber ich liege noch sehr gut in der Zeit. Durch das Teilzeitstudium bin ich im vierten Semester gerade erst bei Halbzeit. Je nachdem wie ich das Master Projektsystementwicklung absolvieren kann, wäre ich auch schon schneller fertig. Falls eine solche Anerkennung meiner Arbeit und den restlichen Scheinen funktioniert, kann ich mit Beendigung des Arbeitsverhältnisses auch gleich mit der Master-Arbeit anfangen. Hier liegt der nächste Knackpunkt: die Master-Arbeit ist in Vollzeit zu erstellen - also kein Teilzeitjob nebenbei wenn man sich auf die Arbeit konzentrieren will. Aus diesem Grund baue ich mir gerade ein kleines Finanzpolster auf.

Urlaub - wer mich kennt weiß, dass ich so was selten mache.

Zur Zeit bin ich aber in einer Art Zwangsurlaub.. Hätte ich meinen Resturlaub aus 2009 nicht genommen, wären 11 Urlaubstage verloren gegangen. So sehr liebe ich das Arbeiten dann nicht, dass ich freiwillig auf Urlaub verzichte

Somit habe ich nun seit dem 30. April Urlaub.
Bis zum 28. Mai bin ich also mal nicht am Arbeitsplatz zu finden

Eine sehr gute Maßnahme war das Entfernen sämtlicher beruflicher Zugänge vom Notebook - also effektiv den private SSH Key für die Server. Da die Passwörter sowieso automatisch generiert wurden, kenne ich die nicht auswändig und war somit voll und ganz ausgesperrt.
Für den Rest musste ich nur meinen Benutzer aus den Berechtigungsgruppen entfernen und schon war jede Versuchung doch sich mal einzuloggen im Keim erstickt.

Dennoch fällt es mir schwer auch mal einen Systemausfall zu bemerken (ich habe vergessen die Monitoring-Mails abzuschalten) und nichts dagegen machen zu können.

Die erste Aktion war übrigens ein Besuch beim lokalen Hardware-Dealer: eine neue CPU, Mainboard, RAM und Grafikkarte musste her.

Noch ein paar Tage und der Urlaub ist rum - nur was mache ich mit dem Jahresurlaub von 2010?

Das hier fällt in die Kategorie ohne Worte: nachdem in der letzten Zeit die Parkplatzsituation am Fachbereich ein wenig angespannt war (wohl auch weil die Schranke immer wieder offen war), hat ein Labing zwei Studis beim Parken vor dem Gebäude wieder vom Parkplatz verwiesen..
Eigentlich sollte man da verstehen, dass man als Studi kein Recht hat dort zu parken sondern sie einfach geduldet werden solange es genug Parkplätze gibt. Insbesondere wenn nachmittags oder abends jemand dort parkt würde ich nichts dagegen sagen.

Nachdem der Labing ins Gebäude verschwunden ist, stand ein weiterer Labing, der Dekan und ich noch vorm anderen Gebäude und unterhielten uns. Kurz danach fuhr der Studi einfach wieder durch die immer noch offene Schranke. Dumm nur, dass wir die Situation vorher mitbekommen haben.
Auf das Winken, dass sie wieder fahren sollen, folgte aber keine Reaktion. Als der Fahrer dann ausstieg, meinte dieser dann, dass sie ja hier parken dürften - immerhin wären sie Mitarbeiter.
Als dann meinem Kollegen der Kragen platzte, stelle sich heraus, dass beide als Tutoren beschäftigt sind.. Mit ein wenig Zurechtweisen sind beide wieder eingestiegen und haben den Hof verlassen. Es ist mir nicht bekannt von welchem Fachbereich die beiden waren

Manchmal muss man sich doch echt fragen wie dreist man sein kann. Es ist die eine Sache einfach reinzufahren und zu parken aber eine andere dann rumzulügen.

Zu meinen Aufgabengebiet im Fachbereich gehört die Absicherung des Netzwerks. Im Zuge dessen werden wir die öffentlichen Netzwerkports auf 802.1x (auch dot1x genannt) umstellen. Die Technik dahinter ist recht simpel und auch schon weit verbreitet - immerhin basiert auch WPA(2)-Enterprise darauf.

Nur haben wir ein großes Problem: die Switches (Linksys SRW2048) können keine Guest oder dynamischen VLANs. Das bedeutet es gibt nur 0 und 1 - entweder der Rechner bekommt Netz oder keins. Während die fehlenden dynamischen VLANs mit unterschiedlichen Ports ausgeglichen werden können (an Dose xy kann sich nur ein Dozent anmelden), ist das Fehlen von Guest VLAN ein großes Ärgernis für Labore. Automatische Rechnerinstallationen per PXE sind damit erstmal nicht mehr möglich. Die aktuelle Lösung ist eine Webschnittstelle über die dot1x ausgeschaltet werden kann, aber das ist nicht wirklich schön.

Auf der Suche nach einem Arbeitsplatzrechner bin ich dann über "Intel Active Management Technology" (AMT) gestolpert. Das ganze ist ein Chip auf dem Mainboard, welcher unabhängig vom Betriebssystem agiert. Man kann sogar den Rechner über das LAN steuern. Aber das beste Feature für unser Problem ist ein dot1x Authenticator. Schon bevor das Betriebssystem bootet kann der Chip sich gegenüber dem Switch authentifizieren und ermöglicht PXE.

Jetzt teste ich das demnächst aus und falls es so wie gewünscht funktioniert, haben wir eine Anforderung für die neuen Laborrechner