jtb.blog

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?

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

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.

Redundanz klingt gut. Failover noch besser.
Aber egal was man macht oder testet - es gibt immer einen Fall den man nicht bedacht hat und der die schöne Verfügbarkeit kaputt macht.

Gestern nacht ist ein Server gestorben. Na ja, zur Hälfte - eine der beiden onboard Netzwerkkarten verweigerte ihren Dienst. Zuständig war dieser Server für DHCP (ca. 30 Subnets) und Radius. Während der DHCP-Dienst durch ein Failover-Setup weiterlief, verlief es mit dem Radius-Server nicht so gut. Auf der zweiten Netzwerkkarte lauschte immer noch der Freeradius-Daemon und wurde somit von den Switches im Gebäude erreicht. Allerdings kann Freeradius ohne Default-Gateway die LDAP-Server nicht erreichen. Ohne Benutzerdatenbank keine erfolgreiche Authentifikation - aber leider dennoch erreichbar. Somit kam es, dass kein Switch auf die anderen Fallback-Radiusserver umschwenkte. Ohne Radius kein 802.1x und somit stehende Rechner am Morgen


Dennoch gibt es ein paar Faktoren, die das Problem minimiert oder bei der Analyse geholfen haben:

• Örtliche Zuordnung - jedes Gebäude hat ihren eigenen Radius-Server mit der höchsten Priorität eingetragen. Somit war das Problem lokal begrenzt und legte nicht gleich mehrere Gebäude lahm.


• Überwachung - es war somit schnell klar, dass der Server nicht erreichbar ist und wann er ausgefallen war. Allerdings zeigte sich, dass nicht jeder die Mail erhalten hat und unser Nagios zur Zeit zuviele Warn-E-Mails schickt.


• Tools - ein Webinterface zum Abschalten der Authentifikation ist in solchen Fällen sehr hilfreich.


• Redundanz - immerhin hat es der DHCP-Dienst geschafft

"Wie installiere ich alle meine Rechner neu?" Diese oder ähnliche Fragen stellt sich jeder Administrator mal. Während bei kleinen Rechnerparks noch der Turnschuhadmin von Rechner zu Rechner rennt, ist ab einer gewissen Anzahl eine automatische Installation angebracht.
Je nach Betriebssystem gibt es diverse Namen für eigentlich immer ähnliche Techniken. Sei es nun FAI (Fully Automated Installation) oder WDS (Windows Deployment Services). Natürlich gibt es auch reine Image-Software wie z.B. Norton Ghost.
Alle Installationsarten haben eine Gemeinsamkeit: der Rechner kann vom Netzwerk booten und bekommt danach über das Netzwerk die Installationsdateien. Dieser Netzwerkboot per PXE hat den angenehmen Vorteil: man muss nicht von Rechner zu Rechner wandern sondern quasi auf Knopfdruck ein Image ausrollen. Sollte beispielsweise der Rechner gerade aus sein, kann man per Wake On Lan diesen booten.


Ob nun ein echtes Image oder die Installationsdateien verwendet werden - beides hat einen entscheidenen Nachteil: das Netzwerk wird belastet. Aus schlechten Erfahrungen in der Vergangenheit werden heutzutage nicht mehr alle Rechner in ein Netzwerk gesetzt sondern per Firewall sauber getrennt. Was Würmer an der Verbreitung hindert, hat aber Nachteile: oft ist die Firewall-Appliance nicht stark genug ausgelegt um eine gleichzeitige Installation dutzender von Rechnern zu verkraften.

Im folgenden möchte ich eine kleine Lösung für dieses Problem vorstellen. Die grundsätzliche Idee ist einfach: das Aufrüsten der Firewall ist zu kostspielig. Ein einfacher Linuxserver mit zwei Netzwerkkarten ist schnell genug, aber wir wollen und können damit nicht die Appliance mit den ganzen Funktionen ersetzen.
Also stellen wir neben die Firewall eine zweite die nur während des Deployment-Prozesses tätig ist.

Die eigentliche Aufgabe besteht nun darin eine Fallunterscheidung zu treffen. Während beim normalen Boot alles wie gewohnt ablaufen soll, muss beim Booten über's Netzwerk alles über den neuen Linux-Server laufen. Das ganze klappt wunderbar wenn ein paar Rahmenbedingungen erfüllt sind - am wichtigsten ist hierbei die Verwendung eines passenden DHCP-Servers.

