Appliance im Eigenbau

Netzwerkapplicance im Eigenbau

Im Bereich der DSL-Router hat man als Kunde ja heute eine recht umfangreiche Auswahl, teils soagr mit NAS und anderen netten Funktionen. Leider sind die Firewalls in der Regel nicht übermäßig konfigurierbar, und zusätzliche Funktionen sind nicht unbedingt immer so ganz sicher.

Ich habe mir bislang damit beholfen, einen ASUS Router mit OpenWRT zu betreiben. Allerdings stößt hier die Hardware bald an ihre Grenzen; vor allem dann, wenn man das Gerät auch für andere Zwecke benutzen will. So habe ich z.B. meine privaten E-Mails auf dem Server, so daß ich von überall her meine E-Mail abrufen kann. Der Versuch Spamassassin zum laufen zu kriegen scheitert allerdings an mangelndem Hauptspeicher, der Versuch einen TOR-Knoten aufzubauen an der Prozessorleistung.

Ich habe daher beschlossen, mir meine eigene Appliance zu bauen, die alle die Dienste anbietet, die ich gerne haben möchte. Da sicher noch mehr Leute an so einer Anwendung interessiert sind, möchte ich hier im Wiki meine einzelnen Arbeitsschritte dokumentieren, damit man die Appliance nachbauen kann.

Anforderungen

• Leise
• Geringer Stromverbrauch
• Platzsparend
• NAS-Laufwerk
• Mail-/IMAP Server
• VPN-Endpunkt
• Sicherheit
• Erweiterbarkeit
• Darknet-Knoten (zu diesem Thema mache ich demnächst einen eigenen Beitrag, soviel sei aber verraten: Die Appliance soll auch dafür Daten aufnehmen)

Hardware

Der erste Schritt ist natürlich die Beschaffung der richtigen Hardware. Ein ausgedienter PC tut es natürlich auch, der erfüllt aber nicht unsere Anforderungen an den Stromverbrauch und die Lärmentwicklung (bei mir steht das Ding im Wohnzimmer). Ich habe mich entschieden, eine Mini-ITX Lösung einzusetzen, da diese mehrere Vorteile hat:

• Preiswert
• Boards sind fertig bestückt (nur RAM fehlt)
• relativ viel Prozessorleistung für's Geld
• volle Kompatibilität zu x86 Hardware == große Softwareauswahl

Zur Zeit (Oktober 2007) das beste Preis-/Leistungsverhältnis habe ich bei Reichelt-Elektronik gefunden (danke Gwenn): Das Intel D201GY mit Celeron (1.33GHz) Prozessor, on-board Graphik und Sound kostet derzeit €62,97. Dazu habe ich ein DDR2-533 RAM Modul mit 1GB gekauft (€19,95). Als Gehäuse habe ich mich für das CUBID CP2699 entschieden. Es geht zwar noch etwas kleiner, aber man kann in dieses gehäuse auch eine 3.5" HDD einbauen (ist billiger), und es hat einen PCI-Slot nach aussen geführt. Bei dem Gehäuse muß man allerdings darauf achten, daß das Netzteil keinen 4-Pin 12V Stecker hat, um den Prozessor mit Strom zu versorgen (die Intel-Mini-ITX-Boards haben meist einen 2x10 und einen 2x2 Stromanschluß, statt des bei ATX üblichen 2x12 Anschlusses). Ein kleiner Adapter löst dieses Problem aber leicht.

Da das ganze ja unter anderem eine Firewall sein soll, sollte man eine zweite Netzwerkkarte einbauen. Ich habe eine simple REALTEK 8139 basierte Karte genommen. Die wird von Linux prima unterstützt, und kostet nur 5€. Wer sich noch den Switch sparen will, kauft eine Karte mit eingebautem Switch. Da gibt's aber gerne mal Probleme mit der Unterstützung durch Linux, weil derartige Karten oft ziemlich exotische Chipsätze haben. Da ich mich da nicht so gut auskenne, habe ich lieber zu einer Lösung gegriffen, von der ich weiß, daß sie geht. Input zum Thema ist natürlich willkommen.

Den Einbau des Boards zu erklären, spar ich mir mal. Wer dieses Wiki liest, weiß vermutlich eh' wie man das mit verbundenen Augen macht. ;-)

Installation

Als Betriebssystem habe ich mich für Gentoo-Linux entschieden, auch wenn das ein bischen mehr Arbeit beim installieren macht. Der Vorteil ist, daß man sich Gentoo so zurechtschneidern kann, wie man es gerade braucht, ohne überflüssigen Ballast mitzuschleppen. Für eine Appliance ein unbestreitbarer Vorteil.

