05.08.2013 Aufrufe

Folien Kapitel 7 - Universität Ulm

Folien Kapitel 7 - Universität Ulm

Folien Kapitel 7 - Universität Ulm

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

7 Namensverwaltung

Namen dienen in verteilten Systemen dazu, Ressourcen, zu benennen und zu identifizieren:

• Computer

• Dienste

• Ports

• Netzadressen

• Objekte

• Dateien

• Prozesse

• Benutzer

Themenstellungen für die Namensverwaltung:

• Struktur von Namen

• Vergabe und Administration

• Zugriff auf Namen

• Abbildung von Namen auf die durch sie repräsentierten Objekte

7.1 Namen in verteilten Systemen

Aufgaben und Eigenschaften von Namen

• Erklärung

Der Name gibt Auskunft über die Art des benannten Objektes

- z.B.: „SekretariatsFarbdrucker“ oder „Kapitel 7“

Prof. Dr. Michael Weber; Verteilte Systeme, SS99, Universität Ulm

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 1

• Identifizierung

Eine Systemidentifikation oder Ressourceidentifikation wird durch den Zugriff über dessen

Namen verborgen

- z.B.: „frodo.informatik.uni-ulm.de“ verbirgt die IP-Adresse dieses Rechners

• Lokalisierung

Die Adresse eines Objektes wird durch den Zugriff über einen Namen verborgen

- Die E-mail-Adresse „weber@informatik.uni-ulm.de“ steht z.B. für die zugehörige Mailboxadresse

Namen sollten sowohl für Endanwender, als auch für Administratoren und Programmierer sinnvoll

sein.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 2


Verwendungskontexte von Namen

• Namen, die im Kontext eines Dienstes benutzt werden

- z.B. ein Dateiname im Dateisystem oder der Prozeßidentifikator im Prozeßmanagement

- die Dienste sind in der Lage, die Namen selbst zu verarbeiten

• dienstübergreifende Namen

- z.B. Benutzername, eine E-mail-Adresse oder ein Dienst selbst, wie das Dateisystem oder

der Druckdienst

• Ein Name ist meist einem Objekt zugeordnet

• Diese Zuordnung nennt man Binden

• Dienstspezifische Namen können direkt an die aktuelle Repräsentation des Objekts gebunden

werden

• Dienstunspezifische Namen werden an Attribute gebunden

• Jedes Objekt hat eine Adresse als Attribut (E-mail, IP-Adresse, Telefonnummer, …)

• Zusätzliche Attribute sind etwa Paßwörter, Home Directories, Versionsnummern, oder die

Betriebssystemversion

• Die Attributwerte bestehen wiederum aus Namen oder sind einfache, primitive Werte (z.B.:

integer)

• Primitive Namen können nicht mehr weiter aufgelöst bzw. unterteilt werden.

Abhängigkeit der Namen von der physischen Konfiguration

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 3

• reine Namen (engl.: pure names) enthalten keine Abhängigkeit

• unreine Namen (engl.: impure names) enthalten solche Informationen

• „Kapitel 7“ ist ein reiner Name, während „frodo.informatik.uni-ulm.de“ ein unreiner Name

ist, da er Ortsinformation beinhaltet.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 4


Namensraum

• Die Menge aller gültigen Namen, entsprechend einer definierten Syntax, nennt man einen

Namensraum

• Ein gültiger Name im Namensraum muß nicht unbedingt gebunden sein

• Namen im selben Namensraum sind immer eindeutig und dürfen deshalb auch nur an ein

Objekt vergeben werden.

• Die Generierung eindeutiger Namen erfolgt zum Beispiel durch einen knotenlokalen Zähler.

Hängt man eine Rechneridentifikation an, so lassen sich global eindeutige Namen erzeugen.

• Häufig setzen sich Namen aus Komponenten zusammen, wie zum Beispiel „informatik.uniulm.de“

oder „/home/weber“

• Einen gültigen Anfangsteil eines Namens nennt man dessen Präfix, den Endteil Suffix.

• Präfix und Suffix sind selbst wieder Namen.

