Index: head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml (revision 47173) +++ head/de_DE.ISO8859-1/books/handbook/network-servers/chapter.xml (revision 47174) @@ -1,6193 +1,6585 @@ 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. + Wissen, wie Sie &os; einrichten, um als LDAP-Server + oder -Client zu agieren. + + + 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, + viele 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; service 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; service 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. + es zu viele Verbindungsversuche gibt. 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;. + werden hier nur einige von ihnen erwähnt. Weitere Optionen + werden in &man.exports.5; erörtert. 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 + Die folgenden Beispiele geben Anhaltspunkte zum + Exportieren von Dateisystemen, obwohl diese Einstellungen + natürlich von der Arbeitsumgebung und der + Netzwerkkonfiguration abhängen. Das nächste Beispiel + exportiert /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. + 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 + auf drei durch IP-Adressen bestimmte Rechner. Diese + Einstellung ist für ein privates Netzwerk nützlich, dass über + keinen DNS-Server verfügt. Optional könnten interne Rechnernamen auch in - /etc/hosts konfiguriert werden. + /etc/hostskonfiguriert werden. Benötigen Sie hierzu weitere Informationen, lesen Sie bitte - &man.hosts.5;. Durch das Flag wird es - möglich, auch Unterverzeichnisse als Mountpunkte + &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 + 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 + 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; service 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: + 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. Für Testzwecke oder zum + temporären einhängen eines entfernten Dateisystems, 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. + Dadurch wird das Verzeichnis /home + des Servers auf dem Client unter /mnt + eingehängt. Wenn alles korrekt konfiguriert ist, sollten alle + Dateien des Servers im Verzeichnis /mnt + sichtbar und verfügbar sein. - Wenn Sie ein entferntes Dateisystem nach jedem Systemstart - automatisch einhängen wollen, fügen Sie das - Dateisystem in /etc/fstab ein. Dazu ein + Um ein entferntes Dateisystem nach jedem Systemstart + automatisch einzuhängen, 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; service 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. + zugreifen. Dies ermöglicht einen schnellen Zugriff auf + die Quelldateien, ohne sie auf jede Maschine zu + kopieren zu müssen. <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: + Das Kommando showmount zeigt die + verfügbaren Mountpunkte eines entfernten Rechners. Um sich + die Mountpunkte des Rechners foobar + anzusehen, 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. + 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 die Router die nötigen + UDP-Informationen weiterleiten. 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 + <acronym>NIS</acronym>-Begriffe und -Prozesse - 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: + Es gibt verschiedene Begriffe und Anwenderprozesse, die + erläutert werden, wenn NIS unter &os; implementiert wird, + unabhängig davon, ob das System ein NIS-Server oder ein + NIS-Client ist: 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. + Nehmen wir an, es handelt sich um ein kleines + Universitätsnetz. Dieses Netz besteht aus fünfzehn + &os;-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; wird ein neuer Benutzer + angelegt, so muss dies auf allen fünfzehn Rechnern manuell + erledigt werden. Dieses Universitätsnetz würde eindeutig + von der Installation von zwei NIS-Servern + profitieren. 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. + Wenn erstmalig ein NIS-Schema eingerichtet wird, sollte + es im Vorraus sorgfältig geplant werden. Unabhängig von der + Größe des Netzwerks müssen einige Entscheidungen im Rahmen + des Planungsprozesses getroffen werden. 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. + Dies muss nicht der übliche 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. + 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 des 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 + dieses Beispiel wird der Name + test-domain verwendet. 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. + Es gibt jedoch auch Betriebssysteme (vor allem + &sunos;), die als NIS-Domänennamen den Namen der + Internetdomäne verwenden. Wenn dies für einen oder + mehrere Rechner des Netzwerks zutrifft, + muss der Name der Internetdomäne als + NIS-Domänennamen verwendet werden. 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. + Wenn ein NIS-Server einrichtet wird, müssen + einige Dinge beachtet werden. 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 + das Netzwerk nicht zu stark ausgelastet ist, ist es auch + möglich, den NIS-Server als weiteren Dienst auf einem + anderen Rechner laufen zu lassen. Wenn jedoch ein + NIS-Server ausfällt, wirkt sich dies negativ auf + alle NIS-Clients aus. 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: + Abhängig von den Anforderungen ist die Einrichtung + eines NIS-Masterservers relativ einfach, da NIS von &os; + bereits in der Standardkonfiguration unterstützt wird. + Er muss nur durch Hinzufügen der folgenden Zeilen in + /etc/rc.conf aktiviert werden: 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. + In Abhängigkeit der NIS-Konfiguration können weitere + Einträge erforderlich sein. Weitere Informationen finden + sich 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: + Nachdem obige Parameter konfiguriert wurden, muss noch + /etc/netstart als Superuser ausgeführt + werden, um alles entsprechend den Vorgaben in + /etc/rc.conf einzurichten. + Als letzter Schritt muss, bevor die NIS-Maps einrichtet + werden können, ypserv-Daemon + manuell gestartet werden: &prompt.root; service 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: + 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 die Passwörter für + root- oder + andere Administratorkonten nicht an alle Server der + NIS-Domäne verteilt werden sollten. Deshalb werden die + primären Passwort-Dateien konfiguriert, bevor die NIS-Maps + initialisiert werden: &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). + Es ist ratsam, alle Systemkonten (wie + bin, + tty, + kmem oder + games), sowie + alle Konten, die nicht an die NIS-Clients weitergeben + werden sollen, wie beispielsweise + root und alle + Konten mit der UID 0 (=Superuser) zu entfernen. - 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. + + Es muss dafür gesorgt werden, dass + /var/yp/master.passwd weder von der + Gruppe noch von der Welt gelesen werden kann + (Zugriffsmodus 600)! Dafür kann das Kommando + chmod entsprechend benutzt + werden. + Tru64 UNIX - Nun können Sie die NIS-Maps initialisieren. - FreeBSD verwendet dafür das Skript + Nun können die NIS-Maps initialisiert werden. + &os; 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: + &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 + Durch diese Datei wird festgelegt, dass in einer + NIS-Umgebung mit nur einem Server gearbeitet wird und dass + alle Clients unter &os; laufen. Da test-domain aber auch über einen - Slaveserver verfügt, müssen Sie - /var/yp/Makefile entsprechend anpassen: + Slaveserver verfügt, muss + /var/yp/Makefile entsprechend + angepasst werden: 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: - + Es sollte nun ein Verzeichnis namens + /var/yp/test-domain existieren. Die + Kopien der NIS-Masterserver-Maps sollten sich in diesem + Verzeichnis befinden. Allerdings müssen diese Daten immer + aktuell sein. Die folgenden Einträge in + /etc/crontab des NIS-Slaveservers + 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. + Verwendung des ypbind-Daemons an einen + NIS-Server. Das ypbind-Kommando 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 + Es gibt verschiedene Wege, den 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. + Denken Sie daran, zumindest ein lokales + Benutzerkonto, das nicht über NIS importiert wird, + in Ihrer /etc/master.passwd zu + 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 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; service ypbind start - Nachdem Sie diese Schritte erledigt haben, sollten Sie - mit ypcat passwd die + Danach sollte 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. + &man.ypserv.8; schicken, um den Inhalt der NIS-Maps abzurufen, + falls er den 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 + /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. + gewähren, beispielsweise durch privilegierte Ports, sind + sie gegenüber IP spoofing-Attacken + verwundbar. Jeder NIS-Verkehr sollte daher von einer + 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. - + Die Verwendung der + TCP-Wrapper verlangsamt die + Reaktion des 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 der + 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 + Anmeldung an einem bestimmten Rechner zu hindern, selbst wenn + diese in der NIS-Datenbank vorhanden sind. Dazu muss + lediglich an diesem Rechner der Eintrag -Benutzername und die richtige Anzahl von - von Doppelpunkten an das Ende von - /etc/master.passwd setzen, - wobei Benutzername der zu - blockierende Benutzername ist. Die Zeile mit dem geblockten - Benutzer muss dabei vor der + Zeile, für - zugelassene Benutzer stehen. 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: + Doppelpunkten an das Ende von + /etc/master.passwd gesetzt werden, wobei + Benutzername der zu blockierende + Benutzername ist. Die Zeile mit dem geblockten Benutzer muss + dabei vor der + Zeile, für zugelassene + Benutzer stehen. Diese Änderung sollte bevorzugt durch + vipw erledigt werden, da + vipw Ä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, geht man 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. + besonders, wenn spezielle Regeln für wenige Benutzer oder + wenige Rechner benötigt werden. In großen Netzwerken werden + Administratoren 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. + Netzwerke mit Hunderten Benutzern und Rechnern zu verwalten. + Sie sind also von Vorteil in solchen Situationen. + 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. + Nehmen wir an, dass die erfolgreiche Einführung von NIS + die Aufmerksamkeit eines Vorgesetzten geweckt hat. Die + nächste Aufgabe besteht nun darin, die 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 + Die 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. + Beim Versuch, diese Einschränkungen umzusetzen, indem + jeder Benutzer einzeln blockiert wird, müsste auf jedem System + für jeden Benutzer eine entsprechende Zeile in + passwd eingefügt werden. Wird nur ein + Eintrag vergessen, kann das erhebliche Probleme verursachen. + Es mag noch möglich sein, dies während der Erstinstallation + zu erledigen, im täglichen Betrieb kann jedoch jemand + vergessen, die entsprechenden Einträge für neue Benutzer + anzulegen. 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. + mehrere Vorteile. Nicht jeder Benutzer muss einzeln verwaltet + werden; stattdessen werden die Benutzer einer Netzgruppe + zugewiesen und allen Mitgliedern dieser Gruppe wird die + Anmeldung an einem Server erlaubt oder verwehrt. Wird ein + neuer Rechner hinzugefügt, müssen die Zugangsbeschränkungen + nur für die Netzgruppen festlegelegt werden. Wird ein neuer + Benutzer angelegt, muss er nur einer oder mehreren Netzgruppen + zugewiesen werden. 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 die Einrichtung von NIS sorgfältig + geplant wurde, muss nur noch eine zentrale Konfigurationsdatei + bearbeitet werden, 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: + der Netzgruppe. &man.ypinit.8; kann dies unter &os; 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. + sowie Praktikanten. 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. + gültig sind. Wird kein Rechnername festgelegt, ist der + Eintrag auf allen Rechnern gültig. Wenn ein Rechnername + angegeben ist, muss auf viele Einzelheiten in dieser + Konfiguration geachtet werden. 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. + Die NIS-Domäne für das Benutzerkonto. Benutzerkonten + können von anderen NIS-Domänen in eine Netzgruppe + importiert werden. 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. + sein, insbesondere wenn Rechner mit verschiedenen + Betriebssystemen in der NIS-Domäne betrieben werden. 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: + Einige NIS-Clients (dies gilt nicht für &os;) + 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. Diese + Grenze kann umgangen werden, indem mehrere Subnetzgruppen + mit weniger als fünfzehn Benutzern anlegt und diese + Subnetzgruppen wiederum in einer Netzgruppe + zusammengefasst wird: 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. + Wiederholen Sie diesen Vorgang , wenn Sie mehr als 225 + Benutzer in einer einzigen Netzgruppe benötigen. - Das Aktivieren und Verteilen Ihre neuen NIS-Map ist - einfach: + Das Aktivieren und Verteilen der 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;. + die Verfügbarkeit der 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. + /var/yp/netgroup wieder. Der zweite + Befehl erzeugt nur dann eine Ausgabe, wenn rechnerspezifische + Netzgruppen erzeugt wurden. 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 + Die Einrichtung der Clients ist einfach. Es muss + lediglich auf dem Server war + &man.vipw.8; aufgerufen werden und die Zeile +::::::::: durch +@IT_EMP::::::::: - ersetzen. + ersetzt werden. 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. + 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 alle Benutzereinträge importiert + werden, ohne ihnen jedoch zu erlauben, sich am + 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. + Importiere alle Einträge, aber ersetze die Shell in den + importierten Einträgen durch + /sbin/nologin entspricht. Es ist + möglich, jedes Feld der passwd-Einträge zu + ersetzen, indem ein einen Standardwert in + /etc/master.passwd eingetragen + wird. 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: + + Nach dieser Änderung muss die NIS-Map nur noch geändert + werden, wenn ein neuer Mitarbeiter der IT-Abteilung beitritt. + Ein ähnlicher Ansatz für weniger wichtige Server kann durch + das Ersetzten des alten Eintrags +::::::::: + in der lokalen Version von + /etc/master.passwd mit etwas wie folgt + verwendet werden: +@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 + damit, Praktikanten zu beschäftigen. Praktikanten dürfen sich an normalen Arbeitsplätzen sowie an den - weniger wichtigen Servern anmelden. Die IT-Lehrlinge + weniger wichtigen Servern anmelden. Die IT-Praktikanten 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 + legen also die neue Netzgruppe IT_INTERN + an, weisen Ihr die neuen IT-Praktikanten 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. + Diese Methode funktioniert besonders gut, wenn + Rechner in Gruppen mit identischen Beschränkungen eingeteilt + werden können. Unglücklicherweise ist dies die Ausnahme und + nicht die Regel. Meistens wird die Möglichkeit zur + rechnerspezischen Zugangsbeschränkung benötigt. 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 + Sobald dies für alle Rechner erledigt ist, müssen die + lokalen Versionen von /etc/master.passwd + nie mehr verändert werden. 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 + Wenn eine Datenbank verwendet wird, um Benutzerkonten zu + verwalten, kann es möglich sein, den ersten Teil der NIS-Map + mit den Datenbanktools zu erstellen. 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 + rechnerbasierte Netzgruppen zu verwenden. Wenn Dutzende + oder gar Hunderte identische Rechner einrichtet werden müssen, + sollten rollenbasierte Netzgruppen verwendet werden, 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. + Nachdem die Rechner in der NIS-Umgebung eingerichtet sind, + müssen Administratoren 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: + Jedes Mal, wenn ein neuer Benutzer angelegt wird, + muss er am NIS-Masterserver hinzugefügt und die NIS-Maps + anschließend neu erzeugt werden. Wird dieser Punkt + vergessen, kann sich der neue Benutzer + nur am NIS-Masterserver anmelden. + Wenn wir also den neuen Benutzer + jsmith anlegen, + gehen wir 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. + Statt pw useradd jsmith kann + auch adduser jsmith verwendet + werden. 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. + in die NIS-Maps ein. Dies ist unerwünscht und + stellt ein Sicherheitsrisiko dar. Diese Benutzer und + Passwörter sollten nicht auf alle Maschinen verteilt + werden. Vor allem, wenn sich Benutzer anmelden können, die + auf diese Konten keinen 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. + 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. + Dies ist die größte Schwäche jeder zentralen + Verwaltung. Wenn die NIS-Server nicht geschützt sind, + wird es viele verärgerte Anwender und ein unzufriedenes + Management geben. 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 + unter &os; nur eingeschränkt. Die NIS-Implementierung + von &os; 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 + unter &os; unterstützt werden, sind Anforderungen zum + Transfer von v1-Maps nicht möglich. Zudem kann &os; 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 + Ein Rechner kann 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: + gezwungen werden, sich an einen bestimmten Server zu binden. + Um diesen Vorgang zu automatisieren, können folgende Zeilen in + /etc/rc.conf eingefügt werden: 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. + DES benutzen. Wenn sich im Netzwerk beispielsweise + &solaris; NIS-Clients befinden, müssen die Passwörter sehr + wahrscheinlich 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: + 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 + Wenn alle &os; NIS-Server und NIS-Clients entsprechend + den obigen Schritten eingestellt sind, wird im ganzen + Netzwerk dasselbe Passwortformat verwendet. Falls Benutzer 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 + In einer heterogenen Umgebung wird wahrscheinlich DES benutzt + werden müssen, da dies der meist unterstützte Standard ist. + + + Lightweight Access Directory Protocol + (<acronym>LDAP</acronym>) + + + + Tom + Rhodes + + Geschrieben von + + + + + LDAP + + Das Lightweight Directory Access Protocol + (LDAP) ist ein Protokoll der + Anwendungsschicht und wird verwendet, um Objekte mithilfe eines + verteilten Verzeichnisdienstes abzurufen, zu verändern und zu + authentifizieren. Betrachten Sie es als ein Telefonbuch, das + homogene Informationen in mehreren hierarchischen Ebenen + speichert. Es wird häufig in Netzwerken genutzt, in denen + Benutzer unter Verwendung eines einzigen Kontos auf diverse + interne Informationen zugreifen müssen. Beispielsweise kann + E-Mail-Authentifizierung, Abfrage von Kontaktinformationen + und Website-Authentifizierung über ein einzelnes Benutzerkonto + aus der Datenbank des LDAP-Servers + erfolgen. + + Dieser Abschnitt behandelt nicht die Geschichte oder + Details der Implementierung des Protokolls. Diese Abschnitte + wurden verfasst, um einen LDAP-Server + und/oder -Client sowohl schnell, als auch sicher zu + konfigurieren. Jedoch erfordert jede Informationsbasis + sorgfältige Planung, und dies ist keine Ausnahme. + + Bei der Planung sollte bestimmt werden, welche Art von + Informationen gespeichert werden, für was diese Informationen + verwendet werden, wer Zugriff auf die Daten bekommen soll, und + wie diese Daten vor neugierigen Blicken geschützt werden + können. + + + <acronym>LDAP</acronym> Terminologie und Struktur + + Da bei der Konfiguration leicht Verwechselungen entstehen, + werden zuvor einige Aspekte von LDAP + erklärt. Zunächst bestehen alle Verzeichniseinträge aus einer + Gruppe von Attributen. Jede + Attributgruppe enthält einen Namen, also einen eindeutigen + Bezeichner, der als DN oder + distinguished name bekannt ist. + Dieser setzt sich normalerweise aus mehreren anderen + Attributen, wie dem RDN zusammen. + RDN, oder relative + distinguished name, ist ein geläufiger + Begriff für ein Attribut. Wie bei Verzeichnissen gibt es auch + hier absolute und relative Pfade. Betrachten Sie + DN als absoluten Pfad und + RDN als relativen Pfad. + + Beispielsweise könnte ein Eintrag wie folgt + aussehen: + + &prompt.user; ldapsearch -xb "uid=trhodes,ou=users,o=example.com" + + # extended LDIF +# +# LDAPv3 +# base <uid=trhodes,ou=users,o=example.com> with scope subtree +# filter: (objectclass=*) +# requesting: ALL +# + + +# trhodes, users, example.com +dn: uid=trhodes,ou=users,o=example.com +mail: trhodes@example.com +cn: Tom Rhodes +uid: trhodes +telephoneNumber: (xxx) xxx-xxxx + +# search result +search: 2 +result: 0 Success + +# numResponses: 2 +# numEntries:1 + + Obwohl die Bedeutung der einzelnen Attribute in diesem + Beispiel offensichtlich ist, sollte das Attribut + cn genauer betrachtet werden. Dies ist der + zuvor beschriebene RDN. Darüber hinaus + gibt es eine eindeutige Benutzer-ID. Es ist gängige Praxis, + in den Einträgen einheitliche uid oder uuids zu haben, um + zukünftige Migrationen zu erleichtern. + + + + Konfiguration eines + <acronym>LDAP</acronym>-Servers + + LDAP Server + + Um &os; so zu konfigurieren, dass es als + LDAP-Server fungiert, muss der Port + OpenLDAP installiert werden. Dies kann unter Verwendung von + pkg_add, oder durch Installation von + net/openldap24-server erreicht werden. Der + Bau des Ports wird empfohlen, da der Administrator zu diesem + Zeitpunkt eine Menge Optionen aktivieren und deaktivieren + kann. In den meisten Fällen werden die Standardwerte + ausreichend sein. Sollte jedoch Unterstützung für SQL nötig + sein, ist dies der richtige Zeitpunkt zur Aktivierung. + + Von nun an werden ein paar Verzeichnisse benötigt. Ein + Verzeichnis für Daten, sowie ein Verzeichnis zum + Speichern der Zertifikate. Erstellen Sie beide Verzeichnisse + mit den folgenden Befehlen: + + &prompt.root; mkdir /var/db/openldap-data + + &prompt.root; mkdir /usr/local/etc/openldap/private + + Kopieren Sie die Konfigurationsdatei der Datenbank: + + &prompt.root; cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG + + Im nächsten Schritt werden die + SSL-Zertifikate konfiguriert. Das + Erstellen von Zertifikaten wird zwar in OpenSSL beschrieben, aber hier + ist eine Zertifizierungsstelle erforderlich, weshalb eine + andere Methode verwendet wird. Es wird empfohlen, diesen Teil + genau zu überprüfen, um sicherzustellen, dass bei der + Erstellung des Zertifikats die richtigen Informationen + eingetragen werden. + + Die folgenden Befehle müssen im Verzeichnis + /usr/local/etc/openldap/private + ausgeführt werden. Dies ist wichtig, da die + Dateiberechtigungen restriktiv gesetzt werden und Benutzer + keinen direkten Zugriff auf diese Daten haben sollten. Geben + Sie folgende Befehle ein, um die Zertifikate zu + erstellen: + + &prompt.root; openssl req -days 365 -nodes -new -x509 -keyout ca.key -out ../ca.crt + + Diese Einträge sind frei wählbar, + mit Ausnahme von + Common Name. Hier muss etwas anderes als + der Hostname des Systems eingetragen werden, ansonsten würde + das System versuchen, den eigenen Hostnamen zu überprüfen. + Wenn wie in diesem Beispiel ein selbstsigniertes Zertifikat + verwendet wird, stellen Sie dem Hostnamen einfach das Präfix + CA für die Zertifizierungsstelle + voran. + + Die nächste Aufgabe besteht darin, einen + Zertifikatsregistrierungsanforderung (CSR) + sowie einen privaten Schlüssel zu erstellen. Dazu geben Sie + die folgenden Befehle ein: + + &prompt.root; openssl req -days 365 -nodes -new -keyout server.key -out server.csr + + Stellen Sie hierbei sicher, dass der + common name richtig eingetragen + wird. Anschließend muss der Schlüssel signiert werden: + + &prompt.root; openssl x509 -req -days 365 -in server.csr -out ../server.crt -CA ../ca.crt -CAkey ca.key -CAcreateserial + + Der letzte Schritt für die Erstellung der Zertifikate + besteht darin, die Client-Zertifikate zu erstellen und zu + signieren: + + &prompt.root; openssl req -days 365 -nodes -new -keyout client.key -out client.csr + + &prompt.root; openssl x509 -req -days 3650 -in client.csr -out ../client.crt -CAkey ca.key + + Achten Sie wieder auf das Attribut + common name. Dies sorgt häufig + für Verwirrung bei der erstmaligen Konfiguration von + LDAP. Stellen Sie außerdem sicher, dass + bei diesem Verfahren acht (8) neue Dateien erzeugt worden + sind. Der nächste Schritt besteht darin, + /usr/local/etc/openldap/slapd.conf zu + editieren und folgende Optionen hinzuzufügen: + + TLSCipherSuite HIGH:MEDIUM:+SSLv3 +TLSCertificateFile /usr/local/etc/openldap/server.crt +TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key +TLSCACertificateFile /usr/local/etc/openldap/ca.crt + + Editieren Sie zusätzlich + /usr/local/etc/openldap/ldap.conf und + fügen die folgenden Zeilen hinzu: + + TLS_CACERT /usr/local/etc/openldap/ca.crt +TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 + + Setzen Sie für die gewünschten Werte + ein und kommentieren Sie die Optionen , + und aus. + Setzen Sie bei + und ein. + + Die daraus resultierende Datei sollte der hier gezeigten + ähnlich sehen: + + BASE dc=example,dc=com +URI ldap:// ldaps:// + +SIZELIMIT 12 +TIMELIMIT 15 +#DEREF never + +TLS_CACERT /usr/local/etc/openldap/ca.crt$ +TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv3 + + Anschließend sollte das Standardpasswort für den Server + geändert werden. Das folgende Kommando schreibt die Ausgabe + in slapd.conf: + + &prompt.root; slappasswd -h "{SHA}" >> /usr/local/etc/openldap/slapd.conf + + Dieser Befehl wird nach einem Passwort fragen und, wenn + der Prozess nicht fehlschlägt, ein Passwort-Hash an das + Ende von slapd.conf hinzufügen. + slappasswd versteht verschiedene + Hash-Formate. Weitere Informationen hierzu finden Sie in der + Manualpage. + + Bearbeiten Sie + /usr/local/etc/openldap/slapd.conf und + fügen folgende Zeilen hinzu: + + password-hash {sha} +allow bind_v2 + + Das Suffix in dieser Datei muss aus + der vorherigen Konfiguration entsprechen. Zudem sollte die + Option ebenfalls gesetzt werden. Ein + guter Vorschlag ist beispielsweise + . Bevor die Datei gespeichert + wird, setzen Sie die Passwortausgabe von + slappasswd hinter die Option + . Das Endergebnis sollte in etwa wie + folgt aussehen: + + TLSCipherSuite HIGH:MEDIUM:+SSLv3 +TLSCertificateFile /usr/local/etc/openldap/server.crt +TLSCertificateKeyFile /usr/local/etc/openldap/private/server.key +TLSCACertificateFile /usr/local/etc/openldap/ca.crt +rootpw {SHA}W6ph5Mm5Pz8GgiULbPgzG37mj9g= + + Aktivieren Sie abschließend + OpenLDAP in + /etc/rc.conf. Zu diesem Zeitpunkt kann + es sinnvoll sein, eine URI sowie die Gruppe + und den Benutzer einzurichten. Editieren Sie dazu + /etc/rc.conf und fügen folgende Zeilen + hinzu: + + slapd_enable="YES" +slapd_flags="-4 -h ldaps:///" + + An dieser Stelle sollte der Server bereit sein, gestartet + und getestet zu werden. Führen Sie dazu folgenden Befehl + aus: + + &prompt.root; service slapd start + + Wurde alles richtig konfiguriert, sollte eine Suche im + Verzeichnis, wie in diesem Beispiel, eine erfolgreiche + Verbindung mit einer Antwort liefern: + + # extended LDIF +# +# LDAPv3 +# base <dc=example,dc=com> (default) with scope subtree +# filter: (objectclass=*) +# requesting: ALL + +# search result +search: 3 +result: 32 No such object + +# numResponses: 1 + + Wenn der Dienst wie im Beispiel oben antwortet, kann das + Verzeichnis mit dem Befehl ldapadd bestückt + werden. In diesem Beispiel gibt es eine Datei mit einer Liste + von Benutzern, die diesem Verzeichnis hinzugefügt werden. + Erstellen Sie zunächst eine Datei mit folgendem Datensatz für + den Import: + + dn: dc=example,dc=com +objectclass: dcObject +objectclass: organization +o: Example +dc: Example + +dn: cn=Manager,dc=example,dc=com +objectclass: organizationalRole +cn: Manager + + + Zur Fehlersuche, stoppen Sie den + slapd-Dienst mit dem + service-Befehl. Starten Sie anschließend + die Anwendung mit + Debugging-Optionen: + + &prompt.root; /usr/local/libexec/slapd -d -1 + + + Angenommen das die Importdatei + import.ldif heißt, geben Sie folgenden + Befehl ein, um die Datendatei zu importieren: + + &prompt.root; ldapadd -Z -D "cn=Manager,dc=example,dc=com" -W -f import.ldif + + Es wird wieder eine Aufforderung zur Passworteingabe + geben und die Ausgabe sollte wie folgt aussehen: + + Enter LDAP Password: +adding new entry "dc=example,dc=com" + +adding new entry "cn=Manager,dc=example,dc=com" + + Stellen Sie mit einer Suche auf dem Server sicher, dass + die Daten importiert wurden. Nutzen Sie dazu + ldapsearch. In diesem Fall sollte die + Ausgabe wie folgt aussehen: + + &prompt.user; ldapsearch -Z + + # extended LDIF +# +# LDAPv3 +# base <dc=example,dc=com> (default) with scope subtree +# filter: (objectclass=*) +# requesting: ALL +# + +# example.com +dn: dc=example,dc=com +objectClass: dcObject +objectClass: organization +o: Example +dc: Example + +# Manager, example.com +dn: cn=Manager,dc=example,dc=com +objectClass: organizationalRole +cn: Manager + +# search result +search: 3 +result: 0 Success + +# numResponses: 3 +# numEntries: 2 + + Es ist natürlich sinnvoll, sich über die Struktur der + LDAP-Verzeichnisse in den hier erwähnten + Manualpages zu informieren. An dieser Stelle sollte der + Server konfiguriert sein und ordnungsgemäß + funktionieren. + + + 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: + Um DHCP beim Systemstart zu aktivieren, sind zwei + Dinge erforderlich: DHCP Anforderungen - Stellen Sie sicher, dass bpf in - Ihren Kernel kompiliert ist. Dazu fügen Sie die Zeile + Stellen Sie sicher, dass bpf im + Kernel kompiliert ist. Dazu fügen Sie die Zeile device bpf - in Ihre Kernelkonfigurationsdatei ein und erzeugen einen + in die 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. + Kernel erzeugt werden. In einer angepassten + Kernelkonfigurationsdatei muss das Gerät enthalten sein, + damit DHCP ordnungsgemäß + funktioniert. - Wenn Sie um die Sicherheit Ihres Systems besorgt - sind, sollten Sie wissen, dass + Diejenigen, die besonders um die Sicherheit + besorgt sind, sollten 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. + funktioniert. Sehr sicherheitsbewusste Personen, + sollten bpf aus dem Kernel + entfernen, wenn DHCP nicht verwendet wird. 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: + Wenn dhclient an einem anderen + Ort installiert wurde, oder zusätzliche Flags an + dhclient übergeben werden müssen, fügen + Sie 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. 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 + &os;-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 + Der Server ist nicht im Basissystem von &os; + enthalten, daher muss der Port net/isc-dhcp42-server - installieren. Lesen Sie , wenn Sie + installiert. 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 + Stellen Sie sicher, dass &man.bpf.4; im Kernel kompiliert ist. Dazu fügen Sie die Zeile - device bpf - Ihre Kernelkonfigurationsdatei ein und erzeugen einen neuen + device bpf in die + 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 + Diejenigen, die um die Sicherheit besorgt + sind, sollten 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. + funktioniert. Sehr sicherheitsbewusste Personen, sollten + bpf aus dem Kernel + entfernen, wenn DHCP nicht verwendet wird. - Danach müssen Sie die vom Port + Danach muss die vom Port net/isc-dhcp42-server erzeugte Vorlage für dhcpd.conf - anpassen. Die bei der Installation erzeugte Datei + angepasst werden. 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, + Nachdem dhcpd.conf fertig + konfiguriert ist, 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 + werden) ersetzen, die der DHCP-Server auf Anfragen von DHCP-Clients hin überwachen soll. Danach können Sie den Server durch Eingabe des folgenden Befehls starten: &prompt.root; service 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. + Künftige Änderungen an der Konfiguration des Servers + erfordern, dass ein SIGTERM-Signal + anstelle von SIGHUP an + dhcpd gesendet wird. Es ist + jedoch definitiv einfacher, den Dienst mit &man.service.8; + 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; service 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. + Adresse in einen Nameserver des 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.1; &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 + 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 + 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 + ServerName erlaubt dem + Administrator, einen anderen Rechnernamen festzulegen, + den der Server an die Clients sendet, wenn sich dieser + vom 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 + dem die Dokumente abgelegt sind. 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. + Es ist empfehlenswert, eine Sicherungskopie der + Apache-Konfigurationsdatei + anzulegen, bevor Änderungen durchgeführt werden. Wenn die + Konfiguration von Apache + abgeschlossen ist, speichern Sie die Datei und überprüfen Sie + die Konfiguration mit &man.apachectl.8;. Geben Sie dazu + apachectl configtest ein. Dieser Befehl + sollte Syntax OK zurückgeben. 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 in /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 + kann 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; 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 mithilfe von &man.service.8; 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: + Wenn der Webserver + www.domain.tld + heißt und die virtuelle Domain + www.someotherdomain.tld + einrichtet werden soll, 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. + SQL-Datenbank voraus. Der &os;-Port wird alle + Abhängigkeiten mit sinnvollen Optionen konfigurieren und + installieren. 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. + Nachdem Django und die abhängigen Pakete installiert + sind, benötigt die Anwendung ein Projektverzeichnis und die + Apache-Konfiguration, um den eingebetteten + Python-Interpreter zu nutzen. Dieser wird spezifische URLs + der Seite aufrufen. 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 + Sie müssen httpd.conf anpassen, + damit Apache Anfragen für bestimmte URLs an die Internet-Applikation übergibt: <Location "/"> SetHandler python-program - PythonPath "['/dir/to/your/django/packages/'] + sys.path" + PythonPath "['/dir/to/the/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 + Ein &os;-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. + In einigen Fällen kann es wünschenswert sein, den Zugang + für manche Benutzer einzuschränken, ohne dabei 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. + Um anonymen FTP-Zugriff auf dem Server zu aktivieren, + muss ein Benutzer + ftp auf dem + &os;-System angelegt werden. Danach können sich Benutzer mit dem Benutzernamen ftp oder anonymous - auf Ihrem FTP-Server anmelden. Das Passwort ist dabei + am 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. + inetd auf dem 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; service ftpd start - Danach können Sie sich auf Ihrem FTP-Server anmelden: + Danach können Sie sich am 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 + Upload von Dateien. Dadurch könnte der 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. + oder noch Schlimmeren missbraucht werden. Wenn anonyme + FTP-Uploads dennoch erforderlich sind, sollten Sie die + Zugriffsrechte so setzen, dass solche Dateien erst nach + Zustimmung eines Administrators 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 + sich dadurch mit einem &os;-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 + auf den &os;-Installationsmedien vorhanden sein. Wenn + Samba noch nicht installiert ist, + können Sie dies ü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. + file system shares, also Bereiche + des Dateisystems, die mit &windows;-Clients geteilt werden sollen. 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 inetd, wie in beschrieben, aktivieren und die folgende 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. + im Internetbrowser die Adresse + http://localhost:901 + auf. Bei der ersten Anmeldung muss das + root-Benutzerkonto + verwendet werden. - + - 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 + Nachdem erfolgreicher Anmeldung an der + Hauptkonfigurationseite von + Samba steht die + Systemdokumentation zur Verfügung, und durch einen Klick auf + die Globals-Karteikarte kann mit der + Konfiguration begonnen werden. 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 + Unabhängig davon, ob + swat verwendet, oder /usr/local/etc/smb.conf direkt - editieren, sollten Sie zuerst folgende Einstellungen - anpassen: + editiert wird, sollten zuerst folgende Richtlinien + angepasst werden: 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 + security = user. Wenn die Clients + Benutzernamen verwenden, die den Benutzernamen auf dem &os;-Rechner entsprechen, dann sollten Sie die Einstellung user level - verwenden. Dies ist auch die Standardeinstellung. + verwenden. Dies ist die Standardeinstellung. Allerdings ist es dazu erforderlich, dass sich die - Clients auf Ihrem Rechner anmelden, bevor sie auf + Clients auf dem 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 + Logins auf dem 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 + verschiedene Backend-Authentifizierungsmodelle. + Clients können sich 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: + ist, Clients zu authentifizieren. Um den Zugriff auf + &unix;-Benutzerkonten von einem &windows;-Client aus zu + ermöglichen, 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. + Official Samba HOWTO. Mit den hier skizzierten + Grundlagen, sollten Sie in der Lage sein, + Samba zu starten. Zusätzlich zu + den Informationen hier, sollte weitere Dokumentation + hinzugezogen werden. <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; service 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 + samba gestartet werden. Wurde winbind name resolution services - in smb.conf aktiviert haben, wird + in smb.conf aktiviert, wird zusätzlich der winbindd-Daemon gestartet. - Sie können Samba jederzeit - durch den folgenden Befehl beenden: + Samba kann jederzeit + durch folgenden Befehl beendet werden: &prompt.root; service 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 + wurde mit dem + Network Time Protocol (NTP) + 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 + Um die Uhrzeit zu synchronisieren, müssen ein oder mehrere 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 + definiert werden. Der Netzwerkadministrator oder + Internetprovider hat 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. + man einen in der Nähe gelegenen Server auswählen kann. + 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 + Wenn Sie die Uhrzeit nur beim Systemstart + synchronisieren wollen, benutzen Sie &man.ntpdate.8;. + 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, + alle Server, mit denen Sie sich synchronisieren wollen, sowie alle an &man.ntpdate.8; zu übergebenden Optionen - in den ntpdate_flags angeben. + in ntpdate_flags angeben + werden. 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. + wo Informationen über frühere Antworten des + 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. + In der Voreinstellung ist der NTP-Server für alle + Rechner im Internet erreichbar. Die Option + restrict in + /etc/ntp.conf steuert, welche Rechner + auf den Server zugreifen können. - Wenn Sie alle Rechner vom Zugriff auf Ihren NTP-Server + Wenn Sie alle Rechner vom Zugriff auf den 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;. + Dieser Eintrag verhindert auch den Zugriff des + Servers auf alle angegebenen Server in der lokalen + Konfiguration. Besteht die Notwendigkeit, den NTP-Server + mit einem externen NTP-Server zu synchronisieren, muss + dieser Server dezidiert zugelassen werden. Weitere + Informationen finden Sie in &man.ntp.conf.5;. - Wenn Sie nur Rechnern Ihres eigenen Netzwerks die - Synchronisation mit Ihrem NTP-Server erlauben, gleichzeitig + Wenn Sie nur Rechnern innerhalb des Netzwerks die + Synchronisation mit dem 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. + sich um einen Rechner innerhalb des Netzwerks. 255.255.255.0 ist die - Netzmaske Ihres Netzwerks. + Netzmaske des Netzwerks. /etc/ntp.conf kann verschiedene restrict-Optionen enthalten. - Weiteres erfahren Sie im Abschnitt - Access Control Support der - Hilfeseite &man.ntp.conf.5;. + Weitere Details finden Sie im Abschnitt + Access Control Support von + &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 + /etc/rc.conf ein. Um weitere + Argumente an &man.ntpd.8; zu übergeben , 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: + aufbauen oder aufrechterhalten kann. Benutzer von PPP können + dies in den filter-Direktiven von + /etc/ppp/ppp.conf festlegen. + Ein Beispiel: 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 + nicht, da Antworten eines NTP-Servers den 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; + 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. + 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 + &prompt.root; touch /var/log/logclient.log Zu diesem Zeitpunkt sollte der syslogd-Dienst neu gestartet und überprüft werden: - &prompt.root; service syslogd restart -&prompt.root; pgrep syslog + &prompt.root; service 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; service 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" + &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; service syslogd restart + &prompt.root; service 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; service syslogd restart + &prompt.root; service 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.