VServer Services: NS Switch konfigurieren

Voraussetzungen und zulässige NS-Switch-Datenbanken

Für die Änderung des NS Switch benötigen Sie eine Administratorsitzung auf dem Cluster oder der betroffenen SVM. Der Eintrag gilt immer für genau einen Vserver. Prüfen Sie daher vor der Änderung den Namen der SVM und arbeiten Sie nicht versehentlich im falschen Mandanten.

Die Auswahl der Datenbank bestimmt, welche Informationen ONTAP über externe Dienste suchen darf. Zulässig sind:

hosts für Hostnamen und IP-Adressen. Erlaubt sind files und dns.
group für Gruppen. Erlaubt sind files, nis und ldap.
passwd für Benutzer. Erlaubt sind files, nis und ldap.
netgroup für Netgroups. Erlaubt sind files, nis und ldap.
namemap für Benutzerzuordnungen. Erlaubt sind files und ldap.

Die Kombination muss zur jeweiligen Datenbank passen. Ein Eintrag wie dns bei passwd oder nis bei hosts ist nicht zulässig.

Besondere Vorsicht gilt für passwd und group. Fehlt dort files, müssen die für ONTAP benötigten lokalen Standardkonten und Gruppen in LDAP oder NIS vorhanden sein. Andernfalls können Zugriffe, Zuordnungen oder Verwaltungsfunktionen scheitern, obwohl der externe Dienst erreichbar ist. Stimmen Sie die Identitäten und Gruppen daher vor der Umstellung mit dem Verzeichnis ab. Die vollständige Liste hängt vom eingesetzten ONTAP-Release und den aktivierten Funktionen ab und sollte gegen die NetApp-Dokumentation der verwendeten Version geprüft werden.

Die spätere Änderung verwendet den Vserver-Namen, die Datenbank und eine gültige Quellenfolge. Mehrere Quellen werden mit Kommas getrennt; ihre Reihenfolge ist bewusst zu wählen. Eine externe Quelle allein ist nur dann sinnvoll, wenn Ausfallsicherheit und vollständige Einträge bereits geprüft sind.

Aktuelle NS-Switch-Einträge mit `show` prüfen

Prüfen Sie die bestehende NS-Switch-Tabelle, bevor Sie einen Eintrag ändern. So erkennen Sie die aktuelle Konfiguration und vermeiden eine Änderung am falschen Vserver.

Für die vollständige Übersicht verwenden Sie:

cluster1::> vserver services name-service ns-switch show

Eine gezielte Prüfung ist meist übersichtlicher. Mit -vserver begrenzen Sie die Ausgabe auf eine SVM:

cluster1::> vserver services name-service ns-switch show -vserver vs0

Zusätzlich können Sie nach einer Datenbank filtern:

cluster1::> vserver services name-service ns-switch show -vserver vs0 -database hosts

Mit -fields lassen sich ausgewählte Spalten anzeigen:

cluster1::> vserver services name-service ns-switch show -fields vserver,database,sources

Benötigen Sie die vollständigen Details jedes Eintrags, verwenden Sie -instance:

cluster1::> vserver services name-service ns-switch show -instance

Achten Sie bei der Ausgabe besonders auf:

den richtigen Vserver,
einen vorhandenen Eintrag für die gewünschte Datenbank,
die beabsichtigte Quellenfolge.

Eine mehrzeilig dargestellte Quellenliste gehört weiterhin zu einem Eintrag. Die Zeilenumbrüche in der CLI-Ausgabe bedeuten also nicht, dass mehrere getrennte Konfigurationen vorliegen. Mit -sources können Sie nach einer bestimmten Quellenfolge filtern; die Prüfung von Vserver und Datenbank ersetzt das jedoch nicht.

Quellen und Abfragereihenfolge je Datenbank festlegen

Die Quellenfolge sollte zum Datenfluss der jeweiligen Datenbank passen. Eine lokale Quelle eignet sich als schnelle erste Prüfung, ein Verzeichnisdienst für zentral verwaltete Identitäten. Maßgeblich sind ein klares Verhalten bei Treffern und Fehlern sowie eine erreichbare Dienstumgebung.

Ordnen Sie die maßgebliche Quelle an die erste Stelle. Weitere Quellen dienen als Ergänzung oder Ausweichweg. Eine langsame oder nicht erreichbare Quelle an erster Stelle kann Anmeldungen und SMB-Vorgänge spürbar verzögern.

Für hosts ist eine kurze Kette üblich. Mit files,dns prüft ONTAP zuerst lokale Einträge und fragt danach DNS ab. Umgekehrt eignet sich dns,files, wenn DNS die führende Datenbasis sein soll.