• Typische Anwendung davon sind die hierarchisch angelegten Bezeichnungen von Dateiverzeichnissen

oder Netzdomänen.

• Häufig erlauben Aliase die Zusammenfassung von Komponenten zu einem neuen Namen.

• Die Verwendung reiner Namen erzeugen einen flachen Namensraum.

• Verwendet man strukturierte Namen, so erreicht man meist einen hierarchischen Namensraum.

• Durch die hierarchische Struktur lassen sich solche Namensräume leicht dezentral verwalten

und sind gut skalierbar.

Partitionierung von Namensräumen

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 5

• physisch partitioniert

Namen tragen die physische Ortsinformation in sich

- zum Beispiel „Kapitel7:PlatteA.Rechner-17“

- die Adresse ist direkt aus dem Namen bekannt

- kein Nachfragen bei einem Namensdienst notwendig

- der Namensraum ist unflexibel für die Umorganisationen der Objekte.

• organisatorisch partitioniert

Meist sind hierarchische Namensräume organisatorisch partitioniert.

- Ein Name wie „vs.informatik.uni-ulm.de“ bezeichnet die aufsteigende Organisationsstruktur,

die sich hinter dem benannten Objekt befindet

- dezentrale Namensverwaltung jeweils unterhalb des eigenen Präfixes bzw. Suffixes möglich

Namensdomäne

ist ein Namensraum, für den eine einzelne Verwaltungsinstanz zuständig ist

• Pro Domäne gibt es typischerweise einen Namensdienst

• Eine Domäne kann wiederum Subdomänen beinhalten, die einen Subnamensraum aufspannen

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 6


7.2 Namensdienste

Ein Namensdienst ist eine Datenbasis, welche die Zuordnung von Namen zu Objekten und damit

zu deren Attributen und Werten speichert.

Hauptaufgabe:

• Namensanfragen in die entsprechenden Attribute auflösen (engl.: resolve).

Da große Namensräume meist auf mehrere, verteilte Datenbasen aufgeteilt werden müssen,

spricht man bei dem verwalteten Inhalt einer Datenbasis von deren Kontext.

Die Namensverwaltung ist meist ein eigener Dienst

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 7

• Separation

Offenheit verteilter Systeme

- spezifische Dienste werden separiert angeboten, so dass unterschiedlichste Klienten diesen

Dienst in Anspruch nehmen können

- Veränderungen des Dienstes erfolgen dann an nur dieser einen Stelle und sind sofort für

alle verfügbar.

• Unifizierung

Das gleiche Namensschema gilt für unterschiedliche Dienste

- In Unix werden beispielsweise alle Ein-/Ausgabemedien wie Dateien, Devices oder Pipes

mit der gleichen Syntax bezeichnet

- ist zusätzlich NFS (Network File System) installiert, werden lokale und entfernte Dateien

mit identischer Syntax bezeichnet.

• Integration

Im Laufe der Zeit können Namensräume zusammenwachsen oder sich auftrennen

- Diese Änderung an einer Stelle im System durchzuführen ist dann einfacher

- Allerdings können beim Zusammenfügen nicht nur doppelte Namen vorkommen, sondern

auch unterschiedliche Namenskonventionen in den Teilbereichen gelten, was das Zusammenwachsen

erschwert.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 8


Anforderungen an Namensdienste

• lange Lebensdauer

Der Namensdienst wird über eine lange Zeit benötigt werden. Während dieser Zeit werden

viele Änderungen der Einträge stattfinden.

• hohe Verfügbarkeit

Viele andere Dienste und Programme verlassen sich auf den Namensdienst. Ein nicht verfügbarer

Namensdienst macht auch die davon abhängigen Dienste nicht verfügbar.

• Fehlerisolation

Einzelne, lokale Ausfälle dürfen nicht den gesamten Namensdienst lahmlegen.

• Toleranz von Mißtrauen

Ein großes, offenes System kann keine Komponente haben, der alle Klienten trauen. Namen

müssen aber authentisch sein, um sinnvoll zu sein.

Daten und Operationen

• Die Daten eines Namensdienstes liegen als Paare

