Home Server, Teil 3 – Konfiguration: Grundkonfiguration & System Update

Projekt 'Home-Server'

Ein Server ist kein Client

Die Konfiguration eines Servers unterscheidet sich in der Regel grundsätzlich von der eines Clients. So werden z.B. nur die Services konfiguriert und gestartet, die der Server auch bereitstellen soll. In meinem Fall ist geplant, den Server ohne Monitor, Tastatur und Maus in einer Ecke des Arbeitszimmer laufen zu lassen. Ausser einem 220V Anschluß, dem SAT und den beiden LAN Kabeln sind keine weiteren Anschlüsse vorgesehen. Der Zugriff sowie die Administration erfolgt rein über das Home LAN.

Mein Ziel ist es, den Server für die Services zu konfigurieren, die er anbieten soll. Alles, was nicht benötigt wird, muss auch nicht laufen – den freien Speicher kann Linux dann zum Cachen der Dateien nutzen.

Jetzt lebt er schon einmal, der kleine Server. Die Hardware summt, das Linux bootet, alles läuft so, wie es aus der “Dose” kommt. Im Fall von unserem EPIA Board versucht ein Prozess verzweifelt, die Stromsparfunktionen einer Mobile-CPU zu bedienen, ein anderer sucht ein PCMCIA Interface und das Script für die ISDN Initialisierung sucht in meinem Fall auch vergeblich. Ist das sinnvoll? Wohl kaum! Weiterhin wurde das Linux von der DVD installiert. Auf dem FTP Server liegen inzwischen sicher zahlreiche Updates, die man gleich noch einspielen kann. Zeit, die Grundkonfiguration vorzunehmen und sich um das Update zu kümmern.

Die nun folgenden Konfigurationsberichte habe ich – hoffentlich – in einem Stil geschrieben, in dem sie auch demjenigen von Nutzen sind, der seinen eigenen Server etwas abgewandelt einsetzen möchte. Ich werde daher häufig neben dem ‘Wie’ auch auf das ‘Warum’ eingehen. Weiterhin habe ich mir in meinen “20 IT Jahren” angewöhnt, nicht nur die Maus zu schubsen sondern viele Sachen kurz und schmerzlos auf der Shellebene zu erledigen. Nützliche Linux Befehle werde ich auch ansprechen, soweit sie für die Administration eines Home-Servers sinnvoll und nützlich sind. Wer lieber die Maus schubst, wird viele Dinge auch über die grafischen Dialoge der grafischen Desktops erledigen können.

Ein Blick auf das Home LAN

In den späteren Konfigurationen werden IP Adressen und Hostnamen auftauchen, die einem ohne Kenntnis des Netzwerkes nicht viel sagen werden. Weiterhin werden häufiger Begriffe wie ‘Private LAN’ und ‘Guest LAN’ auftauchen, die ohne Erläuterung höchstens verwirren, aber kaum helfen. Kurz und gut, zunächst stelle ich die Netzwerk-Struktur vor, die ich bei mir implementieren werde. Mit Hilfe des Übersichtsbildes und der nachfolgenden Erläuterungen sollten die späteren Konfigurationsschritte verständlich sein.

Oops… zwei Netzwerke? Wer wie ich in der IT arbeitet und sich in einem Altersbereich befindet, in dem noch nicht alle Freunde und Bekannte gestorben sind, dürfte das Problem kennen: das Telefon klingelt, ein Hilferuf und einige Stunden später steht jemand verzweifelt mit seinem PC vor der Tür. Monitor und Tastatur sind meistens nicht dabei, dafür häufig zahlreiche Viren auf der Platte. Keine Firewall, alter Virenscanner und mangels besseren Wissens mit dem Internet Explorer gesurft – selbst schuld. Für solche Fälle möchte ich ein Netzwerk haben, in dem derartige PCs keinen Schaden anrichten können. Genauso soll jeder Gast des Hauses sein Notebook im Gästezimmer einstöpseln können, ohne dass ich es mir vorher anschauen muss. Daher die Forderung: ein ‘Private LAN’ für die eigenen PCs und ein ‘Guest LAN’ für alle anderen. Wer mit einem Netzwerk auskommt, kann die Abschnitte über die Einrichtung des Guest LANs ignorieren.