Da unsere Appliance kein CD-Laufwerk hat müssen wir zunächst ein Gerät zum Booten einrichten. Am bequemsten geht das mit einem USB Stick. Hier gibt es eine ausführliche Dokumentation wie man den vorbereitet. Bevor von dem Stick gebootet werden kann, muß im BIOS des Intel-Boards unter "Advanced" die Option "USB-Bootable" auf "Enabled" gestellt werden.

Danach vom USB Stick booten. Die Installation läuft wie im Gentoo-Handbuch beschrieben ab. Wer es etwas bequemer mag, kann auch mit dem Befehl "Installer" einen interaktiven Installer aufrufen, der einem manche Entscheitung abnimmt, dafür aber einige Vorgaben durchsetzt. Beim Einsatz des Installers sollten die USE-Flags "X" sowie "GNOME". "GTK+". "QT3", "QT4" und "KDE" entfernt werden, da auf der Appliance in der Regel keine X11 Unterstützung benötigt wird. Das reduziert die Compilerzeiten, und spart wertvolle Systemresourcen.

Nach erfolgter Installation ist es sinnvoll mit

 # rc-update add sshd default

sicherzustellen, daß der SSH Daemon immer mit gestartet wird. Dann kann man den Bildschirm und Tastatur abstöpseln und das Gerät komplett über das Netzwerk bedienen.

---

TIP: In der Folge müssen immer wieder Konfigurationsdateien bearbeitet werden. Der Standardeditor von Gentoo ist "nano", ein etwas besseres Notepad für die Konsole, wie ich finde. Wer einen mächtigeren Editor möchte, installiert sich Vim oder Emacs. Gentoos Vim-Installation kommt mit einer breiten Palette an Dateitypbeschreibungen, so daß selbst exotische Konfigdateien mit Syntaxhighliting und Auto-Vervollständiung daher kommen. Vim wird installiert mit:

# emerge -av vim

---

Als nächstes sollte der ACPI Daemon installiert werden. Dies ist sinnvoll, da der Rechner dann stromsparend heruntergetaktet werden kann, und auch die Lüftersteuerung funktioiert, was den Lärmpegel nochmal reduziert.

Der Daemon wird installiert mit:

# emerge -av acpid

dann sollte auch dieser Daemon automatisch beim booten gestartet werden.

# rc-update add acpid default

Um ihn gleich zu starten geht es weiter mit:

/etc/init.d/acpid start

XEN

Nachdem unser Basissystem läuft, soll es so ausgebaut werden, daß es die einzelnen Dienste ausführen kann, die wir in unserem Netz anbieten wollen. In einem großen Netz würde man für die verschiedenen Bereiche (internes Netz, internet Dienste, Firewall) verschiedene Rechner verwenden. Die Applicance soll dies ja gerade zusammenführen; dennoch haben die meisten klassichen Lösungen dieser Art, den Nachteil, daß wird z.B. ein Internetdienst kompromittiert, dies die Sicherheit unseres gesamten Netzes gefährdet. Das Risiko läßt sich durch den Einsatz virtueller Maschinen zumindest reduzieren. Deshalb sollen alle Dienstetypen auf unterschiedlichen VMs laufen. Am Ende wird es eine Maschine für die Firewall geben, eine für die internen Dienste, und eine für die im Internet verfügbaren.

Um Xen zu installieren sind einige Vorbereitungen nötig. Zunächst muss die aktuellste Version des Portage verwendet werden. Herausfinden kann man das mit

eselect portage list

Der Stern in der Ergebnisliste sollte bei 2007.0 stehen. Falls dies nicht der Fall ist sollte man

emerge --sync

ausführen.

TLS und CFLAGS

Einige Programme, besonders die TLS Bibliotheken aus der glibc führen zu einem Konflikt mit XEN, namentlich der Art wie Xen die Segmentregister benutzt. Das führt zu einem Performanceverlust von bis zu 50%. Das Problem tritt nur bei x86_32 Architekturen auf. Um das zu verhindern muß das System mit dem Flag '-mno-tls-direct-seg-refs' neu übersetzt werden. Dazu muß die Datei '/etc/make.conf' angepasst werden:

CFLAGS="-O2 -march=i686 -pipe -mno-tls-direct-seg-refs"

Damit nicht für jede vittuelle Maschine das Basissystem neu übersetzt werden muß, sollte man die Gelegenheit nutzten, und das BUILDPKG-Feature von Gentoo nutzen. Dieses erlaubt es, fertige Binärpakete zu erzeugen, die ohne erneute Übersetzung auf das Zielsystem gebracht werden. Dazu muß die FEATURES Variable in '/etc/make.conf' angepasst werden. Dies geht mit folgendem Befehl:

echo 'FEATURES="${FEATURES} buildpkg"' >> /etc/make.conf

