carsten’s blog

Nachdem Microsoft/Skype anfang August 2014 diverse Skype User – vorallem im Linux Bereich – ausgesperrt hat (Zwang zu neuer Skype Version), hatte ich mich erstmal von Skype verabschiedet. Bei mir lief bis zuletzt Version 2.2.0.35 und ich war damit absolut zufrieden.

Alle neueren Versionen waren nicht mehr mit der SUSE Linux Enterprise 11 Serie zu vereinen, da ein neueres QT verlangt wird. Nachdem meine Skypekontakte kaum dazu zu überreden sind sich für Alternativen zu begeistern habe ich mir dann doch etwas Arbeit gemacht
und ein QT Paket in Version 4.7 erstellt, welches Parallel und ohne weitere Systemauswirkungen installiert
werden kann und es somit ermöglicht die aktuellste Skype Version auch unter SLE 11 zu nutzen.

Hier nun die nötigen Schritte

Repository für QT 4.7 hinzufügen

user@host:~> zypper ar -f http://download.obs.j0ke.net/home:/netmax:/playground/SLE_11_SP3/ home:netmax:playground

qt-4.7 Pakete installieren (wird unter /opt/qt-4.7 installiert)

user@host:~> zypper -n in opt-libqt4-47-32bit opt-libqt4-47-qt3support-32bit opt-libqt4-47-sql-32bit opt-libqt4-47-sql-sqlite-32bit opt-libqt4-47-x11-32bit

Pulseaudio Pakete installieren sofern nicht vorhanden

user@host:~> zypper -n in pulseaudio pulseaudio-module-x11 pulseaudio-module-zeroconf pulseaudio-utilspulseaudio-lang

Aktuelle Skype Version herunter laden und installieren

user@host:~> sudo wget http://www.skype.com/go/getskype-linux-beta-suse -O /root/skype-4.3.0.37-suse.i586.rpm
user@host:~> sudo rpm -ivh /root/skype-4.3.0.37-suse.i586.rpm

Skype Startscript anlegen

user@host:~> mkdir -p ~/bin
user@host:~> cat > ~/bin/skype << EOF
#!/bin/bash
LD_LIBRARY_PATH=/opt/qt-4.7/lib/ /usr/bin/skype
EOF

user@host:~> chmod +x ~/bin/skype

Gegebenenfalls die .desktop Dateien / Applikationslinks auf das neue Script in ~/bin/skype verweisen lassen damit auch Starts per Icon Klick funktionieren.

Kürzlich war ich auf der Suche nach Monitoringvorlagen für Cacti um die Werte welche seitens der OPENBSD-PF-MIB bereitgestellt werden zu überwachen. Leider bin ich nicht fündig geworden und habe daher selbst entsprechende Data, Graph und Hosttemplates erstellt.

Daraus entstanden sind zwei Graphen:

State table Überwachung (Anzahl der States, Inserts, Removes & Searches)

State drop Causes (alle Möglichen Gründe welche zu einem State drop geführt haben können)

Erstellt wurden die Templates mit cacti in Version 0.8.8b in Verbindung mit OpenBSD 5.4 und snmpd.

  cacti-templates_openbsd-pf.zip (21.1 KiB, 6,726 hits)

Während einiger Wartungsarbeiten und einem damit verbundenen Kernelupdate auf die derzeit
für SLES 11 SP2 aktuelle Kernel Version 3.0.80 bin ich auf einen Fehler in Verbindung mit DRBD gestoßen.

Das Update selbst liefert keine neuen drbd kmp Pakete mit, sondern verwendet weiterhin eine Vorgängerversion (8.4.2_3.0.51_0.7.9-0.6.6.4)

Der Fehler äußert sich direkt beim Laden des drbd Moduls mit folgender Meldung:

[ 154.173134] events: mcg drbd: 3
[ 154.174916] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 154.174927] IP: [] cleanup_module+0xb0/0x150 [drbd]
[ 154.174949] PGD 7927f8067 PUD 7a0a83067 PMD 0
[ 154.174954] Oops: 0000 [#1] SMP
[ 154.174959] CPU 7
[ 154.174960] Modules linked in: drbd(+) crc32c libcrc32c ip6table_filter ip6_tables iptable_filter ip_tables x_tables nbd usbbk netbk blkbk blkback_pagemap blktap xenbus_be gntdev evtchn mpt2sas scsi_transport_sas raid_class mptctl mptbase ipmi_devintf ipmi_si ipmi_msghandler dell_rbu(X) bridge 8021q garp stp llc bonding microcode fuse loop dm_mod joydev bnx2 usbhid hid sg ses enclosure sr_mod 8250_pnp ipv6 ipv6_lib pcspkr tpm_tis tpm tpm_bios i2c_piix4 i2c_core dcdbas(X) k10temp domctl 8250 serial_core rtc_cmos serio_raw button acpi_power_meter ohci_hcd ehci_hcd usbcore usb_common sd_mod crc_t10dif scsi_dh_hp_sw scsi_dh_alua scsi_dh_rdac scsi_dh_emc scsi_dh xenblk cdrom xennet edd ext3 mbcache jbd fan processor ata_generic pata_atiixp ahci libahci libata megaraid_sas scsi_mod thermal thermal_sys hwmon
[ 154.175039] Supported: Yes, External
[ 154.175041]
[ 154.175044] Pid: 12110, comm: modprobe Tainted: G X 3.0.80-0.5-xen #1 Dell Inc. PowerEdge R515/03X0MN
[ 154.175050] RIP: e030:[] [] cleanup_module+0xb0/0x150 [drbd]
[ 154.175064] RSP: e02b:ffff88079e8efef8 EFLAGS: 00010203
[ 154.175066] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 154.175069] RDX: fffffffffffffff8 RSI: ffff88079e8eff0c RDI: ffffffffa04fe600
[ 154.175072] RBP: ffff88079e8eff0c R08: 0000000000000000 R09: 0000000800040008
[ 154.175075] R10: 0000000100030008 R11: 0000001800010006 R12: ffffffffa0508000
[ 154.175078] R13: 0000000000000000 R14: 0000000000623230 R15: 0000000000000000
[ 154.175084] FS: 00007f92fdf3a700(0000) GS:ffff8807c14e0000(0000) knlGS:0000000000000000
[ 154.175088] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 154.175090] CR2: 0000000000000000 CR3: 00000007a793c000 CR4: 0000000000000660
[ 154.175094] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 154.175097] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 154.175100] Process modprobe (pid: 12110, threadinfo ffff88079e8ee000, task ffff880792438580)
[ 154.175103] Stack:
[ 154.175105] 0000000000000000 ffffffffa04d8f05 0000000000000000 00000000fffffff4
[ 154.175110] 0000000000081dd8 ffffffffa0508085 ffffffffa04fe240 ffffffff8000403b
[ 154.175115] 0000000000000000 ffffffffa04fe240 0000000000081dd8 00007f92fdeb7000
[ 154.175121] Call Trace:
[ 154.175158] [] init_module+0x85/0x1000 [drbd]
[ 154.175177] [] do_one_initcall+0x3b/0x190
[ 154.175185] [] sys_init_module+0xcf/0x240
[ 154.175192] [] system_call_fastpath+0x16/0x1b
[ 154.175201] [<00007f92fda9635a>] 0x7f92fda96359
[ 154.175204] Code: 24 14 01 48 89 ee 48 c7 c7 00 e6 4f a0 e8 69 80 d3 df 48 85 c0 48 89 c3 75 b1 48 8b 05 ba 59 02 00 48 8d 50 f8 48 3d 20 e6 4f a0
[ 154.175228] 8b 4a 08 74 5b 48 8d 59 f8 eb 07 0f 1f 40 00 48 89 f3 48 8b
[ 154.175241] RIP [] cleanup_module+0xb0/0x150 [drbd]
[ 154.175253] RSP
[ 154.175255] CR2: 0000000000000000
[ 154.175258] —[ end trace ae9d139fe656969d ]—
[ 171.660668] IPMI System Interface driver.
[ 171.660720] ipmi_si: probing via SMBIOS
[ 171.660724] ipmi_si: SMBIOS: io 0xca8 regsize 1 spacing 4 irq 0
[ 171.660727] ipmi_si: Adding SMBIOS-specified kcs state machine
[ 171.660733] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca8, slave address 0x20, irq 0
[ 172.742032] ipmi_si ipmi_si.0: Found new BMC (man_id: 0x0002a2, prod_id: 0x0100, dev_id: 0x20)
[ 172.742111] ipmi_si ipmi_si.0: IPMI kcs interface initialized

