YP hat seinen Ursprung in Berekley (Es war Teil der Berekley Software Distribution). Miterfinder Bill Joy brachte es später zu Sun Microsystems. Die Leute bei Sun brachten viele Verbesserungen an und gaben YP sein heutiges Erscheinungsbild. Sun mußte auch den Namen ändern (in NIS: Network Information System), weil British Telecom sie deswegen verklagen wollte. Später bauten sie ein ganz neues System und nannten es NIS+. In diesem Dokument vermeide ich den Begriff NIS, da er sonst zu Konfusionen führen könnte. Außerdem beginnen die meisten Programme sowieso mit den Buchstaben yp...
Wenn aber die Zahl der Maschinen auf die 300 zu geht, die Zahl der Benutzer auf die 10.000 und die Maschinen sich auf vielen Netzwerksegmenten tummeln, dann beginnt die Performanz von YP zu schwinden und es macht mehr und mehr Probleme. In diesem Falle braucht man was Besseres (wie NIS+).
Bei einem heterogenen Cluster hat man oft gar keine andere Wahl. Weil YP schon so alt ist und mit BSD-Unix verteilt wurde, ist es bei vielen Herstellern von Unix-Workstations beim Betriebssystem dabei. Aber es gibt subtile Unterschiede...
Man legt einfach eine Datei /etc/defaultdomain an, die den Namen der YP Domäne enthält und verteilt diese auf alle Maschinen, die der Domäne angehören sollen.
echo "Gollum" >/etc/defaultdomain
foreach host (bilbo frodo pippin merry dick sam)
rdist -c /etc/defaultdomain $host
end
Tip: SunOS 4.1.X hält eine Kopie des YP Makefile in /usr/lib/NIS-Makefile vorrätig.
Auf dem erkorenen YP Master Server (im Beispiel: bilbo) tippt man nun:
domainname `cat /etc/defaultdomain`
ypinit -m
bilbo
frodo
Ctrl-D
reboot
Neben ein paar unwichtigen und offensichtlichen Fragen will das Skript auch die Namen des Master und der Slave Server (bilbo und frodo) wissen. Nach dem Reboot kann man beobachten, wie die neuen Dämonen starten: ypserv, ypbind, ypxfrd, yppasswdd und ypupdated.
domainname `cat /etc/defaultdomain`
ypinit -s bilbo
reboot
Auch hier kann man nach dem Reboot neue Dämonen sehen: ypserv und ypbind.
domainname `cat /etc/defaultdomain`
ypinit -c
reboot
Hier braucht man nicht zu warten und ausserdem bekommt man als neuen Dämonen nur den ypbind zu sehen.
Auf jeden Fall ist es ziemlich aufschlußreich, mal einen Blick in die /etc/rc* Skripten zu werfen, um zu sehen, was bei bestimmten Ereignissen passiert und wie die Dämonen gestartet werden.
Zum Beispiel war ich gar nicht glücklich darüber, wie SunOS entschied, wann der Rechner ein YP Master Server war. Ich habe diese Zeile dann abgeändert:
if [ -f /var/yp/Makefile ]; then
Das macht Sinn und funktioniert bei mir seit Jahren prima.
YP benutzt Remote Procedure Calls (RPC), um die Datenbank auf dem Server abzufragen. Die Datenbanken werden mit "ndbm" aufgebaut und liegen in /var/yp/`domainname`. Folgende /etc Dateien residieren üblicherweise in der YP Datenbank:
Einige Betriebssysteme haben dazu sogar einen generellen Mechanismus implementiert. Solaris 2 tut das (über /etc/nsswitch.conf) genau wie Linux mit der neuen GNU libc. Auf solchen Systemen bereitet es keine Schwierigkeit, weitere Dateien aus /etc in die YP einzubauen (/etc/printcap wäre da ein Kandidat).
Man kann aber auch einige Daten aus der YP herausnehmen. Dazu muß man nur den Namen der /etc Datei aus der "all:"-Zeile des YP Makefile herausnehmen und die zugehörige Datenbankdatei aus /var/yp/`domainname` löschen. Dies kann in einem heterogenen Cluster notwendig sein, wenn die /etc Dateien der Betriebssysteme zuenander nicht passen (/etc/services hat diese Krankheit sehr oft). Manche der /etc Dateien ändern sich ja sogut wie nie oder sind nur auf dem Server notwendig. Ich nehme normalerweise die services, bootparams, aliases und timezone aus der YP raus.
cd /var/yp
make
und voila! Die Äderung wird sogleich auf allen Maschinen sichtbar.
Sind YP Slave Server da, sendet der Master Server eine Kopie der geänderten Datenbank zu ihnen.
Will ein Benutzer sein Passwort ändern, sollte er nun "yppasswd" benutzen. Es intoniert dann automatisch die "Magischen Worte", um die Datenbank zu aktualisieren. "yppasswd" ist oft nur ein Link zu "/bin/passwd".
Dieses Verhalten kann man auf zwei Arten ändern. Einmal kann man die DNS resolver Bibliothek (libresolv.a) in die dynamische libc einbauen. Hat man jedoch YP, bietet sich der zweite Weg an: Im YP Makefile gibt es eine Option "-b". Ist sie aktiviert, macht der YP Server DNS-Abrufe, wenn der Rechner in der YP nicht zu finden ist. Dazu braucht er nur eine funktionierende /etc/resolv.conf.
Rechnernamen, die mit der YP Domäne enden, werden dabei nur von der YP selber aufgelöst. Wenn man sicherstellen kann, daß die /etc/hosts auf dem YP Master Server immer mit der DNS-Domäne abgeglichen ist, dann kann man für YP und DNS den selben Domänenname benutzen. Andererseits sollte man (außer im obigen Fall) niemals einen gültigen DNS Domänenname als YP Domänenname benutzen. Sonst können merkwürdige Dinge passieren.
mv /etc/defaultdomain /etc/defaultdomain.off
mv /var/yp /var/yp.off
Bei der Gelegenheit wird man üblicherweise auch noch andere Änderungen vornehmen (Rechnername, /etc/hosts, /etc/passwd, /etc/fstab und so). Danach sollte die Maschine in den Mehrbenutzermodus hochfahren können.
cd /var/yp/`domainname`
makedbm -u ypservers >ypservers
echo "pippin pippin" >>ypservers
makedbm ypservers ypservers
cd /var/yp
make
Danach fährt man wie oben beschrieben fort, den YP Slave Server einzurichten.
Genau so kann man auch einen YP Slave Server entfernen. Man editiert die Datei ypservers, löscht den entsprechenden Eintrag, erzeugt die Datenbank und intoniert die "Magic Words". Anschließend muß man auf dem ehemaligen YP Server noch das Verzeichnis /var/yp/`domainname` löschen und rebooten.
Das funktioniert aber nicht mit dem YP Master Server.
Schlimmer noch: Zwei YP Server, die gleichzeitig rebooten (passiert z.B. nach einem Stromausfall), können sich gegenseitig binden! Das ist eine besonders krasse Situation, denn wenn eine der Maschinen später stoppt (Crash, Reboot), dann hängen nicht nur dessen Clienten, sondern der andere YP Server und alle seine Clienten auch. Manchmal erholt sich dieser Server nicht, auch wenn der andere YP Server wieder hochgefahren wird.
Ein plattenloser Client sollte seine YP auf seinem NFS-Server finden. Der NFS-Server ist schon eine Fehlerquelle an sich. Bindet sich der Client auch noch an einen anderen YP Server, gibt es schon zwei disjunkte Fehlerquellen. Solche disjunkte Fehlerquellen führen zu Fehlern, die sich nicht aufsummieren, sondern exponentiell vervielfachen!
Es gibt eine einfache Lösung für dieses Problem: "ypbind" kennt eine Option ("-ypsetme"), mit der man später noch den YP Server ändern kann, an den sich 'ypbind" bindet. Damit kann man sicherstellen, daß ein YP Server nur an sich selber bindet und ein plattenloser Client nur an seinen NFS-Server (um nicht eine weitere Fehlerquelle hinzuzufügen).
Hier ein Ausschnitt aus meinem /etc/rc.local. "ypbind" wird darin mit der Option "-ypsetme" gestartet und später wird mit "ypset" auf den richtigen YP Server umgeschaltet:
dname=`domainname`
if [ "$dname" -a -d /var/yp ]; then
ypbind -ypsetme; echo -n ' ypbind'
fi
if [ -d /var/yp/`dname` ]; then
sleep 5
/usr/etc/yp/ypset `hostname`
fi
server=`grep ":.*[ ][ ]*/[ ]" /etc/fstab |\
sed -e "/^#/d" -e "s/:.*//"`
if [ "$server" ]; then
intr -a rdate $server
if [ "$dname" -a -d /var/yp ]; then
/usr/etc/yp/ypset $server
fi
fi
Der Ausschnitt ist nur ein roher Extrakt und soll lediglich zeigen, wie es gemacht wird.
Muß man jedoch die IP-Adresse des Master Servers ändern, bleibt einem nichts anderes übrig, als die YP komplett auf allen Rechnern zu entfernen. Nachdem man die IP-Adresse geändert hat, muß man die YP neu aufbauen. Nur so und nicht anders funktioniert es.
Nagut, nagut, ich mache nur Spaß. Man kann schon was machen, damit YP sicher wird. Wenn "ypserv" die Datei /var/yp/securenets erkennt, dann sollte man diese auch unbedingt benutzen, weil das schon sehr viel hilft.
Man kann aber auch andere Sicherheitswerkzeuge benutzen, um YP sicherer zu machen. Als erstes braucht man unbedingt eine aktuelle Version des "portmapper". Entweder man findet einen Patch beim Hersteller oder man baut sich den "portmapper" von Wietse Venema.
Paranoide Administratoren müssen die YP Dämonen unter Kontroller der TCP-wrapper-libc laufen lassen.
Man kann Shadow-Passworte mit YP benutzen, aber der "ypserv" sollte alle Anfragen auf die Shadow-Daten außer "ypmatch" zurückweisen. Der "ypserv" von Sun erlaubt hingegen Listanfragen, wenn diese von einem Port kleiner 1024 kommen. Das ist ok, solange im Netzwerk nur vertrauenswürdige Rechner sind, aber ein dummer PC reicht, um alle (immerhin noch verschlüsselten) Passworte zu bekommen.
Es wäre eine gute Idee, die Shadow-Passwörter verschlüsselt an die Slave Server zu übertragen, wenn "ypxfrd" dies unterstützen würde.
hosts: files dns [NOTFOUND=return] nisDas bedeutet: Schau erstmal in die /etc/hosts. Wenn da nix gefunden wurde, frage DNS. Wenn DNS nix findet, dann war's das. Meldet DNS einen Fehler, dann frage die YP.