Appliance im Eigenbau: Unterschied zwischen den Versionen

Aus CCC Bremen
Keine Bearbeitungszusammenfassung
Zeile 102: Zeile 102:
nicht vergessen werden!
nicht vergessen werden!


'''Install the Hypervisor'''
'''Den Hypervisor installieren'''


Xen ist noch maskiert, deshalb müssen folgende Zeilen in '/etc/portage/package.keywords' hinzugefügt werden.
Xen ist noch maskiert, deshalb müssen folgende Zeilen in '/etc/portage/package.keywords' hinzugefügt werden.
Zeile 154: Zeile 154:
  # rm x86-xen0.tar.bz2
  # rm x86-xen0.tar.bz2


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.
 
 
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.
 
 
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
  # 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 [http://gentoo-wiki.com/Xen#Updating_your_boot_loader 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.1 / Linux 2.6.12.6
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.


(wird fortgesetzt...)
''(wird fortgesetzt...)''

Version vom 2. November 2007, 12:51 Uhr

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

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.


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.1 / Linux 2.6.12.6
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.

(wird fortgesetzt...)