Home Server, Teil 6 – Konfiguration: Optimierter Host- und UML Kernel

Projekt 'Home-Server'

Im häuslichen LAN stellt der Home-Server bereits die wesentlichen Dienste bereit, Schmankerl wie die Aufnahme von TV-Sendungen über Digital-SAT kommen später. Angesichts des bescheidenen TV Programms eilt die Sache ja auch nicht so sehr. Das nächste Ziel ist die Bereitstellung von Services, die das Internet permanent nutzen (z.B. ein IRC Proxy/Bouncer) bzw. sogar über das Internet verfügbar sind (Remote-Zugriff über die Secure Shell). 100%ige Sicherheit gibt es nicht aber diese Binsenweisheit muss ja nicht dazu führen, dass man fahrlässig handelt. Also müssen diese Dienste in einen “Sandkasten”, wenn man den üblichen Begriff ‘Sandbox’ direkt übersetzt.

Das Stichwort an dieser Stelle heisst UML (User Mode Linux). Wer mehr als einen Server betreiben möchte, findet sicher bessere Lösungen – mir persönlich reicht aber ein Server zu Hause vollkommen aus. UML steht für User-Mode-Linux und bietet die Möglichkeit auf einem Linux basierten Host-System (in meinem Fall der mit Fedora Core 3 laufende Home-Server) ein weiteres Linux (UML) wie ein normales Anwendungsprogramm zu starten. In diesem UML können dann wieder beliebige Linux-Services laufen. Der Vorteil des ganzen: das UML selbst läuft mit normalen User-Berechtigungen auf dem Host-System. Sollte jemand von aussen durch Ausnutzen einer Sicherheitslücke Zugriff auf das UML System bekommen, dann hat er damit noch längst nicht Zugriff auf das Host-System. Da ein Anwendungsgebiet von UML u.a. der Betrieb von diesen “Sandkästen” sind, gibt es auch einige spezielle Kniffe, um das Host-System möglichst weit vor einem UML zu schützen.

Ein Schutz betrifft dabei die Aufteilung des Arbeitsspeichers. Mit einem normalen Kernel sieht das UML grundsätzlich den gleichen Speicherbereich wie das Host-System. Prinzipiell ist daher durchaus noch ein Zugriff vom UML aus auf Speicherinhalte des Host-Systems möglich. Es gibt aber einen Kernel-Patch (SKAS = Separate Kernel Address Space), der genau dies verhindert und dem UML einen getrennten Speicherbereich anbietet. Leider ist dieser SKAS Patch nicht im Fedora Core Kernel drin. Allerdings ist der Fedora Core Kernel wie praktisch alle Kernel von den bekannten Linux Distributionen auch ein Universalkernel und nicht auf das VIA EPIA System optimiert und schleppt damit auch viel unnötigen Balast mit sich rum. Zeit, einen optimierten Kernel zu backen. Genaugenommen sogar zwei. Einen für das Host-System und einen UML Kernel.

EPIA Kernel 2.6.10 Config

Anklicken für Download

Hinweis: Der optimierte Host-Kernel ist nur die Kür, nicht die Pflicht. Man kann das nachfolgend beschreibene UML System auch mit dem Standard Fedora Core (oder anderen) Kerneln aufsetzen, mit etwas höherem Risiko. Weiterhin ist selbst der UML Kernel nicht zwingend notwendig. Wer mutig ist oder meint, er hätte nichts zu verlieren, kann die Internet-Services auch direkt auf dem Host System laufen lassen. Je nachdem, um welche Services es sich handelt und in wie weit von aussen ein Zugriff auf diese Services möglich ist, stellt sich dann nur die Frage, ob der Betreiber nicht auch schon den Verstand verloren hat ;-)

EPIA optimierter Linux Kernel (Host)

Üblicherweise befinden sich die Linux Kernel Sourcen in dem Verzeichnis /usr/src/linux. Beim Fedora Core liegen die Kernel Sourcen leider nicht mehr in diesem Format vor, sondern aufgeteilt in diverse Pakete unter /usr/src/redhat. Da ein Ziel das Einspielen des SKAS Patches war und ich nicht Versuchskaninchen spielen wollte, ob dieser Patch auch noch problemlos mit dem normalerweise modifiziertern Fedora Core Kernel Sourcen zusammen passt, habe ich mich entschlossen, die Original Kernel Sourcen zu verwenden – häufig auch als “Vanilla Kernel Sourcen” bezeichnet. Der Vorteil ist, dass auch andere Patches üblicherweise immer für die Standard Sourcen gedacht sind und damit auch funktionieren sollten.