Zuerst einmal brauchen wir ein neues IP-Segment für die Image-Verteilung. Da öffentliche Adressen Mangelware sind, begnügen wir hier uns mit einem privatem Segment. Da wie schon gesagt, mehrere Netzbereiche versorgt werden sollen, nehmen wir hier ein 10er Bereich und unterteilen ein /16 in 255 Segmente.



Durch die Allow-Zeile wird dieser DHCP-Pool nur verwendet wenn tatsächlich über das Netzwerk gebooted wird. Das Erkennen eines Netzwerkboots erfolgt über die Angabe des Herstellers im DHCP-Request. Neben dem "pxe-kernel" welches über den nicht dokumentierten Kernelparameter dhcpclass gesetzt wurde, forderte der Kernel trotzdem auch noch als "Linux ipconfig" eine IP an.


Der ping-check erwies sich als nötig, da der Linux-Kernel eine IP-Adresse anfragt und gleichzeitig die alte noch in Benutzung ist. Der DHCP-Server pingt also die alte Adresse an und stellt fest, dass er sie nicht vergeben kann, da sie scheinbar noch in Verwendung ist. Was also normalerweise das Netzwerk vor der doppelten Vergabe einer IP schützt, ist hier kontraproduktiv.

Nun fehlt nur noch ein DHCP-Relayagent auf dem Linux-Server und die Rechner bekommen eine DHCP-Adresse. Bleibt aber ein Problem: je nachdem welcher Agent schneller antwortet bekommt der Rechner eine Adresse aus dem regulärem Pool oder aus dem neuen Deployment Pool.
Hier hilft ein explizites Verbieten - leider können wir die Gruppendefinition nicht verwenden, wenn die Rechner per statischen Host-Eintrag mit einer festen IP-Adresse versorgt werden. Hier hilft folgende Zeile im alten Segment für das Netzwerk:


Wieder haben wir die oben schon verwendete Fallunterscheidung. Diesmal wird jedoch die grundsätzliche DHCP-Funktion ein- oder ausgeschaltet. Die Benennung des Parameters booting ist ein wenig unglücklich - hier ist nicht das Booten des Rechners gemeint sondern das Zuweisen einer Adresse per DHCP.


Jetzt fehlen nur noch ein paar Kleinigkeiten. Unter anderem müssen die DHCP-Server eine Rückroute zum 10.10.0.0/16 Segment haben. Auch die beim Deployment beteiligten Rechner brauchen eine solche Route. Damit nicht jeder Server angefasst werden muss, werden alle anderen Netzwerkzugriffe per NAT auf eine bekannte Adresse gemappt. Damit die neue Firewall kein Sicherheitsloch aufreisst, sorgen noch ein paar iptables-Regeln dafür, dass nur die benötigten Dienste erreichbar sind.

Das Ergebnis kann sich sehen lassen: die Installation mehrerer Rechner geschieht jetzt völlig unabhängig von der Firewall. Jetzt bremsen nur noch die Netzwerkanbindung vom Linux-Server sowie natürlich die Anbindung vom Deployment-Server und dessen Festplatten. Aber gerade die Netzwerkanbindung kann man leicht skalieren. Eine Server-Netzwerkkarte gibt es im unteren dreistelligen Bereich. Die Edge-Switche kann man durch einfache Portaggregation schneller an die Core-Switche anbinden. Erst wenn die Backbone aufgerüstet werden muss, wird es wiederrum teuer. Aber 10 Gigabit-Ethernet ist ja im kommen.

Gestern gab es mal wieder eine Lektion bei der Kompatibilität von Switches zweier Hersteller.
Die Aufgabe: einen Linksys SRW2048 Switch mit einem Summit Extreme verbinden. Eigentlich kein Problem - aber man will ja Redundanz und weniger wichtig: Load-Balancing.

Die Technik dafür ist unter mehreren Namen bekannt - Bonding (Linux), Trunking (Sun), Etherchannel (Cisco), Port Aggregation (HP) und der offizielle Name: Link Aggregation (nach IEEE 802.3ad).

