23.4. NIS/YP - Network Information Service

23.4.1. Was ist NIS?

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.

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.

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.

Die Funktion entspricht dem Domänensystem von Windows NT®; auch wenn sich die interne Umsetzung unterscheidet, sind die Basisfunktionen vergleichbar.

23.4.2. Wichtige Prozesse und Begriffe

Es gibt verschiedene Begriffe und Anwenderprozesse, auf die Sie stoßen werden, wenn Sie NIS unter FreeBSD einrichten, egal ob Sie einen Server oder einen Client konfigurieren:

23.4.3. 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.

23.4.4. NIS/YP konfigurieren

Dieser Abschnitt beschreibt an Hand eines Beispiels die Einrichtung einer NIS-Umgebung.

# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd

ellington# 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.

ellington# vi /var/yp/Makefile

NOPUSH = "True"

coltrane# 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.

20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid

23.4.5. Sicherheit unter NIS

Im Allgemeinen kann jeder entfernte Anwender einen RPC an 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 ypserv(8) “securenets”, durch die man den Zugriff auf bestimmte Rechner beschränken kann. ypserv(8) versucht, beim Systemstart die Informationen über securenets aus der Datei /var/yp/securenets zu laden.

# 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 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.

23.4.6. Bestimmte Benutzer an der Anmeldung hindern

In unserem Labor gibt es den Rechner basie, der nur für Mitarbeiter der Fakultät bestimmt ist. Wir wollen diesen Rechner nicht aus der NIS-Domäne entfernen, obwohl passwd des NIS-Masterservers Benutzerkonten sowohl für Fakultätsmitarbeiter als auch für Studenten enthält. Was können wir also tun?

Es gibt eine Möglichkeit, bestimmte Benutzer an der Anmeldung an einem bestimmten Rechner zu hindern, selbst wenn diese in der NIS-Datenbank vorhanden sind. Dazu müssen Sie lediglich an diesem Rechner den Eintrag -Benutzername an das Ende von /etc/master.passwd setzen, wobei Benutzername der zu blockierende Benutzername ist. Diese Änderung sollte bevorzugt durch vipw erledigt werden, da vipw Ihre Änderungen an /etc/master.passwd auf Plausibilität überprüft und nach erfolgter Änderung die Passwortdatenbank automatisch aktualisiert. Um also den Benutzer bill an der Anmeldung am Rechner basie zu hindern, gehen wir wie folgt vor:

basie# vipw
[add -bill to the end, exit]
vipw: rebuilding the database...
vipw: done

basie# 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#

23.4.7. Netzgruppen verwenden

Die im letzten Abschnitt beschriebene Methode eignet sich besonders, wenn Sie spezielle Regeln für wenige Benutzer oder wenige Rechner benötigen. In großen Netzwerken werden Sie allerdings mit Sicherheit vergessen, einige Benutzer von der Anmeldung an bestimmten Rechnern auszuschließen. Oder Sie werden gezwungen sein, jeden Rechner einzeln zu konfigurieren. Dadurch verlieren Sie aber den Hauptvorteil von NIS, die zentrale Verwaltung.

Die Lösung für dieses Problem sind Netzgruppen. Ihre Aufgabe und Bedeutung ist vergleichbar mit normalen, von UNIX-Dateisystemen verwendeten Gruppen. Die Hauptunterschiede sind das Fehlen einer numerischen ID sowie die Möglichkeit, Netzgruppen zu definieren, die sowohl Benutzer als auch andere Netzgruppen enthalten.

Netzgruppen wurden entwickelt, um große, komplexe Netzwerke mit Hunderten Benutzern und Rechnern zu verwalten. Sie sind also von Vorteil, wenn Sie von dieser Situation betroffen sind. Andererseits ist es dadurch beinahe unmöglich, Netzgruppen mit einfachen Beispielen zu erklären. Das hier verwendete Beispiel veranschaulicht dieses Problem.

