Home Server, Teil 7 – Konfiguration: Linux-Installation in der UML Sandbox

Projekt 'Home-Server'

Der nächste Schritt ist die Installation eines Linux-Systems in die UML basierte Sandbox. Da normale Installationsprogramme noch kein UML System berücksichtigen, ist hier etwas Handarbeit angesagt, es geht also jetzt ans Eingemachte. Wer beim Wort ‘UNIX Shell’ erschrickt und nur das hilflose Kreisen der Maus beherrscht, dürfte eventuell jetzt ins Stolpern kommen. Spätestens dann, wenn man nicht den Fedora Core 3 als Host System nimmt und Adamantix für die Sandbox, wird man vermutlich um kleinere Anpassungen nicht herumkommen.

Warum ein UML System

Der Leitspruch eines erfahrenen IT’lers ist “Hardware ist böse, Software fehlerhaft”. Wenn Software dazu eingesetzt wird, irgendwelche Dienste im Internet anzubieten, werden Softwarefehler häufig ausgenutzt, um von aussen unberechtigt Zugang zu einem System zu erhalten. Es ist eine Binsenweisheit, dass es absolute Sicherheit nicht gibt – dies ist aber noch lange kein Grund, den Kopf in den Sand zu stecken. Man kann zumindest versuchen, die Auswirkungen von Sicherheitslücken zu minimieren und es dem ungewünschten Gast zu schwer wie möglich machen.