Bei passwd, group und netgroup sollte die zentrale Quelle nach vorne, wenn LDAP oder NIS die verbindlichen Daten enthält. Eine Folge wie ldap,nis trennt die primäre Verzeichnisabfrage von der Ausweichquelle. Die Reihenfolge sollte in allen drei Datenbanken zusammenpassen; sonst können Benutzer und Gruppen aus unterschiedlichen Diensten stammen.

Für namemap kommen nur files und ldap infrage. Nutzen Sie files,ldap, wenn lokale Zuordnungen Vorrang haben, oder ldap,files, wenn das zentrale Verzeichnis Priorität erhält. Das ist relevant, wenn derselbe Name in beiden Quellen vorkommt.

Die gewünschte Folge tragen Sie mit dem Änderungsbefehl ein. Beispiel für eine zentrale LDAP-Abfrage mit NIS als Reserve:

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database group -sources ldap,nis

Verwenden Sie keine Quelle, die für die gewählte Datenbank nicht zugelassen ist. Prüfen Sie außerdem, ob die Namensauflösung zwischen SVM und Dienstnetz funktioniert. Eine formal korrekte Reihenfolge hilft wenig, wenn DNS, LDAP oder NIS wegen Routing, Firewall oder Zertifikaten nicht erreichbar ist.

Syntax von `vserver services name-service ns-switch modify`

Mit vserver services name-service ns-switch modify ändern Sie einen vorhandenen NS-Switch-Eintrag für einen bestimmten Vserver. Der Befehl passt die Quellenfolge an; er richtet weder LDAP, NIS noch DNS selbst ein.

Die Grundsyntax lautet:

cluster1::> vserver services name-service ns-switch modify -vserver <vserver-name> -database <datenbank> [-sources <quelle1,quelle2>]

Der Parameter -vserver bestimmt das Ziel. Verwenden Sie den exakten Namen der Daten- oder Admin-SVM. Mit -database wählen Sie den zu ändernden Eintrag. -sources ist optional. Fehlt der Parameter, bleibt die bisherige Quellenfolge unverändert.

Mehrere Quellen werden ohne Leerzeichen durch Kommas getrennt. Schreibweisen wie ldap, nis sollten Sie vermeiden, weil die ONTAP-CLI den Wert dann nicht wie beabsichtigt verarbeitet.

Ein vollständiger Aufruf für die Hostdatenbank sieht so aus:

cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources files,dns

Für eine Passwortdatenbank mit LDAP und NIS lautet der Aufruf beispielsweise:

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources ldap,nis

Verwenden Sie pro Aufruf genau eine Datenbank. Sollen mehrere Einträge geändert werden, führen Sie den Befehl für jede Datenbank separat aus. Dadurch bleibt im Änderungsprotokoll klar erkennbar, welche Konfiguration angepasst wurde.

-vserver: Ziel-Vserver
-database: NS-Switch-Datenbank
-sources: neue Quellenfolge, durch Kommas getrennt

Für die Ausführung benötigen Sie ausreichende Administratorrechte. Ein syntaktisch korrekter Aufruf kann trotzdem auf die falsche SVM zeigen. Prüfen Sie den Zielnamen deshalb vor dem Absenden nochmals sorgfältig.

Host-Auflösung mit `files` und `dns` konfigurieren

Für die Datenbank hosts können Sie lokale Einträge und DNS miteinander kombinieren. Die Einstellung wirkt sich auf ONTAP-interne Hostabfragen der jeweiligen SVM aus. Sie ersetzt weder die DNS-Serverkonfiguration noch die Namensauflösung auf Clients.

Eine typische Kombination lautet:

cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources files,dns

ONTAP berücksichtigt zuerst die lokale Quelle und greift anschließend auf DNS zurück. Diese Reihenfolge passt etwa für wenige feste Infrastrukturadressen, während reguläre Hosts aus DNS stammen.

Soll DNS die alleinige Quelle sein, verwenden Sie:

cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources dns

Das vereinfacht die Konfiguration, erhöht aber die Abhängigkeit von erreichbaren DNS-Servern und einer korrekten DNS-Zone. Achten Sie auf passende A- und gegebenenfalls PTR-Einträge. Für Verbindungen genügt meist der A-Eintrag; Protokolle und Prüfungen können zusätzlich eine umgekehrte Auflösung erwarten.

Nach der Änderung kontrollieren Sie die gespeicherte Quellenfolge:

cluster1::> vserver services name-service ns-switch show -vserver vs0 -database hosts

