vmmemctl unter Ubuntu

Mit den Vmware-tools und Ubuntu 12.04 kann es unter ungeklärten Umständen ein Problem geben. Das vmmemctl Modul wird nicht richtig installiert bzw. kompiliert. Beim Kompilieren der Vmware-tools  nach einem Kernel Update erscheint die Meldung:

The module vmmemctl has already been installed on this system by another installer or package and will not be modified by this installer. Use the flag –clobber-kernel-modules=vmmemctl to override.

Das führt dazu das der Kernel Thread vmmemctl nicht läuft,  weil das Modul vmmemctl fehlt. Das Modul dient dazu nicht mehr benötigten Speicher wieder freizugeben um ihn anderen VMs zur Verfügung zu stellen. Zum testen einfach mal auf der VM

$ ps aux|grep vmmemctl

eingeben. Abhilfe schafft ein

vmware-config-tools.pl –clobber-kernel-modules=vmmemctl,vsock,vmxnet3,vmci,pvscsi

Die anderen Module mit rein zunehmen schadet nicht. Die tauchten bei mir auch als Meldung beim kompilieren auf. Danach sollte  der Prozess angezeigt werden.

$ ps aux|grep vmmemctl
root     30933  0.0  0.0      0     0 ?        S    13:57   0:00 [vmmemctl]

Hat man eine größere ESX Struktur kann ein Fehlen des Moduls durchaus einen spürbaren Einfluss auf die benötigte Hardware haben ;-).

Mehr Informationen dazu  findet man z. B. unter http://yuridejager.wordpress.com/2012/02/27/enable-the-vmware-balloon-driver-vmmemctl-to-prevent-swapping-in-an-imported-linux-vm/

p.s. bei den open-vm-tools gibt es kein vmmemctl Modul.

Probleme nach libvirt Update

Sollte man bei KVM  mit Portweiterleitung für VMs (z.B.  iptables -t nat -A PREROUTING -p tcp -d 123.123.123.123 –dport 1234 -j DNAT –to-destination 192.168.99.99:22) arbeiten und folgende Debian Updates eingespielt haben:

[UPGRADE] libvirt-bin 0.8.3-5+squeeze2 -> 0.8.3-5+squeeze5
[UPGRADE] libvirt0 0.8.3-5+squeeze2 -> 0.8.3-5+squeeze5
[UPGRADE] python-libvirt 0.8.3-5+squeeze2 -> 0.8.3-5+squeeze5

Nach dem Einspielen aber bemerkt haben man , dass die Portweiterleitung nicht mehr funktioniert und man auch durch erneutes Eintragen der iptables/routing oder was auch immer für Regeln keinen Erfolgt erzielt, dann könnte tatsächlich ein Reboot des Hosts helfen.

längerer Kurztipp: Schutz gegen einfache DOS Attacken mit mod_evasive

Ein alter Hut, ich kannte es bis heute nicht. Mit mod_evasive kann man einfache DOS Angriffe blocken. Getestet mit dem guten, alten Squeeze.

$ apt-get install libapache2-mod-evasive
$ a2enmod mod-evasive
$ zless /usr/share/doc/libapache2-mod-evasive/README.gz
$ mkdir /var/log/mod_evasive
$ chown www-data /var/log/mod_evasive
$ ln -s /usr/bin/mail /bin/mail

$ joe /etc/apache2/mods-available/mod-evasive.conf

<ifmodule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSLogDir /var/log/mod_evasive
DOSEmailNotify thisis@waste.land
DOSWhitelist 127.0.0.1
</ifmodule>

$ ln -s /etc/apache2/mods-available/mod-evasive.conf /etc/apache2/mods-enabled/mod-evasive.conf
$ /etc/init.d/apache2 reload

Zum testen einfach mal irgendeine Seite aufrufen und ein paar mal schnell F5 drücken bis man ein 403 Forbidden erhält. Dann im logdir schauen und eigentlich sollte man auch eine mail bekommen. Im syslog sollte ein Eintrag der Art
Mar 14 11:36:15 webserver  mod_evasive[15723]: Blacklisting address 123.123.123.123: possible DoS attack
aufauchen.
Mit DOSSystemCommand kann man noch einen Befehl definieren, der ausgeführt werden soll wenn eine IP geblockt wird, also z.B. iptables Regel zum sperren der IP („sudo /sbin/iptables -A INPUT -s %s -j REJECT„) oder was auch immer.
Die Meinungen zum Einsatz von mod_evasive gehen etwas auseinander, daher sollte man es erst mal  unter Beobachtung laufen lassen und am besten vorher mal ein bisschen googlen.
Zusammen mit HAproxy oder Nginx als Reverseproxy funktioniert mod_evasive nicht. Da kann man sich  mal das Nginx Modul HttpLimitReq anschauen. mod_evasive blacklisted zwar die IPs, mehr aber leider nicht.

Links:

http://www.linux-magazin.de/Ausgaben/2005/12/Friede-im-Indianerland

http://pc-freak.net/blog/secure-apache-against-basic-denial-of-service-attacks-with-mod_evasive-on-debian/

http://spielwiese.la-evento.com/xelasblog/archives/56-Apache-DOS-Attacken-erschweren-mit-mod_evasive.html

Bugfix Release für Galera

Es gibt ein Galera Update. Primär ein Bugfix Release. Ein neues Feature klingt aber recht viel versprechend:

„Plus new experimental feature: weighted quorum (lp:1010225). Weight can be an integer in the range 0-255. Nodes with zero weight don’t participate in quorum calculation. By default all nodes have weight 1.“

http://www.codership.com/content/mysql-wsrep-5529-2373-and-galera-2324-released

Updaten lief ohne Probleme.

ioioio makes the server slow

Arbeitet man mit Virtualisierung (ESX, KVM & Co) sollte man auf den VMs immer den iowait im Auge haben. Egal was die Hostmaschinen an schönen  Daten ausgeben, hat die VM einen zu hohen iowait gibt es früher oder später Probleme. Ich nutze dafür den check_cpu_stats  Check von Steve Bosek für Nagios. Der Check liefert  noch einige Daten mehr. Als Ergebnis bekommt man in etwa Folgendes:

$ /usr/lib/nagios/plugins/check_cpu_stats.sh -w 20 -c 40
CPU STATISTICS OK : user=0.50% system=1.01% iowait=3.27% idle=95.21% nice=0.00% steal=0.00% | CpuUser=0.50;CpuSystem=1.01;CpuIoWait=3.27;CpuIdle=95.21;CpuNice=0.00;CpuSteal=0.00;20;40

Bei Debian&Co sollte sysstat installiert sein. Mit den Zahlen lassen sich  schöne Grafiken bei Centreon erzeugen:

loadwait

Hinweise auf bessere Checks sind natürlich willkommen.