![[Frederic]](../../common/images/Frederic_Raynal.png)
Original in fr Frédéric Raynal
fr to de Bernhard Spanyar
![[illustration]](../../common/images/illustration164.gif)
Hier nun werden wir sehen, wie man den Server konfiguriert und wir werden einige Ratschl�ge zur Nutzung von NIS erteilen.
Wir behandeln hier eine aktuelle Version von ypserv (d.h. eine Version die neuer ist als 1.3.2, um unter anderem die Verwaltung von Shadowpassw�rtern zur Verf�gung zu haben). Deshalb handelt es sich um einen NYS Server und kein "traditionelles NIS " ... wobei wir weiterhin "f�lschlich" von NIS sprechen werden.
Zuerst zeigen wir die Schritte, die n�tig sind, um einen Server zu installieren. Wir zeigen Schritt f�r Schritt, wie die einzelnen Konfigurationsdateien auf den Installationsprozess des Servers einwirken.
Im Artikel arbeiten wir auf der Maschine "charly". Die NIS Dom�ne tr�gt den Name "bosley". Die Slaveserver sind "sabrina", "jill" und "kelly".
Danach legt man den Namen der NIS-Dom�ne fest. Es handelt sich dabei nicht um einen Dom�nennamen im Sinne von DNS, sondern im Sinne von YPs. Dieser Name mu� aus Sicherheitsgr�nden anders als der der Maschine sein.
Mit dem Kommando domainname kann man ... den Dom�nennamen festlegen :-) In unserem Fall benutzen wir es wie folgt:
root@charly >> /bin/domainname bosleyDieses Kommando fixiert den NIS-Dom�nennamen im RAM-Speicher. Jedoch, wenn die Serverkonfiguration beendet ist, dann w�nscht man sich doch, da� dies automatisch beim Starten der Maschine erledigt wird. Daf�r mu� man eine Zeile in der Netzwerkkonfiguration /etc/sysconfig/network �ndern:
NISDOMAIN=bosleySobald das Netzwerk beim n�chsten Reboot initialisiert wird, wird auch automatisch der NIS-Dom�nenname festgelegt.
Der folgende Abschnitt besch�ftigt sich mit dem Starten des ypserv D�mons. Zuvor mu� man ihn mittels der Datei /etc/ypserv.conf konfigurieren. Dies ist eine ASCII-Datei:
option: [yes|no]M�gliche Optionen sind dns (der Server fragt DNS, um die Klienten zu finden, die nicht in den hosts-Maps auftauchen), sunos_kludge (obsolet) und xfr_check_port (um den Server auf einen Port unter 1024 zu lenken - yes als Default)
host:map:security:mangle[:field]Sie erlauben es festzulegen, wer was sehen darf.
Jetzt kann man den Server starten:
root@charly >> /etc/rc.d/init.d/ypserv startWenn man den Server automatisch starten m�chte, dann �ndert man die Initialisierungsdateien entsprechend. F�r RedHat sieht das wie folgt aus:
root@charly >> /sbin/chkconfig --levels 345 ypserv onUm zu verifizieren, da� alles korrekt l�uft:
root@charly >> /usr/sbin/rpcinfo -u localhost ypservBevor wir uns auf die Grundlagen st�rzen, kehren wir kurz zu dem zur�ck, was wir im ersten Artikel ausgef�hrt haben. Wir haben gesehen, da� es zwei Typen von Servern gibt: Master und Slaves. Der Master besitzt die NIS-Referenzdatenbank, wovon die Slaves nur eine Kopie haben. Sie dienen dazu, den Master von zu vielen Requests zu entlasten. Die Datenbank wird nur auf dem Server gepflegt. Erst danach wird sie auf die Slaveserver weiterkopiert.
program 100004 version 1 ready and waiting
program 100004 version 2 ready and waiting
Alles ist jetzt bereit ... bis auf die Datenbank. Man mu� sie nur noch erstellen. Und wer erstellen meint, sagt Makefile ;-] Ich kann Sie beruhigen, sie ist bereits fertig geschrieben, es m��en lediglich ein paar Variablen angepasst werden. Sie befindet sich im Verzeichnis /var/yp. Sie ist ausf�hrlich und klar kommentiert. Die wichtigste Zeile ist, wo die Maps, die von NIS benutzt werden sollen, definiert sind. Auf Charly sind dies:
all: passwd group hosts rpc services netid protocols mail shadow \Zu dem, was per Default vorgegeben ist, sollte man auch die Verwaltung der Shadowpassw�rter hinzuf�gen. Man mu� dann aber auch den Wert der Variable MERGE_PASSWD von "true" auf "false" setzen. Sie legt n�mlich fest, da� f�r die Konstruktion der NIS-Datenbank die Dateien /etc/passwd und /etc/shadow zu mischen sind.# netgrp publickey
# networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct
Letztes Detail bevor wir die NIS-Datenbank erstellen, die Verwaltung der Zugriffsrechte. Es gibt zwei Methoden den Zugang zum Server zu verwalten: entweder macht er alles selbst, oder �ber tcp_wrapper. Wir behandeln hier die Sicherheitseinstellungen �ber ypserv selbst.
Wenn Sie nur die Binaries von ypserv haben, dann sagt Ihnen die Option-v mit welcher Konfiguration Ihr Binary kompiliert wurde:
root@charly >> /usr/sbin/ypserv -vDie Datei /var/yp/securenets enth�lt paarweise Kombinationen von netmask/network, mit denen Sie den Serverzugang kontrollieren k�nnen. Sie m�ssen diese Datei unter allen Umst�nden modifizieren: als Default enth�lt sie:
ypserv - NYS YP Server version 1.3.9 (with securenets)
0.0.0.0 0.0.0.0was aller Welt den Zugang auf Ihren NIS-Server erlaubt. Es ist anzumerken, da� der Datei lediglich die IP-Adressen bekannt sind (nicht der Namen der Maschinen).
Jetzt k�nnen wir die NIS-Datenbank erstellen. Wir benutzen dazu das Kommando ypinit. Es erstellt die Datenbank in /var/yp und benutzt die Dateien aus /etc (dies ist der Default, man kann auch ein anderes Verzeichnis im Makefile festlegen). Hier sind die Dateien, die die Daten f�r die Datenbank liefern ( /etc/passwd, /etc/group, /etc/hosts, /etc/networks, /etc/services, /etc/protocols, /etc/netgroup, /etc/rpc ).
Die Option -m gestattet es, den Server mit den Rohdaten zu initialisieren (-m f�r master), die Option -s kopiert die Daten von der Masterdatenbank auf einen Slave (-s f�r Slave - Sklave auf Englisch).
Auf Charly initialisieren wir unsere Datenbank wie folgt:
root@charly >> /usr/lib/yp/ypinit -mUnd voila, schon steht die Datenbank :) Auf jedem Slaveserver mu� man jetzt das folgende Kommando ausf�hren:At this point, we have to construct a list of the hosts which will run NIS
servers. localhost is in the list of NIS server hosts. Please continue to add
the names for the other hosts, one per line. When you are done with the
list, type a <control D>.
next host to add: localhost
next host to add: sabrina
next host to add: jill
next host to add: kelly
next host to add:
The current list of NIS servers looks like this:localhost
sabrina
jill
kellyIs this correct? [y/n: y] y
We need some minutes to build the databases...
Building /var/yp/bosley/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/bosley'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
Updating shadow.byname...
# shadow publickey # networks ethers bootparams printcap \
# amd.home auto.master auto.home passwd.adjunct
gmake[1]: Leaving directory `/var/yp/bosley'
root@kelly >> /usr/lib/yp/ypinit -s charlyUm sicherzustellen, da� alles korrekt l�uft, reicht es aus, einen Server in einen Klienten zu verwandeln, egal ob Master oder Slave, und einen Request abzusetzen. Zum Beispiel auf Charly [sic]:
root@kelly >> ypcat passwd mulder:x:500:100::/home/mulder:/bin/csh scully:x:501:100::/home/scully:/bin/bashMan kann nebenbei auch feststellen, da� die Shadowpassw�rter korrekt funktionieren :)
|
|
|
Um einen Slaveserver hinzuzuf�gen gen�gt es, /usr/lib/yp/ypinit -s charly auf dem neuen Slaveserver auszuf�hren, und seinen Namen in die Datei /var/yp/ypservers des Masterservers einzuf�gen.
Wenn man einen neuen User anlegt, k�nnen sich mehrere Maps ver�ndert haben (passwd, shadow, alias, etc ...).
Sobald man eine Map modifiziert hat, darf man nicht vergessen, ein make im Verzeichnis /var/yp/ des Masterservers zu machen: dies aktualisiert seine Datenbank, indem es die Information integriert und auf die Slaves verteilt (mit dem Kommando yppush).
Das Program rpc.ypxfrd erlaubt es, die Transaktion zwischen einem Masterserver und seinen Slaves zu beschleunigen. Es gestattet einem Slave, die Datenbank des Master-Servers einfach zu kopieren, anstatt sie komplett neuzuerstellen. rpc.ypxfrd mu� zur selben Zeit gestartet werden wie ypserv und nur auf dem Master. Dieses Programm ist notwendig f�r sehr gro�e Maps.
Genauso wie es einige Passw�rter gibt, die man leicht erraten kann, werden auch NIS-Dom�nennamen benutzt, die vorhersehbar sind. Offensichtliche Kandidaten sind, wenn man einmal den (Maschinen-) namen des NIS-Servers herausbekommen hat, der komplette oder teilweise Name des Servers oder auch der Name der Organisation, zu der der Server geh�rt. ypwhich gestattet es, den Namen der Dom�ne zu testen!
Der NIS-Dom�nenname erscheint an mehreren Stellen, besonders im Verzeichnis /var/yp, oder auch in einem Unterverzeichnis, das w�hrend der NIS-Installation angelegt wurde (auf dem(n) Server(n), aber auch auf den Klienten) und den Namen der NIS-Dom�ne tr�gt. Man mu� deshalb die Zugangsrechte zu diesem Verzeichnis genau festlegen. Man darf auf es keinen Fall, nicht einmal read only, mit NFS exportieren. Jeder kann dann dieses Verzeichnis auf seiner eigenen Maschine mounten, um den Dom�nennamen herauszufinden.
Dar�ber hinaus schadet es nicht, tcp_wrapper zu benutzen. Damit kann man n�mlich den portmap-Prozess kontrollieren, und verhindern, da� jederman RPC-Requests auf die eigene Maschine absetzt.
Es ist ebenfalls von Vorteil, die Defaultroute nicht �ber Ihren NIS-Server zu legen, sondern statisches Routing zu den Klienten und den Slaveservern zu benutzen. Der Server kennt auf diese Art nur Routen zu genau festgelegten Maschinen und kann deshalb nicht auf Requests von unbekannten Maschinen antworten.
Auf dem Router-Level erlaubt eine Firewall, den Zugang zu den NIS-Servern effektiv zu kontrollieren.
Diese Ratschl�ge ergeben sich aus dem gesunden Menschenverstand. Sie ver�ndern nicht die Sicherheit von NIS selbst, sondern nur den Rahmen darum herum.Trotz dieser Probleme bleibt NIS ein effektives und praktisches Werkzeug.