Linux Untersttzung in Schulungssystemen

Grnde fr das Sichern von Arbeitspl舩zten

Das Aufsetzten eines Systemes ist meistens mit einem hohen Zeitaufwand verbunden, Einspielen von Service-Packs und die individuelle Einrichtung des Systems nehmen viel Zeit in Anspruch. Glcklich kann hier sein wer, aus Hardware und Lizenssicht, in der Lage ist ein aufgesetztes System auf andere Arbeitspl舩ze zu duplizieren (klonen). Deshalb ist es aus onomischer Sicht sinnvoll, fertige Systeme zu sicher und diese bei Bedarf wieder auf die Rechner zurckgespielen, um ein jungfreuliches System wie nach einer Installation zu erhalten.

Wenn es die Lizenzpolitik erlaut, ist es mlich eine rekursive Installationsherachie aufzubauen. Hierbei wird eine Basisinstallation erstellt, die alle notwendigen Hardwaretreiber und Grundeinstellungen enth舁t. Fr unterschiedliche Hardwareausstattungen werden Hardwareprofile angelegt, und alle notwendigen Scripte und Datenbanken werden integriert. Diese Installation dient jetzt als Basis fr unterschiedliche Installationen, und kann danach mittels klonen der Installation an die Rechner verteilt werden. Mit dieser Technik ist eine Wartung der Installationen auch wesentlich einfacher durchzufhren, Updates und SPｴs knen zentral von der Administrative auf die Installation eingespielt und danach auf alle betreffenden Systeme verteilt werden.

Probleme unterschiedlicher Filesysteme

DOS und W9x Systeme arbeiten mit einem FAT Dateisystem, welches bekannt und auch gut dokumentiert ist. Aus diesem Grunde gibt es fr dieses Filesystem auch die meiste Untersttzung, allerdings hat es auch einige gravierende Nachteile die eine Sicherung erst notwendig machen. FAT untersttzt keine Dateirechte, aus diesem Grund kann jeder der auf dem System arbeitet dieses auch ver舅dern und besch臈igen. Hierbei kann es sich um eine mutwillige, aber auch um eine versehentliche Besch臈igung handeln. NT, W2000 und XP verfgen ber ein NTFS Filesystem, wobei hier die Versionen und verfgbaren Funktionen des Dateisystemes variieren. Dieses Filesystem wird vom Hersteller Microsoft mehr oder weniger geheim gehalten. Die Folge ist, dass es kaum Tools zur Bearbeitung und sinnvollen Sicherung solcher Systeme gibt, da derzeitig nur MS Betriebssysteme dieses Dateisystem sicher bearbeiten knen. Systeme der NT-Schiene besitzen intern eine System-ID, diese muss auf allen System unterschiedlich sein, was durch ein Klonen nicht zu ist. Zur Lung des Problemes hat Microsoft ein Tool zur Verfgung gestellt, mit dem es mlich ist die SID auf den Arbeitsplatzrechnern zu 舅dern Nach dem clonen ist es notwendig jeden W2000 und XP Arbeitsplatz noch einmal von Hand anzufassen, um den Rechner in eine eventuell bestehende Domain einzugliedern oder weitere Netzwerk-Einstellungen durchzufhren. Man kann ruhig sagen, dass das Aufsetzten eines W2000 oder XP Systems wesentlich aufwendiger ist als ein W9x System. Allerdings darf man auch nicht vergessen, das Aufgrund der Nutzerrechte dieses wesentlich l舅ger h舁t. Eine Empfehlung einiger Klone-Tool Hersteller, sein System mit FAT32 zu installieren, um die Funktionen der Software nutzen zu knen, sollte man deshalb kritisch betrachten. Filesysteme unter Linux sind dank Open-Source offen, und bringen von Hause aus gengend Tools zur Sicherung und Wartung mit. Linux kennt ebenfalls Nutzerrechte, und steht in diesem Punkt sicherheitstechnisch nicht hinter dem Microsoft Betriebssystemen zurck. Es ist aufgrund seiner offenen Struktur leichter zu pflegen, und l舖st sich durch Scripte am besten automatisieren.

Unterschiedliche Sicherungsmethoden und Arten

Aufgrund der unterschiedlichen Eigenschaften der vorliegenden Dateisysteme knen auch unterschiedliche Sicherungsmethoden verwendet werden. Hier unterscheide ich zwischen Dateisystemen die auf Dateibasis gesichert werden knen, und Systemen die geometrieabh舅gig gesichert werden mssen. Bei einer Sicherung auf Dateibasis wird keine Information des darunter liegenden Dateisystemes mitgesichert, sondern nur die reinen Dateinformationen. Kandidaten fr eine derartige Sicherung sind alle Unix/Linux Dateisysteme, und das DOS und Windows basierende FAT16. Der Vorteil ist, dass beim Recovern auch die Gre des Laufwerkes ge舅dert werden kann. Das Bedeutet aber, dass das Laufwerk neu Formatiert, und ggf. auch noch ein Bootloader neu installiert werden muss. Hier bleibt fr FAT16 nur die DOS Bootdiskette, und der Befehl sys c: um einen Loader auf die Partition zu installieren. Unter Linux wird meistens der Linux Loader LILO eingesetzt, dieser kann auch von dem Gast Linuxsystem, mit dem das System recovert wurde, wieder initialisiert werden.

+++

