AFS

Informationen zur Installation von Kerberos und AFS und dem Zugriff auf unsere AFS-Zelle itp.tugraz.at findet Ihr unter Linux AFS, AFS für Windows und AFS für Apple Macintosh.

Grundlagen

AFS ist ein verteiltes Dateisystem, bei dessen Entwurf besondere Aufmerksamkeit auf effizienten Datenzugriff sowohl in lokalen als auch weitverteilten Netzen gelegt wurde.

AFS wurde ursprünglich im Information Technology Center an der Carnegie-Mellon University entwickelt und später von der Firma Transarc vermarktet und weiterentwickelt. Nach dem Kauf von Transarc durch IBM wurde es unter der Bezeichnung OpenAFS als OpenSource freigegeben. AFS ist als Dateisystem in vielen Großforschungsinstitutionen im Einsatz (Argonne National Laboratory, CERN, Jet Propulsion Laboratory, MIT, ...)

Weitere Informationen zu AFS findet Ihr in der AFS-FAQ, dem AFS User Guide und dem AFS-Wiki.

Technologie

AFS arbeitet nach dem Client-Server Modell, bei dem alle Daten auf einem oder mehreren Servern gespeichert sind und bei Bedarf auf die Clients kopiert werden. Die Daten werden auf den Clients gecacht; wenn der Server ausfallen sollte, können Lesezugriffe in vielen Fällen weiter aus dem Cache bedient werden, erst Schreibversuche blockieren solange, bis der Server wieder verfügbar ist.

Die meisten benutzerrelevanten Funktionen findet Ihr unter dem Sammelbefehl fs ; bitte konsultiert die Onlinehilfe mit fs help oder den AFS User Guide.

• Zelle Eine Gruppe von Servern und Clients unter einheitlicher Verwaltung bilden eine AFS Zelle; der Zellenname bei uns ist itp.tugraz.at. Die Dateien haben für alle AFS-Clients weltweit den gleichen Namen, dieser Name beginnt mit /afs/<zelle>/; mein Homedirectory am Institut findet man z.B. unter /afs/itp.tugraz.at/user/ahi/.

• Volume: Zusammgehörige Dateien (z.B. alle Dateien eines Benutzers) werden innerhalb AFS in einem Volume gespeichert; Volumes werden über mount points in den Dateibaum aufgenommen. Der Vorteil von Volumes ist, dass diese während des Betriebs verschoben werden können; nur in der Endphase des Transfers ist für wenige Sekunden kein Schreibzugriff möglich. Diese Eigenschaft wird verwendet, um Server und Festplatten gleichmäßig auszulasten bzw. einzelne Server vor einem Austausch freizuspielen.

• Quota: Die Größe eines Volumes ist durch ein Quota beschränkt. Ihr könnt die Größe eines Quotas mit dem Befehl fs listquota betrachten.

[ahi@faeppc48 ~]$ fs listquota ~ahi ~ftp ~flash
Volume Name                Quota      Used %Used   Partition
user.ahi                 3000000   2048002   68%         38%  
common.ftp.readonly      8000000   5629668   70%         33%  
fs: You don't have the required access rights ....

• Token: Zum Zugriff auf eine AFS-Zelle benötigt man ein Token, das beim Einloggen gemeinsam mit dem Kerberos-Ticket erzeugt wird und mit dem Befehl tokens kontrolliert werden kann:

[ahi@faeppc48 ~]$ tokens
Tokens held by the Cache Manager:
User's (AFS ID 997) tokens for afs@itp.tugraz.at
                                      [Expires Feb 22 15:05]
  --End of list--

Sie erkennen an der Ausgabe des Tokens, dass der Benutzer mit der UID 997 in der AFS-Zelle itp.tugraz.at angemeldet ist. Pro Zelle kann man maximal ein Token besitzen.

Unterschiede in der Benutzung

Die wesentliche Unterschiede zwischen der gewohnten UNIX-Semantik bei Dateizugriffen und AFS sind:

• Zugriffsberechtigungen: Die mode bits werden weitgehend ignoriert; Rechte auf Dateien werden über access control lists (ACL) gesteuert. Diese Listen beziehen sich immer auf ein Verzeichnis.
• Benutzergruppen: Jeder Benutzer kann eigene Gruppen anlegen und verwalten (protection service, PTS). Mitgliedern dieser Gruppen können über ACLs Zugriffsberechtigungen gegeben werden.
• Hard links: Hard links sind nur zu Dateien im selben Verzeichnis möglich, um die Sicherheit durch die ACLs nicht zu gefährden.
• Save on close: Die Dateien werden beim Aufruf der Funktion write() nur im lokalen Cache gespeichert; nur wenn die Datei mit close() oder fsync() geschlossen wird, wird der neue Inhalt auch zum Server geschickt. Die meisten Anwendungen (vi, emacs, ...) führen den Befehl close() nach dem Speichern von Änderungen aus, Sie müssen den Editor daher nicht beenden, um sicher zu sein, dass Ihre Daten wirklich gespeichert werden.
• Dateizeiten: Es gibt nur eine Dateizeit, die erst bei einem Schreibzugriff am Server (close() und fsync()) aktualisiert wird - der Zeitpunkt des letzten Lesezugriffs wird nicht protokolliert.
• Read only volumes: Wenn Kopien von Volumes ohne Schreibberechtigung vorhanden sind, werden nur diese verwendet - Änderungen im Volume werden nicht automatisch an die Kopien weitergereicht, sondern müssen explizit freigegeben werden (release).
  Üblicherweise verwendet man zum Zugriff auf das beschreibbare Volume einen mount point mit vorgesetztem Punkt: /afs/itp.tugraz.at/common/.ftp/.

ACL - acces control lists

Sie können in AFS sieben Zugriffsberechtigungen vergeben; diese gelten immer für das gesamte Verzeichnis:

l (lookup)

Ansehen von ACLs und Dateinamen (wird für alle anderen Berechtigungen gebraucht)

r (read)

Ansehen von Dateien

i (insert)

Anlegen neuer Dateien

w (write)

Ändern bereits vorhandener Dateien

d (delete)

Löschen von Dateien

k (lock)

Sperren von Dateien mit flock()

a (administer)

Ändern der ACLs

Sie können folgende Abkürzungen verwenden:

read	rl	read und lookup
write	rlidwk	alle Rechte außer administer
all	rlidwka	alle Rechte
none		löscht alle Rechte

Beim Erzeugen eines Subdirectories werden die ACLs des übergeordneten Verzeichnisses kopiert; allerdings trifft dies beim Kopieren nicht immer zu.

Mit den mode bits von UNIX können sie die Dateiberechtigungen auf einzelne Dateien weiter einschränken; so erlaubt -r--...... nur Lesezugriff, auch wenn die ACL für das gesamte Directory Schreibzugriffe ermöglicht. Allerdings gelten diese Einstellungen für alle Benutzer und nicht nur für den Besitzer, die Einstellungen für group und other werden zwar gespeichert und angezeigt, vom Dateisystem aber ignoriert - mode bits für Verzeichnisse werden grundsätzlich nicht beachtet. Allerdings werten einige Programme die mode bits selbständig aus: ssh, qmail, vsftpd, ....

ACL lesen

[ahi@faeppc48 ~]$ fs listacl ~
Access list for /afs/itp.tugraz.at/user/ahi is
Normal rights:
  system:administrators rlidwka
  mail rlidwk
  ahi rlidwka

Sie erkennen in diesem Beispiel die Zugriffsrechte für den Benutzer Mail; bitte löschen sie diesen Zugang nicht, da sonst Ihre E-mail nicht mehr empfangen werden kann.

ACL setzen und löschen

[ahi@faeppc48 ~]$ fs setacl -acl flash read -dir ~
[ahi@faeppc48 ~]$ fs setacl -acl flash none -dir ~/privat/
[ahi@faeppc48 ~]$ fs setacl -acl ahi   all  -dir ~/Mail/ -clear

Wenn Sie jemandem besondere Rechte in Teilen Ihres Homedirectory gewähren, denken Sie bitte daran, dass der entsprechende Benutzer in allen darüberliegenden Verzeichnissen mindestens das lookup-Recht besitzen muss; dieses Recht kann er gegebenenfalls auch über eine Gruppenzugehörigkeit erlangen.

