Nachdem ich im letzten Blogeintrag die Vorteile der Virtualisierung für mich und die Entscheidungsgründe für vServer beschrieben habe, geht es in diesem Blogeintrag um die Installation, Einrichtung und Inbetriebnahme von vServer.

Installation
Es gibt zwei Möglichkeiten, vServer zu installieren:

1. Einspielen der Debian vServer-Pakete mit apt-get oder aptitude
2. Kompilieren eines eigenen Kernels mit vServer-Unterstützung

Standard Debian-vServer-Kernel
Die 1. Variante ist in wenigen Schritten erledigt:

# Installation des aktuellen Kernels
# mit vServer-Unterstützung und der
# Userspace-Verwaltungsprogramme
apt-get install linux-image-vserver-686 util-vserver \
vserver-debiantools

Wenn der vServer-Kernel standardmäßig beim Booten gestartet werden soll, dann muss in der GRUB-Konfigurationsdatei /etc/grub/menu.lst noch der Standardkernel geändert werden.

Kompilieren eines Vanilla-Kernels mit vServer-Unterstützung
Diese Vorgehensweise empfehle ich nur Linux-Anwendern, die sich die Übersetzung eines eigenen Kernels zutrauen und sich auf der Shell einigermaßen gut auskennen.

Zuerst muss der aktuellste Kernel von der Seite http://www.de.kernel.org/pub/linux/kernel/v2.6/ heruntergeladen werden.
Zum jetzigen Zeitpunkt ist dort die Version 2.6.22.1 aktuell.

Passend zum aktuellen Kernel muss von http://linux-vserver.org/Welcome_to_Linux-VServer.org ein passender vServer-Patch heruntergeladen werden.

Von der Bezeichnung "Latest Prepatch" sollte man sich übrigens nicht verunsichern lassen. Die zur Verfügung gestellten Patche sind stabil und machen im Normalfall keine Probleme. Der momentan aktuelle Patch für den Kernel 2.6.22.1 steht in der Version vs2.2.0.1-rc1 zur Verfügung.

Zur Konfigurierung des Kernels schreibe ich später einen eigenen Blogeintrag.

Die Datei mit den Kernel-Sourcen muss nun in das Verzeichnis /usr/src kopiert und dort wie folgt entpackt werden

# Bzip2-Archiv entpacken
bunzip2 linux-2.6.22.1.tar.bz2

# Tar-Archiv mit Unterverzeichnissen und Dateien entpacken
tar xvf linux-2.6.22.1.tar
apt-get install bzip2

Hinweis:
bzip2 ist bei einer minimalen Debian-Netzinstallation nicht installiert. Es muss mit apt-get install bzip2 zuerst in stalliert werden.

apt-get install bzip2

Ich persönlich benenne jetzt den Kernel-Source-Ordner noch nach linux um.

Nun muss der vServer-Patch noch eingespielt werden. Dazu muss die Datei patch-2.6.22.1-vs2.2.0.1-rc1.diff in das Verzeichnis /usr/src kopiert werden. Nun wechselt man in das Kernel-Source-Verzeichnis und ruft folgendes Kommando auf:

# Patcht die vServer-Erweiterung in den Kernel
cat ../patch-2.6.17.13-vs2.0.2.1.diff | patch -p1

Hinweis:
Das Kommando zcat oder ein Packprogramm muss in diesem Fall nicht verwendet werden, da die Patchdatei unkomprimiert vorliegt.

Jetzt kann der Kernel entweder mittels einer alten Konfigurationsdatei kompiliert werden – dazu muss die alte Konfigurationsdatei .config in das Kernel-Source-Verzeichnis kopiert und make oldconfig aufgerufen werden. Für eine neue Kernelkonfiguration sind die vServer-Module bereits sinnvoll vorkonfiguriert. Ich habe an den Einstellungen nichts mehr verändert. Näheres zu den Einstellungsmöglichkeiten findet sich unter: http://linux-vserver.org/Installation_on_Linux_2.6

Nach dem Einrichten des neuen Kernels (initramdisk, Grub-Anpassung) sollte der neue Kernel mit der vServer-Unterstützung neugestartet werden.

Erzeugung einer vServer-Instanz
Eine neue vServer-Instanz ist neu eingerichtet. Mit folgendem Kommando wird eine neue Instanz mit dem Namen vserver-mld erzeugt. Die einzelnen Optionen werden im folgenden beschrieben.

