Vor dem Installieren der Identitätsdepot-Infrastruktur muss der Server eine Methode (ein Dienst oder eine bestimmte Datei) aufweisen, mit der die Baumnamen im Identitätsdepot in Serververweisadressen aufgelöst werden können. NetIQ empfiehlt die Auflösung der Baumnamen mit SLP-Diensten (Service Location Protocol). Bei älteren Versionen von eDirectory wurde OpenSLP während der Installation mitinstalliert. Ab eDirectory 8.8 ist OpenSLP jedoch nicht mehr in der Installation enthalten. Sie müssen einen SLP-Dienst separat installieren oder eine hosts.nds-Datei verwenden. Wenn Sie einen SLP-Dienst nutzen, müssen die Verzeichnisagenten für den Dienst (SLPDAs) stabil sein.
Dieser Abschnitt enthält die folgenden Informationen:
Die Datei hosts.nds enthält eine statische Suchtabelle, in denen die Identitätsdepot-Anwendungen die Identitätsdepot-Partitionen und -Server suchen. Hiermit können Sie SLP-Multicast-Verzögerungen vermeiden, wenn kein SLP-DA im Netzwerk vorhanden ist. Geben Sie die folgenden Informationen für jeden Baum oder Server jeweils in einer eigenen Zeile in der Datei hosts.nds ein:
Servername oder Baumname: Die Baumnamen müssen mit einem Punkt (.) enden.
Internetadresse: Dies kann ein DNS-Name oder eine IP-Adresse sein. Verwenden Sie nicht localhost.
Serverport: Optional; hängen Sie die Portnummer bei Bedarf mit einem Doppelpunkt (:) an die Internetadresse an.
Für den lokalen Server müssen Sie nur dann einen Eintrag in die Datei vornehmen, wenn der Server einen nicht standardmäßigen NCP-Port überwacht.
Erstellen Sie eine neue hosts.nds-Datei, oder öffnen Sie eine bereits vorhandene Datei.
Fügen Sie die folgenden Informationen hinzu:
partition_name.tree_name. host_name/ip-addr:port
server_name dns-addr/ip-addr:port
Beispiel:
# This is an example of a hosts.nds file: # Tree name Internet address/DNS Resolvable Name CORPORATE. myserver.mycompany.com novell.CORPORATE. 1.2.3.4:524 # Server name Internet address CORPSERVER myserver.mycompany.com:524
(Optional) Wenn Sie sich später entscheiden, den Baumnamen mit SLP aufzulösen und die Verfügbarkeit des Identitätsdepots im Netzwerk sicherzustellen, ergänzen Sie die Datei hosts.nds mit dem folgenden Text:
/usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==[treename or *])"
Soll beispielsweise nach Diensten gesucht werden, deren Attribut svcname-ws mit dem Wert SAMPLE_TREE übereinstimmt, geben Sie den folgenden Befehl ein:
/usr/bin/slptool findattrs services:ndap.novell///(svcname-ws==SAMPLE_TREE)"
HINWEIS:Führen Sie diesen Vorgang aus, sobald SLP und das Identitätsdepot installiert wurden.
Wenn ein Dienst mit dem Wert SAMPLE_TREE für das Attribut svcname-ws registriert ist, erhalten Sie die Ausgabe service:ndap.novell:///SAMPLE_TREE (Beispiel). Ansonsten erfolgt keine Ausgabe.
OpenSLP ist eine Open-Source-Implementierung des Standards IETF Service Location Protocol Version 2.0 (dokumentiert in IETF Request-For-Comments (RFC) 2608).
Die Schnittstelle des OpenSLP-Quellcodes ist eine Implementierung eines weiteren IETF-Standards für den programmtechnischen Zugriff auf die SLP-Funktionen (dokumentiert in RFC 2614).
In diesen Dokumenten wird die Funktionsweise von SLP umfassend erläutert. Lesen Sie daher die Dokumente, und machen Sie sich mit den Funktionen vertraut. Die Dokumente sind relativ komplex, sind jedoch für die richtige Konfiguration von SLP in einem Intranet unerlässlich.
Weitere Informationen zum OpenSLP-Projekt finden Sie auf den Websites von OpenSLP und SourceForge. Auf der OpenSLP-Website finden Sie mehrere Dokumente mit nützlichen Tipps für die Konfiguration. Zum Zeitpunkt der Veröffentlichung dieses Dokuments ist der Großteil der Dokumente auf der Website noch unvollständig.
Dieser Abschnitt umfasst die folgenden Diskussionen über die Verwendung von SLP und das Verhältnis zum Identitätsdepot:
Die NetIQ-Version von SLP nimmt es nicht so genau mit dem SLP-Standard, damit eine robustere Umgebung für die Dienstbekanntgabe erstellt werden kann; dies geht allerdings zu Lasten der Skalierbarkeit.
Soll die Skalierbarkeit für ein Dienstbekanntgabe-Netzwerk erhöht werden, können Sie beispielsweise die Anzahl der Pakete begrenzen, die über ein Teilnetz per Rundsendung oder Multicast verteilt werden. In der SLP-Spezifikation werden hierzu die Verzeichnisagentenabfragen durch die Service- und Benutzeragenten eingeschränkt. Hierbei wird der zuerst ermittelte Verzeichnisagent, der für den gewünschten Bereich zuständig ist, für alle nachfolgenden Abfragen eines Service-Agenten (und damit auch der lokalen Benutzeragenten) zu diesem Bereich herangezogen.
Die NetIQ SLP-Implementierung durchsucht alle bekannten Verzeichnisagenten nach Abfrageinformationen. Eine Laufzeit von 300 Millisekunden gilt dabei als zu lang; somit können 10 Server in etwa 3 bis 5 Sekunden durchsucht werden. Dies ist nicht erforderlich, wenn SLP ordnungsgemäß im Netzwerk konfiguriert ist. (OpenSLP geht davon aus, dass das Netzwerk ordnungsgemäß für den SLP-Verkehr konfiguriert ist.) Die Zeitüberschreitungswerte für Antworten sind bei OpenSLP höher als beim SLP-Dienstanbieter von NetIQ, und die Anzahl der Verzeichnisagenten ist auf den zuerst antwortenden Agenten beschränkt, unabhängig davon, ob die Angaben dieses Agenten richtig und vollständig sind oder nicht.
Benutzeragenten (UA) treten physisch als statische oder dynamische Bibliothek auf, die mit einer Anwendung verknüpft ist. Die Anwendung kann dabei die SLP-Dienste abfragen. Der Benutzeragent bildet eine programmtechnische Schnittstelle, über die die Clients die Dienste abfragen und die Dienste sich selbst bekanntgeben. Ein Benutzeragent stellt eine Verbindung zu einem Verzeichnisagenten her und fragt registrierte Dienste einer bestimmten Dienstklasse in einem bestimmten Bereich ab.
Die Benutzeragenten ermitteln die Adresse des Verzeichnisagenten, an den die Abfragen gesendet werden sollen, mithilfe eines bestimmten Algorithmus. Sobald sie die Adresse eines Verzeichnisagenten (DA) für einen bestimmten Bereich erhalten, nutzen sie diese Adresse so lange für den entsprechenden Bereich, bis der Verzeichnisagent nicht mehr antwortet; anschließend ermitteln sie eine andere DA-Adresse für den Bereich. Die Benutzeragenten suchen wie folgt die Adresse eines Verzeichnisagenten für einen bestimmten Bereich:
Der Agent prüft, ob die Socket-Zugriffsnummer der aktuellen Anforderung mit einem DA für den angegebenen Bereich verbunden ist. Bei einer mehrteiligen Anforderung ist ggf. bereits eine Cache-Verbindung in der Anforderung vorhanden.
Der Agent prüft, ob sich im lokalen Cache der bekannten DAs ein DA befindet, der mit dem angegebenen Bereich übereinstimmt.
Der Agent sucht beim lokalen Service-Agenten (SA) nach einem DA mit dem angegebenen Bereich (und fügt neue Adressen zum Cache hinzu).
Der Agent fragt DHCP nach im Netzwerk konfigurierten DA-Adressen ab, die mit dem angegebenen Bereich übereinstimmen (und fügt neue Adressen zum Cache hinzu).
Der Agent sendet eine DA-Ermittlungsanforderung per Multicast über einen bereits bekannten Port (und fügt neue Adressen zum Cache hinzu).
Soweit nicht anders angegeben, gilt der Bereich „Standard“. Wenn also weder statisch in der SLP-Konfigurationsdatei noch in der Abfrage ein Bereich definiert ist, wird der Wert „Standard“ für den Bereich verwendet. Beachten Sie außerdem, dass das Identitätsdepot unter keinen Umständen einen Bereich in den Registrierungen angibt. Ist ein statisch konfigurierter Bereich vorhanden, so wird dieser Bereich als Standardbereich für alle lokalen UA-Anforderungen und SA-Registrierungen übernommen, wenn anderweitig kein Bereich angegeben ist.
Service-Agenten treten physisch als separater Prozess auf dem Hostcomputer auf. Unter Windows wird slpd.exe als Dienst auf dem lokalen Computer ausgeführt. Die Benutzeragenten senden Nachrichten an die Loopback-Adresse eines bekannten Ports und fragen so den lokalen Service-Agenten ab.
Der Service-Agent stellt permanenten Speicher und Wartungspunkte für lokale Dienste bereit, die sich bei SLP registriert haben. Der Service-Agent pflegt im Wesentlichen eine speicherinterne Datenbank der registrierten lokalen Dienste. Ein Dienst kann sich dabei nur dann bei SLP registrieren, wenn ein lokaler SA vorhanden ist. Die Clients können Dienste durchaus nur mit einer UA-Bibliothek ermitteln. Für die Registrierung ist jedoch ein SA erforderlich, hauptsächlich weil der SA regelmäßig prüfen muss, ob die registrierten Dienste vorhanden sind, damit die Registrierung bei überwachenden Agenten aufrechterhalten werden kann.
Um die Verzeichnisagenten und ihre jeweils unterstützte Bereichsliste zu suchen und im Cache zu speichern, sendet ein Service-Agent wie folgt eine DA-Ermittlungsanforderung direkt an potenzielle DA-Adressen:
Der Agent prüft alle statisch konfigurierten DA-Adressen (und fügt neue DAs zum Cache des SA mit den bekannten DAs hinzu).
Der Agent fordert eine Liste der DAs und ihrer Bereiche von DHCP an (und fügt neue DAs zum Cache des SA mit den bekannten DA hinzu).
Der Agent sendet eine DA-Ermittlungsanforderung per Multicast über einen bereits bekannten Port (und fügt neue DAs zum Cache des SA mit den bekannten DA hinzu).
Der Agent empfängt DA-Bekanntgabepakete, die die DAs in regelmäßigen Abständen per Rundsendung übermitteln (und fügt neue DAs zum Cache des SA mit den bekannten DA hinzu).
Dies ist wichtig, weil ein Benutzeragent stets zuerst den lokalen Service-Agenten abfragt: Die Antwort des lokalen Service-Agenten bestimmt, ob der Benutzeragent zur nächsten Ermittlungsphase übergeht oder nicht (in diesem Fall DHCP; siehe Schritt 3 und Schritt 4 in Benutzeragenten).
Der Verzeichnisagent stellt einen langfristig permanenten Cache für bekannt gegebene Dienste bereit und fungiert als Zugriffspunkt für die Suche nach Diensten durch die Benutzeragenten. Der DA überwacht die SAs, ob neue Dienste bekannt gegeben werden, und speichert diese Benachrichtigungen im Cache. In kurzer Zeit wird der Cache eines DA voller oder vollständiger. Mithilfe eines Ablaufalgorithmus werden die Einträge im Cache der Verzeichnisagenten außer Kraft gesetzt. Beim Starten liest der Verzeichnisagent den Cache aus dem permanenten Speicher aus (in der Regel eine Festplatte), und anschließend werden die Einträge gemäß dem Algorithmus außer Kraft gesetzt. Wenn ein neuer DA gestartet wird oder der Cache gelöscht wurde, erkennt der DA diesen Zustand, und er sendet eine besondere Benachrichtigung an alle empfangenden SAs, ihre lokalen Datenbanken zu übermitteln, sodass der DA den Cache rasch aufbauen kann.
Falls keine Verzeichnisagenten vorhanden sind, sendet der UA eine allgemeine Multicast-Abfrage, auf die die SAs antworten können. So entsteht eine Liste der angeforderten Dienste, ähnlich wie beim Aufbauen des Cache durch die DAs. Die durch diese Abfrage zurückgegebene Diensteliste ist unvollständig und stärker lokal konzentriert als die Liste eines DA, insbesondere wenn eine Multicast-Filterung erfolgt. Diese Filterung wird von zahlreichen Netzwerkadministratoren vorgenommen, damit die Rundsendungen und Multicasts ausschließlich auf das lokale Teilnetz beschränkt werden.
Fazit: Alles hängt von dem Verzeichnisagent ab, den ein Benutzeragent für einen bestimmten Bereich auffindet.
Die folgenden Parameter in der Datei %systemroot%/slp.conf steuern die Ermittlung der Verzeichnisagenten:
net.slp.useScopes = comma-delimited scope list net.slp.DAAddresses = comma-delimited address list net.slp.passiveDADetection = <"true" or "false"> net.slp.activeDADetection = <"true" or "false"> net.slp.DAActiveDiscoveryInterval = <0, 1, or a number of seconds>
Gibt die Bereiche an, in denen der SA die Bekanntgabe vornimmt, außerdem die Bereiche, die abgefragt werden sollen, wenn kein bestimmter Bereich in der Registrierung oder Abfrage des Dienstes oder der Client-Anwendung festgelegt ist. Da das Identitätsdepot Bekanntgaben und Abfragen stets im Standardbereich vornimmt, wird diese Liste zur Standardbereichsliste für alle Registrierungen und Abfragen des Identitätsdepots.
Enthält eine durch Komma getrennte Liste mit dezimalen IP-Adressen der DAs (mit Punkten), die Vorrang vor allen anderen Adressen erhalten sollen. Falls diese Liste der konfigurierten DAs den Bereich einer Registrierung oder Abfrage nicht unterstützt, senden die SAs und UAs ein Multicast für die DA-Ermittlung, sofern diese Art der Ermittlung nicht deaktiviert ist.
Weist standardmäßig den Wert Wahr auf. Wenn die Verzeichnisagenten entsprechend konfiguriert sind, übermitteln sie ihre Existenz in regelmäßigen Abständen per Rundsendung im Teilnetz über einen bekannten Port. Diese Pakete werden als DAAdvert-Pakete bezeichnet. Ist diese Option auf „Falsch“ eingestellt, ignoriert der SA alle rundgesendeten DAAdvert-Pakete.
Weist standardmäßig den Wert Wahr auf. Damit kann der SA in regelmäßigen Abständen per Rundsendung eine Anforderung an alle DAs übermitteln, mit einem zielgerichteten DAAdvert-Paket zu antworten. Ein zielgerichtetes Paket wird nicht rundgesendet, sondern direkt als Antwort auf diese Anforderungen an den SA gesendet. Ist diese Option auf „Falsch“ eingestellt, übermittelt der SA keine DA-Ermittlungsanforderung in regelmäßigen Abständen per Rundsendung.
Parameter mit drei möglichen Zuständen. Der Standardwert lautet 1. Dieser Wert bedeutet, dass der SA nur bei der Initialisierung eine einzige DA-Ermittlungsanforderung senden soll. Wenn Sie diese Option auf 0 einstellen, hat dies dieselbe Wirkung, als wenn Sie die Option activeDADetection auf „Falsch“ einstellen. Jeder andere Wert bezeichnet den Zeitraum (in Sekunden) zwischen den Ermittlungsrundsendungen.
Mithilfe dieser Optionen können Sie die Nutzung der Netzwerkbandbreite für die Dienstbekanntgabe ausgewogen gestalten. Die Standardeinstellungen sind so gewählt, dass die Skalierbarkeit in einem durchschnittlichen Netzwerk optimiert wird.