Index: head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml (revision 45553) +++ head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml (revision 45554) @@ -1,6189 +1,6190 @@ Netzwerkserver MurrayStokelyÜberarbeitet von JohannKoisÜbersetzt von Übersicht Dieses Kapitel beschreibt einige der häufiger verwendeten Netzwerkdienste auf &unix;-Systemen. Beschrieben werden Installation und Konfiguration sowie Test und Wartung verschiedener Netzwerkdienste. Zusätzlich sind im ganzen Kapitel Beispielkonfigurationsdateien vorhanden, von denen Sie sicherlich profitieren werden. Nachdem Sie dieses Kapitel gelesen haben, werden Sie Den inetd-Daemon konfigurieren können. Wissen, wie man ein Netzwerkdateisystem einrichtet. Einen Network Information Server einrichten können, um damit Benutzerkonten im Netzwerk zu verteilen. Rechner durch Nutzung von DHCP automatisch für ein Netzwerk konfigurieren können. In der Lage sein, einen Domain Name Server einzurichten. Den Apache HTTP-Server konfigurieren können. Wissen, wie man einen File Transfer Protocol (FTP)-Server einrichtet. Mit Samba einen Datei- und Druckserver für &windows;-Clients konfigurieren können. Unter Nutzung des NTP-Protokolls Datum und Uhrzeit synchronisieren sowie einen Zeitserver installieren können. Wissen, wie man den Standard-Protokollierungsdienst, syslogd, konfiguriert, um Protokolle von anderen Hosts zu akzeptieren. Bevor Sie dieses Kapitel lesen, sollten Sie Die Grundlagen der /etc/rc-Skripte verstanden haben. Mit der grundlegenden Netzwerkterminologie vertraut sein. Wissen, wie man zusätzliche Softwarepakete von Drittherstellern installiert (). Der <application>inetd</application> <quote>Super-Server</quote> ChernLeeBeigetragen von &os; Documentation ProjectAktualisiert vom Überblick &man.inetd.8; wird manchmal auch als Internet Super-Server bezeichnet, weil er Verbindungen für mehrere Dienste verwaltet. Wenn eine Verbindung eintrifft, bestimmt inetd, welches Programm für die eingetroffene Verbindung zuständig ist, aktiviert den entsprechenden Prozess und reicht den Socket an ihn weiter (der Socket dient dabei als Standardein- und -ausgabe sowie zur Fehlerbehandlung). Der Einsatz des inetd-Daemons an Stelle viele einzelner Daemonen kann auf nicht komplett ausgelasteten Servern zu einer Verringerung der Systemlast führen. inetd wird vor allem dazu verwendet, andere Daemonen zu aktivieren, einige Protokolle werden aber auch direkt verwaltet. Dazu gehören chargen, auth, sowie daytime. Dieser Abschnitt beschreibt die Konfiguration von inetd durch Kommandozeilenoptionen sowie die Konfigurationsdatei /etc/inetd.conf. Einstellungen inetd wird durch das &man.rc.8;-System initialisiert. Die Option inetd_enable ist in der Voreinstellung zwar auf NO gesetzt, sie kann aber in Abhängigkeit von der vom Benutzer bei der Installation gewählten Konfiguration von sysinstall aktiviert werden. Die Verwendung von inetd_enable="YES" oder inetd_enable="NO" in /etc/rc.conf deaktiviert oder startet inetd beim Systemstart. Über den Befehl &prompt.root; /etc/rc.d/inetd rcvar können Sie die aktuelle Konfiguration abfragen. Weitere Optionen können über die Option inetd_flags an inetd übergeben werden. Kommandozeilenoptionen Wie die meisten anderen Server-Daemonen lässt sich auch inetd über verschiedene Optionen steuern. Eine vollständige Liste dieser Optionen finden Sie in der Manualpage von &man.inetd.8;. Die verschiedenen Optionen können über die Option inetd_flags der Datei /etc/rc.conf an inetd übergeben werden. In der Voreinstellung hat diese Option den Wert -wW -C 60. Durch das Setzen dieser Werte wird das TCP-Wrapping für alle inetd-Dienste aktiviert. Zusätzlich kann eine einzelne IP-Adresse jeden Dienst nur maximal 60 Mal pro Minute anfordern. Für Einsteiger ist es erfreulich, dass diese Parameter in der Regel nicht angepasst werden müssen. Da diese Parameter aber dennoch von Interesse sein können (beispielsweise, wenn Sie eine enorme Anzahl von Verbindungsanfragen erhalten), werden einige dieser einschränkenden Parameter im Folgenden näher erläutert. Eine vollständige Auflistung aller Optionen finden Sie hingegen in &man.inetd.8;. -c maximum Legt die maximale Anzahl von parallen Aufrufen eines Dienstes fest; in der Voreinstellung gibt es keine Einschränkung. Diese Einstellung kann für jeden Dienst durch Setzen des -Parameters festgelegt werden. -C rate Legt fest, wie oft ein Dienst von einer einzelnen IP-Adresse in einer Minute aufgerufen werden kann; in der Voreinstellung gibt es keine Einschränkung. Dieser Wert kann für jeden Dienst durch Setzen des Parameters festgelegt werden. -R rate Legt fest, wie oft ein Dienst in der Minute aktiviert werden kann; in der Voreinstellung sind dies 256 Aktivierungen pro Minute. Ein Wert von 0 erlaubt unbegrenzt viele Aktivierungen. -s maximum Legt fest, wie oft ein Dienst in der Minute von einer einzelnen IP-Adresse aus aktiviert werden kann; in der Voreinstellung gibt es hier keine Beschränkung. Diese Einstellung kann für jeden Dienst durch die Angabe angepasst werden. <filename>inetd.conf</filename> Die Konfiguration von inetd erfolgt über die Datei /etc/inetd.conf. Wenn /etc/inetd.conf geändert wird, kann inetd veranlasst werden, seine Konfigurationsdatei neu einzulesen. Die <application>inetd</application>-Konfiguration neu einlesen &prompt.root; /etc/rc.d/inetd reload Jede Zeile der Konfigurationsdatei beschreibt jeweils einen Daemon. Kommentare beginnen mit einem #. Ein Eintrag der Datei /etc/inetd.conf hat folgenden Aufbau: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments Ein Eintrag für den IPv4 verwendenden &man.ftpd.8;-Daemon könnte so aussehen: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name Der Dienstname eines bestimmten Daemons. Er muss einem in /etc/services aufgelisteten Dienst entsprechen. In dieser Datei wird festgelegt, welchen Port inetd abhören muss. Wenn ein neuer Dienst erzeugt wird, muss er zuerst in die Datei /etc/services eingetragen werden. socket-type Entweder stream, dgram, raw, oder seqpacket. stream muss für verbindungsorientierte TCP-Daemonen verwendet werden, während dgram das UDP-Protokoll verwaltet. protocol Eines der folgenden: Protokoll Bedeutung tcp, tcp4 TCP (IPv4) udp, udp4 UDP (IPv4) tcp6 TCP (IPv6) udp6 UDP (IPv6) tcp46 TCP sowohl unter IPv4 als auch unter IPv6 udp46 UDP sowohl unter IPv4 als auch unter IPv6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] gibt an, ob der von inetd aktivierte Daemon seinen eigenen Socket verwalten kann oder nicht. -Sockets müssen die Option verwenden, während Daemonen mit Stream-Sockets, die normalerweise auch aus mehreren Threads bestehen, die Option verwenden sollten. Die Option gibt in der Regel mehrere Sockets an einen einzelnen Daemon weiter, während für jeden neuen Socket einen Childdaemon erzeugt. Die maximale Anzahl an Child-Daemonen, die inetd erzeugen kann, wird durch die Option festgelegt. Wenn ein bestimmter Daemon 10 Instanzen benötigt, sollte der Wert /10 hinter die Option gesetzt werden. Geben Sie hingegen den Wert /0 an, gibt es keine Beschränkung. Zusätzlich zu kann die maximale Anzahl von Verbindungen eines Rechners mit einem bestimmten Daemon durch zwei weitere Optionen beschränkt werden. Die Option legt die maximale Anzahl von Verbindungsversuchen fest, die von einer bestimmten IP-Adresse aus unternommen werden können. Ein Wert von zehn würde die maximale Anzahl von Verbindungsversuchen einer IP-Adresse mit einem bestimmten Dienst auf zehn Versuche in der Minute beschränken. Durch die Angabe der Option können Sie hingegen festlegen, wie viele Child-Daemonen von einer bestimmten IP-Adresse aus gestartet werden können. Durch diese Optionen lassen sich ein absichtlicher oder unabsichtlicher Ressourcenverbrauch sowie die Auswirkungen eines Denial of Service (DoS)-Angriffs auf einen Rechner begrenzen. Sie müssen hier entweder oder angeben. Die Angabe von , und ist hingegen optional. Ein multithread-Daemon vom Streamtyp ohne die Optionen , oder sieht so aus: nowait Der gleiche Daemon mit einer maximal möglichen Anzahl von 10 parallelen Daemonen würde so aussehen: nowait/10 Wird zusätzlich die Anzahl der möglichen Verbindungen pro Minute für jede IP-Adresse auf 20 sowie die mögliche Gesamtzahl von Childdaemonen auf 10 begrenzt, so sieht der Eintrag so aus: nowait/10/20 All diese Optionen werden vom &man.fingerd.8;-Daemon bereits in der Voreinstellung verwendet: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Will man die maximale Anzahl von Child-Daemonen auf 100 beschränken, wobei von jeder IP-Adresse aus maximal 5 Child-Daemonen gestartet werden dürfen, verwendet man den folgenden Eintrag: nowait/100/0/5. user Der Benutzername, unter dem der jeweilige Daemon laufen soll. Meistens laufen Daemonen als User root. Aus Sicherheitsgründen laufen einige Server aber auch als User daemon, oder als am wenigsten privilegierter User nobody. server-program Der vollständige Pfad des Daemons, der eine Verbindung entgegennimmt. Wird der Daemon von inetd intern bereitgestellt, sollte die Option verwendet werden. server-program-arguments Dieser Eintrag legt (gemeinsam mit und beginnend mit argv[0]), die Argumente fest, die bei der Aktivierung an den Daemon übergeben werden. Wenn die Anweisung auf der Kommandozeile also mydaemon -d lautet, wäre mydaemon -d auch der Wert der Option . Wenn es sich beim Daemon um einen internen Dienst handelt, sollte wiederum die Option verwendet werden. Sicherheit Abhängig von der bei der Installation festgelegten Konfiguration werden viele der von inetd verwalteten Dienste automatisch aktiviert! Wenn Sie einen bestimmten Daemon nicht benötigen, sollten Sie ihn deaktivieren! Dazu kommentieren Sie den jeweiligen Daemon in /etc/inetd.conf mit einem # aus, um danach die inetd-Konfiguration neu einzulesen. Einige Daemonen, zum Beispiel fingerd, sollten generell deaktiviert werden, da sie zu viele Informationen an einen potentiellen Angreifer liefern. Einige Daemonen haben unsichere Einstellungen, etwa große oder nichtexistierende Timeouts für Verbindungsversuche, die es einem Angreifer erlauben, über lange Zeit langsam Verbindungen zu einem bestimmten Daemon aufzubauen, um dessen verfügbare Ressourcen zu verbrauchen. Es ist daher eine gute Idee, diese Daemonen durch die Optionen , sowie zu beschränken, wenn Sie sehr viele Verbindungsversuche mit Ihrem System registrieren. TCP-Wrapping ist in der Voreinstellung aktiviert. Lesen Sie &man.hosts.access.5;, wenn Sie weitere Informationen zum Setzen von TCP-Beschränkungen für verschiedene von inetd aktivierte Daemonen benötigen. Verschiedenes Bei daytime, time, echo, discard, chargen, und auth handelt es sich um intern von inetd bereitgestellte Dienste. Der auth-Dienst bietet Identifizierungsdienste über das Netzwerk an und ist bis zu einem bestimmten Grad konfigurierbar, während die meisten anderen Dienste nur aktiviert oder deaktiviert werden können. Eine ausführliche Beschreibung finden Sie in &man.inetd.8;. NFS – Network File System TomRhodesReorganisiert und erweitert von BillSwingleGeschrieben von NFS Eines der vielen von FreeBSD unterstützten Dateisysteme ist das Netzwerkdateisystem, das auch als NFS bekannt ist. NFS ermöglicht es einem System, Dateien und Verzeichnisse über ein Netzwerk mit anderen zu teilen. Über NFS können Benutzer und Programme auf Daten entfernter Systeme zugreifen, und zwar genauso, wie wenn es sich um lokale Daten handeln würde. Einige der wichtigsten Vorteile von NFS sind: Lokale Arbeitsstationen benötigen weniger Plattenplatz, da gemeinsam benutzte Daten nur auf einem einzigen Rechner vorhanden sind. Alle anderen Stationen greifen über das Netzwerk auf diese Daten zu. Benutzer benötigen nur noch ein zentrales Heimatverzeichnis auf einem NFS-Server. Diese Verzeichnisse sind über das Netzwerk auf allen Stationen verfügbar. Speichergeräte wie Disketten-, CD-ROM- oder &iomegazip;-Laufwerke können über das Netzwerk von anderen Arbeitstationen genutzt werden. Dadurch sind für das gesamte Netzwerk deutlich weniger Speichergeräte nötig. Wie funktioniert <acronym>NFS</acronym>? NFS besteht aus zwei Hauptteilen: Einem Server und einem oder mehreren Clients. Der Client greift über das Netzwerk auf die Daten zu, die auf dem Server gespeichert sind. Damit dies korrekt funktioniert, müssen einige Prozesse konfiguriert und gestartet werden: Der Server benötigt folgende Daemonen: NFS Server Dateiserver Unix-Clients rpcbind mountd nfsd Daemon Beschreibung nfsd Der NFS-Daemon. Er bearbeitet Anfragen der NFS-Clients. mountd Der NFS-Mount-Daemon. Er bearbeitet die Anfragen, die &man.nfsd.8; an ihn weitergibt. rpcbind Der Portmapper-Daemon. Durch ihn erkennen die NFS-Clients, welchen Port der NFS-Server verwendet. Der Client kann ebenfalls einen Daemon aufrufen, und zwar den nfsiod-Daemon. Der nfsiod-Daemon bearbeitet Anfragen vom NFS-Server. Er ist optional und verbessert die Leistung des Netzwerks. Für eine normale und korrekte Arbeit ist er allerdings nicht erforderlich. Mehr erfahren Sie in der Hilfeseite &man.nfsiod.8;. <acronym>NFS</acronym> einrichten NFS einrichten NFS lässt sich leicht einrichten. Die nötigen Prozesse werden durch einige Änderungen in /etc/rc.conf bei jedem Systemstart gestartet. Stellen Sie sicher, dass auf dem NFS-Server folgende Optionen in der Datei /etc/rc.conf gesetzt sind: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd läuft automatisch, wenn der NFS-Server aktiviert ist. Auf dem Client muss in /etc/rc.conf folgende Option gesetzt sein: nfs_client_enable="YES" /etc/exports legt fest, welche Dateisysteme NFS exportieren (manchmal auch als teilen bezeichnet) soll. Jede Zeile in /etc/exports legt ein Dateisystem sowie die Arbeitsstationen, die darauf Zugriff haben, fest. Außerdem ist es möglich, Zugriffsoptionen festzulegen. Es gibt viele verschiedene Optionen, allerdings werden hier nur einige von ihnen erwähnt. Wenn Sie Informationen zu weiteren Optionen benötigen, lesen Sie &man.exports.5;. Nun folgen einige Beispieleinträge für /etc/exports: NFS Export von Dateisystemen Die folgenden Beispiele geben Ihnen Anhaltspunkte zum Exportieren von Dateisystemen, obwohl diese Einstellungen natürlich von Ihrer Arbeitsumgebung und Ihrer Netzwerkkonfiguration abhängen. Das nächste Beispiel exportiert das Verzeichnis /cdrom für drei Rechner, die sich in derselben Domäne wie der Server befinden oder für die entsprechende Einträge in /etc/hosts existieren. Die Option kennzeichnet das exportierte Dateisystem als schreibgeschützt. Durch dieses Flag ist das entfernte System nicht in der Lage, das exportierte Dateisystem zu verändern. /cdrom -ro host1 host2 host3 Die nächste Zeile exportiert /home auf drei durch IP-Adressen bestimmte Rechner. Diese Einstellung ist nützlich, wenn Sie über ein privates Netzwerk ohne DNS-Server verfügen. Optional könnten interne Rechnernamen auch in /etc/hosts konfiguriert werden. Benötigen Sie hierzu weitere Informationen, lesen Sie bitte &man.hosts.5;. Durch das Flag wird es möglich, auch Unterverzeichnisse als Mountpunkte festzulegen. Dies bedeutet aber nicht, dass alle Unterverzeichnisse eingehängt werden, vielmehr wird es dem Client ermöglicht, nur diejenigen Verzeichnisse einzuhängen, die auch benötigt werden. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 Die nächste Zeile exportiert /a, damit Clients von verschiedenen Domänen auf das Dateisystem zugreifen können. Das -Flag erlaubt es dem Benutzer root des entfernten Systems, als root auf das exportierte Dateisystem zu schreiben. Wenn dieses Flag nicht gesetzt ist, kann selbst root nicht auf das exportierte Dateisystem schreiben. /a -maproot=root host.example.com box.example.org Damit ein Client auf ein exportiertes Dateisystem zugreifen kann, muss ihm dies explizit gestattet werden. Stellen Sie also sicher, dass der Client in /etc/exports aufgeführt wird. Jede Zeile in /etc/exports entspricht der Exportinformation für ein Dateisystem auf einen Rechner. Ein entfernter Rechner kann für jedes Dateisystem nur einmal festgelegt werden, und kann auch nur einen Standardeintrag haben. Nehmen wir an, dass /usr ein einziges Dateisystem ist. Dann wären folgende Zeilen ungültig: #Nicht erlaubt, wenn /usr ein einziges Dateisystem ist /usr/src client /usr/ports client Das Dateisystem /usr wird hier zweimal auf den selben Rechner (client) exportiert. Dies ist aber nicht zulässig. Der korrekte Eintrag sieht daher so aus: /usr/src /usr/ports client Die Eigenschaften eines auf einen anderen Rechner exportierten Dateisystems müssen alle in einer Zeile stehen. Zeilen, in denen kein Rechner festgelegt wird, werden als einzelner Rechner behandelt. Dies schränkt die Möglichkeiten zum Export von Dateisystemen ein, für die meisten Anwender ist dies aber kein Problem. Eine gültige Exportliste, in der /usr und /exports lokale Dateisysteme sind, sieht so aus: # Export src and ports to client01 and client02, but only # client01 has root privileges on it /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # The client machines have root and can mount anywhere # on /exports. Anyone in the world can mount /exports/obj read-only /exports -alldirs -maproot=root client01 client02 /exports/obj -ro Der Daemon mountd muss die Datei /etc/exports nach jeder Änderung neu einlesen, damit die Änderungen wirksam werden. Dies kann durch das Senden des HUP-Signals an den mountd-Prozess erfolgen: &prompt.root; kill -HUP `cat /var/run/mountd.pid` Alternativ können Sie das mountd-&man.rc.8;-Skript auch mit dem passenden Parameter aufrufen: &prompt.root; /etc/rc.d/mountd onereload Lesen Sie bitte des Handbuchs für Informationen zum Einsatz der rc-Skripte. Eine weitere Möglichkeit, diese Änderungen zu übernehmen, wäre der Neustart des Systems. Dies ist allerdings nicht nötig. Wenn Sie die folgenden Befehle als root ausführen, sollte alles korrekt gestartet werden. Auf dem NFS-Server: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Auf dem NFS-Client: &prompt.root; nfsiod -n 4 Nun sollte alles bereit sein, um ein entferntes Dateisystem einhängen zu können. In unseren Beispielen nennen wir den Server server, den Client client. Wenn Sie ein entferntes Dateisystem nur zeitweise einhängen wollen, oder nur Ihre Konfiguration testen möchten, führen Sie auf dem Client als root einen Befehl ähnlich dem folgenden aus: NFS Dateisysteme einhängen &prompt.root; mount server:/home /mnt Dadurch wird das Verzeichnis /home des Servers auf dem Client unter /mnt eingehängt. Wenn alles korrekt konfiguriert wurde, sehen Sie auf dem Client im Verzeichnis /mnt alle Dateien des Servers. Wenn Sie ein entferntes Dateisystem nach jedem Systemstart automatisch einhängen wollen, fügen Sie das Dateisystem in /etc/fstab ein. Dazu ein Beispiel: server:/home /mnt nfs rw 0 0 Eine Beschreibung aller Optionen enthält die Hilfeseite &man.fstab.5;. Dateien sperren (<foreignphrase>Locking</foreignphrase>) Einige Anwendungen (beispielsweise mutt) erfordern die Sperrung von Dateien, damit sie korrekt arbeiten. Verwenden Sie NFS, so können Sie für die Sperrung von Dateien rpc.lockd einsetzen. Um diesen Daemon zu aktivieren, müssen Sie in /etc/rc.conf (sowohl auf Client- als auch auf Serverseite) folgende Zeilen aufnehmen (wobei vorausgesetzt wird, dasss NFS auf beiden Systemen bereits konfiguriert ist): rpc_lockd_enable="YES" rpc_statd_enable="YES" Danach starten Sie die Anwendung zur Verwaltung der Dateisperren durch folgenden Befehl: &prompt.root; /etc/rc.d/lockd start &prompt.root; /etc/rc.d/statd start Benötigen Sie keine echten Dateisperren zwischen den NFS-Clients und dem NFS-Server, können Sie den NFS-Client durch die Übergabe der Option an &man.mount.nfs.8; zu einer lokalen Sperrung von Dateien zwingen. Lesen Sie dazu auch die Manualpage &man.mount.nfs.8;. Praktische Anwendungen NFS ist in vielen Situationen nützlich. Einige Anwendungsbereiche finden Sie in der folgenden Liste: NFS Anwendungsbeispiele Mehrere Maschinen können sich ein CD-ROM-Laufwerk oder andere Medien teilen. Dies ist billiger und außerdem praktischer, um Programme auf mehreren Rechnern zu installieren. In größeren Netzwerken ist es praktisch, einen zentralen NFS-Server einzurichten, auf dem die Heimatverzeichnisse der Benutzer gespeichert werden. Diese Heimatverzeichnisse werden über das Netzwerk exportiert. Dadurch haben die Benutzer immer das gleiche Heimatverzeichnis zur Verfügung, unabhängig davon, an welchem Arbeitsplatz sie sich anmelden. Verschiedene Rechner können auf ein gemeinsames Verzeichnis /usr/ports/distfiles zugreifen. Wenn Sie nun einen Port auf mehreren Rechnern installieren wollen, greifen Sie einfach auf dieses Verzeichnis zu, ohne die Quelldateien auf jede Maschine zu kopieren. <application>AMD</application> WylieStilwellBeigetragen von ChernLeeÜberarbeitet von amd Automatic Mounter Daemon &man.amd.8; (Automatic Mounter Daemon) hängt ein entferntes Dateisystem automatisch ein, wenn auf eine Datei oder ein Verzeichnis in diesem Dateisystem zugegriffen wird. Dateisysteme, die über einen gewissen Zeitraum inaktiv sind, werden von amd automatisch abgehängt. amd ist eine einfache Alternative zum dauerhaften Einhängen von Dateisystemen in /etc/fstab. In der Voreinstellung stellt amd die Verzeichnisse /host und /net als NFS-Server bereit. Wenn auf eine Datei in diesen Verzeichnissen zugegriffen wird, sucht amd den entsprechenden Mountpunkt und hängt das Dateisystem automatisch ein. /net wird zum Einhängen von exportierten Dateisystemen von einer IP-Adresse verwendet, während /host zum Einhängen von exportierten Dateisystemen eines durch seinen Namen festgelegten Rechners dient. Ein Zugriff auf eine Datei in /host/foobar/usr würde amd veranlassen, das von foobar exportierte Dateisystem /usr einzuhängen. Ein exportiertes Dateisystem mit <application>amd</application> in den Verzeichnisbaum einhängen Sie können sich die verfügbaren Mountpunkte eines entfernten Rechners mit showmount ansehen. Wollen Sie sich die Mountpunkte des Rechners foobar ansehen, so verwenden Sie: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Wie Sie an diesem Beispiel erkennen können, zeigt showmount /usr als exportiertes Dateisystem an. Wenn man in das Verzeichnis /host/foobar/usr wechselt, versucht amd den Rechnernamen foobar aufzulösen und den gewünschten Export in den Verzeichnisbaum einzuhängen. amd kann durch das Einfügen der folgenden Zeile in /etc/rc.conf automatisch gestartet werden: amd_enable="YES" Mit der Option amd_flags kann amd angepasst werden. Die Voreinstellung für amd_flags sieht so aus: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" /etc/amd.map legt die Standardoptionen fest, mit denen exportierte Dateisysteme in den Verzeichnisbaum eingehängt werden. /etc/amd.conf hingegen legt einige der erweiterten Optionen von amd fest. Weitere Informationen finden Sie in den Hilfeseiten &man.amd.8; und &man.amd.conf.5;. Integrationsprobleme mit anderen Systemen JohnLindBeigetragen von Bestimmte ISA-Ethernetadapter haben Beschränkungen, die zu ernsthaften Netzwerkproblemen, insbesondere mit NFS führen können. Es handelt sich dabei nicht um ein FreeBSD-spezifisches Problem, aber FreeBSD-Systeme sind davon ebenfalls betroffen. Das Problem tritt fast ausschließlich dann auf, wenn (FreeBSD)-PC-Systeme mit Hochleistungsrechnern verbunden werden, wie Systemen von Silicon Graphics, Inc. oder Sun Microsystems, Inc. Das Einhängen via NFS funktioniert problemlos, auch einige Dateioperationen können erfolgreich sein. Plötzlich aber wird der Server nicht mehr auf den Client reagieren, obwohl Anfragen von anderen Rechnern weiterhin bearbeitet werden. Dieses Problem betrifft stets den Client, egal ob es sich beim Client um das FreeBSD-System oder den Hochleistungsrechner handelt. Auf vielen Systemen gibt es keine Möglichkeit mehr, den Client ordnungsgemäß zu beenden. Die einzige Lösung ist es oft, den Rechner neu zu starten, da dieses NFS-Problem nicht mehr behoben werden kann. Die korrekte Lösung für dieses Problem ist es, sich eine schnellere Ethernetkarte für FreeBSD zu kaufen. Allerdings gibt es auch eine einfache und meist zufriedenstellende Lösung, um dieses Problem zu umgehen. Wenn es sich beim FreeBSD-System um den Server handelt, verwenden Sie beim Einhängen in den Verzeichnisbaum auf der Clientseite zusätzlich die Option . Wenn es sich beim FreeBSD-System um den Client handelt, dann hängen Sie das NFS-Dateisystem mit der zusätzlichen Option ein. Diese Optionen können auf der Clientseite auch durch das vierte Feld der Einträge in /etc/fstab festgelegt werden, damit die Dateisysteme automatisch eingehängt werden. Um die Dateisysteme manuell einzuhängen, verwendet man bei &man.mount.8; zusätzlich die Option . Es gibt ein anderes Problem, das oft mit diesem verwechselt wird. Dieses andere Problem tritt auf, wenn sich über NFS verbundene Server und Clients in verschiedenen Netzwerken befinden. Wenn dies der Fall ist, stellen Sie sicher, dass Ihre Router die nötigen UDP-Informationen weiterleiten, oder Sie werden nirgends hingelangen, egal was Sie machen. In den folgenden Beispielen ist fastws der Name des Hochleistungsrechners (bzw. dessen Schnittstelle), freebox hingegen ist der Name des FreeBSD-Systems, das über eine Netzkarte mit geringer Leistung verfügt. /sharedfs ist das exportierte NFS -Dateisystem (lesen Sie dazu auch &man.exports.5;). Bei /project handelt es sich um den Mountpunkt, an dem das exportierte Dateisystem auf der Clientseite eingehängt wird. In allen Fällen können zusätzliche Optionen, wie z.B. , oder wünschenswert sein. FreeBSD als Client (eingetragen in /etc/fstab auf freebox): fastws:/sharedfs /project nfs rw,-r=1024 0 0 Manuelles Einhängen auf freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project &os; als Server (eingetragen in /etc/fstab auf fastws): freebox:/sharedfs /project nfs rw,-w=1024 0 0 Manuelles Einhängen auf fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Nahezu alle 16-bit Ethernetadapter erlauben Operationen ohne obengenannte Einschränkungen auf die Lese- oder Schreibgröße. Für alle technisch Interessierten wird nun beschrieben, was passiert, wenn dieser Fehler auftritt, und warum er irreversibel ist. NFS arbeitet üblicherweise mit einer Blockgröße von 8 kByte (obwohl es kleinere Fragmente zulassen würde). Da die maximale Rahmengröße von Ethernet 1500 Bytes beträgt, wird der NFS-Block in einzelne Ethernetrahmen aufgeteilt, obwohl es sich nach wie vor um eine Einheit handelt, die auch als Einheit empfangen, verarbeitet und bestätigt werden muss. Der Hochleistungsrechner verschickt die Pakete, aus denen der NFS-Block besteht, so eng hintereinander, wie es der Standard erlaubt. Auf der anderen Seite (auf der sich die langsamere Netzkarte befindet), überschreiben die späteren Pakete ihre Vorgänger, bevor diese vom System verarbeitet werden (Überlauf!). Dies hat zur Folge, dass der NFS-Block nicht mehr rekonstruiert und bestätigt werden kann. Als Folge davon glaubt der Hochleistungsrechner, dass der andere Rechner nicht erreichbar ist (Timeout!) und versucht die Sendung zu wiederholen. Allerdings wird wiederum der komplette NFS-Block verschickt, so dass sich der ganze Vorgang wiederholt, und zwar immer wieder (oder bis zum Systemneustart). Indem wir die Einheitengröße unter der maximalen Größe der Ethernetpakete halten, können wir sicherstellen, dass jedes vollständig erhaltene Ethernetpaket individuell angesprochen werden kann und vermeiden die Blockierung des Systems. Überläufe können zwar nach wie vor auftreten, wenn ein Hochleistungsrechner Daten auf ein PC-System transferiert. Durch die besseren (und schnelleren) Netzkarten treten solche Überläufe allerdings nicht mehr zwingend auf, wenn NFS-Einheiten übertragen werden. Tritt nun ein Überlauf auf, wird die betroffene Einheit erneut verschickt, und es besteht eine gute Chance, dass sie nun erhalten, verarbeitet und bestätigt werden kann. NIS/YP – Network Information Service BillSwingleBeigetragen von EricOgrenErweitert von UdoErdelhoff Was ist NIS? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS wurde von Sun Microsystems entwickelt, um &unix;-Systeme (ursprünglich &sunos;) zentral verwalten zu können. Mittlerweile hat es sich zu einem Industriestandard entwickelt, der von allen wichtigen &unix;-Systemen (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, FreeBSD und anderen) unterstützt wird. yellow pages NIS NIS war ursprünglich als Yellow Pages bekannt, aus markenrechtlichen Gründen wurde der Name aber geändert. Die alte Bezeichnung (sowie die Abkürzung YP) wird aber nach wie vor häufig verwendet. NIS Domänen Bei NIS handelt es sich um ein RPC-basiertes Client/Server-System. Eine Gruppe von Rechnern greift dabei innerhalb einer NIS-Domäne auf gemeinsame Konfigurationsdateien zu. Ein Systemadministrator wird dadurch in die Lage versetzt, NIS-Clients mit minimalem Aufwand einzurichten, sowie Änderungen an der Systemkonfiguration von einem zentralen Ort aus durchzuführen. Windows NT Die Funktion entspricht dem Domänensystem von &windowsnt;; auch wenn sich die interne Umsetzung unterscheidet, sind die Basisfunktionen vergleichbar. Wichtige Prozesse und Begriffe Es gibt verschiedene Begriffe und Anwenderprozesse, auf die Sie stoßen werden, wenn Sie NIS unter FreeBSD einrichten, egal ob Sie einen Server oder einen Client konfigurieren: rpcbind Begriff Beschreibung NIS-Domänenname Ein NIS-Masterserver sowie alle Clients (inklusive der Slaveserver) haben einen NIS-Domänennamen. Dieser hat (ähnlich den &windowsnt;-Domänennamen) nichts mit DNS zu tun. rpcbind Muss laufen, damit RPC (Remote Procedure Call, ein von NIS verwendetes Netzwerkprotokoll) funktioniert. NIS-Server sowie Clients funktionieren ohne rpcbind nicht. ypbind Bindet einen NIS-Client an seinen NIS-Server. Der Client bezieht den NIS-Domänennamen vom System und stellt über das RPC-Protokoll eine Verbindung zum NIS-Server her. ypbind ist der zentrale Bestandteil der Client-Server-Kommunikation in einer NIS-Umgebung. Wird >ypbind auf einem Client beendet, ist dieser nicht mehr in der Lage, auf den NIS-Server zuzugreifen. ypserv Sollte nur auf dem NIS-Server laufen, da es sich um den Serverprozess selbst handelt. Wenn &man.ypserv.8; nicht mehr läuft, kann der Server nicht mehr auf NIS-Anforderungen reagieren (wenn ein Slaveserver existiert, kann dieser als Ersatz fungieren). Einige NIS-Systeme (allerdings nicht das von FreeBSD) versuchen allerdings erst gar nicht, sich mit einem anderen Server zu verbinden, wenn der bisher verwendete Server nicht mehr reagiert. Die einzige Lösung dieses Problems besteht dann darin, den Serverprozess (oder gar den Server selbst) oder den ypbind-Prozess auf dem Client neu zu starten. rpc.yppasswdd Ein weiterer Prozess, der nur auf dem NIS-Masterserver laufen sollte. Es handelt sich um einen Daemonprozess, der es NIS-Clients ermöglicht, sich auf dem NIS-Masterserver anzumelden, um ihr Passwort zu ändern. Wie funktioniert NIS? In einer NIS-Umgebung gibt es drei Rechnerarten: Masterserver, Slaveserver und Clients. Server dienen als zentraler Speicherort für Rechnerkonfigurationen. Masterserver speichern die maßgebliche Kopie dieser Informationen, während Slaveserver diese Informationen aus Redundanzgründen spiegeln. Die Clients beziehen ihre Informationen immer vom Server. Auf diese Art und Weise können Informationen aus verschiedenen Dateien von mehreren Rechnern gemeinsam verwendet werden. master.passwd, group, und hosts werden oft gemeinsam über NIS verwendet. Immer, wenn ein Prozess auf einem Client auf Informationen zugreifen will, die normalerweise in lokalen Dateien vorhanden wären, wird stattdessen eine Anfrage an den NIS-Server gestellt, an den der Client gebunden ist. Arten von NIS-Rechnern NIS Masterserver Ein NIS-Masterserver verwaltet, ähnlich einem &windowsnt;-Domänencontroller, die von allen NIS-Clients gemeinsam verwendeten Dateien. passwd, group, sowie verschiedene andere von den Clients verwendete Dateien existieren auf dem Masterserver. Ein Rechner kann auch für mehrere NIS-Domänen als Masterserver fungieren. Dieser Abschnitt konzentriert sich im Folgenden allerdings auf eine relativ kleine NIS-Umgebung. NIS Slaveserver NIS-Slaveserver. Ähnlich einem &windowsnt;-Backupdomänencontroller, verwalten NIS-Slaveserver Kopien der Daten des NIS-Masterservers. NIS-Slaveserver bieten die Redundanz, die für kritische Umgebungen benötigt wird. Zusätzlich entlasten Slaveserver den Masterserver: NIS-Clients verbinden sich immer mit dem NIS-Server, der zuerst reagiert. Dieser Server kann auch ein Slaveserver sein. NIS Client NIS-Clients. NIS-Clients identifizieren sich gegenüber dem NIS-Server (ähnlich den &windowsnt;-Workstations), um sich am Server anzumelden. NIS/YP konfigurieren Dieser Abschnitt beschreibt an Hand eines Beispiels die Einrichtung einer NIS-Umgebung. Planung Nehmen wir an, Sie seien der Administrator eines kleinen Universitätsnetzes. Dieses Netz besteht aus fünfzehn FreeBSD-Rechnern, für die derzeit keine zentrale Verwaltung existiert, jeder Rechner hat also eine eigene Version von /etc/passwd und /etc/master.passwd. Diese Dateien werden manuell synchron gehalten; legen Sie einen neuen Benutzer an, so muss dies auf allen fünfzehn Rechnern manuell erledigt werden (unter Verwendung von adduser). Da diese Lösung sehr ineffizient ist, soll das Netzwerk in Zukunft NIS verwenden, wobei zwei der Rechner als Server dienen sollen. In Zukunft soll das Netz also wie folgt aussehen: Rechnername IP-Adresse Rechneraufgabe ellington 10.0.0.2 NIS-Master coltrane 10.0.0.3 NIS-Slave basie 10.0.0.4 Workstation der Fakultät bird 10.0.0.5 Clientrechner cli[1-11] 10.0.0.[6-17] Verschiedene andere Clients Wenn Sie NIS das erste Mal einrichten, ist es ratsam, sich zuerst über die Vorgangsweise Gedanken zu machen. Unabhängig von der Größe Ihres Netzwerks müssen Sie stets einige Entscheidungen treffen. Einen NIS-Domänennamen wählen NIS Domänenname Dies muss nicht der Domainname sein. Es handelt sich vielmehr um den NIS-Domainnamen. Wenn ein Client Informationen anfordert, ist in dieser Anforderung der Name der NIS-Domäne enthalten. Dadurch weiß jeder Server im Netzwerk, auf welche Anforderung er antworten muss. Stellen Sie sich den NIS-Domänennamen als den Namen einer Gruppe von Rechnern vor, die etwas gemeinsam haben. Manchmal wird der Name der Internetdomäne auch für die NIS-Domäne verwendet. Dies ist allerdings nicht empfehlenswert, da dies bei der Behebung von Problemen verwirrend sein kann. Der Name der NIS-Domäne sollte innerhalb Ihres Netzwerks einzigartig sein. Hilfreich ist es, wenn der Name die Gruppe der in ihr zusammengefassten Rechner beschreibt. Die Kunstabteilung von Acme Inc. hätte daher die NIS-Domäne acme-art. Für unser Beispiel verwenden wir den NIS-Domänennamen test-domain. SunOS Es gibt jedoch auch Betriebssysteme (vor allem &sunos;), die als NIS-Domänennamen den Name der Internetdomäne verwenden. Wenn dies für einen oder mehrere Rechner Ihres Netzwerks zutrifft, müssen Sie den Namen der Internetdomäne als Ihren NIS-Domänennamen verwenden. Anforderungen an den Server Wenn Sie einen NIS-Server einrichten wollen, müssen Sie einige Dinge beachten. Eine unangenehme Eigenschaft von NIS ist die Abhängigkeit der Clients vom Server. Wenn sich der Client nicht über den Server mit seiner NIS-Domäne verbinden kann, wird der Rechner oft unbenutzbar, da das Fehlen von Benutzer- und Gruppeninformationen zum Einfrieren des Clients führt. Daher sollten Sie für den Server einen Rechner auswählen, der nicht regelmäßig neu gestartet werden muss und der nicht für Testversuche verwendet wird. Idealerweise handelt es sich um einen alleinstehenden Rechner, dessen einzige Aufgabe es ist, als NIS-Server zu dienen. Wenn Sie ein Netzwerk haben, das nicht zu stark ausgelastet ist, ist es auch möglich, den NIS-Server als weiteren Dienst auf einem anderen Rechner laufen zu lassen. Denken Sie aber daran, dass ein Ausfall des NIS-Servers alle NIS-Clients betrifft. NIS-Server Die verbindlichen Kopien aller NIS-Informationen befinden sich auf einem einzigen Rechner, dem NIS-Masterserver. Die Datenbanken, in denen die Informationen gespeichert sind, bezeichnet man als NIS-Maps. Unter FreeBSD werden diese Maps unter /var/yp/[domainname] gespeichert, wobei [domainname] der Name der NIS-Domäne ist. Ein einzelner NIS-Server kann gleichzeitig mehrere NIS-Domänen verwalten, daher können auch mehrere Verzeichnisse vorhanden sein. Jede Domäne verfügt über ein eigenes Verzeichnis sowie einen eigenen, von anderen Domänen unabhängigen Satz von NIS-Maps. NIS-Master- und Slaveserver verwenden den ypserv-Daemon, um NIS-Anfragen zu bearbeiten. ypserv empfängt eingehende Anfragen der NIS-Clients, ermittelt aus der angeforderten Domäne und Map einen Pfad zur entsprechenden Datenbank, und sendet die angeforderten Daten von der Datenbank zum Client. Einen NIS-Masterserver einrichten NIS Serverkonfiguration Abhängig von Ihren Anforderungen ist die Einrichtung eines NIS-Masterservers relativ einfach, da NIS von FreeBSD bereits in der Standardkonfiguration unterstützt wird. Sie müssen nur folgende Zeilen in /etc/rc.conf einfügen: nisdomainname="test-domain" Diese Zeile setzt den NIS-Domänennamen auf test-domain, wenn Sie das Netzwerk initialisieren (beispielsweise nach einem Systemstart). nis_server_enable="YES" Dadurch werden die NIS-Serverprozesse gestartet. nis_yppasswdd_enable="YES" Durch diese Zeile wird der rpc.yppasswdd-Daemon aktiviert, der, wie bereits erwähnt, die Änderung von NIS-Passwörtern von einem Client aus ermöglicht. In Abhängigkeit von Ihrer NIS-Konfiguration können weitere Einträge erforderlich sein. Weitere Informationen finden Sie im Abschnitt NIS-Server, die auch als NIS-Clients arbeiten. Nachdem Sie obige Parameter konfiguriert haben, müssen Sie nur noch /etc/netstart als Superuser ausführen, um alles entsprechend Ihren Vorgaben in der Datei /etc/rc.conf einzurichten. Bevor Sie die NIS-Maps einrichten können, müssen Sie nun noch den ypserv-Daemon manuell starten: &prompt.root; /etc/rc.d/ypserv start Die NIS-Maps initialisieren NIS maps NIS-Maps sind Datenbanken, die sich im Verzeichnis /var/yp befinden. Sie werden am NIS-Masterserver aus den Konfigurationsdateien unter /etc erzeugt. Einzige Ausnahme: /etc/master.passwd. Dies ist auch sinnvoll, da Sie die Passwörter für Ihr root- oder andere Administratorkonten nicht an alle Server der NIS-Domäne verteilen wollen. Bevor Sie also die NIS-Maps des Masterservers einrichten, sollten Sie Folgendes tun: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Entfernen Sie alle Systemkonten (wie bin, tty, kmem oder games), sowie alle Konten, die Sie nicht an die NIS-Clients weitergeben wollen (beispielsweise root und alle Konten mit der UID 0 (=Superuser). Stellen Sie sicher, dass /var/yp/master.passwd weder von der Gruppe noch von der Welt gelesen werden kann (Zugriffsmodus 600)! Ist dies nicht der Fall, ändern Sie dies mit chmod. Tru64 UNIX Nun können Sie die NIS-Maps initialisieren. FreeBSD verwendet dafür das Skript ypinit (lesen Sie dazu auch &man.ypinit.8;). Dieses Skript ist auf fast allen UNIX-Betriebssystemen verfügbar. Bei Digitals Unix/Compaq Tru64 UNIX nennt es sich allerdings ypsetup. Da wir Maps für einen NIS-Masterserver erzeugen, verwenden wir ypinit mit der Option . Nachdem Sie die beschriebenen Aktionen durchgeführt haben, erzeugen Sie nun die NIS-Maps: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..output from map generation..] NIS Map update completed. ellington has been setup as an YP master server without any errors. Dadurch erzeugt ypinit /var/yp/Makefile aus der Datei /var/yp/Makefile.dist. Durch diese Datei wird festgelegt, dass Sie in einer NIS-Umgebung mit nur einem Server arbeiten und dass alle Clients unter FreeBSD laufen. Da test-domain aber auch über einen Slaveserver verfügt, müssen Sie /var/yp/Makefile entsprechend anpassen: ellington&prompt.root; vi /var/yp/Makefile Sie sollten die Zeile NOPUSH = "True" auskommentieren (falls dies nicht bereits der Fall ist). Einen NIS-Slaveserver einrichten NIS Slaveserver Ein NIS-Slaveserver ist noch einfacher einzurichten als ein Masterserver. Melden Sie sich am Slaveserver an und ändern Sie /etc/rc.conf analog zum Masterserver. Der einzige Unterschied besteht in der Verwendung der Option , wenn Sie ypinit aufrufen. Die Option erfordert den Namen des NIS-Masterservers, daher sieht unsere Ein- und Ausgabe wie folgt aus: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Sie sollten nun über das Verzeichnis /var/yp/test-domain verfügen. Die Kopien der NIS-Masterserver-Maps sollten sich in diesem Verzeichnis befinden. Allerdings müssen Sie diese auch aktuell halten. Die folgenden Einträge in /etc/crontab erledigen diese Aufgabe: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Diese zwei Zeilen zwingen den Slaveserver, seine Maps mit denen des Masterservers zu synchronisieren. Diese Einträge sind nicht zwar nicht unbedingt nötig, da der Masterserver automatisch versucht, alle Änderungen seiner NIS-Maps an seine Slaveserver weiterzugeben. Da Passwortinformationen aber auch für nur vom Slaveserver abhängige Systeme vital sind, ist es eine gute Idee, diese Aktualisierungen zu erzwingen. Besonders wichtig ist dies in stark ausgelasteten Netzen, in denen Map-Aktualisierungen unvollständig sein könnten. Führen Sie nun /etc/netstart auch auf dem Slaveserver aus, um den NIS-Server erneut zu starten. NIS-Clients Ein NIS-Client bindet sich unter Verwendung des ypbind-Daemons an einen NIS-Server. ypbind prüft die Standarddomäne des Systems (die durch domainname gesetzt wird), und beginnt RPCs über das lokale Netzwerk zu verteilen (broadcast). Diese Anforderungen legen den Namen der Domäne fest, für die ypbind eine Bindung erzeugen will. Wenn der Server der entsprechenden Domäne eine solche Anforderung erhält, schickt er eine Antwort an ypbind. ybind speichert daraufhin die Adresse des Servers. Wenn mehrere Server verfügbar sind (beispielsweise ein Master- und mehrere Slaveserver), verwendet ypbind die erste erhaltene Adresse. Ab diesem Zeitpunkt richtet der Client alle Anfragen an genau diesen Server. ypbind pingt den Server gelegentlich an, um sicherzustellen, dass der Server funktioniert. Antwortet der Server innerhalb eines bestimmten Zeitraums nicht (Timeout), markiert ypbind die Domäne als ungebunden und beginnt erneut, RPCs über das Netzwerk zu verteilen, um einen anderen Server zu finden. Einen NIS-Client konfigurieren NIS Client konfigurieren Einen FreeBSD-Rechner als NIS-Client einzurichten, ist recht einfach. Fügen Sie folgende Zeilen in /etc/rc.conf ein, um den NIS-Domänennamen festzulegen, und um ypbind bei der Initialisierung des Netzwerks zu starten: nisdomainname="test-domain" nis_client_enable="YES" Um alle Passworteinträge des NIS-Servers zu importieren, löschen Sie alle Benutzerkonten in /etc/master.passwd und fügen mit vipw folgende Zeile am Ende der Datei ein: +::::::::: Diese Zeile legt für alle gültigen Benutzerkonten der NIS-Server-Maps einen Zugang an. Es gibt verschiedene Wege, Ihren NIS-Client durch Änderung dieser Zeile zu konfigurieren. Lesen Sie dazu auch den Abschnitt über Netzgruppen weiter unten. Weitere detaillierte Informationen finden Sie im Buch Managing NFS and NIS von O'Reilly. Sie sollten zumindest ein lokales Benutzerkonto, das nicht über NIS importiert wird, in Ihrer /etc/master.passwd behalten. Dieser Benutzer sollte außerdem ein Mitglied der Gruppe wheel sein. Wenn es mit NIS Probleme gibt, können Sie diesen Zugang verwenden, um sich anzumelden, root zu werden und das Problem zu beheben. Um alle möglichen Gruppeneinträge vom NIS-Server zu importieren, fügen sie folgende Zeile in /etc/group ein: +:*:: Um den NIS-Client sofort zu starten, führen Sie als Superuser die folgenden Befehle aus: &prompt.root; /etc/netstart &prompt.root; /etc/rc.d/ypbind start Nachdem Sie diese Schritte erledigt haben, sollten Sie mit ypcat passwd die passwd-Map des NIS-Servers anzeigen können. Sicherheit unter NIS NIS Sicherheit Im Allgemeinen kann jeder entfernte Anwender einen RPC an &man.ypserv.8; schicken, um den Inhalt Ihrer NIS-Maps abzurufen, falls er Ihren NIS-Domänennamen kennt. Um solche unautorisierten Transaktionen zu verhindern, unterstützt &man.ypserv.8; securenets, durch die man den Zugriff auf bestimmte Rechner beschränken kann. &man.ypserv.8; versucht, beim Systemstart die Informationen über securenets aus der Datei /var/yp/securenets zu laden. Die Datei securenets kann auch in einem anderen Verzeichnis stehen, das mit der Option angegeben wird. Diese Datei enthält Einträge, die aus einer Netzwerkadresse und einer Netzmaske bestehen, die durch Leerzeichen getrennt werden. Kommentarzeilen beginnen mit #. /var/yp/securnets könnte beispielsweise so aussehen: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 Wenn &man.ypserv.8; eine Anforderung von einer zu diesen Regeln passenden Adresse erhält, wird die Anforderung bearbeitet. Gibt es keine passende Regel, wird die Anforderung ignoriert und eine Warnmeldung aufgezeichnet. Wenn /var/yp/securenets nicht vorhanden ist, erlaubt ypserv Verbindungen von jedem Rechner aus. ypserv unterstützt auch das TCP-Wrapper-Paket von Wietse Venema. Mit diesem Paket kann der Administrator für Zugriffskontrollen die Konfigurationsdateien von TCP-Wrapper anstelle von /var/yp/securenets verwenden. Während beide Kontrollmechanismen einige Sicherheit gewähren, beispielsweise durch privilegierte Ports, sind sie gegenüber IP spoofing-Attacken verwundbar. Jeder NIS-Verkehr sollte daher von Ihrer Firewall blockiert werden. Server, die /var/yp/securenets verwenden, können Schwierigkeiten bei der Anmeldung von Clients haben, die ein veraltetes TCP/IP-Subsystem besitzen. Einige dieser TCP/IP-Subsysteme setzen alle Rechnerbits auf Null, wenn Sie einen Broadcast durchführen und/oder können die Subnetzmaske nicht auslesen, wenn sie die Broadcast-Adresse berechnen. Einige Probleme können durch Änderungen der Clientkonfiguration behoben werden. Andere hingegen lassen sich nur durch das Entfernen des betreffenden Rechners aus dem Netzwerk oder den Verzicht auf /var/yp/securenets umgehen. Die Verwendung von /var/yp/securenets auf einem Server mit einem solch veralteten TCP/IP-Subsystem ist eine sehr schlechte Idee, die zu einem Verlust der NIS-Funktionalität für große Teile Ihres Netzwerks führen kann. TCP-Wrapper Die Verwendung der TCP-Wrapper verlangsamt die Reaktion Ihres NIS-Servers. Diese zusätzliche Reaktionszeit kann in Clientprogrammen zu Timeouts führen. Dies vor allem in Netzwerken, die stark ausgelastet sind, oder nur über langsame NIS-Server verfügen. Wenn ein oder mehrere Ihrer Clientsysteme dieses Problem aufweisen, sollten Sie die betreffenden Clients in NIS-Slaveserver umwandeln, und diese an sich selbst binden. Bestimmte Benutzer an der Anmeldung hindern NIS Benutzer blockieren In unserem Labor gibt es den Rechner basie, der nur für Mitarbeiter der Fakultät bestimmt ist. Wir wollen diesen Rechner nicht aus der NIS-Domäne entfernen, obwohl passwd des NIS-Masterservers Benutzerkonten sowohl für Fakultätsmitarbeiter als auch für Studenten enthält. Was können wir also tun? Es gibt eine Möglichkeit, bestimmte Benutzer an der Anmeldung an einem bestimmten Rechner zu hindern, selbst wenn diese in der NIS-Datenbank vorhanden sind. Dazu müssen Sie lediglich an diesem Rechner den Eintrag -Benutzername an das Ende von /etc/master.passwd setzen, wobei Benutzername der zu blockierende Benutzername ist. Diese Änderung sollte bevorzugt durch vipw erledigt werden, da vipw Ihre Änderungen an /etc/master.passwd auf Plausibilität überprüft und nach erfolgter Änderung die Passwortdatenbank automatisch aktualisiert. Um also den Benutzer bill an der Anmeldung am Rechner basie zu hindern, gehen wir wie folgt vor: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Netzgruppen verwenden UdoErdelhoffBeigetragen von Netzgruppen Die im letzten Abschnitt beschriebene Methode eignet sich besonders, wenn Sie spezielle Regeln für wenige Benutzer oder wenige Rechner benötigen. In großen Netzwerken werden Sie allerdings mit Sicherheit vergessen, einige Benutzer von der Anmeldung an bestimmten Rechnern auszuschließen. Oder Sie werden gezwungen sein, jeden Rechner einzeln zu konfigurieren. Dadurch verlieren Sie aber den Hauptvorteil von NIS, die zentrale Verwaltung. Die Lösung für dieses Problem sind Netzgruppen. Ihre Aufgabe und Bedeutung ist vergleichbar mit normalen, von UNIX-Dateisystemen verwendeten Gruppen. Die Hauptunterschiede sind das Fehlen einer numerischen ID sowie die Möglichkeit, Netzgruppen zu definieren, die sowohl Benutzer als auch andere Netzgruppen enthalten. Netzgruppen wurden entwickelt, um große, komplexe Netzwerke mit Hunderten Benutzern und Rechnern zu verwalten. Sie sind also von Vorteil, wenn Sie von dieser Situation betroffen sind. Andererseits ist es dadurch beinahe unmöglich, Netzgruppen mit einfachen Beispielen zu erklären. Das hier verwendete Beispiel veranschaulicht dieses Problem. Nehmen wir an, dass Ihre erfolgreiche Einführung von NIS die Aufmerksamkeit Ihrer Vorgesetzten geweckt hat. Ihre nächste Aufgabe besteht nun darin, Ihre NIS-Domäne um zusätzliche Rechner zu erweitern. Die folgenden Tabellen enthalten die neuen Benutzer und Rechner inklusive einer kurzen Beschreibung. Benutzername(n) Beschreibung alpha, beta Beschäftigte der IT-Abteilung charlie, delta Die neuen Lehrlinge der IT-Abteilung echo, foxtrott, golf, ... Normale Mitarbeiter able, baker, ... Externe Mitarbeiter Rechnername(n) Beschreibung war, death, famine, pollution Ihre wichtigsten Server. Nur IT-Fachleute dürfen sich an diesen Rechnern anmelden. pride, greed, envy, wrath, lust, sloth Weniger wichtige Server. Alle Mitarbeiter der IT-Abteilung dürfen sich auf diesen Rechnern anmelden. one, two, three, four, ... Gewöhnliche Arbeitsrechner. Nur die wirklichen Mitarbeiter dürfen diese Rechner verwenden. trashcan Ein sehr alter Rechner ohne kritische Daten. Sogar externe Mitarbeiter dürfen diesen Rechner verwenden. Wollten Sie diese Einschränkungen umsetzen, indem Sie jeden Benutzer einzeln blockieren, müssten Sie auf jedem System für jeden Benutzer eine entsprechende Zeile in passwd einfügen. Wenn Sie nur einen Eintrag vergessen, haben Sie ein Problem. Es mag noch angehen, dies während der ersten Installation zu erledigen, im täglichen Betrieb werden Sie allerdings mit Sicherheit einmal vergessen, die entsprechenden Einträge anzulegen. Vergessen Sie nicht: Murphy war Optimist. Die Verwendung von Netzgruppen hat in dieser Situation mehrere Vorteile. Sie müssen nicht jeden Benutzer einzeln verwalten; weisen Sie stattdessen den Benutzer einer Netzgruppe zu und erlauben oder verbieten Sie allen Mitglieder dieser Gruppe die Anmeldung an einem Server. Wenn Sie einen neuen Rechner hinzufügen, müssen Sie Zugangsbeschränkungen nur für die Netzgruppen festlegen. Legen Sie einen neuen Benutzer an, müssen Sie ihn nur einer oder mehrere Netzgruppen zuweisen. Diese Veränderungen sind voneinander unabhängig; Anweisungen der Form für diese Kombination aus Benutzer und Rechner mache Folgendes ... sind nicht mehr nötig. Wenn Sie die Einrichtung von NIS sorgfältig geplant haben, müssen Sie nur noch eine zentrale Konfigurationsdatei bearbeiten, um den Zugriff auf bestimmte Rechner zu erlauben oder zu verbieten. Der erste Schritt ist die Initialisierung der NIS-Maps der Netzgruppe. &man.ypinit.8; kann dies unter FreeBSD nicht automatisch durchführen. Sind die Maps aber erst einmal erzeugt, werden sie jedoch von NIS problemlos unterstützt. Um eine leere Map zu erzeugen, geben Sie Folgendes ein: ellington&prompt.root; vi /var/yp/netgroup Danach legen Sie die Einträge an. Für unser Beispiel benötigen wir mindestens vier Netzgruppen: IT-Beschäftige, IT-Lehrlinge, normale Beschäftigte sowie Externe. IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) Bei IT_EMP, IT_APP usw. handelt es sich um Netzgruppennamen. In den Klammern werden diesen Netzgruppen jeweils ein oder mehrere Benutzerkonten hinzugefügt. Die drei Felder in der Klammer haben folgende Bedeutung: Der Name des Rechners, auf dem die folgenden Werte gültig sind. Legen Sie keinen Rechnernamen fest, ist der Eintrag auf allen Rechnern gültig. Dadurch gehen Sie vielen Problemen aus dem Weg. Der Name des Benutzerkontos, der zu dieser Netzgruppe gehört. Die NIS-Domäne für das Benutzerkonto. Sie können Benutzerkonten von anderen NIS-Domänen in Ihre Netzgruppe importieren, wenn Sie mehrere NIS-Domänen verwalten. Jedes Feld kann Wildcards enthalten. Die Einzelheiten entnehmen Sie bitte &man.netgroup.5;. Netzgruppen Netzgruppennamen sollten nicht länger als 8 Zeichen sein, vor allem dann, wenn Sie Rechner mit verschiedenen Betriebssystemen in Ihrer NIS-Domäne haben. Es wird zwischen Groß- und Kleinschreibung unterschieden. Die Verwendung von Großbuchstaben für Netzgruppennamen ermöglicht eine leichte Unterscheidung zwischen Benutzern, Rechnern und Netzgruppen. Einige NIS-Clients (dies gilt nicht für FreeBSD) können keine Netzgruppen mit einer großen Anzahl von Einträgen verwalten. Einige ältere Versionen von &sunos; haben beispielsweise Probleme, wenn Netzgruppen mehr als fünfzehn Einträge enthalten. Sie können dieses Problem umgehen, indem Sie mehrere Subnetzgruppen mit weniger als fünfzehn Benutzern anlegen und diese Subnetzgruppen wiederum in einer Netzgruppe zusammenfassen: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Sie können diesen Vorgang wiederholen, wenn Sie mehr als 255 Benutzer in einer einzigen Netzgruppe benötigen. Das Aktivieren und Verteilen Ihre neuen NIS-Map ist einfach: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Dadurch werden die NIS-Maps netgroup, netgroup.byhost und netgroup.byuser erzeugt. Prüfen Sie die Verfügbarkeit Ihrer neuen NIS-Maps mit &man.ypcat.1;. ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser Die Ausgabe des ersten Befehls gibt den Inhalt von /var/yp/netgroup wieder. Der zweite Befehl erzeugt nur dann eine Ausgabe, wenn Sie rechnerspezifische Netzgruppen erzeugt haben. Der dritte Befehl gibt die Netzgruppen nach Benutzern sortiert aus. Die Einrichtung der Clients ist einfach. Sie müssen lediglich auf dem Server war &man.vipw.8; aufrufen und die Zeile +::::::::: durch +@IT_EMP::::::::: ersetzen. Ab sofort werden nur noch die Daten der in der Netzgruppe IT_EMP vorhandenen Benutzer in die Passwortdatenbank von war importiert. Nur diese Benutzer dürfen sich am Server anmelden. Unglücklicherweise gilt diese Einschränkung auch für die ~-Funktion der Shell und für alle Routinen, die auf Benutzernamen und numerische Benutzer-IDs zugreifen. Oder anders formuliert, cd ~user ist nicht möglich, ls -l zeigt die numerische Benutzer-ID statt dem Benutzernamen und find . -user joe -print erzeugt die Fehlermeldung No such user. Um dieses Problem zu beheben, müssen Sie alle Benutzereinträge importieren, ohne ihnen jedoch zu erlauben, sich an Ihrem Server anzumelden. Dazu fügen Sie eine weitere Zeile in /etc/master.passwd ein. Diese Zeile sollte ähnlich der folgenden aussehen: +:::::::::/sbin/nologin, was in etwa Importiere alle Einträge, aber ersetze die Shell in den importierten Einträgen durch /sbin/nologin entspricht. Sie können jedes Feld dieses Eintrages ersetzen, indem Sie einen Standardwert in /etc/master.passwd eintragen. Stellen Sie sicher, dass die Zeile +:::::::::/sbin/nologin nach der Zeile +@IT_EMP::::::::: eingetragen ist. Sonst haben alle via NIS importierten Benutzerkonten /sbin/nologin als Loginshell. Danach müssen Sie nur mehr eine einzige NIS-Map ändern, wenn ein neuer Mitarbeiter berücksichtigt werden muss. Für weniger wichtige Server gehen Sie analog vor, indem Sie den alten Eintrag +::::::::: in den lokalen Versionen von /etc/master.passwd durch folgende Einträge ersetzen: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Die entsprechenden Zeilen für normale Arbeitsplätze lauten: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin Ab jetzt wäre alles wunderbar, allerdings ändert sich kurz darauf die Firmenpolitik: Die IT-Abteilung beginnt damit, externe Mitarbeiter zu beschäftigen. Externe dürfen sich an normalen Arbeitsplätzen sowie an den weniger wichtigen Servern anmelden. Die IT-Lehrlinge dürfen sich nun auch an den Hauptservern anmelden. Sie legen also die neue Netzgruppe IT_INTERN an, weisen Ihr die neuen IT-Externen als Benutzer zu und beginnen damit, die Konfiguration auf jedem einzelnen Rechner zu ändern ... Halt. Sie haben gerade die alte Regel Fehler in der zentralisierten Planung führen zu globaler Verwirrung. bestätigt. Da NIS in der Lage ist, Netzgruppen aus anderen Netzgruppen zu bilden, lassen sich solche Situationen leicht vermeiden. Eine Möglichkeit ist die Erzeugung rollenbasierter Netzgruppen. Sie könnten eine Netzgruppe BIGSRV erzeugen, um den Zugang zu den wichtigsten Servern zu beschränken, eine weitere Gruppe SMALLSRV für die weniger wichtigen Server und eine dritte Netzgruppe USERBOX für die normalen Arbeitsplatzrechner. Jede dieser Netzgruppen enthält die Netzgruppen, die sich auf diesen Rechnern anmelden dürfen. Die Einträge der Netzgruppen in der NIS-Map sollten ähnlich den folgenden aussehen: BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS Diese Methode funktioniert besonders gut, wenn Sie Rechner in Gruppen mit identischen Beschränkungen einteilen können. Unglücklicherweise ist dies die Ausnahme und nicht die Regel. Meistens werden Sie die Möglichkeit zur rechnerspezischen Zugangsbeschränkung benötigen. Rechnerspezifische Netzgruppen sind die zweite Möglichkeit, um mit den oben beschriebenen Änderungen umzugehen. In diesem Szenario enthält /etc/master.passwd auf jedem Rechner zwei mit + beginnende Zeilen. Die erste Zeile legt die Netzgruppe mit den Benutzern fest, die sich auf diesem Rechner anmelden dürfen. Die zweite Zeile weist allen anderen Benutzern /sbin/nologin als Shell zu. Verwenden Sie auch hier (analog zu den Netzgruppen) Großbuchstaben für die Rechnernamen. Die Zeilen sollten also ähnlich den folgenden aussehen: +@BOXNAME::::::::: +:::::::::/sbin/nologin Wenn Sie dies für alle Rechner erledigt haben, werden Sie die lokalen Versionen von /etc/master.passwd nie mehr verändern müssen. Alle weiteren Änderungen geschehen über die NIS-Maps. Nachfolgend ein Beispiel für eine mögliche Netzgruppen-Map, die durch einige Besonderheiten erweitert wurde: # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITINTERN (,kilo,test-domain) (,lima,test-domain) D_INTERNS (,able,test-domain) (,baker,test-domain) # # Now, define some groups based on roles USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_EMP IT_APP SMALLSRV IT_EMP IT_APP ITINTERN USERBOX IT_EMP ITINTERN USERS # # And a groups for a special tasks # Allow echo and golf to access our anti-virus-machine SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) # # machine-based netgroups # Our main servers WAR BIGSRV FAMINE BIGSRV # User india needs access to this server POLLUTION BIGSRV (,india,test-domain) # # This one is really important and needs more access restrictions DEATH IT_EMP # # The anti-virus-machine mentioned above ONE SECURITY # # Restrict a machine to a single user TWO (,hotel,test-domain) # [...more groups to follow] Wenn Sie eine Datenbank verwenden, um Ihre Benutzerkonten zu verwalten, sollten Sie den ersten Teil der NIS-Map mit Ihren Datenbanktools erstellen können. Auf diese Weise haben neue Benutzer automatisch Zugriff auf die Rechner. Eine letzte Warnung: Es ist nicht immer ratsam, rechnerbasierte Netzgruppen zu verwenden. Wenn Sie Dutzende oder gar Hunderte identische Rechner einrichten müssen, sollten Sie rollenbasierte Netzgruppen verwenden, um die Grösse der NISs-Maps in Grenzen zu halten. Weitere wichtige Punkte Nachdem Sie Ihre NIS-Umgebung eingerichtet haben, müssen Sie einige Dinge anders als bisher erledigen. Jedes Mal, wenn Sie einen neuen Benutzer anlegen wollen, tun Sie dies ausschließlich am NIS-Masterserver. Außerdem müssen Sie anschließend die NIS-Maps neu erzeugen. Wenn Sie diesen Punkt vergessen, kann sich der neue Benutzer nur am NIS-Masterserver anmelden. Wenn Sie also den neuen Benutzer jsmith anlegen, gehen Sie folgerndermassen vor: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Statt pw useradd jsmith könnten Sie auch adduser jsmith verwenden. Tragen Sie die Administratorkonten nicht in die NIS-Maps ein. Administratorkonten und Passwörter dürfen nicht auf Rechnern verbreitet werden, auf denen sich Benutzer anmelden können, die auf diese Konten keine Zugriff haben sollen. Sichern Sie die NIS-Master- und Slaveserver und minimieren Sie die Ausfallzeiten. Wenn diese Rechner gehackt oder einfach nur ausgeschaltet werden, haben viele Leute keinen Netzwerkzugriff mehr. Dies ist die größte Schwäche jeder zentralen Verwaltung. Wenn Sie Ihre NIS-Server nicht schützen, werden Sie viele verärgerte Anwender haben. Kompatibilität zu NIS v1 NIS Kompatibilität zu NIS v1 ypserv unterstützt NIS v1 unter FreeBSD nur eingeschränkt. Die NIS-Implementierung von FreeBSD verwendet nur NIS v2, andere Implementierungen unterstützen aus Gründen der Abwärtskompatibilität mit älteren Systemen auch NIS v1. Die mit diesen Systemen gelieferten ypbind-Daemonen versuchen, sich an einen NIS-v1-Server zu binden (Dies selbst dann, wenn sie ihn nie benötigen. Außerdem versuchen Sie auch dann, einen v1-Server zu erreichen, wenn Sie zuvor eine Antwort von einem v2-Server erhalten.). Während normale Clientaufrufe unter FreeBSD unterstützt werden, sind Anforderungen zum Transfer von v1-Maps nicht möglich. Daher kann FreeBSD nicht als Client oder Server verwendet werden, wenn ein NIS-Server vorhanden ist, der nur NIS v1 unterstützt. Glücklicherweise sollte es heute keine Server mehr geben, die nur NIS v1 unterstützen. NIS-Server, die auch als NIS-Clients arbeiten Wenn Sie ypserv in einer Multi-Serverdomäne verwenden, in der NIS-Server gleichzeitig als NIS-Clients arbeiten, ist es eine gute Idee, diese Server zu zwingen, sich an sich selbst zu binden. Damit wird verhindert, dass Bindeanforderungen gesendet werden und sich die Server gegenseitig binden. Sonst könnten seltsame Fehler auftreten, wenn ein Server ausfällt, auf den andere Server angewiesen sind. Letztlich werden alle Clients einen Timeout melden, und versuchen, sich an andere Server zu binden. Die dadurch entstehende Verzögerung kann beträchtlich sein. Außerdem kann der Fehler erneut auftreten, da sich die Server wiederum aneinander binden könnten. Sie können einen Rechner durch die Verwendung von ypbind sowie der Option zwingen, sich an einen bestimmten Server zu binden. Um diesen Vorgang zu automatisieren, können Sie folgende Zeilen in /etc/rc.conf einfügen: nis_client_enable="YES" # run client stuff as well nis_client_flags="-S NIS domain,server" Lesen Sie &man.ypbind.8;, wenn Sie weitere Informationen benötigen. Passwortformate NIS Passwortformate Unterschiedliche Passwortformate sind das Hauptproblem, das beim Einrichten eines NIS-Servers auftreten kann. Wenn der NIS-Server mit DES verschlüsselte Passwörter verwendet, werden nur Clients unterstützt, die ebenfalls DES benutzen. Wenn sich auf Ihrem Netzwerk beispielsweise &solaris; NIS-Clients befinden, müssen die Passwörter mit DES verschlüsselt werden. Welches Format die Server und Clients verwenden, steht in /etc/login.conf. Wenn ein System Passwörter mit DES verschlüsselt, enthält die default-Klasse einen Eintrag wie den folgenden: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [weitere Einträge] Mögliche Werte für passwd_format sind unter anderem blf und md5 (mit Blowfish und MD5 verschlüsselte Passwörter). Wenn die Datei /etc/login.conf geändert wird, muss die Login-Capability Datenbank neu erstellt werden. Geben Sie dazu als root den folgenden Befehl ein: &prompt.root; cap_mkdb /etc/login.conf Das Format der schon in /etc/master.passwd befindlichen Passwörter wird erst aktualisiert, wenn ein Benutzer sein Passwort ändert, nachdem die Datenbank neu erstellt wurde. Damit die Passwörter auch im gewählten Format abgespeichert werden, muss mit crypt_default in der Datei /etc/auth.conf die richtige Priorität der Formate eingestellt werden. Das gewählte Format sollte als Erstes in der Liste stehen. Sollen die Passwörter mit DES verschlüsselt werden, verwenden Sie den folgenden Eintrag: crypt_default = des blf md5 Wenn Sie alle &os; NIS-Server und NIS-Clients entsprechend den obigen Schritten eingestellt haben, wird im ganzen Netzwerk dasselbe Passwortformat verwendet. Falls Sie Probleme mit der Authentifizierung eines NIS-Clients haben, kontrollieren Sie die verwendeten Passwortformate. In einer heterogenen Umgebung werden Sie DES benutzen müssen, da dies der meist unterstützte Standard ist. Automatische Netzwerkkonfiguration mit DHCP GregSutterGeschrieben von Was ist DHCP? Dynamic Host Configuration Protocol DHCP Internet Systems Consortium (ISC) Über DHCP, das Dynamic Host Configuration Protocol, kann sich ein System mit einem Netzwerk verbinden und die für die Kommunikation mit diesem Netzwerk nötigen Informationen beziehen. &os; verwendet den von OpenBSD 3.7 stammenden dhclient. Die Informationen in diesem Abschnitt beziehen sich daher sowohl auf den dhclient von ISC als auch auf den von OpenBSD. Als DHCP-Server wird in beiden Fällen der DHCP-Server der ISC-Distribution verwendet. Übersicht Dieser Abschnitt beschreibt sowohl die Clientseite des ISC- als auch des OpenBSD-Clients sowie die Serverseite des DHCP-Systems von ISC. Das Clientprogramm dhclient ist in FreeBSD integriert, das Serverprogramm kann über den Port net/isc-dhcp42-server installiert werden. Weiter Informationen finden Sie in &man.dhclient.8;, &man.dhcp-options.5; sowie &man.dhclient.conf.5;. Wie funktioniert DHCP? UDP Der DHCP-Client dhclient beginnt von einem Clientrechner aus über den UDP-Port 68 Konfigurationsinformationen anzufordern. Der Server antwortet auf dem UDP-Port 67, indem er dem Client eine IP-Adresse zuweist und ihm weitere wichtige Informationen über das Netzwerk, wie Netzmasken, Router und DNS-Server mitteilt. Diese Informationen werden als DHCP-Lease bezeichnet und sind nur für eine bestimmte Zeit, die vom Administrator des DHCP-Servers vorgegeben wird, gültig. Dadurch fallen verwaiste IP-Adressen, deren Clients nicht mehr mit dem Netzwerk verbunden sind, automatisch an den Server zurück. DHCP-Clients können sehr viele Informationen von einem DHCP-Server erhalten. Eine ausführliche Liste finden Sie in &man.dhcp-options.5;. Integration in FreeBSD &os; verwendet den DHCP-Client von OpenBSD. Sowohl während der Installation als auch im Basissystem steht der DHCP-Client zur Verfügung. In Netzen mit DHCP-Servern wird dadurch die Konfiguration von Systemen erheblich vereinfacht. sysinstall DHCP wird von sysinstall unterstützt. Wenn Sie eine Netzwerkkarte mit sysinstall konfigurieren, lautet die zweite Frage Do you want to try DHCP configuration of the interface?. Wenn Sie diese Frage bejahen, wird dhclient aufgerufen, und die Netzkarte wird automatisch eingerichtet. Um DHCP beim Systemstart zu aktivieren, müssen Sie zwei Dinge erledigen: DHCP Anforderungen Stellen Sie sicher, dass bpf in Ihren Kernel kompiliert ist. Dazu fügen Sie die Zeile device bpf in Ihre Kernelkonfigurationsdatei ein und erzeugen einen neuen Kernel. Weitere Informationen zur Kernelkonfiguration finden Sie in des Handbuchs. Das Gerät bpf ist im GENERIC-Kernel bereits enthalten. Für die Nutzung von DHCP muss also kein angepasster Kernel erzeugt werden. Wenn Sie um die Sicherheit Ihres Systems besorgt sind, sollten Sie wissen, dass bpf auch zur Ausführung von Paketsniffern erforderlich ist (obwohl diese dennoch als root ausgeführt werden müssen). bpf muss vorhanden sein, damit DHCP funktioniert. Sind Sie sehr sicherheitsbewusst, sollten Sie bpf aus Ihrem Kernel entfernen, wenn Sie DHCP nicht verwenden. Standardmässig läuft die DHCP-Konfiguration bei &os; im Hintergrund oder auch asynchron. Andere Startskripte laufen weiter, während DHCP fertig abgearbeitet wird, was den Systemstart beschleunigt. DHCP im Hintergrund funktioniert gut, wenn der DHCP-Server schnell auf Anfragen antwortet und der DHCP-Konfigurationsprozess ebenso schnell abläuft. Jedoch kann DHCP eine lange Zeit benötigen, um auf manchen Systemen fertig zu werden. Falls Netzwerkdienste versuchen, vor DHCP zum Ende zu kommen, werden diese fehlschlagen. Durch die Verwendung von DHCP im asynchronen-Modus wird das Problem verhindert, so dass die Startskripte pausiert werden, bis die DHCP-Konfiguration abgeschlossen ist. Um sich zu einem DHCP-Server im Hintergrund zu verbinden, während andere Startskripte fortfahren (asynchroner Modus), benutzen Sie den DHCP-Wert in /etc/rc.conf: ifconfig_fxp0="DHCP" Um den Start zu pausieren, damit DHCP vorher abgeschlossen werden kann, benutzen Sie den synchronen Modus mit dem Eintrag SYNCDHCP: ifconfig_fxp0="SYNCDHCP" Ersetzen Sie fxp0, das in diesen Beispielen verwendet wurde, durch den Namen Ihrer Netzwerkschnittstelle, so wie es in beschrieben ist. Wenn Sie dhclient an einem anderen Ort installiert haben, oder zusätzliche Flags an dhclient übergeben wollen, fügen Sie auch folgende (entsprechend angepasste) Zeilen ein: dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP Server Der DHCP-Server dhcpd ist als Teil des Ports net/isc-dhcp42-server verfügbar. Dieser Port enthält die komplette ISC-DHCP-Distribution, inklusive der Dokumentation. Dateien DHCP Konfigurationsdateien /etc/dhclient.conf dhclient benötigt die Konfigurationsdatei /etc/dhclient.conf. Diese Datei enthält normalerweise nur Kommentare, da die Vorgabewerte zumeist ausreichend sind. Lesen Sie dazu auch &man.dhclient.conf.5;. /sbin/dhclient dhclient ist statisch gelinkt und befindet sich in /sbin. Weitere Informationen finden Sie in &man.dhclient.8;. /sbin/dhclient-script Bei dhclient-script handelt es sich um das FreeBSD-spezifische Konfigurationsskript des DHCP-Clients. Es wird in &man.dhclient-script.8; beschrieben und kann meist unverändert übernommen werden. - /var/db/dhclient.leases + /var/db/dhclient.leases. +interface Der DHCP-Client verfügt über eine Datenbank, die alle derzeit gültigen Leases enthält und als Logdatei erzeugt wird. Weitere Informationen finden Sie in &man.dhclient.8;. Weitere Informationen Das DHCP-Protokoll wird vollständig im RFC 2131 beschrieben. Eine weitere, lehrreiche Informationsquelle existiert unter http://www.dhcp.org/. Einen DHCP-Server installieren und einrichten Übersicht Dieser Abschnitt beschreibt die Einrichtung eines FreeBSD-Systems als DHCP-Server. Dazu wird die DHCP-Implementation von ISC (Internet Systems Consortium) verwendet. Der DHCP-Server ist nicht im Basissystem von FreeBSD enthalten, daher müssen Sie als Erstes den Port net/isc-dhcp42-server installieren. Lesen Sie , wenn Sie weitere Informationen zur Ports-Sammlung benötigen. Den DHCP-Server installieren DHCP installieren Stellen Sie sicher, dass &man.bpf.4; in Ihren Kernel kompiliert ist. Dazu fügen Sie die Zeile device bpf Ihre Kernelkonfigurationsdatei ein und erzeugen einen neuen Kernel. Die Kernelkonfiguration wird in beschrieben. Das Gerät bpf ist im GENERIC-Kernel bereits enthalten. Für die Nutzung von DHCP muss also kein angepasster Kernel erzeugt werden. Wenn Sie um die Sicherheit Ihres Systems besorgt sind, sollten Sie wissen, dass bpf auch zur Ausführung von Paketsniffern erforderlich ist (obwohl diese dennoch als root ausgeführt werden müssen). bpf muss vorhanden sein, damit DHCP funktioniert. Sind Sie sehr sicherheitsbewusst, sollten Sie bpf aus Ihrem Kernel entfernen, wenn Sie DHCP nicht verwenden. Danach müssen Sie die vom Port net/isc-dhcp42-server erzeugte Vorlage für dhcpd.conf anpassen. Die bei der Installation erzeugte Datei /usr/local/etc/dhcpd.conf.sample sollten Sie nach /usr/local/etc/dhcpd.conf kopieren, bevor Sie Veränderungen vornehmen. Den DHCP-Server einrichten DHCP dhcpd.conf dhcpd.conf besteht aus Festlegungen zu Subnetzen und Rechnern und lässt sich am besten an einem Beispiel erklären: option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } Diese Option beschreibt die Domäne, die den Clients als Standardsuchdomäne zugewiesen wird. Weitere Informationen finden Sie in man.resolv.conf.5;. Diese Option legt eine, durch Kommata getrennte Liste von DNS-Servern fest, die von den Clients verwendet werden sollen. Die den Clients zugewiesene Netzmaske. Ein Client kann eine Lease einer bestimmten Dauer anfordern. Geschieht dies nicht, weist der Server eine Lease mit einer vorgegebenen Ablaufdauer (in Sekunden) zu. Die maximale Zeitdauer, für die der Server Konfigurationsinformationen vergibt. Sollte ein Client eine längere Zeitspanne anfordern, wird dennoch nur der Wert max-lease-time in Sekunden zugewiesen. Diese Option legt fest, ob der DHCP-Server eine DNS-Aktualisierung versuchen soll, wenn Konfigurationsdateien vergeben oder zurückgezogen werden. In der ISC-Implementation muss diese Option gesetzt sein. Dadurch werden die IP-Adressen festgelegt, die den Clients zugewiesen werden können. IP-Adressen zwischen diesen Grenzen sowie die einschließenden Adressen werden den Clients zugewiesen. Legt das Standard-Gateway fest, das den Clients zugewiesen wird. Die (Hardware-)MAC-Adresse eines Rechners (durch die der DHCP-Server den Client erkennt, der eine Anforderung an ihn stellt). Einem Rechner soll immer die gleiche IP-Adresse zugewiesen werden. Beachten Sie, dass hier auch ein Rechnername gültig ist, da der DHCP-Server den Rechnernamen auflöst, bevor er die Konfigurationsinformationen zuweist. Nachdem Sie dhcpd.conf fertig konfiguriert haben, sollten Sie den DHCP-Server aktivieren, indem Sie folgende Zeilen in /etc/rc.conf aufnehmen: dhcpd_enable="YES" dhcpd_ifaces="dc0" Dabei müssen Sie den Geräteeintrag dc0 durch die Gerätedatei (mehrere Gerätedateien müssen durch Leerzeichen getrennt werden) ersetzen, die Ihr DHCP-Server auf Anfragen von DHCP-Clients hin überwachen soll. Danach können Sie den Server durch Eingabe des folgenden Befehls starten: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd start Sollten Sie die Konfiguration Ihres Servers einmal verändern müssen, reicht es nicht aus, ein SIGHUP-Signal an dhcpd zu senden, weil damit die Konfiguration nicht erneut geladen wird (im Gegensatz zu den meisten Daemonen). Sie müssen den Prozess vielmehr mit dem Signal SIGTERM stoppen, um ihn anschließend neu zu starten. Dateien Server Konfigurationsdateien /usr/local/sbin/dhcpd dhcpd ist statisch gelinkt und befindet sich in /usr/local/sbin. Lesen Sie auch die mit dem Port installierte Hilfeseite &man.dhcpd.8;, wenn Sie weitere Informationen zu dhcpd benötigen. /usr/local/etc/dhcpd.conf dhcpd benötigt die Konfigurationsdatei /usr/local/etc/dhcpd.conf, damit der Server den Clients seine Dienste anbieten kann. Diese Datei muss alle Informationen enthalten, die an die Clients weitergegeben werden soll. Außerdem sind hier Informationen zur Konfiguration des Servers enthalten. Die mit dem Port installierte Hilfeseite &man.dhcpd.conf.5; enthält weitere Informationen. /var/db/dhcpd.leases Der DHCP-Server hat eine Datenbank, die alle vergebenen Leases enthält. Diese wird als Logdatei erzeugt. Weitere Informationen finden Sie in der vom Port installierten Hilfeseite &man.dhcpd.leases.5;. /usr/local/sbin/dhcrelay dhcrelay wird in komplexen Umgebungen verwendet, in denen ein DHCP-Server eine Anfrage eines Clients an einen DHCP-Server in einem separaten Netzwerk weiterleitet. Wenn Sie diese Funktion benötigen, müssen Sie den Port net/isc-dhcp42-relay installieren. Weitere Informationen zu diesem Thema finden Sie in &man.dhcrelay.8;. <acronym>DNS</acronym> – Domain Name Service ChernLeeBeigetragen von TomRhodes DanielGerzo Überblick BIND DNS ist das für die Umwandlung von Rechnernamen in IP-Adressen zuständige Protokoll. &os; verwendet dazu BIND (Berkeley Internet Name Domain), die am häufigsten verwendete Implementierung von DNS). Eine Anfrage nach www.FreeBSD.org gibt die IP-Adresse des &os;-Webservers, eine Anfrage nach ftp.FreeBSD.org die IP-Adresse des entsprechenden FTP-Servers zurück. Der umgekehrte Weg ist ebenso möglich, eine IP-Adresse kann also auch in ihren Rechnernamen aufgelöst werden. Um eine DNS-Abfrage durchzuführen, muss auf dem jeweiligen Rechner kein Nameserver installiert sein. &os; verwendet derzeit in der Voreinstellung BIND9 als DNS-Serversoftware. Unsere Installation bietet Ihnen eine erhöhte Sicherheit, ein neues Dateisystemlayout sowie eine automatisierte &man.chroot.8;-Konfiguration. DNS Im Internet wird DNS durch ein komplexes System von autoritativen Root-Nameservern, Top Level Domain-Servern (TLD) sowie anderen kleineren Nameservern verwaltet, die individuelle Rechnerinformationen speichern und untereinander abgleichen. Derzeit wird BIND vom Internet Systems Consortium (https://www.isc.org/) verwaltet. Begriffsbestimmungen Um dieses Dokument besser verstehen zu können, müssen einige DNS-spezifische Begriffe genauer definiert werden. Resolver Reverse-DNS Root-Zone Begriff Bedeutung Forward-DNS Rechnernamen in IP-Adressen umwandeln. Origin (Ursprung) Die in einer bestimmten Zonendatei beschriebene Domäne. named, BIND Gebräuchliche Namen für das unter &os; verwendete BIND-Nameserverpaket. Resolver Ein Systemprozess, durch den ein Rechner Zoneninformationen von einem Nameserver anfordert. Reverse-DNS die Umwandlung von IP-Adressen in Rechnernamen Root-Zone Der Beginn der Internet-Zonenhierarchie. Alle Zonen befinden sich innerhalb der Root-Zone. Dies ist analog zu einem Dateisystem, in dem sich alle Dateien und Verzeichnisse innerhalb des Wurzelverzeichnisses befinden. Zone Eine individuelle Domäne, Unterdomäne, oder ein Teil von DNS, der von der gleichen Autorität verwaltet wird. Zonen Beispiele Es folgen nun einige Zonenbeispiele: Innerhalb der Dokumentation wird die Root-Zone in der Regel mit . bezeichnet. org. ist eine Top level Domain (TLD) innerhalb der Root-Zone. example.org. ist eine Zone innerhalb der org.-TLD. 1.168.192.in-addr.arpa. ist die Zone mit allen IP-Adressen des 192.168.1.*-IP-Bereichs. Wie man an diesen Beispielen erkennen kann, befindet sich der spezifischere Teil eines Rechnernamens auf der linken Seite der Adresse. example.org. beschreibt einen Rechner also genauer als org., während org. genauer als die Root-Zone ist. Jeder Teil des Rechnernamens hat Ähnlichkeiten mit einem Dateisystem, in dem etwa /dev dem Wurzelverzeichnis untergeordnet ist. Gründe für die Verwendung eines Nameservers Es gibt zwei Arten von Nameservern: Autoritative Nameserver sowie zwischenspeichernde (cachende, auch bekannt als auflösende) Nameserver. Ein autoritativer Nameserver ist notwendig, wenn Sie anderen verbindliche DNS-Auskünfte erteilen wollen. eine Domain, beispielsweise example.org, registriert wird, und den zu dieser Domain gehörenden Rechnern IP-Adressen zugewiesen werden müssen. ein IP-Adressblock reverse-DNS-Einträge benötigt, um IP-Adressen in Rechnernamen auflösen zu können. ein Backup-Nameserver (auch Slaveserver genannt) oder ein zweiter Nameserver auf Anfragen antworten soll. Ein cachender Nameserver ist notwendig, weil ein lokaler DNS-Server Daten zwischenspeichern und daher schneller auf Anfragen reagieren kann als ein entfernter Server. Wird nach www.FreeBSD.org gesucht, leitet der Resolver diese Anfrage an den Nameserver des ISPs weiter und nimmt danach das Ergebnis der Abfrage entgegen. Existiert ein lokaler, zwischenspeichernder DNS-Server, muss dieser die Anfrage nur einmal nach außen weitergeben. Für alle weiteren Anfragen ist dies nicht mehr nötig, da diese Information nun lokal gespeichert ist. Wie funktioniert <acronym>DNS</acronym>? Unter &os; wird der BIND-Daemon als named bezeichnet. Datei Beschreibung named Der BIND-Daemon. &man.rndc.8; Das Steuerprogramm für named. /etc/namedb Das Verzeichnis, in dem sich die Zoneninformationen für BIND befinden. /etc/namedb/named.conf Die Konfigurationsdatei für named. Je nachdem, wie eine Zone auf dem Server konfiguriert wurde, finden sich die zur Zone gehörendenden Dateien in den Unterverzeichnissen master, slave, oder dynamic des Verzeichnisses /etc/namedb. Diese Dateien enthalten die DNS-Informationen, die der Nameserver für die Beantwortung von Anfragen benötigt. BIND starten BIND Start Da BIND automatisch installiert wird, ist die Konfiguration relativ einfach. In der Voreinstellung wird ein in einer &man.chroot.8;-Umgebung betriebener named-Server zur einfachen Namensauflösung eingerichtet, der nur im lokalen IPv4-Loopback-Adressbereich (127.0.0.1) lauscht. Um den Server manuell zu starten, verwenden Sie den folgenden Befehl: &prompt.root; /etc/rc.d/named onestart Um den named-Daemon beim Systemstart automatisch zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein: named_enable="YES" /etc/namedb/named.conf bietet zahlreiche Konfigurationsoptionen, die in diesem Dokument nicht alle beschrieben werden können. Wollen Sie die Startoptionen von named unter &os; anpassen, sollten Sie sich die named_*-Flags in der Datei /etc/defaults/rc.conf sowie die Manualpage zu &man.rc.conf.5; näher ansehen. Zusätzliche Informationen bietet Ihnen auch der Abschnitt des Handbuchs. Konfigurationsdateien BIND Konfigurationsdateien Die Konfigurationsdateien von named finden sich unter /etc/namedb und müssen in der Regel an Ihre Bedürfnisse angepasst werden. Es sei denn, Sie benötigen nur einen einfachen Resolver. Ein Großteil der Konfigurationsarbeiten erfolgt dabei in diesem Verzeichnis. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // Refer to the named.conf(5) and named(8) man pages, and the documentation // in /usr/share/doc/bind9 for more details. // // If you are going to set up an authoritative server, make sure you // understand the hairy details of how DNS works. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amounts of useless Internet traffic. options { // All file and path names are relative to the chroot directory, // if any, and should be fully qualified. directory "/etc/namedb/working"; pid-file "/var/run/named/pid"; dump-file "/var/dump/named_dump.db"; statistics-file "/var/stats/named.stats"; // If named is being used only as a local resolver, this is a safe default. // For named to be accessible to the network, comment this option, specify // the proper IP address, or delete this option. listen-on { 127.0.0.1; }; // If you have IPv6 enabled on this system, uncomment this option for // use as a local resolver. To give access to the network, specify // an IPv6 address, or the keyword "any". // listen-on-v6 { ::1; }; // These zones are already covered by the empty zones listed below. // If you remove the related empty zones below, comment these lines out. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // If you've got a DNS server around at your upstream provider, enter // its IP address here, and enable the line below. This will make you // benefit from its cache, thus reduce overall DNS traffic in the Internet. /* forwarders { 127.0.0.1; }; */ // If the 'forwarders' clause is not empty the default is to 'forward first' // which will fall back to sending a query from your local server if the name // servers in 'forwarders' do not have the answer. Alternatively you can // force your name server to never initiate queries of its own by enabling the // following line: // forward only; // If you wish to have forwarding configured automatically based on // the entries in /etc/resolv.conf, uncomment the following line and // set named_auto_forward=yes in /etc/rc.conf. You can also enable // named_auto_forward_only (the effect of which is described above). // include "/etc/namedb/auto_forward.conf"; Um vom Cache Ihres Internetproviders zu profitieren, können hier forwarders aktiviert werden. Normalerweise sucht ein Nameserver das Internet rekursiv ab, bis er die gesuchte Antwort findet. Durch diese Option wird stets der Nameserver Ihres Internetproviders zuerst abgefragt, um von dessen Cache zu profitieren. Wenn es sich um einen schnellen, viel benutzten Nameserver handelt, kann dies zu einer Geschwindigkeitssteigerung führen. 127.0.0.1 funktioniert hier nicht. Ändern Sie diese Adresse in einen Nameserver Ihres Einwahlproviders. /* Modern versions of BIND use a random UDP port for each outgoing query by default in order to dramatically reduce the possibility of cache poisoning. All users are strongly encouraged to utilize this feature, and to configure their firewalls to accommodate it. AS A LAST RESORT in order to get around a restrictive firewall policy you can try enabling the option below. Use of this option will significantly reduce your ability to withstand cache poisoning attacks, and should be avoided if at all possible. Replace NNNNN in the example with a number between 49160 and 65530. */ // query-source address * port NNNNN; }; // If you enable a local name server, don't forget to enter 127.0.0.1 // first in your /etc/resolv.conf so this server will be queried. // Also, make sure to enable it in /etc/rc.conf. // The traditional root hints mechanism. Use this, OR the slave zones below. zone "." { type hint; file "/etc/namedb/named.root"; }; /* Slaving the following zones from the root name servers has some significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots 3. Greater resilience to any potential root server failure/DDoS On the other hand, this method requires more monitoring than the hints file to be sure that an unexpected failure mode has not incapacitated your server. Name servers that are serving a lot of clients will benefit more from this approach than individual hosts. Use with caution. To use this mechanism, uncomment the entries below, and comment the hint zone above. As documented at http://dns.icann.org/services/axfr/ these zones: "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET are availble for AXFR from these servers on IPv4 and IPv6: xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org */ /* zone "." { type slave; file "/etc/namedb/slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "/etc/namedb/slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; */ /* Serving the following zones locally will prevent any queries for these zones leaving your network and going to the root name servers. This has two significant advantages: 1. Faster local resolution for your users 2. No spurious traffic will be sent from your network to the roots */ // RFCs 1912 and 5735 (and BCP 32 for localhost) zone "localhost" { type master; file "/etc/namedb/master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // RFC 1912-style zone for IPv6 localhost address zone "0.ip6.arpa" { type master; file "/etc/namedb/master/localhost-reverse.db"; }; // "This" Network (RFCs 1912 and 5735) zone "0.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Private Use Networks (RFCs 1918 and 5735) zone "10.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Link-local/APIPA (RFCs 3927 and 5735) zone "254.169.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IETF protocol assignments (RFCs 5735 and 5736) zone "0.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // TEST-NET-[1-3] for Documentation (RFCs 5735 and 5737) zone "2.0.192.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "100.51.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "113.0.203.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Range for Documentation (RFC 3849) zone "8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // Domain Names for Documentation and Testing (BCP 32) zone "test" { type master; file "/etc/namedb/master/empty.db"; }; zone "example" { type master; file "/etc/namedb/master/empty.db"; }; zone "invalid" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.com" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.net" { type master; file "/etc/namedb/master/empty.db"; }; zone "example.org" { type master; file "/etc/namedb/master/empty.db"; }; // Router Benchmark Testing (RFCs 2544 and 5735) zone "18.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "19.198.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IANA Reserved - Old Class E Space (RFC 5735) zone "240.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "241.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "242.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "243.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "244.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "245.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "246.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "247.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "248.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "249.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "250.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "251.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "252.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "253.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "254.in-addr.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Unassigned Addresses (RFC 4291) zone "1.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "c.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "8.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "0.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "1.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "2.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "3.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "4.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "5.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "6.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "7.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Link Local (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "9.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "a.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "b.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IPv6 Deprecated Site-Local Addresses (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "d.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "e.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; zone "f.e.f.ip6.arpa" { type master; file "/etc/namedb/master/empty.db"; }; // IP6.INT is Deprecated (RFC 4159) zone "ip6.int" { type master; file "/etc/namedb/master/empty.db"; }; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example slave zone config entries. It can be convenient to become // a slave at least for the zone your own domain is in. Ask // your network administrator for the IP address of the responsible // master name server. // // Do not forget to include the reverse lookup zone! // This is named after the first bytes of the IP address, in reverse // order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6. // // Before starting to set up a master zone, make sure you fully // understand how DNS and BIND work. There are sometimes // non-obvious pitfalls. Setting up a slave zone is usually simpler. // // NB: Don't blindly enable the examples below. :-) Use actual names // and addresses instead. /* An example dynamic zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "/etc/named/dynamic/example.org"; }; */ /* Example of a slave reverse zone zone "1.168.192.in-addr.arpa" { type slave; file "/etc/namedb/slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ Hierbei handelt es sich um Slave-Einträge für eine Reverse- und Forward-DNS-Zone, die in der Datei named.conf definiert sind. Für jede neue Zone muss ein zusätzlicher Eintrag in named.conf erstellt werden. Ein einfacher Eintrag für eine Zone example.org könnte beispielsweise so aussehen: zone "example.org" { type master; file "master/example.org"; }; Die Option legt fest, dass es sich um eine Master-Zone handelt, deren Zoneninformationen sich in der Datei /etc/namedb/master/example.org befinden. Diese Datei wird durch die Option festgelegt. zone "example.org" { type slave; file "slave/example.org"; }; Hier handelt es sich um einen Slaveserver, der seine Informationen vom Masterserver der betreffenden Zone bezieht und diese in der angegebenen Datei speichert. Wenn der Masterserver nicht erreichbar ist, verfügt der Slaveserver über die transferierten Zoneninformationen und kann diese an andere Rechner weitergeben. Zonendateien BIND Zonendatei Die in der Datei /etc/namedb/master/example.org definierte Zonendatei für example.org könnte etwa so aussehen: $TTL 3600 ; 1 hour default TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ; Negative Response TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 ; Aliases www IN CNAME example.org. Beachten Sie, dass jeder mit einem . endende Rechnername ein exakter Rechnername ist, während sich alles ohne einen abschließenden . relativ auf den Ursprung bezieht. ns1 steht daher beispielsweise für ns1.example.org.. Eine Zonendatei hat folgenden Aufbau: recordname IN recordtype value DNS Einträge Die am häufigsten verwendeten DNS-Einträge sind: SOA Start der Zonenautorität NS Ein autoritativer Nameserver A Eine Rechneradresse CNAME Der kanonische Name eines Alias MX Mail Exchanger PTR Ein (bei Reverse-DNS verwendeter) Domain Name Pointer example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 300 ) ; Negative Response TTL example.org. Der Name der Domäne und damit der Ursprung dieser Zonendatei. ns1.example.org. Der primäre/autoritative Nameserver dieser Zone. admin.example.org. Die für diese Zone verantwortliche Person. Das Zeichen @ wird dabei ersetzt (admin@example.org wird also zu admin.example.org). 2006051501 Die Seriennummer der Datei. Sie muss stets inkrementiert werden, wenn die Zonendatei geändert wird. Viele Administratoren bevorzugen ein JJJJMMTTRR-Format, um die Seriennummer festzulegen. 2006051501 steht also für den 15.05.2006, die beiden letzten Stellen für die erste Modifikation der Zonendatei an diesem Tag. Die Seriennummer ist von großer Bedeutung, da Slaveserver daran eine aktualisierte Zonendatei erkennen können. IN NS ns1.example.org. Ein NS-Eintrag. Jeder Nameserver, der für eine Zone verantwortlich ist, muss über einen solchen Eintrag verfügen. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 Der Eintrag A bezieht sich auf Rechnernamen. ns1.example.org würde also zu 192.168.1.2 aufgelöst werden. IN A 192.168.1.1 Diese Zeile weist die IP-Adresse 192.168.1.1 dem aktuellen Ursprung, in unserem Fall also example.org, zu. www IN CNAME @ Der Eintrag für den kanonischen Namen wird dazu verwendet, Aliase für einen Rechner zu vergeben. Im Beispiel ist www ein Alias für den Master-Rechner, dessen Name dem Domainnamen example.org (oder 192.168.1.1) entspricht. CNAMEs können daher niemals gleichzeitig mit einem anderen Eintrag für denselben Hostname eingerichtet werden. MX-Eintrag IN MX 10 mail.example.org. Die Option MX legt fest, welcher Mailserver für eintreffende Mails der Zone verantwortlich ist. mail.example.org ist der Rechnername des Mailservers, der eine Priorität von 10 hat. Es können auch mehrere Mailserver mit verschiedener Priorität (10, 20, ...) vorhanden sein. Ein Mailserver, der eine Mail an example.org verschicken will, verwendet zuerst den MX mit der höchsten Priorität (das heißt den mit der niedrigsten Prioritätsnummer), danach den mit der nächsthöheren Priorität. Und dies solange, bis die E-Mail zugestellt werden kann. Für (bei Reverse-DNS verwendete) in-addr.arpa-Zonendateien wird das gleiche Format verwendet. Der einzige Unterschied besteht in der Verwendung der Option PTR an Stelle der Optionen A und CNAME. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 300 ) ; Negative Response TTL IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. Durch diese Datei werden den Rechnernamen der fiktiven Domäne IP-Adressen zugewiesen. Beachten Sie bitte, dass es sich bei allen Namen auf der rechten Seite eines PTR-Eintrags um absolute (fully qualified) Domainnamen handeln muss, die mit . enden. Zwischenspeichernde (cachende) Nameserver BIND Zwischenspeichernde Nameserver Ein cachender Nameserver hat primär die Aufgabe, rekursive Abfragen aufzulösen. Er stellt lediglich eigene Anfragen und speichert deren Ergebnisse ab. <acronym role="Doman Name Security Extensions">DNSSEC</acronym> BIND DNS security extensions Domain Name System Security Extensions, oder kurz DNSSEC, ist eine Sammlung von Spezifikationen, um auflösende Nameserver von gefälschten DNS-Daten, wie beispielsweise vorgetäuschte DNS-Einträge, zu schützen. Durch die Verwendung von digitalen Signaturen kann ein Resolver die Integrität des Eintrages überprüfen. Wichtig dabei ist, dass DNSSEC nur die Integrität über digital signierte Resource Records (RRe) bereitstellt. Weder wird die Vertraulichkeit noch der Schutz vor falschen Annahmen des Endbenutzers sichergestellt. Dies bedeutet, dass es Leute nicht davor schützen kann, zu example.net anstatt zu example.com zu gelangen. Das einzige, was DNSSEC tut, ist die Authentifizierung, dass die Daten während der Übertragung nicht verändert wurden. Die Sicherheit von DNS ist ein wichtiger Schritt in der generellen Absicherung des Internets. Für weitere, tiefergehende Details über die Funktionsweise von DNSSEC sind die dazugehörigen RFCs ein guter Einstieg in die Thematik. Sehen Sie sich dazu die Liste in an. Der folgende Abschnitt wird zeigen, wie man DNSSEC für einen autoritativen DNS-Server und einen rekursiven (oder cachenden) DNS-Server, der jeweils BIND 9 verwenden, einrichten kann. Obwohl alle Versionen von BIND 9 DNSSEC unterstützen, ist es notwendig, mindestens die Version 9.6.2 zu verwenden, um in der Lage zu sein, die signierten Root-Zonen zu benutzen, wenn DNS-Abfragen geprüft werden. Der Grund dafür ist, dass früheren Versionen die Algorithmen fehlen, um die Überprüfung des Root-Zonenschlüssels zu aktivieren. Es wird dringend empfohlen, die letzte Version von BIND 9.7 oder höher einzusetzen, um von den Vorteilen der automatischen Schlüsselaktualisierung des Root-Zonenschlüssels Gebrauch zu machen, genauso wie andere Eigenschaften, um automatisch Zonen signieren zu lassen und Signaturen aktuell zu halten. Unterschiede zwischen den Versionen 9.6.2 und 9.7 und höher werden an den betreffenden Stellen angesprochen. Rekursive <acronym>DNS</acronym>-Server Konfiguration Die Aktivierung der DNSSEC-Überprüfung von Anfragen, die von einem rekursiven DNS-Server stammen, benötigt ein paar Änderungen in der named.conf. Bevor man jedoch diese Änderungen durchführt, muss der Root-Zonenschlüssel oder Vertrauensanker erworben werden. Momentan ist der Root-Zonenschlüssel nicht in einem Dateiformat verfügbar, dass von BIND benutzt werden kann, so dass dieser manuell in das richtige Format konvertiert werden muss. Der Schlüssel selbst kann durch Abfrage an die Root-Zone erhalten werden, indem man dazu dig verwendet. Durch Aufruf von &prompt.user; dig +multi +noall +answer DNSKEY . > root.dnskey wird der Schlüssel in root.dnskey abgelegt. Der Inhalt sollte so ähnlich wie folgt aussehen: . 93910 IN DNSKEY 257 3 8 ( AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3 LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= ) ; key id = 19036 . 93910 IN DNSKEY 256 3 8 ( AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69Hf UyuGBbRN0+HuTOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjE g58sRr4ZQ6Iu6b1xTBKgc193zUARk4mmQ/PPGxn7Cn5V EGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlFrXDW3tjt ) ; key id = 34525 Seien Sie nicht alarmiert, wenn der von Ihnen bezogene Schlüssel anders als in diesem Beispiel aussieht. Diese könnten sich in der Zwischenzeit geändert haben. In dieser Ausgabe sind eigentlich zwei Schlüssel enthalten. Der erste Schüssel mit dem Wert 257 nach dem DNSKEY-Eintrag ist derjenige, der benötigt wird. Der Wert zeigt an, dass es sich um einen sicheren Einstiegspunkt (SEP), gemein auch als Schlüsselsignierungsschlüssel (KSK) bekannt, handelt. Der zweite Schüssel mit dem Wert 256 ist der untergeordnete Schlüssel, im allgemeinen auch als Zonen-Signaturschlüssel (ZSK) bezeichnet. Weitere Schlüsselarten werden später in erläutert. Nun muss der Schlüssel verifiziert und so formatiert werden, dass BIND diesen verwenden kann. Um den Schlüssel zu verifizieren, erzeugen Sie einen DS RR-Satz. Erstellen Sie eine Datei, welche die RRs enthält, mittels &prompt.user; dnssec-dsfromkey -f root-dnskey . > root.ds Diese Einträge verwenden SHA-1 sowie SHA-256 und sollten ähnlich zu folgendem Beispiel aussehen, in dem der längere, SHA-256, benutzt wird. . IN DS 19036 8 1 B256BD09DC8DD59F0E0F0D8541B8328DD986DF6E . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 Der SHA-256 RR kann nun mit dem Abriss in https://data.iana.org/root-anchors/root-anchors.xml verglichen werden. Um absolut sicher zu sein, dass der Schlüssel nicht zusammen mit den XML-Daten verändert wurde, kann die Datei mittels der PGP Signatur in https://data.iana.org/root-anchors/root-anchors.asc überprüft werden. Als nächstes muss der Schlüssel in das passende Format gebracht werden. Dies unterscheidet sich ein bisschen von den BIND Versionen 9.6.2 und 9.7 und höhere. In Version 9.7 wurde die Ünterstützung zur automatischen Verfolgung und notwendigen Aktualisierung von Änderungen am Schlüssel eingebaut. Dies wird durch den Einsatz von managed-keys erreicht, wie in dem Beispiel unten gezeigt ist. Wenn die ältere Version eingesetzt wird, kann der Schlüssel durch eine trusted-keys-Anweisung eingebaut werden und die Aktualisierung muss händisch erfolgen. In BIND 9.6.2 sollte das Format folgendermassen aussehen: trusted-keys { "." 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; In 9.7 wird das Format stattdessen wie folgt aussehen: managed-keys { "." initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; }; Der Root-Schlüssel kann nun zu named.conf hinzugefügt werden, entweder direkt oder durch Inkludierung der Datei, die den Schlüssel enthält. Nachdem diese Schritte absolviert sind, muss BIND konfiguriert werden, um DNSSEC-Validierung für Anfragen durchzuführen, indem named.conf bearbeitet und die folgende options-Direktive hinzugefügt wird: dnssec-enable yes; dnssec-validation yes; Um zu prüfen, dass es tatsächlich funktioniert, benutzen Sie dig, um eine Anfrage zu einer signierten Zone durch den Resolver, der gerade konfiguriert wurde, zu stellen. Eine erfolgreiche Antwort wird den AD-Eintrag aufweisen, um anzudeuten, dass die Daten authentisiert sind. Eine Anfrage wie &prompt.user; dig @resolver +dnssec se ds sollte den DS RR für die .se-Zone zurückgeben. In dem Abschnitt flags: sollte der AD-Eintrag gesetzt sein, wie im folgenden zu sehen ist: ... ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ... Der Resolver ist nun in der Lage, Anfragen ans DNS zu authentisieren. Autoritative <acronym>DNS</acronym>-Server Konfiguration Um einen autoritativen Nameserver dazu zu bringen, als eine DNSSEC-signierte Zone zu fungieren, ist ein wenig mehr Aufwand nötig. Eine Zone ist durch kryptographische Schlüssel signiert, die erzeugt werden müssen. Es ist möglich, nur einen Schlüssel dazu zu verwenden. Die vorgeschlagene Methode ist jedoch, einen starken, gut geschützten Schlüsselsignierungsschlüssel (KSK) einzusetzen, der nicht oft gewechselt wird und einen Zonensignierungsschlüssel (ZSK), der öfter ausgewechselt wird. Informationen zu vorgeschlagenen Einsatzarten können in RFC 4641: DNSSEC Operational Practices nachgelesen werden. Einsatzszenarien, welche die Root-Zone betreffen, finden Sie in DNSSEC Practice Statement for the Root Zone KSK operator sowie DNSSEC Practice Statement for the Root Zone ZSK operator. Der KSK wird dazu verwendet, um eine Kette von Autorität für die Daten, die diese Validierung benötigen, zu erschaffen und wird als solche auch als sicherer Einstiegspunkt (SEP)-Schlüssel bezeichnet. Ein Nachrichtenabriss dieses Schlüssels, der auch Delegation Signer (DS)-Eintrag genannt wird, muss in der Elternzone veröffentlicht werden, um die Vertrauenskette herzustellen. Wie dies erreicht wird, hängt von dem Besitzer der Elternzone ab. Der ZSK wird verwendet, um die Zone zu signieren und muss nur dort öffentlich zugänglich gemacht werden. Um DNSSEC für die example.com-Zone, welche in den vorherigen Beispielen verwendet wird, zu aktivieren, muss als erster Schritt dnssec-keygen benutzt werden, um das KSK und ZSK Schlüsselpaar zu generieren. Dieses Schlüsselpaar kann unterschiedliche kryptographische Algorithmen nutzen. Es wird empfohlen, RSA/SHA256 für die Schlüssel zu nutzen. Eine Schlüssellänge von 2048 Bits sollte genügen. Um den KSK für example.com zu generieren, geben Sie &prompt.user; dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.com ein und um den ZSK zu erzeugen, setzen Sie folgenden Befehl ab: &prompt.user; dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com dnssec-keygen gibt zwei Dateien aus, den öffentlichen und den privaten Schlüssel und zwar in Dateinamen, die ähnlich lauten wie Kexample.com.+005+nnnnn.key (öffentlich) und Kexample.com.+005+nnnnn.private (privat). Der nnnnn-Teil des Dateinamens ist eine fünfstellige Schlüsselkennung. Passen Sie genau auf, welche Kennung zu welchem Schlüssel gehört. Das ist besonders wichtig, wenn mehrere Schlüssel in einer Zone vorliegen. Es ist auch möglich, die Schlüssel umzubenennen. Für jede KSK-Datei tun Sie folgendes: &prompt.user; mv Kexample.com.+005+nnnnn.key Kexample.com.+005+nnnnn.KSK.key &prompt.user; mv Kexample.com.+005+nnnnn.private Kexample.com.+005+nnnnn.KSK.private Für die ZSK-Dateien ersetzen Sie KSK für ZSK wenn nötig. Die Dateien können nun in der Zonendatei inkludiert werden, indem die $include Anweisung verwendet wird. Es sollte folgendermassen aussehen: $include Kexample.com.+005+nnnnn.KSK.key ; KSK $include Kexample.com.+005+nnnnn.ZSK.key ; ZSK Schliesslich signieren Sie die Zone und weisen BIND an, die signierte Zonendatei zu benutzen. Um eine Zone zu signieren, wird dnssec-signzone eingesetzt. Der Befehl, um eine Zone example.com zu signieren, die in example.com.db liegt, sollte wie folgt aussehen: &prompt.user; dnssec-signzone -o example.com -k Kexample.com.+005+nnnnn.KSK example.com.db Kexample.com.+005+nnnnn.ZSK.key Der Schlüssel, welcher mit dem Argument übergeben wird, ist der KSK und die andere Schlüsseldatei ist der ZSK, welcher für die Signatur benutzt werden soll. Es ist möglich, mehr als einen KSK und ZSK anzugeben, was das Ergebnis zur Folge hat, dass die Zone mit allen übergebenen Schlüsseln signiert wird. Dies kann dann benötigt werden, um Zonendaten mit mehr als einem Algorithmus zur Signierung zu verwenden. Die Ausgabe von dnssec-signzone ist eine Zonendatei mit allen signierten RRs. Diese Ausgabe wird in einer Datei mit der Endung .signed abgelegt, wie beispielsweise example.com.db.signed. Die DS-Einträge werden ebenfalls in eine separate Datei dsset-example.com geschrieben. Um diese signierte Zone zu verwenden, ändern Sie die Zonendirektive in named.conf, so dass example.com.db.signed benutzt wird. Standardmässig sind die Signaturen nur 30 Tage gültig, was bedeutet, dass die Zone in etwa 15 Tagen erneut signiert werden muss, um sicher zu stellen, dass Resolver keine Einträge mit veralteten Signaturen zwischenspeichern. Es ist möglich, ein Skript und einen cron-Job zu schreiben, um dies zu erledigen. Lesen Sie dazu die relevanten Anleitungen, um Details zu erfahren. Stellen Sie sicher, dass die privaten Schlüssel vertraulich bleiben, genau wie mit allen anderen kryptographischen Schlüsseln auch. Wenn ein Schlüssel geändert wird, ist es gute Praxis den neuen Schlüssel in die Zone zu inkludieren, noch während der alte Schlüssel noch zum signieren eingesetzt wird, um dann auf den neuen Schlüssel zum signieren zu wechseln. Nachdem diese Schritte erfolgt sind, kann der alte Schlüssel aus der Zone entfernt werden. Wenn das nicht geschieht, können DNS-Daten für einige Zeit nicht verfügbar sein, bis der neue Schlüssel durch die DNS-Hierarchie propagiert wurde. Für weitere Informationen bezüglich Schlüsselübergabe und andere DNSSEC-Einsatzszenarien lesen Sie RFC 4641: DNSSEC Operational practices. Automatisierung mittels <acronym>BIND</acronym> 9.7 oder höher Beginnend mit der Version 9.7 von BIND wurde eine neue Eigenschaft vorgestellt, die Smart Signing genannt wird. Diese zielt darauf ab, das Schlüsselmanagement und den Signierungsprozess einfacher zu gestalten und zu automatisieren. Durch ablegen der Schlüssel in ein Verzeichnis, genannt key repository und die Verwendung der neuen Option auto-dnssec, ist es möglich eine dynamische Zone zu erzeugen, welche dann erneut signiert wird, wenn dazu der Bedarf besteht. Um diese Zone zu aktualisieren, benutzen Sie nsupdate mit der neuen Option . Es hat also rndc die Fähigkeit gewonnen, Zonen mit Schlüsseln im Key Repository zu verwenden, indem die Option eingesetzt wird. Um BIND anzuweisen, diese automatische Signierung und Zonenaktualisierung für example.com zu nutzen, fügen Sie die folgenden Zeilen zur named.conf hinzu: zone example.com { type master; key-directory "/etc/named/keys"; update-policy local; auto-dnssec maintain; file "/etc/named/dynamic/example.com.zone"; }; Nachdem diese Änderungen durchgeführt wurden, erzeugen Sie die Schlüssel für die Zone wie in beschrieben wird, legen diese Schlüssel im Key Repository ab, dass als Argument key-directory in der Zonenkonfiguration steht und die Zone wird automatisch signiert. Aktualisierungen für eine Zone, die auf diese Art und Weise konfiguriert wurde, muss mittels nsupdate erfolgen, dass sich um die erneute Signierung der Zone mit den hinzugefügten Daten kümmern wird. Für weitere Details, lesen Sie und die Dokumentation von BIND. Sicherheit Obwohl BIND die am meisten verwendete (und kontrollierte) Implementierung von DNS darstellt, werden dennoch manchmal neue Sicherheitsprobleme entdeckt. Zwar startet &os; named automatisch in einer &man.chroot.8;-Umgebung, es gibt aber noch weitere Sicherheitsmechanismen, mit denen Sie potentielle DNS-Serviceattacken erschweren können. Es ist daher eine gute Idee, die Sicherheitshinweise von CERT zu lesen sowie die Mailingliste &a.security-notifications; zu abonnieren, um sich über Sicherheitsprobleme im Zusammenhang mit dem Internet und FreeBSD zu informieren. Tritt ein Problem auf, kann es nie schaden, die Quellen zu aktualisieren und named neu zu kompilieren. Weitere Informationsquellen Hilfeseiten zu BIND/named: &man.rndc.8; &man.named.8; &man.named.conf.5; &man.nsupdate.8; &man.dnssec-signzone.8; &man.dnssec-keygen.8; Offizielle ISC-Seite zu BIND Offizielles Forum zu ISC- BIND O'Reilly DNS and BIND 5th Edition Root DNSSEC DNSSEC Vertrauensanker-Publikation für die Root-Zone RFC1034 - Domain Names - Concepts and Facilities RFC1035 - Domain Names - Implementation and Specification RFC4033 - DNS Security Introduction and Requirements RFC4034 - Resource Records for the DNS Security Extensions RFC4035 - Protocol Modifications for the DNS Security Extensions RFC4641 - DNSSEC Operational Practices RFC 5011 - Automated Updates of DNS Security (DNSSEC) Trust Anchors Der Apache HTTP-Server MurrayStokelyBeigetragen von Webserver konfigurieren Apache Überblick Einige der weltgrößten Internetauftritte laufen unter &os;. Die Mehrzahl der Webserver im Internet nutzt den Apache HTTP-Server. Die Installationspakete für den Apache sollten auf Ihrem Installationsmedium vorhanden sein. Wenn Sie den Apache noch nicht installiert haben, können Sie dies jederzeit über den Port www/apache22 nachholen. Nachdem der Apache erfolgreich installiert wurde, muss er noch konfiguriert werden. Dieser Abschnitt beschreibt die Version 2.2.X des Apache HTTP-Servers, da diese Version unter &os; am häufigsten verwendet wird. Weiterführende Informationen zu Apache 2.X finden Sie auf http://httpd.apache.org/. Konfiguration Apache Konfigurationsdatei Der Apache HTTP-Server wird unter &os; primär über die Datei /usr/local/etc/apache22/httpd.conf konfiguriert. Bei dieser Datei handelt es sich um eine typische &unix;-Konfigurationsdatei, in der Kommentarzeilen mit einem #-Zeichen beginnen. Eine komplette Beschreibung aller Optionen würde den Rahmen dieses Handbuchs sprengen, daher beschreiben wir hier nur die am häufigsten verwendeten Optionen. ServerRoot "/usr/local" Legt das Standardwurzelverzeichnis für die Apache-Installation fest. Binärdateien werden in die Verzeichnisse bin und sbin unterhalb des Serverwurzelverzeichnisses installiert, während sich Konfigurationsdateien im Verzeichnis etc/apache befinden. ServerAdmin you@your.address Die E-Mail-Adresse, an die Mitteilungen über Serverprobleme geschickt werden sollen. Diese Adresse erscheint auf vom Server erzeugten Seiten, beispielsweise auf Fehlerseiten. ServerName www.example.com Über die Option ServerName können Sie einen Rechnernamen festlegen, den Ihr Server an die Clients sendet, wenn sich dieser von tatsächlichen Rechnernamen unterscheidet (sie könnten etwa www statt des richtigen Rechnernamens verwenden). DocumentRoot "/usr/local/www/apache22/data" DocumentRoot: Das Verzeichnis, in dem Sie Ihre Dokumente ablegen. In der Voreinstellung befinden sich alle Seiten in diesem Verzeichnis, durch symbolische Links oder Aliase lassen sich aber auch andere Orte festlegen. Es ist empfehlenswert, eine Sicherungskopie Ihrer Konfigurationsdatei anzulegen, bevor Sie Änderungen durchführen. Nachdem Sie die Konfiguration beendet haben, können Sie den Apache starten. Den <application>Apache</application> betreiben Apache Starten oder Beenden Der www/apache22 Port installiert ein &man.rc.8; Skript, welches zum starten, stoppen und neustarten von Apache benutzt werden kann. Das Skript befindet sich im Verzeichnis /usr/local/etc/rc.d/. Um den Apache beim Systemstart zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein: apache22_enable="YES" Wenn Sie während des Systemstarts weitere Parameter an den Apache übergeben wollen, können Sie diese durch eine zusätzliche Zeile in rc.conf angeben: apache22_flags="" Die Konfiguration von Apache kann vor dem ersten Start des httpd-Daemon, oder bei nachfolgenden Änderungen an der Konfigurationsdatei bei laufendem httpd, auf Fehler überprüft werden. Dies kann durch das &man.rc.8;-Skript direkt , oder über das Dienstprogramm &man.service.8; geschehen, indem Sie eines der folgenden Kommandos ausführen: &prompt.root; /usr/local/etc/rc.d/apache22 configtest &prompt.root; service apache22 configtest Es ist wichitg zu beachten, dass configtest kein &man.rc.8;-Standard ist, und somit nicht zwingend mit anderen &man.rc.8;-Startskripten funktioniert. Wenn der Apache keine Fehler in der Konfiguration meldet, kann der Apache  httpd mit den gleichen &man.rc.8; und &man.service.8; Mechanismen gestartet werden: &prompt.root; /usr/local/etc/rc.d/apache22 start &prompt.root; service apache22 start Sie können den httpd-Dienst testen, indem Sie http://localhost in Ihren Browser eingeben, wobei Sie localhost durch den vollqualifizierten Domainnamen der Machine ersetzen, auf dem der httpd läuft. Die Standard Webseite, die angezeigt wird, ist /usr/local/www/apache22 /data/index.html. Virtual Hosting Der Apache unterstützt zwei Formen des Virtual Hostings. Die erste Möglichkeit bezeichnet man als namenbasiertes virtuelles Hosting. Dabei wird der HTTP/1.1-Header der Clients dazu verwendet, den Rechnernamen zu bestimmen. Dadurch wird es möglich, mehrere Domains unter der gleichen IP-Adresse zu betreiben. Damit der Apache namenbasierte virtuelle Domains verwalten kann, fügen Sie die folgende Zeile in httpd.conf ein: NameVirtualHost * Wenn Ihr Webserver www.domain.tld heißt und Sie die virtuelle Domain www.someotherdomain.tld einrichten wollen, ergänzen Sie httpd.conf um folgende Einträge: <VirtualHost *> ServerName www.domain.tld DocumentRoot /www/domain.tld </VirtualHost> <VirtualHost *> ServerName www.someotherdomain.tld DocumentRoot /www/someotherdomain.tld </VirtualHost> Ersetzen Sie dabei die Adressen sowie den Pfad zu den Dokumenten durch Ihre eigenen Einstellungen. Ausführliche Informationen zum Einrichten von virtuellen Domains finden Sie in der offiziellen Apache-Dokumentation unter http://httpd.apache.org/docs/vhosts/. Häufig verwendete Apache-Module Apache Module Es gibt viele verschiedene Apache-Module, die den Server um zusätzliche Funktionen erweitern. Die FreeBSD-Ports-Sammlung ermöglicht es Ihnen, den Apache gemeinsam mit einigen der beliebtesten Zusatzmodule zu installieren. <application>mod_ssl</application> Webserver Verschlüsselung SSL Verschlüsselung Das Modul mod_ssl verwendet die OpenSSL-Bibliothek, um, unter Nutzung der Protokolle Secure Sockets Layer (SSL v2/v3) sowie Transport Layer Security (TLS v1) starke Verschlüsselung zu ermöglichen. Durch dieses Modul können Sie ein signiertes Zertifikat von einer Zertifizierungsstelle anfordern, damit Sie einen sicheren Webserver unter &os; betreiben können. Das Modul mod_ssl wird standardmäßig kompiliert, kann aber auch noch nachträglich durch die Angabe von -DWITH_SSL zur Kompilierzeit aktiviert werden. Skriptsprachen Für die wichtigsten Skriptsprachen existieren Module, die es erlauben, Apache-Module nahezu vollständig in einer Skriptsprache zu programmieren. Derartige Module dienen oft dazu, einen Sprach-Interpreter in den Webserver einzubetten. Dadurch wird ein zusätzlicher externer Interpreter überflüssig, was die Startzeit von dynamischen Internetseiten deutlich verringert. Dynamische Webseiten Webserver dynamisch In den vergangenen Jahren haben immer mehr Unternehmen das Internet als Mittel für die Steigerung ihrer Einnahmen sowie für die Erhöhung ihrer Reichweite entdeckt. Dadurch stieg auch die Nachfrage nach interaktiven Internetinhalten. Neben einigen Unternehmen, darunter µsoft;, die dafür proprietäre Produkte entwickelt haben, hat auch die Open Source Community auf diesen Umstand reagiert und unter anderem mit Django, Ruby on Rails, mod_perl2, und mod_php Möglichkeiten zur Generierung dynamischer Internetseiten geschaffen. Django Python Django Bei Django handelt es sich um ein unter der BSD-Lizenz verfügbares Framework zur schnellen Erstellung von mächtigen Internet-Applikationen. Es beinhaltet einen objekt-relationalen Mapper (wodurch Datentypen als Phyton-Objekte entwickelt werden können) sowie eine API für den dynamischen Datenbankzugriff auf diese Objekte, ohne dass Entwickler jemals SQL-Code schreiben müssen. Zusätzlich existiert ein umfangreiches Template-System, wodurch die Programmlogik von der HTML-Präsentation getrennt werden kann. Django setzt das Modul mod_python, den Apache-Webserver sowie eine SQL-Datenbank voraus. Für FreeBSD gibt es einen Port, der alle Abhängigkeiten mit sinnvollen Optionen konfiguriert und installiert. Django mit <application>Apache2</application>, <application>mod_python3</application>, und <application>PostgreSQL</application> installieren &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Nachdem Django (sowie die abhängigen Pakete) installiert ist, müssen Sie ein Projektverzeichnis erstellen. Danach konfigurieren Sie Apache so, dass der eingebettete Python-Interpreter spezifische URLs Ihrer Seiten aufruft. Apache-Konfiguration für Django/mod_python Sie müssen die Apache-Konfigurationsdatei httpd.conf anpassen, damit Apache Anfragen für bestimmte URLs an Ihre Internet-Applikation übergibt: <Location "/"> SetHandler python-program PythonPath "['/dir/to/your/django/packages/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails Bei Ruby on Rails handelt es sich um ein weiteres, als Open Source verfügbares Webframework. Es bietet einen kompletten Entwicklungsstack und erlaubt es Webentwicklern, umfangreiche und mächtige Applikationen in kurzer Zeit zu programmieren. Das Framework kann über die Ports-Sammlung installiert werden. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean <application>mod_perl2</application> mod_perl2 Perl Die Kombination Apache/Perl vereinigt die Vorteile der Programmiersprache Perl und des Apache HTTP-Servers. Durch das Modul mod_perl2 ist es möglich, vollständig in Perl geschriebene Apache-Module zu erzeugen. Da der Perl-Interpreter in den Server eingebettet wird, müssen Sie weder einen externen Interpreter noch Perl zusätzlich aufrufen. mod_perl2 ist über den Port www/mod_perl2 erhältlich. mod_php TomRhodesGeschrieben von mod_php PHP Bei PHP, dem Hypertext Preprocessor, handelt es sich um eine vielseitig verwendbare Skriptsprache, die besonders für die Internetprogrammierung geeignet ist. PHP kann in HTML eingebettet werden und ähnelt von der Syntax her Sprachen wie C, &java; und Perl. Das Hauptanliegen von PHP ist es, Internetprogrammierern die rasche Erstellung von dynamisch erzeugten Internetseiten zu ermöglichen. Damit Ihr System PHP5 unterstützt, müssen Sie als Erstes den Apache Webserver über den Port lang/php5 installieren. Wenn Sie den Port lang/php5 das erste Mal installieren, werden die verfügbaren Optionen (OPTIONS) automatisch angezeigt. Erscheint das Konfigurationsmenü bei Ihnen nicht, so liegt dies daran, dass Sie den Port lang/php5 schon einmal auf Ihrem System installiert hatten. Es ist aber jederzeit möglich, dieses Menü aus dem Ports-Verzeichnis heraus über folgenden Befehl erneut aufzurufen: &prompt.root; make config In diesem Konfigurationsmenü müssen Sie die Option APACHE auswählen, damit mod_php5 als ein vom Apache-Webserver ladbares Modul gebaut wird. Viele Seiten verwenden nach wie vor (beispielsweise wegen der benötigten Kompatibilität zu bereits vorhandenen Web-Applikationen) PHP4. Ist dies bei Ihnen der Fall, so müssen Sie statt mod_php5 mod_php4 über den Port lang/php4 installieren. Der Port lang/php4 unterstützt viele der Konfigurations- und Laufzeitoptionen von lang/php5. Dieser Port installiert und konfiguriert die Module, die für die Unterstützung von dynamischen PHP-Anwendungen benötigt werden. Stellen Sie danach sicher, dass Ihre /usr/local/etc/apache22/httpd.conf die folgenden Abschnitte enthält: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Nachdem dies erledigt ist, rufen Sie apachectl auf, um das PHP-Modul zu laden: &prompt.root; apachectl graceful Bei künftigen Upgrades von PHP wird make config nicht mehr benötigt, da die von Ihnen ursprünglich ausgewählten Optionen (OPTIONS) vom &os;-Ports-Framework automatisch gespeichert werden. Die PHP-Unterstützung von &os; ist stark modular aufgebaut, daher verfügt eine Basisinstallation nur über wenige Funktionen. Eine Erweiterung um zusätzliche Funktionen ist allerdings sehr einfach über den Port lang/php5-extensions möglich. Der Port bietet Ihnen ein Auswahlmenü, über das Sie verschiedene PHP-Erweiterungen installieren können. Alternativ können Sie einzelne Erweiterungen aber weiterhin direkt über den jeweiligen Port installieren. Um beispielsweise die Unterstützung des Datenbankservers MySQL in PHP5 zu aktivieren, installieren Sie den Port databases/php5-mysql. Nachdem Sie eine Erweiterung installiert haben, müssen Sie den Apache-Server neu starten, damit die Erweiterung auch erkannt wird: &prompt.root; apachectl graceful Ab nun wird MySQL von PHP unterstützt. FTP – File Transfer Protocol MurrayStokelyBeigetragen von FTP-Server Überblick Das File Transfer Protocol (FTP) ermöglicht auf einfache Art und Weise den Dateiaustausch mit einem FTP-Server. Der FTP-Server ftpd ist bei &os; bereits im Basisystem enthalten. Daher sind Konfiguration und Betrieb eines FTP-Servers unter FreeBSD relativ einfach. Konfiguration Der wichtigste Punkt ist hier die Entscheidung darüber, welche Benutzer auf Ihren FTP-Server zugreifen dürfen. Ein FreeBSD-System verfügt über diverse Systembenutzerkonten, um einzelnen Daemonen den Zugriff auf das System zu ermöglichen. Anonyme Benutzer sollten sich allerdings nicht über diese Benutzerkonten anmelden dürfen. Die Datei /etc/ftpusers enthält alle Benutzer, die vom FTP-Zugriff ausgeschlossen sind. In der Voreinstellung gilt dies auch die gerade erwähnten Systembenutzerkonten. Sie können über diese Datei weitere Benutzer vom FTP-Zugriff ausschließen. Sie können den Zugriff für einige Benutzer einschränken, ohne FTP komplett zu verbieten. Dazu passen Sie /etc/ftpchroot entsprechend an. Diese Datei enthält Benutzer und Gruppen sowie die für sie geltenden FTP-Einschränkungen und wird in &man.ftpchroot.5; ausführlich beschrieben. FTP anonymous Wenn Sie einen anonymen FTP-Zugriff auf Ihren Server ermöglichen wollen, müssen Sie den Benutzer ftp auf Ihrem &os;-System anlegen. Danach können sich Benutzer mit dem Benutzernamen ftp oder anonymous auf Ihrem FTP-Server anmelden. Das Passwort ist dabei beliebig (allerdings wird dazu in der Regel eine E-Mail-Adresse verwendet). Meldet sich ein anonymer Benutzer an, aktiviert der FTP-Server &man.chroot.2;, um den Zugriff auf das Heimatverzeichnis des Benutzers ftp zu beschränken. Es gibt zwei Textdateien, deren Inhalt Sie bei der Anmeldung an Ihrem FTP-Server anzeigen lassen können. Der Inhalt von /etc/ftpwelcome wird angezeigt, bevor der Login-Prompt erscheint. Nach einer erfolgreichen Anmeldung wird der Inhalt von /etc/ftpmotd angezeigt. Beachten Sie aber, dass es dabei um einen Pfad relativ zur Umgebung des anzumeldenden Benutzers handelt. Bei einer anonymen Anmeldung würde also die Datei ~ftp/etc/ftpmotd angezeigt. Nachdem Sie den FTP-Server konfiguriert haben, müssen Sie Ihn in /etc/inetd.conf aktivieren. Dazu müssen Sie lediglich das Kommentarsymbol # am Beginn der bereits vorhandenen ftpd-Zeile entfernen: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Nachdem Sie diese Änderung durchgeführt haben, müssen Sie, wie in beschrieben, die inetd-Konfiguration neu einlesen. Lesen Sie bitte Abschnitt des Handbuchs für weitere Informationen zur Aktivierung von inetd auf Ihren System. Alternativ können Sie auch nur den ftpd-Server starten. In diesem Fall ist es ausreichend, die entsprechende Variable in der Datei /etc/rc.conf zu setzen: ftpd_enable="YES" Nachdem Sie diese Variable gesetzt haben, wird künftig beim Systemstart nur der FTP-Server gestartet. Alternativ können Sie den Server auch manuell starten, indem Sie als Benutzer root den folgenden Befehl ausführen: &prompt.root; /etc/rc.d/ftpd start Danach können Sie sich auf Ihrem FTP-Server anmelden: &prompt.user; ftp localhost Wartung syslog Logdateien FTP Der ftpd-Daemon verwendet &man.syslog.3;, um Protokolldateien zu erstellen. In der Voreinstellung werden alle FTP betreffenden Nachrichten in die Datei /var/log/xferlog geschrieben. Dies lässt sich aber durch das Einfügen der folgenden Zeile in /etc/syslog.conf ändern: ftp.info /var/log/xferlog FTP anonymous Beachten Sie, dass mit dem Betrieb eines anonymen FTP-Servers verschiedene Sicherheitsrisiken verbunden sind. Problematisch ist hier vor allem die Erlaubnis zum anonymen Upload von Dateien. Dadurch könnte Ihr Server zur Verbreitung von illegaler oder nicht lizensierter Software oder noch Schlimmeren missbraucht werden. Wollen Sie anonyme Uploads dennoch erlauben, sollten Sie die Zugriffsrechte so setzen, dass solche Dateien erst nach Ihrer Zustimmung von anderen Benutzern heruntergeladen werden können. Mit Samba einen Datei- und Druckserver für µsoft.windows;-Clients einrichten MurrayStokelyBeigetragen von Samba-Server Microsoft Windows Dateiserver Windows-Clients Druckserver Windows-Clients Überblick Samba ist ein beliebtes Open Source-Softwarepaket, das es Ihnen ermöglicht, einen Datei- und Druckserver für µsoft.windows;-Clients einzurichten. Clients können sich dadurch mit einem FreeBSD-System verbinden und dessen Speicherplatz oder dessen Drucker verwenden. Dies genauso, als wenn es sich um lokale Drucker oder Festplatten handeln würde. Samba sollte als Softwarepaket auf Ihren Installationsmedien vorhanden sein. Wenn Sie Samba noch nicht installiert haben, können Sie dies jederzeit über den Port oder das Paket net/samba34 nachholen. Konfiguration Die Standardkonfigurationsdatei von Samba heißt /usr/local/share/examples/samba34/smb.conf.default. Diese Datei muss nach /usr/local/etc/smb.conf kopiert und angepasst werden, bevor Samba verwendet werden kann. Die Datei smb.conf enthält Laufzeitinformationen für Samba, beispielsweise Druckerdefinitionen oder filesystem shares, also Bereiche des Dateisystems, die Sie mit &windows;-Clients teilen wollen. Die Konfiguration der Datei smb.conf erfolgt webbasiert über das im Samba-Paket enthaltene Programm swat. Das Samba Web Administration Tool (SWAT) verwenden Das Samba Web Administration Tool (SWAT) wird als Daemon von inetd aktiviert. Daher müssen Sie den Kommentar vor der folgenden Zeile in /etc/inetd.conf entfernen, bevor Sie swat zur Konfiguration von Samba verwenden können: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Wie bereits in beschrieben, müssen Sie die inetd-Konfiguration neu einlesen, nachdem Sie diese Änderung durchgeführt haben. Nachdem swat in der Datei inetd.conf aktiviert wurde, rufen Sie in Ihrem Internetbrowser die Adresse http://localhost:901 auf und melden sich mit dem root-Benutzerkonto an. Nachdem Sie sich erfolgreich angemeldet haben, wird die Hauptkonfigurationseite von Samba geladen. Sie können nun die Dokumentation lesen, oder durch einen Klick auf die Globals-Karteikarte mit der Konfiguration beginnen. Die Einstellungen, die Sie hier vornehmen können, entsprechen denen des Abschnitts [global] von /usr/local/etc/smb.conf. Globale Einstellungen Unabhängig davon, ob Sie swat verwenden, oder /usr/local/etc/smb.conf direkt editieren, sollten Sie zuerst folgende Einstellungen anpassen: workgroup Der NT-Domänenname oder der Arbeitsgruppenname der Rechner, die auf den Server Zugriff haben sollen. netbios name NetBIOS Legt den NetBIOS-Namen fest, unter dem der Samba-Server bekannt ist. In der Regel handelt es sich dabei um den ersten Teil des DNS-Namens des Servers. server string Legt die Beschreibung fest, die angezeigt werden soll, wenn mit net view oder über andere Netzwerkprogramme Informationen über den Server angefordert werden. Samba absichern Zwei der wichtigsten Einstellungen in /usr/local/etc/smb.conf betreffen das zu verwendende Sicherheitsmodell sowie das Backend-Passwortformat für die Benutzer der Samba-Clients. Folgende Optionen sind dafür verantwortlich: security Die häufigsten Optionen sind security = share und security = user. Wenn Ihre Clients Benutzernamen verwenden, die den Benutzernamen auf Ihrem &os;-Rechner entsprechen, dann sollten Sie die Einstellung user level verwenden. Dies ist auch die Standardeinstellung. Allerdings ist es dazu erforderlich, dass sich die Clients auf Ihrem Rechner anmelden, bevor sie auf gemeinsame Ressourcen zugreifen können. In der Einstellung share level müssen sich Clients nicht unter Verwendung eines gültigen Logins auf Ihrem Rechner anmelden, bevor sie auf gemeinsame Ressourcen zugreifen können. In früheren Samba-Versionen war dies die Standardeinstellung. passdb backend NIS+ LDAP SQL database Samba erlaubt verschiedene Backend-Authentifizierungsmodelle. Sie können Clients durch LDAP, NIS+, eine SQL-Datenbank oder eine Passwortdatei authentifizieren. In der Voreinstellung wird smbpasswd verwendet. Diese Methode wird im folgenden Abschnitt näher beschrieben. Wenn Sie smbpasswd verwenden, müssen Sie die Datei /usr/local/etc/samba/smbpasswd erzeugen, damit Samba in der Lage ist, Clients zu authentifizieren. Wenn Sie auf Ihrem &unix;-Rechner vorhandenen Benutzern den Zugriff von einem &windows;-Client aus ermöglichen wollen, verwenden Sie den folgenden Befehl: &prompt.root; smbpasswd -a username Als Backend wird inzwischen tdbsam empfohlen. Mit dem folgenden Befehl legen Sie neue Benutzerkonten an: &prompt.root; pdbedit -a -u username Ausführliche Informationen zur Konfiguration von Samba finden Sie im Official Samba HOWTO. Sie sollten aber bereits nach dem Lesen dieses Abschnitts in der Lage sein, Samba zu starten. <application>Samba</application> starten Der Port net/samba34 legt ein neues Startskript an, mit dem Samba gesteuert (also etwa gestartet oder beendet) werden kann. Um dieses Skript zu aktivieren, fügen Sie folgende Zeile in /etc/rc.conf ein: samba_enable="YES" Alternativ können Sie auch die folgenden beiden Einträge verwenden: nmbd_enable="YES" smbd_enable="YES" Durch diese Einträge wird Samba beim Systemstart automatisch aktiviert. Danach können Sie Samba jederzeit durch folgenden Befehl starten: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Weitere Informationen zu den rc-Startskripten finden Sie im des Handbuchs. Samba verwendet drei Daemonen. Beachten Sie, dass sowohl nmbd als auch smbd durch das Skript samba gestartet werden. Wenn Sie die winbind name resolution services in smb.conf aktiviert haben, wird zusätzlich der winbindd-Daemon gestartet. Sie können Samba jederzeit durch den folgenden Befehl beenden: &prompt.root; /usr/local/etc/rc.d/samba stop Samba ist ein komplexes Softwarepaket mit umfassenden Funktionen, die eine weitreichende Integration von µsoft.windows;-Netzwerken ermöglichen. Für eine Beschreibung dieser Zusatzfunktionen sollten Sie sich auf http://www.samba.org umsehen. Die Uhrzeit mit NTP synchronisieren TomHukinsBeigetragen von NTP Überblick Da die interne Uhrzeit eines Computers nie ganz exakt ist, wurde mit NTP (Network Time Protocol) eine Möglichkeit geschaffen, die exakte Uhrzeit zu ermitteln und festzulegen. Viele Internetdienste sind von einer exakten Uhrzeit abhängig. Ein Webserver könnte beispielsweise die Anforderung erhalten, eine Datei zu versenden, wenn sich diese in einer bestimmten Zeitspanne geändert hat. In einem lokalen Netzwerk ist es unbedingt notwendig, dass Rechner, die Dateien von einem gemeinsamen Dateiserver beziehen, ihre Uhrzeit synchronisieren, damit die Zeitstempel der Dateien konstistent bleiben. Dienste wie &man.cron.8; führen Befehle zu einem bestimmten Zeitpunkt aus. Ist die Uhrzeit nicht korrekt, kann dies zu Problemen führen. NTP ntpd &os; verwendet den &man.ntpd.8;- NTP-Server, um die genaue Uhrzeit von anderen NTP-Servern abzufragen, die eigene Systemzeit zu setzen, oder um diese anderen Rechnern anzubieten. Einen passenden NTP-Server auswählen NTP Serverwahl Um die Uhrzeit zu synchronisieren, müssen Sie sich mit einem NTP-Server verbinden. Ihr Netzwerkadministrator oder Ihr Internetprovider haben vielleicht schon einen NTP-Server eingerichtet. Lesen Sie deren Dokumentation, um dies zu überprüfen. Es gibt im Internet eine Liste mit frei zugänglichen NTP-Servern, aus der Sie sich einen in Ihrer Nähe gelegenen Server auswählen können. Beachten Sie aber auf jeden Fall die Nutzungsbedingungen des entsprechenden Servers, und fragen Sie um Erlaubnis, wenn dies nötig ist. Die Auswahl von mehreren NTP-Servern kann sinnvoll sein, wenn ein Server ausfällt oder falsche Zeiten liefert. &man.ntpd.8; verwendet die Antworten anderer Server, um zuverlässige Server zu bestimmen, die dann bevorzugt abgefragt werden. NTP unter &os; einrichten NTP Konfiguration NTP aktivieren ntpdate Wenn Sie Ihre Uhrzeit nur beim Systemstart synchronisieren wollen, können Sie &man.ntpdate.8; verwenden. Für Desktoprechner, die regelmäßig neu gestartet werden und keine ständige Synchronisation benötigen, ist dies akzeptabel. In allen anderen Fällen sollten Sie jedoch &man.ntpd.8; verwenden. Die Ausführung von &man.ntpdate.8; während des Systemstarts ist aber auch für Rechner, die &man.ntpd.8; verwenden, sinnvoll. &man.ntpd.8; passt die Systemzeit nur bei größeren Abweichungen an, während &man.ntpdate.8; die Zeit immer synchronisiert, egal wie groß die Differenz zwischen Systemzeit und korrekter Zeit ist. Um &man.ntpdate.8; beim Systemstart zu aktivieren, fügen Sie den Eintrag ntpdate_enable="YES" in /etc/rc.conf ein. Außerdem müssen Sie alle Server, mit denen Sie sich synchronisieren wollen, sowie alle an &man.ntpdate.8; zu übergebenden Optionen in den ntpdate_flags angeben. NTP einrichten NTP ntp.conf Die Konfiguration von NTP erfolgt über die Datei /etc/ntp.conf, und wird in der Hilfeseite &man.ntp.conf.5; beschrieben. Dazu ein einfaches Beispiel: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift Die Option server legt die zu verwendenden Server fest, wobei jeder Server in einer eigenen Zeile steht. Wenn ein Server mit der Option prefer versehen ist, wie dies hier bei ntplocal.example.com der Fall ist, wird dieser Server bevorzugt verwendet. Eine Antwort von einem bevorzugten Server wird nur dann verworfen, wenn sie signifikant von denen anderer Server abweicht, ansonsten wird sie ohne Abfrage weiterer Server verwendet. Die Option prefer wird gewöhnlich nur für sehr zuverlässige und genaue Server verwendet, die über eine spezielle Hardware zur Zeitüberwachung verfügen. Die Option driftfile legt fest, in welcher Datei die Abweichungen der Systemuhr protokolliert werden. &man.ntpd.8; verwendet diese Datei, um die Systemzeit automatisch anzupassen, selbst wenn kurzzeitig kein NTP-Server zur Synchronisation verfügbar ist. Weiterhin legt die Option driftfile fest, wo Informationen über frühere Antworten des von Ihnen verwendeten NTP-Servers gespeichert werden sollen. Diese Datei enthält NTP-interne Informationen, sie sollte daher von anderen Prozessen nicht verändert werden. Den Zugang zu Ihrem NTP-Server beschränken In der Voreinstellung ist Ihr NTP-Server für alle Rechner im Internet erreichbar. Über die Option restrict in der Datei /etc/ntp.conf können Sie den Zugang zu Ihrem Server beschränken. Wenn Sie alle Rechner vom Zugriff auf Ihren NTP-Server ausschließen wollen, fügen Sie folgende Zeile in /etc/ntp.conf ein: restrict default ignore Durch diesen Eintrag verhindern Sie den Zugriff Ihres Servers auf alle auf Ihrem System konfigurierten Server. Müssen Sie Ihren NTP-Server mit einem externen NTP-Server synchronisieren, müssen Sie dies daher dezidiert zulassen. Lesen Sie in diesem Fall die Manualpage &man.ntp.conf.5;. Wenn Sie nur Rechnern Ihres eigenen Netzwerks die Synchronisation mit Ihrem NTP-Server erlauben, gleichzeitig aber verhindern wollen, dass diese den NTP-Server konfigurieren oder als Server für andere Rechner dienen können, fügen Sie folgende Zeile ein: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap Bei 192.168.1.0 handelt es sich um einen Rechner Ihres Netzwerks. 255.255.255.0 ist die Netzmaske Ihres Netzwerks. /etc/ntp.conf kann verschiedene restrict-Optionen enthalten. Weiteres erfahren Sie im Abschnitt Access Control Support der Hilfeseite &man.ntp.conf.5;. Den NTP-Server starten Damit der NTP-Server beim Systemstart automatisch gestartet wird, fügen Sie den Eintrag ntpd_enable="YES" in /etc/rc.conf ein. Wenn Sie weitere Argumente an &man.ntpd.8; übergeben wollen, passen Sie die Option ntpd_flags in der Datei /etc/rc.conf entsprechend an. Um den NTP-Server ohne einen Systemneustart zu starten, rufen Sie ntpd mit den unter ntpd_flags in /etc/rc.conf festgelegten Parametern auf. Hierzu ein Beispiel: &prompt.root; ntpd -p /var/run/ntpd.pid <application>ntpd</application> mit einer Einwahlverbindung verwenden &man.ntpd.8; benötigt keine ständige Internetverbindung. Wenn Sie sich ins Internet einwählen, ist es sinnvoll, zu verhindern, dass NTP-Verkehr eine Verbindung aufbauen oder aufrechterhalten kann. Wenn Sie user-PPP verwenden, können Sie dies in den filter-Direktiven von /etc/ppp/ppp.conf festlegen. Sehen Sie sich dazu das folgende Beispiel ein: set filter dial 0 deny udp src eq 123 # Prevent NTP traffic from initiating dial out set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Prevent incoming NTP traffic from keeping the connection open set filter alive 1 deny udp dst eq 123 # Prevent outgoing NTP traffic from keeping the connection open set filter alive 2 permit 0/0 0/0 Weitere Informationen finden Sie im Abschnitt PACKET FILTERING von &man.ppp.8; sowie in den Beispielen unter /usr/share/examples/ppp/. Einige Internetprovider blockieren Ports mit niedrigen Nummern. In solchen Fällen funktioniert NTP leider nicht, da Antworten eines NTP-Servers Ihren Rechner nicht erreichen werden. Weitere Informationen Weiterführende Dokumentation (im HTML-Format) zum NTP-Server finden Sie unter /usr/share/doc/ntp/. Protokollierung von anderen Hosts mittels <command>syslogd</command> TomRhodesBeigetragen von BenedictReuschlingÜbersetzt von Die Interaktion mit Systemprotokollen ist ein wichtiger Aspekt, sowohl was Sicherheit als auch Systemadministration anbelangt. Überwachen der Protokolldateien von mehreren Hosts kann sehr unhandlich werden, wenn diese Hosts über mittlere oder grosse Netze verteilt sind oder wenn sie Teile von unterschiedlichen Netzwerken sind. In diesen Fällen macht die Konfiguration der Protokollierung von anderen Hosts diesen Prozess wesentlich komfortabler. Die zentralisierte Protokollierung auf einen bestimmten Protokollierungshost kann manche der administrativen Belastungen der Protokolldateiadministration reduzieren. Protokolldateiaggregation, -zusammenführung und -rotation kann an einer zentralen Stelle mit den &os;-eigenen Werkzeugen wie &man.syslogd.8; und &man.newsyslog.8; konfiguriert werden. In der folgenden Beispielkonfiguration sammelt Host A, genannt logserv.example.com, Protokollinformationen für das lokale Netzwerk. Host B, genannt logclient.example.com wird seine Protokollinformationen an den Server weiterleiten. In realen Konfigurationen benötigen beide Hosts passende Vorwärts- und Umkehr-Einträge im DNS oder in /etc/hosts. Andernfalls werden die Daten vom Server abgelehnt. Konfiguration des Protokollierungs-Servers Protokollierungs-Server sind Maschinen, die konfiguriert sind, Protokollinformationen von anderen Hosts zu akzeptieren. In den meisten Fällen wird dies zur Vereinfachung der Konfiguration eingesetzt, in anderen Fällen ist es einfach nur ein Schritt in eine bessere Verwaltung. Was auch immer die Gründe sind, ein paar Anforderungen müssen vorher erfüllt sein. Ein richtig konfigurierter Protokollierungs-Server muss minimal die folgenden Anforderungen erfüllen: Das Regelwerk der Firewall muss UDP auf Port 514 sowohl auf Client- als auch auf Serverseite erlauben; syslogd wurde so konfiguriert, dass es Nachrichten von anderen Clientrechnern akzeptiert; Der syslogd-Server und alle Clientrechner müssen gültige Einträge für sowohl Vorwärts- als auch Umkehr-DNS besitzen, oder in /etc/hosts korrekt eingetragen sein. Um den Protokollierungs-Server zu konfigurieren, muss der Client in /etc/syslog.conf eingetragen sein und der Verbindungsweg der Protokollierung muss spezifiziert sein: +logclient.example.com *.* /var/log/logclient.log Weitere Informationen zu den verschiedenen unterstützten und verfügbaren Verbindungswegen finden sich in der Manualpage &man.syslog.conf.5;. Einmal hinzugefügt, werden alle Nachrichten über den Verbindungsweg in die zuvor angegebene Datei, /var/log/logclient.log protokolliert. Der Server benötigt ausserdem die folgenden Zeilen in der /etc/rc.conf: syslogd_enable="YES" syslogd_flags="-a logclient.example.com -v -v" Die erste Option aktiviert den syslogd-Dienst während des Systemstarts und die zweite Option erlaubt es, Daten von dem spezifizierten Client auf diesem Server zu akzeptieren. Die Verwendung von im letzten Teil erhöht die Anzahl von Protokollnachrichten. Dies ist sehr hilfreich für die Feineinstellung der Verbindungspfade, da Administratoren auf diese Weise erkennen, welche Arten von Nachrichten unter welchen Einstellungen protokolliert werden. Mehrere -Optionen können angegeben werden, um die Protokollierung von mehreren Clients zu erlauben. IP-Adressen und ganze Netzblöcke können ebenfalls spezifiziert werden. Lesen Sie dazu die &man.syslog.3;-Manualpage, um eine vollständige Liste von möglichen Optionen zu erhalten. Zum Schluss muss noch die Protokolldatei erstellt werden. Auf welche Weise dies geschieht ist nicht wichtig, aber in den meisten Fällen funktioniert &man.touch.1; grossartig, wie hier dargestellt: &prompt.root; touch /var/log/logclient.log Zu diesem Zeitpunkt sollte der syslogd-Dienst neu gestartet und überprüft werden: &prompt.root; /etc/rc.d/syslogd restart &prompt.root; pgrep syslog Wenn eine PID zurückgegeben wird, wurde der Server erfolgreich neu gestartet und die Clientkonfiguration kann beginnen. Wenn der Server nicht neu gestartet wurde, suchen Sie im /var/log/messages-Protokoll nach eventuellen Fehlermeldungen. Konfiguration des Protokollierungs-Clients Ein Protokollierungs-Client ist eine Maschine, die Protokollinformationen an einen Protokollierungs-Server sendet, zusätzlich zu ihren lokalen Kopien. Ähnlich wie Protokollierungs-Server müssen Clients auch ein paar minimale Anforderungen erfüllen: &man.syslogd.8; muss so konfiguriert sein, dass es Nachrichten eines bestimmten Typs an einen Protokollierungs-Server schickt, welcher diese akzeptieren muss; Die Firewall muss UDP-Pakete durch Port 514 erlauben; Sowohl Vorwärts- als auch Umkehr-DNS muss konfiguriert sein oder es müssen passende Einträge in /etc/hosts vorhanden sein. Die Clientkonfiguration ist ein bisschen entspannter, verglichen mit der des Servers. Der Clientrechner muss ebenfalls die folgenden Einträge in der /etc/rc.conf besitzen: syslogd_enable="YES" syslogd_flags="-s -v -v" Wie zuvor aktivieren diese Einträge den syslogd-Dienst während des Systemstarts und erhöhen die Anzahl der Protokollnachrichten. Die Option verhindert, dass dieser Client Protokolle von anderen Hosts akzeptiert. Verbindungspfade beschreiben den Systemteil, für den eine Nachricht generiert wird. Beispielsweise sind ftp und ipfw beides Verbindungspfade. Wenn Protokollnachrichten für diese beiden Dienste generiert werden, sind diese beiden Werkzeuge normalerweise in jeder Protokollnachricht enthalten. Verbindungspfade sind mit einer Priorität oder Stufe verbunden, die dazu verwendet wird, zu markieren, wie wichtig eine Nachricht im Protokoll ist. Die Häftigste ist warning und info. Bitte lesen Sie die &man.syslog.3; Manualpage, um eine komplette Liste der verfügbaren Verbindungspfade und Prioritäten zu erhalten. Der Protokollierungs-Server muss in der /etc/syslog.conf des Clients eingetragen sein. In diesem Beispiel wird das @-Symbol benutzt, um Protokolldaten an einen anderen Server zu senden. Der Eintrag sieht wie folgt aus: *.* @logserv.example.com Einmal hinzugefügt, muss syslogd neu gestartet werden, damit diese Änderungen wirksam werden: &prompt.root; /etc/rc.d/syslogd restart Um zu testen, ob Protokollnachrichten über das Netzwerk gesendet werden, kann &man.logger.1; auf dem Client benutzt werden, um eine Nachricht an syslogd zu schicken: &prompt.root; logger "Test message from logclient" Diese Nachricht sollte jetzt sowohl in /var/log/messages auf dem Client, als auch in /var/log/logclient.log auf dem Server vorhanden sein. Fehlerbehebung beim Protokollierungs-Server In bestimmten Fällen ist die Fehlerbehebung notwendig, wenn Nachrichten nicht auf dem Protokollierungs-Server empfangen werden. Es gibt mehrere Gründe dafür, jedoch treten am häufigsten Probleme bei der Netzwerkverbindung und beim DNS auf. Um diese Fälle zu überprüfen, stellen Sie sicher, dass beide Hosts in der Lage sind, sich gegenseitig über den Hostnamen zu erreichen, der in /etc/rc.conf angegeben ist. Wenn das funktioniert, ist möglicherweise eine Änderung der syslogd_flags-Option in /etc/rc.conf notwendig. Im folgenden Beispiel ist /var/log/logclient.log leer und die /var/log/messages-Dateien enthalten keine Gründe für den Fehler. Um die Fehlerausgabe zu erhöhen, ändern Sie die syslogd_flags-Option so, dass diese wie in dem folgenden Beispiel aussieht und initiieren Sie dann einen Neustart: syslogd_flags="-d -a logclien.example.com -v -v" &prompt.root; /etc/rc.d/syslogd restart Fehlerausgabedaten ähnlich der Folgenden werden sofort nach dem Neustart auf dem Bildschirm erscheinen: logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch. Es scheint klar zu sein, dass die Nachrichten aufgrund eines fehlerhaften Namens abgewiesen werden. Nach genauer Untersuchung der Konfiguration, kommt ein Tippfehler in der folgenden Zeile der /etc/rc.conf als Fehler in Betracht: syslogd_flags="-d -a logclien.example.com -v -v" Die Zeile sollte logclient und nicht logclien enthalten. Nachdem die entsprechenden Veränderungen gemacht wurden, ist ein Neustart fällig, mit den entsprechenden Ergebnissen: &prompt.root; /etc/rc.d/syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages Zu diesem Zeitpunkt werden die Nachrichten korrekt empfangen und in die richtige Datei geschrieben. Sicherheitsbedenken Wie mit jedem Netzwerkdienst, müssen Sicherheitsanforderungen in Betracht gezogen werden, bevor diese Konfiguration umgesetzt wird. Manchmal enthalten Protokolldateien sensitive Daten über aktivierte Dienste auf dem lokalen Rechner, Benutzerkonten und Konfigurationsdaten. Daten, die vom Client an den Server geschickt werden, sind weder verschlüsselt noch mit einem Passwort geschützt. Wenn ein Bedarf für Verschlüsselung besteht, ist es möglich, security/stunnel zu verwenden, welches die Daten über einen verschlüsselten Tunnel versendet. Lokale Sicherheit ist ebenfalls ein Thema. Protokolldateien sind während der Verwendung oder nach ihrer Rotation nicht verschlüsselt. Lokale Benutzer versuchen vielleicht, auf diese Dateien zuzugreifen, um zusätzliche Einsichten in die Systemkonfiguration zu erlangen. In diesen Fällen ist es absolut notwendig, die richtigen Berechtigungen auf diesen Dateien zu setzen. Das &man.newsyslog.8;-Werkzeug unterstützt das Setzen von Berechtigungen auf gerade erstellte oder rotierte Protokolldateien. Protokolldateien mit Zugriffsmodus 600 sollten verhindern, dass lokale Benutzer darin herumschnüffeln.