Jetzt kann man den Build-Prouzess neu starten (Achtung, das kann etwas dauern):

emerge -evat world

Um sicher zu gehen, daß alle Konfigurationsdateien richtig sind, sollte der Befehl:

etc-update

nicht vergessen werden!

Den Hypervisor installieren

Xen ist noch maskiert, deshalb müssen folgende Zeilen in '/etc/portage/package.keywords' hinzugefügt werden.

# Xen hypervisor
app-emulation/xen ~x86
app-emulation/xen-tools ~x86
sys-kernel/xen-sources ~x86

Anschließend kann der Hypervisor installiert werden:

# emerge -av app-emulation/xen app-emulation/xen-tools

Nun muß sichergestellt werden, daß der xen Daemon nach dem Neustart läuft:

# rc-update add xend default

Kernel kompilieren

Um den Xen-Kernel zu kompilieren, benutzen wir genkernel. Falls noch nicht geschehen, wird dies mit

# emerge genkernel

installiert.

Nun kann es losgehen. Zunächst installieren wir die Sourcen für den Xen-Kernel.

# emerge -av xen-sources

Dann ändern wir in der Datei '/etc/genkernel.conf' ein paar Zeilen:

MENUCONFIG="yes"

# Force genkernel-3.4 to use the arch-specific kernel config file from /usr/share/genkernel/${ARCH}
CLEAN="yes"
# Bootsplash doesn't work with Xen
BOOTSPLASH="no"
# Force use of Xen-specific genkernel profile in /usr/share/genkernel/x86-xen0
ARCH_OVERRIDE="x86-xen0"
# Necessary if you previously encountered the "mdev not found" error
CLEAR_CPIO_CACHE="yes"
CLEAR_CACHE_DIR="yes"

Damit genkernel den richtigen Kernel kompiliert, sollten wir nicht vergessen, den Symlink auf das Xen-Kernel Verzeichnis zu setzen:

# rm /usr/src/linux
# ln -s /usr/src/linux-2.6.20-xen-r6 linux