vor

• Attribute werden als zu Namen gespeichert

Typ

Benutzer

Service

Computer

Gruppe

Alias

Bild 7.1: Attribute von Namen

Attributwerte

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 9

Login name, Computer für Mailempfang, Telefonnummer, ...

Adresse, Version

Architektur, Betriebssystem, Netzwerkadresse, Owner, ...


Name

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 10


Standardoperationen eines Namensdiensts

• Binden

Die Zuordnung von Name und Attributen wird im Namensdienst gespeichert.

• Auflösen

Im Namensdienst wird der entsprechende Namen gesucht. Falls er gebunden ist, werden die

Attribute zurückgeliefert.

• Löschen

Ein Namenseintrag wird gelöscht. Hier ist zu beachten, daß Kontexte auch Namen sind, deren

Löschen ganze Teilbereiche eines Namensraums unerreichbar machen kann.

• Die Operationen nutzen jeweils die Namen als Suchschlüssel.

• Bei attributbasierten Namensdiensten können auch Attributwerte als Schlüssel verwendet

werden

• Suchanfragen liefern dann im allgemeinen eine Menge von Namen/Attributpaaren zurück

• Um bestimmte Dienste zu finden, ist dies sehr nützlich

- z.B. finde alle PCs der Fakultät mit Windows NT, oder finde alle Druckerspooler des Drukkers

LaserII.

• die attributbasierten Namensdienste nennt man auch Yellow Page Services

• konventionelle Namensdienste nennt man auch White Page Services.

Namensauflösung und Navigation

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 11

• Einen Namen nachzuschauen, bezeichnet man als Namensauflösung (engl.: name resolution)

• Bei hierarchisch aus Komponenten zusammengesetzten Namen entspricht dies einer Traversierung

des Syntaxbaumes, bei gleichzeitiger Traversierung der Datenbasiseinträge im verteilten

Namensdienst.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 12


DE-Server

USt-Server

ET-Server

dbis-Server

uni-stuttgart

Bild 7.2 Partitionierung von Namensräumen

uni-ulm uni-karlsruhe

e-technik

users

dbis

informatik mathe

vs ki

computers

UUlm-Server

Info-Server

VS-Server

...

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 13

• Oft ist mit der Auflösung die Navigation durch verschiedene Namensserver verbunden.

- Die logische Struktur eines Namensraums ist physisch auf verschiedene Server aufgeteilt.

- Dabei werden üblicherweise gleiche Präfixe bzw. Suffixe in einer physischen Lokation

zusammengefaßt.

- Dies vereinfacht Binden und Löschen von Namenseinträgen.

• Klienten beauftragen einen Useragenten mit der Namensauflösung.

- Dieser nimmt die Navigation durch die verschiedenen Nameserver vor und

- liefert nach erfolgreicher Auflösung das Ergebnis an den Klienten.

• Der Useragent kann

- als Bibliothekspaket, das zur Klientensoftware gebunden wird, oder

- als separater Prozeß implementiert sein, der dann mehreren Klienten gleichzeitig dient.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 14


Navigationsvarianten

• Iterative Navigation

- Kann eine Anfrage bei einem Namensserver nicht vollständig aufgelöst werden, wird die

Adresse eines anderen Namensservers zurückgeliefert.

- Bei dieser Adresse kann der Useragent dann erneut anfragen.

- Die Namensserver halten Kontextinformationen, die die Adressen der Server beinhalten,

die weiterführende Informationen zum angefragten Namen haben.

Bild 7.3 Iterative Navigation

UA

(1)

(3)

(2)

NS1

NS2

NS3

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 15

• Multicast-Navigation

- Der Useragent schickt die Anfrage per Multicast an alle Namensserver.

- Bei ungebundenen Namen antwortet keiner, ansonsten derjenige, der den Namen kennt.

UA

Bild 7.4 Multicast-Navigation

(1)

(2)

NS1

NS2

NS3

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 16


• Iterative serverkontrollierte Navigation

- Der Useragent stellt seine Anfrage an einen Namensserver.

