Server

OpenVZ unter Debian

Posted in Linux, Server on Juli 6th, 2010 by Patrick – 2 Comments

Neben verbreiteten Virtualisierungslösungen wie ESX, Xen und KVM existiert noch eine weitere, weniger verbreitete Methode:

OpenVZ ist eine Virtualisierungstechnik für Linux. Damit lassen sich mehrere so genannte Virtual Private Server einrichten, die alle den Kernel und die Hardware des Host-Systems nutzen. Das Konzept ähnelt also anderen Techniken wie FreeBSD Jails und Solaris Zones. Auch als Gastsystem unterstützt OpenVZ ausschließlich Linux. Durch eine detaillierte Ressourcenaufteilung soll es möglich sein, sehr viele virtuelle Maschinen parallel auf einem physischen Computer zu betreiben, die alle streng voneinander isoliert sind. [golem.de]

Installieren kann man OpenVZ auf viele Linux basierten Betriebssysteme direkt aus den Paketquellen; im folgenden habe ich als Beispiel ein Debian (32bit) auf meinem DL380 G3 verwendet.

Zuerst müssen die passenden Kernel und Pakete installiert werden:

1
apt-get install linux-image-openvz-686 vzctl vzquota cstream

Leider ist das Tool vzdump nicht mehr in den Paketquellen enthalten, ist aber essentiell um eine virtuelle Maschine im laufenden Betrieb zu sichern:

1
2
3
cd /tmp/
wget http://download.openvz.org/contrib/utils/vzdump/vzdump_1.2-4_all.deb
dpkg -i vzdump_1.2-4_all.deb

Danach müssen in der Datei /etc/sysctl.conf folgende Punkte ergänzt werden:

1
2
3
4
5
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.forwarding=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.eth0.proxy_arp=1

Nach dieser Anpassung darf nicht vergessen worden, die Konfiguration neu einzulesen:

1
sysctl -p

Nun muss der Server neugestartet werden, damit der OpenVZ-Kernel auch verwendet wird.

Nun ist OpenVZ soweit eingerichtet und die ersten “virtuellen” Maschinen können eingerichtet werden.
Hier zeigt sich aber auch schon die erste Schwäche von dieser Virtualisierungslösung, denn entgegen anderen Methoden lassen sich mit OpenVZ nur genau das Betriebssystem mit dem Kernel für Guests verwenden, welcher auch der Host benutzt.

Nun da alles eingerichtet ist, können die ersten Templates heruntergeladen werden.
Dazu müssen zuerst die Paketquellen angepasst werden:

1
echo "deb http://download.openvz.org/debian-systs lenny openvz" >> /etc/apt/sources.list

Das der neue Eintrag problemlos funktioniert, muss noch der passende Schlüssel nachgeladen werden:

1
2
wget -q http://download.openvz.org/debian-systs/dso_archiv_signing_key.asc -O- | apt-key add -
apt-get update

Nun sollten auch die passenden Templates in den Paketquellen gelistet werden:

1
apt-cache search openvz | grep vzctl

Damit ein Guest mit diesem Template eingerichtet werden kann, muss er vorher natürlich noch heruntergeladen und installiert werden:

1
apt-get install vzctl-ostmpl-debian-4.0-i386-minimal vzctl-ostmpl-debian-5.0-i386-minimal

Nun kann auch schon mit dem Einrichten des ersten Guests begonnen werden.

Die dazu zur Verfügung stehenden Templates sind unter /var/lib/vz/template/cache/ gelistet.
Hier zeigt sich nun ein Vorteil von OpenVZ gegenüber den alternativen Virtualisierungslösungen. Das einrichten eines neuen Guest dauert hier gerade mal ein paar Sekunden, während bei ESX oder Xen normalerweise stets die gesamte Installation durchlaufen werden muss. Das eintippen eines einfachen Befehls reicht schon aus:

1
vzctl create 1 --ostemplate debian-5.0-i386-minimal --config vps.basic

Erhält man danach eine Ausgabe, wie die folgende, so war die Aktion erfolgreich:

1
2
3
Creating VE private area (debian-5.0-i386-minimal)
Performing postcreate actions
VE private area was created

Nun hat man die Möglichkeit direkt Einstellungen für einen Guest vorzunehmen:

1
2
3
4
5
6
7
8
9
10
11
#Beim Booten aufstarten
vzctl set 1 --onboot yes --save
 
#Hostname setzen
vzctl set 1 --hostname tux1.linux.ch --save
 
#IP Adresse setzen
vzctl set 1 --ipadd 192.168.0.1 --save
 
#DNS Server setzen
vzctl set 1 --nameserver 145.253.2.75 --nameserver 213.191.92.86 --save