newvserver –vsroot /var/lib/vservers/ –hostname vserver-mld –domain local –ip 192.168.178.188/24 –dist etch –mirror http://ftp.de.debian.org/debian –interface eth0

Mit dem Parameter –vsroot wird der Installationspfad für die Instanz festgelegt. Dort sollte je nach verwendeter Distribution genügend Platz verfügbar sein. Es bietet sich an, für das Verzeichnis /var eine eigene Partition einzurichten, da in einer vServer-Instanz ja auch meist Nutzdaten abgelegt werden.

–hostname gibt den Namen der Instanz an, unter der sie auch vom Wirtsrechner aus angesprochen werden kann.

–domain gibt den Domainnamen an. local ist für ein lokales Netz keine schlechte Idee.

Mit –ip wird die IP-Adresse und das Netz in der CIDR-Notation angegeben. Wie am Beispiel zu erkennen, bin ich ein FritzBox-Nutzer…

Mit –dist wird die Debian-Version festgelegt, die mittels debootstrap heruntergeladen und installiert wird. Für ein stabiles System bietet sich momentan Etch an.

–mirror gestattet es, einen beliebigen offiziellen Debian-Mirror anzugeben, der für den Download der Debian-Distribution verwendet wird. Es ist nicht verkehrt, hier den dt. Debian-Mirror-Server zu nehmen.

–interface legt schließlich fest, welche physikalisches Netzwerkinterface für die virtuelle IP-Adresse verwendet wird. In meinem Fall ist eth0 die Verbindung zum Switch der FritzBox. Somit hat die vServer-Instanz Zugriff auf das Internet, was für Updates sinnvoll ist. Für die FritzBox verhält sich die virtuelle IP-Adresse wie ein normaler PC. D.h. sollen Dienste auf dem vServer von außen zugreifbar sein, müssen für die virtuelle IP-Adresse die benötigten Ports auf dem Router an den vServer weitergeleitet werden.

Sicherheitskontext setzen:
Für jede vServer-Instanz muss ein sog. Sicherheitskontext gesetzt werden. Dies ist eine beliebige Ziffer, die bei jeder vServer-Instanz unterschiedlich sein muss. Im folgenden Beispielt wird der Sicherheitskontext 100 für den vServer vserver-mld gesetzt.

# Sicherheitskontext setzen
echo 100 > /etc/vservers/vserver-mld/context

Automatisches Starten beim Starten des Wirt-PCs:
Mit folgendem Kommando wird der vServer vserver-mld bei jedem Start des Wirt-PCs automatisch gestartet und beim Herunterfahren gestoppt:

# vServer beim Booten starten
echo "default" > /etc/vservers/vserver-mld/apps/init/mark

Manuelles Starten und "Betreten" einer vServer-Instanz:
Mit folgendem Kommando wird der vServer manuell gestartet und gleichzeitig die Konsole auf ihn umgeschaltet.

vserver verver-mld start; vserver vserver-mld enter

Mit exit kann die vServer-Konsole wieder verlassen werden.

Manuelles Stoppen einer vServer-Instanz:

vserver vserver-mld stop

Anpassen der Debian-Installation:
Nach dem Starten der vServer-Instanz müssen noch ein paar Dinge der jungfräulichen Debian-Installation angepasst werden.

Es sollten folgende Pakete nachinstalliert werden, sollten sie noch nicht installiert sein:

apt-get install ssh vim screen language-pack-de

Evtl. kann es notwendig sein, den Zeichensatz neu zu konfigurieren, wenn nach dem Login Probleme mit den Locales angezeigt werden.

# Zeichensatz rekonfigurieren
dpkg-reconfigure locales

Wird SSH eingesetzt, und soll sich root über das Netzwerk anmelden dürfen, so muss unbedingt für den Benutzer root ein neues Passwort vergeben werden, was mit folgendem Aufruf möglich ist:

# Root-Password vergeben
passwd root

Hinweis zum Schluss:
Auch bei mehreren vServer-Instanzen sollte jede einzelne Instanz regelmäßg mit apt-get update und apt-get-upgrade auf Updates überprüft werden!

Virtualisierung
Virtualisierung – in aller Munde, in jeder (ernsthaften) IT-Zeitschrift besprochen und mittlerweile nicht mehr nur in den großen Mainframe-Rechenzentren sondern auch auf vielen Brot und Butter Servern zu finden. Warum aber Virtualisierung auf meinem Linux-Server für den Hausgebrauch einsetzen?

