Installation von AFS Clients

Übersicht

Unterstütze Plattformen
Voraussetzungen
Ablauf der Installation
Lizenzbedingungen
Zellzugehörigkeit
Erreichbare Zellen
Zugang zu AFS-Kommandos und Manuals
Austauschen von Systembinaries
Wegfall des amd für /uni/global a uf AFS-Clients
Besonderheiten einiger Systeme
AFS unter Linux

Unterstütze Plattformen

Das aktuelle Release ist AFS 3.4a.
AFS 3.4a unterstützt folgende Plattformen:

Systemname	Hardware	Betriebssystem
alpha_osf20	DEC Alpha	DEC OSF/1 V2.0
alpha_osf30	DEC Alpha	DEC OSF/1 V3.0
alpha_osf32	DEC Alpha	DEC OSF/1 V3.2
pmax_ul43	DEC 5000 (MIPS, single processor)	Ultrix 4.3
pmax_ul43a	DEC 5000 (MIPS, single processor)	Ultrix 4.3a/4.4
rs_aix32	IBM RS/6000	AIX 3.2.x
rs_aix41	IBM RS/6000	AIX 4.1.x
rs_aix42	IBM RS/6000	AIX 4.2.x
sgi_52	SGI Iris Indigo/Challenge	IRIX 5.2
sgi_53	SGI Iris Indigo/Challenge	IRIX 5.3
sgi_62	SGI Iris Indigo/Challenge	IRIX 6.2
hp700_ux90	HP9000 Serie 700	HP-UX 9.0x
hp800_ux90	HP9000 Serie 800	HP-UX 9.0x
hp700_ux100	HP9000 Serie 700	HP-UX 10.0x
hp800_ux100	HP9000 Serie 800	HP-UX 10.0x
hp700_ux101	HP9000 Serie 700	HP-UX 10.1x
hp800_ux101	HP9000 Serie 800	HP-UX 10.1x
hp_ux102	HP9000 Serie [78]00	HP-UX 10.2x
sun4_411	SUN 4 (außer SPARCstation)	SunOS 4.1.x
sun4_53	SUN 4 (außer SPARCstation)	SunOS 5.3
sun4_54	SUN 4 (außer SPARCstation)	SunOS 5.4
sun4c_411	SPARCstation (karch: sun4c)	SunOS 4.1.x
sun4c_53	SPARCstation (karch: sun4c)	SunOS 5.3
sun4c_54	SPARCstation (karch: sun4c)	SunOS 5.4
sun4m_412	SPARCstation (karch: sun4m)	SunOS 4.1.x (ab 4.1.2)
sun4m_53	SPARCstation (karch: sun4m)	SunOS 5.3
sun4m_54	SPARCstation (karch: sun4m)	SunOS 5.4
sun4x_55	SPARCstation (karch: sun4m,sun4c,sun4u)	SunOS 5.5/5.5.1

Ältere Systeme werden auch nur in älteren AFS-Versionen unterstützt.
Für die folgenden Systeme wird AFS-Version 3.3 benötigt:

Systemname	Hardware	Betriebssystem
next_mach30	NeXTstation, NeXTcube	NeXTSTEP 3.x

SPARCstation der Kernarchitektur (karch) sun4c sind z.B.: SPARCstation 1, 1+, 2, SLC, ELC
SPARCstation der Kernarchitektur (karch) sun4m sind z.B.: SPARCstation classic, 5, 10, 20
SPARCstation der Kernarchitektur (karch) sun4u sind Maschinen mit dem UltraSPARC-Prozessor,
Weitere Angaben zur Verfügbarkeit von AFS sind in den AFS-FAQ's zu finden.

Voraussetzungen

Um die AFS-Client-Funktionalität installieren zu können, müssen verschiedene Voraussetzungen erfüllt sein:

Das Basisbetriebssystem mit den entsprechenden Netz-Komponenten muß installiert und konfiguriert sein.
AFS arbeitet mit einem Cache auf einer lokalen Festplatte.
Die Größe dieses Caches muß bei der Installation festgelegt werden, sie ist abhängig von der Verwendung der Maschine. Empfohlen wird eine Größe von etwa 70 - 100 MB. AFS ist aber schon mit kleineren Caches arbeitsfähig (mind. 20 MB), beachten Sie jedoch die maximal zulässige Cachegröße von 1GB.
Neben dem Cache werden noch ca. 3 MB für die AFS-Software und etwa 1MB in /tmp benötigt.
Am besten wählt man für den sämtlichen Plattenbedarf ein eigenes lokales Filesystem mit der entsprechenden Nettokapazität aus.
Zur Installation sind root-Rechte erforderlich.

Ablauf der Installation

Bevor Sie die Installation durchführen, lesen Sie bitte erst die folgenden Hinweise.

Für die gebräuchlichsten der oben angeführten Plattformen werden vom URZ Installationsscripts zur Verfügung gestellt.
Da AFS keine freie Software ist und entsprechenden lizenzrechtlichen Bestimmungen unterliegt, wurden folgende Festlegungen getroffen:

Die Software wird nur Mitgliedern der TU Chemnitz-Zwickau zugänglich gemacht.
Die Software darf nur auf Maschinen der TU Chemnitz-Zwickau installiert werden.
Mit dem Kopieren und Installieren der Software erkennen Sie die Lizenzbedingungen an.

Im einzelnen werden vom Installationsscript folgende Aktionen ausgeführt:

Einrichten des lokalen Caches (das Filesystem muß bereits existieren, Pfadname und Cachegröße werden abgefragt)
Festlegen der Zellzugehörigkeit der Maschine (tu-chemnitz.de)
Anpassen des Kernels durch dynamisches Nachladen der AFS-Funktionalität (nicht bei DEC-Alpha-Systemen, da muß ein neuer Kernel erzeugt werden)
Anlegen des Mountpunktes /afs
Starten des Cache-Managers (afsd)
Einrichten eines symbolischen Links zu den AFS-Kommandos (/usr/afsws)
Anpassen der Systeminitialisierungs-Scripts zum automatischen Start von AFS bei reboot

Zellzugehörigkeit

Jeder AFS-Client ist standardmäßig einer AFS-Zelle zugeordnet. In den bereitgestellten Installationsfiles ist tu-chemnitz.de als Zellname eingetragen. Sollten Sie eine eigene Zelle besitzen, muß das File /usr/vice/etc/ThisCell entsprechend geändert werden.

Erreichbare Zellen

Das File /usr/vice/etc/CellServDB enthält die Namen aller Zellen, die vom jeweiligen AFS-Client aus erreichbar sind. Außerdem sind die IP-Adressen der AFS-Database-Server der einzelnen Zellen eingetragen.

Für einen konsistenten Betrieb des Cache-Managers ist es von großer Bedeutung, daß dieses File ständig aktuell gehalten wird, da bei fehlerhaften Einträgen die betroffenen Zellen nicht erreichbar sind.

Mit Hilfe dieses Files bietet sich andererseits auch die Möglichkeit, den Zugriff auf andere Zellen einzuschränken. In Abhängigkeit vom Einsatzzweck einer Maschine kann so der Zugriff auf die lokale Zelle, alle Zellen in Deutschland, alle Zellen in Europa o.ä. eingeschränkt werden, indem einfach die nicht gewünschten Zelleinträge in /usr/vice/etc/CellServDB entfernt werden.

Für die Erreichbarkeit von Zellen ist weiterhin ausschlaggebend, daß deren sog. root-Volume in unserer Zelle montiert ist. Das File /afs/tu-chemnitz.de/common/etc/CellServDB enthält die Einträge der bei uns montierten Zellen. Dieses File wird in regelmäßigen Abständen mit dem von Transarc verwalteten File /afs/transarc.com/common/etc/CellServDB.export abgeglichen.

Im Zuge der Installation wird das File /afs/tu-chemnitz.de/common/etc/CellServDB als /usr/vice/etc/CellServDB eingespielt.