Ich habe den Fehler dann direkt (19.06.2013) als Servicerequest bei Novell gemeldet, heute am 21.06.2013 wurde mir ein PTF bereit gestellt der das Problem behebt.
Zwischenzeitlich hatte ich ein Kerneldowngrade auf die Version 3.0.74-0.6.10.1 durchgeführt, damit meine Systeme wieder einwandfrei arbeiten.

Ursache des ganzen war folgendes:

It is because of a silent change in KABI for xen.
Which requires the drbd module to be re-compiled against the actual
kernel. Also we have found and fixed the NULL pointer dereference possibility
in drbd code.

Öffentlich soll der Fix im laufe der KW26 werden, sofern nichts größeres dazwischen kommt.

Update 25.06.2013:
Der Vorabfix wurde heute von SUSE zurück gezogen und ein komplettes Kernel Update angekündigt, da die KABI
Änderungen wohl umfangreicher ausfallen. Nach dem Update soll das alte drbd Kernel Modul wieder kompatibel sein.

Update 05.07.2013:
Ein neues Kernelupdate (SUSE-SU-2013:1151-1 / Version 3.0.80-0.7.1) wurde released, welches das Problem nun final löst.

Ich wurde gerade auf eine interessante Änderung in Redhat Enterprise 6 und seinen Ablegern aufmerksam gemacht. Wer mit den genannten Distributionen eine transparente Firewall mittels Linux Bridge & iptables bauen möchte fragt sich unter Umständen warum sein Regelwerk in der FORWARD Chain nicht greift.

Ich musste auch etwas suchen und habe dann nach ca. 10 Minuten mal in die /etc/sysctl.conf geschaut und folgendes entdeckt:

# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Hier wird für alle Netzwerkdevices die über das “bridge” Modul aktiviert werden, die iptables,ip6tables und arptables aufrufe im Kernel verhindert und der gesamte Datenverkehr kann ungefiltert passieren.

Um die bekannte Funktionsweise herzustellen reicht es die Werte einfach auf 1 zu setzen und zu aktivieren:

echo 1 >/proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 >/proc/sys/net/bridge/bridge-nf-call-arptables
echo 1 >/proc/sys/net/bridge/bridge-nf-call-ip6tables

Das nenn ich dann mal “Allow from all” im ganz großen Stil 🙂

Auf meinem Heim PC an dem eine Logitech MX5500 Tastatur/Maus (Bluetooth) Kombination hängt, habe ich mir nun openSUSE 12.1 installiert. Zuvor lief dort openSUSE 11.4. Die Installation war kein Update sondern eine Neuinstallation, da ich gleichzeitig meine Festplatte durch ein größeres Modell ersetzt habe.

Nach der Installation funktionierte allerdings weder Maus noch Tastatur. Mit einer PS/2 Tastatur und einer Kabelgebundenenn USB Maus konnte ich allerdings problemlos arbeiten. Nach einigem debuggen und suchen, war auf den ersten Blick kein Fehler erkennbar. Sowohl Maus als auch Tastatur wurden vom System erkannt, funktionierten aber trotzdem nicht.

Über Google bin ich dann im openSUSE Forum fündig geworden. Immerhin gibt es schon jemanden, der das gleiche Problem hat, also ist die chance recht hoch, das es auch eine Lösung dafür gibt. Leider aber nicht in diesem Forumthread.

Ich habe somit weiter gesucht und habe im Novell Bugtracker einen passenden Eintrag finden können der das Problem beschreibt, allerdings auch ohne eine Lösung. In dem Eintrag war allerdings eine Referenz auf einen anderen Bug, in dem das gleiche Problem ähnlich beschrieben ist, mit einem Lösungsweg der bei mir aber so nicht funktioniert hat.

