.LNX-WORLD

Um einen zeitgesteuerten Aufruf / Start eines Scriptes oder Programmes unter Linux auszulösen (unter Linux heisst dies dann cronjob), bedint man sich der Crontab (so heißt im übrigen auch das Programm welches diese Crontabeinträge nachher abarbeitet). Jeder User hat so eine, mit die Wichtigste ist jene, welche sich unter /etc/crontab befindet. Hier schreibe ich fast alle Cronjob´s rein die auf meinem System laufen sollen, also genau solche Jobs wie SQL Datenbankdumps, Datensicherungen, Dienstneustarts, Benachrichtigungsscripts über Systemupdates, etc.

# m h dom mon dow user  command
17 *    * * *   root    /usr/local/cronjob1.sh
25 6    * * *   root    /usr/local/cronjob2.sh

Oben habe ich mal die ersten 3 Zeilen aus meiner Crontab eingestellt… Wie man erkennen kann, teil sich jeder Eintrag / Cronjob für eine Aufgabe in viele Spalten. In dem erstem 5 Spaltigen Bereich, welcher die Zeiten steuert, zu denen der Cronjob ausgeführt werden soll, stehen zuerst die Minute(n), dann die Stunde(n), der Tag, der Monat und der Wochentag. In der nächsten Spalte steht der Benutzer unter dem der Cronjob ausgeführt werden soll, gefolgt von dem Aufruf des zu startenden Programmes inklusive aller Optionen.

Die Crontab eines normalen Benutzers sieht etwas anders aus

# m h dom mon dow command
17 *    * * *   /usr/local/meinscript --optionen

Quasi das Gleiche, jedoch ohne die Spalte vom Benutzer / User, da normale Benutzer nur unter ihrem eigenem Namen Cronjob´s starten dürfen. Auch editiert der Benutzer seine Crontab nicht mit der /etc/crontab, sondern mit dem Kommando “crontab -e”. Ansehen kann man sich seine Cronjob´s mittels “crontab -l”. Dieser Weg ist dem meinem auch eindeutig zu bevorzugen!

Um diesen doch sehr gewöhnungsbedürftigen Sytax mal zu erklären, ein paar Beispiele dazu:

Um ein Script zum Beispiel jede Minute auszuführen müsste der Cronjob wie folgt aussehen:

* * * * *   /usr/local/meinscript --optionen

Wenn das Script alle 15 Minuten laufen soll, also zu jeder 15ten Minute und jeder Stunde, sähe der Cronjob so aus:

*/15 * * * *   /usr/local/meinscript --optionen

Cronjob für ein Script welches genau jeden morgen um 06:00 Uhr ausgeführt werden soll:

0 6 * * *   /usr/local/meinscript --optionen

Cronjob um ein Script jeden morgen zwischen 6 Uhr und 9 Uhr alle 15 Minuten zu starten:

*/15 6-9 * * *   /usr/local/meinscript --optionen

Cronjob f+r ein Script das genau am Heiligabend um 18 Uhr laufen soll:

0 18 24 12 *   /usr/local/meinscript --optionen

Cronjob für ein Scriptdas welches jeden Montag morgen laufen soll:

* * * * 1   /usr/local/meinscript --optionen

Beim letztem Beispiel wird der Wochentag als Zahl angegeben. Gültig hierfür sind die Zahlen 0-7, wobei die 0 und die 7 für den Sonntag stehen – Bitte nicht verzählen!

Folgende Situation tritt ab und zu auf und wirft bei den Administratoren der Server Fragen über Fragen und vor allem Probleme auf:
Die Netzwerkkarte musste ausgetauscht werden und nun ist die neue Netzwerkkarte, oder Ethernetadapter, nicht mehr eth0 wie zuvor sondern statt dessen eth1. Seit der Einführung von udev ist das Problem da und eigentlich auch sehr leicht zu lösen, wenn man weiß wie! Hier die Lösung:

