Archiv nach Monaten: Mai 2011

QEMU / KQEMU – Virtualisierung unter ipfire

Ein wesentliches Ziel der IPFire-Installation war es von Anfang an, Webdienste zur Verfügung zu stellen ohne die Gefahr einzugehen, den IPFire Rechner allzusehr dem Internet “auszusetzen”. Die theoretische Möglichkeit, den bei IPFire “eingebauten” Webserver zweckzuentfremden kam also nie in Frage.

IPFire bietet die Möglichkeit, mittel qemu und kqemu weitere Betriebssysteme virtuell zu betreiben. Diese beiden Pakete haben wir ja mittels “pakfire” bereits im ersten Schritt installiert. (Mehr Infos zu qemu gibt es im IPFire Wiki)

Wer Virtualisierungslösungen wie Virtualbox oder VMware bereits kennt, wird zunächst etwas von der Sprödigkeit von qemu erschrocken sein. Allerdings läuft qemu bei mir sehr stabil und auch hinreichend performant und bietet keinen Grund zu Beanstandungen.

Folgende Befehle sind als Vorbereitung notwendig, um einen Gast zu virtualisieren:

# Kernel Modul laden
modprobe kqemu
# Festplattendisk für qemu erstellen
qemu-img create /mnt/raid/qemu/portal.img 30GB

Und so startet man den virtuellen Gast, um z.B. die OS-Installation durchzuführen. Das notwendige CD-Image habe ich bereits zuvor heruntergeladen:

qemu -vnc :1 -hda /mnt/raid/qemu/portal.img -m 228 -net nic -net user -boot d -redir tcp:222::22 -redir tcp:80::80 -no-acpi -k de -cdrom /mnt/raid/qemu/debian-505-i386-CD-1.iso

Den Zugriff auf die lokale Konsole bekommt man über VNC. Ist das Betriebssystem komplett installiert, sollte dieses heruntergefahren werden. Anschliessend wird mittels Strg+C der qemu Prozess beendet.

Der nächste Aufruf der Virtualisierung bedient sich der wesentlich performanteren Variante “kqemu”. Zudem wird vom Laufwerk “C” gebootet, da CD-ROM Laufwerk benötigen wir nicht mehr:

qemu-kqemu -vnc :1 -hda /mnt/raid/qemu/portal.img -m 228 -net nic -net user -boot c -daemonize -redir tcp:222::22 -redir tcp:80::80 -k de -kernel-kqemu

Die VM läuft nun beträchtlich schneller – allerdings hat kqemu (zumindest) einen Nachteil: Den Preis der Geschwindigkeit erkauft man sich durch einen massiven Speicher-Mehrverbrauch, denn die Größe von /dev/shm muss mindestens die Größe des virtuellen Speicherbedarfs besitzen (zu ändern in /etc/fstab und anschliessender reboot).

Die beiden “-redir” Parameter legen fest, welcher VM-Port auf welchen physikalischen Port umgeleitet werden sollen. Im konkreten Fall wird der virtualisierte SSH-Server vom Port 22 auf den Port 222 umgeleitet. So wäre per ssh Client auf dem Port 222 der virtuelle Rechner zu erreichen. Der Webserver selbst bleibt sowohl virtuell als auch physikalisch abgebilder auf Port 80. Wird nun auf der IPFire Firewall der externe Zugriff auf Port 80 erlaubt, steht dem Internet-Server nichts mehr im Weg!