Das Sichern/Recovern eines Linuxsystems auf Dateibasis sieht analog aus, allerdings werden hier andere Filesysteme auf den Partitionen verwendet. FAT32 ist ein aufgebohrtes FAT16 System, die Unterschiede liegen hier in der verwaltbaren Gre, und in der Mlichkeit lange Dateinamen zu verwenden. Die langen Dateinamen knen sich hierbei als Problem erweisen, da alle Dateien mit ihrem langem Dateinamen gesichert werden, ist die Wahl des kurzen Namens beim Recovern willkrlich. Das wird zu Problemen bei Programmen fhren, die auf die kurzen Namen angewiesen sind. NTFS Dateisystem knen derzeitig unter Linux nur als Partitionsimage gesichert, und recovert werden. Diese Mlichkeit besteht aber auch mit allen anderen Systemen, hierbei kann keine Ver舅derung der Laufwerksgrse durchgefhrt werden. Ein Recovern ist auch nur mlich, wenn die Ziel-Partition mindestens genau so gross ist wie die Quell-Partition. Images von Partitionen lassen sich mit 'dd' erstellen, oder zurckspielen. 'dd' kopiert die gesamte Partition in die entsprechende Datei, hierbei werden auch nicht verwendete Blke mit kopiert. Aus diesem Grund sind die Images immer relativ groﾟ, und auch im komprimiertem Zustand umst舅dlich zu h舅deln. Die eben aufgefhrten Methoden sind fr viele relativ schwierige Komandozeilenbefehle, und setzen aucheiniges an Kenntnissen ber die verwendeten Techniken voraus. Einfacher l舖st sich die Sicherung ber ein Tool len, welches ber ein Benutzerinterface bedient wird. Ein entsprechendes Tool ist auf der aktuellen Knoppix CD verfgbar, es heiﾟt partimage , und kann aus der Komandozeile ber Dialog bedient werden. Es untersttzt die Linux Filesysteme ReiserFS, ext2, ext3 und die Windowsdateisystem FAT16 und FAT32. NTFS wird hier als ;experimental support; gefhrt, dieses wird sich warscheinlich solange nicht 舅dern, wie Microsoft die technischen Details des Filesystemes unter Verschluss h舁t. Partimage speichert nur die benutzten Blke einer Partition, kann aber derzeitig noch nicht zur ﾄnderung von Partitionsgrsen verwendet werden. Die Daten werden komprimiert, und auf Wunsch kann die Sicherung auch auf mehrere Volumen mit einer festlegbaren Gre gesichert werden.

Ich habe hier jetzt mehrere Sicherungsmethoden aufgezeigt, diese lassen sich auf mindestens 2 Arten anwenden. Zum einen besteht die Mlichkeit auf dem System lokal eine Partition anzulegen, in dem die Sicherung abgelegt wird. Auf diese Weise kann eine schnelle Rcksicherung mit einem Gastsystem wie zum Beispiel Knoppix erfolgen, und es werden keine Netzwerkresourcen belegt. Da diese Partition immer im direktem Zugriff des Benutzers steht, besteht hier auch immer die Gefahr einer Besch臈igung oder Lchung der Daten. Ein einfaches Spielen mit fdisk unter DOS reicht dafr schon aus, auch sind die Daten nicht vor einem defekt der Festplatte sicher. Eine andere Mlichkeit besteht darin, die Sicherungsdaten auf eine Server auszulagern. Dadurch sind diese vor Besch臈igungen relativ sicher, und knen ggf. einer Datensicherung zugefhrt werden. Wer die ersten beiden Methoden tar und dd bevorzugt, kann mit dem Gastsystem ein Netzlaufwerk mounten. Als Server knten hier NFS oder ein mit Samba aufgebauter SMB Server dienen. Partimage bringt hierfr seinen eigenen Server mit, dieser sollte auf allen aktuellen Distributionen verfgbar sein. Der Dienst kann dann mit auf dem Fileserver eingerichtet werden, auf diesen kann der Partimage Client zugreifen, und die Images lesen und schreiben. Auf diese Weise stehen die Images Systemweit zur Verfgung, allerdings dauert das Aufspielen einer Sicherung dadurch l舅ger, und es werden erhebliche Netzresourcen belegt.

Fileserver fr administrative Aufgaben

Jeder der Computersysteme verwaltet kennt das Problem, wenn zum Beispiel eine Hardwarekomponente von Rechner A zu Rechner B wechselt, oder mal eben 舁tere Treiber fr eine Grafikkarte benigt werden. Jeder Administrator ist ein J臠er und Sammler, denn auch der 舁teste Treiber oder die ungewlichste Boot-Diskette kann einem schon mal das Wochenende retten. Eine Mlichkeit besteht darin alles auf CD zu brennen und akribisch zu beschriften, eine andere Treiber, Tools und Software systemweit ber einen Fileserver zur Verfgung zu haben. Der Server kann seinen Dienst hier ber SMB mit Samba, ber eine NFS-Freigabe oder ber einen FTP Zugriff zur Verfgung stellen. Der Zugriff sollte ber ein Passwort geschtzt sein, um sicherzustellen das keine Daten lizenzwidrig entfl舫chen. Mit einem gut gewartetem Server fr Treiber ist es ein leichtes mal eben eine neue Hardwarekomponente zu installieren, oder 舁tere Treiber aufzuspielen.

Automatisches verteilen von Updates

Das neue Semester hat begonnen, und man hat es gerade so geschafft alle Systeme einzurichten. Da kommt am Nachmittags der Dozent X vorbei, und merkt an, das ihm auf dem Rechner das Tool Y fehlt, ohne das er n臘hste Woche natrlich keinen Unterricht machen kann. Scher Mist, die Arbeit der letzten 3 Tage zum Teufel, und da man ja nur ab Samstag Mittag die Rechner stillegen kann ist das Wochende auch noch versaut.