Für die einfache Einrichtung und Verhandlung der Möglichkeiten zwischen den beiden Switches gibt es ein standardisiertes Protokoll: Link Aggregation Control Protocol (LACP). Sowohl der Extreme als der Linksys unterstützen dieses und scheinbar wird auch ein Link aufgebaut. Allerdings nur scheinbar - obwohl beide Geräte angeben, dass der Link aufgebaut wurde und verfügbar ist, geht kein Traffic über den Link.
Auch das Spielen an den verfügbaren Parametern brachte keine Besserung. Ein statisches Konfigurieren brachte dann endlich den erwünschten Erfolg. Die Server am Linksys waren auch erreichbar nachdem ein Uplink-Kabel entfernt wurde.

Seit einiger Zeit warte ich auf Netbooks mit Ion-Plattform. Immerhin ist die Grafik sonst nicht die schnellste und die Erfahrungen mit Nettops sind für mich sehr deutlich: Nvidia Ion ist in Sachen Grafik einem GMA haushoch überlegen. Gerade heute wieder habe ich wieder ein solches System mit H264-Material sehen können.
Nur kann es so schwer sein das ins Netbook-Format zu packen? Oder ist es alles mit dem Warten auf Windows 7 zu erklären?

Zwar mag ich mein E6500 aber ab und zu hätte ich gern noch ein zweites Notebook

Nachdem ich am Freitag schon mit dem neuen Objektiv gespielt habe, hatte ich am Montag bei der zentralen Erstsemesterbegrüßung die Gelegenheit dem Objektiv mehr Auslauf zu geben

Die gesamte Kollektion ist wie immer in der Fachschaftsgallery zu finden: Erstsemestereinführung Wintersemester 09/10 - hier eine kleine Auswahl:










Ich bin immer noch fasziniert darüber welcher Unterschied zwischen einer Digital-Spiegelreflex und einer Kompaktkamera liegt. Das sind Welten in der Bildqualität und vor allem auch in Aspekten wie Schärfe, Tiefenschärfe oder gerade gewollter unscharfer Hintergrund. Auch lohnt sich mit dem Objektiv mittlerweile die Anschaffung des großen Blitzes. Auch mit einem Zoom-Objektiv durch den Raum ein ausgeleuchtetes Bild hinzubekommen ist echt nett.

Gestern habe ich mir ein neues Spielzeug geholt: ein 70-300mm Objektiv mit Bildstabilisator und Ultraschallmotor
Insbesondere der Ultraschonmotor ist sehr nett - kein Vergleich zum normalen Scharfstellen.

Natürlich wurden gleich ein paar Fotos gemacht (von D19 aus) - hier einmal mit 70mm:


Dasselbe Motiv mit 300mm:


Am Abend waren noch einige aus der Fachschaft auf der Innovative 2009 und ich konnte ein schönes Nachtfoto machen (mit dem alten Objektiv):

Nachdem der Preis der PS3 wieder mal gefallen ist, spiele ich mit dem Gedanken mir eine als Blueray-Player zu kaufen - eher sollte ich besser sagen spielte?

Gerade hat Sony ein neues Modell vorgestellt - mit interessanten Features. Zuerst einmal: kleiner, leiser und weniger Stromverbrauch.
Sehr nützlich für einen BD-Player ist aber die HDMI-CEC Funktion. Duch meinen Samsung LCD TV mir auch bekannt als Anynet. Damit kann über das HDMI-Kabel ein Gerät das andere steuern. Von Sony wird dies wie folgt beschrieben:

The new PS3 system is also equipped with the BRAVIA® Sync™ feature. By connecting the new PS3 system and a BRAVIA TV with the HDMI cable, users are able to directly operate the XMB on PS3 using the TV remote control. Other functions include “System Standby” that will automatically turn off the PS3 system when the BRAVIA TV is turned off.

Aber dann kommt die große Änderung:

The new PS3 system will focus on delivering games and other entertainment content, and users will not be able to install other Operating Systems to the new PS3 system.

Wahrscheinlich hatte Sony Angst vor größeren PS3-Clustern - nur ist das für mich erstmal ein Grund zu warten

Gestern war wieder ein Dell-Techniker zu Besuch.