Alle nun gemachten Einstellungen werden in der Datei /etc/vz/conf/1.conf gespeichert.

Nun kann der Guest das erste mal gestartet und gleichzeitig auch noch das Rootpasswort angepasst werden:

1
2
vzctl start 1
vzctl exec 1 passwd

Will man den Guest direkt auf der Kommandozeile ansprechen, so kann dies entweder per SSH oder direkt über den Host passieren. Dazu kann folgendes Kommando verwendet werden:

1
vzctl enter 1

Eine List mit allen virtuellen Maschinen erhält man mit dem Befehl vzlist:

1
vzlist -a

Weitere Informationen bekommt man durch die Manpages:

1
man vzctl

oder dem offiziellen Wiki

Was ich bisher noch nicht finden konnte ist eine Möglichkeit mit vzctl set 1 … den Guest zu einer dynamischen IP Adresse zu zwingen.

Insgesamt ist es eine gute Möglichkeit um schnell und unkompliziert zu virtualisieren, jedoch wer viele Ansprüche hat und nicht immer das selbe Betriebssystem / die selbe Distribution verwendet, wird nie seinen Spass an OpenVZ haben.

Natürlich lässt sich alles problemlos auch auf andere Distributionen und Architekturen portieren, wobei die Namen, besonders für die Templates, angepasst werden müssen.

Wartungsfenster mit Hobbit

Posted in Monitoring, Server, Ubuntu on Februar 21st, 2010 by Patrick – Kommentare deaktiviert

Besonders an einem Wartungsfenster ist die Enable/Disable-Funktion von Hobbit sehr hilfreich.
Schliesslich soll Hobbit ja nicht gleich jedes mal die Kavallerie alarmieren, nur weil während ein paar Wartungsarbeiten ein Server mal nicht verfügbar ist.
Doch bevor man Funktionen per WebGUI verwalten kann, muss man sich ein Passwort und einen berechtigten User setzen.

Dazu verwendet man am einfachsten htpasswd:

1
sudo htpasswd -c /etc/hobbit/hobbitpasswd admin

Nun gibt man zwei Mal das gewünschte Passwort ein, und schon ist die Arbeit getan.
Nun kann man auf seinem Hobbitserver das WebGUI aufrufen und unter Administration > enable/disable zuerst den Server, und dann den gewünschten Server oder auch gleich alles deaktivieren. Einloggen kann man sich mit dem Benutzernamen admin und dem eben gewählten Passwort.

Weiter kann man noch einen Grund vermerken und je nach Dauer zwischen automatischem oder manuellem reaktivieren der Überwachung wählen.

Ganz praktisch ist auch der letzte Punkt, mit welchem man das Deaktivieren der Überwachung auf die Minute genau 5 Jahre im voraus planen kann :)

Virenschutz auch unter Linux

Posted in Server, Ubuntu, Xymon on Dezember 26th, 2009 by Patrick – 20 Comments

Erstmal vorweg: Ich will hier keine Grundsatzdiskussion auslösen, ob Linux nun einen Virenschutz braucht oder nicht. Auf allen meinen Servern installiere ich einen Virenschutz, ob dieser nun gebraucht wird oder nicht.

Und da ich mit Xymon (siehe früherer Artikel) den ClamAV Daemon überwachen kann, werden meine eigenen Server nun auch mit dem ausgestattet.

Die Installation von ClamAV ist dank den Paketquellen äußerst simpel:

1
sudo apt-get install clamav clamav-daemon

Danach kann man die Konfiguration des Daemons starten:

2
sudo dpkg-reconfigure clamav-base

Hier wird man schön durch die einzelnen Schritte geführt. Meistens waren die Standardeinstellungen schon ausreichend, dies liegt aber ganz im Ermessen des Admins:

3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Automatische Verwaltung der Konfigurationsdatei: JA
Socket-Typ: UNIX
Lokaler UNIX Socket: STANDARD
Grosszügier Umgang mit übrig geblibenen UNIX-Sockets: NEIN
eMail-Überprüfung: JA
Archiv-Überprüfung: JA
Maximale Grösse: 50
Maximale Verzeichnistiefe: 0
Symbolischen Links folgen: JA
Normalen Links folgen: JA
Zeitbeschränkung: 0
Anzahl Threads: 12
Anzahl wartende Verbidungungen: 15
Nutzung von Syslog: JA
Protokolldatei: STANDARD
Zeitangaben mitprotokollieren: JA
Zeitspanne für Selbsttest: 3600
Benutzer für Daemon: clamav
Daemon-Gruppe: root
Finish :)

Der Daemon kümmert sich nun darum, dass die Virendatenbank immer aktuell bleibt.