Um im laufenden Betrieb dieses File aktuell zu halten, ist es erforderlich, die aktuelle Version zu kopieren und den Cache-Manager über die Änderungen zu informieren. Dazu kann das Programm /afs/tu-chemnitz.de/global/system/bin/ucsdb verwendet werden. Es wird so aufgerufen:

ucsdb /usr/vice/etc/CellServDB /afs/tu-chemnitz.de/common/etc/CellServDB

Für den Aufruf sind root-Rechte erforderlich. Sinnvollerweise sollte der Aufurf per cron geschehen.

Zugang zu AFS-Kommandos und Manuals

Zur Arbeit mit AFS existieren eine Reihe von Kommandos, insbesondere zum Beschaffen und Verwerfen von Tokens und zum Umgang mit den AFS-Zugriffsrechten .

Diese Kommandos werden über den Pfad /usr/afsws/bin verfügbar gemacht. Dazu wird während der Installation ein symbolischer Link

ln -s /afs/tu-chemnitz.de/product/afs/3.3a/@sys /usr/afsws

eingerichtet. Der Ausdruck @sys steht für den aktuellen Systemnamen (siehe Tabelle Unterstützte Plattformen), welcher automatisch durch den Cache-Manager ersetzt wird.

Während die AFS-Kommandos über den Pfad /usr/afsws/bin erreicht werden, findet man analog unter /usr/afsws/man die zugehörigen Manuals.

Es ist also zu empfehlen, die Umgebungsvariablen PATH für den Suchpfad und MANPATH für das Kommando man so zu ändern, das die AFS-spezifischen Kommandos bzw. Manuals gefunden werden. Dabei ist zu beachten, daß AFS einige Standard-Kommandos (wie rsh, rcp, ...) ersetzt und deshalb die AFS-Verzeichnisse vor den Standardverzeichnissen in die Pfade aufgenommen werden müssen.

Austauschen von Systembinaries

Die im folgenden beschriebenen Aktionen müssen nicht unbedingt ausgeführt werden, sie erleichtern jedoch den Nutzern die Arbeit.

Um die Arbeit mit AFS komfortabel zu gestalten, empfiehlt es sich, einige Systembinaries gegen entsprechend angepaßte AFS-Varianten auszutauschen. Dazu gehören

login: Das zum Betriebssystem gehörende login führt natürlich keine AFS-Authentisierung durch. Daher muß vor dem Zugriff auf geschützte Files im AFS zunächst mit dem AFS-Kommando klog ein Token beschafft werden. Die AFS-Version von login (/usr/afsws/bin/login) beschafft so ein Token sofort während des Login-Vorgangs.
ftpd: Für den ftp-Daemon ftpd gilt in etwa das gleiche wie für login; der systemeigene ftpd führt ebenfalls keine AFS-Authentisierung durch, so daß mit ftp kein Zugriff auf nicht-öffentliche Files im AFS möglich ist. Die AFS-Version des ftpd befindet sich in /usr/afsws/etc/ftpd.
telnetd: Es empfiehlt sich weiterhin, das Paket esra zu installieren. Der darin enthaltene telnetd.afs ist in der Lage, für den sich anmeldenden Nutzer sofort ein Token zu beschaffen.

Neben dem Austausch von Binaries läßt sich durch zusätzliche Systemkomponenten die Arbeit mit AFS weiter komplettieren.

Dazu gehört insbesondere die Installation eines zusätzlichen inetd (/usr/afsws/etc/inetd) unter dem Namen inetd.afs und der Austausch weiterer Systembinaries. Der inetd.afs wird zusätzlich zum bereits vorhandenen inetd gestartet und ermöglicht die Übernahme eines bereits vorhandenen Tokens während rsh, rcp, rexec oder rlogin, wenn an der Client-Maschine die entsprechenden AFS-Varianten aus /usr/afsws/bin verwendet werden und auf der Server-Seite die entsprechenden Daemons ausgetauscht wurden. Die AFS-Versionen dieser Daemons findet man in /usr/afsws/etc, z.B. /usr/afsws/etc/rexecd.