Ein UML System stellt eine Art virtuelles Linux dar, das aus Sicht der in der UML laufenden Applikationen wie ein eigenständiges Linux System aussieht, aus Sicht der Hostsystems aber nur wie eine ganz normale Applikation, die mit den Berechtigungen eines normalen Users läuft. Wenn jemand von aussen durch Ausnutzen einer Sicherheitslücke Zugriff auf das System erhält, erhält er prinzipiell erst einmal nur Zugriff auf das UML System. Um von dort aus Zugang zum Host System zu erhalten, hat der Angreifer vermutlich eine größere Hürde zu überwinden als beim Zugang zum UML System (zumindest wenn der SKAS Patch installiert ist, siehe Teil 6.

Die Übernahme eines UML Systems ist zwar sehr unschön, aber die wichtigen Daten (z.B. Daten für die Steuerklärung oder des privat genutzten Finanzen-Managers) befinden sich auf dem Hostsystem. Ein UML System erlaubt damit eine sehr einfache Realisierung eines mehrstufigen Sicherheitskonzeptes, so wie es in Firmen üblicherweise realisiert ist (wenn die Admins dort wissen, was sie tun).

Ziel ist die Installation von Adamantix in dem UML System. Adamantix hies früher mal “Trusted Debian”, musste aufgrund einer Namensregistrierung aber umbenannt werden. Das Ziel von Adamantix ist eine möglichst sicherere Linux Distribution zu erstellen, die dabei aber immer noch benutzbar bleibt. Für Server-Anwendungen, wie die von mir geplanten, bietet sich Adamantix geradezu an, für den Desktop fehlen noch viele Dinge.

Adamantix ist aus der Debian Woody Distribution entstanden. Die Installation erfolgt entweder über eine Boot-CD oder über ein Upgrade eines Debian Woody Systems. Ich bin den zweiten Weg gegangen und habe zunächst ein Minimal System auf Basis von Debian Woody installiert und dann das Upgrade auf Adamantix durchgeführt. Dies ist auch der Standard Weg, die Installation über die Boot CD ist noch relativ neu und sehr starr.

Vorbereitung

Der UML Kernel wurde bereits im letzten Kapitel erstellt, ebenso wurde dort bereits der User-Account und die Gruppe für die UML-Sandbox angelegt. Diese Tätigkeiten werden vorausgesetzt. Damit das UML System später mit minimalen Berechtigungen arbeitet, wird das Home-Verzeichnis für die Sandbox neu angelegt. Ausser dem UML Linux Kernel, einem Startscript und den Image-Dateien für die Dateisysteme wird nur noch ein ‘.uml’ und ein ‘tmp’ Verzeichnis benötigt:

-- Struktur und Berechtigung des Home-Verzeichnisses der Sandbox
[root@server]# cd /home
[root@server]# rm -rf inet
[root@server]# mkdir -p inet/images inet/.uml inet/tmp
[root@server]# chown -R user:vbox inet
[root@server]# chmod -R 755 inet
[root@server]# cd inet
[root@server]# chown inet:vbox .uml tmp
[root@server]# chown user:vbox images

-- Kopieren des UML Linux Kernels in das Home-Verzeichnis

[root@server]# cp ~user/uml/linux-2.6.10/linux .
[root@server]# chown user:xbox linux
[root@server]# chmod 750 linux

Als nächsten werden die leeren Image-Dateien angelegt. Für das UML System habe ich ein 1 GB grosses Root-Filesystem geplant, ein ebenfalls 1 GB grosses Var-filesystem (/var) und ein 2 GB grosses Home-Filesystem (/home). Bei der Erstellung gibt es zwei Varianten, die jeweils ihre Vor- und Nachteile haben.

Variante 1: Filesystem-Images als Sparse Files

Zum einem kann man die Images als ‘Sparse Files’ anlegen. Damit belegen die Dateien immer nur den tatsächlich benötigten Plattenplatz auf dem Host-System. Anfänglich ist dies vernachlässigbar, weil beim Formatieren nur die Verwaltungs-Informationen für das Dateisystem geschrieben werden. Der Nachteil ist, dass die Dateien im Betrieb wachsen und das Host-System dafür jedesmal freie Sektoren suchen muss, was etwas dauern kann. Da die aus dem UML System geschriebenen Daten in der Regel keine ganzen Sektoren belegen, werden beim Schreiben die Sektoren mit Daten aus dem Speicherraum des Host Systems aufgefüllt. Für eine UML, die Internet Dienste anbietet, birgt dies ein höheres Restrisiko.

[root@server]# cd /home/inet/images
[root@server]# dd if=/dev/zero of=root-fs.img bs=1M count=0 seek=1024
[root@server]# dd if=/dev/zero of=var-fs.img  bs=1M count=0 seek=1024
[root@server]# dd if=/dev/zero of=home-fs.img bs=1M count=0 seek=2048
[root@server]# dd if=/dev/zero of=swap-fs.img bs=1M count=0 seek=256
Variante 2: Initialisierte Filesystem-Images

Die zweite Variante füllt die Filesystem-Images mit Nullen und belegt auch gleich den benötigten Plattenplatz. Die Wahrscheinlichkeit, dass die Images dann als ein Block oder zumindest in wenigen Blöcken auf der Festplatte liegen, ist hier auch größer. Je zerstückelter die Images auf der Festplatte verteilt sind, desto träger ist der Zugriff (eine weitere Gefahr von Variante 1). Angesichts der 160 GB Platte und dem Ziel eine Sandbox für Internet-Dienste aufzubauen, habe ich mich für Variante 2 entschieden:

[root@server]# cd /home/inet/images
[root@server]# dd if=/dev/zero of=root-fs.img bs=1M count=1024
[root@server]# dd if=/dev/zero of=var-fs.img  bs=1M count=1024
[root@server]# dd if=/dev/zero of=home-fs.img bs=1M count=2048
[root@server]# dd if=/dev/zero of=swap-fs.img bs=1M count=256
Formatieren der Dateisystem-Images

Die Dateisystem-Images sehen später aus Sicht des UML Systems wie einzelne Partitionen auf der Festplatte aus. Eine Gesamtsicht der Art “ganze Festplatte” gibt es nicht – die Partitionierung entfällt daher (gewissermassen wird die Partitionierung durch die Größe und Zahl der Dateisystem-Images vorgenommen). Im nächste Schritt sind daher die Images zu formatieren, anschließend wird dem späteren Sandbox-User noch die Schreibberechtigung gegeben:

[root@server]# mkfs.ext3 -j -O ^resize_inode -b 2048 -m 2 -L root -F ./root-fs.img
[..]
[root@server]# mkfs.ext3 -j -O ^resize_inode -b 2048 -m 5 -L var  -F ./varfs.img

[..]
[root@server]# mkfs.ext3 -j -O ^resize_inode -b 2048 -m 1 -L home -F ./homefs.img
[..]
[root@server]# mkswap swapfs.img
Setting up swapspace version 1, size = 268431 kB
[root@server]# chown inet:vbox *
[root@server]# chmod 644 *

Installation des Debian Woody Minimal-Systems

Das Ziel ist Adamantix im Zuge eines Upgrades von Debian Woody zu installieren. Dafür reicht ein Debian Woody Minimal-System. Für die Installation gibt es das Debian Bootstrap Tool (debootstrap_0.2.45-0.1_i386.deb), dass wir zunächst auf dem Host System installieren. Die Installation selbst erfolgt in die gerade angelegten Dateisystem-Images:

-- Download des Debian Boottrap Tools
[root@server]# cd /files/share/downloads
[root@server]# wget http://ftp.debian.org/debian/pool/main/d/debootstrap/debootstrap_0.2.45-0.1_i386.deb
[root@server]# cd /
[root@server]# ar -xf /files/share/downloads/debootstrap_0.2.45-0.1_i386.deb

-- Mounten der Dateisystem-Images
[root@server]# mkdir -p /mnt/umlroot /mnt/iso
[root@server]# mount /home/inet/img/root-fs.img /mnt/umlroot -o loop
[root@server]# mkdir -p /mnt/umlroot/home /mnt/umlroot/var
[root@server]# mount /home/inet/img/home-fs.img /mnt/umlroot/home -o loop
[root@server]# mount /home/inet/img/var-fs.img /mnt/umlroot/var -o loop

-- Installation des Basissystems
[root@server]# cd ~
[root@server]# /usr/sbin/debootstrap --arch i386 woody /mnt/umlroot http://http.us.debian.org/debian
I: Validating debootstrap.invalid_dists_woody_Release
I: Retrieving debootstrap.invalid_dists_woody_main_binary-i386_Packages
I: Validating debootstrap.invalid_dists_woody_main_binary-i386_Packages
I: Checking adduser...
I: Checking apt...
I: Checking apt-utils...
[..]
I: Base system installed successfully.
umount: /mnt/umlroot/dev/pts: not mounted
umount: /mnt/umlroot/dev/shm: not found
umount: /mnt/umlroot/proc/bus/usb: not mounted
Abschließende Konfigurationstätigkeiten

Im Prinzip haben wir jetzt ein lauffähiges Debian System, aber nur im Prinzip. Die derzeitige Installation ist für ein normales “Nicht-UML Linux” gedacht. Bei einem UML System sind zunächst noch zwei UML spezifische Dinge zu beachten. Zum einem booten wir einen speziell erstellten UML Kernel, der nichts mit dem von Debian Woody verwendeten Kernel zu tun hat. Der Kernel im Dateisystem-Image wird nicht verwendet und die Module im Image passen nicht zu dem 2.6.10 basierten UML Kernel. Daher müssen noch die Module in das Image transferiert werden:

[root@server]# cd /home/user/uml/linux-2.6.10
[root@server]# make modules_install INSTALL_MOD_PATH=/mnt/umlroot ARCH=um

/etc/fstab

# /etc/fstab @ UML
/dev/ubd0       /               ext3    defaults        1 1
/dev/ubd1       /var            ext3    defaults        1 2
/dev/ubd2       /home           ext3    defaults        1 2
none            /proc           proc    defaults        0 0
none            /dev/pts        devpts  gid=5,mode=620  0 0
/dev/ubd3       swap            swap    defaults        0 0
/dev/ubd4       /mnt/cdrom      auto    defaults        0 0

Weiterhin werden die Dateisystem-Images beim Aufruf des UML Kernels als Parameter mitgegeben. Die Images sind im UML System als einzelne Devices sichtbar. Ein “normales” Linux kennt diese Devices nicht, darum sind sie nach der Bootstrap Installation auch noch nicht vorhanden. Sie sind daher jezt noch anzulegen:

[root@server]# cd /mnt/umlroot/dev
[root@server]# mknod ubd0 b 98 0
[root@server]# mknod ubd1 b 98 16
[root@server]# mknod ubd2 b 98 32
[root@server]# mknod ubd3 b 98 48
[root@server]# mknod ubd4 b 98 64
[root@server]# mknod ubd5 b 98 80
[root@server]# mknod ubd6 b 98 96
[root@server]# mknod ubd7 b 98 112

Beim Booten liest Linux aus der Datei /etc/fstab die Zuordnung der Partitionen raus, also welche Partition wo im Dateisystem eingehängt wird. Diese Datei ist nach der Bootstrap-Installation noch leer und muss jetzt angelegt werden. Den Inhalt der Datei kann man dem Kasten rechts entnehmen.

Einrichtung des Netzwerkes

UML Netzwerk Varianten

Es gibt (derzeit) sieben Arten, wie man in einem UML System ein Netzwerk einrichtet. Hier eine kurze Übersicht:

  • ethertap: Das UML System arbeitet als eigenständiger “Rechner” im gleichen Netzwerk wie das Host System. Diese Variante ist für Hosts gedacht, die mit einem Kernel der Version 2.2 arbeiten. Auf dem Host System wird ein Hilfsprogramm benötigt (uml_net).
  • TUN/TAP: Das UML System arbeitet als eigenständiger “Rechner” im gleichen Netzwerk wie das Host System. Dies Variante ist für Hosts gedacht, die mit einem Kernel der Version 2.4 oder neuer arbeiten. Diese Variante kommt auch ohne Hilfsprogramm aus.
  • Multicast: Für die Einrichtung eines rein virtuellen UML Netzwerkes, nur in Sonderfällen interessant.
  • Slip: Nur interessant, wenn aus irgendwelchen Gründen weder ethertap noch TUN/TAP zur Verfügung steht.
  • Slirp: Nur interessant, wenn man entweder keine Root-Rechte auf dem Host-System hat oder dem UML System keine eigene IP Adresse verpassen möchte.
  • PCAP: Diese Variante ist interessant, wenn das UML System nur lauschen soll, selbst aber keine Daten sendet. Das UML System sieht hier alle Pakete, die am Netzwerk-Interface des Host Systems ankommen. Dies kann z.B. in Ausnahmefällen für die Netzwerk-Verkehrsüberwachung sinnvoll sein.

Sofern man auf das Netzwerk verzichten kann, könnte man nun die Dateisysteme vom Host System aushängen und das UML System booten. Aber ohne Netzwerk ist eine Sandbox in der Regel ziemlich nutzlos. Es gibt insgesamt sieben Varianten, wie man ein UML System netzwerkfähig machen kann. Einen Überblick gibt der Kasten auf der linken Seite.

In meinem Fall läuft auf dem Host ein 2.6 basierter Kernel, weiterhin soll das UML System wie ein eigenständiger Host im lokalen Netzwerk arbeiten. Damit Internet bezogene Services angeboten werden können, muss der DSL-Router in der Lage sein, Pakete gezielt an das UML System weiterzuleiten. Da der DSL Router seine Ziele nur anhand der IP Adresse unterscheidet, benötigt das UML System eine eigene. Es wurde daher der TUN/TAP Mechanismus verwendet, der für die Netzwerk-Anbindung von UML Systemen heute grundsätzlich die erste Wahl sein sollte.

Da das UML System ein virtuelles System ist und damit kein eigenes Netzwerk-Interface im physikalischem Sinne hat, muss das Host System die Pakete annehmen. Es ist aber auch nicht gewünscht, dass das Host System die Pakete verarbeitet, also sich mit den Inhalten der Netzwerkpakete beschäftigt. Wäre dies der Fall, könnte man z.B. mit manipulierten Paketen versuchen, auf dem Host System eine Sicherheitslücke auszunutzen und der Sicherheitsvorteil des UML Systems wäre dahin.

Das Zauberwort an dieser Stelle heisst Bridge. Im Gegensatz zu einem Router, der verschiedene IP Netzwerke miteinander verbindet, vermittelt eine Bridge innerhalb eines IP Netzwerkes zwischen verschiedenen Segmenten. Die Bridge lernt selbsttätig, welche IP Adressen auf welcher Seite der Bridge (in welchem Segment) existieren und leitet Pakete entsprechend weiter. Aus Sicht der Netzwerkteilnehmer arbeitet eine Bridge vollständig transparent, sie ist nicht sichtbar. Sie taucht daher z.B. auch nicht in einem traceroute auf.

Das Netzwerk-Interface eth0 muss zu dem Interface der Bridge gemacht werden. Damit verliert das Host System zunächst selbst den Anschluß an das Netzwerk, die nachfolgenden Befehle können daher nicht remote durchgeführt werden (nicht ganz richtig: wer zwei Netzwerk-Interfaces hat, kann die Aktionen natürlich über das zweite Interface durchführen, z.B. über das Guest LAN). Nachdem die Bridge erstellt ist, wird im ersten Schritt das Host System selbst an die Bridge angeschlossen, im zweiten das UML System. Die folgenden Befehle sollte man daher in Form eines Shell Scripts speichern und bei jedem Systemstart des Host Systems direkt nach der Initialisierung des Netzwerkes aufrufen:

#!/bin/bash
#
# This script must be run once at the system start. You may store it in /etc/rc.d and set a
# symbolic link in /etc/rc3.d. Anyhow you do it, it should run before starting any network
# related service since the changes on the interface may confuse them.
#
# Using interface eth0 for setting up the bridge. The interface must run in promiscuous
# mode using the IP address 0.0.0.0 to work as bridge.
ifconfig eth0 0.0.0.0 promisc up

# Create the bridge and disable searching for other bridges.
brctl addbr umlbr
brctl setfd umlbr 0
brctl sethello umlbr 0
brctl stp umlbr off

# Setting up the created 'umlbr' interface with the IP address used so far. Bind the eth0
# interface to the logical bridge.
ifconfig umlbr 192.168.100.253 netmask 255.255.255.0 up
brctl addif umlbr eth0

# The server should have a working network connection again. However, the default routing
# entry has gone and must be added to the routing list.
route add default gw 192.168.100.254

# The UML system connects to the bridge using a 'tun' device. To get this work, the UML 
#system needs write access on the 'tun' device.
chown root:vbox /dev/net/tun
chmod 660 /dev/net/tun

# Setting up a 'tun' interface for the UML providing Internet related services.

tunctl -u inet -t conn0
ifconfig conn0 0.0.0.0 promisc up
brctl addif umlbr conn0

# Setting up a second 'tun' interface for the UML used to build programs for the first UML
# not available as packages.
tunctl -u user -t conn1
ifconfig conn1 0.0.0.0 promisc up
brctl addif umlbr conn1

Wie man an dem Script sieht, habe ich die Bridge für zwei UML Systeme eingerichtet. Der Grund ist relativ einfach. Adamantix stellt nicht für jede Software bereits ein Paket bereit. Es gibt daher Fälle, in denen man mit der Adamantix Entwicklungsumgebung Software aus den Sourcen heraus erstellen muss. Es erscheint aber wenig ratsam, in einer für Internet Services gedachten Sandbox gleich einen ganzen Werkzeugkasten bereitzustellen, den dann auch die nutzen können, die ein kleines Loch in die Sandbox rein gefunden haben. Ich habe daher alle Dateisystem-Images, wie sie jetzt existieren, kopiert. Die zweite UML läuft mit dem normalen User-Account und sie wird auch nur dann gestartet, wenn ich Software übersetzen muss. Von aussen ist sie natürlich nicht erreichbar.

Wichtig: der Samba Server wird nun mit den Einstellungen aus dem 4. Teil keine Clients aus dem Private LAN mehr akzeptieren, da diese nicht mehr über eth0 sondern über umlbr gesehen werden. Daher ist in der Zeile interfaces = noch das neue Interface umlbr anzufügen.

Start des UML Systems

Es ist soweit, das UML System kann jetzt gestartet werden. Standardmäßig öffnet das UML System für jedes Terminal (unter dem normalen Linux: ALT-1 bis ALT-7) ein xterm, dies ist eher nervig. Der nachfolgende Befehl unterdrückt diese xterms und läßt den Login-Prompt in dem Hauptfenster, in dem die UML gestartet wurde, erscheinen. Weiterhin bekommt die UML 128 MB Speicher reserviert. Für das Consolen-Tool, mit dem vom Host System aus das UML System beeinflusst werden kann, wird ein Name mit angegeben (umid=). Für die Netzwerk-Kommunikation wird das eth0 Interface in der UML mit dem oben erzeugten ‘conn0’ Device verbunden:

[user@server]$ su - inet
[inet@server]$ cd images
[inet@server]$ ../linux umid=inetuml mem=128M ubd0=root-fs.img ubd1=var-fs.img ubd2=home-fs.img
                        ubd3=swap-fs.img con=pty con0=null,fd:2 con1=fd:0,fd:1 eth0=tuntap,conn0
[inet@server]$ reset

Das UML System sollte booten und nach einiger Zeit mit dem Login-Prompt warten. Fehlermeldung über unbekannte Partitionstabellen können ignoriert werden. Die Images werden als Partitionen angesprochen, ein Ö?quivalent für die Festplatte gibt es nicht und damit auch keine Parititonstabelle. Weiterhin erscheinen Fehlermeldungen der Art “QM_MODULES: Function not implemented”, auch diese zunächst ignorieren. Die alten Debian Tools für das Modul-Management des Kernels vertragen sich nicht mit dem 2.6 Kernel. Dazu ist das Paket module-init-tools neu zu übersetzen und zu installieren (in der UML). Die PCMCIA Services werden auch noch gestartet, auch dies ist noch abzuschalten.

Viel wichtiger ist aber, die Netzwerk-Schnittstelle des UML Systems zu konfigurieren. Dazu meldet man sich als root an der UML an (kein Passwort) und sorgt dafür, dass das folgende Shellscript bei jedem Startvorgang des UML Systems ausgeführt wird (‘chmox +x …’ nicht vergessen):

#!/bin/bash

ifconfig eth0 hw ether 01:01:01:01:01:01
ifconfig eth0 192.168.100.200 up
ifconfig lo 127.0.0.1 up

route add default gw 192.168.100.254
hostname inetuml

Für die weiteren UMLs sind natürlich andere Ethernet und IP Adressen sowie andere Hostnamen zu verwenden. Wenn das Script richtig eingebunden ist (Link in rc3.d auf das Script anlegen), sollte die UML nach dem nächsten Bootvorgang einen gültigen Hostnamen und eine Verbindung zum Netzwerk haben. Wenn das Netzwerk mit IP Adressen funktioniert, aber keine Namen aufgelöst werden, ist der Inhalt der Datei /etc/resolv.conf zu prüfen. Dort sollte die IP Adresse des DNS Servers eingetragen sein. Wenn alles klappt, sollte man Server im Internet anpingen können:

zaphod:~# ping www.kernel.org
PING zeus-pub.kernel.org (204.152.189.116): 56 data bytes
64 bytes from 204.152.189.116: icmp_seq=1 ttl=54 time=220.7 ms
64 bytes from 204.152.189.116: icmp_seq=2 ttl=54 time=218.8 ms

Upgrade auf Adamantix

/etc/apt/sources.list

deb http://ftp.szczepanek.de/adamantix/ stable main contrib
deb http://security.adamantix.org/ stable-security main contrib

Sobald die Netzwerkverbindung steht, kann das Upgrade auf Adamantix erfolgen. Die Upgrade selbst erfolgt über die Standard-Bordmittel des Debian Woody Systems, auf dem Adamantix selbst auch basiert. Im ersten Schritt sind dazu die Quellen zu definieren, auf denen die Adamanix Pakete liegen. Die Definitionen befinden sich in der Datei /etc/apt/sources.list (siehe Kasten rechts). Sobald die Datei geändert ist (es sollten nur die beiden Adamantix-Quellen in der Datei stehen), erfolgt das Upgrade mit den folgenden Befehlen:

[root@uml]# apt-get update
[root@uml]# apt-get install libncurses5
[root@uml]# apt-get dist-upgrade

Mit dem nächsten Booten läuft die UML unter Adamantix. Die nächsten Schritte installieren noch ein paar Basistools nach, die man in der Regel immer benötigt sowie OpenSSH, mit dem man einen verschlüsselten und abgesicherten Zugang zu der UML von aussen bereitstellen kann (spätestens jetzt sollte unbedingt ein Passwort für den root-User angegeben werden!):

[root@uml]# apt-get install wget
[root@uml]# apg-get install bzip2
[root@uml]# apt-get install ssh
[root@uml]# apt-get install screen

-- Wenn man 'irssi' als IRC Client oder IRC Proxy/Bouncer nutzen möchte,
-- benötigt man noch folgende Pakete zusätzlich:
[root@uml]# apt-get install perl
[root@uml]# apt-get install libperl-dev
[root@uml]# apt-get install libglib2.0

Zu guter letzt müssen noch die Kernel Module Tools aktualisiert werden. Debian Woody basiert auf dem Kernel 2.4, das UML System auf dem Kernel 2.6. Die für den 2.6er Kernel fertig übersetzten Module Tools stelle ich über meinen Webspace bereit. Im Anschluß werden dann gleich noch die PPP und PCMCIA Services deaktiviert, die man in der UML nicht benötigt. Der pwconv Befehl lagert die Passwörter aus der /etc/passwd in die geschützte /etc/shadow aus.

[root@uml]# cd /tmp
[root@uml]# wget http://www.q-vadis.net/download/module-init-tools-3.1-UML.tgz
[root@uml]# cd /
[root@uml]# tar xfz /tmp/module-init-tools-3.1-UML.tgz
[root@uml]# depmod -a
[root@uml]# cd /etc/rc3.d
[root@uml]# mv S20pcmcia _S20pcmcia
[root@uml]# mv S14ppp _S14ppp
[root@uml]# pwconv

UML Entwicklungs-/Testsystem

Pakete für das Entwicklungssystem

[root@uml]# apt-get install gcc
[root@uml]# apt-get install wget
[root@uml]# apg-get install bzip2
[root@uml]# apt-get install g++
[root@uml]# apt-get install apache2-mpm-worker
[root@uml]# apt-get install libglib2.0
[root@uml]# apt-get install libncurses5-dev
[root@uml]# apt-get install autoconf
[root@uml]# apt-get install make
[root@uml]# apt-get install libperl-dev
[root@uml]# apt-get install automake
[root@uml]# apt-get install cvs
[root@uml]# apt-get install libtool
[root@uml]# apt-get install ssh
[root@uml]# apt-get install docbook

Nicht jede Software gibt es fertig als binäres Adamantix und man braucht ja auch nicht jede. Es ist aber keineswegs unwahrscheinlich, dass man über kurz oder lang über etwas stolpert, was man gerne in der UML einsetzen möchte, was es aber noch nicht als fertiges Adamantix Paket gibt. Prinzipiell ist das alles kein Thema, schließlich kann man die Software unter Linux üblicherweise sehr einfach selbst übersetzen und installieren. Dazu braucht man in den meisten Fällen den GNU C/C++ Compiler sowie ein paar weitere Tools aus dem Software-Entwicklungsumfeld. Es ist aber wenig ratsam, diese Umgebung auf einer UML laufen zu lassen, die dazu gedacht ist, Services im Umfeld des Internets anzubieten.

Wer oben bereits die Dateisystem-Images kopiert hat, muss nur die letzten Schritte parallel noch einmal durchführen. Alternativ kopiert man jetzt die Images und ändert die Netzwerk-Einstellungen (IP Adresse, Hostname, Ethernet-Adresse). Das Entwicklungssystem kann man sorglos mit dem normalen User-Account nutzen, von aussen sollte natürlich kein Zugang existieren.

Der Kasten rechts zeigt die wichtigsten Pakete an, die man in der Regel zusätzlich braucht. Je nach zu übersetzender Software können natürlich weitere Pakete notwendig werden. Wer den IRC Client/Proxy irssi übersetzen will, braucht dazu noch das docbook-utils Package auf dem Entwicklungssystem. Leider gibt es dazu kein Adamantix Package, aber für das Entwicklungssystem kann man hier durchaus auch das Woody-Paket nutzen (es wird nur für die Übersetzung der Man-Pages genutzt und nicht auf dem “Produktivsystem” benötigt). Dazu ist in der Datei /etc/apt/sources.list eine Quelle für Debian Woody einzutragen und dann das Paket mit apt-get install docbook-utils zu installieren. Ich empfehle nach der Installation wieder ein auskommentieren der Woody-Quelle.

Um Software vom Entwicklungssystem in das Zielsystem zu übertragen, empfiehlt sich eine Installation der Software in einer leeres Verzeichnis. Dort packt man die Daten zusammen und überträgt sie z.B. mittels des SSH Zugangs in das Zielsystem.

Ich hoffe, dass dieser Teil als eine Art Kochrezept zum Erstellen eines UML Systems geeignet ist. Was man in dem UML System laufen läßt, ist natürlich von den persönlichen Wünschen abhängig. Ich lasse in meiner UML z.B. einen IRC Proxy/Bouncer laufen, der ständig die Verbindung in einen von mir administrierten IRC Channel hält. Weiterhin ermöglicht mir das UML System per SSH Zugang von aussen – natürlich nur über einen Public-Key Mechanismus, bei dem auf dem anfragenden Client ein entsprechendes, Kennwortgeschütztes Key-File vorliegen muss.

Surftip(p)s (englisch)

6 Kommentare zum Artikel “Home Server, Teil 7 – Konfiguration: Linux-Installation in der UML Sandbox”

  1. Zunächst Kompliment für die Gute Arbeit! Deine Einleitung finde ich echt prima. Aber dennoch: Bin gerade Dabei, mir unter Suse 9.3 in einer UML-Umgebung IPcop einzurichten. Deine Einleitung hat mich bisher am weitesten gebracht aber leider noch nicht zum Ende. Was muss ich tun, um das besagte IPcop z. B. von aus einer ISO-Datei oder CDROM-Laufwerk anstelle von der “Installation des Debian Woody Minimalsystem” – wie Du das in Kap. 7 beschrieben hast? Es geht also um die Installation des Systems in der UML. Wäre echt prima, falls jemand den einen oder anderen Tipp in diesem Zusammenhang für mich hätte.Danke:-)

  2. Hallo,

    in dem Zusammenhang ist vielleicht das c’t Debian Server Projekt und das ctserver.org Forum ganz interresant…

  3. Hallo,

    zunächst mal Respekt für die Side, sehr übersichtlich und informativ.

    Zu meinem Anliegen: Seit meinem Umzug habe ich kein DSL mehr, sondern stelle die Verbindung zum Internet über eine WLAN-Strecke her. Und da habe ich im Moment mein Problem. Im Moment ist der Server nur mit einem Firewallscript im Netz. Gefällt mir logischerweise nicht. Ich bekomme aber die WLAN-Karte in der tun/tap Umgebung nicht konfiguriert. Hat jemand eine Ahnung, wie und vor allem wo ich die WLAN-Karte in der tun/tap-Umgebung konfiguriere? Geht das überhaupt?

    Meine Konfiguration:
    Server: Debian 3.1 sarge 2.6er Kernel
    UML: Debian 3.1 sarge 2.4er Kernel
    Netzwerkkarte für das interne Netzwerk: eth0 (intel sowieso…)
    Netzwerkkarte zum Internet: ath0 (netgear wg311T mit madwifi-Treibern)

    Authorisierung beim Provider über dynamisches WEP per RADIUS (xsupplicant)

    Konfiguriert habe ich folgendes:
    eth0 mit br0 und ath0 mit br1 verbunden
    tap0 an eth0 der UML und br0 des Servers, tap1 an eth1 der UML und ath0 des Servers “angeschlossen”
    IP von eth1 der UML als Standardgateway des Servers eingetragen und NAT in der UML aktiviert

    -> ich kann die IP von eth1 der UML von allen Rechnern anpingen, bekomme aber keine Verbindung zum AP, da die wireless-tools innerhalb der UML kein WLAN-device finden…

    In der Hoffung, das die Beschreibung nicht allzu verwirrend ist und jemand einen Tipp hat

    MARTIN

  4. Hi,

    sehr sauber gemachtes Tutorial, jedoch ist mir ‘ne Kleinigkeit aufgefallen und zwar setzt du die Ether Adresse der UML erst, nachdem diese hochgefahren ist. Es gibt auch einen Parameter hierfuer, so dass bereits beim Aktivieren des UML-Netzwerkdevices die richtige Etheradresse gesetzt wird: eth0=tuntap,umlcon0,FE:FD:00:00:00:00, z.B. fuer DHCP ganz nuetzlich.

    Ansonsten gute Arbeit, hat Spass gemacht sie durchzulesen.

    Gruss, Chris

    PS. Und ein Typo ist mir aufgefallen, eigentlich zwar unwichtig aber bei einer sonst einwandfreien Howto kann man ja darauf hinweisen, zu finden unter:
    TUN/TAP: Das UML System arbeitet als eigenständiger ”Rechner” im gleichen Netzwerk wie das Host System. Dies Variante …

  5. hallo,
    super gemacht alles ,hoffe das du weiter drann arbeitets ,weil ich noch gerne wissen möchte wie man aus den server ein webserver machen kann für zu hause . da ich entlich mal lehrnen will http,php usw.
    danke
    carsten

    • Der sollte “eigentlich” schon an Bord sein (jedenfalls bei einer Fedora-Vollinstallation). Falls nicht, brauchst du die Pakete für den Apache (Empfehlung: 2.x), den PHP Interpreter (Empfehlung: 5.x) und die MySQL Datenbank (oder alternativ PostgreSQL).

      Ggf. mußt du noch dafür sorgen, dass der Apache und die MySQL Datenbank beim Booten startet. Der PHP Interpreter hängt am Apache dran und muß nicht extra gestartet werden.

      Im Fall von Fedora ist das Web-Verzeichnis /var/www/html. Wenn du dort eine index.html reinschmeißt, solltest du den Inhalt beim Aufruf von http://localhost sehen.

Schreibe einen Kommentar


Beim Speichern ihres Kommentars wird auch ihre IP Adresse gespeichert (nur für den Website-Betreiber einsehbar)!