Watchdog script to supervise /proc/user_beancounters

I’m in the process of setting up my new server. The services are running inside OpenVZ-Containers. The Problem is, that you don’t know how to setup the resource parameters. You have to walk the way of trial and error, because you don’t how much resources the services consume under productive load.

After migrating some domains, my postfix process died last night because of a lack of pirvvmpages. So I wrote a script that monitors changes in /proc/user_beancounters of every container. The script runs from crontab every 5 minutes and compares UBC failcounter values to the last known values. If there is a difference, a mail is sent to root.

Feel free to re-write the script in your favorite language 😉

#!/bin/sh
# get running VEs
VES=`vzlist -H -o veid`
MAILFILE=/var/run/ubcWatchdog_mail.txt
 
# check every running VE
for VE in $VES; do
  # create file if it does not exist
  NEWFCFILE=/var/run/ubcWatchdog_$VE.new.txt
  OLDFCFILE=/var/run/ubcWatchdog_$VE.txt
  touch $NEWFCFILE
  touch $OLDFCFILE
 
  # save current failcounter
  vzctl exec $VE 'cat /proc/user_beancounters' | cut -b 13-129 | sed 's/ \+/ /g' | awk {'print $6 "\t"  $1'} > $NEWFCFILE
 
  # compare to reference failcounter
  diff -U 0 -d $OLDFCFILE $NEWFCFILE > /dev/null
  if [ $? != 0 ]; then              
    # yepp, something failed
    echo "****************************************" >> $MAILFILE
    echo "UBC fail in VE $VE!" >> $MAILFILE
    diff -U 0 -d $OLDFCFILE $NEWFCFILE | grep "^[+,-][a-z,A-Z,0-9]\+" >> $MAILFILE
    echo "****************************************" >> $MAILFILE
    echo "" >> $MAILFILE
    echo "UBC now:" >> $MAILFILE
    vzctl exec $VE 'cat /proc/user_beancounters' >> $MAILFILE
  fi
 
  # save new failcounter as reference
  mv $NEWFCFILE $OLDFCFILE
done;
 
# send mail to root
if [ -f $MAILFILE ]; then
  mail -s "UBC Fail!" root < $MAILFILE
  rm $MAILFILE
fi

The mail looks like this:

****************************************
UBC fail in VE 20!
-205 kmemsize
+59936 kmemsize
****************************************

And is the result of a fork-bomb that exploded inside VE 20 🙂

dovecot deliver – Fatal: postmaster_address setting not given

It took me an hour to figure out the reason for this message. The only hint is, that there might be special characters like tabs in the config file. But in my case, the reason was the dovecot-postfix package of Ubuntu 9.10.

There are two config-files: /etc/dovecot/dovecot-postfix.conf and /etc/dovecot/dovecot.conf. The header says:

# If there's a file /etc/dovecot/dovecot-postfix.conf, which is part of
# dovecot-postfix package, it will be used instead of dovecot.conf.
 
# Keep in mind that, if that file exist, none of the changes in
# /etc/dovecot/dovecot.conf will have effect on dovecot's configuration.
# In that case you should customize /etc/dovecot/dovecot-postfix.conf.

The problem: dovecot’s deliver command ignores dovecot-postfix.conf and reads it’s config from /etc/dovecot/dovecot.conf 🙁

Ok, how to fix this? Open /etc/postfix/master.cf and specify the configfile using the -c parameter of the deliver-command:

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -c /etc/dovecot/dovecot-postfix.conf -f ${sender} -d ${recipient}

See bug #511295.

pam-ldap: I have no name! (ubuntu)

Ich bin gerade über einen blöden Fehler gestolpert, den ich nicht noch einmal machen möchte… Ich habe an pam und ldap geschraubt und plötzlich konnten Gruppen und User-IDs nicht mehr aufgelöst werden:

groups: cannot find name for group ID 1000
I have no name!@vz10:~$

In einem nahezu identischen System ging es ohne Probleme. Ein Vergleich der beiden /etc-Verzeichnisse hat keine Auffälligkeiten gezeigt. Nachdem ich drauf und dran war, das System wegzuschmeißen und neu aufzusetzen, habe ich doch noch die Lösung gefunden:

/etc/ldap.conf muss für alle User lesbar sein. Ich hatte testweise ein Bind-Password eingetragen und aus diesem Grund die Rechte der Datei eingeschränkt. Ein einfaches

chmod 644 /etc/ldap.conf

hat das Problem gelöst 🙂

Debian Lenny auf einem Rootserver mit Raid-1 und LVM

Das ist ein Update zu meiner alten Anleitung. Der Unterschied zur alten Anleitung:

  • Dieses Mal soll ein Server unter Debian Lenny eingerichtet werden
  • Swap liegt ebenfalls im Raid
  • Der Server soll mit OpenVZ virtualisierte Maschinen hosten
  • Das root-Dateisystem soll ebenfalls im LVM liegen, damit wir beim Backup konsistente Snapshots vom gesamten System machen können

Hier also das Update zu meiner rundum-sorglos copy&paste-Anleitung zur Einrichtung von

Debian Lenny auf einem Rootserver mit Raid-1 und LVM

„Debian Lenny auf einem Rootserver mit Raid-1 und LVM“ weiterlesen

OpenLDAP Replikation mit syncprov

Für einen neuen Server in unserer Rootserver-Kommune brauche ich eine Replik unseres LDAP-Servers. Wie sich herausstellte, ist das ziemlich einfach und in der umfangreichen Dokumentation exzellent erklärt.

Im zu replizierenden LDAP-Server („Provider“) muss man lediglich dafür sorgen, dass das syncprov-Modul in der slapd.conf geladen wird:

modulepath      /usr/lib/ldap
moduleload      back_hdb
moduleload      syncprov

Im Zielserver („Consumer“), wird so eine 1:1 Replikation des Quellservers konfiguriert:

# replication settings
syncrepl rid=001
    provider=ldaps://ldaps.yourdomain.de:636
    type=refreshAndPersist
    searchbase="dc=yourdomain,dc=de"
    schemachecking=on
    type=refreshAndPersist
    retry="60 +"
    bindmethod=simple
    binddn="cn=replicator,dc=yourdomain,dc=de"
    credentials=assword

Natürlich müssen im Quellserver entsprechende Credentials hinterlegt werden. Durch das Keyword refreshAndPersist bleibt die Verbindung dauerhaft bestehen und Änderungen im Quellserver werden sofort auf dem Zielserver repliziert.

Achtung: im Zielserver müssen natürlich die gleichen Schemata geladen sein, wie im Quellserver. Schaut euch also die Include-Section entsprechend an, sonst hagelt es Fehler.

Mit dieser Methode kann man den LDAP-Server super-komfortabel umziehen, einfach Replikation einschalten, DNS-umschwenken und dann die Replikation auf dem Zielserver ausschalten.