[LinuxFocus-icon]
Home  |  Map  |  Index  |  Zoek

Nieuws | Archieven | Links | Over LF
Dit document is beschikbaar in: English  Castellano  Deutsch  Francais  Nederlands  Portugues  Russian  Turkce  

convert to palmConvert to GutenPalm
or to PalmDoc

[Photo of the Author]
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:

 

Yellow Pages, deel 1

[Illustration]

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.

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.

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
Dus, als een cliënt het wachtwoord van een gebruiker genaamd Toto wil vinden in het domein titi, zal hij het bestand /var/yp/titi/passwd.byname lezen op de YP-server op zoek naar de gebruiker.

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.

Conclusie

Nu we het algemene principe kennen, zal het volgende artikel gaan over de cliëntkant van yellow pages: hoe het werkt, hoe het te configureren, de gereedschappen die gebruikt worden, enz... We zullen ook moeten kijken naar de gereedschappen die nodig zijn om onze cliënt correct te configureren zowel voor RPC als voor YP.  

Talkback voor dit artikel

Elk artikel heeft zijn eigen talkback pagina. Daar kan je commentaar geven of commentaar van anderen lezen:
 talkback pagina 

Site onderhouden door het LinuxFocus editors team
© Frédéric Raynal, FDL
LinuxFocus.org

Klik hier om een fout te melden of commentaar te geven
Vertaling info:
fr --> -- : Frédéric Raynal <pappy(at)users.sourceforge.net>
fr --> en: Jo Simoens <rainbow(at)linuxfocus.org>
en --> en: Lorne Bailey <sherm_pbody(at)yahoo.com>
en --> nl: HJ Heins <hjh(at)passys.nl>

2002-06-08, generated by lfparser version 2.28