jtb.blog

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.

Diese Woche hatte ich mit einem interessantem Fall zu tun. Einer der Linksys SRW2048 Switche des Fachbereichs schien nicht mehr richtig zu arbeiten.

An dem Switch hingen zwei Server jeweils mit zwei Netzwerkkarten. Alle beiden Server sowie das Management-Interface des Switches waren ohne Probleme erreichbar. Nur die zweite Netzwerkkarte der Server wollte nicht richtig.
Die Symptome waren einfach: man konnte die Server nicht auf der zweiten Netzwerkkarte anpingen. Wohlgemerkt nur wenn man es von einem anderen Switch aus versuchte - intern klappte alles wunderbar.

Zuerst wurde also der Uplink des Switches verdächtig. Als erstes habe ich die redundante Anbindung an die beiden Backbone-Switche entfernt - aber selbst bei nur einer Verbindung zum Backbone blieb das Problem bestehen. Also wurde testweise der Port-Channel deaktiviert. Somit war der Switch nur noch von einem LAN-Kabel an die Backbone angeschlossen. Das brachte allerdings keine Besserung.
Eine genauere Analyse brachte zutage, dass ARP erfolgreich war. Der Switch lernte brav die angeschlossenen MAC-Adressen und auch die Backbone kannte alle MACs. ICMP-Pings gingen im unteren einstelligem Prozentbereich durch, aber auch wirklich nur ganz selten.
Die Fehlersuche ging also weiter. Reboot der Server und des Switches, Reset des Switches und leere Konfiguration - nichts half weiter.

Dann änderte ich die MAC-Adresse der zweiten Netzwerkkarte und siehe da - es funktionierte! Jetzt war es offensichtlich: der Switch hatte einen Fehler. Weitere Tests zeigten, dass der Switch jegliche Datenpakete mit einer ungeraden MAC-Adresse nicht sauber verarbeitete sobald die Rechner auf bestimmten Ports angeschlossen waren. Beispielsweise funktionierten die Ports 2 und 3 untereinander wunderbar, aber nicht in Kombination mit dem Uplinkport 48.

Über die eigentliche Ursache kann man nun nur mutmaßen. Wahrscheinlich hat sich durch den Staub im Serverraum eine Datenleitung verabschiedet oder wurde kurzgeschlossen und ein Bit wird nicht mehr richtig übermittelt. Das Verhalten der Ports kann man sich vielleicht mit einer Backplaneaufteilung auf Portgruppen erklären...


Jedenfalls wurde der Switch nun außer Betrieb genommen und der Ersatz funktioniert wunderbar. Nur die Problemsuche war ein wenig ärgerlich - oft kann man durch strukturiertes Vorgehen einen Fehler schnell finden, aber selten geht man von einem Hardwaredefekt aus. Normalerweise liegen die Probleme ja ein wenig weiter oben im Schichtenmodell

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.

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

In der letzten Woche war ich quasi nur mit Angebote einholen. Ein paar für die Arbeit und eins für die Fachschaft
Es ist schon ein komisches Gefühl innerhalb von einer Woche mehr zu bestellen als man Jahresgehalt hat.
Die Regel mit den drei Angeboten produziert zwar viel Arbeit, aber wenn man mal die erste Version und die letzte der Angebote betrachtet, merkt man wofür man gearbeitet hat. Als wir dann auch noch festgestellt haben, dass wir eigentlich noch einen großen Serverschrank brauchen, habe ich kurzerhand noch einen ausgehandelt. Angebote werden dann gut, wenn der Vertriebler auf der anderen Seite dies erstmal genehmigen lassen muss

Dennoch war ich erstaunt wie viel Rabatt wir als Hochschule erstmal pauschal bekommen. Bei einem Lieferanten war dies sogar der Sprung vom teuersten (online-Preis) zum billigsten Angebot (das ausgehandelte Endangebot). Gleichzeitig stelle ich fest, dass der frühere Vertriebler bei demselben Lieferanten absolut unfähig war.

Mittlerweile ist alles bestellt und die nächste Woche wird quasi ein vorgezogenes Weihnachten.
Die Studierenden bekommen einen größeren Leihnotebookpool (das ging über die Fachschaft, weil die die Gelder beantragt hat) und viel mehr Speicherplatz auf dem zentralen Server. Gleichzeitig wird die Serverinfrastruktur des Fachbereichs ein wenig aufgestockt. Ich bin auf jedenfall gespannt auf die Performance vom neuen Xeon X5550 Prozessor. Durch die veränderte Architektur wurde der Bottleneck FSB beseitigt. Für QuickPath Interconnect (QPI) hat Intel gut bei AMD abgeguckt
Dennoch ist es ein wenig komisch CPU-Leistung in GigaTransfers/s zu messen - da war ich erstmal verstutzt und musste nachlesen was das überhaupt bedeutet. Gerade für Virtualisierung sollte das neue Design viel bringen.

Gestern war es soweit: ich habe meinen neuen Arbeitsvertrag unterschrieben
Ab dem 02.03.2009 bin ich dann Angestellter der Hochschule Darmstadt am Fachbereich Informatik.

Mein Aufgabengebiet umfasst die Mitwirkung bei der Konzeption und Umsetzung eines Netzwerk-Sicherheitskonzepts, Konzeption und Installation eines gesicherten Internetzugangs und Realisierung einer internetbasierten Kommunikation zwischen Studierenden und Betreuern im Fachbereich Informatik.

Das ganze ist eine halbe Stelle (genauer: 47,62%) und dient der Verbesserung der Qualität der Studienbedingungen und der Lehre.

Auch wenn im Moment der Papierkram recht nervig ist, freue ich mich auf die neue Stelle

Nachdem ich letzten Freitag meine Bewerbung abgegeben habe, weiß ich nun, dass es nur eine Bewerbung gab

Wenn nichts mehr unvorhergesehenes geschieht, bin ich ab 01.03. Mitarbeiter am Fachbereich. Das mir nicht langweilig werden wird, zeigt sich schon an der groben Vorabplanung was alles ansteht.

Dennoch wird mir der Wechsel nicht unbedingt leicht fallen. Neun Jahre in der alten Firma gehen nicht spurlos an einem vorbei. Damals noch in der Schulzeit hat mir meine Arbeit dort so einige Rückhaltung gegeben. Ich blickte aber trotzdem mit Zuversicht in die Zukunft

Heute habe ich meine Bewerbung auf eine Mitarbeiterstelle an der Hochschule Darmstadt abgegeben
Das Themengebiet ist sehr interessant: IT-Sicherheit am Fachbereich, sichere Bereitstellung sowie Betreuung des Internetzugangs für Studierende und Einführung von E-Mail-Verschlüsslung.
Als halbe Stelle mit BAT IVa auch nett bezahlt - jedenfalls für öffentlichen Dienst.

Somit beginnt demnächst der nächste Schritt in meiner Laufbahn.

Und endlich ist ein arbeitsamer Tag vorbei. Am Samstagmittag ging es los: ein Dateiserver sollte neue Hardware verpasst bekommen. Da das Gehäuse mit vielen HDD-Slots versehen ist und drei Netzteile hat. Außerdem hat die Hardware in letzter Zeit Mucken gemacht. Erst sah der RAID-Controller sich nicht in der Lage ein RAID1 wieder zu initialisieren. Später war die Performance grottenschlecht und keine Ursache weit und breit zu finden. Weiterhin gab es keine Treiber für Windows 2008 mehr - das System war ja auch über fünf Jahre halt.

Also wurde ein neues Mainboard, Quad-Core CPU, RAM und RAID-Controller bestellt und heute dann eingebaut. Jeder, der schon mal an einem Server gebastelt hat, wird wissen, dass in solch einem Rackgehäuse kaum Platz ist. Erst recht wenn es eine 16er HDD-Backbone zu verkabeln gilt. Leider hat 3ware die Kabel geändert: jetzt gibt es nicht mehr einzelne Kabeln pro SATA-HDD sondern eine Kabelpeitsche. Zwar eigentlich recht sinnig, aber das bedeutet man muss alle SATA-Kabel neu ziehen. Nach einigen Stunden war dann die Installation komplett fertig und es ging an die Installation. Über den Ärger mt der 3ware Firmware hab ich ja schon geschrieben. Nachdem nun alles fertig ist, muss ich sagen, ist die Geschwindigkeit wirklich nett. 30MB/sek sind kein Problem und produzieren noch nicht mal merkenswerte CPU-Last. Und das während noch ein anderes RAID5 ein Rebuild durchführt (Spare Disk ist angesprungen)... Ich glaube außerdem, dass da eher meine lokale Festplatte gebremst hat

Jetzt fehlt noch ein wenig Software wie Backup-Agent, SVN-Server etc und das System ist wieder voll da. Aber dafür gibt es ja noch den Sonntag

Schon einmal habe ich über das Übernahme und das daraus entstandene Chaos berichtet.

Heute war es wieder soweit: ich hatte durch die Installation eines neuen Notebook und Installieren der neuen Sicherheitsupdates genug Zeit und Lust auf einen Anruf

Erster Anruf ging an die 0800er Nummer, die auf der Versatel-Homepage unter Kontakt stand. Dort bekommt man die Auswahl vom Sprecher:

• Schon Kunde


• Neukunde

Wählt man die 1 für "Schon Kunde" bekommt man eine neue Nummer genannt - diesmal eine 0180-5er Nummer, also nicht mehr kostenfrei.
Dort angerufen bekommt man gesagt, dass man eine veraltete Nummer gewählt hat
Danach soll man seine eigene Telefonnummer eingeben. Eigentlich sollte man dann annehmen, dass sich daraus alle nötigen Informationen ergeben, aber nach ein paar Minuten Warteschleife bekommt man die Frage (das erste mal mit einem richtigen Menschen verbunden) in welchem Bundesland man denn wäre..
Nach ca 10min Warteschleife für die nötige Weiterverbindung bekommt man dann gesagt, dass man an der falschen Hotline angenommen ist. Für Geschäftskunden ist wieder eine 0800er Nummer zuständig

Dort angerufen war erstmal besetzt. Beim zweiten Versuch konnte man nach 15min Warteschleife endlich mit jemanden sprechen, der einem wenigstens ein bißchen weiterhelfen konnte. Der versprochene Rückruf für heute fand allerdings nicht statt

Ab heute läuft der erste von mir betreute Server mit mehr als 4GB RAM (um genauer zu sein: mit 6GB)..

Grund ist die steigende Anzahl virtueller Maschinen, die alle ihren RAM wollen
Aber die Vorteile der Virtualisierung sind viel größer als der Nachteil, dass man viel RAM braucht..
Jetzt habe ich nur Angst, dass irgendwann der I/O-Throughput nicht mehr ausreichen wird und ich ein SAN oder so brauch