Anleitung für Administratoren - web server

InstantAFS und AFS
Anleitung für Administratoren
(Version 1.2)
Frank Burkhardt
Max–Planck–Institut für
Kognitions- und Neurowissenschaften ∗
10. April 2007
∗ http://instantafs.cbs.mpg.de

Inhaltsverzeichnis
1 Einleitung 12
1.1 Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Vorraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Was ist/macht InstantAFS für mich? . . . . . . . . . . . . . . . 13
1.4 Ziele von InstantAFS . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Technische Grundlagen 16
2.1 AFS in wenigen Worten . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Besonderheiten von AFS . . . . . . . . . . . . . . . . . . . . . 16
2.3 Festlegungen und Einschränkungen . . . . . . . . . . . . . . . 18
2.4 Anders als unter UNIX . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Grundlegendes zu Volumes . . . . . . . . . . . . . . . . . . . . 21
2.7 AFS-Kommunikation oberhalb Layer 4 . . . . . . . . . . . . . 22
2.7.1 AFS-Clients . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.2 Datenbankserver . . . . . . . . . . . . . . . . . . . . . 23
2.7.3 AFS-Kommando-Familien . . . . . . . . . . . . . . . . 23
2.7.4 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.5 Anderes . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 Authentifikation, Autorisation, Sicherheit . . . . . . . . . . . . 24
2.9 Wo werden Daten über die Benutzer gespeichert? . . . . . . . . 25
2.10 Ablauf eines Filezugriffs auf das AFS . . . . . . . . . . . . . . 25
2.11 DOs and DON’Ts . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Technische Details zu AFS 27
2
3.1 Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 RW-Volumes (RW-Instanzen) . . . . . . . . . . . . . . 27
3.1.2 RO-Volumes (RO-Instanzen) . . . . . . . . . . . . . . . 27
3.1.3 Backup-Volumes (Backup-Instanzen) . . . . . . . . . . 29
3.1.4 Differenzielle Speicherung . . . . . . . . . . . . . . . . 29
3.1.5 Temporäre differentiell gespeicherte Instanzen . . . . . 30
3.1.6 Zusätzliche differenziell gespeicherte Instanzen . . . . . 31

3.1.7 Verschieben von Volumes im Produktionsbetrieb . . . . 31
3.2 Volume-Mountpoints . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.1 Arten . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Dynamische Mountpoints . . . . . . . . . . . . . . . . 34
3.2.3 Punkt oder nicht Punkt... . . . . . . . . . . . . . . . . . 34
3.2.4 Wie werden Mountpoints gespeichert? . . . . . . . . . . 34
3.3 Die AFS-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 Grundlegendes . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2 Synchronisation der DB-Server . . . . . . . . . . . . . 36
3.3.3 Benötigte Prozesse auf den DB-Server-Maschinen . . . 37
3.4 Die Zelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.1 Organellen . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.2 Das zentrale Zellenverzeichnis . . . . . . . . . . . . . . 38
3.5 Der Cachemanager (AFS-Client) . . . . . . . . . . . . . . . . . 39
3.5.1 Der Client-Cache . . . . . . . . . . . . . . . . . . . . . 39
3.5.2 Kenngrößen des Caches . . . . . . . . . . . . . . . . . 39
3.5.3 Verwaltung von Daten im Cache . . . . . . . . . . . . . 41
3.5.4 Cache-Kohärenz . . . . . . . . . . . . . . . . . . . . . 42
3.5.5 Sicherheitshinweise . . . . . . . . . . . . . . . . . . . . 42
3.5.6 Konfigurationsoptionen . . . . . . . . . . . . . . . . . . 43
3.6 Das AFS-Netzwerkprotokoll (Layer 3 und 4) . . . . . . . . . . 44
3.6.1 Server/Clients mit mehreren IP-Adressen/Netzwerkkarten 45
3.7 Das Sicherheitsmodell . . . . . . . . . . . . . . . . . . . . . . 47
3.7.1 Der AFS-Key . . . . . . . . . . . . . . . . . . . . . . . 47
3.7.2 Authentifikation . . . . . . . . . . . . . . . . . . . . . 47
3.7.3 Autorisation . . . . . . . . . . . . . . . . . . . . . . . 51
3.7.4 Sicherheitshinweise . . . . . . . . . . . . . . . . . . . . 54
3.7.5 Der AFS-Superuser . . . . . . . . . . . . . . . . . . . . 54
3.8 Fileserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.8.1 AFS-Volumes sind keine Shares oder Exports . . . . . . 57
3.8.2 Die OpenAFS-Fileservertypen . . . . . . . . . . . . . . 57
3.8.3 Wirtspartitionen . . . . . . . . . . . . . . . . . . . . . 59
3.8.4 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.9 Der bos-Server . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.9.1 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.9.2 Authentifikation . . . . . . . . . . . . . . . . . . . . . 60
3.10 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3

3.10.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.10.2 Der Principal . . . . . . . . . . . . . . . . . . . . . . . 62
3.10.3 Keytabs . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.10.4 Kerberos und AFS . . . . . . . . . . . . . . . . . . . . 64
3.10.5 Server-Komponenten . . . . . . . . . . . . . . . . . . . 64
3.10.6 Synchronisation . . . . . . . . . . . . . . . . . . . . . 64
3.10.7 Gültigkeitsdauer von Tickets . . . . . . . . . . . . . . . 65
4 Einrichtung einer AFS-Zelle 66
4
4.1 Vorüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.1.1 Standorte . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.1.2 Serverprozesse . . . . . . . . . . . . . . . . . . . . . . 66
4.2 InstantAFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.1 Voraussetzungen, Prinzipien . . . . . . . . . . . . . . . 67
4.2.2 Woher bekommt man die benötigten Pakete . . . . . . . 68
4.2.3 Obligatorische Serverpakete . . . . . . . . . . . . . . . 68
4.2.4 Obligatorische Clientpakete . . . . . . . . . . . . . . . 69
4.3 Ablauf einer InstantAFS-Installation . . . . . . . . . . . . . . . 69
4.3.1 Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.2 Allgemeine Informationen zum Ablauf . . . . . . . . . 70
4.3.3 Definieren von Rechnern (hosts) . . . . . . . . . . . . . 71
4.3.4 Auswahl der DNS-Server (dns) . . . . . . . . . . . . . 73
4.3.5 Zeitserver-Auswahl (timeservers) . . . . . . . . . . . . 74
4.3.6 Auswahl der AFS-DB-Server (dbservers) . . . . . . . . 74
4.3.7 Auswahl der AFS-Fileserver (fsservers) . . . . . . . . . 75
4.3.8 Auswahl eines Samba-Gateways (smbgateway) . . . . . 75
4.3.9 SSH-Schlüssel für Datenbankupdates (ssh-keys) . . . . . 75
4.3.10 Aufräumen vor der Installation (cleanup) . . . . . . . . 76
4.3.11 Überprüfen der Konfiguration (check) . . . . . . . . . . 76
4.3.12 Setup der DNS-Server (dns-servers) . . . . . . . . . . . 76
4.3.13 Setup der DNS-Clients (dns-clients) . . . . . . . . . . . 76
4.3.14 Setup der Zeitserver (ntp-servers) . . . . . . . . . . . . 76
4.3.15 Setup der NTP-Clients (ntp-clients) . . . . . . . . . . . 76
4.3.16 Setup der Kerberos-Server (krb5-servers) . . . . . . . . 77
4.3.17 Erzeugen der Service-Keytabs (keytabs) . . . . . . . . . 77
4.3.18 Initialisieren der AFS-Server (afs-init) . . . . . . . . . . 77
4.3.19 Initialisierung der AFS-Datenbank (afs-db) . . . . . . . 77
4.3.20 Setup des ersten Fileservers (afs-fs1) . . . . . . . . . . . 77

4.3.21 Start der restlichen Fileserver (afs-fs2) . . . . . . . . . . 77
4.3.22 Setup des Samba-Gateways (samba-server) . . . . . . . 77
4.3.23 Setup der acall-Server (acall) . . . . . . . . . . . . . . 77
4.3.24 Abschließendes . . . . . . . . . . . . . . . . . . . . . . 78
4.3.25 Ein kleiner Test... . . . . . . . . . . . . . . . . . . . . . 78
4.4 Ablauf einer manuellen Grundinstallation . . . . . . . . . . . . 79
4.4.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4.2 Client-Konfiguration . . . . . . . . . . . . . . . . . . . 83
4.4.3 Zeitserver . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4.4 Die Kerberos-Server . . . . . . . . . . . . . . . . . . . 86
4.4.5 Der erste AFS-DB-Server . . . . . . . . . . . . . . . . 89
4.4.6 Der erste Fileserver . . . . . . . . . . . . . . . . . . . . 91
4.4.7 Start der AFS-Clients . . . . . . . . . . . . . . . . . . . 94
4.4.8 Das Samba-Gateway . . . . . . . . . . . . . . . . . . . 96
5 Backups und Ausfallsicherheit 98
5.1 Welche Server für welche Volumes? . . . . . . . . . . . . . . . 98
5.1.1 RO-Daten . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.2 RW-Daten . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.3 Gekoppelte Server . . . . . . . . . . . . . . . . . . . . 99
5.2 Das AFS-Backup-System . . . . . . . . . . . . . . . . . . . . . 100
5.2.1 Prinzipielles zu AFS-Backups . . . . . . . . . . . . . . 100
5.2.2 Welche Instanzen sollte man zum Sichern verwenden? . 101
5.2.3 Ablauf unter InstantAFS . . . . . . . . . . . . . . . . . 101
5.3 Etwas Theorie zum InstantAFS-Backup . . . . . . . . . . . . . 107
5.3.1 Kategorisierung von Dumps durch instantafs.vtapes . . . 107
5.4 Backup “light” - die erste . . . . . . . . . . . . . . . . . . . . . 108
5.5 Backup “light” - die zweite . . . . . . . . . . . . . . . . . . . . 109
5.5.1 Backup light mit Shadow-Instanzen . . . . . . . . . . . 110
5.6 Backup für Daten ausserhalb des AFS . . . . . . . . . . . . . . 110
5.7 Wiederherstellen zerstörter RW-Instanzen . . . . . . . . . . . . 111
5.7.1 ... aus einer RO-Instanz . . . . . . . . . . . . . . . . . . 111
5.7.2 ... aus dem AFS-Backup-System . . . . . . . . . . . . . 112
5.7.3 ... aus Volume-Dumps . . . . . . . . . . . . . . . . . . 113
5

6 Tägliche Arbeit mit AFS 114
6
6.1 Manuelles Anlegen neuer Benutzer . . . . . . . . . . . . . . . . 114
6.2 Ändern der Maximalgröße (Quota) eines Volumes . . . . . . . . 115
6.2.1 Setzen der Quota als Superuser . . . . . . . . . . . . . . 115
6.2.2 Setzen der Quota durch Benutzer . . . . . . . . . . . . 115
6.3 Anlegen eines Volumes . . . . . . . . . . . . . . . . . . . . . . 116
6.3.1 Anlegen eines Volumes durch den Superuser . . . . . . 116
6.3.2 Anlegen eines Volumes durch einen normalen Benutzer . 117
6.4 Hinzufügen eines Fileservers . . . . . . . . . . . . . . . . . . . 118
6.5 Datenbankserver hinzufügen, entfernen oder wechseln . . . . . 118
6.5.1 Rechner und deren Sonderwünsche . . . . . . . . . . . 118
6.5.2 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.6 Ändern von Verzeichnisrechten im AFS . . . . . . . . . . . . . 120
6.7 Arbeiten mit AFS-Gruppen . . . . . . . . . . . . . . . . . . . . 121
6.8 Löschen eines Volumes oder einer Volume-Instanz . . . . . . . 122
6.8.1 ... wenn’s keine Unregelmäßigkeiten gibt . . . . . . . . 122
6.8.2 ... das der VLDB unbekannt ist . . . . . . . . . . . . . . 123
6.8.3 ... das sich auch nach mehreren Versuchen nicht Löschen
läßt . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.8.4 ... aus der VLDB . . . . . . . . . . . . . . . . . . . . . 123
6.9 Verschieben eines Volumes . . . . . . . . . . . . . . . . . . . . 123
6.10 Einholen von Informationen... . . . . . . . . . . . . . . . . . . 124
6.10.1 ... über Server . . . . . . . . . . . . . . . . . . . . . . . 124
6.10.2 ... über Volumes . . . . . . . . . . . . . . . . . . . . . 127
6.10.3 ... über den Client . . . . . . . . . . . . . . . . . . . . . 130
6.10.4 ... über Verzeichnisse/Dateien . . . . . . . . . . . . . . 130
6.10.5 ... über die Zelle . . . . . . . . . . . . . . . . . . . . . 130
6.11 Load-Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.11.1 RO-Daten . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.11.2 RW-Daten . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.12 Server-Ranks definieren . . . . . . . . . . . . . . . . . . . . . . 136
6.13 Sperren auf Volume-Ebene . . . . . . . . . . . . . . . . . . . . 137
6.13.1 Gesperrte Volumes . . . . . . . . . . . . . . . . . . . . 137
6.13.2 “Beschäftigte” Instanzen . . . . . . . . . . . . . . . . . 137
6.13.3 Offline-Instanzen . . . . . . . . . . . . . . . . . . . . . 139

7 Rezepte 140
7.1 Eine Beispiel-Zelle . . . . . . . . . . . . . . . . . . . . . . . . 140
7.1.1 Verzeichnisstruktur . . . . . . . . . . . . . . . . . . . . 140
7.1.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.2 Administrationsarme Backups . . . . . . . . . . . . . . . . . . 141
7.3 Sicher und Bequem - SSH ohne Passwort . . . . . . . . . . . . 142
7.3.1 Einloggen per SSH mit Public-Key . . . . . . . . . . . 142
7.3.2 Single-Sign-On mit Kerberos5 . . . . . . . . . . . . . . 143
7.4 Wie kommt ein kerberosifizierter Dienst zu seinem Schlüssel? . 145
7.5 Aufsetzen eines unspezialisierten AFS-Servers . . . . . . . . . 146
7.6 Erhöhte Privilegien für einfache Benutzer . . . . . . . . . . . . 148
7.6.1 Das Problem . . . . . . . . . . . . . . . . . . . . . . . 148
7.6.2 Das Prinzip . . . . . . . . . . . . . . . . . . . . . . . . 149
7.6.3 Der Ablauf eines acall-RPCs . . . . . . . . . . . . . . . 150
7.6.4 Einrichten eines acall-Servers . . . . . . . . . . . . . . 151
7.7 Dienste AFS-tauglich machen . . . . . . . . . . . . . . . . . . 152
7.7.1 Rechner-basierte Authentifikation . . . . . . . . . . . . 152
7.7.2 Tokens für Dienste . . . . . . . . . . . . . . . . . . . . 153
7.7.3 Weiterleiten von Authentifikationsinformationen der Nutzer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.7.4 Lokal gespeicherte Benutzer-Keytabs . . . . . . . . . . 154
7.8 Homedirectories im AFS . . . . . . . . . . . . . . . . . . . . . 154
7.9 Benutzerverwaltung unter InstantAFS . . . . . . . . . . . . . . 155
7.10 Praktische Anwendung der Volume-Replikation . . . . . . . . . 158
7.11 Ein Projekt aus mehreren Volumes . . . . . . . . . . . . . . . . 159
7.11.1 Wie wird ein Projekt prinzipiell aufgebaut? . . . . . . . 159
7.11.2 Konkretes Beispiel: Vorüberlegungen . . . . . . . . . . 160
7.11.3 Vorbereitung durch den Administrator . . . . . . . . . . 160
7.11.4 Backups . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.11.5 Acall-Einstellungen . . . . . . . . . . . . . . . . . . . . 162
7.11.6 Komfort . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.11.7 Tägliche Arbeit mit dem Projekt . . . . . . . . . . . . . 163
7.12 Ein Debian-Server für Instantafs . . . . . . . . . . . . . . . . . 164
7.13 Automatische Client-Installation mit instantafs-customclient . . 165
7.14 Schutz des AFS-Keys mit Echtzeitverschlüsselung . . . . . . . 166
7.14.1 InstantAFS neu paketieren . . . . . . . . . . . . . . . . 168
7.15 Daten über die Zelle zentral sammeln . . . . . . . . . . . . . . 169
7.15.1 Punkt oder nicht . . . . . . . . . . . . . . . . . . . . . 169
7

7.16 Schnelles Kopieren eines Volumes . . . . . . . . . . . . . . . . 170
7.17 Eine komplette AFS-Partition mit allen Volume-Instanzen verschieben
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
7.17.1 AFS-Boardmittel . . . . . . . . . . . . . . . . . . . . . 170
7.17.2 Speichersubsystem umbauen . . . . . . . . . . . . . . . 170
7.17.3 Manuelles Kopieren auf Dateiebene . . . . . . . . . . . 171
7.18 AFS schneller machen . . . . . . . . . . . . . . . . . . . . . . 172
7.18.1 Fileserver . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.19 AFS-Clients finden . . . . . . . . . . . . . . . . . . . . . . . . 172
8 Problembehebung 173
8
8.1 Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.2 Fehler mit tokenmgr, kinit oder aklog . . . . . . . . . . . . . . 173
8.2.1 aklog: Request is a replay while getting AFS tickets . . 173
8.3 vos, pts oder bos liefern Fehlermeldungen . . . . . . . . . . . . 174
8.3.1 u: no quorum elected . . . . . . . . . . . . . . . . . . . 174
8.3.2 u: not synchronization site (should work on sync site) . . 174
8.3.3 vsu_ClientInit: Could not get afs tokens, running unauthenticated.
. . . . . . . . . . . . . . . . . . . . . . . 174
8.3.4 bos: failed to [...] (you are not authorized for this operation)
. . . . . . . . . . . . . . . . . . . . . . . . . . . 175
8.3.5 libprot: no such entry Could not get afs tokens, running
unauthenticated. . . . . . . . . . . . . . . . . . . . . . 175
8.3.6 pts: Permission denied [...] . . . . . . . . . . . . . . . . 175
8.3.7 VLDB: no permission access for call . . . . . . . . . . 175
8.3.8 Failed to move data for the volume [...] . . . . . . . . . 175
8.3.9 Could not remove server [...] from the VLDB . . . . . . 176
8.4 Probleme im AFS-Dateisystem (AFS-Client) . . . . . . . . . . 176
8.4.1 Zu viele AFS-Dateien sind auf einer Maschine geöffnet . 176
8.4.2 In einem Verzeichnis lassen sich keine weiteren Dateien
anlegen. . . . . . . . . . . . . . . . . . . . . . . . . . . 176
8.4.3 Clientseitig ist kein Zugriff auf /afs möglich . . . . . . . 176
8.4.4 ”Read-only file system”-Fehler beim Schreiben . . . . . 178
8.4.5 In einem Verzeichnis haben alle Dateien unerwarteterweise
die Größe 0 . . . . . . . . . . . . . . . . . . . . . 178
8.4.6 Der MacOSX-AFS-Client stürzt beim Versuch ab, ein
.dmg-file zu mounten . . . . . . . . . . . . . . . . . . . 179
8.5 Fileserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.5.1 Ein Fileserver generiert undefinierte Fehler . . . . . . . 179

8.5.2 Ein Fileserver ist ausgefallen, die /vicep-Partitionen jedoch
intakt . . . . . . . . . . . . . . . . . . . . . . . . 179
8.5.3 Ein Fileserver wurde komplett zerstört . . . . . . . . . . 180
8.5.4 Eine Volume-Instanz auf einem Server bleibt offline . . 181
8.5.5 Eine Volume-Instanz auf einem Server ist löschresistent 182
8.5.6 Eine Partition auf einem Fileserver ist voll, nichts geht
mehr . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
8.5.7 Volume-Instanzen names bogus.XXX tauchen auf Fileservern
auf . . . . . . . . . . . . . . . . . . . . . . . . 183
8.6 Ein Fileserver registriert sich mit zu vielen (evtl. falschen) IP-
Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.7 Datenbankserver . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.7.1 Es ist überhaupt kein Zugriff auf die AFS-Datenbank
möglich . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.7.2 Schreibzugriffe sind nicht möglich . . . . . . . . . . . . 185
8.7.3 Ein Volume läßt sich nicht aus der Datenbank löschen . 185
8.8 Backup-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . 186
8.8.1 Der Speicher auf dem Backup-Server ist voll, das Backup
läuft noch . . . . . . . . . . . . . . . . . . . . . . . . . 186
8.9 acall-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.9.1 mk_req error: No credentials cache found . . . . . . . . 187
8.9.2 E: acall(): Kerberos error in get_server_rcache(): Permission
denied in replay cache code . . . . . . . . . . . 187
8.9.3 E: Not authorized. . . . . . . . . . . . . . . . . . . . . 187
8.9.4 mk_req error: Server not found in Kerberos database . . 188
8.9.5 Der acall-Aufruf blockiert für immer . . . . . . . . . . 188
8.10 Andere Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.10.1 In einer SSH-Shell ist der Zugriff auf das AFS nicht
möglich . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.11 Localhost und die Hostnamensauflösung . . . . . . . . . . . . . 190
8.11.1 /etc/hosts säubern . . . . . . . . . . . . . . . . . . . . . 190
8.11.2 Schadensbeseitigung . . . . . . . . . . . . . . . . . . . 191
9 AFS- Kerberos- und InstantAFS-Kommandos 192
9.1 AFS-Kommandos . . . . . . . . . . . . . . . . . . . . . . . . . 192
9.1.1 Arbeiten an AFS-Serverprozessen . . . . . . . . . . . . 192
9.2 InstantAFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.2.1 instantafs.acall (Kurzform: acall) . . . . . . . . . . . . 194
9.2.2 instantafs.acall-backup (Kurzform: ia:backup) . . . . . . 194
9.2.3 instantafs.acall-helloworld (Kurzform: ia:helloworld) . . 194
9

9.2.4 instantafs.acall-release (Kurzform: ia:release) . . . . . . 195
9.2.5 instantafs.acall-setquota . . . . . . . . . . . . . . . . . 195
9.2.6 instantafs.acall-usermgr (Kurzform: ia:usermgr) . . . . . 195
9.2.7 instantafs.acall-volcreate (Kurzform: ia:volcreate) . . . . 195
9.2.8 instantafs.achmod (Kurzform: achmod) . . . . . . . . . 196
9.2.9 instantafs.afsdir . . . . . . . . . . . . . . . . . . . . . . 197
9.2.10 instantafs.backup . . . . . . . . . . . . . . . . . . . . . 197
9.2.11 instantafs.bind-update . . . . . . . . . . . . . . . . . . 197
9.2.12 instantafs.calcrestore . . . . . . . . . . . . . . . . . . . 197
9.2.13 instantafs.cellcheck . . . . . . . . . . . . . . . . . . . . 200
9.2.14 instantafs.servercheck . . . . . . . . . . . . . . . . . . 200
9.2.15 instantafs.getvoldirs . . . . . . . . . . . . . . . . . . . 201
9.2.16 instantafs.homedir . . . . . . . . . . . . . . . . . . . . 201
9.2.17 instantafs.kcheckpass . . . . . . . . . . . . . . . . . . . 201
9.2.18 instantafs.kerberos . . . . . . . . . . . . . . . . . . . . 201
9.2.19 instantafs.release (Kurzform: iarel) . . . . . . . . . . . 202
9.2.20 instantafs.remote . . . . . . . . . . . . . . . . . . . . . 202
9.2.21 instantafs.setquota . . . . . . . . . . . . . . . . . . . . 203
9.2.22 instantafs.setup . . . . . . . . . . . . . . . . . . . . . . 203
9.2.23 instantafs.tokenmgr . . . . . . . . . . . . . . . . . . . . 203
9.2.24 instantafs.tool (Kurzform: iat) . . . . . . . . . . . . . . 203
9.2.25 instantafs.usermgr . . . . . . . . . . . . . . . . . . . . 204
9.2.26 instantafs.volgrep (Kurzform: volgrep) . . . . . . . . . 204
9.2.27 instantafs.vsserver . . . . . . . . . . . . . . . . . . . . 205
9.2.28 instantafs.vtapes . . . . . . . . . . . . . . . . . . . . . 206
9.3 Wichtige AFS-bezogene Kommandos . . . . . . . . . . . . . . 206
10 Andere Betriebssysteme und Plattformen 209
10
10.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
10.1.1 Allgemeines zu 32bit-Windows . . . . . . . . . . . . . 209
10.1.2 Allgemeines zu NT-basierten Windows-Versionen . . . 209
10.1.3 Windows 3.11 . . . . . . . . . . . . . . . . . . . . . . 210
10.1.4 Windows 95, 98, ME . . . . . . . . . . . . . . . . . . . 210
10.1.5 Windows NT 4.0 . . . . . . . . . . . . . . . . . . . . . 210
10.1.6 Windows 2000, XP . . . . . . . . . . . . . . . . . . . . 210
10.1.7 Windows XP 64bit . . . . . . . . . . . . . . . . . . . . 214
10.1.8 Windows Vista . . . . . . . . . . . . . . . . . . . . . . 214
10.2 andere Linux-Distributionen . . . . . . . . . . . . . . . . . . . 214

10.3 Fedora Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
10.4 andere Unix-Derivate (z.B. MacOSX) . . . . . . . . . . . . . . 215
10.4.1 MacOS X . . . . . . . . . . . . . . . . . . . . . . . . . 215
10.4.2 Irix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
10.4.3 FreeBSD, NetBSD . . . . . . . . . . . . . . . . . . . . 217
10.4.4 OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 217
10.5 andere Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . 217
10.5.1 OS/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Glossar 220
A Anhang 222
Anhang 222
A.1 SSH-Login-Varianten . . . . . . . . . . . . . . . . . . . . . . . 222
A.2 Die PTDB als NSS-Dienst nutzen . . . . . . . . . . . . . . . . 224
A.2.1 Prinzipielle Grenzen . . . . . . . . . . . . . . . . . . . 225
A.3 Simple Regular Expressions . . . . . . . . . . . . . . . . . . . 225
A.4 Namenskonventionen für Volumes . . . . . . . . . . . . . . . . 226
A.5 NAT-geroutete AFS-Clients . . . . . . . . . . . . . . . . . . . . 229
A.6 Ein AFS-zu-SMB-Gateway unter Linux . . . . . . . . . . . . . 230
A.6.1 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . 230
A.6.2 Lösung mit verringerter Sicherheit . . . . . . . . . . . . 231
A.7 Dateinamen und Pfade . . . . . . . . . . . . . . . . . . . . . . 232
A.8 AFS-Schlüssel aus einer laufenden Zelle besorgen . . . . . . . . 235
A.9 Löschen des AFS-Caches eines AFS-Clients . . . . . . . . . . . 235
A.10 Fileserver mit mehreren IP-Adressen im selben logischen Netzwerk
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
11

1 Einleitung
http://instantafs.cbs.mpg.de
1.1 Danksagungen
Dieses Dokument soll dazu dienen, dem geneigten Leser das Netzwerkdateisystem
AFS näherzubringen. Im Rahmen dieser Dokumentation sind keine Vorkenntnisse
zu AFS oder Kerberos nötig, jedoch sollten man grundsätzliche Dinge
über die Administration von Linux und über Netzwerkdateisysteme wissen.
Diese Anleitung richtet sich an (zukünftige) Administratoren von AFS-Zellen.
Mit Schritt-für-Schritt-Anleitungen und zugehörigen Erklärungen wird der
Aufbau und der Betrieb einer AFS-Zelle erläutert. Es sind keine AFS- oder
Kerberos-Vorkenntnisse nötig.
Es existiert auch noch eine Anleitung für normale Benutzer. Beide Dokumente
werden aktiv weiterentwickelt und können unter folgender URL bezogen werden:
Ich möchte mich vor allem bei folgendem Personen bedanken:
Sascha Kiesewetter : der seine privaten Computer in einer AFS-Zelle betreibt und mir dadurch
zahllose Erkenntnisse darüber beschert hat, was an InstantAFS noch besser/benutzerfreundlicher/anders
werden muss/musste. Durch ihn ist die
Unterstützung multipler Zellen in InstantAFS überhaupt erst möglich gewesen.
Dr. Helmut Hayd : der das Geld für dieses Projekt organisiert hat, indem er es auf einzigartige
Weise versteht, Menschen von einer guten Sache zu überzeugen.
Jana Weissfuss : die als meine Freundin viel Geduld aufbringt, während ich an InstantAFS
programmiere und die sich mit AFS auseinandersetzt, damit ich Erfahrungen
einer einfachen Benutzerin in meine Arbeit einfliessen lassen
kann, obwohl sie eigentlich nur Texte schreiben und im Internet surfen
will.
Torsten Zumpf : der diese Anleitung tapfer gebugfixt hat, wo andere an meiner zweifelhaften
Orthographie und meiner hochgradig kreativen Grammatik längst
gescheitert wären.
Norbert Gruener : dem Programmierer der AFS-Perl-Bindings.
Istvan-Tibor Nebel : für die Vorlage zur Windows XP-Installationsanleitung.
Mitarbeitern des MPI/CBS : darunter Dr. Christoph Preul, Dr. Marc Tittgemeyer, Tim Wetzel und Reiner
Hertwig, die InstantAFS täglich benutzen und durch ihr Feedback zur
stetigen Verbesserung beitragen.
1.2 Vorraussetzungen
InstantAFS baut auf der Debian GNU/Linux-Distribution auf - die Homepage
gibt’s unter http://www.debian.org. Benötigt wird mindestens Debian
Sarge 3.1, erfolgreich getestet wurde InstantAFS jedoch auch auf Debian Sid
12

1.3 Was ist/macht InstantAFS für mich? 13
1.3 Was ist/macht InstantAFS für mich?
(Stand 06.07.2006). Es funktioniert auch auf Debian Woody 3.0, jedoch werden
im Rahmen von InstantAFS dann keine 2.6er-Kernel und lediglich OpenAFS
1.2 bereitgestellt.
InstantAFS ist keine AFS-Implementation. Es ist eine Sammlung von ineinandergreifenden
Skripten, Bibliotheken (vor allem Perl-Klassen), Konzepten,
Dokumentationen und Konfigurationsfiles, die zusammengenommen das Aufsetzen
und den Betrieb einer AFS-Zelle stark vereinfachen.
Viele Routineaufgaben werden mittels InstantAFS automatisiert, auf Fehler und
mögliche Fussangeln, die beim Umgang mit AFS auftreten können, wird hingewiesen.
Hier ist eine Liste der InstantAFS-Features:
• Es kommt ausschliesslich freie Software zum Einsatz. Finanziell ist es
also z.B. kein Unterschied, ob man 1 oder 100 Computer InstantAFSifizieren
will.
• Automatische Setup-Routine: Nach Eingabe einiger Parameter (IP-
Adressen, Rollen der beteiligten Rechner, ...) wird eine arbeitsfähige
Zelle aufgesetzt.
• Automatisches Backup: Ein Programmaufruf genügt, um einen Server
einzurichten, der ein Backup auf Platte automatisch durchführt. An zentraler
Stelle definiert eine Konfigurationsdatei, welche Daten (Muster von
Volumes) zu sichern sind.
• Skripte warnen, wenn bestimmte Daten (AFS-Volumes) nicht redundant
genug gespeichert sind. Welche Daten wie redundant gespeichert sein
müssen, ist konfigurierbar.
• Halbautomatische Datenwiederherstellung nach schwerem Servercrash:
Ein komplett zerstörter Fileserver kostet den InstantAFS-Administrator
nur ein müdes Lächeln. Skripte kümmern sich um die manuell getriggerte
und automatisch durchgeführte Ersetzung von defekten Fileservern. Bei
richtig verteilten Daten (siehe InstantAFS-administrations-Anleitung)
kann z.B. der Zustand des Vortages unabhängig von der Datenmenge in
kürzester Zeit (Sekunden!) wiederhergestellt werden.
• Eine InstantAFS-Zelle bringt eine einfache interaktive Benutzerverwaltung
per ncurses gleich mit - kein LDAP-/NIS- oder NIS+-Server ist zu
konfigurieren. Trotzdem ist die Integration in bestehende Benutzermanagement-
Systeme leicht möglich, da alle InstantAFS-Funktionen per Kommandozeile
ausgeführt werden können.
• Das Kerberos-basierte RPC-Konzept acall ermöglicht Funktionsaufrufe
normaler Benutzer auf Servern. Damit ist die kontrollierte Zuweisung von
Privilegien an Benutzer ohne zusätzliche Einträge in den Superuserlisten
von AFS-Servern möglich.
Hinweise:
– Durch dieses Konzept ergibt sich z.B. die Möglichkeit, auf sichere
Weise Volumes durch einfache Benutzer anlegen zu lassen.
– Zahlreiche andere acall-Funktionen (z.B. Setzen von Quotas, Synchronisation
von Volumes, User-Management, ...) werden bereits
mitgeliefert und konfiguriert.

14 1 Einleitung
1.4 Ziele von InstantAFS
1.5 Konventionen
– Neue Funktionen sind leicht in Form von Skripten (vergleichbar
dem CGI bei Webservern) implementierbar.
• Es sind keine selbstdurchzuführenden Dirty Patches nötig - InstantAFS
und alle Komponenten, die nicht per Default in Debian enthalten sind,
werden als Debian-Softwarepakete 1 incl. Quellcode zur Verfügung gestellt.
Ziele des InstantAFS-Projektes sind folgende:
• Der Betrieb einer AFS-Zelle soll soweit wie möglich vereinfacht und automatisiert
werden.
• Das Aufsetzen einer AFS-Zelle soll kinderleicht gemacht werden. Die
Installation ist ohne 2 jegliches AFS- und Kerberos-Knowhow möglich.
Folgende Notation wird in diesem Dokument benutzt:
Formatierung von Beispiel
Dateinamen/Pfadnamen /afs/cbs.mpg.de/user
Shell-Kommando user@host>ls -la
Shell-Kommando als root root@host>reboot
Shell-Kommando als Zellensuperuser admin@afs>vos lock root.cell
Shell-Kommando mit Parametererläuterumg admin@afs>vos lock Volume
Shell-Kommando mit Beispielen ernie@afsclient> echo ∼ernie
Ausgabe eines Shell-Kommandos E: Fehler aufgetreten
Eine Zeile aus einer Datei workgroup = CBS.MPG.DE
Ein Debian-Paket instantafs-client .deb
Eine C-Funktion (i.d.R. Kernel- oder Libc) stat()
Ein Kerberos-Principal (Dienst oder Benutzer) afs@CBS.MPG.DE
Ein AFS-Volume root.cell
Muss in einem Kommando eine Partition angegeben werden, so ist damit
immer die Zeichenkette (i.d.R. nur ein Buchstabe) hinter dem /vicep des Pfadnamens
gemeint, der zu einer bestimmten AFS-Serverpartition führt.
Der Begriff Volume wird im Zusammenhang mit AFS für zwei verschiedene
Dinge verwendet, was in einigen Fällen verwirrend ist. In dieser Dokumentation
wird deshalb für einzelne Kopien eines Volumes (Backup-Volume, RW-Volume,
RO-Volume) der Begriff “Instanz” benutzt.
Die Meldungen der Skripte, die im Zusammenhang mit InstantAFS entwickelt
wurden, enthalten meist vorangestellte Wichtigkeits-Kennzeichen - z.B. “E: ”
in
E: Invalid AFSID/UID.
Diese haben folgende Bedeutungen:
1 Plattform i386
2 Selbstverständlich sollte man sich jenes Knowhow unbedingt aneignen, wenn man eine AFS-
Zelle dauerhaft betreiben will.

1.5 Konventionen 15
Kennzeichen Bedeutung
D Debug - Ein weiterführender Hinweis, der i.d.R. nur im Debug-
Mode des Skriptes angezeigt wird
E Error - Ein schwerer Fehler, der das Skript zum Abbruch zwingt
I Information - Ein Hinweis (kein Fehler)
V Verbose - Ein weiterführender Hinweis, der nur im - -verbose
oder Debug-Mode (2x - -verbose) eines Skriptes angezeigt wird
W Warning - Ein aufgetretener Fehler, der jedoch nur minderschweren
Einfluss auf den weiteren Ablauf hat

2 Technische Grundlagen
2.1 AFS in wenigen Worten
2.2 Besonderheiten von AFS
Das AFS ist ein verteiltes Netzwerkdateisystem, das auf globalen Betrieb
ausgelegt ist. Es ist in Einheiten - genannt Zellen (vergleichbar mit Windows-
Domänen) - eingeteilt, die unabhängig voneinander verwaltet werden. Zu jeder
Zelle gehören Benutzer, ein oder mehrere Datenbankserver, ein oder mehrere
Fileserver, AFS-Client-Computer sowie Volumes. Alle diese Objekte gehören
jeweils zu genau einer AFS-Zelle.
Auf den Fileservern befinden sich jeweils eine oder mehrere Datenpartitionen.
Auf diesen Partitionen liegen Instanzen von Volumes. Welche Instanz wo liegt,
ist zentral in den Datenbankservern verzeichnet.
Volumes lassen sich über Mountpoints mineinander verknüpfen und spannen
dadurch den AFS-Namensraum auf. Ein spezielles Volume wird unter /afs in
das VFS aller AFS-Client-Computer gemountet. Dadurch ist Filesystemzugriff
auf das AFS an allen Clients einheitlich möglich.
Die Authentifikation in einer AFS-Zelle wird (wenn InstantAFS benutzt wird)
durch eine Kerberos5-Realm realisiert, zu der mindestens ein Kerberos-KDC
gehört. Eine Kerberos-Realm kann auch für mehrere AFS-Zellen verantwortlich
sein.
AFS ist ein globales Dateisystem. Es setzt sich aus AFS-Zellen (siehe 3.4, Seite
38) zusammen, von denen jede unabhängig von allen anderen administriert
werden kann. Jeder Computer gehört zu maximal einer Zelle. Der Name einer
Zelle entspricht üblicherweise dem Namen der jeweiligen DNS-Domain,
wobei jedoch hierarchische Strukturen zwischen den Zellen nur scheinbar existieren
1 . Auf Daten im AFS kann man ausschließlich über AFS-Clients, eine
freie Software, die für alle gängigen Betriebssysteme verfügbar ist, zugreifen.
Die Metadaten werden über das AFS-Tool vos bearbeitet.
An dieser Stelle seien die wichtigsten Vorteile von AFS genannt:
• Das klassische AFS lässt sich mit einigen wenigen Kommandofamilien
(bos, fs, pts, vos, backup, kas) komplett steuern (siehe 2.7.3, Seite
23). Durch die Integration von Kerberos5 entfällt der kas-Befehl, jedoch
sind noch einige weitere Befehle nötig (siehe 9.3, Seite 206).
• AFS beherrscht die Replikation auf Volume-Ebene (siehe 2.6, Seite 21).
Die Replikation muss (unabhängig von Zugriffen auf das Dateisystem)
ausgelöst werden - es handelt sich nicht um Echtzeit-Replikation.
• Autorisation von Filesystemzugriffen erfolgt im AFS über ACLs (siehe
3.7.3, Seite 51). Die ACLs müssen auf den Servern nicht auf Filesystemebene,
wie unter UNIX, durchgesetzt werden. Sie werden als Metadaten
“irgendwie” vom Fileserver gespeichert. Auf welche Weise das geschieht,
muss den AFS-Client nicht interessieren.
1 Die Zelle cbs.mpg.de ist vollkommen unabhängig von der Zelle mpg.de, jedoch kann die DNS-
Domain cbs.mpg.de nur dann global erreichbar sein, wenn der Administrator des mpg.de-DNS-
Servers das erlaubt.
16

2.2 Besonderheiten von AFS 17
• Der Administrator braucht sich idealerweise nicht darum zu kümmern,
auf welchem Server welche Daten liegen. Man kann Programme damit
beauftragen, automatisch Daten zwischen Servern zu verschieben - z.B.
für Lastverteilung (siehe 6.11, Seite 132). Werden Daten im laufenden
Betrieb von Server zu Server verschoben, so kann ein Nutzer, der per
AFS-Client darauf zugreift, ohne Ausfälle weiterarbeiten - auch schreibend.
Würde er direkt auf die Partition eines Servers zugreifen, könnte er
das nicht - der Server ändert sich ja im Laufe der Aktion.
• Ein Backup-Konzept ist in AFS bereits integriert. Man braucht dazu auch
nicht unbedingt DLT-Laufwerke oder Bänder - viel Plattenplatz 2 reicht
aus.
• AFS setzt einen Cache auf Clientseite (deshalb wird der AFS-Client auch
Cachemanager genannt) ein (siehe 3.5, Seite 39). Das entlastet die benutzten
Server und spart Bandbreite, was vor allem dann hilfreich ist,
wenn zwischen Client und Server dünne Leitungen liegen.
• AFS benutzt feste UDP-Portnummern, keine Portmapper. Eine Firewall
lässt sich leicht entsprechend konfigurieren (siehe 3.6, Seite 44).
• Reguläre Benutzer können im AFS selbstständig Benutzergruppen bilden
und verwalten (siehe 3.7.3.4, Seite 54).
• Mit AFS werden Daten, auf die hauptsächlich lesend zugegriffen wird
(RO-Daten, z.B. Executables) und Daten, die oft verändert werden (RW-
Daten, z.B. Homedirectories), unterschiedlich behandelt, so dass Lastverteilung
(siehe 6.11, Seite 132) und Ausfallsicherheit (siehe 5.1, Seite 98)
jeweils optimal realisiert sind.
Natürlich gibt es auch einige Schattenseiten:
• Sicherheit kostet Zeit. Da alle Pakete signiert (bei entsprechender Einstellung
auch verschlüsselt) werden, kann AFS prinzipiell nicht so schnell
sein, wie ein unsicher arbeitendes Netzwerkdateisystem (z.B. NFS in der
Grundeinstellung).
• Das Callback-Prinzip (siehe 3.5, Seite 39) macht den Einsatz von AFS-
Clients, die von einem privaten Netzwerk hinter einem Router mit
Network Address Translation auf öffentlich erreichbare Server zugreifen,
schwierig (siehe A.5, Seite 229).
• Der AFS-Client ist nicht für so große Speichermengen ausgelegt, wie sie
heute üblich sind und wirkt deshalb als Flaschenhals.
• Der Linux-AFS-Client benötigt ein Kernelmodul (openafs-modulesxxx
.deb ). Das Kernelmodul ist relativ empfindlich im Bezug auf falsche
Handhabung. Das Start/Stop-Script /etc/init.d/openafs-client des Paketes
openafs-client .deb berücksichtigt solche Eigenheiten.
• Unix-Gruppen mit GIDs im Bereich von 0x7F 00 bis 0xBF 00 sollten 3
nicht benutzt werden, wenn auf AFS-Clients im selben Netz PAGs (siehe
3.7.2.3, Seite 49) zum Einsatz kommen, was sehr wahrscheinlich ist.
• AFS unterstützt keine echten Byte-Range-Locks. Der Windows-Client
simmuliert ab Version 1.4.1rc2 allerdings Byte-Range-Locks und setzt
sie auf File-Locks um.
2 Diese Dokumentation befasst sich ausschließlich mit dem Backup auf Platten.
3 Einem Benutzer ist es u.U. möglich, sie unerlaubt in diese Gruppen einzuschleichen.

18 2 Technische Grundlagen
2.3 Festlegungen und Einschränkungen
• AFS-Fileserver reagieren empfindlich, wenn Wirtspartitionen volllaufen
- vor allem, wenn gerade eine RW-Instanz geklont wird (siehe 3.1.4, Seite
29). InstantAFS bietet Tools, die alle Fileserver überwachen und im
Gefahrenfall Alarm schlagen können (siehe 9.2.13, Seite 200).
• Ein logischer AFS-Server nur zu genau einer Zelle gehören. Virtualisierung
(z.B. per Xen) kann Abhilfe schaffen.
• File-Zugriffe auf Kernel-Ebene auf AFS-Objekte, die nicht anonym benutzbar
sind, funktionieren nicht. Das betrifft z.B. Loop-Mounts unter
Linux oder das Mounten von .dmg-Dateien unter MacOSX.
Es sind einige Programme bekannt, die im Zusammenhang mit AFS Probleme
haben. Unter folgender URL gibt’s dazu Informationen:
http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/
ProgsHateAfs
Folgende Festlegungen werden für InstantAFS - also diese Dokumentation, sowie
die InstantAFS-Libraries und -Skripte getroffen:
• Als AFS-Implementierung wird ausschließlich OpenAFS unterstützt. Es
existieren jedoch weitere AFS-Varianten.
• Zur Authentifikation kommt ausschließlich MIT-Kerberos5 zum Einsatz.
Heimdal-Kerberos sowie Authentifikation per kaserver werden nicht
unterstützt. Es ist prinzipiell auch möglich, andere Kerberos-Versionen zu
benutzen. Die Entscheidung zugunsten von MIT-Kerberos5 fiel, weil es
die zukunftsträchtigste Implementierung ist und weil es bereits offizielle
Debian-Pakete für dessen OpenAFS-Integration gibt.
• Die Namen von Zelle, DNS-Domain und Realm müssen gleich sein, abgesehen
davon, dass die komplett Realm groß, die anderen Namen jedoch
vollständig klein geschrieben werden.
• Als Server werden ausschließlich Linux-Systeme unterstützt. Dabei
wird von Debian GNU/Linux 3.1 Sarge ausgegangen. Auch nachfolgende
Debian-Ditributionen sollten kein Problem darstellen - unter Sid
funktioniert es ebenfalls (Stand 13.10.2005). Clients können trotzdem
unter anderen Betriebssystemen (andere Linux-Distributionen, andere
Unix-Betriebssysteme sowie diverse Windows-Versionen) laufen.
• Es kommen ausschließlich namei-Fileserver zum Einsatz (siehe 3.8.2,
Seite 57).
• Die Kerberos5-Passwörter der Benutzer lassen sich nicht per kpasswd
ändern. Diese Einschränkung ist nötig, um die Synchronisation mit anderen
Datenbanken, die Passwörter speichern, sicherzustellen.
• Clients ermitteln die Liste der Datenbankserver von AFS-Zellen nicht
per CellServDB-File, sondern erhalten die Adressen der AFS-DB-Server
über das DNS.
• Die erstellte Zelle ist nicht automatisch global bekannt - man muß bei
Bedarf selbst dafür sorgen. Dadurch, dass einige Max-Planck-Institute
NAT-Router 4 benutzen und so die Fileserver im jeweiligen Institutsnetz
nicht weltweit erreichbar sind, hatte das keine Priorität.
4 Es ist aufwändig AFS-Server und Clients zu benutzen, die durch NAT-Router getrennt sind.

2.4 Anders als unter UNIX 19
2.4 Anders als unter UNIX
• Pro Backup-Server kommt das InstantAFS-Backup-Konzept nur mit einem
Tape-Controller-Prozess klar. AFS ist jedoch in der Lage mehrere
davon pro Host zu verwalten.
AFS unterscheidet sich in einigen Punkten von den klassischen UNIX-
Filesystemen. Diese sollte man kennen, da es u.U. merkwürdige Effekte bei
Programmen gibt, die sich auf bestimmte Eigenschaften des Filesystems
verlassen, diese aber im AFS nicht bekommen.
AFS benutzt im Gegensatz z.B. zu NFS eine eigene Methode, um Benutzernamen
auf AFS-IDs abzubilden. Die AFSID wird vom AFS ähnlich der UID im
normalen Unix-Dateisystem benutzt, um Dateien ihren Besitzern zuzuordnen.
Die stat()-Funktion liefert innerhalb des AFS-Namensraumes keine UID,
sondern jeweils eine AFSID zurück. Um z.B. mit ls sinnvolle Anzeigen zu erhalten,
müssen die AFSIDs und die UIDs der Clients übereinstimmen. Da AFS
ein globales Filesystem ist, kann das niemals perfekt funktionieren (siehe A.2.1,
Seite 225).
Die AFS-PT-Datenbank (PTDB) enthält die Loginnamen, die AFSID sowie
die Gruppenzugehörigkeiten aller AFS-Nutzer, stellt jedoch keine Informationen
wie Homedirectories oder Login-Shells zur Verfügung. Deshalb müssen
diese aus einer anderen Benutzerdatenbank (z.B. NIS oder LDAP, es geht
aber auch jeder andere NSS-Dienst) bezogen werden. Benutzt man das Paket
libnss-ptdb .deb (siehe A.2, Seite 224) für die Namensauflösung, spart man
diese zusätzliche Datenbank ein und kann auf eine Synchronisation mit der
AFS-Datenbank verzichten.
Die Datenbank des AFS wird durch spezielle Serverprozesse verwaltet und automatisch
auf mehrere Server verteilt. Diese Datenbankserver synchronisieren
sich untereinander, so dass die Datenbank auch bei Netzunterbrechungen nutzbar
bleibt.
AFS bricht mit einigen Prinzipien klassischer Unix-Filesysteme. Hier eine
Übersicht:
• AFS stellt keine Shares/Exports zur Verfügung. Es ist also nicht möglich,
die Wirtspartition der Fileserver einfach mit einem alternativen Netzwerkdateisystem
(NFS,Samba,...) zur Verfügung zu stellen.
Faustregel: Auf Daten im AFS kann nur mit AFS-Tools (OpenAFS-
Client, vos, ...) zugegriffen werden.
Lösung: Server für andere Netzwerkdateisystem-Protokolle wie Samba
(siehe A.6, Seite 230) können auf AFS-Clients laufen und so den
AFS-Namensraum exportieren.
• AFS kennt keine Gerätedateien, Sockets oder Pipes. Braucht man solche
speziellen Objekte, muss man auf symbolische Links zurückgreifen, die
dann auf ein anderes Filesystem zeigen. Das hat z.B.Konsequenzen für
Programme, die im Homedirectory eines AFS-Benutzers solche Objekte
anlegen wollen. Beispiele für solche Programme sind
– kile - der KDE-LaTeX-Editor
– comodo - eine Skript-Entwicklungsumgebung der Firma Active-
State
• ACLs die AFS zur Autorisation von File-Zugriffen benutzt, sind weder
Posix- noch NTFS-kompatibel. Klassische Unix-Modebits werden für

20 2 Technische Grundlagen
2.5 Grenzen
user@host>fs lq Verzeichnisname
AFS- Dateisystemobjekte gespeichert, haben jedoch im AFS besondere
Bedeutungen (siehe 3.7.3.3, Seite 52).
• Autorisiert wird immer auf Verzeichnisebene. Die ACLs sind also
zwangsläufig für alle Dateien in einem Verzeichnis gleich. Die ACLs
werden nach unten vererbt.
• Harte Links auf eine Datei müssen sich unter AFS immer im selben Verzeichnis
befinden. Diese Einschränkung wurde eingeführt, da AFS-ACLs
nicht an Dateien gebunden werden können. Die Zugriffsrechte für eine
Datei mit harten Links in mehreren Verzeichnissen wären andernfalls
u.U. nicht eindeutig.
• Der AFS-Namensraum muss nicht baumförmig sein - er kann Zyklen
enthalten.
• Ein Benutzer definiert sich nicht durch seine UID und die Unix-Gruppen,
in denen er Mitglied ist, sondern durch die im AFS-Token gespeicherte
AFSID und die AFS-Gruppen, deren Zusammensetzung in einer AFS-
Datenbank (PTServer) gespeichert ist 5 .
• Die Benutzung von chown() (z.B. in den Kommandos chown oder
tar) ist im AFS nur für Mitglieder der Gruppe system:administrators
möglich, nicht für lokale Superuser.
• Die Ermittlung des verfügbaren Speicherplatzes auf einem AFS-Fileserver
ist nicht mit der statfs()-Funktion (z.B. von df benutzt) möglich.
Stattdessen muss das Kommando
benutzt werden, um den freien Speicher in einem bestimmten Verzeichnis
innerhalb des AFS zu ermitteln.
• Quotas werden unter AFS pro Volume (siehe 2.6, Seite 21) und nicht pro
Benutzer oder pro Benutzergruppe definiert. Da üblicherweise jeder Benutzer
unter AFS ein eigenes Homedirectory-Volume erhält, ist das unkritisch.
Für projektorientiertes Arbeiten ist diese Art der Quotabestimmung
sehr hilfreich.
• AFS aktualisiert die atime von Files nicht. Da AFS als globales Filesystem
mit Cache ausgelegt ist, wäre das nicht sinnvoll.
• Files ohne harte Links sind unter AFS nicht möglich. Allerdings emuliert
der AFS-Client eine solche Funktionalität ähnlich dem NFS-Client.
Löscht man eine Datei während sie auf dem selben Client noch geöffnet
ist, so benennt der Cache-Manager diese um in .afs + eine zufällige
Zeichenfolge und löscht sie, sobald sie geschlossen wird.
Hier einige Zahlen zu den derzeitigen Begrenzungen, die sich aus den von AFS
benutzten Datenstrukturen ergeben:
• Speicher wird unter AFS in Blöcken von je 1024 Byte verwaltet.
• Dateien sind bei OpenAFS 1.2 auf eine Maximalgröße von 2 31 − 1 Byte
(knapp 2GByte) beschränkt. OpenAFS 1.3 hebt diese Beschränkung auf.
Das gilt jedoch nicht für den Windows-Client (Stand: 03.06.2005).
5 Dadurch sind dynamische Gruppenmitgliedschaften, wie sie z.B. das PAM-Modul libpam_group.so
ermöglicht, zwar nicht ausgeschlossen, sie bewirken jedoch im AFS-Namespace
keine veränderten Rechte.

2.6 Grundlegendes zu Volumes 21
2.6 Grundlegendes zu Volumes
• Pro Verzeichnis stehen maximal 64435 Verzeichniseinträge zur Verfügung
— solange alle Dateinamen kürzer als 15 Zeichen sind. Genaueres
zur Maximalanzahl von Verzeichniseinträgen gibt’s unter 8.4.2 auf Seite
176.
• Volumes sind auf eine Maximalgröße von 2 31 − 1 Blöcke (knapp 2 Ti-
Byte) beschränkt. Angeblich sind auch 4 TiByte möglich, das konnte jedoch
mangels einer so grossen Partition nicht ausprobiert werden.
• Die Größe einer Datenpartition eines OpenAFS-namei-Fileservers (siehe
3.8.2, Seite 57) ist auf 2 TiByte begrenzt.
• Der OpenAFS-Fileserver unterstützt maximal 255 Datenpartitionen pro
AFS-Fileserver.
• AFS unterstützt ein Maximum von 254 Fileservern.
• Jedes Keyfile darf maximal 10 Schlüsselversionen enthalten. Das
schränkt die Anzahl parallel unterstützter nicht-syncronisierter Kerberos-
Realms ein, die nicht per Vertrauenspfad vernetzt sind.
• OpenAFS unterstütz ein Maximum von insgesammt 13 in der VLDB registrierten
Volume-Instanzen. Abzüglich RW- und Backup-Instanz ergibt
sich ein Maximum von 11 RO-Instanzen.
• Volume-Namen dürfen die Zeichen a-z, A-Z, 0-9, sowie die Sonderzeichen
., - und _ enthalten. Die Länge ist auf 22 Zeichen begrenzt. Diese
Grenze bezieht sich auf die Namen der jeweiligen RW-Instanz - die RW-
Instanz volume- -mit-22-Zeichen kann also durchaus eine RO-Instanz
volume- -mit-22-Zeichen.readonly besitzen. Achtung: Wenn man vorhat,
das AFS-Backup-System zu benutzen, sollte man sich unbedingt auf 21
Zeichen beschränken.
• Zu jeder Zelle können minimal ein und maximal maximal fünf Datenbankserver
gehören. Damit sind Datenbankserver gemeint, die in der
Lage sind, an dem Update-Prozess teilzunehmen. Zusätzlich können
Readonly-Kopien von Datenbankservern im Netz gehalten werden.
• Die PTS-IDs von AFS-Benutzern sind vorzeichenlose 31-bit-Integer.
Man sollte tunlichst die Benutzung folgender IDs vermeiden:
1 : Auch wenn man das theoretisch ändern kann, wird diese PTS-ID
praktisch immer für den Zellensuperuser (admin) benutzt.
32768-65536 : Hier liegen einige hart codierte PTS-IDs, die z.B. für anonyme Benutzer
reserviert sind.
Ansonsten ist alles bis 2147483647 erlaubt.
• Die ACLs eines Verzeichnisses können jeweils maximal 20 Einträge enthalten.
• AFS unterstützt kein IPv6 sondern ausschliesslich IPv4.
Volumes sind logische Container, Verwaltungseinheiten in AFS. Für den Anfang
ist es hilfreich, sich darunter eine Art Plattenpartition - allerdings mit vom
Administrator im laufenden Betrieb anpassbarer Größe - vorzustellen. Ein Volume
kann Daten in Form normaler Files, Verzeichnisse sowie Verweise auf
andere Volumes enthalten. Jedes Volume besitzt zumindest eine Ausprägung
- die RW-Instanz. Name sowie ID des Volumes sind mit Namen und ID der

22 2 Technische Grundlagen
2.7 AFS-Kommunikation oberhalb Layer 4
2.7.1 AFS-Clients
RW-Instanz identisch. Unter 3.1, Seite 27 werden die verschiedenen Instanzen
genauer erläutert.
Volumes werden vom AFS-Client dynamisch ineinander gemountet - die
Anwendung bemerkt nicht, wenn sie von einem Volume zum nächsten wechselt.
Die Volumes werden wie Partitionen über spezielle Einstiegspunkte, die
Volume-Mountpoints, zu einem übergeordneten Filesystem zusammengefügt.
Ein Volume-Mountpoint ist vergleichbar mit einem symbolischen Link, der
einem Verzeichnis ein Volume zuordnet. Volume-Mountpoints (siehe 3.2, Seite
32) müssen einmalig mit einem speziellen AFS-Befehl angelegt werden, wobei
lediglich der Name (oder die ID) des Zielvolumes definiert wird. Trifft der
Client auf einen solchen Mountpoint ermittelt er selbstständig einen Fileserver,
auf dem die gesuchte Instanz eines Volumes zu finden ist. Dadurch ist es möglich,
Volumes beliebig in der Zelle zu verschieben - sie sind nicht an bestimmte
Server gebunden wie z.B. NFS-Exports oder Samba-Shares.
Eine weitere Ausprägung eines Volumes ist die Readonly-Instanz. Von jedem
Volume können maximal 11 solcher RO-Instanzen (Kopien der RW-Instanz) in
der Zelle existieren, wodurch sich Lastverteilung und Ausfallsicherheit realisieren
lassen. Mittels eines AFS-spezifischen Befehls wird der Inhalt der RW-
Instanz mit den RO-Instanzen abgeglichen. Das passiert sequenziell. Multicasts,
etc. zur Beschleunigung des Abgleichs sind nicht vorgesehen.
Ein spezielles Volume namens root.afs 6 wird von jedem AFS-Client unter /afs
statisch gemountet. Andere Volumes erreicht man, indem in diesem Volume
Volume-Mountpoints (siehe 3.2, Seite 32) vom Administrator bei der Erstkonfiguration
der Zelle angelegt werden, die auf andere Volumes zeigen.
Die Volume-Mountpoints werden intern als eine spezielle Form von symbolischen
Links verwaltet, die nur der AFS-Client auswertet - für AFS-Server haben
die Mountpoints keine besondere Bedeutung. Volume-Mountpoints können
auch auf Volumes anderer Zellen zeigen und diese dadurch in den eigenen Namensraum
einbinden. Durch solche Links wird das AFS zu einem globalen Filesystem.
Üblicherweise besteht eine AFS-Zelle aus vielen (je nach Größe aus
vielen tausend) Volumes, die durch Mountpoints zu einem großen Filesystem
verbunden sind.
Die eigentlichen Dateien, Verzeichnisse und symbolischen Links werden in den
Volumes zusammen mit den Volume-Mountpoints gespeichert. Normale Anwendungen
können nicht zwischen Volume-Mountpoints und Verzeichnissen
unterscheiden.
Die Möglichkeit, Volumes beliebig untereinander zu vernetzen, ist auch der
Grund dafür, dass im AFS Zyklen auftreten können. Besitzt z.B. ein Volume
a einen Volume-Mountpoint, der auf Volume a zeigt, ist bereits ein einfacher
Zyklus vorhanden. Ein Zyklus kann sich natürlich auch über mehrere Volumes
erstrecken (z.B.: a → b → c → a). Ob das eine gute Idee ist, soll hier lieber
nicht diskutiert werden.
AFS-Clients müssen 7 - um fehlerfrei hochfahren zu können - Zugriff auf mindestens
einen AFS-Datenbank-Server und einen Fileserver mit einer Kopie des
AFS-Rootvolumes haben.
6 in dieser Dokumentation wird es als AFS-Rootvolume bezeichnet
7 ausgenommen Clients, mit der Startoption -dynroot (siehe 3.5.6.3, Seite 44)

2.7 AFS-Kommunikation oberhalb Layer 4 23
2.7.2 Datenbankserver
2.7.3 AFS-Kommando-Familien
Durch Anfrage ans DNS 8 ermittelt der AFS-Client die AFS-DB-Server der Zelle.
DNS ist nötig, /etc/hosts oder ein host-Map im NIS reichen nicht. Durch eine
weitere Anfrage an einen AFS-DB-Server 9 erfährt der Client, auf welchen Fileservern
eine Kopie des AFS-Rootvolumes zu finden ist. Das root-Volume wird
anschließend statisch an /afs gemountet. Der AFS-Client versteift sich dabei
nicht auf einen bestimmten Fileserver. Fällt der Fileserver aus, der eine Kopie
eines bestimmten Volumes zur Verfügung stellt, benutzt der AFS-Client einen
anderen. Die Anwendung merkt davon - abgesehen von einer angemessenen
(zur Compilierzeit fest einprogrammierten) Wartezeit - nichts.
Achtung: Die Volumes werden nicht in Echtzeit repliziert (siehe 3.1, Seite 27).
Mountpoints in Volumes enthalten Verweise auf andere Volumes. Ein erster Zugriff
auf einen solchen Mountpoint generiert eine Anfrage an einen der AFS-
DB-Server. Auf das jeweilige Volume wird dann im Hintergrund zugegriffen -
die Anwendung merkt nichts vom Eintritt 10 in ein neues Volume.
Die AFS-Datenbankserver kommunizieren untereinander. Unter anderem führen
sie in regelmäßigen Abständen eine Wahl (siehe 3.3.2, Seite 36) durch, um
einen Server zu bestimmen, der als Sync-Site berechtigt ist, Änderungen an der
Datenbank durchzuführen. Außerdem werden die auf der Sync-Site (und nur
dort) durchgeführten Änderungen an der Datenbank sofort auf alle erreichbaren
anderen Datenbankserver übertragen.
AFS kennt mehrere Kommando-Familien mit zahlreichen Unterkommandos,
die ggf. auch eine Netzwerkkommunikation auslösen:
bos : Die bos-Kommandos kontrollieren die zahlreichen Serverprozesse auf
AFS-Servern
fs : Dieses Kommandos dienen der Kommunikation mit dem Cachemanager
(also dem AFS-Client) und der Namensänderung im Filesystem. fs kommuniziert
nicht direkt mit Servern im Netzwerk, sondern überlässt das
dem Cachemanager.
vos : Mit vos manipulierverwaltet man Volumes. Viele Unterkommandos setzen
vorraus, dass der Rechner, auf dem sie benutzt werden, die Sync-Site
der Volume-DB (VLDB) erreichen kann.
pts : Die pts-Kommandos verwalten die Zugriffsrechte auf Volumes, indem
sie Einträge in der Protection-DB machen.
backup : Die backup-Kommandos kommunizieren mit einem beliebigen DB-
Server, um Daten aus der Backup-DB (BDB) auszulesen. Zum Ändern
von Daten benötigt der entsprechende Rechner Kontakt zur Sync-Site
der BDB.
kas : Die kas-Kommandos kommen unter InstantAFS nicht zum Einsatz.
Ein Kommando beginnt immer mit der Kommando-Familie gefolgt von einem
der meist zahlreichen Unterkommandos. Dieses kann auch abgekürzt werden.
8 Es ist möglich, die IP-Adressen der DB-Server dem AFS-Client in einem File (CellServDB) zur
Verfügung zu stellen. Bei vielen Rechnern ist das aber unpraktikabel.
9 Welcher genau kontaktiert wird, hängt von einem Client-internen Ranking aller bekannten Datenbankserver
ab. Ein ähnliches Ranking existiert auch für alle (bekannten) Fileserver.
10 Einer Anwendung ist es mit etwas Aufwand möglich, festzustellen, ob sie mit einem Verzeichnis
auch das Volume wechselt. Der find-Befehl überquert z.B. per default keine Volume-Grenzen.

24 2 Technische Grundlagen
2.7.4 Kerberos
2.7.5 Anderes
Zu jeder Kommando-Familie und den jeweiligen Unterkommandos gibt es online
Hilfe. Beispiel:
user@host>vos help
vos: Commands are:
addsite add a replication site
apropos search by help text
backup make backup of a volume
...
user@host>vos help addsite
vos addsite: add a replication site
Usage: vos addsite -server -partition ...
Where: -noauth don’t authenticate
-localauth use server tickets
-verbose verbose
-encrypt encrypt commands
2.8 Authentifikation, Autorisation, Sicherheit
Die Kerberos-Kommandos und -Bibliotheken kommunizieren mit den auf den
AFS-DB-Servern installierten Kerberos-Serverprozessen. Dabei werden praktisch
nie Daten auf dem Kerberos-Server geändert, weshalb es auch reicht, einen
beliebigen Kerberos-Server (auf einer beliebigen AFS-DB-Servermaschine)
erreichen zu können. Der Kerberos-Admin-Server, der auf einem beliebigen
AFS-DB-Server installiert wird, muss nur dann erreichbar sein, wenn z.B. mit
kadmin Änderungen an der Kerberos-Datenbank anstehen.
Acall-Server (siehe 7.6.2, Seite 149) warten am TCP-Port 6999 auf Anfragen.
Der PTDB-NSS-Dienst (siehe A.2, Seite 224) benutzt den UDP-Port 6998, jedoch
ausschließlich lokal (also explizit an die Adresse 127.0.0.1 gebunden). Die
PTDB-NSS-Clients (also die NSS-Module lokal laufender Anwendungen) benutzen
jeweils einen beliebigen freien UDP-Port zur Kommunikation mit dem
Dienst.
AFS erkennt Benutzer anhand eines verschlüsselten Datenblocks, eines Tokens,
der aus einem Kerberos-Ticket (siehe 3.10, Seite 61) errechnet wird - die Authentifikation
basiert also auf Kerberos. Die Entwicklung geht jedoch dahin,
dass Kerberos-Tickets direkt als Token verwendet werden können. Wie auch
Kerberos-Tickets, haben Tokens eine zeitlich begrenzte Gültigkeit.
Das Prinzip der Authentifikation unter AFS unterscheidet sich durch 2 Dinge
von klassischen Methoden in Unix-Netzwerken:
• Die Authentifikation von Dateisystemzugriffen erfolgt nicht an der
Client-Maschine, sondern am Server. Der AFS-Client speichert lediglich
das AFS-Token für den Benutzer und benutzt es für jeden Zugriff auf das
AFS. Da das AFS-Token aus einem Kerberos-Ticket erzeugt wurde, das
wiederum nur von einem (natürlich stark geschützten) Kerberos-Server
ausgestellt werden kann, ist ein AFS-Token praktisch fälschungsicher -
solange das Passwort eines Nutzers nicht geknackt wurde.
In einem klassischen Unix-Netz wird lediglich die UID eines Benutzers
vom Server zur Authentifikation genutzt - und die UID eines Benutzers
ist leicht herauszufinden und zu übernehmen.

2.9 Wo werden Daten über die Benutzer gespeichert? 25
• Die Authentifikation ist zeitlich begrenzt. Dies ist z.B. dann von Vorteil,
wenn Benutzer vergessen sich auszuloggen. Da sowohl das Kerberos-
Ticket wie auch der AFS-Token nach einer gewissen Zeit ablaufen, ist
eine lange vergessene Login-Session praktisch wertlos. Es ist zwar noch
möglich, Programme zu starten, jedoch ist mit dem Token auch das Recht
auf nicht-anonymen Zugriff auf das AFS abgelaufen.
An diesem Beispiel wird auch deutlich, dass man zwischen hohem Komfort
für die Nutzer (lange Ticket-/Token-Gültigkeitsdauer) und hoher
Sicherheit (kurze Gültigkeitsdauer) die Balance finden muss.
Dieses Sicherheitskonzept ist natürlich wie jedes andere, das ohne Spezialhardware
auskommt, in einer Hinsicht machtlos: Besitzt ein Angreifer die Kontrolle
über eine Client-Maschine und loggt sich ein regulärer Benutzer ein, so kann
der Angreifer das Passwort des Benutzers abhören. Damit kann er sich - bis der
Benutzer sein Passwort ändert - im AFS im Namen des Benutzers bewegen.
Alle Anfragen an die Fileserver (d.h. alle Netzwerkübertragungen) werden vom
AFS-Client signiert und sind somit schwer zu fälschen. Optional können auch
alle Übertragungen verschlüsselt werden. Achtung: Das gilt nur, wenn man mit
einem gültigen Token arbeitet.
Zugriffe auf das Dateisystem selbst werden hauptsächlich per ACLs (siehe
3.7.3, Seite 51) gesteuert - jedoch auch über Modebits (siehe 3.7.3.3, Seite 52).
ACLs werden pro Verzeichnis gespeichert. Sollen also Dateien im gleichen Verzeichnis
unterschiedliche Zugriffsrechte erhalten, muss mit symbolischen Links
und zusätzlichen Verzeichnissen gearbeitet werden. AFS-ACLs ermöglichen
eine feinere Einstellung der Rechte als Modebits oder Posix-ACLs.
2.9 Wo werden Daten über die Benutzer gespeichert?
Ein Benutzer, der interaktiv als ein normaler Benutzer auf das AFS zugreifen
will muss in verschiedenen Datenbanken eingetragen sein:
Kerberos5 : In der Kerberos5-Datenbank müssen für jeden Benutzer der Name sowie
sein Passwort gespeichert sein. Das Passwort wird nicht im Klartext
gespeichert.
2.10 Ablauf eines Filezugriffs auf das AFS
PTDB : (ProTectionDataBase) Diese AFS-Datenbank (siehe 3.3, Seite 35) wird
von den Fileservern benutzt, um die in einem AFS-Token gespeicherten
Kerberos-Namen in eine AFSID umzuwandeln. Hier muss also der Name
und zellenweit eindeutige Zahl für jeden Benutzer gespeichert werden.
NSS : (NameServiceSwitch) Hier kann eine beliebige Methode, die vom NSS
unter Linux benutzt werden kann, um Benutzernamen auf UIDs und
umgedreht abzubilden, eingesetzt werden. Diese Dokumentation beschränkt
sich dabei auf das für dieses Projekt entwickelte NSS-Modul
libnss-ptdb .deb (siehe A.2, Seite 224).
Die Schritte, um einen neuen Benutzer anzulegen sind unter 6.1 auf Seite 114
beschrieben und lassen sich leicht automatisieren.
Soll eine Datei aus dem AFS gelesen werden, so muss der AFS-Client mehrere
Server kontaktieren, um auf die Datei Zugriff zu erhalten. An einer Beispielzelle
11 sollen die Aktivitäten beschrieben werden, die folgendes Kommando
auslöst:
cat /afs/cbs.mpg.de/test.txt
11 Die Beispielzelle ist unter 7.1, Seite 140 genau beschrieben.

26 2 Technische Grundlagen
2.11 DOs and DON’Ts
1. Das cat-Kommando führt die Funktion open() aus, um lesend auf die
Datei /afs/cbs.mpg.de/test.txt zuzugreifen.
2. Das AFS-Rootvolume, das statisch unter /afs gemountet ist, wird nach
dem Eintrag cbs.mpg.de durchsucht.
3. Der Eintrag ist ein Mountpoint auf #root.cell. Gemäß der Mountpoint-
Regeln (siehe 3.2, Seite 32) wird die RO-Instanz von root.cell an dieser
Stelle benutzt. Hinweis: Je nach Einstellung auf dem AFS-Client kann
auch ein dynamischer AFS-Root verwendet werden. Dabei handelt es
sich um eine Art Automounter. In diesem Fall würde der AFS-Client
bei Zugriff auf /afs/cbs.mpg.de On-the-Fly einen Mountpoint auf das
Volume root.cell der Zelle cbs.mpg.de erzeugen.
4. Um einen Server in Erfahrung zu bringen, auf dem eine RO-Instanz dieses
Volumes liegt, wird ein DB-Server kontaktiert. Welcher das ist, wird
durch die im Kernel gespeicherten Server-Ranks (siehe 6.12, Seite 136)
entschieden.
5. Der DB-Server antwortet mit einer Liste von Servern, auf denen die RO-
Instanz zu finden ist.
6. Der AFS-Client wählt aus den Servern dieser Liste den aus, der entsprechend
seinem Rank (siehe 6.12, Seite 136) am besten scheint.
7. Das root-Verzeichnis des Volumes root.cell wird nach test.txt durchsucht,
die Daten kommen aus der RO-Instanz auf dem gewählten Server.
8. Vom gewählten Server wird jetzt der Inhalt der Datei test.txt angefordert
und im lokalen AFS-Cache (siehe 3.5.1, Seite 39) abgelegt.
9. Die read()-Funktion des cat-Kommandos liefert den Inhalt der Datei
zurück, anschließend wird sie nach STDOUT ausgegeben.
Liegen die Volumes im selben LAN wie der AFS-Client, dauert dieser Vorgang
nur Millisekunden. Sind die Volumes aber weiter entfernt (man kann AFS-
Server bei bedarf im ganzen IPv4-tauglichen Internet verteilen), dauert es durch
höhere Latenzzeiten und geringere Bandbreite natürlich länger.
Hier einige Regel, die man sich tunlichst merken sollte, wenn man mit AFS
arbeitet:
• Die Zeit ist lebenswichtig. Achte immer auf korrekte Zeit auf AFS-
Servern, Kerberos-Servern und AFS-Clients!
• Kombiniere niemals AFS-File- und AFS-Datenbankserver auf der selben
Maschine! Für Testzellen ist das kein Problem, aber in Produktion ist das
ein grosser Fehler.

3 Technische Details zu AFS
3.1 Volumes
3.1.1 RW-Volumes (RW-Instanzen)
Der Begriff Volume bezieht sich unter AFS auf 2 Dinge:
1. einen Eintrag in der VLDB (VoLumeDataBase), der beschreibt, welche
Instanzen von einem Volume auf welchen Servern existieren und welche
numerische ID diesen Instanzen jeweils zugeordnet ist,
2. einzelne Instanz eines Volumes.
Um Verwirrungen vorzubeugen, wird für das auf einer definierten Festplatte
liegende Volume eines bestimmten Typs immer der Begriff Instanz benutzt.
Die Länge des Namens der RW-Instanz und damit des Volumes ist auf 22 Zeichen
begrenzt. Mit diesen kurzen Namen muss sich aber nur der Administrator
herumschlagen. Der Benutzer bekommt nur die normalen Pfadnamen zu Gesicht,
auf welche die Volumes gemountet sind.
Legt man mit dem Befehl vos create ein neues Volume an, erstellt man
damit nur eine RW-Instanz:
admin@afs>vos create Servername Partition Name des Volumes
Eine RW-Instanz ist die einzige Volume-Instanz, in der Änderungen möglich
sind. Pro Volume gibt es immer nur eine RW-Instanz, RO-Instanzen hingegen
kann es beliebig viele geben. Beispielsweise muss der Pfad zum Homedirectory
eines Benutzer so aufgebaut sein (siehe 3.2, Seite 32), dass an dieser Stelle eine
RW-Instanz gemountet wird. Erstellt man einen Mountpoint auf die RW-Instanz
mit fs mkmount und setzt die ACLs darin mit fs setacl entsprechend,
kann man darauf lesend und schreibend zugreifen:
admin@afs>fs mkmount /afs/pfad/zum/volume mein_volume -rw
3.1.2 RO-Volumes (RO-Instanzen)
Hinweis: Beim Anlegen von RW-Instanzen (und damit von Volumes) sind weitere
Dinge zu beachten, unter 6.3.1 auf Seite 116 findet man Details dazu.
Eine der Stärken von AFS ist die Möglichkeit, Volumes bei Bedarf replizieren
zu können. vos addsite setzt einen Fileserver auf die Liste der Server,
die die RO-Instanz (auch RO-Kopie oder RO-Volume genannt) eines Volumes
aufnehmen sollen. Es wird noch nichts kopiert. Erst durch das Kommando vos
release wird die RW-Instanz auf ihre RO-Instanzen repliziert:
admin@afs>vos addsite Server Partition Volume
admin@afs>vos release Volume
Es können mehrere (derzeitig bis zu 12) RO-Instanzen zu jeder RW-Instanz
existieren, jedoch immer nur eine pro Server.
27

28 3 Technische Details zu AFS
Beispiel:
Es ist nicht möglich, nur ein RO-Volume zu erzeugen, indem man eine RO-
Instanz anlegt - es muss zuerst ein RW-Volume angelegt werden.
Der vos release-Befehl gleicht den Inhalt der RO-Instanz an den der
RW-Instanz einmalig an. Auch jeder weitere Abgleich muss explizit mit diesem
Kommando ausgelöst werden und geschieht niemals automatisch. Auch kann
man RO-Instanzen, von denen pro Volume mehrere existieren können, nicht
einzeln abgleichen 1 . Die RW-Instanz wird immer in alle RO-Instanzen auf
einmal kopiert, wobei immer nur die Differenzen 2 übertragen werden. Ist ein
Server, der eine der RO-Instanzen enthält, nicht erreichbar, wird die jeweilige
Kopie ausgelassen. Um solche Instanzen ebenfalls zu synchronisieren, muss
der entsprechende Server wieder verfügbar gemacht und das Volume erneut
mit vos release abgeglichen werden. In der VLDB wird dann vermerkt,
dass die entsprechende Kopie nicht up-to-date ist. Wie man die Replikation von
Volumes nutzt, ist unter 7.10 (Seite 158) beschrieben.
Eine Kopie von Ernies Home-Directory wird angelegt:
admin@afs>vos addsite afsserv2 /vicepa user.ernie
admin@afs>vos release user.ernie
Beispiel:
Das Kommando vos release kann nur von Zellensuperusern ausgeführt
werden. Normale Benutzer müssen dafür auf acall (siehe 7.6.2, Seite 149)
zurückgreifen:
user@host>acall db instantafs.acall-release user.ernie
user@host>iarel -d ∼ernie
3.1.2.1 Selbe Partition oder nicht
oder komfortabler durch Angabe des Verzeichnisses mit
Der Name einer RO-Instanz setzt sich immer aus dem Namen der entsprechenden
RW-Instanz sowie dem Suffix .readonly zusammen.
Auf einem Fileserver können nicht mehrere RO-Instanzen eines Volumes existieren.
Die Synchronisation der RO-Instanzen mit einer RW-Instanz ist ein verhältnismäßig
komplexer Prozess. Existieren mehrere RO-Instanzen von einen Volume,
dann ist sichergestellt, dass AFS-Clients immer auf wenigstens eine davon zugreifen
können. Um das zugewährleisten, interagiert der Synchronisationsprozess
stark mit der VLDB (auch schreibend!), weshalb die VLDB unbedingt im
Zustand Quorum elected sein muss (siehe 3.3.2, Seite 36).
RO-Instanzen, die auf der selben Partion 3 wie die RW-Instanz liegen, werden
differentiell gespeichert (siehe 3.1.4, Seite 29). Man kann sie nicht als ein physisches
Backup betrachten.
RO-Instanzen, die nicht auf derselben Partition wie die RW-Instanz liegen, können
als physisches Backup betrachtet werden (siehe 5.5, Seite 109).
Man kann durch den Befehl
admin@afs>vos convertROtoRW Server Partition Volume-Name
1 Dies ist wohl eher ein Feature als ein Mangel, da andernfalls unterschiedliche Kopien entstehen
würden. Ausserden gibt es für solche Zwecke die Backup-Volumes.
2 Man sollte dabei nicht die Performance von optimierten Protokollen wie rsync erwarten. Es
werden ganze Dateien und nicht nur veränderte Dateifragmente kopiert.
3 also auch auf dem selben Server

3.1 Volumes 29
3.1.3 Backup-Volumes (Backup-Instanzen)
3.1.4 Differenzielle Speicherung
aus einer RO-Instanz eine RW-Instanz machen. Dies ist die schnellste Form
einen Backup “zurückzuspielen”.
Die vollständige Synchronisation einer RW-Instanz mit allen RO-Instanzen
dauert üblicherweise länger (vor allem, wenn viele Dateien enthalten sind),
wenn auf der Partition der RW-Instanz keine RO-Instanz existiert.
Zuerst ein wichtiger Hinweis: Backup-Instanzen schützen nicht vor Hardware-
Schäden, da sie immer auf derselben Partition wie die RW-Instanz liegen müssen.
Sie verhindern aber Schäden durch versehentliches Löschen oder durch
clientseitige Softwarefehler 4 .
Backup-Instanzen funktionieren wir RO-Instanzen, die auf der selben Partition
wie die zugehörige RW-Instanz liegen - nur können sie unabhängig von einer
evtl. vorhandenen RO-Instanz angesprochen und synchronisiert werden (siehe
3.1.4, Seite 29). Anstelle von vos release wird vos backup verwendet,
um die Synchronisation einer solchen Instanz mit der zugehörigen RW-Instanz
durchzuführen.
Wird eine RW-Instanz verschoben, so wird die Backup-Instanz gelöscht und
muss bei Bedarf auf dem neuen Server mit vos backup neu angelegt werden.
Die Bezeichnung Backup kommt nicht daher, dass diese Sorte Instanzen einen
Backup darstellt, sondern dass sie für Backups verwendet werden sollten (siehe
5.2.2, Seite 101), da sie einen eingefrorenen Zustand eines Volumes repräsentiert.
Backup-Instanzen funktionieren in etwa wie RO-Instanzen, die auf derselben
Partition wie die RW-Instanz liegen, jedoch werden sie durch vos release
nicht verändert. Daten werden ebenfalls differenziell zur RW-Instanz gespeichert.
Das Kommando, um eine Backup-Instanz mit der RW-Instanz zu synchronisieren
lautet vos backup. Explizit anlegen muss man eine Backup-
Instanz nicht, da es keine Wahlmöglichkeit gibt, wo sie angelegt werden soll.
Existiert sie noch nicht, wird sie durch vos backup erzeugt.
Mit Backup-Instanzen kann man ein besonders administrationsarmes Backup-
System realisieren (siehe 7.2, Seite 141). Ein solches Backup lässt sich theoretisch
auch mit RO-Instanzen realisieren, jedoch werden diese u.U. schon für
andere Zwecke gebraucht.
Backup-Instanzen werden immer differentiell gespeichert (siehe 3.1.4, Seite 29)
und liegen immer auf der Partition, auf der die RW-Instanz liegt.
Die Synchronisation einer Backup-Instanz mit der RW-Instanz erfolgt, ohne
dass Schreibzugriffe in die VLDB erforderlich sind. Aber Vorsicht: Synchronisation
ist nicht gleichbedeutend mit “Anlegen einer Backup-instanz”. Anders
gesagt: Nur wenn vos examine Volume anzeigt, dass das Volume eine
Backup-ID (�= 0), dann ist vos backup Volume möglich, selbst wenn mehr
als die Hälfte der AFS-Datenbankserver ausgefallen oder nicht erreichbar ist 5 .
Wird eine RO-Instanz auf derselben Partition oder eine Backup-Instanz zu einer
RW-Instanz angelegt, kommt eine besondere Funktionalität von AFS zum
Einsatz: Die Instanz wird zu einem Clone. Clone-Instanzen sind grundsätzlich
4 z.B. ein abstürzendes MS-Word, das ein .doc-File in einem unbrauchbaren Zustand hinterlässt.
5 Wenigstens einer muss natürlich erreichbar sein.

30 3 Technische Details zu AFS
3.1.5 Temporäre differentiell gespeicherte Instanzen
nur lesbar. Die die RW-Instanz zusammen mit ihren Clone-Instanzen nennt man
Volume Group.
Solche Instanzen benötigen unmittelbar nach einer Synchronisation praktisch
keinen 6 Speicherplatz - egal wie groß die RW-Instanz ist, da sie zunächst nur
Verweise auf die Objekte in der RW-Instanz enthalten. Wird nach der Replikation
etwas an der RW-Instanz geändert, läuft das aus Sicht des Fileservers wie
folgt ab:
1. Das zu ändernde Objekt (also eine Datei oder ein verzeichnis), wird
kopiert, das RW-Volume arbeitet anschliessend mit der Kopie. Dieser
Vorgang heißt Copy-on-Write. Er spart viel Speicher (solange sich am
Original wenig verändert) und Kopierzeit beim Synchronisieren der ROund
Backup-Instanzen. Existieren mehrere Clone-Instanzen, so teilen
sich diese anschliessend die Kopie des Objektes.
2. Erst jetzt werden die Änderungen in das Objekt geschrieben.
Für den Benutzer ist es jedoch ein ganz normaler Schreibzugriff, vom Copyon-Write
bekommt er nur durch die Verzögerung bei der ersten Änderung (vor
allem bei grossen Dateien) etwas mit.
Diese Instanzen werden zwar auf Fileservern differenziell zur RW-Instanz gespeichert
- nach außen hin 7 verhalten sie sich aber wie vollständige Volumes:
• Diese Instanzen sind in den AFS-Namensraum integriert und beinhalten
alle Dateien und Verzeichnisse der RW-Instanz plus die Differenzen, die
im Speicherbereich der RO- oder Backup-Instanz gespeichert sind.
• Sichert man solche Instanzen z.B. im Rahmen eines Backups (siehe 5.2,
Seite 100), so wird das in der Instanz gespeicherte Abbild gesichert und
nicht nur die physisch dort gespeicherten Differenzen, d.h. die Daten und
nicht nur die Verweise.
Diese Instanzen sind deshalb ein Abbild der RW-Instanz zu einem bestimmten
Zeitpunkt, durch die differenzielle Speicherung werden sie up-to-date gehalten.
RO- und Backup-Instanzen sind für Backups von besonderer Bedeutung (siehe
5.2.2, Seite 101), da sie sich eben erst auf Befehl des Administrators hin ändern.
Der Platzbedarf für die differenzielle Speicherung wächst nach der Synchronisation
mit der RW-Instanz bei Schreibzugriffen an und kann die Größe der
RW-Instanz erreichen, wenn diese in keiner Datei mehr mit dem Zustand bei
der letzten Synchronisation übereinstimmt 8
Für bestimmte Aktionen legt das AFS temporäre Clone-Instanzen an, die ebenfalls
differentiell gespeichert werden, jedoch keinen Namen haben und auch
nicht ins Filesystem eingemountet werden können. Die gestarteten Aktionen
arbeiten dann nicht direkt auf der RW-Instanz, sondern auf diesem temporary
clone.
Solche Aktionen sind z.B.
• vos move ohne -live-Option
6 Es werden lediglich Tabellen angelegt, die über die differenzielle Speicherung Buch führen.
7 Sprich: für Benutzer und auch z.B. beim Dumpen der instanz mit vos dump
8 also wenn alle Verweise durch Kopien der alten Dateien ersetzt wurden.

3.1 Volumes 31
• vos release Wenn auf der Partition der RW-Instanz eine RO-Instanz
existiert, wird kein temporärer Clone angelegt, sondern direkt auf die RO-
Instanz zugegriffen.
• vos dump -clone
3.1.6 Zusätzliche differenziell gespeicherte Instanzen
Dieser Aufwand ist sinnvoll, da auf diese Weise mit einem konsistenten Image
des Volumes gearbeitet werden kann. Schreibzugriffe, die nach dem Start der
Aktion auf die RW-Instanz ausgeführt werden, haben keinen Einfluss mehr auf
den Inhalt des Images.
Ab OpenAFS 1.3 existiert die Möglichkeit, weitere differenziell gespeicherte
Volumes auf der RW-Partition zu erzeugen. Dabei darf jedoch die maximale
Anzahl von 6 Clone-Instanzen pro Volume nicht überschritten werden.
Achtung: Der Administrator muss selbst dafür sorgen, dass nicht zuviele Clones
erzeugt werden! Auf der sicheren Seite ist man, wenn nicht mehr als 3
zusätzliche Clones manuell benutzt.
Das Kommando zum Erzeugen eines zusätzlichen Clones lautet:
admin@afs>vos clone Volume Server Partition -toname Clone-Name
3.1.7 Verschieben von Volumes im Produktionsbetrieb
Der Name des Clones taucht dann lediglich in der Instanzenliste des Fileservers
(vos listvol) auf, nicht jedoch in der VLDB. Es ist auch nicht möglich,
den Clone per Mountpoint ins Filesystem einzubauen.
Volume-Instanzen lassen sich im laufenden Betrieb on Server zu Server (oder
auch zwischen 2 Partitionen des selben Servers verschieben).
Diese Möglichkeit beschränkt sich allerdings auf RW-Instanzen, da RO-
Instanzen auf andere Weise effizienter "verschoben"werden können - mehr
dazu weiter unten.
RW-Instanzen werden verschoben, während weiterhin Benutzer darauf arbeiten
können. Der Ablauf dahinter ist wie folgt:
1. Ein Move-Clone der RW-Instanz wird auf dem Quellserver erzeugt (siehe
3.1.6, Seite 31).
2. Auf dem Zielserver wird eine neue Instanz angelegt, und der Move-Clone
wird in diese Instanz kopiert.
3. Die RW-Instanz auf dem Quellserver wird jetzt auf Busy (siehe 6.13.2,
Seite 137) geschaltet, wodurch weitere Zugriffe von Clients blockiert
werden ohne das Timeouts auftreten können.
4. Die RW-Instanz vom Quellserver wird inkrementell in die neue Instanz
auf dem Zielserver kopiert.
5. Die neue Instanz auf dem Zielserver wird zur RW-Instanz gemacht und
in der VLDB entsprechend registriert
6. Die gesammte Volume-Group der alten RW-Instanz auf dem Quellserver
wird gelöscht. Das umfasst die RW-Instanz, den Move-Clone und alle
evtl. vorhandenen anderen Clones (z.B. eine Backup-Instanz).
Ausnahme: Wenn auf der selben Partition noch eine RO-Instanz des Volumes
lag, existiert dieses weiter.

32 3 Technische Details zu AFS
7. Clients, die auf die alte RW-Instanz zugreifen, bekommen den Hinweis,
dass die Instanz nicht mehr exitiert, wenden sich an die VLDB, erfahren
dort, wo die RW-Instanz jetzt liegt und greifen sofort auf diese zu.
Ausgelöst wird das Verschieben eines Volumes wie folgt:
admin@afs>vos move Volume Quellserver Quellpartition Zielserver Zielpartition
RO-Instanzen "verschiebtman, indem man folgendes macht:
admin@afs>vos addsite Zielserver Zielpartition Volume
admin@afs>vos release Volume
admin@afs>vos remove Quellserver Quellpartition Volume.readonly
3.2 Volume-Mountpoints
3.2.1 Arten
Volume-Mountpoints hängen die Volumes in den AFS-Namensraum ein. Sie
werden vom Client ausgewertet. Mountpoints können - das “a”-Recht im entsprechenden
Verzeichnis vorrausgesetzt (siehe 3.7.3.2, Seite 51) - von jedem
Benutzer angelegt und gelöscht werden. Dadurch haben Benutzer eine gewisse
Kontrolle über die Struktur des Namensraumes.
Mountpoints sehen für normale Programme wie Verzeichnisse aus.
An jedem Mountpoint muss der AFS-Client entscheiden, welche Art Volume
und von welchem Server gemountet wird. Die Informationen im Mountpoint
selbst reichen für diese Entscheidung oft noch nicht aus. Man unterscheidet 4
verschiedene Arten von Mountpoints. Angegeben ist neben dem Befehl zum
Anlegen des jeweiligen Mountpoints auch ein Beispieloutput, des Befehls fs
lsm, angewandt auf einen solchen Mountpoint.
Hinweis: Die Konstrukte, bei denen jeweils ein Verzeichnis und eines, das abgesehen
von einem Punkt davor genauso heisst, in verschiedene Instanzen des
selben Volumes führen, sind unter AFS üblich und unter 3.2.3 (Seite 34).
Hier ist die Liste der Mountpoint-Typen:
1. Der Befehl
user@host>fs mkm Verzeichnis RO-Instanz
generiert einen Mountpoint, der immer zu einer RO-Instanz eines Volumes
führt. Auf der RO-Instanz kann man natürlich keine Dateien
verändern. Ist keine RO-Instanz vorhanden, kann man nicht in das entsprechende
Verzeichnis wechseln. Output:
’vol’ is a mount point for volume ’#vol.readonly’
2. Mit
user@host>fs mkm Verzeichnis Backup-Instanz
legt man Mountpoint an, der in eine Backup-Instanz 9 führt. Darin können
ebenfalls keine Dateien verändert werden. Ist keine Backup-Instanz
vorhanden, kann man nicht in das entsprechende Verzeichnis wechseln.
9 Hinweis: Die Namen von Backup-Instanzen enden immer auf .backup

3.2 Volume-Mountpoints 33
Output:
’vol’ is a mount point for volume ’#vol.backup’
3. Der Befehl
user@host>fs mkm Verzeichnis Volume -rw
erzeugt einen Mountpoint, so dass der Cachemanager beim Wechseln
in das entsprechende Verzeichnis explizit auf eine RW-Instanz zugreift,
wodurch man die enthaltenen Dateien bearbeiten kann. Ist das Volume
nicht verfügbar (weil z.B. der Server ausgefallen ist) oder existiert keine
RW-Instanz 10 , wird ein Fehler zurückgeliefert. RW-Mountpoints, die auf
ein Volume verweisen, auf das hauptsächlich lesend zugegriffen wird
(z.B. installierte Softwarepakete, Konfigurationsfiles, Archive), werden
im AFS üblicherweise mit einem vorangestellten Punkt gekennzeichnet.
Output:
’.vol’ is a mount point for volume ’%vol’
4. Mit
user@host>fs mkm Verzeichnis Volume
wird ein besonderer (dynmischer) Mountpoint angelegt, bei dem die Art
des Instanz, in der der Mountpoint liegt, über die zu mountende Instanz
entscheidet. Mehr dazu im folgdenden Abschnitt. Output:
’vol’ is a mount point for volume ’#vol’
Hinweise:
• Ein Mountpoint kann immer angelegt werden - auch wenn das entsprechende
Volume nicht existiert. Ein merkwürdiger Mechanismus verhindert
das Anlegen von Mountpoints, auf die man keinen Zugriff hat - das
ist jedoch sicherheitsmäßig nur heiße Luft (siehe 3.2.4, Seite 34)
• Die Regeln, nach denen Volume-Instanzen gemountet werden, können
u.U. verwirrend sein. Das Programm instantafs.afsdir schafft
Abhilfe:
user@host>instantafs.afsdir Verzeichnis im AFS
Hinweis:
Der Output besteht aus einer detailierten Angabe über die auf dem Pfad
durchlaufenen Volumes sowie einer Begründung, warum die entsprechenden
Volume-Instanzen jeweils gemountet wurden.
• Anstelle des Namens eines Volumes kann das Ziel des Volume-Mountpoints
auch die ID eines Volumes sein. Als Volumename wird dann einfach die
ID (eine Dezimalzahl) benutzt und auch von fs lsm angezeigt.
• Mountpoints können auch auf Volumes anderer Zellen zeigen. Der zusätzliche
Parameter -cell Zellenname für das fs mkm-Kommando
ist dafür zuständig.
Beispiel:
admin@afs>fs mkm tu root.cell -cell tu-chemnitz.de
admin@afs>fs lsm tu
’tu’ is a mount point for volume ’#tu-chemnitz.de:root.cell’
10 Das ist möglich, jedoch sehr ungewöhnlich.

34 3 Technische Details zu AFS
3.2.2 Dynamische Mountpoints
3.2.3 Punkt oder nicht Punkt...
3.2.4 Wie werden Mountpoints gespeichert?
• Es ist günstig, ein Standardschema zu benutzen, nach dem die zu einer
RO-Instanz gehörige RW-Instanz im Namensraum des AFS erreicht werden
kann (siehe 3.2.3, Seite 34).
Wird der Mountpoint aus einer RW-Instanz aufgerufen, so wird versucht,
wiederum eine RW-Instanz zu mounten. Wird er hingegen aus einer ROoder
Backup-Instanz heraus aufgerufen, so wird eine RO-Instanz gemountet.
Existiert zu dem angegebenen Volume keine RO-Instanz, wird immer
die RW-Instanz benutzt. Existieren RO-Instanzen, sind jedoch (z.B. wegen
Serverausfalls) nicht erreichbar, wird ein Fehler gemeldet.
In neueren AFS-Versionen (bei 1.4 und höher z.B.) kann man dem AFS-
Client eine Option mitgeben, die das Verhalten dynamischer Mountpoints
ändert, wenn sie aus Backup-Instanzen herraus aufgerufen werden. Die Option
-backuptree sorgt dafür, dass ein aus einer Backup-Instanz aufgerufener
dynamischer Mountpoint versucht, eine Backup-Instanz zu mounten. Existiert
keine, wird die RW-instanz benutzt. Ist die Backup-Instanz nicht erreichbar,
gibt’s einen Fehler.
Verschiedene Volumes sollten per Default als RO-Instanzen gemountet werden
- z.B. local.scripts (siehe 7.1, Seite 140), ein Verzeichnis für ausführbare
Programme. Das Volume ist dann über /afs/cbs.mpg.de/local/scripts erreichbar.
Soll sein Inhalt verändert werden, muß irgendwie die zugehörige RW-Instanz
angesprochen werden. Da es i.d.R. nicht bei einem einzigen derartigen Volume
bleibt, muss ein Schema her, nach dem die RW-Instanz zu einem Volume, das
normalerweise nur in seiner RO-Ausführung von Interesse ist, leicht zu finden
ist. Z.B. kann man definieren, das ein vor den Mountpoint gesetzter Punkt immer
zur RW-Instanz führt. Im Beispiel wäre das: /afs/cbs.mpg.de/local/.scripts.
Weitere Beispiele für diese Konstruktion sind:
RO-Pfad RW-Pfad
/afs/cbs.mpg.de /afs/.cbs.mpg.de
/afs/user-backup /afs/.user-backup
/afs/cbs.mpg.de/user /afs/cbs.mpg.de/.user
Dabei ist der Mountpoint ohne Punkt vom Typ 4 (siehe Seite 33), der mit Punkt
dagegen vom Typ 3. Unter 7.10 auf Seite 158 ist Schritt für Schritt beschrieben,
wie man eine solche Konstruktion anlegt.
Dadurch, dass standardmäßig die RO-Instanz benutzt wird, wird die durch das
jeweilige Volume erzeugte Last, wenn mehrere RO-Instanzen existieren, auch
auf mehrere Server verteilt (siehe 6.11.1, Seite 132). Damit einher geht Ausfallsicherheit
(siehe 5.1.1, Seite 98).
Mountpoints werden innerhalb des AFS als einfache symbolische Links gespeichert
und lediglich vom AFS-Client ausgewertet. Man kann deshalb auch einen
Mountpoint mit dem ln-Kommando anlegen, wobei das Linkziel jeweils dem
Output des fs lsm-Kommandos mit einem zusätzlichen Punkt entspricht.
Beispiel:

3.3 Die AFS-Datenbank 35
user@host>fs mkm test root.cell
• Ein Mountpoint wird angelegt:
• So findet man herraus, wie der Mountpoint intern codiert ist:
user@host>fs lsm test
’test’ is a mount point for volume ’#root.cell’
user@host>ln -s ’#root.cell.’ test
3.3 Die AFS-Datenbank
3.3.1 Grundlegendes
• Man hätte ihn auch so anlegen können:
Jede AFS-Zelle beinhaltet eine AFS-Datenbank. Die Datenbank ist auf jedem
der AFS-Datenbankserver vollständig gespeichert, wobei es bei Verbindungsproblemen
möglich ist, dass die Datenbank auf einigen Rechnern nicht aktuell
ist. “Einigen” steht dabei für “weniger als die Hälfte” - eine Eigenart des benutzten
Synchronisationsprotokolls UBIK.
Die Datenbank besteht aus mehreren Teilen:
VLDB : Die Volume Database speichert Informationen über die Volumes und die
Server, auf denen sie liegen. Der vlserver-Prozess verwaltet diese Daten.
PTDB : Die Protection Database beinhaltet Informationen über Benutzer und
Benutzer-Gruppen:
• Die Zuordnungen von AFSID 11 zu Benutzername.
• Die Zuordnungen von AFSID 12 zu Gruppenname.
• Eine Liste für jede Gruppe, welche Benutzer-AFSIDs zu ihr gehören.
• Metainformationen von Einträgen – also von Benutzern und AFS-
Gruppen (siehe 3.7.3.4, Seite 54):
creator : Der Benutzer, der den jeweiligen Benutzer ursprünglich angelegt
hat.
owner : Der Besitzer des Eintrages. Dieser darf Metadaten des jeweiligen
Eintrages ändern.
membership : Bei Benutzern: die Anzahl der Gruppen, in denen der Benutzer
Mitglied ist.
Bei Gruppen: Die Anzahl der Benutzer, die in der Gruppe Mitglied
sind.
group quota : Dieser für jede AFSID spezifische Wert gibt an, wieviele zusätzliche
Gruppen der entsprechende Benutzer anlegen darf.
flags : Diese Rechte definieren, wer mit dem Benutzer was machen
darf. In [ADMREF] sind die Flags genau beschrieben.
11 Dabei ist die 0 keine gültige AFSID.
12 Anhand des Vorzeichens einer AFSID kann man Gruppen und Benutzer-AFSIDs unterscheiden:
Gruppen-IDs sind immer negativ.

36 3 Technische Details zu AFS
Die PTDB wird von Fileservern kontaktiert, um z.B. festzustellen, ob ein
Benutzer zu einer bestimmten Gruppe gehört, die in einer ACL erwähnt
wird.
BDB : Die Backup Database speichert Informationen über Daten, die über das
AFS-Backup-System gesichert wurden. Dazu zählen:
• Definitionen von Volume-Gruppen, sog. (Volume-Sets). Das AFS-
Backup-System kann immer nur ganze Volume-Gruppen sichern,
nicht einzelne Volumes. Eine Gruppe kann aber auch nur ein Volume
enthalten.
• Gesicherte Volume-Sets mit ihrem Sicherungszeitpunkt sowie dem
Referenzzeitpunkt bei einer inkrementellen Sicherung.
• Bänder 13 , auf die diese Volumes-Gruppen gesichert wurden.
Der Prozess buserver ist für die Verwaltung verantwortlich. Zugriff
auf diese Datenbank erhält man mit der backup-Kommando-Familie.
Die verschiedenen Teile der Datenbank werden zwar von unterschiedlichen Prozessen
verwaltet (ptserver, vlserver, buserver), jedoch benutzen alle
diese Prozesse den selben Synchronisationsalgorithmus (mit unterschiedlichen
Ports) und müssen immer zusammen auf den AFS-DB-Servern installiert sein.
Deshalb kann man die AFS-Datenbank im Normalbetrieb als Einheit sehen.
Man kann sich die DB-Server auflisten lassen:
user@host>bos listhosts Servername
wobei Servername der Name eines AFS-File- oder DB-Servers ist.
Mit den nächsten beiden Befehlen kann man Datenbankservereinträge (DB-Server)
auf AFS-Servern (Servername) hinzufügen bzw. entfernen:
admin@afs>bos addhost Servername DB-Server
admin@afs>bos removehost Servername DB-Server
Änderungen an der AFS-DB-“Serverfarm” müssen auf jedem DB-Server einzeln
erfolgen - der entsprechende bos addhost/bos removehost-Befehl
muss also einmal für jeden AFS-Server ausgeführt werden.
Mit folgenden Kommando kann man den Zustand der Datenbankserver gründlich
testen:
user@host>instantafs.servercheck -a dns
3.3.2 Synchronisation der DB-Server
Mit dem Kommando kann man noch mehr testen, fuer die Datenbankserver
reicht aber dieser Aufruf.
Die DB-Server einer Zelle wählen regelmäßig einen Sync-Server (so etwas wie
einen Master-Server) aus, der als einziger in die Datenbank schreiben darf. Der
gewählte Sync-Server, auch Sync-Site genannt, ist der einzige Rechner, an den
sich ein Programm wenden kann, um Änderungen an den Daten durchzuführen.
Können bestimmte Clients nicht mit dem Sync-Server kommunizieren, so
können diese trotzdem das AFS als Filesystem nutzen, auch schreibend. Änderungen
an der der Datenbank sind i.d.R. Administratoren vorbehalten, weshalb
13 Das müssen nicht zwangsläufig echte Magnetbänder sein (siehe 9.2.28, Seite 206).

3.3 Die AFS-Datenbank 37
fehlender Schreibzugriff auf die Datenbank dem normalen Benutzer nicht auffallen
sollte.
Damit die Wahl des Sync-Servers erfolgreich verläuft, müssen verschiedene
Voraussetzungen erfüllt sein:
1. Alle DB-Server müssen die gleiche Liste an DB-Servern besitzen,
da sonst die zahlenmäßige Hälfte der DB-Server nicht mehr korrekt
berechnet werden kann.
2. Die Uhren der DB-Server müssen synchron laufen. Mehr als 10 Sekunden
Differenz sind kritisch.
3. Mehr als die Hälfte 14 der DB-Server müssen sich gegenseitig erreichen
können.
Warum diese Bedingungen sinnvoll sind, soll an einem Beispiel erklärt werden:
Die erste Bedingung ist nötig, damit alle Datenbankserver sicher feststellen
können, ob sie mit anderen Datenbankservern eine Gruppe bilden können, die
aus mindestens der Hälfte aller Datenbankserver der Zelle entspricht.
Es existieren in einer Außenstelle 2 Datenbankserver, im zentralen Institut jedoch
3 und die Verbindung zwischen beiden Institutsteilen ist unterbrochen.
In der Zentrale können weiterhin Änderungen in die Datenbank geschrieben
werden, während die Außenstelle das Nachsehen hat. Wird jetzt z.B. die Verbindung
wiederhergestellt und plötzlich fallen 2 der zentralen Datenbankserver
aus, so werden die 2 Server der Außenstelle und der eine aus der Zentrale eine
Gruppe bilden, die größer als die Hälfte der DB-Server ist.
Der Server in der Zentrale wird anhand der Update-Zeitstempel als der aktuellste
erkannt und die Außenstellen-Server mit diesem synchronisiert. Während
der Wahl wird geprüft, ob die Uhren synchron laufen. Würde die Wahl abgeschlossen
werden und die Uhren der Außenstelle würden weit vorraus gehen,
so könnte der einzelne Server der Institutszentrale nicht sicher als der aktuellste
eingestuft werden - evtl. würde der Datenbankinhalt sogar “downgegraded”.
Alle Datenbankteile (VLDB, PTDB, BDB) ermitteln jeweils unabhängig voneinander
eine Sync-Site. Da der benutzte Algorithmus zur Ermittlung der Sync-
Site jedoch immer derselbe ist, sollte im Normalfall (wenn kein einzelner Datenbankprozess
abgestürzt ist) eine einzelne Maschine Sync-Site aller Datenbankteile
sein.
Das für die Synchronisation der Datenbankserver untereinander verwendete
Protokoll ist in der Lage, Netzwerkunterbrechungen zu handhaben. Mit
udebug aus dem Paket openafs-client .deb können Informationen über den
Stand der Wahl abgerufen werden:
user@host>udebug Servername 7003
3.3.3 Benötigte Prozesse auf den DB-Server-Maschinen
Der Port-Parameter 7003 bewirkt, dass der vlserver kontaktiert wird.
Es ist auch möglich, die Ports (siehe 3.6, Seite 45) der anderen AFS-DB-
Serverprozesse zu benutzen und damit die Synchronisation der anderen
Datenbankteile zu prüfen.
Auf einer DB-Servermaschine müssen folgende Prozesse laufen, von denen jeder
genau einen AFS-Datenbankteil verwaltet:
14 Der Datenbankserver mit der

38 3 Technische Details zu AFS
3.4 Die Zelle
3.4.1 Organellen
bosserver : Der “init”-Prozess aller AFS-Dienste.
vlserver : Der vlserver verwaltet die Volume-Datenbank (VLDB), synchronisiert
diese auch mit jeweils allen anderen erreichbaren vlserver-
Prozessen auf anderen DB-Servermaschinen. Mit dem Kommando
vos kann auf vlserver-Funktionen zugegriffen werden, Logging-
Informationen fließen nach /var/log/VLLog.
ptserver : Der Protection-Server (ptserver) verwaltet die AFSIDs (die AFSinternen
User-IDs). Mit dem Kommando pts kann man auf ptserver-
Prozesse zugreifen. Für die Benutzung von pts ist es, immer wenn das
entsprechende Unterkommando bestimmte Privilegien erfordert, nötig,
dass der OpenAFS-Client läuft. Der ptserver schreibt das Logfile
/var/log/openafs/PtLog.
buserver : Der Backup-Server (buserver) verwaltet die Backup-Datenbank
(BDB).
Läuft einer dieser Prozesse nicht (z.B. der ptserver), muss er mit einem
Kommando folgender Form aktiviert werden:
admin@afs>bos create -server Server -instance ptserver -type simple -cmd
/usr/lib/openafs/ptserver
Den Prozess, der die Oberaufsicht führt - den bosserver - startet man so:
root@host>/etc/init.d/openafs-fileserver start
3.4.2 Das zentrale Zellenverzeichnis
AFS ist zwar ein globales Dateisystem, basiert jedoch auf eigenständig administrierten
“kleinen” Untereinheiten - den sogenannten Zellen. Zu jeder Zelle
existiert mindestens ein Superuser (i.d.R. admin), der universellen Zugriff auf
alle Server und damit auf alle Datenbanken hat.
Die Zelle enthält folgende Objekte:
• Die AFS-Datenbanken VLDB und PTDB (Volume-, Protection-DB)
• AFS-File-Server-Maschinen, die jeweils nur genau einer Zelle zugeordnet
sein können.
• AFS-Client-Computer, die ebenfalls nur zu genau einer Zelle gehören
können.
• Volumes auf den Fileservern.
Um auf eine Zelle zugreifen zu können, benötigt ein AFS-Client die IP-
Adressen der Datenbankserver dieser Zelle. Diese Liste aller öffentlichen
AFS-Zellen Adressen erhielt der AFS-Client ursprünglich in Form der Datei
/etc/openafs/CellServDB. Es existiert eine offizielle Version dieses Files, verwaltet
von Grand.Central. Die Datei ist unter
http://grand.central.org/dl/cellservdb/CellServDB
zu finden und wird allen neu gepackten OpenAFS-Client .deb -Paketen in der
aktuellen Version beigelegt. Will man die eigene Zelle öffentlich bekannt
machen, findet man unter
http://www.central.org

3.5 Der Cachemanager (AFS-Client) 39
3.5 Der Cachemanager (AFS-Client)
3.5.1 Der Client-Cache
3.5.2 Kenngrößen des Caches
3.5.2.1 Größe eines Cache-Eintrages
den entsprechenden Kontakt. Die Liste erhebt keineswegs Anspruch auf Vollständigkeit.
Es gibt verschiedene Gründe, sich nicht in die offizielle CellServDB
eintragen zu lassen:
• Die Adressen der Datenbankserver der eigenen lokalen Zelle werden per
AFSDB-Records im DNS bekannt gemacht. Das ist wohl die eleganteste
Methode. Neuere Clients können sich so immer die aktuellen Informationen
zu den Datenbankservern verschiedener Zellen besorgen - ein Update
der CellServDB ist dann weder bei Grand.Central noch auf AFS-Clients
nötig.
• Die eigene Zelle befindet sich hinter einer NAT-Firewall und kann damit
nicht von Rechnern aus dem Internet erreicht werden.
• Die eigene Zelle hat eine dynamische IP-Adresse. Zellen in der offiziellen
CellServDB benötigen eine statische IP-Adresse, der DNS-Name eines
Servers reicht nicht aus.
• Die eigene Zelle soll der Öffentlichkeit nicht bekannt sein. Man kann auf
eine solche Zelle trotzdem zugreifen - schließlich kann man die Daten
der eigenen Zelle auf seinem lokalen Client manuell eintragen.
Auf jedem Rechner, der direkt 15 auf das AFS zugreift, muss eine Client-
Software, AFS-Client oder auch Cachemanager genannt, installiert werden.
Unter 2.10 ist beschrieben, wie ein Zugriff des AFS-Clients auf das AFS
prinzipiell abläuft.
Der Cache ist integraler Bestandteil des AFS. Der AFS-Client wird deshalb
auch Cache-Manager genannt. Der Cache verwaltet eine Liste von Dateistückchen
im Verzeichnis /var/cache/openafs mit einer zum Startzeitpunkt des
Clients festzulegenden Maximalgröße. Nur root sollte Zugriff auf die Cache-
Files haben. Dateien im AFS sind zwar auf dem Server und wahlweise auch
bei der Übertragung über’s Netzwerk gut gesichert, auf der Cache-Partition des
Clients liegen sie jedoch unverschlüsselt.
Der Cache-Manager besteht aus mehreren arbeitsteiligen Prozessen, deren Namen
immer mit afs anfangen. Diese Prozesse werden als Einheit mittels des
OpenAFS-init-Skriptes /etc/init.d/openafs-client gestartet und auch wieder beendet.
Je nachdem, welche Aktionen auf der Maschine geplant sind, sollte man die
Chunksize (die Maximalgröße eines gecachten Dateistückchens) einstellen, um
die Performance zu verbessern. Default ist 2 16 Byte für Caches auf Platte und
in der RAM-Disk.
• Sollen z.B. Programme compiliert oder umfangreiche Datenbestände aus
kleinen Textdateien durchsucht werden (große Dateimengen), sind kleinere
Chunks besser (z.B. 32kB).
15 Es existierten NFS-Gateways für Rechner, auf denen kein AFS-Client läuft. Diese Gateways laufen
jedoch nur unter Solaris. Außerdem ist die Kommunikation NFS-Gateway ↔ Client natürlich
weder signiert noch verschlüsselt.

40 3 Technische Details zu AFS
3.5.2.2 Anzahl der gleichzeitig benutzten Volumes
3.5.2.3 Größe des Caches
3.5.2.4 Volume-Cache
• Werden z.B. Videos (große Dateien) abgespielt, sind größere Chunks
günstiger (z.B. 4MB).
Die Chunksize ist nur als volle Zweierpotenz wählbar und wird mit der afsd-
Option -chunksize definiert. Gültige Größen sind 2 0 (1 Byte) bis 2 30 (1
GByte).
Configfile: Geändert wird sie, indem man den Parameter -chunksize Größe
in den OPTIONS-String in der Datei /etc/openafs/afs.conf auf dem gewünschten
AFS-Client einträgt. Größe ist der Logarithmus dualis aus der gewünschten
Chunk-Größe.
Normalerweise sollte es nicht nötig sein, mit vielen Volumes gleichzeitig zu
arbeiten, da der AFS-Namensraum üblicherweise eher tief als breit ist.
Beispiel: Wenn ein Verzeichnis viele Volumes (z.B. 1000) eingemountet sind,
dann trifft man mit der Debian-Standardeinstellung von 70 auf Probleme. Wenn
man Informationen über die Volumes in einem solchen Verzeichnis einholt (z.B.
mittels ls -la), dann verdrängen die aktuelle gelesenen Volumes immer andere,
deren Daten noch gecacht werden - der Cache ist also vollkommen wirkungslos.
Configfile: In /etc/openafs/afs.conf muss man den Wert ändern, der hinter
-volumes steht.
Empfehlung: Wie gross die Anzahl sein muss, hängt direkt davon ab, wie die
jeweilige zelle konstruiert ist.
Die Größe des Caches wird in ganzen 1kB-Blöcken in der Datei /etc/openafs/cacheinfo
definiert. Sie darf unter Unix 95% der Größe des Filesystems, auf
dem der Cache liegt, nicht überschreiten - der Cachemanager würde dann mit
einer Warnung den Start verweigern.
Die optimale Größe des Caches ist von den auf dem jeweiligen Rechner erwarteten
Zugriffsmustern auf das AFS sowie vom Betriebssystem abhängig. Hier
einige Faustregeln:
• Wenn nicht oft auf das AFS zugegriffen wird, kommt man mit einem
Cache von 15 MB aus.
• Wird unter Unix im AFS viel mit großen Dateien gearbeitet, ist eine separate
Partition mit 10GB oder größer sinnvoll.
• Unter 32-bittigem Windows ist die sinnvoll nutzbare Cachegröße auf
1GB begrenzt.
• Bei den unter 64-bittigem-Windows möglichen Cachegrößen sollen man
beachten, dass dem Cache immer eine gewisse Menge physischer Speicher
gegenüberstehen muss. Laut Jeffrey Altman sind 12GB Cache mit
1GB RAM ok, 20GB Cache mit GB RAM sind dagegen zuviel. Eine
Maschine mit 8GB RAM sollte hingegen eine Cachegröße von 60GB
verkraften.
Der AFS-Client kann nur eine bestimmte Anzahl an Volume-Informationen
speichern. Glücklicherweise kann man diese maximale Anzahl beim Start mit

3.5 Der Cachemanager (AFS-Client) 41
3.5.3 Verwaltung von Daten im Cache
dem Parameter -volumes Größe einstellen.
Relevant ist diese Maximalzahl z.B. dann, wenn man oft in Verzeichnissen mit
sehr vielen Mountpoints arbeitet. Ist der Volume-Cache dann zu klein, ist jedes
ls -la eine Qual.
Je nach Verwendungszweck des Clients kann man den Unix-Cachemanager anweisen,
die Chunks auf eine der folgenden Arten zwischenzuspeichern:
Speicher : Der Cache im Speicher (afsd-Option -memcache) ist prinzipiell
schneller, als einer, der auf Filezugriffe angewiesen ist. Aus noch ungeklärtem
Grund ist das aber nicht der Fall. Man sollte von dieser Option
vorerst absehen (Stand OpenAFS 1.2.11). Der Cache verliert mit einem
Neustart des Cachemanagers natürlich seinen Inhalt.
Festplatte : Ein Cache auf einer Plattenpartition kann um Größenordnungen größer
sein, als ein Cache im Speicher (viele Gigabyte). Vor allem, wenn auf
Server zugegriffen werden soll, zu denen nur eine geringe Netzwerkbandbreite
existiert, bietet es sich an, große Caches zu benutzen, die auch
einen Neustart überstehen. Auch wenn auf größere Datensätze mehr als
einmal nur lesend zugegriffen wird, lohnt sich diese Art von Cache.
RAM-Disk : Eine RAM-Disk ist die schnellste Cache-Variante, jedoch ist auch sie
durch die maximale Hauptspeichergröße limitiert. Die Benutzung von
speziellen Speicher-Filesystemen wie tmpfs ist nicht möglich - ext2/ext3
ist Pflicht.
Installiert man das Paket openafs-ramdisk .deb
root@host>apt-get install instantafs-ramdisk
wird immer beim Booten direkt vor dem Start des openafs-client eine
Ramdisk unter /var/cache/openafs gemountet.
Kommt ein Platten- oder RAM-Disk-Cache zum Einsatz, greift der Cachemanager
auf das Verzeichnis /var/cache/openafs zu. An dieser Stelle muss er
ein ext2-Dateisystem vorfinden. Es ist möglich, die root-Partition als Cache
zu benutzen. Da der Cachemanager aber von einer bestimmten (einstellbaren)
Größe des Caches ausgeht und diese Größe nicht im laufenden Betrieb
anpassen kann, ist es günstiger, eine eigene Partition exklusiv als Cache zu
benutzen.
Es ist selbstverständlich auch möglich, ein per Loopback gemountetes Filesystem,
also eine einzelne Datei als Cache zu benutzen. Auf dieses Weise ist es
möglich trotz eines nicht unterstützten root-Filesystems (XFS, Reiser, JFS, ...)
einen Plattencache auf der root-Partition zu betreiben.
Bei Benutzung von Platten- oder Ramdisk-Cache sind folgende Dinge unbedingt
zu beachten:
1. Es dürfen nur die Filesystemtypen ext2 und ext3 benutzt werden. Alle
anderen führen mit hoher Wahrscheinlichkeit zu Datenverlust!
2. Wird die Cachepartition durch einen anderen Prozess gefüllt, so dass der
Cachemanager keinen freien Speicher mehr findet, dann droht Datenverlust.
Aus diesem Grund ist dringend eine eigene Partition oder eine RAM-
Disk für den Cache zu empfehlen.

42 3 Technische Details zu AFS
3.5.4 Cache-Kohärenz
3.5.4.1 Eine Aktualitätsgarantie vom AFS-Server
3.5.5 Sicherheitshinweise
Unter Windows wird als Cache immer ein einzelnes File benutzt, auf das per
Memory-mapped-IO zugegriffen wird.
Empfehlung für Linux: Benutzen Sie eine Ramdisk. Die Installation des Paketes
openafs-ramdisk .deb erledigt das automatisch.
AFS garantiert die volle Kohärenz der Caches auf allen Clients. Fordert der
Cachemanager ein File von einem Server an, so garantiert der Server damit,
dass er den Client benachrichtigt, wenn das File geändert wird. Sobald ein
File auf dem Server geändert wird, schickt der Server an alle Clients, die eine
“callback”-Garantie erhalten haben, einen Hinweis, dass das entsprechende
File zu verwerfen ist.
Schreibt ein Client in ein File im AFS, so werden die Zugriffe im Cache-
Manager gepuffert. Der Cachemanager kontaktiert den Fileserver, wenn
mindestens eine der 3 Voraussetzungen erfüllt sind:
• Das File wurde mit close() geschlossen
• Die Funktion fsync() wurde auf das File angewandt. Diese Funktion
blockiert, bis der Fileserver die Bestätigung geschickt hat, dass das File
erfolgreich gespeichert wurde.
• Der Cachemanager benötigt freie Chunk-Slots, findet aber keine.
Es gibt jedoch keine Garantie, dass der Cachemanager nicht trotzdem zwischendurch
Teile von Dateien auf den Fileserver schreibt.
Wird der Cachemanager heruntergefahren, kontaktiert er schnell noch alle Fileserver,
von denen ihm vorher Callback-Garantien gegeben wurden und gibt diese
Garantien zurück. In jedem anderen Fall würden die Fileserver sonst evtl.
unnötig versuchen, den jeweiligen Cachemanager bei Änderungen zu kontaktieren.
Der Datencache des AFS-Clients bleibt nach einem Herunterfahren des Clients
erhalten - nur der stat()-Cache wird gelöscht. Soll später eine Datei benutzt
werden, die sich noch im Cache befindet, muß der Client zumindest eine
stat()-Anfrage an den entsprechenden Fileserver richten. Dadurch erfährt
er, ob die Datei verändert wurde. Wurde sie es nicht, kann auf die Datei aus
dem Datencache zugegriffen werden.
Das Callback-Prinzip verursacht Probleme mit AFS-Clients hinter NAT-
Routern (siehe A.5, Seite 229).
Im Gegensatz z.B. zu NFS-Netzen ist eine kompromittierte 16 AFS-Client-
Maschine unkritisch, solange kein Nutzer daran arbeitet. Natürlich kann auch
das beste Netzwerkdateisystem nichts ausrichten, wenn ein Angreifer eine
Client-Maschine (root-)kompromittiert und z.B. Tastatureingaben (und damit
Passwörter) mitloggt.
Der Cache (siehe 3.5.1, Seite 39) ist u.U. ebenfalls ein Sicherheitsrisiko. Wird
als Cache eine Festplattenpartition benutzt, so kann ein mit einer Knoppix
bewaffneter Angreifer ohne Authentifikation an die im Cache abgelegten
16 z.B. wenn das Root-Passwort bekannt wurde,

3.5 Der Cachemanager (AFS-Client) 43
3.5.6 Konfigurationsoptionen
3.5.6.1 Verschlüsselung
3.5.6.2 Fakestat
root@host>fs setcrypt on
root@host>fs setcrypt off
Dateifragmente. In dem Cache-Verzeichnis kann man zwar keine Verzeichnisstrukturen
oder Dateinamen einfach erkennen, jedoch liegen die Dateien
im Cache im Klartext. Der Angreifer scheitert natürlich, wenn der Cache
auf einer RAM-Disk oder direkt im Speicher liegt - zumindest, wenn er kein
root-Passwort hat.
Es besteht ausserdem noch die Moeglichkeit, den Plattencache mit einem Wegwerfpasswort
zu verschlüsseln und bei jedem Booten neu anzulegen. Das Paket
loop-aes-utils .deb unterstützt so etwas.
Der Administrator hat bei der Konfiguration des AFS-Clients etwas Spielraum.
Hier soll auf einige wichtige Konfigurationsoptionen eingegangen werden.
AFS signiert immer alle übertragenen Daten. Die Verschlüsselung ist jedoch
optional. Verschlüsselung für den aktuellen Client anschalten:
Verschlüsselung abschalten:
Beide Kommandos werden nur vom lokalen Superuser akzeptiert. Durch eine
Zeile in /etc/openafs/afs.conf.client lässt sich steuern, ob Verschlüsselung benutzt
werden soll.
Verschlüsselung wird nur bei authentifiziertem Zugriff (also, wenn ein gültiges
Token vorhanden ist) benutzt.
Empfehlung: Es sollte aktiviert werden, die Performance wird nur geringfügig
von der Verschlüsselung gedrosselt.
Configfile: Verschlüsselung wird bei Start des Cachemanagers aktiviert, wenn
in der Datei /etc/openafs/afs.conf.client die Zeile AFS_CRYPT=true steht.
Die afsd-Option -fakestat bewirkt, dass beim Aufruf der stat()-
Funktion für einen Volume-Mountpoint das entsprechende Volume nicht extra
angefordert wird. Dadurch sind u.U. gezeigte Metadaten (mtime, modebits, ...)
nicht korrekt, der Zeitgewinn kann jedoch enorm sein.
Beispiel: Das AFS-Verzeichnis /afs/cbs.mpg.de/user enthält Mountpoints zu
Homedirectories, jedes in einem eigenen Volume, von 1000 (!) verschiedenen
Benutzern. Das Kommando
user@host>ls -la /afs/cbs.mpg.de/user
(oder auch z.B. das Anzeigen des Verzeichnisses in einem Filemanager) würde
jetzt bewirken, dass der AFS-Client Informationen zu 1000 verschiedenen
Volumes auf möglicherweise vielen verschiedenen Servern anfordert. Mit der
-fakestat-Option wird nur ein Verzeichnis ausgelesen, als Metadaten der
Mountpoints werden Default-Werte (mtime=01.01.1970, modebits=0755, ...)
benutzt. Die Option lässt sich im File /etc/openafs/afs.conf.client aktivieren.
Configfile: Fakestat wird beim Start des Cachemanagers aktiviert, wenn in der
Datei /etc/openafs/afs.conf.client die Zeile AFS_FAKESTAT=true steht.

44 3 Technische Details zu AFS
3.5.6.3 Dynamic Root
3.5.6.4 SetUID
Empfehlung: Es sollte aktiviert werden.
Die -dynroot-Funktion bewirkt, dass unter /afs nicht das AFS-Rootvolume
gemountet wird. An seine Stelle tritt ein virtuelles Verzeichnis, das Mountpoints
für jede Zelle enthält, die in /etc/openafs/CellServDB erwähnt wird. Dadurch
wird der Administrator von der Aufgabe befreit, das AFS-Rootvolume an neue
Versionen der CellServDB anzupassen.
Configfile: Der dynamische AFS-Root wird beim Start des Cachemanagers aktiviert,
wenn in der Datei /etc/openafs/afs.conf.client die Zeile AFS_DYNROOT=true
steht.
Empfehlung: In einem per NAT ans Internet angeschlossenen Netzwerk sollte
es abgeschaltet sein. In jedem anderen Fall bringt es Komfort-Pluspunkte beim
Zugriff auf andere Zellen, wenn es aktiviert ist.
Auf jedem Client-Computer lässt sich für jede Zelle separat einstellen, ob dem
SetUID-Bit an Dateien in Volumes der entsprechenden Zelle zu trauen ist.
SetUID-Auswertung anschalten:
fs setcell Zellenname -suid
SetUID-Auswertung ausschalten:
fs setcell Zellenname -nosuid
3.6 Das AFS-Netzwerkprotokoll (Layer 3 und 4)
Beide Kommandos werden nur von lokalen Superusern akzeptiert. Das SetUID-
Bit bewirkt nur eine Änderung der UID auf dem lokalen Rechner, nicht der
AFS-Identität im Netzwerk.
Empfehlung: Es sollte nur dann aktiviert werden, wenn man plant, SetUID-
Binaries über das AFS zur Verfügung zu stellen.
Sowohl AFS-Server als auch Clients kommunizieren ausschließlich per UDP/IP
und arbeiten mit festen Portadressen. Daraus folgen 2 Dinge:
• Pro öffentlicher IP-Adresse kann maximal ein AFS-Server erreichbar
sein. AFS kennt keine virtuellen 17 Server. Deshalb kann unter einer
öffentlichen IP auch nur maximal eine Zelle erreichbar sein.
• Zellen, deren Fileserver innerhalb eines per NAT maskierten Netzwerkes
stehen, haben praktisch keine Chance, global erreichbar zu sein. Das kann
man höchstens umgehen, indem die Fileserver in einer mit öffentlichen
IP-Adressen ausgestatten DMZ aufgebaut werden und der NAT-Router
zwischen internem Netzwerk und DMZ lediglich routet und nicht masqueriert.
Damit AFS-Clients in einem durch einen NAT-Router ans Internet gekoppelten
Netz auf AFS-Server außerhalb des Netzes zugreifen können, müssen einige
Dinge beachtet werden (siehe 3.5.4, Seite 42). Die von AFS benutzten Ports
sind in Tabelle 3.6 aufgeführt.
17 wie z.B. bei HTTP-Servern üblich

3.6 Das AFS-Netzwerkprotokoll (Layer 3 und 4) 45
Prozess UDP-Port Benötigt auf ...
bosserver 7007 allen AFS-Servern
Cachemanager 7001 allen Rechnern, die auf das AFS auf Datei-
(Kernelmodul)
systemebene zugreifen müssen (hauptsächlich
Arbeitsplatzrechner)
fileserver 7000 allen AFS-Fileservern (Die Funktionen der
Prozesse sind unter 3.8.4 erläutert.)
volserver 7005
ptserver 7002 allen AFS-Datenbankservern (Die Funktionen
der Prozesse sind unter 3.3 erläutert.)
Diese Portnummerm werden für das udebug-
Kommando benötigt.
vlserver 7003
buserver 7021
butc 7025-
7032
dem Backup-Server (siehe 5.2.3.1, Seite 102)
Tabelle 3.1: UDP-Ports von AFS-Client und -Server. Hinweis: Jeder butc
braucht nur einen Port. Läuft nur z.B.ein butc-Prozess, wird auch nur Port
7025 benutzt.
Einige weitere Ports werden für Dienste rund um das AFS benutzt, sind jedoch
nicht direkt AFS-spezifisch bzw. ausschliesslich lokal. In Tabelle 3.6 sind sie
aufgelistet.
Richten Sie Firewalls, die AFS-bezogene Pakete auf ihrem Weg zwischen
Client und Server bzw. von Server zu Server passieren, entsprechend ein. Es
sollte kein NAT zwischen Rechnern einer Zelle zum Einsatz kommen.
Der AFS-Client braucht für Lesezugriff auf eine AFS-Zelle nur eine Information:
den Namen der Zelle, zu der er gehört 18 . Für Schreibzugriffe benötigt der
Client den Namen der Kerberos-Realm. Der Name der Kerberos-Realm kann
u.U. vom Zellennamen abweichen. Dann sind zusätzliche Informationen in /etc/krb5.conf
nötig. Auf diesen speziellen Fall wird diese Dokumentation jedoch
nicht eingehen (siehe 2.3, Seite 18).
Die Datenbanken des AFS und das Netzwerkprotokoll sind fest auf IPv4 eingestellt
und können derzeitig nicht mit IPv6-Adressen umgehen.
3.6.1 Server/Clients mit mehreren IP-Adressen/Netzwerkkarten
Ist ein AFS-Client oder Server mit mehreren IP-Adressen ausgestattet (z.B.
weil er gleichzeitig ein Router ist), kann es wünschenswert sein, die AFS-
Kommunikation auf bestimmte Interfaces zu beschränken. AFS-Prozesse
binden sich immer an alle IP-Adressen - das läßt sich nicht ändern.
Allerdings ist es möglich, Hinweise zu geben, welche Adressen eines Rechners
zu benutzen sind. Die zu benutzenden IP-Adressen schreibt man dazu (eine
numerische IP-Adresse pro Zeile, jede Zeile durch \n terminiert) in die Datei
NetInfo. Das korrekt Verzeichnis fuer dieses File zu bestimmen, ist etwas tricky
und von der Umgebung abhängig:
Debian Sarge (OpenAFS 1.3+) : /etc/openafs/server-local/NetInfo
Debian Woody (OpenAFS 1.2) : /var/lib/openafs/NetInfo
18 Ältere AFS-Client-Implementationen benötigen zusätzlich die Datei /etc/openafs/CellServDB,
um die DB-Server der Zelle zu finden.

46 3 Technische Details zu AFS
Protokoll Port Erklärung
DNS 53 Sobald AFSDB-Records benutzt werden, was
unter InstantAFS zwingend ist, wird DNS unbedingt
benötigt.
Achtung:Es geht wirklich kein anderer Namensdienst
(NIS, NIS+, LDAP, ...).
Kerberos5 88 Kerberos ist dann nötig, wenn authentifizierter
Zugriff auf das AFS statfinden soll (sprich:
fsync 2040/tcp
(nur lokal)
ptdb-nss 6998/udp
(nur lokal)
praktisch immer).
Über diesen TCP-Kanal kommunizieren unter
OpenAFS die Prozesse volserver und
fileserver. z.B. kann der volserver so den
fileserver anweisen, eine RO-Instanz zu sper-
ren, wenn diese gerade upgedatet wird.
Auf diesem Port lauscht ein lokaler Daemon,
der für die Auslösung von AFS-Benutzern zu
AFSIDs und umgekehrt zuständig ist (siehe
A.2, Seite 224).
acall 6999/tcp Auf diesem Port wartet auf jedem acall-
Server (siehe 7.6.2, Seite 149) das Programm
instantafs.acall-server auf Kommandos.
Tabelle 3.2: TCP/UDP-Ports, die zusätzlich zu den Standard-AFS-Ports
üblicherweise zum Einsatz kommen.
Transarc-Pfade : /usr/vice/etc/NetInfo
Das hat für AFS-Client und -Server-Prozesse unterschiedliche Auswirkungen:
AFS-Fileserver : Fileserver registrieren sich bei jedem Neustart in der VLDB. Nur die
angegebenen Adressen werden in der VLDB registriert.
AFS-DB-Server : Datenbankserver benutzen nur angegebene Adressen zur UBIK- Kommunikation.
AFS-Clients : AFS-Clients senden normalerweise alle ihre IP-Adressen an Fileserver,
mit denen sie kommunizieren. Die Fileserver benutzen dann diese Adressen,
um im Falle von Änderungen an Daten im AFS-Cache des Clients
Cache-Bereiche für ungültig zu erklären (siehe 3.5.4, Seite 42). Mit dem
NetInfo-file kann man die Adressen einschränken, über die Callbacks entgegengenommen
werden sollen.
Hinweise:
• Das NetInfo-File ändert nichts an den Port-Bindings. Alle anderen Adressen
können trotzdem benutzt werden - die jeweiligen Ports bleiben an allen
Netzwerkinterfaces offen. Wenn die entsprechenden Adressen wirklich
geschützt werden sollen, muß ein Paketfilter her.
• Nach einer Änderung an NetInfo sind die AFS-Prozesse auf dem entsprechendem
Rechner neu zu starten (Rechnerneustart geht natürlich auch).
• Clients, die bereits von einer Adresse eines Servers wissen, die später auf
diesem Server durch Benutzung von NetInfo deaktiviert wird, benutzen
diese Adresse auch weiterhin. Benutzer an solchen Clients merken keinen
Unterschied zu vorher. Mit dem Neustart eines solchen Clients (oder dem
Neustart des Cachemanagers auf ihm) werden dann jedoch nur noch die

3.7 Das Sicherheitsmodell 47
3.7 Das Sicherheitsmodell
3.7.1 Der AFS-Key
3.7.2 Authentifikation
gewünschten Server-IP-Adressen benutzt.
• Manchmal funktioniert NetInfo nicht wie gewünscht. In diesem Fall legt
man die Datei NetRestrict an und trägt dort die Adressen ein, die man
explizit nicht veröffentlichen will.
Die Sicherheit einer AFS-Zelle basiert darauf, dass ein zellenspezifischer
symmetrischer Schlüssel 19 geheim bleibt. Pro Zelle existiert genau ein solcher
Schlüssel. Der Schlüssel muss auf jedem File- und Datenbank-Server der Zelle
im Klartext liegen. Die große Schwäche von AFS ist, dass, wenn dieser Schlüssel
kompromitiert wurde, die ganze Zelle (und damit jeder einzelne Server) als
geknackt gilt 20 .
Der saubere 21 Weg ist dann, die Zelle mit einem neuen AFS-Key komplett neu
zu installieren. Ansonsten muß man auf andere Weise sicherstellen, daß von
einem Angreifer, dem dieser Schlüssel in die Hände fiel, keine Hintertüren installiert
wurden.
Die Authentifikation von Benutzern am AFS erfolgt ausschließlich über Kerberos.
In den Anfangstagen von AFS kam dafür ein spezieller Kerberos-Server
(KA-Server) zum Einsatz. Heute sind auch andere Kerberos-Server nutzbar.
Hier eine Liste, die keinen Anspruch auf Vollständigkeit erhebt:
• AFS-kaserver, der Original-AFS-Authentifikationsserver. Er basiert
auf einer Vorversion des Kerberos4-Protokolls und sollte bei Neuinstallationen
nicht mehr verwendet werden.
• MIT-Kerberos5, die derzeitige Kerberos-Version vom MIT. In dieser Dokumentation
wird ausschließlich auf diese Kerberos-Implementation eingegangen.
• Heimdal-Kerberos - die Kerberos-Implementation der KTH Schweden
• Andere Kerberos-Implementationen (z.B. von Microsoft)
Alle Kerberos5-Server benötigen derzeitig noch einen Ticket-Konverter (krb524d 22
bei MIT-Kerberos5), der auf allen Kerberos5-Servern laufen muss, da AFS intern
nur mit Kerberos-4-Tickets arbeiten kann. Im Prinzip kann AFS jedoch mit
allen ticketbasierten Authentifikationsprotokollen umgehen (z.B. GSSAPI), es
muss nur jeweils eine Methode zur Verfügung gestellt werden, das Ticket für
den AFS-Dienst in einen Token umzuwandeln.
Ziel der gesamten Prozedur ist dabei immer, ein gültiges AFS-Token zu erhalten.
Das Token ist nötig, um authentifizierten Zugriff auf das Filesystem zu
haben.
19 der des-cbc-crc-Kerberos-Schlüssel des afs-Principals
20 Abhilfe würden separate Schlüssel für jeden einzelnen Server schaffen (so wie unter DFS, dem
aus anderen Grund gescheiterten Nachfolger von AFS) - das ist jedoch im AFS so nicht machbar.
21 um evtl. installierte Hintertüren auszuschalten
22 kerberos 5 to kerberos 4 daemon

48 3 Technische Details zu AFS
3.7.2.1 Der Ablauf einer Authentifikation unter AFS
user@host>kinit Benutzername
3.7.2.2 Zeitlich begrenzte Authentifikation
Eine Authentifikation läuft nun wie folgt ab:
1. Der Benutzer fordert vom Kerberos-Server ein TGT (Ticket Granting
Ticket). Das geht per PAM (mit dem libpam_krb5.so-Modul) oder manuell,
mit dem folgendem Befehl 23 :
Dieser Schritt ist die eigentlich Authentifikation.
Das TGT berechtigt dazu, vom KDC 24 Tickets für spezielle Dienste anzufordern
- solange das TGT nicht abgelaufen ist. Die Ablaufzeit eines
angeforderten Tickets ist immer mit der des TGT identisch.
2. Der Benutzer fordert ein Ticket für den Dienst afs in einer bestimmten
Realm vom Kerberos-Server an.
3. Das Ticket für afs wird in einen Token umgerechnet, der im Kernel des
Clients abgelegt wird. Es können auch Tokens mehrerer Zellen gleichzeitig
im Kernel liegen - mehrere Tokens der selben Zelle können nicht
gleichzeit von einer Anwendung benutzt werden. Der Kernel kann jedoch
Tokens mehrere Benutzer (auch aus der gleichen Zelle) enthalten.
Die Schritte 2 und 3 können mit dem Kommando
aklog 25 manuell ausgeführt werden.
Eine einfachere Möglichkeit, mit Tokens zu arbeitet bietet tokenmgr, ein Perl-
Skript, das im User-Primer genauer beschrieben ist. Außerdem sollten beim
Einloggen die PAM-Module libpam_krb5.so und libpam_openafs_session.so
die Authentifikation automatisch erledigen und TGT sowie anschließend das
Token automatisch holen.
Die Authentifikation geschieht normalerweise vom Benutzer unbemerkt während
der Anmeldung (z.B. am Display-Manager kdm). Die pam-Module
pam_krb5.so und pam_openafs_session.so sorgen dafür. Da für die Authentifikation
per Kerberos das Benutzerpasswort zwingend notwendig ist, kann eine
Anmeldung am AFS auch nur dann automatisch erfolgen, wenn das Passwort 26
zur Verfügung steht.
Kerberos5 ist ein ticketbasiertes Authentifikationssystem. Tickets sind zeitlich
nur begrenzt gültig. Der Administrator hat eine sinnvolle Gültigkeitsdauer für
die ausgestellten Tickets festzulegen. Dabei sind primär die maximale Gültigkeit
von folgenden Tickets wichtig:
TGT : Dieses Ticket berechtigt zum Anfordern der eigentlich interessanten
Service-Tickets. Es wird benötigt, um ein afs-Ticket,also ein Ticket des
Services afs, anzufordern.
afs : Aus dem afs-Ticket wird der eigentlich interessante AFS-Token extrahiert.
Der extrahierte Token läuft zum selben Zeitpunkt ab, wie das afs-
Ticket.
23 kinit wird auch von tokenmgr (siehe 9.2.23, Seite 203) benutzt
24 Key Distribution Center - also ein Kerberos-Server
25 aklog ist ein Zusatzprogramm aus dem AFS-Kerberos5-Migration-Kit (openafs-krb5 .deb ),
AFS basiert eigentlich auf Kerberos4.
26 Man kann auch sog. Keytabs einsetzen. Diese Methode ist für Benutzerlogins jedoch unpraktisch.

3.7 Das Sicherheitsmodell 49
3.7.2.3 PAGs
Basierend auf der Annahme, dass die meisten Arbeitnehmer ihren Tag im Büro
relativ regelmäßig beginnen, ist 26h eine sinnvolle Gültigkeitsdauer. So kann
man sich früh am Rechner einloggen und auch einmal (was jedoch nicht empfohlen
ist) am Abend nur die Oberfläche sperren anstatt sich auszuloggen. Am
nächsten Morgen ist dann das Ticket noch gültig - evtl. nachts laufende Programme
wurden nicht durch ein ungültiges Token unterbrochen. Entsperrt der
Benutzer nun die grafische Oberfläche, so kann das eingegebene Passwort verwendet
werden, um eines neues TGT zu holen und daraus ein neues Token zu
erzeugen.
Die Gültigkeitsdauer von Kerberos5-Tickets beträgt per Default 10h, lässt sich
aber beeinflussen (siehe 3.10.7, Seite 65).
Eine PAG (Process Authentication Group) ist eine Gruppe zusammengehöriger
Prozesse, die auf gemeinsame Authentifikationsinformationen zugreifen können.
Unter Linux arbeitet ein AFS-Benutzer, der sich z.B. per XDM, KDM oder SSH
einloggt, üblicherweise in einer PAG.
Diese Prozesse besitzen dann alle Tokens gemeinsam - mit dem Effekt, dass
wenn der Token in einem Prozess der Gruppe manipuliert 27 wird, es sich auch
auf alle anderen Prozesse der Gruppe auswirkt.
Unter OpenAFS werden PAGs durch die Mitgliedschaft in bestimmten 28 Unix-
Gruppen gebildet.
3.7.2.3.1 Wie weiss man, ob manuser@host>tokenmgr in einer PAG ist? -c
3.7.2.3.2 Wozu das alles? Ohne PAGs wird ein Token der numerischen UID
des Prozesses zugeordnet, der den Token angefordert hat. Alle anderen Prozesse
mit der selben UID (die nicht in einer PAG sind!) können dann auf den Token
zugreifen und im AFS mit diesem Token Dateien lesen/schreiben.
Kritisch ist das z.B. in folgenden Fällen:
• wenn unter einer UID (z.B. root) mehrere Serverprozesse (z.B. Web- und
FTP-Server) mit unterschiedlichen Rechten (also unterschiedlichen AFS-
Token) laufen sollen
• wenn ein Benutzer mit su seine UID wechselt und dabei jedoch weiterhin
authentifiziert auf das AFS Zugreifen will
• wenn Kommandos mit anderen Rechten ausgeführt werden sollen, als die
gerade benutzten, man jedoch trotzdem mit anderen Programmen weiterarbeiten
will
3.7.2.3.3 Wie benutzt man PAGs? Normale Benutzer, die nur eMail lesen
wollen, werden mit PAGs nicht viel zu tun haben. Das OpenAFS-PAM-Modul
sorgt beim Einloggen (z.B. per kdm oder an der Konsole) dafür, dass die Session
in einer PAG ausgeführt wird. Auch das für InstantAFS modifizierte ssh .deb -
Paket sorgt für eine PAG beim Login.
27 z.B. aktualisiert oder gelöscht
28 Die Numerische GID dieser Gruppen haben bestimmte mathematische Eigenschaften.

50 3 Technische Details zu AFS
user@host>su -
Weitere Informationen findet man in der InstantAFS-Anleitung für Benutzer.
3.7.2.3.4 Mehrere Tokens benutzen Eine PAG bindet eigentlich keinen Token
direkt an eine Gruppe von Prozessen, sondern einen Tokencontainer. Da
man auch mehrere Tokens (für unterschiedliche Zellen) gleichzeitig benutzen
kann, macht es sinn, diese alle an eine PAG zu binden. Somit ist die PAG ein
Gruppe von Prozessen mit dem selben Token-Behälter.
3.7.2.3.5 Unter Linux zu beachten
Ungewollte PAG-Mitgliedschaft Folgendes Szenario sei gegeben:
Ein Benutzer ist auf einem Rechner eingeloggt, befindet sich in einer PAG und
muß einen Serverprozess neu starten. Er wird zu root
bleibt aber weiterhin in der PAG und starten den wichtigen Serverprozess neu:
root@host>/etc/init.d/apache force-reload
Der neue Serverprozess läuft jetzt in der PAG des Benutzers, hat also i.d.R.
Rechte, die er nicht haben sollte.
Lösungen:
• Unter Kernel 2.4 schafft unpagsh (Paket openafs-tools .deb ), das jedoch
nur als root eingesetzt werden kann, Abhilfe:
user@host>su -
root@host>tokenmgr -c
We’re inside a PAG
root@host>unpagsh
root@host>tokenmgr -c
No PAG detected.
root@host>/etc/init.d/apache stop root@host>/etc/init.d/apache start
Der Serverprozess läuft jetzt ohne besondere AFS-Rechte.
• Ab Kernel 2.6 funktioniert das jedoch nicht mehr. Hier muss man sich
durch Tricks behelfen - z.B. so:
user@host>su -
root@host>echo ’/etc/init.d/apache stop;/etc/init.d/apache start’ | at now
Das geht natürlich nur solange, wie der at-Daemon selbst nicht innerhalb
einer PAG läuft.
Ungewollte Mitgliedschaft in Unix-Gruppen Wird eine neue PAG erzeugt
(was jeder Benutzer beliebig oft machen darf), dann werden dem entsprechenden
Prozess 2 neue GIDs in die Liste der Gruppenmitgliedschaften geschrieben.
Diese GIDs kommen aus dem Bereich 0x7F 00 bis 0xBF 00 , haben aber gleiche
Autorisationsfunktionen wie andere GIDs. Sind diese GIDs zufällig schon
vergeben, dann ist der entsprechende Prozess plötzlich Mitglied in einer Unix-
Gruppe und erhält dadurch u.U. Rechte, die ihm gar nicht zustehen. Durch geschicktes
Erstellen von PAGs kann das ein Angreifer auch in gewünschte Bahnen
lenken - also Mitglied einer bestimmten Gruppe werden.

3.7 Das Sicherheitsmodell 51
3.7.3 Autorisation
3.7.3.1 Zugriff auf das Filesystem
3.7.3.2 Die verschiedenen ACL-Rechte
Es hat sich gezeigt, dass vor allem die Praxis, jedem Benutzer auch gleich eine
Gruppe zuzuweisen vor allem bei größeren Netzen dazu führt, dass die unerreichbar
hohen GIDs plötzlich vergeben werden und mit dem Bereich der PAGs
kollidieren.
Lösung: GIDs aus dem Bereich 0x7F 00 bis 0xBF 00 nicht benutzen. In einer
AFS-Zelle werden Unix-Gruppen für Filezugriffe sowieso nicht ausgewertet.
AFS kennt nur Rechte für Verzeichnisse. Die Files in einem Verzeichnis erben
automatisch die Rechte des Verzeichnisses. Sollen Dateien in einem Verzeichnis
mit unterschiedlichen Rechten ausgestattet werden, können diese aber in
andere Verzeichnisse verschoben werden und durch einen symbolischen Link
im eigentlichen Verzeichnis ersetzt werden.
Es existieren einige Besonderheiten, die bestimmten Nutzern implizit Rechte
verleihen, die sie laut ACLs eigentlich gar nicht hätten (siehe 3.7.3.3, Seite 52).
Zugriffe auf das Filesystem werden durch ACLs (Access Control Lists) geregelt.
ACLs bestehen aus einer Liste von Benutzern oder AFS-Gruppen (siehe
3.7.3.4, Seite 54), denen jeweils bestimmte Rechte zugeordnet sind. Jedem Verzeichnis
sind 2 ACLs zugeordnet: eine positive (normal rights) und eine negative
(negative rights). Beim Auswerten des Zugriffsrechts eines Benutzers auf
eine Datei wird zuerst die positive ACL des Verzeichnisses abgearbeitet und alle
Rechte, die am entsprechenden Benutzer bzw. an Gruppen, in denen er Mitglied
ist, stehen, ihm angerechnet. Analog wird dann die negative ACL abgearbeitet,
die dort jeweils gefundenen Rechte, von den in der positiven ACL evtl. erworbenen
abgezogen.
Das Kommando achmod (siehe 9.2.8, Seite 196) kann benutzt werden, um
ACLs von Verzeichnissen anzuzeigen und zu manipulieren.
Sicherheitstechnisch ist es nicht zu empfehlen, mit negativen Rechten zu arbeiten,
da dadurch die Rechtelage relativ unübersichtlich wird.
Wird ein Verzeichnis neu angelegt, so erbt es beide ACLs des Verzeichnisses, in
dem es angelegt wurde. Wird ein Volume neu angelegt, so enthält die positive
ACL des root-Directories dieses Volumes nur einen Eintrag:
system:administrators => rlwidka
(Mitglieder des Zellensuperusergruppe dürfen alles)
Die Rechte in den ACLs des AFS sind feiner einstellbar, als im klassischen
Unix-Schema (rwx). Die verfügbaren Rechte sind in Tabelle 3.3 aufgeführt.
Tabelle 3.4 zeigt die für bestimmte Aktionen benötigten Rechte.
Hinweise:
• Gelegentlich gibt es Interesse an ”Append-only”-Funktionalität im AFS
(vergleichbar mit dem ext2-a-Attribut). Das ist jedoch prinzipiell nicht
möglich, da durch die Organisationsstruktur (Stichwort: Chunks) des
Cache-Managers dazu praktisch immer read- und write-Rechte auf Serverseite
nötig wären, auch wenn der Cache-Manager ”Append-only”
simmulieren könnte.

52 3 Technische Details zu AFS
Recht Erklärung
l list Dieses Recht erlaubt, die Einträge in einem Verzeichnis zu listen (readdir()) und
durch das Verzeichnis hindurchzuwechseln. Außerdem können Metadatan von Unterverzeichnissen
des Verzeichnisses mit stat() und Inhalte von symbolischen Links
mit readlink() ausgelesen werden.
r read read erlaubt, Dateien sowie deren Metadaten (stat()) im entsprechenden Verzeichnis
zu lesen.
Um den Befehl fs listquota zu benutzen, muß man im Grundverzeichnis des entsprechenden
Volumes dieses Recht besitzen.
w write Mit write erhält man das Recht, in Dateien des entsprechenden Verzeichnisses beliebig
zu schreiben.
i insert Dieses Recht ermöglicht es, Dateien anzulegen und in diese zu schreiben, schließt jedoch
nicht das Recht ein, sie später wieder zu ändern. D.h. nach close() auf eine
frisch angelegte Datei ist das insert-Recht für dieses File wertlos.
Dieses Recht ist z.B. für das /incoming-Verzeichnis eines FTP-Servers nützlich.
Hinweis: Der Windows-XP-Client hat derzeitig (Stand OpenAFS-1.2.11) ein Problem
mit dieser Funktion - um eine Datei einzufügen ist unter Windows immer auch das
write-Recht nötig.
d delete Mit diesem Recht ist es möglich, Dateien und Verzeichnisse in einem Verzeichnis zu
löschen.
k lock lock berechtigt dazu, Dateien im Verzeichnis zu sperren (flock()). Solche Sperren
werden auf dem Server gesetzt und sind damit netzwerkweit gültig. Bestimmte Programme
benötigen diese Funktion, um lock-Files benutzen zu können.
a admin Dieses Recht ermöglicht das Ändern der ACLs sowie das Anlegen und Löschen von
Volume-Mountpoints (nur wenn man auch die i bzw. d -Rechte hat) innerhalb eines
Verzeichnisses.
Tabelle 3.3: Die verschiedenen Rechte, die mit AFS-ACLs vergeben werden können
3.7.3.3 Zusätzliche Rechte ausserhalb der ACLs
Es gibt noch weitere reservierte Rechte, die jedoch auf Fileservern, die nicht
speziell modifiziert wurden, keine Bedeutung haben.
Es existieren einige Ausnahmen der Rechteverwaltung, die die vermuteten
Rechte aus den ACLs beeinflussen:
Admins dürfen alles : Alle Mitglieder der Gruppe system:administrators dürfen unabhängig
von den ACLs immer alles. Mit dem Parameter -implicit des
Fileserver-Prozesses (fileserver) können diese implizit gewährten
Rechte beschränkt werden. Das a-Recht wird jedoch trotz evtl.
angegebenem -implicit immer gewährt.
Volume-Besitzer : Der Besitzer eines AFS-Volumes (sprich: Der AFS-Benutzer mit der
PTS-ID, die der Owner-UID des root-Verzeichnisses eines Volumes entspricht)
besitzt implizit das a-Recht für alle Verzeichnisse des Volumes.
Verzeichnis-Besitzer : Der Besitzer eines AFS-Verzeichnisses bekommt vom OpenAFS-1.2-
Fileserver immer implizit das a-Recht.
Achtung: Dieses Verhalten war ein unerwünschter Nebeneffekt der
Volume-Besitzer-Ausnahme. Ab OpenAFS-1.3 ist diese Ausnahme
hinfällig.
Datei-Besitzer : Hat man in einem Verzeichnis das i-Recht inne, erhält man implizit ein
Schreibrecht für alle Dateien, die einem in diesem Verzeichnis gehören.

3.7 Das Sicherheitsmodell 53
Aktion
Datei, Link oder Verzeichnis anlegen
Datei lesen
Inhalt einer Datei verändern
Daten an eine Datei anfügen
Dateieigenschaften abfragen (stat())
Datei oder Link löschen (unlink())
r
√
√
√
l
√
√
√
√
√
√
w
√
√
i
√
√
d
√
k a
Verzeichnis löschen (zu löschendes Verzeichnis)
Verzeichnis löschen (Parent-Directory)
Mountpoint anlegen
Mountpoint entfernen
ACLs im Verzeichnis ändern
√
√
√
√
√
√
√
√
√
√
Tabelle 3.4: Die verschiedenen Rechte, die für bestimmte Tätigkeiten im AFS benötigt werden
u+r : Lesezugriffe auf Dateien ohne Bit 8 (u+r) sind nicht möglich.
u+w : Schreibzugriffe auf Dateien ohne Bit 7 (u+w) sind nicht möglich.
Datei-Modebits ändern : Die Modebits 0 bis 8 (ugo+rwx) einer Datei lassen sich nur ändern, wenn
der jeweilige Benutzer die die Rechte w und l an dem Verzeichnis hat, in
dem die Datei liegt.
Verzeichnis-Modebits ändern : Die Modebits 0 bis 8 (ugo+rwx) eines Verzeichnisses lassen sich nur ändern,
wenn der jeweilige Benutzer die Rechte l, i und d an diesem Verzeichnis
hat.
insert-Besonderheiten : Der Fileserver erlaubt das Lesen von eigenen Dateien 29 , wenn das i-Recht
gewährt wird. Das sollte vor allem bei der Absicherung einer global erreichbaren
Zelle beachtet werden.
Der Cache-Manager kennt diese Besonderheit allerdings nicht und verweigert
plichtbewusst den Zugriffe auch auf eigene Dateien in einem solchen
Verzeichnis, wobei der lokale Root natürlich direkt den Cache auslesen
kann...
Der Cache-Manager (also der AFS-Client) beachtet auch einige Metadaten von
Dateien:
• Dateien im AFS sind nur dann ausführbar, wenn die Modebits 6 und 8
(u+rx) aktiviert gesetzt sind - Bit 6 alleine reicht nicht.
• Wenn die Auswerdung von SetUID-Bits für die jeweilige Zelle aktiviert
ist (und nur dann), wird das wie unter Unix üblich gehandhabt (Ausführung
geschieht mit den Privilegien der Owner-ID der Datei). Dabei ist
jedoch zu beachten, dass sich fürals SetUID gestartete Programme lediglich
die lokale UID ändert, nicht die AFS-Identität.
Hinweise:
• Das Sticky-Bit (t), die GID einer Datei sowie die unteren 6 Modebits
(go+rwx) werden komplett ignoriert.
• Die Bits 6 bis 8 (u+rwx) werden für Verzeichnisse komplett ignoriert.
• Neue AFS-Dateien und -Verzeichnisse erhalten als User-ID die PTS-ID
die dem Token des aktuellen Nutzers zugeordnet ist.
29 Dateien, deren Besitzer mit der AFSID des aktuellen Tokens übereinstimen

54 3 Technische Details zu AFS
3.7.3.4 AFS-Gruppen
3.7.3.5 Serversteuerung
• Neue AFS-Dateien erhalten die GID der primäre Gruppe des aktuellen
Benutzers als GID zugeordnet.
Die PTDB einer jeden Zelle enthält Gruppendefinitionen, die mit dem Kommando
pts eingesehen und verändert werden können. Gruppen können genau
wie Benutzer in AFS-Verzeichnis-ACLs benutzt werden. Der PT-Server verwaltet
Zugriffsrechte für die einzelnen AFS-Gruppen und User. Neben den Zellensuperusern
können unter AFS auch einfache Benutzer Gruppen anlegen und
verwalten.
Ab der OpenAFS-Version 1.3 wird es die Möglichkeit geben, Gruppen als Mitglieder
in andere Gruppen aufzunehmen. Gruppen, die andere Gruppen enthalten,
heissen supergroups.
Einfache Benutzer sind bei der Wahl des Namens von neu anzulegenden Gruppen
jedoch eingeschränkt: Der Gruppenname muss aus dem Namen des Nutzers,
einem “:” und einem Namen aus Buchstaben und Zahlen bestehen. Unter
6.7 auf Seite 121 ist beschrieben, wie man mit solchen Gruppen umgeht.
Die Autorisation gegenüber AFS-Serverprozessen, wird z.B. von vos und
bos benutzt, unterscheidet sich grundlegend von den ACLs, die beim AFS-
Filesystemzugriff ausgewertet werden.
AFS-Server verwenden Benutzerlisten 30 auf den einzelnen Servern. Diese
müssen nicht auf allen Servern der Zelle gleich sein, jedoch gilt: Wer auf mindestens
einer der Listen steht, kann problemlos Shellkommandos ausführen:
admin@afs>bos exec Servername Kommando
Da man auf diese Weise leicht in den Besitz des AFS-Keys (und somit der
ganzen Zelle) gelangen kann, sollten einfache Benutzer niemals auch nur auf
einer dieser Listen stehen.
Zusätzlich zu den erlaubten Benutzern, kann jeder Superuser eines AFS-
Servers der Zelle mit der Option -localauth beliebige bos-, vos und
backup-Unterkommandos ausführen:
root@host>bos exec Servername Kommando -localauth
3.7.4 Sicherheitshinweise
3.7.5 Der AFS-Superuser
Aus ungeklärtem Grund ist das mit dem pts-Kommando nicht möglich.
Achtung: Man sollte Zellensuperuserrechte - vor allem in automatisierten
Skripten - nur dort verwenden, wo sie wirklich notwendig sind. Evtl. ist es
günster bestimmte Kommandos in acall-Aufrufe (siehe 7.6.2, Seite 149) zu
kapseln.
Die Unterkommandos mancher AFS-Kommando-Familien benötigen Zellensuperuserrechte.
Dafür ist nicht zwangsläufig ein Token oder auch nur
ein Kerberos-Ticket nötig. Liegt auf dem Rechner, auf dem das Kommando
30 Unter 9.1.1 (Seite 192) ist beschrieben, wie man diese Listen manipuliert und ausliest.

3.7 Das Sicherheitsmodell 55
3.7.5.1 Server oder Filesystem?
3.7.5.2 Verschiedene Wege zu Superuserrechten
ausgeführt werden soll, der gültige AFS-Zellenschlüssel (abgelegt in /etc/openafs/server/KeyFile),
kann man den Kommandozeilenparameter -localauth
benutzen und hat damit eine niemals ablaufende Zugangsberechtigung. Das
funktioniert für die Kommandos vos, bos und backup.
Leider kennt das pts-Kommando diese Option nicht. Will man es mit
Superuser-Rechten benutzen, muss also immer ein gültiges Token erreichbar
sein oder man muss acall benutzen.
Superuser kann man auf zwei sich nicht gegenseitig bedingende Arten für unterschiedliche
Aufgaben sein. Üblicherweise sind die Server-Superuserlisten jedoch
deckungsgleich mit den Gruppenmitgliedern von system:administrators.
3.7.5.1.1 Filesystem Benötigt man Superuserrechte im Filesystem (z.B.,
weil im Root-Volume der Zelle ein Verzeichnis angelegt werden muss), muß
man Mitglied der Gruppe system:administrators sein.
3.7.5.1.2 Server Für Server-bezogene Aktionen (Anlegen von Volumes,
Löschen und Durchführen von Backups, ...) muß man Superuser auf den beteiligten
Servern sein. Dabei zählen nicht nur die Fileserver sondern wirklich alle
beteiligten Server - also z.B. auch Backup-Server und Datenbank-Server.
Jeder Server unterhält unabhängig von allen anderen eine Liste mit Namen
der AFS-Benutzer, die (anhand ihrer Token) als Superuser akzeptiert werden.
Üblicherweise sind die Superuserlisten aller AFS-Server identisch. Sind Änderungen
an den Superuserlisten nötig müssen diese Änderungen jedoch auf allen
AFS-Servern durchgeführt werden (siehe 3.9.2, Seite 60).
Unabhängig von dieser Liste kann jeder, der den AFS-Zellenschlüssel kennt mit
der -localauth-Option Kommandos mit AFS-Superuserrechten ausführen.
Zur Demonstration verschiedener Superuser-Authentifikationsarten soll das
neue Volume local.scripts angelegt werden. Folgende Kommandos, die sich
ihre Autorisierung auf 4 verschiedene Arten verschaffen, kommen dafür in
Frage:
auf einem AFS-Server : Das Kommando benutzt den AFS-Schlüssel eines AFS-Servers. Ein
laufender AFS-Client ist dafür nicht nötig, dafür aber Root-Rechte auf
dem entsprechenden Server:
root@host>vos create afsserv1 a local.scripts -localauth
auf einem AFS-Client : Damit kann von einem beliebigen Rechner der Zelle aus das Volume angelegt
werden. Es ist ein laufender AFS-Client nötig. Da ein neues TGT
geholt werden muss, ist die Eingabe des admin-Passwortes nötig:
user@host>kinit admin
user@host>aklog
admin@afs>vos create afsserv1 a local.scripts
mit Tokenmgr auf einem Client : Der Befehl tokenmgr fasst die Ausführung von kinit und aklog zu einem
Befehl zusammen und kümmert sich um die Beseitigung des TGTs nach
Ausführung von vos create:

56 3 Technische Details zu AFS
user@host>tokenmgr -S admin - - vos create afsserv1 a local.scripts
Hinweis: Die -S-Option fasst ein ganzes Bündel kleinerer Optionen zusammen.
Sie sorgt unter anderem dafür, dass das angegebene Kommando
in einer PAG (siehe 3.7.2.3, Seite 49) läuft.
mit Frischhaltegarantie : Wie vorheriges Beispiel, jedoch startet tokenmgr eine Reauthentifikationsautomatik.
Für vos create ist das nicht wichtig, braucht ein Kommando
jedoch sehr lange (z.B: vos dump über eine langsame Leitung),
kann es sein, dass das Token während der Ausführung abläuft und die Aktion
unterbrochen wird. Mit dem -r-Parameter ist man davor geschützt.
Beispiel:
user@host>tokenmgr -rS admin - - vos dump local.scripts \
-server afsserv1 -partition a
3.7.5.3 Superuserrechte auf AFS-Servern
3.7.5.4 Benutzer auf AFS-Servern
Achtung: Man sollte den -r-Parameter nur verwenden, wo das absolut
nötig ist. Er hebelt einen Teil des Ticket-Konzeptes aus, indem
er tokenmgr veranlaßt, das Passwort eines Benutzers im Speicher zu
halten.
Das erste Kommando muss zwar immer auf einen AFS-Server als Root ausgeführt
werden, hat jedoch den Vorteil, dass es keine zeitliche Begrenzung gibt -
bei den beiden mittleren Beispielen muss die jeweilige Aktion vor Ablauf des
Tokens beendet sein.
AFS benutzt ein relativ sicheres Netzwerkprotokoll. Im Gegensatz zu Protokollen
wie NFS 31 werden alle übers Netzwerk übertragenen Pakete kryptographisch
signiert und optional auch verschlüsselt.
AFS’ Schwachstelle sind die Server. Gelangt ein Angreifer mit Superuser-
Rechten auf einen Server, gilt die Zelle als kompromittiert. Diese Situation
wäre dann mit einem Rechner vergleichbar, auf dem der Root-Zugang kompromittiert
wurde: Um mögliche installierte Hintertüren auszuschließen, müssten
die Server eigentlich danach neu installiert werden.
Der Grund für diese Schwachstelle ist, dass es pro Zelle genau einen symmetrischen
Schlüssel gibt, von dem eine unverschlüsselte Kopie auf allen AFSsowie
auf allen Kerberos-Servern existieren muss.
Zuküftige AFS-Versionen sollen mehrere Schlüssel pro Zelle (also z.B. einer
pro Server) zulassen - konkrete Zeitpläne gibt es aber nicht.
Der AFS-Schlüssel auf den Fileservern ist per Unix-Modebits geschützt und
nur dem Superuser zugänglich. Theoretisch ist es also unkritisch. Da man aber
nie weiß, wann und wo der nächste buffer overflow gefunden wird, sollten sich
keine Benutzer auf AFS-Servern einloggen können. Das kann man wie folgt
einrichten:
root@host>echo ’+:root:ALL’ > /etc/security/access.conf
root@host>echo ’-:ALL:ALL’ >> /etc/security/access.conf
31 NFS lässt sich auch relativ sicher einrichten, jedoch ist dann der Aufwand enorm.

3.8 Fileserver 57
3.8 Fileserver
user@host>man pam_access
3.8.1 AFS-Volumes sind keine Shares oder Exports
PAM sorgt dann über das pam_access-Modul dafür, daß sich nur root anmelden
darf. Weitere Informationen bietet
AFS-Fileservermaschinen besitzen mindestens eine Datenpartition, die als /vicepx
gemountet ist, wobei x für jeweils einen bzw. zwei beliebige kleinen Buchstaben
steht. Die OpenAFS-Fileserver schreiben nur auf dedizierte Partitionen.
Legt man einfach nur ein Verzeichnis (z.B. /vicepx oder auch /vicepeg) an, so
greift der jeweilige Fileserver (zumindest ohne Tricks) nicht darauf zu.
Die Art und Weise, wie der Fileserver Volumes (und damit Files aus dem AFS-
Namensraum) auf den Wirtspartitionen ablegt, ist spezifisch für den verwendeten
Fileserver (siehe 3.8.2, Seite 57). Man sollte auf keinen Fall Daten auf den
Wirtspartitionen direkt ändern, sondern nur über geeignete AFS-Kommandos
(mittels vos) bzw. durch Zugriffe auf /afs). I.d.R. gilt zwar, dass jeder Datei in
einer RW-Instanz eine gleichgroße Datei in einer /vicepx-Partition gegenübersteht,
jedoch gilt diese Regel schon für RO-Instanzen nicht mehr zwangsläufig.
Auch werden die Verzeichnisstrukturen in Volumes auf inode-Servern nicht
durch Verzeichnisse auf den Wirtspartitionen repräsentiert
Hinweise:
3.8.2 Die OpenAFS-Fileservertypen
3.8.2.1 Der inode-Server
• Es ist möglich, das Verzeichnis einer Volume-Instanz auf der Datenpartition
eines Fileservers zu ermitteln (siehe 9.2.15, Seite 201).
• Die Volumes auf AFS-Servern sind nicht mit SMB-Freigaben oder NFS-
Exports zu vergleichen. Der AFS-Fileserver ist eher eine Blackbox mit
definierten Schnittstellen: dem AFS-Client und vos.
• Es gibt Programme 32 , die in der Lage sind, Teile des VFS als AFS-
Volume zu exportieren. Die Programm liegen im globalen AFS-Namensraum
für jedermann kopierbar:
HostAFS : /afs/cs.cmu.edu/project/systems-jhutz/hostafs
tafssrv : /afs/cs.cmu.edu/project/systems-jhutz/tafssrv
Bei diesen lösungen muß man auf einige AFS-Goodies wie z.B. sichere
Authentifikation verzichten.
Man kann unter Linux zwischen 2 verschiedenen OpenAFS-Fileservertypen
wählen. Wenn Sie schnell etwas Über ihren Fileserver wissen wollen, liegen sie
in den meisten Fällen mit Abschnitt 3.8.2.2 richtig. Die vorbereiteten Pakete
für Debian bringen ausschliesslich namei-Fileserver mit.
Der klassische AFS-Fileserver (inode-Server) greift über inode-Nummern auf
die Dateien im Wirtsfilesystem zu. Er greift dabei auf Kernelebene - unter Benutzung
eines Kernelmoduls - auf Files in den /vicepx-Partitionen zu. Dabei
umgeht er die zeitraubende Auflösung von Filenamen in inode-Nummern, was
jedoch das Filesystem in einen inkonsistenten Zustand versetzt. Würde man
32 eigenständige AFS-Server-Implementationen, die keine direkte Beziehung zu OpenAFS haben

58 3 Technische Details zu AFS
3.8.2.2 Der namei-Server
anschließend die Inkonsistenzen wieder entfernen (z.B. mit fsck), so gehen
unweigerlich AFS-Daten verloren gehen. Ausserdem kann man nicht einfach
mal so auf Filesystemebene auf die AFS-Daten zugreifen (z.B. zum Debuggen).
Benutzt man diesen Fileserver, muss auch eine modifizierte fsck-Version zum
Einsatz kommen, woraus sich auch schon ableiten lässt, dass nicht jedes Filesystem
geeignet ist. Unter Linux bietet sich z.B. nur ext2 an. Der inode-Fileserver
unterstützt keine Dateien > 2GB.
Der namei-Server ist nach der Kernel-Funktion zur Umwandlung eines Dateinamens
in eine inode-Nummer (namei()) benannt. Er benötigt kein
Kernelmodul mehr und läuft als reiner Userspace-Prozess. Es können beliebige
Filesysteme 33 als /vicepx-Partitionen zum Einsatz kommen, modifizierte
fsck-Versionen sind nicht länger nötig. Die Auflösung von Dateinamen zu
inode-Nummern kostet Zeit und macht den Server etwas langsamer. Die mit
diesem Fileserver mögliche Benutzung von Journaling-Filesystems (xfs, ext3,
Reiserfs, ...) macht diesen Makel 34 durch einen drastisch beschleunigten Filesystemcheck
allerdings wieder wett. Der namei-Fileserver ist unter Linux die
einzig sinnvolle Wahl.
3.8.2.2.1 Die Verzeichnisstruktur auf der Wirtspartition Wenn man sich
die Datenpartition eines namei-Fileservers ansieht, wird man folgendes finden:
Lock : hier liegen Dateien, anhand derer der Fileserver sicherstellt, dass die Partition
nicht mehrmals benutzt wird (also z.B. als /vicepa und vicepb)
V12345678.vol : (die Zahl variiert) sind sog. Volume-Header. In diesen stehen einige Metainformationen
der auf der Partition gespeicherten Volume-Instanzen.
AFSIDat : enthält die eigentlich Daten.
Das AFSIDat-Verzeichnis führt über zwei Unterverzeichnis-Ebenen an die
Daten der Volume-Instanzen. Mit instantafs.getvoldirs kann man herrausfinden,
wie der Pfad für ein gegebenes Volume lautet. Der Pfad besteht dabei aus
base64-codierten Komponenten der (numerischen) Volume-ID. Der Rest des
Pfades setzt sich dann aus base64-codierten Komponenten der inode-ID einer
Datei oder eines Verzeichnisses zusammen.
Achtung:
• Die Dateien unter /vicepx/AFSIDat sind sehr empfindlich - der Namei-
Server speichert auch in den Metadaten (Owner, Group, Modebits, ...)
wichtige Informationen.
• Unter MacOSX ist die Abbildung Volume-ID/Inode-ID auf die AFSIDat-
Pfade anders als unter anderen Unix-Betriebssystemen. Das ist jedoch nur
dann kritisch, wenn eine MacOSX-Platte an einen anderen Unix-Rechner
angeschlossen werden soll - oder umgedreht.
3.8.2.2.2 Forensik Wenn man eine Platte hat, die vorher eine /vice-Partition
eines namei-Fileservers war, kann man trotz intaktem Filesystem nicht viel über
den Inhalt sagen. Die Namen der Dateien darauf sind lediglich codierte AFSinode-Nummern.
Sinnvolle Baumstrukturen sind gar nicht zu erkennen.
33 die natürlich eine gewisse Unix-Kompatibilität aufweisen müssen. vfat geht z.B. nicht.
34 für den hier leider keine vergleichenden Daten vorgelegt werden können.

3.8 Fileserver 59
Bevor man etwas mit der Platte anstellt, sollte man sie auf jeden Fall kopieren
und am besten nur mit der Kopie arbeiten, wobei zu beachten ist, dass wirklich
alles kopiert werden muss - also auch
• Modebits und
• Owner
Achtung: Wenn man das nicht beachtet, gilt das auf einer /vice-Partition als
Inkonsitenz und der salvager entfernt die entsprechenden Files.
Man kann diese Festplatte nun in einen Fileserver der eigenen Zelle ’reinschrauben
und den Fileserver mit
admin@afs> vos syncvldb Servername
bearbeiten. Damit setzt man die Zelle jedoch einem gewissen Risiko 35 aus.
Besser ist es — z.B. mit InstantAFS — eine neue Mini-Zelle auf einem Rechner
zu erstellen und die Platte in diese Zelle einzuhängen. Danach sollte man nicht
vergessen, folgendes Kommando auszuführen:
admin@afs>vos syncvldb Fileserver mit Fremdplatte
3.8.3 Wirtspartitionen
3.8.4 Prozesse
Unabhängig vom benutzten fileserver-Typ sind für die Datenpartitionen
des AFS einige Dinge zu beachten:
• Unter /vicepx (stellvertretend für ein beliebiges /vicep-Verzeichnis) wird
immer ein eigens Filesystem (üblicherweise eine eigene Partition) erwartet
(/vicepx muss also immer ein Mountpoint sein). Das lässt sich im
Bedarfsfall übersteuern, indem die Datei /vicepx/AllwaysAttach angelegt
wird.
• Welche Filesystemtypen benutzt werden können, ist vom Typ des Fileservers
abhängig (siehe 3.8.2, Seite 57).
• Die für die Durchsetzung der AFS-Quotas optimale Blockgröße von
Wirtspartitions-Filesystemen beträgt 1kByte, da Blöcke im AFS diese
Größe haben. Werden größere Blöcke verwendet, ist evtl. (vor allem bei
vielen kleine Dateien in einem oder mehreren Volumes) die angerechnete
Quota kleiner als der auf der Wirtspartition benutzte Speicher.
Auf jedem AFS-Fileserver müssen zwei miteinander per TCP kommunizierende
Prozesse immer laufen:
fileserver : Dieser Prozess beantwortet Anfragen der AFS-Clients. Er ermöglicht Zugriff
auf AFS-Daten auf Dateisystemebene. Es müssen 19 Prozesse mit
dem Namen /usr/lib/openafs/fileserver laufen. Weniger
dürfen es nur dann sein, wenn der fileserver gerade hochgefahren
wird.
Der fileserver schreibt Logging-Informationen nach /var/log/openafs/FileLog.
volserver : Dieser Prozess bearbeitet Anfragen, die sich nicht auf Dateien im
AFS-Namensraum, sondern auf ganze Volume-Instanzen beziehen (z.B.
35 z.B. könnte die Partition ein Volume Names root.cell enthalten

60 3 Technische Details zu AFS
vos remove oder vos move). Bevor ein Schreibzugriff auf eine
Volume-Instanz erfolgt, wird der Fileserver davon in Kenntnis gesetzt
und die entsprechende Instanz auf “busy” (siehe 6.13.2, Seite 137) geschaltet.
Logging-Informationen speichert dieser Prozess in /var/log/openafs/VolserLog.
Ein weiterer Prozess wird nur bei Bedarf gestartet - der salvager. Dieser Prozess
sucht nach Inkonsistenzen in den Datenstrukturen von Volume-Instanzen
und versucht, diese zu korrigieren. Gestartet wird er, wenn
admin@afs>bos salvage Servername
3.9 Der bos-Server
3.9.1 Aufgaben
3.9.2 Authentifikation
• ein privilegierter Benutzer es auslöst:
• der fileserver abstürzt oder
• der bosserver gerade gestartet wurde (z.B. bei einem Neustart) 36 .
Der volserver lässt sich über zahlreiche Unterkommandos von vos steuern.
Er erhält dabei von vos jedoch keine komplexen Befehle wie “Verschiebe
Volume-Instanz X zu Server B”. Die Steuerung von Transaktionen zwischen
und auf Fileservern ist deshalb Aufgabe des zugreifenden Tools (vos), nicht
des volservers.
Der bosserver (Basic OverSeer Server 37 ) läuft auf ausnahmslos jedem
AFS-Server. Er hat für AFS-Server eine vergleichbare Aufgabe wie der
init-Prozess für das gesamte System:
• Starten, Beenden, Überwachen sowie regelmäßiges Neustarten der
eigentlichen Serverprozesse
• Management der Liste der privilegierten Benutzer, die Zugriff auf den
Server haben
• Fernsteuerung
• Management der AFS-Keys eines Servers
• Authentifiziertes Ausführen von Shellkommandos auf der Servermaschine
• einige andere (siehe [ADMREF])
Der bosserver lässt sich netzwerkweit fernsteuern - der Befehl bos steht dafür
zur Verfügung. Der bosserver kann auch zur Überwachung AFS-fremder
Prozesse eingesetzt werden.
Das bos-Kommando und auch andere AFS-Kommandofamilien benutzen den
Token des aufrufenden Nutzers, um sich gegenüber dem ausgewählten Server
36 Das lässt sich (für einen schnelleren Start des Fileservers) unterbinden, jedoch steigt dann das
Risiko für Inkonsistenzen in Volume-Instanzen auf der entsprechenden Fileservermaschine.
37 dt. Aufseher

3.10 Kerberos 61
3.10 Kerberos
3.10.1 Übersicht
zu authentifizieren (siehe 3.7.5.1.2, Seite 55). Dabei werden bestimmte Befehle
nur von Benutzern akzeptiert, die sich in der serverspezifischen Liste privilegierter
Nutzer befinden. 3 Befehle ermöglichen vollen Zugriff auf die Liste
eines einzelnen Servers.
So zeigt man die Liste an:
user@host>bos listusers afsserv1
SUsers are: admin
Ein neuer Nutzer bekommt folgendermaßen Zugriffsrechte für den Server:
admin@afs>bos adduser afsserv1 ernie
admin@afs>bos listusers afsserv1
SUsers are: admin ernie
... und schon sind sie wieder weg:
admin@afs>bos removeuser afsserv1 ernie
bos listusers afsserv1
SUsers are: admin
Es versteht sich von selbst, dass die Kommandos zum Hinzufügen und Entfernen
von Benutzern nur von privilegierten Nutzern akzeptiert werden. Die
Authentifikation erfolgt über den AFS-Token, nicht über das Kerberos-Ticket.
Die spezielle bos-Option -localauth ermöglicht eine Authentifikation ohne
ein Token. Dabei wird der AFS-Key aus der Datei /etc/openafs/server/KeyFile
benutzt. Diese Option empfiehlt sich deshalb nur, wenn das bos-Kommando
auf einem von regulären Benutzern abgeschotteten AFS-Server benutzt wird
(z.B. bei der Installation der Zelle).
Kerberos ist ein Authentifikationsmechanismus, der sich wie folgt charakterisieren
lässt:
• Kerberos arbeitet mit Tickets. Tickets sind wie zeitlich begrenzte Personalausweise:
Solange das Gültigkeitsdatum nicht überschritten ist, kann
ich mich damit ausweisen, danach nicht mehr.
• Es gibt 2 Sorten von Tickets:
ticket-granting ticket : Ist eine Art Berechtigungskarte für Kerberosdienste, die man gegen
"Vorlage"des Passwortes bekommt.
service ticket : auch nur Ticket genannt, erhält man für bestimmte Dienste gegen
Vorlage des ticket-granting tickets.
• Die Authentifikation erfolgt immer im Rahmen einer Kerberos-Realm.
Eine Realm kann man sich ähnlich wie eine Windows-Domäne vorstellen:
Hat man sich an einem Kerberos-Server authentifiziert, so gilt man
für alle Rechner der Realm dieses Servers als authentifiziert. Sie ist der
Herrschaftsbereich eines Kerberos-Master-Servers
• Die Kerberos-Server kennen alle Passwörter 38 der Benutzer.
38 Eigentlich werden Hashes der Passwörter der Kerberos-Benutzer abgespeichert - nicht die
Passwörter selbst. Trotzdem gilt: Wer den Kerberos-Server knackt, darf damit alles, was jeder
einzelne Benutzer darf.

62 3 Technische Details zu AFS
3.10.2 Der Principal
• Will ein Benutzer auf einen bestimmten Dienst zugreifen (z.B. AFS oder
SSH auf rechner1), so benötigt er für diesen Dienst jeweils ein Kerberos-
Ticket.
• Kerberos-Tickets sind vom Kerberos-Server signierte Datenstrukturen,
die einem Dienst auf einem Rechner der Realm vorgelegt werden können,
um die eigene Identität nachzuweisen. Mit einer Ausnahme (dem
TGT selbst) werden alle Tickets vom Kerberos-Server gegen Vorlage
eines bestimmten Tickets - dem TGT (Ticket Granting Tickets) - erteilt.
• Über’s Netzwerk wird das TGT ausschliesslich verschlüsselt übertragen.
Erfolgreich entschlüsseln kann man es nur mit dem gültigen Benutzerpasswort.
sein Passwort eingibt - verschlüsselt ist es nutzlos.
• Kann man das TGT mit dem eigenen Passwort erfolgreich entschlüsseln,
hat man damit auch eine Garantie, dass es vom richtigen"Kerberos-Server
geschickt wurde (Mutual Authentication), da nur der Benutzer und der
Kerberos-Server das Passwort, dass zum Verschlüsseln des TGT benutzt
wird, kennen.
• Die Gültigkeit von Tickets ist zeitlich begrenzt (siehe 3.10.7, Seite 65).
• Jeder Benutzer besitzt für jede einzelne Session (Beispiel: KDE-Sitzung
auf Computer A) einen Credentials-Cache (CC) - einen Speicherbereich
39 , in dem seine Tickets gespeichert sind. Diesen Cache kann nur
der jeweilige Benutzer (und der allmächtige root lesen). Kann ein Angreifer
den CC auslesen, kann er im Namen des entsprechenden Nutzers
handeln - solange, bis die im CC enthaltenen Tickets ablaufen.
• Wird Zugriff auf einen Dienst benötigt (z.B. für ssh rechner1) dann
fordert der Client (z.B. ssh) vom Kerberos-Server ein Ticket für diesen
Dienst an 40 . Dazu benutzt der Client das TGT aus dem Credentials-
Cache. Das dienstspezifische Ticket (z.B. host/rechner1@REALM für
ssh) wird übers Netzwerk dem benutzten Dienst vorgelegt. Damit ist man
beim entsprechenden Dienst authentifiziert, was jedoch nicht zwangläufig
bedeutet, dass man auch autorisiert ist.
AFS benutzt z.B. zur Autorisation von Filezugriffen die ACLs in AFS-
Directories (siehe 3.7.3, Seite 51) sowie die PTDB (siehe 3.3, Seite
35).
• Kerberos ist nur für die Authentifizierung zuständig, nicht für Autorisation.
Jeder kerberosifizierte Dienst (z.B. SSH) kann für einen bereits authentifizierten
Benutzer entscheiden, ob er diesem Zugriff gewährt oder
nicht.
AFS z.B. entscheidet darüber anhand der ACLs der Verzeichnisse (siehe
3.7.3, Seite 51).
Ein Kerberos5-Principal ist eine Datenstruktur, hinter der sich entweder ein Benutzer
oder ein Dienst verbirgt, also etwas, was sich authentifizieren muss. Für
jeden Principal sind einer oder mehrere Schlüssel gespeichert. Die Schlüssel
sind symmetrisch und bestehen entweder aus einer Zufallszahl oder aus einem
Passwort. Mit einem solchen Schlüssel kann sich ein Benutzer gegenüber dem
Kerberos-Server und auch der Kerberos-Server gegenüber dem Benutzer ausweisen.
Durch verschachtelte Verschlüsselungsebenen in den Tickets kann sich
ein Benutzer auch gegenüber einem Dienst (z.B. dem AFS) ausweisen.
39 unter Unix ist das eine geschützte Datei unter /tmp
40 Wenn ein solches Ticket nicht schon im Credentials-Cache liegt.

3.10 Kerberos 63
3.10.3 Keytabs
Benötigt ein Benutzer Zugriff auf einen bestimmten Dienst, fordert der Client 41
ein TGT vom Kerberos-Server an und benutzt dieses, um Tickets für andere
Dienste zu bekommen. Jedem Dienst ist dabei ein Principal zugeordnet, der
i.d.R. kein Passwort (siehe -randkey-Option im kadmin), sondern nur eine
Zufallszahl als Schlüssel hat. Durch die Verschlüsselung mit dem Schlüssel des
speziellen Dienstes (z.B. AFS), kann dieser Dienst später, wenn der Benutzer
dem Dienst sein Ticket vorzeigt, feststellen, ob der Benutzer vom Kerberos5-
Server authentifiziert wurde - schließlich kennt außer dem Dienst nur noch der
Kerberos-Server die geheime Zufallszahl.
Der AFS-Dienst wird in der Kerberos-Datenbank durch einen Principal repräsentiert.
Dieser kann 2 Formate haben:
• afs@[Realm] (z.B. afs@CBS.MPG.DE) kommt dann zum Einsatz, wenn
gilt:
Zellenname = Kerberos-Realm.
• afs/[Zellenname]@[Realm] (z.B. afs/cbs.mpg.de@CBS.MPG.DE) sollte
benutzt werden, wenn über die Realm mehrere Zellen verwaltet werden
sollen. Da das flexibler ist, ist dieses Format Standard unter InstantAFS.
Keytabs sind Dateien, die beliebig viele Schlüssel von beliebig vielen Principals
enthalten können. Damit erfüllen sie jeweils eine von zwei Funktionen:
• Sie speichern (meist in /etc/krb5.keytab) die Schlüssel von Kerberos-
Dienst-Principals. Diese Schlüssel werden von den kerberosifizierten
Diensten (z.B. sshd) benötigt, um die Gültigkeit von Kerberos-Tickets
überprüfen zu können 42 .
Keytabs von Service-Principals werden i.d.R. mit dem Kommando
ktadd in der kadmin.local-Shell auf dem Kerberos5-Master-Server
erzeugt:
kadmin.local: ktadd -k Keytab-Datei Principal
Dabei wird der Schlüssel des entsprechenden Principals mit jedem
ktadd-Aufruf neu generiert, womit alle Schlüssel dieses Dienstes, die
vorher in Keytabs gespeichert wurden, ungültig werden.
Unter 7.4 auf Seite 145 ist erklärt, wie man mit Service-Keytabs umgeht.
• Keytabs können auch die Schlüssel von Benutzern speichern. Eine solche
Keytab hat für Kerberos den selben Wert wie das Passwort des Benutzers
(auch wenn das Passwort daraus nicht ermittelt werden kann). Eine
Benutzer-Keytab kann an tokenmgr oder kinit übergeben werden,
um die Eingabe des Passwortes zu sparen. Dadurch lassen sich nichtinteraktive
mit Kerberos authentifizierte und am AFS-angemeldete Prozesse
realisieren.
So wird eine Keytab erzeugt:
41 Sowohl Client als auch Server müssen dabei explizit Kerberos-tauglich sein. Es ist nicht mit PAM
vergleichbar.
42 Hinweis: Ist die Keytab eines solchen Dienstes einem Angreifer bekannt, hat der Angreifer diesen
speziellen Dienst geknackt.

64 3 Technische Details zu AFS
user@host>ktutil
ktutil: add_entry -password -p Principal@Realm -k 1 -e des3-hmac-sha1
Password for Principal@Realm: Eingabe des Passwortes
ktutil: write_kt Keytab-Datei
3.10.4 Kerberos und AFS
3.10.5 Server-Komponenten
3.10.6 Synchronisation
AFS arbeitet mit einem Kerberos-Principal pro Zelle. Dieser Principal darf derzeitig
lediglich aus Schlüsseln der Typen
• DES-CBC-CRC
• DES-CBC-MD5 und
• DES-CBC-MD4
(ein Schlüssel reicht). Wenn man das nicht beachtet, werden Tokens von Benutzern
nicht von AFS-Fileserver akzeptiert. Diese Beschränkung ist dabei zu
fallen. Enige Entwickler schreiben (Stand 30.08.2006) an einem Verschlüsselungsmodul
für das von AFS verwendete RPC-Protokoll RX namens rxk5, das
dann alle Schlüsseltypen von Kerberos5 unterstützen wird.
Der Kerberos-Server besteht minimal lediglich aus dem KDC (Key Distribution
Center), einem Daemon der als krb5kdc im Paket krb5-kdc .deb enthalten ist.
Dieser Daemon greift ausschließlich lesend auf die Kerberos5-Datenbank, die
eigentlich nur aus einer einfachen Liste besteht, zu. Die darin enthaltenen Principals
sind verschlüsselt in der Datei /var/lib/krb5kdc/principal gespeichert, der
nötige Schlüssel liegt in der Datei /etc/krb5kdc/stash.
Eine für AFS zusätzlich benötigte Komponente ist der Kerberos4-Ticket-
Konverter krb524d. Dieser Daemon läuft i.d.R. auf derselben Maschine wie
krb5kdc und beantwortet Anfragen von Programmen, die auf Tickets nach
altem Kerberos4-Standard bestehen. OpenAFS benötigt Kerberos4-Tickets.
Das Programm aklog auf einem AFS-Client benutzt diesen Dienst, um
Kerberos4-Tickets für den AFS-Dienst zu erhalten.
Der Admin-Server kadmind (Paket krb5-admin-server .deb ) ist für Änderungen
an der Kerberos-Datenbank zuständig. Darunter fallen Dinge wie:
• Ändern von Passwörtern
• Anlegen von Principals, was oft dem Anlegen eines Benutzers entspricht
• Löschen von Principals, was oft dem Entfernen eines Benutzers entspricht
• Anzeigen der in der Datenbank gespeicherten Principals
Benutzt man Kerberos zur Authentifikation ist es besser, nicht nur den Master-
Server, sondern noch ein oder mehrere Slave-Server zu betreiben. MIT-
Kerberos5 besitzt (Stand 18.08.2005) keine automatische Synchronisationsfunktion.
Ein regelmäßig aufgerufenes Script schafft Abhilfe - jedoch ist das
Updateintervall dann auch die Zeit, die ein Benutzer u.U. warten muss 43 , bis
sein neues Passwort akzeptiert wird.
43 Mit dem alten Passwort geholte Tickets und Tokens bleiben weiterhin gültig.

3.10 Kerberos 65
3.10.7 Gültigkeitsdauer von Tickets
instantafs.kerberos (siehe 9.2.18, Seite 201) ist ein InstantAFS-Skript, dass
sich um die Synchronisation kümmert.
Der AFS-Administrator kann die Gültigkeitsdauer des Tokens serverseitig beeinflussen.
Sie ist das kleinste der folgenden Gültigkeitsmaxima:
• Die maximale Lebensdauer von Tickets, die der Kerberos-KDC zu vergeben
bereit ist (Option max_life in dem File /etc/krb5kdc/kdc.conf ) auf
allen Kerberos-Servern. Die Einstellung ist lokal und gilt deshalb nur für
Tickets, die von dem entsprechenden Kerberos-Server ausgestellt werden.
• Maximum ticket life des TGT-Principals (z.B. krbtgt/CBS.MPG.DE@CBS.MPG.DE),
also die maximale Gültigkeitsdauer des TGT
• Maximum ticket life des AFS-Server-Principals (z.B. afs@CBS.MPG.DE)
• Maximum ticket life des Principals des anfordernden Benutzers (z.B.
ernie@CBS.MPG.DE)
• Die vom Client bei der Anforderung des TGT definierte maximale Ticket-
Lifetime.
Das Maximum ticket life-Feld eines Principals ist in der Kerberos-Datenbank
gespeichert und kann z.B. mit modprinc in der Kerberos-Shell geändert werden.
Leider muss auch am Kerberos-Client einiges konfiguriert werden, da sich
Kerberos-Clients wegen des 10h-Defaults trotz evtl. serverseitig längerer
Gültigkeitsdauer in Selbstbeschränkung üben und nur 10h anfordern. Die
clientseitig festgelegte Ticket-Lifetime kann wie folgt definiert werden:
• Holt man das TGT mittels
user@host>kinit -l Ticket-Lifetime
user@host>man kinit
user@host>kinit -l 1d
kann man das 10h-Default-Limit umgehen. Das Format der Ticket-
Lifetime ist unter
beschrieben. Bsp:
• Durch Änderungen im Quellcode des Kerberos-Clients. Das ist z.B. beim
PAM-Modul nötig. Zu den InstantAFS-Paketen gibt es eine gepatchte
Version von libpam-krb5 .deb , in der die 10h-Beschränkung aufgehoben
wurde. Beim Einloggen werden 1000h Gültigkeit für das TGT
angefordert. Dieser hohe Wert wird natürlich durch die oben genannten
Gültigkeitsmaxima beschränkt - i.d.R. sollte libpam-krb5 .deb unter
InstantAFS ein 26h-TGT bekommen.

4 Einrichtung einer AFS-Zelle
4.1 Vorüberlegungen
4.1.1 Standorte
4.1.2 Serverprozesse
Folgende Dinge sollten bekannt sein, bevor mit dem Aufbau der Zelle begonnen
wird:
Fileserver : Natürlich gehören die Daten möglichst in die Nähe des Benutzers. Gibt
es Außenstellen, sollte in diesen mindestens ein Fileserver stehen - aus
Gründen der Performance und Sicherheit (der Internet-Uplink kann
schließlich ausfallen).
AFS-Datenbankserver : Jedes Teilnetz (z.B. das Netzwerk einer Außenstelle) sollte einen eigenen
Datenbankserver haben. Wenn die Verbindung zum Hauptnetz abbricht,
können dann alle Benutzer im Teilnetz auf den Daten, die sich auf Fileservern
in diesem Teilnetz befinden, weiterarbeiten.
Achtung: Ohne eine Verbindung zu mindestens einem Datenbankserver kann
ein AFS-Clients nicht auf das AFS zugreifen - auch wenn alle Fileserver verfügbar
sind.
Man sollte überlegen, welche Serverprozesse auf welchen Maschinen laufen
sollen. Vor allem mit Blick auf eine mögliche Kompromittierung der AFS-Zelle
ist es sicherer, nur die wichtigsten Dienste auf den AFS-Servern laufen zu lassen.
• AFS-Datenbankserver sollten mit möglichst wenigen zusätzlichen Prozessen
belastet werden, da bekanntlich weniger Dienste auf einem Server
weniger potentielle Sicherheitslücken nach sich ziehen.
Es ist jedoch wichtig, dass der Kerberos5-Server zusammen mit dem
Kerberos4-Ticket-Konverter auf allen Datenbankservern läuft. Ein
kompromittierter Kerberos5-Server bedeutet ebenfalls, dass die Zelle
kompromittiert ist - der AFS-Key liegt schließlich im Klartext in der
Kerberos-Datenbank.
Auf einer der Maschinen muß zusätzlich der Kerberos5-Master installiert
werden. Im MIT-Kerberos5 ist eine automatische Synchronisation nicht
vorgesehen - ein Skript (z.B. instantafs.krbkerberos) wird sich später
darum kümmern, die Kerberos5-Slave-Server 1 up-to-date zu halten.
• Der verfügbare Plattenplatz unter AFS skaliert sehr gut. Man kann sehr
leicht zusätzliche AFS-Server in die Zelle aufnehmen und auch wieder
entfernen. Man sollte auf diesen nur die AFS-Serverprozesse laufen lassen.
Auch sollte man DB-Server und Fileserver nicht kombinieren.
• DNS-Server können beliebig auf andere Maschinen verteilt werden. Es
ist ratsam, mehrere DNS-Servers im Netzwerk zu haben. Ein kompletter
1 wenn vorhanden, was sehr zu empfehlen ist
66

4.2 InstantAFS 67
4.2 InstantAFS
4.2.1 Voraussetzungen, Prinzipien
Ausfall des DNS führt bereits dazu, dass sich kein Nutzer mehr anmelden
2 kann.
Bedenken sie, dass es verschiedene Problemsituationen gibt, auf die die Serverprozesse
per eMail hinweisen müssen. Ein konfigurierter Mailserver für die
Domain der Zelle und installierte Mailforwarder (z.B. nullmailer .deb ) auf allen
Servermaschinen sind sehr hilfreich.
AFS ist ein mächtiges Netzwerkdateisystem mit sehr geringem Administrationsaufwand
im laufenden Betrieb. Die Erstinstallation einer AFS-Zelle jedoch
ist jedoch besonders für Neulinge aufwändig und mit zahlreichen Tücken versehen.
InstantAFS ist der Name einer Script-Sammlung, die vor allem die Erstinstallation,
jedoch auch Dinge der späteren Administration, wie das Anlegen von
Benutzern oder das Hinzufügen von Servern, vereinfachen sollen. Es baut auf
freier Standard-Software auf und kümmert sich um deren Konfiguration.
Neben der Konfiguration von “richtigen” AFS-Zellen ist InstantAFS z.B. auch
dafür geeignet, vor kritischen Aktionen schnell eine Testzelle aufbauen zu können,
für die im Extremfall nur ein einziger Rechner nötig ist.
Die Konfiguration einer Zelle läuft wie folgt ab:
1. InstantAFS setzt eine Standard-Installation des Betriebssystems Debian
GNU/Linux Woody 3.0 bzw. Sarge 3.1 3 auf den zukünftigen Servern
voraus. Zusätzlich werden einige InstantAFS-spezifische Pakete installiert.
Vor der Installation der Rechner wird dringend die Lektüre des
Abschnitts Sicherheitshinweise (siehe 3.7.4, Seite 54) empfohlen.
2. Der Administrator wählt einen Rechner aus, von dem aus die Zelle eingerichtet
werden soll. Dieser Rechner muss nicht zwangsläufig Teil der
einzurichtenden Zelle sein. Einzige Vorraussetzung für den Rechner ist,
das das Paket instantafs mit allen Abhängigkeiten auf ihm installiert
wurde.
3. Mit dem Kommando instantafs.setup (siehe 9.2.22, Seite 203)
wird ein dialogorientiertes Tool gestartet. In diesem müssen die Server
der zukünftigen Zelle definiert und deren zukünftige Funktionen zugewiesen
werden.
4. Alle nötigen Dienste werden durch dieses Tool auf den Servern der Zelle
installiert. Dazu wird das Skript instantafs.remote (siehe 9.2.20,
Seite 202) benutzt, dass mittels ssh auf den zukünftigen Servern aufgerufen
wird.
5. Das Ergebnis ist eine arbeitsfähige AFS-Zelle, die eine einfache Benutzerverwaltung
per Kommandozeile gleich mitbringt. Diese Benutzerverwaltung
sollte sich auf einfachste Weise auch in eine bestehende Benutzerverwaltung
integrieren lassen.
InstantAFS baut hauptsächlich auf die folgenden Softwarekomponenten der
freien Linux-Distribution Debian GNU/Linux Woody:
2 Ausgefallene Kerberos-Server hingegen verhindern nur das Anmelden. Bereits verteilte Tickets
und Tokens bleiben uneingeschränkt gültig, das AFS funktioniert weiterhin.
3 Auch der Betrieb auf Servern/Clients unter Debian GNU/Linux Sid sollte keine Probleme bereiten
- das kann jedoch nicht garantiert werden.

68 4 Einrichtung einer AFS-Zelle
OpenAFS : Diese Komponente enthält Client- und Server-Komponenten des AFS-
Netzwerkprotokolls. Außerdem stellt sie Tools zur Manipulation der
AFS-Datenbanken (pts, vos) sowie zur Benutzung spezieller AFS-
Funktionen auf Dateisystemebene (fs) zur Verfügung.
OpenSSH : Diese freie Implementation des SSH-Protokolls wird während der Installation
von InstantAFS benutzt, um Kommandos auf anderen Rechnern
auszuführen.)
Kerberos5 : Kerberos wird als Authentifikationsdienst benutzt, der zusätzlich auch
den AFS-Zellenschlüssel verwaltet.
4.2.2 Woher bekommt man die benötigten Pakete
4.2.3 Obligatorische Serverpakete
Bind : Der DNS-Server bind wird benutzt, um Hostnamen der neuen Zelle
aufzulösen. Außerdem werden die AFS-DB-Server und die Kerberos5-
Server per DNS bekanntgegeben.
Hinweis: Es ist auch möglich, einen bereits bestehenden DNS-Server zu
benutzen. In diesem Fall ist bind nicht zwingend nötig.
NTP : ntp wird benutzt, um die Zeit der Zelle zwischen allen Servern und
Clients synchron zu halten.
Viele von InstantAFS benutzten Pakete sind Teil der offiziellen Debian-
Distribution. Die modifizierten Pakete sowie die InstantAFS-Pakete selbst
werden vom Max Planck Instutut für Kognitions- und Neurowissenschaften zur
Verfügung gestellt:
http://instantafs.cbs.mpg.de
Es gibt auch einen FTP-Server zum leechen:
ftp://instantafs.cbs.mpg.de
Die Servermaschinen der Zelle benötigen folgende Pakete:
openafs-fileserver .deb : Programme für AFS-File- und AFS-DB-Server
openafs-dbserver .deb : Programme für den AFS-DB-Server
krb5-kdc .deb : MIT-Kerberos5-Server
openafs-krb5 .deb : Schnittstelle zwischen MIT-Kerberos5 und OpenAFS)
bind .deb : DNS-Server
Man kann die benötigten Pakete einzeln installieren. Schneller geht es aber,
wenn man stattdessen eines oder mehrere der folgende Meta-Pakete auf der jeweiligen
Maschine installiert. Diese Pakete bestehen nur aus einer Liste von
Abhängigkeiten, so dass bei deren Installation all die abhängigen Pakete nachgezogen
werden.
instantafs-afsserver .deb für zukünftige AFS-Datenbank-Server und Fileserver
instantafs-dnsserver .deb für alle zukünftigen DNS-Server
instantafs-krb5server .deb für alle zukünftigen Kerberos5-Server
instantafs-smbserver .deb für den zukünftigen SMB2AFS-Gateway
Beachten Sie, daß auf dem ersten AFS-Fileserver auch das Paket instantafsclient
.deb installiert werden muß.

4.3 Ablauf einer InstantAFS-Installation 69
4.2.4 Obligatorische Clientpakete
Auf allen AFS-Client-Computern müssen einige Pakete installiert werden.
Zusätzlich benötigen folgende Rechner diese Pakete:
• der erste AFS-DB-Server (=db-acall-Server)
• das Samba-Gateway
• der erste AFS-Fileserver (nur zur Installation per instantafs.setup,
später kann der AFS-Client wieder deinstalliert werden).
Es existiert ein Meta-Paket namens instantafs-client .deb , das bei seiner Installation
folgende Pakete, die für AFS-Clients benötigt werden, nachzieht:
openafs-client .deb : Dieses Paket enthält den Cachemanager und einige Tools wie fs, vos
und pts. Beachten Sie bei den debconf-Fragen 4 , dass der Client noch
nicht gestartet werden darf.
openafs-modules2 .deb : Dieses virtuelle Paket wird von allen Kernel-spezifischen OpenAFS-
Modulpaketen bereitgestellt. Wenn ein solches Paket nicht vorhanden ist,
gibt es mehrere Lösungen:
1. Im Rahmen von InstantAFS werden Kernelpakete mit diversen Modulpaketen
bereitgestellt. Die Kernel haben folgende Kennungen:
2.4.27-f3 : ein Allerweltskernel (fuer 586-kompatible Rechner)
2.4.27-f3p : ein P-IV-Kernel mit SMP-Support.
Zu diesen Kerneln werden openafs-modules .deb -Pakete bereitgestellt,
die man z.B. so installiert:
root@host>dpkg -i openafs-modules-2.4.27-f3_1.2.11-3.1+rorw+2_i386.deb
2. Man kann sich auch selbst Kernelpakete und ein passendes OpenAFS-
Modulpaket bauen 5 .
instantafs .deb : Dieses Paket enthält die für InstantAFS geschriebenen Skripte. Es zieht
durch Abhängigkeiten weitere Pakete hinterher (vor allem Perl-Module).
libpam-krb5 .deb : Dieses Paket stellt ein PAM-Plugin für die Authentifikation gegen
Kerberos-Server bereit.
libpam-openafs-session .deb : Dieses Paket wird benötigt, damit man bei der Anmeldung am Rechner
gleich am AFS “angemeldet wird” (ein Token erhält).
libnss-ptdb .deb : ein Namensdienst, der die PTDB zur Namensauflösung nutzt.
4.3 Ablauf einer InstantAFS-Installation
4.3.1 Start
ntp .deb : das Zeitsynchronisationstool, das die Zeit innerhalb der Zelle abgleicht.
InstantAFS stellt eine Installationsprozedur zur Verfügung, die nach Eingabe
einiger Parameter AFS automatisch aufsetzt.
4 debconf: Tool, das die Konfiguration der Software bei der Installation unterstützt
5 Debian stellt Tools für diesen Zweck bereit, so dass ein Kernelpaket zu bauen kaum schwieriger
ist als einen neuen Kernel zu compilieren.

70 4 Einrichtung einer AFS-Zelle
user@host>instantafs.setup
4.3.2 Allgemeine Informationen zum Ablauf
Lesen Sie unbedingt vorher die Sicherheitshinweise (siehe 3.7.4, Seite 54) und
installieren Sie alle nötigen Pakete (siehe 4.2.3, Seite 68) - möglichst vor der
instantafs.setup-Installation. Wenn die neue Zelle auf einem einzelnen
Rechner laufen soll, genügt die Installation von instantafs-all .deb - alle weiteren
Pakete werden durch Abhängigkeiten ebenfalls installiert.
Wählen Sie einen Rechner aus, von dem aus sie die Installation steuern wollen.
Auf diesem Rechner wird dann instantafs.setup ausgeführt. Auf diesem
Rechner muß lediglich instantafs .deb installiert sein.
Ein zusätzlicher Parameter wird als Datei interpretiert, aus der eine vorher gespeicherte
Konfiguration geladen werden soll. Das Hauptmenü (siehe 4.1) erscheint.
Zur Darstellung der Oberfläche wird dialog benutzt.
Alle bereits abgearbeiteten Menüpunkte sind jederzeit wieder auswählbar. Bei
bestimmten Änderungen (z.B. Festlegung der DNS-Server), sind bereits abgearbeitete
Konfigurationsschritte erneut durchzuführen (z.B. Einrichtung der DNS-
Serverprozesse). Einige Menüpunkte sind immer “gefahrlos” wählbar:
write-config : Hier kann man den aktuellen Zustand von instantafs.setup komplett
speichern. Diese Funktion ist vor allem sinnvoll, wenn man verschiedene
Konfigurationen der Zelle ausprobieren will und sie dafür mehrmals
hintereinander neu konfiguriert. Es werden immer 2 Dateien geschrieben
- eine mit den geheimen Daten der Zelle und eine, die für die Allgemeinheit
bestimmt ist (Endung: .public).
read-config : Damit lässt sich eine vorher abgespeicherte Konfiguration wieder laden.
Hinweis: Es lassen sich nur “geheime” Konfigurationsfiles laden (siehe
write-config).
show-config : Dieser Menüeintrag zeigt den internen Zustand des Setup-Tools an (Bsp.
siehe Listing 4.2).
options : Hier lassen sich einige Flags setzen oder löschen (z.B. Verbose-Mode
ein/aus).
cclient : Hier werden einige Optionen für instantafs-customclient .deb gesetzt.
Das sollte nicht nötig sein, jedoch ist es u.U. hilfreich, wenn bestimmte
Einstellungen auf den Clients von den InstantAFS-Vorgaben abweichen
sollen.
Die aktivierte debug-Option im options-Untermenü sorgt dafür, dass alle benutzten
Shell-Kommandos angezeigt werden. Außerdem bewirkt diese Option,
dass nach den Konfigurationsschritten immer auf einen Druck der Enter-Taste
gewartet wird. Das ist sinnvoll, um Hinweise und Warnungen zu sehen, die sonst
durch die dialog-Dialoge sofort wieder überdeckt würden. Konnte ein Konfigurationsschritt
nicht fehlerfrei ausgeführt werden, wird auch ohne debug um
einen Tastendruck gebeten.
Listing 4.1: Hauptmenü von instantafs.setup
+−−−−−−−−−−−−−−−−−−−−−−−−−−−InstantAFS−S e t u p t o o l −−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| c e l l −name : A c e l l i s an AFS−a d m i n i s t r a t i o n −domain . Each AFS−e n a b l e d |
| Computer b e l o n g s t o e x a c t l y one AFS−C e l l . The c e l l name s h o u l d be e q u a l t o |
| t h e domain name . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | c e l l −name Choose a name f o r t h e new c e l l | |
| | | |
| | w r i t e−c o n f i g Write a c e l l −c o n f i g u r a t i o n −f i l e | |

4.3 Ablauf einer InstantAFS-Installation 71
| | read−c o n f i g Read a c e l l −c o n f i g u r a t i o n −f i l e | |
| | show−c o n f i g An overview of your c o n f i g u r a t i o n d e c i s i o n s | |
| | c c l i e n t C o n f i g u r e i n s t a n t a f s −c u s t o m c l i e n t o p t i o n s h e r e | |
| | o p t i o n s S e l e c t o p t i o n s f o r t h e c e l l −c r e a t i o n −p r o c e s s | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < OK > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
Listing 4.2: Konfigurationsübersicht von instantafs.setup
+−−−−−(+)−−−−−−−−−−−−−−C o n f i g u r a t i o n Overview−−−−−−−−−−−−−−−−−−−−−−−−+
| $VAR1 = { |
| ’ f i l e s e r v e r s ’ => [ ] , |
| ’ dns ’ => { |
| ’ s e r v e r s ’ => [ ] , |
| ’ f o r w a r d e r s ’ => [ ] |
| } , |
| ’ o p t i o n s ’ => { |
| ’ r s s h ’ => 1 , |
| ’ debug ’ => 1 |
| } , |
| ’ menustate ’ => 5 , |
| ’ time ’ => { |
| ’ s e r v e r s ’ => [ ] , |
| ’ f o r w a r d e r s ’ => [ ] |
| } , |
| ’ p r i n c i p a l s ’ => { |
+−−−−.(+)−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−( 41%)−−+
| < EXIT > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
4.3.3 Definieren von Rechnern (hosts)
Jeder Menüpunkt führt entweder zu einem Dialogfeld oder zu einem Untermenü.
Wurde ein Konfigurationsschritt erfolgreich 6 abgeschlossen, werden weitere
Konfigurationsschritte freigeschaltet. Dabei werden u.U. auch mehrere Konfigurationsschritte
freigeschaltet. Z.B. werden nach der Konfiguration der benötigten
Recher (siehe 4.3.3, Seite 71) der Menüpunkt dns freigeschaltet.
Alle in und von der Zelle benutzten Rechner müssen über den Menüpunkt
hosts definiert werden, wobei jeweils der Name des Rechners (ohne Domainname,
nur der Hostname) angegeben werden müssen.
Alle hier angegebenen Rechner werden während der Konfiguration ins DNS
aufgenommen bzw. 7 später als A-Records auf bestehenden DNS-Servern vorausgesetzt.
Auch zellenfremde Maschinen wie DNS-Forwarder, Paketserver oder Upstream-
Zeitserver müssen hier definiert werden - die benutzten Rechner müssen nicht
zwingend Teil der neuen AFS-Zelle sein - sie werden nur in die DNS-Domain
aufgenommen. Als DNS-Forwarder und Upstream-Zeitserver können nur
Rechner verwendet werden, die hier definiert wurden. Auf diesen Rechnern ist
keine weitere Konfiguration für InstantAFS nötig.
Die Liste der Rechner ist am Anfang leer (siehe Listing 4.3). Man kann Rechner
hinzufügen (siehe Listing 4.4) (natürlich auch wieder entfernen), bis die Liste
6 Die Konfiguration (z.B. des DNS) muss sinnvoll sein. Wurde kein DNS-Server konfiguriert, ist
der Schritt nicht erfolgreich abgeschlossen.
7 Wenn die DNS-Konfiguration manuell erfolgen soll (dns/dnscfg = manually)

72 4 Einrichtung einer AFS-Zelle
alle Rechner enthält (z.B. wie in Listing 4.5, die man während der Installation
benutzen will.
Für jeden Rechner können bestimmte Flags gesetzt werden, die darüber entscheiden,
ob InstantAFS darauf bestimmte Konfigurationen durchführen soll:
afs-client : Der AFS-Cache-Manager soll auf diesem Computer konfiguriert werden.
Das schliesst Einstellungen über den Zellennamen und die Konfiguration
des Cache-Directories ein.
dns-client : Die Option konfiguriert den Name Service Switch der libc so, dass er für
host-Auflösung DNS benutzt. Die Datei /etc/resolv.conf wird mit dem
korrekten Domainnamen und mit den DNS-Server-IPs bestückt und letztendlich
wird getestet, ob ein bei einem Lookup auf den eigenen Hostnamen
die korrekte FQDN zurückgeliefert wird.
ntp : Die Option steuert die Konfiguration eines lokalen NTP-Deamons (ntpd)
sowie der einmaligen NTP-Synchronisation beim Booten (ntpdate).
nss_passwd : Dieses Flag bewirkt, das der Name Service Switch der libc angewiesen
wird, für den passwd-Dienst auf libnss-ptdb .deb zurückzugreifen.
nss_justadd : Ist diese Option gesetzt, werden bei Änderungen an der NSS-Konfiguration
(durch nss_passwd oder dns-client) die zu benutzenden Dienste hinzugefügt.
Das ist. z.B. sinnvoll, wenn InstantAFS in einem bereits arbeitenden NIS-
Netzwerk eingeführt werden , die Migration aber schrittweise erfolgen
soll.
krb5-client : Dieses Flag steuert die Konfiguration des Kerberos5-Clients. Das Läuft
praktisch nur auf die Anpassung von /etc/krb5.conf hinaus.
afsserver : Diese Option konfiguriert den entsprechenden Rechner als einen AFS-
Server (siehe 7.5, Seite 146). Die File- und DB-Server der Zelle werden
automatisch zu AFS-Servern. Soll z.B. später noch ein Backup-Server
eingerichtet werden, kann man ihn mit dieser Option vorbereiten.
Hinweise:
• Wenn man keine Sonderwünsche hat, sollte man am besten keines der
Flags setzen. InstantAFS stellt später auf den Servern der Zelle automatisch
ein, was unbedingt konfiguriert werden muss.
• Sollen zusätzliche AFS-Clients konfiguriert werden folgende Konfigurationsoptionen
benötigt:
– afs-client
– dns-client
– ntp
– nss_passwd
– krb5-client
Man kann allerdings auch einfach später das Paket instantafs-customclient .deb
installieren (siehe 7.13, Seite 165).
Listing 4.3: Liste der verfügbaren Rechner - noch leer
+−−−−−−−−−−−−−−−−−−−−−−S e r v e r s f o r your new AFS−Cell−−−−−−−−−−−−−−−−−−−−−−−−−+
| This i s t h e l i s t of your h o s t . Add more or d e l e t e some i f you l i k e . A l l |
| h o s t s you e n t e r here , w i l l be known t o a l l of your c e l l h o s t s . You may |
| want t o e n t e r some h o s t s n o t b e l o n g i n g t o your c e l l , t o o |

4.3 Ablauf einer InstantAFS-Installation 73
| ( debian−package−s e r v e r s , u p s t r e a m t i m e s e r v e r s , . . . ) . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | ( no h o s t s e n t e r e d ) | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
| |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < Delete > < Add > < Done > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
Listing 4.4: Hinzufügen eines Rechners zur Liste
+−−−−−−−−−−−−−−−Add a host , you want t o use w i t h i n your Cell−−−−−−−−−−−−−−−−−+
| E n t e r Name and IP−a d d r e s s ( s e p e r a t e d by a t l e a s t one w h i t e s p a c e ) of a |
| Computer i n s i d e your Network . The Name needn ’ t r e f l e c t i t s f u t u r e |
| f u n c t i o n . Example : " zeus 1 0 . 0 . 2 . 1 " . A l t e r n a t i v e l y you may g i v e j u s t a |
| hostname ( no FQDN ) . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | f i l e s e r v e r 1 1 0 . 0 . 5 3 . 1 5 5 | |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < OK > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
Listing 4.5: Liste der verfügbaren Rechner - gefüllt
+−−−−−−−−−−−−−−−−−−−−−−S e r v e r s f o r your new AFS−Cell−−−−−−−−−−−−−−−−−−−−−−−−−+
| This i s t h e l i s t of your h o s t . Add more or d e l e t e some i f you l i k e . A l l |
| h o s t s you e n t e r here , w i l l be known t o a l l of your c e l l h o s t s . You may |
| want t o e n t e r some h o s t s n o t b e l o n g i n g t o your c e l l , t o o |
| ( debian−package−s e r v e r s , u p s t r e a m t i m e s e r v e r s , . . . ) . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | d a t e n b a n k 1 0 . 0 . 5 0 . 2 5 0 | |
| | d n s f o r w a r d e r 1 0 . 0 . 5 2 . 1 | |
| | e x t t i m e s e r v 1 0 . 0 . 5 3 . 1 6 8 | |
| | f i l e s e r v e r 1 1 0 . 0 . 5 3 . 1 5 5 | |
| | f i l e s e r v e r 2 1 0 . 0 . 5 8 . 1 | |
| | | |
| | | |
| | | |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
| |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < Delete > < Add > < Done > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
4.3.4 Auswahl der DNS-Server (dns)
In diesem Dialog kann ausgewählt werden, ob InstantAFS neue DNS-Server
aufsetzen soll, oder ob bereits existierende DNS-Server direkt benutzt werden
sollen.
Installation neuer DNS-Server durch InstantAFS (dnscfg=by InstantAFS)
Bei dieser Installationsmethode müssen DNS-Server und optional
DNS-Forwarder angegeben werden. Durch Auswahl des Hauptmenüpunktes
dns-servers (später) werden die Server eingerichtet. DNS-Server liefern Informationen
zur Domain der Zelle aus und leiten Anfragen an Rechner im
Internet, oder an die optionalen DNS-Forwarder weiter. InstantAFS wird nichts
an den DNS-Forwardern ändern.

74 4 Einrichtung einer AFS-Zelle
4.3.5 Zeitserver-Auswahl (timeservers)
Testen bereits existierender DNS-Server (dnscfg=manually) Wurde diese
Methode gewählt zeigt InstantAFS bei Auswahl des Hauptmenüpunktes dnsservers
(später) evtl. fehlende DNS-Records an und wird die Installation fortsetzen,
wenn die Records manuell auf den bereits existierenden DNS-Servern
angelegt wurden.
Hier müssen die zukünftigen NTP-Server der Zelle definiert werden. Die Zeitserver
werden miteinander verbunden und greifen dann alle unabhängig voneinander
zusätzlich auf die optionalen externen Zeitserver (“forwarder“) zu,
um sich global gültige Zeit zu holen.
Hinweise:
4.3.6 Auswahl der AFS-DB-Server (dbservers)
• Es ist ratsam, daß die (alle) AFS-DB-Server gleichzeitig Zeitserver sind.
• Wenn gerade keine frei zugänglichen Zeitserver im Internet bekannt sind
- hier ein Tip:
ptbtime1.ptb.de und ptbtime2.ptb.de - die Zeitserver der Physikalisch
Technischen Bundesanstalt.
Hier müssen einer oder mehrere AFS-Datenbank-Server für die neue Zelle
ausgewählt werden (siehe Listing 4.6. Diese Server dienen gleichzeitig als
Kerberos-Server. Von besonderer Bedeutung ist der primäre DB-Server. Eigentlich
sind unter AFS alle DB-Server gleichwertig, jedoch muß es es einen
DB-Server geben, der die Rolle des acall-db-Servers übernimmt. Ausserdem
muß ein Kerberos-Server eine Sonderstellung einnehmen - nur auf diesem
können Kerberos-Nutzer verändert (Passwort setzen, neu anlegen, löschen)
werden.
Listing 4.6: Die Liste der AFS-DB-Server
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−AFS−DB−s e r v e r s −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| This i s t h e l i s t of your DB−s e r v e r s . Each one w i l l c o n s i s t of |
| AFS−DB−s e r v e r p r o c e s s e s ( p t s e r v e r , v l s e r v e r and b u s e r v e r ) and |
| Kerberos−s e r v e r p r o c e s s e s ( krb5kdc , krb524d ) . The p a c k a g e s |
| i n s t a n t a f s −a f s s e r v e r and i n s t a n t a f s −k r b 5 s e r v e r have t o be i n s t a l l e d on any |
| AFS−DB−S e r v e r . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | d a t e n b a n k ( Primary ) 1 0 . 0 . 5 0 . 2 5 0 | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
| |
| |
| |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < D e l e t e > < Add > < Done > < Set_Primary > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
Hinweis:
• Den Primären AFS-DB-Server definiert man mit Set_Primary.
• Jeder Zeitserver sollte ein AFS-DB-Server sein und umgedreht.

4.3 Ablauf einer InstantAFS-Installation 75
4.3.7 Auswahl der AFS-Fileserver (fsservers)
In diesem Dialog werden die zukünftigen AFS-Fileserver der Zelle definiert.
Auf hier gibt es wieder einen hervorstechenden Server - den primären AFS-
Fileserver. Auf diesem wird InstantAFS 90% der Konfigurationsarbeit leisten -
die Konfiguration dieses Fileservers ist deshalb auch (später) ein eigener Menüpunkt.
Listing 4.7: Die Liste der AFS-Fileserver
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−AFS−F i l e s e r v e r s −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| This i s t h e l i s t of your AFS−f i l e s e r v e r s . F i l e s e r v e r s w i l l p r o v i d e s t o r a g e |
| f o r f i l e s r e s i d i n g i n AFS f i l e s p a c e . ’ i n s t a n t a f s −a f s s e r v e r ’ has t o be |
| i n s t a l l e d on any AFS f i l e s e r v e r . The f i r s t f i l e s e r v e r you choose , w i l l |
| c o n t a i n t h e most i m p o r t a n t volumes of t h e c e l l ( r o o t . a f s , r o o t . c e l l , . . . |
| ) . Any f i l e s e r v e r must c o n t a i n a t l e a s t one / v i c e p∗− p a r t i t i o n ( s e e |
| d o c u m e n t a t i o n ) . New volumes w i l l be c r e a t e d on t h e f i r s t p a r t i t i o n of t h e |
| p r i m a r y f i l e s e r v e r by d e f a u l t . This r e q u i r e s t h a t t h e f i r s t f i l e s e r v e r has |
| a ’ / v i c e a ’− p a r t i t i o n . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | f i l e s e r v e r 1 ( Primary ) 1 0 . 0 . 5 3 . 1 5 5 | |
| | f i l e s e r v e r 2 1 0 . 0 . 5 8 . 1 | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < D e l e t e > < Add > < Done > < Set_Primary > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
4.3.8 Auswahl eines Samba-Gateways (smbgateway)
Hier kann einem einzelnen Rechner die Rolle des Samba-Gateways zugewiesen.
Dieser Rechner wird später das Äquivalent von Klartextpasswörtern der
Kerberos-Nutzer speichern - er sollte entsprechend sicherheitsbewusst behandelt
werden.
Einige theoretische Details zu Samba-Gateway gibt’s unter A.6 auf Seite 230.
Listing 4.8: Auswahl des Samba-Gateways
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−AFS2SMB−Gateways−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| You may choose e i t h e r a s i n g l e Samba gateway h o s t or none . That h o s t w i l l |
| p r o v i d e AFS a c c e s s f o r Windows computers (= c l i e n t s s p e a k i n g SMB ) . I f you |
| want t o l e t s i m p l e Windows NT c l i e n t s a c c e s s t h e AFS f i l e s p a c e , you won ’ t |
| need a gateway − a ( more or l e s s ) n a t i v e AFS c l i e n t i s a v a i l a b l e f o r |
| Windows NT/ 2 k / XP . Windows 3 . 1 1 / 9 5 / 9 8 and ME c l i e n t s s h o u l d use a gateway . |
| I n s t a l l ’ i n s t a n t a f s −smbserver ’ on t h e t h a t machine b e f o r e c o n t i n u i n g . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | f i l e s e r v e r 2 1 0 . 0 . 5 8 . 1 | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
| |
| |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < Delete > < Add > < Done > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
4.3.9 SSH-Schlüssel für Datenbankupdates (ssh-keys)
An dieser Stelle werden die für DNS- und für Kerberos-Datenbankupdates
benötigten SSH-Schlüssel erzeugt. Die Public-Keys werden jeweils auf den

76 4 Einrichtung einer AFS-Zelle
4.3.10 Aufräumen vor der Installation (cleanup)
Slave-Servern unter /root/.ssh/authorized_keys gespeichert. Die Private-Keys
werden unter /etc/krb5kdc/syncsshkey (für Kerberos) bzw. unter /etc/bind/syncsshkey
(für DNS) abgelegt.
Die Schlüssel werden später jeweils von den Skripten instantafs.kerberos (siehe
9.2.18, Seite 201) und instantafs.bind-update (siehe 9.2.11, Seite 197) benutzt,
um die jeweilige Datenbank nach Veränderungen auf die Slave-Server zu
kopieren.
Wählt man den Menüpunkt cleanup aus, loggt sich instantafs.setup auf
allen Rechnern ein, die als Zellenmitglieder ausgewiesen sind und entfernt
bereits laufende AFS-Client-Prozesse, temporäre Files und ähnliche Dinge,
die einer Installation mit InstantAFS im Wege stehen könnten. Es werden
jedoch keine Daten von AFS-Fileservern gelöscht - diese Verantwortung wäre
für ein Programm zu groß - der Benutzer wird lediglich darauf hingewiesen.
Eventuell ist es dann nötig, alte Daten aus dem AFS manuell zu löschen. Je
nach /vice-Partition muß dann ein Befehl in folgender Form eingegeben werden:
root@afsserver> cd /vicepa && rm -rf V*.vol AFSIDat Lock
4.3.11 Überprüfen der Konfiguration (check)
4.3.12 Setup der DNS-Server (dns-servers)
4.3.13 Setup der DNS-Clients (dns-clients)
4.3.14 Setup der Zeitserver (ntp-servers)
4.3.15 Setup der NTP-Clients (ntp-clients)
Dieser spezielle Befehl löscht nur AFS-spezifische Dateien und Verzeichnisse.
Mit Betätigung dieses Menüpunktes wird die Konfiguration überprüft. Dabei
werden u.U. Hinweise und Warnungen ausgegeben. Ausserdem werden die
host-Flags (siehe 4.3.3, Seite 71) für Server der neuen Zelle sinnvoll gesetzt.
Je nach Einstellung (siehe 4.3.4, Seite 73) werden die DNS-Server der Zelle
jetzt automatisch konfiguriert oder die bereits existierenden DNS-Server auf
alle von InstantAFS benötigten DNS-Records überprüft.
Das Setup-Tool logt sich bei Auswahl dieses Menüpunktes bei allen Rechnern,
bei denen das Flag dns-client (siehe 4.3.3, Seite 71) gesetzt ist, ein und setzt die
DNS-Einstellungen (in /etc/resolv.conf ) entsprechend.
Hier werden die NTP-Server der Zelle konfiguriert. Wenn keine externen Referenzzeitserver
definiert wurden bzw. das Internet nicht erreichbar ist, sollte man
vorher die Zeit auf diesen Rechnern richtig einstellen.
Dieser Menüpunkt sorgt für die Konfiguration der NTP-Clients auf den Rechnern
der Zelle. Die NTP-Clients bestehen jeweils aus einem automatisch gestarteten
Serverprozess (ntpd), der die Zeit durch Driften und durch sanfte Anpassungen
konstant hält, sowie dem bei jedem Rechnerstart einmalig aufgerufenem
Synchronisationstool ntpdate, das die Zeit auf einen Schlag synchronisiert.

4.3 Ablauf einer InstantAFS-Installation 77
4.3.16 Setup der Kerberos-Server (krb5-servers)
4.3.17 Erzeugen der Service-Keytabs (keytabs)
4.3.18 Initialisieren der AFS-Server (afs-init)
4.3.19 Initialisierung der AFS-Datenbank (afs-db)
4.3.20 Setup des ersten Fileservers (afs-fs1)
4.3.21 Start der restlichen Fileserver (afs-fs2)
4.3.22 Setup des Samba-Gateways (samba-server)
4.3.23 Setup der acall-Server (acall)
Hier wird die Konfiguration der Kerberos-Server durchgeführt. Die REALM
der Zelle wird auf dem Kerberos-Master-Server (immer der primäre AFS-DB-
Server) angelegt. Die Kerberos-Datenbank wird anschliessend auf die Slave-
Server kopiert.
Dieser Menüpunkt sorgt dafür, dass die für die Zelle benötigten Kerberos-
Keytabs auf dem Kerberos-Master-Server erzeugt und in den Konfigurationsbaum
der Zelle eingebaut werden. Der Konfigurationsbaum befindet sich
derzeitig noch im Speicher - instantafs.setup arbeitet damit. Später
wird er im AFS abgelegt werden.
Während der Erzeugung der Keytabs werden auch host-Principals für alle Rechner
erzeugt, deren krb5-client-Flag (siehe 4.3.3, Seite 71) gesetzt ist. Dadurch
ist ein komfortables Einloggen auf diesen Rechnern möglich (siehe A.1, Seite
223).
Hier werden alle AFS-Server der Zelle mit Grundeinstellungen versehen, sie erhalten
jedoch noch keine spezifische Funktion (Fileserver, DB-Server, Backup-
Server, ...) (siehe 7.5, Seite 146).
Diese Funktion sorgt dafür, dass alle AFS-Datenbankserver der Zelle konfiguriert
werden. Die wichtigsten Principals (admin und acall) werden angelegt
und mit Zellensuperuserrechten (Mitgliedschaft in system:administrators)
ausgestattet. Ausserdem wird die BDB mit einer Beispiel-Dump-Hierarchie
versehen.
Hier wird der erste Fileserver der Zelle aufgesetzt. Das erste Mal wird ein AFS-
Client in der Zelle gestartet. Es werden sämmtliche benötigten Volumes angelegt,
alle benötigten Rechte gesetzt.
Außerdem wird der Demonstrationsbenutzer afstest komplett mit Homedirectory
eingerichtet.
Die anderen Fileserver (alle bis auf den primären) werden aktiviert.
Hier wird das Samba-Gateway konfiguriert und gestartet.
Diese Funktion loggt sich auf folgenden Rechnern ein und richtet auf diesen
instantafs.acall-server ein:
• auf dem primären AFS-DB-Server
• dem primären Kerberos5-Server

78 4 Einrichtung einer AFS-Zelle
4.3.24 Abschließendes
• dem Samba-Gateway
Mit der Konfiguration des acall-Server ist die Zelle arbeitsfähig.
Die Zelle sollte jetzt bereits arbeitsfähig sein. Hier noch einige Dinge, die zu
beachten sind:
• Wurden alle Server gegen Benutzer abgesichert (siehe 3.7.5.4, Seite 56)?
• Wird ein Backup-System gebraucht (siehe 5.2, Seite 100)?
Listing 4.9: Lohn der Mühe - das finish im Setup-Menü
+−−−−−−−−−−−−−−−−−−−−−−−−−−−InstantAFS−S e t u p t o o l −−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| f i n i s h : Your C e l l i s c o n f i g u r e d now . You may l e a v e t h i s s e t u p t o o l . |
| +−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| | f i n i s h E x i t program | |
| | | |
| | a c a l l Setup a c a l l −p r o c e s s e s on v i t a l s e r v e r s | |
| | samba−s e r v e r Setup a t h e samba−gateway | |
| | a f s−c l i e n t s S t a r t a l l openafs−c l i e n t s ( e x c e p t t h e f i r s t f i l e s e r v e r ) | |
| | a f s−f s 2 Setup r e m a i n i n g AFS−FS−S e r v e r s | |
| | a f s−f s 1 Setup f i r s t AFS−FS−S e r v e r s + a l l n e c e s s a r y volumes | |
| | a f s−db Setup AFS−DB−S e r v e r s | |
| | a f s−i n i t I n i t i a l i s i z e AFS−S e r v e r s | |
| | k e y t a b s C r e a t e n e c e s s a r y Kerberos5−Keytabs on Kerberos−Master | |
| | krb5−c l i e n t s Setup K e r b e r o s c l i e n t s | |
| | krb5−s e r v e r s C r e a t e a s i m p l e k e r b e r o s−Realm | |
| +.(+)−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ |
| |
| |
| |
| |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
| < OK > |
+−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+
4.3.25 Ein kleiner Test...
Praktisch alle Funktionen der Zelle lassen sich mit folgenden Kommandos
testen, wobei davon ausgegangen wird, dass im Laufe der Installation der
Rechner afsclient als AFS-Client konfiguriert wurde:
user@host>ssh afstest@afsclient
Password:Gewähltes Passwort von afstest
afstest@afsclient>
Mit tokens kann überprüft werden, ob afstest beim Einloggen automatisch ein
Token bekommen hat:
afstest@afsclient> tokens
Tokens held by the Cache Manager:
User’s (AFS ID 1000) tokens for afs@cbs.mpg.de [Expires Oct 5 13:36]
- -End of list- -
afstest@afsclient> ssh afsclient
Wichtig ist, dass eine Zeile, die mit User’s beginnt, angezeigt wird.
Mit dem folgenden Kommando testet man, ob die automatische Weiterleitung
des Kerberos-TGT über ssh per gssapi (siehe A.1, Seite 223)funktioniert:
Im positiven Fall sollte man ohne ein Passwort einzugeben wieder auf afsclient
eingeloggt sein. Das Kommando tokens sollte wiederum ein Token anzeigen –
eines, das den selben Ablaufzeitpunkt wie das vorherige Token hat.

4.4 Ablauf einer manuellen Grundinstallation 79
Das folgende Kommando testet, ob die acall-Schnittstelle funktioniert:
afstest@afsclient> acall db ia:helloworld
This is instanafs-acall’s innovative hello-world program.
You’ve been identified as: ’afstest’
Your Kerberos5-Principal is : ’afstest’
This is the ’db’-acall-server.
You didn’t send any arguments.
4.4 Ablauf einer manuellen Grundinstallation
4.4.1 DNS
4.4.1.1 Installation
Wenn acall oder das holen eines Tokens per ssh Probleme bereitet, könnte das
an einer fehlenden Reverse-Lookup-Zone im DNS liegen. Hinweise, wie man
sie aufsetzt, wurden während des Installationsprozesses nach
/etc/bind/named.conf
auf dem DNS-Server geschrieben.
Lesen Sie unbedingt vorher die Sicherheitshinweise (siehe 3.7.4, Seite 54).
Führen Sie die Installation der Zelle in der angegeben Reihenfolge durch. Beachten
Sie, dass sowohl auf den Clients wie auf den Servern Debian Woody
3.0 vorausgesetzt wird. In jedem anderen Fall ist die Installation trotzdem möglich,
sie kann jedoch vor allem in Bezug auf die Pfade zu Konfigurationsfiles
erheblich von dieser Beschreibung abweichen.
Installieren Sie zuerst die benötigten Pakete (siehe 4.2.3, Seite 68) auf jeder
Maschine. Sorgen Sie außerdem dafür, dass Sie in Problemfällen - vor
allem auf den zukünftigen Servern - weiterhin Pakete installieren können.
Es kann z.B. hilfreich sein, ein /etc/apt/sources.list-File zur Hand zu haben,
in dem der Paketserver als numerische IP-Adresse angegeben ist, falls die
DNS-Konfiguration auf dem Rechner von InstantAFS modifiziert wurde.
Es wird vorsichtshalber davon ausgegangen, dass auch so grundlegende Dienste
wie DNS erst noch eingerichtet werden müssen. Stehen diese Dienste bereits
zur Verfügung, müssen lediglich die Konfigurationsdateien entsprechend erweitert
werden.
Dieser Dienst ist für alle anderen unverzichtbar und wird deshalb zuerst installiert:
1. Die nötigen Softwarepakete werden auf dem Server installiert:
root@dnsserver> apt-get install instantafs-dnsserver
2. Nötig ist mindestens ein Zonenfile (Format wie in Listing 4.10, Beispiel:
siehe Listing 4.11), das im Verzeichnis /etc/bind/ angelegt werden und in
/etc/bind/named.conf eingetragen werden muss.
3. Beachten Sie, dass die IPs aller Rechner, bei einem Reverse-Lookup den
korrekten FQDN zurückliefern müssen. Legen Sie deshalb ein oder mehrere
Reverse-Lookup-Zonenfiles an (siehe Doku von bind .deb für weitere
Informationen darüber).

80 4 Einrichtung einer AFS-Zelle
Das Anlegen eines Reverse-Lookup-Zonenfiles lässt sich schwer automatisieren.
InstantAFS richtet ein solches File nicht von selbst ein. Listing
4.12 zeigt das Reverse-Lookup-Zonenfile der Beispielzelle, Listing 4.14
die Integration in das Konfigurationsfile von bind .deb .
Testen Sie nach der Einrichtung, ob der Reverse-Lookup funktioniert:
user@host>host IP eines Rechners der Zelle
$TTL 604800
@ IN SOA ns . [ Zellenname ] . r o o t . [ Zellenname ] . (
1 ; s e r i a l
604800 ; r e f r e s h
86400 ; r e t r y
2419200 ; e x p i r e
7200 ; t t l
)
IN NS ns1
IN MX 10 [ Name des M a i l s e r v e r s ]
l o c a l h o s t IN A 1 2 7 . 0 . 0 . 1
ns1 IN A [ IP des DNS−S e r v e r s ]
; W i c h t i g e s ab h i e r
; Der Punkt h i n t e r dem Domainnamen i s t w i c h t i g .
[ Name d e r Z e l l e ] . IN AFSDB 1 a f s d b 1
[ Name d e r Z e l l e ] . IN AFSDB 1 a f s d b 2
; . . . w e i t e r e AFS−DB−S e r v e r
a f s d b 1 IN CNAME [ Name des 1 . D a t e n b a n k s e r v e r s ]
a f s d b 2 IN CNAME [ Name des 2 . D a t e n b a n k s e r v e r s ]
; . . . w e i t e r e AFS−DB−S e r v e r
Wenn der erwartete FQDN (also der richtige Name des Rechners incl.
Zellenname) zurückgeliefert wurde, ist das ein gutes Zeichen.
Listing 4.10: Format des Zonenfiles für eine DNS-Domain, auf der eine AFS-
Zelle aufgesetzt werden soll
_ k e r b e r o s IN TXT " [ Name d e r Realm (DNS−Domainname i n G r o s s b u c h s t a b e n ) ] "
_ k e r b e r o s−m a s t e r . _udp IN SRV 0 0 88 k e r b e r o s
_ k e r b e r o s−adm . _ t c p IN SRV 0 0 749 k e r b e r o s
_kpasswd . _udp IN SRV 0 0 464 k e r b e r o s
k e r b e r o s 1 IN CNAME a f s d b 1
k e r b e r o s 2 IN CNAME a f s d b 2
; . . . w e i t e r e Kerberos−S e r v e r . . .
_ k e r b e r o s . _udp IN SRV 0 0 88 k e r b e r o s 1
IN SRV 0 0 88 k e r b e r o s 2
; . . . w e i t e r e Kerberos−S e r v e r . . .
k e r b e r o s IN CNAME k e r b e r o s 1
; Das Samba−Gateway . . .
sambaserv1 IN CNAME [ Name des Samba−S e r v e r s ]
; Die a c a l l −S e r v e r . . .
a c a l l . db IN CNAME a f s d b 1
a c a l l . krb5 IN CNAME k e r b e r o s
a c a l l . samba IN CNAME sambaserv1
$TTL 604800
@ IN SOA ns . cbs . mpg . de . r o o t . cbs . mpg . de . (
1 ; s e r i a l
604800 ; r e f r e s h
86400 ; r e t r y
2419200 ; e x p i r e
7200 ; t t l
)
IN NS ns1
IN MX 10 mail . cbs . mpg . de
l o c a l h o s t IN A 1 2 7 . 0 . 0 . 1
ns1 IN A 1 0 . 0 . 0 . 1 5
ns2 IN A 1 0 . 0 . 0 . 1 6
Listing 4.11: Beispiel eines Zonenfiles - die DNS-Domain der Zelle cbs.mpg.de

4.4 Ablauf einer manuellen Grundinstallation 81
; Der Punkt h i n t e r dem Domainnamen i s t w i c h t i g !
cbs . mpg . de . IN AFSDB 1 a f s d b 1
cbs . mpg . de . IN AFSDB 1 a f s d b 2
a f s d b 1 IN CNAME s e r v e r 5
a f s d b 2 IN CNAME s e r v e r 6
t i m e s e r v 1 IN CNAME s e r v e r 5
t i m e s e r v 2 IN CNAME s e r v e r 6
t i m e s e r v IN CNAME t i m e s e r v 1
sambaserv1 IN CNAME s e r v e r 2 0
_ k e r b e r o s IN TXT "CBS .MPG. DE"
k e r b e r o s IN CNAME k e r b e r o s 1
_ k e r b e r o s−m a s t e r . _udp IN SRV 0 0 88 k e r b e r o s
_ k e r b e r o s−adm . _ t c p IN SRV 0 0 749 k e r b e r o s
_kpasswd . _udp IN SRV 0 0 464 k e r b e r o s
k e r b e r o s 1 IN CNAME a f s d b 1
k e r b e r o s 2 IN CNAME a f s d b 2
_ k e r b e r o s . _udp IN SRV 0 0 88 k e r b e r o s 1
IN SRV 0 0 88 k e r b e r o s 2
; Rechner d e r Z e l l e
s e r v e r 5 IN A 1 0 . 0 . 0 . 5
s e r v e r 6 IN A 1 0 . 0 . 0 . 6
s e r v e r 1 0 IN A 1 0 . 0 . 0 . 1 0
s e r v e r 1 1 IN A 1 0 . 0 . 0 . 1 1
s e r v e r 1 5 IN A 1 0 . 0 . 0 . 1 5
s e r v e r 1 6 IN A 1 0 . 0 . 0 . 1 6
s e r v e r 2 0 IN A 1 0 . 0 . 0 . 2 0
c l i e n t IN A 1 0 . 0 . 0 . 1 0 0
; E x t e r n e Rechner
d e b s e r v IN A 1 0 . 0 . 5 0 . 1 1 5
p t b t i m e 1 IN A 1 9 2 . 5 3 . 1 0 3 . 1 0 3
p t b t i m e 2 IN A 1 9 2 . 5 3 . 1 0 3 . 1 0 4
e x t d n s s e r v 1 IN A 1 0 . 0 . 5 2 . 1
e x t d n s s e r v 2 IN A 1 0 . 0 . 5 2 . 2
; Die a c a l l −S e r v e r
a c a l l . db IN CNAME a f s d b 1
a c a l l . krb5 IN CNAME k e r b e r o s
a c a l l . samba IN CNAME sambaserv1
$TTL 604800
@ IN SOA ns1 r o o t . cbs . mpg . de . (
1 ; s e r i a l
604800 ; r e f r e s h
86400 ; r e t r y
2419200 ; e x p i r e
7200 ; t t l
)
IN NS ns1 . cbs . mpg . de .
5 IN PTR s e r v e r 5
6 IN PTR s e r v e r 6
10 IN PTR s e r v e r 1 0
11 IN PTR s e r v e r 1 1
15 IN PTR s e r v e r 1 5
16 IN PTR s e r v e r 1 6
20 IN PTR s e r v e r 2 0
100 IN PTR c l i e n t
Listing 4.12: Ein Reverse-Lookup-Zonenfile am Beispiel der Zelle cbs.mpg.de
Die AFSDB-Einträge werden vom AFS-Client benutzt, um die DB-Server
zu finden. Die Konstruktionen mit dem afsdb1-CNAME (Listing 4.11) sind
nicht unbedingt nötig, jedoch hilfreich, da man auf diese Weise schnell einen
Rechner mit einer bestimmten Funktion benennen kann (z.B. afsdb1 - ein
AFS-DB-Server). Die diversen Kerberos-bezogenen Records reichen für die
Arbeitsplatzrechner, also für Kerberos-Client-Funktionen, als Konfiguration
aus. Man kann dann mit einem generischen /etc/krb5.conf -File arbeiten und
trotzdem die Kerberos5-Server bei Bedarf wechseln.
Ein Eintrag in /etc/bind/named.conf wie in Listing 4.13 lässt bind auf das
Zonenfile zugreifen - ein Beispiel ist im Listing 4.14 zu finden.

82 4 Einrichtung einer AFS-Zelle
zone " [ Name d e r Z e l l e ] " {
t y p e m a s t e r ;
f i l e " / e t c / bind / [ Name des neuen Z o n e n f i l e s ] " ;
n o t i f y no ;
}
; . . .
[ Z o n e n e i n t r a g f u e r Reverse−Lookups ]
; . . .
; . . .
zone " cbs . mpg . de " {
t y p e m a s t e r ;
f i l e " / e t c / bind / db . cbs . mpg . de " ;
n o t i f y no ;
}
zone " 0 . 0 . 1 0 . in−addr . a r p a " {
t y p e m a s t e r ;
f i l e " / e t c / bind / r e v . 1 0 " ;
n o t i f y no ;
}
; . . .
4.4.1.2 Automatische Synchronisation der DNS-Server
Listing 4.13: Zur Datei /etc/bind/named.conf hinzuzufügende Zeilen
Listing 4.14: Zur Datei /etc/bind/named.conf hinzuzufügende Zeilen in der Beispielzelle
cbs.mpg.de
Ist noch kein redundantes DNS mit automatischer Synchronisation vorhanden,
stellt instantafs .deb das Skript instantafs.bind-update zur Verfügung.
Es ist in der Lage, einen DNS-Server auf beliebige andere Maschinen zu
klonen. So funktioniert es:
1. Man lege eine Datei /etc/bind/syncservers auf dem primären DNS-Server
an, die zeilenweise die Adressen 8 aller (also incl. dem primären) DNS-
Server enthält.
2. Die ebenfalls anzulegende Datei (/etc/bind/syncfiles) muss die Namen aller
zu kopierenden Files im Verzeichnis /etc/bind enthalten. Listing 4.15
enthält ein Beispiel.
3. Sollen weitere DNS-Server zum Einsatz kommen, müssen auf diesen
Rechnern lediglich das Pakete instantafs-dnsserver .deb installiert
werden.
4. Die Synchronisation wird gestartet mit:
root@dnsmaster> instantafs.bind-update
Das Skript benutzt ssh, um die anderen DNS-Server upzudaten. Es versucht
sie unter den in /etc/bind/syncservers aufgeführten Namen zu erreichen.
Hinweis: Die Namen sollten sich zur Not ohne DNS-Server auflösen lassen
(z.B. durch einen Eintrag in /etc/hosts). Es können auch IP-Adressen
in /etc/bind/syncservers eingetragen werden.
5. Um das Update nicht-interaktiv auszuführen (empfohlen), müssen Sie
dafür sorgen, dass sich SSH ohne ein Passwort auf den Slave-DNS-
Servern einloggen kann - z.B. mittels Public-Key-Authentifikation (siehe
8 Namen sind zwar OK, IP-Adressen jedoch besser - schliesslich könnte wärend der Synchronisation
etwas schiefgehen, womit die Host-Namensauflösung unmöglich wird.

4.4 Ablauf einer manuellen Grundinstallation 83
named . conf
db . 0
db . 1 2 7
db . 2 5 5
db . l o c a l
db . r o o t
db . cbs . mpg . de
r e v . 1 0
s y n c f i l e s
s y n c s e r v e r s
4.4.2 Client-Konfiguration
4.4.2.1 DNS
7.3.1, Seite 142), wobei dann der entsprechende private Schlüssel unter
/root/.ssh/id_dsa liegen muss.
6. Die automatische Synchronisation wird z.B. durch folgende Zeile in einem
cron-File realisiert:
1 * * * * root instantafs.bind-update
Listing 4.15: Beispiel der Datei /etc/bind/syncfiles für die Zelle cbs.mpg.de
Installieren Sie die benötigten Pakete mit:
root@host>apt-get install instantafs-client
n a m e s e r v e r [ IP des Nameservers ]
n a m e s e r v e r [ IP des 2 . Nameservers ]
# . . .
s e a r c h [ Zellenname ]
n a m e s e r v e r 1 0 . 0 . 5 8 . 3
n a m e s e r v e r 1 0 . 0 . 5 8 . 6
s e a r c h cbs . mpg . de
4.4.2.2 Kerberos
Beachten Sie, dass auch die AFS-Server dabei als DNS- sowie Kerberos-Clients
gelten: auch auf diesen müssen die entsprechenden Client-Funktionen konfiguriert
werden.
Die Datei /etc/resolv.conf enthält Informationen über das DNS. Sie muss wie in
Listing 4.16 aussehen - in der Beispielzelle wäre das wie in Listing 4.17.
Listing 4.16: Format von /etc/resolv.conf
Listing 4.17: Format von /etc/resolv.conf
Bearbeiten Sie die Datei /etc/krb5.conf - das Format ist im Listing 4.18 skizziert.
[ l i b d e f a u l t s ]
d e f a u l t _ r e a l m = [ Name d e r Realm ]
d e f a u l t _ t g s _ e n c t y p e s = des3−hmac−sha1 des−cbc−c r c des−cbc−md5
d e f a u l t _ t k t _ e n c t y p e s = des3−hmac−sha1 des−cbc−c r c des−cbc−md5
p e r m i t t e d _ e n c t y p e s = des3−hmac−sha1 des−cbc−c r c des−cbc−md5
k r b 4 _ c o n f i g = / e t c / krb . conf
k r b 4 _ r e a l m s = / e t c / krb . r e a l m s
k d c _ t i m e s y n c = 1
c c a c h e _ t y p e = 4
t i c k e t _ l i f e t i m e = [ Maximale T i c k e t−G u e l t i g k e i t ]
f o r w a r d a b l e = t r u e
p r o x i a b l e = t r u e
[ r e a l m s ]
[ Name d e r Realm ] = {
a d m i n _ s e r v e r = k e r b e r o s
Listing 4.18: Format der Datei /etc/krb5.conf

}
84 4 Einrichtung einer AFS-Zelle
[ l o g i n ]
k r b 4 _ c o n v e r t = t r u e
k r b 4 _ g e t _ t i c k e t s = t r u e
[ a p p d e f a u l t s ]
a f s _ k r b 5 = {
[ Name d e r Realm ] = {
a f s = f a l s e
}
}
Setzen sie jeweils für [Name der Realm] und [Zellenname] die entsprechenden
Werte für ihre Zelle ein. Das Konstrukt unter [appdefaults]
ist zur Aufwärtskompatibilität mit neueren Kerberos-Versionen nötig - stört jedoch
unter Debian 3.0 Woody nicht.
Hinweis: Die Zeile
admin_server = kerberos
ist theoretisch nicht nötig, da der Record
_kerberos-adm._tcp IN SRV 0 0 749 kerberos
im DNS diese Information bereits liefert. Zumindest das kpasswd-Kommando
kann jedoch in der mit Woody gelieferten Kerberos-Version mit den entsprechenden
DNS-Records nichts anfangen und verlässt sich auf die Einträge in
/etc/krb5.conf.
Listing 4.19 zeigt am Beispiel der Zelle cbs.mpg.de wie /etc/krb5.conf auszusehen
hat.
[ l i b d e f a u l t s ]
d e f a u l t _ r e a l m = CBS .MPG. DE
d e f a u l t _ t g s _ e n c t y p e s = des3−hmac−sha1 des−cbc−c r c des−cbc−md5
d e f a u l t _ t k t _ e n c t y p e s = des3−hmac−sha1 des−cbc−c r c des−cbc−md5
p e r m i t t e d _ e n c t y p e s = des3−hmac−sha1 des−cbc−c r c des−cbc−md5
k r b 4 _ c o n f i g = / e t c / krb . conf
k r b 4 _ r e a l m s = / e t c / krb . r e a l m s
k d c _ t i m e s y n c = 1
c c a c h e _ t y p e = 4
t i c k e t _ l i f e t i m e = 93600
f o r w a r d a b l e = t r u e
p r o x i a b l e = t r u e
[ r e a l m s ]
CBS .MPG. DE = {
a d m i n _ s e r v e r = k e r b e r o s
}
[ l o g i n ]
k r b 4 _ c o n v e r t = t r u e
k r b 4 _ g e t _ t i c k e t s = t r u e
[ a p p d e f a u l t s ]
a f s _ k r b 5 = {
CBS .MPG. DE = {
a f s = f a l s e
}
}
4.4.2.3 NTP
Listing 4.19: Beispiel der Datei /etc/krb5.conf anhand der Zelle cbs.mpg.de
Das Zeitsynchronisationstool NTP (Network Time Protocol) benötigt die beiden
Pakete ntp .deb und ntpdate .deb . Die Konfiguration der zu benutzenden Zeitserver
erfolgt normalerweise bei der Paket-Installation. Nachträglich geht es
natürlich auch:
1. Die Datei /etc/default/ntp-servers muss eine einzelne Zeile enthalten, die
wie folgt aussieht:
NTPSERVERS=timeserv1 timeserv2"

4.4 Ablauf einer manuellen Grundinstallation 85
In diesem Fall gibt es 2 Zeitserver: timeserv1 und timeserv2.
2. Die Datei /etc/ntp.conf muss wie in Listing 4.20 aussehen. Weitere Zeitserver
müssen jeweils mit einer zusätzlichen server-Direktive bedacht
werden.
3. Mit folgenden Kommandos wird die Zeitsyncronisation gestartet:
root@host>/etc/init.d/ntp-simple stop
root@host>/etc/init.d/ntpdate start
root@host>/etc/init.d/ntp-simple start
l o g f i l e / v a r / l o g / ntpd
d r i f t f i l e / v a r / l i b / n t p / n t p . d r i f t
s t a t s d i r / v a r / l o g / n t p s t a t s /
s t a t i s t i c s l o o p s t a t s p e e r s t a t s c l o c k s t a t s
f i l e g e n l o o p s t a t s f i l e l o o p s t a t s t y p e day e n a b l e
f i l e g e n p e e r s t a t s f i l e p e e r s t a t s t y p e day e n a b l e
f i l e g e n c l o c k s t a t s f i l e c l o c k s t a t s t y p e day e n a b l e
s e r v e r t i m e s e r v 1 . cbs . mpg . de
4.4.2.4 AFS-Client
Beachten Sie, dass Zeitserver der Zelle eine etwas andere Konfigurationsdatei
benötigen (siehe 4.4.3, Seite 86).
Listing 4.20: Listing Beispiel für die Datei auf einem NTP-Client /etc/ntp.conf
Für den AFS-Client sind folgende Konfigurations-Dateien auf den Client-
Rechnern anzupassen:
/etc/openafs/CellServDB : In dieser Datei sind im AFS die Namen sowie die IP-Adressen vieler
weltweit erreichbarer Zellen gespeichert (siehe 3.4, Seite 38). Bei Benutzung
der -afsdb-Option des AFS-Clients (empfohlen), muss diese
Datei lediglich vorhanden sein:
root@host>rm /etc/openafs/CellServDB && touch /etc/openafs/CellServDB
Hinweis: Sind in dieser Datei Daten zur eigenen Zelle vorhanden, werden
die Einstellungen im DNS damit übersteuert. Das sollte man vermeiden,
wenn man die DB-Server per DNS bekannt machen will.
/etc/openafs/afs.conf.client : Diese Datei steuert einige Eigenschaften des AFS-Clients und sieht z.B.
wie folgt aus:
AFS_AFSDB=true
AFS_CRYPT=true
AFS_DYNROOT=false
AFS_FAKESTAT=true
Die Erklärung zu den Optionen findet man unter 3.5.6, Seite 43. Die Option
AFS_CLIENT=false
bewirkt, dass AFS nicht beim Hochfahren des Rechners automatisch gestartet
wird. Der automatische Start muss explizit deaktiviert sein, wenn
die Zelle noch nicht einsatzfähig ist.
/etc/openafs/ThisCell : Diese Datei muss genau eine (mit NewLine) abgeschlossene Zeile enthalten
auf der der Name der Zelle steht. Beispiel:
root@host>echo cbs.mpg.de > /etc/openafs/ThisCell

86 4 Einrichtung einer AFS-Zelle
4.4.3 Zeitserver
/etc/openafs/cacheinfo : Dieses File muss aus einer Zeile bestehen:
/afs:/var/cache/openafs:[Cachegröße]
Passen Sie diese Zeile je nach gewünschter Art und Größe des Caches an
(siehe 3.5.1, Seite 39).
Legen Sie außerdem einen Link im root-Verzeichnis an, der auf das root-
Volume ihrer Zelle zeigt. Das geht z.B. für die Zelle cbs.mpg.de wie folgt:
root@host>ln -s /afs/cbs.mpg.de /a
l o g f i l e / v a r / l o g / ntpd
d r i f t f i l e / v a r / l i b / n t p / n t p . d r i f t
s t a t s d i r / v a r / l o g / n t p s t a t s /
s t a t i s t i c s l o o p s t a t s p e e r s t a t s c l o c k s t a t s
f i l e g e n l o o p s t a t s f i l e l o o p s t a t s t y p e day e n a b l e
f i l e g e n p e e r s t a t s f i l e p e e r s t a t s t y p e day e n a b l e
f i l e g e n c l o c k s t a t s f i l e c l o c k s t a t s t y p e day e n a b l e
r e s t r i c t d e f a u l t kod n o t r a p nomodify n opeer
r e s t r i c t t i m e s e r v 2 nomodify
; . . . w e i t e r e r e s t r i c t −Z e i l e n f ü r Z e i t s e r v e r
r e s t r i c t 1 2 7 . 0 . 0 . 1 nomodify
s e r v e r p t b t i m e 1 . p t b . de
s e r v e r p t b t i m e 2 . p t b . de
p e e r t i m e s e r v 2
; . . . w e i t e r e peer−Z e i l e n f ü r Z e i t s e r v e r
4.4.4 Die Kerberos-Server
4.4.4.1 Der Master
Die NTP-Prozesse auf den Zellenzeitservern werden untereinander vernetzt.
Die Konfiguration ist im Listing 4.21 veranschaulicht. Tragen Sie als server-
Direktiven die Zeitserver ein, von denen die Zeitserver der neuen Zelle ihre
Zeit erhalten sollen.
Listing 4.21: Beispiel für die Datei /etc/ntp.conf auf einem NTP-Server
Sind mehr als zwei Zeitserver in der Zelle vorhanden, müssen für jeden weiteren
jeweils diese beiden Zeilen eingetragen werden:
restrict timeserv[Nummer] nomodify
peer timeserv[Nummer]
Man gehe wie folgt vor:
1. Alle für den Kerberos-Server nötigen Pakete werden mit diesem Metapaket
installiert:
root@kerberos> apt-get install instantafs-krb5server
[ k d c d e f a u l t s ]
k d c _ p o r t s = 750 ,88
[ r e a l m s ]
2. Die Datei /etc/krb5kdc/kdc.conf muss angelegt werden, so dass sie wie
folgt aussieht (Ersetzen Sie [Name der Realm] durch den Namen
der neuen Kerberos-Realm):
Listing 4.22: /etc/krb5kdc/kdc.conf

4.4 Ablauf einer manuellen Grundinstallation 87
[ Name d e r Realm ] = {
database_name = / v a r / l i b / krb5kdc / p r i n c i p a l
admin_keytab = FILE : / e t c / krb5kdc / kadm5 . k e y t a b
a c l _ f i l e = / e t c / krb5kdc / kadm5 . a c l
k e y _ s t a s h _ f i l e = / e t c / krb5kdc / s t a s h
k d c _ p o r t s = 750 ,88
m a x _ l i f e = 1d 2h 0m 0 s
m a x _ r e n e w a b l e _ l i f e = 7d 0h 0m 0 s
m a s t e r _ k e y _ t y p e = des3−hmac−sha1
s u p p o r t e d _ e n c t y p e s = des3−hmac−sha1 : normal des−cbc−c r c : normal des : normal des : v4 des : norealm des : o n l y r e a l m des : a f s 3
d e f a u l t _ p r i n c i p a l _ f l a g s = + p r e a u t h
}
root@kerberos> krb5_newrealm
4.4.4.2 Erstellen des AFS-Keys
3. Eine Kerberos-Realm wird angelegt:
Man wird nun mit einer Passwortabfrage konfrontiert. Das Passwort sollte
komplex sein, aufgeschrieben werden und anschließend in etwas gut
Verschließbarem verschwinden - es wird im Produktionsbetrieb nicht benötigt.
4. Die Kerberos-Realm ist damit eigentlich schon fertig - diverse Principals
müssen jedoch noch angelegt werden.
5. Richten sie auf dem Kerberos-Master-Server den krb5-acall-Server ein
(siehe 7.6.4, Seite 151).
Der AFS-Key (siehe 3.7.1, Seite 47) wird im Kerberos durch einen Principal
repräsentiert. Hier ist beschrieben wie man den Key erzeugt.
Achtung: Wenn man den Schlüssel neu aus der Kerberos-Datenbank extrahiert
(ktadd [...]) wird dieser verändert. Macht man das in einer bereits arbeitenden
AFS-Zelle, kann ab diesem Zeitpunkt kein Benutzer mehr gültige Tokens
bekommen. Braucht man eine Keytab mit dem AFS-Key einer arbeitenden
Zelle, hilft vielleicht A.8 auf Seite 235 weiter.
1. Hinter dem Kommando kadmin.local verbirgt sich eine Shell, mit der
der Kerberos-Server interaktiv gesteuert werden kann. Alle Kommandos
können jedoch auch auf der Kommandozeile ausgelöst werden.
kadmin.local wird jetzt benutzt, um den afs-Principal anzulegen:
root@kerberos> kadmin.local -q ’addprinc -requires_preauth \
-randkey -e des-cbc-crc:afs3 afs’
2. Der Kerberos-Schlüssel muss in eine Datei gespeichert werden:
root@kerberos> kadmin.local -q ’ktadd -k /tmp/afs.keytab’ \
-e des-cbc-crc:afs3 afs’
Achtung: Es handelt sich dabei nicht um eine Kopie des Schlüssels, vielmehr
wird ein neuer Schlüssel erzeugt, jedoch nicht nur in der Kerberos-
Datenbank, sondern zusätzlich in dem Keytab-File abgelegt. Führt man
diesen Befehl erneut aus, sind damit alle vorher exportierten Keytabs dieses
Principals ungültig!
3. Zur Sicherheit sollte man die Keytabs überprüfen. Das geht z.B. so:

88 4 Einrichtung einer AFS-Zelle
root@kerberos> (echo rkt /tmp/afs.keytab ; echo list) | \
ktutil | egrep ’ˆ+[0-9]’
1 1 afs@CBS.MPG.DE
Jeder Schlüssel wird auf einer Zeile ausgegeben. Die zweite Zahl auf
jeder Zeile zeigt dabei die KVNO (Key-Version-Number) an. Werden
mehrere Schlüssel angezeigt, dann ist beim Exportieren (ktadd) des
AFS-Keys im Kerberos etwas schief gegangen. Löschen Sie in diesem
Fall den afs-Principal und die Keytab wieder:
root@kerberos> rm -f afs.keytab
root@kerberos> echo yes | kadmin.local -q ’delprinc afs@ CBS.MPG.DE ’
4.4.4.3 Anlegen des Zellen-Superusers
und fangen Sie noch einmal bei 1. an.
Hinweis: Eine häufige Fehlerquelle ist, den -e-Parameter zu vergessen.
Das afs.keytab-File muss gut aufgehoben werden - aus ihm wird später der afs-
Key mittels asetkey extrahiert. Es ist wichtig, dass niemand unautorisiert den
Inhalt von afs.keytab lesen kann - das wäre wie ein herumliegender beliebig
leicht kopierbarer Generalschlüssel zur Zelle.
Ein Principal wird das Recht erhalten, die Kerberos-Datenbank zu bearbeiten
und im AFS als Zellensuperuser aufzutreten. So wird er eingerichtet:
root@kerberos> kadmin.local -q ’addprinc -requires_preauth admin’
Geben Sie zweimal das Passwort des Zellensuperusers ein. Die Datei
/etc/krb5kdc/kadm5.acl muss aus einer einzelnen Zeile bestehen:
admin *
Jetzt muss der Kerberos-Admin-Server neu gestartet werden um /etc/krb5kdc/kadm5.acl
neu einzulesen:
root@kerberos> /etc/init.d/krb5-admin-server force-reload
4.4.4.4 Der acall-Principal
Der admin-Principal ist bis jetzt nur als Kerberos5-Principal vorhanden. Um ihn
zu einem richtigen AFS-User zu machen, muss er noch in die AFS-Datenbank
eingetragen werden. Das geht jedoch erst, wenn später die AFS-Datenbank konfiguriert
wird.
Für einige acall-Funktionen (siehe 7.6.2, Seite 149) wird ein eigener Principal
benötigt. Man legt diesen wie folgt an:
root@kerberos> kadmin.local -q ’addprinc -randkey acall’
Anschliessend wird der Schlüssel des acall-Principals in eine Datei gespeichert:
root@kerberos> kadmin.local -q ’ktadd -k /tmp/acall.keytab acall’
Diese Keytab wird später auf dem db-acall-Server — also auf dem Kerberos-
Master — benötigt.

4.4 Ablauf einer manuellen Grundinstallation 89
4.4.4.5 Slave-Server-Konfiguration
Die Datenbank von Slave-Kerberos-Servern muss möglichst immer exakt mit
der auf dem Master-Server übereinstimmen. Da im MIT-Kerberos5 keine automatische
Synchronisation vorgesehen ist, muss ein Skript einspringen.
4.4.4.5.1 Einstellungen auf den Slave-Servern Folgendes ist dazu auf jedem
der Kerberos-Slave-Server zu tun:
1. Alle nötigen Pakete sind zu installieren:
root@host>apt-get install instantafs-krb5server
2. Legen Sie die Datei /etc/krb5kdc/kdc.conf wie in Listing 4.22 an, ersetzen
Sie [Name der Realm] durch den Namen der neuen Realm.
4.4.4.5.2 Einstellungen auf dem Kerberos-Master Die Kerberos-Datenbank
muß vom Master-Server auf alle Slave-Server kopiert werden. Das sollte man
mindestens einmal von Hand machen, um die öffentlichen SSH-Schlüssel der
Slave-Server zu bestätigen:
root@kerberos> instantafs.kerberos -domain cbs.mpg.de -server server2,server3
4.4.5 Der erste AFS-DB-Server
4.4.5.1 Anlegen der Datenbank
Die Namen server3 und kerberos-3 sind Beispiele - hier müssen die qualifizierten
Namen (am besten FQDNs) der Slave-Server stehen - getrennt durch Kommas.
Als Domain wird hier cbs.mpg.de verwendet - man muss in der eigenen
Zelle dann den den eigenen Domainnamen angeben.
Um das Update nicht-interaktiv auszuführen (empfohlen), müssen Sie dafür
sorgen, dass sich SSH ohne ein Passwort auf den Slave-DNS-Servern einloggen
kann - z.B. mittels Public-Key-Authentifikation (siehe 7.3.1, Seite 142).
instantafs.kerberos versucht, den privaten Schlüssel /etc/krb5kdc/syncsshkey
dafür zu benutzen. Legen Sie also einen privaten SSH-Schlüssel an diese Position
und platzieren sie die zugehörigen Public-Keys in den /root/.ssh/authorized_keys
Ein automatisches Update kann man z.B. wie folgt aufsetzen:
• Durch folgenden crontab-Eintrag wird einmal pro Tag ge-updated:
1 * * * * root instantafs.kerberos -server server2,server3
-domain cbs.mpg.de
• Jetzt sollte man noch dafür sorgen, dass die Datenbank nach jeder Änderung
auf die Slave-Server kopiert wird. Dazu kann man mit einem
/etc/inittab-Job arbeiten. Dazu ist diese Zeile in die Datei /etc/inittab
einzutragen:
iaku:23:respawn:/usr/bin/instantafs.kerberos -w
60 -server server2,server3 -domain cbs.mpg.de
Was -w bedeutet ist unter 9.2.18 erklärt.
Richten Sie zuerst einen unspezialisierten AFS-Server ein (siehe 7.5, Seite 146).
Die PTDB muss vor dem ersten Start des ersten Servers bereits einen definierten
Zustand haben.

90 4 Einrichtung einer AFS-Zelle
Folgendes Kommando sollte vorsichtshalber benutzt werden, um evtl. vorhandene
Reste einer alten AFS-Datenbank zu entfernen:
root@afsdb> rm -f /var/lib/openafs/db
Die PTDB muss mit default-Werten initialisiert und der Zellenadministrator angelegt
werden. Diese Werte lege man als Default in /tmp/ptdb.base ab:
root@afsdb> cat /tmp/ptdb.base
admin 128/20 1 -204 -204
acall 128/20 2 -204 -204
system:administrators 130/20 -204 -204 -204
admin 1
acall 2
Achtung:Die Leerzeichen jeweils am Anfang der Zeilen unter system:administrators
sind essentiell.
Nun initialisiere man damit die PTDB:
root@afsdb> pt_util -p /var/lib/openafs/db/prdb.DB0 -w < /tmp/ptdb.base
4.4.5.2 Konfiguration der Serverprozesse
VLDB und BDB werden beim ersten Start der jeweiligen Serverprozesse automatisch
initialisiert, sie sind im Grundzustand leer.
Richten Sie auf dem ersten AFS-DB-Server den db-acall-Server ein (siehe
7.6.4, Seite 151).
Dem AFS-DB-Server muß mitgeteilt werden, dass es in der Zelle vorerst nur
ihn gibt:
root@afsdb> bos addhost localhost Name des Rechners
Dabei muss Name des Rechners der DNS-Name 9 der lokalen Maschine
sein.
Der ptserver wird aktiviert...
root@afsdb> bos create localhost ptserver simple \
/usr/lib/openafs/ptserver -localauth
... der vlserver gestartet...
root@afsdb> bos create localhost vlserver simple \
/usr/lib/openafs/vlserver -localauth
... und der buserver hochgefahren:
root@afsdb> bos create localhost buserver simple \
/usr/lib/openafs/buserver -localauth
9 Vorzugsweise der FQDN

4.4 Ablauf einer manuellen Grundinstallation 91
4.4.6 Der erste Fileserver
Richten Sie einen unspezialisierten AFS-Server ein (siehe 7.5, Seite 146), wenn
der Rechner nicht bereits ein arbeitender AFS-Server ihrer Zelle (z.B. ein DB-
Server) ist.
Sorgen Sie dafür, dass das Speichersubsystem am Server angeschlossen und
mindestens eine Partition entsprechend eingerichtet ist (siehe 3.8.3, Seite 59).
Im folgenden wird davon ausgegangen, dass auf dem Fileserver die Partition
/vicepa als AFS-Datenpartition zur Verfügung steht.
Der AFS-Client muss komplett (mit allen Basisdiensten wie DNS und Kerberos)
konfiguriert sein bzw. konfiguriert werden, wenn er es noch nicht ist (siehe
4.4.2, Seite 83).
Achtung: Der Client darf noch nicht gestartet werden/sein.
Der Fileserver wird mit folgendem Kommando eingerichtet und aktiviert:
root@afsserv1> bos create localhost -instance fs -type fs \
-cmd /usr/lib/openafs/fileserver \
-cmd /usr/lib/openafs/volserver \
-cmd /usr/lib/openafs/salvager -localauth
Das AFS-Rootvolume wird angelegt:
root@afsserv1> vos create localhost a root.afs -localauth
Das Zellen-Rootvolume wird angelegt:
root@afsserv1> vos create localhost a root.cell -localauth
Der AFS-Client wird gestartet. Das ist erst jetzt möglich, da das AFS-Root-
Volume (root.afs) bereits angelegt sein muss.
root@afsserv1> /etc/init.d/openafs-client force-start
root@afsserv1> kinit admin
root@afsserv1> aklog
Jetzt wird das Token eines Zellensuperusers gebraucht. Zuerst wird ein
Kerberos5-TGT organisiert:
... anschliessend ein AFS-Ticket geholt und in einem Token umgerechnet...
Hinweis: Lokale Superuserrechte sind ab jetzt eigentlich nicht mehr nötig - die
Macht des Zellensuperusertokens reicht für alle AFS-Befehle.
Das Zellenrootvolume wird in das AFS-Rootvolume gemountet...
admin@afs>fs mkmount /afs/Zellenname root.cell
... und ein alternativer Mountpoint nach root.cell angelegt, über den die RW-
Instanz erreichbar ist (siehe 3.2.3, Seite 34):
admin@afs>fs mkm /afs/.Zellenname root.cell -rw

92 4 Einrichtung einer AFS-Zelle
Jetzt wird ein Mountpoint angelegt, über den die RW-Instanz des AFS-
Rootvolumes erreicht werden kann:
admin@afs>fs mkm /afs/.root.afs root.afs -rw
Dieser Mountpoint wird nur dann benötigt, wenn weitere Zellen in den AFS-
Namensraum eingebunden werden sollen.
Die Verzeichnisrechte in den beiden Root-Volumes werden so gesetzt, dass
jeder hindurchwechseln darf:
admin@afs>fs sa -path /afs -path /afs/.Zellenname system:anyuser rl
Von beiden Root-Volumes wird eine RO-Instanz auf dem ersten Fileserver erstellt.
Man sollte dringend weitere hinzufügen, wenn weitere Fileserver verfügbar
sind.
admin@afs>vos addsite localhost Partition root.afs -localauth
admin@afs>vos addsite localhost Partition root.cell -localauth
Jetzt werden die neu angelegten RO-Instanzen noch mit den RWs synchronisiert:
admin@afs>vos release root.afs
admin@afs>vos release root.cell
Hinweise:
user@host>tokens
user@host>kinit admin
user@host>aklog
admin@afs>
Wenn bei Schritt 4.4.6 ein Fehler auftritt, liegt das mit hoher Wahrscheinlichkeit
an schlecht synchronisierter Zeit zwischen den Rechnern der Zelle oder aber
daran, dass die auf den AFS-Servern installierten AFS-Keys nicht korrekt sind.
Die AFS-Keys müssen auf allen Rechnern gleich sein und mit dem Schlüssel
des afs-Principals in der Kerberos-Datenbank übereinstimmen. Beachten Sie
dazu die Hinweise unter 4.4.4 und 7.5.
Jetzt werden noch zusätzliche Volumes und Verzeichnisse angelegt, die Struktur
der fertigen Zelle ist danach vergleichbar mit der Beispielzelle (siehe 7.1,
Seite 140),abgesehen von den fehlenden Benutzer-Homedirectories von ernie
und bert.
• Es wird davon ausgegangen, dass das AFS-Token eines Zellensuperusers
(i.d.R. admin) zur Verfügung steht. Das kann mit:
überprüft werden.
Damit ein Token zur Verfügung steht, muß der AFS-Client installiert,
konfiguriert und gestartet sein. Das Token holt man mittels:
• Diese Befehle müssen nicht zwangsläufig auf dem ersten AFS-Server
eingegeben werden. Wenn man sie auf einem anderen Rechner ausführt,
muß jedoch localhost durch den Namen eines AFS-Servers (z.B.
afsserv1) ersetzt werden. Das kann ein beliebiger AFS-Fileserver
sein.

4.4 Ablauf einer manuellen Grundinstallation 93
Dieser Link verringert Tipparbeit und wird von einigen InstantAFS-Skripten
benötigt:
root@host>ln -s /afs/Zellenname /a
Die Root-Volumes der Homedirectories (siehe 7.9, Seite 155) werden angelegt
und in den AFS-Namensraum eingebaut:
admin@afs>vos create localhost Partition user
admin@afs>fs mkm /afs/.Zellenname /user user
admin@afs>vos create localhost Partition user-backup
admin@afs>fs mkm /afs/.Zellenname/user-backup user-backup
admin@afs>for i in user{,-backup,-na}; do \
> fs sa /afs/.Zellenname/$i;\
> done
admin@afs>mkdir /afs/.Zellenname/user-backup/{ro,backup}
admin@afs>vos create localhost Partition user-na
admin@afs>fs mkm /afs/.Zellenname /user-na user-na
Jetzt noch die RW-Instanz-Mountpoints:
admin@afs>fs mkm /afs/.Zellenname/.user user -rw
admin@afs>fs mkm /afs/.Zellenname/.user-backup user-backup -rw
admin@afs>fs mkm /afs/.Zellenname/.user-na user-na -rw
... und die obligatorischen RO-Instanzen:
admin@afs>for v in user{,-backup,-na}; \
do \
vos addsite localhost Partition $v; \
vos release $v; \
done
Dieses Volume kann benutzt werden, um Kleinigkeiten zwischenzuspeichern
(ein Netzwerk-/tmp-Verzeichnis). Die Quota kann man den eigenen Bedürfnissen
anpassen.
admin@afs>vos create localhost Partition tmp -maxquota 3000000
admin@afs>fs mkm /afs/.Zellenname/tmp tmp -rw
admin@afs>fs sa /afs/.Zellenname/tmp system:anyuser rlwid
Dieses Volume wird Konfigurationsfiles aufnehmen, die die ganze Zelle betreffen.
Einige InstantAFS-Skripte greifen später zwingend auf dieses Verzeichnis
zu:
admin@afs>vos create localhost Partition a.etc
admin@afs>mkdir /afs/.Zellenname/admin
admin@afs>fs mkm /afs/.Zellenname/admin/etc a.etc
admin@afs>fs mkm /afs/.Zellenname/admin/.etc a.etc -rw
admin@afs>fs sa /afs/Zellenname/admin/.etc system:anyuser rl
Die Rechte werden gesetzt. Das Verzeichnis /a/a/etc/secret wird in einem seperaten
Volume abgeriegelt - nur Zellensuperuser dürfen darauf zugreifen:

94 4 Einrichtung einer AFS-Zelle
admin@afs>vos create localhost Partition a.etc.secret
admin@afs>fs mkm /afs/.Zellenname/admin/.etc/secret a.etc.secret
admin@afs>mkdir /afs/Zellenname/admin/.etc/secret
admin@afs>fs sa /afs/Zellenname/admin/.etc/secret -clear
Die etc-Volumes sind viel zu wichtig, um keine RO-Instanzen zu haben:
admin@afs>vos addsite localhost partition a.etc
admin@afs>vos addsite localhost partition a.etc.secret
admin@afs>vos release a.etc
admin@afs>vos release a.etc.secret
Das cellinfo-Volume (siehe 7.15, Seite 169) wird angelegt - für den Anfang
ohne RO-Instanz:
admin@afs>vos create localhost Partition a.cellinfo
admin@afs>fs mkm /afs/.Zellenname/admin a.cellinfo
Ein Volume für Skripte wird fakultativ angelegt:
admin@afs>vos create localhost Partition local.scripts
admin@afs>mkdir /afs/.Zellenname/local
admin@afs>fs mkm /afs/.Zellenname/local/scripts
admin@afs>fs mkm /afs/.Zellenname/local/.scripts -rw
admin@afs>vos addsite localhost Partition local.scripts
admin@afs>vos release local.scripts
Das Zellenrootvolume muss noch einmal released werden:
admin@afs>vos release root.cell
4.4.7 Start der AFS-Clients
4.4.7.1 Voraussetzungen
4.4.7.2 Start
Die Struktur der fertigen Zelle ist danach (abgesehen von den Homedirectories
der Beispiel-Benutzer) vergleichbar mit der Beispielzelle (siehe 7.1, Seite 140).
Zuletzt wird der AFS-Client konfiguriert. Folgende Bedingungen sind vorher
zu erfüllen:
1. Es klingt trivial, ist aber wichtig: Der Computer muss Zugang zum
Netzwerk haben (Netzwerkkabel eingesteckt, Netzwerkkarte konfiguriert)
sonst kann der AFS-Client beim Hochfahren einen Kernelfehler
(Kernel-OOPS)) verursachen.
2. Die Zelle muss fertig konfiguriert sein, d.h. mindestens ein DB-Server
und ein Fileserver müssen existieren und mindestens eine RO-Instanz des
AFS-Rootvolumes muss auf einem der Fileserver liegen.
In der Datei /etc/openafs/afs.conf.client muss die Zeile
AFS_CLIENT=false
durch
AFS_CLIENT=true

4.4 Ablauf einer manuellen Grundinstallation 95
4.4.7.3 Tests
ersetzt werden, wenn der AFS-Client bei jedem Rechnerstart automatisch hochfahren
soll. Nun kann man den AFS-Client starten:
root@host>/etc/init.d/openafs-client force-start
ptdbnssd (siehe A.2, Seite 224) muss noch eingerichtet werden. Dazu wird
das ptdb-Modul für den passwd-Dienst in /etc/nsswitch.conf eingetragen. Es
muß also z.B. die folgende Zeile hinein:
passwd: files ptdb
Mit folgenden Kommandos wird der ptdbnssd-Dienst dann gestartet:
root@host>/etc/init.d/libnss-ptdb stop
root@host>/etc/init.d/libnss-ptdb start
user@host>kinit admin
user@host>aklog
4.4.7.3.1 Der AFS-Cache-Manager selbst Den nicht-authentifizierten Zugriff
testet man, indem man nach /afs/[Zellenname] wechselt. Funktioniert das,
arbeitet die Zelle bereits. Funktioniert es nicht, sollte man unter 8.4.3, Seite 176
nachschlagen.
Zum Testen des authentifizierten Zugriffs auf die neue Zelle, muss zuerst ein
AFS-Token geholt werden:
Das Kommando tokens sollte jetzt diese Ausgabe erzeugen:
user@host>tokens
User’s (AFS ID 1) tokens for afs@alpha [Expires Mar 3 01:35]
user@host>touch /a/tmp/test
Die Ablaufzeit kann natürlich variieren. Zeigt tokens den erwarteten Output,
funktioniert das Kerberos.
Das Anlegen einer Datei testet man mit:
Mit ls testet man, ob der Zugriff authentifiziert war:
user@host>ls -nla /a/tmp/test
-rw-r-r- 1 1 65534 0 Jan 22 14:29 "/a/tmp/test"
Wenn es nicht geklappt hat (man beachte die Zahl hinter der 1:
user@host>ls -nla /a/temp/test
-rw-r-r- 1 32766 65534 0 Jan 22 14:29 "/a/tmp/test"
Die 32766 ist die AFSID von “anonymous” - in diesem Fall hat der Fileserver
das Token nicht akzeptiert - der Zugriff erfolgte ohne gültige Authentifikation.
Funktioniert es nicht, sollte man unter 8.4.3, Seite 176 nachschlagen.

96 4 Einrichtung einer AFS-Zelle
4.4.7.3.2 Das NSS-PTDB-Modul Mit folgenden Kommandos kann man
testen, ob das NSS-PTDB-Modul (siehe A.2, Seite 224) korrekt arbeitet:
user@host>/usr/lib/libnss-ptdb/nsstest admin
uid=1 name=’admin’ homedir=’/afs/alpha/user/admin’ gid=65534 passwd=’x’
user@host>/usr/lib/libnss-ptdb/nsstest 1
uid=1 name=’admin’ homedir=’/afs/alpha/user/admin’ gid=65534 passwd=’x’
Hinweis: Homedirectory, gid und Passwort sind fake-Werte - generiert von
libnss-ptdb .deb . Sie sind jedoch der entscheidende Anhaltspunkt dafür, dass
das NSS-PTDB-Modul funktioniert.
Funktioniert es nicht, läßt sich mit cstest herrausfinden, ob es am ptdbnssd
liegt:
user@host>/usr/lib/libnss-ptdb/cstest 1
E: Error talking to ptdbnssd.
Das liegt mit hoher Wahrscheinlichkeit daran, dass der ptdbnssd nicht läuft.
Folgendes ist dann zu tun:
user@host>/etc/init.d/libnss-ptdb start
Funktioniert es, sollte das Ergebnis wie folgt aussehen:
user@host>/usr/lib/libnss-ptdb/cstest 1
uid=1 name=admin
4.4.8 Das Samba-Gateway
[ g l o b a l ]
workgroup = [ Name d e r Z e l l e ]
s e r v e r s t r i n g = InstantAFS−Samba−Gateway a u f %h
l o g f i l e = / v a r / l o g / samba / l o g .%m
max l o g s i z e = 1000
s y s l o g = 0
p a n i c a c t i o n = / u s r / s h a r e / samba / panic−a c t i o n %d
s e c u r i t y = u s e r
e n c r y p t passwords = t r u e
obey pam r e s t r i c t i o n s = yes
i n v a l i d u s e r s = r o o t admin
s o c k e t o p t i o n s = TCP_NODELAY
[ homes ]
Überprüfen Sie vorher, ob sie ein Samba-Gateway brauchen (siehe 10.1, Seite
209). Die Theorie zu diesem Samba-Gateway steht unter A.6 auf Seite 230.
Das Samba-Gateway muss auf einem Rechner installiert werden, auf dem der
AFS-Client läuft.
Sicherheitshinweis: Stellen Sie sicher, dass sich keine Benutzer interaktiv auf
diesem Rechner einloggen können.
Legen Sie die Datei /etc/samba/smb.conf wie folgt an und ersetzen sie die Zeichenkette
[Name der Zelle] jeweils durch den Zellennamen:
## Die n a e c h s t e Z e i l e f u e r Sarge oder h o e h e r auskommentieren
# p assdb backend = tdbsam g u e s t
comment = Home D i r e c t o r i e s im AFS
p a t h =/ a f s / [ Zellenname ] / u s e r /%u
b r o w s e a b l e = no
w r i t a b l e = yes
c r e a t e mask = 0700
d i r e c t o r y mask = 0700
l o c k i n g = yes
Listing 4.23: /etc/samba/smb.conf

4.4 Ablauf einer manuellen Grundinstallation 97
[ a f s ]
p r e e x e c c l o s e = yes
## Die n a e c h s t e Z e i l e f u e r Sarge oder h o e h e r auskommentieren . . .
# p r e e x e c =/ u s r / b i n / tokenmgr −Kbr −w \"\% d \ " −p \"\% u \ " −k / v a r / l i b / samba / k e y t a b s /\"% u \ " . k e y t a b
## Die n a e c h s t e Z e i l e f u e r Woody auskommentieren
# p r e e x e c =/ u s r / b i n / tokenmgr −S \"\% u \ " −k / v a r / l i b / samba / k e y t a b s /\"% u \ " . k e y t a b
comment = AFS−R o o t d i r e c t o r y d e r l o k a l e n Z e l l e
p a t h =/ a f s / [ Zellenname ]
b r o w s e a b l e = yes
w r i t a b l e = yes
c r e a t e mask = 0700
d i r e c t o r y mask = 0700
l o c k i n g = yes
## Die n a e c h s t e Z e i l e f u e r Sarge o der h o e h e r auskommentieren . . .
# p r e e x e c =/ u s r / b i n / tokenmgr −Kbr −w \"\% d \ " −p \"\% u \ " −k / v a r / l i b / samba / k e y t a b s /\"% u \ " . k e y t a b
## Die n a e c h s t e Z e i l e f u e r Woody auskommentieren
# p r e e x e c =/ u s r / b i n / tokenmgr −S \"\% u \ " −k / v a r / l i b / samba / k e y t a b s /\"% u \ " . k e y t a b
Jetzt muss noch der acall-Server auf dem Samba-Gateway aktiviert werden. Der
samba-acall-Server ist dazu auf dem Gateway einzurichten (siehe 7.6.4, Seite
151).

5 Backups und Ausfallsicherheit
5.1 Welche Server für welche Volumes?
5.1.1 RO-Daten
In diesem Kapitel werden zum einen die diversen Strategien diskutiert, die im
Rahmen InstantAFS’ für Backups unterstützt werden. Zum anderen wird auch
darauf eingegangen, wie man ganz allgemein mit den speziellen Möglichkeiten
des AFS das Risko von Betriebsunterbrechungen und Datenverlust minimieren.
Es gibt verschiedene Möglichkeiten, Backups unter AFS durchzuführen. Primär
wird in diesem Abschnitt auf das AFS-Backup-System eingegangen. Zwei
weitere Möglichkeiten werden kurz vorgestellt. Diese könnten zwar als eigenständige
Backup-Systeme betrieben werden, bieten jedoch weniger komfortable
Automatismen.
Hinweis: Alles, was unter AFS mit Backups zu tun hat, muss mit Zellenadministratorrechten
durchgeführt werden (siehe 3.7.5, Seite 54). Das ist schon allein
deshalb vernünftig, da die aus Volume-Instanzen erstellten Dumps Zugriff auf
alle Daten unter Umgehung der ACLs ermöglichen.
Wie auch bei der Lastverteilung muss Ausfallsicherheit spezifisch für die Art
der Daten 1 eingerichtet werden.
Hinweis: Beachten Sie, dass mit Art der Daten nicht Typ der Volume-Instanz
gemeint ist. Auch Daten, auf die praktisch nur lesend zugegriffen wird, haben
üblicherweise eine RW-Instanz. Hier geht es jedoch um die primären Zugriffsmuster.
Beispiele:
Homedirectories : Keiner wird daran zweifeln, dass es sich dabei um Daten im Schreibzugriff
handelt. Bereits das Einloggen unter einer grafischen Oberfläche wie
KDE ist ohne Schreibzugriff unmöglich.
Softwareverzeichnisse : Unix trennt i.d.R. die Speicherorte von Programmen und zugehörigen
Daten sehr scharf. Softwarepakete, kann man deshalb i.d.R. so ablegen,
dass nur lesend darauf zugegriffen werden - die eigentlichen Daten
werden dann woanders gespeichert
Ausfallsicherheit erreicht man bei Daten, die nicht oft verändert werden, indem
man mehrere RO-Instanzen der entsprechenden Volumes im Netzwerk verteilt.
Fällt ein Fileserver aus, der eine RO-Instanz eines Volumes bereitstellt, so greifen
die Clients (nach einem Timeout) auf andere Fileserver zu.
Auch wenn die RW-Instanz noch nicht wiederhergestellt ist, funktioniert der
Zugriff auf die RO-Instanzen weiterhin, lediglich ein Update der RO-Instanzen
(mit vos release) ist dann nicht möglich.
1 Daten im Lesezugriff bzw. Daten im Schreibzugriff
98

5.1 Welche Server für welche Volumes? 99
5.1.2 RW-Daten
AFS besitzt nicht die Fähigkeit der Echtzeitreplikation von Daten. Fällt eine
RW-Instanz eines Volumes aus, kann sie nicht so einfach, wie eine RO-Instanz
ersetzt werden.
Es sollte versucht werden, die RW-Instanzen auf soviele Fileserver wie möglich
zu verteilen. Dadurch wird das Risiko, viele Volumes auf einmal zu verlieren,
geringer. Der balancer (siehe 6.11.2, Seite 133) hilft dabei mit dem
“bynumber-agent” (→ Verteilung, so dass danach auf allen Fileservern eine ausgewogene
Anzahl an RW-Instanzen liegt).
Legt man zu allen RW-Instanzen jeweils auf anderen Server RO-Instanzen
an, kann man durch das Kommando vos convertROtoRW bei einem
Fileserver-Ausfall RO-Instanzen in RW-Instanzen umwandeln (siehe 8.5.3,
Seite 180).
Mit dem Kommando instantafs.calcrestore läßt sich ermitteln, wie
kritisch der Ausfall eines Servers wäre 2 . Im folgenden Beispiel wird überprüft,
welche Volumes vom Ausfall des Servers afsserv1 betroffen wären:
user@host>instantafs.calcrestore -critical afsserv1/\*
local.scripts
user.ernie
user@host>echo $?
1
Diese beiden Volumes sind nicht durch RO-Instanzen auf anderen Servern
abgesichert. Das kann man leicht nachholen:
admin@afs>vos addsite afsserv2 a user.ernie
admin@afs>vos release user.ernie
admin@afs>vos addsite afsserv2 a local.scripts
admin@afs>vos release local.scripts
Ein zweiter Versuch:
user@host>instantafs.calcrestore -critical afsserv1/\*
user@host>echo $?
0
5.1.3 Gekoppelte Server
Der Ausfall dieses Server würde also keine Daten irreversibel vernichten.
Teilen sich 2 Server einen gemeinsamen SPOF (Single Point of Failure), z.B.
ein mit mehreren SCSI-Kanälen ausgestattetes Storage-System, sollte man
auch den Ausfall beider Server simmulieren.
Beispiel: Die Server afsserv1 und afsserv2 greifen auf 2 Partitionen des selben
externen RAID-Systems zu:
2 Genauer: welche RW-Instanzen nach dem Ausfall eines Server verloren wären.

100 5 Backups und Ausfallsicherheit
user@host>instantafs.calcrestore -critical afsserv1/\* afsserv2/\*
user.bert
user.ernie
root.afs
root.cell
...
5.2 Das AFS-Backup-System
5.2.1 Prinzipielles zu AFS-Backups
In diesem Fall ist dringend zu empfehlen, weitere Server in die Zelle zu integrieren
oder aber ein zweites Storage-System zu beschaffen, so dass nicht der
Ausfall eines einzigen RAID-Systems die ganze Zelle in den Abgrund zieht.
Unter AFS werden Backups immer von ganzen Volumes durchgeführt - ein
Backup einzelner Dateien/Verzeichnisse ist nicht vorgesehen. Dabei wird wie
folgt vorgegangen:
1. Man wähle einen Instanz-Typ des zu sichernden Volumes. Per default benutzt
instantafs.backup immer Backup-Instanzen. Hinweise siehe 5.2.2
auf Seite 101.
2. Die zu sichernden Volumes werden ge“dump”t - also in Dateien umgewandelt,
die alle Informationen des jeweiligen Volumes enthalten.
Das Dumpen kann auch inkrementell erfolgen. Es werden dann nur die
Dateien und Verzeichnisse gesichert, die seit dem letzten Backup verändert
wurden.
3. Ein Steuerprozess (das Kommando backup dump) weist jeweils einen
Fileserver (genauer: einen volserver-Prozess) an, jeweils ein Volume
an einen TapeController (Backup-Server) zu schicken. Auf diesem nimmt
ein butc-Prozess 3 die Daten entgegen und speichert sie auf einem (virtuellen)
Band.
4. Es ist ökonomisch sinnvoll, die gedumpten Volumes noch zu komprimieren
- das Backup-System macht das nicht selbstständig.
5. InstantAFS stellt für die Steuerung dieses Prozesses das Kommando
instantafs.backup zur Verfügung, das jedoch noch einige Zusätzliche
Aufgaben hat (siehe 5.2.3, Seite 101).
Das Backup-System besteht nun aus zwei Teilen:
• einem (oder mehreren Backup-Servern), auf denen jeweils ein oder mehrere
TapeController-Prozesse (butc) laufen. Tapecontroller nehmen Daten
von Fileservern aus dem Netzwerk entgegen und leiten diese an Bandlaufwerke
(oder auch an Dateien - also virtuelle Bänder - weiter)
• der Backup-Datenbank (BDB), die von den buserver-Prozessen verwaltet
wird. In dieser Datenbank werden primär die Zeitpunkte vermerkt,
zu denen Volumes gesichert wurden. In Kombination mit an AFS-Files
angebrachten Zeitmarken sind so inkrementelle Backups möglich. Ausserdem
enthält sie eine Liste der beschriebenen Bänder (oder auch virtueller
Bänder).
3 BackUp TapeController

5.2 Das AFS-Backup-System 101
5.2.2 Welche Instanzen sollte man zum Sichern verwenden?
5.2.3 Ablauf unter InstantAFS
Unter InstantAFS wird dieses Backup zum größten Teil über zwei Dateien gesteuert:
• /etc/cron.d/instantafs-backup Dieses Datei wird von instantafs.vtapes
beim Einrichten des Backup-Servers angelegt und mit einigen Beispielen/Kommentaren
versehen.
Durch diese crontab werden die regelmäßigen Backups mit instantafs.backup
ausgelöst. Das ist jedoch auch auf jedem anderen AFS-Server der Zelle
möglich.
Ausserdem kümmert sich ein instantafs.vtapes-Job in diesem File um
das regelmäßige Löschen alter virtueller Bänder. Das muss allerdings auf
jedem Backup-Server einzeln geschehen, da Zugriffe auf das lokale Filesystem
nötig sind.
• /a/admin/etc/backup.conf In diesem File werden Volumes zu handlichen
Gruppen zusammengefasst und jeweils einem speziellen TapeController
zugewiesen. So läßt sich z.B. das Backup einer Zelle in zwei durch eine
dünne Leitung voneinander getrennten Gebäuden mit jeweils einem
Backup-Server leicht organisieren.
Backup-Instanzen sowie RO-Instanzen auf der Partition ihrer RW-Instanz (siehe
3.1.4, Seite 29) haben für Backups zwei Vorteile:
• Im Gegensatz zu RW-Instanzen repräsentiert ihr Inhalt während des gesamten
Zeitraumes, in dem das Backup läuft, ein konsistentes da unveränderliches
Abbild der RW-Instanz zu dem Zeitpunkt als die letzte Synchronisation
(vos release bzw. vos backup) lief.
• Im Gegensatz zu RO-Instanzen, die nicht auf der Partition der RW-Instanz
liegen, brauchen sie wenig Platz (siehe 3.1.4, Seite 29).
Der Inhalt ist immer das exakte Abbild des RW-Volumes zu einem gewissen
Zeitpunkt - der Abgleich mit der RW-Instanz ist atomar 4 , was ein
Backup im laufenden Betrieb erst sicher macht. In jedem anderen Fall sind
Race-Conditions durch den parallelen Zugriff von Backup-Prozess und Anwendungsprogrammen
denkbar.
Einstellen muß man die zu benutzende Instanz beim Aufruf von instantafs.backup,
der üblicherweise auf dem Backup-Server unter /etc/cron.d/instantafs-backup
zu finden ist.
InstantAFS’ Backup-Konzept sieht vor, Daten ausschließlich auf Festplattenpartitionen
zu sichern. Benötigt wird dazu ein Rechner mit angeschlossenen
großen gemounteten Festplatten. Auf diesem Rechner muss ein butc-Prozess
mit Zellenadministratorrechten laufen (siehe 3.7.5, Seite 54).
InstantAFS’ Backup-Konzept kombiniert dabei i.d.R. 5 drei Dinge:
• Regelmäßige Updates der Backup-Instanzen, wobei alle Beispiele immer
von täglicher Synchronisation ausgehen (immer Nachts). Damit sind die
“Benutzer-verwalteten Backups” abgedeckt (siehe 7.2, Seite 141).
4 kann also nicht durch zugreifende Benutzer unterbrochen werden
5 Man kann bei Bedarf auf beliebig viele davon verzichten.

102 5 Backups und Ausfallsicherheit
5.2.3.1 Konfiguration des Backup-Servers
• Regelmäßige Updates der RO-Instanzen, wobei alle Beispiele immer von
wöchentlicher Synchronisation (jeden Freitagabend) ausgehen.
• Regelmäßige Backups auf Festplatten. Dabei wird jeden Freitagabend ein
Full-Backup gestartet 6 .
Unter 5.2.3.2 ist beschrieben, wie man einstellt, welche Daten zu sichern sind.
Während eines Backups passiert bei InstantAFS per default folgendes:
• Das Programm instantafs.backup synchronisiert die für die Dumps benutzten
Instanzen (siehe 5.2.2, Seite 101). Ein Nebeneffekt davon ist, dass
man durch diese automatische Synchronisation den Grundstein für das
Administrationsarme Backup (siehe 7.2, Seite 141) legt.
• instantafs.backup erstellt Volume-Mengen-Einträge in der BDB, die
sich 1 : 1 aus den definierten Volsets (siehe 5.2.3.2, Seite 104) aus der
Datei /a/a/etc/backup.conf ableiten.
• instantafs.backup benutzt die ihm übergebene Dump-Schedule (siehe
5.2.3.3, Seite 105) und erstellt damit für jedes zu sichernde Volset einen
Dump. Ein solcher Dump ist im Prinzip ein Datenstrom, der aus dem
Inhalt mindestens eines 7 Volumes gebildet und auf dem Backup-Server
in kleinen Stückchen (Bändern, vtapes) gesichert wird.
• Auf dem Backup-Server wird von instantafs.backup das Hilfsprogramm
butc (BackUp Tape Controller), aus dem Paket instantafsclient
.deb ) aufgerufen. butc nimmt die zu sichernden Daten aus dem
Netzwerk von den AFS-Fileservern entgegen und speichert sie in eine
Datei definierter Größe.
• Hat die Datei die definierte Größe erreicht, wird jeweils automatisch
instantafs.vtapes aufgerufen, das die Datei komprimiert und
in eine Baumstruktur einsortiert. Sollen Daten wiederhergestellt werden,
sucht instantafs.vtapes die entsprechenden Dateien aus
der Baumstruktur herraus und stellt sie dem AFS-Backup-System zur
Rücksicherung zur Verfügung.
• Stellt instantafs.vtapes fest, dass nicht mehr genug Speicher auf den
Backup-Partitionen des Backup-Servers verfügbar ist, friert es den
Backup-Vorgang ein und schickt eine eMail mit nützlichen Hinweisen,
wie der Administrator nun vorzugehen hat.
Dieses Skript ist also eine Art virtueller Bandwechselroboter.
5.2.3.1.1 Theorie InstantAFS stellt das Skript instantafs.vtapes
(siehe 9.2.28, Seite 206) bereit, das einen Backup-Server komplett konfigurieren
kann. instantafs.vtapes ist für einen Backup in Dateien
ausgelegt - arbeitet also nicht mit Magnetbändern. Dieses Skript wird nur in
Ausnahmefällen manuell aufgerufen.
Der Backup-Server wird dabei mit nur einem Tapecontroller ausgestattet (AFS
lässt eigentlich auch mehrere zu).
6 Schliesslich ist dann das ganze Wochende Zeit, um auch umfangreiche Daten zu sichern
7 üblicherweise enthält er viele Volumes

5.2 Das AFS-Backup-System 103
5.2.3.1.2 Der Ablauf Das Kommando zur Konfiguration des Backup-
Servers lautet (die Bedeutung der Parameter wird weiter unten erklärt):
root@backupserv> instantafs.vtapes - -init - -compression Methode \
- -tapesize Megabytes - -tempdir Temp-Verzeichnis \
- -storage Archiv-Verzeichnis - -days Tage \
- -deletelimit Anzahl der Dumps - -mail eMail-Adresse
instantafs.vtapes listet während der Einrichtung alle Dateien auf, die
es anlegt oder verändert. Die Konfiguration lässt sich im Nachhinein verändern.
Die Parameter werden in folgenden Dateien gespeichert:
/etc/instantafs/vtapes.conf : die Konfigurationsdatei von instantafs.vtapes
/var/lib/openafs/backup/tapeconfig : die allgemeine Konfigurationsdatei des Tape-Controllers (butc)
/var/lib/openafs/backup/... : Die Konfigurationsdatei des virtuellen Bandlaufwerkes, das von
instantafs.vtapes mit virtuellen Bändern bestückt wird.
Die letzte Pfadkomponente ist von dem mit dem Parameter
- -tempdir Temp-Verzeichnis übergebenen Verzeichnis abhängig.
Hier einige Beispiele:
- -tempdir Verzeichnis Konfigurationsdatei
/AFSBACKUP /var/lib/openafs/backup/CFG_AFSBACKUP_vtape
/var/tmp/instantafs /var/lib/openafs/backup/CFG_var_tmp_instantafs_vtape
• Wählen Sie einen Rechner mit viel Plattenkapazität - die Platten müssen
nicht besonders schnell sein.
• Konfigurieren Sie den Rechner als Roh-AFS-Server (siehe 7.5, Seite
146). Die Pfade zu den Filesystemen auf den entsprechenden Partitionen
müssen mit - -storage Archiv-Verzeichnis angegeben werden
- natürlich als absolute Pfade.
• Ein temporäres Verzeichnis auf einer möglichst schnellen Festplatte wird
zusätzlich benötigt. Dieses temporäre Verzeichnis muss groß genug sein,
um ein Backup-File unkomprimiert speichern zu können.
Das temporäre Verzeichnis muss mit - -tempdir Temp-Verzeichnis
als absoluter Pfad angegeben werden. Achtung: Das temporäre Verzeichnis
sollte nicht auf einem flüchtigen Datenträger (z.B. RAM-disk)
liegen.
• Die Backup-Dateien müssen eine definierte Maximalgröße

104 5 Backups und Ausfallsicherheit
• Es stehen 3 Kompressionsmethoden für die Backup-Dateien zur Verfügung,
von denen eine mit dem Parameter - -compression Methode
angegeben werden muss:
none : Keine Kompression. Das ist konkurrenzlos schnell, jedoch extrem
unwirtschaftlich.
gzip : Kompression mittels gzip (Lempel-Ziv). Diese Methode bietet eine
gute Balance zwischen Geschwindigkeit und Kompressionseffizienz.
bzip2 : Kompressions mittels bzip2 (Burrows-Wheeler und Huffman).
Diese Methode ist langsamer als gzip, erreicht jedoch üblicherweise
etwas bessere Kompressionsraten.
• Backups kann man angesichts chronisch knapper Plattenkapazität nicht
ewig aufheben. In /a/a/etc/backup.conf wird für jedes Volset festgelegt,
wie lange es minimal aifgehoben werden muss. Backups, die älter sind,
werden üblicherweise automatisch aus der BDB entfernt und die zugehörigen
vtapes werden gelöscht.
Sollte einmal während eines Backups nicht genug Speicher zur Verfügung
stehen, wird sich instantafs.vtapes per eMail bei dem im Parameter
- -mail eMail-Adresse angegebenen Empfänger wenden und
Vorschläge unterbreiten, wie das Problem vom Administrator gelöst werden
kann. Dieser Vorschlag läuft dann darauf hinaus, dass man die Minimalspeicherdauer
der Volsets in /a/a/etc/backup.conf reduziert.
• Ein cron-Job, der automatisch durch instantafs.vtapes konfiguriert
wird, löscht einmal am Tag alle Metainformationen über Backups,
die älter sind als in ihren entsprechenden Konfigurationszeilen in /a/a/etc/backup.conf
angegeben. Anschliessend werden dann die entsprechenden
vtapes entfernt, was jedoch auf allen Backup-Servern seperat geschehen
muss. Die Anzahl der Dumps, die dabei entfernt werden dürfen, wird
durch den Parameter - -deletelimit Anzahl der Dumps limitiert.
Stellt das Backup-System fest, dass mehr Dumps als angegeben entfernt
werden müssten, wird eine Warn-eMail generiert und keine Daten
entfernt.
Hinweis: Das ist eine Vorsichtsmaßnahme, die verhindern soll, dass ein
kleiner Fehler die Löschung aller gespeicherten Backups auslöst.
Hier ein Beispiel:
root@backupserv> instantafs.vtapes - -init \
- -compression gzip \
- -tapesize 10 \
- -tempdir /AFSBACKUP \
- -storage /BIG_RAID - -storage /AFSBACKUP/PART2 \
- -storage /AFSBACKUP/PART2 - -days 40
5.2.3.2 Volume-Gruppen (Volume-Sets)
Das Backupsystem sichert immer ganze Gruppen von Volume-Instanzen - keine
einzelnen. Instanzen können auch in mehreren Gruppen enthalten sein. Eine
Gruppe besteht dabei aus einer Liste von regulären Ausdrücken, die auf folgende
Eigenschaften von Volume-Instanzen angewandt werden:
• den Namen der Instanz,
• den Server, auf dem sie liegt und

5.2 Das AFS-Backup-System 105
5.2.3.3 Dump-Level
• die Partition, auf der sie liegt.
Es kommen simple reguläre Ausdrücke (siehe A.3, Seite 225) zum Einsatz.
Die AFS-Volume-Gruppen werden automatisch aus den in /a/admin/etc/backup.conf
definierten Volume-Gruppen aufgebaut und aktualisiert, wenn
das Backup mit instantafs.backup durchgeführt wird. Bei der automatischen
Installation wird eine Beispieldatei für /a/admin/etc/backup.conf angelegt,
die auch die Syntax dieses Files beschreibt. Man kann z.B. Volume-Gruppen
so definieren, dass nur die Volumes hineinfallen, deren RW-Instanzen auf bestimmten
Fileservern oder bestimmten Partitionen liegen. Jeder Volume-Gruppe
in /a/admin/etc/backup.conf ein bestimmter Tape-Controller zugeordnet werden.
Das ermöglicht z.B. die unkomplizierte Sicherung einer Aussenstelle auf
eigene Backup-Server, ohne die potentiell dünne Leitung zu dieser zu belasten.
Dumplevel werden vom AFS-Backup-System benutzt, um das Verhalten inkrementeller
Backups zu steuern. Dumplevel sind immer ein Pfad durch die
Dump-Hierarchie der BDB. Sowohl für das AFS-eigene Kommando
admin@afs>backup dump Dumplevel Volumeset
als auch beim Backup mittels
admin@afs>instantafs.backup -b Dumplevel Volumeset
muss jeweils ein Dump-Level angegeben werden.
Das Backup-System ermittelt anhand des Pfades durch die Dump-Hierarchie
den Zeitpunkt, auf den sich ein inkrementelles Backup beziehen muss.
Hier ein einfaches Beispiel:
/week
/week/mo
/week/tu
/week/we
/week/th
Diese Hierarchie ist z.B. geeignet, um von Homedirectories am Wochenende
ein volles Backup zu machen (Pfad: /week). Außerdem wird am Ende eines
jeden Tages ein inkrementelles Backups (Pfade: /week/mo, /week/tu, ...)
gemacht. Die Referenz für das inkrementelle Backup ist dabei jeweils der Pfad
durch die Dump-Hierarchie, der nach Abzug der letzten Komponente - bei
diesem Beispiel also immer das volle Backup des letzten Wochenendes - nicht
das Backup des letzten Tages. So wird diese Dump-Hierarchie angelegt:
admin@afs>backup adddump /week
admin@afs>for t in mo tu we th; do adddump /week/$i;done
Es ist auch möglich, ein wöchentliches Backup zu machen, bei dem jeweils der
letzte Tag die Referenz ist. Hier ein Beispiel:
/week2
/mo
/tu
/we
/th

106 5 Backups und Ausfallsicherheit
5.2.3.4 Verdrängungsstrategie
Hier wäre der Pfad für das volle Backup /woche2, die inkrementellen Pfade
durch die Hierarchie wären jedoch
• /week/mo
• /week/mo/tu
• /week/mo/tu/we
u.s.w. ...
Beide Beispiel werden bereits während der Installation durch instantafs.setup
automatisch angelegt.
Über kurz oder lang werden sich die Storage-Directories füllen und der Platz
wird knapp. instantafs.vtapes stellt eine Verdrängungsstrategie zur Verfügung:
Entfernen von vtapes, die älter als n Tage sind.
Der günstigste Wert für n ist dabei von verschiedenen Dingen abhängig:
• der Menge der zu sichernden Daten,
• wie oft sich die Daten in welchem Umfang ändern,
• dem - -compression-Parameter der für instantafs.vtapes - -init
benutzt wurde sowie
• von der Größe der angeschlossenen Storage-Partitionen.
Man sollte n am Anfang sehr großzügig festlegen (z.B. 100). Wenn der Speicher
während des Backup-Prozesses knapp wird, meldet sich instantafs.vtapes
per eMail und weist darauf hin. Das Kommando zum einmaligen Entfernen von
alten vtapes lautet:
root@backupserv> instantafs.vtapes - -remove Tage - -cleanup
Tage ist dabei die das maximale Alter von Backups, die nicht entfernt werden
sollen. Bei Tage=21 werden also alle Backups entfernt, die älter als 21 Tage
sind.
Um ein versehentliches Löschen des kompletten Backup-Datenbestandes zu
verhindern, bricht instantafs.vtapes mit einem Hinweis ab, wenn mehr
als 10 Dumps gleichzeitig gelöscht werden sollen. In diesem Fall muß man die
Zeile modifizieren - z.B. so:
root@backupserv> instantafs.vtapes - -remove 100 - -cleanup - -deletelimit 20
Damit würde instantafs.vtapes alle Dumps aussortieren, die älter als 100 Tage
sind und die dazugehörigen vtapes umgehend entfernen - jedoch nur dann,
wenn dadurch maximal 20 Dumps entfernt werden.
Sollen alte vtapes regelmäßig entfernt werden (das ist der Normalfall), so sollte
der entsprechende instantafs.vtapes-Aufruf in einen cron-Job wandern. Bei
der Einrichtung des Backup-Server mit instantafs.vtapes - -init
wird ein entsprechender cron-Job bereits angelegt (siehe /etc/cron.d/instantafsbackup
auf dem Backup-Server).

5.3 Etwas Theorie zum InstantAFS-Backup 107
5.2.3.5 Regelmäßigkeit
5.2.3.6 Mehrere Backup-Server
5.3 Etwas Theorie zum InstantAFS-Backup
5.3.1 Kategorisierung von Dumps durch instantafs.vtapes
Sind Tapecontroller und die BDB konfiguriert, muss ein Rechner das Backup regelmäßig
durchführen. Der Tapecontroller wird durch instantafs.vtapes
bereits entsprechend konfiguriert - durch cron-Jobs in /etc/cron.d/instantafsbackup.
Am Ende dieser Datei befindet sich auch ein bereits aktiviertes
Beispiel für ein wöchentliches Backup der Volume-Sets users (alle Benutzer-
Homedirectories) und cell (diverse Root-Volumes) befindet. Es sollte sofort
funktionieren.
Das Setup-Tool instantafs.setup von InstantAFS legt bei der Konfiguration
der Zelle bereits die Datei /a/a/etc/backup.conf an. Auf die Einträge in
diesem File müssen sich die Aufrufe der Backup-cron-Jobs beziehen. Alle zu
sichernden Volumes müssen hier eingetragen sein, wobei reguläre Ausdrücke
zur Verfügung stehen.
Das Backup-System ist jetzt fertig konfiguriert. Auf die Wiederherstellung von
Volumes wird unter 5.7.2 auf Seite 112 eingegangen.
Es ist auch möglich, mehrere InstantAFS-Backup-Server zu benutzen. Bei weiteren
zu konfigurierenden Servern muß bei der Konfiguration mit instantafs.vtapes
immer der folgende Parameter angegeben werden:
- -portoffset=Nummer des Backupservers
Die Nummer ist dabei eine Zahl, die beim 1. Zusätzlichen Backupserver 1,
beim zweiten 2, usw. sein muss. Backups werden durch instantafs.backup
immer parallel auf alle Backupserver gleichzeitig durchgeführt. Die Steuerung
der Backups muß nicht (kann aber) auf den einzelnen Backup-Servern erfolgen.
Wichtig ist nur, daß der Recher, der das Backup steuert, ein AFS-Server
der lokalen Zelle ist - er also auf den Zellenschlüssel unter /etc/openafs/server-
/KeyFile zugreifen kann.
In der Backup-Konfigurationsdatei /a/a/etc/backup.conf definierte Volume-
Gruppen beziehen sich per default immer auf den ersten Backup-Server. Mit
der Option tc=Hostname eines Backup-Servers kann man eine
Volume-Gruppe an einen anderen Backup-Server binden.
Achtung: Automatisches Wiederherstellen von Daten läßt sich nur dann leicht
automatisieren, wenn Volumes immer auf dem gleich Backup-Server landen.
Das muß man nur beachten, wenn man z.B. Volumes hat, die gelegtlich durch
ihre pysische Position die Volume-Gruppe wechseln.
instantafs.vtapes benutzt in Ausgaben und Fehlermeldungen verschiedene
Begriffe, um Dump-Mengen zu beschreiben. Diese werden im folgenden näher
erläutert:
archived dump : Wenn ein Dump archived ist, bedeutet das, dass er (vertreten durch mindestens
ein vtape) auf einer lokalen Storage-Partition liegt.
bdb dump : Ein dump, der in der BDB vermerkt ist, heisst bdb dump.
lost dump : Solche Dumps wurden auf den lokalen Datenpartitionen gefunden, sind
jedoch nicht mehr in der BDB vermerkt. Das liegt i.d.R. daran, dass sie

108 5 Backups und Ausfallsicherheit
mit
root@backupserv> instantafs.vtapes - -remove Tage
aus der BDB, jedoch noch nicht physisch entfernt wurden. Der Befehl
root@backupserv> instantafs.vtapes - -cleanup
entfernt alle lost dumps.
redundant : Solche Dumps sind zwar in der BDB aufgeführt, können jedoch nicht
auf einer Storage-Partition des lokalen Backup-Servers gefunden werden.
Das kann z.B. daran liegen, dass sie auf einem anderen Backup-Server
liegen oder aber, dass sie gelöscht wurden.
timedout : Ein Dump, der durch die Option - -remove zur Vernichtung ausgewählt
wurde.
incomplete dump : Ein Dump gilt dann als incomplete (unvollständig), wenn nicht alle vtapes
beginnend von Nr. 1 bis zur höchsten gefundenen Nummer auf den
Storage-Partitionen des Fileservers gefunden wurden.
Achtung: Die Existenz eines incomplete dumps ist ein Fehlerfall, der
nicht auftreten sollte. InstantAFS kann solch einen Fehler nicht selbst beheben.
5.4 Backup “light” - die erste
Ein Dump kann in mehreren Dump-Mengen vertreten sein.
Volume-Instanzen lassen sich komplett in ein einzelnes File schreiben:
admin@afs>vos dump Name oder ID der Instanz > Dump-Datei
Von der eigentlich für die Umleitung des Datenstromes in eine Datei vorgesehenen
Option -file ist abzuraten. Man würde mit hoher Wahrscheinlichkeit
über das 2GByte-Limit stolpern. Auch kann man ohne -file den Datenstrom
gleich noch weiterbearbeiten, z.B. komprimieren:
admin@afs>vos dump Name oder ID der Instanz | gzip > Dump-Datei
Eine Sicherung der Unterschiede seit einem bestimmten Datum ist möglich. Die
dafür benötigte Option ist -time Zeitpunkt. Das Format von Zeitpunkt
ist:
mm/tt/jjjj hh:MM
Die Entscheidung, welche Dateisystemobjekte gesichert werden, wird anhand
eines für Benutzer nicht sichtbaren Zeitstempels gefällt - ist also nicht von der
mtime abhängig, wie sie im VFS des AFS-Clients erscheint und kann deshalb
auch nicht von Nutzern manipuliert werden.
Mit dem Parameter Name oder ID der Instanz legt man fest, welche
Instanz eines Volumes zu sichern ist. Man kann immer nur eine Instanz auf
einmal sichern, paralleles Dumpen mehrerer Instanzen ist natürlich damit nicht
ausgeschlossen.
Hier einige Beispiele:
• Sichern des Zellenrootvolume in eine Datei:
admin@afs>vos dump root.cell.readonly > root.cell.dump

5.5 Backup “light” - die zweite 109
• Sichern der Backup-Instanz des Homedirectories von ernie im komprimierter
Form:
admin@afs>vos dump user.ernie.backup | gzip -9 > user.ernie_full.dump.gz
• Sichern aller Änderungen seit 00:00 am 02.05.2004 (wiederum komprimiert):
admin@afs>vos dump user.ernie.backup -time “05/02/2004 00:00” | \
gzip -9 > user.ernie_incr_1.dump.gz
• Sichern des Homedirectories von bert in eine Datei:
admin@afs>vos dump user.bert > user.bert.dump
Achtung: Die RW-Instanz wird direkt gesichert, so dass Inkonsistenzen
auftreten können, die es bei Verwendung der RO- oder Backup-Instanz
nicht geben würde (siehe 5.2.2, Seite 101).
Mit einem eigenen kleinen Skript kann man den Inhalt mehrere Volumes komplett
oder inkrementell zu einem definierten Zeitpunkt sichern. Bei einer kleinen
Zelle kann man so mit Hilfe eines cron-Jobs in Windeseile ein Backup-System
aufsetzen, jedoch ist die Rücksicherung wenig komfortabel (siehe 5.7.3, Seite
113).
Der vos dump-Befehl ist auch für “das kleine Backup zwischendurch” sinnvoll.
Alle Homedirectories zu sichern geht z.B. wie folgt:
admin@afs>for v in ‘volgrep user.\*‘; \
do \
vos dump $v > $v.dump; \
done
oder auch so:
admin@afs>for v in ‘volgrep user.\*‘; \
do \
vos backup $v; \
vos dump $v > $v.dump; \
done
5.5 Backup “light” - die zweite
Es ist möglich, Volumes lediglich durch Anlegen und Updaten von RO-
Instanzen auf anderen Servern zu sichern. Ein solches Backup ist extrem leicht
aufzusetzen und durchzuführen (kein Bandwechsel, keine teure Hardware),
hat jedoch einen Nachteil: Es lässt sich immer nur ein Zeitpunkt sichern.
Updatet man die RO-Instanz, wird die alte Version überschrieben. Dieser
Nachteil wird jedoch durch eine sonst unerreichbare Geschwindigkeit bei der
Wiederherstellung (siehe 5.7.1.0.3, Seite 111) ausgeglichen.
Es handelt sich bei dieser Art des “Backups” eher um eine erhöhte Ausfallsicherheit,
das Prinzip ist unter 5.1.2, Seite 99 beschrieben.
Die automatische Installation mit instantafs.setup legt bereits einen
Grundstein für diese Art von Backup

110 5 Backups und Ausfallsicherheit
5.5.1 Backup light mit Shadow-Instanzen
Ab OpenAFS 1.3 existiert die Möglichkeit, sog. shadow-Instanzen einer ER-
Instanz anzulegen. Das Prinzip ist wie folgt:
1. RW-Instanzen werden regelmäßig mit vos shadow auf einen entfernten
Server synchronisiert. Die Synchronisation erfolgt inkrementell.
2. Die Shadow-Instanz sieht üblicherweise (man kann es beeinflussen) wie
eine RW-Instanz aus - hat sogar die selbe ID wie die RW-Instanz. Der
einzige Unterschied ist, dass die Shadow-Instanz nicht in der VLDB aufgeführt
ist.
3. Stürzt jetzt der Fileserver mit der RW-Instanz ab, kann man mit
admin@afs> vos syncvldb Shadow-Fileserver
5.6 Backup für Daten ausserhalb des AFS
die vorher kopierte RW-Instanz mit O(1) wiederherstellen.
Oft ist es nötig, Dinge zu sichern, die sich prinzipbedingt nicht im AFS befinden
können (z.B: Root-Partitionen von wichtigen Servern).
Das funktioniert ungefährt so:
1. Man lege einen cron-Job an, der regelmäßig Dateien aus einem zu
sichernden Verzeichnis in ein anderes (sprich: in ein dafür angelegtes
Verzeichnis in einem AFS-Volume) kopiert. Beispiel-cron-Job:
0 10 * * * nobody rsync -av /wichtige/lokale/daten
/afs/meine.zelle/locale-backups
2. Der cron-job muss AFS-tauglich gemacht werden (Anleitung siehe 7.7
auf Seite 152) — schliesslich soll nicht jeder, der Zugriff auf die Zelle
hat, diese Daten manipulieren dürfen. Hat man den Kerberos-Principal
und den AFS-Benutzer angelegt und die Keytab auf dem Rechner deponiert,
auf dem der Prozess (in diesem Fall rsync) später laufen soll, muss
man noch dafür sorgen, dass der Unix-Nutzer (in diesem Fall nobody)
auch an die Keytab kommt — z.B. so:
root@host>chown nobody.root /etc/instantafs/local-backup.keytab
root@host>chmod 400 /etc/instantafs/backup-buttler.keytab
Die neue cron-Zeile muss dann z.B. so aussehen:
0 10 * * * nobody tokenmgr -S backup-buttler -k
/etc/instantafs/backup-buttler.keytab - - rsync
-av /wichtige/lokale/daten /afs/meine.zelle/locale-backups
3. Das Volume, in dem die gesicherten Daten liegen, kann nun wie jedes andere
AFS-Volume regelmäßig auf verschiedene Weisen gesichert werden
Hinweise:
• Das AFS ist kein 100%ig Unix-kompatibles Dateisystem. Vor allem,
wenn die Besitzer-Metadaten der zu sichernden Dateien wichtig sind,
dann muss darf man das Backup nicht einfach als Kopie auslegen,
sondern muss z.B. ein tar oder cpio-Archiv anlegen.
• U.U. ist es nötig, dass der Prozess unter der Unix-UID (in diesem
Fall nobody) läuft, die der AFSID des AFS-Benutzers (in diesem

5.7 Wiederherstellen zerstörter RW-Instanzen 111
5.7 Wiederherstellen zerstörter RW-Instanzen
5.7.1 ... aus einer RO-Instanz
Fall backup-buttler) entspricht. rcs 9 ist ein Beispiel dafür. In diesem
fall muß man die cron-Zeile anpassen und auch den Besitzer von
/etc/instantafs/backup-buttler.keytab entsprechend ändern.
Manchmal ist es nötig, eine RW-Instanz aus den Daten einer RO-Instanz zu
erstellen. Nach Ausfall eines Server, der RW-Instanzen speicherte, ist es z.B.
sinnvoll.
Es gibt 3 Möglichkeiten, das zu tun. An dieser Stelle wird auf die Wiederherstellung
einzelner Instanzen eingegangen. Ist die Zeit ein kritischer Faktor bzw.
sind viele Instanzen wiederherzustellen, lesen Sie besser unter 8.5.3 auf Seite
180 weiter.
5.7.1.0.1 dump/restore mit einer RO-Instanz Bei dieser Methode werden
die Daten einer existierenden RO-Instanz über den volserver-Prozess des
AFS-Fileservers ausgelesen, auf dem diese RO-Instanz liegt. Über eine Pipe
wird dieser Datenstrom an das vos restore-Kommando geschickt, was die
Daten an den volserver auf dem Ziel-Fileserver weiterreicht, der dann die
RW-Instanz neu erzeugt. Das ist eine sehr saubere, jedoch auch langsame Lösung.
Hier ein Beispiel:
Die RW-Instanz von user.ernie lag auf einem Server, der jetzt zerstört ist. Auf
afsserv1 liegt glücklicherweise eine RO-Instanz:
admin@afs>vos dump user.ernie.readonly -server afsserv1 -partition a | \
vos restore afsserv2 a user.ernie
Damit wurde die RW-Instanz wiederhergestellt und liegt jetzt auf afsserv2.
Hinweis: Ab OpenAFS 1.3 geht das effizienter mit vos copy (siehe 7.16,
Seite 170).
5.7.1.0.2 Wiederherstellung mit klassischen Unix-Tools Es ist natürlich
möglich, die Wiederherstellung im AFS-Namespace auf Dateisystemebene
durchzuführen. Dazu legt man die RW-Instanz auf einem beliebigen Server neu
an (siehe 6.3, Seite 116). Anschließend wechselt man in einen Pfad unter /afs,
der in der RW-Instanz endet und kopiert die Daten z.B. mit cp, mit tar, dem
Midnight Commander (mc) oder einem beliebigen anderen Programm, das in
der Lage ist, Dateibäume zu kopieren. Diese Methode ist nur dann sinnvoll,
wenn von dem wiederherzustellenden Volume nur wenige Daten noch benötigt
werden, die noch existierende RO-Instanz jedoch große Datenmengen enthält.
5.7.1.0.3 Wiederherstellung durch RO-RW-Umwandlung Es ist auch
möglich, eine RO-Instanz in eine RW-Instanz umzuwandeln. Diese Funktion ist
Teil eines inoffiziellen Patches gegen die OpenAFS-1.2.11-Quellen, hat jedoch
bereits Einzug in die Entwicklerversion von OpenAFS (1.3.x) gehalten.
Hier ein Beispiel:
admin@afs>vos convertROtoRW -server afsserv1 -partition a -id user.ernie
9 rcs wird z.B. von twiki .deb benutzt, das wiederum auf apache .deb aufsetzt. Wenn apache .deb
afsifiziert wird, wirkt sich das auch auf rcs aus.

112 5 Backups und Ausfallsicherheit
5.7.2 ... aus dem AFS-Backup-System
Damit wird die RO-Instanz des Volumes user.ernie auf dem Rechner afsserv1
(auf Partition a) in eine RW-Instanz umgewandelt.
Das AFS-Backup-System kennt verschiedene Wiederherstellungsmodi:
• backup volrestore restauriert ein einzelnes Volume. Beispiel:
backup volrestore -server afsserv1 -partition a \
-volume user.ernie -volume user.bert -extension .xx
Damit werden die Homedirectories von ernie und bert wiederhergestellt
- allerdings in die neuen Volumes user.ernie.xx und user.bert.xx. Die Angabe
eines Suffixes mit -extension Erweiterung ist dann nötig,
wenn nur wenige Daten aus einem Backup benötigt werden und die derzeitige
RW-Instanz nicht überschrieben werden soll. In diesem Fall würden
einfach Volumes mit neuen Namen angelegt werden.
• Der Befehl backup volsetrestore restauriert alle Volumes eines
bestimmten Volume-Sets (siehe 5.2.3.2, Seite 104). Es ist möglich, eine
Datei anzugeben, in der für jedes Volume definiert ist, auf welche Partition
welches Servers es wiederhergestellt werden soll (siehe [ADMREF]).
Hier ein Beispiel:
admin@afs>cat /tmp/home.restore
afsserv1 a user.ernie
afsserv2 a user.bert
admin@afs>backup volsetrestore users -file /tmp/home.restore
Damit würden die Homedirectories (und nur die) von ernie (auf den
Rechner afsserv1) und bert (auf den Rechner afsserv2) wiederhergestellt.
In der Datei /tmp/home.restore muss das wiederherzustellende Volume
zusammen mit einem Zielserver und einer Zielpartition aufgeführt sein.
• Ein besonders praktisches Kommando ist backup diskrestore.
Damit kann eine komplette Partition eines Fileservers wiederhergestellt
werden. Ein Beispiel:
admin@afs>backup diskrestore -partition a -server afsserv2 \
-newpartition a -newserver afsserv1
Damit würde die RW-Instanzen, die vorher auf dem jetzt zerstörten
RAIDs /vicepa auf afsserv2 lagen, auf den Rechner afsserv1 wiederhergestellt.
Bei Bedarf kann allen wiederhergestellen Volumes mit
-extension Erweiterung ein Suffix angehängt werden.
Zusätzliche Parameter
• Der Parameter -n bewirkt, dass lediglich die wiederherzustellenden
Volumes aufgelistet, nicht jedoch wiederhergestellt werden (Trockentraining).
• Man kann auch einen Zeitpunkt angeben, der wiederhergestellt werden
soll. Das Backupsystem wählt dann die entsprechenden Dumps aus,
wobei kein Dump nach dem angegebenen Zeitpunkt benutzt wird.
-date MM/TT/JJJJ hh:mm

5.7 Wiederherstellen zerstörter RW-Instanzen 113
10 also z.B.:
admin@afs>backup volrestore user.gert -extension .x -date 12/13/2005 00:00
-server mekong -partition a
5.7.3 ... aus Volume-Dumps
• Mit -portoffset Portoffset des Servers kann man einen
vom primären abweichenden Backup-Server für die Rücksicherung auswählen.
Das ist unbedingt nötig, wenn die entsprechenden Daten nicht
auf dem primären Backup-Server liegen.
Soll ein Volume wiederhergestellt werden, müssen ein Full-dump sowie evtl.
nötige inkrementelle Dumps des wiederherzustellenden Volumes zur Verfügung
stehen. Je nachdem, wie die Volume-Dumps archiviert werden, ist dazu der Einsatz
eines Kommandos der benutzten Backup-Software nötig. Die Wiederherstellung
erfolgt zu einem definierten Server auf eine bestimmte Partition. Um
das Volume wiederherzustellen, muss der Full-Dump und alle inkrementellen
Dumps dekomprimiert und wiederhergestellt werden. Ein Beispiel (Das benutzte
Skript ist als Listing 5.1 verfügbar):
admin@afs>restore-volume.sh root.cell.restored afsserv1 a \
root.cell_full.gz root.cell_incremental_1.gz
# ! / b i n / bash
#
# S y n t a x : $0 [ Z i e l v o l u m e ] [ Z i e l s e r v e r ] [ p a r t i t i o n ]
# [ Fulldump−F i l e ] { [ i n k r e m e n t e l l e s Dumpfile ] { . . . } }
#
s e t −e
volume="$1" ; s h i f t
s e r v e r ="$1" ; s h i f t
p a r t i t i o n ="$1" ; s h i f t
gunzip < "$1" | vos r e s t o r e −s e r v e r "$server" \
−p a r t i t i o n "$partition" −name "$volume" \
−o v e r w r i t e f u l l
s h i f t
f o r f i l e in "$@" ; do
gunzip < "$file" | vos r e s t o r e −s e r v e r "$server" \
−p a r t i t i o n "$partition" −name "$volume" \
−o v e r w r i t e i n c r e m e n t a l
done
echo "Success."
e x i t 0
Listing 5.1: Einfaches Shellskript zur Wiederherstellung eines Volumes aus
Dumps
10 Datum und Uhrzeit sind wirklich 2 Parameter

6 Tägliche Arbeit mit AFS
6.1 Manuelles Anlegen neuer Benutzer
Dieses Kapitel beschreibt, wie täglich anfallende Aufgaben unter AFS zu erledigen
sind.
Hinweis: Hier wird beschrieben, wie ein Benutzer manuell angelegt wird. Es
geht auch anders - über InstantAFS-Skripte (siehe 7.9, Seite 155). Diese Skripte
sind in folgenden Fällen sinnvoll:
• Wenn die Benutzerverwaltung zentralisiert/automatisiert werden soll
(z.B. per Web-Interface),
• wenn Benutzer auch Zugriff auf ein Samba-Gateway erhalten sollen oder
• wenn die manuelle Methode nicht komfortabel genug ist.
Manuell geht es wie folgt:
1. Man verschafft dem Benutzer einen neuen Eintrag in der AFS-Datenbank:
admin@afs>pts createuser Benutzername AFSID
Beispiel:
admin@afs>pts createuser ernie 1000
2. Den Kerberos-Principal des Benutzers erzeugt man auf dem Kerberos-
Master-Server. Beachten Sie, dass mit dieser Methode außer Zahlen und
Buchstaben nur wenige Sonderzeichen (_ und - sind ok) als Passwort
erlaubt sind.
root@kerberos1> kadmin.local -p admin -q ’addprinc -requires_preauth \
-pw Password Benutzername’
oder am Beispiel:
root@kerberos1> kadmin.local -p admin -q ’addprinc -requires_preauth \
-pw Geh-Heim ernie’
3. Der Benutzer muß evtl. noch in diverse AFS-Gruppen eingetragen werden.
Das Kommando
admin@afs>pts add Gruppenname Benutzername
admin@afs>pts add users ernie
114
erledigt das für jeweils eine Gruppe. Beispiel:
Hinweise:
• Mehr Informationen dazu, wie man mit AFS-Gruppen umgeht, sind
unter refPTDB-Groups (Seite 121) zu finden.

6.2 Ändern der Maximalgröße (Quota) eines Volumes 115
• InstantAFS’ Benutzermanager (instantafs.usermgr) erkennt
den Status von Benutzern an ihrer Mitgliedschaft entweder in
der Gruppe users oder users-na (siehe 7.9, Seite 155).
4. Ein Eintrag in einem NSS-Dienst (z.B. LDAP) ist nicht nötig, da per
default libnss-ptdb .deb zum Einsatz kommt, das sich wiederum aus der
PTDB bediehnt.
5. Das Homedirectory-Volume user.[Benutzername] muss erstellt (siehe
6.3, Seite 116) und in den AFS-Namespace eingebunden werden:
admin@afs>fs mkm /afs/Zellenname/user/Benutzername user.Benutzername \
-rw
6. Eine Backup-Instanz sollte erzeugt und regelmäßig upgedatet werden
(siehe 7.2, Seite 141). Die Backup-Instanz wird unter InstantAFS an eine
genau definierte Stelle im Filesystem gemountet:
admin@afs>fs mkm /afs/Zellenname/user-/Benutzername \
user.Benutzername.backup
6.2 Ändern der Maximalgröße (Quota) eines Volumes
6.2.1 Setzen der Quota als Superuser
7. Das Homedirectory muss mit sinnvollen default-Rechten versehen werden
(siehe 7.8, Seite 154).
Die Quota eines Volumes kann man mit dem Kommando fs sq anpassen.
Dabei muß immer ein Verzeichnis angegeben werden - nicht das Volume selbst.
Der AFS-Client ermittelt dann das zugehörige Volume und setzt die Maximalquota
entsprechend:
admin@host> fs sq Verzeichnis Maximalgröße
also z.B.:
admin@afsserv1> fs sq /afs/cbs.mpg.de/user/ernie 1000000
Hinweise:
• Man kann die Quota eines Volumes auch beim Anlegen des Volumes
festlegen:
admin@afs>vos create Server Partition Volume -maxquota Maximalgröße
6.2.2 Setzen der Quota durch Benutzer
• Die Maximalquota von Volumes, die über acall angelegt werden (siehe
6.3.2, Seite 117), kann in der Konfigurationsdatei des Kommandos
instantafs.acall-volcreate (siehe 9.2.7, Seite 195) eingestellt
werden.
Es ist u.U. nötig, dass einfache Benutzer die Quotas von Volumes setzen. Als
einfacher Benutzer zählt z.B. auch ein automatisches Web-orientiertes Benutzermanagementsystem,
dass auf Anfrage, Gnade walten lassen und die Quota
kurzfristig erhöhen kann. InstantAFS’ acall-Schnittstelle (siehe 7.6.2, Seite
149) bietet eine Möglichkeit dazu.

116 6 Tägliche Arbeit mit AFS
6.3 Anlegen eines Volumes
6.3.1 Anlegen eines Volumes durch den Superuser
Der Administrator muß vorher die Datei /a/a/etc/acall.access entsprechend bearbeiten,
so daß die gewünschten Nutzer entsprechenden Zugriff auf das Kommando
instantafs.acall-setquota auf dem acall-Server db erhalten.
Die Syntax ist an Beispielen in der Datei /usr/share/doc/examples/acall.access
(Paket instantafs-doc .deb ) erklärt.
Außerdem muß der Administrator in der Datei /a/a/etc/acall-setquota.conf
einstellen, in welchem Bereich welcher Nutzer die Quota von welchen Volumes
setzen darf. Die Syntax findet man an Beispielen in der Datei /usr/share/doc/examples/acallsetquota.conf
im Paket instantafs-doc .deb
Ein Volume wird angelegt, sobald die RW-Instanz desselben erstellt wird. Anschließend
muss man das Volume noch in den Namensraum einhängen 1 .
Wo : Eine Partition muss immer angegeben werden. Gültige Partitionen lassen
sich wie folgt herausfinden, wobei man gleich den freien Speicher angezeigt
bekommt:
user@host>vos partinfo AFS-Fileserver
Erzeugen : Mit vos create wird die RW-Instanz auf der entsprechenden Partition
des angegebenen Servers erstellt. Die Option -maxquota ist nicht
zwingend, aber in jedem Falle sinnvoll
admin@afs>vos create Servername Partition Name des Volumes \
-maxquota Quota in kB
Mountpoint : Das Volume ist erst sichtbar, wenn es in den AFS-Namensraum eingebunden
ist. Dazu muss ein Mountpoint angelegt werden:
admin@afs>fs mkm Mount-Point Volumename -rw
Freigeben : Üblicherweise muß jetzt noch das Volume, in dem der Mountpoint liegt,
mit vos release bearbeitet werden, damit er auch in der jeweiligen
RO-Instanz erscheint.
admin@afs>vos release Mountpount-Volume
Rechte : Die ACLs sind per default sehr restriktiv. Mit fs sa können sie neu
gesetzt werden (siehe 6.6, Seite 120)
RO-Instanz : Eine RO-Instanz auf einem zweiten Server bringt Redundanz. Man legt
sie wie folgt an:
admin@afs>vos addsite Zweiter Server Partition auf dem zweiten Server
Volumename
1 vergleichbar mit Mounten einer frisch formatierten Partition

6.3 Anlegen eines Volumes 117
Jetzt das ganze an einem konkreten Beispiel:
admin@afs>vos partinfo afsfserver1
Free space on partition /vicepa: 8773476 K blocks out of total 26245408
admin@afs>vos create afsserver1 a user.ernie -maxquota 300000
admin@afs>fs mkm /afs/.cbs.mpg.de/users/ernie user.ernie -rw
admin@afs>vos release user
admin@afs>vos addsite afsserver a user.ernie
Mit folgender Zeile würde ernie volle Rechte über das Volume bekommen. Die
Gruppe sesamstrasse dürfte lesend zugreifen.
admin@afs>fs sa /afs/cbs.mpg.de/user/ernie ernie rlwidka sesamstrasse rl
6.3.2 Anlegen eines Volumes durch einen normalen Benutzer
Manchmal ist es nötig, Benutzern zu erlauben, Volumes anzulegen. InstantAFS’
acall-Schnittstelle (siehe 7.6.2, Seite 149) bietet eine Möglichkeit dazu. Das
unter 7.11 auf Seite 159 skizzierte Beispiel macht von dieser Möglichkeit gebrauch.
Der Administrator muß vorher die Datei /a/a/etc/acall.access entsprechend
bearbeiten, so daß die gewünschten Nutzer entsprechenden Zugriff auf das
Kommando instantafs.acall-volcreate auf dem acall-Server db
erhalten. Die Syntax ist an Beispielen in der Datei /usr/share/doc/examples/acall.access
(Paket instantafs-doc .deb ) erklärt.
Außerdem muß der Administrator einige Parameter festlegen, die beim Anlegen
von Volumes durch die entsprechenden Benutzer beachtet werden sollen.
Dazu ist die Datei /a/a/etc/acall-volcreate.conf anzupassen. Informationen zur
Syntax findet man an Beispielen in der Datei /usr/share/doc/examples/acallvolcreate.conf
im Paket instantafs-doc .deb
Der Ablauf ist dabei wie folgt:
1. Ein Benutzer legt ein Volume mittels acall an:
user@host>acall db ia:volcreate Volumename
also z.B.:
ernie@afsclient> db ia:volcreate proj.sesam.1
2. instantafs.acall-volcreate sucht die erste Zeile in dem File /a/a/etc/acallvolcreate.conf,
auf die der aufrufende Benutzer sowie das anzulegende
Volume passt. Das könnte z.B. die folgende sein:
ernie proj\.sesam\.[0-9] quota=10000,location=afsserv1/a,
acl=$CREATOR;rlwidka,rolocation=afsserv2/a,backup
3. Das Volume wird genau mit den Optionen angelegt, die in dieser Zeile
angegeben sind. Es gibt für den Nutzer keine Möglichkeit, Einfluß auf
diese Optionen zu nehmen.
Im Beispiel wird das Volume auf dem Rechner afsserv1 auf Partition a
angelegt und eine RO-Instanz auf afsserv2 auf Partition a eingerichtet.
Ausserdem wird eine Backup-Instanz angelegt, die Maximalgröße auf
10MB festgelegt und die ACL im Grundverzeichnis des neuen Volumes
so gesetzt, dass der erstellende Benutzer (in diesem Fall ernie) volle
Rechte hat.
Beispielfile: /usr/share/doc/instantafs-doc/examples/acall-volcreate.conf
aus dem Debian-Paket instantafs-doc.

118 6 Tägliche Arbeit mit AFS
6.4 Hinzufügen eines Fileservers
4. Der Benutzer kann den Prozess nicht beeinflussen (kein Abbruch mittendrin,
keine anderen Interaktionen, keine Signale).
5. Auf Serverseite ist der Principal acall im Einsatz, um das Volume anzulegen,
Rechte zu definieren und evtl. weitere (Backup- oder RO-) Instanzen
anzulegen. Der acall-Principal hat gleiche Rechte wie admin.
Bei diesem Vorgang wird kein Volume-Mountpoint auf das neue Volume angelegt.
Das muss der Benutzer selbst machen, was natürlich nur in Verzeichnissen
funktioniert, in denen er das a-Recht besitzt (siehe 3.7.3.2, Seite 51). Dabei
kann ihm der Administrator durch das Schreiben kleiner Skripte zur Hand gehen
(siehe 7.11.6, Seite 163).
In einem Beispielprojekt wird von der Möglichkeit des Anlegens von Volumes
durch Benutzer gebrauch gemacht (siehe 7.11, Seite 159).
Reichen die Fileserver der Zelle nicht mehr aus, können leicht weitere hinzugefügt
werden. Man lege dazu einen unspezialisierten AFS-Server an (siehe 7.5,
Seite 146).
Achtung:
• Wenn man sich mit AFS noch nicht besonders auskennt, sollte man die
Anweisungen in 7.5 genau befolgen.
• Die Anweisungen in 7.5 sind idempotent.
Dieser sollte natürlich über mindestens eine große Massenspeicherpartition
(siehe 3.8.3, Seite 59) verfügen, die dann unter /vicepa, usw. gemountet sein
muß.
Danach ist auf dem neuen Server noch folgendes Kommando auszuführen:
root@host>bos create localhost fs fs -cmd /usr/lib/openafs/fileserver \
-cmd /usr/lib/openafs/volserver -cmd /usr/lib/openafs/salvager \
-localauth
Benutzt wird der Fileserver, sobald man Volumes auf ihm anlegt (siehe 6.3,
Seite 116).
6.5 Datenbankserver hinzufügen, entfernen oder wechseln
6.5.1 Rechner und deren Sonderwünsche
Änderungen an der Liste der Datenbankserver müssen immer gut geplant werden
und sorgfältig durchgeführt werden. Wenn man sich an einige Regeln hält,
funktioniert das jedoch, ohne die geringste Unterbrechung für die Benutzer.
Man muss die verschiedenen Rechner der Zelle in der richtigen Reihenfolge an
die neue Datenbank-Konfiguration anpassen. Dazu teilt man sie erst einmal in
Klassen ein:
DBonly : Reine Datenbankserver auf denen kein Fileserver läuft.
DB-FS : Kombinierte Datenbank-/Fileserver.
FS : Reine Fileserver
WRITE : Reine Fileserver und AFS-Clients, die Schreibzugriff auf die Datenbank
brauchen.

6.5 Datenbankserver hinzufügen, entfernen oder wechseln 119
6.5.2 Ablauf
READ : Andere Rechner der Zelle, die keinen Schreibzugriff auf die AFS-
Datenbank brauchen, worunter die meisten Workstations fallen dürften.
Achtung:
• Alle Rechner der Klassen DB-FS müssen immer die Adresse der aktuellen
Sync-Site kennen - die entsprechende IP muss also zu jedem Zeitpunkt
in der lokalen CellServDB stehen. Um das sicherzustellen, werden
einige zusätzliche Schritte unternommen, die man bei etwas mehr Erfahrung
teilweise auslassen kann.
• Diese Anleitung geht davon aus, dass nicht sämmtliche aktuellen DB-
Server entfernt/ersetzt werden. Sie funktioniert also nur dann, wenn min.
1 DB-Server erhalten bleibt. Will man alle austauschen, muss man das
Prozedure zweimal durchführen: Zuerst müssen die alten raus, beim
zweiten Durchlauf die neuen rein.
1. Da im Laufe dieses Prozesses die AFS-Fileserverprozesse neu gestartet
werden müssen, sollte man dieses Prozedure an einem Tag durchführen,
an dem die Zelle möglichst wenig zu tun hat.
2. Zuerst werden die AFSDB-Einträge neuer Datenbankserver ins DNS eingetragen
(siehe 4.4.1, Seite 79).
3. Auf den WRITE-Rechnern werden die neuen Datenbankserver in die
Client-CellServDB (/etc/openafs/CellServDB) eingetragen wenn diese
Datei nicht leer ist. Ausserdem muss der AFS-Client neu gestartet
werden. Dadurch ist gesichert, dass die Rechner immer die aktuelle
Sync-Site kennen - und Sync-Site kann schliesslich einer der neuen
Datenbankserver werden.
4. Auf den FS-Rechnern werden die neuen Datenbankserver in die Server-
CellServDB (/etc/openafs/server/CellServDB) eingetragen.
5. Auf den DBonly und den DB-FS-Servern werden jetzt die neuen Datenbankserver
eingetragen - und zwar immer ein neuer Server nach dem
anderen:
(a) Man wähle einen der neuen Datenbankserver aus. Die Datenbankprozesse
auf diesem Rechner dürfen noch nicht laufen. Das /etc/openafs/server/CellServDB-File
muss so aussehen, wie auf den anderen
DBonly-Servern der Zelle. Der neue Datenbankserver zählt
ab sofort zur Rechnerklasse DBonly.
(b) Es versteht sich von selbst, dass der neue Datenbankserver einen
gültigen AFS-Key haben muss (siehe A.8, Seite 235).
(c) Der gewählte Datenbankserver wird in /etc/openafs/server/Cell-
ServDB auf allen vorhandenen DBonly- und DB-FS-Servern
eingetragen.
(d) Die Datenbankprozesse auf den restlichen Datenbankservern werden
neu gestartet.
(e) Die Datenbankprozesse auf dem neuen Server werden gestartet.
(f) Man sollte jetzt sicherstellen, dass die Server eine Sync-Site gewählt
haben (siehe 3.3.2, Seite 36). Das testet man mit:
user@host>udebug beliebiger Datenbankserver 7003

120 6 Tägliche Arbeit mit AFS
6. Jetzt sollte man noch einmal absolut sicher sein, dass die VLDB wirklich
eine Sync-Site hat:
user@host>udebug beliebiger Datenbankserver 7003
Hat sie das nicht, können die Fileserver nicht korrekt hochfahren.
7. Auf allen FS- und DB-FS-Rechnern müssen die Fileserver-Prozesse neu
gestartet werden.
8. Die AFSDB-Einträge der zu entfernenden Datenbankserver werden aus
dem DNS geworfen (siehe 4.4.1, Seite 79).
9. Auf den DBonly und den DB-FS-Servern werden jetzt die zu entfernenden
Datenbankserver aus der Serverliste gelöscht - wieder muss man das
für jeden zu entfernenden Datenbankserver einzeln machen:
(a) Man wähle einen der alten Datenbankserver aus. Der alte Datenbankserver
zählt ab sofort nicht mehr zur Rechnerklasse DBonly.
(b) Die Datenbankprozesse auf dem gewählten Server werden gestoppt.
(c) Der gewählte alte Datenbankserver wird aus allen /etc/openafs/server/CellServDB
auf allen vorhandenen DBonly- und DB-FS-
Servern entfernt.
(d) Die Datenbankprozesse auf allen DB- und DB-FS-Rechnern werden
neu gestartet.
(e) Man sollte sicherstellen, dass die Server eine Sync-Site gewählt
haben (siehe 3.3.2, Seite 36). Das testet man mit:
user@host>udebug beliebiger Datenbankserver 7003
10. Jetzt sollte man noch einmal absolut sicher sein, dass die VLDB wirklich
eine Sync-Site hat:
user@host>udebug beliebiger Datenbankserver 7003
6.6 Ändern von Verzeichnisrechten im AFS
11. Auf den WRITE-Rechnern werden die entfernten Datenbankserver aus
der Client-CellServDB (/etc/openafs/CellServDB) geworfen wenn diese
Datei nicht bereits leer ist. Dann wir der AFS-Client (mal wieder) neu
gestartet. Das dient nur der Verringerung möglicher Timeouts - die WRI-
TE-Rechner könnten auch ohne diese zwei Schritte problemlos weiterarbeiten.
12. Auf den FS-Rechnern werden die entfernten Datenbankserver aus der
Server-CellServDB (/etc/openafs/server/CellServDB) geworfen. Neustart
der Fileserverprozesse ist nicht nötig.
Das fs-Kommando kann benutzt werden, um die Zugriffsrechte von Benutzern
oder Benutzergruppen auf Verzeichnisse zu definieren. Hier einige Beispiele:
Der Benutzer ernie soll zusätzlich zu denen, die jetzt schon dürfen, Dateien im
Verzeichnis /afs/cbs.mpg.de/local/scripts ändern und Hinzufügen dürfen:
admin@afs>fs sa /afs/cbs.mpg.de/local/.scripts ernie rliw
admin@afs>instantafs.release -d /afs/cbs.mpg.de/local/.scripts

6.7 Arbeiten mit AFS-Gruppen 121
Der Benutzer ernie soll das Recht haben, Dateien unter /afs/cbs.mpg.de/local/scripts
zu verwalten (Lesen/Schreiben/Löschen). Alle anderen Benutzer sollen jedoch
Leserecht haben:
admin@afs>fs sa /afs/cbs.mpg.de/local/.scripts ernie rliwd \
system:anyuser rl -clear
Man kann auch die Rechte aus einem anderen Verzeichnis in ein anderes kopieren.
Folgendes Kommando setzt die Rechte im Scripts-Verzeichnis entsprechend
der Rechte in ernie’s Homedirectory:
root@host>fs ca /afs/cbs.mpg.de/user/ernie /afs/cbs.mpg.de/local/.scripts
Hinweise:
6.7 Arbeiten mit AFS-Gruppen
• Das Kommando instantafs.achmod (siehe 9.2.8, Seite 196) steht
für interaktives Bearbeiten von Verzeichnisrechten zur Verfügung.
• Machen Sie - wo immer das möglich ist - von den Möglichkeiten der
AFS-Gruppen (siehe 6.7, Seite 121) gebrauch.
Gruppen legt man folgendermaßen an:
Das ist eine Gruppe, die nur ein Superuser anlegen darf:
admin@afs>pts creategroup sesamstrasse
Solche Gruppen dürfen Benutzer (in diesem Fall ernie) anlegen:
ernie@afsclient> pts creategroup ernie:sesamstrasse
Die Zugriffsrechte auf einen Benutzereintrag oder eine Gruppe zeigt folgendes
Kommando:
admin@afs>pts examine ernie:sesamstrasse
Name: ernie:sesamstrasse, id: -10001, owner: ernie, creator: ernie,
membership: 0, flags: S-M-, group quota: 0.
Besonders interessant sind die Flags 2 , die unter [ADMREF] näher beschrieben
sind. Diese legen fest, welche Zugriffe auf die Gruppe von wem akzeptiert werden.
Das group quota-Feld ist nur bei Benutzereinträgen von Bedeutung -
es zeigt an, wieviele weitere Gruppen der jeweilige Benutzer anlegen darf.
Benutzer lassen sich wie folgt hinzufügen:
user@host>pts add bert ernie:sesamstrasse
...und wieder entfernen:
user@host>pts removeuser bert ernie:sesamstrasse
...und wieder hinzufügen:
user@host>pts add ernie ernie:sesamstrasse
Mit pts membership läßt sich anzeigen, welche Mitglieder eine Gruppe hat
bzw. in welchen Gruppen ein Benutzer Mitglied ist:
2 eigentlich sind es Tristates und keine Flags

122 6 Tägliche Arbeit mit AFS
user@host>pts membership ernie
Groups ernie (id: 1000) is a member of:
ernie:sesamstrasse
user@host>pts membership ernie:sesamstrasse
Members of ernie:sesamstrasse (id: -10001) are:
ernie
Welche Gruppen es so gibt, zeigt das Kommando
admin@afs>pts listentries -groups
Allerdings dürfen nur Administratoren 3 dieses Kommando ausführen.
Hinweise:
user@host>tokenmgr -l
6.8 Löschen eines Volumes oder einer Volume-Instanz
6.8.1 ... wenn’s keine Unregelmäßigkeiten gibt
• Fügt man einen Benutzer einer Gruppe hinzu, kann es sein, daß der
Benutzer sich ein neues Token holen muß, um auf Verzeichnisse zuzugreifen,
auf die er nur durch die Gruppenmitgliedschaft Zugriff erhält:
Analog gilt, daß ein Nutzer, der aus einer Gruppe entfernt wird, seine
Rechte u.U. nicht sofort verliert, sondern erst, wenn er ein neues Token
anfordert.
Der Grund dafür sind Cache-Mechanismen der AFS-Fileserver.
• pts listentries kann nur von Zellensuperusern ausgeführt werden.
Je nach Situation bietet AFS verschiedene Möglichkeiten, einzelne Instanzen
von Volumes zu entfernen. Ist die Zelle in einem perfekten Zustand (alle
Fileserver sind da, es existieren keine Inkonsistenzen), kommt der Befehl vos
remove zum Einsatz. Es wird dabei immer eine konkrete Instanz auf einer
bestimmten Partition entfernt - nicht z.B. alle RO-Instanzen eines Volumes.
Wie man sich einen Überblick über die Instanzen eines Volumes verschafft,
ist unter 6.10, Seite 124 beschrieben. Soll ein Volume komplett aus der Zelle
entfernt werden, müssen dazu alle Instanzen entfernt werden (zuerst RO- und
Backup-Instanzen, zuletzt die RW-Instanz). Mit der RW-Instanz wird dann auch
der Eintrag in der VLDB getilgt.
Hier einige Beispiele zur Benutzung des vos remove-Kommandos:
• Die RO-Instanz des Volumes user.ernie wird mit
admin@afs>vos remove afsserv2 a user.ernie
vom Fileserver afsserv2 entfernt. Das vos-Kommando verlangt die Angabe
der Partition (in diesem Fall a) 4 .
• Die Backup-Instanz von user.bert wird entfernt:
admin@afs>vos remove afsserv1 a user.bert.backup
3 Mitglieder von system:administratores
4 obwohl das theoretisch nicht nötig sein sollte, da es nur eine RO-Instanz desselben Volumes auf
einem Server geben darf

6.9 Verschieben eines Volumes 123
6.8.2 ... das der VLDB unbekannt ist
Der vos remove-Befehl versagt, wenn eine Instanz eines Volumes noch auf
einem Fileserver liegt, aber nicht mehr in der VLDB eingetragen ist. In diesem
Fall gibt es zwei Möglichkeiten:
admin@afs>vos syncvldb afsserv1
• Synkronisiert man die VLDB mit dem betroffenen Server, werden solche
Ungereimtheiten beseitigt. Bsp:
Es ist auch möglich, die Synkronisation auf eine Partition oder sogar auf
ein Volume zu beschränken. In [ADMREF] ist das genauer beschrieben.
• Es ist möglich, eine Instanz unter kompletter Umgehung der VLDB zu
entfernen:
admin@afs>vos zap Servername Partition ID der Instanz
6.8.3 ... das sich auch nach mehreren Versuchen nicht Löschen läßt
6.8.4 ... aus der VLDB
Das ist z.B. nötig, wenn das entsprechende Volume keinen Eintrag (also
auch keinen Namen) mehr in der VLDB hat.
Unter 8.5.5 auf Seite 182 ist beschrieben, wie man Volumes entfernen kann, die
sich hartnäckig gegen Löschung mit Standardmitteln sträuben.
Die vorher beschrieben Methoden des Instanzen-Löschens funktionieren allerdings
nur, wenn der Server mit der entsprechenden Instanz auch erreichbar ist.
Ist er z.B. defekt, kann man, je nachdem, ob es eine RO-Instanz oder aber den
ganzen Volume-Eintrag der VLDB zu löschen gilt, einen der folgenden Befehle
benutzen:
• Mit vos remsite lassen sich VLDB-Einträge für RO-Instanzen entfernen.
Es ist zu beachten, dass der Name bzw. die ID vom RW-Volume
anzugeben ist - nicht von der RO-Instanz. Das Kommando ist dann sinnvoll,
wenn man auf einen Server mit einer RO-Instanz eines wichtigen
Volumes nicht mehr zugreifen kann, man die RW-Instanz selbst jedoch
behalten will. Beispiel:
admin@afs>vos remsite afsserv1 a user.ernie
admin@afs>vos delentry user.ernie
6.9 Verschieben eines Volumes
• vos delentry entfernt den Eintrag eines Volumes komplett aus der
VLDB. Evtl. vorhandene RO- und Backup-Instanzen stehen dann auch
nicht mehr in der VLDB. Es sollte sichergestellt werden, dass vorher
alle noch existierenden Kopien des Volumes entfernt wurden. Auf Fileservern
vergessene Volume-Instanzen kosten schließlich Plattenspeicher.
Beispiel:
RW-Instanzen lassen sich mit dem Kommando vos move von einem AFS-
Fileserver zu einem anderen verschieben. Benutzer können während dieses Vorganges
auf dem RW-Volume arbeiten.

124 6 Tägliche Arbeit mit AFS
Hinweis: Während dieses Vorganges werden nicht zwangsläufig nur Daten von
A nach B verschoben. Durch die Differenzielle Speicherung (siehe 3.1.4, Seite
29) wird aus dem “Verschieben” u.U. “Kopieren”. Dieser feine Unterschied
ist wichtig, wenn man Volumes verschieben will, um auf dem ursprünglichen
Fileserver mehr Speicher zu erhalten (siehe 8.5.6, Seite 183).
RO-Instanzen lassen sich nicht verschieben. Das ist auch nicht nötig, da man
ja üblicherweise nicht die exakten Daten aus einer RO-Instanz haben will,
sondern nur eine weitere Kopie der RW-Instanz. Man kann das Verschieben auf
einfache Weise “simulieren” - hier ein Beispiel:
admin@afs>vos remove afsserv1 a user.ernie.readonly
admin@afs>vos addsite afsserv2 a user.ernie
admin@afs>vos release user.ernie
6.10 Einholen von Informationen...
6.10.1 ... über Server
6.10.1.1 DB-Server
Dabei werden allerdings alle RO-Instanzen von user.ernie auf den neuesten
Stand gebracht - nicht nur die auf dem Zielserver.
In diesem Abschnitt wird beschrieben, wie man welche Informationen über eine
Zelle einholen kann. Alle hier genannten Methoden benötigen keine Authentifikation
an den Servern (also kein gültiges Token), um zu funktionieren.
Beachten Sie den feinen Unterschied zwischen den Informationen, die über Volumes
auf einem Fileserver gespeichert sind und den in der VLDB gespeicherten
Informationen. Normalerweise sollte die VLDB exakt die Zustände auf den
Fileservern abbilden, jedoch kann z.B. durch den Ausfall einer Serverpartition
(durch den die VLDB nicht automatisch aktualisiert wird) die VLDB inaktuell
sein.
Mit Sicherheit ist die VLDB auf dem aktuellen Stand, wenn vos syncvldb
für jeden einzelnen Fileserver ausgeführt wird. Das geht wie folgt:
admin@afs>for s in ‘vos listaddrs‘; do vos syncvldb $s;done
Wenn die Daten der VLDB über die Instanzen auf den Fileserver nicht übereinstimmen,
ist das ein Fehler, der z.B. durch den Totalschaden eines Servers
verursacht wurde - es ist keineswegs alltäglich.
Das AFS verlangt, dass alle DB-Server eine vollständige Liste aller DB-Server
kennen. Diese Liste lässt sich mit bos listhosts von jedem der DB-Server
einzeln auslesen. Beispiel: bos listhosts afsdb1
Mit udebug lassen sich Informationen über den einzelnen Datenbankserver-
Prozess, über die Sync-Site sowie über den Zustand des entsprechenden
Datenbankteils abfragen. Dabei ist zu beachten, dass die einzelnen AFS-
Datenbankteile unabhängig voneinander von verschiedenen Prozessen auf
den Datenbankservern verwaltet werden. Die jeweiligen Portnummern sind in
Tabelle 3.6, Seite 45 aufgeführt.
Je nachdem, ob der Server gerade Sync-Site (siehe Listing 6.2) ist oder nicht
(siehe Listing 6.1), zeigt udebug unterschiedliche Daten an.

6.10 Einholen von Informationen... 125
Host ’ s a d d r e s s e s a r e : 1 0 . 0 . 5 8 . 6
Host ’ s 1 0 . 0 . 5 8 . 6 time i s Tue May 18 1 3 : 4 9 : 2 7 2004
Local time i s Tue May 18 1 3 : 4 9 : 2 7 2004 ( time d i f f e r e n t i a l 0 s e c s )
L a s t yes v o t e f o r 1 0 . 0 . 5 8 . 2 was 8 s e c s ago ( sync s i t e ) ;
L a s t v o t e s t a r t e d 7 s e c s ago ( a t Tue May 18 1 3 : 4 9 : 2 0 2004)
Local db v e r s i o n i s 1079368316.2
I am n o t sync s i t e
Lowest h o s t 1 0 . 0 . 5 8 . 2 was s e t 8 s e c s ago
Sync h o s t 1 0 . 0 . 5 8 . 2 was s e t 8 s e c s ago
Sync s i t e ’ s db v e r s i o n i s 1079368316.2
0 l o c k e d pages , 0 of them f o r w r i t e
Listing 6.1: Beispieloutput von udebug, angewandt auf einen Rechner, der
nicht Sync-Site ist
Host ’ s a d d r e s s e s a r e : 1 0 . 0 . 5 8 . 2
Host ’ s 1 0 . 0 . 5 8 . 2 time i s Tue May 18 1 3 : 3 7 : 2 9 2004
Local time i s Tue May 18 1 3 : 3 7 : 3 1 2004 ( time d i f f e r e n t i a l 2 s e c s )
L a s t yes v o t e f o r 1 0 . 0 . 5 8 . 2 was 8 s e c s ago ( sync s i t e ) ;
L a s t v o t e s t a r t e d 9 s e c s ago ( a t Tue May 18 1 3 : 3 7 : 2 2 2004)
Local db v e r s i o n i s 1079368316.2
I am sync s i t e u n t i l 50 s e c s from now ( a t Tue May 18 1 3 : 3 8 : 2 1 2004) (2
s e r v e r s )
Recovery s t a t e 1 f
Sync s i t e ’ s db v e r s i o n i s 1079368316.2
0 l o c k e d pages , 0 of them f o r w r i t e
Listing 6.2: Beispieloutput von udebug angewandt auf eine Sync-Site
S e r v e r ( 1 0 . 0 . 5 8 . 6 ) : ( db 1079368316.2)
l a s t v o t e r cvd 9 s e c s ago ( a t Tue May 18 1 3 : 3 7 : 2 2 2 0 0 4 ) ,
l a s t beacon s e n t 8 s e c s ago ( a t Tue May 18 1 3 : 3 7 : 2 3 2 0 0 4 ) , l a s t v o t e was yes
d b c u r r e n t =1 , up=1 b e a c o n S i n c e =1
Folgende Informationen sind im udebug-Output enthalten:
1. alle IP-Adressen des DB-Servers, der befragt wurde:
Host’s address are: ...
2. die aktuelle Zeit auf dem Server sowie die Differenz zur lokalen Zeit (auf
dem Rechner, auf dem udebug aufgerufen wurde)
3. die “Versionsnummer” (Zeitpunkt der letzten Änderung) der Datenbank,
wobei der Zeitpunkt Unix-typisch in Sekunden seit 1.Januar 1970
00:00:00 angegeben ist
4. welcher DB-Server gerade Sync-Site ist bzw.
5. welche anderen Server von der Sync-Site gefunden 5 wurden. Diese Information
wird nur auf der Sync-Site angezeigt. Man muss also u.U. mit
udebug die Sync-Site ermitteln, um dann udebug noch einmal auf die
Sync-Site anzuwenden.
6. die “Versionsnummer” der Datenbank auf der Sync-Site
7. Einige Flags zum Zustand des entsprechenden Datenbank-Teils. Die
Flags sind in den Bits einer Hexadezimalzahl hinter Recovery State
codiert. Hier die Bedeutung der Bits, wenn sie gesetzt sind:
bit 0 : Der Server ist Sync-Site (ist das Bit nicht gesetzt, wird Recovery
State nicht angezeigt.
bit 1 : Die Datenbankversionen der anderen DB-Server sind in Ordnung.
bit 2 : Die Sync-Site ist bereits im Besitz der aktuellsten Datenbankversion.
bit 3 : unbekannt (Zitat aus [UDEBUG]: (8) shows that it has changed the
version number of its database.
5 i.d.R. sollten das alle anderen DB-Server sein. Nur bei Netzunterbrechungen oder Ausfällen von
DB-Servern werden nicht alle anderen gefunden.

126 6 Tägliche Arbeit mit AFS
6.10.1.2 Fileserver
admin@afs>vos listaddrs
afsserv1.cbs.mpg.de
afsserv2.cbs.mpg.de
bit 4 : Seit der Rechner Sync-Site ist, hat er seine Datenbank bereits mindestens
einmal an alle andere DB-Server verschickt.
Die VLDB enthält die Liste aller Volume-Instanzen der Zelle, jeweils mit
Angaben darüber, auf welchem Server und auf welcher Partition sie liegen.
Das sind üblicherweise alle Fileserver der Zelle, auf jeden Fall jedoch alle
Fileserver, auf die AFS-Clients zugreifen können 6 . Die Liste der bekannten
Server sieht z.B. wie folgt aus:
Fehlen Fileserver in der Liste, was eigentlich nicht sein sollte, kann man das
mit einem Befehl folgender Form korrigieren:
admin@afs>vos syncvldb Servername
Es gibt 2 Methoden, um eine Liste der AFS-Wirtspartitionen eines Servers zu
erhalten:
user@host>vos listpart afsserv1
The partitions on the server are:
/vicepa
/vicepb
Total: 1
user@host>vos partinfo afsserv1
Free space on partition /vicepa: 8773636 K blocks out of total 26245408
Free space on partition /vicepb: 16773636 K blocks out of total 41214116
vos partinfo zeigt zu den gefundenen Partitionen auch den verbrauchten
sowie den freien Speicher auf den Partitionen an. Das macht es sehr einfach,
ein Script zu schreiben, was alle Partitionen aller Fileserver auf drohende
Überfüllung prüft.
Hinweis: Das Paket openafs-nagios-plugins .deb enthält ein Nagios-Skript,
das dafür verwendet werden kann.
Mit vos listvol lässt sich anzeigen, welche Volumes wirklich auf einem
Fileserver liegen. Benutzt man die Option -fast, wird die VLDB dabei nicht
konsultiert. Mehr zu diesem Kommando gibt’s unter 6.10.2, Seite 127.
Bestimmte Signale veranlassen den Fileserver, Debug-Informationen auszugeben.
Das entsprechende Signal ist jeweils mit kill an den fileserver-
Prozess zu schicken, der direkt vom bosserver gestartet wurde. Das geht
z.B. so (man beachte die Backticks):
root@host>kill -Signalname ‘pgrep -P \‘pidof bosserver\‘ fileserver‘
Folgende Signale können benutzt werden:
XCPU : Dieses Signal veranlasst den Fileserver, im Verzeichnis /var/lib/openafs
folgende Dateien anzulegen:
6 AFS-Clients können nur Server benutzen, die in der VLDB vermerkt sind.

6.10 Einholen von Informationen... 127
6.10.2 ... über Volumes
6.10.2.1 ... per VLDB
• hosts.dump - Informationen über AFS-Clients, die dem Fileserver
bekannt sind
• clients.dump - Informationen über die Benutzer auf den ihm bekannten
AFS-Clients
• callback.dump - Diese Datei enthält Informationen über die Callbacks,
die der Server garantiert hat. Die Datei ist binär - das Programm
cbd (siehe 9.3, Seite 206) ist in der Lage, sie zu interpretieren.
TSTP : Dieses Signal erhöht den Debuglevel des Fileservers. Debuginformationen
werden nach /var/log/openafs/FileLog geschrieben. Mehrmals angewandt,
erhöht sich die geloggte Informationsmenge. Der Debug-Output
ist sehr umfangreich und umfasst bereits bei Debuglevel 1 die Namen der
Dateien, auf die AFS-Clients zugreifen.
user@host>vos examine users
HUP : Mit HUP setzt man den Debuglevel wieder auf 0 (= keine Debug-
Informationen schreiben).
Mit vos examine können Informationen über alle Instanzen eines Volumes
gebündelt angezeigt werden. Dabei werden verschiedene Informationen aus der
VLDB ausgelesen:
1. Name und ID aller bekannten Instanzen des Volumes
2. Namen der Server sowie die Partitionen, auf denen die Instanzen liegen
3. Ob das Volumes gesperrt (LOCKED) ist oder nicht (siehe 6.13.1, Seite
137).
Listing 6.3 zeigt einen Beispieloutput dieses Kommandos, angewandt auf das
Root-Volume des AFS-Namensraumes einer Zelle.
Listing 6.3: Beispieloutput des von vos examine
r o o t . a f s 536870912 RW 11 K On−l i n e
a f s s e r v 1 . cbs . mpg . de / v i c e p a
RWrite 536870912 ROnly 536870913 Backup 0
MaxQuota 5000 K
C r e a t i o n Tue Nov 19 1 7 : 1 0 : 5 4 2002
L a s t Update Thu Mar 4 1 3 : 1 1 : 1 1 2004
15 a c c e s s e s i n t h e p a s t day ( i . e . , vnode r e f e r e n c e s )
RWrite : 536870912 ROnly : 536870913
number of s i t e s −> 3
s e r v e r a f s s e r v 1 . cbs . mpg . de p a r t i t i o n / v i c e p a RW S i t e
s e r v e r a f s s e r v 1 . cbs . mpg . de p a r t i t i o n / v i c e p a RO S i t e
s e r v e r a f s s e r v 2 . cbs . mpg . de p a r t i t i o n / v i c e p a RO S i t e
Zusätzlich wird der Fileserver, der die RW-Instanz speichert, kontaktiert, um
dort u.a. folgende Informationen zu beschaffen:
• Zeitpunkt des letzten Schreibzugriffes sowie der Erstellung des Volumes
7 .
Hinweis: Der Timestamp des letzten Schreibzugriffes wird nicht sofort
nach einem Schreibzugriff aktualisiert. Garantiert ist lediglich, dass
er aller 25 Minuten sowie zu Begin einer Volumebezogenen Aktion
(Verschieben, Releasen, ...) korrekt ist.
7 was i.d.R. dem Zeitpunkt der Erstellung der RW-Instanz entspricht

128 6 Tägliche Arbeit mit AFS
• Statistische Informationen über Zugriffe auf die RW-Instanz. Diese Informationen
können von Programmen ausgewertet werden, um durch das
Verschieben von RW-Instanzen zwischen verschiedenen Fileservern eine
Lastverteilung über diese zu erreichen.
• Der maximale Speicherbedarf einer einzelnen Instanz des Volumes (die
Quota des Volumes).
Ist der Fileserver der RW-Instanz nicht verfügbar, entsprechen die von vos
examine gelieferten Informationen denen von
user@host>vos listvldb Name oder ID der RW-Instanz
6.10.2.2 ... direkt per Fileserver
Der Befehl vos listvldb zeigt sämtliche Instanzen aller Volumes einer
Zelle an. Das lässt sich durch Kommandozeilenparameter einschränken:
• Mittels -server Servername werden nur Volumes angezeigt, von
denen mindestens eine Instanz auf dem angegebenen Server liegt.
• Die Option -partition Partition beschränkt in Kombination mit
-server Servername die Ausgabe auf die Volumes, von denen Instanzen
auf der Partition Partition des Servers Server liegen.
• Die Option -locked bewirkt, dass nur gesperrte Volumes (siehe 6.13.1,
Seite 137) angezeigt werden.
Es lassen sich Volume-Instanzen anzeigen, die sich auf einem bestimmten Fileserver
befinden (Beispieloutput siehe Listing 6.4):
user@host>vos listvol Servername
Im Gegensatz zu vos listvldb werden die auf dem Fileserver enthaltenen
Instanzen nicht über die VLDB sondern direkt über den Server ermittelt. Angezeigt
werden dabei folgende Informationen zu den einzelnen Volumes:
1. Die ID der Volume-Instanz
2. Der Name 8 der Instanz
3. Der Typ der Instanz (siehe 3.1, Seite 27)
4. Die Größe der Instanz. Diese entspricht bei RO-Instanzen, die auf der selben
Partition wie RW-Instanzen liegen sowie bei Backup-Instanzen nicht 9
dem auf der entsprechenden Partition belegten Speicher, sondern vielmehr
folgenden Speichermengen:
• der Größe des Teilbaumes im AFS-Namespace, den die entsprechende
Instanz repräsentiert.
• der Größe eines Volume-Dumps von dieser Instanz
5. Ob die Instanz online oder offline ist. Alle Instanzen sollten immer online
sein. Ist eine Instanz nicht online, finden sich unter 8.5.4, Seite 181
Hinweise zur Behebung.
Zusätzlich werden Instanzen (nur durch ihre ID) angezeigt, die gerade in Benutzung,
also “busy” (siehe 6.13.2, Seite 137) sind. Folgende Optionen werden
von vos listvol akzeptiert:
8 Der Name wird über die VLDB abgefragt und ist auch nur dort gespeichert. Ist die VLDB nicht
verfügbar, so wird kein Name angezeigt.
9 Das liegt an der differenziellen Speicherung bei diesen Volumes (siehe 3.1.4, Seite 29).

6.10 Einholen von Informationen... 129
• Die Option -partition Partition beschränkt die Ausgabe auf Instanzen,
die auf der Partition Partition des Fileservers liegen.
• Bei angabe der Option -extended werden erweiterte Informationen zu
den gefundenen Instanzen angezeigt (u.a. Zugriffsstatistiken).
Listing 6.4: Beispiel-Output des vos listvol-Kommandos:Auf dem Rechner
afsserv1 befinden sich die RW-Instanzen der Root-Volumes der Zelle, zusammen
mit platzsparenden RO-Instanzen (siehe 3.1.4, Seite 29)
T o t a l number of volumes on s e r v e r a f s s e r v 1 . cbs . mpg . de p a r t i t i o n / v i c e p a : 4
r o o t . a f s 536870912 RW 11 K On−l i n e
r o o t . a f s . r e a d o n l y 536870913 RO 11 K On−l i n e
r o o t . c e l l 536870915 RW 9 K On−l i n e
r o o t . c e l l . r e a d o n l y 536870916 RO 9 K On−l i n e
T o t a l volumes onLine 4 ; T o t a l volumes o f f L i n e 0 ; T o t a l busy 0
6.10.2.3 Die verschiedenen Timestamps von Volume-Instanzen
Das instantafs .deb -Skript volgrep kann Volumes auflisten, die bestimmten
Kriterien entsprechen (siehe 9.2.26, Seite 204). Das ist z.B. nützlich, wenn man
diese Liste in Skripten einfach weiterverarbeiten will. Das Ausgabeformat der
klassischen AFS-Tools ist dafür eher ungeeignet.
Im folgenden ist die Bedeutung der Timestamps erläutert, die einer jeden Instanz
eines Volumes zugeordnet sind:
Last Update : Zeitpunkt der letzten Änderung auf Dateisystemebene an der Instanz.
Wenn es sich um eine RO- oder Backup-Instanz handelt, ist dieser Timestamp
identisch mit dem der RW-Instanz zum Zeitpunkt des Abgleichs.
Creation : Je nach Instanztyp unterschiedlich:
RW : Der Zeitpunkt, zu dem die Instanz angelegt wurde.
RO, Backup : Der Zeitpunkt der letzten Synchronisation (vos release bzw.
vos backup)
:
Backup : Zeitpunkt der letzten Synchronisation der zugehörigen RW-Instanz mit
der Backup-Instanz des Volumes. Daraus folgt, dass dieser Timestamp an
einer Backup-Instanz immer gleich dem Creation-Timestamp ist.
Copy : Je nach Instanztyp unterschiedlich:
RW, RO auf nicht-RW-Partition : Bei nicht-differenziell gespeicherten Instanzen (siehe 3.1.4, Seite
29), ist dieses Feld der Zeitpunkt, zu dem die Instanz angelegt wurde.
Achtung: Eine RO-instanz wird nicht durch vos addsite angelegt,
sondern durch das erste vos release danach.
RO auf RW-Partition, Backup : Bei diesem Instanzen ist der Copy-Timestamp gleich dem Creation-
Timestamp und damit der Zeitpunkt der letzten Synchronisation mit
der RW-Instanz.
6.10.2.4 Größe einer Volume-Instanz
Es gibt verschiedene Merkmale einer jeden Volume-Instanz, die mit ihrer Speichergröße
zu tun haben.
Zum einen sind da die aktuelle Quota und die Summe des Speicherbedarfs der
Dateien, die man sieht, wenn man sich die gemountete Volume-Instanz im VFS
eines AFS-Clients ansieht.

130 6 Tägliche Arbeit mit AFS
Eine weitere Größe wäre oft noch interessant: Der Speicherplatz, den eine
Clone innterhalb einer Volume-Group zusätzlich zur RW-Instanz kostet. Leider
läßt sich dieser prinzipiell nicht berechnen, wenn mehr als ein Clone innerhalb
der Volume-Group liegen und auch wenn es nur einer ist, gibt es keine
AFS-Funktion dafür.
Eine weitere Größe, die oft interessant ist, ist die erwartete Größe eines inkrementellen
Volume-Dumps. Das vos size-Kommando kann so etwas:
admin@afs>vos size Volumename oder ID -server Server -partition Partition -dump
-time MM/TT/JJJJ
6.10.3 ... über den Client
Dabei werden die Größen von allen Dateien aufsummiert, die sich seit dem
angegebenen Zeitpunkt verändert haben.
Der AFS-Client verrät seine genaue Versionsnummer per RX-RPC:
Hier ein Beispiel:
user@host>rxdebug -version Rechnername afs3-callback
Trying xxx.xxx.xxx.xxx (port 7001):
AFS version: OpenAFS 1.4.2 built 2006-12-15
6.10.4 ... über Verzeichnisse/Dateien
6.10.5 ... über die Zelle
6.10.5.1 Ermitteln der Volume-Mountpoints der Zelle
# ! / b i n / bash
Das funktioniert netzwerkweit - eine Liste inaktueller AFS-Clients zu erstellenm,
ist also ein Kinderspiel.
In diesem Abschnitt soll beleuchtet werden, was man alles über ein Verzeichnis
herrausfinden kann, das im AFS liegt. Dabei wird auf das Homedirectory des
gedachten Nutzers ernie zurückgegriffen. Benutzt man die aufgeführten Kommandos
für Dateien, so werden jeweils Informationen zum Verzeichnis eingeholt,
in dem sie liegen.
AFS führt nicht zentral Buch über die Mountpoints, die in Volumes liegen. Deshalb
ist es auf nicht ohne weiteres Möglich, Mountpoints auf nicht mehr existierende
Volumes zu entfernen.
Der salvager-Prozess auf Fileservern hat eine kleine Sonderfunktion: Er kann
nach Mountpoints suchen - sogar ohne die durchsuchten Volumes herunterzufahren.
Allerdings geht das nicht über das bos-Kommando, sondern muss lokal
ausgelöst werden, was aber natürlich auch per SSH geschehen kann.
Nachteilig ist, dass das auf jedem Fileserver geschehen muss. Hier ist ein Beispielskript:
Listing 6.5: Einfaches Shellskript, dass alle Mountpoints der aktuellen AFS-
Zelle anzeigt
# Read l i s t o f s e r v e r s − use t h e f i r s t NIC o n l y
SERVERS=‘vos listaddrs -printuuid | grep -A 1 UUID | egrep -v ’^(UUID|--)’‘
f o r s e r v e r in $SERVERS ; do
s s h r o o t @ $ s e r v e r ’/usr/lib/openafs/salvager -showlog -showmounts’

6.10 Einholen von Informationen... 131
done
6.10.5.2 Speicher, Volumename
Positives:
• Es findet wirklich alle Mountpoints der aktuellen Zelle
• Es geht im laufenden Betrieb - der Salvager führt keine Änderungen
durch.
Einschränkungen:
• Das Skript läuft - vor allen, wenn die Zelle viele Dateien enthält - sehr
lange.
• Es werden nur Volumes der aktuellen Zelle erfasst.
• Es sind root-Rechte auf allen Fileservern nötig. Achtung: Das ist nicht
gleichbedeutend mit Administratorrechten im AFS.
Das ist das Format, dass ausgegeben wird:
02/06/2007 14:06:44 In volume 536875765 (volume1) found mountpoin
Es gibt verschiedene Informationen, die man über das Volume eines Verzeichnisses
herrausfinden kann. Meist gibt es mehrere Befehle dafür. Z.B. lassen
sich der Name des Volumes und Informationen zum Speicherbedarf auf verschiedenen
Wegen herrausfinden:
user@host>fs diskfree /afs/cbs.mpg.de/user/ernie
Volume Name kbytes used avail %used
user.ernie 722610020 50206735 672403285 7%
user@host>fs examine /afs/cbs.mpg.de/user/ernie
Volume status for vid = 536870927 named user.ernie
Current disk quota is 100000
Current blocks used are 45346
The partition has 672403285 blocks available out of 722610020
user@host>fs listquota /afs/cbs.mpg.de/user/ernie
Volume Name Quota Used %Used Partition user.ernie 100000 45346 45% 7%
6.10.5.3 Auf welchem Fileserver?
4 Werte zum Speicher existieren zu einem Volume - alle beziehen sich auf
1024Byte-Blöcke:
• Die Größe der Partition, auf der das Volume liegt (hier 722610020).
• Der auf der Partition, auf der das Volume liegt, noch freie Speicher (hier
672403285).
• Der Speicher, den das Volume selbst belegt (hier 45346).
• Der maximal zulässige Speicherbedarf des Volumes - die Quota (hier
100000).
Mit folgendem Kommando läßt sich herrausfinden, auf welchem Fileserver ein
bestimmtes Verzeichnis liegt:
user@host>fs whereis /afs/cbs.mpg.de/user/ernie
File /afs/cbs.mpg.de/user/ernie lives on host afsserver1.cbs.mpg.de

132 6 Tägliche Arbeit mit AFS
Wendet man dieses Kommando auf einen Pfad in einer RO-Instanz an, dann
kann das Verzeichniss auch redundant auf mehreren Rechnern liegen:
user@host>fs whereis /afs
File /afs lives on hosts afsserver1.cbs.mpg.de afsserver2.cbs.mpg.de
6.10.5.4 In welcher Zelle?
Hinweis: Wird eine RW-Instanz gerade verschoben, so wird der ursprüngliche
Fileserver angezeigt - nicht etwa beide gleichzeitig.
Folgendes Kommando kann benutzt werden, um herrauszufinden, in welcher
Zelle ein bestimmtes AFS-Verzeichnis liegt:
user@host>fs whichcell /afs/cbs.mpg.de/user/ernie
File /afs/cbs.mpg.de/user/ernie lives in cell ’cbs.mpg.de’
6.10.5.5 Welche Rechte gelten?
Die beiden Access Control Lists von Verzeichnissen — also die Rechte —
lassen sich mit folgendem Kommando anzeigen:
user@host>fs listacl /afs/cbs.mpg.de/user/ernie
Access list for /afs/cbs.mpg.de/user/ernie is
Normal rights:
system:administrators rlidwka
system:anyuser l
ernie rlidwka
6.11 Load-Balancing
6.11.1 RO-Daten
Unter AFS sind je nach Art der Daten, um die es sich jeweils handelt, zwei Prinzipien
der Lastverteilung möglich. Die Lastverteilung erfolgt nicht automatisch
durch die AFS-Server, lässt sich jedoch auf sehr einfache Weise von Hand bzw.
mit dem bereitgestellten Tool balancer realisieren.
Eine Lastverteilung für Daten, auf die hauptsächlich lesend zugegriffen wird, ist
unter AFS sehr einfach zu realisieren. Die Last wird auf Volume-Ebene verteilt.
Das soll am Beispiel eines netzwerkweiten Verzeichnisses für Bash-Skripte gezeigt
werden:
1. Das Volume local.scripts wird zusammen mit seiner RW-Instanz auf
afsserv1 angelegt:
admin@afs>vos create afsserv1 a local.scripts
2. Es wird mit zwei Mountpoints (Erklärung siehe 7.1, Seite 140) in den
AFS-Namensraum eingebunden:
admin@afs>fs mkm /afs/.cbs.mpg.de/local/scripts local.scripts
admin@afs>fs mkm /afs/.cbs.mpg.de/local/.scripts local.scripts -rw
admin@afs>instantafs.release /afs/.cbs.mpg.de/local

6.11 Load-Balancing 133
6.11.2 RW-Daten
6.11.2.1 Vorarbeit
3. Jetzt wird auf beiden AFS-Fileservern jeweils eine RO-Instanz angelegt:
admin@afs>vos addsite afsserv1 a local.scripts
admin@afs>vos addsite afsserv2 a local.scripts
admin@afs>vos release local.scripts
Benutzer, die nun auf /afs/cbs.mpg.de/local/scripts zugreifen, benutzen
nun je nach den lokalen Serverranks (siehe 6.12, Seite 136) unterschiedliche
Fileserver.
Das Prinzip ist an einem Beispiel (siehe 7.10, Seite 158) verdeutlicht.
Die Lastverteilung von RW-Daten beruht auf der Möglichkeit, die RW-
Instanzen von Volumes leicht zwischen Servern verschieben zu können.
Verteilt man die RW-Volumes der Zelle geschickt auf die Fileserver, wird die
Last sehr gut verteilt. Da Fileserver Statistiken über die Zugriffshäufigkeit
auf einzelne Instanzen führen, kann die Verteilung der Volumes sehr genau
optimiert werden.
Das Prinzip ist wie folgt:
1. Per Hand werden Volumes so gestaltet (z.B. durch Zerlegung von sehr
großen Volumes), dass sie sich leicht verschieben lassen.
2. Das Programm balancer wird anschließend benutzt, um (ausschließlich)
RW-Instanzen je nach Auslastung auf die verfügbaren Fileserver zu
verteilen.
Wichtig für die Lastverteilung von RW-Zugriffen ist, dass die Daten der Zelle
geschickt auf Volumes verteilt sind. Dabei ist es u.U. nötig, einzelne Volumes
in mehrere zu zerteilen. Hier ein Beispiel:
1. Das Homedirectoryvolume user.ernie des Benutzers ernie ist sehr
groß (mehrere GB), die Hälfte besteht nur aus eMails im Verzeichnis
/afs/cbs.mpg.de/user/ernie/Mail.
2. Die eMails lagert man in ein separates Volume mail.ernie aus. Angelegt
wird dieses z.B. mit
admin@afs>vos create afsserv1 a mail.ernie
3. Die Teilung eines Volumes lässt sich nicht ohne Race-Conditions im laufenden
Betrieb durchführen, sollte also vorzugsweise zu einer Zeit geschehen,
wenn der Benutzer ernie gerade nicht anwesend ist.
4. Das alte Mail-Verzeichnis wird umbenannt
admin@afs>mv ∼ernie/Mail ∼ernie/Mail.preafs
und das neue Volume an seine Stelle gemountet
admin@afs>fs mkm ∼ernie/Mail mail.ernie
5. Jetzt muss man sich Gedanken darüber machen, wie die vorher einheitliche
Quota des Homedirectories von ernie auf die beiden Volumes verteilt
wird.

134 6 Tägliche Arbeit mit AFS
Hinweis: Es ist nicht möglich, eine Maximalquota für die Summe des
Speicherbedarfs zweier Volumes zu definieren. Das Volume user.ernie
hatte vorher eine Quota von 4000MB:
user@host>fs lq ∼ernie
Volume Name Quota Used %Used Partition
user.ernie 4000000 3566236 89% 75%
admin@afs>fs sq ∼ernie/Mail 2000000
Die Hälfte von ernie’s belegtem Speicherplatz besteht aus eMails - dem
neuen Volume werden deshalb 2000MB als Quota zugewiesen:
6. Das Volume mail.ernie wird mit vos move auf einen anderen Server
verschoben, was den Server, auf dem user.ernie liegt, entlastet.
7. Die eMails von ernie werden in das neue Volume kopiert:
admin@afs>shopt -s dotglob
admin@afs>cp -a ∼ernie/Mail.preafs/* ∼ernie/Mail
admin@afs>shopt -u dotglob
Die alten Mails werden gelöscht:
admin@afs>rm -rf ∼ernie/Mail.preafs
admin@afs>fs sq ∼/ernie 2000000
user@host>fs lsm ∼ernie/Mail
8. Die Quota des Homedirectory-Volumes von ernie wird nach unten korrigiert:
9. ernie und sein Mailtool werden mit 2 Ausnahmen keinen Unterschied zur
Situation vorher bemerken:
• Das Kommando
user@host>mv ∼ernie/Mail/Grosse_Datei.dat ∼
user@host>cp ∼ernie/Mail/Grosse_Datei.dat ∼
user@host>rm ∼ernie/Mail/Grosse_Datei.dat ∼
enttarnt das Verzeichnis /afs/cbs.mpg.de/user/ernie/Mail als Volume-
Mountpoint.
• Das Verschieben eines Files innerhalb des Homedirectories zwischen
den Volumes user.ernie und mail.ernie - z.B. mit
dauert nach der Zerteilung des Volumes genauso lange wie
Vor der Zerteilung wäre nur der Link auf das File in ein anderes Verzeichnis
des selben Volumes verschoben worden - jetzt wird kopiert
und danach gelöschte.
Der Vorteil von kleinen Volumes ist, dass sie sich leichter im Netzwerk verschieben
lassen. Es ist prinzipiell möglich, auch sehr große Volumes zu benutzen
(100GB sind kein Problem), jedoch sind diese sehr unflexibel.
Man sollte auch bedenken, dass Volumes zum Wachstum neigen

6.11 Load-Balancing 135
6.11.2.2 Volumes automatisch verschieben
# Der Name d e r Z e l l e . . .
c e l l cbs . mpg . de ;
6.11.2.2.1 ... mit balancer Das Programm balancer ist in der Lage,
die Zugriffsstatistiken der Fileserver auszulesen und daraus eine bessere Verteilung
der RW-Instanzen zu errechnen. Ergebnis ist eine Folge von vos
move-Kommandos, die die vom balancer errechnete bessere Verteilung der
RW-Instanzen herbeiführt.
Der balancer benötigt eine Konfigurationsdatei, die einige Eigenschaften der
Zelle beschreibt (Beispiel siehe Listing 6.6.
Listing 6.6: Beispielkonfigurationsdatei für balancer
# Eingangs− und A u s g a n g s r e g e l n f u e r d i e F i l e s e r v e r p a r t i t i o n e n d e r
# Z e l l e . P a r t i t i o n e n , d i e h i e r n i c h t a u f t a u c h e n werden vom b a l a n c e r n i c h t
# b e a c h t e t .
# Eine E i n g a n g s r e g e l i s t durch e i n ’ < ’ g e k e n n z e i c h e t . A l l e Volumes , d i e
# ( Globber−Ausdruecke s i n d e r l a u b t ) d a h i n t e r a u f t a u c h e n , d u e r f e n a u f d i e s e
# P a r t i t i o n f l i e s s e n .
# A e h n l i c h e s g i l t f u e r d i e A u s g a n g s r e g e l ( durch ’ > ’ g e k e n n z e i c h e n t ) . Nur
# d i e Volumes d a h i n t e r d u e r f e n den S e r v e r v e r l a s s e n .
#
# Bei b e i d e n R e g e l t y p e n koennen den e r l a u b t e n Volumes auch s o l c h e f o l g e n ,
# d i e t r o t z v o r h e r i g e r Nennung a u s z u s c h l i e s s e n s i n d . Die a u s z u s c h l i e s s e n d e n
# werden von den a n d e r e n durch ’ − ’ g e t r e n n t .
# Das Volume u s e r . e r n i e wird i n d i e s e r K o n f i g u r a t i o n a u f den S e r v e r a f s s e r v 1
# g e d r a e n g t − i s t es einmal a u f a f s s e r v 1 , wird es vom b a l a n c e r n i c h t mehr
# v e r s c h o b e n .
f s a f s s e r v 1 . cbs . mpg . de a
< u s e r .∗
> u s e r .∗ − u s e r . e r n i e ;
f s a f s s e r v 2 . cbs . mpg . de a ;
< u s e r .∗
> u s e r . ∗ ;
# P a r a m e t e r f u e r d i e e i n z e l n e n Module ( a g e n t s ) des b a l a n c e r s
# Der "−p"−P a r a m e t e r g i b t d i e T o l e r a n z des B a l a n c e r s an . Das
# i s t n o e t i g , um RW−I n s t a n z e n n i c h t dauernd h i n und herwandern
# zu l a s s e n .
# ’ b y s i z e ’ b e w i r k t , d a s s d e r b a l a n c e r den S p e i c h e r b e d a r f d e r
# RW−I n s t a n z e n i n s e i n e Berechnung e i n b e z i e h t .
a g e n t b y s i z e −p 3 0 ;
# ’ byweekuse ’ b e a c h t e t d i e Z u g r i f f e d e r l e t z t e n Wochen b e i d e r
# A u s b a l a n c i e r u n g d e r RW−I n s t a n z e n .
a g e n t byweekuse −p 3 0 ;
# ’ bynumber ’ b e w i r k t , d a s s d e r b a l a n c e r auch d i e Anzahl d e r
# RW−I n s t a n z e n pro S e r v e r a l s O p t i m i e r u n g s k r i t e r i u m b e n u t z t .
a g e n t bynumber −p 3 0 ;
# Der B a l a n c e r h a t 15 Stunden Z e i t um f o l g e n d e s zu t u n :
# ∗ Z u g r i f f s s t a t i s t i k e n einsammeln
# ∗ B e s s e r e V o l u m e v e r t e i l u n g e r r e c h n e n
# ∗ Volumes v e r s c h i e b e n
r u n t i m e = 15h ;
Für jeden Fileserver muss in dem File ein Block existieren, der mit fs
[Servername] beginnt und mit “;” endet. Mit den Zeichen “”
werden dann jeweils Blöcke von Volumes angegeben, deren RW-Volumes verschoben
werden sollen. Dabei sind Globber-Ausdrücke erlaubt. Ein innerhalb
dieser Blöcke angegebenes “-” bewirkt, dass die im Block nach dem “-”
angegebenen Volumes ausgeschlossen werden.
Nach jedem Verschieben eines Volumes legt der balancer eine Backup-
Instanz des Verschobenen Volumes an (wenn es auf dem Quellserver bereits
eine gab).
Da das Verschieben einer RW-Instanz dazu führt, dass die Backup-Instanz neu
synchronisiert wird, kann der balancer mit den Benutzer-Wiederherstellbaren

136 6 Tägliche Arbeit mit AFS
6.12 Server-Ranks definieren
Backups (siehe 7.2, Seite 141) interferieren. Er sollte deshalb möglichst am
Wochenende laufen.
6.11.2.2.2 ... etwas hochtrabender Russ Allbery hat ein Verfahren entwickelt,
in dem die Verteilung der Volumes auf den Fileservern der Zelle auf
eine lineare Optimierung zurückgeführt wird. Das ist mathematisch etwas
anspruchsvoller, für kleine Zellen jedoch übertrieben. Außerdem benötigt man
für seine spezielle Lösung ein kommerzielles Softwarepaket, das die lineare
Optimierung errechnet.
Mehr dazu unter http://www.eyrie.org/~eagle/notes/afs/
balance.html
Die AFS-Clients wählen selbstständig individuell aus, welchen Server sie mit
welcher Priorität kontaktieren. Dabei kommen zwei im Kernel auf jedem Client
unabhängig von allen anderen Clients gespeicherte Tabellen zum Einsatz, in
der jedem Server ein “Rank” (eine Priorität) zugeordnet ist. Eine der Tabellen
regelt den Zugriff auf Datenbankserver, die andere den Zugriff auf Fileserver.
Dabei gelten folgende Regeln:
• Server im selben Subnetz werden stark bevorzugt.
• Server mit numerisch kleineren IP-Adressen werden bevorzugt.
• Ist der beste Server nicht erreichbar, wird der nächst“schlechtere” benutzt.
Die Serverranks lassen sich mit dem Kommando fs getserverprefs
auslesen. Mit der zusätzlichen Option -vlservers werden anstelle der
Fileserver-Ranks die Datenbankserver-Ranks angezeigt. Niedrigere Werte
bedeuten höhere Priorität.
Gelegentlich ist es sinnvoll, die Ranks manuell zu definieren. Das kann jedoch
nur ein lokaler Superuser auf dem jeweiligen Client. Das entsprechende Kommando
lautet fs setserverprefs. Hier einige Beispiele:
root@host>fs setserverprefs afsserv1 20001 afsserv2 20002
weist den AFS-Client an, afsserv1 dem Rechner afsserv2 vorzuziehen, wenn
eine angeforderte RO-Instanz auf beiden Rechnern liegt.
root@host>fs setserverprefs -vlservers afsdb1 20001 afsdb2 20002
führt dazu, dass der AFS-Client Anfragen an die AFS-Datenbank bevorzugt an
afsdb1 richtet.
Serverranks sind solange gültig, bis der AFS-Client beendet wird. Sie werden
nicht abgespeichert, müssen also bei Bedarf nach jedem Neustart des Clients
(und somit bei jedem Bootvorgang) neu gesetzt werden. Das setzen der Serverranks
ist nur durch den lokalen Superuser des AFS-Clients möglich. Fällt ein
bevorzugter Rechner aus, werden die verbleibenden verwendet. Der AFS-Client
merkt sich, welche Rechner erreichbar bzw. nicht erreichbar sind und überprüft
das regelmäßig.

6.13 Sperren auf Volume-Ebene 137
6.13 Sperren auf Volume-Ebene
6.13.1 Gesperrte Volumes
Für jedes Volume (mit all seinen Instanzen) kann in der VLDB ein Bit gesetzt
werden, was von Tools, die auf Volumes-Ebene auf das AFS zugreifen (z.B.
vos) als eine Sperre interpretiert wird. Diese Sperre ist ein Hinweis, kein hartes
Hindernis. Sie verhindert, dass Transaktionen (z.B. das Verschieben einer RW-
Instanz) durch konkurrierende Schreibzugriffe auf die Instanzen des Volumes
oder auf die den entsprechenden VLDB-Eintrag gestört werden.
Folgende Kommandos sind im Zusammenhang mit Volume-Sperren wichtig:
• Mit vos lock wird ein Volume gesperrt. Ist das Volume bereits gesperrt,
wird ein Fehler zurückgeliefert. Beispiel:
admin@afs>vos lock root.cell
Locked VLDB entry for volume root.cell
admin@afs>echo $?
0
admin@afs>vos lock root.cell
Could not lock VLDB entry for volume root.cell
VLDB: vldb entry is already locked
admin@afs>echo $?
1
user@host>vos listvldb -locked
• Das Kommando vos unlock entsperrt ein Volume. War das Volume
nicht gesperrt, ist der Rückgabewert von vos unlock trotzdem 0 (=erfolgreich).
• Alle gesperrten Volumes einer Zelle lassen sich mit
anzeigen. Im Normalfall (wenn gerade keine Backups durchgeführt oder
Volumes verschoben/released werden) sollte die Liste leer sein:
user@host>vos listvldb -locked
VLDB entries for all servers which are locked:
Total entries: 0
admin@afs>vos unlockvldb
6.13.2 “Beschäftigte” Instanzen
• Es ist möglich, alle Volume-Sperren einer Zelle auf einmal aufzuheben:
Normalerweise sollte es nicht nötig sein, am Locking von Volumes manuell
etwas zu ändern. Es kommt vor allem in AFS-Kommandos zum Einsatz um exklusiv
auf ein Volume zugreifen zu können. Bricht ein AFS-Kommando jedoch
unerwartet ab und kann die Sperre eines Volumes nicht wieder aufheben, so
muss der Administrator manuell eingreifen.
Diese Sperre wird in der VLDB gespeichert - überlebt also z.B. einen Neustart
aller Datenbankserver der Zelle.
Es ist möglich, eine ganz bestimmte Volume-Instanz zu sperren. Das ist dann
nötig, wenn gerade auf Volume-Ebene schreibend auf diese zugegriffen wird.
Das passiert z.B., wenn eine RW-Instanz mit vos release mit ihren RO-
Instanzen synchronisiert wird. Eine solche Sperre verhindert weitere Zugriffe

138 6 Tägliche Arbeit mit AFS
auf Volume-Ebene (also z.B. per vos dump) sowie Zugriffe auf Filesystemebene
(über einen AFS-Client).
Vor allem RW-Instanzen sind i.d.R. immer nur kurz “beschäftigt”, so dass Zugriffe
nur um Sekunden verzögert werden. Der reguläre Benutzer merkt das nur
durch eine kurze Wartezeit.
Es ist möglich, dass ein AFS-Kommando “vergisst”, eine Instanz wieder freizugeben
(z.B. durch einen Absturz des Kommandos). Leider lässt sich eine solche
Sperre nicht direkt aufheben. Startet man jedoch die Serverprozesse des entsprechenden
Fileservers neu, so werden alle Instanzen dieses Fileservers wieder
entsperrt. Außerdem verfällt die Sperre nach einiger Zeit 10 .
Achtung:Oft braucht ein Kommando lediglich sehr viel Zeit an einer Volume-
Instanz. Bevor man schwere Geschütze auffährt und die Instanz zwangsweise
aus dem Zustand “busy” holt, sollte man sich deshalb sicher sein, dass wirklich
etwas schief läuft.
Folgende Befehl sind im Zusammenhang mit Volume-Instanz-Sperren wichtig:
Alle laufenden Transaktionen (und damit alle gesperrten Instanzen) eines
Fileservers zeigt man mittels vos listvol oder zusammen mit Hintergrundinformationen
durch vos status an. So sieht’s z.B. aus, wenn gerade
keine Instanz busy ist:
user@host>vos status afsserv1
No active transactions on afsdb1
user@host>vos listvol afsserv1
Total number of volumes on server afsserv1 partition /vicepa: 1
user.afstest 536870942 RW 2233 K On-line
Total volumes onLine 1 ; Total volumes offLine 0 ; Total busy 0
Wird gerade eine Instanz benutzt, sieht das z.B. wie folgt aus:
user@host>vos status afsserv1
Total transactions: 1
------------------------transaction:
115 created: Fri Aug 20 16:08:35 2004
attachFlags: busy
volume: 536870942 partition: /vicepa procedure: TransCreate
-------------------------
vos listvol zeigt unter den Instanz-Listen der einzelnen Partitionen jeweils
an, wieviele Instanzen gesperrt (“busy”) sind. Beispiel:
user@host>vos listvol afsserv1
Total number of volumes on server afsserv1 partition /vicepa: 1
**** Volume 536871192 is busy ****
Total volumes onLine 0 ; Total volumes offLine 0 ; Total busy 1
Mit folgendem Kommando kann man den voslerver neu starten und dabei
10 10 Minuten sind im OpenAFS-Quellcode eingestellt. Der Wert lässt sich zur Laufzeit nicht än-
dern.

6.13 Sperren auf Volume-Ebene 139
root@fileserver> killall volserver
6.13.3 Offline-Instanzen
alle “busy”-Instanzen wieder freigeben, ohne dass der Fileservice auf dem
entsprechenden AFS-Server unterbrochen wird:
Es ist möglich, einzelne Instanzen zu sperren. AFS-Clients greifen dann nicht
auf sie zu. Man kann jedoch trotzdem mit Administrationstools wie vos dump
auf solche Instanzen zugreifen (Bsp: siehe 5.4, Seite 108.
Hier ein Beispiel - das Volume user.afstest ist zuerst Online, wird danach auf
Offline und anschliessend wieder auf Online gesetzt:
user@host>vos listvol afsserv1
Total number of volumes on server afsserv1 partition /vicepa: 1
user.afstest 536870942 RW 2233 K On-line
Total volumes onLine 1 ; Total volumes offLine 0 ; Total busy 0
user@host>vos offline afsserv1 a user.afstest
user@host>vos listvol afsserv1
Total number of volumes on server afsserv1 partition /vicepa: 1
user.afstest 536870942 RW 2233 K Off-line
Total volumes onLine 0 ; Total volumes offLine 1 ; Total busy 0
user@host>vos online afsserv1 a user.afstest
user@host>vos listvol afsserv1
Total number of volumes on server afsserv1 partition /vicepa: 1
user.afstest 536870942 RW 2233 K On-line
Total volumes onLine 1 ; Total volumes offLine 0 ; Total busy 0
Hinweise:
• Es kommt vor, dass ein Fileserver einzelne Volumes als Offline markiert.
Das ist ein Problem, unter 8.5.4 auf Seite 181 gibt’s Tips zur Lösung.
• Die Kommandos vos online und vos offline sind sonst nirgends
dokumentiert.

7 Rezepte
7.1 Eine Beispiel-Zelle
7.1.1 Verzeichnisstruktur
Pfad Volume B e s c h r e i b u n g
+ M o u n t p o i n t t y p
In diesem Abschnitt wird ein Zelle skizziert, die für einige der Rezepte als Umgebung
dienen soll.
Der Baum in 7.1 zeigt dabei zum einen die Struktur des Filesystems sowie die
jeweiligen Ziele der Mountpoints.
Listing 7.1: Verbundene Volumes in der Beispielzelle
/ a f s r o o t . a f s Das AFS−Root−V e r z e i c h n i s
|− cbs . mpg . de r o o t . c e l l Das Root−V e r z e i c h n i s d e r Z e l l e
| |− u s e r u s e r Das Root−Volume f u e r Homedirs
| | |− e r n i e u s e r . e r n i e (−rw ) Ein Homedirectory
| | ‘− b e r t u s e r . b e r t (−rw ) . . . noch e i n Homedirectory
| |− . u s e r u s e r (−rw )
| | . . .
| |− user−backup user−backup Backup−I n s t a n z e n d e r Homedirs
| | ‘− b e r t u s e r . b e r t . backup Backup des Homedirs von b e r t
| | . . .
| |− . user−backup user−backup (−rw )
| | . . .
| |− user−na user−na D e a k t i v i e r t e Benutzer−Homedirs
| |− . user−na user−na (−rw )
| |− tmp tmp (−rw ) / tmp im AFS ( Z w i s c h e n a b l a g e )
| |− admin
| | |− e t c a . e t c K o n f i g u r a t i o n s d a t e i e n
| | | ‘ s e c r e t Nicht−o e f f e n t l i c h e K o n f i g u r a t i o n s d a t e i e n
| | |− tmp a . tmp (−rw ) Nicht−o e f f e n t l i c h e t e m p o r a e r e D a t e i e n
| | ‘− . e t c a . e t c (−rw )
| |− p r o j e c t s p r o j e c t s Root−Volume f u e r P r o j e k t e
| |− . p r o j e c t s p r o j e c t s (−rw )
| ‘− l o c a l
| |− s c r i p t s l o c a l . s c r i p t s s e l b s t g e s t r i c k t e S k r i p t e
| ‘− . s c r i p t s l o c a l . s c r i p t s (−rw )
|− . cbs . mpg . de r o o t . c e l l (−rw ) Fuer Aenderungen an d e r Z e l l e n s t r u k t u r
| . . .
‘− . r o o t . a f s r o o t . a f s (−rw )
root@host>vos release root.cell
Anhand der Beispielzelle soll auch erklärt werden, wofür die verschiedenen
Volume-Mountpoints (siehe 3.2, Seite 32) in der Praxis relevant sind.
Das AFS-Rootvolume der lokalen Zelle wird vom AFS-Client immer ROgemountet.
Das Zellen-Rootvolume der lokalen Zelle ist als RO-Instanz unter
/afs/cbs.mpg.de zu erreichen, weil /afs auch RO-gemountet wird und der
Mountpoint /afs/cbs.mpg.de nicht explizit auf eine RW-Instanz verweist. Soll
etwas am Zellen-Rootvolume geändert, z.B. ein Verzeichnis angelegt werden,
so muss diese Änderung unter /afs/.cbs.mpg.de, also in der RW-Instanz erfolgen
und anschließend in die RO-Kopien des Zellen-Rootvolumes verteilt werden:
Das klingt umständlich, hat aber einen einfachen Grund: RO-Instanzen können
beliebig oft existieren. Wird per default eine RO-Instanz auf einem Pfad durchschritten,
dann wird vom AFS-Client eine beliebige verfügbare RO-Instanz (von
dem es auf jedem AFS-Fileserver der Zelle eine geben kann) benutzt. Würde
140

7.2 Administrationsarme Backups 141
7.1.2 Server
7.2 Administrationsarme Backups
man eine RW-Instanz benutzen, so wäre das ein Single-Point-of-Failure, da es
nur maximal eine RW-Instanz eines jeden Volumes gibt. Das Prinzip ist unter
(siehe 3.2.3, Seite 34) beschrieben.
Alle Nutzer der Zelle haben ihr Homedirectory unter
/afs/cbs.mpg.de/user/. Die eigentlichen Homedirectory-Volumes
sind explizit RW-gemountet. Wären die Volumes ohne RW-Option
gemountet, so würde sich der AFS-Client für eine RO-Kopie entscheiden,
schließlich ist das Parent-Directory (/afs/cbs.mpg.de/user) eine RO-Instanz
des Volumes users, in dem die Mountpoints für alle Homedirectories liegen.
Jeder Nutzer besitzt ein Homedirectory-Volume. Der Name setzt sich aus
user. und dem Loginnamen zusammen. Alle Volumes einer “Art” (z.B. alle
Homedirectory-Volumes) sollten den gleichen Präfix haben, um sie leicht
mit Globber-Ausdrücken in Kommandos wie vos backupsys erfassen zu
können.
Die Beispielzelle besteht aus 4 Servern:
1. afsserv1 - ein Fileserver
2. afsserv2 - noch ein Fileserver
3. afsdb1 - ein Datenbankserver
4. afsdb2 - noch ein Datenbankserver
Hinweis: Die Zelle enthält nur 2 DB-Server, was in einer wirklichen Zelle nicht
zu raten ist. 3 sind das empfohlene Minimum. Die Anzahl der DB-Server sollte
immer ungerade sein.
AFS bietet mit seinen Backup-Instanzen und der damit verbundenen differenziellen
Speicherung von Volumes eine Möglichkeit, Dateien und Verzeichnisse
durch die Nutzer selbst wiederherstellen zu lassen, besonders wenn die Backups
auf Platten gemacht werden. Wird diese Möglichkeit genutzt, sinkt der Administrationsaufwand
für Probleme der Art Ich–hab’–da–gerade–diese–wichtige–
Datei–gelöscht gegen Null.
Man lege einfach für jedes, auf diese Weise zu sichernde, Volume eine Backup-
Instanz an (siehe 3.1, Seite 27). Die Synchronisation der Backup-Instanz mit
der RW-Instanz macht AFS nicht automatisch. Bei der Installation des Backupservers
schreibt InstantAFS jedoch einen cron-Job auf dem Backupserver, der
durch Aufrufe von instantafs.backup die Synchronisation automatisch durchführen
kann (siehe 5.2.3, Seite 101).
Hier ein Beispiel, wobei die Beispielzelle (siehe 7.1, Seite 140) vorrausgesetzt
wird:
1. Der Benutzer ernie will Sicherheit für seine Daten und beantragt eine
Backup-Instanz für sein Homedirectory-Volume. Natürlich sollte der
Administrator in weiser Voraussicht für jeden Benutzer eine solche
Instanz anlegen.
Hinweis: InstantAFS’s Benutzermanagement legt per default 1 eine
Backup-Instanz gleich mit dem Homedirectoryvolume neuer User an.
Dreh- und Angelpunkt dieses Automatismus ist der Aufruf der acall-
Funktion instantafs.acall-volcreate auf dem db-acall-Server.
1 und je nach Inhalt der Datei /a/a/etc/acall-volcreate.conf

142 7 Rezepte
root@host>vos backup user.ernie
2. Der Administrator muß für ernie eine Backup-Instanz erzeugen. Diese
liegt dann auf der selben Partition wie die RW-Instanz:
3. Der Administrator muss nun das Doppelte des Quotas des Volumes
user.ernie an Maximalspeicherverbrauch auf der entsprechenden Partition
einplanen (worst case).
4. Die Backup-Instanz von ernie’s Homedirectory-Volume user.ernie wird
nicht automatisch aktualisiert. Es bietet sich an, zu einem definierten Zeitpunkt
alle Backup-Instanzen, die mit Homedirectories zu tun haben, zu
aktualisieren. InstantAFS bringt ein Konzept für diese Synchronisation
mit, das mit dem Backup eng verbunden ist (siehe 5.2.3, Seite 101).
5. Damit ernie Zugriff auf das Volume hat, wird ein neuer Mountpoint auf
die Backup-Instanz von ernie’s Homedirectory-Volume erzeugt:
admin@afs>fs mkm /afs/cbs.mpg.de/.user-backup/ernie user.ernie.backup
admin@afs>vos release user-backup
Jetzt muss die RW-Instanz von user-backup in seine RO-Instanzen synchronisiert
werden, damit unter /afs/cbs.mpg.de/user-backup/ernie die
Backup-Instanz sichtbar wird:
6. Aus versehen löscht ernie die Datei /afs/cbs.mpg.de/user/ernie/wichtig.txt.
7. Da er die Datei an vorherigen Tag bereits besessen hat 2 , kann ernie
sie selbst wiederherstellen. Der Administrator muss sich nicht darum
kümmern.
ernie@afsclient> cp /afs/cbs.mpg.de/user-backup/ernie/wichtig.txt \
/afs/cbs.mpg.de/user/ernie/wichtig.txt
7.3 Sicher und Bequem - SSH ohne Passwort
7.3.1 Einloggen per SSH mit Public-Key
8. Wäre die Datei erstellt und gleich wieder gelöscht worden, also ohne,
dass zwischendrin ein Synchronisationsprozess die Backup-Instanz upgedated
hat, dann wäre diese Wiederherstellung nicht möglich gewesen.
In diesem Abschnitt wird erklärt, wie man auf sichere Weise Kommandos auf
anderen Rechnern ausführen kann. Dazu zählt auch das interaktive Einloggen
per ssh sowie die Übertragung von Dateien mit sftp oder scp.
Dieses Rezept ist nicht AFS-spezifisch, hilft jedoch beim Aufsetzen von Zellen,
die aus mehr als einem Server bestehen. Diese Methode ist vor allem für
Administratoren interessant. Sie ist sehr robust und funktioniert im Gegensatz
zu Kerberos-basierenden Lösungen auch, wenn die Zeit zwischen Client und
Server nicht synchronisiert ist.
Mittels ssh ist es möglich, ein Kommando auf einem entfernten Rechner sicher
- ohne Eingabe eines Passwortes - auszuführen. Das ist von der Funktionalität
her mit den Kommandos rsh/rexec vergleichbar - nur eben sicherer.
2 und hier davon ausgegangen wird, dass sich ein nächtlicher cron-Job um die Synchronisation
kümmert

7.3 Sicher und Bequem - SSH ohne Passwort 143
Man braucht zwar kein Passwort einzugeben, eine Authentifikation ist allerdings
trotzdem nötig. So geht es:
1. Zuerst muss ein neues Schlüsselpaar erzeugt werden:
user@host>ssh-keygen -f Dateiname -t dsa
root@host>chmod 600 Dateiname
root@host>chown root Dateiname
Man wird nun zum zweimaligen Eingeben eines Passwortes aufgefordert
- hier sollte man einfach Return drücken, ein leeres Passwort also.
Danach enthält die Datei den privaten Schlüssel und
.pub den öffentlichen.
2. Den privaten Schlüssel legt man jetzt auf dem Rechner ab, von dem aus
man sich auf dem entfernten Rechner einloggen will. Beachten Sie, die
Leserechte so zu setzen, dass wirklich nur die Personen/Prozesse Zugriff
auf die Datei haben, die das auch später haben sollen - also z.B. so:
3. Der öffentlich Schlüssel besteht nur aus einer Zeile. Auf dem Rechner,
auf dem man sich später passwortlos einloggen will, hängt man diese
Zeile im Homedirectory des Benutzers, als der man sich einloggen will
(z.B. root), an die Datei ∼/.ssh/authorized_keys an.
4. Zum Testen führt man jetzt auf dem Rechner, auf dem der private Schlüssel
liegt, folgendes Kommando aus:
user@host>ssh -i Dateiname Benutzer@Rechner hostname
7.3.2 Single-Sign-On mit Kerberos5
Das auszuführende Kommando hostname wird auf der Gegenseite an
/bin/sh übergeben.
Wird jetzt der Name des entfernten Rechners ausgegeben, ohne dass ein
Passwort eingegeben werden musste, hat alles geklappt.
Hinweis:Wahrscheinlich ist der öffentliche Schlüssel des SSH-Servers
noch durch Eingabe von yes (mit anschließendem Newline) zu bestätigen.
5. Soll der private Schlüssel per default benutzt werden, muss er in
∼.ssh/id_dsa des entsprechenden Benutzers 3 umbenannt (oder entsprechend
verlinkt) werden.
Mit Kerberos5 ist es möglich, den Benutzern der Zelle die Eingabe von
Passwörtern beim Zugriff auf Dienste im Netzwerk zu ersparen. Das Prinzip
ist unter 3.10 erklärt. Eine Anwendung (z.B. ssh) muss explizit Kerberos
unterstützen, um die Authentifikation ohne Passwort zu ermöglichen.
Unter AFS besteht die zusätzliche Schwierigkeit darin, dass auf Rechner, auf
denen man über die Ferne (z.B. per ssh) arbeitet, meist ein AFS-Token benötigt
wird. Um es auf den anderen Rechnern zu bekommen, existieren folgende
theoretische Möglichkeiten, von denen die letzte (2b) die beste ist:
1. Das Token kann (selbstverständlich nur über verschlüsselte Kanäle) zum
entfernten Rechner geschickt und dort in den Kernel kopiert werden.
3 Der Name des Benutzers auf dem Client, der den Schlüssel zur Authentifikation einsetzen will.
Das hat nicht zwangsläufig etwas mit dem Loginnamen auf dem Zielserver zu tun.

144 7 Rezepte
Dafür ist keine spezielle Unterstützung durch Kerberos nötig - jedoch
muss das im Netzwerk benutzte Protokoll (z.B. SSH) explizit dieses
“AFS-Token-Forwarding” unterstützen.
2. Das Token kann auf dem entfernten Rechner neu erzeugt werden. Beim
Einsatz von AFS mit Kerberos5 gibt es dafür zwei Möglichkeiten:
(a) Der Benutzer gibt (entweder per PAM oder in ein entsprechendes
Skript in einer bash-Konfigurationsdatei) ein Passwort ein, um
ein neues TGT vom Kerberos-Server zu holen. Anschließend wird
über den Zwischenschritt eines AFS-Service-Tickets ein neues
AFS-Token erzeugt.
Nachteil: Man muss ein Passwort eingeben, obwohl man ja eigentlich
schon an der Kerberos-Realm authentifiziert ist.
(b) Das TGT wird (selbstverständlich nur über verschlüsselte Kanäle)
zum entfernten Rechner geschickt und dort im “Credentials Cache”
abgelegt. Anschließend wird über den Zwischenschritt eines AFS-
Service-Tickets ein neues AFS-Token erzeugt. Diese Methode ist
sehr komfortabel. Da kein Passwort benötigt wird, können sich auch
Skripte und Programme auf diese Weise auf anderen Rechner mit
den Rechten eines Nutzers anmelden.
Diese Methode wird empfohlen, da sie am komfortabelsten ist.
Diese Methode ist gegenüber dem Token-Forwarding im Vorteil, da ...
• ... sie ohne spezielle AFS-Unterstützung 4 in den beteiligten Programmen
(z.B. ssh und sshd) auskommt und
• ... weil damit sichergestellt ist, daß man auch auf der Gegenseite
ohne weitere Passworteingabe gleich mit Kerberos arbeiten kann.
Ein für Methode 2b modifiziertes ssh .deb steht für InstantAFS zur Verfügung.
Es unterscheidet sich in folgenden Dingen vom Standard-Debian-SSH-Paket:
• Das Authentifikationsmodul “gssapi-with-mic” wird unterstützt. Es ermöglicht
das Einloggen mit Kerberos5-Ticket und die Weiterleitung des
TGT an den entfernten Rechner. Es existiert bereits ein Kerberos–taugliches
SSH-Paket für Debian (ssh-krb5 .deb ), jedoch ist dieses durch das
verwendete Authentifikationsmodul (“gssapi”) nicht zukunftssicher 5 .
• angepasste Versionen von /etc/ssh/ssh_config und /etc/ssh/sshd_config,
damit’s auch gleich funktioniert
• Das neue TGT wird mit einer Lifetime von 1000h (siehe 3.10.7, Seite 65)
angefordert.
• Das Kommando aklog wird von sshd selbst aufgerufen, um ein Token
zu generieren 6 .
Auf allen Rechnern, auf denen man sich auf diese Weise einloggen will,
muss das modifizierte ssh .deb -Paket installiert werden. Außerdem muss jeder
dieser Rechner einen Kerberos5-Principal erhalten. Komfortabler geht das mit
instantafs.kerberos, das auf dem Kerberos-Master-Server auszuführen ist.
4 Kerberos wird i.d.R. eher unterstützt als AFS
5 “gssapi” ist nicht kompatibel zu “gssapi-with-mic”. Client und Server müssen zur erfolgreichen
Authentifikation die gleichen Module benutzen.
6 Das könnte theoretisch auch in der ∼/.bashrc passieren, jedoch würde dann für sftp und
scp kein Token zur Verfügung stehen.

7.4 Wie kommt ein kerberosifizierter Dienst zu seinem Schlüssel? 145
Hier ein Beispiel für die Zelle cbs.mpg.de:
root@kerberos> instantafs.kerberos -G afsclient1
Damit würde der Rechner afsclient1.cbs.mpg.de einen Schlüssel 7 für den Principal
host/afsclient1.cbs.mpg.de@CBS.MPG.DE erhalten. Evtl. muss das root-
Passwort von afsclient1 auf dem Kerberos-Master-Server bis zu zweimal eingegeben
werden.
7.4 Wie kommt ein kerberosifizierter Dienst zu seinem Schlüssel?
root@host>ssh root@kerberos
root@host>kadmin.local
Jeder Dienst, der von einer Authentifikation per Kerberos profitieren will, muß
über mindestens einen eigenen Schlüssel (und damit über einen Principal) in der
Kerberos-Datenbank verfügen. Hier sind einige Beispiele für Dienst-Principals:
• afs@CBS.MPG.DE
• host/afsserv1.cbs.mpg.de@CBS.MPG.DE
• acall/afsserv1.cbs.mpg.de@CBS.MPG.DE
Bei vielen Diensten muss der Name des Rechners, auf dem sie laufen als Instanz,
also vom eigentlichen Namen abgetrennt durch ein “/”, angegeben werden.
Der Administrator muß sich selbst darum kümmern, den Principal des Dienstes
anzulegen und dem Dienst den Schlüssel aus der Kerberos-Datenbank auf einem
sicheren Weg (Diskette,Memorystick,SSH,...) zur Verfügung zu stellen.
Kerberos5-Dienste erwarten, dass der Schlüssel in einer Keytab gespeichert ist
- meist in der Datei /etc/krb5.keytab.
Hinweis: AFS ist kein Kerberos5-, sondern ein Kerberos4-Dienst. AFS-Server
benötigen zwar auch eine Kerberos5-Keytab, diese muß aber vor Benutzung
umgewandelt werden (siehe 7.5, Seite 146).
In folgenden Beispiel soll der SSH-Dienst des Rechners afsserv1.cbs.mpg.de
mit einem host-Schlüssel versorgt werden - das erhöht den Komfort beim Einloggen
(siehe 7.3.2, Seite 143). So geht das:
root@host>addprinc ernie
root@host>addprinc ernie@CBS.MPG.DE
1. Ein Login auf dem Kerberos-Master-Server ist nötig:
2. Eine kadmin-Shell wird auf dem Kerberos-Server gestartet:
Evtl. ist ein Password einzugeben, um den ssh-Daemon glücklich zu
machen. Bei der Angabe von Principals kann man i.d.R. den Namen der
Realm weglassen. Die folgenden ktutil-Kommandos sind z.B. in der
Realm CBS.MPG.DE äquivalent:
3. In der kadmin-Shell wird der neue Principal angelegt:
root@host>addprinc -randkey host/afsserv1.cbs.mpg.de
Der -randkey-Parameter weist dem Principal anstelle eines Passwortes
eine zufällige Zeichenfolge zu, was schwerer zu knacken ist.
7 Der Schlüssel wird unter /etc/krb5.keytab abgelegt.

146 7 Rezepte
4. Der/die Schlüssel des Principals werden in eine Keytab (siehe 3.10.3,
Seite 63) geschrieben. Der Name der Keytab (hier /tmp/geheim.keytab)
ist frei wählbar:
root@host>ktadd -k /tmp/geheim.keytab host/afsserv1.cbs.mpg.de
Achtung:
• Wer die Keytab eines Dienstes in seinen Händen hält, kann sich
unberechtigten Zugriff auf diesen einen Dienst verschaffen. Legen
Sie diese deshalb nicht in ein öffentlich zugängliches Verzeichnis 8 .
• Manche Dienste (z.B. AFS) können nur mit bestimmten Schlüsseltypen
umgehen. Bei ktadd ist in diesem Fall noch der -e-
Parameter zu benutzen. AFS benötigt z.B. unbedingt den Schlüsseltyp
des-cbc-crc:afs3. Hier ein Beispiel:
root@host>ktadd -k /tmp/afs.keytab -e des-cbc-crc:afs3 afs
user@host>exit
5. Die kadmin-Shell wird beendet:
6. Die Keytab wird auf den Zielrechner übertragen:
user@host>scp /tmp/geheim.keytab \
root@afsserv1.cbs.mpg.de:/etc/krb5.keytab
Achtung:
• Mit diesem Kommando wird die evtl. vorher auf diesem Rechner
vorhandene Keytab-Datei /etc/krb5.keytab mit allen in ihr gespeicherten
Schlüssel überschrieben. Schlüssel zu einer bereits vorhandenen
Keytab hinzuzufügen ist etwas aufwendiger.
• Nicht alle Dienste benutzen /etc/krb5.keytab um hinterlegte Schlüssel
zu laden.
7. Der Dienst, der diesen Schlüssel benutzt, sollte neu gestartet werden - in
diesem Fall der sshd auf afsserv1.cbs.mpg.de:
root@afsserv1> /etc/init.d/ssh force-reload
Für die Verteilung des host-Schlüssel eines Rechners auf dem entsprechenden
Rechner, existiert ein Kommando, das die oben genannten Schritte automatisch
ausführt. Es muss auf dem Kerberos-Master-Server ausgeführt werden:
root@kerberos> instantafs.kerberos -G Rechnername
7.5 Aufsetzen eines unspezialisierten AFS-Servers
Achtung: Der Rechnername darf keinen Domainanteil enthalten.
Dieses Rezept zeigt, was zu beachten ist, wenn eine neue AFS-Servermaschine
in die Zelle integriert werden soll. Dabei ist es unwichtig, ob diese später ein
File-, DB oder Backup-Server werden soll.
1. Vorrausgesetzt wird ein installiertes Debian Sarge 3.1.
8 /tmp ist eigentlich keine gute Idee, jedoch wird davon ausgegangen, daß sich kein normaler Benutzer
auf dem Kerberos-Master einloggen kann.

7.5 Aufsetzen eines unspezialisierten AFS-Servers 147
2. Mit der Zeile
AFS_CLIENT=false
in der Datei /etc/openafs/afs.conf.client stellt man sicher, dass der AFS-
Client bei einem Neustart nicht versehentlich hochgefahren wird. Der
nächste Punkt kann übersprungen werden, wenn die Datei nicht existiert.
3. Ein evtl. noch laufender AFS-Client muss zuerst beendet werden:
root@host>/etc/init.d/openafs-client stop
U.U. sträubt sich der Client und reagiert mit einem Kernel-Oops. Das
passiert z.B., wenn kein DB-Server verfügbar ist. In diesem Fall ist jetzt
ein Neustart des Systems fällig.
4. Mit folgendem Kommando werden alle nötigen Pakete installiert:
root@host>apt-get install instantafs-afsserver
. Die Fragen, die debconf jetzt stellt, kann man einfach weg-¨returnën, da
sich das Paket instantafs-customclient .deb später darum kümmert.
5. Ein evtl. noch laufender bosserver-Prozess muss mitsamt aller Unterprozesse
entfernt werden:
root@host>/etc/init.d/openafs-fileserver stop
root@host>killall bosserver
6. Die Datei /etc/openafs/server/ThisCell sollte nur den eigenen Zellennamen
auf einer Zeile enthalten - z.B. so:
root@host>cat /etc/openafs/server/ThisCell
cbs.mpg.de
7. Die Datei /etc/openafs/server/CellServDB muss vorhanden aber leer sein:
root@host>rm /etc/openafs/CellServDB
root@host>touch /etc/openafs/CellServDB
8. Die Dateien /etc/openafs/BosConfig und /etc/openafs/server/Keyfile müssen
weg:
root@host>rm -f /etc/openafs/BosConfig /etc/openafs/server/Keyfile
9. Die Datei /etc/openafs/server/UserList muss wie folgt aussehen:
root@host>cat /etc/openafs/server/UserList
admin
acall
10. Auf sichere Weise muss die beim Kerberos-Setup erstellte Datei afs.keytab
den Weg auf den neuen AFS-Server finden (z.B. per Diskette).
11. Der AFS-Key muß aus der Keytab extrahiert werden. Diese Kommando
erledigt das und stellt speichert den AFS-Key in die Datei /etc/openafs/server/KeyFile:
root@host>asetkey add 2 afs.keytab afs
Die “2” ist i.d.R. die KVNO (=Key Version Number Versionsnummer des
Schlüssels dieses Principals) des Schlüssels im keytab-File.

148 7 Rezepte
Meldet asetkey einen Fehler, müssen sie die korrekte KVNO mit
kt_util ermitteln. Beispiel:
user@host>echo -e ’rkt afs.keytab\nlist’ | ktutil
ktutil: ktutil: slot KVNO Principal
--- --- ------------------
1 1 afs@CBS.MPG.DE
Existiert mehr als ein Schlüssel für den afs-Principal in der Keytab, dann
ist diese Keytab unbrauchbar. In diesem Fall sollte man die Keytab neu
erzeugen und darauf achten, dass das Keytabfile, in das mittels ktadd
-k [keytabfile] der Schlüssel gespeichert wird, vor dem ktadd-
Aufruf nicht existiert.
12. Vorsichtshalber sollte die Datei /var/lib/openafs/sysid entfernt werden:
root@host>rm -f /var/lib/openafs/sysid
Wenn der Rechner vorher bereits ein Server war und die Datei nicht
entfernt wird, könnten die DB-Server den neuen Server fälschlicherweise
“wiedererkennen” und unzutreffende Annahmen über seinen Zustand
machen.
13. Der offizielle Name des Rechners muß lokal korrekt zurückgelieferter
werden. Informationen darüber, wie man das sicherstellt, findet man unter
8.11 auf Seite 190
14. Den bosserver startet man nun mit:
root@host>/etc/init.d/openafs-fileserver start
Ist er korrekt hochgefahren, müsste der bosserver ohne Unterprozesse
laufen. Das kann man mit folgendem Kommando testen:
user@host>pgrep -P ‘pgrep bosserver‘ || echo Alles OK
7.6 Erhöhte Privilegien für einfache Benutzer
7.6.1 Das Problem
Im Fehlerfall hilft ein Blick in /var/log/openafs/BosLog.
Gelegentlich müssen normale Benutzer Kommandos ausführen, die eigentlich
für Zellensuperuser reserviert sind. Z.B. macht das vos release-
Kommando solche Privilegien nötig, wenn einfache Benutzer für statische
Websites oder spezielle Softwarevolumes (Daten, die relativ selten verändert
werden) verantwortlich sind. Da jedoch kein Benutzer das Zellensuperuserpasswort
kennen sollte, gibt es nur zwei Lösungen:
• Der Benutzer (Benutzergruppen sind nicht möglich) wird auf allen betroffenen
Fileservern mit lokalen Superuserrechten ausgestattet:
root@host>bos adduser Servername Benutzername
“Betroffene Fileserver” sind alle die, auf die zur Ausführung der benötigten
Kommandos zugegriffen werden muss. Diese Methode ist hochgradig
unsicher, da der Benutzer auf diese Weise leicht eine Root-Shell auf dem
Fileserver und somit auch leicht den AFS-Key bekommt.

7.6 Erhöhte Privilegien für einfache Benutzer 149
7.6.2 Das Prinzip
• Ein Daemon könnte auf einem gesicherten Server Kommandos von nichtprivilegierten
Benutzern annehmen und anschließend mit Zellensuperuserrechten
ausführen. Auf diese Lösung wird jetzt näher eingegangen.
Hinweis: Es existiert bereits ein ähnliches Clilent/Server-Konzept (remctl,
siehe http://www.eyrie.org/~eagle/software/remctl/), programmiert
von Russ Allbery. Dieses kam aber nicht in Fragen, da InstantAFS
die Möglichkeit der Übergabe von Parametern für die aufgerufenen Kommandos
vorraussetzt.
acall ist eine Methode, um auf entfernten Servern Shell-Kommandos auszuführen.
Die Kommandos laufen dabei i.d.R. als root. Der Name soll andeuten, dass
es sich um AFS-bezogene Aufrufe (calls) von Funktionen handelt.
Alle Übertragungen über das Netzwerk werden DES verschlüsselt.
Achtung: Die Shellkommandos sind auf dem Zielsystem gegen beliebiges Ausführen
von Unterkommandos abzusichern.
Es dürfen nur Kommandos ausgeführt werden, die mittels eines Konfigurationsfiles
(/a/a/etc/acall.access) explizit dafür vorgesehen sind. Dabei läßt sich genau
einstellen, welche Benutzer welche Kommandos mit welchen Parametern ausführen
dürfen. Eine kommentierte Beispiel-Datei liegt dem Paket instantafsdoc
.deb unter /usr/share/doc/instantafs-doc/acall.access bei.
Der Benutzer kann die Ausführung von per acall aufgerufenen Shell-
Kommandos nicht unterbrechen oder anderweitig beeinflussen. Das ist wichtig,
da z.B. ein abgebrochenes vos move-Kommando das entsprechende Volume
in einem undefinierten Zustand hinterlassen kann.
Der exit-Code des ausgeführten Kommandos sowie ausgegebener Text von
STDOUT und STDERR, insgesammt maximal 4096 Zeichen, werden von
instantafs.acall zurückgeliefert.
InstantAFS baut bereits auf folgende 3 acall-Server auf:
db : Der acall-server auf dem ersten AFS-DB-Server. Er wird benutzt um
AFS-Benutzer (in der PTDB) und um Volumes anzulegen.
krb5 : Dieser kommt auf dem Kerberos-Server zum Einsatz um Kerberos-
Principals anzulegen.
samba : Der samba-acall-server ist für das Management der Keytabs auf dem
Samba-Gateway und für die Aktualisierung der /etc/samba/smbpasswd-
Datei zuständig.
db- und krb5-Server sind unter InstantAFS derzeitig zwangsweise identisch.
InstantAFS stellt einige entsprechende Kommandos zu Verfügung:
instantafs.acall-usermgr : verwaltet Einträge in Datenbanken, die irgendwie mit Benutzerinformationen
zu tun haben (Kerberos, AFS-PTDB und Samba). Ausserdem können
damit Homedirectories von Benutzern verwaltet (angelegt, deaktiviert
und gelöscht) werden. (siehe 9.2.6, Seite 195)
instantafs.acall-release : synchronisiert Volume-Instanzen mittels vos release (siehe 9.2.4,
Seite 195)
instantafs.acall-backup : synchronisiert die Backup-Instanz eines Volumes mit der RW-Instanz (
vos backup ) (siehe 9.2.2, Seite 194).
instantafs.acall-volcreate : legt Volumes an (siehe 9.2.7, Seite 195).

150 7 Rezepte
instantafs.acall-helloworld : ein Testkommando, das per default jeder Benutzer auf jedem Server aufrufen
darf (siehe 9.2.3, Seite 194).
instantafs.acall-setquota : zum setzen der Quota von Volumes
7.6.3 Der Ablauf eines acall-RPCs
Nach einer Installation mittels instantafs.setup kann acall sofort benutzt
werden. Die Anleitung zur manuellen Installation geht darauf ein, wie acall-
Server manuell aufzusetzen sind.
An einem Beispiel sei erläutert, was abläuft, wenn ein acall-RPC ausgeführt
wird. Im RW-gemounteten Verzeichnis /afs/cbs.mpg.de/local/.scripts hat
der Benutzer ernie Änderungen vorgenommen und will die Änderungen im
korrespondierenden RO-gemounteten /afs/cbs.mpg.de/local/scripts sichtbar
machen:
1. Mit folgendem Kommando setzt ernie jetzt das Release in Gang:
ernie@host> instantafs.release -d /afs/cbs.mpg.de/local/.scripts
I: releasing volume ’local.scripts’
2. Das Kommando instantafs.release ermittelt zunächst das Volume
des angegeben Verzeichnisses (es heisst local.scripts), stellt fest, dass
nur acall als Release-Methode in Frage kommt und führt selbstständig
folgendes Unterkommando aus:
instantafs.acall db instantafs.acall-release local.scripts
Die Parameter haben folgende Bedeutung:
db : Der anzusprechende acall-Server.
instantafs.acall-release : Das auf dem acall-Server aufzurufende Kommando. Beginnt das
Kommando mit der Zeichenkette instantafs.acall-, kann
man stattdessen ia: benutzen - also z.B. ia:release anstelle
von instantafs.acall-release.
local.scripts : Ein Parameter für das aufzurufende Kommando - es können auch
mehrere angegeben werden.
3. Das Tool instantafs.acall erfragt den korrekten Namen (FQDN)
von acall-db - die Antwort ist für dieses Beispiel server5.cbs.mpg.de.
4. server5.cbs.mpg.de wird per TCP (Port 6999) kontaktiert.
5. Beim acall-Server authentifiziert sich instantafs.acall mit dem
Kerberos-Ticket acall/server5.cbs.mpg.de@CBS.MPG.DE und schickt
das Kommando mit seinen Parametern verschlüsselt über den TCP-
Kanal.
6. Der acall-Server schickt, nachdem instantafs.acall-release
ausgeführt wurde, die Ausgaben des Shell-Kommandos zusammen
mit dem exit-Code verschlüsselt zurück zum Client und beendet die
Verbindung.
7. Auf dem Client werden die Ergebnisse ausgegeben:
Released volume root.cell successfully
ernie@host> echo $?
0

7.6 Erhöhte Privilegien für einfache Benutzer 151
7.6.4 Einrichten eines acall-Servers
Jeder beliebige Rechner kann ein acall-Server sein - ohne Risiko 9 für die anderen
acall-Server. Hier soll als Beispiel der Rechner mekong.cbs.mpg.de, der
sich in der Realm CBS.MPG.DE befindet zum db- und zum krb5-acall-Server
werden:
1. Auf dem Kerberos-Master muss ein Schlüssel für den einzelnen Rechner
angelegt werden:
root@kerberos> kadmin.local -q ’addprinc -randkey acall/mekong.cbs.mpg.de’
Der Schlüssel wird in eine keytab geschrieben:
root@kerberos> kadmin.local -q ’ktadd -k /tmp/acall.mekong.keytab’
user@host>acall db ia:helloworld
2. Auf den DNS-Servern der Zelle müssen folgende Records zur Zonendatei
der Domain cbs.mpg.de hinzugefügt werden:
acall-db IN CNAME mekong
acall-krb5 IN CNAME mekong
Diese Records werden später von instantafs.acall benutzt, um
jeweils den acall-Server zu ermitteln, der eine bestimmte Funktion anbietet
- z.B. wird mittels
der Server kontaktiert, der auf den DNS-Namen acall.db hört.
3. Die Keytab muß auf den neu einzurichtenden acall-Server in die Datei
/etc/instantafs/acall.local.keytab kopiert werden - z.B. so:
root@mekong> scp root@kerberos:/tmp/acall.mekong.keytab
/etc/instantafs/acall.local.keytab
root@mekong> instantafs.acall-server
root@mekong> init q
4. Der acall-Server-Prozess muß auf dem neuen acall-Server gestartet werden:
Es bietet sich an, das automatisch bei jedem Rechnerstart zu erledigen -
z.B. mit folgender Zeile in der Datei /etc/inittab
iaac:23:respawn:/usr/bin/instantafs.acall-server
Die Kennung iaac wird auch von den InstantAFS-Skripten für diesen
Zweck verwendet - sie sollte nicht verändert werden. Der init-Prozess
muss jetzt noch reinitialisiert werden:
Hinweis: Es ist prinzipiell möglich, einen acall-Server ohne einen AFS-Client
zu betreiben, jedoch entfällt dann die komfortable zentrale Konfiguration. Per
Default benutzt der instantafs.acall-server die Datei /a/a/etc/acall.access,
um Zugriffe zu authorisieren. Der Parameter - -accessfile
ermöglich es, eine andere Datei anzugeben - z.B. so:
root@host>instantafs.acall-server - -accessfile /etc/instantafs.acall.access
9 d.h.: es müssen keine gemeinsamen Schlüssel auf den acall-Servern liegen.

152 7 Rezepte
Test eines acall-Servers
ernie@host>kinit ernie
Um sicherzustellen, dass sich bei der Installation eines acall-Servers keine
Fehler eingeschlichen haben, sollte man ihn danach testen. acall-Server können
ausschliesslich von Kerberos-authentifizierten Benutzern benutzt werden -
anonymer Zugriff ist unmöglich. Für das Beispiel wurde der Benutzer ernie
ausgewählt, am Test mitzuwirken. Nur mit Kerberos-Authentifikation ist acall
nutzbar:
oder auch
ernie@afsclient>tokenmgr -l ernie
Das Kerberos-TGT wird jetzt für den acall-Zugriff eingesetzt:
ernie@host> acall db ia:helloworld hello world
This is instanafs-acall’s innovative hello-world program.
You’ve been identified as: ’ernie’
Your Kerberos5-Principal is : ’ernie’
This is the ’db’-acall-server.
Those were your arguments:
hello
world
7.7 Dienste AFS-tauglich machen
7.7.1 Rechner-basierte Authentifikation
Wenn das nicht funktioniert, hilft vielleicht ein Blick in Kapitel 8.9 auf Seite
187.
Manche Dienste/Prozesse müssen auf Dateien im AFS zugreifen, die nicht von
jedermann erreichbar sein sollten. Beispiele dafür sind:
• FTP-Server
• Einfache HTTP-Server.
Solche Dienste haben, wenn sie als root auf einem Rechner gestartet werden,
prinzipiell erst einmal keine Rechte, die sie im AFS nutzen könnten. Es gibt
drei Möglichkeiten, das zu ändern:
1. Der Computer, auf dem der Dienst läuft (oder auch das ganz Subnetz)
kann in eine Gruppe aufgenommen werden. Diese Gruppe kann man dann
in den ACL der benötigten Verzeichnisse aufnehmen und ihr Rechte zuweisen.
2. Der Dienst kann in eine PAG (siehe 3.7.2.3, Seite 49) gekapselt und mit
einem Token ausgestattet werden. Diese Methode ist besser, da man Netzwerkadressen
im Gegensatz zu Tokens leichter fälschen kann.
3. Der Dienst kann mit weitergeleiteten Authentifikationsinformationen von
zugreifenden Nutzern arbeiten.
Es ist möglich, Rechner zu AFS-PT-Gruppen zusammenzufassen (auch ein einzelner
Rechner pro Gruppe ist OK) und diese Gruppen in ACLs zur Rechtever-

7.7 Dienste AFS-tauglich machen 153
user@host>host ftp.cbs.mpg.de
ftp.cbs.mpg.de A 10.0.0.100
gabe zu nutzen. Im folgenden soll der Zugriff auf /afs/cbs.mpg.de/pub/ftp für
einen Prozess möglich sein, der auf dem Rechner ftp.cbs.mpg.de läuft:
root@host>pts createuser 10.0.0.100
1. Die IP-Adresse des Rechner wird ermittelt (Rechner können nicht per
DNS-Namen eingefügt werden):
2. Für den Rechner wird ein PT-Benutzer angelegt:
3. Eine Gruppe wird angelegt:
root@host>pts creategroup ftphosts
4. Der Rechner wird in die neue Gruppe eingefügt:
root@host>pts add 10.0.0.100 ftphosts
5. Die ACL im zu benutzenden Verzeichnis wird angepasst:
root@host>fs setacl /afs/cbs.mpg.de/pub/ftp ftphosts rl
7.7.2 Tokens für Dienste
root@host>pts createuser ftp
Der FTP-Server-Prozess auf ftp.cbs.mpg.de kann jetzt (wie auch alle anderen
Prozesse auf diesem Rechner) lesend auf /afs/cbs.mpg.de/pub/ftp zugreifen.
Diese Methode ist etwas komplizierter aufzusetzen, bietet dafür aber deutlich
mehr Sicherheit. Am Beispiel des Prozesses proftpd auf afsserv1, der einen
anonymen FTP-Server zur Verfügung stellen wird, soll hier demonstriert werden,
wie das geht:
1. Man benötigt einen neuen PT-Benutzer:
2. Außerdem ist ein neuer Kerberos-Principal nötig. Auf dem Kerberos-
Master-Server muß deshalb der neue Principal in der kadmin-Shell
angelegt werden:
root@host>kadmin.local
kadmin.local: addprinc -randkey ftp
kadmin.local: ktadd -k /tmp/ftp.keytab ftp
kadmin.local: exit
Die Keytab /tmp/ftp.keytab wird mit scp auf afsserv1 ins Verzeichnis /etc
gelegt.
3. Die Datei /etc/proftpd.conf muß folgende Zeile enthalten:
ServerType standalone
4. Mit folgenden Aufruf wird der Server auf afsserv1 nun gestartet:
root@host>tokenmgr -rS ftp -k /etc/ftp.keytab - - /usr/sbin/proftpd -n
Der Parameter -n bewirkt, dass proftpd keinen Background-fork()
macht. Das ist nötig, weil sich tokenmgr sonst beenden würde. Der

154 7 Rezepte
7.7.3 Weiterleiten von Authentifikationsinformationen der Nutzer
7.7.4 Lokal gespeicherte Benutzer-Keytabs
7.8 Homedirectories im AFS
tokenmgr-Prozess ist jedoch wichtig, um das Token regelmäßig aufzufrischen.
Diese Kommandozeile läßt sich auch z.B. über init starten. Dazu ist
dieser Einzeiler in /etc/inittab einzutragen:
ftp:23:respawn:/usr/bin/tokenmgr -rS ftp -k /etc/ftp.keytab
- - /usr/sbin/proftpd -n
Bestimmte Dienste sind in der Lage, Authentifikationsinformationen der Nutzer,
die auf sie zugreifen, für den Zugriff auf das AFS einzusetzen. Im folgenden
sind einige Dienste aufgeführt, die das unterstützen. Ausserdem ist beschrieben,
wie das jeweils geschieht:
sshd : OpenSSH ist in der Lage, Kerberos-Tickets von Benutzern zur Authentifikation
heranzuziehen. Mit einigen Modifikationen am SSH können solche
Tickets auch gleich in Tokens umgerechnet und somit für den Zugriff
auf das AFS benutzt werden (siehe 7.3.2, Seite 143). Für die Benutzung
von Kerberos-Tickets muß jedoch auf jeden Fall auch der SSH-Client
diese Funktion explizit unterstützen.
proftpd : Der ProFTPd besitzt keine eigene Kerberos-Unterstützung, kann jedoch
in Verbindung mit libpam-krb5 .deb und libpam-openafs-session .deb
aus einem übergebenen Passwort ein gültiges Token erzeugen.
smbd : Samba kann wie auf ProFTPd die unverschlüsselten Passwörter der
Nutzer per PAM-Module in Tokens umrechnen. Aktuelle Windows-
Versionen weigern sich jedoch, unverschlüsselte Passwörter zur Authentifikation
zu benutzen 10 . Für solche Fälle existiert eine weitere
Möglichkeit der Authentifikation von Benutzern (siehe 7.7.4, Seite 154).
Es ist möglich, lokal gespeicherte Kerberos-Keytabs der Benutzer einzusetzen,
um im Namen von Benutzern auf das AFS zuzugreifen. Das ist z.B. für Samba
sinnvoll, wenn LANMAN- oder NT-Hashes zur Authentifikation benutzt werden
und dadurch das Passwort des Nutzers für die Erstellung eines Tokens nicht
zur Verfügung steht. Einige Theoretische Betrachtungen darüber findet man unter
A.6 auf Seite 230, die Anleitung zum Aufsetzen ist unter 4.4.8 auf Seite 96.
Durch seine Pro-Verzeichnis-ACLs (siehe 3.7.3, Seite 51) sind im AFS einige
Dinge beim Anlegen eines Homedirectories zu beachten. Bestimmte Dateien
im Homedirectory sind um jeden Preis vor anderen Benutzern abzuschirmen
(z.B. ∼/.ssh, E-Mail-Verzeichnis). Bei bestimmten Dateien ist es dagegen sinnvoll,
anderen Benutzern 11 Zugriff darauf zu gewähren (z.B. ∼/public_html, Verzeichnis
größerer Projekte). Dem kann man folgendermaßen Rechnung tragen:
• Alle Benutzer dürfen sehen, was im Homedirectory liegt (“l”-Recht).
• Das Lesen von Dateien ist jedoch per Default verboten (kein “r”-Recht).
• Bestimmte Unterverzeichnisse des Homedirectories werden später explizit
für andere Nutzer freigeschaltet.
10 Oft läßt sich Windows durch Registry-Patches trotzdem zur Kooperation bewegen.
11 Das Wort “Benutzer” schließt natürlich auch Prozesse ein. Der SSH-Server sshd muss z.B. das
File ∼/.ssh/authorized_keys lesen können.

7.9 Benutzerverwaltung unter InstantAFS 155
7.9 Benutzerverwaltung unter InstantAFS
In diesem Zusammenhang können die Pro-Verzeichnis-ACLs und ihre Vererbung
an nachgeordnete Daten zu einem echten Feature werden. Man kann beispielsweise
Directories wie ∼/streng_privat und ∼/fuer_meine_Arbeitsgruppe
anlegen und mit den entsprechenden ACLs ausstatten. Einfach durch die Ablage
im richtigen Verzeichnis werden die Zugriffsrechte zweckmäßig gesetzt. 12
Das Skript instantafs.homedir enthält Kommandos, um ein AFS-
Homedirectory einzurichten. Es muss mit Zellensuperuserrechten ausgeführt
werden - z.B. durch das acall-Kommando instantafs.acall-usermgr
(siehe 9.2.6, Seite 195). Für einen Administrator ist es durchaus möglich, ein
Homedirectory so zu konfigurieren, dass der Benutzer keine Unterschiede
zum Nicht-AFS-Betrieb bemerkt, ohne auf den Sicherheitsgewinn von AFS
zu verzichten. Wie das instantafs.homedir aber zeigt, sind dafür oft
symbolische Links nötig.
Ist die acall-Schnittstelle (siehe 7.6.2, Seite 149) korrekt konfiguriert, läßt sich
die Benutzerverwaltung durch InstantAFS stark automatisieren.
InstantAFS beinhaltet das Tool instantafs.usermgr - ein interaktives
Perl-Skript zum Verwalten von Benutzeraccounts. Alle Verwaltungsaufgaben
werden per acall erledigt, wobei die folgenden acall-Funktionen zum Einsatz
kommen:
instantafs.acall-usermgr : zum Manipulieren der 4 Zustandstypen, die einen InstantAFS-Benutzer
characterisieren.
instantafs.acall-volcreate : zum Anlegen von neuen Homedirectory-Volumes.
Es ist auch leicht möglich, die Befehle zum Anlegen und Löschen von Benutzern
in bereits bestehende Benutzerverwaltungsanwendungen (z.B. Webformulare)
zu integrieren, wenn das Ausführen von Shell-Kommandos möglich ist.
Benutzer können unter InstantAFS in einem von drei Zuständen sein:
NOTEXISTENT : Der Benutzer wurde noch nicht angelegt bzw. er wurde wieder gelöscht.
NOTACTIVE : Der Benutzer wurde angelegt, ist jedoch nicht aktiviert. Solche Benutzer
sind Mitglied der PT-Gruppe users-na. Sie haben keine Chance, sich in
der Zelle einzuloggen, da der Kerberos-Server ihnen keine Tickets ausstellt.
Unter /a/user-na/ liegt das Homedirectory eines
solchen Nutzers. Typischerweise sind das User, deren Status sich in absehbarer
Zeit in Aktiv ändert.
ACTIVE : Der Benutzer hat einen gebrauchsfähigen Account, kann unter AFS arbeiten.
Er ist Mitglied der PT-Gruppe users. Sein Homedirectory liegt unter
/a/user/, die Version seines Homedirectories vom letzten
Tag liegt unter /a/user-backup/.
Es existieren noch zwei weitere spezielle Zustände:
VAGUE : Der entsprechende Zustand des Benutzers kann nicht eindeutig identifiziert
werden.
Beispiel: Ein Benutzer ist zugleich in den PT-Gruppen users und
users-na.
UNKNOWN : Der entsprechende Zustand des Benutzers kann nicht ermittelt werden,
weil ein Fehler auftrat.
12 kein Fummeln an umask, kein mühsames chmod, kein Vergessen eben dieser Aktionen

156 7 Rezepte
Hinweise:
Beispiel: Alle Datenabankserver sind nicht erreichbar und die Abfrage
isGroupmember($user,’users’) greift ins Leere.
• instantafs.usermgr ist nur ein kleines Demonstrationsskript. Man kann
es natürlich benutzen, um die eigene Zelle zu verwalten, i.d.R. sollte man
jedoch auf die acall-Funktionen, die dieses Tool aufruft direkt zugreifen
und diese in das eigene (bereits vorhandene) Benutzermanagement integrieren.
• Abhängig von der eigenen Zelle kann es gewünscht/nötig sein, dass die
Zustanstypen eines Benutzer nicht alle übereinstimmen oder dass die Reihenfolge
der Zustandsänderungen modifiziert werden muss.

7.9 Benutzerverwaltung unter InstantAFS 157

158 7 Rezepte
7.10 Praktische Anwendung der Volume-Replikation
Am Beispiel eines netzwerkweiten Verzeichnisses für selbstgeschriebene Skripte
der Benutzer der Beispielzelle (siehe 7.1, Seite 140), soll erläutert werden,
wie man RO-Instanzen praktisch einsetzen kann. Ein Skript-Verzeichnis eignet
sich dafür i.d.R. gut, da hauptsächlich aus ihm gelesen und relativ selten hinein
geschrieben wird.
Mit folgenden Befehlen wird das Volume angelegt und in den AFS-Namensraum
integriert:
1. Das Volume local.scripts wird mitsamt Lastverteilung angelegt (Erklärung
siehe 6.11.1, Seite 132). Es wird eine Punkt-nicht-Punkt-
Konstruktion benutzt (siehe 3.2.3, Seite 34):
root@host>vos create afsserv1 /vicepa local.scripts
root@host>vos addsite afsserv1 /vicepa local.scripts
root@host>vos addsite afsserv2 a local.scripts
root@host>fs mkmount /afs/.cbs.mpg.de/local/scripts local.scripts
root@host>fs mkmount /afs/.cbs.mpg.de/local/.scripts l.scripts -rw
root@host>vos release root.cell
2. Da es sich um Daten handelt, die hauptsächlich gelesen werden, bedeutet
die Lastverteilung gleichzeitig Ausfallsicherheit (siehe 5.1.1, Seite 98).
3. Die AFS-Fileserver, die RO-Instanzen des Zellen-Rootvolumes enthalten,
informieren nach jedem vos release-Aufruf umgehend alle
AFS-Clients, über die Updates in Volume root.cell. Dadurch sind die
neuen Pfade
/afs/cbs.mpg.de/local/scripts
und
/afs/cbs.mpg.de/local/.scripts
sofort auf allen Clients sichtbar.
4. Die User-Profiles (z.B. ∼/.profile oder /etc/profile) sollte man so einstellen,
dass der Pfad /afs/cbs.mpg.de in die $PATH-Umgebungsvariable integriert
wird - die Benutzer sollen schließlich die Skripte komfortable
nutzen können. Die ∼.bashrc sollte also solch eine Zeile enthalten:
PATH="$PATH:/a/local/scripts"
5. Scripte in local.scripts sind im frisch angelegten Zustand nur für Zellensuperuser
nutzbar. Man muss noch allen Benutzern Lese- und Ausführungsrechte
auf dem Volume einräumen:
root@host>fs setacl /afs/cbs.mpg.de/local/.scripts system:anyuser rl
6. Soll z.B. der Benutzer ernie das Recht haben, Skripte in dem neuen Volume
zu bearbeiten, muss man ihm in der entsprechenden ACL auch diese
Recht noch erteilen:
root@host>fs sa /a/local/.scripts ernie rlw
Hinweis: Diese Änderung der ACL verschafft ernie noch nicht das Recht,
neue Dateien anzulegen - dazu fehlt das “i”-Recht (siehe 3.7.3, Seite 51).
7. Der Administrator muß ernie jetzt noch die Möglichkeit verschaffen,
das local.scripts-Volume freizugeben. Dazu muß der Datei /a/a/etc/a-

7.11 Ein Projekt aus mehreren Volumes 159
call.access diese Zeile hinzugefügt werden:
db ernie instantafs.acall-release local.scripts
8. Hat ernie Änderungen unter /afs/cbs.mpg.de/local/.scripts durchgeführt
und hält sie für sinnvoll, stabil, fehlerfrei kann er die Änderungen in den
Produktionsbereich der Zelle kopieren, d.h. das local.scripts-Volume synchronisieren.
Das geht wie folgt:
ernie@host> instantafs.release local.scripts
oder auch, wenn ernie nichts von Volumes wissen will:
ernie@host> iarel -d /afs/cbs.mpg.de/local/scripts
7.11 Ein Projekt aus mehreren Volumes
7.11.1 Wie wird ein Projekt prinzipiell aufgebaut?
Projekte (Studien, Experimente) eines Institutes werden üblicherweise nicht
von Administratoren, sondern von aus EDV-Sicht regulären, Benutzern verwaltet.
An einigen Stellen sind dazu Zellensuperuserrechte nötig, die natürlich für
normale Benutzer stark eingeschränkt werden sollten.
Speichert man die Daten des Projektes unter AFS ab, sind einige Punkte zu
bedenken:
1. Zuerst muß die Struktur der benötigten Daten ermittelt werden. Fallen
viele große Datensätze an? Werden diese nur für dieses Projekt benutzt
oder auch für andere?
2. Ein root-Volume für dieses Projekt muß angelegt werden. In dieses Volume
werden im AFS dann alle Daten, die mit dem Projekt zu tun haben,
eingehängt, wohl gemerkt: nicht abgespeichert.
3. Für die Autorisation von Zugriffen sollte mindestens eine Gruppe für das
Projekt angelegt werden. U.U. sind auch mehrere Gruppen sinnvoll - z.B.
eine für Personen mit Schreibrecht, eine für Personen mit Leserecht, eine
für Personen mit eingeschränktem Leserecht, ... .
4. Eine oder mehrere Personen (z.B. der Leiter der Arbeitsgruppe, die das
Projekt bearbeitet) müssen besondere Rechte eingeräumt bekommen:
• Neue Volumes anlegen: Das ist nur nötig, wenn die Menge oder
die Struktur der Daten die Benutzung mehrerer Volumes sinnvoll
erscheinen lassen.
Der Administrator muß dabei gleich festlegen, auf welchen Servern
die Volumes angelegt, wo Sicherheitskopien (RO-Instanzen) abgelegt
werden und welche weiteren Parameter für die neuen Volumes
gelten sollen.
Der Vorgang des Anlegens und Einmountens eines Volumes umfasst
mehrere Befehle - ein kleines Skript kann dem Projektleiter
die Arbeit deutlich erleichtern.
• Bearbeiten der Projekt-Benutzergruppen: Kommen z.B. neue Personen
zur Arbeitsgruppe hinzu, kann der Projektleiter diesen nach
eigenem Ermessen Rechte an dem Projekt einräumen und braucht
sich nicht an Administratoren zu wenden.

160 7 Rezepte
7.11.2 Konkretes Beispiel: Vorüberlegungen
7.11.3 Vorbereitung durch den Administrator
5. Das Projekt muss vom Backup-System erfasst werden. Folgende Dinge
sind dabei zu koordinieren:
• Das Erstellen von Backup-Instanzen (siehe 3.1.3, Seite 29), um tägliche
Backups im schnellen Zugriff zu haben. (siehe 7.2, Seite 141)
• Das Synchronisieren der RO-Instanzen mit den RW-Instanzen des
Projektes, um maschinenübergreifende Redundanz der Daten zu haben.
• Das Sichern der Projektvolumes auf die Platten des Backup-Servers
(siehe 5.2.3, Seite 101).
Am Beispiel eines fMRI 13 -Experiments soll demonstriert werden, wie man ein
Projekt so organisiert, dass es von einem normalen Benutzer verwaltet werden
kann. Hier sind einige Kenndaten zu diesem Projekt:
• Man benötigt ein Kürzel für das Projekt. Ist es zu lang, kommt man mit
den Volumenamen in Schwierigkeiten. Diese Studie wird fmri-1 heißen,
das Projekt-Volume wird proj.fmri-1 genannt.
• Die Benutzer ernie und bert arbeiten gemeinsam an der Studie, benötigen
beide Schreibzugriff.
• Der Benutzer kermit erhält lediglich Lesezugriff.
• Für die Studie werden große Datensätze (1GByte pro Person) von Versuchspersonen
nach der jeweiligen Messung gespeichert und ausgewertet.
Für die Forschungsergebnisse und die Skripte zum Projekt sind 3GB
Speicherplatz veranschlagt.
• Es werden 40 Versuchspersonen erwartet.
• Der Benutzer ernie leitet die Studie - muß deshalb mit mehr Rechten
ausgestattet werden.
• Die Datenmenge macht es unpraktisch, die komplette Studie in ein Volume
zu legen (siehe 6.11.2, Seite 133). Die Studie bekommt deshalb ein
root-Volume, die Probandendaten werden in eigene Volumes gelegt und
in das Projekt-Root-Volume hineingemountet.
Die Versuchspersonenvolumes werden proj.fmri-1.vpxx genannt, wobei
xx eine zweistellige Zahl ist.
Hinweis: Wenn die Daten der Versuchspersonen auch in weiteren Experimenten
verwendet werden, ist es günstiger, sich für eine andere Struktur
zu entscheiden und die Versuchspersonenvolumes z.B. vpxxxx zu nennen.
Diese Volumes können dann je nach Bedarf in die diversen Projekte gemountet
werden.
Der Administrator muß vorher einiges einstellen. Werden oft Projekte angelegt,
bietet sich hier ein kleines Shellskript an, das solche Aufgaben automatisiert -
also ein Projekt-Generator.
Der Administrator der Zelle benutzt tokenmgr, um eine Shell mit Zellensuperuserrechten
zu starten:
root@host>tokenmgr -S admin bash
13 functional Magnetic Resonance Imaging; Funktionale Magnet-Resonanz-Tomographie

7.11 Ein Projekt aus mehreren Volumes 161
7.11.4 Backups
Das Projekt bekommt ein Root-Volume...
root@host>vos create afsserv1 a proj.fmri-1
... plus 2 RO-Instanzen...
admin@afs>vos addsite afsserv1 a proj.fmri-1
admin@afs>vos addsite afsserv2 a proj.fmri-1
Das Projekt wird ins Dateisystem gemountet. Da an dem Projekt gearbeitet
wird, sollte es einen RW-Mountpoint erhalten (siehe 3.2, Seite 32):
admin@afs>fs mkm /a/.projects/fmri-1 -rw
admin@afs>vos release projects
Eine üppige Quota (3GByte) wird vergeben:
root@host>fs sq /a/projects/fmri-1 3000000
Achtung: Es handelt sich dabei nicht um die Quota für Daten der Probanden,
sondern um die Quota des root-Volumes des Projektes.
Speziell für das Projekt werden zur leichteren Administration 14 zwei von ernie
verwaltete PT-Gruppen erstellt:
admin@afs>pts creategroup -name proj.fmri-1.writers -owner ernie
admin@afs>pts creategroup -name proj.fmri-1.readers -owner ernie
... und Rechte für die Mitarbeiter zugewiesen. ernie erhält zusätzlich das a-
Recht (siehe 3.7.3.2, Seite 51), damit er Mountpoints anlegen und ACLs ändern
darf:
admin@afs>fs sa /a/projects/fmri-1 ernie rlwidka proj.fmri-1 rlwidk
Das neue Projektvolume erhält noch etwas Struktur:
root@host>mkdir /a/projects/fmri-1/documents
root@host>mkdir /a/projects/fmri-1/probands
root@host>mkdir /a/projects/fmri-1/scripts
Das Projekt wird ins Backup aufgenommen (siehe 5.2, Seite 100). Dazu wird
folgende Zeilen in die Datei /a/a/etc/backup.conf eingefügt:
proj-fmri - proj\.fmri-1 proj\.fmri-1\.prb\..* Die Volumes
des Projektes werden durch diese Zeile zusammengefasst und können so
leicht dem Backup-System übergeben werden.
Beachten Sie, daß das Backup-System auch angewiesen werden muß, sich der
Volumes des Projektes anzunehmen (siehe 5.2.3.5, Seite 107). Das geschieht in
der Datei /etc/cron.d/instantafs-backup auf dem Backup-Server. Dabei gilt es,
mehrere Fälle zu unterscheiden:
Fall 1 Das Backup-System erfaßt bereits Volumes, die auf eine Weise gesichert
werden, wie man sich das bei den Volumes des Projektes auch wünscht
14 Weiteren Mitarbeitern können auf diese Weise leichter Rechte an dem Projekt zugewiesen wer-
den.

162 7 Rezepte
(z.B: 1x pro Woche full, sonst inkrementell). Die Beispielzeilen
0 30 * * 6 root instantafs.backup -rob /week users cell
0 30 * * 2 root instantafs.backup -ob /week/mo users cell
0 30 * * 3 root instantafs.backup -ob /week/tu users cell
0 30 * * 4 root instantafs.backup -ob /week/we users cell
0 30 * * 5 root instantafs.backup -ob /week/th users cell
müßten dann durch folgende ersetzt werden:
0 30 * * 6 root instantafs.backup -rob /week users cell proj-fmri
0 30 * * 2 root instantafs.backup -ob /week/mo users cell proj-fmri
0 30 * * 3 root instantafs.backup -ob /week/tu users cell proj-fmri
0 30 * * 4 root instantafs.backup -ob /week/we users cell proj-fmri
0 30 * * 5 root instantafs.backup -ob /week/th users cell proj-fmri
Fall 2 Das Backup-System erfaßt noch keine Volumes. Es müssen also neue
instantafs-backup-Aufrufe in /etc/cron.d/instantafs-backup eingetragen
werden:
0 30 * * 6 root instantafs.backup -rob /week users cell proj-fmri
0 30 * * 2 root instantafs.backup -ob /week/mo users cell proj-fmri
0 30 * * 3 root instantafs.backup -ob /week/tu users cell proj-fmri
0 30 * * 4 root instantafs.backup -ob /week/we users cell proj-fmri
0 30 * * 5 root instantafs.backup -ob /week/th users cell proj-fmri
Achtung: Wenn diese Datei noch nicht existiert, ist etwas nicht in Ordnung. Es
könnte sein, daß Sie gerade nicht auf dem wirklich Backup-Server eingeloggt
sind oder aber, daß das Backup-System noch nicht konfiguriert wurde (siehe
5.2.3, Seite 101).
Fall 3 Das Backup-System ist, wie in Beispiel 2 in der Datei /usr/share/doc/instantafsdoc/examples/instantafs-backup.cron
im Paket instantafs-doc .deb beschrieben,
darauf eingestellt, alle Volume-Gruppen in /a/a/etc/backup.conf zu erfassen -
z.B. so:
0 30 * * 6 root instantafs.backup -rob /woche -m
0 30 * * 2 root instantafs.backup -ob /week/mo -m
0 30 * * 3 root instantafs.backup -ob /week/tu -m
0 30 * * 4 root instantafs.backup -ob /week/we -m
0 30 * * 5 root instantafs.backup -ob /week/th -m
7.11.5 Acall-Einstellungen
In diesem Fall ist auf dem Backup-Server nichts mehr zu tun.
Der Benutzer ernie bekommt Rechte zum Ausführen von acall-Kommandos
(siehe 7.6.2, Seite 149) erteilt. Diese Zeile in der Datei /a/a/.etc/acall.access
erlaubt es ernie, über die acall-Schnittstelle Volumes anzulegen (siehe 6.3.2,
Seite 117):

7.11 Ein Projekt aus mehreren Volumes 163
7.11.6 Komfort
root@host>iarel -d /a/a/.etc
# ! / b i n / bash
# Anlegen e i n e s V e r s u c h s p e r s o n e n v o l u m e s
db ernie instantafs.acall-volcreate \S+
Mit der folgenden Konfigurationszeile wird genau definiert, welche Volumes
ernie anlegen darf, auf welchem Rechner sie angelegt werden, welche ACLs
im Root-Verzeichnis des neuen Volumes jeweils gesetzt werden. Ausserdem
wird die Quota für neue Volumes festgelegt (1GByte für jede Versuchsperson)
und eine Backup-Instanz angelegt. Die Zeile muß der Datei /a/a/.etc/acallvolcreate.conf
hinzugefügt werden.
Achtung:Es ist wirklich nur eine Zeile:
s e t −e
VP="$1"
i f ! echo "$VP" | e g r e p −q ’^[0-9][0-9]$’ ; then
echo "E: Bitte nur zweistellige Zahlen als Personen verwenden"
e x i t 1
f i
# Anlegen des neuen Probandenvolumes
i n s t a n t a f s . a c a l l db i n s t a n t a f s . a c a l l −v o l c r e a t e p r o j . fmri −1. prb . $VP
rolocation1=afsserv1.cbs.mpg.de/a,rolocation2=afsserv2.cbs.mpg.de
backup,quota=1000000,acl=ernie;rlwidka;proj.fmri-1.writers;rlwidk
proj.fmri-1.readers;rl
Diese Zeile legt die RW-Instanz jedes Volumes, das per acall von ernie erzeugt
wird, auf dem Server afsserv1.cbs.mpg.de an. Ausserdem werden jeweils RO-
Instanzen auf den Servern afsserv1.cbs.mpg.de und afsserv2.cbs.mpg.de angelegt.
Hinweis: Das Volume, in dem /a/a/.etc liegt, muß danach released werden:
Der User ernie ist sehr bequem und will sich keine komplizierten Kommandos
merken. Deshalb legt der Administrator unter /a/projects/fmri-1/scripts/newvp.sh
ein Skript an, mit dem Probandenvolumes erzeugt werden können:
# Anlegen e i n e s M o u n t p o i n t s im fMRI−1−P r o j e k t v e r z e i c h n i s
f s mkm / a f s / cbs . mpg . de / p r o j e c t s / fmri −1/ p r o b a n d s / $VP p r o j . fmri −1. prb . $VP
echo "I: Das Verzeichnis der neuen Versuchsperson lautet:"
echo "/afs/cbs.mpg.de/projects/fmri-1/probands/$VP"
7.11.7 Tägliche Arbeit mit dem Projekt
Listing 7.2: Das Beispielskript zum Anlegen von Volumes
Alles weitere muß ernie selbst erledigen.
Ein Proband wird im MRT untersucht, seine Daten müssen untergebracht
werden. ernie legt eine neue Versuchsperson an:
ernie@host> /afs/cbs.mpg.de/projects/fmri-1/scripts/newvp 01
I: Das Verzeichnis der neuen Versuchsperson lautet:
/afs/cbs.mpg.de/projects/fmri-1/probands/01

164 7 Rezepte
Die Daten zur Versuchsperson werden in das neue Volume kopiert:
ernie@host> cp -a /tmp/fmri_messdaten/* \
/afs/cbs.mpg.de/projects/fmri-1/probands/01
Je nachdem, in welcher der beiden Projektgruppen Benutzer sind, können sie
nun auf die Daten des Projekts lesend bzw. lesend und schreibend zugreifen.
ernie kann neue Probanden anlegen, löschen kann er sie jedoch nicht. Soll ein
Versuchspersonen–Volume entfernt werden, muß er sich an den Administrator
wenden.
Die Struktur Beispielzelle (siehe 7.1, Seite 140) hat durch das fMRI-Projekt
einige Änderungen erfahren:
Pfad Volume B e s c h r e i b u n g
+ M o u n t p o i n t t y p
Listing 7.3: Volumestruktur im Beispielprojekt
/ a f s r o o t . a f s Das AFS−Root−V e r z e i c h n i s
|− cbs . mpg . de r o o t . c e l l Das Root−V e r z e i c h n i s d e r Z e l l e
| |− p r o j e c t s p r o j e c t s Root−Volume f u e r P r o j e k t e
| | ‘− fmri −1 p r o j . fmri −1 (−rw ) Das Root−Volume des fmri −1−P r o j e k t e s
| | |− documents
| | |− r e s u l t s
| | |− s c r i p t s
| | ‘− p r o b a n d s
| | |− 01 p r o j . fmri −1. prb . 0 1 (−rw ) Datenvolume zu e i n e r V e r s u c h s p e r s o n
| | ‘− 02 p r o j . fmri −1. prb . 0 2 (−rw ) Datenvolume zu e i n e r a n d e r e n VP .
| |− . p r o j e c t s p r o j e c t s (−rw )
| ‘− . . .
‘− . . .
ernie kann jederzeit neue Mitglieder in die PT-Gruppen des Projektes aufnehmen.
Mit folgendem Befehl erhält z.B. kermit Schreibrechte:
root@host>pts add kermit proj.fmri-1.writers
Soll z.B. bert ausgeschlossen werden, ist folgendes einzugeben:
root@host>pts remove bert proj.fmri-1.writers
7.12 Ein Debian-Server für Instantafs
Bert würde seine Rechte u.U. jedoch nicht sofort verlieren (siehe 3.7.3.4, Seite
54).
Es ist sinnvoll, alle Pakete, die für InstantAFS zusätzlich zu den original-
Debian-Paketen benötigt werden, auf einen Server zu legen, so dass man auf
den zu installierenden Rechnern bequem mit apt-get arbeiten kann. Dazu ist
folgendes zu tun:
root@host>apt-get install apt-utils
1. Man wählt einen Rechner als Paketserver aus - dieser sollte später kein
AFS-Server der Zelle werden. Im Beispiel heisst er debserv.cbs.mpg.de
2. Im InstantAFS-Wiki ist beschrieben, wo man die Pakete herunterladen
kann.
3. Man sollte die ganze Verzeichnisstruktur in ein Verzeichnis ablegen. Beispiel:
/DEBSERV/instantafs-pakete
4. Auf dem Paketserver wird das Paket apt-utils .deb benötigt.

7.13 Automatische Client-Installation mit instantafs-customclient 165
5. Für die InstantAFS-Pakete müssen das Packages- und das Sources-File
erzeugt werden:
root@host>cd /DEBSERV/instantafs-pakete
root@host>apt-ftparchive packages . | tee Packages | gzip Packages.gz
root@host>apt-ftparchive sources . | tee Sources | gzip Sources.gz
6. Ein FTP-Server stellt dann das /DEBSERV-Verzeichnis zur Verfügung.
Dafür eignet sich z.B. proftpd .deb . Ein HTTP-Server (z.B. apache .deb )
geht auch - dann müssen jedoch die URLs der sources.list-Einträge entsprechend
angepaßt werden.
7. Auf jedem Rechner, auf dem man InstantAFS-Pakete von diesem
Debian-Server installieren will, müssen noch diese beiden Zeilen an die
Datei /etc/apt/sources.list angefügt werden:
deb ftp://debserv.cbs.mpg.de/instantafs-pakete/ /
deb-src ftp://debserv.cbs.mpg.de/instantafs-pakete/ /
root@host>apt-get update
8. Schliesslich zieht man sich die Paketliste auf den Rechner:
7.13 Automatische Client-Installation mit instantafs-customclient
Das Paket instantafs-customclient .deb kann verwendet werden, um ein beliebig
großes Netzwerk von Computern AFS-ready zu machen. So funktioniert
es:
1. Während einer InstantAFS-Installation (siehe 4.3, Seite 69) werden die
Parameter der neuen Zelle als XML-File gespeichert. Das geht mit dem
instantafs.setup-Menüpunkt write-config. Beachten Sie, dass dabei
2 Dateien geschrieben werden. Für instantafs.customclient .deb ist
die Datei mit der Endung .public 15 wichtig. Im folgenden wird angenommen,
dass die Datei instantafs.xml gespeichert wurde - es wird also die
Datei instantafs.xml.public benötigt.
2. Beachten Sie, dass unter dem Menüpunkt ccoptions die Möglichkeit
besteht, das Paket instanafs-customclient .deb zu steuern. In dem erscheinenden
Untermenü lassen sich folgende Flags setzen:
afsclient : Diese Option steuert, ob der AFS-Cachemanager konfiguriert und
gestartet werden soll.
dns : Wenn diese Option aktiviert ist, modifiziert das Paket
instantafs-customclient .deb die Datei /etc/resolv.conf und trägt in
diese die gewählten DNS-Server ein.
ntp : Wenn diese Optione ausgewählt ist, wird der NTP-Client auf AFS-
Clients automatisch eingerichtet.
krb5client : Diese Option steuert, ob die Datei /etc/krb5.conf modifiziert werden
soll. Das Sollte praktisch niemals nötig sein - aber man weiss ja nie.
nss_host : steuert, ob die host-Zeile in /etc/nsswitch.conf modifiziert werden
soll.
15 Also die Datei, in der keine hochgeheimen Informationen über die Zelle stehen.

166 7 Rezepte
Ist die Option gesetzt, wird DNS als host-Namensdienst eingetragen.
Ist sie es nicht, wird nichts verändert, was z.B. dann sinnvoll
ist, wenn host-Lookups per NIS oder LDAP durchgeführt werden
sollen.
nss_passwd : steuert, ob die passwd-Zeile in /etc/nsswitch.conf modifiziert
werden soll.
Das ist z.B. dann sinnvoll, wenn auf den reinen AFS-Client-
Computer der Zelle ein anderer Benutzer-Namensdienst eingesetzt
werden soll (z.B. LDAP oder NIS). Ist die Option gesetzt, aktiviert
instantafs-customclient .deb libnss-ptdb .deb zur Namensauflösung.
nss_justadd : steuert, ob die InstantAFS-default-Namensdienste (host:dns und
passwd:ptdb) nur zu bereits definierten Namensdiensten hinzugefügt
werden sollen. Das ist sinnvoll, wenn ein Netzwerk z.B.
langsam von NIS/NFS auf AFS migriert werden soll - “Legacy”-
Nutzer können sich so weiterhin anmelden, neu hinzukommende
AFS-Nutzer jedoch auch.
Alle Optionen werden in dem Konfigurations-XML-File gespeichert.
3. Jetzt gibt’s 2 Möglichkeiten:
HTTP : Man kann die Datei instantafs.xml.public auf einen Webserver
legen, so dass sie unter der URL
http://instantafs-config/instantafs.xml.public.
net erreichbar ist.
Eigenes Paket : Man kann instantafs.xml.public auch direkt in das instantafscustomclient
.deb -Paket packen. Unter 7.14.1 ist erklärt, wie das
geht.
4. Auf den Clients installiert man nun das Paket:
root@host>apt-get install instantafs-customclient
5. Je nachdem, ob das Konfigurationsfile im Paket enthalten ist oder nicht,
versucht instantafs-customclient .deb , die Konfiguration jetzt per wget
vom Webserver zu laden.
6. Manchmal 16 ist jetzt noch ein Neustart auf dem Client fällig.
7.14 Schutz des AFS-Keys mit Echtzeitverschlüsselung
Ist man im Besitz des AFS-Schlüssels, kann man alle Server der Zelle kontrollieren.
Natürlich kann man die Server gegen diverse Angriffsszenarien schützen.
Wenn jedoch ein Server nicht verschlossen in einem Serverraum steht - besteht
die Gefahr, dass durch Diebstahl oder unbemerktes Boot-CD-Starten der
AFS-Schlüssel kompromitiert wird. Dagegen hilft nur Echtzeitverschlüsselung
des Filesystems, auf dem der Schlüssel liegt.
Das Paket instantafs-cryptofs .deb bietet eine komfortable Möglichkeit, kritische
Daten auf AFS-Server zu sichern. Dabei werden Verzeichnisse durch sog.
bind-Mounts auf ein verschlüsseltes Filesystem umgebogen:
/etc/openafs/server : In diesem Verzeichnis liegt der AFS-Zellenschlüssel KeyFile.
16 wenn der AFS-Cachemanager vorher lief und nicht korrekt heruntergefahren werden kann

7.14 Schutz des AFS-Keys mit Echtzeitverschlüsselung 167
/var/lib/krb5kdc : In diesem Verzeichnis liegt auf AFS-DB-Servern üblicherweise die
Kerberos-Datenbank.
/vicepz : Dieses Verzeichnis stellt später eine verschlüsselte AFS-Datenpartition
zur Verfügung. Hier können also auf einem AFS-Fileserver Instanzen von
Volumes mit extrem kritischen Daten (z.B. das Volume a.etc.secret) abgelegt
werden.
Das erwartet den Administrator eines mit instantafs-cryptofs .deb gesicherten
Servers:
1. Der Rechner wird eingeschaltet (oder neu gestartet)
2. InstantAFS-CryptoFS meldet sich mit einem Prompt, hier muss das
Passwort eingegeben werden. Alternativ kann auch eine Floppy benutzt
werden (Details dazu gibt’s weiter unten). I.d.R. sorgt ein timeout (einzustellen
in /etc/default/instantafs-cryptofs dafür, dass nach einer gewissen
Zeit ohne Crypto-Filesystem weitergebootet wird.
3. instantafs.cryptofs setzt ein verschlüsselndes Loopback-Device ( /dev/loop0
auf und mounted das verschlüsselte Image in der Datei /var/lib/instantafs/cryptofs/image
unter /var/lib/instantafs/cryptofs/mnt.
4. An die geschützten Pfade werden anschliessend die entsprechenden Unterverzeichnisse
aus dem verschlüsselten Filesystem gemountet.
5. Wurden alle geschützten Pfade erfolgreich gemountet, wird die Datei
/var/lib/instantafs/cryptofs/ok erzeugt - andernfalls wird sie entfernt. Die
Existens dieser Datei signalisiert später bestimmten Anwendungen, dass
sie sicher starten können.
6. Die init.d-Start-Skripte der Pakete openafs-fileserver .deb , krb5-kdc .deb
und krb5-admin-server .deb werden aufgerufen, überprüfen die Existenz
von /var/lib/instantafs/cryptofs/ok und starten bei Erfolg die jeweiligen
Original-init.d-Skripte um den jeweiligen Dienst hochzufahren.
Das ganze Procedure ist nötig, um die Dienste am Starten zu hindern,
wenn das Crypto-Filesystem nicht gestartet wurde/werden konnte.
So setzt man instantafs-cryptofs .deb auf:
1. Das Paket muss mit
root@host>apt-get install instantafs-cryptofs
installiert werden.
2. Mit folgendem Kommando wird das instantafs-cryptofs .deb initialisiert:
root@host>instantafs.cryptofs - -mount - -init
Man wird hier zur Eingabe eines Passwortes aufgefordert. Dieses sollte
durchaus 50 Zeichen lang und mit Zahlen, Gross-/ Kleinschreibung und
Sonderzeichen gespickt sein.
Hinweise:
• Komfortabel ist, das Passwort in eine Datei (als eine Zeile) zu
schreiben und diese Datei auf eine msdos-formatierte Diskette zu
speichern. Die Datei muss auf der Diskette iacrypto heissen. Wenn
man nun nach einem Passwort gefragt wird, drückt man einfach
Return und folgt den Anweisungen.
• Eine solche Diskette ist sehr wertvoll. Man sollte mindests 2 identische
davon haben. Auch könnte es hilfreich sein, dass Passwort in

168 7 Rezepte
ausgedruckter Form zu haben.
• Passwort/Diskette sollte(n) an einer Stelle gelagert werden, an die
man nicht so leicht herankommt - ein Tresor z.B.
• Den Schlüssel zu einem Tresor kann man verlegen - eine zweite
Lagerstätte für Diskette/Passwort ist zu empfehlen - z.B. ein zweiter
Tresor.
3. Wenn das geklappt hat, sollte man jetzt, das verschlüsselnde Filesystem
erst einmal wieder abschalten:
root@host>instantafs.cryptofs - -umount
root@host>instantafs.cryptofs - -mount
7.14.1 InstantAFS neu paketieren
, die Verzeichnisse /etc/openafs/server und /var/lib/krb5kdc löschen und
anschliessend das verschlüsselte Dateisystem wieder starten:
4. Durch Ändern der Zeile ENABLED=”no” in ENABLED=”yes” wird
das verschlüsselnde Filesystem bei jedem Systemstart hochgefahren.
Ziele der Verschlüsselung:
• Der Diebstahl eines Servers soll sich nicht auf die Sicherheit aller Daten
der Zelle auswirken können. Der AFS-Schlüssel und die Kerberos-
Datenbank sind die Daten auf AFS-Servern, die ohne Verschlüsselung
auf einem entwendeten Server Superuserrechte in der betroffenen Zelle
bringen würden.
• Auch eine Echtzeitverschlüsselung kann nicht vor lokalen Angriffen (z.B.
durch Hardware-Keylogger) schützen.
• Die Verschlüsselung soll (und kann) nicht vor Angriffen über das Netzwerk
auf den laufenden Rechner schützten - schliesslich ist das verschlüsselte
Filesystem im laufenden Betrieb einfach kopierbar.
Haben sie die InstantAFS-Pakete bereits auf einem Paketserver liegen (siehe
7.12, Seite 164) und diesen in die lokale /etc/apt/sources.list-Datei eingetragen,
wechselt man in ein leeres Verzeichnis und gibt ein:
root@host>apt-get source instantafs
Ein einzelnes Verzeichnis instantafs- sollte entstanden sein.
In dieses Verzeichnis kopiert man die Konfigurationsdatei - sie muß dann instantafs.xml.public
heißen. Ändern sie jetzt noch folgende Daten des Paketes:
Versionsnummer : Damit das Paket möglichst unverwechselbar ist, sollte es eine eindeutige
Versionskennung (zu finden in der Datei debian/changelog) bekommen.
Beispiel: Die aktuelle Version (siehe erste Zeile) sei 1:0.9.7-2 und die
neue Zelle soll eva.mpg.de heißen. Die Versionskennung 1:0.9.7-2+eva
bietet sich an.
Maintainer : Das selbstgepackt Paket sollte auf irgendeine Weise darauf hinweisen,
wer es gepackt hat. Dazu trägt man in die Datei debian/control in der 4.
Zeile und in der Datei debian/changelog in der ersten Zeile, die mit “
- -” beginnt, die eigene eMail-Adresse ein.

7.15 Daten über die Zelle zentral sammeln 169
InstantAFS benötigt u.U. noch einige Pakete, um gepackt werden zu können:
root@host>apt-get build-dep instantafs dpkg-dev fakeroot
Jetzt kann das neue InstantAFS-Paket gepackt werden:
root@host>dpkg-buildpackage -rfakeroot
7.15 Daten über die Zelle zentral sammeln
7.15.1 Punkt oder nicht
Die neu entstandenen Dateien werden zusätzlich auf den eigene Paketserver
gelegt und die Paketlisten neu gescannt - evtl. hilft die Beschreibung unter 7.12
auf Seite 164).
Viele InstantAFS-Programme benötigen Informationen über die AFS-Zelle
(Volumes, TapeController, ...). Natürlich können solche Informationen sobald
sie gebraucht werden direkt von den AFS-Servern eingelesen werden.
Es geht jedoch eleganter. instantafs.vsserver (siehe 9.2.27, Seite 205) liesst
alle Daten über die Zelle regelmäßig per default aller 7 Minuten ein und legt
sie in einem komprimierten XML-File unter /a/a/.cellinfo ab - ein Pfad, der per
default in dem Volume a.cellinfo liegt.
Benötigt ein Programm nun Informationen über die Zelle, kann es dieses komprimierte
XML-File einlesen. Die Daten werden aus einer Quelle gelesen, die
durch RO-Replikation auch auf mehreren Rechnern liegen kann. Ist ein Fileserver
ausgefallen, so ist das in dem XML-File vermerkt - das interessierte Programm
muß nicht die potentiell langen Timeouts der volserver-Anfragen abwarten.
Der Geschwindigkeitsvorteil kann dabei durchaus mehrere Größenordnungen
betragen.
Russ Allbery setzt ein ähnliches Verfahren ein, um Informationen über Volumes
zentral zu sammeln, jedoch mit einigen Unterschieden zur InstantAFS- Lösung:
• Die Daten werden in einer SQL-Datenbank und nicht als XML-File gespeichert.
• Die InstantAFS-Lösung ist eher als Allheilmittel zur Geschwindigkeitssteigerung
(vor allem bei Serverausfällen) gedacht, wohingegen Russ Allbery’s
Methode wohl primär für statistische Auswertungen gedacht ist.
• Alle Daten im InstantAFS-XML-File enthalten einen Zeitstempel, um zu
definieren, ob und wann sie aus der Zelle ausgelesen wurden.
Mehr Informationen gibt’s hier:
http://www.eyrie.org/~eagle/notes/afs/afsdb.html
Per default legt instantafs.vsserver das XML-file in /a/a/.cellinfo ab, wohingegen
Programme, die libafs-instant benutzen, auf /a/a/cellinfo zugreifen.
Hintergedanke dieses Unterschiedes ist, dass es von Vorteil sein kann, das
XML- File auf mehreren Servern abzulegen, wenn es z.B. eine langsam
angebundene Außenstelle gibt, in der auch InstantAFS-Skripte arbeiten.
instantafs.vsserver würde dann das a.cellinfo-Volume regelmäßig in die
Aussenstelle replizieren und die Clients dort auch auf diese Kopie zugreifen.
Gibt es nur ein schnelles lokales Netz, kann man auf die RO-Replikation verzichten.

170 7 Rezepte
7.16 Schnelles Kopieren eines Volumes
Der Pfad /a/a/cellinfo kann so entweder in eine RO-Instanz oder direkt in die
RW-Instanz von a.cellinfo führen, ohne dass die Zugriffe des instantafs.vsserver
auf /a/a/.cellinfo beeinträchtigt werden.
Gelegentlich ist es nötig, eine Instanz komplett von A nach B zu kopieren, wobei
die neue Instanz jedoch nicht von der alten abhängig 17 sein soll. Im klassischen
AFS kommt nun vos dump | vos restore zum, Einsatz, wobei
die Daten jedoch 2 Mal 18 über’s Netzwerk geschickt werden. Seit OpenAFS 1.3
existiert ein Kommando, was die selbe Funktionalität bietet, den Quellfileserver
jedoch anweist, die Daten direkt zum Zielfileserver zu schicken.
So funktioniert’s:
admin@afs> vos copy Quellvolume Quellserver Quellpartition\
Zielvolume Zielserver Zielpartition
7.17 Eine komplette AFS-Partition mit allen Volume-Instanzen verschieben
7.17.1 AFS-Boardmittel
Dafür gibt es mehrere Möglichkeiten - welche davon am günstigen ist, muss
jeder selbst entscheiden. Partition kann man dabei immer auch auf mehrere Partitionen
beziehen.
Wenn man Zeit hat - z.B. weil der Server in absehbarer Zeit zugunsten eines
neuen ausser Dienst gestellt werden soll - kann man einfach alle RW-Instanzen
mit vos move verschieben und die vorhandenen RO-/Backup-Instanze neu
anlegen. Dafür kann man auch folgenden Befehl benutzen:
admin@afs>iat evacuate Quellserver/Quellpartition Zielserver/Zielpartition
7.17.2 Speichersubsystem umbauen
Vorteil: Es gibt praktisch keine Unterbrechung (abgesehen von der Zeit für’s
erstellen der Move-Clone-Instanzen) für die Nutzer der Zelle.
Nachteil: Es dauert sehr lange, da eine kryptografisch gesichert Übertragung
zwischen den Fileservern statfindet.
Man kann einfach das Speichersubsystem vom alten Server abkoppeln und an
den neuen Server anschliessen. Das sorgt zwar für eine merkliche Unterbrechung
für Nutzer (es seie denn, es steht ein Wartungsinterval - z.B. Nachts - zur
Verfügung). So muss das ablaufen:
1. Neuen Fileserver einrichten (siehe 6.4, Seite 118).
2. AFS-Fileserver auf dem alten Server abschalten:
admin@afs>bos stop Alter Servername fs
3. Speichersubsystem abkoppeln. Je nach Speichersystem ist ein Neustart
dafür nötig.
17 Es soll also keine RO-Instanz des alten sein
18 Quellfileserver ⇒ vos dump , vos restore ⇒ Zielfileserver

7.17 Eine komplette AFS-Partition mit allen Volume-Instanzen verschieben 171
4. AFS-Fileserver auf dem alten Server wieder hochfahren:
admin@afs>bos start Alter Servername fs
5. Volume-Instanzen auf der verschobenen Partition aus der VLDB abmelden:
admin@afs>vos syncvldb Alter Servername
6. Alten Server endgültig stillegen.
7. Speichersystem an den neuen Server anschliessen
8. AFS-Fileserver auf dem neuen Server starten:
admin@afs>bos startup fs Neuer Servername
9. Volume-Instanzen in der VLDB registrieren:
admin@afs>vos syncvldb Neuer Servername
7.17.3 Manuelles Kopieren auf Dateiebene
Vorteil: Die nötige Zeit zum Verschieben aller Instanzen ist nicht von Speichermenge
oder Anzahl der Instanzen abhängig - O(1) .
Nachteil: Wenn man schnell ist und das Speichersubsystem ohne Neustart einund
ausbaubar ist, kann man die Ausfallzeit im Sekundenbereich halten. Eine
gewisse Ausfallzeit ist jedoch vorhanden.
Die hier beschriebene Methode kann bei Unachtsamkeit leicht schiefgehen, jedoch
bemerkt man das sofort und kann sie beliebig wiederholen oder auch zu
einer anderen Methode greifen.
Der Namei-Fileserver (siehe 3.8.2.2, Seite 58) legt seine Daten als einfache Dateien
ins Wirtsfilesystem, was es ermöglicht, einfach den ganzen Dateibaum
der Wirtspartition zu kopieren. Dabei muss man jedoch aufpassen, dass auch
die Standard-Metadaten der Dateien (Eigentümer, Gruppe, Modebits, Zugriffszeiten)
exakt kopiert werden - ansonsten droht Datenkorruption.
So geht’s:
1. Fileserver herunterfahren:
admin@afs>bos stop Fileserver fs
2. Kopieren der Daten auf eine neue Partition - z.B. so:
root@host>cd /vicepa tar -S -p - -atime-preserve - -numeric-owner -c | \
( cd /vicepb && tar x )
3. Die alte Partition muss jetzt unbedingt geummounted oder anderweitig
aus dem Einflussbereich des AFS-Fileservers entfernt werden. Macht
man das nicht, kommt die VLDB durcheinander.
4. Fileserver hochfahren:
admin@afs>bos start Fileserver fs
admin@afs>vos syncvldb Fileserver
5. Liegen die Daten danach nicht mehr auf der selben /vicep - Partition,
muss die VLDB davon unterrichtet werden:

172 7 Rezepte
7.18 AFS schneller machen
7.18.1 Fileserver
7.19 AFS-Clients finden
Vorteil: Effizientes Kopieren ist innerhalb eines Server möglich - z.B. um eine
laut S.M.A.R.T. defekte Festplatte auszutauschen.
Nachteil: Die Instanzen auf der bearbeiteten Platte sind für einige Zeit nicht
benutzbar. Diese Zeit ist von der Datenmenge und der Anzahl der Dateien in
den einzelnen Volume-Instanzen abhängig.
Sven Oehme schlägt folgende Einstellungen vor, um die Performance - vor allem
in schnellen Netzen - zu verbessern:
fileserver : -nojumbo -L -rxpck 400 -udpsize 1310720
volserver : -nojumbo -log -udpsize 1310720
Jim Rees nutzt etwas andere Parameter für den Fileserver:
-L -p 92 -rxpck 2400 -udpsize 524288 -l 1000 -s 1000
-vc 1000 -nojumbo
Die Einstellungen müssen ins bos-Konfigurationsfile /etc/openafs/BosConfig
hinter die entsprechenden bnode-Kommandos geschrieben werden.
Gelegentlich ist es von Interesse, herrauszufinden, welche Clients Teil der eigenen
Zelle sind. Es gibt dafür keine Patenlösung, aber zwei brauchbare Ansätze:
• Man kann die Serverlogs auf Fileservern auswerten. Dazu muss man den
Loglevel etwas erhöhen und (siehe 6.10.1.2, Seite 126) und die Datei
/var/log/openafs/FileLog nach Client-Adressen Filtern.
• Der zweite Ansatz ist, das eigene Netzwerk nach AFS-Client-Prozessen
zu scannen. Dazu kann man rxdebug benutzen - z.B. so:
user@host>for((host=1;host /dev/null && echo $ip;done
Hinweis:Mit dem Parameter -version kann man per rxdebug sogar
die benutzte AFS-Version herrausfinden.

8 Problembehebung
8.1 Fehlermeldungen
8.2 Fehler mit tokenmgr, kinit oder aklog
8.2.1 aklog: Request is a replay while getting AFS tickets
AFS ist ein komplexes System. In diesem Kapitel werden die Probleme, die
beim Autor dieses Dokuments aufgetreten sind, mit den entsprechenden Lösungsvorschlägen
verewigt. Wenn bei ihnen ein hier nicht aufgeführtes Problem
auftreten sollte, schicken Sie bitte eine Mail mit einer möglichst genauen
Beschreibung an burk[at]cbs.mpg.de. Ziel dabei ist, ein möglichst vollständiges
FAQ zu allen möglichen Fehlfunktionen/Eigenheiten von AFS aufzubauen.
Unabhängig davon existieren unter http://www.openafs.org einige
Mailinglisten (English is spoken...), auf denen AFS-Nutzer und Entwickler
miteinander kommunizieren. Kann diese Dokumentation nicht weiterhelfen,
sind diese Mailinglisten die erste Adresse, die man aufsuchen sollte.
Wer Echtzeitkommunikation bevorzugt, kann sich auch in einen IRC-Channel
begeben - z.B #openafs im Freenode-Netzwerk ( siehe http://www.
freenode.net ).
Probleme mit Anwendungsprogrammen, die sich an den Besonderheiten von
AFS stossen, sind der größeren Flexibilität halber auf einer Wiki-Seite aufgeführt:
http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/
ProgsHateAfs
Hier ist eine Liste von Fehlermeldungen, jeweils mit Hinweisen, was genau
schief läuft und wo man Hilfe findet.
8.1.0.0.3 afs: Lost contact with file server 127.0.0.1 in cell [...] Das liegt
an falsch konfigurierter Libc-Host-Namensauflösung (siehe 8.11, Seite 190) .
8.1.0.0.4 kernel: afs_NewVCache: warning none freed, using 3600 of 3600
Es sind zu viele Dateien im AFS auf dem lokalen Rechner gleichzeitig geöffnet
(siehe 8.4.1, Seite 176).
Die Replay-Erkennung des Kerberos hat angeschlagen. Die Replay-Erkennung
sorgt dafür, dass der Kerberos-Server keine 2 Anfragen nacheinander akzeptiert,
die exakt gleich sind. Exakt gleich heisst z.B., dass das gleiche Ticket für
den selben Principal zur selben Sekunde angefordert wird. Das ist eine Schutzmassnahme
gegen sogenannte Replay-Angriffe.
Vermutlich haben in diesem Fall 2 Prozesse zum exakt gleichen Zeitpunkt eine
Anfrage an den selben Kerberos-Server gerichtet. Das kann z.B. durch zwei
cron-Jobs passieren:
173

174 8 Problembehebung
root@host>cat /etc/instantafs/ernies_job
0 1 * * * ernie tokenmgr -S ernie -k /etc/instantafs/ernie - - test
0 1 * * * ernie tokenmgr -S ernie -k /etc/instantafs/ernie - - echo toast
Beide Jobs würden immer 01:00 nachts ausgeführt. Mit einer gewissen Wahrscheinlichkeit
(es wird nicht immer passieren), werden die entsprechenden
Kerberos-Tickets zur gleichen Zeit angefordert. Abhilfe läßt sich durch einen
leichten zeitlichen Versatz schaffen:
root@host>cat /etc/instantafs/ernies_job
0 1 * * * ernie tokenmgr -S ernie -k /etc/instantafs/ernie - - test
1 1 * * * ernie tokenmgr -S ernie -k /etc/instantafs/ernie - - echo toast
Der zweite Job startet nun eine Minute später.
8.3 vos, pts oder bos liefern Fehlermeldungen
8.3.1 u: no quorum elected
8.3.2 u: not synchronization site (should work on sync site)
Hier sind einige Fehlermeldungen der diversen AFS-Kommandos und Möglichkeiten
der Beseitigung aufgeführt.
Die Meldung bedeutet, dass die DB-Server der Zelle noch nicht abschließend
geklärt haben, welche Server verfügbar sind. Das ist ein DB-Server-Problem
(siehe 8.7.2, Seite 185).
Diese Fehlermeldung deutet darauf hin, dass z.B. vos nicht die korrekte Liste
der Datenbankserver benutzt. Man sollte in diesem Fall folgendes überprüfen:
user@host>bos listhosts Servername
• Die Datei /etc/openafs/CellServDB überprüfen.
Hinweis: InstantAFS benutzt das DNS, um die Liste der Datebankserver
den AFS-Clients bekannt zu machen. In diesem Fall muss /etc/openafs/-
CellServDB eine leere Datei sein.
• Die Datei /etc/openafs/server/CellServDB auf allen beteiligten Servern
(im Zweifelsfall auf allen AFS-Servern der Zelle).
Hinweis: Man kann das mit folgendem Kommando (für jeden Server
einmal ausführen) auch über das Netzwerk machen:
8.3.3 vsu_ClientInit: Could not get afs tokens, running unauthenticated.
vos gibt diese Meldung aus, wenn kein Token im Kernel gespeichert ist. Ob
ein Token vorhanden ist, kann mit dem Kommando tokens überprüft werden.
Ohne Token können einige vos-Unterkommandos nicht benutzt werden. Es
gibt zwei Möglichkeiten, dieses Kommando ohne ein Token zu benutzen:
• Wird das Kommando als root auf einem AFS-Server ausgeführt, kann
man mit dem Parameter -localauth dafür sorgen, dass der auf
dem Server gespeicherte Zellenschlüssel (/etc/openafs/server/KeyFile)
verwendet wird, um mit Superuserrechten auf den entfernten Server
zuzugreifen.
• Um die Warnung zu vermeiden und einfach anonym auf den entfernten
Server zuzugreifen, kann man die Option -noauth benutzen.

8.3 vos, pts oder bos liefern Fehlermeldungen 175
8.3.4 bos: failed to [...] (you are not authorized for this operation)
Ursache und Lösung dieses Problems die selben, wie bei der vorherigen Fehlerbeschreibung.
8.3.5 libprot: no such entry Could not get afs tokens, running unauthenticated.
8.3.6 pts: Permission denied [...]
Diese Meldung gibt pts aus, wenn kein Token im Kernel gespeichert ist. Man
sollte sich in diesem Fall mit tokenmgr -l ein Token besorgen. Im Gegensatz
zu vos und bos kennt pts jedoch die -localauth-Option nicht.
Die Checkliste:
user@host>tokenmgr -l Benutzername
1. Ist überhaupt ein gültiges Token vorhanden? Einige Funktionen der
PTDB können nur von bestimmten Benutzern (also nicht anonym) aufgerufen
werden. Stellen Sie sicher, dass ein gültiges Token vorhanden
ist. Mit folgendem Kommando geht das:
also z.B.
ernie@afsclient> tokenmgr -l ernie
für den Benutzer ernie.
2. Einige pts-Unterkommandos (z.B. pts listentries) können nur
von Superusern (siehe 3.7.5, Seite 54) benutzt werden. Superuser sind
für den ptserver die Mitglieder der Gruppe system:administrators.
Hinweise:
• pts kennt die -localauth-Option nicht, die bei anderen AFS-
Kommandos dafür sorgt, dass man ohne Token arbeiten kann.
• Der Principal acall ist in einer InstantAFS-Zelle mit genug Macht
ausgestattet, um alle PTDB-Kommandos auszuführen. Auf dem
ersten AFS-DB-Server der Zelle liegt die keytab von acall. Soll ein
pts-Unterkommando mit Superuserrechten ausgeführt werden,
geht das wie folgt:
root@host>tokenmgr -S acall -k /etc/instantafs/acall.keytab - - pts
Unterkommando Optionen
8.3.7 VLDB: no permission access for call
8.3.8 Failed to move data for the volume [...]
Manche vos-Unterkommandos können nur von Superusern benutzt werden.
Die Definition von “Superuser” ist äquivalent zu der in der vorhergehenden
Fehlerbeschreibung.
Wenn das vos move -Kommando fehlschlägt, kann das an folgendem liegen:
Inkosistente Quellinstanz In diesem Fall hilft es meist weiter, per bos salvage die Quellpartition
zu bearbeiten.
Quota-Überschreitung Wenn die ursprüngliche Volume-Instanz auf dem Quellserver over-Quota
ist, versagt vos move. Lösung: Zuerst die Quota erhöhen, dann verschieben.

176 8 Problembehebung
8.3.9 Could not remove server [...] from the VLDB
Wenn ein Fileserver aus der VLDB entfernt werden soll, dürfen ihm keine
Volume-Instanzen mehr zugeordnet sein. Um zu sehen, welche Instanzen dem
Fileserver noch zugeordnet sind, hilft folgender Befehl:
user@host>vos listvl -server Servername
8.4 Probleme im AFS-Dateisystem (AFS-Client)
8.4.1 Zu viele AFS-Dateien sind auf einer Maschine geöffnet
Anschliessend kann man mit vos remsite, vos remove bzw. vos
delentry der entsprechenden Volume-Instanz zuleibe rücken.
Abhilfe schafft hier das erhöhen des -stat -Parameters des Unix-AFS-Clients.
Unter Debian geht das in /etc/openafs/afs.conf, unter MacOSX in /var/db/openafs/etc/config/afsd.options.
8.4.2 In einem Verzeichnis lassen sich keine weiteren Dateien anlegen.
8.4.2.1 Erklärung
8.4.2.2 Lösung
8.4.3 Clientseitig ist kein Zugriff auf /afs möglich
Wenn sich aus mysterioesem Grund in einem Verzeichnis keine weiteren
Dateien oder Verzeichnisse anlegen lassen, liegt das u.U. daran, dass man das
Verzeichniseinträge-Limit erreicht hat.
AFS-Verzeichnisse besitzen maximal 64436 Slots, in die man Verzeichniseinträge
(also Dateien oder Unterverzeichnisse) ablegen kann. Diese Beschränkung
ist im AFS-Protokoll verankert und nicht direkt ein OpenAFS-Problem.
Ein Verzeichniseintrag verbraucht mindestens einen Slot - wenn er maximal 15
Zeichen lang ist. Ist der Dateiname länger, verbraucht er weitere Slots (einen
für weitere angerissene 16 Zeichen), wobei sich die Anzahl der maximalen verzeichniseinträge
reduziert.
Alle Slots, die ein Eintrag einnimmt, müssen zusammenhängen. Es existiert
leider kein Defragmentierungsprozess, der dafür sorgen könnte. Wenn man also
oft Lange Dateieinträge anlegt und löscht, kann das die Fragmentierung neue
verzeichniseinträge mit >15 Zeichen komplett verhindern.
Wenn ein solcher Fehler auftritt, muss das Verzeichnis schon sehr viele Dateien
enthalten. Man sollte zuerst einmal über die Struktur des eigenen Filesystems
nachdenken - es sollte eher tief als flach sein. Kurzfristig hilft es auch, die Dateien/Verzeichnisse
in ein anderes Directory zu verschieben und das andere Directory
dann zum ursprünglichen umzubenennen.
Die Fehlermeldungen des Clients werden ins Syslog (/var/log/syslog) geschrieben.
Dort finden man oft wichtige Hinweise. Einige davon sind hier beschrieben:
• afs: Lost contact with file server 10.0.0.10 in
cell cbs.mpg.de (all multi-homed ip addresses down
for the server)

8.4 Probleme im AFS-Dateisystem (AFS-Client) 177
user@host>tokenmgr -r
Diese Zeile deutet an, dass der Kontakt zu einem AFS-Fileserver abgerissen
ist bzw. nicht hergestellt werden kann. Folgende Ursachen sind
denkbar:
– Generelles Netzwerkproblem auf dem Client oder auf dem Server
(Netzwerkkarte kaputt, Netzwerkkabel nicht eingesteckt, Switch/Hub
ausgefallen, Routing-Problem).
– Der Server ist ausgefallen oder abgeschaltet.
– Softwareproblem auf dem Fileserver (siehe 8.5.1, Seite 179).
– Eine Firewall zwischen Client und Server filtert AFS-Traffic (siehe
3.6, Seite 44).
Hinweis: Den Kontakt zu einem AFS-Server zu verlieren heißt, dass der
fileserver-Prozess auf der Maschine nicht kontaktiert werden kann
- also dass die Anfragen an den UDP-Port 7000 dieser Maschine nicht
beantwortet werden.
• afs: Lost contact with volume location server 10.0.0.5
in cell cbs.mpg.de
Die Zeile zeigt an, dass einer der Datenbankserver nicht erreichbar ist.
Die Ursachen dafür sind ähnlich denen, die zu Kommunikationsproblemen
mit dem Fileserver führen. Folgende Szenarien sind denkbar:
– Ein Netzwerkproblem verhindert die Kommunikation mit dem DB-
Server.
– Der entsprechende DB-Server ist ausgefallen.
– Es laufen nicht alle nötigen Prozesse auf dem DB-Server (siehe
8.7.1, Seite 184).
• kernel: afs: Tokens for user of AFS id 1000 for
cell test.cbs.mpg.de are discarded (rxkad error=19270405)
Diese Zeile weist darauf hin, dass ein Fileserver den Token eines Benutzers
(hier mit der AFS-ID 1000), der am lokalen Rechner arbeitet,
zurückgewiesen hat. Einer der folgenden Gründe ist meist dafür verantwortlich:
– Der Token des Benutzers ist ganz normal abgelaufen. Das passiert
z.B., wenn ein Batch-Job zulange läuft und vergessen wird, das Token
regelmäßig zu erneuern. Abhilfe schafft dafür das Kommando
(siehe auch “Einführung in die Benutzung von AFS an der MPG”,
3.2. Batch-Jobs).
– Die Uhren der Zelle laufen nicht synchron. Überprüfen Sie die
Zeit auf den DB-Servern (eigentlich auf den Kerberos-Servern, bei
Benutzung von InstantAFS sind Kerberos- und DB-Server jedoch
gleich), auf dem Fileserver, auf den gerade zugegriffen werden
sollte und auf dem lokalen Rechner, auf dem die Fehlermeldung
angezeigt wurde.
Wenn vom Client gar kein Zugriff auf das AFS möglich ist, gehen Sie folgende
Checkliste durch:
• Das Paket instantafs-client .deb muss mit allen Abhängigkeiten installiert
sein.

178 8 Problembehebung
• Der openafs-client muss natürlich gestartet sein. Manuell kann er mit
root@host>/etc/init.d/openafs-client force-start
8.4.4 ”Read-only file system”-Fehler beim Schreiben
hochgefahren werden. Automatisch wird er bei jedem Reboot gestartet,
wenn die Datei
/etc/openafs/afs.conf.client die Zeile
AFS_CLIENT=true
enthält.
• In der Datei /etc/krb5.conf muss im Konfigurationsblock
[libdefaults]
eine Zeile in folgender Form stehen:
default_realm = CBS.MPG.DE
CBS.MPG.DE ist dabei der Name der Kerberos-Realm (also der Name
der AFS-Zelle in Großbuchstaben).
Dieser Fehler deutet darauf hin, dass versucht wurde, auf eine RO-Instanz eines
Volumes zu schreiben. Auf RO-Instanzen kann prinzipiell nicht über das
Filesystem geschrieben werden (auch Administratoren können das nicht).
Beispiel: Folgendes geht nicht:
user@host>touch /afs/cbs.mpg.de/local/scripts/test
touch: cannot touch ‘/afs/cbs.mpg.de/local/scripts/test’:Read-onl
allerding funktioniert (entsprechende Rechte vorrausgesetzt) das:
user@host>touch /afs/cbs.mpg.de/local/.scripts/test
genau wir folgendes Kommando:
user@host>touch /afs/.cbs.mpg.de/local/scripts/test
Beachten Sie die Arten der Mountpoints (siehe 3.2, Seite 32), die auf dem entsprechenden
Pfad durchschritten werden. Die Arten der Mountpoints (nicht nur
des letztens) sind entscheidend dafür, auf welche Instanz am Ende zugegriffen
wird. Mit dem Kommando
user@host>instantafs.afsdir Verzeichnis
(siehe 9.2.9, Seite 197) kann eine Begründung abgerufen werden, warum ein
bestimmtes Verzeichnis in einem RO-Volume liegt. Beispiel:
user@host>instantafs.afsdir /afs/cbs.mpg.de/local/scripts/test
8.4.5 In einem Verzeichnis haben alle Dateien unerwarteterweise die Größe 0
Das kann daran liegen, dass dem entsprechenden Benutzer die Rechte fehlen,
stat()-Informationen von den Dateien einzuholen, was wiederum 2 Ursachen
haben kann:
• Das Token des Benutzers ist abgelaufen
• Der Benutzer bekommt in den ACLs das r-Recht nicht verliehen. (siehe
3.7.3.2, Seite 51).

8.5 Fileserver 179
In jedem Fall muss man sich ein neues Token besorgen.
8.4.6 Der MacOSX-AFS-Client stürzt beim Versuch ab, ein .dmg-file zu mounten
8.4.6.1 Problem
8.4.6.2 Lösung
8.5 Fileserver
8.5.1 Ein Fileserver generiert undefinierte Fehler
.dmg-Dateien enthalten Dateisysteme, die als sog. loopback gemountet werden.
Dabei simmuliert der Kernel die Blockdevice, desse Zugriffe auf die entsprechende
Datei umgesetzt werden. Ein Filesystemtreiber des Kernels greift anschliessend
auf das Blockdevice zu.
Das .dmg-file ist nicht anonym erreichbar - man benötigt also ein Token, um
darauf zuzugreifen. Der Kernel hat kein Token - nur der Benutzer hat eines.
.dmg-File auf eine lokale Platte kopieren und dort öffnen.
Auf dem Fileserver müssen alle Prozesse korrekt gestartet werden (siehe 3.8.4,
Seite 59). Suchen Sie in den entsprechenden Logfiles nach Hinweisen, was das
korrekte Arbeiten des Fileservers behindert.
8.5.2 Ein Fileserver ist ausgefallen, die /vicep-Partitionen jedoch intakt
Installieren Sie einen neuen unspezialisierten AFS-Server (siehe 7.5, Seite 146).
Machen sie diesen danach mit folgendem Kommando zu einem AFS-Fileserver:
root@host>bos create localhost -instance fs -type fs \
-cmd /usr/lib/openafs/fileserver -cmd /usr/lib/openafs/volserver \
-cmd /usr/lib/openafs/salvager -localauth
Beenden Sie die Serverprozesse erst einmal wieder:
root@host>/etc/init.d/openafs-fileserver stop
Soll der Ersatzserver eine andere IP (oder auch mehrere andere IPs) als der
ausgefallene benutzen, muss die VLDB davon in Kenntnis gesetzt werden:
• Führen Sie das Kommando
root@host>vos changeaddr Defekter Server Ersatzserver -localauth
auf einem noch intakten AFS-Server aus. Damit wird der VLDB vorgegaukelt,
dass der defekte Fileserver lediglich eine neue IP bekommen hat.
• Besaß der defekte Fileserver mehrere IPs, muss man vos changeaddr
mehrmals anwenden. Besitzt der Ersatzserver nicht soviele IP-Adressen
wie der defekte Fileserver, sollte man die restlichen Adressen des defekten
Servers mit
root@host>vos changeaddr Defekter Server -remove
entfernen, damit Clients nicht versuchen, den Server über diese Adresse
zu kontaktieren 1 .
1 Das ist nicht unbedingt nötig, spart jedoch im Zweifelsfall Wartezeit auf den AFS-Clients.

180 8 Problembehebung
Wenn von dem alten Server die Datei /var/lib/openafs/sysid zur Verfügung steht
(z.B. aus einem Backup), sollte man diese jetzt an die selbe Stelle auf dem neuen
Server legen. Die VLDB erkennt Server nicht anhand ihrer IP-Adressen,
sondern anhand einer in dieser Datei gespeicherten Eindeutigen Zahl. Unterscheidet
sich diese Zahl auf dem neuen Server von der auf dem alten, so bleiben
die Volume-Instanzen des alten Servers in der VLDB gespeichert und müssen
später manuell entfernt werden. Bis sie entfernt sind, führt das u.U. zu erhöhten
Wartezeiten auf den AFS-Clients, die versuchen, auf den nicht mehr existierenden
alten AFS-Fileserver zuzugreifen.
Schließen sie das Storage-System wieder an, mounten sie alle /vicepx-Partitionen.
und starten sie die Fileserverprozesse auf dem neuen Server:
root@host>bos start localhost fs -localauth
Die VLDB muss jetzt noch über die Volume-Instanzen auf dem neuen Server
informiert werden:
root@host>vos syncvldb -localauth Neuer Server
8.5.3 Ein Fileserver wurde komplett zerstört
Achtung: Dieses Desaster-Recovery benötigt kein Backup-System, kann dafür
aber nur die RW-Instanzen wiederherstellen, für die noch RO-Instanzen in
der Zelle existieren. Ist ein Backup-System vorhanden, können natürlich noch
mehr Daten wiederhergestellt werden (siehe 5.7.2, Seite 112).
Folgender Befehl zeigt die Volumes an, die nicht wiederhergestellt werden
können:
user@host>instantafs.calcrestore -c Zerstörter Server/\*
Ist ein Fileserver mit allen Daten komplett verloren (z.B. durch Blitzschlag,
Brand, Vandalismus oder Diebstahl), sind folgende Schritte durchzuführen:
1. Man beschaffe einen Ersatz-Server (incl. einem mit dem Vorgängermodell
vergleichbarem Storage-System), den man wie unter 7.5 (Seite 146)
einrichtet. Die Vice-Partitionen müssen danach entsprechend dem letzten
Server eingerichtet sein (d.h. alle Vice-Partitionen, die auf dem letzten
Server waren, müssen auch auf dem neuen verfügbar sein und sollten 2
jeweils mindestens die gleiche Kapazität wie vorher haben).
2. Jetz wird ein Bash-Skript generiert, das den Restore-Vorgang später
durchführt:
admin@afs>instantafs.calcrestore -m Zerstörter Server/\* -s Neuer Server \
-p Partition auf dem neuen Server > skript.sh
admin@afs>sh ./skript.sh
Hinweis: Mit der zusätzlichen Option - -rorw kann der Wiederherstellungsprozess
erheblich beschleunigt werden. Sie bewirkt, dass
RO-Instanzen auf den noch vorhandenen Server in RW-Instanzen umgewandelt
werden. Dabei werden keine Daten über das Netzwerk geschickt,
sondern nur die RO-Instanzen verändert.
Das Skript wird dann einfach ausgeführt:
3. Je nachdem, was für Daten auf dem Server lagen, ergeben sich verschiedene
Konsequenzen:
2 Das ist nur nötig, wenn instantafs.calcrestore ohne - -rorw aufgerufen wird.

8.5 Fileserver 181
Hinweise:
(a) Lagen auf dem Server lediglich RO-Instanzen, so gibt es keinen Datenverlust.
(b) Lagen auf dem Server RW-Instanzen, für die auf anderen Servern
RO-Instanzen angelegt wurden, so können alle Daten zurück bis
zum letzten Release des jeweiligen Volumes wiederhergestellt werden.
Daten, die nach dem letzten Release des jeweiligen Volumes
verändert wurden, sind verloren.
(c) Befanden sich RW-Instanzen auf dem Server, von denen keine RO-
Instanzen existieren, so können diese nicht wiederhergestellt werden.
• Es ist möglich, die Wiederherstellung mit der Option - -volumepcre
auf bestimmte Volumes zu beschränken (z.B. weil die Zeit zu knapp ist
und nicht alle Volumes sofort wiederhergestellt werden müssen).
• Das Kommando
instantafs.calcrestore -c Servername/\*
8.5.4 Eine Volume-Instanz auf einem Server bleibt offline
zeigt alle Volumes an, die nicht wiederhergestellt werden können. Ersetzt
man -c durch -n, so werden die Volumes angezeigt, die wiederhergestellt
werden können.
Instanzen eines Volumes die als offline markiert sind, stehen über einen Fileserver
nicht zur Verfügung. Das kann verschiedene Ursachen haben - z.B. eine
Inkonsistenz in den diversen Datenstrukten der Instanz. Ähnlich dem fsck existiert
für AFS-Server ein Konzept, um solche Inkonsistenzen zu beseitigen.
1. Zuerst sollte man versuchen, das Volume per Kommando in den Modus
On-Line zu versetzen:
admin@afs>vos online Server Partition Volume-Instanz
admin@afs>vos exa Volume-Instanz
2. Nach dem ersten und auch den weiteren Schritten sollte man jeweils
testen, ob das Volume vielleicht schon wieder On-Line ist:
Dieser Befehl bezieht sich immer auf alle Volume-Instanzen einer Klasse
(RO, Backup, RW). Bei Backup und RW-Instanzen ist das unkritisch, bei
RO-Instanzen werden jedoch immer alle aufgeführt.
3. Jetzt sollte man versuchen, die Instanz zu reparieren:
admin@afs>bos salvage Server Partition Volume-Instanz
Sollte es nicht funktionieren, macht man das am besten mehrmals (bis zu
3x).
4. Man kann jetzt noch versuchen, die ganze Partition zu reparieren. Für die
Dauer des Vorgangs kann kein AFS-Client auf die Volume-Instanzen, die
auf der Partition liegen, zugreifen.
admin@afs>bos salvage Server Partition

182 8 Problembehebung
8.5.4.1 Extraktion von Dateien aus AFS-Dumps
Auch diesen Vorgang sollte man bis zu 3x ausführen, wenn es nicht sofort
klappt.
Das bos salvage-Kommando kennt zahlreichen Optionen. Weitere Informationen
finden sich in [ADMREF].
Es ist auch möglich, dass sich eine Instanz gar nicht reparieren lässt. Existieren
keine anderen Instanzen des Volumes kommt man nur über einen Umweg
trotzdem an die Files in dieser Instanz. Die Instanz muss dazu mit vos dump
in eine Datei gespeichert werden:
admin@afs>vos dump user.ernie -server afsserv1 -partition a >
/tmp/user.ernie.dump
Mit dumptool (Paket openafs-tools .deb ) kann anschließend in dem Dump-
File interaktiv nach Dateien gesucht und diese extrahiert werden:
user@host>dumptool /tmp/user.ernie.dump
Ein Programm, das allerdings nicht Teil von OpenAFS ist, macht es möglich,
den ganzen Verzeichnisbaum eines Dump-Files zu extrahieren:
user@host>afsdump_extract Dumpfile Zielverzeichnis
Wurden alle Daten extrahiert, sollte man die defekte Volume-Instanz löschen
und neu anlegen. Wenn sie sich nicht löschen läßt, findet man unter 8.5.5 Hilfe.
Das Programm ist Teil des Paketes dumpscan .deb .
8.5.5 Eine Volume-Instanz auf einem Server ist löschresistent
Es kann vorkommen, dass sich Instanzen auf Fileservern gar nicht löschen lassen
oder aber, dass sie nach dem Löschen und anschliessenden Neustart des
Fileservers als Off-Line-Instanzen mit Namen wie bogus.536871547 ein Schattendasein
führen, jedoch trotzdem Speicher 3 verbrauchen.
Achtung: Auch wenn dabei noch nie etwas schiefgegangen ist 4 , kann dabei
theoretisch etwas schiefgehen und andere Instanzen auf der selben Partition in
Mitleidenschaft gezogen werden.
Mit dem Tool instantafs.getvoldirs kann man das Verzeichnis einer Volume-
Instanz ermitteln:
user@host>instantafs.getvoldirs 536871547
v=/v7++U
Die ausgegebene Zeichenfolge ist das Verzeichnis zur bogus-Volume-Instanz,
relativ zur AFS-Datenpartition. Die Sonderzeichen machen es vermutlich nötig,
den Pfad zu quoten - am besten mit ’. Wäre die Instanz auf Partition a, wären
folgende Befehle das Ende der Bogus-Instanz:
3 Fälschlicherweise wird bei solchen Instanzen meist angezeigt, dass sie 0 kByte Speicher verbrauchen
- das ist i.d.R. falsch!
4 Der Author hat diese Methode bereits mehr als zehnmal ohne Nebeneffekte benutzt

8.5 Fileserver 183
root@afsserv> rm -rf ’/vicepa/v7++U’
root@afsserv> rm /vicepa/V0536871547.vol
8.5.6 Eine Partition auf einem Fileserver ist voll, nichts geht mehr
Ist eine /vicepx-Partition komplett gefüllt, kann es zu Problemen kommen, wenn
auf dieser Partition Instanzen liegen, die differenziell gespeichert werden (siehe
3.1.4, Seite 29). Das primäre Ziel ist dann, die RW-Instanzen auf der Partition
arbeitsfähig zu erhalten bzw sie wieder benutzbar zu machen. Man geht jetzt in
3 Schritten vor.
1. Zuerst wird auf der vollen Partition Platz geschaffen:
(a) Die Backup-Instanzen aller Volumes, deren RW-Instanzen auf
dieser Partition liegen, sollten mit den RW-Instanzen synchronisiert
werden. Durch die differenzielle Speicherung (siehe 3.1.4, Seite
29) ist der Speicherbedarf direkt nach der Synchronisation am
geringsten. Das geht z.B. mit diesem Befehl:
admin@afs>iarel ‘volgrep rwlocation=Server/Partition \
backup_exists=1‘
(b) Alle differenziell gespeicherten RO-Instanzen auf der Partition
sollten mit den entsprechenden RW-Instanzen (aus dem selben
Grund wie bei den Backup-Instanzen) synchronisiert werden. Ein
möglicher Befehl dafür lautet:
admin@afs>iarel ‘volgrep rolocation=Server/Partition
rwlocation=Server/Partition‘
(c) Sind RO-Instanzen von Volumes auf der Partition, von denen auch
auf anderen Partitionen RO-Instanzen existieren, können diese entfernt
werden. Clients, die auf RO-Instanzen des jeweiligen Volumes
zugreifen wollen, benutzen dann einfach einen anderen Server.
(d) Wenn ein kurzzeitiger Ausfall der Erreichbarkeit unkritisch ist,
kann man auch die -live-Funktion benutzen, um bestimmte
einzelne RW-Instanzen von der Partition zu verschieben. Normalerweise
wird zum Verschieben ein move-Clone angelegt (siehe
3.1.5, Seite 30). Durch die -live-Option wird kein Clone erzeugt,
die RW-Instanz bleibt dann jedoch während des Verschiebens die
ganze Zeit busy (siehe 6.13.2, Seite 137).
2. Zur Sicherheit sollte man den salvager auf der betroffenen Partition
laufen lassen:
admin@afs>bos salvage Servername -partition Partition
3. Man sollte in Betracht ziehen, einige RW-Instanzen auf andere Server zu
verlagern (siehe 6.11.2, Seite 133).
Hinweis:Das geht im laufenden Betrieb (siehe 6.9, Seite 123).
8.5.7 Volume-Instanzen names bogus.XXX tauchen auf Fileservern auf
Solche Volume-Instanzen werden generiert, wenn die Inkonsistenzen auf
Wirtspartitionen die Heilungskräfte des Salvagers (siehe 3.8.4, Seite 59) übersteigen.
Das Log-file /var/log/openafs/SalvageLog gibt Auskunft über solche
Bogus-Instanzen, wenn sie generiert werden. Oft weiss der Salvager einfach

184 8 Problembehebung
nur nicht, wie der korrekte Name der Instanz ist. Durch einen Abgleich des Inhaltes
der VLDB mit den Instanzen der entsprechenden Partition sollte schnell
geklärt sein, um welche Instanz es sich handelt - es seie denn, es gibt mehrere
Bogus-Instanzen.
Achtung: Bogus-Instanzen deuten nur auf einen unbekannten Instanz-Namen
hin - nicht darauf, dass die Daten unwichtig wären. Auf einer Partition, die nur
RO-Instanzen enthält, kann man diese problemlos löschen - die entsprechende
RO-Instanz wird beim, nächsten vos release einfach neu erzeugt. Wenn es
aber eine RW-Instanz sein könnte, darf man auf keinen Fall solche Instanzen
einfach löschen.
8.6 Ein Fileserver registriert sich mit zu vielen (evtl. falschen) IP-Adressen
root@fileserver ifconfig eth1 down
Das ist besonders Lästig, wenn diese Adressen nicht geroutet werden - z.B. weil
ein Fileserver einfach noch eine zweite aktive Netzwerkkarte mit einer Dummy-
Adresse hat. AFS-Clients versuchen dann, auch diese Adresse zu erreichen,
fragen aber logischerweise beim Default-Gateway an.
Wenn man nun diese Netzwerkkarte mit
abschaltet und den Fileserver mit
root@fileserver bos restart localhost fs -localauth
8.7 Datenbankserver
neustartet, beißt man auf Granit - die Adresse bleibt weiterhin registriert - wie
man mit
user@host>vos listaddrs
sehen kann. Nach dem Abschalten der Netzwerkkarte ist es wichtig, eine NetRestrict-Datei
(siehe 3.6.1, Seite 45) mit der IP der nun abgeschalteten Netzwerkkarte
anzulegen - dann entfernt der Fileserver beim Neustart die entsprechende
Adresse aus der VLDB.
Um Ausfallzeiten zu minimieren, kann man sich den Neustart des Fileservers
sparen - zumindest, wenn man den bosserver angewiesen hat, den Fileserver
regelmäßig automatisch neu zu starten (was der default ist).
8.7.1 Es ist überhaupt kein Zugriff auf die AFS-Datenbank möglich
Die AFS-Datenbank ist üblicherweise stark redundant ausgelegt. Lesezugriffe
auf die AFS-Datenbank sind auch dann noch möglich, wenn nur noch ein
einziger Datenbankserver korrekt arbeitet. Folgendes Kommando kann benutzt
werden, um zu analysieren, wo das Problem liegt:
admin@afs>instantafs.servercheck - -cell Zellenname 1. DB-Server 2. DB-Server
...
Im Fall der Zelle cbs.mpg.de wäre das:
admin@afs>instantafs.servercheck - -cell cbs.mpg.de server3 server4
.

8.7 Datenbankserver 185
8.7.2 Schreibzugriffe sind nicht möglich
Ist kein Schreibzugriff auf die VLDB, PTDB oder BDB möglich, liegt das mit
hoher Wahrscheinlichkeit daran, dass die Kommunikation zwischen den DB-
Servern gestört ist. Überprüfen Sie in diesem Fall folgendes:
• Können die DB-Server ungestört kommunizieren (siehe 3.6, Seite 44)?
• Laufen die Systemuhren der DB-Server synchron? Ab 10 Sekunden ist
die Abweichung kritisch.
• Sind auf allen DB-Servern alle anderen DB-Server korrekt eingetragen?
Der Befehl bos listhosts Servername sollte auf jeden
DB-Server angewandt die komplette Liste aller DB-Server ausgeben.
• Sind auf allen DB-Servern aktuelle Versionen von openafs-dbserver .deb
installiert? Die Software muss mindestens die Versionsnummer 1.2.11
haben.
Das Kommando
user@host>udebug Server Portnummer
8.7.3 Ein Volume läßt sich nicht aus der Datenbank löschen
8.7.3.1 VLDB neu aufbauen
ist hilfreich, um aktuelle Informationen über die Wahl der Sync-Site zu erhalten.
Die jeweiligen Portnummern der einzelnen Datenbank-Prozesse sind in
Tabelle 3.6, Seite 45 aufgeführt.
Schneller geht’s mit instantafs.servercheck (siehe 9.2.14, Seite 200).
Wenn sichergestellt ist, dass es sich nicht um das unter 8.7.2 beschriebene Problem
handelt, könnte es sein, dass die VLDB inkonsistent ist. Es gibt 2 Lösungsansätze.
Die AFS-Datenbank enthält keine wirklich wertvollen 5 Informationen.
Wenn sich nur wenige 6 AFS-File- und Datenbank-Server in der Zelle befinden,
kann man die VLDB einfach neu erstellen.
Achtung: Bei dieser Methode gibt’s eine mehr oder weniger lange Downtime
der Datenbank. Ist diese kurz genug, um auf Clients, die gerade Volume-
Informationen abfragen, keinen Timeout zu triggern, ist das unkritisch. In jedem
anderen Fall wird’s brenzlig, wenn gerade Benutzer im AFS arbeiten.
So wird’s gemacht:
1. Man fahre die Datenbankserver-Prozesse für die vldb herunter. Dazu
muss für jeden AFS-Datenbankserver folgendes Kommando ausgeführt
werden:
admin@afs>bos stop Datenbankserver vlserver
2. Auf jedem der Datenbankserver entfernt man nun die Dateien, in denen
die VLDB liegt:
root@afsdb> rm -f /var/lib/openafs/db/vldb.*
5 Praktisch alle Informationen können mit wenigen Befehlen wiederhergestellt werden
6 Sind es zu viele Server wird’s mühsam, so daß sich die andere Methode eher lohnt.

186 8 Problembehebung
3. Die Datenbankserver werden jetzt einer nach dem anderen wieder hochgefahren:
admin@afs>bos stop Datenbankserver vlserver
admin@afs>vos syncvldb Fileserver
8.7.3.2 VLDB reparieren
4. Alle Fileserver müssen jetzt angewiesen werden, Daten über ihre
Volume-Instanzen bei der VLDB abzuliefern:
Das Tool vlclient, kann benutzt werden, um bestimmte Schäden in der VLDB
zu reparieren. Das geht im laufenden Betrieb, allerdings muss das Tool zuerst
durch Compilierung der OpenAFS-Quellen selbst erstellt werden.
So repariert man damit die VLDB:
admin@afs>vlclient -cell Zellenname -host Sync-Site
Die aktuelle VLDB-Sync-Site kann man mit
user@host>udebug Beliebiger_Datenbankserver 7003
vl> checkhash unused
vl> fixhash unused
8.8 Backup-Probleme
herrausfinden. Anschliessend arbeitet man auf dem vlclient-Prompt:
8.8.1 Der Speicher auf dem Backup-Server ist voll, das Backup läuft noch
instantafs.vtapes verschickt eine Warnungs-eMail, wenn nicht mehr genug
Speicher zur Verfügung steht. Der Backup-Prozess läuft in diesem Fall noch
und sollte auch möglichst nicht unterbrochen werden. Es gibt 3 Möglichkeiten,
um fortzufahren:
Alte Backups löschen : Mit einem manuellen Aufruf der Form
root@backupserv> instantafs.vtapes - -remove 90 - -cleanup
kann Platz geschaffen werden. Anschließend wird dem noch laufenden
instantafs.vtapes-Prozess mit
root@backupserv> touch instantafs.vtapes-Tempdir
mitgeteilt, dass er den verfügbaren Speicher neu berechnen und das
Backup fortsetzen soll.
Zusätzlichen Platz zur Verfügung stellen : Läßt sich auf einfache Weise eine neue Festplatte ins Dateisystem des
Backup-Servers integrieren (z.B. da bereits ein zusätzliches unbenutztes
Speichersystem integriert ist), kann man diese dem Backup-System jetzt
zur Verfügung stellen. Die Platte muß beschreibbar sein und in der Datei
/etc/instantafs/vtapes.conf mit einem Eintrag der Form
storagedir=/pfad/zur/grossen/platte

8.9 acall-Probleme 187
verewigt werden. Anschliessend ist folgendes auszuführen:
root@backupserv> touch instantafs.vtapes-Tempdir/iavt-resume
wobei instantafs.vtapes-Tempdir das Temporäre Verzeichnis
ist, das bei der Konfiguration des Backup-Servers mit
instantafs.vtapes - -init - -tempdir Tempdir angegeben
wurde. Mit folgendem Befehl läßt es sich herrausfinden:
user@backupserv> grep ’tempdir=’ /etc/instantafs/vtapes.conf
Aufgeben : Mit folgendem Kommando wird das AFS-Backup-System zur Aufgabe
gezwungen - der aktuelle Dump wird dann abgebrochen:
root@backupserv> touch instantafs.vtapes-Tempdir/iavt-abort
8.9 acall-Probleme
8.9.1 mk_req error: No credentials cache found
Achtung: Es ist möglich, dass bereits andere Backup-Prozesse darauf
warten, dass der Backup-Server wieder frei wird. Bricht man in
solch einem Fall das aktuelle Backup ab, ist der Backup-Server direkt
danach wieder frei und die nächste Warnungs-eMail ist nicht
weit. Man sollte also dringend vorher den auslösenden Prozess (i.d.R.
instantafs.backup auf dem Backup-Server) beenden.
instantafs.acall kann auf keinerlei Kerberos-Tickets zugreifen.
Lösung:
user@host>tokenmgr -l Benutzername
Wenn die entsprechende acall-Funktion automatisiert ausgeführt werden soll,
greift man besser auf eine Keytab zurück (siehe 3.10.3, Seite 63) und authorisiert
sich mit dieser. Beispiel:
user@host>tokenmgr -lp volumemaster -k /etc/instantafs/volumemaster.keytab \
- - acall db ia:volcreate wichtiges-volume
8.9.2 E: acall(): Kerberos error in get_server_rcache(): Permission denied in replay cache code
Dieser Fehler deutet darauf hin, dass sich unter /var/tmp viel Unrat angesammelt
hat. Abhilfe schafft man wie folgt:
root@host>rm -f /var/tmp/rc_client*
8.9.3 E: Not authorized.
Damit eine bestimmte acall-Funktion von einem Nutzer ausgeführt werden
kann, muss das in mindestens einer Zeile der Konfigurationsdatei des jeweiligen
acall-Servers 7 erlaubt sein. Wenn der Zugriff auf die Konfigurationsdatei
nicht möglich ist, sind alle Zugriffe verboten.
Mögliche Ursachen:
7 i.d.R. ist das die globale Konfigurationsdatei /a/a/etc/acall.access

188 8 Problembehebung
8.9.4 mk_req error: Server not found in Kerberos database
• Die angegebene Konfigurationsdatei (bzw. /a/a/etc/acall.access, wenn
keine angegeben wurde) existiert nicht.
Lösung: Die genannte Datei anlegen. Eine Beispieldatei befindet sich
unter /usr/share/doc/instantafs-doc/examples/acall.access im Paket
instantafs-doc .deb .
• Es befindet sich keine Regel in der Konfigurationsdatei, die dem entsprechenden
Benutzer den Zugriff auf diese acall-Funktionen auf diesem Server
erlaubt.
Hinweise:
– Ist im Feld acall-Server der richtige angegeben? Soll ein Kommando
auf allen acall-Servern ausführbar sein, ist der PCRE .* die richrige
Wahl.
– Als aufzurufende Funktion kann kein PCRE angegeben werden.
Dieser Fehler kann eine oder auch beide der folgenden Ursachen haben:
Fehlender Principal : Der entsprechende Principal (in der Form acall/meinserver.meinezelle
existiert im Kerberos nicht. Dabei ist zu beachten, dass [meinserver.meinezelle]
zusammen der FQDN des Servers sein muss.
FQDN-Unstimmigkeit : Das Reverse-Lookup des Servers könnte falsch konfiguriert sein (siehe
4.4.1, Seite 79) - mit dem folgendem Befehl kann man das testen:
user@host>host IP-Adresse
8.9.5 Der acall-Aufruf blockiert für immer
8.10 Andere Dienste
Man sollte sich die Ausgaben von instantafs.acall-server auf Serverseite
ansehen. Folgende mögliche Ausgaben sind von Interesse:
8.10.1 In einer SSH-Shell ist der Zugriff auf das AFS nicht möglich
• rd_req error: Wrong principal in request
Das könnte daran liegen, dass der acall-Server seinen eigenen FQDN
nicht korrekt ermitteln kann. Das liegt oft an der Datei /etc/hosts. Dieser
sollte eine Zeile der Form
[IP-Adresse des Servers] [FQDN] [evtl. weitere
Aliase]
enthalten - z.B. so:
10.0.0.10 afsserv1.cbs.mpg.de afsserv1
Die Reihenfolge ist wichtig. Diese Zeile wäre schon falsch: 10.0.0.10
afsserv1 afsserv1.cbs.mpg.de
Auch darf die FQDN und der Hostname in keiner anderen Zeile wie z.B.
127.0.0.1 afsserv1 localhost
auftauchen.
Der SSH-Server ist per default nicht in der Lage, den für AFS-Zugriffe nötigen
Token zu generieren. Loggt man sich also per ssh auf einem Rechner ein, so
agiert man aus Sicht des AFS immer noch als anonymer Nutzer und erhält i.d.R.
keinen Zugriff auf Homedirectories. Es gibt zwei Lösungen für dieses Problem:

8.10 Andere Dienste 189
user@host>tokenmgr -l
• Mit dem Kommando
kann man direkt nach dem Login ein Token erstellen und damit arbeiten.
• Die (für den Administrator) kompliziertere Lösung ist (für den Benutzer)
jedoch komfortabler: SSH mit Kerberos-Support (siehe 7.3.2, Seite 143).
Wenn Sie bereits SSH für Kerberos konfiguriert haben und es eigentlich funktionieren
sollte, gehen sie folgende Checkliste durch:
• Liegt in Reichweite des ssh-Prozesses auf dem SSH-Client ein gültiges
Kerberos-TGT? Man kann das wie folgt testen:
user@host>klist 2>/dev/null | grep krbtgt
06/30/04 08:53:11 07/01/04 10:53:07 krbtgt/CBS.MPG.DE@CBS.MPG.DE
user@host>date
Wed Jun 30 12:41:07 CEST 2004
In diesem Fall ist das TGT noch bis fast 10:53 des folgenden Tages gültig.
• Die Tickets auf dem Client müssen unbedingt forwardable sein, damit
sie zum SSH-Server weitergeleitet werden können. So kann man das
testen:
user@host>klist -f 2>/dev/null | grep -A1 krbtgt
08/03/06 10:42:45 08/04/06 12:42:43 krbtgt/CBS.MPG.DE@CBS.MPG.DE
Flags: FPIA
user@host>tokenmgr -l
Das Grosse F unter den Flags ist wichtig. Ist es nicht vorhanden, können
keine Tickets weitergeleitet werden.
• Die Versionsnummer des Host-Tickets auf dem SSH-Client könnte falsch
(sprich: veraltet) sein. Es ist leichter, sicherzugehen, dass dem nicht so
ist, als festzustellen, ob das wirklich der Fehler ist. Man besorge auf
Client-Seite einfach ein neues Ticket/Token:
• Kann man auf dem SSH-Server manuell mit kinit ein TGT holen?
Wenn das nicht geht, kann es an folgendem liegen:
– Ein Kerberos-Server läuft nicht oder ist falsch konfiguriert,
– die DNS-Einträge für das Kerberos sind nicht korrekt oder
– die Datei /etc/krb5.conf ist nicht korrekt.
Unter 4.4 (Seite 79) findet man Informationen darüber, wie die DNS-
Einträge und /etc/krb5.conf auszusehen haben.
• Ist die Version des ssh .deb -Paketes in der Lage, mit Kerberos umzugehen?
Man findet das wie folgt heraus:
user@host>ssh -V
OpenSSH_3.8.1p1 Debian 2:3.8.1p1-8+afs, OpenSSL 0.9.6l 04 Nov 2003
Die Kerberos-fähige ssh .deb -Version von InstantAFS hat die Zeichenfolge
“+afs” im Namen.
• Liegt auf dem SSH-Server eine gültige Kerberos-Keytab? Mit dem Kommando
instantafs.kerberos -G (siehe 9.2.18, Seite 201) kann

190 8 Problembehebung
man dafür sorgen.
8.11 Localhost und die Hostnamensauflösung
8.11.1 /etc/hosts säubern
user@host>hostname -f
afsserver1.cbs.mpg.de
user@host>hostname -i
10.0.0.10
• Ist die Zeit zwischen Kerberos-Server und dem SSH-Server synchron?
Kerberos reagiert empfindlich auf schlecht synchronisierte Zeit.
• Gibt’s vielleicht Probleme mit der Lokalen Host-Namensauflösung? (siehe
8.11, Seite 190)
• Evtl. hilft ein Blick in das Logfile (/var/log/auth.log) des Kerberos-
Servers (oder der Kerberos-Server, wenn es mehrere gibt). In diesem
Logfile wird z.B. jede fehlgeschlagene Anforderung eines Service-
Principals mit der jeweiligen Ursache gelistet.
Für einige Dienste wie z.B.
• AFS-Datenbankserver (ptserver, vlserver, ...)
• acall-Server
• SSH-Server
ist es unerläßlich, daß die Auflösung der lokalen Hostnamen korrekt funktioniert.
Oft sind ungeeignete Einträge in /etc/hosts vorhanden 8 , die die genannten
Dienste einschränken oder vollkommen unbrauchbar machen.
Hier einige Hinweise - am Beispiel des Rechners afsserv1.cbs.mpg.de - wie die
Datei /etc/hosts aussehen muss:
• Der Hostname darf in keiner Form (also weder verkürzt noch als FQDN)
in einer Zeile erscheinen, die auf das lokale Netz (127.0.0.1/255.0.0.0)
hindeutet. Hier einige Negativbeispiele:
127.0.0.1 afsserv1 localhost localhost.localnet
127.0.0.2 localhost afsserver1
• Der FQDN, also der Hostname mit angehängtem Domännamen, muß direkt
hinter der IP-Adresse stehen. Also nicht so:
10.0.0.10 afsserv1 afsserv1.cbs.mpg.de
sondern so:
10.0.0.10 afsserv1.cbs.mpg.de afsserv1
Folgende Tests (wieder am Beispiel von afsserv1.cbs.mpg.de) stellen sicher,
dass alles OK ist:
Das hostname -f-Kommando muß die erwartete FQDN zurückliefern,
hostname -i sollte die erwartete IP ausgeben.
8 Natürlich können solche Einträge auch im DNS stehen, das kommt i.d.R. aber nicht vor.

8.11 Localhost und die Hostnamensauflösung 191
8.11.2 Schadensbeseitigung
Ein falscher /etc/hosts-Eintrag kann Fehler in der VLDB hinterlassen haben
Wenn im Log-File eines AFS-Clients eine Zeile wie folgt auftaucht
afs: Lost contact with file server 127.0.0.1 in cell [...]
muss man den entsprechenden Fileserver-Eintrag aus der VLDB werfen:
admin@afs>vos changeaddr -remove 127.0.0.1

9 AFS- Kerberos- und InstantAFS-Kommandos
9.1 AFS-Kommandos
9.1.1 Arbeiten an AFS-Serverprozessen
In diesem Kapitel werden alle relevanten Kommandos beschrieben, die für den
Betrieb einer Zelle benötigt werden.
Der bosserver stellt einige Kommandos zur Verfügung, um die untergeordneten
Prozesse zu manipulieren und um den Zugriff auf AFS-Serverprozesse zu
steuern. Tabelle 9.1 (Seite 193) zeigt eine kurze Übersicht über die wichtigsten
Kommandos. Weitere Informationen finden sich in [ADMREF].
192

9.1 AFS-Kommandos 193
Funktion Befehl Erklärung
Starten eines neuen bos create Server -instance Dieses Kommando fügt einen neuen AFS-Serverprozess zur Liste
Prozesses
Bezeichnung des Prozesses der Bosserver-Prozesse hinzu und startet den Prozess. Bei Prozessen
-type Typ -cmd Kommando
vom Typ fs, müssen mehrere -cmd-Parameter angegeben werden.
Bezeichnung des Prozesses ist ein beliebiger Name für den Prozess.
Üblicherweise werden die Namen ptserver, vlserver, buserver und
fs benutzt.
Herunterfahren aller bos shutdown Server Dieses Kommando beendet alle laufenden vom BOS-Server verwalteten Pro-
Serverprozesse
zesse auf dem Server.
Starten aller Server- bos startup Server Mit diesem Befehl wird der bosserver angewiesen, alle verwalteten Serverprozesseprozesse
zu starten.
Zustand der Server- bos status Server Dieses Kommando zeigt an, welche Prozesse auf dem Server (korrekt) laufen.
prozesse
Neustart aller Pro- bos restart Server -all Startet alle verwalteten Prozesse neu.
zesse
Automatischen Neu- bos setrestart Server -time
start steuern Startzeitpunkt -general
Dieser Befehl definiert, wann der bosserver sich selbst und alle Prozesse
(regelmäßig) neu startet. Startzeitpunkt kann dabei folgende Werte annehmen:
• never Abschalten des automatischen Neustarts
• Stunde:Minute Täglicher Neustart zur angegebenen Zeit
• Startzeitpunkt Wöchentlicher Neustart am angebenen Tag zur angegebenen
Zeit.
Das folgende Beispiel führt zu einem
Neustart an jedem Sontag 00:00:
bos setrestart localhost
-time ’sat 00:00’
bos listusers Server Dieser Befehl zeigt die Nutzer an, die auf diesen Server zugreifen dürfen. Das
hat nichts mit reinem Dateizugriff auf Files unter /afs zu tun (siehe 3.7.3.5,
Seite 54) sondern mit Berechtigungen zur Ausführung bestimmter vos- bos
und pts-Unterkommandos.
Autorisierte Benutzer
anzeigen
Benutzer hinzufügen bos adduser Server Benutzer Mit diesem Befehl fügt man einen neuen Benutzer in die Liste der autorisierten
Benutzer ein.
Benutzer entfernen bos removeuser Server Dieses Kommando entfernt einen Benutzer von der Liste autorisierter Benut-
Benutzer
zer.
Tabelle 9.1: Verwaltung von Prozessen über den bosserver mittels des bos-Kommandos

194 9 AFS- Kerberos- und InstantAFS-Kommandos
9.2 InstantAFS
9.2.1 instantafs.acall (Kurzform: acall)
Die in diesem Abschnitt beschriebenen Kommandos (hauptsächlich Perl-
Skripte) sind Teil von InstantAFS und befinden sich im Paket instantafs .deb .
Die einzige Ausnahme ist das im Paket instantafs .deb enthaltene
instantafs.kcheckpass.
Dieses Kommando wird benutzt, um eine acall-Funktion (siehe 7.6.2, Seite
149) auf einem Server im Netzwerk auszuführen. Die Syntax ist wie folgt:
user@host>instantafs.acall acall-Server Funktion Parameter
Also z.B.:
user@host>instantafs.acall db ia:helloworld foo bar
This is instanafs-acall’s innovative hello-world program.
You’ve been identified as: ’ernie’
Those were your arguments:
foo
bar
In diesem Fall wurde das Programm instantafs.acall-helloworld 1 mit den Parametern
foo und bar aufgerufen.
Wer welche Kommandos ausführen darf, ist per default in /a/admin/etc/acall.access
definiert. Es kann auch eine andere Datei zur Zugriffskontrolle
benutzt werden, die über den Parameter - -accessfile Dateiname
definiert werden muss.
instantafs.acall-server setzt für ausgeführte Programme einige Umgebungsvariablen,
damit diese evtl. weitere Zugriffseinschränkungen vornehmen können.
Informationen über diese Variable sind on-line erhältlich:
user@host>instantafs.acall-server - -help
9.2.2 instantafs.acall-backup (Kurzform: ia:backup)
9.2.3 instantafs.acall-helloworld (Kurzform: ia:helloworld)
Einige acall-Funktionen, also Skripte, die sich zum Aufruf über acall eignen,
sind in InstantAFS bereits enthalten - erkennbar an dem Namensmuster
instantafs.acall-[Funktion].
Dieses Skript wird auf dem db-acall-Server benutzt. Es ermöglicht einfachen
Benutzern, die Backup-Instanzen von Volumes mit deren RW-Instanzen zu synchronisieren.
Dieses Testprogramm demonstriert, zum einen, wie man leicht eigene acall-
Funktionen schreiben kann. Ausserdem ist es per default jedem authentifizierten
Nutzer gestattet, dieses Skript als acall-Funktion aufzurufen.
1 “ia:” wird automatisch durch “instantafs.acall-” ersetzt.

9.2 InstantAFS 195
9.2.4 instantafs.acall-release (Kurzform: ia:release)
9.2.5 instantafs.acall-setquota
9.2.6 instantafs.acall-usermgr (Kurzform: ia:usermgr)
Dieses Kommando wird auf einem AFS-DB-Server (genauer: dem db-acall-
Server) mittels acall aufgerufen. Es ermöglicht Benutzern, die RO-Instanzen
bestimmter Volumes mit deren RW-Instanzen zu synchronisieren. Das ist z.B.
sinnvoll, wenn ein Benutzer, der für ein bestimmtes Software-Verzeichnis verantwortlich
ist, Änderungen an diesem Verzeichnis durchgeführt hat und die
Änderungen nun allen anderen Benutzern zur Verfügung stellen will.
Dieses Kommando ist die acall-Serverkomponente für instantafs.release.
instantafs.acall-release überprüft nicht, ob ein Benutzer berechtigt ist,
ein bestimmtes Volume zu synchronisieren. Diese Überprüfung muß vom
instantafs.acall-server durchgeführt werden, wozu man die Datei /a/a/etc/acall.access
entsprechend bearbeiten muß.
Dieses Skript wird mittels acall (siehe 7.6.2, Seite 149) aufgerufen. Es
ermöglicht Benutzern, Volumequotas in gewissen Grenzen zu setzen. Die Konfigurationsdatei,
in denen diese Grenzen definiert werden, heisst /a/a/etc/acallsetquota.conf,
ein Beispiel liegt unter /usr/share/doc/instantafs-doc/examples/acallsetquota.conf
im Paket instantafs-doc .deb .
Dieses Skript wird mittels acall (siehe 7.6.2, Seite 149) aufgerufen. Es verändert
(oder zeigt an) mit jedem Aufruf jeweils einen Zustand eines Benutzers.
Folgende Zustandstypen existieren zu jedem Benutzer:
db : Der Zustand des Benutzers in der PTDB. In diesen Zustand fliesst u.a. die
Mitgliedschaft in den Benutzergruppen users bzw. users-na ein.
krb5 : Dieser Zustand sagt aus, ob der Benutzer ein gültiges Kerberos5-Konto
hat.
homedir : Je nach Position und Existenz des Homedirectory-Volumes errechnet sich
der homedir-Zustand eines Benutzers.
samba : Dieser Zustand zeigt an, ob ein Benutzer auf dem Samba-Gateway einen
gültigen Account hat.
Es ist für den Einsatz auf Servermaschinen mit den folgenden Serverprozessen
sinnvoll:
AFS-DB-Server : zum Verwalten der PTDB-Einträge von AFS-Benutzern und zum Verwalten
von AFS-Homedirectories.
Kerberos5-Master-Server : zur Manipulation der Principals in der Kerberos5-Datenbank
Samba-Gateway : zum Generieren der User-Keytab (siehe 3.10.3, Seite 63) und der
LANMAN-/NT-Hashes, die zur Authentifikation von SMB-Nutzern
eingesetzt werden.
9.2.7 instantafs.acall-volcreate (Kurzform: ia:volcreate)
Dieses Skript ist Kern des InstantAFS-Usermanagements (siehe 7.9, Seite 155).
instantafs.acall-volcreate wird benutzt, um Volumes von normalen Benutzern
anlegen zu lassen. In der Konfigurationsdatei /a/a/etc/acall-volcreate.conf läßt
sich definieren, wer welche Volumes wo und mit welchen Optionen anlegen
darf. Der aufrufende Benutzer hat dabei (teilweise) Kontrolle über den Namen

196 9 AFS- Kerberos- und InstantAFS-Kommandos
des neuen Volumes. Alle anderen Parameter werden über die Konfigurationsdatei
definiert. Im Beispielprojekt (siehe 7.11, Seite 159) wird u.a. beschrieben,
wie man dieses acall-Kommando sinnvoll einsetzt. Die Syntax ist wie folgt:
user@host>acall db ia:volcreate Volumename
9.2.8 instantafs.achmod (Kurzform: achmod)
Dieses interaktive Tool stellt eine ncurses-Overfläche zur Verfügung, mit der
ACLs von AFS-Verzeichnissen bearbeitet werden können. Zusätzlich bietet es
auch Funktionen für nicht-interaktive Manipulation von ACLs.
Bei Bedarf lassen sich komplette Unterbäume, wenn gewünscht auch über Volumegrenzen
hinweg, mit neuen ACLs versehen. Die man-Page hält weitere
Informationen bereit.

9.2 InstantAFS 197
9.2.9 instantafs.afsdir
Dieses Tool zeigt an, durch welche Volumes ein angebener Verzeichnispfad
im AFS führt, welche Instanzen dabei jeweils benutzt werden und vor allem
warum. Beispiel:
user@host>instantafs.afsdir /a/a/.etc
Listing 9.1: instantafs.afsdir-Output
Walking a l o n g t h e p a t h ’ / a / a / . e t c ’
< / > ( VFS−D i r e c t o r y )
[ / a ] ( Symbolic Link p o i n t i n g i n t o an AFS−p a t h )
/ [ / a f s / a l p h a ] ( AFS−Mountpoint )
|−Volume : r o o t . c e l l
|− D e s c r i p t i o n : Das Z e l l e n−Rootvolume ( u n t e r / a zu e r r e i c h e n )
|− Mountpoint−Type : magic , c e l l = a l p h a ( ’ # a l p h a : r o o t . c e l l ’ )
|− I n s t a n c e : r e a d o n l y
\ _Why : RO of ’ r o o t . c e l l ’ e x i s t s so i t was chosen i n f a v o u r of t h e RW.
/ [ / a f s / a l p h a ] ( AFS−Mountpoint )
|−Volume : r o o t . c e l l
|− D e s c r i p t i o n : Das Z e l l e n−Rootvolume ( u n t e r / a zu e r r e i c h e n )
|− Mountpoint−Type : magic , c e l l = a l p h a ( ’ # a l p h a : r o o t . c e l l ’ )
|− I n s t a n c e : r e a d o n l y
\ _Why : RO of ’ r o o t . c e l l ’ e x i s t s so i t was chosen i n f a v o u r of t h e RW.
[ / a / a ] ( Symbolic Link p o i n t i n g i n t o an AFS−p a t h )
[ / a / admin ] ( AFS−D i r e c t o r y )
|−Volume : r o o t . c e l l
|− D e s c r i p t i o n : Das Z e l l e n−Rootvolume ( u n t e r / a zu e r r e i c h e n )
|− Mountpoint−L o c a t i o n : / a f s / a l p h a
|− I n s t a n c e : r e a d o n l y
\ _Why : ( n o t d i s p l a y e d ) : Type / a / a / s c r i p t s / i n s t a n t a f s . a f s d i r ’ / a / admin ’ t o f i n d o u t
[ / a / admin ] ( AFS−D i r e c t o r y )
/ [ / a / a / . e t c ] ( AFS−Mountpoint )
|−Volume : a . e t c
|− D e s c r i p t i o n : K o n f i g u r a t i o n s f i l e s d e r Z e l l e
|− Mountpoint−Type : r e a d w r i t e (’% a . e t c ’ )
|− I n s t a n c e : r e a d w r i t e
\ _Why : This i n s t a n c e was e x p l i c i t l y r e q u e s t e d by t h e m o u n t p o i n t
9.2.10 instantafs.backup
9.2.11 instantafs.bind-update
9.2.12 instantafs.calcrestore
Dieses Skript fasst 3 Aktionen, die mit dem Backup zu tun haben, zusammen:
1. Synchronisation der Backup-Instanz mit der RW-Instanz zu sichernder
Volumes (siehe 7.2, Seite 141)
2. Synchronisation der RO-Instanzen mit der RW-Instanz zu sichernder Volumes
(siehe 5.5, Seite 109)
3. Auslösen der echten Backups (über das AFS-Backup-System)
I.d.R. wird dieses Tool als cron-Job auf dem Backup-Server aufgerufen - z.B.
einmal pro Tag. Eine Beispieldatei, wie sie unter /etc/cron.d liegen könnte, ist
unter /usr/share/doc/instantafs-doc/examples/instantafs-backup.cron erhältlich.
Die zu sichernden Volumes werden zu Volume-Gruppen zusammengefasst in
der Datei /a/a/etc/backup.conf.
Dieses Skript startet ein manuelles Update der Datenfiles eines DNS-Master-
Servers. Dabei werden alle Dateien (z.B. Zonenfiles und Konfigurationsfiles),
die in /etc/bind/syncfiles aufgeführt sind, per ssh auf die Slave-Server kopiert
und die bind-Instanzen auf den Slave-Servern neu gestartet.
Dieses Skript ermittelt, welche Möglichkeiten bestehen, zerstörte RW-Instanzen
wiederherzustellen. “Zerstört” bezieht sich dabei vor allem auf physische Zer-

198 9 AFS- Kerberos- und InstantAFS-Kommandos
störung (Brand, Diebstahl) sowie auf (z.B. durch Softwarefehler auf Serverseite)
irreparable beschädigte Filesysteme auf den Wirtsplatten von AFS-Servern.
Nicht geeignet ist es hingegen, um versehentliches Löschen durch Benutzer
rückgängig zu machen. instantafs.calcrestore ist geeignet, große Mengen
(viele tausend) von Volumes wiederherzustellen, kann jedoch auch für einzelne
sinnvoll verwendet werden.
instantafs.calcrestore analysiert die Zerstörung partitionsweise. Auf der
Kommandozeile gibt man die zerstörten Partitionen an:
admin@afs>instantafs.calcrestore Funktion Servername/Partition
oder auch
root@afsserver> instantafs.calcrestore Funktion Servername/Partition \
- -localauth
Partition besteht dabei entweder aus einem Buchstaben (für die /vicepx-
Partition) oder aus *, um den Server als komplett zerstört zu kennzeichnen.
Es können beliebig viele Partitionen auf beliebig vielen Servern als zerstört
gekennzeichnet werden.
Bei allen Aktionen verlässt sich instantafs.calcrestore ausschließlich auf Daten
aus der VLDB. Es benutzt die Kommandos vos listaddrs, um die Liste der
AFS-Fileserver und vos listvldb, um die Liste der Volumes und deren Instanzen
zu erhalten. Es werden keine Fileserver direkt kontaktiert. Es muss kein
wirklicher Datenverlust stattgefunden haben, um dieses Tool sinnvoll einsetzen
zu können. Vor allem die -c Option ist auch sinnvoll, um im Vorraus nach fehlender,
jedoch gewünschter Daten-Redundanz im Netzwerk zu suchen.
instantafs.calcrestore beherrscht 3 Modi - alle können ohne Zellensuperuserrechte
benutzt werden. In allen Modi bedeutet ein Exit-Code von 0, dass alle
Volumes wiederherstellbar sind:
Anzeige kritischer Volumes : Der 1. Modus gibt eine Liste der Volumes aus, die nicht automatisch wiederhergestellt
werden können:
user@host>instantafs.calcrestore - -showcritical Server/Partition
Anzeige unkritischer Volumes : Der nächste Modus arbeitet analog zu instantafs.calcrestore
-c , zeigt jedoch genau die Volumes an, die wiederhergestellt werden
können:
user@host>instantafs.calcrestore - -shownoncritical Server/Partition
Skriptgenerierung : Mit diesem Befehl wird ein Shell-Skript (Bourne-Shell) auf STDOUT
geschrieben, das Befehle enthält, um die RW-Instanzen der Volumes von
den zerstörten Partitionen wiederherzustellen:
user@host>instantafs.calcrestore - -makescript Optionen Server/Partition
Folgende Optionen steuern, welche Optionen den Befehlen in dem zu
erzeugenden Shell-Skript mitgegeben werden:
- -localauth : erzeugt AFS-Kommandos mit -localauth-Option. Dadurch ist
es möglich, das erzeugte Skript auf einem AFS-Server ohne AFS-
Client laufen zu lassen.

9.2 InstantAFS 199
- -rorw : erzeugt Code, der vos convertROtoRW-Kommandos enthält.
Damit wird ein sehr schnelles Verfahren 2 benutzt, um RO-Instanzen
auf noch intakten Fileservern in RW-Instanzen zu verwandeln.
-s Neuer Server -p Partition : weist instantafs.calcrestore an, die RW-Instanzen,
die auf zerstörten Servern lagen, auf der angegebenen Partition des
angegebenen Servers neu anzulegen. Entweder diese Option oder
- -rorw muß angegeben werden.
Beispiel:
user@host>instantafs.calcrestore - -makescript - -rorw \
’afsserv2/*’ > /tmp/restore.sh
admin@afs>sh /tmp/restore.sh
Die ersten beiden Modi sind vor allem sinnvoll, um die Datenverluste bei Zerstörung
bestimmter Server abzuschätzen. Man kann sie zur Planung der Datenredundanz
der Zelle einsetzen.
Hinweise für alle Modi:
• Die wiederhergestellten Daten sind i.d.R. nicht 100-prozentig aktuell. Sie
spiegeln den Stand zum Zeitpunkt des letzten vos release-Aufrufes des
entsprechenden Volumes wieder. Den Aufruf von vos release sollte man
automatisiert regelmäßig (z.B. mittels cron) ablaufen lassen.
• Es ist möglich, weitere, nicht mehr brauchbare Server oder Partitionen
zu definieren, deren RW-Instanzen jedoch nicht wiederherzustellen sind
(- -unavailable Server/Partition) bzw. die Wiederherstellungsversuche
auf RO-Instanzen von bestimmten Servern/Partitionen zu
beschränken (Option - -available/Partition). Beispiele:
– Dieses Kommando geht auf den zerstörten Server afsserv1 ein,
greift jedoch zur Wiederherstellung nicht auf Instanzen auf den
Rechnern dontuse1 und dontuse2 zu:
user@host>instantafs.calcrestore Funktion afsserv1/\* \
- -unavailable dontuse1/* - -unavailable dontuse2/*
– Dieses Kommando geht auf den zerstörten Server afsserv2 ein, benutzt
jedoch zur Wiederherstellung nur Instanzen, auf den Rechnern
lasthope1 und auf der Partition /vicepb des Rechners lasthope2:
user@host>instantafs.calcrestore Funktion afsserv2/\* \
- -available lasthope1/* - -available lasthope2/b
• Das Skript kann man auf bestimmte Volumes beschränken. Mit der
Option - -volumepcre PCRE kann man einen PCRE angeben, der auf
alle zu bearbeitenden Volumes matchen muss.
Beispiele:
– Dieses Kommando überprüft, ob alle Homedirectories auf dem
Server afsserv1 bei einem Crash wiederhergestellt werden könnten:
admin@afs>instantafs.calcrestore -c - -volumepcre ’user\..*’ \
afsserv1/\*
2 Die Umwandlungszeit ist unabhängig von der Volumegröße

200 9 AFS- Kerberos- und InstantAFS-Kommandos
9.2.13 instantafs.cellcheck
9.2.14 instantafs.servercheck
• Es ist möglich, automatisch Ersatz für zerstörte RO-Instanzen zu schaffen.
Die Option - -restorero bewirkt, dass, wenn auf den zerstörten
Partitionen eine RO-Instanz lag, eine RO-Instanz des selben Volumes auf
der durch -s und -p angegebenen Partition angelegt wird. Achtung:
Diese Option ist noch experimentell.
Dieses Programm testet die Einhaltung von Regeln, die der Administrator für
Daten im AFS festlegt. Hier einige Beispiele für solche Regeln:
• Auf Partition /vicepa von Fileserver orinoco müssen mindestens 15% des
Speichers frei sein.
• Auf Partition /vicepb von Fileserver mekong darf die Summer der Quota
nicht über 300% der Partitionsgröße liegen.
• Volume root.cell muss mindestens 4mal physisch existieren, wobei die
Speicherorte nicht keinerlei Single-Point-of-Failure 3 haben dürfen.
• Volume root.cell muss einmal in der ersten und einmal in der 2. Etage liegen.
Hintergrund: Wenn zwei Netze nur schwach verbunden sind (z.B.
per VPN über das Internet), kann diese Verbindung schon einmal ausfallen.
Eine solche regel stellt sicher, dass wichtige RO-Instanzen in jedem
der dann getrennten Netze vorhanden sind.
• ...
Ein Beispielfile befindet sich im Paket instantafs.doc .deb . Mit man check.conf
bekommt man Informationen zum Aufbau der Konfigurationsdatei check.conf,
doe instantafs.cellcheck steuert.
Dieses Skript kümmert sich nur um die Ebene der Daten und deren Verteilung
in der AFS-Zelle. Will man den Zustand der Dienste und Server untersuchen,
bietet sich instantafs.servercheck an.
Mit diesem Programm können Probleme identifiziert werden, die mit den Serverprozessen
selbst zu tun haben. Es untersucht alle Datenbankprozesse, alle
Fileserverprozesse und alle Backup-Server-Prozesse auf Unstimmigkeiten und
Probleme (siehe 8.7, Seite 184) hin und macht Vorschläge, wie diese zu beseitigen
sind. Außerdem überprüft es den Zustand der bosserver-Prozesse auf
allen AFS-Servern der Zelle und analysiert die AFSDB-Records des DNS. Hier
einige Beispiele:
als Zellensuperuser : Mit Zellensuperuserrechten geht es mit diesem Kommando. Achtung: ein
laufender AFS-Client ist dafür nötig!:
admin@afs>instantafs.servercheck - -cell cbs.mpg.de server5 server6
- -localauth : Als Root auf einem AFS-Server (kein AFS-Client nötig):
admin@afs>instantafs.servercheck - -localauth - -cell cbs.mpg.de \
server5 server6
3 Es lassen sich Gruppen von AFS-Datenpartitionen definieren, die irgendwie zusammenhängen
(z.B. weil sie auf das selbe RAID zugreifen)

9.2 InstantAFS 201
- -nokeycheck : Ohne Superuserrechte. Dabei werden alle Überprüfungen übersprungen,
bei denen AFS-Superuserrechte benötigt werden:
admin@afs>instantafs.servercheck - -nocellroot - -cell cbs.mpg.de \
server5 server6
9.2.15 instantafs.getvoldirs
9.2.16 instantafs.homedir
9.2.17 instantafs.kcheckpass
9.2.18 instantafs.kerberos
Hinweise:
• Es müssen unbedingt alle DB-Server angegeben werden. Das ist nötig,
um zu überprüfen, ob im DNS und in den DB-Serverlisten der
AFS-Server auch wirklich alle DB-Server eingetragen sind.
• instantafs.dbcheck überprüft auch die bekannten AFS-Schlüssel der
DB-Server. Dazu sind allerdings Zellenadministrator-Privilegien (entweder
durch ein entsprechendes Token oder über einen lokal erreichbaren
AFS-Schlüssel auf einem AFS-Server) nötig. Verfügt man beim Aufruf
nicht über solche Privilegien, sollte man die Option - -nokeycheck
anfügen um entsprechende Fehlermeldungen zu minimieren.
• instantafs.servercheck überwacht die untere Ebene des AFS - also
die Server selbst sowie die Dienste. Um alles darüber kümmert sich
instantafs.cellcheck.
Dieses Skript kann IDs von Volume-Instanzen in die entsprechenden Pfade auf
dem AFS-Fileserver umrechnen - also den Speicherort der Files eines Volumes
im VFS des Fileservers ermitteln.
Auch der umgedrehte Weg ist möglich - also die Ermittlung der Instanz-ID aus
einem Pfad einer Datenpartition.
Dieses Skript ist als Demonstration gedacht. Es dient dazu, ein bereits erstelltes
Homedirectoryvolume mit sicheren Zugriffsrechten zu versehen. Es wird
üblicherweise nur als Unterprogramm von instantafs.acall-usermgr
(siehe 9.2.6, Seite 195) auf dem db-acall-Server (siehe 7.6.2, Seite 149) aufgerufen.
Sie sollten dieses Skript auf dem db-acall-Server an die Gegebenheiten ihrer
Zelle anpassen.
Dieses Skript ist im Gegensatz zu den anderen InstantAFS-Skripten im Paket
instantafs-client .deb enthalten. Wird instantafs-client .deb installiert, ersetzt es
per dpkg-divert das unter KDE2 und KDE3 verwendete kcheckpass.
Sperrt ein Benutzer seinen KDE-Desktop und gibt ihn danach per Eingabe seines
Passwortes wieder frei, dann überprüft dieses Tool das Passwort und benutzt
es, um den AFS-Token des Nutzers aufzufrischen.
Dieses Skript hat mehrere Funktionen:

202 9 AFS- Kerberos- und InstantAFS-Kommandos
9.2.19 instantafs.release (Kurzform: iarel)
user@host>iarel root.cell
user@host>iarel -d ∼
9.2.20 instantafs.remote
• Mit ihm können auf komfortable Weise Kerberos-Keytabs (siehe 3.10.3,
Seite 63) an Rechner einer AFS-Zelle verteilt werden. Damit sich Benutzer
überall ohne Passwort einloggen können (siehe 7.3.2, Seite 143), sollte
jeder Computer, vor allem jeder Arbeitsplatzrechner, einen Kerberos-
Principal besitzen. Dieses Skript lässt sich auch auf eine größere Menge
Computer anwenden. Außerdem lässt es sich leicht automatisieren.
Sicherheitsbewusste werden anmerken, dass es keine gute Idee ist,
Kerberos-Schlüssel übers Netz zu schicken. Man sollte jedoch bedenken,
dass der Kerberos-Schlüssel eines Dienstes auf einer Workstation, zu der
Benutzer physischen Zugang haben, sowieso unsicher gelagert wird. Der
worst case wäre, dass sich ein Angreifer als root auf der Workstation
einloggt, was auch mit einer Boot-CD (z.B. Knoppix) gelingt. Zugriff auf
das AFS-Filesystem mit erhöhten Rechten ist so jedoch nicht möglich
(siehe 7.3.1, Seite 142).
• Es kann bei Bedarf (also bei einer Änderung), oder auf Wunsch, die
Kerberos-Datenbank vom Master- zu den Slave-Servern kopieren werden.
Dieses Skript wird bei Bedarf ausgelöst und updated dann die
Kerberos-Slave-Server. Es kommt ausschließlich auf dem Kerberos-
Master-Server zum Einsatz (siehe 4.4.4.5.2, Seite 89). Dieses Kommando
benutzt nicht den kpropd sondern ausschließlich ssh, um die
Kerberos-Datenbank an die Slave-Server der Zelle zu schicken.
Dieses Kommando ist ein Wrapper um vos release, der automatisch eine funktionierende
Authentifikationsmethode wählt. Folgendene Authentifikationsmethoden
werden unterstützt:
local : Authentifikation per -localauth-Option, also mittels eines lokal unter
/etc/openafs/server/KeyFile gespeicherten AFS-Key
token : Authentifikation mittels des aktuellen Tokens
acall : Aufruf der acall-Funktion instantafs.acall-release auf dem acall-db-
Server – die Einzige Methode, die normale Benutzer verwenden können.
Dieses Kommando ist nützlich, um normalen Benutzern die Möglichkeit zu geben,
einzelne Volumes zu verwalten (siehe 7.10, Seite 158).
Hier einige Anwendungsbeispiele:
• Das Root-Volume der Zelle releasen:
• Das eigene Homedirectory releasen:
Dieses Kommando wird von instantafs.setup und von einigen Routinen des
instantafs-customclient .deb -Paketes (siehe 7.14.1, Seite 168) benutzt, um
AFS-Clients, AFS-Server und andere Server, die für AFS notwendig sind, zu
konfigurieren.
Das funktioniert mit instantafs.setup z.B. wie folgt:

9.2 InstantAFS 203
1. Der Administrator richtet eine Zelle mit instantafs.setup ein und wählt
afsinit im Hauptmenü aus - die Funktion, für die Grundkonfiguration
von AFS-Servern.
2. instantafs.setup ruft die call_helper()-Funktion für jeden AFS-
Server auf.
3. call_helper() schickt die XML-Konfigurationsdatei der aktuellen
Zellenkonfiguration zum Server:
user@host>scp /tmp/config.xml root@10.2.1.1:/tmp/config.xml
(vereinfacht)
und startet ssh für jeden Aufruf in dieser Form:
user@host>ssh root@10.2.1.1 instantafs.remote - -config /tmp/config.xml \
afsinit
9.2.21 instantafs.setquota
9.2.22 instantafs.setup
9.2.23 instantafs.tokenmgr
9.2.24 instantafs.tool (Kurzform: iat)
(vereinfacht)
In Wirklichkeit werden i.d.R. einige zusätzliche Optionen an instantafs.remote
übertragen. Auch werden u.U. spezielle Optionen für ssh benutzt.
Letztendlich wird auch nicht /tmp benutzt, um die Konfigurationsdatei
zwischenzuspeichern. Die genauen Kommandos werden angezeigt, wenn
instantafs.setup im Debug-Modus läuft (Menüpunkt “options/debug”).
4. instantafs.remote erkennt anhand des Schlüsselwortes afsinit, dass
der Grundstein für eine AFS-Serverinstallation gelegt werden soll und
richtet die nötigen Konfigurationsfiles entsprechend der Zellenkonfiguration
in /tmp/config.xml ein.
Mit diesem Programm können Volumequotas neu gesetzt werden. Dabei wird
per acall die Funktion instantafs.acall-serquota aufgerufen, die wiederum anhand
der Datei /a/admin/etc/acall-setquota.conf entscheidet, ob die Modifikation
erlaubt ist, oder nicht.
Diese Funktion ist vor allem für "kleine Administratoren", die zwar Benutzer
verwalten sollen, jedoch nicht die volle Kontrolle über die Zelle bekommen
dürfen.
Dieses Tool ist das Setup-Programm von InstantAFS. Es besitzt eine dialogbasierte
Benutzerschnittstelle und zeigt bei Bedarf jeden Schritt der Installation
einzeln an. Der Ablauf der Installation ist unter 4.3 (Seite 69) beschrieben.
Dieses Tool ist für die komfortable Handhabung von AFS-Tokens gedacht. Es
kann ausschliesslich mit MIT-Kerberos5 arbeiten. Einige Beispiele sind in der
man-Page enthalten. Es gibt auch eine ausführlichere Anleitung im Internet:
http://fbo.no-ip.org/tokenmgr
Dieses Tool enthält nützliche Funktionen, die vor allem zum schnellen Manuellen
Analysieren und Manipulieren der eigenen AFS-Zelle dienen.

204 9 AFS- Kerberos- und InstantAFS-Kommandos
9.2.25 instantafs.usermgr
Das umfasst z.B. Funktionen, die mit Volumes umgehen, dabei aber ein Batchfreundlicheres
Format erwarten.
Die man-page bietet weitere Informationen.
Mit diesem interaktiven Tool können Benutzer verwaltet werden. Das umfasst
die folgenden Tätigkeiten:
• Anlegen von Benutzern
• Löschen von Benutzern
• Deaktivieren von Benutzern, d.h. vorrübergehendes Sperren des Zugangs
• Aktivieren von Benutzern, d.h. Aufheben einer vorrübergehenden Sperre
• Ändern von Benutzerpasswörtern
Hinweise:
9.2.26 instantafs.volgrep (Kurzform: volgrep)
• Dieses Tool wird niemals Daten löschen. Homedirectories von neuen Benutzern
werden zwar erzeugt, jedoch wird niemals ein Homedirectory gelöscht
- es verbleibt vielmehr mit dem Namen user-na.
auf dem Fileserver.
• Dieses Tool muß das Recht haben, auf verschiedenen Servern bestimmte
acall-Funktionen (siehe 7.6.2, Seite 149) aufzurufen:
ia:usermgr : wird benötigt, um den Kerberos-Account, den Eintrag in die PT-
Datenbank und den Samba-Account eines Benutzers zu bearbeiten
(siehe 9.2.6, Seite 195).
ia:volcreate : wird eingesetzt, um das Homedirectory von neuen Benutzern anzulegen.
InstantAFS setzt diese Rechte bei der Installation für den AFS-Benutzer
uadmin. Man kann das auch manuell machen - die Beispiel-Files unter
/usr/share/doc/instantafs-doc/examples helfen da weiter.
• Mit der Option - -nosamba wird der Zugriff auf das Samba-Gateway
verhindert. Das ist u.U. nötig, wenn kein Samba-Gateway vorhanden ist,
da dann die entsprechenden Fehlermeldungen stören.
Weitere Informationen finden man unter 7.9 auf Seite 155.
Dieses Kommando zeigt eine Liste von Volumes an, die bestimmten zu definierenden
Kriterien entsprechen. Die Syntax ist dabei folgende:
user@host>volgrep Optionen Kriterium=Wert ...
user@host>volgrep - -help
Weitere Hilfe erhält man mit:
Dieses Kommando zeigt auch alle gültigen Kriterien an, nach denen Volumes
gefiltert werden können.

9.2 InstantAFS 205
9.2.26.1 Selektionsbedingungen
9.2.26.2 Anzeigemodi
Format OptionErklärung
Alle Instanzen -I Anzeige aller Instanzen matchender
Volumes
Alle instanzen (2) -u Anzeige aller Instanzen des Volumes
als URLs
Alle Informationen -l Ausgabe des gesammten Volume-
Datenblocks als Perl-Code
Alle Informationen -x Ausgabe des gesammten Volume-
(XML)
Datenblocks als XML
RW-Instanzen -r Anzeige der URLs der RW-
Größeninformationen -t
Instanzen selektierter Volumes.
Anzeige des Volume-Namens, sowie
der Quota und der Groesse der
RW-Instanz
Tabelle 9.2: Anzeigeoptionen von instantafs.volgrep
Es können beliebig viele Kriterium=Wert-Gruppen angegeben werden. Alle
angezeigten Volumes müssen alle diese Ausdrücke erfüllen. Ausserdem kann
man Globber-Ausdrücke, denen Volumes genügen müssen, ohne = angeben,
solange sie kein =-Zeichen enthalten.
Hier einige Beispiele:
user@host>volgrep rolocation=afsserv1/a
zeigt alle Volumes an, von denen auf afsserv1 auf Partition a eine RO-Instanz
liegt.
user@host>volgrep pcrename=’.[a-z].*’ ’rwlocation=afsserv2/*’
user@host>volgrep user.\*
zeigt alle Volumes, deren zweites Zeichen im Namen ein kleiner Buchstabe ist
und deren RW-Instanz auf afsserv2 liegt.
zeigt alle Volumes an, die mit user. beginnen.
user@host>iarel ‘volgrep user.\* ‘
9.2.27 instantafs.vsserver
unterzieht alle Benutzerhomedirectories einem vos release.
Die ausgewählten Volumes werden per default einfach mit Namen - eines pro
Zeile - angezeigt. Durch Optionen (siehe Tabelle 9.2) läßt sich das Ausgabeformat
ändern.
Dieses Programm sammelt Informationen (z.B. Volumenamen, Quotainformationen,
Zugriffsstatistiken und Daten über den verfügbaren Speicher) aus der
Zelle ein und legt sie an definierter Stelle (/a/a/.cellinfo per default) in ein komprimiertes
XML-File.

206 9 AFS- Kerberos- und InstantAFS-Kommandos
9.2.28 instantafs.vtapes
Mehr dazu unter 7.15 auf Seite 169.
9.3 Wichtige AFS-bezogene Kommandos
instantafs.vtapes ist die Schnittstelle zwischen dem AFS-Backup-
System und den auf einer oder mehreren großen Platten archivierten virtuellen
Backup-Bändern (vtapes). Weiteres zu diesem Skript ist im Abschnitt Backup
(siehe 5.2, Seite 100) beschrieben.
In Tabelle 9.3 sind wichtige Kommandos aufgelistet, die für AFS-Benutzer und
-Administratoren von Interesse sind. In Spalte BC ist vermerkt, ob InstantAFS
für das entsprechende Programm Bash-Completion 4 ermöglicht.
4 die automatische Vervollständigung von Parametern dieses Kommandos in der Bourne Again
SHell

9.3 Wichtige AFS-bezogene Kommandos 207
Kommando BC Paket Beschreibung
aklog - openafs-krb5 .deb aklog holt mit dem im Credentials-Cache gespeicherten Kerberos5-TGT ein Ticket für den
afs-Service. Anschließend wandelt es dieses Service-Ticket in einen Token um und legt es im
Kernel ab. Dieses Kommando muss bei Benutzung von AFS nach kinit ausgeführt werden,
um Zugriff auf das AFS zu erlangen.
asetkey - openafs-krb5 .deb Dieses Kommando ist nötig, um eine MIT-Kerberos5-Keytab in eine AFS-Schlüsseldatei umzuwandeln.
Außerdem können damit auch Schlüssel in einer AFS-Schlüsseldatei angezeigt
bzw. gelöscht werden.
backup - openafsclient
.deb
Mit backup wird die BDB manipuliert und werden AFS-Backups/Rücksicherungen ausgelöst.
balance - balancer-afs .deb Dieses Programm wird für automatisches Loadbalancing für RW-Daten im AFS benutzt (siehe
6.11.2, Seite 133).
√
bos
openafsclient
.deb
Mit den zahlreichen Unterkommandos von bos wird der bosserver auf AFS-Server-
Maschinen gesteuert. In [ADMREF] sind alle Unterkommandos detailiert beschrieben. Onlinehilfe
ist mit bos help abrufbar.
cdb - (openafs-source) Dieses Tool kann benutzt werden um binäre Debug-Files von Fileservern (siehe 6.10.1.2, Seite
126) im Klartext auszugeben.
√
dumptool
(openafs-tools) Mit diesem Tool ist es möglich, aus Volume-Dumps einzelne Dateien zu extrahieren.
√
fs
openafs-client Die Unterkommandos dieses Tools dienen der Steuerung des lokalen Cachemanagers. Außerdem
lassen sich damit bestimmte AFS-spezifische Aktionen im AFS-Namensraum durchführen
(z.B. Anlegen von Volume-Mountpoints). Die Unterkommandos von fs sind in
[ADMREF] beschrieben. Onlinehilfe ist mit fs help abrufbar.

208 9 AFS- Kerberos- und InstantAFS-Kommandos
√ .deb kadmin
krb5-user Dieser Befehl ist eine kleine Shell, mit der sich die Kerberos-Datenbank auf einem entfernten
Server (Berechtigung vorrausgesetzt) manipulieren lässt. Mit kadmin lassen sich z.B. Principals
anlegen und Keytabs für Principals erzeugen.
√
kadmin.local krb5-adminserver
.deb
Dieser Befehl funktioniert ähnlich wie kadmin. Er kann nur auf dem Kerberos5-Master-
Server eingesetzt werden und verlangt keine Authentifikation (root-Rechte auf dem Server
vorrausgesetzt).
√ .deb kinit
krb5-user Dieses Kommando holt vom Kerberos5-Server ein TGT. Dazu ist i.d.R. die Eingabe eines
Passwortes nötig.
√
pts
openafsclient
.deb
Mit den Unterkommandos von pts ist der Zugriff auf die PTDB möglich (also die Manipulation
und das Auslesen von Informationen über AFS-Benutzer und AFS-Benutzergruppen). Die
Unterkommandos von pts sind in [ADMREF] beschrieben. Onlinehilfe ist mit pts help
abrufbar.
tokenmgr - instantafs .deb Mit tokenmgr lassen sich verschiedene häufig auftretende Prozeduren vereinfachen, die damit
zu tun haben, einen AFS-Token zu holen und aktuell zu halten.
unpagsh - openafs-tools .deb Dieses Kommando startet eine Shell, die sich in keiner PAG (siehe 3.7.2.3, Seite 49) befindet.
Achtung: Das funktioniert nur unter Kernel 2.4.
√
udebug
openafsclient
.deb
udebug zeigt Informationen über AFS-DB-Server an.
√
vos
openafsclient
.deb
Die Unterkommandos von vos dienen dem Zugriff auf AFS-Daten auf Volume-Ebene sowie
dem Auslesen und der Manipulation der VLDB. In [ADMREF] sind die Unterkommandos
beschrieben. Informationen über vos convertROtoRW befinden sich unter 5.7.1, Seite 111.
Onlinehilfe gibt’s mittels vos help.

10 Andere Betriebssysteme und Plattformen
10.1 Windows
10.1.1 Allgemeines zu 32bit-Windows
10.1.2 Allgemeines zu NT-basierten Windows-Versionen
AFS läuft auf vielen Betriebsystemen nativ. Da sich diese Dokumentation sonst
primär auf Debian GNU/Linux konzentriert, sollen in diesem Kapitel einige
Hinweise zur AFS-Installation auf anderen Systemen gegeben werden. Dabei
geht es immer nur um AFS-Clients, nicht um Server.
Jegliche Software, die für den Zugriff auf Windows-Clients benötigt wird, kann
von der InstantAFS-Homepage heruntergeladen werden. Diese Clients wurden
nicht im Rahmen des InstantAFS-Projektes entworfen - jedoch ist es in der
Regel komfortabler, wenn man alles an einer Stelle findet. Die Original-URLs
sind jeweils mit angegeben.
Die 32bit-Versionen der Windows-Client-Software beinhalten jeweils ein grafisches
Installationsprogramm. Außerdem ist ein grafisches Konfigurationsinterface
enthalten. Hinweise:
• Der AFS-Client ist ein Windows-Dienst, kann deshalb nur von Administratoren
gestartet werden.
• Neben den Kommandozeilentools fs, vos, bos steht ein grafisches Interface
für AFS-spezifische Filesystem-Operationen als Shell-Erweiterung
(Rechte Maustaste auf ein Verzeichnis im Explorer ...) zur Verfügung.
Damit können ACLs, Mountpoints und Quotas eingesehen und manipuliert
werden.
OpenAFS wird für Windows i.d.R. als Installierbares Paket vorkompiliert verteilt.
Es ist auch möglich OpenAFS selbst zu übersetzen. Gleiches gilt für den
Kerberos-Client.
Die OpenAFS-Quellen enthalten Code, um OpenAFS-Server unter Windows
betreiben zu können. Grundsätzlich ist aber davon abzuraten einen Windows-
AFS-Server im Produktivbetrieb zu haben. Gründe sind:
• Der Code wird nicht aktiv weiterentwickelt/gewartet.
• Der Server funktioniert bei aktuellen OpenAFS-Versionen nicht.
• Die Performance ist schlechter als auf einem Linux-Server
• Man benutzt keine Windows-Server, wenn Unix-Server die selbe Aufgabe
erfüllen können
Für Bastelzwecke kann von der InstantAFS-Homepage trotzdem ein funktionsfähiger
OpenAFS-Server für Windows heruntergeladen werden.
209

210 10 Andere Betriebssysteme und Plattformen
10.1.3 Windows 3.11
10.1.4 Windows 95, 98, ME
10.1.5 Windows NT 4.0
10.1.5.1 Installationsanleitung
10.1.6 Windows 2000, XP
Für Windows 3.11 existiert kein nativer AFS-Client. Es wird auch nie einen
geben. Solche Clients können jedoch per SMB über ein Samba-Gateway auf
den AFS-Namensraum zugreifen, wobei auch authentifizierter Zugriff möglich
ist. AFS-Sonderfunktionen wie das Auslesen von Quotainformationen oder das
Setzen von ACLs können mit dieser Lösung jedoch nicht benutzt werden.
Für Windows 98 steht ein simpler Client zur Verfügung, der jedoch nicht gepflegt
wird. Auch unterstützt er keine Authentifikation via Kerberos5. Wenn ein
Kerberos5-Server für die Zelle benutzt wird (was unter InstantAFS zwingend
ist), ist deshalb nur anonymer Zugriff auf das AFS möglich.
Für Windows NT 4.0 (alle Versionen) steht eine ältere Version von Open-
AFS (1.2.9a) zur Verfügung. Der AFS-Client setzt zwar nur einen Rechner
vorraus 1 , jedoch handelt es sich im Kern um einen lokal laufendes AFS-zu-
SMB-Gateway. Um authentifiziert auf das AFS zugreifen zu können, ist die
Installation des MIT-Kerberos5-Clients nötig.
Hinweise:
• Der NT4-AFS-Client wird nicht mehr gewartet. Wechseln sie auf eine
aktuellere Windows-Version bzw. auf ein Unix-Betriebssystem.
Gerüchte:
• Dieser AFS-Client soll bei dieser alten Version Probleme mit sog. überlappenden
Schreibzugriffen, wie sie u.a. von MS-Office Anwendungen
durchgeführt werden, haben.
• Die Unterscheidung verschiedener Benutzer - z.B. bei mehreren Sitzungen
eines Terminalservers - soll Probleme bereiten. Benutzer können u.U.
mit Rechten arbeiten, die eigentlich einem anderen gerade eingeloggten
Benutzer zustehen. Dieses Problem ist in neueren Versionen behoben.
Der Kerberos5-MIT-Client sowie der OpenAFS-Client sind manuell zu installieren.
Alternativ stehen MSI-Pakete für beide Clients zur Verfügung.
Für neuere Windows-Versionen auf NT-basis steht ein aktueller AFS-Client zur
Verfügung, der vom Aufbau her mit der Windows NT4.0-Version vergleichbar
ist. Folgende Windows-Versionen fallen darunter:
• Windows 2000 Workstation und Server
• Windows XP Home und Professional
• Windows 2003 Server und R2 Server
Dieser Client wird sehr aktiv weiterentwickelt, unter http://web.mit.
edu/jaltman/Public/OpenAFS/ gibt’s immer die aktuellste Version
- auch als MSI-Paket sowie als Debug-Version, die man benötigt, um den
Entwicklern bei Problemen wichtige Informationen zukommen zu lassen.
1 Im Gegensatz zum sog. AFS-Light-Gateway

10.1 Windows 211
10.1.6.1 Installationanleitung
Diese Anleitung deckt folgende AFS-spezifische Konfigurationen ab:
• Authentifizierter und anonymer Zugriff auf das AFS
• Zur Authentifikation wird der MIT-Kerberos5-Server benutzt - Active Directory
ist nicht notwendig.
• Automatisches Kerberos-TGT- und Token-Holen beim einloggen wenn
Windows-Passwort und Kerberos-Passwort übereinstimmen.
Diese Anleitung kann folgendes nicht 2 bieten:
• Windows-Benutzerprofile im AFS
• Wartungsarme Benutzereinrichtung. Alle Nutzer, die an einem gegebenen
Rechner mit AFS arbeiten müssen, müssen von Hand als lokale Benutzer
angelegt werden.
Zuerst müssen alle benötigten Dateien heruntergeladen werden:
• Der OpenAFS-Client
• Der Kerberos-Client
• Das afsk5log.exe -Binary sowie das dazugehörige Batch file afsk5log.bat.
Beide werden ins Windows-Verzeichnis (also z.B. c:\windows gelegt)
und müssen/dürfen nicht von Benutzern veränderbar sein.
Die Installation beginnt mit dem OpenAFS-Client. Angemeldet muss man natürlich
als benutzer mit lokalen Administratorrechten sein. Hier wird von einer
manuellen Installation per Ausführbarem Installer-Binary ausgegangen - .msi-
Pakete stehen auch zur Verfügung.
Man wähle die Sprache English. Installiert werden müssen die Komponenten
AFS Client und MS Loopback Adapter - letzterer erhöht die Stabilität bei wechselnden
Netzwerkinterface-Zuständen wie sie z.B auf WLAN-tauglichen Notebooks
oder auf DHCP-benutzenden Rechnern vorkommen. Als CellServDB
kann man die dem Paket beiliegende nehmen - die eigene Zelle wir später per
DNS erschlossen.
Als Zellenname gibt man (kleingeschrieben!) die eigene Zelle ein und check
sämmtliche Checkboxen an.
2 Zumindest zum jetzigen Zeitpunkt

212 10 Andere Betriebssysteme und Plattformen
Es folgt die Konfiguration des System-Tools, das als kleines Symbol z.B. auf
abgelaufene Tickets hinweist. Hier müssen alle Checkboxen angecheckt sein -
mit Ausnahme von Show credentials window on startup.
Der OpenAFS-Installer beendet die Installation, ein Neustart ist fällig. Ohne
den Neustart kann man den OpenAFS-Client nicht konfigurieren. Weiter macht
man dann wieder als Nutzer mit Administratorrechten.
In der Systemsteuerung ruft man die AFS Client Configuration auf. Im Tab
General muss die Option Optain AFS tokens when logging into Windows:
Im Tab Drive Letters wird definiert, welche Laufwerksbuchstaben auf welche
AFS-Pfade zeigen sollen. Am MPI/CBS ist Standard, die lokale Zelle auf Laufwerk
F zu legen. Es ist sinnvoll, wenn diese Verbindungbei jedem erneuten
Einloggen wiederhergestellt wird, also wird Restore this mapping whenever I
logon angecheckt. Der text im Submount-Feld wird später als Laufwerks-Label
im Filemanager gezeigt - ÄFSïst ein sinnvoller Text.

10.1 Windows 213
Im Tab Advanced werden jetzt noch nervice Hinweise deaktiviert, die auftauchen,
wenn das Windows-Passwort nicht mit dem Kerberos5-Passwort übereinstimmt.
Dazu wählt man Logon.. und setzt dort Fail Logins Silently auf Yes.
Jetzt zur Kerberos-Installation. Wieder wird vom ausführbaren Installer ausgegangen.
Dieser fragt nach einer Sprache und erhält vom Administrator English
als Antwort.
An Komponenten wird lediglich der KfW Client benötigt.
Der Installer bietet an, ihn im vorraus mit Konfigurationsinformationen zu befüllen.
Man lade die entsprechende Datei (krb5.ini) herunter. Dann wird das
heruntergeladene File als Quelle für Konfigurationsinformationen angegeben.
Achtung: Direkt aus dem Kerberos-Installer herunterladen ist aufwendiger.
Im Dialog Kerberos Configuration müssen die Checkboxen Autostart the Leash
ticket manager each time you Login to Windows und Ensure that Kerberos tickts
are available throughout the Windows logon session [-autoinit] angecheckt

214 10 Andere Betriebssysteme und Plattformen
sein.
Eine Anpassung in der Registry sorgt dafür, dass beim Windows-Logon wirklich
ein TGT geholt wird und sich der Kerberos-Support nicht in Authentifikation
erschöpft. Der Schlüssel
HKLM/SYSTEM/CurrentControlSet/Control/Lsa/Kerberos/Parameters/AllowTGTSessionKey
muss ein dword mit dem Wert 1 sein.
Die Datei afsk5log.bat wird in den Autostart-Ordner für alle Benutzer per Verknüpfung
verlinkt. Das stellt sicher, dass das TGT beim Logon in ein Token
umgerechnet wird.
Jetzt muss man Windows noch dazu bringen, mit einem non-MS-Kerberos-
Server zusammenzuarbeiten. Dazu wird einige Aufrufe von ksetup.exe nötig:
c:\>ksetup /SetRealm Kerberos-Realmname
c:\>ksetup /MapUser * *
Das folgende Kommando definiert die Kerberos-Server für eine bestimmte Domaine.
Kerberos-Server werden hier nicht angegeben, was Windows veranlasst,
im DNS nach KDCs zu suchen.
c:\>ksetup /AddKdc Rechnername in Grossschreibung
10.1.7 Windows XP 64bit
10.1.8 Windows Vista
Jetzt ist ein Reboot fällig. Anschliessend kann man sich als beliebiger normaler
Nutzer einloggen Jedoch funktioniert das automatische Token-Holen erst bei
zweiten einloggen eines jeden Nutzers. Beim Einloggen ist als Domäne der
aktuelle Rechnername auszuwählen.
Unter http://web.mit.edu/jaltman/Public/OpenAFS/ kann
man MSI-Pakete für 64bit-Windows herunterladen.
Windows Vista wird derzeitig von OpenAFS unterstützt, jedoch gibt es Komplikationen
im Zusammenhang mit den Stromsparfunktionen. Wenn Windows in
Sleep-Mode geht und die Netzwerkinterfaces herunterfahren, bricht der AFS-
Client die Verbindung zu Fileservern ab, womit die AFS-Filehandles von offenen
Dateien ungültig werden. Solange der Stromsparmodus nicht benutzt wird,
gibt’s keine Probleme.
(Stand: 09.01.2007)
10.2 andere Linux-Distributionen
10.3 Fedora Core
Das Übersetzen von OpenAFS-Kernelmodulen für den laufenden Kernel geht
so (nicht selbst getestet):
1. Man besorge sich das neues Source-RPM-File - z.B. hier:
http://www.openafs.org/release/latest.html
Die OpenAFS-Client-Pakete findet man auch auf dieser Seite.

10.4 andere Unix-Derivate (z.B. MacOSX) 215
2. Das Source-RPM wird übersetzt:
user@host>rpmbuild - -rebuild - -target=i686 openafs-version.src.rpm
10.4 andere Unix-Derivate (z.B. MacOSX)
10.4.1 MacOS X
Es stehen vorkompilierte Pakete für MaxOSX 10.1 (leider vollkommen ungetestet)
bis MaxOSX 10.4 zur Verfügung. Alle Pakete können auf der InstantAFS-
Homepage heruntergeladen werden. Getestet wurde die Installation nur unter
MacOSX 10.3 und MacOSX 10.4. Für MacOSX 10.4 existiert ein Universal
Binary - es läuft also auch auf Intel-Prozessoren.
Im Rahmen von InstantAFS steht ein modifiziertes OpenSSH-Paket für Linux
zur Verfügung, das es u.a. ermöglicht, sich passwortlos von einem MacOSX-
System auf ein Linux-System und umgekehrt einzuloggen gssapi-mitm, wobei
jeweils auch ein Token auf dem Zielsystem erzeugt wird.
Hinweis: InstantAFS-Tools stehen unter MacOSX nicht zur Verfügung (Stand:
01.12.2005) - die Zeit war einfach zu knapp. Prinzipiell sollte es jedoch funktionieren
- Perl ist schliesslich sehr portabel.
10.4.1.0.1 Installationsanleitung Die Installation ist ein wenig zerstückelt
- man muss mehrere Pakete instalieren und einige Konfigurationsdateien anpassen,
die man alle unter dieser URL findet:
ftp://instantafs.cbs.mpg.de/instantafs/collection/
clients/macosx
Die zu installierenden Pakete sind dabei nach MacOSX-Version sortiert.
Folgende Files muss man erstmal auf den MacOSX-Rechner kopieren:
openafs-macosx(Version)-... : Das OpenAFS-Paket für MacOSX. Es sind verschiedene Versionen verfügbar:
orig : Ein OpenAFS-Paket von http://www.openafs.org - also
hochoffiziell.
improved : Ein selbstgepacktes Paket, bei dem einige Modifikationen vorgenommen
wurden. Mehr informationen zu diesen Modifikationen
und zum Mac-Openafs-Selberpacken gibt’s unter:
http://fbo.no-ip.org/cgi-bin/twiki/view/Instantafs/
MacAfsBuild
kerberos_extras-macosx.dmg : Das Ticket-Management-Tool, das auf dem MacOSX-eigenen Kerberos
aufsetzt.
Hinweis: Unter MacOS 10.4 Tiger erzeugt dieses Programm lediglich
einen Link auf den vorhandenen aber gut versteckten systemeigene
Ticket-Manager.
aklog-kerberos-plugin-1.0.dmg : Ein Plugin für Kerberos, dass nach einer erfolgreichen Kerberos-
Authentifikation automatisch ein AFS-Token generiert.
Hinweis: Das Plugin befindet sich dann unter /Library/Kerberos Plug-
Ins/aklog.loginLogout. Es ist in die Kerberos-Library integriert und nicht
in ein spezielles Kerberos-Tool (z.B. kinit).
aklog : Das aklog-Tool. Es ist für Einzellenbetrieb nicht unbedingt erforderlich,
jedoch schadet es nicht.

216 10 Andere Betriebssysteme und Plattformen
Jetzt muss man folgendes machen:
1. Zuerst muss das OpenAFS-, danach das Kerberos-Paket installiert werden.
2. Als root muss man einiges auf der Kommandozeile tun (Als Editor bietet
sich vi an - der ist bei MacOSX dabei):
• /var/db/openafs/etc/ThisCell muss den Namen der AFS-Zelle enthalten
- z.B. rivers.de.
• Die CellServDB sollte am besten gelöscht werden - die vielen
Zellennamen verwirren sonst die Mac-User:
root@host>echo -n > /var/db/openafs/etc/CellServDB
[ l i b d e f a u l t s ]
d e f a u l t _ r e a l m = RIVERS . DE
n o a d d r e s s e s = TRUE
l o g i n _ l o g o u t _ n o t i f i c a t i o n = " a k l o g "
t i c k e t _ l i f e t i m e = 93600
f o r w a r d a b l e = t r u e
p r o x i a b l e = t r u e
• In /var/db/openafs/etc/cacheinfo muss man als letztes Feld die gewünschte
Cachegröße in kB angeben (siehe 3.5.2.3, Seite 40).
• In /var/db/openafs/etc/config/afsd.options gibt man dem Cachemanager
diverse Optionen mit. Folgende Konfiguration (siehe
3.5.2, Seite 39) ist sinnvoll:
-stat 2000 -dcache 800 -daemons 3 -volumes
1200 -fakestat-all -afsdb.
• Das File /Library/Preferences/edu.mit.Kerberos ist das Äquivalent
von /etc/krb5.conf unter Linux. Es muss wie folgt aussehen (wobei
der Beispiel-Realm-Name RIVERS.DE durch den gewünschten
Namen ersetzt werden muss):
Listing 10.1: /Library/Preferences/edu.mit.Kerberos
3. Die Kerberos-Extras umfassen ein Programm, mit dem man komfortabel
Tickets (und durch das aklog-Plugin auch Tokens holen kann).
Hinweise:
• Es ist vorteilhaft, sich dieses Tool (Siehe Programme/Dienstprogramme/Kerberos
) ins Dock zu ziehen.
• Das Dock-Icon zeigt die noch verfügbare Zeit des Tickets und
des Tokens an ( Stunden:Minuten ) und warnt vor Ablauf des
Tickets/Tokens.
• Es ist nicht möglich, in einer InstantAFS-Zelle das Kerberos-
Passwort in diesem Tool zu setzen (siehe 2.3, Seite 18).
• Dieses Programm kann maximal 10h-gültige Tickets besorgen, obwohl
in InstantAFS 26h der default sind. Benutzt man kinit -l 26h,
ist diese Einschränkung nicht gegeben.
Um MacOSX’ Versuche, Metadaten in Netzwerkverzeichnisse zu schreiben,
abzuschalten (was zu empfehlen ist), muss folgendes gemacht werden:

10.5 andere Betriebssysteme 217
10.4.2 Irix
user@host>defaults write com.apple.desktopservices\
DSDontWriteNetworkStores true
user@host>cp ∼/Library/Preferences/com.apple.desktopservice.plist\
/Library/Preferences
Der Rechner muss jetzt einmal neu gestartet werden, um den AFS-Clilent hochzufahren.
Das AFS ist anschliessend als Icon auf dem Desktop verfügbar. Nach
dem Einloggen ins MacOS muss man sich jetzt noch am AFS authentifizieren.
Dazu benutzt man das Kerberos-Tool, dass sich jetzt im Dock befindet.
AFS soll unter Irix laufen - persönlich konnte das der Autor jedoch mangels
Hardware nicht testen. Unter folgender URL gibt’s eine Anleitung:
http://grand.central.org/twiki/bin/view/AFSLore/InstallingAdditionalClientMachines
10.4.3 FreeBSD, NetBSD
10.4.4 OpenBSD
10.5 andere Betriebssysteme
10.5.1 OS/2
Das automatische Token-Holen bei Anmeldung (authlib) scheint nicht zu funktionieren.
Für FreeBSD gibt’s zwar keinen OpenAFS-Client, jedoch soll der Arla-Client
(siehe http://www.stacken.kth.se/project/arla/) darunter laufen,
jedoch gilt das Nur für FreeBSD unter Version 9.
Für OpenBSD kann man ebenfalls den Arla-Client benutzen (wie bei FreeBSD),
jedoch ist er nicht gut getestet und sollte deshalb nicht produktiv eingesetzt
werden.
Für OS/2 existiert eine ältere OpenAFS-Client-Version. Diese beherrscht Kerberos5
nicht und kann deshalb in einer Kerberos5-Umgebung (zwingend bei
InstantAFS) lediglich anonymen Zugriff auf des AFS bieten.
10.5.1.0.2 Installationsanleitung Die Installation ist wenig komfortabel:
Das bereitgestellte ZIP-Archiv ist zu entpacken. Anschliessend führt eine
README-Datei durch die manuelle Installation.

Glossar
acall acall Ein einfaches Prinzip (siehe 7.6.2, Seite 149), um
Shellkommandos auf AFS-Servern authentifiziert und authorisiert
auszuführen. Es wird von diversen InstantAFS-
Tools benutzt.
ACL Access Control List Unter AFS: Ein Metadatum zu einem
Verzeichnis, das die Rechte verschiedener Benutzer
oder Benutzergruppen für Zugriffe auf dieses Verzeichnis
definiert. Dabei können jedem auf der Liste eingetragenem
Benutzer und jeder eingetragenen Benutzergruppe unterschiedliche
Rechte an dem Objekt zugewiesen werden. Unter
AFS besitzt jedes Verzeichnis genau 2 ACLs - eine normale
(die Rechte gewährt) und eine negative (die Rechte
aberkennt).
BaseDN Base-Distinguished-Name Ein gemeinsamer Prefix bestimmter
LDAP-Einträge. Die BaseDN lässt sich unter InstantAFS
eindeutig aus dem Zellennamen ermitteln und
fasst LDAP-Objekte (z.B. Benutzer), die zur Zelle gehören
zusammen.
Bash Completion
Bash Completion Bash Completion ist ein flexibles Konzept,
um Benutzern Parameter für Kommandozeilentools
vorzuschlagen. z.B. könnte der Vorschlag für das cat-
Kommando eine Liste von Dateien im aktuellen Verzeichnis
sein, das ping-Kommando kann dagegen eher mit einer
Liste bekannter Rechnernamen etwas anfangen.
BDB Backup DataBase Der Teil der AFS-Datenbank einer Zelle,
der Daten über die Sicherung von Volumes enthält, die für
das AFS-Backup-System relevant sind.
butc BackUp Tape Coordinator Prozess der die in der Backup-
DB gespeicherten Vorgaben umsetzt und das Backup-
Device ansteuert.
cc Credentials Cache Eine Datei, die von Kerberos-Clients
benutzt wird, um Tickets zu speichern. Die Datei wird
üblicherweise unter /tmp angelegt und läßt sich nur durch
den jeweiligen Benutzer lesen.
FQDN Full Qualified Domain Name Der vollständige Name eines
Computers (also Rechnername plus Domainname).
218

GLOSSAR 219
Globber Globber-Ausdrücke Eine Form regulärer Ausdrücke, die
jedoch stark eingeschränkt ist. Metazeichen sind “*” und
“?”. Globber-Ausdrücke werden z.B. in praktisch jeder
Unix-Shell benutzt. “*.txt” in dem Kommando rm -rf
*.txt ist z.B. ein solcher Ausdruck.
IP-ACLs IP-based-ACLs Es ist unter AFS möglich, ACLs nicht nur
an Gruppen oder Benutzern festzumachen, man kann auch
IP-Adressen (also Rechner) mit bestimmten Rechten versehen.
Das hat allerdings starke unerwünschte Nebeneffekte.
Mehr dazu gibt’s unter http://www.duke.edu/jhv/
answers/afs-ip-acls.html.
KDC Key Distribution Center Ein Prozess, der auf dem
Kerberos-Server läuft. Dieser Prozess ist für die Erstellung
und Verteilung von Tickets zuständig. I.d.R. laufen
auf dem Kerberos-Server noch weitere Prozesse (z.B. der
krb524d).
keytab Kerberos-Keytab Eine Keytab ist eine Datei, in der
Kerberos-Schlüssel gespeichert werden.
KVNO Key Version Number Ein Attribut eines Schlüssels eines
Kerberos-Principals. Dieser Wert wird mit jedem neu
erzeugtem Schlüssel (z.B. bei Ausführung des ktadd-
Kommandos innerhalb der kadmin-Shell) hochgezählt. Die
KVNO stellt das friedliche Nebeneinander mehrerer unterschiedlicher
Schlüssel des selben Prinzipals sicher.
NAT Network Address Translation NAT bedeutet, dass n Adressen
eines i.d.R. privaten Subnetzes auf der einen Seite des
Routers auf eine oder mehrere i.d.R. öffentliche Addressen
abgebildet werden. Dieses Prinzip wird vorrangig eingesetzt,
um den knappen IP-Adressraum besser auszunutzen
und mehreren Computer einen Internetzugang zur Verfügung
zu stellen, ohne dass diese auf Proxies zurückgreifen
müssen.
NSS Name Service Switch Ein Plugin-Modell für Namensauflösung.
Die libc benutzt dieses Modell, um Namensauflösung
(Benutzer ↔ UID, Rechnername ↔ IP, Benutzergruppen
↔ GID, ...) mit unterschiedlichen Diensten (lokale Dateien,
NIS, LDAP, ...) zu ermöglichen.
PAG Process Authentication Grouop Ein Gruppe von Prozessen,
die identische Authentifikationsinformationen teilen (siehe
3.7.2.3, Seite 49).
PCRE Perl Compatible Regular Expression PCRE bezeichnet eine
Klasse regulärer Ausdrücke. PCREs kommen z.B. in Perl
zum Einsatz. Sie sind deutlich mächtiger als Standard-grepregexps.

220 GLOSSAR
Principal Kerberos-Principal Ein Kerberos-Principal ist ein Eintrag
in der Kerberos-Datenbank. Er repräsentiert entweder einen
Benutzer oder einen Dienst. Zu jedem Principal sind einer
oder mehrere Schlüssel gespeichert, die zur Shared-Secret-
Authentifikation und zur Verschlüsselung von Tickets benutzt
werden. Siehe auch 3.10.2, Seite 62.
PTDB Protection DataBase Der Teil der AFS-Datenbank einer
Zelle, der Informationen über die AFS-Benutzer der Zelle
und deren Gruppenzugehörigkeiten speichert.
Realm Kerberos-Realm (“Königreich”) Eine Kerberos-Realm ist
der Gültigkeitsbereich eines bestimmten oder mehrerer verbundener
Kerberos-Server.
SetUID SetUID-Bit Dieses Bit ist ein Metadatum, das allen Unix-
Dateisystemobjekten zugeordnet werden kann. Einer Datei
zugeordnet bewirkt dieses Bit i.d.R., dass die Datei, wenn
sie mit exec() gestartet wird, mit der effektiven UID
des Besitzers der Datei ausgeführt wird. Dadurch lassen
sich z.B. privilegierte Kommandos wie mount (i.d.R. eingeschränkt)
durch normale User benutzen.
SMB Server Message Block Ein Netzwerkdateisystemprotokoll
für lokale Netze. Dieses Protokoll wird vor allem unter Betriebssystemen
und Plattformen der Firma Microsoft eingesetzt.
Sync-Site AFS-Sync-Site Der AFS-DB-Server, der in einer bestimmten
Zelle zu einem bestimmten Zeitpunkt zum Update der
VLDB berechtigt ist. Es kann davon in einer bestimmten
Zelle nur jeweils einen geben. Die Sync-Site wird regelmäßig
“gewählt”, was nur möglich ist, wenn mehr als die
Hälfte aller Datenbankserver einer Zelle miteinander kommunizieren
können.
TGT Ticket Granting Ticket Ein Kerberos-Ticket, das vor allen
anderen Tickes von einem Kerberos-Server angefordert
werden muß (siehe 3.10.1, Seite 61). Im Gegensatz zu
Service-Tickes, erhält man dieses Ticket nur gegen ein gültiges
Passwort oder eine passende Keytab.
VLDB Volume DataBase Der Teil der AFS-Datenbank einer Zelle,
der Informationen über die auf den Fileservern einer Zelle
gespeicherten Volumes enthält.
Volume-Set Volume-Set Ein Volume-Set ist eine Gruppe von Volumes,
die in der BDB definiert wird. Die meisten AFS-Backup-
Operationen lassen sich nur auf Volume-Sets anwenden,
nicht auf einzelne Volumes (siehe 5.2.3.2, Seite 104).

Literaturverzeichnis
[ADMREF] IBM Corporation - AFS 3.6 Administration Reference, 1. Edition
http://www.openafs.org/pages/doc/AdminReference/
auarf002.htm
[ADMGUIDE] IBM Corporation - AFS 3.6 Administration Guide, 1. Edition
http://www.openafs.org/pages/doc/AdminGuide/
auagd002.htm
[LMWeak] Philippe Oechslin - Making a Faster Cryptoanalytic Time-Memory
Trade-Off
PDF-File: http://lasecwww.epfl.ch/pub/lasec/doc/
Oech03.pdf
Homepage: http://lasecpc13.epfl.ch/ntcrack/
[UDEBUG] AFS Debugging Tools: udebug
http://www-1.ibm.com/support/docview.wss?rs=0&q=
%2BAFS+Debugging&uid=swg21113428&loc=en_US&cs=
utf-8&cc=US&lang=en
[Knoppix] Klaus Knopper - die Knoppix http://www.knoppix.de
[Demolinux] Demolinux http://www.demolinux.org/
[OpenAFS] OpenAFS.org http://www.openafs.org
221

Anhang A Anhang
A.1 SSH-Login-Varianten
Authentifikation per Passwort
Soll per SSH eine Verbindung zu einem Account auf einem anderen Rechner
hergestellt werden, können verschiedene Authentifikationsmethoden zum Einsatz
kommen, die unterschiedliche Vor- und Nachteile haben. Auf host-basierte
(hostbased) Authentifikation wird dabei bewusst verzichtet - schliesslich kann
man einfachen Client-Computern in Zeiten von Demolinux und Knoppix nicht
trauen...
Die Authentifikation per Passwort ist am einfachsten aufzusetzen - sie funktioniert
sofort. Außerdem steht mit dem eingegeben Passwort auf dem entfernten
Rechner eine Möglichkeit zur Verfügung, ein Token zu erzeugen. SSH stellt
zwei Möglichkeiten zur Auswahl, um sich per Passwort zu authentifizieren:
password (ein ssh-Eigener Passwort-Check) und keyboard-interactive
(Passwort-Überprüfung per PAM). keyboard-interactive ist dabei in der Lage,
auch komplexe PAM-Passwortabfragen abzubilden.
Problem: Aus nicht geklärten Gründen ist es nicht möglich, daß sich Benutzer,
die keinen Kerberos-Principal besitzen per password authentifizieren
- das schliesst üblicherweise auch root ein. Anderseits ist es nicht möglich,
als Kerberos-Benutzer mittels keyboard-interactive ein neues Token zu erhalten.
Lösungen:
user@host>tokenmgr -S ernie
1. Hat man keine wichtigen Nicht-Kerberos-Benutzer, kann man für die Fälle,
in denen sich z.B. root per Passwort anmeldet, dass Skript rssh benutzen
(Paket instantafs .deb ), das exakt wie ssh funktioniert.
Nachteil: Man muß sich ein ungewöhnliches zweites Kommando merken.
2. Man kann Benutzer, die sich per SSH mit Passwort 1 anmelden, dazu verdonnern,
das Passwort ein zweites Mal einzugeben. Das können die Benutzer
entweder manuell machen:
oder sie schreiben folgende zusätzliche Zeile in ∼/.profile:
tokenmgr -TP
Nachteil: z.B. sftp funktioniert nur anonym 2 . Das Passwort muß für
interaktive Logins mehrmals eingegeben werden.
Die erste Lösung ist deutlich komfortabler für einfache Benutzer und sollte benutzt
werden.
1 Es gibt noch andere Methoden
2 Es steht ja kein Token zur Verfügung und ∼/.profile wird vom sftp-Server nicht abgearbeitet.
222

SSH-Login-Varianten 223
Authentifikation per Public-Key
Authentifikation per GSSAPI
TGT-Weiterleitung
Bei der Public-Key-Authentifikation wird keine geheime benutzergebundene
Information (Schlüssel/Passwort) über das Netzwerk übertragen. Die Identität
des Clients wird dadurch überprüft, dass dieser eine Rechenoperation auf eine
vom Server geschickte Zufallszahl korrekt ausführen muß. Das wiederum ist
nur mit dem privaten Schlüssel des Clients möglich.
Nachteil: Der Public-Key muß irgendwie auf den Server gelangen, bevor diese
Methode das erste Mal genutzt werden kann. Unter 7.3.1 auf Seite 142 ist
beschrieben, wie das gemacht wird.
Die Authentifikationsmethode gssapi-with-mic kann benutzt werden, um sich
mittels eines Kerberos-Tickets zu authentifizieren. Jeder SSH-Server, der das
unterstützten soll, muß mit einem eigenen Kerberos-Principal ausgestattet
werden ( host/Rechner.Domain@Realm ), dessen Schlüssel auf möglichst
sichere Weise in Form einer Keytab auf dem SSH-Server unter /etc/krb5.keytab
deponiert werden muß.
Unter 7.3.2 ist beschrieben, wie das aufgesetzt wird.
Tip: Es ist möglich, für einzelne Nutzer festzulegen, daß sich bestimmte
Kerberos-Nutzer unter deren Namen einloggen dürfen. Das macht jedoch beim
Einsatz von AFS nur für root Sinn. Beispiel:
1. ernie muß gelegentlich auf afsserv1 arbeiten.
2. Der Administrator legt die Datei /root/.k5login an und schreibt ernie
hinein:
root@host>echo ernie > /root/.k5login
ernie@host> ssh root@afsserv1
3. ernie kann sich jetzt mit afsserv1 verbinden:
A.1.0.0.3 GSSAPI in alten OpenSSH-Versionen Vor der Version 3.8 von
OpenSSH stand gssapi-with-mic noch nicht zur Verfügung. Statt dessen konnte
man gssapi als Authentifikationsmethode benutzen, die jedoch gegen MITM-
Angriffe anfällig ist.
Unter Linux gibt es keinen Grund mehr, gssapi zu benutzen, unter MacOSX
(Stand: MacOSX 10.3, 22.04.2005) sieht die Sache jedoch anders aus. Apple
legt dem Panther (sowie dem Jaguar) OpenSSH-3.6 bei.
Die im Rahmen von InstantAFS erstellten SSH-Pakete enthalten einen Patch,
der es ermöglicht, unter Linux sowohl mit dem Client wie auch mit dem Server
gssapi zu verwenden, wodurch passwortfreies einloggen zwischen MacOS und
Linux möglich wird.
SSH kann ein auf dem Client vorhandenes Kerberos-TGT an den SSH-Server
weiterleiten. In Kombination mit der GSSAPI-Authentifikation bedeutet das für
normale Benutzer, daß sie sich nur noch einmal im Netzwerk anmelden müssen
und sich dann per SSH mit jedem Computer sicher und ohne Passworteingabe
verbinden können.

224 Die PTDB als NSS-Dienst nutzen
Die TGT-Weiterleitung kann auch benutzt werden, wenn Public-Key-Authentifikation
zum Einsatz kommt.
Hinweise:
• Ein TGT ist noch kein Token, läßt sich jedoch leicht in eines umwandeln.
Die ssh .deb -Version, die in InstantAFS enthalten ist, wurde leicht modifiziert,
so dass sie gleich ein Token aus dem Kerberos-Ticket erzeugt.
• Damit ein Rechner ein weitergeleitetes Ticket benutzen kann, muss er
einen Kerberos-host-Key haben. Das geht z.B. so:
root@kerberos-master> instantafs.kerberos -G Rechnername
A.2 Die PTDB als NSS-Dienst nutzen
Die Idee
Die Lösung
Es wäre elegant, die PTDB zu nutzen, um Namensauflösung zu betreiben. Damit
kann man auf einfache Art und Weise eine Namensdatenbank (LDAP, NIS,
...) einsparen.
In der PTDB sind nicht alle nötigen Informationen über interaktive Nutzer enthalten.
Vorhanden sind lediglich:
• AFSID
• Loginname
Die restlichen Informationen kann man jedoch theoretisch errechnen bzw. auf
sinnvolle Default-Werte setzen (siehe Tabelle A.1).
Feld Erklärung
UID Die UID ist üblicherweise identisch mit der AFSID.
GID Die Standardgruppe eines Nutzers hat in einer AFS-Zelle keine
Bedeutung. Sie kann deshalb auch für alle Nutzer gleich sein.
Passwort-Hash AFS-Authentifikation wird über Kerberos erledigt - der Hash
sollte also für jeden Nutzer ein Wert sein, der möglichst zu keinem
Passwort passt (z.B. “x”).
Homedirectory Hat man die AFS-Zelle geschickt geplant, kann man das Homedirectory
einfach aus dem Nutzernamen errechnen.
Beispiel: /afs//user/
Standard-Shell Da heute grafische Logins oft überwiegen, ist eine default-Shell
für alle Nutzer i.d.R. ausreichend. Der Standard-Wert /bin/bash
ist sinnvoll.
Tabelle A.1: Mögliche default-Werte für Felder von Benutzerkonten
Mit dem Paket libnss-ptdb .deb läßt sich das realisieren. Es besteht aus 2 Komponenten:
1. einem dauerhaft laufender Serverprozess (ptdbnssd), der die Anfragen
an die PTDB durchführt und seine Dienste per lokalem UDP anbietet und
2. einem nss-Modul, das dynamisch mit der libc geladen wird und sich in
die Funktionen getpwnam und getpwuid einschaltet.

Simple Regular Expressions 225
Implementierung
Benutzen kann man das Modul, indem man das Paket installiert...
root@host>apt-get install libnss-ptdb
A.2.1 Prinzipielle Grenzen
... und in /etc/nsswitch.conf den Dienst ptdb für passwd-Auflösung z.B. wie
folgt konfiguriert:
passwd: files ptdb
Das automatische Setup-Tool von InstantAFS setzt per default libnss-ptdb .deb
als Namensdienst auf.
Diese Trennung in 2 Komponenten hat folgende Vorteile:
• Die AFS-Libraries werden statisch gelinkt. Wäre der Code für die Kommunikation
mit der PTDB im nss-Modul, wäre er praktisch in jedem aufgerufenen
Programm enthalten und würde den Speicherbedarf stark vergrößern.
• Das vom AFS benutzte Threading-Modell LWP kollidiert mit dem im
Debian sehr häufig benutzten Modell pthreads.
Ein NSS-Modul kann nur dann korrekte Namen zu UIDs liefern, wenn es sich
bei diesen UIDs um AFSIDs der lokalen Zelle handelt. Beispiel:
user@host>ls -la /afs/cbs.mpg.de
wird in der Zelle cbs.mpg.de sinnvolle Namen der Besitzer von Verzeichnissen
und Dateien anzeigen, jedoch nicht
user@host>ls -la /afs/ipp.mpg.de
A.3 Simple Regular Expressions
Namen der Besitzer von Dateien werden wie folgt aufgelöst:
1. Mit stat() wird die UID des Besitzers einer Datei ermittelt.
2. Die Funktion getpwuid() wird benutzt, um den Namen zur ermittelten
UID herrauszufinden.
3. getpwuid() leitet die Anfrage an das NSS-PTDB-Modul weiter.
Problematisch ist nun, dass das NSS-PTDB-Modul keine Informationen darüber
erhält, ob die zu ermittelnde UID zur lokalen Zelle gehört oder nicht.
Da dieses Modul aber stets einen PT-Server der lokalen Zelle kontaktiert, werden
mit extrem hoher Wahrscheinlichkeit die AFSIDs von Volumes anderer Zellen
zu falschen Benutzernamen aufgelöst.
Einige AFS-Kommandos können mit einfachen regulären Ausdrücken umgehen,
um Volumegruppen durch Ausdrücke zu bilden. Das ist besser als Globber-
Expressions oder Prefix-Matching zu benutzen, jedoch immer noch eine starke
Einschränkung gegenüber mächtigen Klassen regulärer Ausdrücke wie z.B.
Perl Compatible Regular Expressions (PCRE). In Tabelle A.2 sollen kurz die
Möglichkeiten der Simple Regular Expressions beschrieben werden:

226 Namenskonventionen für Volumes
A.4 Namenskonventionen für Volumes
Element Erklärung
Buchstaben, Zahlen Literale sind selbstverständlich erlaubt
. Der Punkt matcht auf jedes Zeichen
* Der Stern kann wie bei allen anderen regulären
Ausdrücken verwendet werden - matcht also das
vorhergehende Zeichen (oder die Zeichenklasse)
beliebig oft (auch 0 mal).
[...] Zeichenklassen dürfen definiert werden.
[ˆ...] Zeichenklassen, bei denen die Nicht-matchenden
Zeichen angegeben werden.
Tabelle A.2: Elemente von Simple Regular Expressions
Bestimmte AFS-Kommandos (siehe Tabelle A.3) sind in der Lage, Operationen
auf Gruppen von Volumes auszuführen, wobei diese Kommandos unterschiedlich
mächtige reguläre Ausdrücke bzw. Wildcards nur an bestimmten Positionen
erlauben, um Volume-Gruppen zu definieren. Sind in einer Zelle sehr viele
Volumes zu verwalten, lohnt es sich, bestimmte Namenskonventionen genau
einzuhalten. Das Ziel dabei ist, gleichartige Volumes leicht ausdrücken zu können,
was am besten mit gleichen Präfix für gleichartige Volumes zu erreichen
ist. Manche administrative Befehle, die auf Gruppen von Volumes operieren,
erlauben nur eingeschränkte Wildcard-Benutzung für Volume-Namen.
vos backupsys ist ein Beispiel für ein Kommando, das nur über die simpelste
Art (Prefix-Matching) Volume-Gruppen zu erfassen verfügt. Es wird deshalb
hier als Beispiel für das Ausdrücken von Volume-Gruppen benutzt.
Verdeutlichung am Beispiel: Die Benutzer ernie und bert brauchen Homedirectories.
• Man könnte die entsprechenden Homedirectory-Volumes ernie und bert
nennen. Das regelmäßige Synchronisieren der entsprechenden Backup-
Instanzen (siehe 7.2, Seite 141) erfolgt mit einem cron-Job der Form
admin@afs>for i in ernie bert; do vos backup $i; done
• Kommen jedoch weitere Nutzer hinzu ist es schnell mühsam, jeden
Nutzer angeben zu müssen, so dass man die Homedirectories besser
user.ernie und user.bert nennt. So kann man die Schleife durch ein
einzelnes Kommando ersetzen:
admin@afs>vos backupsys -prefix user.
Damit sind auch alle zukünftigen Nutzer versorgt.
• Sollen jetzt z.B. für die Mail jedes Nutzers ein zusätzliches Volume angelegt
werden, könnte man es user.ernie.mail bzw. user.bert.mail nennen.
Das Kommando
admin@afs>vos backupsys -prefix user.
würde diese Volumes ebenfalls erfassen.
Will man das nicht 3 , bieten sich z.B. die Volumenamen mail.bert und
mail.ernie an. Damit könnten jetzt Mail- und Homedirectory-Volumes
3 z.B. weil Mail häufiger gesichert werden soll, als der Rest des Homedirectories

Namenskonventionen für Volumes 227
admin@afs>vos backupsys -prefix home.
admin@afs>vos backupsys -prefix mail.
separat erfasst und z.B. unterschiedlich oft synchronisiert werden:
Tabelle A.4 zeigt, wie eine Namenskonvention aussehen könnte.
Hinweis: Die Maximallänge für Volumenamen (also für die Namen der RW-
Instanzen) ist auf 22 begrenzt.

228 Namenskonventionen für Volumes
Tabelle A.3: AFS-Kommandos, die mit Volume-Gruppen arbeiten. Simple Regular Expressions sind eine stark eingeschränkte Klasse regulärer Ausdrücke (siehe A.3,
Seite 225), PCREs sind die mächtigsten Ausdrücke und schränken bei der Wahl von Volume-Namen praktisch nicht ein.
Kommando Gruppierung durch ... Beschreibung
vos backupsys Prefix-Matching Dieses Kommando erstellt Backup-Instanzen von Volume-Gruppen. Prefix-Matching ist nicht sehr mächtig
- alle Volumes, die bearbeitet werden sollen, müssen mit einer bestimmten oder einer von mehreren anzugebenden
Zeichenketten beginnen. Außerdem ist es möglich, beliebig viele Zeichenketten anzugeben, mit
denen Volumes explizit nicht beginnen dürfen, um bearbeitet zu werden.
backup addvolentry Simple Regular Expressions Dieser Befehl fügt einem Volume-Set eine Menge an Volumes hinzu. Volume-Sets werden z.B. von
backup dump benutzt, um Volumes mit gleichen Sicherheitsansprüchen zusammenzufassen und gemeinsam
zu sichern. Volumes werden als reguläre Ausdrücke definiert, negatives Matching ist nicht möglich.
balancer Globber-Expressions In der balancer-Konfigurationsdatei werden Volumes definiert, die zwischen Fileservern bewegt werden
dürfen.
instantafs.backup Simple Regular Expressions instantafs.backup (siehe 9.2.10, Seite 197) automatisiert verschiedene Backup-Prozesse. Darunter die
Aufrufe von vos backup, vos release und backup dump. Der Aufruf von backup dump macht den
Einsatz von Simple Regular Expressions nötig.
instantafs.calcrestore PCREs Dieses Skript kann zur Wiederherstellung von Servern genutzt werden. Es läßt die Beschränkung auf Volumes
zu, die einem zu definierenden PCRE genügen (siehe 9.2.12, Seite 197).
instantafs.volgrep PCREs Mit instantafs.volgrep (siehe 9.2.26, Seite 204) lassen sich die Namen von Volumes ausgeben, die einem
zu definierenden PCRE bzw. zu definierenden Globber-Expressions genügen.

NAT-geroutete AFS-Clients 229
Muster IA Beschreibung
√
user.
Homedirectories der regulären Benutzer
user-na.
√
Homedirectories gelöschter oder inaktiver Benutzer
(man kann sie ja vorsichtshalber noch 1/2
Jahr aufheben ...)
www.* - Websites
local.* - (ähnlich /usr/local) Volumes, die Software und
zellenspezifische Skripte enthalten
p.. - Volumes von Projekten, die jeweils einer speziellen
Arbeitsgruppe zugeordnet sind
a.* - Alles, was mit der Administration der Zelle zu
tun hat
Tabelle A.4: Beispiel für eine Namenskonvention einer AFS-Zelle. Die Spalte IA zeigt an, ob diese Konvention
in InstantAFS zwingend ist.
A.5 NAT-geroutete AFS-Clients
Hinweis: Es gibt im reinen AFS keine 4 wirkliche Vorgaben für die Namen von
Volumes außer, dass sie nicht länger als 22 Zeichen sein dürfen. Sonderzeichen
sind i.d.R. erlaubt, man sollte sich jedoch auf kleine Buchstaben, Zahlen 5 , “.”
und “-” beschränken. Die Erfahrung zeigt, daß Sonderzeichen in Bezeichnern
leicht zu Problemen führen.
Clients innerhalb eines per NAT ans Internet gekoppelten privaten Netzes können
mit externen Servern (auch von anderen Zellen) kommunizieren - es ist
jedoch nicht ganz einfach. Der NAT-Router schaltet in diesem Fall jeweils eine
zeitlich begrenzte UDP-“Verbindung” 6 zwischen dem internen Client und dem
externen Server. Fließen über diese “Verbindung” eine Weile (default: 3 Minuten)
keine Daten, wird sie gekappt. Durch die callback-Garantie der AFS-Server
ist es jedoch u.U. nötig, Stunden oder Tage nach der letzten Anforderung von
Daten, ein Paket zum Client zu schicken.
Das Problem mit dem Timeout der dynamischen UDP-Portmappings lässt sich
mit statischen Portmappings umgehen: eines für jeden AFS-Client hinter dem
Router. Dabei verbraucht jeder Client einen UDP-Port an der öffentlichen IP —
kein Problem, solange nicht viele tausend AFS-Clients im privaten Netz bedacht
werden sollen. Zumindest unter Kernel 2.4 lässt sich jedoch etwas derartiges
nicht mit Bordmitteln bewerkstelligen.
Listing A.1: netfilter-Regel für AFS-spezifisches timeout-behaftetes UDP-NAT
i p t a b l e s −t n a t −A POSTROUTING −p udp −s [ AFS−C l i e n t ] −−source−p o r t 7001 \
−j SNAT −−to−s o u r c e [ ö f f e n t l i c h e IP ] : [ UDP−P o r t ]
Es ist zwar möglich, wie in Listing A.1 eine feste Zuordnung von öffentlichem
UDP-Port zum internen AFS-Client aufzubauen, jedoch greift dann das auf
3 Minuten beschränkte Timeout für UDP-“Verbindungen”. Das Timeout lässt
sich per sysctl (siehe /etc/sysctl.conf ) erhöhen. Die zu ändernden Variablen
4 abgesehen von root.cell und root.afs
5 nicht nur Zahlen, sonst wird der Volumename als ID interpretiert
6 natürlich existieren keine wirklichen UDP-Verbindungen. Unter Linux (Kernel 2.4) handelt es
sich dabei um einen Eintrag in der Tabelle des Connection Trackers (ip_conntrack.o).

230 Ein AFS-zu-SMB-Gateway unter Linux
heissen net.ipv4.netfilter.ip_conntrack_udp_timeout und
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream.
Diese Änderung beeinflusst jedoch alle UDP-“Verbindungen” - also z.B. auch
DNS-Anfragen eines internen Clients an einen externen DNS-Server. Die
Tabelle des Connection Trackers könnte schnell überlaufen. Würde man UDP-
NAT für alle anderen Protokolle außer AFS verbieten, wäre das kein Problem.
Gäbe es eine iptables-Option, um das Timeout “Verbindungs”-spezifisch
anzupassen, wäre das Problem ebenfalls gelöst.
Eine weitere Lösung ist, auf dem AFS-Client selbst, den Server-Check-Interval
herunterzusetzen - im Beispiel auf 30 Sekunden:
root@host>fs checkservers -interval 30
Man könnte theoretisch das Connection Tracking umgehen und wie in Listing
A.2 AFS-Datenverkehr manuell weiterleiten und verändern. Diese zweite Möglichkeit
scheiterte jedoch daran, dass es keine entsprechenden netfilter-Module
gibt 7 , um die IP-Adressen und Portnummern eines Paketes manuell zu ändern.
Listing A.2: netfilter-Regeln für ein AFS-Client-spezifisches NAT
# P a k e t e von a u s s e n a e n d e r n . . .
i p t a b l e s −t n a t −A INPUT −p udp −s [ AFS−C l i e n t ] −−d e s t i n a t i o n −p o r t [UDP−P o r t ] \
−j MANGLE_DESTINATION −−s e t −d e s t i n a t i o n [ AFS−C l i e n t ] −−s e t −d e s t i n a t i o n p o r t 7001
# P a k e t e von i n n e n a e n d e r n . . .
i p t a b l e s −t n a t −A POSTROUTING −p udp −s [ AFS−C l i e n t ] −−source−p o r t 7001 \
−j MANGLE_SOURCE −−s e t −s o u r c e [ ö f f e n t l i c h e IP ] −−s e t −s o u r c e p o r t [UDP−P o r t ]
A.6 Ein AFS-zu-SMB-Gateway unter Linux
A.6.1 Probleme
In einigen Fällen ist es nötig (siehe 10.1, Seite 209), ein Linux-Samba-Gateway
- z.B. für Rechner mit alten Windows-Versionen - zu betreiben.
Beim Betrieb eines AFS-zu-SMB-Gateways sind einige Hürden zu nehmen.
Zentrales Problem ist dabei die Frage:
“Wie leite ich die Authentifikationsinformationen des Benutzers durch den Sambaserver
hindurch zum AFS weiter?”
Im Gegensatz zu einer interaktiven Session (z.B. ssh) kann man schliesslich
nicht einfach das Passwort zur Erzeugung des Tokens noch einmal eingeben -
das SMB-Protokoll läßt das nicht zu.
LanMan- und NT-Hashes : Authentifiziert sich ein SMB-Client an einem SMB-Server, so kann
das entweder durch die Übertragung des Passwortes im Klartext 8 (unsicher)
oder durch Übertragung eines Hashes des Passwortes passieren.
Dabei werden 2 Arten von Hashes unterstützt (LanMan- und NT-
Hashes). Diese Methode ist sicherer, der LanMan-Hash ist jedoch durch
Designschwächen angreifbar [LMWeak]. Diese Hashes stehen jedoch
üblicherweise unter Unix nicht wie die Unix-Crypt-Hashes (z.B. per
/etc/passwd oder per NIS) zur Verfügung. Samba benutzt deshalb eine
lokale Datei, um diese Hashes zu speichern. Dabei muss jedoch bei jeder
Änderung des Passwortes auch der entsprechende Hash in diesem File
angepasst werden.
Es gibt auch eine Möglichkeit, Samba die Hashes per LDAP zugänglich
zu machen. Das geht jedoch erst ab Samba 3.
7 zumindest ist mir keines bekannt, Stand 19.03.2004.
8 Windows 3.11 und der MSDOS-SMB-Client von Microsoft unterstützten nur diese Methode

Ein AFS-zu-SMB-Gateway unter Linux 231
AFS-Tokens unter Samba : Auf irgendeine Weise muss jeder Samba-Prozess den Token des jeweiligen
Nutzers bekommen. Steht das Passwort des Nutzers zur Verfügung ist
das leicht möglich. Da das Samba-Gateway jedoch mit Hashes 9 arbeiten
sollte 10 , muss das für die Erzeugung des Tokens benötigte Kerberos5-
TGT auf andere Weise geholt werden.
Ablaufende AFS-Tokens : AFS-Tokens laufen nach einer gewissen Zeit ab (siehe 3.7.2.2, Seite 48),
müssen also regelmäßig aufgefrischt werden. Der Ablauf einer Authentifikation
ist bei einer SMB-Share nicht vorgesehen. Es gibt auf dem SMB-
Client (i.d.R. ein Windows-Rechner) keine Mechanismen, um die Authentifikation
zu erneuern.
Ein im Hintergrund auf dem Samba-Server über den Samba-Prozess des
jeweiligen Nutzers wachender Reauthentifikationsprozess könnte den Token
des Nutzers unbegrenzt gültig halten.
A.6.2 Lösung mit verringerter Sicherheit
# ! / b i n / bash
#
# S y n t a x : makekeytab [ P r i n c i p a l ] [ Realm ] [ Passwort ] [ D a t e i ]
(
echo "addent -password -p ’$1$2’ -k 1 -e des3-hmac-sha1"
echo "$3"
echo "wkt $4"
echo "quit"
) | k t u t i l
Es ist möglich, für jeden Benutzer des Samba-Gateways den Kerberos-
Schlüssel auf dem Gateway zu hinterlegen. Es ist nicht möglich, aus diesem
Schlüssel das Passwort wiederherzustellen, jedoch reicht der Schlüssel aus,
um Kerberos-Tickets anzufordern. Die Kerberos-Schlüssel werden für jeden
Benutzer einzeln in jeweils einem Keytab-File gespeichert. Benötigt wird der
Loginname des Nutzers, sein Passwort im Klartext und der Name der Kerberos-
Realm (also der Name der Domain in Großbuchstaben). Das folgende Listing
zeigt ein Skript, mit dem solche Kerberos-Keytabs (immer eine pro Aufruf)
angelegt werden können:
Listing A.3: Kerberos-Keytabs anlegen
Hinweis: Dieses Skript ist zur Veranschaulichung gedacht. Es funktioniert aufgrund
einiger nicht nachvollziehbarer Mechanismen in ktutil nicht ohne weiteres
- statt dessen kommt expect zum Einsatz.
Zusätzlich muss für jeden Benutzer auf dem Samba-Gateway der LanMan- und
der NT-Hash hinterlegt werden. Der Befehl dafür lautet:
root@host>smbpasswd -a Loginname Passwort
In der Samba-Konfigurationsdatei /etc/samba/smb.conf sind für alle Shares, die
AFS-Tokens benötigen (i.d.R. alle, deren Pfade im AFS liegen), preexec- und
postexec-Einträge nötig, die vor dem Zugriff auf das AFS einen Token für
den jeweiligen Samba-Prozess holen.
Auf einem solchen Gateway werden die Kerberos-Schlüssel der Zellenbenutzer
abgelegt. Wird dieser Rechner geknackt, hat das folgende Konsequenzen:
• Es ist davon auszugehen, dass der Angreifer danach die Passwörter der
Benutzer im Klartext besitzt 11 . Alle Benutzer müssen neue Passwörter für
ihre Kerberos-Principals setzen.
9 die smb.conf -Option dafür lautet:
encrypt passwords=true
10 Im anderen Fall wandern die Kerberos-Passwörter im Klartext durch das Netzwerk!
11 Das liegt am fehlenden Salt der LANMAN-Hashes

232 Dateinamen und Pfade
A.7 Dateinamen und Pfade
• Die Sicherheit der Zelle ist nicht direkt von einem solchen Angriff betroffen
- solange man keine Keytabs von mächtigen Principals (z.B. acall
oder afs) auf dem Server liegen hatte.
Der Gateway ist natürlich ein Server - reguläre interaktive Logins sollten
auf diesem nicht erlaubt sein (siehe 3.7.5.4, Seite 56), womit ein lokaler
root-Exploit eher unkritisch ist. Durch den laufenden Samba-Server besteht
allerdings ein Restrisiko.
Unter 4.4.8 auf Seite 96 ist beschrieben, wie man das Samba-Gateway aufsetzt.
Dieser Abschnitt enthällt eine vollständige Liste von Pfaden und Dateien sammt
zugehöriger Erklärung, die von OpenAFS,InstantAFS und der in diesem Dokument
besprochenen Software benutzt werden.
/afs : Der AFS-Namensraum
/etc/cron.d/instantafs-backup : instantafs.vtapes-init legt dieses File an und schreibt voll funktionsfähige
Beispiel-cronjobs hinein, die das AFS-backup steuern. Erklärungen
sind in Kommentaren darin enthalten.
/etc/openafs : Das Konfigurationsbasisverzeichnis von OpenAFS unter Debian. Hinweis:
Die Konfigurations files liegen nicht unter diesem Verzeichnis,
wenn OpenAFS mit Transarc-Pfaden übersetzt wurde
/etc/instantafs : Konfigurationsfiles für InstantAFS sowie Keytabs liegen hier
/etc/instantafs/acall.keytab : Die Kerberos-Keytab des acall-Principals - also acall@MYCELL. Dieser
Principal ist unter InstantAFS mit Superuserrechten versehen - die Keytab
ist deshalb gleich schützenswert wie das Zellenadministrator-Passwort
/etc/instantafs/acall.local.keytab : Die Service-Keytab des acall-Servers des Rechners, auf dem sie liegt -
also z.B. der Principal acall/mekong.mycell@MYCELL.
/etc/instantafs/users.nokrb5 : Die Liste der Benutzer (ein Benutzer pro Zeile), bei denen keine
Kerberos-Authentifikation per PAM durchgeführt werden soll. Per
default sieht die Datei so aus:
root
/etc/instantafs/pam.d : Alternative PAM-Konfigurationsfiles aus dem Paket instantafs-client .deb
/etc/instantafs/pam.d/common-auth-afs : Dieses PAM-File wird von den Diensten benutzt, die darauf angewiesen
sind, nach der Authentifikation ein Token vorzufinden (z.B. interaktive
Logins, kdm, ...).
/etc/instantafs/pam.d/common-auth : Dieses PAM-File wird von Diensten benutzt, die lediglich das passwort
überprüfen wollen (z.B. su oder auch ein POP3-Server).
/etc/instantafs/vtapes.conf : Das Konfigurationsfile für den virtuellen Bandwechsler instantafs.vtapes
(siehe 9.2.28, Seite 206) des lokalen AFS-Tapecontrollers.
/etc/krb5kdc : Das Konfigurationsdirectory der Kerberos-Serverprozesse. Hier sollte
man nichts ändern, da sich instantafs.setup bereits darum kümmert.
/etc/krb5kdc/kadm5.acl : In diesem File sind die Kerberos-Principals gelistet, die über die Ferne
Änderungen an der Kerberos-Datenbank vornehmen dürfen. Unter
InstantAFS ist dieses File per default leer, da sowieso nur lokale (per
kadmin.local) gearbeitet wird - für Fernzugriff wird acall benutzt.)
/etc/krb5kdc/kadm5.keytab : Die Service-Keytab des kadmind-Prozesses (Kerberos5-Admin-Deamon)
/etc/krb5kdc/kdc.conf : Das Konfigurationsfile des Kerberos-Servers

Dateinamen und Pfade 233
/etc/krb5kdc/stash : Der Schlüssel, mit dem die eigentliche Kerberos-Datenbank auf dem Platte
gesichert ist
/etc/krb5kdc/syncsshkey : Der SSH-Schlüssel, der von instantafs.kerberos benutzt wird, um die
aktualisierte Kerberos-Datenbank vom Kerberos-Admin-Server auf die
Slave-Server zu verteilen. Auf den Slave-Servern sorgen entsprechende
Einträge in /root/.ssh/authorized_keys dafür, dass der fernzugriff klappt.
/etc/openafs/server : Hier liegen Konfigurationsfiles, die nur AFS-Serverprozesse auf dem lokalen
Rechner interessieren. Es ist dringend zu empfehlen, dass der Inhalt
dieses Verzeichnis auf sämmtlichen AFS-Servern (File-,Datenbank- und
Backup-Server) absolut identisch ist.
/etc/openafs/server/CellServDB : Diese Datei enthält die Liste sämmtlicher DB-Server der Zelle. Die Liste
wird von UBIK-Server-Prozessen (vlserver, ptserver, ...) benutzt, um
die Synchronisation sicherzustellen.
Beispiel:
>mycell
10.0.1.1 # orinoco.mycell
10.0.1.2 # rubicon
/etc/openafs/server/krb.conf : Diese Datei muss - wenn die Kerberos-Realm nicht dem Zellennamen
entspricht - den Namen der Kerberos-Realm enthalten. Das ist bei InstantAFS
nicht vorgesehen - die Datei sollte also nicht existieren.
/etc/openafs/server/ThisCell : Der Name der AFS-Zelle.
Beispiel:
mycell
/etc/openafs/server/UserList : Die Liste der Benutzer, die privilegiert auf Serverprozesse dieses Rechners
zugreifen dürfen (siehe 3.7.3.5, Seite 54). Unter InstantAFS müssen
zwei Benutzer zwingend drinstehen: acall und admin
Beispiel:
admin
acall
/etc/openafs/server/KeyFile : Der AFS-Zellenschlüssel (siehe 3.7.1, Seite 47). Es handelt sich dabei um
ein Schlüsselliste, die jedoch ein anderes Format als Kerberos-Keytabs
hat. Üblicherweise ist nur ein Schlüssel drin. Mit asetkey kann die Liste
bearbeitet werden.
/etc/openafs/server-local : Ein Konfigurationsverzeichnis für AFS-Serverprozesse
/etc/opebafs/server-local/sysid : Die UID des lokalen AFS-Fileservers. Die UID jedes Fileservers ist
einzigartig und muss das auch sein (siehe auch vos listaddrs
-printuuid). Wenn man einen Fileserver clont, muss man darauf
achten, dass dieses File vorher gelöscht wird. Existiert das File nicht,
wenn der Fileserver startet, wird ein neues angelegt.
/etc/openafs/BosConfig : Das Konfigurationsfile des bosserver-Prozesses. Dieses File definiert,
welche Prozesse laufen müssen und wann sie neu gestartet werden
sollen. Man muss dieses File i.d.R. nicht mit der Hand bearbeiten sonder
mittels des bos-Kommandos (siehe 9.1.1, Seite 192). Auf einem reinem
AFS-Datenbankserver sieht die Datei z.B. so aus:
restarttime 11 0 4 0 0
checkbintime 3 0 5 0 0
bnode simple vlserver 1
parm /usr/lib/openafs/vlserver
end
bnode simple ptserver 1
parm /usr/lib/openafs/ptserver

234 Dateinamen und Pfade
end
bnode simple buserver 1
parm /usr/lib/openafs/buserver
end
/etc/openafs/CellServDB : Das Zellenverzeichnis. Diese Datei muss unter InstantAFS leer sein, da
Datenbankserver über das DNS gesucht werden. Ansonsten übersteuert
dieses File die Daten im DNS.
/etc/openafs/afs.conf : Dieses Debian-spezifische File ist zur leichteren Konfigurations des
AFS-Cachemanagers gedacht. Hier lassen sich z.B. die diversen Cache-
Parameter festlegen und der Debug-Modus aktivieren.
/etc/openafs/afs.conf.client : Eine weitere Konfigurationsdatei des Cachemanagers (siehe 3.5.6, Seite
43). Üblicherweise sieht diese Datei unter InstantAFS wie folgt aus:
Beispiel:
AFS_CLIENT=true
AFS_AFSDB=true
AFS_CRYPT=true
AFS_DYNROOT=false
AFS_FAKESTAT=true
/etc/openafs/cacheinfo : Ein weiteres Konfigurationsfile des Cachemanagers. In diesem ist nur die
Cachegroesse interessant, die ganz am Ende als kB-Angabe steht.
Beispiel:
/afs:/var/cache/openafs:100000
/etc/krb5.conf : Das Konfigurationsfile für lokale Kerberos-Clients
/etc/krb5.keytab : Das Keytab für lokale Dienste. Unter InstantAFS wird darin nur der host-
Key gespeichert (also z.B. host/mekong.mycell@MYCELL).
/var/cache/openafs : Das Cache-Verzeichnis des AFS-Cachemanagers
/var/lib/openafs/backup : In diesem Verzeichnis lagern Konfigurations- und Logfiles des TapeControllers
(butc), der Teil des AFS-Backup-Systems ist (siehe 5.2.3.1, Seite
102). Normalerweise sollte man Änderungen an diesen Files dem Kommando
instantafs.vtapes-init überlassen.
/var/lib/openafs/backup/CFG_* : Das Konfigurationsfile eines Tapedevices
/var/lib/openafs/backup/TE_* : Das Fehler-Logfile eines Tapedevices
/var/lib/openafs/backup/TL_* : Das Logfile eines Tapedevices
/var/lib/openafs/backup/tapeconfig : In diesem File befindet sich eine Liste der verfügbaren Tapedevices eines
Rechners. Unter InstantAFS existiert in dieser Liste nur ein Eintrag, der
jedoch auf eine Datei (oder auf nichts) zeigt und nicht auf ein physisches
Gerät.
/var/lib/openafs/db : Die AFS-Datenbanken
/var/lib/openafs/db/bdb.DB0 : Die BDB (Backup DataBase)
/var/lib/openafs/db/prdb.DB0 : Die PTDB (ProTection DataBase)
/var/lib/openafs/db/vldb.DB0 : Die VLDB (VoLume DataBase)
/var/lib/openafs/NetInfo : In diesem File wird bei Servern mit mehreren Adressen definiert, welche
Adressen für AFS benutzt werden (siehe 3.6.1, Seite 45).

AFS-Schlüssel aus einer laufenden Zelle besorgen 235
A.8 AFS-Schlüssel aus einer laufenden Zelle besorgen
A.9 Löschen des AFS-Caches eines AFS-Clients
root@host>fs setcache 1
root@host>fs setcache 0
Sollen neue Fileserver oder Datenbankserver in die Zelle eingebaut werden, so
benötigt man einen gültigen AFS-Key. Kann diesen entweder aus einer gültigen
Keytab (üblicherweise afs.keytab) extrahieren (mit asetkey add, darf
dabei jedoch auf keinen Falldie Keytab mit ktadd [...] aus der Kerberos-
Datenbank erstellen.
Wenn man die Keytab nicht mehr findet, kann man auch einfach die Datei /etc/openafs/server/KeyFile
von einem bereits arbeitenden Datenbank- oder Fileserver
an die gleiche Stelle auf dem neuen Server kopieren.
Ein direktes forciertes flushen des AFS-Caches ist nicht möglich, jedoch kann
man folgenden Trick anwenden:
Das erste Kommando setzt den Cache auf die Größe 1 (ein Chunk), was eine
Weile dauern kann. Das zweite setzt die Cachegröße wieder auf den Wert, der
in /etc/openafs/cacheinfo definiert ist.
A.10 Fileserver mit mehreren IP-Adressen im selben logischen Netzwerk
Fileserver können mit mehreren Netzwerkinterfaces umgehen und dadurch auch
zusätzliche Ausfallsicherheit (-> gegen Ausfall von Netzwerkkarten) schaffen
(siehe 3.6.1, Seite 45).
Setzt man einen Fileserver auf, der mehrere Netzwerkkarten besitzt und diese
im selben logischen Netzwerk (z.B. 192.168.1.1 und 192.168.1.2 mit der
Netzmaske 255.255.255.0) liegen, bekommt man nicht automatisch, was man
erwartet. Alle ausgehenden Pakete werden immer über eine der Karten geroutet,
da die Routingtabelle nicht speziell auf die Quelladresse von ausgehenden
Paketen schaut.
Abhilfe schafft Policy based routing. Hier ist beispielhaft beschrieben, wie man
so etwas unter Debian ab Sarge einrichtet. Vorrausgesetzt ist ein aktueller Kernel
(2.6.15.0 geht auf jeden Fall).
Benötigt wird das nicht-Standard-Paket iproute .deb :
root@host>apt-get install iproute
Man benötigt ein kleines Skript - z.B. /etc/iproute2/ipr2, das sich darum kümmert,
zwei unabhängige Routingtabellen einzurichten und entsprechend mit
Quelladressen des Servers zu verbinden. Im Beispiel sind eth0 und eth1 die
Netzwerkinterfaces und 192.168.1.10 das default-Gateway:
ip route add 192.168.1.0/255.255.255.0 via 192.168.1.1 dev eth0 t
ip route add 192.168.1.0/255.255.255.0 via 192.168.1.2 dev eth1 t
ip route add default via 192.168.1.10 dev eth0 tab 1
ip route add default via 192.168.1.10 dev eth1 tab 2
ip rule add from 192.168.1.1/32 tab 1 priority 500

236 Fileserver mit mehreren IP-Adressen im selben logischen Netzwerk
ip rule add from 192.168.1.1/32 tab 2 priority 500
Die passenden Rechte nicht vergessen...
root@host>chmod 755 /etc/iproute2/ipr2
...und folgende Zeile gleich unter dem ifup -a in der Datei /etc/init.d/networking
eintragen:
/etc/iproute2/ipr2