Der neue Server ist up und ich entjungfere ihn mal direkt mit einem “LECK MICH AM ARSCH – WARUM???” – Blogeintrag.

Ich sitze auf der Arbeit, richte, wie ich es sicher schon dutzende Male gemacht habe, ein Heartbeat mit DRBD ein und sehe (erstmals unter Lucid Lynx) folgendes beim starten einer Filesystem-Ressource im Log:

…
ResourceManager[8524]:  2010/08/11_20:39:08 info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd1 /server/data/nfs reiserfs defaults,acl,rw start
Filesystem[8840]:       2010/08/11_20:39:08 INFO: Running start for /dev/drbd1 on /server/data/nfs
FATAL: Module scsi_hostadapter not found.
…

Worauf lässt es sich zurückführen? Man lese und staune:

Zitat aus Datei “/usr/lib/ocf/resource.d/heartbeat/Filesystem”, Zeilen 404 bis 408:

if [ "X${HOSTOS}" != "XOpenBSD" ];then
# Insert SCSI module
# TODO: This probably should go away. Why should the filesystem
# RA magically load a kernel module?
$MODPROBE scsi_hostadapter >/dev/null

So, Masterfrage: Was passiert, wenn ein Kernel das Modul scsi_hostadapter nicht oder nicht als Modul kompiliert hat (so wie es, nebenbei bemerkt, beim Standardkernel von Lucid Lynx (2.6.32-24-server) der Fall ist)? Riiiiiiiiiiiiichtig: Hier wird ein Exitcode ungleich 0 generiert, und Heartbeat denkt die ganze Aktion ist fehlgeschlagen.

Das ganze lässt sich also durch auskommentieren der Zeile 408 (“$MODPROBE scsi_hostadapter >/dev/null”) beheben.

12.08.2010 – UPDATE: Scheinbar hatte ich das gestern fehlinterpretiert. Es wird zwar die “FATAL: Module scsi_hostadapter not found.” – Meldung ausgegeben, jedoch hat dieses doch keine Auswirkungen auf den Errorcode des gesamten Scriptes. Dann lag das gestern an was anderes … gnaaaahr

mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: www.xxx.yyy.zzz
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: db.002174
Read_Master_Log_Pos: 342719703
Relay_Log_File: mysqld-relay-bin.000003
Relay_Log_Pos: 6458545
Relay_Master_Log_File: db.002170
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1005
Last_Error: Error ‘Can’t create table ‘/tmp/#sql7c49_2f_0′ (errno: -1)’ on query. Default database: ‘live’. Query: ‘create temporary table tmp_gen_table like tmp_to_gen_neu’
Skip_Counter: 0
Exec_Master_Log_Pos: 620120976
Relay_Log_Space: 4109869668
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
1 row in set (0.09 sec)

