vom OpenVMS-Fachberater Bob Gezelter
Änderungen an SYS$MANAGER:SYLOGIN.COM vorzunehmen kann gefährlich sein. Was wie eine unbedeutende Änderung aussieht, kann unabsehbare Seiteneffekte haben. In einigen Fällen haben Änderungen, die eine interaktive Umgebung verbessern sollten, dazu geführt, dass produktive Batch- und Standalone-Prozesse fehlschlugen. In anderen Fällen sind ganz andere Benutzergruppen als eigentlich beabsichtigt von einer Änderung betroffen. Diesen Ärger muss man sich nicht machen. Eine Änderung an SYS$MANAGER:SYLOGIN.COM, mit der die Prozedur eine gruppen-spezifische Login-Verarbeitung unterstützt, ist unkompliziert, vermindert die Risiken von Kollateralschäden, und verringert die Belastung des Systemmanagements.
Eine Balance zwischen Sicherheit und Effektivität zu finden kann oft schwierig sein. Lokale Änderungen betreffen weniger Benutzer und sind mithin sicherer als systemweite Änderungen. Dagegen sind systemweite Änderungen ökonomischer, einfacher zu verwalten und zu überprüfen. Änderungen an der Login-Umgebung unterscheiden sich in dieser Beziehung nicht von anderen Änderungen. Systemweite Änderungen bergen mehr Risiken als lokale. Die Login-Einstellungen auf einer begrenzten Basis zu ändern ist bei weitem sicherer. Auch wenn individuelle Benutzer-Logins eine offensichtiliche Wahl sind, um die Reichweite und das Risiko von Änderungen zu begrenzen, so sind sie entsprechend schwieriger zu verwalten und zu kontrollieren. OpenVMS-Gruppen bietet einen Mittelweg; eine natürliche Begrenzung, innerhalb derer Änderungen ausgewogen implementiert werden können, was Skalierung und Risiko angeht. Gruppen sind kein so breiter Kontext wie der systemweite; trotzdem sind sie eine größere Einheit gegenüber dem individuellen Benutzer. Sich einzuschränken mindert die Risiken und beschränkt auch die Komplexität der Wartung. Das Risiko eines Fehlers wird reduziert, wenn Änderungen auf einer Gruppen-Basis vorgenommen werden. Damit ist es z.B. möglich, Änderungen an der Entwicklungsumgebung vorzunehmen, ohne Gefahr zu laufen, die Produktionsumgebung nachteilig zu beeinflussen, selbst wenn sich beide auf derselben OpenVMS-Instanz befinden.
In diesem Kontext betrachtet sind Änderungen an SYS$MANAGER:SYLOGIN.COM eine grobe Keule. Die meisten Änderung sind ihrer Natur nach nicht global; fast immer betreffen sie nur eine bestimmten Kreis von Benutzern. Der SYLOGIN-Mechanismus, so wie er in OpenVMS verwendet wird, hat globalen Einfluß - er wird ausgeführt, wenn ein Prozeß erzeugt wird. Aber OpenVMS stellt auch die Mittel bereit, Anpassungen abgestufter vorzunehmen. Obwohl die Ausführung von SYS$MANAGER:SYLOGIN.COM global passiert, kann der SYLOGIN-Mechanismus dahingehend verändert werden, dass er eine feinere Auflösung bietet (z.B. eine bestimmte OpenVMS-Gruppe), was auch die Reichweite und Risiken der Änderungen begrenzt. Diese Folge des OpenVMS-Fachberaters wird zeigen, wie man den SYLOGIN-Mechanismus erweitern kann, so dass er gruppen-spezifischen Code beinhaltet. Dieser spezielle Code wird vom Gruppenleiter betreut. Noch wichtiger ist: der Gruppenleiter kann die Umgebung seiner Nutzer verwalten, ohne dafür Systemprivilegien zu brauchen.
Dies ist die dritte Folge in einer Serie von Kolumnen über die Verwaltung des SYLOGIN-Prozesses. Die allgemeinen Konzepte, Prinzipien und Gefahren von Änderungen an Dateien, die als Teil der Erzeugung eines Prozesses ausgeführt werden, waren Inhalt der ersten Folge (siehe SYS$MANAGER:SYLOGIN.COM - Flexibilität erfordert Sorgfalt). Die zweite Folge, SYS$MANAGER:SYLOGIN.COM - störungsfreie Verarbeitungsprüfung von SYLOGIN, behandelte sichere Ansätze zur Fehlerisolierung beim Ändern der SYLOGIN-Prozeduren.
In dieser Folge wollen wir eine anderen Aspekt beleuchten, nämlich das Delegieren der Verwaltung von Gruppen-Login-Profilen an relativ nicht-privilegierte Gruppenleiter. Dies stellt ein unkompliziertes Herangehen mit zwei wichtigen Zielen dar: die Begrenzung von Privilegien und das Delegieren von Verwantwortung.
Delegation wird oft unterbewertet. Sie bildet ein wichtiges Fundament im Umgang mit großen und verschiedenen OpenVMS-Nutzer-Gemeinschaften. Delegation grenzt Verantwortlichkeiten für Konsequenzen auf diejenige Gruppe ein, die von Änderungen am stärksten betroffen ist. Diese Eingrenzung ist nützlich, egal ob die Änderungen korrekt sind oder Fehler haben. Dies nützt der Organisation mehr, als wenn das Systemmanagement diese Aufgaben übernimmt. Die Delegierung von Gruppen-Ressourcen an relativ nicht-privilegierte Gruppenleiter war auch eine der Grundlagen meines Workshops OpenVMS User Environments auf der HP World Conference 2004. Natürlich behält das Systemmanagement die Befugnis, bei Bedarf einzugreifen, auch wenn die Gruppenleiter für Änderungen zuständig sind. Die Delegierung der Gruppen-Umgebungen findet immer innerhalb der Grenzen der System-Authorization-Datei (SYSUAF) statt.
In vergleichbarer Art und Weise ist das Konzept eines Gruppen-Verzeichnisbaums (implementiert durch einen logischen Namen DISK$Gruppenname als gruppeneigene private Platte, wie beschrieben in Der OpenVMS-Fachberater: Logische Namen (Teil 5)) nützlich, da es ebenfalls für die Initialisierung auf Gruppenebene verwendet werden kann.
Initialisierung auf Gruppenebene bietet auch eine Testumgebung für Anpassungen. Wenn eine Änderung der Umgebung für eine bestimmte Gruppe nützlich ist, kann sie auch von anderen Gruppen in Erwägung gezogen werden. Wenn festgestellt wird, dass eine solche Änderung weitergehend anwendbar ist, kann sie in den systemweiten Login aufgenommen werden; das Risiko ist in einem solchen Fall deutlich kleiner, da sie schon in einer oder mehreren Gruppen getestet wurde. Zwischenschritte sind ebenfalls möglich.
Eine gruppenspezifische Verarbeitung von SYLOGIN zu implementieren ist unkompliziert. Eine einfache Modifikation an SYS$MANAGER:SYLOGIN.COM ist alles, was dafür nötig ist. Wie oben erwähnt, steht diese Verbesserung im Einklang mit der OpenVMS-Hierarchie und -Philosophie.
Ich erzeuge bevorzugt eine Platte oder eine Pseudo-Platte (d.h. einen "rooted logical name") für jede Gruppe. Der Ansatz mit Rooted Logischen Namen (s. Logical Names: Part 5) hat Vorteile im einfacheren Backup- und Platten-Management. Alternativ können Gruppen auch auf ihren eigenen logischen Disks (erzeugt mit LDDRIVER) platziert werden. Wenn ein SAN-Storage-Controller mit Unterstützung für virtuelle Platten verwendet wird, ist es möglich, für jede Gruppe eine eigene Platte mit einer für die Gruppe angemessenen Größe zu erzeugen.
Die Implementierung einer hierarchischen SYLOGIN-Verarbeitung ist einfach. Während der Ausführung von SYLOGIN wird getestet, ob eine gruppenspezifische Login-Kommandodatei existiert. Dies kann auf verschiedene Arten implementiert werden. Einige gängige Praktiken sind:
- eine Datei mit gleichbbleibendem Namen (z.B. GROUPLOGIN.COM) im Wurzelverzeichnis der gruppen-eigenen Platte oder Pseudo-Platte (meine bevorzugte Methode)
- eine Datei, die über einen logischen Namen in der Gruppen-Tabelle (z.B. GROUPLOGIN) angesprochen wird
- eine Datei mit einem Namen, der von der UIC-Gruppe abgeleitet wird (z.B. SYS$MANAGER:GROUP_gruppen_uic.COM)
Ein Test, ob GROUPLOGIN.COM im Wurzelverzeichnis der gruppen-eigenen Platte existiert, ist sehr einfach; z.B.:
...
$ GROUPLOGINPROFILE = -
$_ F$SEARCH("DISK$''F$GETJPI("","ACCOUNT")':[000000]GROUPLOGIN.COM")
$ IF F$LENGTH(GROUPLOGINPROFILE) .NE. 0 THEN -
$_ @'GROUPLOGINPROFILE'
...
Der Kontext, in dem das gruppen-spezifische Login-Profile ausgeführt wird, ist derselbe wie von SYLOGIN. In der Regel platziere ich Code für den Gruppen-Login ans Ende von SYLOGIN, hinter den Kommentar (der Standard-SYLOGIN.COM) "Place your site-specific LOGIN commands below". Das ist die Stelle im SYLOGIN-Codepfad, an dem die verschiedenen Ausführungspfade wieder zusammenlaufen. Das garantiert, dass das Gruppen-Login-Profile für alle Prozesse ausgeführt wird.
Der Inhalt des Gruppen-Logins liegt ganz bei denen, die es verwalten. Man kann z.B.
- DCL-Kürzel definieren
- DCL-Kommandos mittels SET COMMAND definieren
- logische Namen in den verschiedenen prozess- und gruppen-eigenen Tabellen definieren
- logische Namen für Druckerqueues definieren
Das Profil sollte eine Sektion mit DCL GOTO enthalten (siehe DCL Computed GOTO [Artikel nicht übersetzt - Anm.d.Ü.]).
Beispielcode, der zu SYLOGIN hinzugefügt werden kann, zusammen mit einem einfachen Skelett eines gruppenweiten Login-Profils befindet sich unter http://www.rlgsc.com/demonstrations/openvms-grouplogin.html.
Gruppen-Login-Profile sind eine gut strukturierte Anpassung der Standard-OpenVMS-Umgebung. Wie man aus den Kommentaren am Ende der mitgelieferten SYS$MANAGER:SYLOGIN.COM sehen kann, gibt es klar markierte Positionen, an denen lokale, spezifische Anpassungen vorgenommen werden können; Gruppen-Logins sind lediglich ein strukturierter Weg, die Standard-SYLOGIN zu erweitern. Diese Erweiterung delegiert die Verwaltung des Gruppen-Login-Profils an relativ nicht-privilegierte Gruppenleiter, während die Systemsicherheit gewahrt bleibt. Änderungen an Gruppen-Login-Profilen betreffen nur die Gruppe. Insgesamt werden durch die bessere Kontrolle und die Reduzierung des Wartungsaufwands Kosten gespart.
Wie immer begrüße ich Leserkorrespondenz zu den Inhalten dieser Kolumne. Ich bin zu erreichen über den Website meiner Firma unter http://www.rlgsc.com.
Über den Autor:
Robert Gezelter, CDP, CSA, CSE, Software Consultant, hat mehr als 30 Jahre internationale Erfahrung mit der Fachberatung im privaten und öffentlichen Sektor. Er ist regelmäßiger Gastredner auf technischen Konferenzen weltweit, einschließlich des HP Technology Forums. 2004 hat die IEEE Computer Society Mr. Gezelter in ihr Distinguished Visitors Program berufen, das Redner auf Veranstaltungen von IEEE-Verbänden in ganz Nordamerika vermittelt. Außerdem hat er zahlreiche technische Artikel und Buchkapitel verfasst, einschließlich zweier Kapitel in dem kürzlich erschienenen Computer Security Handbook, 5. Auflage.
Außerdem veröffentlicht er Ruminations - An IT Blog über IT-Themen zu schreiben, die nicht unbedingt mit OpenVMS in Verbindung stehen.
Die Tätigkeit seiner Firma betont detaillierte technische Expertise in den Bereichen Computer-Architekturen, Betriebssysteme, Netzwerke, Sicherheit, APIs und verwandte Themen. Mr. Gezelter hat mit OpenVMS seit der ersten Release von VAX/VMS 1977 gearbeitet.
Seine Kundenstamm umfasst sowohl kleinere Firmen wie auch Firmen in den Fortune 10, lokal, national und international, mit Arbeitsbereichen, die von individuellen Telefon-Fragen bis zu größeren Projekten reichen.
Im Web ist er über den Website seiner Firma unter http://www.rlgsc.com zu erreichen.
Original auf www.openvms.org
Original auf Bob Gezelters Site
|