In der Datei /etc/udev/rules.d/70-persistent-net.rules steht folgendes über die im System vorhandenen (oder ehemals vorhandenen Netzwerkadapter drin:

# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.

# PCI device 0x15ad:0x0720 (vmxnet)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:aa:65:82", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:aa:4d:27", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Wie man hier relativ leicht sehen kann, ist der Name des Netzwerkadapters direkt an diese Einträge gekoppelt. Aus der ID auf dem PCI Bus und der Mac-Adresse ergibt sich auch ein eideutiges Merkmal für jeden Adapter.

Probleme in diesem Bereich hatte ich schon bei den Szenarien das die als etho erkannte karte eigentlich eth1 sein sollte, oder als Szenario 2 wie Eingangs beschrieben das die Karte eth1 eigentlich die Austauschkarte für eth0 ist.

Lösung Szenario 1: Die Namen sind vertauscht / nicht richtig sortiert
Hier sollte man sich die Datei /etc/udev/rules.d/70-persistent-net.rules in einem Editor seiner Wahl öffnen und den String NAME=”eth0″  etc. einfach umschreiben. Nicht vergessen die Datei zu speichern und vor dem editieren eine Sicherungskopie anzufertigen! Nach einem Reboot sind die Karten in der gewünschten Reihenfolge.

Lösung Szenario 2: Die nun eth1 genannte Karte hat die ehemalige eth0 ersetzt
Noch einfacher geht es quasi kaum… Zuerst eine Sicherungskopie der /etc/udev/rules.d/70-persistent-net.rules anfertigen, anschließend muss man nur /etc/udev/rules.d/70-persistent-net.rules noch löschen (ja, wirklich löschen) und dann rebooten – Schon ist eth1 wieder eth0, da die Datei bei jedem Bootvorgang angelegt wird, sollte sie nicht existieren und die Netzwerkkarten in der Reihenfolge eingetragen werden, in welcher sie vom System gefunden werden.

Netzwerkkonfiguration per Kommandozeile
Gerade heute habe ich wieder mal von einem Kunden die Anfrage bekommen, wie er denn seine Netzwerkkonfiguration an seinem Linux Server ändern kann – schließlich habe er ja gar keine GUI zum konfigurieren der eth Interfaces zur Verfügung und ein Yast gibt es auf Debian Systemen (zum Glück) auch nicht. Schnell hatte ich ihm per Telefon erklären können wie er als Beispiel eth0 unter Debian konfigurieren kann – das die Netzwerkkonfiguration unter Linux so einfach “zu lesen” ist, wollte er mir zu Anfang gar nicht glauben.

Da dies abermals ein Thema ist, welches mir öfter mal begegnet, denke ich das es an der Zeit ist hier auf meinem Blog die Konfiguration der IP Adressen auf die eth Interfaces von Debian basierenden Linuxsystemen zu erklären (ja, Ubuntu ist auch ein “Debian Derivat”)

Statische IP Adresse auf eth0 vergeben
In der Datei /etc/network/interfaces muss nur das nachfolgende eingetragen / konfiguriert werden, dabei dürfen jedoch keine Einträge die mit lo Interface zu tun haben entfernt oder geändert werden. Lo ist der sogenannte Loopbackadapter und für den Betrieb des Systems zwingend so wie er da steht erforderlich!

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.2
gateway 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

Zuer Erklärung: “auto eth0″ steht für einen automatischen Start des Interface beim booten. Wenn dieser Eintrag fehlt, müsste man das Interface eth0 von Hand aktivieren, was manchmal schwer fällt, wenn zum Beispiel der Server nur über Netzwerk erreicht werden kann (wie bei Root Servern oder anderen entfernten Servern der Fall).
“address” ist die IP Adresse die auf das eth0 Interface gelegt werden soll.
“gateway” steht für das default Gateway und ist für ein sauberes Routing unabdinglich – es sei denn man definiert es im nachhinein per Hand nach.
“netmask” steht für die Netzmaske – was das ist erkläre ich später mal – von seinem Provider (bei Root Servern) erhält man diese Angabe meist mit, bei einem LAN Server ist die Netzmaske meist wie hier im Beispiel 255.255.255.0 – sprich ein Class C Netzwerk von 192.168.1.0 bis 192.168.1.255 (wobei hier die .0 und .255 reserviert sind und nicht verwendet werden dürfen, siehe “network und “broadcast”)
“network” definiert nochmal das Netz in dem sich der Server befindet – wobei hier die vereinfachte Schreibweise verwendet wird.
“broadcast” am besten hier nachlesen:  7070

In der Datei /etc/resolv.conf wird nun definiert über welche DNS Server, oder auch Nameserver, dieNamensauflösung stattfinden soll und über den Eintrag “search” wird definiert in welcher Domain Linux suchen soll, wenn bei einem Serverrequest kein Domainname mit angegeben wird.

search domain.local
nameserver 192.168.1.1

IP Adresse für eth0 über DHCP
Hier muss ebenfalls natürlich das eth0 definiert werden, die Werte für die IP Adresse etc kommen aber über den DHCP Server, man braucht sie also nicht mit eintragen. Einfacher als eine DHCP IP Adress Konfiguration geht es, wie man sieht, kaum noch.

# The primary network interface
auto eth0
iface eth0 inet dhcp

Zweite IP Adresse auf ein Netzwerk Interface legen
Wenn die zweite IP Adresse statisch vergeben werden soll, kann man dies durch sogenannte virtuelle Interfaces machen. Dazu wird die Konfiguration des physikalischen Interfaces quasi kopiert und hinter den Namen einfach ein :Nr gehängt. Im Falle von ETH0 würde das erste virtuelle Interface also beispielsweise so aussehenen:

# The primary network interface - second IP address
auto eth0:1
iface eth0:1 inet static
address 192.168.1.3
gateway 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

Für eine zweite IP Adresse für eth0 über DHCP sieht das dann wie folgt aus:

auto eth0:1
iface eth0:1 inet dhcp

Weblinks:

http://www.debianadmin.com/ubuntu-networking-for-basic-and-advanced-users.html

Um die VMware Tools unter Debian Etch zu installieren, müssen nur ein paar Kleinigkeiten vorbereitet werden. Zuerst muß man hier die Grundlage schaffen, um die VMware Tools zu kompilieren und die nötigen Kernelmodule zu bauen. Sprich wir brauchen die nachfolgenden Pakete:

1

aptitude install autoconf automake make psmisc gcc

Um die Kernelmodule bauen zu können brauchen wir zusätzlich noch diese nachfolgenden Pakete:

1

aptitude install linux-headers-`uname -r` build-essential

Bei den Linux Kernel Headers wird durch das “uname -r” gleich der für den auf dem System aktive Kernel Headerkram geladen – so das hier nicht erst geprüft werden muss, welcher Kernel denn anliegt (und da gibt es ja reichlich Auswahl). Vor der eigentlichen Installation der obigen Pakete sollte ein

1

aptitude update

ausgeführt werden, ich schreibe das hier extra nochmals rein, da es oftmals vergessen wird.

Nun können wir uns an die eigentliche Installation der VMware Tools machen. Also via VMware die entsprechende CD “einlegen” und dann via

1

mount /dev/cdrom /mnt

die CD mounten und somit zugreifbar machen. Anschließend kopieren wir das VMware Tools tar.gz rüber, am besten in ein temporäres Verzeichnis – ich nehme hierfür gerne /root/tmp

1
2
3

mkdir /root/tmp
cp /mnt/ /root/tmp/
cd /root/tmp

Nun kann das Archiv mit den VMware Tools entpackt werden und dann das Script für die Installation angeworfen werden:

1
2
3

tar xvzf VMwareTools-X.X.X.XXXX.tar.gz
cd vmware-tools-distrib
./vmware-install.pl

Die Fragen des Script brav durcharbeiten und dann die ganze Geschichte beobachten ob alles glatt geht. Abschließend ist leider ein Reboot erforderlich, aufgrund der neuen Netzwerktreiber sowie der neuen Kernelmodule. Fragen und Anmerkungen können gern als Kommentar hinterlassen, ich freu mich über jede Anregung wie etwas vielleicht besser oder einfacher geht.

Ziel
Um die Zugriffe auf die Festplatte/Flashkarte zu minimieren, soll das Log-Verzeichnis /var/log beim Starten in den RAM geschrieben werden.
Beim ausschalten und reboot muss mit der HD syncronisiert werden. Weiter muss es möglich sein in bestimmten Abständen und auch manuell bzw. per Script zu syncronisieren.

Mit tmpfs lässt sich das alles recht komfortabel umsetzen.

Vorbereitung

Kernel

Im Kernel muss FS Unterstützung im RAM aktiviert sein.

Symbol: TMPFS

Location:
-> File Systems
   -> Pseudo Filesystems

Sync-Verzeichnis

Man muss ein Verzeichnis anlegen, in dass syncronisiert wird und aus dem beim Systemstart die Dateien in den RAM geladen werden.

mkdir /var/log.hd

fstab

Diese Zeile hinzufügen:

tmpfs    /var/log    tmpfs    size=100M    0 0

Wir mounten damit /var/log in einen reservierten Bereich des Arbeitsspeichers.

init-Scipt

Folgendes Script unter /etc/init.d/varlogfs speichern:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/bin/sh
 
PATH=/bin:/usr/bin:/sbin:/usr/sbin
TMPFS_DIR="/var/log/"
HDD_DIR="/var/log.hd/"
 
case $1 in
        start)
                echo "sync hdd to tmpfs.."
                /bin/cp -Rpv $HDD_DIR* $TMPFS_DIR
                echo "done."
                ;;
        sync)
                echo "sync tmpfs to hdd.."
                /bin/cp -Rpv $TMPFS_DIR* $HDD_DIR
                echo "done."
                ;;
        stop)
                echo "sync tmpfs to hdd.."
                /bin/cp -Rpv $TMPFS_DIR* $HDD_DIR
                echo "done."
                ;;
        *)
                echo $"usage: $0 {start|sync|stop}"
                exit 1
                ;;
esac
 
exit 0

Das init-Script sollte logischerweise vor allen Diensten gestartet werden, die nach /var/log schreiben. Außerdem muss es beim Herunterfahren am Schluss ausgeführt werden, um das das Dateisystem zu syncronisieren.

ln -s /etc/init.d/varlogfs /etc/rc2.d/S9varlogfs
ln -s /etc/init.d/varlogfs /etc/rc3.d/S9varlogfs
ln -s /etc/init.d/varlogfs /etc/rc5.d/S9varlogfs
ln -s /etc/init.d/varlogfs /etc/rc0.d/K99varlogfs
ln -s /etc/init.d/varlogfs /etc/rc1.d/K99varlogfs
ln -s /etc/init.d/varlogfs /etc/rc6.d/K99varlogfs

Unter Debian geht auch:

update-rc.d varlogfs defaults 9 99

Beim nächsten Neustart ist das Log-Verzeichnis im Arbeitsspeicher.

Manuell syncronisieren kann man mit:

/etc/init.d/varlogfs sync