Intention
Drei Überlegungen haben dazu geführt, dass ich Virtualisierung auf meinem Debian-Server einsetze:

• Stromkosten
• Sicherheit
• CPU-Leistung

Stromkosten
Aus Sicherheitsgründen bräuchte man eigentlich für den Fileserver und den P2P-Client zwei physikalisch eigenständige Rechner. Selbst wenn ein sparsamer Rechner eingesetzt wird, sind das pro Gerät 20 Watt. Wenn sich die beiden Rechner durch einen einzigen ließen, hielte sich der Stromverbrauch bei einem Dauerbetrieb in Grenzen.

Sicherheit
Natürlich kann man alle Netzwerkdienste auf einem PC laufen lassen. Bei einer Kompromittierung über das Internet hätte der Eindringling aber automatisch z.B. auch Zugriff auf den Web-Server oder die mit dem P2P-Client heruntergeladenen Dateien. Mit einer Virtualisierungslösung lassen sich mehrere Dienst auf einem physikalischen Rechner voneinander abschotten. Dass man natürlich nicht die gleiche Sicherheit wie bei physikalisch getrennten Rechner erreicht, versteht sich von selbst. Für den Privatgebrauch stellt diese Einschränkung aber einen sinnvollen Kompromiss dar.

CPU-Leistung
Heutige CPUs langweilen sich bei normalen Aufgaben, wenn es sich dabei nicht gerade um Bild- oder Videobearbeitung oder 3D-Spielen handelt. In meinem Fall läuft im Hintergrund ein P2P-Client und ein WebDAV-Server. Ab und zu läuft über SMB ein Backup, das im Höchstfall die CPU zu 50-60 % auslastet, weil die Daten über Gigabit-Ethernet über das Kabel rauschen. Was liegt damit also näher die Multitasking-Fähigkeit und die Performance aktueller CPUs für mehrere parallel laufende Dienste auszunutzen?

Die Qual der Wahl
Unter Linux gibt es sehr viele Virtualisierungslösungen: VMWare, VirtualBox, XEN, QEmu, vServer, KVM etc.

Ich habe mich für vServer entschieden. vServer ist keine vollständige Virtualisierung, die einen vollständigen PC nachbildet. vServer erzeugt vielmehr voneinander abgeschottete Linux-Distributionen. Als Besonderheit kann für jede laufende Instanz die zur Verfügung stehende Speichermenge und die zur Verfügung stehende CPU-Zeit angegeben werden. Somit geht vServer deutlich über den chroot Mechanismus hinaus.

Virtual Private Server (VPS) sind unter vServer sehr schnell eingerichtet. Man kann eine Instanz einem beliebigen physikalischen Netzwerkinterface zuweisen und eine eigene beliebige IP-Adresse vergeben, die im gesamten Netzwerk ansprechbar ist, und die man so auch z.B. beim Port-Forwarding verwenden kann. Unter Debian kann mit dem debootstrap Paket automatisch eine Debian Etch Instanz erzeugt werden. Das Grundsystem ist vorkonfiguriert und hat bereits Zugriff auf das interne Netzwerk und wenn Gewünscht (Gateway gesetzt) auf das Internet.

Ausblick
Im nächsten Blog-Eintrag werde ich die Installation, Konfiguration und Erzeugung von vServer-Instanzen zeigen. Die Einarbeitung in diese Software fällt nicht sonderlich schwer und belohnt den geneigten Linux-Anwender mit interessanten neuen Einsatzmöglichkeiten für seinen Linux-Server.

Eine Debian-Installation ist mit der aktuellen Version 4.0 Etch auch von Linux-Einsteigern leicht zu meistern.

Installationsmedium:
Für einen reinen Serverbetrieb ohne grafische Oberfläche empfehle ich als Installationsmedium die NetInstall die man sich von einem offiziellen Debian-Mirror aus der Nähe herunterladen kann. Die ISO-Datei liegt im relativen Verzeichnispfad 4.0_r0/i386/iso-cd und hat den Dateinamen debian-40r0-i386-netinst.iso.

Diese CD-ISO-Datei kann nun mit jedem beliebigen Brennprogramm, ich verwende Nero Burnin ROM, auf CD gebrannt werden. Für die Installation muss das BIOS das Booten von CD unterstützen.

