Genauso unabdingbar wie Liebe und guter Wein für Goethe waren, sind Cron und Logrotate das Lebenselixier für jeden Serveradmin. Vielleicht etwas übertrieben formuliert, aber auch nur fast. 🙂 Als "normaler" Linuxnutzer kommt man nur sehr selten direkt mit den beiden in Berührung, da in der Regel einfach alles läuft.
Nur am Rande bemerkt: Wer an Debians und Ubuntus "Popularity Contest" teilnimmt und ihn nicht auf einem Server laufen lässt, sollte auf jeden Fall noch anacron installiert haben, da das Senden der Berichte zu wechselnden Tageszeiten erfolgt und man unter Umständen den Rechner dann nicht eingeschaltet hat, weswegen der Cron-Job nicht ausgeführt werden kann.
Im Gegensatz zu Anacron arbeitet Cron präzise zu einem bestimmten Zeitpunkt Aufträge ab und setzt damit voraus, dass der Rechner kontinuierlich verfügbar ist. Im Zusammenspiel mit Logrotate, das Logdateien nach einem vorgegebenen Zeitintervall verschieben und komprimieren kann, ist er äußerst wichtig und nützlich für jeden Server.
Logrotate-Beispiel anhand von OpenArena
Der OpenArena-Server speichert den Verlauf der Spiele in der Logdatei games.log. Hierfür habe ich eine neue Konfigurationsdatei in /etc/logrotate.d/ angelegt, die wie folgt aufgebaut ist.
/home/openarena/.openarena/baseoa/games.log { daily missingok rotate 14 compress delaycompress notifempty create 644 openarena openarena sharedscripts postrotate if [ -x /usr/sbin/invoke-rc.d ]; then invoke-rc.d oa_ded restart > /dev/null 2>&1; else /etc/init.d/oa_ded restart > /dev/null 2>&1; fi; endscript }
Die Syntax ist sehr logisch.
- Wann soll rotiert werden? Alternativen sind weekly und monthly
- Sollte die Logdatei nicht vorhanden sein, ignoriere den Fehler und gehe zur nächsten Datei.
- Wie oft werden Logdateien rotiert? In diesem Fall werden für jeden Tag für insgesamt 14 Tage Logdateien vorgehalten. Am 15. Tag würde also die älteste Logdatei überschrieben werden. Wäre z.B. weekly und rotate 8 eingestellt, würde die Logdatei jede Woche für insgesamt 8 Wochen rotiert.
- Um Platz zu sparen sollten die Dateien mit gzip komprimiert werden.
- Verzögere die Kompression um einen Rotationszyklus, da manche Programme noch in die letzte Logdatei schreiben können. Dadurch ist games.log.1 immer unkomprimiert.
- Wenn die Datei leer ist, soll gar nichts gemacht werden.
- Eine neue games.log wird automatisch mit den Dateirechten 644 und Benutzer und Gruppe openarena erzeugt.
- Normalerweise wird die Anweisung prerotate und postrotate bei jeder Logdatei ausgeführt, also wenn anstelle von games.log z.B. eine Wildcard wie *.log angegeben worden wäre. In diesem Fall nicht entscheidend, sondern nur zur Sicherheit.
- Mit dem letzten Kommando postrotate kann eine Aktion nach der durchgeführten Logrotation ausgeführt werden. In meinem Fall starte ich danach den Server immer neu. Das hat den zusätzlichen Vorteil, dass eventuell durch Spieler geänderte Servervariablen wieder auf die Standardwerte zurückgesetzt werden. Für den Teeworlds-Server war ein Neustart sogar notwendig, da er ansonsten nicht in die neue Logdatei geschrieben hat.
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 644 openarena openarena
sharedscripts
Weitere Ideen und Anregungen finden sich im Verzeichnis /etc/logrotate.d/ und natürlich mit man logrotate. Die Konfigurationsdatei für logrotate ist /etc/logrotate.conf.
Cron in Kürze
Cron ist das Herzstück jedes Servers. Er arbeitet zeitgesteuert alle Shellskripte in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly und /etc/cron.monthly ab und wertet die Informationen in /etc/crontab und den jeweiligen crontabs aus. Cron muss nicht neugestartet werden, wenn eine Einstellung verändert wird.
In meiner /etc/crontab habe ich z.B so etwas stehen:
05 7 * * * openarena /usr/local/bin/oa_stats_daily.sh > /dev/null 2>&1
Hier wird mit den Rechten des Benutzers openarena ein kleines Skript ausgeführt, welches die täglichen Statistiken um 7 Uhr und fünf Minuten für OpenArena generiert.
Mehrere Beispiele für Cron aus der Wikipedia:
#M S T M W Befehl 5 * * * * /usr/bin/message.sh #Befehl wird fünf Minuten nach jeder vollen Stunde aufgerufen. */5 * * * * /usr/bin/message.sh #Befehl wird alle 5 Minuten aufgerufen (die Schrittweite wird durch */Schrittweite angegeben). 59 23 * * 0 gzip /var/log/messages #Befehl wird einmal pro Woche sonntags um 23:59 Uhr ausgeführt. 0 0 * * * gzip /var/log/auth.log #Befehl wird täglich um 00:00 Uhr ausgeführt. 20,30 1 * * 1-5 /usr/bin/work.sh #Befehl wird montags bis freitags jeweils um 01:20 und 01:30 ausgeführt. 0 1 1-7 12 1 /usr/bin/work.sh #Befehl wird am 1. bis 7. Dezember sowie an jedem Montag im Dezember um ein Uhr nachts ausgeführt.
Aus Sicherheitsgründen kann man die Erlaubnis für Cron-Jobs einschränken, indem eine Datei /etc/cron.allow mit den berechtigten Benutzern angelegt wird. (Ein Name pro Zeile). Ansonsten darf jeder Benutzer mit Eingabe von crontab -e seine eigenen Aufträge anlegen.
Cron bietet damit neben seinen typischen Aufräum- und Prüfarbeiten die Möglichkeit eigene Skripte zeitlich gesteuert auszuführen. In Zusammenspiel mit Logrotate lassen sich so ganz leicht Statistiken für den Spieleserver generieren, sofern das Spiel diese überhaupt mitloggt. Zu dem genauen Inhalt des Skripts ein anderes Mal mehr.
Links
http://de.wikipedia.org/wiki/Cron
http://linux.die.net/man/8/cron
http://www.debian-administration.org/articles/56
Wie kann ich eigentlich die Ausführungszeit täglicher Cronjobs, wie bsdmainutils anpasen?
Tägliche cronjobs wie bei bsdmainutils lassen sich in /etc/cron.daily/ anpassen.