.LNX-WORLD

Einen Teamspeak 3 Server aufsetzen kann so fast ein jeder – aber wie sichert man diesen? Seit Teamspeak 3 kommt eine Datenbank anstelle des Textfiles für die Konfigurationen und Benutzerdaten zum Einsatz. Diese SQLLite Datenbank des Teamspeak 3 macht eine einfache Sicherung etwas schwieriger, da man Datenbanken nicht “online” wegsichern sollte – zumindest nicht wenn man mit der Datenbankkopie später noch etwas anfangen können möchte.

Da mir meine Teamspeak 3 Datenbank auch einmal schon um die Ohren geflogen ist, bin ich was das Backup angeht etwas sensibilisiert, auch wenn es “nur” mein kleiner eigener Teamspeak 3 Server ist. Und wenn man sich schon hinsetzt und ein Backup Script schreibt, kann man doch auch gleich ein paar Mechanismen einbauen, welche regelmässig prüfen ob der Teamspeak 3 Server überhaupt läuft – und gegebenenfalls diesen auch gleich neu startet.

Ziel des Scriptes ist also zum einen eine regelmässige Datensicherung (einmal die Woche) des Teamspeak 3 Servers inklusive der Datenbanken, Files und Binaries, zum anderen eine kleine Überwachung.

Ich bin mittlerweile auch ein großer Freund von Syslog Servern geworden – also sollte mein kleines Teamspeak 3 Backup auch nicht in ein eigenes Logfile loggen, sondern gleich ins Syslog!

TS3BACKUP Features:

• Teamspeak 3 Server Backup
• Repository mit Wochensicherungen des ganzen Jahres
• Watchdog ob der Teamspeak 3 Server online ist
• Restart Funktionalität
• Syslog Anbindung

TS3BACKUP Installationanleitung:

Schritt 1: Script downloaden, auf den Server entpacken und das Script direkt in das Teamspeak 3 Server Verzeichnis speichern.

Schritt 2: Das Script hat im oberen Bereich lediglich ein paar Settings die gemacht werden müssen (Pfad zur Teamspeak Installation, gewünschter Backuptag, gewünschte Backupuhrzeit sowie gewünschter Zielpfad zum Backupstorage.

Schritt 3: Verzeichnis erstellen, in welches die Teamspeak 3 Backups geschrieben werden sollen.

Schritt 4: Cronjob für root erstellen – ich habe einen Cronjob im 5-Minuten Takt für mein Teamspeak Backup erstellt, damit ich falls der Teamspeak Server mal absturzt nicht mal angerufen werde – er startet ja von selbst binnen 5 Minuten neu (und diese 5 Minuten warten die meisten bevor sie mich anrufen :) )!

Offene Punkte:

• sudo Integration, damit der Teamspeak 3 Server nicht mehr als Root laufen muss.
• FTP Target Option als Repository für die Datensicherungen
• Option für optionales eigenes Logfile

Downloadlink zur aktuellen Version: Teamspeak 3 Backup & Watchdog Script (64)

LINUX ONLY!!! Dieses Script funktioniert nur unter Linux!!!
Bisher getestete Distributionen:

• Ubuntu Server 10.04 64 Bit LTS
• CentOS 5.3

Bei Wünschen oder Anmerkungen – jederzeit an mich wenden!  Setzt ihr mein Script ein, bitte zumind. einen kleinen Kommentar hinterlassen, schön wären auch ein paar Infos zur verwendetes Scriptversion, Teamspeakversion und eurer Distribution.

Ich letzter Zeit bon ich selbst immer wieder in die gleiche Falle gegangen: Route für ein bestimmtes Netz auf einem Server hinzugefügt (für meinen Zugriff via VPN) und nach einem Reboot – alles wieder weg, ergo keinen direkten Zugriff mehr. Und alles nur weil ich zu faul war mir zu merken wie ich permanente statische Route in Ubuntu erstelle. Das soll sich nun ändern – ich schreibe wie so oft einfach einen Blog dazu – und schon ist es unauslöschlich in meinem Kopf. Hier also:

HowTo: Permanente Routen unter Ubuntu Linux