Der Anschluß zum Internet wird von einem DSL Router bereitgestellt. Er sorgt dafür, dass sämtliche auf der LAN Seite angeschlossenen PCs Zugriff auf das Internet haben. Weiterhin sorgt er dafür, dass aus dem Internet kein Zugriff auf einen PC im LAN möglich ist (für die Services, die ich im Internet bereitstellen möchte, wird dies später natürlich geändert). Während der Server feste IP Adressen besitzt und nicht auf enien DHCP Server angewiesen ist, werden alle Clients per DHCP konfiguriert. Für einige Clients sind weiterhin feste IP Adressen gekoppelt über die Mac-Adresse vorgesehen. Dies ist die Voraussetzung, um gezielt Services auf dem Server abhängig vom Client blocken zu können. So sollen z.B. die Administrations-Webinterfaces grundsätzlich nur von ‘desktop1’ zugänglich sein.

IP Adressen und Hostnamen

Hostname IP Adresse Kommentar
gateway 192.168.100.254 DSL Router
desktop1 192.168.100.1 Mein Desktop PC
desktop2 192.168.100.2 Der PC meiner Frau
notebook 192.168.100.3 Mein Notebook
server 192.168.100.253 Server (Private LAN)
server-g 192.168.101.254 Server (Guest LAN)
guest1 192.168.101.? Gast, variable IP Adresse
guest2 192.168.101.? Gast, variable IP Adresse

Die .254 kennzeichnet hierbei immer das Default-Gateway für das betreffende Netzwerk.

Für die LAN Seite werden zwei IP Netzwerke benötigt, eines für das Guest LAN, eines für das Private LAN. Für derartige Zwecke gibt es spezielle IP Netzwerke, die für die private Nutzung vorgesehen sind. Diese sind in dem RFC 1918 definiert. Zwar funktioniert das private Netzwerk auch mit (fast) jedem anderen IP Netzwerk, wer aber ein Netzwerk ausserhalb des RFC 1918 verwendet, blendet einen Teil des Internets aus. Dies kann dazu führen, dass man irgendwann einen Webserver nicht erreichen kann, es kann auch dazu führen, dass Anfragen ins Internet ab und an sehr lange dauern.

Für die Nutzung zu Hause empfehlen sich die Netzwerke 192.168.x.*, wobei man x beliebig zwischen 0 und 255 wählen kann (Netzmaske: 255.255.255.0). Innerhalb eines Netzwerkes stehen einem dann 254 IP Adressen für Clients zur Verfügung (die .0 wird für die Angabe des gesamten Netzwerkes verwendet, die .255 dient als Broadcast-Adresse). Ich habe für das Private LAN das IP Netzwerk 192.168.100.0 verwendet und für das Guest LAN das IP Netzwerk 192.168.101.0. Die nebenstehende Tabelle enthält die in den nachfolgenden Konfigurationen verwendeten IP Adressen und Hostnamen. Es ist nicht notwendig sie auswendig zu lernen – wer aber in einer der späteren Konfigurationsdateien eine Zuordnung benötigt, findet sie in der Tabelle links.

PS: Um ehrlich zu sein, die tatsächlich verwendeten IP Adressen und Hostnamen sind natürlich andere. Ich bin mir zwar sicher, dass meine kleine Hardware Firewall gegen Spoofing-Angriffe gewappnet ist, aber man muss ja nicht mit dem Feuer spielen. Für die hier verwendeten Beispiele gelten aber durchgehend die oben genannten Angaben.

Routing für Guest LAN

Die Zugriffskontrolle für Clients aus dem Guest LAN übernimmt die im Linux integrierte Firewall auf dem Server. Vom Routing her soll das Guest LAN sauber eingebunden werden. Da ein Client im Private LAN alle Pakete ausserhalb des eigenen Netzwerkes immer zum Router schickt, muss mindestens der wissen, dass er das Guest LAN über den Server erreicht. Auf dem Router muss daher ein statischer Routing Eintrag vorgenommen werden, der alle Pakete für das Netzwerk 192.168.101.0 (Netzmaske 255.255.255.0) zu dem Gateway 192.168.100.253 schickt (Metric 2).

Mit diesem Routing erreicht man den Server, aber noch nicht die Clients im Guest LAN. Dazu ist noch ein Forward- Eintrag auf dem Server nötig, der später per Startupscript vorgenommen wird (s.u.).

Einbinden in das Netzwerk

Der Server sollte nun vom Arbeitsplatz-PC (desktop1) aus auf beiden LAN Interfaces erreichbar sein. Dies läßt sich sehr einfach mit einem ping Befehl testen: ein ping 192.168.100.253 testet, ob der Server prinzipiell im gleichen Netzwerk wie desktop1 antwortet, ein ping 192.168.101.254 testet dann das korrekte Routing ins Guest LAN.

