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.

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

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?

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.

Die Installation war dank einer hervorragenden Anleitung im UU.de-Wiki überhaupt kein Problem. Jedoch, da mein svn nicht öffentlich jedem zugänglich sein soll, habe ich in der /etc/apache2/mods-enabled/dav_svn.conf einen fixen User eingetragen:

<Location /svn>
    DAV svn
    SVNPath /var/local/svn
    AuthType Basic
    AuthName "svn"
    AuthUserFile /etc/apache2/dav_svn.passwd
    Require user compr00t
</Location>

Nach der Installation dann ist mir aufgefallen, das Subversion den ganzen Traffic per http transportiert, was mir nicht so wirklich zusagen wollte.

Also habe ich meinen Apache2 auf Port 443 verschoben, so dass alles per SSL gesichert wird.

Das “Umkonfigurieren” ist eigentlich überhaupt kein Problem, wenn man weiss wie Doch leider hatte ich nur eine wage Ahnung, weshalb sich das ganze über mehrere Stunden in die Länge zog.

Ich versuche hier nochmals wiederzugeben, was ich so alles rumgebastelt habe

Als erstes habe ich einen neuen Virtualhost angelegt unter /etc/apache2/sites-available/ mit dem Namen ssl und mit folgendem Inhalt gefüllt:

<VirtualHost *:443>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/svn/
    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

Nun wird der neue Virtualhost aktiviert und der alte deaktiviert

sudo a2ensite ssl
sudo a2dissite default

Danach wird Port 443 aktiviert. Dazu überschreibt man die Datei /etc/apache2/ports.conf mit folgendem Eintrag:

Listen 443

Jetzt fehlt noch ein Zertifikat für die gesicherte Verbindung. Dazu muss das Packet openssl installiert sein:

sudo apt-get install openssl

Nun kann man sein Zertifikat erstellen:

mkdir -p /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem\
-keyout /etc/apache2/ssl/apache.pem

Jetzt muss nur noch das Module ssl aktiviert werden:

sudo a2enmod ssl

Jetzt gilt es noch den Apache neuzustarten:

sudo /etc/init.d/apache2 restart
sudo /etc/init.d/apache2 force-reload

Und wenn beim restart kein fail als Antwort rauskommt, so sollte ab sofort die Weboberfläche nun über https://localhost/svn verfügbar sein.

Ich hoffe mal, ich habe nichts vergessen

Als nächstes ist nun geplant, die etwas zu schlichte Weboberfläche von Subversion durch Websvn zu ersetzten.

Dabei wollte ich vorallem den SSH-Zugang besser schützen, mindestens vor automatisierten Bruteforce-Attacken.

Dabei bieten sich mir diverse Möglichkeiten:

• Keyfiles
• PermitRootLogin
• AllowUsers
• Portänderung
• fail2ban
• PortKnocking
• OTP

Als erstes habe ich mal das einloggen vom User “root” verboten. Damit sind bereits 80% aller automatisierten Attacken erfolglos.

PermitRootLogin

Dazu setzt man unter

/etc/ssh/sshd_config

hinter dem Punkt PermitRootLogin ein

no

AllowUsers

Noch besser als das Login als root zu verbieten, ist es, nur bestimmte User zuzulassen.

Dazu muss man in der Datei

/etc/ssh/sshd_config

unter dem Punkt AllowUsers alle Benutzer eingeben, welche Zugriff haben dürfen:

AllowUsers user1 user2 user3

Keyfiles

Keyfiles sind auch noch eine gute Möglichkeit um automatisierte Angriffe abzublocken. Denn, wer die passenden Keyfiles nicht hat, kann sich auch mit dem richtigen Passwort nicht einloggen.

Doch für mich persönlich sind Keyfiles eher unpraktisch, da ich mich oft von verschiedenen Maschinen aus einloggen soll, und meistens da die Keyfiles dann fehlen würden.

Portänderung

Gegen automatisierte Angriffe kann auch eine Umstellung der Ports über welche SSH (22) kommuniziert, helfen.

Das Problem jedoch, mit einem kurzen Scan kann man aufdecken, auf welchem Port SSH nun wirklich läuft.

Ändern kann man den Port unter dem Punkt

Port

