UCS – Probleme mit Board Controller

Neuerdings habe ich vereinzelt B-Server, bei denen sich der Board-Controller nicht richtig funktioniert. Speziell bei neu eingebauten Systemen läuft der Discovery-Prozess nicht vollständig durch. Es gab schon Fälle, in denen laut Cisco UCSM eine unbekannte CPU verbaut war oder nicht die vollständige Menge Arbeitsspeicher angezeigt wurde. Etwas Forschungsarbeit war nötig, bis auffiel, dass der Board-Controller der jeweiligen Server keine Firmware-Version hatte.

Ist das Blade noch keinem Service Template zugeordnet und/oder greift das Default Firmware Package nicht (wie bei mir), kann man über die Firmware-Ansicht eine Version auswählen und aktivieren.

Firmware Übersicht

]1

Dabei ist es in erster Linie egal, ob es sich um die aktuellste Version handelt. Hauptsache der Controller wird zum Arbeiten überredet und der Discovery-Prozess läuft problemlos durch.

Manuelle Aktivierung des Updates

]2

Ein Reboot des Cisco Blades ist nötig.

Reboot des Servers

]3

Nach dem initialen Firmware-Flash konnte man mit dem Blade problemfrei arbeiten und ein Service-Template zuordnen. Es muss dazu erwähnt werden, dass ich auf der Version 2.2.5(a) bin. Das ist derzeit das einzige Problem mit dieser Version. Andere UCS-Admins raten derzeit von der Benutzung ab – siehe hier.

UCS – Festplattendaten durch UCSB-MRAID12G unter SLES auslesen

Unter manchen Szenarien kann oder muss man B-Series-Server im UCS mit lokalen Festplatten lassen. In den neuen B200 M4 neue RAID-Controller verbaut. Genauer gesagt, der Cisco FlexStorage 12G SAS RAID (UCSB-MRAID12G).

UCS - Local Raid

UCS - Local HDD

Hier haben sich (wie fast schon üblich) die Werte geändert. Mit smartctl kann man den Controller scannen.

# smartctl --scan
/dev/sda -d scsi # /dev/sda, SCSI device
/dev/bus/0 -d megaraid,4 # /dev/bus/0 [megaraid_disk_04], SCSI device
/dev/bus/0 -d megaraid,5 # /dev/bus/0 [megaraid_disk_05], SCSI device

Es handelt sich noch immer um eine Variante des MegaRaid. Mit der Erweiterung des „-d“ gelangt man über das Raid auf die einzelne Platte. Im dargestellten Fall handelt es sich um ein Raid mit zwei Platten.

Continue Reading

Shellshock Bug – Bash selbst kompilieren

shellshock_logo Hier ein Beitrag, wie man sein Bash-Binary selber neu erstellt, um es gegen den Shellshock Bug abzusichern. In meinem Beispiel habe ich das für SLES10SP2 gebaut zu einem frühen Zeitpunkt, als es von Suse noch keine passenden Updates zur Verfügung gestellt wurden. Jetzt ist das zum Glück anders aber vielleicht hat der eine oder andere ein altes System, zum es keine Updates in rpm- oder pkg-Format gibt. Der Ablauf sollte dann ähnlich sein. Eventuell muss die passende Bash-Version genutzt werden. Bis zur Version 2.05b gibt es Patches auf dem Ftp-Server.

Vorausetzung

  • wget
  • curl
  • tar
  • make
  • gcc compiler
  • passende Bash-Quelldateien inkl. Patches von GNU.org
  • sollte beim Kompilieren eine Fehlermeldung auf das Fehlen von yacc hinweisen, dann einfach das Paket bison nachinstallieren

Ablauf

(1) Check ob die Sicherheitslücke existent ist – mit Sicherheit 🙂

# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

(2) Welche Version von Bash ist installiert? Hier die Version 3.1

# rpm -qa|grep bash
bash-3.1-24.26.20
# bash --version
GNU bash, version 3.1.17(1)-release (x86_64-suse-linux)
Copyright (C) 2005 Free Software Foundation, Inc.

(3) Die Quelldateien für die Bash-Version 3.1 herunterladen und in einen Arbeitsordner entpacken

# mkdir /opt/bash-fix && cd /opt/bash-fix
# wget https://ftp.gnu.org/pub/gnu/bash/bash-3.1.tar.gz
# tar -xvzf bash-3.1.tar.gz
# cd bash-3.1/

(4) Patches herunterladen und in den Quellcode verbauen. Hier sollte man vorher kurz prüfen, wie viele Patch-Dateien vorrätig sind. Bei 3.1 sind es zum Zeitpunkt der Artikelerstellung 23, bei Version 3.2 sogar 57 Patchdateien. Das kann man mit curl und patch manuell für jede Datei einzeln machen….