Bei Versionen von genkernel >=3.4.0 fehlt das architektur Target für x86-xen. In diesem Fall schlägt der Aufruf zu genkernel fehl (genaueres zu diesem Fehler: bug #120236. Das lässt sich aber zum Glück leicht beheben:

# wget http://bugs.gentoo.org/attachment.cgi?id=94540 -O x86-xen0.tar.bz2
# tar -xvjf x86-xen0.tar.bz2 -C /usr/share/genkernel/
# rm x86-xen0.tar.bz2

Wenn ihr eine Init-Ramdisk benutzen wollt, müsst ihr noch eine Modifikation an den Dateien von genkernel vornehmen. Aus irgendwelchen Gründen, schaltet nämlich die xen0-Architektur für genkernel die Verwendung von switch_root in busybox aus. Das führt dann dazu, daß der Init-Prozess nicht auf das eigentliche Root-Mount umschalten kann. Der Fehler wird mit dem Kommando:

# echo "CONFIG_SWITCH_ROOT=y" >>/usr/share/genkernel/x86-xen0/busy-config

behoben.

Vor dem Aufruf des Compilers müssen wir noch ein paar patches Einspielen, zumindest für unser Intel Board: Das Board hat zwar eine Lüftersteuerung, die Module dafür sind aber in der Kernelversion 2.6.20, die dem aktuellen Xen-Kernel zugrunde liegt, noch nicht drin.

Erstmal ins Buildverzeichnis wechseln

# cd /usr/src/linux

Nun laden wir die Patches herunter

# wget http://www.hobbes.ch/statisch/linuxfiles/patches/add-coretemp-driver.patch
# wget http://www.hobbes.ch/statisch/linuxfiles/patches/coretemp-add-documentation.patch
# wget http://www.hobbes.ch/statisch/linuxfiles/patches/hwmon-w83627ehf-add-w83627dhg-support.patch

Und nun wenden wir die patches an:

# patch -p1 -i add-coretemp-driver.patch
# patch -p1 -i coretemp-add-documentation.patch
# patch -p1 -i hwmon-w83627ehf-add-w83627dhg-support.patch

Wenn Menuconfig eingeschaltet ist muß unter

Device Drivers-->
  Hardware Monitor -->

Die 'Intel Core 2' Option zusätzlich eingeschaltet werden!

Nun können wir den Kernel konfigurieren und installieren. Der Kernel sollte wie jeder andere Kernel auf die benötige Hardware abgestimmt werden. Die Xen-spezifischen Optionen werden alle verfügbaren Optionen eingeschaltet (Frontend und Backend), weil wir denselben Kernel für Dom0 und DomU verwenden wollen (Multi-Dom-Kernel). Das ist nicht unbedingt notwendig, geht aber schneller. Achetet darauf, alle Module einzuschalten, die ihr für den Betrieb eures Kernels braucht, wenn Menuconfig aufgeht.

# genkernel all

Nun ist unser Kernel fertig, aber noch nicht ganz bereit. Xen kann leider keine genkernel initrds lesen, weil diese ein paar byte Müll am Ende des gzip-Archivs mit sich herumschleppen. Daher müssen wir das initrd-Image tatsächlich mit gunzip aus- und mit gzip wieder einpacken:

# cd /boot
# mv initramfs-genkernel-x86-xen0-2.6.20-xen-r60 initramfs-genkernel-x86-xen0-2.6.20-xen-r60.gz
# gunzip initramfs-genkernel-x86-xen0-2.6.20-xen-r60.gz
# gzip initramfs-genkernel-x86-xen0-2.6.20-xen-r60

Nun können wir den frisch gebackenen Kernel benutzen. Ich nehme zum Booten GRUB; PXELinux oder LiLo gehen natürlich auch, entsprechende Anleitungen finden sich hier.

Wir ändern die Datei '/boot/grub/grub.conf', indem wir einen neuen Eintrag hinzufügen. Den bisherigen Kernel sollte man in jedem Fall stehen lassen, damit es noch ein Fallback-System gibt, auf das man zurückgreifen kann, wenn Xen nicht geht:

title  Xen 3.0 / Linux 2.6.20
root   (hd0,0)
kernel /xen.gz
module /kernel-genkernel-x86-xen0-2.6.20-xen-r60 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda3
module /initramfs-genkernel-x86-xen0-2.6.20-xen-r60.gz

Abschließend muß GRUB neu installiert werden (nicht vergessen!):

# grub-install /dev/hda

Nun könnt ihr den Rechner neu booten. Wenn alles geklappt hat, sollte der Rechner zunächst den Hypervisor, und dann den neuen Kernel starten.

Den Lüfter leise bekommen

In meinem Gehäuse sind zwei Gehäuselüfter und ein CPU-Lüfter. Der CPU Lüfter ist weniger problematisch, weil er angenehm leise läuft. Die Gehäuselüfter dagegen machen unnötig Krach. Hauptgrund ist die Tatsache, daß sie mit voller Leistung laufen, obwohl die Gehäusetemperatur niedrig ist.

Um den Lüfter temperaturabhängig zu steuern, müssen wir die Kernelmodule für die Lüftersteuerung laden. Einkompiliert haben wir die Module ja vorhin schon. Nun müssen wir die zugehörigen Pakete installieren und konfigurieren.

# emerge -av lm_sensors fancontrol

Nun müssen wir herausfinden, welche Module wir brauchen. 'lm_sensors' nimmt uns den Großteil der Arbeit zum Glück ab. Der Aufruf von

# sensors-detect

startet einen Assistenten, der die nötige Konfigurationsdatei erstellt. Am einfachsten beläßt man alle Fragen auf den Standardeinstellungen, beantwortet also alle Fragen mit einfachem Druck auf 'Return'.

Wenn der Assistent fertig ist, können wir 'lm_sensors' testen. Dazu rufen wir

# /etc/init.d/lm_sensors start

auf. Wenn keine Fehlermeldungen kamen, liefert uns

# sensors

nun eine nette Übersicht über Temperatur, Lüfterdrehzahlen und Stromversorgung auf unserem Board. Graphische Tools wie 'grellkm' oder 'conky' bringen das auch auf den X11-Bildschirm, was uns jetzt aber nicht weiter interessiern muß.

Als nächstes müssen wir die Lüfterdrehzahl abhängig von der Temperatur steuern. Das Programm 'fancontrol' bedient sich dabei der Daten die 'lm_sensors' liefert. Zur Konfiguration gibt's ebenfalls ein passendes Skript. Dieses testet die Lüfterdrehzahlen, und versucht die richtigen Einstellungen zu finden. Da das Skipt ein paar mal fragt, ob der Lüfter gerade läuft, oder wann er anhält, sollte man das Skipt bei offenem Gehäuse durchführen, so daß man die Lüfter sehen kann. Aufgerufen wird das Skript mit:

# pwmconfig

Seid vorsichtig mit der Lüftersteuerung. Man kann mit angehaltenen Lüftern die CPU auch grillen! Am Ende sollte 'pwmconfig' die Datei '/etc/fancontrol' erzeugt haben. Mit dieser läßt sich der fancontrol Daemon nun starten

# /etc/init.d/fancontol start

Die Lüfter sollten nun deutlich langsamer, und damit leiser, laufen. Klappt alles, können wir die Daemons beim Start mitlaufen lassen:

# rc-update add lm_sensors default
# rc-update add fancontrol default

(wird fortgesetzt...)