Wer keine IP Adressen verwenden möchte, kann nun in der lokalen HOSTS Datei (unter Windows: C:\Windows\System32\Drivers\Etc\hosts; unter Linux: /etc/hosts) den Server eintragen. Oder er wartet, bis der DNS Server eingerichtet ist.

Balast abwerfen

/etc/inittab

[..]
id:3:initdefault:
[..]

Im nächsten Schritt ging es mir darum den Server ohne Monitor, Tastatur und Maus betreiben zu können sowie alle die Services zu deaktivieren, die ich nicht benötigte. Ohne Monitor brauche ich z.B keine grafische Oberfläche und ganz sicher auch keinen grafischen Login. Linux unterscheidet seine Systemzustände grob in sogenannte Runlevel. Dabei steht der Runlevel 5 (bei Fedora Core) für einen Betrieb mit grafischer Oberfläche, d.h auch grafischen Login, und Runlevel 3 für einen Multiuser-Betrieb mit Text-Login. Der Default-Runlevel, den Linux nach dem Booten verwendet, ist in der Datei /etc/inittab eingetragen. Nach der Installation wird der Runlevel 5 verwendet, für den Text-Modus brauchen wir den Runlevel 3 (siehe Block rechts).

Tip(p): Konfigurations Verzeichnis

Um ständig einen Überblick über die geänderten Konfigurationsdateien und im gleichen Zuge eine einfache Sicherungsmöglichkeit zu haben, habe ich mir angewöhnt im Root-Verzeichnis des Servers ein Verzeichnis anzulegen, in dem ich sogenannte Hardlinks zu den geänderten Konfigurationsdateien erzeuge. Während ein Symbolischer Link ein “Fingerzeig” auf die Zieldatei ist, ist ein Hardlink einfach ein zweiter Name für ein und dieselbe Datei. Man kann daher später auch den Editor über den “Hardlink” aufrufen, es wird damit auch die “richtige” Datei geändert (genaugenommen gibt es kein “richtig” mehr, beide Dateinamen sind für Linux gleichwertig).

[root@server]# mkdir -p /servercfg/etc
[root@server]# cd /servercfg/etc
[root@server]# ln /etc/hosts
[root@server]# ls -l /etc/hosts /servercfg/etc/hosts
-rw-r--r--  2 root root 428 Jan 30 17:41 /etc/hosts
-rw-r--r--  2 root root 428 Jan 30 17:41 /servercfg/etc/hosts
[root@server]#

Ziel war es, die weitere Konfiguration alleine über die Secure Shell (OpenSSH) vorzunehmen. Auf dem Arbeitsplatz-PC sollte dazu ein X11 Server zur Verfügung stehen, damit X11 Anwendungen auf dem Server vom Arbeitsplatz-PC aus genutzt werden können (prinzipiell geht es allerdings auch ohne X11). Ich verwende dazu das frei verfügbare Cygwin/X. Im Cygwin Paket enthalten sind viele nützliche UNIX Tools für Windows Systeme einschließlich eines SSH Clients.

Die Services lassen sich unter Fedora Core sehr einfach mit dem setup Tool aktivieren bzw. deaktivieren. Da die Einstellungen nimmer auf den aktuellen Runlevel bezogen sind, muss zunächst der gewünschte Ziel-Runlevel eingestellt werden. Dies kann entweder nach der oben beschriebenen Ö?nderung der Datei /etc/initab mit Reboot erfolgen, oder durch Verwendung des Befehls init 3.