Wenn die Berechtigungen rekursiv an alle Unterdirectories weitergegeben werden sollen, verwenden sie das Programm afs_acl_rec; sie erhalten dazu eine Hilfe mit afs_acl_rec -man .

PTS - protection service

Vordefinierte Gruppen

AFS protection groups sind den Benutzergruppen von UNIX ähnlich, werden aber teilweise von den Benutzern selbst verwaltet. Einige Gruppen werden vom System zur Verfügung gestellt:

• system:anyuser - enthält alle AFS Benutzer weltweit
• system:authuser - enthält nur AFS Benutzer, die derzeit ein gültiges Token der Zelle haben; das sind in unserem Fall alle Benutzer am Institut und die Studenten im Computerraum.
• system:administrators - enthält alle lokalen AFS Administratoren

Netzwerkbasierende Gruppen

Einige weitere Gruppen werden von uns definiert - die Zugehörigkeit zu diesen Gruppen basiert auf den Netzwerkadressen der beteiligten Clients.

• admin:www - erlaubt den Webservern Zugriff (wird gebraucht werden, um das Directory ~/public_html zu verwenden).
• admin:net_tu - erlaubt allen PCs mit einer IP-Adresse aus dem Netz der TU Graz Zugrif.
• admin:net_itp - erlaubt allen PCs mit einer IP-Adresse aus dem Netz des Instituts für Theoretische Physik Zugriff.
• admin:net_fub - erlaubt allen PCs mit einer IP-Adresse aus dem Netz des Computerraums Physik Zugriff.

Passende Berechtigungen für diese Benutzergruppen sind meistens rliwk - alle Rechte außer der Zuordnung neuer Berechtigungen und dem Löschen von Daten.

Projektgruppen

Die Mitglieder der Gruppen wird durch ihren Besitzer über das Kommando pts verwaltet; der Besitzer kann selbst wieder eine Gruppe oder die Gruppe selbst sein. Gruppennamen sind (fast) immer zweiteilig: <besitzer>:<gruppe>.

Für einzelne Arbeitsgruppen scheint ein Modell mit 2 Ebenen praktikabel zu sein:

1. Eine Gruppe mit dem ,,inneren Kreis`` der Arbeitsgruppe als Gruppenmitglieder, diese Gruppe besitzt sich selbst - daher darf jedes Gruppenmitglied neue Gruppenmitglieder aufnehmen oder löschen. Es ist günstig, die Mitgliderzahl dieser Gruppe möglichst klein zu halten.
2. Weitere Gruppen mit Mitgliedern des Teams, externen Mitarbeitern, Gästen, ... Dissertanten und Diplomanden. Der Besitzer dieser Gruppen ist die Gruppe aus Punkt1.

Ich habe nach diesem Schema einige Gruppen für die Abteilung für Plasmaphysik angelegt; der erste Teil für den ,,inneren Kreis`` muss von jemandem mit Administratorrechten ausgeführt werden, weil ein einfacher Gruppenname ohne Besitzerteil sonst nicht angelegt werden kann.

[root@faepsv01 ~]# pts creategroup -name plasma:plasma
group plasma has id -207
[root@faepsv01 ~]# pts adduser -user heyn kernbich -group plasma:plasma
[root@faepsv01 ~]# pts members heyn
Groups heyn (id: 707) is a member of:
  plasma
[root@faepsv01 ~]# pts chown plasma:plasma plasma:plasma
[root@faepsv01 ~]# pts examine plasma:plasma
Name: plasma:plasma, id: -207, owner: plasma:plasma, creator: admin,
  membership: 2, flags: S-M--, group quota: 0.

Die restlichen Gruppen könnten durch alle Mitglieder der Gruppe plasma:plasma angelegt und gefüllt werden:

[root@faepsv01 ~]# pts creategroup -name plasma:team -owner plasma:plasma
group plasma:team has id -208
[root@faepsv01 ~]# pts creategroup -name plasma:diss -owner plasma:plasma
group plasma:diss has id -209
[root@faepsv01 ~]# pts creategroup -name plasma:dipl -owner plasma:plasma
group plasma:dipl has id -210

Die Gruppen plasma:team ... können durch die Mitglieder von plasma:plasma mit den Befehlen pts adduser und pts removeuser gewartet werden.