Bleibt eine Auflösung aus, prüfen Sie:

Ist die SVM über ihre Daten-LIFs zum DNS-Dienst geroutet?
Erlauben Firewalls DNS-Anfragen über UDP und bei Bedarf TCP auf Port 53?
Antwortet der zuständige DNS-Server für den abgefragten Namen?
Verweist der Name auf die erwartete IP-Adresse?

Ein lokaler Treffer kann einen fehlerhaften DNS-Eintrag verdecken. Für Tests sollten Sie daher Namen verwenden, die nicht gleichzeitig in beiden Quellen mit unterschiedlichen Adressen vorkommen.

Benutzer-, Gruppen- und Netgroup-Quellen mit LDAP oder NIS konfigurieren

Für zentrale Benutzer-, Gruppen- und Netgroup-Abfragen setzen Sie die jeweilige Datenbank auf ldap oder nis. LDAP ist meist bei hierarchischen Verzeichnisstrukturen üblich, NIS eher in älteren UNIX-Umgebungen.

Eine LDAP-basierte Konfiguration für Benutzer, Gruppen und Netgroups kann so aussehen:

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources ldap

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database group -sources ldap

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database netgroup -sources ldap

Für NIS lautet der entsprechende Aufbau:

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources nis

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database group -sources nis

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database netgroup -sources nis

Ein gemischter Betrieb ist möglich. Beispielsweise kann LDAP Benutzer liefern, während NIS Gruppen bereitstellt. Stimmen Benutzername, numerische ID und Gruppenzugehörigkeit nicht überein, entstehen schwer erkennbare Berechtigungsfehler.

Prüfen Sie vor der Aktivierung:

ob der externe Dienst aus der SVM erreichbar ist,
ob Suchbasis und relevante Attribute zum ONTAP-Namensdienstprofil passen,
ob identische Namen in LDAP und NIS unterschiedliche IDs besitzen,
ob Netgroup-Mitglieder im erwarteten Format vorliegen,
ob Gruppenmitgliedschaften auch bei verschachtelten Gruppen korrekt geliefert werden.

Verwenden Sie für eine Ausweichquelle etwa ldap,nis. Das ist nur sinnvoll, wenn beide Dienste denselben Identitätsbestand abbilden. Sonst kann ein Ausfall des primären Dienstes zu einem anderen Benutzer- oder Gruppenbild führen.

Namemap zwischen lokalen Dateien und LDAP einrichten

Die Datenbank namemap steuert die Zuordnung zwischen Windows- und UNIX-Benutzernamen. Sie ist wichtig, wenn SMB-Zugriffe auf Dateien treffen, deren Berechtigungen mit UNIX-Identitäten arbeiten. Für diese Datenbank sind nur files und ldap zulässig.

Verwenden Sie lokale Zuordnungen, wenn wenige feste Regeln benötigt werden:

cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database namemap -sources files

LDAP als zentrale Quelle konfigurieren Sie so:

cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database namemap -sources ldap

Eine Kombination erlaubt lokale Ausnahmen mit LDAP als Reserve:

cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database namemap -sources files,ldap

Wählen Sie dagegen ldap,files, wenn die zentrale Zuordnung Vorrang haben soll. Treffen beide Quellen denselben Namen, kann die Reihenfolge bestimmen, welche Identität ONTAP verwendet.

Vor der Umstellung müssen die LDAP-Zuordnungen zum verwendeten Namensschema passen. Prüfen Sie insbesondere:

ob Windows- und UNIX-Namen eindeutig zusammengehören,
ob die erwarteten LDAP-Attribute gefüllt sind,
ob Groß- und Kleinschreibung konsistent behandelt wird,
ob Domänen- oder Bereichsangaben im Mapping berücksichtigt werden,
ob keine widersprüchlichen lokalen und zentralen Regeln existieren.

Ändern Sie die Quellenfolge nicht mit einer passwd- oder group-Konfiguration. Für Benutzerzuordnungen ist ausschließlich die Datenbank namemap vorgesehen. Nach der Änderung sollten Sie einen SMB-Zugriff mit einem Testkonto ausführen und prüfen, ob die erwartete UNIX-Identität verwendet wird.

Standardbenutzer und -gruppen bei externer Auflösung berücksichtigen

Wenn passwd oder group ohne files arbeitet, müssen zentrale Dienste auch die für ONTAP relevanten Systemidentitäten liefern. Fehlt ein benötigter Eintrag, können SMB-Anmeldung, Besitzauflösung oder Gruppenprüfungen scheitern. Der Dienst ist dann zwar erreichbar, die Antwort bleibt aber unvollständig.