testserver:/opt/bash-fix/bash-3.1 # curl http://ftp.gnu.org/pub/gnu/bash/bash-3.1-patches/bash31-001 |patch -p0
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2708  100  2708    0     0  11824      0 --:--:-- --:--:-- --:--:-- 2644k
patching file parse.y
patching file patchlevel.h

…oder mit zwei kleinen for-schleifen. Irgendwie war ich nicht im Stande, die Sache mit der führenden Null richtig zu verbauen, daher zwei Schleifen 🙁

for j in {1..9}; do curl http://ftp.gnu.org/gnu/bash/bash-3.1-patches/bash31-00$j| patch -p0; done
for j in {10..23}; do curl http://ftp.gnu.org/gnu/bash/bash-3.1-patches/bash31-0$j| patch -p0; done

Continue Reading

Mit biosdevnames eth0 zurück holen

Vor einiger Zeit schrieb ich etwas über SLES11 auf Dell-Servern und davon, dass die bekannte, erste Netzwerkkarte nicht mehr eth0 heißt. Nun bin ich mit kurz dazu gekommen, mich mit Redhat7 zu befassen und hier gibt es standardmässig auch so etwas zu finden. Dabei muss es nicht einmal ein Server von Dell sein, es reicht schon eine virtuelle Maschine unter VMware um beispielsweise mit ip addr show eine en01877732 oder ähnlich angezeigt zu bekommen.

Nun gibt es auch hier mehrere Möglichkeiten dieses neue Naming zu unterbinden, welches (wenn man die ganze Geschichte im Detail betrachtet) eigentlich nur bei Servern mit vielen Netzwerkports Sinn macht oder wenn man diese 10GbE-Adapter verbaut hat, die sich partitionieren lassen.

Variante 1 – Bei der Installation

Wie bereits beschrieben in der Zeile mit dem append ... initrd.img ein biosdevname=0 einfügen. In der Kickstart-Datei selbst soll auch -biosdevname funktionieren. Das habe ich nicht ausprobiert.

Variante 2 – Nach der Installation

Hier ist etwas mehr zu tun. Hier muss man eine Zeile im Grub2 erweitern. Dazu in /etc/default/grub gehen und in der Zeile GRUB_CMDLINE_LINUX folgende Parameter ergänzen:

net.ifnames=0 biosdevname=0

Dabei ist auf zwei Sachen zu achten. Erstmal müssen die Parameter inhalb der Anführungszeichen sein und zweitens muss die neue Konfiguration mit grub2-mkconfig -o /boot/grub2/grub.cfg neu geschrieben werden. Als nächstes ist unter den Netzwerk-Skripten die alte ifcfg-Datei umzubennen. Das geht am Besten mit:

cd /etc/sysconfig/network-scripts/ && mv ifcfg-en01877732 ifcfg-eth0

Zur Sicherheit ist noch in den udev-Regeln unter /etc/udev/rules.d/60-net.rules zu schauen, ob die MAC-Adresse der Netzwerkkarte irgendwo eingetragen hat. Wenn dem so ist, einfach die ganze Zeile löschen. Beim Reboot des Systems (der dann nötig ist) wird der Inhalt der Datei dann neu mit „eth0“ geschrieben.

In den Tiefen des Internets gibt es noch Admins, die das entsprechende Paket noch deinstallieren – musste ich jetzt nicht – yum remove biosdevname Ansonsten ist es dann soweit fertig. Zum Abschluss noch ein shutdown -r now.

Continue Reading

Homeserver für Professionals?

Nur eine Idee?! Heute bin ich durch ein Gespräch mit einem Gleichgesinnten auf einen Tower-Server aufmerksam geworden. Wir sind irgendwie über das Heimnetz auf sein neues Projekt gekommen. Ein Linux-Profi, der dicke Mengen an Daten sein eigen nennt (irgendwas im 12 TB-Bereich) und viele virtuelle Maschinen beruflich benötigt und vorhält, die ebenfalls auf dem Heimspeicher betrieben werden. Dazu noch das Übliche wie Mailservice, DNS, DHCP und alle anderen Features die Linux so bietet. Das Gerät ist 24×7 daheim als Zentrale online.

Da er, wie ich auch beruflich viel mit Servern zu tun hat, weiß er wo im Ernstfall einzugreifen ist und wie die Dinge laufen. Außerdem möchte er viel selbst installieren und nach der eigenen Auffassung konfiguieren. Auf diesem Wege fielen bei ihm die Geräte von Synology oder Qnap durchs Raster. Viel mehr geht es in Richtung des HP ProLiant ML350e in der achten Generation. Nach anfänglicher Skepsis habe ich mir das Teil etwas genauer angesehen und muss sagen, dass mir die Idee des Profi-Home-Servers durchaus gefällt.
ML350e-1
Continue Reading

Manuelles Bios-Update Dell R610 unter SLES

