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.

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.

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.

Bei einem Kernelupdate eines SLES 10 SP3 Gastsystems auf einem SLES 11 SP1 XEN Host
kam es bei mir, während der letzten Kernelupdates in den DomUs vor,
das ich erst von PV auf HVM und nun wieder auf PV wechseln mußte
damit die virtuellen Maschinen wieder booten konnten.

Das erste Update war von 2.6.16.60-0.62.1 auf 2.6.16.60-0.66.1
und dann kam das heutige auf die Version 2.6.16.60-0.67.1

Nach dem einspielen des letzten Updates kamen meine DomUs nicht mehr hoch.
Ein ‘xm list’ zeigte einen normalen status. Ein Versuch die Console der VM
zu öffnen mittels ‘xm console <domain>’ wurde mit folgendem Fehler abgebrochen:

xenconsole: Could not read tty from store: No such file or directory

Ein neustart des xend und auch ein reboot des gesamten Hostsystems hat
nicht geholfen, da mein erster Verdacht in Richtung xenconsoled ging hatte
ich dies zuerst versucht. Leider bis hierher vergebens.

Dann erinnerte ich mich das ich beim Kernelupdate davor auf HVM wechseln
mußte damit meine DomUs wieder hoch kamen. Also war der nächste Schritt
diese Umstellung rückgängig zu machen.
Das ganze klappte auf Anhieb und alle VMs laufen nun wieder paravirtualisiert.

Gestern hat Novell das Service Pack 1 für SUSE Linux Enterprise 11 offiziell zugänglich gemacht. Sowohl neue ISO Images als auch die nötigen Updatepakete werden verteilt.

Die neue Version bringt neben XEN 4.0 nun auch KVM mit und läuft mit einem aktualisierten Kernel 2.6.32.

Die wichtigsten Links im Netz:
Novell Announcement
How to update