![[Photo of the Author]](../../common/images/Frederic_Raynal.png)
Original in fr Frédéric Raynal
fr to en: Jo Simoens
en to en: Lorne Bailey
en to nl: HJ Heins
![[Illustration]](../../common/images/illustration148.gif)
De Network Information Service (NIS) werd in eerste instantie gecreëerd door Sun en stond bekend als de Sun Yellow Pages (beter bekend als de Yellow Pages of YP). Dit is echter een handelsmerk van British Telecom en daarom mag het niet gebruikt worden zonder hun toestemming. Deze Yellow Pages zijn een verwijzing naar degene waarin we telefoonnummers kunnen opzoeken (Gouden Gids).
De NIS servers beheren kopieën van gewone configuratiebestanden op verschillende machines die aan elkaar gekoppeld zijn via een netwerk in een database. De NIS-cliënten vragen de server om deze bestanden in plaats van hun eigen configuratie te gebruiken.
Laten we doen alsof we een gebruiker zijn op een netwerk die z'n wachtwoord wil veranderen. Laten we eerst doen alsof YP niet is geïnstalleerd. Deze gebruiker moet inloggen op alle machines in het netwerk om z'n wachtwoord te veranderen. Als YP geïnstalleerd zou zijn, zou hij z'n wachtwoord op één van de NIS-cliënten kunnen veranderen, waarna het wachtwoord wordt doorgegeven aan een NIS server waar dit dan veranderd wordt in de database. Als de gebruiker hierna een machine met een netwerkverbinding benadert (eentje waarop een NIS-cliënt draait natuurlijk ;-), zal z'n wachtwoord worden vergeleken met datgene dat in de database van de server staat.
Er bestaan verschillende varianten van YP, maar aangezien dit artikel een introductie is, zullen we alleen naar de principes van hoe het werkt kijken, zonder dat we in detail zullen treden. Deze details komen later aan bod.
glibc 2.x (libc6) ondersteunt het gebruik van NSS (Name Switch Service) dat de volgorde waarin de informatie opgezocht moet worden, bepaalt. (zie het bestand /etc/nsswitch.conf). Dit beheert de aliassen, subnetten, groepen, gastheren, netgroepen, netwerken, protocollen, publieke sleutels, wachtwoorden, rpc, services en schaduwbestanden.Er moet een machine op het netwerk zitten die fungeert als NIS-server voor het domein. Dit domein correspondeert, min of meer met de naam van de database die de server beheert. Dit is de sleutel die de NIS-cliënten gebruiken om de benodigde informatie op de NIS-server te lokaliseren. Dit domein heeft absoluut niets te maken met de DNS domeinnaam. Er kan meer dan een NIS server op hetzelfde domein zitten. Ze kunnen ieder een verschillend domein administreren (op NIS niveau), of ze kunnen hetzelfde domein administreren (in dat geval is er een master server en (meerdere) slave servers).
De slave servers hoeven alleen maar een kopie te hebben van de database van de master server. Deze servers vullen de master server aan als deze er te lang over doet om te antwoorden op een aanvraag van een cliënt of wanneer de master server uitvalt.
De slave servers worden van alle veranderingen in de database op de hoogte gesteld door het programm yppush en daarmee zullen ze hun eigen database updaten zodat deze er exact hetzelfde uit ziet als de database op de server.
De cliënten hebben echter geen "onderhoud" nodig aangezien zij continu in contact staan met de NIS server om informatie in z'n database op te zoeken.
De YP database staat in het GDBM formaat, dat is afgeleid van het ASCII formaat. Ze wordt aangemaakt tijdens de installatie van de server door het makedbm programma.
Deze tabellen maken een relatie aan tussen een sleutel en diens waarde. Alle YP-tabellen zijn gebaseerd op dit model. Vanaf de server gezien, heeft de database geen waarde (tenminste, behalve enkele uitzonderingen wat betreft gegevens over de hoofdserver of data). Dit betekent dat, wat betreft de server, een tabel met wachtwoorden of groepen niets meer is dan een set van sleutel/waarde paren. Alleen de YP cliënt weet hoe hij moet zoeken in deze tabellen om de benodigde informatie te vinden.
Deze representatie van gegevens kan problemen opleveren. Aangezien de server de waarde van een sleutel niet kan "uitlezen" om een tweede sleutel in de database te vinden, is het nodig om de gegevens te dupliceren. Bijvoorbeeld in het geval van wachtwoorden, waar iemand deze zou willen opzoeken door gebruik te maken van de login naam of het gebruikers-ID of UID (een unieke identificatie voor iedere gebruiker op het netwerk). Dit leidt tot redundantie van gegevens, zoals gezien kan worden aan de aanwezigheid van de passwd.byname en passwd.byuid bestanden. Als gevolg daarvan zal er een nieuwe map aangemaakt worden voor iedere sleutel, wat betekent dat de gegevens tweemaal moeten worden verzonden in geval van een verandering.
Er zijn drie parameters nodig om een cliënt toe te laten de gegevens die hij nodig heeft, te vinden in de database:
Dit levert een zeer flexibel systeem, aangezien het aanmaken van een nieuw domein niet meer inhoudt dan het maken van een directory /var/yp/new_domain, het copiëren van Makefile en het uitvoeren hiervan met de juiste opties en instellingen.
De functionaliteit van YP is in essentie gebaseerd op "Remote Procedure Calls" (RPCs) die aanvragen tussen de server en diens cliënten aannemen.
De RPC poortmapper (portmap) is een programma dat de RPC-programmanummers omzet in poortnummers. Wanneer een RPC wordt gestart, zal hij de portmap vertellen welke poort hij gaat gebruiken en de RPC programmanummers die hij beheert. Wanneer een cliënt een RPC aanvraag indient onder een zeker programmanummer, zal hij eerst de portmapserver aanspreken om het poortnummer te verkrijgen waarop het programma draait. Nadat hij dit poortnummer heeft verkregen, adresseert hij de RPC-pakketten naar de corresponderende poort. Het cliënt/server model van YP is niets meer dan een specifieke vorm van het algemene cliënt/server RPC.
Het bestand yp_prot.h bevat de strukturen en de koncepten van 11 functies die het RPC protocol tussen de cliënten en de YP server definieert.