Als Basis wurde der Kernel 2.6.10 ausgewählt. Den 2.6.9 Kernel sollte man nicht verwenden, es gibt mit ihm zahlreiche Probleme; ich vermute, dass auch die anfänglichen Stabilitätsprobleme hier ihre Ursache dort hatten, nach dem Update auf den 2.6.10er Kernel von Fedora läuft der Server “rock solid”, so wie es sein soll. Nebem dem Kernel wird dann noch der SKAS Patch benötigt:

[user@server]$ mkdir -p /files/share/downloads; cd !$
[user@server]$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
[user@server]$ wget http://www.user-mode-linux.org/~blaisorblade/patches/skas3-2.6/host-skas3-2.6.10-v7.patch

Die Sourcen für den Host-Kernel werden in dem Verzeichnis /usr/src entpackt:

[root@server]# cd /usr/src
[root@server]# tar xfj /files/share/downloads/linux-2.6.10.tar.bz2
[root@server]# mv linux-2.6.10 linux-2.6.10-skas3-v7
[root@server]# cd !$
[root@server]# patch -p1 < /files/share/downloads/host-skas3-2.6.10-v7.patch

make gconfig


make xconfig



make menuconfig

Die Sourcen liegen nun in dem Verzeichnis /usr/src/linux-2.6.10-skas3-v7 und enthalten auch bereits den SKAS Patch. Wer kein UML System nutzen oder aus irgendwelchen Gründen auf den SKAS Patch verzichten möchte, der spart sich das Umbenennen des Verzeichnisses und das Einspielen des Patches. Der nächste Schritt ist das Erstellen der Konfiguration. Mein Ziel war, einen möglichst optimalen Kernel für das EPIA System zu erstellen. Das bedingt, sich durch eine Vielzahl von Kerneloptionen zu schlagen und jedesmal zu prüfen, ob man diese Funktion direkt im Kernel haben, in ein Modul auslagern oder ausschliessen möchte. Wer sich das alles ersparen möchte und ein EPIA System auf der Basis von PD10000 (für die M-Boards sollte der Kernel genauso geeignet sein) verwendet, klickt einfach oben rechts auf die Grafik und speichert die von mir erstellte Konfigurationsdatei unter /usr/src/linux-2.6.10-skas3-v7/.config ab.

Wer die Kernel Konfiguration selbst vornehmen möchte oder Ö?nderungen an meiner plant, hat drei Möglichkeiten (von der direkten Editierung der Konfigurationsdatei sollte man tunlichst absehen, da diverse Abhängigkeiten zwischen den Optionen existieren). Allen drei Varianten ist gemeinsam, dass die Optionen in einer Art Baumstruktur dargestellt sind:

  • make gconfig: Nach dem Aufruf erscheint eine grafische Oberfläche. Für die jeweils angewählte Option erscheint unten eine Erläuterung. Für die Darstellung der Optionen gibt es drei Darstellungsvarianten. Neben X11 werden auch die GTK Bibliotheken benötigt, die aber sowieso zum Pflichtprogramm einer Linux-Installation mit X11 Unterstützung gehören. Diese Variante ist ganz klar mein Favorit.
  • make xconfig: Diese Variante entspricht der ersten, nur dass statt der GTK Bibliotheken die QT Bibliotheken genutzt werden.
  • make menuconfig: Diese Variante stellt eine textbasierte Variante zur Verfügung, die etwas unkomfortabel ist und vermutlich nur dann eine Rolle spielt, wenn keine X11 Bibliotheken auf dem Server installiert sind.

Rein der Vollständigkeit halber sei die ganz simple Methode noch erwähnt, die Kernelkonfiguration durch aufeinanderfolgende Fragen vorzunehmen (mit make config). Ich bezweifele aber, dass sich dies wirklich jemand antun will.

Kommentare zur Host Kernel Konfiguration

Verlaufen?

