Nisserver mit mehreren Typen von Maps

Überlegungen zur Administration

Konfigurationstest

Die Konfigurationsdatei hat nun eine etwas kompliziertere Syntax bekommen. Deswegen verwische ich meine Spuren nicht und lasse dem Administrator mein testprogramm:

nmpars -d level-s confdatei

Als Debuglevel ist hier 2 gut, dann wird die Zugriffsliste getestet. Mit -s kommt die bison-Parserdebugausgabe, da kann man herausfingen warum der Parser eine andere meinung hat. Bemerkung: Der wahre Programmierer und Administrator braucht so was nicht, weil ohnehin alles trival ist.

So wahr ich diese Leute bewundere, bin ich jedoch der Meinung, daß es sehr Hilfreich ist, daß man seine Konfiguration vorher testen kann. Gerade in Bezug auf die Sicherheit mit den Zugriffsliesten halte ich das für unentbehrlich. Man denke auch an Administatoren, deren Nutzer für Experimenten des Administrators nichts übrig haben ...

Generieren der Maps

Traditionellerweise sind die Maps readonly und werden bei Änderungen einfach überschrieben. Ich vermute, daß es den Erfindern von YP/NIS vorallem auf die Netzwerkseite ankam und diese die Map-Seite so einfach wie möglich machen wollten.

Bei gdbm wird die Sperrung während des gesamten Zugriffs gemacht. Daher können Schreibe- und Lese-Prozesse nicht koexistieren. BerkleyDB erlaubt nun endlich die Koexistenz.
Daher ist das Neugenerieren bei jeder Änderung anachronistisch. Bei der Dmap-Implementierung habe ich schon an den yppasswdd/ypadmindd gedacht. Daher können manche Maps beschreiben werden.

makedbm

Tratitionell gibt es das Programm makedbm, das die Maps generiert.

Jeder sendmail-Freund kennt auch das Programm makemap, welches Maps für den Sendmail generiert.

Ich habe nun makemap mit der dmap-Bibliothek objektorientiert reimplementiert, aber ohne die nis- und sendmail-spezifischen Sachen. Die Überlegung ist, ob man alles verallgemeinert und die yp-spezifischen Sachen extra macht.

Rudolf Weber Informatik und Netzwerkverein Ravensburg e.V