Installation
Die eigentliche Installation benötigt nur wenige Benutzereingriffe. Es muss die Systemsprache, die Netzwerkeinstellungen (DHCP, fixed IP etc.), ein Root-Passwort und eine grobe Paketauswahl getroffen werden. Die Festplattenpartionierung kann automatisch oder unterstützt von Hand erfolgen. Bei der Paketauswahl sollte für ein minimales System alle Einträge entfernt werden außer dem gewünschten Einsatzgebiet (bei mir z.B. Datei- /Fileserver). Ist Linux das einzige Betriebssystem auf der Festplatte, dann sollte der Bootloader in den MBR geschrieben werden.

Nach einem notwendigen Neustart ist Debian voll einsatzfähig.

Soweit die Theorie…

Bei meinem VIA-Mainboard wurde nur das erste Netzwerkinterface eth0 erkannt und eingerichtet. Es muss hierzu die Datei /etc/network/interfaces um eth1 ergänzt werden. Meine Konfigurationsdatei sieht wie folgt aus:

# This file describes the network interfaces
# available on your system and how to
# activate them. For more information,
# see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.178.88
netmask 255.255.255.0
network 192.168.178.0
broadcast 192.168.178.255
gateway 192.168.178.1
# dns-* options are implemented by the
# resolvconf package, if installed
dns-nameservers 192.168.178.1
dns-search local

allow-hotplug eth1
iface eth1 inet static
address 192.168.1.88
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

Für ein schlankes und vor allem sicheres Linux-System sollten alle unnötigen Dienste deaktiviert oder besser entfernt werden. Folgende Anweisungen entfernen die meiner Meinung nach für einen Backup- und WebDAV-Server überflüssigen Programme und deaktiviert unsichere / unnötige Dienste.

# Löscht unbenötigte Programme / Dienste
apt-get remove lpr nfs-common portmap pidentd \
pcmcia-cs pppoe pppoeconf ppp pppconfig netatalk

# Deaktiviert unsichere / unnötige Netzwerkdienste
update-inetd –remove daytime
update-inetd –remove telnet
update-inetd –remove time
update-inetd –remove finger
update-inetd –remove talk
update-inetd –remove ntalk
update-inetd –remove ftp
update-inetd –remove discard

Folgende Programme haben sich für das Bauen eines eigenen Kernels und alltägliche Aufgaben als ganz nützlich erwiesen. Sie können mit dem Kommando apt-get install Paketname nachinstalliert werden:

# Pakete für vServer
apt-get install linux-image-vserver-686 util-vserver \
vserver-debiantools

# Pakete für das kompilieren eines eigenen Kernels
apt-get install kernel-package libncurses5-dev \
fakeroot wget bzip2 dash initramfs-tools make \
automake gcc patchutils

# Sonstige wichtige / interessante Programme
apt-get install ssh pciutils bzip2 ethtool \
cpufrequtils lm-sensors hddtemp

Die einzelnen Pakete, vor allem SSH, vServer, cpufreq, lm-sensors und hddtemp werde ich einen der nächsten Einträge näher beschreiben.

Warum habe ich gerade Debian als Linux-Distribution für meinen Linux-Server verwendet?
Warum nicht Fedora, OpenSuSE, Slackware, oder Ubuntu?

Um das zu erklären, muss ich etwas in die Vergangenheit gehen.

