Studiengang Informatik FHDW Vorlesung Betriebssysteme 2 Quartal 2005

Studiengang Informatik FHDW Vorlesung: Betriebssysteme 2. Quartal 2005 Vorlesung: 1 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Gliederung · Wiederholung Kommunikation in verteilten Systemen · Einstieg: Problemstellung Rechte Berechtigungen anhand einer · · · praktischen Implementation ISO/OSI-Referenzmodell Vergleich diverser Protokollstacks (TCP/IP. . . ) Einführung Netzwerkkomponenten und -technologien (globale) Verzeichnisdienste (NDS, AD, i. Planet) Synchronisation in verteilten Systemen Deadlocks in verteilten Systemen Prozesse und Prozessoren in verteilten Systemmodelle (das Workstation-Modell) Scheduling in verteilten Systemen Einführung in Netzwerkdienste Ausblick Vorlesung: 2 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensverwaltung Namen dienen in verteilten Systemen dazu, Ressourcen, zu benennen und zu identifizieren: Computer Dienste Ports Netzadressen Objekte Dateien Prozesse Benutzer Vorlesung: 4 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Themenstellungen Struktur von Namen Vergabe und Administration Zugriff auf Namen Abbildung von Namen auf repräsentierten Objekte Vorlesung: 5 Betriebssysteme III 2005 Prof. Dr. G. Hellberg die durch sie