Wer sich mit seiner Konfiguration verlaufen hat, möchte vielleicht wieder zum Ausgangspunkt zurück. Der harte Weg besteht aus dem Löschen des Verzeichnisses und dem erneuten Auspacken des Kernel-Sourcearchivs. Etwas einfacher geht es mit make mrproper – wie beim Löschen des Verzeichnisses wird aber auch hier die Konfigurationsdatei .config mit gelöscht. Wer die Konfiguration behalten möchte und nur die zwischenzeitlich durch eine Kernel-Erstellung entstandenen Binär- und temporären Dateiten löschen möchte, kann dies mit make clean erreichen.

Ich möchte die Konfiguration jetzt nicht im Detail beschreiben, das würde dann ein Roman werden. Damit man aber weiss, worauf man sich grundsätzlich einläßt, wenn man die oben zum Download angebotete Konfiguration nutzt, möchte ich wenigstens einen groben Überblick gebe.

Ziel war es einen optimierten Kernel für VIA EPIA Systeme mit VIA C3 Nehemiah CPU zu erstellen. Alles, was auf einem EPIA System nicht unterstützt wurde, flog aus der Konfiguration raus. Alles, was höchstwahrscheinlich im Server-Betrieb wichtig ist, befindet sich direkt im Kernel (Hardware-Unterstützung für LAN, Video, Audio, Schnittstellen) – alles was unter Umständen mal benötigt werden könnte, wird als nachladbares Modul bereitgestellt.

Da der Kernel für einen Home-Server ausgelegt wurde, sind im Bereich TCP/IP Netzwerk praktisch alle Optionen entweder direkt im Kernel oder als Modul verfügbar (z.B. die diversen Firewall-Funktionen). Auch der Bereich USB ist (fast) vollständig einbezogen – die USB Hostcontroller direkt im Kernel, die USB Geräteunterstützung in Form von Modulen. Optionen, die als experimentell gekennzeichnet sind, wurden nicht verwendet – um als ‘obsolete’ markiert Optionen wurde ebenfalls ein Bogen gemacht. Weiterhin enthält der Kernel alles, was für das geplante UML Subsystem benötigt wird.

Kernel-Erstellung und Installation

Mit dem Befehl make bzImage wird der Kernel selbst erstellt, mit make modules die Module. Man kann auch einfach make aufrufen, dann wird sowohl der Kernel als auch die Module erstellt. Die Installation des Kernels erfolgt damit wie folgt:

[root@server]# cd /usr/src/linux-2.6.10-skas3-v7
[root@server]# make bzImage
[root@server]# cp -f arch/i386/boot/bzImage /boot/vmlinuz-2.6.10-skas3-v7
[root@server]# cp -f System.map /boot/System.map-2.6.10-skas3-v7
[root@server]# make modules
[root@server]# rm -rf /lib/modules/2.6.10-skas3-v7
[root@server]# make modules_install
[root@server]# mkinitrd -f /boot/initrd-2.6.10-skas3-v7.img 2.6.10-skas3-v7

/etc/grub.conf

# grub.conf @ server
#
# NOTICE:  You have a /boot partition. This means that all kernel
# and initrd paths are relative to /boot.

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz

password --md5 8sdf7uj$sfjH$40dfsddf34jsej344jhwe

title Fedora Core (2.6.10-1.766_FC3)
        root (hd0,0)
        kernel /vmlinuz-2.6.10-1.766_FC3 ro root=/dev/hda3
        initrd /initrd-2.6.10-1.766_FC3.img
title Fedora Core (2.6.10-1.741_FC3)
        root (hd0,0)
        kernel /vmlinuz-2.6.10-1.741_FC3 ro root=/dev/hda3 rhgb quiet
        initrd /initrd-2.6.10-1.741_FC3.img
title EPIA Optimized Kernel (2.6.10-skas3-v7)
        root (hd0,0)
        kernel /vmlinuz-2.6.10-skas3-v7 ro root=/dev/hda3
        initrd /initrd-2.6.10-skas3-v7.img