Zum einen ist das LCD-Bezel erneut gebrochen. Dazu kamen fehlende Displayabstandshalter und ein fehlender Gummifuss - alle sind in den letzten Wochen verloren gegangen
Gleichzeitig wollte ich noch eine Schraube für das DVD-Laufwerk haben (der dritte Versuch eine solche zu bekommen).

Nachdem der Techniker mit dem Austauschen fertig war, konnte ich mich nicht mehr per Fingerprint am Bios anmelden. Da keine Lösung in Sicht war wurde ein erneuter Einsatz für den nächsten Tag geplant. Nachdem der Techniker weg war, fiel auch noch das TouchPad inkl. TouchPad aus. Gleichzeitig funktionierten die Lautstärke-Tasten über der Tastatur nicht mehr richtig und sendeten falsche Tastatur-Codes.

Am nächsten Tag wurde dann der Fingerprintreader getauscht. Der "Defekt" wegen Tastatur/Touchpad hat sich dann auch automatisch gelöst: es war wohl nur ein nicht korrekt sitzendes Kabel.

Nachdem mir jemand eine Mail geschrieben hat, dass sein Display vom Dell E6400 getauscht wurde und danach das Fiepen weg war, habe ich mal wieder den Dell-Service bemüht.

Ein Service-Einsatz am Freitag war leider nicht möglich, da das Ersatzteil nicht im Gebiet verfügbar war. Erklärbar, da das neue LCD-Panel nicht das Samsung-Panel ist (welches ich derzeit habe) sondern ein Teil von einem anderen Hersteller.

Jetzt bin ich mal auf Montag gespannt

Ich habe Anfang 2008 einen kleinen Server aufgesetzt. Aufgrund des beschränkten Budgets und dem Anspruch vier Netzwerkinterfaces zu haben, fiel die Wahl auf ein Asus P5BP-E/4L. Eigentlich ein sehr nettes Board. Da ich mich auf Festplatten nicht mehr verlasse, verwendete ich ein RAID aus zwei Festplatten. Es bot sich die Raid-Funktionialität des Intel ICH7R Chipsatzes an.
Die Installation war ein wenig umständlicher (initrd-Image nötig), aber irgendwann lief es dann.

Am Freitag kamen dann die Nagios-Meldungen: eine Platte ist ausgefallen und die Load schoss auf über 200 - der Server war nicht mehr erreichbar. Vor Ort erstmal per Sysrq einen halbwegs sauberen Reboot ausgelöst und über die Bios-Meldung gewundert: die RAIDs auf den zwei Platten sollten angeblich ok sein. Ein Boot funktionierte dann auch aber ein anschliendes Auslesen der HDD mit dd führte zu einem erneuten Crash. Also stand fest, dass die Platte kaputt ist und sie wurde ausgebaut. Mangels direktem Ersatz sollte der Server erstmal wieder online gehen. Das Bios meldete korrekterweise, dass das RAID1 degraded ist und das RAID 0 nicht verfügbar - kein Problem da auf dem RAID 0 nur Temp-Directories und der Squid-Cache liegt.
Allerdings kam der Boot nicht weit - direkt im initrd wurde das Mapper-Device nicht gefunden. Mit der Shell fand ich dann schnell heraus, dass dmraid Probleme hatte:

ERROR: isw: unsupported map state 0x2 on /dev/sda for System

Fazit: Intel Software-Raid ist jetzt nach Promise auf meiner persönlichen Blackliste - jedenfalls was Linux angeht. Der Controller ist jetzt auf AHCI runterstuft und demnächst kommt da ein Linux Software-RAID drauf..

Am Montag habe ich mit dem Vorgesetzten telefoniert.. Dieser hat mir zugesagt spätestens am Dienstag eine Mail zu schicken. Da das nicht geschehen ist, musste ich heute wieder anrufen..
Leider konnte ich ihn nicht direkt erreichen, so dass er jetzt nur einen Hinweis bekommt, dass ich noch auf Antwort warte..

Dann habe ich dann auch gleich die Mailadresse der Beschwerdeabteilung erfragt...

Heute habe ich dann mal wieder bei Dell angerufen (nachdem wieder kein Rückruf erfolgt ist).