Aufgaben und Eigenschaften von Namen Erklärung Der Name bezeichnet ein Objekt z. B. : "HP-LJ-4 N_Sekretariat" oder "Kapitel 7" Identifizierung Eine Systemidentifikation oder Ressourceidentifikation wird durch den Zugriff über dessen Namen verborgen z. B. : "www. fhdw. de" verbirgt die IP-Adresse dieses Rechners Lokalisierung Die Adresse eines Objektes wird durch den Zugriff über einen Namen verborgen Die E-mail-Adresse "Hellberg@fhdw. de" steht z. B. für die zugehörige Mailboxadresse Namen sollten sowohl für Endanwender, als auch für Administratoren und Programmierer sprechend sein (Zusammenhang Verwendung Name). Vorlesung: 6 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Verwendungskontexte von Namen, die im Kontext eines Dienstes benutzt werden Bsp. : ein Dateiname im Dateisystem oder Prozeßidentifikator im Prozeßmanagement die Dienste sind in der Lage, die Namen selbst zu verarbeiten Dienstübergreifende Namen Bsp. : Benutzername, eine e. Mail-Adresse oder ein Dienst selbst, wie das Dateisystem oder Druckdienst Ein Name ist meist einem Objekt zugeordnet (gebunden) Vorlesung: 7 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Verwendungskontexte von Namen (2) 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, BS-Version 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. Vorlesung: 8 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Abhängigkeit der Namen von der physischen Konfiguration: 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 " www. fhdwhannover. de" ein unreiner Name ist, da er Ortsinformation beinhaltet. Vorlesung: 9 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

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. Vorlesung: 10 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensraum (2) Häufig setzen sich Namen aus Komponenten zusammen, wie zum Beispiel "www. fhdw. de" oder "/home/hellberg" 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. Vorlesung: 11 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensraum (3) 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. Vorlesung: 12 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Partitionierung von Namensräumen physisch partitioniert: Namen tragen die physische Ortsinformation in sich zum Beispiel "Kapitel 7. Platte. A. 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 "teilnehmer. informatik. fhdw. de" bezeichnet die aufsteigende Organisationsstruktur, die sich hinter dem benannten Objekt befindet dezentrale Namensverwaltung jeweils unterhalb des eigenen Präfixes bzw. Suffixes möglich Vorlesung: 13 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensdomäne Eine 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 Vorlesung: 14 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensdienst Ein Namensdienst ist eine Datenbasis, welche die Zuordnung von Namen zu Objekten und damit zu deren Attributen und Werten speichert. Hauptaufgabe: Namensanfragen in die auflösen (engl. : resolve). entsprechenden Attribute 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. Vorlesung: 15 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensverwaltung Die Namensverwaltung ist meist ein eigener Dienst 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. Vorlesung: 16 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensverwaltung (2) 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. Vorlesung: 17 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Anforderungen an Namensdienste Lange Lebensdauer Der Namensdienst wird über eine lange Zeit benötigt. Es werden viele Änderungen der Einträge stattfinden. Hohe Verfügbarkeit Abhängigkeit anderer Dienste und Programme. 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. Vorlesung: 18 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Daten und Operationen Die Daten eines Namensdienstes liegen als Paare <Name, Attribut> vor. Attribute werden als <Typ, Wert> zu Namen gespeichert Vorlesung: 19 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Standardoperationen des Namensdienstes 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. Vorlesung: 20 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Standardoperationen (2) Die Operationen nutzen jeweils die Namen als Suchschlüssel. Bei attributbasierten Namensdiensten können auch Attributwerte als Schlüssel verwendet werden. Suchanfragen liefern i. a. eine Menge von Namen / Attributpaaren zurück: Bsp. : finde alle PCs der Fakultät mit OS=Windows NT, finde alle Druckerspooler eines Druckers mit Druckername=HP-LJ-4 N Die attributbasierten Namensdienste nennt man auch Yellow Page Services. Konventionelle Namensdienste nennt man auch White Page Services. Vorlesung: 21 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensauflösung und Navigation 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. ABBILDUNG EINFÜGEN!!! Vorlesung: 22 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensauflösung und Navigation (2) 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. Vorlesung: 23 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Namensauflösung und Navigation (3) 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. Vorlesung: 24 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

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 Adressen der Server beinhalten, die weiterführende Informationen zum angefragten Namen haben. Vorlesung: 25 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Navigationsvarianten (2) Multicast-Navigation Der Useragent schickt die Anfrage per Multicast an alle Namensserver. Bei ungebundenen Namen antwortet keiner, ansonsten derjenige, der den Namen kennt. Vorlesung: 26 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Navigationsvarianten (3 a) Iterative serverkontrollierte Navigation Der Useragent stellt seine Anfrage an einen Namensserver, der dann iterativ die weitere Navigation durchführt. Der zuerst beauftragte Namensserver übernimmt die Rolle eines iterativ navigierenden Useragenten. Vorlesung: 27 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Navigationsvarianten (3 b) Iterative serverkontrollierte Navigation am Beispiel von DNS Vorlesung: 28 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Navigationsvarianten (4) 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. Vorlesung: 29 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Navigationsvarianten 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. Vorlesung: 30 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Caching Um Zugriffe auf oder unter Namensservern zu reduzieren, wird Caching eingesetzt. Bei jeder Namensauflösung werden Paare aus <Name, Attribut> oder <Kontext, Servername> im Useragenten bzw. Server gespeichert. Verbessert die Leistungsfähigkeit des Namensdienstes und erhöht die Verfügbarkeit bei Ausfällen. Die Cacheverfahren nutzen, daß sich Namensinformationen nur selten ändern. Vorlesung: 31 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Caching (2) Es wird beim Caching keine strikte Konsistenz gefordert. Eine fehlerhafte Namensauflösung läßt den angeforderten Dienst des Klienten im schlechtesten Fall mit einer Fehlermeldung zurückkehren, es wird eine zweite Namensauflösung 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. Vorlesung: 32 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Replikation ist eine weitere Möglichkeit, die Verfügbarkeit des Dienstes zu verbessern. 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. Vorlesung: 33 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

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 muss eine skalierbare Lösung verwendet werden: Internet Domain Name System, DNS Vorlesung: 34 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Internet Domain Name System (2) DNS ist konzeptuell für viele Namensräume entworfen worden, Verwendung findet es 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. Vorlesung: 35 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Internet Domain Name System (3) Folgende Endsuffixe (Top Level Domain, TLD) sind vergeben: generic TLDs com edu gov mil net int org Kommerzielle Organisationen Bildungseinrichtungen Verwaltungs- oder Regierungseinrichtungen Militärische Organisationen Netzwerkunterstützungszentren Internationale Organisationen andere Organisationen. neue generic TLDs arts firm info rec shop Unternehmen im Bereich Kultur/Unterhaltung Unternehmen und Firmen Unternehmen im Informationsdienstleistungssektor Unternehmen im Bereich Erholung/Freizeit Verkaufseinrichtungen Vorlesung: 36 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Internet Domain Name System (4) (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. Bsp. : Lets. Buy. It. de , Hauptsitz Schweden (TLD: se) Vorlesung: 37 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Internet Domain Name System (5) 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 dass immer der komplette Name zur Auflösung notwendig ist. Oft gleicht die Klientensoftware, d. h. der Useragent, dies aus, indem sie an einfache Namen die Default Domain anhängt. Vorlesung: 38 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Internet Domain Name System (6) DNS-Einstellungen des Betriebssystems MS Windows 2000 drhellberg. de Vorlesung: 39 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Internet Domain Name System (7) DNS unterstützt für Klienten zwei Standardanfragen: 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 (oft nur ein Eintrag) kann die Software dann die Mail abschicken. Vorlesung: 40 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Internet Domain Name System (8) 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. Vorlesung: 41 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

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ßgebenden Daten der Zone halten. Namen der Namensserver von Subzonen. Managementparameter, u. a. für Caching & Replikation. Vorlesung: 42 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

DNS Namensserver (2) Alle Zonendaten werden in Dateien, sogenannten Resource Records (RR) 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). Vorlesung: 43 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

