Kapitel 29. Netzwerkserver

Die Konfiguration von inetd erfolgt über /etc/inetd.conf Jede Zeile dieser Datei repräsentiert eine Anwendung, die von inetd gestartet werden kann. In der Voreinstellung beginnt jede Zeile mit einem Kommentar (#), was bedeutet dass inetd keine Verbindungen für Anwendungen akzeptiert. Entfernen Sie den Kommentar am Anfang der Zeile, damit inetd Verbindungen für diese Anwendung entgegennimmt.

Nachdem Sie die Änderungen gespeichert haben, fügen Sie folgende Zeile in /etc/rc.conf ein, damit inetd bei Booten automatisch gestartet wird:

Starten Sie jetzt inetd, so dass er Verbindungen für die von Ihnen konfigurierten Dienste entgegennimmt:

Sobald inetd gestartet ist, muss der Dienst benachrichtigt werden, wenn eine Änderung in /etc/inetd.conf gemacht wird:

Normalerweise müssen Sie lediglich den Kommentar vor der Anwendung entfernen. In einigen Situationen kann es jedoch sinnvoll sein, den Eintrag weiter zu bearbeiten.

Als Beispiel dient hier der Standardeintrag für ftpd(8) über IPv4:

Die sieben Spalten in diesem Eintrag haben folgende Bedeutung:

Wie die meisten anderen Server-Daemonen lässt sich auch inetd über verschiedene Optionen steuern. In der Voreinstellung wird inetd mit -wW -C 60 gestartet. Durch das Setzen dieser Werte wird das TCP-Wrapping für alle inetd-Dienste aktiviert. Zudem wird verhindert, dass eine IP-Adresse eine Dienst öfter als 60 Mal pro Minute anfordern kann.

Um die Voreinstellungen für inetd zu ändern, fügen Sie einen Eintrag für inetd_flags in /etc/rc.conf hinzu. Wenn inetd bereits ausgeführt wird, starten Sie ihn mit service inetd restart neu.

Die verfügbaren Optionen sind:

Es sind noch weitere Optionen verfügbar. Eine vollständige Liste der Optionen finden Sie in inetd(8).

Viele Daemonen, die von inetd verwaltet werden, sind nicht auf Sicherheit bedacht. Einige Damonen, wie beispielsweise fingerd, liefern Informationen, die für einen Angreifer nützlich sein könnten. Aktivieren Sie nur erforderliche Dienste und überwachen Sie das System auf übermäßige Verbindungsversuche. max-connections-per-ip-per-minute, max-child und max-child-per-ip können verwendet werden, um solche Angriffe zu begrenzen.

TCP-Wrapper ist in der Voreinstellung aktiviert. Lesen Sie hosts_access(5), wenn Sie weitere Informationen zum Setzen von TCP-Beschränkungen für verschiedene von inetd aktivierte Daemonen benötigen.

Die Dateisysteme, die der NFS-Server exportieren soll, werden in /etc/exports festgelegt. Jede Zeile in dieser Datei beschreibt ein zu exportierendes Dateisystem, Clients, die darauf Zugriff haben sowie alle Zugriffsoptionen. Die Optionen eines auf einen anderen Rechner exportierten Dateisystems müssen alle in einer Zeile stehen. Wird in einer Zeile kein Rechner festgelegt, dürfen alle Clients im Netzwerk das exportierte Dateisystem einhängen.

Wie Dateisysteme exportiert werden, ist in der folgenden /etc/exports zu sehen. Diese Beispiele müssen natürlich an die Arbeitsumgebung und die Netzwerkkonfiguration angepasst werden. Es existieren viele verschiedene Optionen, allerdings werden hier nur wenige von ihnen erwähnt. Eine vollständige Liste der Optionen finden Sie in exports(5).

Dieses Beispiel exportiert /cdrom für drei Clients, alpha, bravo und charlie:

Die Option -ro kennzeichnet das exportierte Dateisystem als schreibgeschützt. Dadurch sind Clients nicht in der Lage, das exportierte Dateisystem zu verändern. Dieses Beispiel geht davon aus, dass die Hostnamen entweder über DNS oder über /etc/hosts aufgelöst werden können. Lesen Sie hosts(5) falls das Netzwerk über keinen DNS-Server verfügt.

Das nächste Beispiel exportiert /home auf drei durch IP-Adressen bestimmte Clients. Diese Einstellung kann für Netzwerke ohne DNS-Server und /etc/hosts nützlich sein. Die Option -alldirs ermöglicht es, auch Unterverzeichnisse als Mountpunkte festzulegen. Dies bedeutet aber nicht, dass alle Unterverzeichnisse eingehängt werden, vielmehr wird es dem Client ermöglicht, nur diejenigen Verzeichnisse einzuhängen, die auch benötigt werden.

Das nächste Beispiel exportiert /a, damit Clients von verschiedenen Domänen auf das Dateisystem zugreifen können. Die Option -maproot=root erlaubt es dem Benutzer root des Clients, als root auf das exportierte Dateisystem zu schreiben. Wenn diese Option nicht gesetzt ist, wird der root-Benutzer des Clients dem nobody-Konto des Servers zugeordnet und unterliegt somit den Zugriffsbeschränkungen dieses Kontos.

Ein Client kann für jedes Dateisystem nur einmal definiert werden. Wenn beispielsweise /usr ein gesondertes Dateisystem ist, dann wären die folgenden Einträge falsch, da in beiden Einträgen der gleiche Rechner angegeben wird:

Das richtige Format für eine solche Situation ist:

Das Folgende ist ein Beispiel für eine gültige Exportliste, in der /usr und /exports lokale Dateisysteme sind:

Damit die vom NFS-Server benötigen Prozesse beim Booten gestartet werden, fügen Sie folgende Optionen in /etc/rc.conf hinzu:

Der Server kann jetzt mit diesem Kommando gestartet werden:

Wenn der NFS-Server startet, wird auch mountd automatisch gestartet. Allerdings liest mountd /etc/exports nur, wenn der Server gestartet wird. Um nachfolgende Änderungen an /etc/exports wirksam werden zu lassen, kann mountd angewiesen werden, die Datei neu einzulesen:

Um den NFS-Client zu aktivieren, setzen Sie folgende Option in /etc/rc.conf auf jedem Client:

Der Client ist nun in der Lage, ein entferntes Dateisystem einzuhängen. In diesen Beispielen ist der Name des Servers server und der Name des Clients client. Fügen Sie folgenden Befehl aus, um das Verzeichnis /home vom server auf dem client ins Verzeichnis /mnt einzuhängen:

Die Dateien und Verzeichnisse in /home stehen dem Rechner client nun im Verzeichnis /mnt zur Verfügung.

Um ein entferntes Dateisystem bei jedem Systemstart automatisch einzuhängen, fügen Sie das Dateisystem in /etc/fstab ein:

fstab(5) enthält eine Beschreibung aller Optionen.

Einige Anwendungen erfordern die Sperrung von Dateien, damit sie korrekt arbeiten. Um diese Sperre zu aktivieren, müssen diese Zeilen in /etc/rc.conf sowohl auf dem Client als auch auf dem Server hinzugefügt werden:

Danach starten Sie die beiden Anwendungen:

Wenn keine Dateisperren zwischen den NFS-Clients und dem NFS-Server benötigt werden, können Sie den NFS-Client durch die Übergabe der Option -L an mount zu einer lokalen Sperrung von Dateien zwingen. Weitere Details finden Sie in mount_nfs(8).

autofs(5) ist eine gebräuchliche Bezeichnung für verschiedene Komponenten, welche es erlauben, lokale und entfernte Dateisysteme automatisch einzuhängen, sobald auf eine Datei oder ein Verzeichnis in diesem Dateisystem zugegriffen wird. Es besteht aus einer Kernel-Komponente autofs(5) und mehreren Benutzerprogrammen: automount(8), automountd(8) und autounmountd(8). autofs(5) ist eine Alternative für amd(8) aus früheren FreeBSD-Versionen. amd(8) steht nach wie vor zur Verfügung, da beide Programme ein unterschiedliches Format verwenden. Das Format welches autofs(5) verwendet ist das gleiche wie bei anderen SVR4 Automountern, beispielsweise denen aus Solaris™, Mac OS® X und Linux®.

Das virtuelle autofs(5)-Dateisystem wird von automount(8) in einen bestimmten Mountpunkt eingehängt. Dies geschieht gewöhnlich während des Bootens.

Jedes Mal, wenn ein Prozess versucht auf eine Datei unterhalb des autofs(5)-Mountpunkts zuzugreifen, wird der Kernel den automountd(8)-Daemon benachrichtigen und den aktuellen Prozess anhalten. Der automountd(8)-Daemon wird dann die Anfrage des Kernels bearbeiten und das entsprechende Dateisystem einhängen. Anschließend wird der Daemon den Kernel benachrichtigen, dass der angehaltene Prozess wieder freigegeben werden kann. Der autounmountd(8)-Daemon hängt automatisch Dateisysteme nach einiger Zeit ab, sofern sie nicht mehr verwendet werden.

Die primäre Konfigurationsdatei von autofs ist /etc/auto_master. Sie enthält die einzelnen Zuordnungen zu den Mountpunkten. Eine Erklärung zu auto_master und der Syntax für die Zuordnungen finden Sie in auto_master(5).

Eine spezielle Automounter Zuordnung wird in /net eingehängt. Wenn auf eine Datei in diesem Verzeichnis zugegriffen wird, hängt autofs(5) einen bestimmten, entfernen Mountpunkt ein. Wenn beispielsweise auf eine Datei unterhalb von /net/foobar/usr zugegriffen werden soll, würde automountd(8) das exportierte Dateisystem /usr von dem Rechner foobar einhängen.

Die Ausgabe von showmount zeigt das exportierte Dateisystem /usr. Wenn in das Verzeichnis /host/foobar/usr gewechselt wird, fängt automountd(8) die Anforderung ab und versucht, den Rechnernamen foobar aufzulösen. Gelingt dies, wird automountd(8) automatisch das exportierte Dateisystem einhängen.

Um autofs(5) beim Booten zu aktivieren, fügen Sie diese Zeile in /etc/rc.conf ein:

Danach kann autofs(5) gestartet werden:

Obwohl das Format von autofs(5) das gleiche ist wie in anderen Betriebssystemen, kann es wünschenswert sein, Informationen von anderen Betriebssystemen zu Rate zu ziehen, wie dieses Mac OS X Dokument.

Weitere Informationen finden Sie in den Manualpages automount(8), automountd(8), autounmountd(8) und auto_master(5).

Tabelle 30.1 fasst die Begriffe und Anwenderprozesse zusammen, die von NIS verwendet werden:

Mit NIS 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.

Dieser Abschnitt beschreibt eine einfache NIS-Umgebung, welche aus 15 FreeBSD-Maschinen besteht, für die 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.

In Zukunft soll die Konfiguration wie folgt aussehen:

Wenn erstmalig ein NIS-Schema eingerichtet wird, sollte es im Voraus sorgfältig geplant werden. Unabhängig von der Größe des Netzwerks müssen einige Entscheidungen im Rahmen des Planungsprozesses getroffen werden.

Die verbindlichen Kopien aller NIS-Dateien befinden sich auf dem 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. Da ein NIS-Server mehrere Domänen verwalten kann, 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 ypserv(8), um NIS-Anfragen zu bearbeiten. Dieser Daemon ist für eingehende Anfragen der NIS-Clients verantwortlich. Er ermittelt aus der angeforderten Domäne und Map einen Pfad zur entsprechenden Datenbank und sendet die angeforderten Daten von der Datenbank zum Client.

Abhängig von den Anforderungen ist die Einrichtung eines NIS-Masterservers relativ einfach, da NIS von FreeBSD bereits in der Standardkonfiguration unterstützt wird. Es kann durch folgende Zeilen in /etc/rc.conf aktiviert werden:

Wird ypserv in einer Multi-Serverdomäne verwendet, 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.

Server, die auch als Client arbeiten, können durch das Hinzufügen der folgenden Zeilen in /etc/rc.conf zu gezwungen werden, sich an einen bestimmten Server zu binden:

Nachdem die Parameter konfiguriert wurden, muss noch /etc/netstart ausgeführt werden, um alles entsprechend den Vorgaben in /etc/rc.conf einzurichten. Bevor die NIS-Maps einrichtet werden können, muss der ypserv(8)-Daemon manuell gestartet werden:

Um einen NIS-Slaveserver einzurichten, melden Sie sich am Slaveserver an und bearbeiten Sie /etc/rc.conf analog zum Masterserver. Erzeugen Sie aber keine NIS-Maps, da diese bereits auf dem Server vorhanden sind. Wenn ypinit auf dem Slaveserver ausgeführt wird, benutzen Sie -s (Slave) statt -m (Master). Diese Option benötigt den Namen des NIS-Masterservers und den Domänennamen, wie in diesem Beispiel zu sehen:

Hierbei wird auf dem Slaveserver ein Verzeichnis namens /var/yp/test-domain erstellt, welches Kopien der NIS-Masterserver-Maps enthält. Durch hinzufügen der folgenden Zeilen in /etc/crontab wird der Slaveserver angewiesen, seine Maps mit den Maps des Masterservers zu synchronisieren:

Diese Einträge sind nicht zwingend notwendig, 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.

Um die Konfiguration abzuschließen, führen Sie /etc/netstart auf dem Slaveserver aus, um die NIS-Dienste erneut zu starten.

Ein NIS-Client bindet sich unter Verwendung von ypbind an einen NIS-Server. Dieser Daemon sendet RPC-Anfragen auf dem lokalen Netzwerk. Diese Anfragen legen den Namen der Domäne fest, die auf dem Client konfiguriert ist. Wenn der Server der entsprechenden Domäne eine solche Anforderung erhält, schickt er eine Antwort an ypbind, das wiederum die Adresse des Servers speichert. Wenn mehrere Server verfügbar sind, verwendet der Client die erste erhaltene Adresse und richtet 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 FreeBSD-Rechner als NIS-Client einrichten:

Um den NIS-Client direkt zu starten, führen Sie als Superuser die folgenden Befehle aus:

Danach sollte bei der Eingabe von ypcat passwd auf dem Client die passwd-Map des NIS-Servers angezeigt werden.

Da RPC ein Broadcast-basierter Dienst ist, kann jedes System innerhalb der Domäne mittels ypbind den Inhalt der NIS-Maps abrufen. Um nicht autorisierte Transaktionen zu verhindern, unterstützt ypserv(8) eine Funktion namens "securenets", durch die der Zugriff auf bestimmte Rechner beschränkt werden kann. In der Voreinstellung sind diese Informationen in /var/yp/securenets gespeichert, es sei denn, ypserv(8) wurde mit der Option -p und einem alternativen Pfad gestartet. Diese Datei enthält Einträge, die aus einer Netzwerkadresse und einer Netzmaske bestehen. Kommentarzeilen beginnen mit "#". /var/yp/securnets könnte beispielsweise so aussehen:

Wenn 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 securenets nicht existiert, erlaubt ypserv Verbindungen von jedem Rechner.

TCP Wrapper beschreibt eine alternative Methode zur Zugriffskontrolle. Obwohl beide Methoden einige Sicherheit gewähren, sind sie anfällig für "IP-Spoofing"-Angriffe. Der NIS-Verkehr sollte daher von einer Firewall blockiert werden.

Server, die securenets verwenden, können Schwierigkeiten bei der Anmeldung von NIS-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 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 securenets umgehen.

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 Clients dieses Problem aufweisen, sollten Sie die betreffenden Clients in NIS-Slaveserver umwandeln, und diese an sich selbst binden.

Bestimmten Benutzern die Anmeldung an einzelnen Systemen zu verweigern, kann in großen Netzwerken schnell unübersichtlich werden. Dadurch verlieren Sie den Hauptvorteil von NIS: die zentrale Verwaltung.

Netzgruppen wurden entwickelt, um große, komplexe Netzwerke mit Hunderten Benutzern und Rechnern zu verwalten. Ihre Aufgabe ist vergleichbar mit UNIX® Gruppen. Die Hauptunterschiede sind das Fehlen einer numerischen ID sowie die Möglichkeit, Netzgruppen zu definieren, die sowohl Benutzer als auch andere Netzgruppen enthalten.

Um das Beispiel in diesem Kapitel fortzuführen, wird die NIS-Domäne um zusätzliche Benutzer und Rechner erweitert:

Bei der Verwendung von Netzgruppen wird jeder Benutzer einer oder mehreren Netzgruppen zugewiesen und die Anmeldung wird dann für die Netzgruppe erlaubt oder verwehrt. Wenn ein neuer Rechner hinzugefügt wird, müssen die Zugangsbeschränkungen nur für die Netzgruppen festgelegt werden. Wird ein neuer Benutzer angelegt, muss er einer oder mehreren Netzgruppen zugewiesen werden. 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.

Dieses Beispiel erstellt vier Netzgruppen: IT-Mitarbeiter, IT-Lehrlinge, normale Mitarbeiter sowie Praktikanten:

Jede Zeile konfiguriert eine Netzgruppe. Die erste Spalte der Zeile bezeichnet den Namen der Netzgruppe. Die Einträge in den Klammern stehen entweder für eine Gruppe von einem oder mehreren Benutzern, oder für den Namen einer weiteren Netzgruppe. Wenn ein Benutzer angegeben wird, haben die drei Felder in der Klammer folgende Bedeutung:

Wenn eine Gruppe mehrere Benutzer enthält, müssen diese durch Leerzeichen getrennt werden. Darüber hinaus kann jedes Feld Wildcards enthalten. Weitere Einzelheiten finden Sie in netgroup(5).

Netzgruppennamen sollten nicht länger als 8 Zeichen sein. 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 mehr als 15 Einträgen verwalten. Diese Grenze kann umgangen werden, indem mehrere Subnetzgruppen mit weniger als fünfzehn Benutzern angelegt werden und diese Subnetzgruppen wiederum in einer Netzgruppe zusammengefasst wird, wie in diesem Beispiel zu sehen:

Wiederholen Sie diesen Vorgang, wenn mehr als 225 (15*15) Benutzer in einer einzigen Netzgruppe existieren.

Die neue NIS-Map aktivieren und verteilen:

Dadurch werden die NIS-Maps netgroup, netgroup.byhost und netgroup.byuser erzeugt. Prüfen Sie die Verfügbarkeit der neuen NIS-Maps mit ypcat(1):

Die Ausgabe des ersten Befehls gibt den Inhalt von /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.

Wenn Sie einen Client einrichten, verwenden Sie vipw(8) um den Namen der Netzgruppe anzugeben. Ersetzen Sie beispielsweise auf dem Server namens war die folgende Zeile:

durch

ersetzt werden.

Diese Zeile legt fest, dass nur noch Benutzer der Netzgruppe IT_EMP in die Passwortdatenbank dieses Systems importiert werden. Nur diese Benutzer dürfen sich an diesem Server anmelden.

Diese Konfiguration gilt auch für die ~-Funktion der Shell und für alle Routinen, die auf Benutzernamen und numerische Benutzer-IDs zugreifen. Oder anders formuliert, cd ~Benutzer 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. Dies kann durch das Hinzufügen einer zusätzlichen Zeile erreicht werden:

Diese Zeile weist den Client an, alle Einträge zu importieren, aber die Shell in diesen Einträgen durch /usr/sbin/nologin zu ersetzen.

Stellen Sie sicher, dass die zusätzliche Zeile nach der Zeile +@IT_EMP::::::::: eingetragen ist. Andernfalls haben alle via NIS importierten Benutzerkonten /usr/sbin/nologin als Loginshell und niemand wird sich mehr am System anmelden können.

Um die weniger wichtigen Server zu konfigurieren, ersetzen Sie den alten Eintrag +::::::::: auf den Servern mit diesen Zeilen:

Die entsprechenden Zeilen für Arbeitsplätze lauten:

NIS ist in der Lage, Netzgruppen aus anderen Netzgruppen zu bilden. Dies kann nützlich sein, wenn sich die Firmenpolitik ändert. 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 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:

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 eine weitere 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 /usr/sbin/nologin als Shell zu. Verwenden Sie auch hier (analog zu den Netzgruppen) Großbuchstaben für die Rechnernamen:

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:

Es ist nicht immer ratsam, rechnerbasierte Netzgruppen zu verwenden. Wenn Dutzende oder Hunderte identische Rechner eingerichtet werden müssen, sollten rollenbasierte Netzgruppen verwendet werden, um die Größe der NIS-Maps in Grenzen zu halten.

Alle Rechner innerhalb der NIS-Domäne müssen für die Verschlüsselung von Passwörtern das gleiche Format benutzen. Wenn Benutzer Schwierigkeiten bei der Authentifizierung auf einem NIS-Client haben, liegt dies möglicherweise an einem anderen Passwort-Format. In einem heterogenen Netzwerk muss das verwendete Format von allen Betriebssystemen unterstützt werden, wobei DES der kleinste gemeinsame Standard ist.

Welches Format die Server und Clients verwenden, steht in /etc/login.conf:

In diesem Beispiel verwendet das System das Format DES. Weitere mögliche Werte sind unter anderem blf und md5 (mit Blowfish und MD5 verschlüsselte Passwörter).

Wird auf einem Rechner das Format entsprechend der NIS-Domäne geändert, muss anschließend die Login-Capability Datenbank neu erstellt werden:

LDAP verwendet mehrere Begriffe die Sie verstehen sollten bevor Sie die Konfiguration beginnen. Alle Verzeichniseinträge bestehen aus einer Gruppe von Attributen. Jede Attributgruppe enthält einen eindeutigen Bezeichner, der als distinguished name (DN) bekannt ist. Dieser setzt sich normalerweise aus mehreren anderen Attributen, wie dem Relative Distinguished Name (RDN) zusammen. 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 LDAP-Eintrag wie folgt aussehen. Dieses Beispiel sucht nach dem Eintrag für das angegebene Benutzerkonto (uid), Organisationseinheit (ou und Organisation (o):

Die Einträge in diesem Beispiel zeigen die Werte für die Attribute dn, mail, cn, uid und telephoneNumber. Das Attribut cn ist der RDN.

Weitere Informationen über LDAP und dessen Terminologie finden Sie unter http://www.openldap.org/doc/admin24/intro.html.

FreeBSD integriert keinen LDAP-Server. Beginnen Sie die Konfiguration mit der Installation des Ports oder Pakets net/openldap-server:

Im Paket sind eine große Anzahl an Optionen aktiviert. Mit dem Befehl pkg info openldap-server können diese überprüft werden. Falls die Optionen nicht ausreichend sind (weil bspw. SQL-Unterstützung benötigt wird), sollten Sie in Betracht ziehen, den Port mit dem entsprechenden Framework neu zu übersetzen.

Während der Installation wird für die Daten das Verzeichnis /var/db/openldap-data erstellt. Das Verzeichnis für die Ablage der Zertifikate muss manuell angelegt werden:

Im nächsten Schritt wird die Zertifizierungsstelle konfiguriert. Die folgenden Befehle müssen in /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. Weitere Informationen über Zertifikate und deren Parameter finden Sie im OpenSSL. Geben Sie folgenden Befehl ein, um die Zertifizierungsstelle zu erstellen und folgen Sie den Anweisungen:

Diese Einträge sind frei wählbar, mit Ausnahme von Common Name. Hier muss etwas anderes als der Hostname des Systems eingetragen werden. Wenn 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. Geben Sie folgenden Befehl ein und folgen Sie den Anweisungen:

Stellen Sie hierbei sicher, dass Common Name richtig eingetragen wird. Die Zertifikatsregistrierungsanforderung muss mit dem Schlüssel der Zertifizierungsstelle unterschrieben werden, um als gültiges Zertifikat verwendet zu werden:

Der letzte Schritt für die Erstellung der Zertifikate besteht darin, die Client-Zertifikate zu erstellen und zu signieren:

Achten Sie wieder auf das Attribut Common name. Stellen Sie außerdem sicher, dass bei diesem Verfahren acht (8) neue Dateien erzeugt worden sind.

Der Daemon, auf dem der OpenLDAP-Server läuft, heißt slapd. Die Konfiguration erfolgt über slapd.ldif. Die alte slapd.conf wird von OpenLDAP nicht mehr verwendet.

Konfigurationsbeispiele für slapd.ldif finden sich auch in /usr/local/etc/openldap/slapd.ldif.sample. Optionen sind in slapd-config(5) dokumentiert. Jeder Abschnitt in slapd.ldif wird, wie alle anderen LDAP-Attributgruppen, durch einen DN eindeutig identifiziert. Achten Sie darauf, dass keine Leerzeilen zwischen der Anweisung dn: und dem gewünschten Ende des Abschnitts verbleiben. Im folgenden Beispiel wird TLS verwendet, um einen sicheren Kanal zu implementieren. Der erste Abschnitt stellt die globale Konfiguration dar:

Hier müssen die Zertifizierungsstelle, das Serverzertifikat und die privaten Schlüssel des Servers angegeben werden. Es wird empfohlen, den Clients die Wahl der Sicherheits-Chiffre zu überlassen und die Option olcTLSCipherSuite wegzulassen (inkompatibel mit anderen TLS-Clients als openssl). Mit der Option olcTLSProtocolMin benötigt der Server nur eine minimale Sicherheitsstufe. Diese Option wird empfohlen. Während die Verfizierung für den Server verpflichtend ist, ist sie es nicht für den Client: olcTLSVerifyClient: never.

Der zweite Abschnitt behandelt die Backend-Module und kann wie folgt konfiguriert werden:

Der dritte Abschnitt widmet sich dem Laden der benötigten ldif-Schemata, die von den Datenbanken verwendet werden sollen. Diese Dateien sind essentiell.

Als nächstes folgt der Abschnitt zur Frontend-Konfiguration:

Ein weiterer Abschnitt ist dem Konfigurations-Backend gewidmet, der einzige Weg, später auf die OpenLDAP-Serverkonfiguration zuzugreifen, ist als globaler Superuser.

Der voreingestellte Benutzername für den Administrator lautet cn=config. Geben Sie slappasswd in eine Shell ein, wählen Sie ein Passwort und verwenden Sie seinen Hash in olcRootPW. Wenn diese Option jetzt nicht angegeben ist, kann vor dem Import der slapd.ldif niemand später den Abschnitt global configuration ändern.

Der letzte Abschnitt befasst sich mit dem Datenbank-Backend:

Diese Datenbank enthält den eigentlichen Inhalt des LDAP-Verzeichnisses. Neben mdb sind weitere Versionen verfügbar. Dessen Superuser, nicht zu verwechseln mit dem globalen, wird hier konfiguriert: ein Benutzername in olcRootDN und der Passworthash in olcRootPW; slappasswd kann wie zuvor benutzt werden.

Dieses Repository enthält vier Beispiele für slapd.ldif. Lesen Sie diese Seite, um eine bestehende slapd.conf in slapd.ldif zu konvertieren. Beachten Sie, dass dies einige unbrauchbare Optionen einführen kann.

Wenn die Konfiguration abgeschlossen ist, muss slapd.ldif in ein leeres Verzeichnis verschoben werden. Folgendes ist die empfohlene Vorgehensweise:

Importieren Sie die Konfigurationsdatenbank:

Starten Sie den slapd-Daemon:

Die Option -d kann, wie in slapd(8) beschrieben, zur Fehlersuche benutzt werden. Stellen Sie sicher, dass der Server läuft und korrekt arbeitet:

Dem Server muss noch vertraut werden. Wenn dies noch nie zuvor geschehen ist, befolgen Sie diese Anweisungen. Installieren Sie das Paket oder den Port OpenSSL:

Aus dem Verzeichnis, in dem ca.crt gespeichert ist (in diesem Beispiel /usr/local/etc/openldap), starten Sie:

Sowohl die CA als auch das Serverzertifikat werden nun in ihren jeweiligen Rollen korrekt erkannt. Um dies zu überprüfen, führen die folgenden Befehl aus dem Verzeichnis der server.crt aus:

Falls slapd ausgeführt wurde, muss der Daemon neu gestartet werden. Wie in /usr/local/etc/rc.d/slapd angegeben, müssen die folgenden Zeilen in /etc/rc.conf eingefügt werden, um slapd beim Booten ordnungsgemäß auszuführen:

slapd bietet beim Booten keine Möglichkeit zur Fehlersuche. Überprüfen Sie dazu /var/log/debug.log, dmesg -a und /var/log/messages.

Das folgende Beispiel fügt die Gruppe team und den Benutzer john zur LDAP-Datenbank domain.example hinzu, die bislang leer ist. Erstellen Sie zunächst die Datei domain.ldif:

Weitere Informationen finden Sie in der OpenLDAP-Dokumentation. Benutzen Sie slappasswd, um das Passwort durch einen Hash in userPassword zu ersetzen. Der in loginShell angegebene Pfad muss in allen Systemen existieren, in denen john sich anmelden darf. Benutzen Sie schließlich den mdb-Administrator, um die Datenbank zu ändern:

Änderungen im Bereich global configuration können nur vom globalen Superuser vorgenommen werden. Angenommen die Option olcTLSCipherSuite: HIGH:MEDIUM:SSLv3 wurde ursprünglich definiert und soll nun gelöscht werden. Dazu erstellen Sie zunächst eine Datei mit folgendem Inhalt:

Übernehmen Sie dann die Änderungen:

Geben Sie bei Aufforderung das im Abschnitt configuration backend gewählte Passwort ein. Der Benutzername ist nicht erforderlich: Hier repräsentiert cn=config den DN des zu ändernden Datenbankabschnitts. Alternativ können Sie mit ldapmodify eine einzelne Zeile der Datenbank löschen, mit ldapdelete einen ganzen Eintrag.

Wenn etwas schief geht oder der globale Superuser nicht auf das Konfigurations-Backend zugreifen kann, ist es möglich, die gesamte Konfiguration zu löschen und neu zu schreiben:

slapd.ldif kann dann bearbeitet und erneut importiert werden. Bitte folgenden Sie dieser Vorgehensweise nur, wenn keine andere Lösung verfügbar ist.

Dies ist nur die Konfiguration des Servers. Auf demselben Rechner kann auch ein LDAP-Client mit eigener, separater Konfiguration betrieben werden.

Die Unterstützung für den DHCP-Client ist im Installationsprogramm von FreeBSD enthalten, sodass ein neu installiertes System automatisch die Adressinformationen des Netzwerks vom DHCP-Server erhält. In Benutzerkonten, Zeitzone, Dienste und Sicherheitsoptionen finden Sie Beispiele für eine Netzwerkkonfiguration.

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 relevante Informationen über das Netzwerk, wie Netzmasken, Router und DNS-Server mitteilt. Diese Informationen werden als DHCP-Lease bezeichnet und sind nur für 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 dhcp-options(5).

Das Gerät bpf ist im GENERIC-Kernel bereits enthalten. Für die Nutzung von DHCP muss also kein angepasster Kernel erzeugt werden. In einer angepassten Kernelkonfigurationsdatei muss das Gerät enthalten sein, damit DHCP ordnungsgemäß funktioniert.

Standardmässig läuft die DHCP-Konfiguration bei FreeBSD 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 der Clients antwortet. Jedoch kann DHCP eine lange Zeit benötigen, um auf manchen Systemen fertig zu werden. Falls Netzwerkdienste gestartet werden, bevor DHCP die Informationen und Netzwerkadressen gesetzt hat, 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.

Diese Zeile wird in /etc/rc.conf verwendet, um den asynchronen Modus zu aktivieren:

Die Zeile kann bereits vorhanden sein, wenn bei der Installation des Systems DHCP konfiguriert wurde. Ersetzen Sie fxp0 durch die entsprechende Schnittstelle. Die dynamische Konfiguration von Netzwerkkarten wird in “Einrichten von Netzwerkkarten” beschrieben.

Um stattdessen den synchronen Modus zu verwenden, der während des Systemstarts pausiert bis die DHCP-Konfiguration abgeschlossen ist, benutzen Sie "SYNCDHCP":

Es stehen weitere Optionen für den Client zur Verfügung. Suchen Sie in rc.conf(5) nach dhclient, wenn Sie an Einzelheiten interessiert sind.

Der DHCP-Client verwendet die folgenden Dateien:

Dieser Abschnitt beschreibt die Einrichtung eines FreeBSD-Systems als DHCP-Server. Dazu wird die DHCP-Implementation von ISC (Internet Systems Consortium) verwendet. Diese Implementation und die Dokumentation können als Port oder Paket net/isc-dhcp44-server installiert werden.

Der Port net/isc-dhcp44-server installiert eine Beispiel-Konfigurationsdatei. Kopieren Sie /usr/local/etc/dhcpd.conf.example nach /usr/local/etc/dhcpd.conf und nehmen Sie die Änderungen an der neuen Datei vor.

Diese Konfigurationsdatei umfasst Deklarationen für Subnetze und Rechner, die den DHCP-Cleints zur Verfügung gestellt wird. Die folgenden Zeilen konfigurieren Folgendes:

Die Konfigurationsdatei unterstützt viele weitere Optionen. Lesen Sie dhcpd.conf(5), die mit dem Server installiert wird, für Details und Beispiele.

Nachdem dhcpd.conf konfiguriert ist, aktivieren Sie den DHCP-Server in /etc/rc.conf:

Dabei müssen Sie dc0 durch die Gerätedatei (mehrere Gerätedateien müssen durch Leerzeichen getrennt werden) ersetzen, die der DHCP-Server auf Anfragen von DHCP-Clients hin überwachen soll.

Starten Sie den Server mit folgenden Befehl:

Künftige Änderungen an der Konfiguration des Servers erfordern, dass der Dienst dhcpd gestoppt und anschließend mit service(8) gestartet wird.

Es gibt zwei Arten von Nameservern: Autoritative Nameserver sowie zwischenspeichernde (cachende, auch bekannt als auflösende) Nameserver.

Ein autoritativer Nameserver ist notwendig, wenn

Ein cachender Nameserver ist notwendig, weil

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.

Unbound ist im Basissystem von FreeBSD enthalten. In der Voreinstellung bietet es nur die DNS-Auflösung auf dem lokalen Rechner. Obwohl das im Basissystem enthaltene Unbound konfiguriert werden kann, um Namensauflösung über den lokalen Rechner hinweg bereitzustellen, ist es empfehlenswert für solche Anforderungen Unbound aus der FreeBSD Ports-Sammlung zu installieren.

Um Unbound zu aktivieren, fügen Sie folgende Zeile in /etc/rc.conf ein:

Alle vorhandenen Nameserver aus /etc/resolv.conf werden als Forwarder in der neuen Unbound-Konfiguration benutzt.

Nachdem jeder Server für DNSSEC konfiguriert ist, starten Sie Unbound:

Dieses Kommando sorgt für die Aktualisierung von /etc/resolv.conf, so dass Abfragen für DNSSEC gesicherte Domains jetzt funktionieren. Führen Sie folgenden Befehl aus, um den DNSSECTrust Tree für FreeBSD.org zu überprüfen:

Der Apache HTTP-Server wird unter FreeBSD primär in /usr/local/etc/apache2x/httpd.conf konfiguriert, wobei das x die Versionsnummer darstellt. In dieser Textdatei leitet ein # einen Kommentar ein. Die am häufigsten verwendeten Optionen sind:

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 apachectl. Der Befehl apachectl configtest sollte Syntax OK zurückgeben.

Um den Apache beim Systemstart zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein:

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:

Wenn apachectl keine Konfigurationsfehler meldet, starten Sie httpd:

Sie können den httpd-Dienst testen, indem Sie http://localhost in einen Browser eingeben, wobei Sie localhost durch den vollqualifizierten Domainnamen der Maschine ersetzen, auf dem der httpd läuft. Die Standard Webseite, die angezeigt wird, ist /usr/local/www/apache24/data/index.html.

Die Konfiguration von Apache kann bei nachfolgenden Änderungen an der Konfigurationsdatei bei laufendem httpd, auf Fehler überprüft werden. Geben Sie dazu folgendes Kommando ein:

Virtual Hosting ermöglicht es, mehrere Webseiten auf einem Apache-Server laufen zu lassen. Die virtuellen Hosts können IP-basiert oder namensbasiert sein. IP-basiertes virtual Hosting verwendet eine IP-Adresse für jede Webseite. Beim namensbasierten virtual Hosting 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 für jede Webseite einen separaten VirtualHost-Block ein. Wenn der Webserver beispielsweise www.domain.tld heißt und die virtuelle Domain www.someotherdomain.tld einrichtet werden soll, ergänzen Sie httpd.conf um folgende Einträge:

Setzen Sie für jeden virtuellen Host die entsprechenden Werte für ServerName und DocumentRoot.

Ausführliche Informationen zum Einrichten von virtuellen Hosts finden Sie in der offiziellen Apache-Dokumentation unter http://httpd.apache.org/docs/vhosts/.

Apache verwendet Module, die den Server um zusätzliche Funktionen erweitern. Eine vollständige Auflistung der zur Verfügung stehenden Module und Konfigurationsdetails finden Sie unter http://httpd.apache.org/docs/current/mod/.

In FreeBSD können einige Module mit dem Port www/apache24 kompiliert werden. Geben Sie in /usr/ports/www/apache24make config ein, um zu sehen, welche Module zur Verfügung stehen und welche Module in der Voreinstellung aktiviert sind. Wenn ein Modul nicht zusammen mit dem Port kompiliert wird, bietet die Ports-Sammlung die Möglichkeit viele Module zu installieren. Dieser Abschnitt beschreibt drei der am häufigsten verwendeten Module.

Neben mod_perl und mod_php stehen noch weitere Sprachen zur Erstellung von dynamischen Inhalten zur Verfügung. Dazu gehören auch Django und Ruby on Rails.

Der wichtigste Punkt ist hier die Entscheidung darüber, welche Benutzer auf den FTP-Server zugreifen dürfen. Ein FreeBSD-System verfügt über diverse Systembenutzerkonten, die jedoch nicht auf den FTP-Server zugreifen sollen. 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.

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, wie in ftpchroot(5) beschrieben, entsprechend an. Diese Datei enthält Benutzer und Gruppen sowie die für sie geltenden Einschränkungen für FTP.

Um anonymen FTP-Zugriff auf dem Server zu aktivieren, muss ein Benutzer ftp auf dem FreeBSD-System angelegt werden. Danach können sich Benutzer mit dem Benutzernamen ftp oder anonymous 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 chroot(2), um den Zugriff auf das Heimatverzeichnis des Benutzers ftp zu beschränken.

Es gibt zwei Textdateien, deren Inhalt den FTP-Clients bei der Anmeldung angezeigt wird. 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 der Inhalt von ~ftp/etc/ftpmotd angezeigt.

Sobald der FTP-Server konfiguriert ist, setzen Sie die entsprechende Variable in /etc/rc.conf, damit der Dienst beim Booten gestartet wird:

Starten Sie den Dienst:

Testen Sie die Verbindung zum FTP-Server, indem Sie folgendes eingeben:

Der ftpd-Daemon verwendet syslog(3), um Protokolldateien zu erstellen. In der Voreinstellung werden alle FTP betreffenden Nachrichten nach /var/log/xferlog geschrieben. Dies lässt sich aber durch das Einfügen der folgenden Zeile in /etc/syslog.conf ändern:

Samba wird in /usr/local/etc/smb4.conf konfiguriert. Diese Datei muss erstellt werden, bevor Samba benutzt werden kann.

Eine einfache smb4.conf, wie hier gezeigt, stellt den Zugriff auf Verzeichnisse und Drucker für Windows®-Clients in einer Arbeitsgruppe (engl. Workgroup) zur Verfügung. In aufwendigeren Installationen, in denen LDAP oder Active Directory zum Einsatz kommt, ist es einfacher die smb4.conf mit dem Werkzeug samba-tool(8) zu erstellen.

Damit Samba beim Systemstart automatisch aktiviert wird, fügen Sie die folgende Zeile in /etc/rc.conf ein:

Jetzt kann Samba direkt gestartet werden:

Samba verwendet drei Daemonen. Sowohl nmbd als auch smbd werden durch samba_enable gestartet. Wenn eine Namensauflösung über winbind benötigt wird, setzen Sie zusätzlich:

Samba kann jederzeit durch folgenden Befehl beendet werden:

Samba ist ein komplexes Softwarepaket mit umfassenden Funktionen, die eine weitreichende Integration von Microsoft® Windows®-Netzwerken ermöglichen. Für eine Beschreibung dieser Zusatzfunktionen sollten Sie sich auf http://www.samba.org umsehen.

FreeBSD enthält mit ntpd ein Werkzeug, das zur Synchronisation der Uhrzeit verwendet werden kann. Die Konfiguration von Ntpd erfolgt über Variablen in rc.conf(5) und /etc/ntp.conf, und wird in den folgenden Abschnitten beschrieben.

Ntpd kommuniziert über UDP mit mit seinen Peers. Sämtliche Firewalls zwischen Ihrem Rechner und seinen NTP-Peers müssen so konfiguriert sein, dass UDP-Pakete auf Port 123 ein- und ausgehen können.

ntpd benötigt keine ständige Internetverbindung. Wenn Sie sich über eine PPP-Verbindung ins Internet einwählen, sollten Sie verhindern, dass NTP-Verkehr eine Verbindung aufbauen oder aufrechterhalten kann. Dies kann in den filter-Direktiven von /etc/ppp/ppp.conf festgelegt werden. Ein Beispiel:

Weitere Informationen finden Sie im Abschnitt PACKET FILTERING von ppp(8) sowie in den Beispielen unter /usr/shared/examples/ppp/.

Um ein iSCSI-Target zu konfigurieren, erstellen Sie die Konfigurationsdatei /etc/ctl.conf und fügen Sie eine Zeile in /etc/rc.conf hinzu, um sicherzustellen, dass ctld(8) automatisch beim Booten gestartet wird. Starten Sie dann den Daemon.

Das folgende Beispiel zeigt eine einfache /etc/ctl.conf. Eine vollständige Beschreibung dieser Datei und der verfügbaren Optionen finden Sie in ctl.conf(5).

Der erste Eintrag definiert die Portalgruppe pg0. Portalgruppen legen fest, auf welchen Netzwerk-Adressen der ctld(8)-Daemon Verbindungen entgegennehmen wird. Der Eintrag discovery-auth-group no-authentication zeigt an, dass jeder Initiator iSCSI-Targets suchen darf, ohne sich authentifizieren zu müssen. Die dritte und vierte Zeilen konfigurieren ctld(8) so, dass er auf allen IPv4- (listen 0.0.0.0) und IPv6-Adressen (listen [::]) auf dem Standard-Port 3260 lauscht.

Es ist nicht zwingend notwendig eine Portalgruppe zu definieren, da es bereits eine integrierte Portalgruppe namens default gibt. In diesem Fall ist der Unterschied zwischen default und pg0 der, dass bei default eine Authentifizierung nötig ist, während bei pg0 die Suche nach Targets immer erlaubt ist.

Der zweite Eintrag definiert ein einzelnes Target. Ein Target hat zwei mögliche Bedeutungen: eine Maschine die iSCSI bereitstellt, oder eine Gruppe von LUNs. Dieses Beispiel verwendet die letztere Bedeutung, wobei iqn.2012-06.com.example:target0 der Name des Targets ist. Dieser Name ist nur für Testzwecke geeignet. Für den tatsächlichen Gebrauch ändern Sie com.example auf einen echten, rückwärts geschriebenen Domainnamen. 2012-06 steht für das Jahr und den Monat, an dem die Domain erworben wurde. target0 darf einen beliebigen Wert haben und in der Konfigurationsdatei darf eine beliebige Anzahl von Targets definiert werden.

Der Eintrag auth-group no-authentication erlaubt es allen Initiatoren sich mit dem angegebenen Target zu verbinden und portal-group pg0 macht das Target über die Portalgruppe pg0 erreichbar.

Die nächste Sektion definiert die LUN. Jede LUN wird dem Initiator als separate Platte präsentiert. Für jedes Target können mehrere LUNs definiert werden. Jede LUN wird über eine Nummer identifiziert, wobei LUN 0 verpflichtend ist. Die Zeile mit dem Pfad path /data/target0-0 definiert den absoluten Pfad zu der Datei oder des zvols für die LUN. Der Pfad muss vorhanden sein, bevor ctld(8) gestartet wird. Die zweite Zeile ist optional und gibt die Größe der LUN an. Als nächstes fügen Sie folgende Zeile in /etc/rc.conf ein, um ctld(8) automatisch beim Booten zu starten:

Um ctld(8) jetzt zu starten, geben Sie dieses Kommando ein:

Der ctld(8)-Daemon liest beim Start /etc/ctl.conf. Wenn diese Datei nach dem Starten des Daemons bearbeitet wird, verwenden Sie folgenden Befehl, damit die Änderungen sofort wirksam werden:

Um den Initiator zu verwenden, muss zunächst ein iSCSI-Daemon gestartet sein. Der Daemon des Initiators benötigt keine Konfigurationsdatei. Um den Daemon automatisch beim Booten zu starten, fügen Sie folgende Zeile in /etc/rc.conf ein:

Um iscsid(8) jetzt zu starten, geben Sie dieses Kommando ein:

Die Verbindung mit einem Target kann mit, oder ohne eine Konfigurationsdatei /etc/iscsi.conf durchgeführt werden. Dieser Abschnitt beschreibt beide Möglichkeiten.