http://www.urz.uni-heidelberg.de/zentral/urz/schriften/unixhb/kap03.html (Einblicke ins Internet, 10/1995)Dieser Aufbau bringt verschiedene Vorteile mit sich: Wird z.B. von einem Benutzer auf einem Modell 580 hohe Rechenleistung für eine numerische Simulation angefordert, so werden davon die Anwender, deren Applikationen auf einem Modell 320 laufen, nicht beeinträchtigt. Auch bleiben im Falle eines technischen Defektes an einem der Rechner im Pool alle anderen Computer einsatzbereit. Außerdem läßt sich die Zusammensetzung des Geräteparks modular erweitern bzw. auf bestimmte Bedürfnisse einzelner Anwender- oder Gruppen hin anpassen.
Diese durch die dezentrale Architektur erreichte Flexibilität wirft aber nun leider auch eine Frage auf: Wie und vor allen Dingen wo werden die jeweiligen Benutzerdaten abgelegt? Der einzelne Anwender hat es nun ja nicht mehr, wie beim Großrechner oder PC, mit einem einzigen Computer und "seiner" Festplatte zu tun.
Eine mögliche Lösung dieses Problems wäre es, alle Geräte des Pools mit entsprechender Festplattenkapazität auszurüsten, um auf jeder Maschine die Informationen aller Benutzer bereithalten zu können. Dies hieße, daß jede einzelne Workstation die Daten von ca. 2500 Anwendern verwalten müßte. Es leuchtet sicherlich ein, daß dieser Vorschlag schon wegen des enormen finanziellen Aufwandes, der nötig wäre, solche Festplattenkapazitäten zu installieren bzw. zu betreiben, nicht praktikabel ist.
Vor einigen Jahren nun sahen sich die Systemverwalter am Massachusetts Institute of Technology (MIT) mit der gleichen Problematik konfrontiert und entwickelten daher ein Lösungskonzept, das heute unter dem Namen Network File System (NFS)[3 ]bekannt ist.
Die zugrundeliegende Idee ist einfach und doch brilliant: Man benutzt das Netzwerk, über das die einzelnen Computer miteinander verbunden sind, um Teile des Dateibaums einer anderen Maschine im lokalen Dateibaum "einzublenden". Die Benutzer auf der lokalen Maschine "sehen" jetzt die Daten des anderen Rechners so, als ob diese auf der lokalen Festplatte vorhanden wären, d.h. auch diese Dateien können auf dem lokalen Computer, entsprechende Zugriffsrechte vorausgesetzt, gelesen, modifiziert und gelöscht werden.
Das Betriebssystem setzt dabei die einzelnen Dateizugriffe in entsprechende Anfragen an den Computer um, der die Daten physisch verwaltet, d.h. auf dessen Festplatte sie real vorhanden sind. Dieser Computer führt nun alle Dateioperationen, die ihm von der lokalen Maschine mitgeteilt werden, quasi "ferngelenkt" durch und quittiert die jeweilige Aktion.
Der Dateizugriff ist für den jeweiligen Benutzer völlig transparent, d.h. er merkt nichts von der geschäftigen Aktivität auf dem Netzwerk. Alle Operationen werden genauso ausgeführt, als ob die Daten auf der lokalen Festplatte gehalten würden. Da es unter NFS nun möglich ist, beliebige Informationen auf jedem Rechner des Netzwerkes zu speichern bzw. auf diese Informationen von jedem Rechner aus zuzugreifen, spricht man in diesem Zusammenhang auch von einem verteilten Filesystem oder Dateibaum. Ein verteiltes Filesystem verknüpft also die Dateibäume verschiedener Computer und verbirgt zugleich die Struktur des zugrundeliegenden Netzwerkes. Da NFS leider mit steigender Benutzer- bzw. Gerätezahl gewisse Unsicherheiten bezüglich der Zugriffsbeschränkung einzelner Dateien und eine hohe Netzbelastung zeigt, hat man am Konzept des verteilten Filesystems weiter gearbeitet. Die Ergebnisse dieser Bemühungen wurden im Andrew File System (AFS) zusammengefaßt bzw. umgesetzt.
Alles, was bisher zu verteilten Filesystemen gesagt wurde, gilt in vollem Umfang auch für AFS. Im Gegensatz zu NFS stellt AFS jedoch erheblich verbesserte Schutzmechanismen zur Verfügung, die weit über die einfachen Standard-UNIX Zugriffsrechte, die ja nur nach Eigentümer, Gruppe und allen anderen Benutzern unterscheiden, hinausgehen. So ist es im AFS z.B. möglich, den Zugriff auf Dateien für einen bestimmten Benutzer zu erlauben oder zu verbieten. Die Vergabe dieser erweiterten Zugriffsrechte kann in der gegenwärtigen Implementierung nur für ganze Verzeichnisse erfolgen.
Außerdem kann jeder Benutzer eigene Benutzergruppen bilden. Die Mitglieder einer Gruppe, z.B. Mitarbeiter eines Institutes, können untereinander Informationen austauschen und auf dieselben Dateien zugreifen, gleichgültig, auf welchen Rechnern diese abgelegt oder zuletzt bearbeitet wurden. Gruppen können mit anderen Gruppen ebenso wie mit einzelnen Benutzern in Kontakt treten, diesen Daten zu Verfügung stellen oder auch umgekehrt den Zugriff durch Dritte einschränken. Mit AFS ist es für jeden Benutzer sehr einfach, sich eine abgeschlossene Arbeitsumgebung zu erstellen.
Unter AFS ist es für den Benutzer nicht relevant, den physischen Aufenthaltsort seiner Daten zu kennen. Es genügt schon, wenn eine Datei mit ihrem regulären UNIX-Pfadnamen angesprochen wird (z.B.: "cat /u/efi/yz9/lies_mich") und AFS findet automatisch die entsprechende Datei genau so, als ob diese auf einer lokal angeschlossenen Festplatte abgelegt worden wäre. Wie funktioniert dies nun?
Das Andrew File System basiert auf dem "Client-Server Prinzip", d.h. es kommen zwei Kategorien von Rechnern, die verschiedene spezielle Funktionen ausführen, zum Einsatz. Fileserver sind Geräte, die Informationen speichern und diese auf Anfrage anderen Maschinen zur Verfügung stellen. Diese anderen Maschinen werden Clients genannt. Die Hauptaufgabe der Clients besteht in der Bereitstellung von Rechenleistung für die Anwender. Clients und Server stehen über das Netzwerk in ständigem Kontakt zueinander und tauschen Informationen aus. In den meisten Fällen wird ein Benutzer also auf einem Rechner arbeiten, der als Client konfiguriert ist und dabei Daten benutzen, die auf einem Fileserver abgelegt sind und vom diesem bereitgestellt werden.
Bei der Installation am URZ dienen die beiden Geräte aixfile1 und aixfile2 als AFS-Server und alle anderen RS/6000-Computer sowie viele weitere UNIX-Rechner als Clients. Zusätzlich zu ihrer Rolle als Server sind die beiden erwähnten 950er Modelle auch als Clients konfiguriert.
Der Name einer solchen Zelle wird üblicherweise aus dem Namen der jeweiligen Internet-Domain abgeleitet (siehe auch Kapitel 1.4). Aus diesem Grund heißt die AFS-Zelle des Rechenzentrums "urz.uni-heidelberg.de". (Da dies nun ein ziemlich unhandlicher Verzeichnisname ist und wir uns auch laufend vertippt haben, gibt es einen symbolischen Link namens "urz" auf dieses Verzeichnis). Die Zelle, zu der die Workstation gehört, auf der Sie gerade arbeiten, wird als lokale Zelle bezeichnet; alle anderen Zellen heißen fremde Zellen.
Obwohl jede einzelne Zelle von ihren jeweiligen Administratoren völlig unabhängig verwaltet wird, können verschiedene Zellen ihre Dateibäume miteinander verbinden. So ist es theoretisch möglich, daß alle AFS-Zellen am Internet in Kontakt treten und einen einzigen, sehr großen weltweiten Dateibaum bilden. Einschränkend muß hier gesagt werden, daß die Übertragungsgeschwindigkeit etwa beim Kopieren von Files von unserer lokalen Zelle in die USA so niedrig ist, daß ein "normales" Arbeiten nicht möglich ist. Anders liegt der Fall bei nähergelegenen Zellen, z.B. innerhalb von Heidelbergs (HD-Net) oder Baden-Württemberg (BelWü). Daher wird die Verknüpfung der Heidelberger AFS-Zelle mit allen AFS-Zellen in Baden-Württemberg (u.a. in Stuttgart und in Freiburg) von standardmäßig bereitgestellt. Weitere Zellen können auf Wunsch verfügbar gemacht werden.
Auf welchem der Fileserver sich "Ihr" Volume und damit Ihr Home-Verzeichnis befindet, ist nicht relevant, da AFS die Wiederbeschaffung der Daten automatisch abwickelt (und bisher erfreulicherweise auch alle Dateien wiedergefunden hat).
Volumes haben bestimmte Eigenschaften. So werden Benutzer-Volumes in unserer Zelle standardmäßig mit einem Kontingent von sechs MByte versehen, d.h. Sie dürfen maximal sechs MB Plattenplatz belegen. Eine solche Platzbeschränkung bezeichnet man als quota. Sollten Sie versuchen, größere Datenmengen abzuspeichern, dann wird AFS Ihren Schreibversuch mit einer Fehlermeldung quittieren. Jedes quota kann selbstverständlich durch die Administratoren je nach Bedarf verändert werden.
Jedes Volume befindet sich in genau einer Partition. Deshalb kann es vorkommen, daß das einzelne Volume seine Quotierung noch nicht ausgeschöpft hat, aber wegen einer bereits gefüllten Partition keine Daten mehr gespeichert werden können.
Eine weitere Eigenschaft eines Volumes ist eine Liste mit individuellen Zugriffsrechten, die sog. access control list (acl). Hierzu jedoch später mehr.
Wenn Sie mit dem Befehl cd von einem Verzeichnis in ein anderes wechseln, kann es nun sein, daß Sie in Wirklichkeit über einen Mount-point hinweg, statt in ein anderes Verzeichnis, in ein anderes Volume hineingesprungen sind. Dieses neue Volume ist eventuell auf einem anderen Fileserver abgespeichert oder gehört gar zu einer fremden Zelle. Bitte erinnern Sie sich: wo sich ein Volume physisch befindet, können Sie nicht aus dessen Lage im Dateibaum schließen. Sie können auf Informationen eines anderen Rechners in der lokalen oder einer fremden Zelle zugreifen, indem Sie einfach in ein anderes Verzeichnis im AFS-Dateibaum wechseln. Ein Beispiel: Der Benutzer mit der User-ID ZY9 in der AFS-Zelle urz.uni-heidelberg.de gehört dem Institut für Esperanto und Fischzucht (EFI) an und besitzt ein Volume mit dem Namen user.zy9. Der mount point für sein Home-Verzeichnis befindet sich dann im Verzeichnis /afs/urz.uni-heidelberg.de/usr/efi, trägt den Namen zy9 und "zeigt" auf das Volume user.zy9. Wenn ZY9 nun in seinem Home-Verzeichnis Unterverzeichnisse anlegt, dann befinden sich diese immer noch im Volume user.zy9 und werden auch auf demselben Fileserver abgespeichert, wo sich das Volume user.zy9 befindet. Wechselt ZY9 jetzt von seinem Home-Verzeichnis aus in das seines Kollegen XY8, dann greift er über den mount point xy8 im Verzeichnis /afs/urz.uni-heidelberg.de/usr/efi auf das Volume user.xy8 zu. Dieses liegt möglicherweise auf einem anderen Fileserver als sein eigenes, doch davon merkt ZY9 nichts, da AFS die Verwaltung der Volumes automatisch und selbständig erledigt.
Wenn Sie auf eine Datei zugreifen, fordert der Cache Manager diese vom Fileserver an. Nachdem der Server die gewünschte Datei aufgefunden und beim Client abgeliefert hat, speichert der Cache Manager auf der lokalen Platte des Clients eine Kopie dieser Datei. Alle weiteren Zugriffe der Client Workstation erfolgen nun nicht mehr über das Netzwerk auf den Server, sondern nur noch auf die lokale Platte, den sog. Cache.
Bitte beachten Sie: der Cache Manager verwendet eine Kopie der Datei und speichert diese auf der lokalen Festplatte. Alle Veränderungen, die Sie an dieser Datei vornehmen, befinden sich zunächst nur im lokalen Cache und werden nicht auf die zentral gespeicherte Version übertragen. Erst wenn die modifizierte Datei mit close() geschlossen wird, meldet sich der Cache Manager wieder beim Server und veranlaßt, daß die Datei aus dem Cache heraus zum Server übertragen und dort abgespeichert wird.
Sie editieren z.B. mit einem Editor einen Text. Alle Veränderungen, die Sie während Ihrer Sitzung an diesem Text ausführen, werden erst, nachdem Sie das Kommando "speichere Datei" abgegeben haben, zum Fileserver übertragen.
Wird nun eine Datei auf dem Fileserver durch eine veränderte Version ersetzt, dann benachrichtigt AFS alle erreichbaren Clients, daß diese eventuell veraltete Kopien einer Datei in ihren Caches halten. Beim nächsten Zugriff auf die betreffende Datei wird der Cache Manager seine lokale Kopie ignorieren und stattdessen die aktuelle Version vom Server anfordern.
Zu diesem Zweck verfügt AFS über einen Mechanismus, der solche Nachrichten zwischen Server und Client zügig überträgt. Der Fileserver schickt an den Cache Manager zusammen mit der Kopie einer veränderbaren Datei auch einen sog. callback. Dieser callback ist wie ein "Versprechen" des Servers, daß dieser, sobald die zentral gespeicherte Datei verändert werden sollte, den Cache Manager hierüber benachrichtigen wird. Tritt dieser Fall ein, dann "bricht" der Fileserver den callback. Erhält der Cache Manager jetzt eine Anfrage nach dieser Datei, so fällt ihm der "gebrochene" callback auf und er fordert sofort die aktuelle Dateiversion vom Server an.
Falls mehrere Benutzer gleichzeitig ein und dieselbe Datei modifizieren, dann verhält sich AFS genau wie das Standard-UNIX Filesystem: die zuletzt geänderte Version der Datei wird zentral gespeichert. Sollten Sie also mit Kollegen zusammen an den gleichen Dateien arbeiten, dann erscheint es ratsam, daß Sie zuvor Ihre Aktivitäten koordinieren, damit Sie sich nicht gegenseitig wichtige Daten überschreiben.
Die erste AFS Sicherheitsstufe besteht aus der Anforderung eines Kennwortes für den Systemzugang. Gibt der Benutzer das richtige Kennwort an, so erfolgt die Bestätigung durch AFS.
Das funktioniert nach folgendem Prinzip. Der Cache Manager der Client Workstation, auf der die Anmeldung des Benutzers erfolgte, erhält vom Fileserver einen sogenannten Token. Dieser Token ist der Hinweis dafür, daß der Benutzer sich gegenüber AFS erfolgreich autorisieren konnte. Ein Token ist eine Informationseinheit, die von einem bestimmten AFS-Systemprogramm mittels des Benutzerkennwortes verschlüsselt wurde. Der lokale Cache Manager kann nun diesen Token wieder entschlüsseln, da er sowohl das Kennwort des Benutzers, als auch den Verschlüsselungsalgorithmus kennt.
Ist der Cache Manager in der Lage, den zugeteilten Token zu entschlüsseln, so wird der Benutzer damit vom AFS anerkannt: seine Autorisierung ist bestätigt.
Dieser Token ist auch für andere AFS-Fileserver der Beweis für die Autorisierung. Damit ist die Grundlage für die zweite AFS-Sicherheitsstufe gewährleistet, die wechselseitige Bestätigung der Autorisierung. Beide Beteiligten kommunizieren über das Netzwerk miteinander und bestätigen sich gegenseitig ihre Autorisierung. AFS verlangt diese wechselseitige Bestätigung immer dann, wenn ein Server mit einem Client, in den meisten Fällen dem Cache Manager, Informationen austauscht. Dieses zweiseitige Protokoll, von dem AFS intensiv Gebrauch macht, ist so aufgebaut, daß es nur sehr schwierig entschlüsselt werden kann. Sollte also eine fremde Person, sei es absichtlich oder unabsichtlich, die Kommunikation zwischen "Ihrem" Client und dem Fileserver abhören, so kann der- oder diejenige mit den Datenpaketen nicht allzuviel anfangen.
Anhand eines vereinfachten Beispiels soll die Funktionsweise der wechselseitigen Bestätigung verdeutlicht werden:
Wenn der lokale Cache Manager mit einem Fileserver in Verbindung treten will, dann schickt er diesem zunächst den Token des Benutzers. Der Token enthält die verschlüsselte User-ID. Die Art der Verschlüsselung kann nur von einem AFS Fileserver interpretiert werden. Kann der Server den Token entschlüsseln, dann kommunizieren Server und Client miteinander.
Der lokale Cache Manager muß einen gültigen Token besitzen, um mit einem Server in Kontakt treten zu können. Andererseits wird ein Fileserver vom Cache Manager nur dann als authentisch anerkannt, wenn dieser die Information, die der Token überträgt, entschlüsseln und verwenden kann.
Die wechselseitige Bestätigung ist dann erfolgreich verlaufen, wenn der lokale Cache Manager, der den Benutzer repräsentiert, und der Fileserver sich gegenseitig von der Richtigkeit ihrer Identität überzeugt haben.
In Erweiterung des Standard-UNIX stellt AFS dem Benutzer sieben Zugriffsrechte zu Verfügung: Read, Lookup, Insert, Delete, Write, Lock und Administer (abgekürzt mit den Buchstaben rlidwka). Diese lassen sich in zwei Gruppen unterteilen:
Zugriffsrechte für Verzeichnisse
Zugriffsrechte, die sich auf Dateien auswirken
und haben folgende Bedeutung:
Verzeichnisrechte: Lookup (l): Dateien und Unterverzeichnisse des aktuellen Verzeichnisses werden beim Aufruf von ls angezeigt. (Falls der Benutzer für die Unterverzeichnisse nicht das lookup-Recht besitzt, so kann deren Inhalt nicht dargestellt werden).
Die ACL des aktuellen Verzeichnisses kann mit fs la betrachtet werden.
Auf Unterverzeichnisse darf, so es deren ACL erlaubt, zugegriffen werden.
Insert (i) Im aktuellen Unterverzeichnis dürfen Dateien hinzugefügt werden. Dies kann entweder durch Anlegen neuer oder durch Kopieren vorhandener Dateien geschehen.
Es dürfen neue Unterverzeichnisse angelegt werden.
Delete (d): Im aktuellen Verzeichnis dürfen Dateien und Unterverzeichnisse gelöscht werden.
Administer (a): Die ACL des aktuellen Verzeichnisses darf verändert werden. Jeder Benutzer besitzt dieses Recht für sein Home-Verzeichnis (selbst dann, wenn er sich selbst aus seiner acl ausgetragen hat). Dateirechte: Read (r): Alle Dateien im aktuellen Verzeichnis dürfen geöffnet bzw. deren Inhalte gelesen werden.
Write (w): Alle Dateien im aktuellen Verzeichnis dürfen verändert werden.
Lock (k): Alle Dateien im aktuellen Unterverzeichnis dürfen von Programmen mit "flock" gegen gemeinsamen Dateizugriff blockiert werden. Hinweis: Die ACL gilt für ganze Verzeichnisse und nicht für einzelne Dateien. Um die Handhabung dieser vielfältigen Möglichkeiten etwas zu vereinfachen, können Kombinationen mehrerer Rechte durch bestimmte Abkürzungen angesprochen werden. In Anlehnung an die Zugriffsrechte des Standard-UNIX finden folgende Kombinationen Verwendung: write alle Rechte mit Ausnahme von Administer (rlidwk)
read Read und Lookup (rl)
all alle sieben Zugriffsrechte (rlidwka)
none keine Zugriffsrechte, d.h. der betreffende Benutzer wird aus der acl entfernt.
Gruppen sind im AFS den individuellen Benutzern völlig gleichgestellt, d.h. wenn einer Gruppe in der ACL ein bestimmtes Recht eingeräumt wurde, so hat jedes Mitglied dieser Gruppe dasselbe Recht.
Jedes Verzeichnis besitzt seine eigene ACL, die festlegt, welcher Nutzer Zugriff zum Verzeichnis und seinen Dateien hat. Jede ACL kann maximal 20 Nutzer oder Gruppen enthalten.
Benutzer fremder Zellen, die in der lokalen Zelle nicht autorisiert wurden, sind per AFS-Definition Mitglied einer Gruppe namens system:anyuser. Falls bestimmte Dateien der Öffentlichkeit zugänglich gemacht werden sollen, so sollte in der betreffenden ACL diese Gruppe erwähnt werden. Näheres ist unter der Beschreibung des Befehls fs sa nachzulesen.
Alle Benutzer, die gegenüber dem lokalen AFS-Filessystem eine dedizierte Zugriffsberechtigung (Token) haben, werden u.a. in die Gruppe system:authuser eingeordnet.
Die rudimentären Werkzeuge zur Dateibearbeitung wie z.B. cp, rm etc. sind identisch zu denen des Standard-Systems. Auch die meisten Anwendungsprogramme können ohne jegliche Änderung weiterverwendet werden. Einige Punkte sollte aber dennoch beachtet werden.
Beispiel:
cd /afs/rus.uni-stuttgart.de
AFS beachtet von den UNIX mode bits nur die owner bits für den Dateischutz.
befehls_art <befehl> -option <argument>+ [-schalter]
Hierbei gilt folgende Nomenklatur: Eckige Klammern [ ] schließen optionale Parameter ein.
Spitze Klammern < > bezeichnen Informationen, die der Benutzer von Fall zu Fall angeben muß.
Das Pluszeichen + bezeichnet einen Parameter, der mehrfach verwendet werden darf.
Der fett gesetzte Text muß wörtlich eingegeben werden.
Kursiver Text steht für Angaben, die je nach Sachlage variieren.
Beispiel: fs setacl -dir $HOME -acl theoderich all sigismund none -neg
fs ist die befehls_art. In diesem Fall handelt es sich um ein Fileserver Kommando.
setacl ist der eigentliche Befehl, der an einen bestimmten AFS-Prozeß gerichtet ist. Dieser Prozeß wird von der befehls_art bestimmt. Hier soll z.B. die Liste der individuellen Zugriffsrechte für das Home-Verzeichnis ( steht in der Shell-Variablen HOME) festgelegt werden.
-dir $HOME und -acl theoderich all sigismund none stellen die Argumente des Kommandos dar. Bestimmte AFS-Kommandos benötigen ein oder mehrere Argumente. Argumente bestehen aus zwei Teilen: den Optionen und dem eigentlichen Argument. -dir und -acl sind Optionen. Optionen bezeichnen den Typ des folgenden Arguments und werden stets mit einem vorangestellten Minuszeichen (-) angegeben.
$HOME und theoderich all sigismund none sind Argumente, d.h. Informationen, die vom Benutzer je nach Lage des Einzelfalles angegeben werden müssen.
Einige Optionen akzeptieren eine Liste von Argumenten, wie z.B. hier
-acl. Solche Optionen tragen in der Syntaxbeschreibung ein Pluszeichen (+). -neg ist ein Schalter. Solch ein Schalter bestimmt z.B. die Art und Menge des Dialoges mit AFS oder legt die Art und Weise fest, wie der angegebene Befehl ausgeführt werden soll. Schalter werden stets mit einem vorangestellten Minuszeichen (-) angegeben und sind immer optional.
1. das komplette Kommando, so wie es in der Syntaxbeschreibung erklärt wird
2. in einer eindeutigen Abkürzung und
3. in einigen Fällen als Alias.
So kann z.B. listacl in folgenden Formen verwendet werden:
komplettes Kommando: fs listacl
Kurzform: fs lista (oder fs listac)
Alias: fs la
In der folgenden Tabelle finden Sie die Kurzformen bzw. Aliasnamen zu den beschriebenen AFS-Befehlen.
Befehl Alias/Kurzform
fs checkservers fs checks
fs cleanacl fs cl
File fs examine fs exa
Server fs help fs h
Kommandos fs listacl fs la
fs listcells fs listc
fs listquota fs lq
fs quota fs q
fs setacl fs sa
pts adduser pts ad
pts chown pts cho
pts creategroup pts cg
Protection pts delete pts del
Kommandos pts examine pts e
pts help pts h
pts membership pts m
pts removeuser pts r
pts setfields pts setf
Beispiel: fs help
Wird beim help-Aufruf gleich ein Befehl mitangegeben, dann erhalten Sie eine detailierte Beschreibung aller Optionen und Schalter des betreffenden Befehls.
Beispiel: fs help sa
Darüberhinaus ist für viele AFS-Kommandos noch eine manual page vorhanden. Diese kann wie im UNIX üblich mit dem man kommando angesprochen werden.
[-cell <Name einer AFS-Zelle>] [-servers <Liste der anzusprechenden Fileserver>+] [-help]
Beschreibung:
Das Kommando klog autorisiert den Benutzer gegenüber der angegebenen AFS-Zelle und teilt ihm einen Token zu. Sollte der Benutzer bereits einen gültigen Token der angegebenen AFS-Zelle besessen haben, so wird dieser durch den neu zugeteilten ersetzt. Standardmäßig wird ein Token der lokalen Zelle, d.h. der Zelle, zu der auch das Gerät gehört, von welchem das Kommando abgesetzt wurde, dem Benutzer zugeteilt. Das Kommando klog verändert nicht die Benutzerkennung des Standard-UNIX. Während einer einzigen Sitzung kann sich ein Benutzer mittels klog gegenüber mehreren verschiedenen AFS-Zellen autorisieren, wobei er allerding pro Zelle immer nur einen gültigen Token erhalten kann. (Pro Client kann ein Benutzer sich in jeder AFS-Zelle nur unter einer einzigen Benutzerkennung autorisieren) Optionen:
-principal ist die Benutzerkennung, unter der der Benutzer sich gegeüber der AFS-Zelle autorisieren möchte. Wird diese Option nicht angegeben, dann verwendet klog die Benutzerkennung des Standard-UNIX.
-password übergibt das Kennwort des Benutzers gleich beim Kommandoaufruf und unterdrückt die Eingabeaufforderung, mit der klog nach standardmäßig nach dem Kennwort fragt. Diese Option sollte nur in Ausnahmefällen verwendet werden, da das Benutzerkennwort offen, für jeden sichtbar, in der Komandozeile übergeben wird.
-cell gibt diejenige AFS-Zelle an, für die der Benutzer autorisiert werden möchte. Wird diese Option nicht angegeben, dann verwendet klog standardmäßig den Namen der lokalen AFS-Zelle, d.h. der Zelle, zu der der Client gehört, auf dem der Benutzer sich angemeldet hat.
-servers übergibt dem Kommando eine Liste von einem oder mehreren Fileservern, die explizit wegen der Erteilung eines Tokens angesprochen werden sollen. Wird mehr als ein Fileserver aufgeführt, dann wählt das System zufällig einen aus dieser Liste aus und spricht diesen an. Wird diese Option nicht angegeben, so wendet sich klog an die bekannten Fileserver der lokalen AFS-Zelle.
-help gibt eine kurze Anleitung des Kommandos aus.
Beispiele: klog
password: In den meisten Fällen wird klog ohne irgendwelche Optionen oder Argumente angewendet. Der Benutzer wird dann zur Eingabe seines Kennwortes aufgefordert.
klog xy8 -cell united.federation.of.planets
password: Mit diesem Kommando will sich der Benutzer unter der Kennung xy8 in der AFS-Zelle united.federation.of.planets autorisieren.
Beschreibung:
Mit diesem Kommando wird der Cache Manager des AFS Clients, bei dem Sie sich angemeldet haben, dazu veranlaßt, alle Tokens anzuzeigen, die er für Ihre User-ID im Moment zu Verfügung hat. Der Token ist der Nachweis, daß Sie sich gegenüber AFS erfolgreich autorisieren konnten.
Ausgabe:
Das Kommando listet einen Token für jede AFS Zelle, in der Sie sich autorisiert haben, auf. Diese Liste enthält: falls vorhanden, Ihre AFS UID
den Server, für den der Token im Moment Gültigkeit besitzt
das Datum und die Uhrzeit, an dem Ihr Token seine Gültigkeit verlieren wird. Die Zeile "--End of list--" schließt diese Liste ab. Sofern Sie sich bisher nicht in einer AFS Zelle angemeldet haben, wird Tokens nur diese eine Zeile ausgeben.
Beispiele: tokens
Tokens held by the Cache Manager:
[ 1] User's (AFS ID 1034) tokens for afs@urz.uni-heidelberg.de
[Expires Mar 15 12:00]
[ 2] --End of list--
Der Benutzer mit der AFS UID 1034 hat sich erfolgreich in der Zelle urz.uni-heidelberg.de autorisiert und der Cache Manager seines Clients verwaltet den entsprechenden Token.
tokens
Tokens held by the Cache Manager:
[ 1] --End of list--
Der Benutzer hat sich bisher in keiner AFS Zelle angemeldet und damit auch keine Zugriffsrechte auf den AFS-Dateibaum.
Wenn Sie sich in einer AFS-Zelle anmelden wollen, verwenden Sie bitte das Kommando klog.
tokens
Tokens held by the Cache Manager:
[ 1] User's (AFS ID 1076) tokens for afs@urz.uni-heidelberg.de
[>>Expired<<]
[ 2] --End of list--
Der Benutzer mit der UID 1076 hatte sich in der AFS Zelle urz.uni-heidelberg.de erfolgreich autorisieren können, sein Token ist aber nicht mehr gültig. Damit ist er für das System nicht mehr autorisiert und hat keine Zugriffsrechte im AFS-Dateibaum.
Um sich gegenüber AFS erneut zu autorisieren, muß der Benutzer das Kommando klog verwenden.
Beschreibung:
Dieses Kommando veranlaßt den Cache Manager, den angegebenen Token zu verwerfen und damit die Autorisierung gegenüber AFS aufzugeben. Wenn keine AFS-Zelle beim Aufruf angegeben wird, verwirft der Cache Manager alle Tokens, die er momentan für den Benutzer verwaltet.
Beispiele: unlog Ab sofort hat der Benutzer keine gültigen Tokens mehr. Um sich wieder gegenüber dem System zu autorisieren, muß er das Kommando klog benutzen.
unlog united.federation.of.planets transarc.com Der Benutzer gibt die Tokens für die Zellen united.federation.of.planets und transarc.com auf. Falls er noch andere Tokens besitzen sollte, so werden diese von dem Kommando nicht beeinflußt.
kpasswd
kann das Kennwort geändert werden.
Es wird zuerst die Eingabe des bestehenden Kennwortes verlangt. Anschließend wird zur Eingabe des neuen Kennwortes aufgefordert, das durch eine wiederholte Eingabe bestätigt werden muß.
Changing password for username in cell urz.uni-heidelberg.de
Old password: altes Kennwort
New password (RETURN to abort): neues Kennwort
Retype new password: neues Kennwort
Nach der Ausführung dieser Eingaben ist sofort das neue Kennwort auf allen Rechnern gültig, die zu der AFS-Zelle urz.uni-heidelberg.de gehören.
Sie dürfen nicht mehr Daten abspeichern als Ihnen Ihre Quotierung erlaubt. Falls Sie nahe daran sind, Ihr Limit zu überschreiten, kann es vorkommen, daß Sie soeben durchgeführte Änderungen an einer Datei nicht mehr abspeichern können. Andererseits kann es vorkommen, daß Sie eine Datei trotz ausreichender Quotierung nicht abspeichern können, wenn der verfügbare Platz Ihrer Partition aufgebraucht ist.
Überprüfen Sie darum regelmäßig den verfügbaren freien Speicherplatz. Überprüfen Sie ebenfalls Ihr Limit, falls Sie Probleme haben, Dateien abzuspeichern. Sie können die Plattenquotierung prüfen mit Hilfe von drei verschiedenen fs-Kommandos. fs quota listet die prozentuale Nutzung des AFS-Volumes
fs listquota listet die prozentuale Nutzung und den Namen des Volumes
fs examine listet die maximale Größe der Partition und ihre aktuelle Größe
Das Kommando
fs whereis -dir Verzeichnisname
listet den Server, auf dem dieses Verzeichnis abgespeichert ist.
Durch
fs checkservers &
werden im Hintergrund alle definierten Server abgefragt. Die Antwort sieht folgendermaßen aus: All servers are running oder These servers are still down:
aixfile1.urz.uni-heidelberg.de
Mit dem Kommando fs whereis läßt sich ermitteln, ob benötigte Verzeichnisse betroffen sind.
AFS erlaubt es, den Zugriff für jedermann zu gestatten, indem einer Gruppe namens system:anyuser der Zugriff erlaubt wird.
Die möglichen Zugriffsrechte und ihre Bedeutung sind bereits in Kapitel 3.3.2 beschrieben worden.
Die drei vordefinierten Systemgruppen sind: system:anyuser
Diese Gruppe beinhaltet jeden, der auf irgeneine Weise Zugang zu einem Rechner der AFS-Zelle bekommen hat.
system:authuser
Diese Gruppe beinhaltet jeden Benutzer, der sich gegenüber der jeweiligen Zelle authentisiert hat.
system:administrators
In dieser Gruppe befinden sich nur wenige Zugangsberechtigungen, die die Aufgabe haben, AFS zu verwalten bzw. notwendige Datensicherungen durchzuführen. Die automatische Datensicherung am URZ setzt voraus, daß diese Gruppe auf die zu sichernden Verzeichnisse die Leseberechtigung hat. Anderenfalls können keine automatischen Sicherungen durchgeführt werden.
Zusätzlich zu den Systemgruppen kann jeder Benutzer seine eigenen Gruppen definieren und ihnen Rechte zuordnen.
Mit den Zugriffskontrollisten und den Zugriffsgruppen kann jeder Anwender bestimmen, welcher Zugriff auf seine Verzeichnisse erlaubt ist.
Syntax:
fs listacl [-dir <Verzeichnis>+]
Verzeichnis bezeichnet eines oder mehrere durch Leerzeichen getrennte Verzeichnisse. Als Default wird das aktuelle Verzeichnis angenommen.
Die Ausgabe des Kommandos listet die Benutzernamen oder Gruppen und die ihnen zugeordneten Rechte.
Beispiel:
fs la $HOME Access list for /afs/urz.uni-heidelberg.de/usr/efi/xy8 is
Normal Rights:
system:administrators rl
system:anyuser rl
xy8 rlidwka
Syntax:
fs setacl -dir <Verzeichnis>+ -acl <Zugriffseinträge>+
Verzeichnis bezeichnet eines oder mehrere durch Leerzeichen getrennte Verzeichnisse.
Zugriffseinträge paarweise Angabe von Benutzer/Gruppe und Zugriffsrechten, die jeweils durch ein Leerzeichen voneinander getrennt sein müssen.
Jeder Benutzer, der das Administer-Recht (siehe 3.3.2) in einem Verzeichnis besitzt, darf für dieses Verzeichnis Rechte vergeben.
Beispiele:
fs sa $HOME frodo rlidwk
Damit wird dem Benutzer frodo der Schreibzugriff auf das Home-Verzeichnis des Anwenders eingeräumt.
fs sa -dir /u/efi/xy8/pub /u/efi/xy8/common -acl z99 write system:authuser rl
In diesem Beispiel werden gleichzeitig für die beiden Unterverzeichnisse pub und common in dem Verzeichniss /u/efi/xy8 Rechte vergeben. Der Anwender z99 erhält Schreibrechte, die Gruppe system:authuser erhält das Leserecht. Um diese Rechte wahrnehmen zu können, müssen die aufgeführten Benutzer/Gruppen in allen darüberliegenden Verzeichnissen mindestens das Lookup-Recht haben.
Benutzer oder Gruppen, die nicht in der Liste der normalen Rechte erscheinen, haben keinen Zugriff auf das Verzeichnis. Sie können jedoch Zugriff haben durch ihre Zugehörigkeit in einer anderen Gruppe der Liste. Insbesondere gehört jedermann zu der Gruppe system:anyuser.
Die Aufnahme einzelner Benutzer in eine Liste mit negativen Rechten stellt sicher, daß diese keinen Zugriff auf dieses Verzeichnis bekommen. Dies ist insbesondere sinnvoll, wenn der Mehrheit einer Gruppe über den Gruppennamen der Zugang gestattet werden soll, einzelne aber ausgeschlossen oder eingeschränkt werden sollen.
Syntax zum Ändern der Liste der normalen Rechte:
fs setacl -dir <Verzeichnis>+ -acl <Name> none <Zugriffseinträge>+
Verzeichnis bezeichnet eines oder mehrere durch Leerzeichen getrennte Verzeichnisse.
Name none bezeichnet den Eintrag (Gruppe oder Benutzer), dessen Rechte entfernt werden sollen.
Zugriffseinträge paarweise Angabe von Benutzer/Gruppe und Zugriffsrechten, die jeweils durch ein Leerzeichen voneinander getrennt sein müssen.
Es ist möglich, gleichzeitig Rechte zu entfernen und einzutragen.
Beispiele:
fs sa -dir $HOME -acl bilbo none
Mit diesem Befehl werden alle Zugriffsrechte, die der Benutzer bilbo in dem Home-Verzeichnis des Anwenders hatte, gelöscht.
fs sa $HOME sam none gimli read
Mit diesem Kommando werden dem Benutzer sam alle Zugriffsrechte entzogen, der Benutzer gimli erhält das Leserecht für das Home-Verzeichnis.
Syntax zum Setzen negativer Rechte:
fs setacl -negative -dir <Verzeichnis>+ -acl <Zugriffseinträge>+
Verzeichnis bezeichnet eines oder mehrere durch Leerzeichen getrennte Verzeichnisse.
Zugriffseinträge paarweise Angabe von Benutzer/Gruppe und Zugriffsrechten, die jeweils durch ein Leerzeichen voneinander getrennt sein müssen.
-negative spricht die Liste negativer Rechte an
Die standardmäßigen Filesysteme von UNIX basieren auf neun Mode-Bits die zu jeder Datei gehören. AFS benutzt nur die ersten drei, d.h. die anderen Mode-Bits (für group und other) sind bedeutungslos.
Jeder Anwender kann nur eine beschränkte Anzahl von Gruppen anlegen. Am Rechenzentrum der Universität Heidelberg ist diese sogenannte "group quota" auf 20 Gruppen eingestellt.
Die meisten Gruppennamen haben zwei Bestandteile, die durch einen Doppelpunkt getrennt sind. Der Teil vor dem Doppelpunkt sollte einen Bezug zu dem Eigentümer darstellen, der zweite Teil ist der eigentliche Gruppenname.
Die maximale Gesamtlänge eines Gruppennames beträgt 63 Zeichen.
Syntax:
pts creategroup -name <username:group-name>+ [-owner <owner>]
username:group-name Als username muß die eigene Benutzerkennung gewählt werden. Für den Gruppennamen empfiehlt sich ein beschreibender Name, der den Zweck dieser Gruppe erkennen läßt.
owner Falls ein anderer als der Ersteller einer Gruppe der Eigentümer sein soll, so kann er hier angegeben werden.
Syntax:
pts adduser -user <Name>+ -group <Gruppenname>+
Name gibt die Benutzerkennung der Personen an, die der Gruppe hinzugefügt werden sollen.
Gruppenname ist eine Liste von Gruppennamen, denen die erwähnten Benutzerkennungen hinzugefügt werden sollen.
In der Regel kann nur der Eigentümer neue Gruppenmitglieder hinzufügen. Es besteht allerdings die Möglichkeit, mit dem Kommando pts setfields dies auch allen Gruppenmitglieder oder gar allen autorisierten Benutzern zu erlauben.
Syntax:
pts removeuser -user <Name>+ -group <Gruppenname>+
Name gibt die Benutzerkennung der Personen an, die aus der Gruppe entfernt werden sollen.
Gruppenname ist eine Liste von Gruppennamen, aus denen die erwähnten Benutzerkennungen entfernt werden sollen.
In der Regel kann nur der Eigentümer Gruppenmitglieder entfernen. Es besteht allerdings die Möglichkeit, mit dem Kommando pts setfields dies auch allen Gruppenmitglieder oder gar allen autorisierten Benutzern zu erlauben.
Es ist möglich, eigene Gruppen zu erzeugen, ohne die Mitglieder einer solche Gruppe davon zu informieren. Die Existenz einer Gruppe läßt sich nicht geheim halten, weil jeder Zugriffsberechtigte mit dem Kommando fs la sich alle Rechte auf ein Verzeichnis anzeigen lassen kann.
Existierende Gruppen können auch von anderen als dem Eigentümer in deren ACL verwendet werden. Allerdings bestimmt ausschließlich der Gruppeneigentümer über die Gruppenmitgliedschaft. So kann es unbeabsichtigt dazu kommen, daß neue Benutzer unerwartet Zugriff auf eigene Verzeichnisse bekommen.
die Mitglieder einer Gruppe (pts membership)
wer darf Gruppeninformation listen ? (pts examine)
wer ist der Eigentümer einer Gruppe ? (pts examine)
wer erstellte die Gruppe ? (pts examine)
welche Gruppe ist Eigentümer dieser Gruppe? (pts listowned)
Mit dem Kommando pts membership erhält man eine Liste aller Benutzerkennungen einer Gruppe. Der Eigentümer einer Gruppe kann jedoch die Anwendung dieser Möglichkeiten mit dem Kommando pts setfields einschränken.
Syntax:
pts membership [-name <Gruppenname>+] [-id <id>+]
Gruppenname Name der zu listenden Gruppe
id Die von AFS verwendete Gruppennummer
Mit dem Kommando pts examine wird Information ausgegeben über den Eigentümer, Ersteller und Rechten gegenüber dieser Gruppe.
Syntax:
pts examine [-name <Gruppenname>+] [-id <id>+]
Gruppenname Name der zu listenden Gruppe
id Die von AFS verwendete Gruppennummer
Folgendes Kommando erstellt eine Liste der Gruppen für die die angegebene Gruppe Eigentümer ist.
Syntax:
pts listowned [-name <Gruppenname>+] [-id <id>+]
Gruppenname Name der zu listenden Gruppe
id Die von AFS verwendete Gruppennummer
1. Anschluß der Workstation an das Datennetz prüfen.
2. Überprüfen der eigenen Zugriffsrechte mit dem Kommando tokens. Falls keine Zugriffsrechte bestehen sollten, das Kommando klog verwenden.
3. Überprüfen der Zugriffsrechte mit dem Kommando fs la.
4. Mit dem Kommando fs checkservers überprüfen, ob alle Fileserver verfügbar sind.
5. Überprüfen mit dem Kommando fs whereis, auf welchem Fileserver sich das Verzeichnis befindet.
Weitere Hinweise zur Fehlerdiagnose können dem AFS User's Guide Kapitel 14 entnommen werden. Diese Broschüre ist in der Beratung einzusehen.