DNS Namensserver (3) Jede Zone muß mindestens einmal repliziert werden. Die Primärserver (auch: Zonenmaster) lesen die Zonendaten direkt aus einer Masterdatei, die der Systemverwalter manuell pflegt. Die Sekundärserver replizieren die Information periodisch von ihrem Primärserver. Die Frequenz der Aktualisierung wird vom Systemverwalter eingestellt und liegt typischerweise bei 12 -24 Stunden Vorlesung: 44 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Funktionsprinzip Caching Die Namensserver dürfen Daten cachen. Jeder Eintrag hat ein Verfallsdatum (engl. : time-to-live) und nur für diese Zeit stellen Namensserver Klienten Daten aus dem Cache zur Verfügung. Die Namensserver halten dabei Einträge über bis zu zwei Namenskomponenten bzw. Domänen hinweg. Dadurch ist es möglich, meist mit zwei Zugriffen auf Namensservern auszukommen, um einen Namen aufzulösen. Grund: die DNS Hierarchie ist selten tiefer als vier Stufen. Vorlesung: 45 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Useragenten und das DNS-Protokoll Die Useragenten des DNS heißen Resolver. Sie sind im allgemeinen als Bibliothekssoftware implementiert, die über UDP/IP das DNS-Protokoll nutzen. Die Wahl, ob DNS iterative und rekursive Navigation verwendet, liegt beim Resolver. Ebenfalls möglich: mehrere Anforderungen des Resolvers pro DNS-Anfrage um so mit einer Nachricht gleich mehrere Namen auflösen zu lassen. Vorlesung: 46 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

BIND Eine in der Linux/Unix-Welt oft eingesetzte Implementierung des DNS-Namensservers ist Berkeley Internet Name Domain (BIND). Die BIND-Namensserver laufen als named Dämonen Die Useragenten sind durch Bibliothekssoftware implementiert. Vorlesung: 47 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Zusammenfassung DNS ist ein recht primitiver Namensdienst im Internet. DNS existiert deshalb zusammen mit anderen lokalen Diensten, z. B. : Network Information Service, NIS, speichert Benutzernamen und Paßwörter. Vorlesung: 48 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Global Name Service Der Global Name Service (GNS) wurde bei Digital Equipment Corporation (DEC) 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 <Directoryname, Wertename>, Die Wertenamen zeigen auf einen strukturierten Wertebaum. Vorlesung: 49 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Beispiel eines GNS-Directoybaumes Vorlesung: 50 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Vereinigung 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). siehe Beispiel nächste Folie Vorlesung: 51 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Beispiel Vereinigung von GNS-Directories Vorlesung: 52 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Restrukturierung GNS unterstützt die Restrukturierung eines Namensbaums aufgrund organisatorischer Änderungen. Im nachfolgenden 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. Vorlesung: 53 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Beispiel Restrukturierung v. GNS-Directories Vorlesung: 54 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

