1 vs Verteilte Verzeichnisse können ein verteiltes Betriebssystem unterstützen dienen der Abbildung von „Namen“ auf „Daten“ aller Art sollten ihre Information persistent halten (Dateien, Datenbank) müssen hochzuverlässig sein  typisch: Verwendung mehrfach replizierter Dateien Beispiele - im lokalen Netz:Sun NIS(BS-unterstützend) - im Internet:DNS(BS-unabhängig)

2 vs11.3 Der Verzeichnisdienst unterstützt mehrere Abbildungen:(lokal) passwd.byname:user name  uid /etc/passwd hosts.byname:host name  IP address /etc/hosts mail.aliases:mail alias  mail addresses /etc/aliases services.byname:service name  port #, protocol /etc/services rpc.bynumber:rpc serv. name  rpc program # /etc/rpc..... und andere - siehe man ypfiles Sun NIS Network Information System, ehemals Yellow Pages (basiert auf SunRPC über UDP)

3 vs11.3 Benutzung, z.B. für Namensauflösung, mit Befehl ypmatch key map (mit key = Benutzername) Dahinter verbirgt sich der Aufruf einer Bibiliotheksroutine (siehe man ypclnt ) yp_match(...) (diese benutzt Fernaufrufe... siehe unten) Weitere Befehle: ypmatch –x Anzeige praktischer Kurzformen (nicknames) für einige ausgewählte Abbildungen ypcat map Auflistung aller Einträge der Abbildung

4 vs11.3 Funktionsweise: Replizierte Anbieter (Programm ypserv ), per Fernaufruf ansprechbar:  Klienten wie ypmatch fragen lokalen Repräsentanten des NIS (Programm ypbind ) per RPC nach einem geeigneten Replikat;  ypbind schickt Broadcast RPC an die ypserv-Replikate, merkt sich das erste, das antwortet, für spätere Anfragen  und teilt es dem Klienten mit; dieser wendet sich daraufhin direkt an das Replikat.  Es gibt eine Primärkopie und i.a. mehrere Sekundärkopien.

5 vs11.3 ypse rv..... master (Primärkopie) slaves (Sekundärkopien) Klientenstationen.. Klientenprozesse    ypwhich host liefert den Namen der Station, auf der sich der für host aktuell verwendete ypserv -Server befindet ypwhich –m map liefert den Namen der Station, auf der sich der für die Abbildung map zuständige Master befindet (ohne map : Liste der Masters für alle Abbildungen) ypcat ypservers liefert Liste aller Servers ypbi nd

6 vs11.3 Daten bei Master und Slaves: /etc/... Rohdaten, vom Systemverwalter manipuliert /var/yp/... daraus abgeleitete Maps, von den Servers benutzt Änderung der Abbildungen: 1. Systemverwalter modifiziert Rohdaten und erstellt neue Map(s) mittels make. 2. Das vorgesehene Makefile sorgt dafür, daß die Slaves von der Änderung informiert werden (Befehl yppush, führt RPCs aus). 3. Slaves wenden sich an die Master-Station: Befehl ypxfr wendet sich per RPC an ypxfrd, beschafft alle Einträge (!) aktualisierter Maps und generiert daraus eigene neuen Maps. (4. ypxfr auch in regelmäßigen Zeitabständen!)

7 vs11.3 Ausnahme: Passwort-Änderung ohne Beteiligung des Systemverwalters Befehl yppasswd kontaktiert yppasswdd -Prozess auf Master-Station; dieser Prozess übernimmt Rolle des Verwalters. ypse rv ypbi nd cli e nt yppa sswd d Master Slave Client yppush ypxf rd yppasswd

8 vs11.3 Charakterisierung des NIS: „quasi-aktive“ Replikation mit Primärkopie, erlaubt Heterogenität; Konsistenz sehr schwach aber für die Zwecke des NIS ausreichend: Änderungen selten, temporäre Inkonsistenz unproblematisch.

9 vs DNS Domain Name System Auflösung von menschenlesbaren Rechner-Namen zu Adressen -> Ursprünglich zentrale Registrierung per beim Stanford Research Institute (SRI) in Datei HOSTS.TXT Beschaffung wöchentlich mittels FTP, Basis für /etc/hosts Seit 1983 DNS (Mockapetris et al.) Dezentrale Verwaltung durch Netz von domain name servers für bestimmte Bereiche der Domänen-Hierarchie - mit Caching für Lastreduzierung - und Replikation für Ausfallsicherheit