Der Vorgesetzte, den ich dann am Telefon hatte, meinte, dass kein technischer Defekt vorliegen könnte, da Dell alle Teil "genaustens überprüft, ansonsten würde die Komponente nicht rausgehen".
Außerdem meinte er, dass es eine Spezifikation für das Gerät gibt, in der auch die Systemlautstärke beschrieben ist. Und das weitere Vorgehen wäre abhängig davon, ob die Komponente unterhalb der zugelassenen Systemlautstärke lärmt...

Diese Spezifikation konnte er aber auf die schnelle nicht finden, schickt sie mir aber heute, spätestens morgen. Mal sehen ob er das einhalten kann.

Ansonsten habe ich eine fachliche Eskalation gefordert - es soll sich mal jemand das Gerät ans Ohr halten, der Ahnung von der Hardware hat.

Die Geschichte geht also weiter..

Soeben habe ich wieder bei Dell angerufen.
Man erinnere sich an den erwarteten Rückruf. Da dieser bis heute nicht stattgefunden hat und online der Vorfall als geschlossen markiert war, hab ich mal wieder angerufen.

Nach fünf Minuten Wartemusik habe ich dann einen Techniker bekommen, der dafür sorgte, dass sich der für den Fall zuständige Techniker bei mir meldete (fünf Minuten später klingelte mein Handy).

Leider waren seine Aussagen nicht so erfreulich:

[..] wirklich am Design und dann können wir es nicht ändern.

und

Wenn wir ihn [den Inverter] schon zweimal getauscht haben, können wir es leider nicht ändern

Auf die Aussage von mir, dass es auch der Techniker gehört hat (und deswegen ja den Fall eigentlich offen lassen wollte) und er doch mal ein Testgerät ans Ohr halten könne, meinte er, dass er in einem Großraumbüro sitzt und man dort sowas nicht hören kann.
Fazit ist nun, dass er das Problem eskaliert und ich heute oder morgen einen Rückruf eines Vorgesetzten bekomme.

Apropos Eskalieren: beim selben Techniker habe ich mich über die 40€ für das LCD-Bezel beschwert und er hat es an das "Solution Center" weitergegeben (dort musste ich das LCD-Bezel bestellen). Diese haben aber noch kein Statement abgegeben, "er will aber nochmal Druck machen".

Eben war der Techniker da und hat mir bis auf das eigentliche LCD-Display wieder den gesamten oberen Teil getauscht. Diesmal waren die Pins zum Einrasten nicht verbogen. Dafür ist aber der Inverter immer noch hörbar. Jetzt warte ich auf den Rückruf von Dell um das weiter zu klären...

Wer das ganze mal unter Linux ausprobieren will:

Für Fragen siehe dellLcdBrightness --help

Ich berichte dann weiter..

Eigentlich lief das neue Notebook die ganze Zeit ohne Probleme. Aber schon bei meinem Review damals, merkte ich schon an:

Ich hoffe mal, dass die Qualität aus Polen an die vorherige Qualität aus Irland rankommt.

Auch beim Testbericht für die Dell-Homepage schrieb ich damals:

Fazit: Das E6500 ist ein guter Nachfolger des D830. Allerdings muss sich zeigen inwiefern die Stabilität und Verarbeitung den Arbeitsalltag überstehen.

Seit einiger Zeit habe ich aber nicht mehr soviel Freude am Notebook. Eines Tages stellte ich fest, dass mein LCD-Bezel angebrochen. Auch auf der anderen Seite gab es einen Riss im LCD-Bezel.



Ich hatte allerdings keine Ahnung wie es zu diesem Defekt kam. Aber kein Problem dachte ich, mir ist das Gerät nicht heruntergefallen (außerdem ist es auf der Innenseite) und ich behandele das E6500 nicht so, dass sowas brechen sollte. Also habe ich beim Dell-Support angerufen. Wohlgemerkt - ich habe den ProSupport gebucht. Das sollte eigentlich für einen guten Support sorgen.
Leider war die erste Reaktion des Technikers auf meine Aussage, dass da was gebrochen wäre und ich ihm ein paar Fotos geschickt habe, dass ich das Gerät mit Sicherheit falsch behandelt habe und dafür die Garantie nicht aufkommen würde. Und außerdem, ich habe ja nicht CompleteCare gebucht - da wäre das ja alles kein Problem. Ich konnte ihn nicht überzeugen, dass ich vom Support anderes gewöhnt wäre und er bot mir an, ein "Out of Warranty Repair" Angebot erstellen zu lassen. Nach einiger Zeit in der Warteschleife, bekam ich eine Mail mit dem Angebot. Der Preis war erstmal unfassbar: 144 € ohne Märchensteuer für den Austausch eines Stück Plastiks.
Der hohe Preis erklärt sich dadurch, dass ich das Teil nicht austauschen dürfte und da ein Techniker vorbeikommen muss. Also habe ich erstmal das Angebot nicht wahrgenommen. Nach ein paar Tagen kam dann ein Briefumschlag mit der angeforderten Schraube für das DVD-Laufwerk. Allerdings fehlte die Schraube - diese wurde sauber aus dem Brief rausgedrückt