Ich musste recht lange suchen. Die o.g. Datei (/tmp/#sql7c49_2f_0.ibd) wurde zwar von mysql:mysql angelegt, jedoch war sie 0 byte groß. Im MySQL – Log fand ich nur den o.g. Fehler wieder. Also schaute ich im syslog und wurde fündig:

Jan 28 12:55:22 db kernel: [495131.291630] audit(1264679722.493:141): type=1503 operation=”file_lock” requested_mask=”wk::” denied_mask=”k::” name=”/tmp/#sql7c49_2f_0.ibd” pid=7924 profile=”/usr/sbin/mysqld” namespace=”default”

Das kenne ich inzwischen: Eine Zeile mit so komischen “requested_mask=”wk::”” – Rechten kommt meistens, wenn eine Applikation an apparmor scheitert. Ich habe also der Datei /etc/apparmor.d/usr.sbin.mysqld die folgenden Zeilen hinzugefügt:

/usr/sbin/mysqld {
…
/tmp/ r,
/tmp/** rwk,
}

Schon geht’s!
Ich fand es sehr überraschend, das das /tmp – Verzeichnis (in meinem Oldschool-Linux-Hinterkopf immer als das “jeder darf – Verzeichnis” abgelegt) ebenfalls einer eigenen Zeile in der apparmor-Konfiguration bedarf. Noch verwunderlicher finde ich, das dieses unter Ubuntu (8.04 – Hardy Heron) nicht standardmäßig dort aufgenommen wurde. Immerhin ist tmpdir=/tmp die Standardeinstellung unter dieser Ubuntu-Version.

Ich hatte eben Probleme den VMware Server unter einem Ubuntu x86_64 System zu installieren. Meine Bildschirmausgabe sah wie folgt aus:

The correct version of one or more libraries needed to run VMware Server may be missing. This is the output of ldd /usr/bin/vmware:
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib32/libm.so.6 (0xf7f93000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7f8f000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7f76000)
libX11.so.6 => not found
libXtst.so.6 => not found
libXext.so.6 => not found
libXt.so.6 => not found
libICE.so.6 => not found
libSM.so.6 => not found
libXrender.so.1 => not found
libz.so.1 => /usr/lib32/libz.so.1 (0xf7f60000)
libc.so.6 => /lib32/libc.so.6 (0xf7e16000)
/lib/ld-linux.so.2 (0xf7fc6000)

This program cannot tell for sure, but you may need to upgrade libc5 to glibc
before you can run VMware Server.

Auf dieser Seite habe ich die Lösung gefunden:

Man muss das Paket “ia32-libs” nachinstallieren. Nun klappt alles

Unter Debian und Debian-artigen Linux Distributionen ist das Syntax Highlighting standardmäßig deaktiviert. Ist auch gut so für ein Serverbetriebssystem, da manche KVM Displays auf Farben nicht so gut zu sprechen sind.
Meistens ist dieses jedoch ein Feature, das einen ungemein bei der Arbeit unterstützt.

In diesem Blog, der leider nur von registrierten Usern Kommentare akzeptiert ( was mir aber zu umständlich ist ), habe ich schnell gefunden, wie man es aktiviert:

Einfach in die Datei “/etc/vim/vimrc” die Option “syntax on” setzen. Bei Debian und Ubuntu existiert der Eintrag bereits, ist jedoch durch doppelte Anführungszeichen auskommentiert.
Das war’s schon! Beim nächsten Start von vim ist das Syntax Highlighting aktiviert.

Achtung: Auf diesem Wege gillt es global für alle User!
Userspezifisch kann man dasselbe erreichen, indem man stattdessen die Datei “.vimrc” im jeweiligen Home-Dir des Users wie oben beschrieben editiert.

Ich habe ja länger nichts geschrieben. Aufgrund der heutigen Aktion mit VMware unter Linux sehe ich mich dazu aber fast gezwungen. Das ist mal wieder _so_ schwachsinnig und typisch VMware, das muss einfach festgehalten werden:

Was ich schon kenne im Zusammenhand mit VMware Server unter Linux ans laufen bringen ist, das man irgendwie immer erst einen Kernel kompilieren muss, da die mit der Distribution mitgelieferte GCC Version in aller Regel eine andere ist, als die, mit der der ebenfalls mitgelieferte Kernel kompiliert wurde.

Zumindest war das unter meinem Debian System so.
Nun habe ich jedoch ein (k)ubuntu auf meinem Laptop und bekomme nach der Installation von VMware Server, beim starten der VMware Konsole diesen Block an Fehlermeldungen:

/usr/local/lib/vmware/bin/vmware:
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4′ not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0′ not found (required by /usr/local/lib/libstdc++.so.6)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4′ not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0′ not found (required by /usr/local/lib/libstdc++.so.6)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4′ not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0′ not found (required by /usr/lib/libstdc++.so.6)

Ich denke mir schon so .oO( … oh NO! Nicht schon wieder Kernel backen! ). Ist aber auch garnicht nötig gewesen!

Auf dieser Seite fand ich die Lösung. Sie liest sich erstmal so “… alles klar … lösche ich mal ein paar Libraries … dadurch wird’s bestimmt besser …”</ironie>. Aber: Das klappt wirklich!

Man muss nur die Datei lib/libgcc_s.so.1/libgcc_s.so.1 (im Unterverzeichnis, wo man den VMware Server installiert hat. Bei mir z.B.: /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1 ) entfernen, bzw. umbenennen. Anschliessend startet VMware ohne Probleme … kurios!