- Dieser übernimmt dann iterativ die weitere Navigation.

- Der zuerst beauftragte Namensserver übernimmt quasi die Rolle eines iterativ navigierenden

Useragenten.

Bild 7.5 Iterative serverkontrollierte Navigation

Klient

Resolver

Bild 7.6 Beispiel: DNS

UA

(1)

(4)

Query:

rechner.rz.firma-c.de

Answer: 1.2.3.4

Name

Server

NS1

(3)

(2)

NS2

NS3

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 17

de ?

firma-c.de ?

rz.firma-c.de ?

rechner.rz.

firma-c.de ?

Root-Server

com

de

DE-Server

firma-a

firma-b

firma-c

firma-c.de

abt1

abt2

rz

rz.firma-c.de

rechner 1.2.3.4

server 1.2.3.5

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 18


• Rekursive serverkontrollierte Navigation

- Kann ein Namensserver einen Namen nicht vollständig auflösen, so beauftragt er einen

anderen Namensserver.

- Dieser verfährt dann gegebenenfalls genauso.

- Es erfolgt dadurch ein rekursiver Abstieg entsprechend der konkreten Namenssyntax.

Bild 7.7 Rekursive server-kontrollierte Navigation

Anmerkung zur Sicherheit

• Falls ein Namensdienst administrative Grenzen überschreitet, sind die Useragenten und

Namensserver unter Umständen nicht mehr zugriffsberechtigt.

• Dies bedingt, daß dann meist rekursiv serverkontrolliert zu verfahren ist.

Caching und Replikation

UA

(1)

(5)

NS1

(4)

(2)

NS2

NS3

(3)

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 19

• Um Zugriffe auf oder unter Namensservern zu reduzieren, wird Caching eingesetzt.

• Bei jeder Namensauflösung werden Paare aus oder

im Useragenten bzw. Server gespeichert.

• Caching verbessert die Leistungsfähigkeit des Namensdienstes und erhöht die Verfügbarkeit

bei Ausfällen.

• Die Cacheverfahren nutzen, daß sich Namensinformationen nur selten ändern.

• Es wird dabei keine strikte Konsistenz gefordert.

- Eine fehlerhafte Namensauflösung läßt den angeforderten Dienst des Klienten im schlechtesten

Fall mit einer Fehlermeldung zurückkehren.

- Eine zweite Namensauflösung wird dann gestartet, die sich nicht mehr aus dem Cache

bedient, sondern an den Namensdienst wendet.

• Caching ist ein Grund, warum Useragenten oft als eigenständige Prozesse implementiert werden.

- Somit können mehrere Klienten von Nachfragen anderer profitieren.

• Replikation ist eine weitere Möglichkeit, die Verfügbarkeit .

- Die gesamte oder Teile der Namensinformation eines Namensservers wird an anderen

unabhängigen Stellen nochmals gehalten.

- Die Zuordnung kann als Primär- und Sekundärserver oder als symmetrisches Serverkonzept

erfolgen.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 20


7.3 Internet Domain Name System

In den Anfängen des Internet:

• alle Rechnernamen und ihre IP-Adressen werden in einer zentralen Masterdatei gehalten.

• bei Bedarf wird diese Datei mittels FTP in den lokalen Rechner geladen.

mit der Verbreitung des Internet ist eine besser skalierbare Lösung nötig:

• Internet Domain Name System, DNS [Mockapetris 1987].

• DNS ist konzeptuell für viele Namensräume entworfen

• Verwendung findet es nur für den Namensraum des Internet

• Die Namensräume des DNS sind baumstrukturiert, wobei die Namenskomponenten durch

einen Punkt getrennt werden.

• Der Weg vom Knoten zur Wurzel wird von links nach rechts aufgeschrieben.

• Der Internet-Namensraum ist in den USA organisatorisch partitioniert.

• ausserhalb der USA ist er vorwiegend geographisch partitioniert.

Folgende Endsuffixe (Top Level Domain, TLD) sind vergeben:

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 21

• generic TLDs

- com Kommerzielle Organisationen.

- edu Bildungseinrichtungen.