X. 500 Directory Service DNS und GNS sind Namensdienste, die vorwiegend für Rechnernamen und deren Adressen eingesetzt werden. Darüber hinausgehende Forderungen: Rechnernamen zu Adressen auflösen, komplexe Suchanfragen stellen, Speicherung zusätzlicher Information. Solche Dienste nennt man Directory- oder Verzeichnisdienste. Directorydienste sind hochwertige, attributbasierte Namensdienste. Vorlesung: 55 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

X. 500 Directory Service (2) X. 500 ist ein solcher Dienst, der als CCITT Standard auf Ebene 7 des OSI-Referenzmodells definiert ist. X. 500 ist Bestandteil von OSF-DCE (Open Software Foundation, Distributed Computing Environment) und wurde daher von der Industrie aufgegriffen und unterstützt. X. 500 ist die Ausgangsbasis zu LDAP (lightweight directory access protocol) Vorlesung: 56 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

X. 500 Namen 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. Vorlesung: 57 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

X. 500 Directory Information Tree Vorlesung: 58 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Directory Information Base Die Attribute eines DIB-Eintrags bestehen aus Typ und mehreren Werten. Jeder Typ wird durch einen Typnamen spezifiziert, z. B. Country. Name, Organization. Name, Common. Name, Telephone. Number, Mailbox, Object. Class, 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, Organizational. Person, Document. Neue Klassen können definiert werden. Attribute können als "obligatorisch" oder "optional" spezifiziert werden. Die Definition der Klassen erfolgt im objektorientierten Sinn in einer Vererbungshierarchie. Vorlesung: 59 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Directory Information Base (2) 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". Er bestimmt die Positionierung des Eintrags im Baum und dient als Navigationsanker für den gesamten Eintrag. Vorlesung: 60 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Directory Information Base (3) Laut Standard soll 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 heißen "Directory User Agent" (DUA). Vorlesung: 61 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

X. 500 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. Vorlesung: 62 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

X. 500 Probleme Der X. 500 Standard schreibt die Implementierung nicht vor, auch nicht die Form der Navigation. Ein Nachteil von X. 500 ist, dass die Definition der Object. Classes auf nationaler und internationaler Ebene geschehen muß, um den Gültigkeitsbereich weit zu fassen, damit auch eine weite Suche ermöglicht wird. Vorlesung: 63 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

LDAP Das zugrunde liegende X. 500 DAP (Directory Access Protocol) ist ein OSI-Anwendungsprotokoll. DAP benötigt den kompletten OSI Protokollstack, dieser ist in vielen Fällen nicht verfügbar / nicht installiert. Es erfolgte die Entwicklung eines Lightweight Directory Access Protocol (LDAP): LDAP nutzt den TCP/IP Protokollstack, es existiert inzwischen in der Version 3 als Proposed Standard (RFCs 2252 - 2256). Vorlesung: 64 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

LDAP Architekturbeispiele 1. ) Standalone LDAP Server 2. ) LDAP Server als X. 500 -Gateway Vorlesung: 65 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

Eigenschaften von LDAP Vereinfachte und weniger Operationen als X. 500: suchen, hinzufügen, löschen, modifizieren, verschieben, vergleichen Definitionen von Namen und Attributen als String statt in ASN. 1 Vorlesung: 66 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

LDAP Authentisierung & Autorisierung 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 V 4, S/Key, GSSAPI, CRAMMD 5, External, SSL) und jeweils Credentials des Klienten. Access Control List (ACL) derzeit herstellerspezifisch Internet Draft existiert bereits Vorlesung: 67 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

LDAP V 3 Zusätzlich in LDAP Version 3 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 Vorlesung: 68 Betriebssysteme III 2005 Prof. Dr. G. Hellberg

ENDE Fragen? Vorlesung: 69 Betriebssysteme III 2005 Prof. Dr. G. Hellberg