Slackware
Alles begann im Jahr 1996. Damals kam ich über ein Abonnement der Zeitschrift PC Online das erste Mal in Berührung mit Linux. Auf einer damals aufkommenden Heft-CDs war eine Slackware Linux CD enthalten, die sich direkt unter DOS (mittels UMSDOS in Betrieb nehmen lies. Mit dieser Linux Distribution kämpfte ich mich das erste Mal durch die Konsole und durch Konfigurationsdateien. Das Experiment wurde aber schnell wieder beendet, da ich den X-Server mit meiner VLB-Grafikkarte nicht zum Laufen bekam.

SuSE
Ca. ein Jahr später sah ich die erste SuSE-Linux-Distribution beim Freund meiner Schwester. Er benötigte Linux für sein Physik-Studium. Welche Version das genau war, weiß ich nicht mehr. Ich habe noch etwas mit 4.x im Kopf. Nach diesen ersten Berührungen wuchs bei mir das Interesse an Linux. Ich orderte eine SuSE-Linux 5.0 Distribution inkl. Handbuch. Dieses Buch könnte ich auch heutzutage allen Neueinsteigern empfehlen. Mit SuSE 5.0 habe ich das erste Mal 2.0.x Kernel kompiliert und ausgiebig Netzwerkdienste und sonstige Dienste ausprobiert. Später bin ich aus reiner Neugier auf RedHat umgestiegen und war ein paar Jahre sehr zufrieden.

Fedora Core 1
Die nächste große Veränderung hat mit meinem späteren Beruf zu tun. 2001 habe ich mit dem Informatikstudium begonnen. In einigen Vorlesungen (C, C++, XML, Python) war es möglich / notwendig Linux als Betriebssystem einzusetzen. Zu diesem Zeitpunkt hatte ich als Landei endlich einen 768 kbit DSL-Anschluss erhalten. Über ihn habe ich die erste Fedora Core Distribution heruntergeladen und eingesetzt. Ich hatte eigenen Linux-Server, der für P2P und als Fernzugang verwendet wurde.

IPCOP
In diese Zeit fallen auch erste Versuche mit IPCOP, einer speziell für den Firewall- und Routereinsatz ausgerichteten Linux-Distribution. Anfangs basierte IPCOP auf RedHat, später wurde das System auf Linux From Scratch umgestellt. IPCOP bietet eine komfortable WEB-Oberfläche für die Konfiguration des Netzwerks und des Internetzugangs. Man kann, wie von Hardwareroutern gewohnt, leicht Ports weiterleiten oder die Firewallregeln anpassen. Es gibt zahlreiche Erweiterungen wie z.B. Web- und Spamfilter und vieles mehr. Mit einem Kommilitionen habe ich den IPCOP nach einer Anleitung in der c’t aufgebohrt und zu einem WLAN-AccessPoint gemacht. Grundlage war dabei eine PCI Wlan-Karte mit Prism-Chipsatz und entsprechender Firmware. Auf dem Rechner lief damals zum ersten Mal mldonkey. Der Zugang auf die mldonkey-Web-Oberfläche war nicht direkt sondern über einen gesicherten SSH-Tunnel realisiert.

Debian – 1. Versuch
Im Jahr 2002 hatte ich das erste Mal Kontakt zu Debian. Ein Mitstudent schwärmte von dieser Distribution, die damals eindeutig noch einen hohen Freak-Faktor besaß. Ich kämpfte mich sogar durch eine Installation, gab aber dann entnervt auf, weil es wieder einmal Probleme mit dem X-Server gab.

Fedora Core 2
Die Jahre 2005 bis Anfang 2007 waren eher Linux-frei. Als Backup-Server lief zwar mittlerweile ein Linux-Server mit Fedora Core 2, aber ich arbeitete nicht wirklich häufig mit Linux. Irgendwann einmal wurde Fedora Core 2 nicht mehr direkt, sondern nur noch indirekt über Fedora Legacy mit Sicherheitsupdates unterstützt.

Debian forever
Erst Anfang 2007 habe ich mir endlich konkrete Gedanken zu meinem langjährigen Traum gemacht, einen eigenen sparsamen Linux-Server zusammenzustellen und einzurichten. Durch die verstärkte Besprechungen in der c’t und Expertenmeinungne bestärkt bin ich endlich meiner Wunsch-Distribution angelangt: Debian GNU/Linux 4.0

Debian rules!
Hier an dieser Stelle erlaube ich mir jetzt eine kleine, naive Einschätzung zu Debian. Das entscheidende Auswahlkriterium für die Wahl von Debian war für mich seine Unabhängigkeit. Es steht keine Firma hinter Debian, die Umsatzzahlen und Gewinn aus ist oder sich Sorgen um ihr Image machen muss. Es droht keine Übernahme wie bei SuSE durch Novell, keine Ausgliederungen und Umstrukturierungen wie bei RedHat / Fedora. Eine veraltete Debian-Installation kann auch mit wenigen Befehlen auf den aktuellen Stand gebracht werden.

Persönliches Fazit
Debian steht für mich für Stabilität, Sicherheit und langjährige Unterstützung und bedachte Weiterentwicklung. D.h. nicht, dass andere Distributionen nicht auch ihre Vorteile hätten. Wer auf einfache Bedienung Wert legt, wird wohl eher zu Unbuntu oder OpenSuSE greifen. Ich bleibe aber bei Debian.

Klein aber fein. Das trifft ganz gut auf das mini-ITX Gehäuse Morex CUBID CP3677SW zu. Es bietet Platz für eine mini-ITX-Hauptplatine, eine 2,5" Notebookfestplatte und ein Slimline-CD/DVD-Laufwerk. Im Lieferumfang ist ein externes, passives Netzteil enthalten.

An der Gehäuseseite ist ein 60mm Lüfter angebracht, der über einen 3-poligen Molex-Stecker mit der Hauptplatine verbunden wird. Zuerst habe ich diesen Lüfter als überflüssig angesehen. Ich wollte doch ein möglichst leises und damit lüfterloses System aufbauen. Zusätzliche wurde ja nur Notebooktechnik verbaut (2,5" Notebookfestplatte, externes Netzteil). Während der ersten Testläufe habe ich den Lüfter somit abgeklemmt gelassen. Über die Auswirkungen berichtet ich später…

Nun ein paar genauer Informationen zum Gehäuse:

Das Gehäuse lässt sich sowohl waagrecht als auch senkrecht betreiben. Für den senkrechten Betrieb wird ein massiver Plastiksockel mitgeliefert, der dem Gehäuse einen sicheren Halt bietet.

Im Gehäuse geht es eher beengt zu, was bei der Bestückung des Gehäuses mit Laufwerken und Hauptplatine zum Tragen kommt. Vor allem das Verlegen der Kabel gestaltet sich nicht immer ganz einfach. Mein Tipp: soweit möglich SATA verwenden. Die Kabel sind nicht nur einfacher zu verlegen, sie behindern auch weniger die Luftzirkulation.

In der Seitenansicht sieht man den 60mm NoName-Lüfter mit Molex-Anschluss. Er ist nicht besonders leise, bietet aber für seine Größe, falls benötigt, eine gute Kühlleistung. Er kann natürlich durch einen leisereren Vertreter (z.B. Papst) ersetzt werden. Im Screenhot sieht man auch noch die Wandlerplatine, die trotz des 12 V Netzteils den Anschluss eines ATX-Mainboards ermöglicht.

Im folgenden Screenshot sieht man die internen Anschlüsse des Gehäuses. Für die bessere Übersichtlichkeit wurde die "Befestigungsbrücke" für das Slimline-Laufwerk und die Notebookfestplatte entfernt. Hierzu müssen leider vier Schrauben entfernt werden.

Neben den üblichen Mainboardkabeln (Lautsprecher, LEDs, Reset und Power) fällt zunächst der Standard-ATX-Stecker auf. Weiterhin sind die zwei USB-Kabel der Front-USB-Anschlüsse sichtbar. Mal schauen, was ich mit denen noch so alles anstelle…

An Stromanschlüssen stehen nur ein 4-poliger Anschluss für 5,25" und 3,5" Geräte und ein Anschluss für ein Diskettenlaufwerk zur Verfügung. Schade ist der Umstand, dass kein Stromanschluss für SATA-Geräte enthalten ist. Man kann sich aber mit SATA-Stromadaptern behelfen, die einem bei eBay oder Reichelt für 1-2 € hintergeschmissen werden.

Zwei Anschlüsse erscheinen zwar nicht viel, aber mehr Geräte können im Gehäuse eh nicht angeschlossen werden und würden auch das Netzteil überfordern.

Wie bin ich auf die VIA Eden Plattform gekommen? Dass VIAs mini-ITX Hardware wenig Strom benötigt, ist ja mittlerweile ein Gemeinplatz. Nun kam es also nur noch darauf an, welcher VIA-Prozessor und welcher Chipsatz genau zu verbauen war.

So sah meine Einkaufsliste bei Reichelt aus:

Reichelt-Preis

Morex CUBID CP3677SW	Mini-ITX Gehäuse	97,50 €
J7F4K1G2	Mini-ITX Motherboard 1200MHz / passiv	151,90 €
DDR2-IN533 512MB	Infineon/Qimonda 240pin 1,8V PC4200	26,90 €
WD 1200BEVS	Notebookfestplatte SATA 120GB 5400rpm	68,90 €
AK 3197	S-ATA Stromadapter gerade, +5,25	1,85 €

Die VIA-Webseite listet eine Unzahl an verschiedenen Prozessoren (C3- und C7-Variante), was die Auswahl nicht gerade leicht macht. Ich habe mich für den VIA Eden 1200 entschieden, der mit 1200 MHz getaktet ist und maximal 7 Watt an Leistung verbrauchen soll.

Als Gehäuse habe ich mich für das CUBID CP3677 entschieden. Es nimmt eine 2,5" Festplatte und alle gängien mini-ITX-Hauptplatinen auf. Auf der Rückseite kann leider keine PCI-Karte (auch nicht mit einer Riser-Karte) eingebaut werden. Zum jetztigen Zeitpunkt stellt das für mich aber keine Einschränkung dar. Das Gehäuse besitzt ein externes Netzteil, das passiv gekühlt wird und mit 12 V arbeitet. Der Anschluss am ATX-Anschluss ist über eine Wandlerplatine realisiert, die bereits im Gehäuse angebracht ist.

Dem Gehäuse und seinen Vor- und Nachteil werde ich demnächst noch einen eigenen Blog-Eintrag widmen.

Da die Speicherpreise momentan im Keller sind, habe ich für mich ein 512 MB DDR2-Markenspeichermodul von Infineon/Quimonda entschieden.

Bei der Notebookfestplatte war für mich der Anschluss entscheidend. Aufgrund der dünneren und einfach zu verlegenden Kabel wollte ich dass schwankte ich zwischen einer Samsung-Festplatte und der obene aufgelisteten Western Digital Festplatte. Für die Samsung Festplatte sprach vor allem die Lautstärke. Die Western Digital Platte punktete vor allem bei der Geschwindigkeit und der Zugriffszeit. Laut c’t sollte die WD 1200BEVS auch im Betrieb nicht allzu laut sein.

Die Hauptplatine J7F4K1G2 von Jetway ist billiger als ihre original VIA-Pendants und bietet als Zuckerl zwei Gigabit Ethernet Ports. An Schnittstellen bietet sie 4 direkte USB-Anschlüsse, Audio-Buchsen, Seriell, Parallel, Maus, Tastatur und VGA.

So sah bis vor kurzem mein Linux-Server aus, den ich als Backup-Server (Samba), als auch P2P-Client (mldonkey) und als Spielwiese bis jetzt einsetze.

Zur bisherigen Hardware:

Ich habe das uralte (1996) Gateway-ATX-Gehäuse von meinem Bruder als Basis verwendet.

Die Hauptplatine ist von DFI, Modell: K6XV3+-66.

Darauf thront ein nicht sehr sparsamer AMD K6-2 500 MHz, der mit 100 MHZ FSB lief und leider nicht sehr sparsam ist. Er lässt sich definitiv mit vertretbarem Aufwand nur aktiv kühlen.

Als Arbeitsspeicher sind zwei 128 MB SD-RAM 100 Module auf dem Board, die, obwsohl sie NonName-Module sind, bis jetzt ihren Dienst ohne Probleme verrichtet haben.

Als Netzteil wird ein NoName 300 Watt ATX-Netzteil verwendet, das zum Glück nicht übermäßig laut ist.

Es sind zwei Festplatten momentan verbaut: Zwei 40 GB Festplatten (einmal von Hitachi und einmal von Seagate). Beide Festplatten haben das Manko, dass sie im Dauerbetrieb sehr heiß werden. Daher habe ich den Festplattenkäfig profisorisch versetzt angebracht und im vorderen Bereich des Käfigs einen NoName 80mm-Lüfter eingebaut. Das ganze kühlt die Festplatten sowei ab, dass sie auch bei Dauernutzung nicht wärmer als 35° C werden.

Die Festplatten sind nicht am Onboard-ATA-Anschluss angeschlossen, da dieser maximal UDMA-66 unterstützt. Hierzu habe ich bei eBay den ATA-Adapter Promise Ultra 100 gekauft, der auch von älteren Linux-Distributionen unterstützt wird.

Als Grafikkarte ist eine uralte Matrox PCI-Grafikkarte verbaut, die nur für Wartungsarbeiten benötigt wird.

Es stecken zwei Netzwerkkarten im Server: Eine Intel e100 (100 MBit, PCI), die direkt mit meiner FRITZ!Box Fon WLAN 7170 verbunden ist und eine Intel e1000 (1 GBit, PCI), die für das Backup zum PC verwendet wird.

Als Linux-Distribution wird momentan Fedora Core 2 eingesetzt, weil diese recht einfach einzurichten war und die Promise ATA Karte problemlos unterstützt hat. Update habe ich bis letztes Jahr noch über Fedora Legacy erhalten.