Wer vorgebaut hat ist in solchen Situationen fein raus, viele Updates lassen sich auch ber ein Netzwerk erledigen und sind so im laufendem Betrieb mlich. Ein Server stellt hier die Updates zur Verfgung, der Client prft diese beim Hochfahren ab, und spielt sie ein wenn es notwendig ist. Linux-Clients sind hier durch ihr offenes System sehr stark im Vorteil, die leistungsf臧igen Scriptf臧igkeiten erweitern hier die Mlichkeiten. Bei Windowssystem ist das ganze schon wesentlich schwieriger, h舫fig muss hier das Update im zwei-pass Verfahren durchgefhrt werden. Das bedeutet, es sind mindestens 2 Systemstarts notwendig um das Update einzuspielen.

Der Ablauf des Updates ist bei allen System gleich, allerdings unterscheidet sich der Aufruf und die Abarbeitung je nach System. Zum Beginn muss ein Netzlaufwerk eingebunden werden, und von diesem eine Indexliste aller zur Verfgung stehenden Updates geladen werden. Anhand der Indexliste kann der Client ermitteln welche Pakete er benigt, und welche er verwerfen kann da er diese schon installiert hat. Danach knen die Pakete geladen, installiert, ein Updatestatus gespeichert, das Netzlaufwerk getrennt und ein Protokoll geschrieben werden. Auf diese Weise knen Einzeldateien oder Programmpakete ausgetauscht werden. Handelt es sich bei dem Client nicht um ein W9x System, ist auf ein korrektes setzen der Benutzerrechte zu achten.

Fr Einzeldateien und Pakete kann in der Indexliste eine Prfsumme mit bergeben werden, der Client kann so, ohne die Datei zu laden, prfen ob diese nicht schon aktuell ist. Da jetzt nicht jedesmal beim Starten 20 Clients 30 Pakete laden, die sie danach eh wieder verwerfen, werden hier Bandbreite auf dem Netzwerk und Resourcen beim Server eingespart. Bei einigen Systemen ist es nicht mlich Dateien auszutauschen die gerade verwendet werden, so kann z.B. die 'system.dat' einer Windows 98 Installation nicht im laufendem Betrieb ausgetausch werden. Solche Dateien mssen dann in zwei Durchg舅gen ausgetauscht werden. Pass eins, die Dateien werden normal geladen, zwischengespeichert und das System wird neu gestartet. Pass zwei, zu einem sehr frhem Zeitpunkt (autoexec.bat) werden die lokal gespeicherten Dateien eingespielt. Hierbei ist darauf zu achten, dass keine Endlosschleife entsteht, und das System nur noch am booten ist. Der Update-Vorgang l舖st sich bei W9x Clients mit in das netlogon Script einbinden, so ist sichergestellt das eine bestehende Serververbindung vorhanden ist. Zum Schreiben komplexer Scripte und Funktionen sind die Batch-Funktionen von Microsoft leider nicht geeignet. Fr diesen Zweck bietet sich GNU/AWK fr DOS an, damit stehen neben den allgemeinen Erleichterungen auch Feinheiten wie regul舐e Ausdrcke und assoziative Arrays zur Verfgung.

Bei Linux-Systemen kann der Prozess mit in den Init-Ablauf eingebunden werden, direkt nach dem initialisieren des Netzwerkes ist ein Zugriff auf Netzwerkresourcen mlich. Unter Linux stehen auch komplette Paketformate wie .rpm und .dep zur Verfgung, diese bieten schon von Hause aus eine weitreichende Untersttzung fr Updates. Pakete im .dep Format knen von Hause aus ber Netzwerk auf den neusten Stand gebracht werden, auch knen hier Server fr Updates festgelegt, oder eigene Server genutzt werden. Gerade die letzte Option ist fr eine lokale Administration wichtig, mit ihr kann der Administrator Updates lokal fr seine Systeme zusammenstellen und diese so unter Kontrolle halten.

Zentrale Unterrichtsarchive

Die im Unterricht benigten Materialien und Vorlagen knen zentral auf einem Fileserver verwaltet und bereitgehalten werden, sie stehen dann durch die Vernetzung im gesamten Unterrichtsraum zur Verfgung. Dadurch kann Arbeitszeit gespart werden, da eine individuelle Verteilung an die Teilnehmer nicht mehr notwendig ist. Auch der bei einer lokalen Vorhaltung der Archive, auf den Clients, benigte Speicherplatz kann eingespart werden, und die Pflege der Archive kann Zentral erfolgen.

Verteilen von Unterrichtsmaterial

Die "eigenen Dateien" der Benutzer knen auf ein Serververzeichniss ausgelagert werden. Auf dem Server liegen diese sicher, und man muss sich beim Wiederherstellen einer Installation keine Gedanken ber diese Daten machen. Bei anonymen Benutzern knen diese Verzeichnisse dem Dozenten zug舅glich gemacht werden, auf diese Weise kann der Dozent individuell eingreifen, und dem Teilnehmer eine Hilfestellung geben. Durch die zug舅glichen Verzeichnisse ist es auch mlich individuelles Material an die Teilnehmer zu verteilen oder Ergebnisse einzusammeln.

Gemeinsames Nutzen von Hardwareressourcen