- gov Verwaltungs- oder Regierungseinrichtungen.

- mil Militärische Organisationen.

- net Netzwerkunterstützungszentren.

- int Internationale Organisationen.

- org Andere Organisationen.

• neue generic TLDs

- arts Unternehmen im Bereich Kultur/Unterhaltung.

- firm Unternehmen und Firmen.

- info Unternehmen im Informationsdienstleistungssektot.

- nom private Internetnutzer.

- rec Unternehmen im Bereich Erholung/Freizeit.

- shop Verkaufseinrichtungen.

- web Web-Angebote.

• (geographische) TLDs

- de, uk, fr, it, … : Zwei Buchstaben kennzeichnen das jeweilige Land.

- Die geographischen Domänen sind nicht physisch an ihre Länder gebunden.

- Ein Name mit dem Suffix „.de“ kann auch eine Firmendependence einer deutschen Firma

in jedem beliebigen Land der Welt sein.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 22


• Die Namen im DNS heißen Domain Names.

• Die Vergabe der Namen liegt bei der entsprechend der Baumstruktur vorgegebenen Verantwortlichkeit.

• Das DNS selbst kennt keine relativen Namen, so daß immer der komplette Name zur Auflösung

notwendig ist.

• Oft gleicht die Klientensoftware, d.h. der Useragent, dies aus, indem sie an einfache Namen

(z.B. „frodo“) die Default Domain (z.B. „.informatik.uni-ulm.de“) anhängt.

DNS unterstützt für Klienten zwei Standardanfragen:

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 23

• Namensauflösung

- Zu einem Rechnernamen wird die IP-Adresse zurückgeliefert.

- Dies bezeichnet man als Host Name Resolution.

• Mail Host Location

- Die E-mail-Software fragt bei DNS nach den Mailhosts für eine E-mail-Adresse und

- bekommt eine geordnete Liste mit Domain Names der Rechner, die für diese Adresse eine

Mailbox bereithalten.

- An diese Liste (meist nur ein Eintrag) kann die Software dann die Mail abschicken.

Zusätzliche DNS-Anfragen sind definiert, werden jedoch nicht von allen Implementierungen

angeboten.

• Reverse Resolution

- Zu einer IP-Adresse wird der Domain Name des Rechners ermittelt.

• Host Information

- Zu jedem Rechner können Informationen über den Architekturtyp und das Betriebssystem

angefragt werden.

- Dies ist aus Sicherheitsgründen meist nicht verfügbar.

• Wohlbekannte Dienste

- Zu jedem Rechner wird eine Liste bekannter dort verfügbarer Dienste wie telnet, ftp oder

WWW, sogenannte Well Known Services, und deren verwendetes Protokoll, z.B. TCP oder

UDP, geliefert.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 24


DNS Namensserver

• Jeder DNS Namensserver verfügt über einen Teil der gesamten Namensdatenbasis.

• Vorwiegend besteht dieser Teil aus den Daten der lokalen Domäne.

• Die Vereinigung aller Namensserver bildet dann die gesamte Datenbasis.

• Die Namensdaten sind dabei in Zonen unterteilt. Eine Zone enthält folgende Daten:

- Attribute aller Namen der Domäne, außer der Subdomänen, die separat verwaltet werden.

- Namen und Adressen der Namensserver, die maßgebende Daten der Zone halten, d.h. diese

Daten sind die aktuellsten.

- Namen der Server mit maßgebenden Daten von Subzonen.

- Managementparameter, wie Caching- und Replikationssteuerung.

• Alle Zonendaten werden in Dateien, sogenannten Resource Records gespeichert.

• Die verwendeten Recordtypen sind:

- A (Computeradresse),

- NS (maßgebender Namensserver),

- CNAME (kanonischer Aliasname),

- SOA (Start der Zonendaten),

- WKS (well-known Service),

- PTR (Domain Name Pointer für Reverse Resolution),

- HINFO (Host Info),

- MX (Mail Exchange),

- TXT (Text).

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 25

• Jede Zone muß mindestens einmal repliziert werden.