Der mkinitrd Befehl erzeugt eine Initial Ramdisk, die der Kernel zum Booten benutzt. Die Dateinamen für den Kernel, für die Symboldatei und für die Initial Ramdisk enthalten alle die Kernel-Versionsbezeichnung, die der Kernel nach dem Booten auch mit dem Befehl uname -a anzeigen wird. Jeder Kernel sucht zunächst die Datei mit der Versions-Erweiterung, anschließend ohne. Wenn man sich angewöhnt die Dateien ausschließlich mit Versionserweiterung zu benennen, gibt es nie Konflikte zwischen den für das Booten verfügbaren Kerneln.

Jetzt muss der Kernel noch dem Bootloader bekannt gemacht werden. Im Fall von Fedora Core wird der GRUB genutzt, wie vermutlich inzwischen bei den meisten Distributionen. Da mein Home-Server ohne Monitor und Tastatur vor sich hinwerkelt, wollte ich den Kernel zunächst in einem Umfeld testen, dass bei Problemen beim übernächsten Bootvorgang automatisch wieder der funktionierende Fedora Core Kernel verwendet wird. Daher habe ich den Kernel zunächst am Ende der GRUB Konfigurationsdatei eingetragen (siehe rechts).

Die von Fedora Kernel üblicherweise genutzten Optionen rhgb (RedHat Graphical Boot) und quiet (Meldungen beim Systemstart unterdrücken) sollten tunlichst ausgeschaltet werden, damit man im Fehlerfall durch Anklemmen eines Monitors gleich sieht, wo der Kernel in die Wüste läuft. Wer den Server mit Monitor und Tastatur betreibt, kann beim nächsten Boot nun einfach den EPIA Kernel anwählen – ansonsten kann man den GRUB mit der folgenden Anweisung veranlassen, einmal den EPIA Kernel zu booten (Nummer 2, da die Zählung mit 0 beginnt) und beim darauf folgenden Bootvorgang wieder den unter default eingestellten Kernel zu verwenden:

[root@server]# grub

    GNU GRUB  version 0.95  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]

grub> savedefault --default=2 --once

grub> quit

[root@server]# shutdown -r now

Sobald der Kernel fehlerfrei bootet (dazu den Inhalt der Dateien /var/log/boot.log und /var/log/messages überprüfen), kann er zum Default-Bootkernel gemacht werden. Am besten verschiebt man dazu die vier Zeilen mit der Definition des EPIA Kernels nach ganz oben – alternativ kann man auch die Angabe bei dem default Wert verändern. Wer sich nicht sicher ist, ob er wirklich den EPIA Kernel gebootet hat, kann dies mit dem uname -a Befehl prüfen:

[user@server]$ uname -a Linux server 2.6.10-skas3-v7 #3 Sat Feb 19 11:32:26 CET 2005 i686 i686 i386 GNU/Linux

Erstellung des UML Kernels (User Mode Linux)

Der zweite Kernel wird für die Sandbox benötigt. Im Gegensatz zu dem Host-Kernel, der direkt mit der Hardware spricht, läuft ein UML Kernel als Anwendungsprozess und nutzt den Host-Kernel für den Kommunikation mit der Hardware. Innerhalb eines UML Kernels sehen die Anwendunge nicht, dass sie auf einem virtuellen System laufen. Da ein UML System auch keine Root-Berechtigung auf dem Host-System braucht, kann es auch mit ganz normalen User-Berechtigungen laufen. Gerade beim Bereitstellen von Services, die permanente Verbindungen zum Internet aufbauen bzw. aus dem Internet erreichbar sind, erreicht man so ein deutlich höheres Sicherheitsniveau. Wenn es jemand schafft, eine Sicherheitslücke in einem Service zu nutzen, dann hat der Angreifer damit noch keinen Zugriff auf das Hostsystem, wo die evtl. kritischen Daten liegen.

Früher entstand ein UML Kernel aus den Standad Kernelsourcen und dem Einspielen eines Patches. Seit der Kernel Version 2.6.9 ist UML fester Bestandteil der Kernelsourcen, wobei die Version 2.6.9 aufgrund von Stabilitätsproblemen nicht zu empfehlen ist. Ich habe für den UML Kernel die gleichen Sourcen genutzt, wie für den Host-Kernel auch (dies ist aber nicht notwendig, die Kernel Version des UML Kernels muss nicht der Kernel-Version des Host-Kernels entsprechen).