Hardware ist teuer, und Geld meistens knapp. Ein Netzwerk ermlicht es die Hardwarerressourcen in einem Unterrichtsraum gemeinsam einzusetzen, oft ist es nur so mlich berhaupt an die Anschaffung eines Ger舩es zu denken. Das klassische Beispiel ist hier der Drucker, dieser kann an einen Arbeitsplatz angeschlossen und von den anderen Benutzern genutzt werden. Sollte es allerdings unterschiedliche Drucker geben, ist es notwendig die unterschiedlichen Treiber zu installieren, und bei einem Wechsel des Ger舩es an allen Arbeitspl舩zten die Treiber zu tauschen. Hier besteht wieder die Mlichkeit sich mit einem Samba Druckserver die Arbeit zu erleichtern. Auf dem Server wird der Drucker lokal eingerichtet und getestet, danach wird mit Samba eine Drucker Freigabe erzeugt. Wir wollen aber die Druckverarbeitung vom Server durchfhren lassen, die Daten werden im Postscript Format empfangen und fr den Drucker lokal auf dem Server weiterverarbeitet. Als Druckertreiber muss auf den Arbeitspl舩zen dann ein Postscript Treiber wie der "Appel Laserwriter" installiert werden. Sollte sich dann sp舩er der Drucker 舅dern, braucht er nur noch lokal auf dem Server angepasst zu werden. Es ist aber zu beachten, das die Umsetzung von Postscript mit Hilfe des Ghostscipt Paketes erfolgt, dieses benigt dafr aber mehr Zeit und auch mehr Speicher als auf den Arbeitspl舩zen nig w舐e. Als Drucker sollte im Schulungsbereich nicht auch billige Tintenstrahldrucker zurckgegriffen werden, da die Verbrauchskosten und der Wegwerfanteil im Schulbetrieb zu hoch sind. Sinnvoll w舐en Laserdrucker mit gekapseltem Papiervorrat, diese sind gnstig im Verbrauch und Robust in der Handhabung.

Wenn man denn schon einen Rechner fr die Druckverarbeitung im Unterrichtsraum stehen hat, kann dieser auch gleich fr die Nutzung des Scanners eingesetzt werden. Der Scanner wird wie der Drucker auf dem Server lokal installiert, und ber einen Dienst allen anderen Nutzern zur Verfgung gestellt. Auf den Arbeitspl舩zen muss dafr ein Client installiert werden, ber den der Scanner angesprochen werden kann. Da immer nur eine Person zur Zeit einen Scannvorgang durchfhren kann, ist hier etwas Disziplin bei den Teilnehmern notwendig. Auf dem Server eignet sich hierfr SANE, der Standard beim Thema scannen unter Linux. Auf der Site des Projektes kann man erkennen das SANE eine grosse Anzahl an Ger舩en untersttzt. Vor dem Kauf eines neuen Scanners, sollte man hier einmal einen Blick draufwerfen. Der Scannvorgang wird in 2 Bereich unterteilt. ﾜber das Backend wird der Zugriff auf die Hardware durchgefhrt, es bildet den Treiber fr das verwendetet Ger舩. Zus舩zlich gibt es auch noch Meta-Backends, ber diese ist es zum Beispiel mlich einen einen Netzwerkscanner anzusprechen. Das Frontend bildet die Schnittstelle zum Benutzer, dieses wird aber auf dem Server meisens nicht benigt, auﾟer man mhte von hier direkt scannen knen. Das Herzstck fr den Netzwerkeinsatz ist aber der Dienst Saned, der den Scanner nach auﾟen zur Verfgung stellt. Dieser Dienst, der fr einen lokalen Ger舩eeinsatz nicht benigt wird, wird ber den Inetd Demon geladen, und muss deshalb auch in der Datei /etc/inetd.conf wie folgt eingerichtet werden.

sane stream tcp nowait saned.saned /usr/......../saned saned

Wie in der Konfigurationszeile zu sehen ist, sollte fr den Betrieb ein Benutzer (saned) und eine Gruppe (saned) zur Nutzung eingericht werden. Die Gruppe (saned) sollte auch einen vollen Zugriff auf das verwendete Ger舩e im Ger舩everzeichniss /dev bekommen, um dieses Ger舩 nutzen zu knen. Ebenfalls ist in zu erkennen, das wir den Port des Dienstes ber einen Alias ansprechen, dieser muss eventuell in der Datei /etc/services nachgetragen werden.

sane      6566/tcp    saned #; SANE network scanner deamon

Jetzt knen wir daran gehen das Backend von SANE zu konfigurieren, die Dateien dafr befinden sich meistens unter /etc/sane.d oder /usr/local/etc/saned.d. Die Dateien dll.conf und net.conf sind Meta-Backends, ber dll.conf wird festgelegt mit welchen Backends SANE arbeiten soll. In net.conf knen Netzwerkscanner angegeben werden, die eingebunden werden sollen. Alle anderen Dateien sind zur Konfiguration der Backends verschiedener Ger舩e vorgesehen, hier schlagen Sie fr die Konfiguration am besten auf der SANE Site nach. Falls es notwendig ist, kann der Zugriff auf das Ger舩 auch noch durch einen Benutzer- und Passwortschutz gesichert werden. Benutzer, Passwter und erlaubte Backends werden hierbei in die Datei saned.user mit folgendem Schema eingetragen:

user:password:backend

Eine weitere Datei die den externen Zugriff auf den Dienst regelt ist die Datei saned.conf. Hier knen die Hosts mit Namen oder IP-Adresse eingetragen werden, von denen ein Zugriff erlaubt ist. Es ist aber darauf zu achten, dass auch ein Reverse-Lookup der Hostnamen mlich ist, da sonst der Zugriff verweigert wird. Bei DNS Problemen kann das Resolving lokal erfolgen, hierfr mssen die die Hosts in der Datei /etc/hosts eingetragen werden. Wenn keine Zugriffsbeschr舅kung auf Netzbasis gewscht ist, ist in der Datei saned.conf nur eine Zeile mit einem "+" einzutragen. Als letztes kann geprft werden welche Scanner zur Verfgung stehen.

$ scanimage -L