Nehmen wir an, dass Ihre erfolgreiche Einführung von NIS die Aufmerksamkeit Ihrer Vorgesetzten geweckt hat. Ihre nächste Aufgabe besteht nun darin, Ihre NIS-Domäne um zusätzliche Rechner zu erweitern. Die folgenden Tabellen enthalten die neuen Benutzer und Rechner inklusive einer kurzen Beschreibung.

Wollten Sie diese Einschränkungen umsetzen, indem Sie jeden Benutzer einzeln blockieren, müssten Sie auf jedem System für jeden Benutzer eine entsprechende Zeile in passwd einfügen. Wenn Sie nur einen Eintrag vergessen, haben Sie ein Problem. Es mag noch angehen, dies während der ersten Installation zu erledigen, im täglichen Betrieb werden Sie allerdings mit Sicherheit einmal vergessen, die entsprechenden Einträge anzulegen. Vergessen Sie nicht: Murphy war Optimist.

Die Verwendung von Netzgruppen hat in dieser Situation mehrere Vorteile. Sie müssen nicht jeden Benutzer einzeln verwalten; weisen Sie stattdessen den Benutzer einer Netzgruppe zu und erlauben oder verbieten Sie allen Mitglieder dieser Gruppe die Anmeldung an einem Server. Wenn Sie einen neuen Rechner hinzufügen, müssen Sie Zugangsbeschränkungen nur für die Netzgruppen festlegen. Legen Sie einen neuen Benutzer an, müssen Sie ihn nur einer oder mehrere Netzgruppen zuweisen. Diese Veränderungen sind voneinander unabhängig; Anweisungen der Form “für diese Kombination aus Benutzer und Rechner mache Folgendes ...” sind nicht mehr nötig. Wenn Sie die Einrichtung von NIS sorgfältig geplant haben, müssen Sie nur noch eine zentrale Konfigurationsdatei bearbeiten, um den Zugriff auf bestimmte Rechner zu erlauben oder zu verbieten.

Der erste Schritt ist die Initialisierung der NIS-Maps der Netzgruppe. ypinit(8) kann dies unter FreeBSD nicht automatisch durchführen. Sind die Maps aber erst einmal erzeugt, werden sie jedoch von NIS problemlos unterstützt. Um eine leere Map zu erzeugen, geben Sie Folgendes ein:

ellington# vi /var/yp/netgroup

Danach legen Sie die Einträge an. Für unser Beispiel benötigen wir mindestens vier Netzgruppen: IT-Beschäftige, IT-Lehrlinge, normale Beschäftigte sowie Externe.

IT_EMP  (,alpha,test-domain)    (,beta,test-domain)
IT_APP  (,charlie,test-domain)  (,delta,test-domain)
USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
        (,golf,test-domain)
INTERNS (,able,test-domain)     (,baker,test-domain)

Bei IT_EMP, IT_APP usw. handelt es sich um Netzgruppennamen. In den Klammern werden diesen Netzgruppen jeweils ein oder mehrere Benutzerkonten hinzugefügt. Die drei Felder in der Klammer haben folgende Bedeutung:

1. 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.

2. Der Name des Benutzerkontos, der zu dieser Netzgruppe gehört.

3. Die NIS-Domäne für das Benutzerkonto. Sie können Benutzerkonten von anderen NIS-Domänen in Ihre Netzgruppe importieren, wenn Sie mehrere NIS-Domänen verwalten.

Jedes Feld kann Wildcards enthalten. Die Einzelheiten entnehmen Sie bitte netgroup(5).

Das Aktivieren und Verteilen Ihre neuen NIS-Map ist einfach:

ellington# cd /var/yp
ellington# make

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

ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser

Die Ausgabe des ersten Befehls gibt den Inhalt von /var/yp/netgroup wieder. Der zweite Befehl erzeugt nur dann eine Ausgabe, wenn Sie rechnerspezifische Netzgruppen erzeugt haben. Der dritte Befehl gibt die Netzgruppen nach Benutzern sortiert aus.