Meine Lösung habe ich im Bug 731221 dokumentiert.

Am letzten Wochenende bin ich dann doch endlich einmal dazu gekommen meinen Mailserver mit einer IPv6 Adresse und entsprechenden DNS Einträgen zu versehen.

Die Software war weitestgehend für IPv6 vorbereitet, dachte ich zumindest. Gestern stellte sich heraus das doch noch ein kleiner Teil nicht mit den “neuen” Adressen klar kommt.

Ich benutze auf meinem Qmail System helodnscheck2 als qmail-spp Plugin. Die letzte Version ist aus dem Jahr 2008, da wurde IPv6 leider immernoch sehr vernachlässigt.

Ich konnte diesen Zustand so natürlich nicht beibehalten und habe mit meinen C Grundkenntnissen einen kleinen Patch zusammen bekommen der nun auch mit IPv6 Adressen klar kommt. Die gepatchte Version und auch den Patch gibt es auf meiner OSS Seite.

Eine neue Version von stresslinux basierend auf openSUSE 11.4 steht zum download bereit. Neben den Neuerungen der Basisdistribution sind auch wieder einige

zusätzliche Pakete aktualisiert worden, dazu gehören:

• busybox 1.18.4
• iperf 2.0.5
• lm_sensors 3.3.0
• lshw B.02.15
• memtest86 4.0
• memtest86+ 4.20
• mprime 2.6.5
• smartmontools 5.40.3314
• x86info 1.29
• y-cruncher 0.5.5.9179

Wie immer gibt es  ISO, USB und VMware Images zum download.

Viel Spaß beim Testen!

Bei M-Net läuft bereits seit geraumer Zeit ein IPv6 Testbetrieb an
dem man freiwillig teilnehmen kann. Support gibt es dafür allerdings
bisher nicht. Hilfe findet man allerdings im Forum.

Ich selbst habe einen Linux Router mit SLES 11 SP1 an dem ein
Standard DSL Modem hängt. Die Einwahl erfolgt mittels pppd und
pppoe und wurde initial über yast konfiguriert. In dem Router
befinden sich mehrere Netzwerkschnittstellen (eth0 – eth5) wovon ich mittels
Bridge Konfiguration eth0 – eth4 zu einem Interface br0 zusammengefasst habe.
Das DSL Modem selbst hängt an eth5. Bei der Einwahl über ppp wird dsl0 erzeugt.

Für die Nutzung von IPv6 über den ppp0 Link sind einige Anpassungen
am System nötig.

• Loginname anpassen
• Installation von wide-dhcpv6 und radvd

Der erste Punkt ist sehr einfach umzusetzen, dazu wird
in der Datei /etc/sysconfig/network/provides/provider0
in der Zeile USERNAME der Teil nach dem ‘@’ Symbol mit
“v6.mnet-online.de” ersetzt und in der Datei /etc/ppp/peers/pppoe diese Zeileangehängt.

+ipv6 ipv6cp-use-ipaddr

Der zweite Teil ist auf SLES11 etwas problematischer gewesen,
da es kein wide-dhcpv6 Paket gab. Das Standard dhcpv6 Paket
funktioniert leider nicht, es ist zwar von der Konfiguration
her ähnlich hat aber nicht den Umfang den wide-dhcpv6 bereit
stellt.

Ich habe daher ein eigenes wide-dhcpv6 Paket erstellt, welche
nun zum Einsatz kommt. Das Paket befindet sich in server:network
Repository. Das Repository wie folgt hinzufügen:

zypper ar -f http://download.obs.j0ke.net/server:/network/SLE_11_SP1/ server:network

Die Pakete im Anschluss wie folgt installieren:

zypper in wide-dhcpv6 radvd

Sollte das Paket dhcpv6 bereits installiert sein, muss die Deinstallation dieses Pakets
bestätigt werden.

Nach der Installation werden für beide Dienste Konfigurationsdateien angelegt:

/etc/dhcp6c.conf

#
# See dhcp6c.conf(5) man page for details.
#