Ein paar Tage später dann stellte ich beim Arbeiten nachts fest, dass mein Notebook ein leichtes Brumen/Pfeifen von sich gibt. Das hatte ich bislang nicht gehört, weil ich immer in Räumen war wo noch ein anderes Gerät lief, dass das Notebook übertönt hatte. Nach einer kleinen Suche stellte sich heraus, dass es das Display bzw. der Inverter war. Auf voller Helligkeitsstufe war nichts zu hören und die Tonhöhe varierte mit der Helligkeitsstufe.
Im Laufe der Nacht nervte mich das immer mehr und ich rief am nächsten Morgen wieder beim Support an. Diesmal gab es kein Problem und es war schnell klar, dass ich einen Techniker inkl. Ersatzteil bekomme. Da sowieso der Techniker das LCD-Bezel abmontieren muss, habe ich mir ein Angebot über das LCD-Bezel einzeln erstellen lassen und akzeptierte Zähne-Knirschen die 40 € Kosten (wieder ohne Märchensteuer). Ersatzteil und Techniker kamen dann am nächsten Tag in die FH und der Umbau konnte beginnen.
Bei der Montage des neuen LCD-Bezels kam dann heraus, dass das neue Ersatzteil verbogen war. Wiederrum hier ein Bild - das alte LCD-Bezel unten und oben das neue. So konnte das neue LCD-Bezel natürlich nicht korrekt einrasten und saß nicht korrekt:


Auf der einen Seite konnte der Techniker das noch passend biegen, aber auf der anderen Seite war das kaum möglich.

Also rief dieser bei Dell an und erklärte das Ersatzteil als DOA (Dead on arrival). Wohlgemerkt: der Techniker musste über zehn Minuten in der Warteschleife hängen... Am nächsten Tag sollte dann erneut ein Techniker kommen und er verabschiedete sich. Als dann am nächsten Tag kein Techniker mich für ein Termin angerufen hat, rief ich beim Dell-Support an und hakte nach. Dort hieß es dann, dass es am Vortag nicht korrekt vermerkt wurde, dass erneut ein Technikereinsatz nötig ist und der Fall deswegen geschlossen wurde... Die Aussage war dann, dass am nächsten Tag ein Techniker kommen sollte. Am nächsten Tag jedoch das gleiche Spiel. Weiterhin hatte ich über Nacht festgestellt, dass auch der neue Inverter wieder hörbar ist sobald das Display gedimmt wird.
Ich hatte das Glück, dass ich dieselbe Person wie am Vortag am Telefon hatte. Dieser schickte mir auch morgens eine E-Mail, dass er nochmal das Problem beschrieben haben müsste. Nach fünfzehn Minuten Telefongespräch bekomme ich nun am Montag (hoffentlich) einen Techniker. Dieser soll dann Inverter sowie das LCD-Bezel austauschen. Weiterhin soll die Schraube für das DVD-Laufwerk diesmal in einem gepolsterten Briefumschlag rausgeschickt werden. Ich bin gespannt wie das weitergeht.


Aber jetzt kommt das beste: während ich an diesem Blogartikel schreibe, kommt ein Kommilitone rein, der sich das kleinere Modell gekauft hat - das Dell Latitude E4300. Dort auf sein Gerät geschaut, stellte sich heraus, dass dort exakt derselbe Schaden vorliegt. Und er hatte es bislang noch nicht mal gemerkt.

Aus diesem Grund kämpfe ich jetzt auch noch darum die 40€ für das LCD-Bezel zurückzubekommen.

Update: ich habe noch jemanden gefunden dessen LCD-Bezel gebrochen ist: