jtb.blog

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.

Wie üblich zur Klausurenzeit entstand auch dieses Semester wieder ein interessantes Projekt - quasi als Ablenkung vom Lernen.

Durch die Bauarbeiten in D10 konnte die Fachschaft aus einem alten Türrahmen einen Riegelschaltkontakt bekommen. Dieser Schalter erfasst ob eine Tür abgeschlossen wurde (Riegel drückt den Schalter dann rein) oder nicht. Damit kann das alte Problem endlich gelöst werden: wie bekomme ich raus ob der Fachschaftsraum offen ist oder nicht?

Der Riegelschaltkontakt ist eigentlich ein einfacher Schalter:


Angebunden wurde das ganze über 1-Wire. Da Freddy mal ein Haufen Sensoren testweise bestellt hat, konnten wir nicht nur den Sensor anbinden sondern auch gleich noch ein paar Temperatursensoren.

Versteckt wurde die ganze Verkabelung im Kabelschacht. Obwohl der Chip recht klein ist (und somit auch die Kontakte zum Anlöten) haben wir vorsorglich eine größere Box zusammenimprovisiert
Das macht die spätere Fummelei bei Erweiterungen einfacher.


Gleichzeitig musste dann auch die Information verbreitet werden. Und was liegt näher als den Türstatus in die große Informationsmüllhalde einzukippen? Somit hat die Fachschaft jetzt einen Twitter-Account. Für mich war das ein wenig gewöhnungsbedürftig, da ich selber kein Twitter-Benutzer bin. Nach den ersten Schritten Account anlegen etc fand ich schnell raus, dass ich nicht einfach mit einem Programm ein Status-Update schreiben kann sondern erst eine Anwendung registrieren muss und dieser dann noch passende Zugangsdaten beschaffen. Zuerst einmal bin ich über einige defekte Links bei Twitter gestolpert und konnte mich dann unter der Developer-Seite trotz korrekter Logindaten nicht anmelden.. Da hätte ich eigentlich mehr Professionalität erwartet. Durch die Umstellung auf OAuth waren dann noch einige Tutorials im Internet unbrauchbar. Nach einigen Versuchen stand aber dann die fertige "1-Wire Filesystem auslesen und zu Twitter posten" Anwendung.

Die anderen Sensoren werden einfach per SNMP abgefragt und im Monitoring erfasst. Derzeitiges Ziel ist es die Temperatur im Vorlesungssaal 4.04 unter dem Dach von D14 zu erfassen. Die Überlegung ist hier nach Arbeitsstätten-Richtlinie zu hohe Temperaturen zu bemerken und passend Änderungen einzufordern. Beispielsweise einen effektiveren Sonnenschutz oder gerade in der Klausurenzeit im Sommer keine Klausuren in dem Raum zu planen.

Alle Details gibt es im Fachschaftswiki zu 1-Wire.
Mehr Bilder von dem Projekt gibt es online in der Gallery: Fachschaftsprojekte: 1-Wire.

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...

Auch wenn der Titel nach Viagra-Werbung klingt, ist hier etwas harmloses gemeint

Nachdem ich vor ein paar Jahren mein altes Jugendbett durch ein breites ersetzt habe (Ikea Hopen), hatte ich immer noch das Problem, dass die Bettdecken zu klein waren.
Heute kam endlich mit über drei Wochen Lieferzeit meine neue Bettdecke an: mit stolzen 2,20m Länge und 1,55m Breite ist somit die Bettdecke größer als manches Bett
Aber es lohnt sich - schon jetzt gucken die Füße nicht mehr so ohne weiteres raus