• Die Primärserver lesen die Zonendaten direkt aus einer Masterdatei, die der Systemverwalter

pflegt.

• Die Sekundärserver laden die Information periodisch von ihrem Primärserver.

• Die Frequenz der Aktualisierung wird vom Systemverwalter eingestellt und liegt typischerweise

bei ein- bis zweimal am Tag.

Caching

• Die Server dürfen Daten cachen.

• Jeder Eintrag hat ein Verfallsdatum (engl.: time-to-live) und nur für diese Zeit stellen Server

Klienten Daten aus dem Cache zur Verfügung.

• Die Server halten dabei Einträge über bis zu zwei Namenskomponenten bzw. Domänen hinweg.

• Dadurch ist es möglich, meist mit zwei Zugriffen zu Namensservern auszukommen, um einen

Namen aufzulösen.

• Die DNS Hierarchie ist nämlich selten tiefer als vier Stufen.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 26


User Agent und DNS Protokoll

• Die Useragenten des DNS heißen Resolver.

• Sie sind im allgemeinen als Bibliothekssoftware implementiert, die über UDP das DNS-Protokoll

fahren.

• DNS erlaubt iterative und rekursive Navigation.

• Die Wahl liegt beim Resolver.

• Es ist auch möglich, mehrere Anfragen in ein Protokollelement zusammenzupacken und so

mit einer Nachricht gleich einige Namen auflösen zu lassen.

BIND

• Eine in der Unix-Welt oft eingesetzte Implementierung ist Berkeley Internet Name Domain,

BIND.

• Die BIND-Namensserver laufen als named Dämonen

• Die Useragenten sind durch Bibliothekssoftware implementiert.

Zusammenfassung

• DNS ist ein recht primitiver Namensdienst im Internet.

• DNS existiert deshalb zusammen mit anderen lokalen Diensten:

- z.B. Network Information Service, NIS, speichert Benutzer-namen und Paßwörter.

7.4 Global Name Service

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 27

• GNS wurde bei Digital als ein langlebiger Namensdienst zur Ressourcenlokation, Mailadressierung

und Authentisierung entwickelt.

• GNS unterstützt Veränderungen in der Partitionierungsstruktur von Namensräumen.

• GNS benutzt Caching und Replikation.

• Die Namensdatenbasis besteht aus einem Baum von Verzeichnissen, den Directories.

• Jedes Directory besitzt einen Directory Identifier, DI.

• Die Namen bestehen aus Paaren .

• Die Wertenamen zeigen auf einen strukturierten Wertebaum.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 28


Uni-Ulm

Informatik

Bild 7.8 GNS Directorybaum [CDK94]

Vereinigung und Restrukturierung

Mailboxen

A

DE

B

EC

C

UK

Michael Weber

Passwort

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 29

• GNS unterstützt die Vereinigung von bereits existierenden Namensbäumen durch eine

gemeinsame neue Wurzel.

• Damit Klienten, die noch alte Pfadnamen verwenden, nicht geändert werden müssen, verfügt

GNS an der neuen Wurzel über eine Tabelle mit der alte Wurzelbezeichner (z.B. #599) auf

die neuen Pfadnamen abgebildet werden (z.B. #633/EC).

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 30


a) vorher

DI: 543

b) nacher

DI: 599

DE

EC

Well-known directories

#599=#633/EC

#642=#633/NorthAm

DI: 543

EC

DI: 599

DE

UK

UK

Bild 7.9 Vereinigung von Namensbäumen

DI: 574

DI: 633 World

DI: 574

US

DI: 732

US

DI: 732

NorthAm

NorthAm

DI: 642

CDN

CDN

DI: 457

DI: 642

DI: 457

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 31

• GNS unterstützt die Restrukturierung eines Namensbaums aufgrund organisatorischer Änderungen.

• Im Bild wurde das Directory US umgehängt.

• Um alte Pfadnamen weiterhin zuzulassen, wird an der vorhergehenden Position des verschobenen

Directories ein symbolischer Verweis eingefügt.

DI: 543

Well-known directories

#599=#633/EC