interface dsl0 {
        send ia-pd 0;
        send rapid-commit;
        script "/usr/bin/dhcp6c-state";
        request domain-name-servers;
};

id-assoc pd 0 {
        prefix-interface lo {
                sla-id 0;
                sla-len 8;
        };
        prefix-interface br0 {
                sla-id 1;
                sla-len 8;
        };
};

/etc/radvd.conf

interface br0
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        prefix ::/64 {
                AdvOnLink on;
                AdvAutonomous on;
        };
};

Zudem ein kleines Shellscript was vom dhcp6c ausgefürht wird:
/usr/bin/dhcp6c-state

#!/bin/bash
sleep 10
/etc/init.d/radvd restart 2>&1 >/dev/null

Auf meinem Router habe ich zur Überwachung der DSL Verbindung
ein weiteres Shellscript mitlaufen, welches prüft ob dsl0 aktiv
ist und andernfalls die DSL Verbindung herstellt. Zeitgleich
werden darin auch der dhcp6c gestartet und die Defaultroute
für IPv6 gesetzt.

/usr/local/bin/keepalive.ppp

#!/bin/sh
# restart the ppp connection whenever it goes down
export PATH=/bin:/usr/bin:/sbin:/usr/sbin
export LOG="logger -p daemon.notice -t `basename $0`[$$]"

$LOG "Monitoring PPP connection"
while [ 1 ]
do

        if `ifconfig | grep -q ^dsl0`
        then
                $LOG "PPP connection ok"
        else
                $LOG "Starting pppoed"
                # set dsl modem interface to up state
                ifconfig eth5 up
                # set dsl0 to off to be sure it's really off
                ifdown dsl0
                # start dsl0 connection
                ifup dsl0
                sleep 10
                # run dhcp6 client on dsl0 interface
                killall -9 dhcp6c 2>/dev/null
                dhcp6c -c /etc/dhcp6c.conf -p /var/run/dhcp6c.pid dsl0
                # set IPv6 default route to dsl0 interface
                ip -6 ro add default dev dsl0
        fi

        sleep 30
done

Das hier gezeigte Script wird beim Booten des Systems von einem init-Script
aufgerufen. Diese script so aus:

/etc/init.d/keepalive.init

#!/bin/sh
# keepalive.ppp wrapper startup script

### BEGIN INIT INFO
# Provides: keepalive.init
# Required-Start: $network $remote_fs sshd
# Required-Stop: $network $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start the keepalive.ppp script
### END INIT INFO
. /etc/rc.status
# Shell functions sourced from /etc/rc.status:
#      rc_check         check and set local and overall rc status
#      rc_status        check and set local and overall rc status
#      rc_status -v     ditto but be verbose in local rc status
#      rc_status -v -r  ditto and clear the local rc status
#      rc_failed        set local and overall rc status to failed
#      rc_reset         clear local rc status (overall remains)
#      rc_exit          exit appropriate to overall rc status    

# First reset status of this service
rc_reset
case "$1" in
        start)
                if [ -z "`find /proc -lname "/usr/local/bin/keepalive.ppp" 2>/dev/null |awk -F/ '{print $3}'`" ]; then
                        echo "starting keepalive.ppp..."
                        /usr/local/bin/keepalive.ppp &
                else
                        echo "keepalive.ppp is already running"
                        rc_failed
                fi
                        rc_status -v
        ;;
        stop)
                echo "stopping keepalive.ppp"
                PID=`find /proc -lname "/usr/local/bin/keepalive.ppp" 2>/dev/null |awk -F/ '{print $3}'`
                if [ -n "$PID" ]; then
                        kill -9 $PID
                else
                        rc_failed
                fi
                rc_status -v
        ;;

        status)
                PID=`find /proc -lname "/usr/local/bin/keepalive.ppp" 2>/dev/null |awk -F/ '{print $3}'`
                if [ -n "$PID" ]; then
                        echo "keepalive.ppp status: "
                else
                        echo "keepalive.ppp status: "
                        rc_failed
                fi
                rc_status -v
        ;;

        *)
                echo "Usage: $0 < start | stop | status >"
        ;;
esac
rc_exit