Der UML Kernel sollte unter keinen Umständen in dem üblichen Verzeichnis /usr/src/linux… erstellt werden! Das Erstellen des UML Kernels habe ich unter meinem Arbeits-Account (als ‘user’ gekennzeichnet) auf dem Server vorgenommen (nicht root!), für die Sandbox habe ich einen eigenen User-Account eingerichtet, der auch eine eigene Gruppe nutzt:

UML Kernel 2.6.10 Config

Anklicken für Download

[root@server]# groupadd -g 800 vbox
[root@server]# adduser -g 800 -s /bin/sh -c "Internet Services" inet
[root@server]# passwd inet
Changing password for user inet.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Das Erstellen des Kernels verläuft ähnlich wie bei dem Host-Kernel oben. Wichtig ist, grundsätzlich die Option ARCH=um anzugeben. Wer sich das Durchklickern durch die Kernel-Optionen sparen möchte, kann rechts auf die Grafik klicken und mit meiner UML Kernelkonfiguration beginnen. Sie ist für die Bereitstellung von Netzwerk-Services gedacht. Alles, was vermutlich sowieso genutzt wird, ist direkt in den Kernel eingebunden, optionale Features als Modul:

[user@server]$ mkdir -p ~/uml; cd !$
[user@server]$ tar xfj /files/share/downloads/linux-2.6.10.tar.bz2
[user@server]$ cd linux-2.6.10
[user@server]$ make defconfig ARCH=um
[user@server]$ make gconfig ARCH=um
[user@server]$ make linux ARCH=um
[user@server]$ make modules ARCH=um
[user@server]$ strip linux

Die strip linux Anweisung entfernt die Debuginformationen vom Kernel.

Was nun noch für die Sandbox fehlt ist das eigentliche Linux-System in Form eines sogenannten Root-Filesystems. Die Erstellung des Root-Filesystems ist etwas komplizierter und wird erst im nächsten Kapitel behandelt. Damit man schon einmal etwas zum Spielen hat, beschreibe ich nun noch, wie man den UML Kernel mit einem Mini-System booten kann. Somit kann man auch schon prüfen, ob der UML Kernel auch prinzipiell läuft.

Der UML Kernel selbst soll mit dem User-Account ‘inet’ laufen. Der User ‘inet’ selbst hat nur minimale Berechtigungen, er soll z.B nicht einmal Zugriff auf die Inhalte von anderen Home-Verzeichnissen haben. Da der User ‘inet’ eine eigene Gruppe hat, muss dazu nur die ‘Other-Berechtigung’ von den Home-Verzeichnissen entfernt werden. Das Home-Verzeichnis des ‘inet’ Users selbst ist schreibbar für den Arbeits-Account, für den ‘inet’ Account selbst nur lesbar!

[root@server]# cd /home
[root@server]# chmod o-rwx *
[root@server]# chown -R user inet
[root@server]# chgrp -R vbox inet
[root@server]# chmod 750 inet

Nun sollten wir den UML Kernel in das Ziel-Verzeichnis kopieren können. Weiterhin stelle ich zum Spielen noch ein kleines, vorbereitetes Miniboot-Image bereit, mit dem man eine Shell starten kann (ein paar Utilities sind auch noch dabei):

[user@server]$ cp ~/uml/linux /home/inet
[user@server]$ cd /home/inet
[user@server]$ wget http://www.q-vadis.net/download/QVN-MiniBoot.img.bz2
[user@server]$ bzip2 -d QVN-MiniBoot.img.bz2
[user@server]$ su - inet
Passwort:
[inet@server]$ ./linux mem=64M ubd0=QVN-MiniBoot.img con=pty con0=fd:0,fd:1 con2=xterm

Wenn alles klappt, bekommt man eine einfache Shell (bin/sh) in der UML. Mit dem Befehl wird der UML 64 MB Speicher bereitgestellt und es öffnet sich zusätzlich noch ein ‘xterm’ mit einer Login-Aufforderung des UML Systems. Man kann vom Hostsystem aus sehen, wie der UML Kernel als User-Prozess läuft und ihn z.B. auch einfach killen. Viel Spass beim Spielen.