Für ein Netzwerk eine Route zu erstellen ist ja (fast) allgemein bekannt, aber damit wir in diesem Artikel alle über das gleiche Netz sprechen, hier mein Beispiel für die Route die ich permanent hinzufügen möchte und nach jedem Reboot auch immer gleich online haben will:

route add -net 192.168.101.0 netmask 255.255.255.0 gw 192.168.1.1 dev eth0

Zu Deutsch: Alle Anfragen an und von IPs aus dem netzbereich von 192.168.101.1 bis 192.168.101.255 sollen über das Gateway 192.168.1.1 abgewickelt werden. Das Gateway ist über das Netzwerkinterface eth0 zu erreichen.

Wenn man dies nun so in die Konsole haut, funktioniert die Route gleich und sofort (sofern keine Tippfehler drin sind). jedoch ist diese Route nach einem Reboot wieder weg – und genau das wollen wir ja nicht, wir wollen einen permanente statische Route für dieses Netzwerk!

Um diese statische Route nun permanent zu machen, müssen wir die Datei “/etc/network/interfaces” editieren – ganz unten sammel ich meine Routen um die Übersichtlichkeit zu bewahren.

Wir ergänzen einfach die obige Zeile leicht ergänzt und angepasst:

up route add -net 192.168.101.0/24 gw 192.168.1.1 dev eth0

Mehr ist wirklich nicht zu tun – eine Route also nicht gleich hier einzutragen ist wahrlich nur Faulheit.

Aber hier nochmal kurz der Syntax für die Route:

up route add [-net|-host] / gw  dev

Welche Netzmaske ihr habt, solltet ihr wissen – wenn nicht, habt ihr ganz andere Probleme :)

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.

Ich habe so einige PDF Dokumente, welche regelmässig in Intranetseiten oder in das SAP integriert werden. Leider gab es selten eine schöne Thumbnailgrafik zu dem jeweiligem Dokument – was die Suche nach einigen Dokumenten erschwerte, bzw. optisch nicht so schön war.

Praktisch war nur, das alle PDF Dokumente an einem zentralem Ort abgelegt sind und werden. So kam dann auch die Idee zu dem nachfolgendem Script, welches den als $SOURCE definierten Ort nach PDF Dokumenten durchsucht, zu welchen dem Namen nach noch kein Thumbnail im $TARGET Ordner existiert. Wenn kein Thumbnail zu einem Dokument existiert, wird aus der ersten Seite des PDF via ImageMagick ein Thumbnail erzeugt und unter $TARGET abgelegt. Der Name des Thumbnails entspricht dabei dem Namen des PDF, nur die Dateiendung ist logischerweise .jpg statt .pdf.

Unter $DENSITY und $QUALITY kann die Qualität des jpg Thumbnails noch eingestellt werden, die Grösse ist über den Parameter “-geometry x200″ im Imagmagickkommando fest auf 200 pixel Breite eingestellt. Die Höhe wird automatisch ermittelt, damit nihts verzerrt wird, selbst wenn das Quelldokument  kein DIN A4 hat.

Script:

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

#!/bin/bash
#set -x
###########################################################
###
### Variablen Definition
###
###########################################################
SOURCE=/pub/scan
TARGET=/pub/scan
DENSITY=50
QUALITY=65
 
###########################################################
###
### Script
###
###########################################################
 
cd $SOURCE
for i in `ls *.pdf`; do
        FILE=`/bin/echo $i | /bin/sed 's/pdf/jpg/'`
        ANAME=`/bin/echo $i | /bin/sed 's/.pdf//'`
        if [ -f $TARGET/$ANAME.jpg ]; then
                /bin/echo "JPEG to $i exists, skipping file"
        else
                /usr/bin/convert -geometry x200 -density $DENSITY $SOURCE/$i[0] -colorspace rgb -quality $QUALITY $TARGET/$FILE
        fi
done

Damit auch automatisiert der $SOURCE Ordner brav auf neue PDF gescannt wird, sollte das Script optimalerweise im Cron stehen. Nach meiner Erfahrung reichen 3-4 Läufe pro Tag auch locker aus…

Verbesserungsvorschläge oder gar Korrekturen nehme ich gerne als kleinen Kommantar entgegen. Ebenso gern gesehn ist die Weiterverlinkung dieser Seite ;)

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