Die Einrichtung des Netzwerkscanners auf Arbeitsplatzrechner mit einem Linux Betriebssystem funktioniert analog, hier kann aber die Konfiguration des saned Dienstes ausgelassen werden, da der Scanner ja nicht noch einmal freigegeben werden soll. Als Backend ist das net.conf Backend zu konfigurieren, die Verfgbarkeit von Scannern kann dann wieder mit scanimage geprft werden. Bei Problemen sollte man auch mal einen Blick auf die Log Dateien des Servers werfen.

Fr Windows stehen verschiedene Clients zur Verfgung, hierbei sind auch erste Clients mit TWAIN Schnittstelle, die ein gewohntes arbeiten mit dem Ger舩 ermlichen, verfgbar. Zu Empfehlen w舐e der XSane Client, hier mssen die eingescannten Objekte zwar noch als Datei gespeichert werden, aber er ist einfach zu bedienen und ist sehr ausgereift. Die Installation von XSane ist sehr einfach, das Archiv wird nach c:\ entpackt, hierbei wird ein Unterverzeichniss sane angelegt in dem sich das gesamte Paket befindet. Konfiguriert wird das ganze ber die Datei c:\sane\etc\sane.d\; net.conf, hier ist die IP Adresse des Servers anzugeben ber den der Scanner verfgbar ist. Nach dem Aufruf von c:\sane\Xsane.exe wird der Scanner gesucht, und das GUI baut sich auf.

DHCP und DNS die unsichtbaren Helfer

DHCP steht fr "Dynamic Host Configuration Protokol" und kann helfen die Netzwerkkonfiguration in den Unterrichtsr舫men zu vereinfachen. Hierbei wartet ein Dienst im Netzwerk darauf, dass sich ein neuer Client im Netzwerk meldet und nach Konfigurationsdaten fragt. Daraufhin wird dem Client ein Datensatz mit Konfigurationsinformationen zugestellt, die er zum Einrichten seines Netzwerkes verwenden soll. Es knen folgende Informationen enthalten sein:

Alle diese Informationen werden dem Client dynamisch mitgeteilt, dadurch wird das statisches Eintragen der Werte auf den Arbeitspl舩zen vermieden. Sollten sich diese Werte einmal 舅dern, muss so nicht mehr jeder Arbeitsplatz von Hand umconfiguriert werden. Die ﾄnderungen werden einmalig auf dem Server durchgefhrt und stehen den Clients beim n臘hstem Start zur Verfgung. Es gibt hier vielf舁tige Mlichkeiten den Dienst zu konfigurieren, ich mhte hier den einfachsten Weg fr eine Konfiguration mit einer dynamischen IP-Range beschreiben. Der Dienst ist fr alle Distributionen verfgbar und wird meistens mitgeliefert. Wenn er auf einem Server installiert ist, ist die Datei /etc/dhcp.conf fr die Konfiguration zust舅dig.

# /etc/dhcpd.conf
# Allg. Konfigurationsbeispiel fr eine einfache Arbeitsumgebung
#
# Def. globaler Werte
default-lease-time 10800; # Die Standard-Adreﾟzuweisung soll 3 Stunden
                          # (10800 Sekunden) betragen
max-lease-time     86400; # Maximal gilt die Zuweisung fr 1 Tag
                          # (86400 Sekunden)
get-lease-hostname false; # Der Server soll die Clients nicht mit
                          # einem Hostnamen versorgen
# Def. globaler Optionen
# Festlegen von Netzwerkmaske und Broadcast die global
# verwendet werden soll (Wenn nicht sp舩er anders angegeben)
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.101.255
# Festlegen der Domain
option domain "meineschule.local"
# Festlegen der gltigen DNS-Server im Netzwerk
option domain-name-servers 192.168.101.16, 192.168.101.17
#
#-----------------------------------------------------------
# Festlegung der IP Adressen im Arbeitsnetzwerk
# 000, 255  -> NC
# 001-015   -> Gateways, Router, Switches, Hubs
# 016-031   -> Server mit Diensten, File, Print, Time, .....
# 032-063   -> NC
# 064-127   -> IP-Vergabe von Hand
# 128-254   -> IP-Vergabe per DHCP
#-----------------------------------------------------------
#
subnet 192.168.101.0 netmask 255.255.255.0 {
  option routers 192.168.101.5;
  option broadcast-address 192.168.101.255;
  range 192.168.101.128 192.168.101.254;
}

Bei diesem Beispiel verwaltet der DHCP-Dienst die Hostadressen 128-254 in einem vorhandenem Subnet. Die Clients knen eine Adresse fr max. 3 Stunden anforden, nach Ablauf dieser Zeit muss die Adresse erneut abgefragt und best舩igt werden. Der Server vergibt eine Adresse maximal fr 24 Stunden an einen Client. Die Adressen aller weiterer Dienste und Optionen wie DNS-Server, Netzwerkmasken, Broadcastadressen und Domain Name sind hier vermerkt und werden den Clients mitgeteilt. Die meisten Optionen wurden global angegeben, da sie sich im Verlauf der gesamten Konfiguration nicht 舅dern. Abweichende Einstellungen knen innerhalb der Konfigurationsblke ge舅dert werden.