Mit dem Aufruf setup startet man unter Fedora Core das Text Mode Setup Utility. Neben diversen Grundeinstellungen findet sich hier die Option System services, unter der man wählen kann, welche Services beim Start von Linux automatisch mitgestartet werden. Hier wird nun erst einmal aufgeräumt. Benötigt werden zunächst die folgenden Services, alles andere wird deaktiviert (gilt für Fedora Core 3):

  • acpid: Dieser Daemon wartet auf ACPI (Advanced Configuration and Power Interface) Ereignisse und führt entsprechend einem Regelsatz Aktionen aus. So fährt z.B. der Fedora Core 3 nach der Installation den Server sauber runter, wenn man den Ausschalter drückt.
  • anacron: Erlaubt das periodische Ausführen von Befehlen. Im Gegensatz zum Cron Daemon, setzt Anacron nicht voraus, dass der Server ständig läuft. Nach dem Start prüft Anacron, welche Befehle in der Vergangenheit nicht ausgeführt wurden und holt dies nach.
  • atd: Über den atd können Befehle zeitversetzt gestartet werden. Dies ist sehr nützlich, wenn man dann und wann dem Server über Nacht ein paar einmalig durchzuführende Aufgaben mitgeben möchte.
  • crond: Über den crond können periodisch Befehle ausgeführt werden. Im Gegensatz zum anacron Daemon muss hier der Server zu dem Zeitpunkt an dem der Befehl gestartet werden soll auch laufen.
  • Nutzung von X11 Anwendungen

    Mit laufendem OpenSSH Service auf dem Server und installiertem X11 Server auf dem Arbeitsplatz-PC können nun auch X11 Anwendungen problemlos genutzt werden. Dazu ist auf dem Windows PC zunächst der X11 Server zu starten, im Fall von Cygwin/X passiert dies mit dem Befehl startxwin. Über das dann erscheinende xterm kann dann eine X11 Anwendung vom Server aus gestartet werden, z.B. ein GNOME Terminal:

    desktop1 $ xhost +
    access control disabled, clients can connect from any host
    desktop1 $ ssh root@192.168.100.253
    root@192.168.100.253's password: 
    [root@server ~]# export DISPLAY=192.168.100.1:0.0
    [root@server ~]# gnome-terminal &
    [1] 4514
    [root@server ~]#

  • cups, cups-config-daemon: Das UNIX Drucksystem. Die Administration erfolgt bequem über ein Webinterface. Über CUPS wird in meinem Fall der HP Laserjet angeschlossen.
  • network, portmap, xinetd: Diese Services sind zwingend für den Netzwerkbetrieb erforderlich. Sie initialisieren das Netzwerk, ermöglichen RPC Aufrufe bzw. warten auf Kommunikationsanforderungen um dann weitere Dienste zu starten.
  • nfs, nfslock, rpcgssd, rpcidmapd, rpcsvcgssd: NFS steht für Network File System und stellt Netzwerkverzeichnisse primär für UNIX Clients zur Verfügung. Wer keine UNIX (Linux) Clients im Netzwerk hat, braucht in der Regel auch kein NFS. Windows Clients werden über den Samba Server (s.u.) bedient.
  • ntpd: Dieser Service synchronisiert die Systemzeit mit einem externen Zeitreferenzserver.
  • smartd: Dieser Daemon aktiviert die SMART (Self-Monitoring, Analysis and Reporting Technology) Funktionalität der Festplatten und meldet Fehler über das Syslog-System.
  • smb: Der Samba-Server stellt die Datei- und Druckdienste für Windows Clients bereit.
  • sshd: Dies ist der OpenSSH Server, über den wir den Administrations-Zugang zum Server über das Netzwerk herstellen.
  • syslog: Der Syslog-Services ist für das Protokollieren der Systemmeldungen zuständig.
  • sysstat: Dieser Service protokolliert System Aktivitäten.

Im Zuge der Serverkonfiguration werden später noch weitere Dienste gestartet, die aber zunächst sauber konfiguriert werden müssen. An dieser Stelle empfiehlt sich ein Reboot um zu prüfen, ob der Server ohne Probleme den Bootvorgang durchläuft. Der Lohn der Abspeckung ist auch ein flotter Bootvorgang und sehr geringer Grundspeicherverbrauch. Linux belegt nach dem Booten ca. 40 MB an Hauptspeicher zzgl. 35 MB an File System Cache.

System Update

up2date

Der Fedora Core ist von der Philosophie her als sehr aktuelles System ausgelegt. Wenn eine neue Release erscheint, sind überlicherweise jeweils die aktuellsten Versionen integriert. Diese schnelle Einbindung birgt das Risiko, dass auch mal eine etwas instabilere Version eingebunden wird. Im Fall von Fedora Core 3 konnte ich sowohl auf einem professionellen HP Proliant DL380 Server als auch auf meinem Home-Server Instabilitäten beobachten, wenn starke Netzwerk/Festplatten-Aktivitäten über längere Zeit anstanden. Nach dem Update waren diese Instabilitäten Geschichte.

Das Update wird am einfachsten über das grafische Tool up2date durchgeführt, z.B. über den X11 Server auf dem Arbeitsplatz-PC. Ich habe an dieser Stelle ein Vollupdate durchgeführt, also sämtliche Pakete aktualisiert. Alternativ kann man auch direkt yum für die Systemaktualisierung nutzen.

Je nach Bandbreite der Internetverbindung dauert das erstmalige Update lange bis sehr lange, bei einem DSL-Light Anschluß kann man mehrere Stunden einkalkulieren (beim Vollupdate). Bei mir war dies gleich der erste Nachtjob, den der Server durchführen durfte.