UpdateManchmal kommt es vor, dass Firmware-Updates für Serverkomponenten nur einzeln angeboten werden. Im Beispiel über die Update-Schnittstelle (Dell Repository Manager) wird nicht das aktuelle Firmware fürs das BIOS angeboten sonden eine Version „darunter“. Zusätzlich kommt dazu, dass das Update-Paket nur über ein installiertes Betriebssystem installiert werden kann und nicht wie gewohnt über das UEFI.
Wie funktioniert das? In meinem Fall handelt es sich um ein SLES11. Ladet die entsprechende Datei bei Dell auf den Server. Entweder per wget oder über Browser.
Als nächstes muss die Datei ausführbar sein.

# chmod +x R610_BIOS_93WDP_LN32_6.3.0.BIN

Danach die Datei starten.

# ./R610_BIOS_93WDP_LN32_6.3.0.BIN
Collecting inventory...
./biosie.bin: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory

Inventory collection failed.

Da fehlt wohl eine Bibliothek? Also im Yast das Paket libxml2 nachinstallieren und das Ganze erneut durchziehen. Continue Reading

DNS-Forwarding: query (cache) .. denied

Linux Logo
Heute einmal etwas aus der Netzwerkabteilung mit Linux-Anteil. Es ist eine Weile her, dass ich einen DNS-DHCP-Server aufzubauen hatte. Mit SLES lief das ganz gut. Allerdings hatte ich kurz am DNS-Forwarding zu knappern. Alle Anfragen, die nicht zur eigenen, internen Domain gehören, sollten „auswärts“ nachgefragt werden. Die Konfiguration ist eigentlich recht einfach. In der /etc/named.conf gibt es die Option forwarders { ip-address; }; Die IP-Adresse ist dann die des nächsten Nameservers an den oder die die DNS-Anfragen weitergereicht werden sollen, die nicht direkt beantwortet werden können. Trotz eingetragendem Server in der forwarding-Option konnten die Clients nix ausserhalb der internen Domain auflösen.

nslookup www.google.com
Server: 192.168.10.10
Address: 192.168.10.10#53

** server can´t find www.google.com: NXDOMAIN

Continue Reading

AutoYast – Skiplist für bestimmte Devices

AutoYast wird genutzt für die automatische Installation (unattended) von SLES oder OpenSuse. Dazu nutzt man ein XML-basiertes Installationsprofil, welches beim Aufruf der Installation mit angegeben wird. Die XML-Datei sich quasi kann überall befinden. Einfach auf einem Datenträger oder bei Netzwerkinstallationen auf einen Share oder unter einer Url. Der Parameter für die Lokation wird dann mittels autoyast angegeben. Nun kann es Szenarien geben, in denen man zum Beispiel ein System neu installieren muss und sicherstellen möchte, dass das Betriebssystem von vornherein auf dem richtigen Storage landet. Dies kann man beeinflussen mit einer sogenannten Skiplist. Bei Windows MDT gibt es das beispielsweise schon länger, hier erst ab openSUSE 12.2 und SLES11 SP2. Normalerweise schnappt sich bei ungenauer Spezifikation die AutoYast-Routine das zuerst gefundene Speichergerät. Das ist machmal ungesund, wenn im Anschluss eine Neuformatierung folgend sollte. Continue Reading

SMART-Infos von Platten hinter an meinem Dell PERC-H-Controller

Hängen die Platten hinter einem Raid-Controller, ist der SMART Disk Monitoring Daemon in der Regel nicht so kommunikativ hinsichtlich der SMART-Infos der Platten.
Perc Raid

Die Geräte sind unter /dev/sgX zu finden.  Für mein Beispiel diente ein PERC-Controller eines Dell R610-Servers mit einem Raid 1.

$ smartctl /dev/sg0 -a 

smartctl 5.39 2008-10-24 22:33 [x86_64-suse-linux-gnu] (openSUSE RPM) 
Copyright (C) 2002-8 by Bruce Allen, http://smartmontools.sourceforge.net 
Device: DP       BACKPLANE        
Version: 1.07 
Device type: enclosure 
Local Time is: Wed Sep 19 12:25:04 2012 

CEST Device does not support SMART Error Counter logging not supported 
Device does not support Self Test logging

Continue Reading

LVM2 – LV Status NOT available

Heute hatte ich mal einen Bare-Metal-Restore vor mir. Fehler kann es immer mal geben. Gut wenn man ein Backup hat.  Mit einer kleinen SystemRescueCD auf Basis von Linux geht das in der Regel ganz gut.
* Das System mit hochfahren mit Stick oder Scheibe
* Filesysteme und LVM mounten
* Notwendige Dateien restoren
* Reboot und läuft Diesmal war es jedoch anders. Das LVM lies sich nicht einhängen…

Continue Reading