Der nächste Schritt ist nun die Installation eines Linux-Systems in die UML. Da normale Installationsprogramme noch kein UML System berücksichtigen, ist hier etwas Handarbeit angesagt. Das nächste Kapitel wird sich damit befassen.

7 Kommentare zum Artikel “Home Server, Teil 6 – Konfiguration: Optimierter Host- und UML Kernel”

  1. Als erstes Gratulationen zu deiner Site ! Echt Cool und informativ.

    Auf meinem Linux-Server plane ich unter Debian und dem 2.6.13 Kernel verschiedene Server zusammen zu führen. Es handelt sich hierbei um einen Entwicklungs, Test und Produktions-Server für eine Mail-Anwendung sowie einen DNS und Web-Server. Dabei dachte ich mir, dass allenfalls das User-Mode Linux eine gute Alternative ist, meine aktuelle Server-Farm auszumisten. Dabei brauche ich kein KDE/Gnome Oberflächen und begnüge mich mit einer einfachen Terminal. Gerade das habe ich unter VMware WorkStation bemängelt. Kannst du für diesen Einsatz das User-Mode Linux empfehlen ?

    Besten Dank für eine Kurze Antwort.
    Gruss Ramon

    P.S: http://www.uniqmail.org (ist noch nicht aufgeschalten, aber es kommt …)

  2. Ich denke schon. Die Alternative wäre das XEN Virtual Machine System. Ich bin mir nicht sicher, ob es in dem Fedora Core 4 schon drin ist, im Fedora Core 5 soll es enthalten sein (kommt Ende Februar 2006). In wie weit es sich einfach implementieren läßt und ob es Pakete für Debian gibt, weiss ich nicht. Tiefer beschäftigt habe ich mich damit noch nicht.

    Meine Erfahrungen mit dem UML System sind jedenfalls sehr gut. Seit dem Aufsetzen des Servers am Anfang des Jahres habe ich nur einen Absturz gehabt und der wurde durch eine zu heiss gewordenen Festplatte verursacht. Die Sandbox läuft mit 128 MB Speicher und 256 MB Swap. In ihr läuft ein irssi, der mit als Client und als Proxy dient, sowie eine weitere Anwendung. Wenn man mehrere UML Systeme aufsetzen will, kann man vor der Installation der Anwendungen einfach die Imagefiles kopieren. Die Handhabung ist einfach, man kann die UML Systeme über die Kommandozeile starten und wieder sauber runterfahren.

    Ich habe inzwischen auf dem Hostsystem einen VNC Server gestartet. Der administrative Zugriff erfolgt damit vom Windows PC aus über einen VNC Client, der mir einen auf dem Host laufenden GNOME Desktop bereitstellt. Die UML Anwendungen laufen dort in Shellfenstern. Für email/DNS/Web Anwendungen dürfte diese Vorgehensweise auch bei dir gut passen.

  3. Danke für den Hinweis. Unter der URL http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.html findet sich ein interessanter Performance Test. Da scheint XEN gegenüber User-Mode Linux sowie VMWare sehr gut abzuschneiden. Nebst Performance ist aber auch Stabilität immer ein Thema.

    Gute Idee, das mit dem VNC-Server.

  4. Ist das Absicht, dass .config für den UML-Kernel nicht mehr zu haben ist?
    Ansonsten tolle Anleitung.

  5. hey

    erstmal, super tutorial, hat mir gut gefallen.

    allerdings hätte ich noch ein paar fragen zum kernelkompilieren die mir beim ausprobieren probleme gemacht haben.
    und zwar hast du ja schon eine .config für den via epia geschrieben welche ich gerne übernehmen würde.
    mein problem ist jedoch dass wenn ich für einen neueren kernel z.b. 2.6.20 deine config übernehmen möchte, werde ich nach ein haufen einstellungen gefragt, von denen ich keine ahnung(da noch nie kernel kompiliert;-) ).

    hast du eine idee wie ich am besten deine config auf die neue kernelversion anpasse? hab nämlich keine lust die 1000 zeilen mit texteditor zu überprüfen. vielleicht gibts da ja ein tool?

    • Vermutlich wird er dich nach den Optionen fragen, die seit dem von mir verwendeten Kernel neu hinzugekommen sind. Für den ersten Schuss würde ich einfach die Defaults übernehmen.

Schreibe einen Kommentar


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