Prüfen Sie im externen Verzeichnis mindestens die folgenden Benutzerkonten:

root
nobody
pcuser
sshd
daemon
operator
bin
www
admin
autosupport

Zusätzlich sollten die benötigten Systemgruppen vorhanden sein. Dazu zählen unter anderem wheel, daemon, sys, tty, operator, staff, sshd, www, nogroup und nobody.

Achten Sie nicht nur auf den Namen. Auch die numerische Benutzer- oder Gruppen-ID muss konsistent sein. Liefert LDAP für denselben Namen eine andere ID als ein früher verwendetes lokales System, können Besitzangaben und Zugriffsrechte einer anderen Identität zugeordnet werden.

Kontrollieren Sie außerdem:

eindeutige Einträge ohne doppelte Namen,
passende Primärgruppen für technische Konten,
erreichbare Suchbasen und korrekte Filter,
die Rückgabe aller benötigten Attribute,
die Auflösung von Benutzer- und Gruppennamen aus der betroffenen SVM.

Führen Sie die Umstellung zunächst mit einem Wartungs- oder Testfenster durch. Nach der Änderung testen Sie einen SMB-Zugriff, die Anzeige von Besitzerinformationen und eine Gruppenberechtigung. Bleibt ein Systemkonto im externen Dienst verborgen, hilft auch eine korrekte NS-Switch-Reihenfolge nicht weiter.

Beispiel: Nur DNS für Hosts verwenden

Wenn die SVM Hostnamen ausschließlich über DNS auflösen soll, setzen Sie für die Datenbank hosts nur die Quelle dns. Dadurch entfallen lokale Fallback-Einträge.

Verwenden Sie für den Vserver vs0 folgenden Befehl:

cluster1::> vserver services name-service ns-switch modify -vserver vs0 -database hosts -sources dns

Der Aufruf ändert ausschließlich den Eintrag für die Hostdatenbank dieser SVM. Benutzer, Gruppen, Netgroups und Namemap-Zuordnungen bleiben unberührt.

Vor der Umstellung müssen die DNS-Daten vollständig sein. Prüfen Sie insbesondere die Namen von LDAP-Servern, NIS-Servern, SMB-Partnern und Managementsystemen, die ONTAP über diese SVM erreichen muss. Fehlt ein erforderlicher A- oder AAAA-Eintrag, kann der Zugriff trotz funktionierender IP-Verbindung scheitern.

Kontrollieren Sie nach dem Ändern den gespeicherten Eintrag:

cluster1::> vserver services name-service ns-switch show -vserver vs0 -database hosts

In der Ausgabe muss bei Source Order ausschließlich dns stehen. Testen Sie danach einen Namen aus der produktiven DNS-Zone und einen absichtlich nicht vorhandenen Namen.

Prüfen Sie die DNS-Server und Suchdomänen der SVM.
Stellen Sie die Erreichbarkeit über das Routing der SVM sicher.
Erlauben Sie DNS-Verkehr über UDP sowie bei großen Antworten auch über TCP auf Port 53.
Kontrollieren Sie bei Bedarf die IPv4- und IPv6-Auflösung getrennt.

Nutzen Sie diese Einstellung nur, wenn DNS als verbindliche Quelle vorgesehen ist. Bei Wartungsarbeiten am DNS-Dienst gibt es keinen lokalen Ersatz.

Beispiel: LDAP vor NIS für Passwörter abfragen

Mit ldap,nis legen Sie LDAP als erste Quelle und NIS als Ausweichquelle für die Passwortdatenbank fest:

cluster1::> vserver services name-service ns-switch modify -vserver vs1 -database passwd -sources ldap,nis

Ein erfolgreicher Treffer aus LDAP beendet die Suche. NIS wird nur berücksichtigt, wenn LDAP keinen passenden Eintrag liefert oder nicht verwendet werden kann.

Die Konfiguration setzt voraus, dass beide Dienste denselben Identitätsbestand abbilden. Prüfen Sie deshalb, ob Benutzername, numerische Benutzer-ID, Primärgruppe und relevante Attribute in LDAP und NIS zusammenpassen.

Da files nicht enthalten ist, müssen die erforderlichen Standardkonten in LDAP oder NIS verfügbar sein. Dazu gehören beispielsweise root, nobody, pcuser, sshd und autosupport.

Prüfen Sie nach der Änderung den gespeicherten Eintrag:

cluster1::> vserver services name-service ns-switch show -vserver vs1 -database passwd