Das init-Script kann mit folgendem Befehl für den Startvorgang dauerhaft aktiviert werden:

chkconfig keepalive.init on

Sobald die DSL Verbindunzg per ‘/etc/init.d/keepalive.init start’ gestartet wird sollten im Anschluss auf den lokalen Netzwerkschnittstellen lo0 (loopback) und br0 (interne LAN Bridge) IPv6 Adressen zu sehen sein. Bei M-Net beginnen diese mit “2001:a60:”. Damit der Linux Rechner IPv6 auch von und zum internen Netz weiter leitet muss IPv6 Forwarding aktiv sein.

Dazu wird “net.ipv6.conf.all.forwarding=1” in /etc/sysctl.conf eingetragen. Damit IPv6 forwarding sofort aktiv ist kann man es per Hand mit diesem Befehl aktivieren:

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding

Abschließend kann ich nur empfehlen, das jeder der IPv6 einrichtet sich mit einer entsprechenden Firewall ausrüstet,.da jeder PC im Netzwerk mittels einer automatisch zugewiesenen IPv6 Adresse von überall im Internet direkt erreichbar und somit auch direkt angreifbar ist.

Die letzten zwei abende habe ich damit verbracht einen merkwürdigen Fehler auf einem SLES11 System zu finden auf dem eine Asterisk Telefonanlage (1.6.2.x) mit chan_lcr läuft. Über eine HFC ISDN Karte und dazu gehörigem mISDN Treiber werden eingehende ISDN Anrufe auf SIP gebridged.
Seit dem neuesten Kernel Update kamen die Anrufe zwar noch durch, es läutet, man konnte abheben und die Verbindung war da, aber eine Sprachverbindung war nicht möglich (in beide Richtungen).
Nach langem Suchen inklusive Austausch von ISDN Kabel und HFC Karte blieb am Ende nur noch der Kernel übrig.

Im Changelog des Kernels bin ich über folgenden Eintrag gestolpert, der unter Umständen für dieses Verhalten verantwortlich ist.