Ein weiteres Hilfsmittel ist die Einrichtung eines Domain Name Service zur Auflung von Hostnamen zu IP-Adressen. Meistens werden Mailsserver bei Outlook oder der Webproxy mit einer IP eingetragen, 舅dert sich diese aus irgend einem Grund, muss man seine Turnschuhe einpacken und alle Arbeitspl舩ze aufsuchen. Auﾟerdem sind Namen wie pop3.meineschule.local, smtp.meineschule.local oder proxy.meineschule.local wesentlich aussagekr臟tiger als reine IP-Adressen, und helfen mit ein System skalierbar zu halten. Alle Anfragen zwecks einer Namensauflung gehen an den internen DNS-Server, dieser versucht den Namen aufzulen, oder die Antwort ber eine Anfrage bei einem externem DNS-Server zu beschaffen. Fr alle Antworten ist eine Zeit definiert wie lange diese gltig ist, der lokale DNS merkt sich die Antwort ber diesen Zeitraum und gibt sie bei einer gleichen Anfrage wieder heraus. Dadurch werden Resourcen und Bandbreite von Providern und externen Dienstanbietern geschont, und auch die eigenen Nutzer haben davon Vorteile. Vor dem Einrichten muss eine DNS-Domain gew臧lt werden, hierbei ist darauf zu achten, dass die verwendete Toplevel-Domain (.local) keine offizielle Toplevel-Domain ist. Die Verwendung einer offiziellen Toplevel-Domain knte zu Unstimmigkeiten bei der Namensauflung fhren, und weitreichende Maﾟnahmen bei der Einrichtung anderer Dienste notwendig machen.

Die Einrichtung des DNS-Servers BIND erfolgt in mehreren Dateien, zum Einem die Konfigurationsdatei /etc/named.conf, zum Anderen in den Zonen- und Datenbankdateien mit den DNS Informationen.

#/etc/named.conf
# Einfaches Beispiel fr eine BIND8 konfiguration
options {
        directory "/var/named";
        check-names master warn;
        pid-file "/var/run/named.pid";
        datasize default;
        coresize default;
        files unlimited;
        multiple-cname no;

# Der Server soll nicht selber externe Anfragen auflen;
# sondern einen externen DNS dafr verwenden.
        forward only
        forwarders {
                   212.185.254.170;
                   212.185.253.70;
                   };
#[.....]; ACL und Logging wurde ausgelassen
}
zone "." IN {
         type hint;
         file "root.hint";
};
zone "localhost" IN {
         type master;
         file "localhost.zone";
         check-names fail;
         allow-update { none;};
};
zone "0.0.127.in-addr.arpa" IN {
         type master;
         file "127.0.0.zone";
         check-names fail;
         allow-updates {none;};
};
zone "meineschule.local" IN {
         type master;
         file "meineschule.local.zone"
         check-names fail;
         allow-updates {none;};
};
zone "100.168.192.in-addr.arpa" IN {
         type master;
         file "meineschule.local.rev"
         check-name fail;
         allow-updates {none;};
};

Eine wichtige Einstellung ist hier die Angabe wo sich die Zonen-Dateien befinden (/var/named), und die Option forward only. Durch diese Option wird BIND angewiesen, fr Namen die er nicht kennt, einen externen Nameserver als Forwarder zu benutzen. Diese sind in der Liste forwarder{} einzutragen, am besten nimmt man hier 2 Nameserver seines Providers und 2 offizielle .DE Server. Ohne diese Option wrde BIND selber versuchen den Namen aufzulen, er wrde dabei bei den Root-Servern anfangen und sich bis zum zust舅digem Domainenserver hocharbeiten. Dieses stellt eine unnige Verzerung da, da die Server vom Provider einen greren Cache und eine besser Netzanbindung besitzt, als unser lokaler Nameserver. Als n臘hsten kommt die Konfigurationen der Zonen. Die Zone "." ist die Root-Zone, sie zeigt auf eine Datei in der die 15 Root-Server verzeichnet sind. Diese Server w舐en wichtig wenn unser Nameserver selber eine Auflung der externen Namen durchfhren wrde, aber auch wenn wir sie nicht benigen, sollte man diese Datei gelegentlich updaten. Die Zone "localhost" ist eine Auflung des loopback Interfaces, diese Dateien sollten in der Regel schon existieren und mssen ggf. nur angepasst werden. Bei der Zone "0.0.127.in-addr.arpa" handelt es sich um ein Reverse-Lookup fr die Zone "localhost". Reverse-Loockup bedeutet, dass auf eine IP-Adresse ein Hostname gesucht wird. Viele Dienste fhren ein Reverse-Lookup des Clients durch, der auf diesen zugreifen mhte. F舁lt die Anfrage negativ oder unerwartet aus, verweigert der Dienst seine Arbeit. Bei einem sauber konfigurierten Netzwerk sollte deshalb immer ein Reverse-Lookup mlich sein. Die beiden letzten Zonen stellen unsere eigene Zone fr die Domain "meineschule.local" und das dazugehige Reverse-Lookup da. Der jeweiligen Zone wird mittels "file" mitgeteilt, in welche Datei sich die Datenbank fr diese Zone befindet. Alle Dateien liegen realtiv zum Datenpfad "directory". Die Datei fr die eigene Zone wurde zur besseren Wartbarkeit in mehrere Dateien aufgeteilt.

;/var/named/meineschule.local.zone
@  in SOA dns1.meineschule.local admin.meineschule.local (
             10110    ; Seriennummer der Datei, bei ﾄnderung erhen.
             43200    ; Zeit bis zum n臘hsten Zonen refresh, fr
                      ; einen sekund舐en DNS
             3600     ; Zeit fr einen erneuten Versuch eines
                      ; fehlgeschlagenen Zonenrefreshs.
             360000   ; So lange darf ein sekund舐er Nameserver auch
                      ; ohne gelungenem Zonenrefresh die Daten
                      ; weiterferwenden.
             250000 ) ; TTL - Lebensdauer der Antworten
include NAMEuMAIL.meineschule.local
include DIENSTE.meineschule.local.zone
include DHCP-CLIENTS.meineschule.local.zone