Bei der Erzeugung von Projektverzeichnissen werden derzeit 3 Gruppen und dazu passende ACLs angelegt:

• p.projektname.a: Gruppen-Administratoren; dürfen im Projekt ACLs ändern und haben vollen Schreib- und Lese-Zugriff
• p.projektname.w: dürfen unbeschränkt schreiben und alle Inhalte lesen
• p.projektname.r: dürfen Lesen, aber nichts schreiben

Eigene Gruppen

Sie können mit den Gruppenbefehlen bis zu 20 eigene Gruppen festlegen.

Woher kommen Ticket und Token?

Am Institut und im Computerraum

Darüber muss nicht viel gesagt werden, der Ablauf funktioniert durch die Systemkonfiguration von selbst. In Notfällen (kein gültiges Token, zu testen mit tokens) kann durch die Kombination

$ kinit -f; aklog 

ein gültiges Token erzeugt werden.

Zur Abkürzung dieses Vorgangs wird am Institut ein shell alias klog definiert, der diese Operationen gemeinsam ausführt:

 [ahi@faeppc48 ahi]$ klog
 Password for ahi@ITP.TUGRAZ.AT: ********
 .
 Tokens held by the Cache Manager:
 .
 User's (AFS ID 997) tokens for afs@itp.tugraz.at [Expires Oct 20 11:15]
    --End of list--

Externer Zugriff

$ kinit ahi@ITP.TUGRAZ.AT
$ klist
$ aklog
$ tokens
$ ls /afs/itp.tugraz.at/user/ahi/
...
$ kdestroy; klist; tokens

Um auch hinter einer Firewall auf unsere AFS-Server zugreifen zu können; müssen auf Ihrer Seite einige Ports geöffnet sein:

kerberos 

88/udp
749/tcp (für Passwortänderungen)

afs 

7000/udp bis 7009/udp

Bei Firewalls mit NAT (network address translation) müssen zusätzlich address-less tickets erzeugt werden:

$ kinit -A ahi@ITP.TUGRAZ.AT
$ ... (weiter wie oben)

Zugriff auf andere AFS-Zellen

Die Zugriffsmöglichkeiten auf anderen Zellen hängen teilweise von den dort dort verwendeten Konfigurationen ab, vermutlich gibt es von der anderen Organisation Hilfestellungen. Eventuell muss bei uns am Server zuerst die entsprechende Zelle gemounted werden; Sie können dies durch ls /afs/ prüfen - bitte kontaktieren Sie zum Anbinden fremder Zellen den jeweils zuständigen Administrator.

Kerberos 4

$ /usr/bin/klog benutzername -cell afs.zelle.name
$ tokensfreizuspielen

Kerberos 5

$ kinit benutzername@FREMDER.KERBEROS.REALM
$ klist
$ aklog --cell fremde.afs.zelle
$ tokens

Spezialfälle

Die Notwendigkeit ein gültiges Token für den Dateizugriff zu besitzen bereitet in einigen Fällen Probleme. Sie gehen diesen am besten aus dem Weg, indem sie auf lokale vorliegende Dateien oder netzwerkbasierenden ACLs zurückgreifen.

Lange Berechnungen

Wenn Ihre Berechnungen länger als die voreingestellte Dauer von einem Tag benötigen, muß auch Ihr Token diese Lebenszeit haben; sie ist in jedem Fall auf 31 Tage beschränkt. Es gibt im wesentlichen 2 Möglichkeiten:

• Sie verlängern aus Ihrem Programm das Token regelmäßig - diese Lösung ist komplizierter und erfordert den regelmäßigen Aufruf von kinit -R; aklog.
• Sie fordern vor dem Programmstart Ticket und Token mit langer Lebensdauer an: kinit -l 4d; aklog

CRON- oder Condor-Jobs

Diese Programme werden vom System automatisch gestartet; die Passworteingabe ist nicht möglich.

• Sie holen beim Start des Programms ein Ticket; dazu müssen wir eine keytab-Datei erzeugen, die ihre verschlüssseltes Passwort enthält; danach können sie mit kinit -k -t <keytab>; aklog Ticket und Token erzeugen. Die keytab-Datei muß natürlich ohne Token zu erreichen sein und daher auf der lokalen Festplatte gespeichert werden.