Der Einfachheit halber habe ich (zusammenfassend einige Startoptionen, das Laden des Kernel-Moduls und den Start der VM in die Datei /etc/sysconfig/rc.local gestellt:

# ondemand-Governor auch hochtakten lassen
# wenn die Prozesse mit niedriger Prio laufen
echo 0 >/sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load

# Bei einer Auslastung von 30 Prozent bereits hoeherschalten
echo 30 >/sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

# Das Modul fuer qemu laden
modprobe kqemu

# Meine virtuelle Maschine starten
qemu-kqemu -vnc :1 -hda /mnt/raid/qemu/portal.img
 -m 228 -net nic -net user -boot c -daemonize
 -redir tcp:222::22 -redir tcp:80::80
 -no-acpi -k de -kernel-kqemu

Konfiguration und Fine-Tuning des ipfire

Nachdem die Grundkonfiguration unproblematisch verlaufen ist, kommen wir nun zur Optimierung einiger Parameter bzw. zur Konfiguration der weiteren Dienste.

RAID-Devices aufsetzen

Ursprünglich wollte ich den Server mit einem Software-RAID betreiben, habe aber mittleweile einen (günstigen und guten) Hardware-Controller verbaut. Grund war, dass der Software-RAID-Treiber in der „damaligen“ ipfire Version sehr langsam war – dieser Mangel ist mittlerweile behoben und auch die SW-RAID Lösung würde sehr gut laufen.

Die Grundlagen zur RAID-Konfiguration finden sich im ipfire Wiki, deshalb hier nur skizzenartig die Schritte:

  • Alle vier Platten mit gleichen Partitionen versehen, Partitionstyp „fd“
  • Alle vier Platten zum RAID-10 Device „md0“ konfigurieren
  • Das RAID-Device formatieren (ext3) und nach /mnt/raid mounten

Das Partitionieren läuft wie gewohnt mit fdisk, das Erstellen des RAID-Devices geschieht mit:

mdadm --create /dev/md0 --level=10 --raid-devices=4 --spare-devices=0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

Das RAID wird im Hintergrund erstellt, mittels des Kommandos

cat /proc/mdstat 

lässt sich der Fortschritt des RAID-Aufbaus verfolgen. Nun kann das RAID-Device mit einem Filesystem versehen und gemountet werden. Ist das alles korrekt erledigt, kann man die Datei /etc/fstab anpassen, damit das RAID-Device beim Systemstart automatisch gemountet wird. Aufpassen bei Einträgen in der fstab – Fehler können dazu führen, dass ipfire nicht mehr bootet.

Damit der RAID-Dienst beim Systemstart automatisch startet, ist folgender Symlink zu erstellen:

ln -s /etc/init.d/mdadm /etc/rc.d/rcsysinit.d/S11mdadm

Nun muss nur noch die Datei /etc/mdadm.conf erzeugt werden. Dies geschieht mittels der folgenden Kommandos:

cd /etc
echo 'DEVICE /dev/hd*[0-9] /dev/sd*[0-9]' > mdadm.conf mdadm --detail --scan >> mdadm.conf

Samba-Performance

Nachdem die RAID-10 Performance auf dem erwarteten Niveau lag (2x Durchsatz der Einzelplatten, also ca 190MB/sec) war ich von der SMB-Performance mit ca. 40MB/sec etwas enttäuscht. Nach etwas herumprobieren stellten sich zwei Faktoren als limitierend heraus:

  • Samba-Konfiguration
  • Der Governor für PowerNOW ist etwas „konservativ“ eingestellt und hat die CPU nicht rechtzeitig und genug hochgetaktet.

Bei dem Samba-Dienst brachte die Einstellung für die socket-Optionen den maximalen Durchsatz:

TCP_NODELAY SO_RCVBUF=32767 SO_SNDBUF=32767 SO_KEEPALIVE

Bei heftigerem Samba-IO jedoch hängte sich der SMB-Dienst reproduzierbar auf. Dies lag daran, dass im /var/lock Verzeichnis nicht genügend Platz konfiguriert ist. Ich habe den zugewiesenen Platz in der Datei /etc/fstab mit 64MB recht großzügig dimensioniert.

PowerNOW! und Speedstep

Sobald man das addon cpufrequtils installiert, werden CPU’s welche das Heruntertakten unterstützen, dynamisch heruntergetaktet und ab bestimmten Lastzuständen wieder hochgetaktet. I.d.R. arbeitet dieser Mechanismus recht zufriedenstellend, bei meinem IPFire Rechner allerdings war die CPU-Last nicht hoch genug, um den Governor zum Hochtakten zu zwingen. Die durchschnittliche Load an Prozessen allerdingswar oft dermassen hoch, dass der Rechner nicht mehr zügig arbeiten wollte.

Abhilfe verschaffen die folgenden Änderungen:

echo 0 >/sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
echo 30 >/sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

Diese Befehle bewirken, dass auch bei Prozessen mit niedriger Priorität hochgetaktet wird und die Umschaltung zu höchstem Prozessortakt bereits bei 30% Systemauslastung geschieht.

In der Praxis idled der Rechner immer noch vor sich hin, selbst dann, wenn die (wie später noch geschildert) virtuelle Gentoo-Installation auch idle läuft. Wird etwas mehr als Leerlauf Last erzeugt, taktet die CPU “nervöser” hoch.

Proxy-Cache umleiten

Standardmässig würde ipfire den Proxy-Cache auf der SSD ablegen – was man aus zwei Gründen nicht mag: Eine SSD verkraftet nicht viele Schreibzugriffe, zudem ist der Speicher knapp und verhältnismässig „teuer“.

Normalerweise würde man ja die squid.conf Datei editieren, wenn man ein anderes Cache-Verzeichnis wünscht. Dies führt aber bei IPFire nur temporär zum Erfolg, da bei jeder Änderung in der Web-Oberfläche die squid.conf neu erstellt wird – und die Einstellung des Cache-Verzeichnisses ist in der Datei proxy.cgi hart codiert.

Der einfachste Weg liegt darin, ein neues Verzeichnis auf dem RAID-Device zu erstellen, eventuell bestehende Cache-Dateien dorthin zu verschieben und anschliessend den Verzeichnislink /var/log/cache auf das neue Verzeichnis “zu verbiegen”.

Wichtig ist, dass Eigentümer und Gruppe des Cache-Verzeichnisses auf squid:squid geändert sind.

Auf der Suche nach dem idealen Homeserver

Mittlerweile hat sich in meinem Keller ein wahres Sammelsurium an Rechnern angefunden – für jeden Zweck fast schon ein Gerät (Firewall und WLAN, Fileserver, Download-Server, …) . Als ich dann noch meinen Mailserver und den Webserver betreiben wollte, war ich mit meinem Hardware-Zoo am Ende.

Folgende Voraussetzungen musste die „neue“ Lösung erfüllen:

  • Hochperformanter Windows-Fileserver mit Gigabit Interface
  • Firewall und WLAN Accesspoint
  • Proxyserver
  • Die Möglichkeit, einen von der Firewall möglichst isolierten virtuellen Server zu betreiben
  • Relativ sparsam im Betrieb

Herausgekommen ist nach langer Recherche und vielen Versuchen folgende Lösung:

  • Als Software-Plattform wählte ich ipfire – dieses erfüllt alle Anforderungen (dazu später mehr)
  • Hardwareplattform:
    GigaByte MA780G UD3H Mainboard mit möglichst vielen PCIe/PCI Slots (ATX), onboard Gigabit (GREEN Interface)
    AMD  4850e (Stromsparprozessor, heruntergetaktet auf meist 1000MHz)
    4 GByte RAM, zusätzliche Intel Pro100S für das RED Interface
    300MBit WLAN (AR922X Wireless Network Adapter) von TPLink (BLUE Interface)
    DELL Perc 5i SATA/SAS RAID Controller (in aktuellen ipfire Releases lässt sich auch das Software-RAID sehr performant betreiben, ein HW-Controller ist eigentlich Luxus)
    Kleine SATA SSD (16GB von KingSpec) für das ipfire-System
    4 x 1TB Samsung EcoGreen SATA
    Netzteil Revoltec 82+
    -> Stromverbrauch von ca. 55Watt (Billigmessgerät)

Für einen reinen Fileserver ist die Hardware natürlich vollkommen überdimensioniert – allerdings möchte ich den Webserver/Mailserver virtuell betreiben und ein wenig Hardware-Reserven im Lastbetrieb sind sicher nicht schlecht

Installation

Auf die Installation möchte ich nur stichpunktartig eingehen – sie ist eigentlich selbsterklärend und sowohl durch das Wiki und das sehr hervorragende Forum leicht durchzuführen und unterstützt. Die Doku gilt für ipfire 2.7.x – mittlerweile ich die Version 2.9 aktuell – die Doku ist aber trotzdem auch in 2.9 anwendbar.

  • Booten vom USB-Stick (USB Harddisk image verwenden)
    Image lässt sich unter Windows mit dem Programm physdiskwrite schreiben, eventuell zuvor den USB-Stick mit Programmen wie “killdisk” komplett löschen.
  • Als Filesystem habe ich (wegen der SSD) ext2 gewählt – die zusätzlichen Schreibzugriffe durch das Journal spare ich mir
  • Einstellungen für Tastatur, Region, Passwörter klug wählen
  • Netzwerk-Konfiguration entsprechend der Hardware vornehmen (bei mir rot, grün, blau).

Anschliessend wird der Rechner neu gestartet und bootet IPFire von der konfigurierten Festplatte.

Die ersten Schritte in der Konfiguration erfolgen nun im Web-Frontend mittels des zuvor gewählten Admin-Accounts: https://<adresse_der_ipfire_box>:444

  • SSH-Zugriff aktivieren: Viele Konfigurationsschritte erfordern einen Shell-Zugriff. Entweder direkt am Rechner oder (komfortabler) per SSH.
    Aktiviert wird der SSH-Zugriff im Web-Frontend unter “System” -> “SSH Zugriff” -> “SSH Zugriff”. Auch den SSH-Port habe ich vom Port 222 auf den Standard-Port gelegt.
    Aus Sicherheitsgründen sollte der SSH-Zugriff deaktiviert werden, wenn man ihn nicht mehr benötigt!
  • Benötigte Pakete installieren und Konfigurieren: Da ich einige „experimentelle“ Pakete verwendet habe, stelle ich IPFire jetzt auf “testing” um, wie das geht ist im Wiki ausführlich beschrieben (kurz: in der Datei /opt/pakfire/etc/pakfire.conf die Versionsnummer auf 2.7.1 ändern, anschliessend “pakfire update –force” ausführen).
    * cpufrequtils (PowerNOW bzw. Speedstep zum automatischen Runtertakten)
    * hostapd (für den WLAN Accesspoint)
    * mdadm (zum Einrichten des Software-RAID) – für ein HW-RAID entbehrlich
    * nano (Texteditor, weil mir vi zu umständlich ist)
    * qemu und qemu-kqemu (für die Virtualisierung meines Debian-Servers)
    * samba (für den Windows-Fileservice)
  • Anschliessend habe ich alle benötigten Dienste (WLAN-AP, DHCP, Proxy, Samba, …) so konfiguriert, dass der IPFire Rechner prinzipiell funktioniert.

Die Feinkonfiguration schildere ich im nächsten Artikel (PowerNOW, Samba-Performance, Debian-Server virtualisieren, RAID einrichten).

Icinga – Installation unter Debian Squeeze

Auf Grund der Tatsache, dass die mir übergebene icinga-Installation etwas „kaputtkonfiguriert“ und zudem ein relativ altes Release ist, habe ich mich entschlossen, eine komplett neue Installation durchzuführen. Auf der icinga Webseite wird die Installation ziemlich ausführlich geschildert, die wirklich relevanten Informationen, wie es GENAU unter Debian funktioniert, sind aber schwer zu separieren – ich möchte daher nur auf die Installation unter Debian „Squeeze“ eingehen.

Ich möchte auch auf dieses Blog verweisen, von dem ich viele Infos bezogen habe.

Ich setze voraus, dass sich der Anwender in grundsätzlichen Debian-Belangen ausreichend zurechtfindet, da ich (vorläufig) nur ein kurzes Installations-Log posten möchte.

Als Basis diente mir eine minimale Debian 6 32bit Installation (also keine „zusätzlichen“ Pakete etc.).

Los gehts:

# Pakete installieren

apt-get install apache2 build-essential libgd2-xpm-dev
apt-get install libjpeg62 libjpeg62-dev libpng12-0 libpng12-dev
apt-get install mysql-server mysql-client libdbi0 libdbi0-dev libdbd-mysql

# Benutzer hinzufügen

/usr/sbin/useradd -m icinga
passwd icinga
/usr/sbin/groupadd icinga
/usr/sbin/groupadd icinga-cmd
/usr/sbin/usermod -a -G icinga-cmd icinga
/usr/sbin/usermod -a -G icinga-cmd www-data

# Icinga
cd /usr/src
wget http://downloads.sourceforge.net/project/icinga/icinga/1.4.0/icinga-1.4.0.tar.gz
tar xvzf icinga-1.4.0.tar.gz
cd icinga-1.4.0
./configure --with-command-group=icinga-cmd --enable-idoutils
make all
make install
make install-init
make install-config
make install-commandmode
make install-idoutils
make install-api
# Idoutils anpassen
cd /usr/local/icinga/etc
mv idomod.cfg-sample idomod.cfg
mv ido2db.cfg-sample ido2db.cfg
nano -w /usr/local/icinga/etc/icinga.cfg
# Broker_module auskommentieren

# Mysql Datenbank einrichten etc.
mysql -u root -p

 CREATE DATABASE icinga;

 GRANT USAGE ON *.* TO 'icinga'@'localhost'
 IDENTIFIED BY 'icinga'
 WITH MAX_QUERIES_PER_HOUR 0
 MAX_CONNECTIONS_PER_HOUR 0
 MAX_UPDATES_PER_HOUR 0;

 GRANT SELECT , INSERT , UPDATE , DELETE
 ON icinga.* TO 'icinga'@'localhost';

 FLUSH PRIVILEGES ;

 quit

cd /usr/src/icinga-1.4.0/module/idoutils/db/mysql/
mysql -u root -p icinga < mysql.sql

nano -w /usr/local/icinga/etc/ido2db.cfg
# Einstellungen prüfen

# Klassisches Web-Interface erstellen
cd /usr/src/icinga-1.4.0
make cgis
make install-cgis
make install-html

# Web Frontend erstellen
apt-get install php5 php5-cli php-pear php5-xmlrpc php5-xsl php5-ldap php5-gd php5-mysql
cd /usr/src
wget http://downloads.sourceforge.net/project/icinga/icinga-web/1.4.0/icinga-web-1.4.0.tar.gz
tar xzvf icinga-web-1.4.0.tar.gz
cd icinga-web-1.4.0
./configure --prefix=/usr/local/icinga-web --with-web-user=www-data --with-web-group=www-data --with-web-path=/icinga-web --with-web-apache-path=/etc/apache2/conf.d --with-db-type=mysql --with-db-host=localhost --with-db-port=3306 --with-db-name=icinga_web --with-db-user=icinga_web --with-db-pass=icinga_web --with-icinga-api=/usr/local/icinga/share/icinga-api
make install
make install-apache-config
/etc/init.d/apache2 restart
make install-done
# make icinga-reset-password
make testdeps

make db-initialize
mysql -u root -p
 GRANT USAGE ON icinga_web.* TO 'icinga_web'@'localhost' IDENTIFIED BY 'icinga_web' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0;
 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX ON icinga_web.* TO 'icinga_web'@'localhost';
 quit

a2enmod rewrite

/etc/init.d/apache2 restart
/etc/init.d/icinga restart
/etc/init.d/ido2db restart

# Klassisches Web-Frontend installieren

cd /usr/src/icinga-1.4.0
make install-webconf
htpasswd -c /usr/local/icinga/etc/htpasswd.users icingaadmin
/etc/init.d/apache2 restart

# Nagios-Plugins
cd /usr/src
wget http://sourceforge.net/projects/nagiosplug/files/nagiosplug/1.4.15/nagios-plugins-1.4.15.tar.gz
tar xzvf nagios-plugins-1.4.15.tar.gz
cd /usr/src/nagios-plugins-1.4.15
./configure --prefix=/usr/local/icinga --with-cgiurl=/icinga/cgi-bin --with-htmurl=/icinga --with-nagios-user=icinga --with-nagios-group=icinga
make
make install

# Automatischer Start
update-rc.d ido2db defaults
# Icinga Konfiguration testen:
/usr/local/icinga/bin/icinga -v /usr/local/icinga/etc/icinga.cfg
update-rc.d icinga defaults

Ein weiteres Blog …

Ja, ein weiteres Blog. Aber (hoffentlich) nicht ein beliebiges weiteres Blog, sondern ein besonderes.

Auf meinem Blog möchte ich zum einen Einsichten und Ergebnisse meiner täglichen Arbeit im IT-Umfeld darstellen, zum anderen ein wenig ausschweifen in einige meiner privaten Anliegen und Interessen. Manches lässt sich nicht eindeutig voneinander trennen, da sich meine privaten Interessen und die beruflichen Anforderungen stark überschneiden und ergänzen.

Ausflüge in mein Privatleben wird es u.a. in den Themen Fotografie, Radfahren, Tagesthemen geben – berufliche Themen sind alle Belange der IT im mittelständischen Umfeld. Überschneidungen wird es zwangsweise im Bereich Firewall, VDR und Windows geben.

So, nun genug getextet – viel Spass auf meinen Seiten.