Die Datei /var/named/meineschule.local.zone enth舁t am Anfang den SOA Record (Start of Authority), das @ reverenziert die Zonen-Domain, diese wird aus dem entsprechendem Zonenblock der /etc/named.conf Datei bernommen. Gefolgt von dem Hostnamen, der der Masterserver fr diese Domain ist und der EMail-Adresse der verantwortlichen Person fr den Server. Bei der Mailadresse wurde das "@" durch einen "." ersetzt. Die weiteren Parameter nehmen Einfluss auf das Verhalten der Domain.

Die Seriennummer sollte nach jeder ﾄnderung der Zonen-Datei hochgez臧lt werden, damit ein sekund舐er Nameserver diese Ver舅derung bemerkt. Die n臘hsten drei Werte sind bei der Verwendung eines sekund舐enm Nameservers wichtig. Ein Sekund舐er Nameserver erh舁t seinen Datenbestand durch einen Zonentransfer mit dem Masterserver, jeder Masterserver kann auch fr eine andere Domain den sekund舐en Nameserver bernehmen. Der zweite Wert sagt, aus wieviel Zeit ins Sekunden zwischen den Transfers liegen soll. Sollte ein Transfer nicht geklappt haben, sagt der vierte Wert nach welchem Zeitablauf ein erneuter Versuch gestartet werden soll. Der fnfte Wert sagt aus, wie lange die Server die Daten ohne durchgefhrtem Zonentransfer als gltig betrachten soll. Als letztes steht die allgemeine Lebensdauer (TTL) die jeder Antwort beigefgt wird, und dem Client sagt wie lange die Antwort Gltigkeit besitzt.

Die zugehigen Elemente wurden per include der Datei hinzugefgt. In diesen werden die DNS-Daten in Records abgelegt, der Aufbau eines Records sieht wie folgt aus:

 [name][ttl] IN data

Aufbau eines DNS-Records

;/var/named/NAMEuMAIL.meineschule.local
; Festlegung von Name- und Mailserver fr die Zone
                IN     NS    dns1.meineschule.local.
                IN     NS    dns2.meineschule.local.
                IN     MX    10 mail.meineschule.local.

In dem ersten Abschnitt legen wird die Name- und Mailserver fr die Domain fest, ber diese Eintr臠e kann zum Beispiel ein Mail Transfer Agent (MTA) einen Mailserver fr eine Mailauslieferung lokalisieren. Die ersten beiden Records sind Nameserver Records (NS), sie deklarieren die fr diese Domain zust舅digen Nameserver. Der letzte Record ist ein Mail-Exchange (MX) Record, er gibt an welche Mailserver fr die Domain zust舅dig sind. In diesem Record wird eine Pr臟erenzwert (10) eingetragen, mit diesem kann bei mehrern Mailservern festgelegt werden in welcher Reihenfolge die Server verwendet werden. Mit mehrern Servern kann die Mailauslieferung ausfallsicherer durchgefhrt werden, je kleiner der Wert, um so besser ist der Server.

;/var/named/DIENSTE.meineschule.local.zone
; Festlegung von Diensten die im Netzwerk verfgbar sind.
; Alle Angaben erfolgen relativ zur Zone.
; ->; Unsere Server
merkur          IN     A     192.168.101.16
mars            IN     A     192.168.101.17
; -> Zuweisung der Dienste
; Domain Name Server
dns1            IN     CNAME     merkur
dns2            IN     CNAME     mars

; Mail und News Dienste
mail            IN     CNAME     mars
pop3            IN     CNAME     mars
imap            IN     CNAME     mars
smtp            IN     CNAME     mars
sntp            IN     CNAME     mars

; Webdienste
www             IN     CNAME     merkur
proxy           IN     CNAME     mars

; Dateidienste
ftp             IN     CNAME     merkur
smb             IN     CNAME     merkur
nfs             IN     CNAME     merkur

In diesem Abschnitt erfolgt die Deklaration unserer Server und Dienste. Unsere beiden Server sind Merkur und Mars, auf diesen verteilen sich alle im Netzwerk befindlichen Dienste. Die ersten beiden Records deklarieren unsere Server mit ihrer IP Adresse, es handelt sich hier um Adress Records (A). Hierbei ist zu beachten, dass die Namen keinen Punkt besitzten. Dadurch gehen sie relativ zur behandelten Zonen-Domain, und der volle Name wird mars.meineschule.local lauten. Als n臘hstes folgt die Deklaration der Dienste. Auch hier gibt es keine Punkte, weshalb auch diese Namen relativ zur Zonen-Domain stehen. Bei den Records handelt es sich um Aliase (CNAME), es werden einfach Verweise auf die bestehenden Server gelegt auf dem der Dienst l舫ft.

DHCP-CLIENTS.meineschule.local
; Festlegung der Namen des DHCP-Adressbereiches
; Diese Datei l舖st sich einfach mit einem Skript aufbauen
client-128      IN      A        192.168.101.128
client-129      IN      A        192.168.101.129
[....];
client-254      IN      A        192.168.101.254

Im letzten Abschnitt werden fr alle brigen Hosts Hostnamen eingetragen. Da es sich hier um eine DHCP Vergabe handelt, werden diese einfach durchnummeriert.

Jetzt muss noch die Zone fr das Reverse-Lookup der Zone "meineschule.local" eingerichtet werden. Diese lautet "100.168.192.in-addr.arpa" und befindet sich in der Datei meineschule.local.rev.