#642=#633/NorthAm

DI: 599

DE

Bild 7.10 Restrukturierung eines Namensbaums [CDK94]

EC

UK

DI:

DI: 574

US

World

DI: 732

NorthAm

#633/EC/US

DI:

CDN

DI: 457

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 32


7.5 X.500 Directory Service

• DNS und GNS sind Namensdienste, die vorwiegend für Rechnernamen und deren Adressen

eingesetzt werden.

• Notwendigkeit darüber hinausgehen, Rechnernamen gegen Adressen aufzulösen.

• Man möchte komplexe Suchanfragen stellen können.

• Man will mehr Information speichern,

- beispielsweise zu einer Person nicht nur die E-mail-Adresse, sondern deren berufliche Position,

die Hobbies und ein Bild.

• Solche Dienste nennt man Directory- oder Verzeichnisdienste.

• Directorydienste sind hochwertige, attributbasierte Namensdienste.

• X.500 ist ein solcher Dienst, der als CCITT Standard auf Ebene 7 des OSI-Referenzmodells

definiert ist [1988].

- d.h. er ist über OSI-Protokollen definiert

• X.500 ist Bestandteil von OSF-DCE

- wurde somit auch von der Industrie aufgegriffen.

• X.500 ist die Ausgangsbasis zu LDAP (lightweight directory access protocol)

X.500 Namen

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 33

• Ein X.500 Namensbaum heißt Directory Information Tree, DIT.

• Die gesamte Datenstruktur mit allen Attributinhalten nennt man Directory Information Base,

DIB.

• Alle Namen/Attribute sind einem Typ bzw. einer Objektklasse zugeordnet.

• Jeder DIB-Eintrag besteht aus einem Namen und einer Menge von Attributen.

• Absolute Namen beschreiben den Gesamtpfad von der Wurzel zu dem Objekt.

• Relative Namen sind möglich, der Klient setzt dazu einen entsprechenden Kontext.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 34


France (country)

Siemens (organization)

Dekanat (organizationalUnit) WWW Service (applicationProcess)

Michael Weber (person) Frank Kargl (person) Torsten Illmann (person)

Bild 7.11 Directory Information Tree

X500 Service (root)

Germany (country)

Universität Ulm (organization)

E-Technik (organizationalUnit) Mathematik (organizationalUnit)

Informatik (organizationalUnit)

Abt. VS (organizationalUnit)

Great Britain (country)

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 35

• Die Attribute eines DIB-Eintrags bestehen aus Typ und mehreren Werten.

• Jeder Typ wird durch einen Typnamen spezifiziert,

- zum Beispiel CountryName, OrganizationName, CommonName, TelephoneNumber,

Mailbox, ObjectClass, usw.

• Neue Attributtypen können durch einen Namen, plus eine Syntaxdefinition in ASN.1, definiert

werden.

• Alle Einträge werden jeweils einer Objektklasse zugeordnet,

- z.B. Organization, OrganizationalPerson, Document.

• Neue Klassen können definiert werden.

• Attribute können als zwingend oder optional spezifiziert werden.

• Die Definition der Klassen erfolgt im objektorientierten Sinn in einer Vererbungshierarchie.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 36


info

Bild 7.12 Directory Information Base Eintrag

Michael Weber, Abt. Verteilte Systeme, Universität

Ulm, Deutschland

commonName

Michael Weber

M. Weber

surname

Weber

telephoneNumber

+49 731 50 241 43

uid

weber

mail

weber@informatik.uni-ulm.de

roomNumber

O27 / 348

userClass

Professor

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 37

• Der Name des DIB-Eintrags wird aus den vorhanden Attributen gewählt

- wird als Distinguished Attribute bezeichnet.

• Eingebettet in die Hierarchie ist dies der Distinguished Name,

- bestimmt die Positionierung des Eintrags im Baum

- und dient als Navigationsanker für den gesamten Eintrag.

• Laut Standard sollte es eine einzige DIB auf der Welt geben, verteilt auf individuelle X.500-

Server, um so eine weltweite Suchanfrage stellen zu können.