in der Konfig von SSH unter

/etc/ssh/sshd_config

fail2ban

Mittels dem Tool fail2ban kann man eine IP Adresse nach einer vordefinierten Anzahl fehlgeschlagener Logins automatisch sperren.

Dies ist besonders praktisch, da ich somit nicht nur ein Mittel gegen automatisierte sondern auch gegen jegliche andere SSH Attacken habe.

Und mitels fail2ban kann man nicht nur den Zugriff auf SSH, sondern auch noch für unzählige andere Dienste wie Appache, DNS, FTP und viele mehr.

fail2ban gibt es auf den Ubuntu Packetservern über

sudo apt-get install fail2ban

Nach der Installation heisst es erst mal Einstellungen bearbeiten. Die Konfig ist unter

/etc/fail2ban/jail.conf

abgelegt.

Um den SSH Zugriff überwachen zu lassen, gilt es folgenden Textschnippsel noch zu ergänzen:

[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3

Damit wird jede IP-Adresse, welche sich 3mal mit falschem Passwort einloggen will, automatisch gebannt.

Portknocking

Eine weitere, sehr effektive Massnahme ist das sogenannte Portknocking. Das beschreibt ein Verfahren, bei welchem man zuerst mit dem geheimen Zeichen anklopfen muss, bevor man sich per SSH einloggen kann.

Wird das geheime Zeichen nicht vorweg gesendet, so erscheint der Port 22 nach aussen als geschlossen.

Realisieren lässt sich dies mittels knockd, welches wiederum in den Packetquellen verfügbar ist

sudo apt-get install knockd

Konfiguriert wird das Programm über eine zentrale Datei

/etc/knockd.conf

Um knocked nun auf den SSH Port vorzubereiten, muss man die Datei mit folgenden Eintrag ergänzen:

[openSSH] sequence = 1234,1234,1234 seq_timeout = 5 command =
/sbin/iptables -A INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn

[closeSSH]
sequence = 1234,1234,1234
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j DENY
tcpflags = syn

Will man sich nun per SSH einloggen, so muss man zuerst mittels

knock ip 1234 1234 1234

den Port freischalten. Nach vollbrachter Arbeit wird der Port über selbiges Kommando auch wieder geschlossen.

OTP

OTP ist ein Verfahren, mittels welchem für jedes Login ein neues Passwort generiert wird. Hier bedanke ich mich bei Benjamin für den Gedankenanstoss und die ausführliche Anleitung.

Er beschreibt dabei wie OTP in Kombination mit seinem Android Handy verweden kann. Doch auch iPhone-Benützern wie mir wird mit dem Tool “OTP Generator” von Dragon Technology Ltd geholfen, welches für CHF 3.30 im Appstore verfügbar ist.

Fazit

Für mich ist fail2ban und PermitRootLogin am besten geeignet. Obwohl ich der Meinung bin, das Portknocking wohl das effektivste wäre, weiss ich noch nicht, ob ich mein “Geheimzeichen” auch von anderen Betriebssystemen aus versenden kann. Deshalb ist dieses Verfahren vorerst mal auf Eis gelegt.

OTP ist für mich schon fast wieder übertriebene Sicherheit, und der Aufwand, jedes mal ein neues Passwort zu generieren ist mir einfach zu gross.

Natürlich ist ein offener SSH Port immer ein Sicherheitsrisiko, aber mit den obig aufgezeigten Möglichkeiten, sollte man 95% aller Attacken abwehren können.

Und sonst gilt halt immer noch: Wählt ein sicheres Passwort

[Quellen: 4t2, Horst und FreiesMagazin]

Um auch einzelne Server innerhalb meines Netzwerkes anzusprechen, so habe ich dafür ein Portforwarding eingerichtet. Doch was, wenn ich nun zwei Webserver im Netzwerk habe. Wie kann ich beide ansprechen? Ich kann den Port 80 ja nicht auf mehrere Server weiterleiten.

Die Lösung heisst Reverse Proxy. Dabei kann ich die Anfrage vom Router, über den Proxy auf den passenden Server weiterleiten.

Somit kann ich also als Beispiel einen Webserver und eine Groupware beide auf Port 80 betreiben. Von aussen angesprochen werden Sie dann mittels http://ip.com/webserver/ oder http://ip.com/groupware/. Der Proxy entscheidet und leitet auf den entsprechenden Server weiter.

Die Installation ist auch ganz einfach
Alles was man tun muss, ist ein Paket aus den Paketquellen zu installieren

sudo apt-get install libapache2-mod-proxy-html

Danach muss man noch die folgenden drei Module aktivieren

sudo a2enmod proxy
sudo a2enmod proxy_html
sudo a2enmod proxy_http

und den Webserver neu zustarten.

sudo /etc/init.d/apache2 force-reload

Nun kann man mit der Konfiguration beginnen. Ein Beispiel kann in etwa so aussehen:

<VirtualHost *>
…
ProxyRequests Off

Order deny,allow
Allow from all
ProxyPass /webserver/ http://192.168.1.2:80/
ProxyPassReverse /webserver/ http://192.168.1.2:80/

ProxyPass /groupware/ http://192.168.1.3:80/
ProxyPassReverse /groupware/ http://192.168.1.3:80/
…
</VirtualHost>

Nun gilt es einfach alle Server einzutragen und dann den Webserver nochmals neu zustarten. Nun trägt man ein Portforwarding im Router ein und kann somit beide Server auf Port 80 ansprechen.

Vielen Dank an das Ubuntuusers-Wiki

Einer der besten Tipps ist der SSH-Zugriff. Dieser ist zwar nicht offiziell unterstützt, ist aber eine in ESXi integrierte Funktion, es sind also keine weiteren Installationen nötig.

Um SSH zu aktivieren muss man zuerst in eine Konsole wechseln. Dies geht wie unter Linux mit ALT + F1. Im Gegensatz zu einem normalen Linux ist hier nur eine Konsole aktiv und nicht alle 6.

Nun folgt der schwierigste Part

Man muss blind und ohne Rückmeldung das Wort “unsupported” und das eigene Passwort eintippen.

Ab nun hat man eine normale Konsole:

~ #

Nun muss man in der inetd.conf SSH aktivieren. Dazu öffnet man diese in einem Editor,

vi /etc/inetd.conf

suchen den Eintrag

#ssh

und entfernt die Rauten wodurch bei der Zeile der Kommentar entfällt. Nun heisst es den physikalischen Server neustarten und man kann von nun an per SSH zugreifen.

Nun kann man sich per SSH alle VM’s ausgeben lassen,

vim-cmd vmsvc/getallvms

einzelne VM’s starten

vim-cmd vmsvc/power.on ID

oder den aktuellen Status abfragen.

vim-cmd vmsvc/power.getstate ID

Es gibt sicher noch unzählige mehr, aber ich denke das sind mal die wichtigsten

Einen weiteren Tipp, ist die Möglichkeit mehrere VMs automatisch mit dem Serverstart zu starten. Für mich ist diese Funktion sehr nützlich da ich meinen Server per WOL boote, wenn ich ihn brauche.

In der Hoffnung möglichst viel aus dem Server herauszuholen, habe ich mich für ein ESXi als Betriebssystem entschieden.

Die Wahl viel eigentlich relativ schnell, da ich so mehrere Server betreiben kann. Ein weiterer Vorteil von ESXi gegenüber allen anderen Virtualisierungssystemen die ich kenne ist, dass man mehr einer vMaschine mehr Ressourcen zuordnen kann als eigentlich vorhanden ist. Und da ich “nur” 2x 2.8Ghz und 4GB Ram (soll bald auf 6GB aufgerüstet werden) zur Verfügung habe, kann dies noch ganz praktisch sein.

Doch bevor ich das OS installierte, wollte ich erst noch das RAID einrichten. (Vorab; im Server stecken zwei 18GB und zwei 72GB Platten.)

Aufgrund der Konstellation der Platten fiel meine Wahl recht schnell. So wurden die beiden 18GB Platten mittels RAID 1 und die 72GB Platten zu einem RAID 0 zusammengefasst.

So war das Betriebssystem, welches auf den 18er beherbergt wurde durch ein RAID geschützt.

Doch zurück zur Installation: So schnell die Wahl auch viel, umso länger dauerte die Installation. Begonnen habe ich mit dem normalen ESXi 4.0 von der VMware-Seite.

Als ich mich nach einem erfolglosen Installationsversuch weiter umgesehen habe, bin ich auf ein ESXi 4.0 for HP gestossen. Doch auch dies wollte den modifizierten  Linuxkernel, welcher die Basis von ESX und ESXi bildet nicht booten lassen.

Nach erneuter Suche habe ich ganz am unteren Ende der VMware-Seite einen unscheinbaren Link ausgemacht:

“VMware ESXi 4.0 is certified to run on a broad range of 64-bit hardware. For 32-bit hardware support, download the previous version, VMware ESXi 3.5.”

Also habe ich auch noch ESXi 3.5 auf CD gebrannt und gebootet. Und siehe da!! Nach gerade mal 15 Minuten war das Betriebssystem installiert und konnte gestartet werden.

Einrichten und Konfigurieren des ganzen geht problemlos über die ein bisschen farblose Oberfläche. Und viel mehr als eine statische IP muss man hier auch nicht tun. Praktisch hierbei war für mich, dass ich, dank dem iLO Port (ähnlich einer Remote Management Karte), das ganze ohne weiteren Bildschirm und Tastatur managen konnte.

Dann war es endlich soweit!

Vom Server selbst kann man dann den VMware Infrastructure Client herunterladen, welche, entgegen meinen Erwartungen, nicht nur für Windows verfügbar ist.

Diese kurz installiert und schon wird auf den Server verbunden. Als erstes sollte man hier das Passwort ändern, ausser man steht auf Überraschungsbesucher

Nachdem auch das erledigt ist, kann man schon seine ersten virtuellen Server anlegen. Besonders gut gefällt mir hier, die Möglichkeit ein ISO oder Laufwerk vom lokalen Computer direkt dem Server zu übergeben.

Das Aufsetzten einer neuen VM ist sichtlich einfach und genau gleich gehalten wie bei allen anderen VMware Produkten. Dadurch war schon nach kurzer Zeit mein erster Ubuntu 8.04 LTS Server verfügbar und online.

Doch bevor ich loslegte, wollte ich erst noch die VMware Tools installieren. Dazu gibt es den Menupünkt “Install VMware Tools” unter VM.

Nach einem Klick darauf habe ich auf eine Rückmeldung meines Servers gewartet – leider vergebens. Unwissend ob es nun geklappt hat oder nicht, machte ich mich auf die Suche nach einer Hilfestellung und bin dabei über einen Beitrag von Roman gestolpert, womit sich auch dieses kleine Problem lösen liess.

Da der DL380 Server alles andere als Stromsparend ist, wollte ich auch noch WOL aktivieren. Vom Einrichten von WOL auf einem Client wusste ich noch, wie mühsam es sein kann, war jedoch umso erstaunter, als sich die ganze Konfiguration in einem Punkt im BIOS verflüchtigte.

Nach ca 2 Stunden war mein ESXi-Server aufgesetzt und konfiguriert und mein erster virtueller Server online und ich glücklich

Fotos folgen noch

Am Server selbst ist das CD-Laufwerk futsch, was für mich aber nicht wirklich eine Rolle spielt…

Es gibt ja immer noch die gute Netzwerkinstallation

Im Server drin stecken:

- 2 (von 3) SCSI Platten mit je 18GB
- 2 mal 1 GB RAM
- 2 mal Intel Pentium III 1.4 GHz
- eine Embedded Remote Assistance card

Ich habe nun die Qual der Wahl: Was für ein OS kommt drauf. Auf der einen Seite wäre eine Lösung mit virutellen Maschinen genial, da der Server zum Testen und Probieren verwendet wird, und ich somit mit Snapshots immer voll dabei wäre.

Auf der anderen Seite ist das umständlicher und da der Server nicht mehr der neuste ist, kann da auch z.B. kein ESXi drauf rumrennen!

Weiter wäre noch Debian oder Ubuntu Server in der Auswahl, da ich diese gut kenne.

Oder vielleicht doch eine komplett andere Distri?

Es würde mich intressieren:

- was setzt ihr so ein?
- was könnt ihr mir empfehlen?
- was würdet ihr auf das süsse 14.5 kg Ding machen?

Ich freue mich über viele konstruktive Vorschläge