;/var/named/meineschule.local.rev
@  in SOA dns1.meineschule.local admin.meineschule.local (
             10110    ; Seriennummer der Datei, bei ﾄnderung erhen.
             43200    ; Zeit bis zum n臘hsten Zonen refresh, fr
                      ; einen sekund舐en DNS
             3600     ; Zeit fr einen erneuten Versuch eines
                      ; fehlgeschlagenen Zonenrefreshs.
             360000   ; So lange darf ein sekund舐er Nameserver auch
                      ; ohne gelungenem Zonenrefresh die Daten
                      ; weiterferwenden.
             250000 ) ; TTL - Lebensdauer der Antworten
                IN      NS         dns1.meineschule.local.
                IN      NS         dns2.meineschule.local.

include DIENSTE.meineschule.local.rev
include DHCP-CLIENTS.meineschule.local.rev

Der Aufbau entspricht der Datei meineschule.local.zone, allerdings wird diese Datei andere Recordtypen verwenden. Am Anfang der Datei steht wieder der SOA, gefolgt von den Namenserver der fr die Zonen-Domain zust舅dig sind. Die Zonen-Domain ist bei dieser Datei "100.168.192.in-addr.arpa".

; /var/named/DIENSTE.meineschule.local.rev
16              IN      PTR        merkur.meineschule.local.
17              IN      PTR        mars.meineschule.local.

Bei Diensten mssen wir nur unsere beiden Server auflen, die unsere Dienste beherbergen. Am Anfang eines Records steht wieder der Name, dieser wird, ohne Punkt am Ende, wieder um die Zonen-Domain erg舅zt. Als Recordtyp wird ein Pointer verwendet (PTR), dieser sorgt fr eine Umwandlung der Adresse zum Hostnamen. Als Daten enthalten die Records die zugehigen Hostnamen, damit diese nicht erweitert werden wurden sie mit einem Punkt abgeschlossen.

;/var/named/DHCP-CLIENTS.meineschule.local.rev
128             IN      PTR        client-128.meineschule.local.
[...];
254             IN      PTR        client-254.meineschule.local.

Als letztes folgt noch in einer eigenen Datei die Auflung der dynamischen Client-Adressen.

Mail und Newsserver im eigenem Haus

...

Proxy fr Webzugriff

Ein Proxy steht bei der Auslieferung zwischen dem Client und dem Server, er vertritt hierbei gegenber dem Server den Client. Dieses kann mehrere Vorteile haben, der Client braucht keinen direkten Zugriff auf das Internet, und der Proxy kann Seiten zwischenspeichern (cachen) und diese bei Bedarf noch einmal ausliefern. Durch den Cache-Mechanismus wird an derBandbreite nach auﾟen gespart und der Zugriff auf Seiten im Internet beschleunigt. Zu Zeiten wo man noch mit ISDN oder Modem an das Internet angebunden war, war die Verwendung von Web-Proxys weit verbreitet. Heute, wo die Anbindung meistens mit DSL und einem Instant-Router ber NAT durchgefhrt wird, sieht man immer weniger Proxys an kleinen Standorten und in Schulen. Das ist eigentlich schade, da durch die Verwendung von Proxys die vorhandene Bandbreite besser und nomiescher genutzt werden kann.

Unter Linux stehen verschiedene Proxys zur Verfgung, der Bekanntestet ist hierbei wohl der Squid (Tintenfisch). Squid ist ein ausgewachsener Tintenfisch, der Funktionsumfang ist sehr weitreichend, Syncronistationsmlichkeiten mit anderen Proxys, Zugriffsbeschr舅kungen ber ACLｴs, diverse Mlichkeiten zum Tunen und das Einbinden von Modulen machen den Tintenfisch zu einem anspruchsvollem Gesellen. In den meisten F舁len werden die Mlichkeiten nicht voll ausgeschft.

Ein weiterer bekannter Proxy ist der WWWOFFLE, dieser Proxy ist im Gegensatz zu Squid in der Lage Webseiten auch offline auszuliefern. Das bedeutet, dass der Cacheinhalt auch ohne Aktivierung des Internetzuganges verfgbar ist. Mit diesem Proxy ist es auch mlich, ganze Sites automatisch in den Cache zu befdern und so z.B. den Unterrichtsstoff gezielt verfgbar zu machen. Aus den Seiten knen auch gezielt animierte GIFs, javascript oder HTML Tags entfernt oder ver舅dert werden. Trotz dieser Mlichkeiten, und weil Squid besser gepflegt wird, wird Squid wohl der Standard bei der Proxyanwendung bleiben.

Beim Einsatz von Squid sollte auf eine artgerechte Haltung des Tintenfisches geachtet werden, die alte Faustregel ein Proxy l舫ft schon auf einem 486ｴer stimmt zwar, aber er wird wenig Freude machen. Zur Verwendung von Squid in einer kleineren bis mittleren Umgebung sollte mindestens ein Pentium 200 Mhz zu verwendet, und in 128MB Hauptspeicher investiert werden. Die Cachedateie sollte nicht zu groﾟ gew臧lt werden (<500MB), da Squid fr jedes Objekt was es speichert einen Index erstellt. Dieser Index wird im Hauptspeicher gehalten, zus舩zlich kommen noch Prozesse fr die Abarbeitung der Anfragen und ggf. noch andere Programme. Sobald der Speicher knapp wird, f舅gt das Betriebssystem an diesen auszulagern, das Ergebnis ist dann ein Tintenfisch der den Webverkehr nach auﾟen lahmlegt anstatt ihn zu beschleunigen. Wenn mlich sollte fr den Cacheinhalt eine eigene Platte oder Partition gew臧lt werden, um das gesamte System nicht auszubremsen.

Ich mhte hier keine komplette Konfiguration von Squid vorstellen, die Einstellungen und Mlichkeiten wrden einfach den Rahmen sprengen. Deshalb verweise ich hier auf des deutschsprachige Squid-Handbuch, es stellt wohl die umfassenste Referenz zu diesem Proxy da.