• Jede mittlere und größere Organisation hat dazu einen Server.

• Die Klienten können jeden dieser Server kontaktieren.

• Bei X.500 heißen die Server Directory Service Agent, DSA, die Klienten Directory User

Agent, DUA.

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 38


Zugriffsmethoden

• Spezielle Benutzer dürfen Einträge einfügen, ändern und löschen.

• die Klienten nutzen die beiden Leseoperationen:

- Lesen

Eingabe ist ein absoluter oder relativer Name und eine Liste der zu lesenden Attribute. Der

DIT wird entsprechend navigiert und der DSA gibt die geforderten Werte zurück.

- Suchen

Eingabe ist ein Basisname und ein Filterausdruck.

Ab dem Basisnamen beginnt die Suche.

Eine Liste aller Namen, die den Filterausdruck erfüllen, wird zurückgeliefert.

Die Suche kann noch zusätzlich im Suchbereich, in der Länge der Ausgabeliste und in der

zeitlichen Dauer der Suche begrenzt werden.

Schlussbemerkungen

• der Standard schreibt die Implementierung nicht vor, auch nicht die Form der Navigation.

• Ein Nachteil von X.500 ist, daß die Definition der ObjectClasses auf nationaler und internationaler

Ebene geschehen muß, um den Gültigkeitsbereich weit zu fassen, damit auch eine

weite Suche ermöglicht wird.

7.6 LDAP

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 39

• X.500 DAP (directory access protocol) ist ein OSI-Anwendungsprotokoll

- d.h. DAP benötigt den kompletten OSI-Stack

- dies ist in vielen Fällen nicht möglich / installiert

• Entwicklung eines Lightweight Access Protocol LDAP

- über TCP/IP

- inzwischen Version 3 als Proposed Standard (RFCs 2252 - 2256)

- Version 2 ist Draft Standard (RFCs 1777 - 1779, 1959, 1960)

- Referenzimplementierung der University of Michigan

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 40


Architektur

LDAP

Klient

Bild 7.13 LDAP Server als X.500 Gateway

Bild 7.14 Standalone LDAP Server

Eigenschaften von LDAP

TCP/IP LDAP

Server

OSI

LDAP

Klient

TCP/IP

LDAP

Server

• vereinfachte und weniger Operationen als X.500

- Suchen,

- Hinzufügen,

- Löschen,

- Modifizieren,

- Bewegen (move),

- Vergleichen

X.500

Server

Directory

• Definitionen von Namen und Attributen als String statt in ASN.1

Authentisierung

Directory

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 41

• Klienten müssen sich binden

- anonyme Sessions - keine Authentisierung

- Basic Authentication mit eigenem DN und Klartext-Passwort

- SASL (simple authentication and security layer)

- wählbare Mechanismen (Kerberos V4, S/Key, GSSAPI, CRAM-MD5, External, SSL)

- und jeweils Credentials des Klienten

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 42


Autorisierung

• Access Control List

- derzeit herstellerspezifisch

- Internet Draft existiert bereits

in Version 3 zusätzlich:

• dynamische Directory-Services

• Language Codes

• Transport Layer Security

• Simple Paged Results

• Referrals und Knowledge References

• Server Side Sorting

• LDAP API

- für C

- Java NDI (Java naming and directory interface) beinhaltet LDAP API

Referenzen

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 43

• http://www.umich.edu/~dirsvcs/ldap/

• Heinz Johner, Larry Brown, Franz-Stefan Hinner, Wolfgang Reis, Johan Westman: Understanding

LDAP. IBM Redbook 1998. http://www.redbooks.ibm.com

Server zum Ausprobieren

• www.dante.net

• tricia.hrz.tu-chemnitz.de

• ldap.four11.com (www.four11.com)

• ldap.infospace.com (www.infospace.com)

• ldap.whowhere.com (www.whowhere.com)

• ldap.bigfoot.com (www.bigfoot.com)

• ldap.switchboard.com (www.switchboard.com)

Michael Weber, Verteilte Systeme, Sommersemester 2000, Kapitel 7, Seite 44

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!