Home  |  Map  |  Index  |  Zoek

Convert to GutenPalm or to PalmDoc door Frédéric Raynal <pappy(at)users.sourceforge.net> Over de auteur: Frédéric Raynal schrijft een thesis over informatisering aan de INRIA. Hij houdt van lezen (zowel Tolkien als Balzac) en van luisteren naar muziek (van Mozart tot Philip Glass en van Led Zeppelin tot Massive Attack via Björk en Boris Vian, maar daarbij vermijdt hij rap, techno en andere soorten lawaai ;-) Vertaald naar het Nederlands door: HJ Heins <hjh(at)passys.nl> Inhoud: Structuur De tabellen Talkback voor dit artikel

Yellow Pages, deel 1

Kort:

De Network Information Service (NIS) beheert een database op een server. Iedere machine op het netwerk waarop een NIS server draait kan een aanvraag doen bij de server om informatie te verkrijgen (zoals login, naam, wachtwoord, informatie over gebruikers, groepen,...). Dit zorgt voor een gecentraliseerd beheer van veel machines (vooral wanneer dit systeem gebruikt wordt in samenwerking met een gedistribueerd netwerkbestandssysteem zoals NFS) aangezien de veranderingen die worden aangebracht in deze gegevens via de server aan al z'n cliënten wordt doorgegeven.

Inleiding

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.

Hoe werkt het?

Structuur

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 tabellen

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:

1. de domeinnaam: dit is de naam van de database op de YP server
2. de mapnaam
3. de naam van de sleutel

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.

"Remote Procedure Calls" (RPC)

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.

• YPPROC_DOMAIN en YPPROC_DOMAIN_NOACK staan cliënten op een server voor een gegeven domein toe.
• De functies YPPROC_MATCH, YPPROC_FIRST, YPPROC_NEXT en YPPROC_ALL geven toegang tot de mappen die de tabellen bevatten.
• YPPROC_XFR wordt aangeroepen door yppush om aan de slave servers aan te geven dat de tabel op de master server veranderd is en dat zij hun kopieën moeten bijwerken.
• YPPROC_CLEAR ruimt de cache en de bestandsaanhechtingspunten op. Deze funktie wordt aangeroepen nadat de map up to date is gebracht, bijvoorbeeld na het makedbm -c commando.
• YPPROC_MASTER, YPPROC_ORDER en YPPROC_MAPLIST staan het verkrijgen van speciale informatie over de mappen toe. Bijvoorbeeld om het wachtwoord te veranderen, het yppasswd programma doet een aanroep naar YPPROC_MASTER om de master server te bepalen voordat hij het wachtwoord te verandert.

Conclusie

Talkback voor dit artikel

2002-06-08, generated by lfparser version 2.28