10 vs11.3 "" A.ROOT-SERVERS.NET "de" f.nic.de "uk" ns1.nic.uk "org" tld1.ultradns.net "fu-berlin.de" ns1.fu-berlin.de "tu-berlin.de" names.zrz.tu-berlin.de "inf.fu-berlin.de" sahib.inf.fu-berlin.de (= ns1.inf.fu-berlin.de) "physik.fu-berlin.de" nukleon.physik.fu-berlin.de tim.inf.fu-berlin.de (= vader.inf.fu-berlin.de Normalerweise gibt es mehrere DNS-Server pro Domäne (evtl. rotierend)

11 vs11.3 DNS-Abfragen auf mehrere Arten möglich: resolv er NS1 NS3 NS2 resolv er NS1 NS3 NS2 resolv er NS1 NS3 NS iterativrekursivgemischt Rekursive Weiterleitung durch DNS-Server ist optional. Caching der Antworten reduziert Kommunikationsvolumen.

12 vs11.3 Programme wenden sich nicht direkt an DNS-Server, sondern verwenden lokalen resolver (Bibliothek, Prozess) Typische Konfiguration eines UNIX-resolvers: Datei /etc/resolv.conf search mi.fu-berlin.de inf.fu-berlin.de math.fu-berlin.de nameserver (pyramid.mi.fu-berlin.de) nameserver (sahib.inf.fu-berlin.de) nameserver (ns1.fu-berlin.de) Einfache Rechner-Namen ohne Domänen-Teil werden der Reihe nach um die bei search angegebenen Domänen erweitert. Sofern der erste bei nameserver angegebene DNS-Server nicht antwortet, werden die nachfolgenden der Reihe nach kontaktiert.

13 vs11.3 Die Datenbank eine DNS-Servers besteht aus mehreren Zonen-Dateien, normalerweise zwei pro Domäne: - Abbildung von Namen auf Adressen - Abbildung von Adressen auf Namen (optional) Zonen-Dateien werden vom Master-Server auf Slave-Server repliziert. Eine Zone enthält mehrere resource records (RR) der Form [ ] [ ] name ist ein Rechner-Name oder die spezielle kodierte Adresse davon TTL steuert die Verweildauer im Cache eines DNS-Servers/Resolvers class gibt die behandelte Protokollfamilie an ( IN = Internet) type bestimmt den Typ des Eintrags und gültige Werte für rdata rdata beschreibt Eigenschaften von name, z.B. zugehörige Adresse

14 vs11.3 Pro Zone steuert ein SOA (start of authority ) RR die Replikation auf Slave-Servers: inf.fu-berlin.de. IN SOA sahib.inf.fu-berlin.de. \ hostmaster.inf.fu-berlin.de. ( 667 ; serial number ; refresh time, 3 hours 1 sec 3600 ; retry time, 1 hour ; expiry time, 14 days ; default TTL for RR caching, 1 day ) Replikat muss aktualisert werden, falls höhere serial -Nummer; Slave-Server kontaktiert den Master alle refresh Sekunden zur Prüfung; wenn Master nicht erreichbar, neuer Versuch alle retry Sekunden; Zone ungültig falls nach expiry Sekunden keine Antwort. Ausserdem: Alle RR-Einträge der Zone dürfen maximal TTL Sekunden in DNS Caches verbleiben, sofern nicht individuell angegeben.

15 vs11.3 Weitere Einträge geben gültige DNS-Server für die Zone an: inf.fu-berlin.de. IN NS sahib.inf.fu-berlin.de. sahib.inf.fu-berlin.de.IN A sowie Delegation an Server für untergeordnete Domänen: spline.inf.fu-berlin.de. IN NS bla.spline.inf.fu-berlin.de. bla.spline.inf.fu-berlin.de. IN A Dabei muss auch die Adresse des zuständigen Servers als glue record angegeben werden, um Anfragen korrekt weiterzuleiten. Normale A RR bilden dann Namen auf Adressen ab. Mit einem CNAME RR kann man alternative Namen (alias) vergeben. tim.inf.fu-berlin.de. IN A CNAME tim.inf.fu-berlin.de.

16 vs11.3 Viele weitere RR-Typen: MX mail exchanger = zuständiger -Server HINFO host info = Maschinentyp und Betriebssystem TXT Freitext! AAAA IPv6-Adresse PTR Verweis für Umleitung/Rückwärtsauflösung... Zu jeder Zone sollte es auch eine reverse-Zone gegeben für korrespondierende Rückwärtsauflösung von Adresse zu Name. Realisiert mit spezieller Pseudo-Domäne in-addr.arpa : in-addr.arpa IN NS sahib.inf.fu-berlin.de in-addr.arpa IN PTR tim.inf.fu-berlin.de. umgekehrte IP-Adresse als "Domäne"

17 vs11.3 IDNA - International Domain Names in Applications Problem: Für Domänen-Namen ist nur eine sehr kleine Untermenge von ASCII-Zeichen erlaubt: A-Z, 0-9 und - Darstellung von anderen Zeichen (Umlaute, Akzente,...) oder anderen Schrift-Systemen (Griechisch, Japanisch,...) nicht möglich. Abhilfe: Anwendungen kodieren Namen zunächst in kompatible Form "Punycode" (analog zu UNICODE als UTF-8-Kodierung), z.B. bücher.de->xn--bcher-kva.de xn-- reservierter IDNA-Prefix als Markierung bcher Zeichen des Original-Namens ohne Sonderzeichen - Trennzeichen kva Kombination aus Sonderzeichen (UNICODE) und Position

18 vs11.3 Bonjour / Rendezvous DNS as discovery service Idee: DNS-System zum Auffinden von Geräten und Diensten verwenden Dazu Verwendung von PTR, SRV (service) und TXT RRs: _printer._tcp.local. IN PTR LaserWriter 8500._printer._tcp.local. LaserWriter 8500._printer._tcp.local. IN SRV myhost.local. IN TXT #pdl=application/postscript#color=T LaserWriter 8500 Name des antwortenden Dienstes _printer Protokoll für Dienst (hier: LPR) _tcp zugrundeliegendes Transport-Protokoll.local. spezielle mDNS-Domäne für lokales Netz (opt) 0 0 Priorität/Gewicht des Dienstes, steuert Auswahl 515 myhost.local. Port und Name des anbietenden Rechners Auflisten durch PTR-Anfrage an DNS-Server, oder Multicast für.local SRV-Anfrage liefert Host/Port, TXT-Anfrage liefert Dienst-Details