Testen Sie anschließend mindestens einen LDAP-Benutzer und einen Benutzer, der nur in NIS vorhanden ist. Ein identischer Testname in beiden Diensten ist dafür ungeeignet, weil er die Ausweichlogik verdecken kann.

LDAP-Eintrag vorhanden: LDAP liefert das Ergebnis.
LDAP ohne passenden Treffer: ONTAP versucht NIS.
LDAP nicht erreichbar: NIS kann als Reserve dienen.
Kein Treffer in beiden Quellen: Die Benutzerauflösung bleibt erfolglos.

Für eine vollständige zentrale Identitätsverwaltung sollten Sie die zugehörige Datenbank group mit einer konsistenten Quellenfolge planen. Nur so passen Benutzer- und Gruppenauflösung dauerhaft zusammen.

Änderung prüfen und typische Fehler vermeiden

Nach jeder Änderung prüfen Sie nicht nur die gespeicherte Quellenfolge, sondern auch das Verhalten der betroffenen SVM. Eine korrekte Anzeige beweist lediglich, dass der Eintrag übernommen wurde.

Führen Sie zunächst eine gezielte Kontrolle aus:

cluster1::> vserver services name-service ns-switch show -vserver vs1 -database passwd -instance

Vergleichen Sie Vserver, Datenbank und vollständige Reihenfolge mit dem Änderungsauftrag. Prüfen Sie außerdem, ob nicht versehentlich ein anderer Eintrag mit ähnlichem Namen angepasst wurde.

Testen Sie danach einen realistischen Anwendungsfall. Bei passwd und group gehört dazu ein Benutzer mit bekannter Identität und eine Gruppe mit erwarteter Mitgliedschaft. Bei hosts testen Sie einen vorhandenen Namen sowie eine bewusst ungültige Anfrage. Für namemap eignet sich ein SMB-Zugriff mit einem Konto, dessen Windows- und UNIX-Zuordnung bekannt ist.

Typische Fehler lassen sich meist einer dieser Ursachen zuordnen:

Falscher Vserver: Die Änderung wurde auf einer anderen SVM vorgenommen als der produktive Zugriff.
Unpassende Datenbank: Eine Hostauflösung wird geprüft, obwohl nur passwd geändert wurde.
Veraltete Dienstantwort: Ein Verzeichnisdienst liefert zwischengespeicherte oder noch nicht replizierte Daten.
Unterschiedliche IDs: Derselbe Name besitzt in mehreren Quellen verschiedene numerische IDs.
Unvollständiger Fallback: Die Reservequelle enthält den gesuchten Benutzer oder die Gruppe nicht.
Fehlerhafte Dienstbindung: LDAP oder NIS ist erreichbar, liefert aber wegen Filter, Suchbasis oder Berechtigung kein passendes Ergebnis.

Vermeiden Sie schnelle Gegenänderungen. Sichern Sie zuerst die aktuelle Ausgabe und notieren Sie Zeitpunkt, Vserver, Datenbank sowie die verwendete Quellenfolge. Bei Störungen grenzen Sie die Ursache schrittweise ein: zuerst Konfiguration, dann Netzwerkpfad, danach Dienstantwort und zuletzt die Identitätsdaten.

Fazit: NS-Switch gezielt ändern und anschließend kontrollieren

Eine belastbare NS-Switch-Konfiguration entsteht nicht durch möglichst viele Quellen, sondern durch eine klar begründete Zuordnung pro Datenbank. Setzen Sie mit vserver services name-service ns-switch modify nur die tatsächlich benötigte Reihenfolge und halten Sie die Änderung im Betriebshandbuch fest.

Für den Abschluss zählen drei Ergebnisse: Der richtige Vserver wurde geändert, die gewählte Quelle liefert die erwarteten Daten, und ein definierter Rückweg ist bekannt. Planen Sie deshalb einen Rückfall auf die zuvor dokumentierte Quellenfolge. Ändern Sie bei einer Störung nur den betroffenen Datenbankeintrag und beobachten Sie anschließend die produktiven SMB- oder Verwaltungsfunktionen.

Änderungsgrund und betroffene SVM dokumentieren.
Vorherige und neue Quellenfolge gegenüberstellen.
Erwartetes Verhalten für Treffer, Nichttreffer und Dienstausfall festlegen.
Nach der Änderung einen fachlich passenden Zugriff prüfen.
Die Konfiguration bei Änderungen an LDAP, NIS oder DNS erneut bewerten.

Damit wird der NS Switch zu einer kontrollierbaren Betriebsregel statt zu einer versteckten Fehlerquelle. Kleine, gezielte Änderungen lassen sich prüfen, zurücknehmen und später eindeutig erklären.