Dazu müssen, neben dem Austausch der Daemon-Programme, die Einträge für shell, rexec und login aus dem Konfigurationsfile des inetd (/etc/inetd.conf) entfernt oder auskommentiert und in das Konfigurationsfile des inetd.afs (/etc/inetd.conf.afs) übernommen werden. Zusätzlich muß in /etc/inetd.conf.afs die Zeile

ta-rauth   stream  tcp  nowait  root    internal    ta-rauth

eingetragen werden. Weiterhin ist erforderlich, daß folgender Eintrag für ta-rauth in /etc/services bzw. der NIS-Map services vorgenommen wird:

ta-rauth        601/tcp        rauth   # AFS

Der Start des inetd.afs erfolgt im Zusammenhang mit dem Start des AFS Cache Managers afsd im entsprechenden rc-File.

Wegfall des `amd` für `/uni/global` auf AFS-Clients

Nachdem sämtliche vom URZ unterstützte Plattformen von /uni/global vom NFS ins AFS umgezogen sind, werden keine Reorganisationen mehr nötig sein, die Auswirkungen auf die Organisation am Client haben (vorausgesetzt man benutzt /uni/global über AFS). Deshalb ist auf AFS-Clients der amd zur Verwaltung von /uni/global nicht mehr erforderlich.

Folgende Aktionen können ausgeführt werden.

verhindern, daß /usr/etc/amd/amd.start während des Boot-Vorgangs abgearbeitet wird; dazu muß der Aufruf von /usr/etc/amd/amd.start in den rc-Files, die während des Boot-Vorgangs abgearbeitet werden, gelöscht werden
Stoppen des laufenden amd

kill amd-pid

den nächsten Schritt erst ausführen, wenn der amd wirklich nicht mehr läuft; bitte mit ps kontrollieren

Setzen folgender Links

rm -fr /uni
mkdir /uni
ln -s /afs/tu-chemnitz.de/global/karch /uni/global
ln -s /afs/tu-chemnitz.de/docu/karch /uni/docu

wobei anstelle karch der Wert der Variablen KARCH aus /usr/etc/amd/amd.start einzusetzen ist (siehe auch Struktur von /uni/global ).

Besonderheiten einiger Systeme

pmax_ul43a (Ultrix 4.3a/4.4 auf DEC 5000)

Das Beschaffen von Token (Kommandos klog, login) funktioniert nur, wenn in /etc/svc.conf die Verwendung von NIS für services ausgeschaltet wurde. Die entsprechende Zeile muß in /etc/svc.conf also so aussehen:

services=local

Das Austauschen von login führt dazu, dass der grafische Login-Manager (Xprompter), der standardmäßig für das login an der Console bei DECwindows benutzt wird, NICHT mehr funktioniert.

Lizenzbedingungen

Der folgende Text ist als File README.license in der Verteilung der AFS-Client-Software enthalten.

Dieses Verzeichnis enthält die lizensierte Software zur Installation eines AFS-Clients. Das Universitätsrechenzentrum hat von der Transarc Corporation, Pittsburgh, USA, die Rechte zur Installation und Nutzung dieser Software für die Technische Universität Chemnitz-Zwickau erworben. Die Programme in diesem Verzeichnis dürfen deshalb nur von Mitgliedern der TU Chemnitz-Zwickau kopiert und nur auf Rechnern der TU Chemnitz-Zwickau installiert und betrieben werden. Für das Betreiben eines AFS-Clients werden keine Lizenzgebühren erhoben.
Das Universitätsrechenzentrum hat die aus dem Vertragsverhältnis resultierenden Verpflichtungen an hinzukommende Nutzer weiterzugeben. Mit dem Kopieren der Software anerkennen und übernehmen das Mitglied der TU Chemnitz-Zwickau und dessen Institut diese Verpflichtungen und achten auf deren Einhalten.

Thomas Müller, 3. Mai 1995, 28. November 1996