Die Einrichtung der Clients ist einfach. Sie müssen lediglich auf dem Server war vipw(8) aufrufen und die Zeile

+:::::::::

durch

+@IT_EMP:::::::::

ersetzen.

Ab sofort werden nur noch die Daten der in der Netzgruppe IT_EMP vorhandenen Benutzer in die Passwortdatenbank von war importiert. Nur diese Benutzer dürfen sich am Server anmelden.

Unglücklicherweise gilt diese Einschränkung auch für die ~-Funktion der Shell und für alle Routinen, die auf Benutzernamen und numerische Benutzer-IDs zugreifen. Oder anders formuliert, cd ~user ist nicht möglich, ls -l zeigt die numerische Benutzer-ID statt dem Benutzernamen und find . -user joe -print erzeugt die Fehlermeldung “No such user”. Um dieses Problem zu beheben, müssen Sie alle Benutzereinträge importieren, ohne ihnen jedoch zu erlauben, sich an Ihrem Server anzumelden.

Dazu fügen Sie eine weitere Zeile in /etc/master.passwd ein. Diese Zeile sollte ähnlich der folgenden aussehen:

+:::::::::/sbin/nologin, was in etwa “Importiere alle Einträge, aber ersetze die Shell in den importierten Einträgen durch /sbin/nologin” entspricht. Sie können jedes Feld dieses Eintrages ersetzen, indem Sie einen Standardwert in /etc/master.passwd eintragen.

Danach müssen Sie nur mehr eine einzige NIS-Map ändern, wenn ein neuer Mitarbeiter berücksichtigt werden muss. Für weniger wichtige Server gehen Sie analog vor, indem Sie den alten Eintrag +::::::::: in den lokalen Versionen von /etc/master.passwd durch folgende Einträge ersetzen:

+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin

Die entsprechenden Zeilen für normale Arbeitsplätze lauten:

+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin

Ab jetzt wäre alles wunderbar, allerdings ändert sich kurz darauf die Firmenpolitik: Die IT-Abteilung beginnt damit, externe Mitarbeiter zu beschäftigen. Externe dürfen sich an normalen Arbeitsplätzen sowie an den weniger wichtigen Servern anmelden. Die IT-Lehrlinge dürfen sich nun auch an den Hauptservern anmelden. Sie legen also die neue Netzgruppe IT_INTERN an, weisen Ihr die neuen IT-Externen als Benutzer zu und beginnen damit, die Konfiguration auf jedem einzelnen Rechner zu ändern ... Halt. Sie haben gerade die alte Regel “Fehler in der zentralisierten Planung führen zu globaler Verwirrung.” bestätigt.

Da NIS in der Lage ist, Netzgruppen aus anderen Netzgruppen zu bilden, lassen sich solche Situationen leicht vermeiden. Eine Möglichkeit ist die Erzeugung rollenbasierter Netzgruppen. Sie könnten eine Netzgruppe BIGSRV erzeugen, um den Zugang zu den wichtigsten Servern zu beschränken, eine weitere Gruppe SMALLSRV für die weniger wichtigen Server und eine dritte Netzgruppe USERBOX für die normalen Arbeitsplatzrechner. Jede dieser Netzgruppen enthält die Netzgruppen, die sich auf diesen Rechnern anmelden dürfen. Die Einträge der Netzgruppen in der NIS-Map sollten ähnlich den folgenden aussehen:

BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP  ITINTERN
USERBOX   IT_EMP  ITINTERN USERS

Diese Methode funktioniert besonders gut, wenn Sie Rechner in Gruppen mit identischen Beschränkungen einteilen können. Unglücklicherweise ist dies die Ausnahme und nicht die Regel. Meistens werden Sie die Möglichkeit zur rechnerspezischen Zugangsbeschränkung benötigen.

