Archiv nach Schlagworten: ipfire

Sophos UTM9 auf Fujitsu Futro S500 Thin Client – Update 26.05.

Nach meinem vorherigen Artikel ist es endlich vollbracht – auf dem ThinClient läuft nun die Sophos UTM9. Die Performance ist akzeptabel, die Investition hielt sich in Grenzen. Und Spaß hat’s nebenbei auch noch gemacht. Weiterlesen »

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).