/etc/rc.d/rc.local

#!/bin/bash
#
# First the stuff from the original Fedora Core 3 rc.local
touch /var/lock/subsys/local

# Activate IP forwarding between ethernet interfaces
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "IP forwarding activated."
logger -t rc.local "IP forwarding activated."

# Activate Syncookies
echo 1 >/proc/sys/net/ipv4/tcp_syncookies
echo "Syncookies activated."
logger -t rc.local "Syncookies activated."

# Force backup  disc to automatically enter standby mode
# after 15 minutes of idle time.
hdparm -S 180 /dev/hdc
logger -t rc.local "Setting standby timeout for /dev/hdc."

exit 0

Startup Script

Als letzten Schritt in diesem Kapitel wird noch das Startup Script installiert, soweit es bereits erstellt werden kann. In diesem Script wird nun das IP Routing aktiviert, damit die Clients im Guest LAN fröhlich mitspielen können und sowohl Clients im Private LAN als auch Hosts im Internet erreichen können. Weiterhin werden die Syncookies aktiviert, damit die TCP/IP Session IDs nicht so leicht zu erraten sind. Dies ist für den Home-LAN Bereich zwar unkritisch, schadet aber auch nicht.

Weiterhin wird die zweite Festplatte, die nur zum nächtlichen Datenbackup vorgesehen ist, so eingestellt, dass sie nach 15 Minuten Idlezeit automatisch in den Standby-Modus geht, in dem der Motor abgeschaltet ist und damit auch der Leistungsverbrauch auf ca. 1 W sinkt. Die 15 Minuten sollten sicherstellen, dass keine unnötigen Ein-/Ausschaltvorgänge auftreten, die die Festplatten weniger mögen als ein paar Stunden zusätzliche Laufzeit. Wer die zweite Festplatte als Slave am primären IDE Controller angeschlossen hat, muss statt /dev/hdc natürlich /dev/hdb angeben. Damit die Festplatte auch ausgeschaltet bleibt, muss sie aus der Konfigurationsdatei /etc/smartd.conf entfernt werden. Ansonsten wird sie durch die Abfragen von dem < strong>smartd Daemon regelmäßig wieder aktiviert!

Wer will kann auch die erste Platte veranlassen, automatisch in den Standby-Modus zu schalten. Allerdings dürfte dies in der Regel nicht erfolgreich sein, da die primäre Festplatte unter Linux eigentlich ständig irgendetwas zu tun hat. Ausnahmen sind Fälle, in denen wirklich kein Service mehr aktiv ist. Nur stellt sich dann die Frage, warum der Server überhaupt läuft. Wer es probieren will, sollte aber die Idle Zeit etwas höher einstellen: mit hdparm -S 242 /dev/hda kann man eine Idle Zeit von 60 Minuten einstellen.

In dem nächsten Kapitel werden die Datei- und Druckdienste für Windows Clients eingerichtet.

4 Kommentare zum Artikel “Home Server, Teil 3 – Konfiguration: Grundkonfiguration & System Update”

  1. Nette Anleitung. Gefällt mir gut. Speziell der UML-Teil.
    Aber kurzer Hinweis: Das Startskript brauchst Du nicht.
    Forwarding und SYN-Cookies können in /etc/sysctl.conf eingetragen werden.
    hdparm kann in /etc/sysconfig/harddisks
    konfiguriert werden.

    Schöne Grüße,

    Ralf

  2. Die Anleitung gefällt mir auch sehr gut.
    Ggfs. könnte man hda auch in den Standby schalten,
    wenn man die Logs auf eine RAM-Disk auslagert!?

    Viele Grüße,

    Thomas

    • Ich bezweifele, dass das mit der hda so einfach klappt. Sobald irgendein Daemon von Zeit zu Zeit prüft, ob sich seine Konfigurationsdatei in /etc ändert, wird die Platte immer wieder aktiviert. Wenn Hintergrundjobs ihren Speicherbedarf ändert, will das System auf den Swap zugreifen.

      Vermutlich kriegt man das alles hingebogen, der Aufwand dürfte aber über das Verlagern der Logfiles in eine RAM-Disk hinaus gehen.

  3. hab auf meinem server noflushd laufen.
    das prog schreibt die logs etc. erst mal in den ram.
    http://www.newbie-net.de/anleitung_noflushd.html

    mfg

    tom

Schreibe einen Kommentar


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