Leider aber ist ClamAV ein sogenannter OnDemand-Scanner, d.h. der Suchvorgang muss gestartet werden, und es wird nicht, wie üblich jede Datei vor dem Verwenden gescant.

Dem kann man jedoch mit einem Cronjob entgegenkommen, und da meine Server nur einem minimalen Risiko ausgesetzt sind, reicht dies auch vollkommen aus. Für einen Server mit High-Availability-Anwendungen sollte man sich einen “richtigen” Scanner zulegen.

Also rufe ich die Cronjobs von Root auf:

23
sudo crontab -e

Da lege ich dann einen neuen Eintrag an:

24
00 01 * * 0 sudo clamscan -ri --quiet --bell --scan-mail --phishing-sigs --phishing-scan-urls --heuristic-scan-precedence --algorithmic-detection --scan-pdf --exclude-dir=^/proc\ / #Scan Root rekursiv, show only infected files

Damit wird jeden Sonntag morgen um Punkt 01:00 Uhr ein Scan ausgelöst, welcher das gesamte Root-Verzeichnis rekursiv durchscannt.

Weiter Informationen zu Zeitangaben für Cronjobs findet man im uu.de-Wiki.

Zum Abschluss würde es mich nun aber doch noch interessieren, wie und ob ihr eure Server den schützt?

DNS Server Konfiguration

Posted in Server, Ubuntu on November 29th, 2009 by Patrick – 10 Comments

Damit ich mir für meine virtuellen Server nicht jedes mal die passende IP merken oder irgendwo nachsehen will, habe ich mir einen eigenen DNS Server im Netzwerk installiert.

Für mich war das eine Premiere, da ich bisher nur unter Windows das vergnügen hatte, und da ist es wirklich keine grosse Sache.

Umso erstaunter war ich, wie kompliziert das eigentlich unter Linux ist…

Doch war ich irgendwie zu faul (oder einfach vom WindowsGUI verwöhnt), alle Dateien einzeln zu editieren und konfigurieren, also habe ich auf Webmin zurückgegriffen.

Webmin erlaubt es, viele Einstellungen in Bereichen wie Netzwerkverwaltung, Useradministration, Servereinstellungen und vieles mehr direkt über ein GUI im Browser zu konfigurieren.

Zuerst muss man sich also das aktuelle Paket von Sourceforge holen:

wget http://downloads.sourceforge.net/project/webadmin/webmin/1.390/webmin_1.390_all.deb

Danach kann man die Installation starten:

sudo dpkg -i webmin_*

Da aber noch einige Pakete fehlen, wird die Installation vorerst fehlschlagen. Also gilt es dies noch zu berichtigen:

sudo apt-get install -f

Und nun ist Webmin auch schon installiert unter unter https://127.0.0.1:10000 verfügbar.

Jetzt kann also die Installation losgehen. Dazu ruft man Webmin auf und loggt sich mit einem User ein, welcher sudo-Rechte besitzt.
Dann wählt man unter “Server” den Punkt “BIND DNS Server”.

Nun muss man zuerst mal eine neue Zone erstellen. Hierfür wählt man den Punkt “Create master zone”. Will man, wie in meinem Fall Namen zu IPs auflösen, so muss man eine Forward Lookup Zone erstellen.

Unter “Domain name / Network” vergibt man den Namen für die Zone. Dieser wird auch gleich der Name der Top Level Domain sein (zB. lokal, ch oder com).
Nun muss man noch unter “Email address” eine eMail-Adresse eingeben. Der Rest kann man auf den Standardeinstellungen belassen.

Jetzt kann man endlich die ersten Namen einer IP zuordnen. Dazu definiert man alle Namen und IPs unter dem Punkt “Address (0)”.

Wenn man will, kann man unter “Reverse Address (0)” nochmal die selbigen Informationen zuordnen.

Nachdem man seine Änderungen abgespeichert hat, kann man die Einstellungen testen.
Dazu logge ich mich per SSH ein und führe eine Abfrage an den DNS Server aus:

dig @127.0.0.1 name.domain

Eine Antwort sollte etwa so aussehen:

; <<>> DiG 9.4.2-P2 <<>> @127.0.0.1 name.domain
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18355
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;name.domain. IN A

;; ANSWER SECTION:
name.domain. 38400 IN A 192.168.0.1

;; AUTHORITY SECTION:
domain. 38400 IN NS SL004.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 29 01:52:00 2009
;; MSG SIZE rcvd: 62

Nun muss man nur noch den einzelnen Hosts den DNS hinzufügen. Da bei mir alle Clients ihre IPs per DHCP beziehen, musste ich den DNS nur da eintragen, und abwarten.

Und von nun an, muss ich mir keine mühsamen IP-Adressen mehr merken :)
Vielen Dank an Roman für die Tipps zu Webmin.