Rechnerspezifische Netzgruppen sind die zweite Möglichkeit, um mit den oben beschriebenen Änderungen umzugehen. In diesem Szenario enthält /etc/master.passwd auf jedem Rechner zwei mit “+” beginnende Zeilen. Die erste Zeile legt die Netzgruppe mit den Benutzern fest, die sich auf diesem Rechner anmelden dürfen. Die zweite Zeile weist allen anderen Benutzern /sbin/nologin als Shell zu. Verwenden Sie auch hier (analog zu den Netzgruppen) Großbuchstaben für die Rechnernamen. Die Zeilen sollten also ähnlich den folgenden aussehen:

+@BOXNAME:::::::::
+:::::::::/sbin/nologin

Wenn Sie dies für alle Rechner erledigt haben, werden Sie die lokalen Versionen von /etc/master.passwd nie mehr verändern müssen. Alle weiteren Änderungen geschehen über die NIS-Maps. Nachfolgend ein Beispiel für eine mögliche Netzgruppen-Map, die durch einige Besonderheiten erweitert wurde:

# Define groups of users first
IT_EMP    (,alpha,test-domain)    (,beta,test-domain)
IT_APP    (,charlie,test-domain)  (,delta,test-domain)
DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
DEPT2     (,golf,test-domain)     (,hotel,test-domain)
DEPT3     (,india,test-domain)    (,juliet,test-domain)
ITINTERN  (,kilo,test-domain)     (,lima,test-domain)
D_INTERNS (,able,test-domain)     (,baker,test-domain)
#
# Now, define some groups based on roles
USERS     DEPT1   DEPT2     DEPT3
BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP    ITINTERN
USERBOX   IT_EMP  ITINTERN  USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR       BIGSRV
FAMINE    BIGSRV
# User india needs access to this server
POLLUTION  BIGSRV  (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH     IT_EMP
#
# The anti-virus-machine mentioned above
ONE       SECURITY
#
# Restrict a machine to a single user
TWO       (,hotel,test-domain)
# [...more groups to follow]
     

Wenn Sie eine Datenbank verwenden, um Ihre Benutzerkonten zu verwalten, sollten Sie den ersten Teil der NIS-Map mit Ihren Datenbanktools erstellen können. Auf diese Weise haben neue Benutzer automatisch Zugriff auf die Rechner.

Eine letzte Warnung: Es ist nicht immer ratsam, rechnerbasierte Netzgruppen zu verwenden. Wenn Sie Dutzende oder gar Hunderte identische Rechner einrichten müssen, sollten Sie rollenbasierte Netzgruppen verwenden, um die Grösse der NISs-Maps in Grenzen zu halten.

23.4.8. Weitere wichtige Punkte

Nachdem Sie Ihre NIS-Umgebung eingerichtet haben, müssen Sie einige Dinge anders als bisher erledigen.

• Jedes Mal, wenn Sie einen neuen Benutzer anlegen wollen, tun Sie dies ausschließlich am NIS-Masterserver. Außerdem müssen Sie anschließend die NIS-Maps neu erzeugen. Wenn Sie diesen Punkt vergessen, kann sich der neue Benutzer nur am NIS-Masterserver anmelden. Wenn Sie also den neuen Benutzer jsmith anlegen, gehen Sie folgerndermassen vor:

  # pw useradd jsmith
  # cd /var/yp
  # make test-domain
  

  Statt pw useradd jsmith könnten Sie auch adduser jsmith verwenden.

• Tragen Sie die Administratorkonten nicht in die NIS-Maps ein. Administratorkonten und Passwörter dürfen nicht auf Rechnern verbreitet werden, auf denen sich Benutzer anmelden können, die auf diese Konten keine Zugriff haben sollen.

• Sichern Sie die NIS-Master- und Slaveserver und minimieren Sie die Ausfallzeiten. Wenn diese Rechner gehackt oder einfach nur ausgeschaltet werden, haben viele Leute keinen Netzwerkzugriff mehr.

  Dies ist die größte Schwäche jeder zentralen Verwaltung. Wenn Sie Ihre NIS-Server nicht schützen, werden Sie viele verärgerte Anwender haben.

23.4.9. Kompatibilität zu NIS v1

ypserv unterstützt NIS v1 unter FreeBSD nur eingeschränkt. Die NIS-Implementierung von FreeBSD verwendet nur NIS v2, andere Implementierungen unterstützen aus Gründen der Abwärtskompatibilität mit älteren Systemen auch NIS v1. Die mit diesen Systemen gelieferten ypbind-Daemonen versuchen, sich an einen NIS-v1-Server zu binden (Dies selbst dann, wenn sie ihn nie benötigen. Außerdem versuchen Sie auch dann, einen v1-Server zu erreichen, wenn Sie zuvor eine Antwort von einem v2-Server erhalten.). Während normale Clientaufrufe unter FreeBSD unterstützt werden, sind Anforderungen zum Transfer von v1-Maps nicht möglich. Daher kann FreeBSD nicht als Client oder Server verwendet werden, wenn ein NIS-Server vorhanden ist, der nur NIS v1 unterstützt. Glücklicherweise sollte es heute keine Server mehr geben, die nur NIS v1 unterstützen.

23.4.10. NIS-Server, die auch als NIS-Clients arbeiten

Wenn Sie ypserv in einer Multi-Serverdomäne verwenden, in der NIS-Server gleichzeitig als NIS-Clients arbeiten, ist es eine gute Idee, diese Server zu zwingen, sich an sich selbst zu binden. Damit wird verhindert, dass Bindeanforderungen gesendet werden und sich die Server gegenseitig binden. Sonst könnten seltsame Fehler auftreten, wenn ein Server ausfällt, auf den andere Server angewiesen sind. Letztlich werden alle Clients einen Timeout melden, und versuchen, sich an andere Server zu binden. Die dadurch entstehende Verzögerung kann beträchtlich sein. Außerdem kann der Fehler erneut auftreten, da sich die Server wiederum aneinander binden könnten.

Sie können einen Rechner durch die Verwendung von ypbind sowie der Option -S zwingen, sich an einen bestimmten Server zu binden. Um diesen Vorgang zu automatisieren, können Sie folgende Zeilen in /etc/rc.conf einfügen:

nis_client_enable="YES"    # run client stuff as well
nis_client_flags="-S NIS domain,server"

Lesen Sie ypbind(8), wenn Sie weitere Informationen benötigen.

23.4.11. Passwortformate

Unterschiedliche Passwortformate sind das Hauptproblem, das beim Einrichten eines NIS-Servers auftreten kann. Wenn der NIS-Server mit DES verschlüsselte Passwörter verwendet, werden nur Clients unterstützt, die ebenfalls DES benutzen. Wenn sich auf Ihrem Netzwerk beispielsweise Solaris NIS-Clients befinden, müssen die Passwörter mit DES verschlüsselt werden.

Welches Format die Server und Clients verwenden, steht in /etc/login.conf. Wenn ein System Passwörter mit DES verschlüsselt, enthält die default-Klasse einen Eintrag wie den folgenden:

default:\
    :passwd_format=des:\
    :copyright=/etc/COPYRIGHT:\
    [weitere Einträge]

Mögliche Werte für passwd_format sind unter anderem blf und md5 (mit Blowfish und MD5 verschlüsselte Passwörter).

Wenn die Datei /etc/login.conf geändert wird, muss die Login-Capability Datenbank neu erstellt werden. Geben Sie dazu als root den folgenden Befehl ein:

# cap_mkdb /etc/login.conf

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 FreeBSD NIS-Server und NIS-Clients entsprechend den obigen Schritten eingestellt haben, wird im ganzen Netzwerk dasselbe Passwortformat verwendet. Falls Sie Probleme mit der Authentifizierung eines NIS-Clients haben, kontrollieren Sie die verwendeten Passwortformate. In einer heterogenen Umgebung werden Sie DES benutzen müssen, da dies der meist unterstützte Standard ist.