* Mo Jan 17 2011 jeffm@suse.com
– patches.fixes/misdn-add-support-for-group-membership-check:
mISDN: Add support for group membership check (bnc#564423).

Dieser Eintrag brachte mich dann zu folgenden Commit

Mit diesem Patch wird ein neuer Modulparameter zu mISDN_core hinzugefügt welcher vermutlich in meiner Umgebung extra gesetzt werden muss:

parm:           gid:Unix group for accessing misdn socket (default 0) (uint)

Ich habe vorerst ein Kerneldowngrade durchgeführt, damit die Produktivität des Systems nicht weiter leidet, werde den Parameter aber noch ausprobieren.

Update: 27.03.2011

Ich hatte nun Gelegenheit den gid Parameter von mISDN_core zu testen. Mein lcr bzw. asterisk selbst läuft als Benutzer asterisk mit gid 330. Ich habe also gid=330 an modprobe mISDN_core als Parameter übergeben. Danach lcr und asterisk wieder gestartet. Alles funktioniert nun auch mit dem neuen Kernel wieder.

Seitdem wir bei InterNetX in den neueren Servermodellen in den Bereichen
wo bisher SAS6iR verbaut wurden nun auch die H200 Raidcontroller benutzen,
blieb immer wieder der Eindruck hängen das diese z.T. langsamer sind als ihre
Vorgänger. Eigentlich sollte es genau andersrum sein, denn der H200 ist
ein 6G und der SAS6iR nur ein 3G Controller.

Wie sich nun herausgestellt hat, wird beim H200 der Cache, der angeschlossenen
Festplatten deaktiviert. Dies war vor einigen Jahren auch schon beim SAS5i
Controller der Fall und konnte bis zum SAS6iR mittels dem Tool ‘lsiutil’
von Linux aus konfiguriert werden. Beim SAS6iR war der Cache allerdings
von Haus aus aktiviert, somit war dort keine Anpassung nötig.

Beim H200 funktioniert ‘lsiutil’ leider nicht mehr. Es gibt derzeit nur eine
mir bekannte Lösung die aus meiner Sicht noch etwas viel “Overhead” mit sich bringt.

Vorab wird geprüft, welchen Status der Cache hat, dazu schaut man in der Ausgabe
von ‘dmesg’ oder in /var/log/boot.log und sucht dort am besten nach “Write cache”

Finden sollte man mindestens einen Eintrag der wie folgt aussieht (Cache ist aus):

sd 0:1:0:0: [sda] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA

Sollte der Eintrag in etwa so aussehen, dist der Cache bereits an:

sd 0:1:0:0: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA

Um den Cache zu aktivieren benötigen wir OMSA (Open Manage Server Administrator) von DELL.
Dieser kann entweder direkt auf dem Server installiert werden oder mittels einer Live CD gebootet werden.

Nach der Installation auf dem Server sollte dieser Entweder neu gestartet werden
oder man muß die nötigen Dienste per Hand starten:

# modprobe ipmi_devintf
# modprobe ipmi_si
# /etc/init.d/dataeng start
# /etc/init.d/dsm_om_shrsvc start
# /etc/init.d/dsm_om_connsvc start

Der Cache kann dann entweder über das OMSA Webinterface https://<server-ip>:1311/ oder
per Console aktiviert werden.

Um die IDs von Controller & virtueller Disk zu bekommen nutzt man die folgenden Kommandos:

# omreport storage controller

Controller  PERC H200 Adapter (Slot 1)

Controllers
ID                                            : 0
Status                                        : Ok
Name                                          : PERC H200 Adapter
Slot ID                                       : PCI Slot 1
State                                         : Ready
Firmware Version                              : 07.01.33.00
Minimum Required Firmware Version             : Not Applicable
Driver Version                                : 04.100.01.03
Minimum Required Driver Version               : Not Applicable
Storport Driver Version                       : Not Applicable
Minimum Required Storport Driver Version      : Not Applicable
Number of Connectors                          : 2
Rebuild Rate                                  : 50%
BGI Rate                                      : 50%
Check Consistency Rate                        : 50%
Reconstruct Rate                              : Not Applicable
Alarm State                                   : Not Applicable
Cluster Mode                                  : Not Applicable
SCSI Initiator ID                             : Not Applicable
Cache Memory Size                             : Not Applicable
Patrol Read Mode                              : Not Applicable
Patrol Read State                             : Not Applicable
Patrol Read Rate                              : Not Applicable
Patrol Read Iterations                        : Not Applicable
Abort Check Consistency on Error              : Not Applicable
Allow Revertible Hot Spare and Replace Member : Not Applicable
Load Balance                                  : Not Applicable
Auto Replace Member on Predictive Failure     : Not Applicable
Redundant Path view                           : Not Applicable
CacheCade Capable                             : Not Applicable
Persistent Hot Spare                          : Not Applicable
Encryption Capable                            : Not Applicable
Encryption Key Present                        : Not Applicable
Encryption Mode                               : Not Applicable
Spin Down Unconfigured Drives                 : Not Applicable
Spin Down Hot Spares                          : Not Applicable

# omreport storage vdisk

List of Virtual Disks in the System

Controller PERC H200 Adapter (Slot 1)
ID                  : 0
Status              : Ok
Name                : Virtual Disk 0
State               : Ready
Encrypted           : Not Applicable
Layout              : RAID-1
Size                : 232.25 GB (249376538624 bytes)
Device Name         : /dev/sda
Bus Protocol        : SATA
Media               : HDD
Read Policy         : Not Applicable
Write Policy        : Not Applicable
Cache Policy        : Not Applicable
Stripe Element Size : 64 KB
Disk Cache Policy   : Disabled

Der Cache kann nun mit folgendem Befehl aktiviert werden.

# omconfig storage vdisk action=changepolicy controller=0 vdisk=0 diskcachepolicy=enabled

Nach nochmaligem Ausführen von ‘omreport storage vdisk’ wird der Wert ‘Disk Cache Policy’
auf ‘Enabled’ stehen. Der Cache ist sofort aktiv, es wird kein Neustart benötigt.

Es gibt noch eine weiteres Tool was direkt von LSI stammt, was aber keine Funktion
zum Einschalten des Caches hat (sas2ircu).