Um in den vollen Genuss der Möglichkeiten eines Kerberos-Systems (Single Sign On) zu kommen muss man eine Kerberos-Implementierung installieren. Die Implementierung besteht im wesentlichen aus einer Kerberos Bibliothek und einigen Programmen zur Ticket(cache) Verwaltung.
Die Bibliothek muss über eine Konfigurationsdatei eine Liste von sogenannten Realm Spezifikationen erhalten, um einer DNS Adresse einen Realm, und diesem einen KDC-Server zuzuordnen. Sie muss wie folgt abgeändert werden: http://www.g4t3.de/download/krb5.ini
Die restlichen Realm-Beschreibungen (in der Sektion [Realms]) können bestehen bleiben, werden aber für uns nicht benötigt.
Diese Datei ist insofern nicht sicherheitskritisch, als dass sie problemlos gelesen werden darf. Schreibzugriff sollte allerdings nur einem Administrator gestattet sein. Ansonsten könnte durch Manipulation der kdc und admin_server Adresse eine Spoofing-Attake eingeleitet werden.
Unter Linux liegt die krb5.conf gnaz normal unter /etc/.
Voraussetzungen für die Verwendung von Kerberos sind die oben beschriebenen Einstellungen, eine bestehende Netzwerkverbindung (Internet) und Verfübarkeit des korrekten DNS-Servers. Ein ping auth.g4t3.de sollte möglich sein. Weiterhin muss die Uhrzeit des Rechners korrekt eingestellt sein.
Funktioniert dieser Test nicht, der obrige aber schon, dann arbeitet die DNS-Auflöung nicht richtig. Dass kann an einem fehlerhaften Nameserver liegen, oder auch an überchreibenden Einstellungen des Clients bzw. alten Werten in dessen Puffer.
Als SSH Client wird OpenSSH verwendet (Kerberos-Support muss einkompiliert sein).
In der ssh Konfigurationsdatei /etc/ssh/ssh_config (nicht /etc/ssh/sshd_config) muss der Wert von GSSAPIAuthentication auf yes gesetzt sein.
Der Wert von GSSAPIDelegateCredentials yes sollte bei bestimmten Anwendungen ebenfalls gesetzt werden. Mit dieser Option gibt man dem Zielrechner die Möglichkeit, die eigenen Berechtigungen einzufordern, also zum Beispiel auch entsprechende weiterführende ssh Verbindungen zu autorisieren. Generell heißt das, dass ein kompromittierter Zielhost nach einem erfolgreichen login für die Lebensdauer des TGT wie man selbst agieren könnte, insbesondere also auch Dateien löschen, Mails senden und löschen usw. Dieser Zugriff ist aber auf die Lebensdauer des TGTs beschränkt.
Auf der andern Seite ermöglicht dieser Mechanismus einigen Servern nahezu rechtelos zu laufen, da sie die für ihre Dienste erforderlichen Rechte direkt aus diesem übermittelten Ticket ziehen können. Zum einen ist es damit unmöglich, Rechte wahrzunehmen die man selbst nicht hat, und zum anderen kann ein kompromittierter Service so nur sehr begrenzten Schaden anrichten.
Eine ssh Verbindung zu dev.g4t3.de aufbauen. Nach eingabe des Benutzernamens sollte der Loginvorgang automatisch abgeschlossen werden (keine weitere Eingabe eines Passwortes).
In der damit gestarteten Shell $> ssh www eingeben. Dies sollte mit einem Permission denied vom Server verweigert werden.
Ein TGT mit aktivierter forwarding-Option ziehen (kinit -f) und den Vorgang (Einwählen nach dev.g4t3.de) wiederholen.
In der damit gestarteten Shell erneut $> ssh www eingeben. Dies sollte jetzt erfolgreich sein.
Das mit OpenSSH mitgelieferte scp kann problemlos verwendet werden.
Es ist keine weitere Konfiguration erforderlich
Eine belibige Datei per scp auf dev.g4t3.de kopieren.
Die Authentifizierung kann nicht erfolgreich durchgeführt werden.
Unter g4t3.de wird ein kerberosgesicherter Mailserver betrieben. Dieser bietet den g4t3.de usern unter anderem folgende Features:
Der Mailserver läuft auf mail.g4t3.de und ist per IMAP und SMTP erreichbar. Um auf die jeweligen Dienste zuzugreifen, wird ein entsprechendes Service-Ticket benötigt. Das heißt in der Regel, dass die Clientanwendung kerberisiert sein muss.
Um auf den IMAP Server zuzugreifen kann normales IMAP oder IMAP über SSL oder TLS verwendet werden (TLS empfohlen)
Der SMTP Server kann über mehrere Ports angesprochen werden, und erfordert eine Authentifizierung um Mails mit einer Zieladresse außerhalb der g4t3.de Domäne zu versenden (Relay). Dies ist nicht nur sinvoll, sondern auch von der DENIC erwünscht.
Hier gibt es derzeit drei verfügbare Ports.
Sollte keiner der drei Ports aufgrund von Firewalleinstellungen der Umgebung erreichbar sein, kann noch ein SSH Tunnel verwendet werden.
in den Konfigurationswerten (Erreichbar über Einstellungen -> Erweitert -> Konfiguration bearbeiten) müssen einige kerberosrelevante Werte angepasst werden:
Es sollte ein Konto mit folgenden Daten angelegt werden:
Für den Benutzernamen wird der eigene Accountname angegeben.
Weiterhin wird noch der dazugehörige SMTP-Server angelegt. Die Konfiguration erfolgt im Thunderbird unter dem Knoten Ausgehende Mailserver. Dort wird eine neuer Eintrag hinzugefügt (der Name kann frei gewählt werden), mit den folgenden Einstellungen:
Direkt in der Hauptkonfiguration z.B. des g4t3 Accounts sollte dann diese SMTP Verbindung für ausgehende Nachrichten gewählt werden. (Rechtsklick auf einen Konteneintrag -> Eigenschaften)
Es sollte ein Konto mit folgenden Daten angelegt werden:
Für den Benutzernamen wird der eigene Accountname angegeben.
Weiterhin wird noch der dazugehörige SMTP-Server angelegt. Die Konfiguration erfolgt im Thunderbird unter dem Knoten Ausgehende Mailserver. Dort wird eine neuer Eintrag hinzugefügt (der Name kann frei gewählt werden), mit den folgenden Einstellungen:
Direkt in der Hauptkonfiguration z.B. des g4t3 Accounts sollte dann diese SMTP Verbindung für ausgehende Nachrichten gewählt werden. (Rechtsklick auf einen Konteneintrag -> Eigenschaften)
In den Programm-Konfigurationswerten (Erreichbar über Einstellungen -> Erweitert -> Konfiguration bearbeiten) müssen die folgenden Werte gesetzt werden (dabei wird angenommen das der g4t3 SMTP Server der erste oder einzige ist):
in den Konfigurationswerten (Erreichbar über Einstellungen -> Erweitert -> Konfiguration bearbeiten) müssen einige kerberosrelevante Werte angepasst werden:
Es sollte ein Konto mit folgenden Daten angelegt werden:
Für den Benutzernamen wird der eigene Accountname angegeben.
Weiterhin wird noch der dazugehörige SMTP-Server angelegt. Die Konfiguration erfolgt im Thunderbird unter dem Knoten Ausgehende Mailserver. Dort wird eine neuer Eintrag hinzugefügt (der Name kann frei gewählt werden), mit den folgenden Einstellungen:
Direkt in der Hauptkonfiguration z.B. des g4t3 Accounts sollte dann diese SMTP Verbindung für ausgehende Nachrichten gewählt werden. (Rechtsklick auf einen Konteneintrag -> Eigenschaften)
Zuerst muss ein neues Konto angelegt werden.
Im Fenster Äbrufen von E-Mails"wird dann der IMAP-Server definiert.
Im Fenster "Verschicken von E-Mails"wird der SMTP-Server definiert.
Am Ende kann noch der Name des neuen Kontos eingegeben werden.
Das textbasierte mailprogramm ist auf dev.g4t3.de bereits installiert. Bei einer eigenen Installation muss darauf geachtet werden, das SASL und IMAP aktiviert sind.
Zur Konfiguration muss lediglich folgender Inhalt in die .muttrc (im Heimatverzeichniss) eingetragen werden. Dabei muss USERNAME durch den eigenen Accountnamen ersetzt werden:
Sollte das G4T3 Master Zertifikat auf dem system nicht installiert sein, fragt Mutt beim erstmaligen Verbindungsaufbau nach der Korrektheit. Nach der manuellen Prüfung kann das Zertifikat permanent (mit a) akzeptiert werden.
Soll statt dem direkten SMTP Zugang ein Tunnel verwendet werden, wird der Mail-Ausgangsserver wie folgt konfiguriert:
Der Port kann hier natürlich auch anders gewählt werden, muss aber mit dem weitergeleiteten Port des Tunnels übereinstimmen.
Vor dem Versenden von Mails muss dann ein Tunnel zu dem Mailserver aufgebaut werden. Dazu wird in Windows mittels PuTTY eine spezielle Verbindung eingerichtet:
Diese Verbindung kann manuell gestartet werden, oder aber mit einer Verknüfung auf putty.exe -load thunderbird.
Soll statt dem direkten SMTP Zugang ein Tunnel verwendet werden, wird der Mail-Ausgangsserver wie folgt konfiguriert:
Der Port kann hier natürlich auch anders gewählt werden, muss aber mit dem weitergeleiteten Port des Tunnels übereinstimmen.
Vor dem Versenden von Mails muss dann ein Tunnel zu dem Mailserver aufgebaut werden. Dazu kann das Kommando ssh -L 10025:mail.g4t3.de:25 -n dev.g4t3.de & verwendet werden.
Wenn die Mails nach dem Versand nicht in das Gesendet (oder Sent) Verzeichnis kopiert werden, so kann man versuchen in den entsprechenden Konten-Einstellungen unter Kopien und Ordner die Einstellung “Anderer Ordner” auswählen und dann über die eigene IMAP-Inbox auf Gesendet navigieren.
Wenn keiner der SMTP Ports angesprochen werden kann, oder der Mailclient keine Kerberos-Authentifizierung unterstützt, kann auch ein ssh Tunnel auf einen der g4t3-server verwendet werden um eine ausreichende Autorisierung zum Mailversand zu gewähleisten.
Bei diesem Zugang wird die Authentifizierung über den vorhandenen Tunnel hergestellt, genauer genommen durch die Tatsache dass der Mailursprung aus einem privaten Server-Adressbereich stammt. Das heißt, bevor Mails versendet werden können muss stets ein spezielle Verbindung mit dem Server hergestellt werden. Als Tunnelendpunkt wird hier dev.g4t3.de empfohlen, wobei der lokale Port auf mail.g4t3.de:25 gemappt werden muss. Wenn einer der anderen Ports verwendet wird, wird ein guter Client aufgrund der unpassenden Zertifikate zumindest eine Warnung ausgeben, evtl. sogar die Verbindung verweigern.
Ein Mailabruf ist damit jedoch nicht direkt möglich, da hier nicht nur das Vorhandensein eines Accounts, sondern auch der spezifische Account geprüft werden müssen (Jeder soll ja nur auf seine eigenen Mails zugreifen).
Wenn der Server nicht erreichbar sein sollte (aus dem Mailclient heraus), überprüfe ob der Tunnel korrekt eingerichtet ist. Ein netstat -abnp tcp sollte folgende Zeile enthalten:
Wenn der Server nicht erreichbar sein sollte (aus dem Mailclient heraus), überprüfe ob der Tunnel korrekt eingerichtet ist. Ein netstat -anp tcp –inet sollte folgende Zeile enthalten:
Auf dem Mailserver läuft ein Subsystem, welches für jeden Mailuser eine beliebige Anzahl von Mailkonten auf anderen Servern abrufen und in ein beliebiges Mailkonto übertragen kann. Die abzurufenden Mailkonten werden über LDAP Verzeichniseinträge eingerichtet, somit kann jeder Nutzer seine eigenen Einträge verwalten. Alle eingerichteten Konten werden alle 5 Minuten auf neue Mails überprüft (polling). Demzufolge ist diese Methode der Mail-Aggregation etwas schlechter als eine vom Quellserver vorgenommene direkte Weiterleitung. Solch eine Weiterleitungs-Option wird allerdings nicht von jedem Mailserver angeboten, und bei jenen die es nicht tun, bietet sich der Sammeldienst an.
Da der Sammeldienst das Passwort des abzurufenden Mailkontos benötigt, muss dieses ebenfalls in dem entsprechenden LDAP Eintrag hinterlegt werden (im Klartext). Die Einträge sind zwar geschützt, denn nur der User und der Sammeldienst haben vollen (lesenden) Zugriff auf die Einträge, LDAP Administratoren haben Zugriff auf die Einträge, nicht aber die Passwort-Attribute. Aber, ein Programm mit root Rechten auf dem LDAP Server oder dem Root-Server kann natürlich ebenfalls Zugriff auf die Daten erlangen. Insbesondere kann der Server-Administrator also auf diese Einträge zugreifen, auch auf die Passwörter.
Demzufolge sollte, so ein Konto mit diesem Mechanismus automatisch abgerufen werden soll, das Zugangspasswort vorher auf ein neues, langes (es muss ja nicht mehr manuell eingegeben werden) und möglichst zufällig generiertes, gesetzt werden. Zum einen erhöht das die Wiederstandskraft gegen Brute-Force Angriffe, und zum anderen kann mit diesem Passwort dann weder in ein anderes System eingebrochen werden, noch auf Teile anderer Passwörter geschlossen werden. Das Programm pwgen ist ein tool, mit dem man solche Passwörter erzeuchen kann. Es findet sich z.B. auf dev.g4t3.de.
Weiterhin sollte, so möglich, eine SSL gesicherte Verbindung verwendet werden. Andernfalls wäre es für einen Angreifer aufgrund der starken regelmäßigkeit und damit Vorhersagbarkeit der Zugriffe recht leicht, ein im Klartext übertragenes Passwort mitzulesen (so er irgendwie an die Route dazwischen kommt).
Die LDAP Einträge sind in dem Pfad ou=fetch,ou=mail,dc=g4t3,dc=de untergebracht. Die Klasse ist fetchmailAccount und erlaubt die folgenden Attribute:
Jeder Mailuser kann beliebige Aliasnamen auf sein Mailkonto einrichten, d.h. belibige Adressen der Form name@g4t3.de. Auch diese Mail-Aliasnamen werden über LDAP Einträge spezifiziert. Sie befinden sich in ou=alias,ou=mail,dc=g4t3,dc=de und sollten die Klasse mailTranslationTable enthalten. Diese Klasse enthält folgende Attribute:
Alle vorhanden Gruppen sind automatisch als Mailverteiler verwendbar. Um neue statische Verteiler einzurichten wird eine neue Gruppe benötigt. Derzeit können solche Gruppen nur von einem Administrator angelgt werden, dies sollte allergind nur ein kleines Hindernis darstellen.
Sollte jemand seinen Mail-Account auf g4t3.de nicht direkt abrufen ist es ratsam, die dort ankommenden Mails an eine andere Adresse weiterzuleiten.
Dazu reicht es aus, die eigene Mail-Adresse (Attribut mail im LDAP) auf die gewünschte Zieladresse zu setzen. Wenn die Mails zugleich noch an das Mailkonto auf g4t3.de gleitet werden sollen, kann auch ein doppelter mail Eintrag verwendet werden.
Seiten, welche auf dem Server liegen können mit einem Zugriffsschutz versehen werden der gegen Kerberos authentifiziert und somit keine weitere Anmeldung erfordert. Um diese Möglichkeit zu nutzen muss ein Browser verwendet werden welcher mit Kerberos zusammenarbeiten kann. Ein Beispiel dafür ist Mozilla Firefox
Nach der Installation des Firefox sollte das Zertifikat eingestellt werden. Das kann im Firefox einfach durch den Klick auf den entsprechenden Link im Download-Bereich http://g4t3.de/download/g4t3-ca-master.crt geschehen. Das Zertifikat sollte für alle drei möglichen Anwendungszwecke abgesegnet werden.
Mit dem Filter nego sind diese Einstellungen zu setzen:
Firefox starten und in die Adresszeile https://g4t3.de eingeben. Die Seite sollte, eventuell nach einer Anmeldeaufforderung des installierten Kerberos-Frontends, geladen werden könne. Dabei sollten keine Fehlermeldung (weder Zertifikat-Frage, noch Autorisierung) auftreten.
Wenn die Webseite wegen eines Access denied nicht geladen werden konnte, überprüfe folgendes:
Wenn der Browser die Gültigkeit des Zertifikates von https://www.g4t3.de abfragt, stelle sicher dass das G4T3-Master-Zertifikat korrekt in den Browser importiert wurde.
Auch der Datentransfer per FTP ist über Kerberos abgesichert und erfrodert (nach der initialen Anmeldung per Kerberos) keine Passworteingabe.
Der FTP Server läuft auf data.g4t3.de und horcht dort auf dem Standard Port 21. Um eine Verbindung herzustellen, muss eine Client das passende Service-Session Ticket besitzen (das heißt der Client muss Kerberos unterstützen, und es muss ein TGT vorhanden sein). In der Regel wird der passive Modus für den Datentransfer verwendet werden.
Es ist keine weeitere Konfiguration vornöten.
Auf dem Server können eine beliebige Anzahl von SVN Repositories betrieben werden, sei es für den ausschließlich eigenen Gebrauch, oder für eine Gruppe.
Zugriff auf die SVN Repositories erfolgt direkt über das svn Protokoll:
Für den einfachen (Client) Zugang bedarf es unter Linux keiner weiteren Konfiguration.
Vor dem Zugriff auf Kerberos-basierte SVN Repositories muss ein Ticket angefordert werden. Je Nach Anmeldeclient wird, sollte dieses zum Zugriffszeitpunkt nicht vorhanden sein, die Eingabe der User-Credentials gefordert. Dies ist jeduch nur einmalsig im Gültigkeitszeitraum des Tickets notwendig.
Wenn ein Ticket vorhanden ist, können vorhandenen Repositories unter der URL svn://data.g4t3.de/REPOSITORY angesprochen werden. REPOSITORY muss hierbei natürlich durch einen gültigen namen ersetzt werden.
Als Beispiel kann das Repository dieser Dokumentation augecheckt werden, die dazugehörige URL lautet svn://data.g4t3.de/g4t3-doc/trunk.
Dazu bedarf es folgender Schritte:
Öffne eine Konsole und gebe svn co svn://data.g4t3.de/g4t3-doc/trunk g4t3-doc ein.
Der checkout sollte erfolgreich durchgeführt werden können, in dem g4t3-doc erzeichniss sollten nun die LaTeX Quellen zi diesem Dokument aufgeführt sein.
Hier wechselt man in das Wurzelverzeichnis ders checkout-Verzeichnisses.
Dann kann mit svn info | grep URL die ursprüngliche, alte URL des Repositories ermittelt werden. Zum Beispiel svn+ssh://dev.g4t3.de/var/prj/g4t3-doc/trunk.
Die neue URL kann nun durch Ersetzen des ersten Teils (bis zum Repository-Namen mit svn://data.g4t3.de/ gebildet werden. Dies ergibt in diesem Beispiel also svn://g4t3-doc/trunk.
Immer noch im Wurzelverzeichnis des Checkouts kann mit dem dem Kommando
svn switch –relocate URL-ALT URL-NEU der Checkout an die neue
Position auf dem Server angepasst werden. Das gibt in dem Beispielfalle also:
svn switch –relocate ∖
svn+ssh://dev.g4t3.de/var/prj/g4t3-doc/trunk ∖
svn://data.g4t3.de/g4t3-doc/trunk
Hier geht es um ein Tool, um den Inhalt von lokalen Verzeichnissen mit dem Inhalt von Verzeichnissen auf dem Server abzugleichen. Unison wurde an der Universität von Pensilvania entwickelt, und stellt eine Synchronisierungslösung dar, welche sowohl unter Windows als auch Linux verfügbar ist.
Mittlerweile wurde die Weiterentwicklung offiziell zwar eingestellt, das Programm liegt aber in einer stabilen Version vor. Desweiteren ist eine kleine Community dabei immer wieder neue Versionen zu entwickeln. Unison basiert auf dem unter Unix üblichen rsync Protokoll.
Es bedarf keiner weiteren Konfiguration, allerdings muss sehr genau auf gleiche Versionsnummern geachtet werden (es wird Version 2.13.16-2 verwand). Es muss sehr genau auf die korrekte Version geachtet werden (Version 2.13.16-2).
Weiterhin müssen vor der Verwendung noch einige Umgebungsvariablen eingerichtet und ein wenig mit den Einstellungen getrickst werden. Dazu wählt man Start -> Einstellungen -> Systemsteuerung und dort System -> Erweitert -> Umgebungsvariablen.
Hier gibt es zwei Vorgehensmöglichkeiten, Es können alle Variablen Lokal, das heist nur für den gerade angemeldeten User gesetzt werden, oder ein Teil (der Userunabhängige Teil) wird allgemein für alle User auf dem System gesetzt. Auf euren Rechnern könnt ihr die Variablen besser für alle User setzen.
Je nach dem müssen die entsprechenden Variablen im oberen (user) oder unteren (system) Teil gesetzt werden, für Systemweite Variablendefinition benötigt man Administratorrechte.
Unison benötigt einen SSH Client um eine abgesicherte Verbindung zum Zielhost herzustellen. Eine Cygwin-Installation oder eine gewisse unfreie SSH Implemntierung sind vorgesehen, um die Vorzüge von Kerberos auch hier nutzen zu können muss aber das modifizierte Putty verwendet werden. Da dies nicht mit allen standard-ssh Komandozeilenoptionen zurechtkommt muss ein wenig getrickst werden. Es sollte in dem unison Verzeichnis eine Profildatei mit dem Namen connection (ohne Endung, einfache Textdatei) mit folgendem Inhalt angelegt werden: http://g4t3.de/download/connection
Dabei ist der Pfad bei rshcmd natürlich durch den entsprechend gültigen Pfad auf die modifizierte plink.exe zu ersetzen.
Weiterhin muss in dem modifizierten Putty noch eine Session für den Zielhost, dev.g4t3.de und den in 2 beschriebenen Kerberos Optionen (beide) angelegt werden. Die Option „Attempt Keyboard-interactive auth“ (gleiches Submenü) sollte deaktiviert werden. Das ganze muss unter dem sessionnamen unison abgespeichert werden.
Es sollten Profildateien für die tatsächliche Synchronisierung eingerichtet werden. Informationen dazu findet man im Unison Handbuch ( http://www.g4t3.de/download/unison-2.13.16-manual.pdf) als Beispiel sei hier folgende gegeben
( http://www.g4t3.de/download/home-sync-linux.prf)
root = /home/torian/
root = ssh://dev.g4t3.de/home/torian/lin-home
include connection
ignore = Name *.aux
ignore = Name *.bbl
ignore = Name *.blg
ignore = Name *.log
ignore = Name *.toc
ignore = Name {,.}*{.aux}
ignore = Path {.bash_history}
Die Synchronisierung kann entweder per GUI angestoßen werden (da passende Profil auswählen), oder mit der Kommandozeile.
Als Datenbank wird PostgreSQL verwendet, welches eine ausgereifte Kerberos-Anbindung ermöglicht, und mit pgAdmin steht auch ein Administrationswerkzeug zur Verfügung, welches kerberosfähig ist.
Der Datanbankserver läuft auf data.g4t3.de auf dem standard PostgreSQL Port 5432. Die Wartungs-DB ist template1.
Datei-> neuen Server hinzufügen. Der Name kann frei Gewählt werden, z.B. „G4T3 Main“, Server und Port wie oben aufgeführt. Unter Username gebt ihr euren User an, das Passwort-Feld bleibt leer und das Häcken bei Passwort speichern kann gesetzt werden. Der Rest kann auf den Standardwerten verbleiben.
Test Wenn ihr euch mit dem Server verbindet, sollte (nach dem Anklicken des Servers) dieser geladen und „Aufklappbar sein“.
Es ist keinerlei weitere Konfiguration für psql erforderlich (neben der Kerberos installation). Es muss allerdings stets der Datenbankserver mittels der -h Option mitgeliefert werden, auch wenn man sich auf data.g4t3.de eingeloggt hat.
Als erstes muss das Modul für Debian kompiliert werden. Falls er noch nicht installiert ist, dazu mit $> apt-get install module-assistant einspielen.
Dann mit $> m-a prepare openafs das herunterladen von allen zum kompilieren des opeafs-Kernelmoduls notwenidgen Paketen veranlassen. Hiernach kann mit $> m-a a-i openafs das ensprechende module erstellt werden.
Anschließend noch mit $> apt-get install openafs-client openafs-krb5 den OpenAFS client für Linux installieren und konfigurieren.
Der Zellenname für G4T3 ist g4t3.de, der primäre File- und Volumeserver ist data.g4t3.de. Der Client kann ruhig mit dem Rest des Systems gestartet werden.
Ein $> emerge net-fs/openafs net-fs/openafs-kernel mit dem aktivierten USEFLAG kerberos sollten für die Installation ausreichen. Dabei sollten beide pakete nicht in /etc/portage/package.keywords aufgeführt sein.
Wenn es hierbei zu einem Compile-Fehler kommt wird vermutlich eine inkompatible Version des Linux-Kernel verwendet. In diesem Falle kann für die Version 1.4.6_p20080222 der letzte Kernel der Version 2.6.24 verwendet werden. In Jedem Falle NICHT die unstable (maskierte) Version der openafs Pakete wählen.
Anschließend kann der OpenAFS client noch in die Autostartliste eingetragen werden mit $> rc-update add openafs-client default.
In Ubuntu 8.04 (Hardy Heron) kompiliert das OpenaAFS Paket der Version 1.4.6.dfsg1-2 nicht gegen den verwendeten Kernel 2.6.24-21-rt, wie in Bug #129480 beschrieben ( https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/129480). Hintergrundinformationen zu dem Begriff Tainted-Kernel und den GPLONLY Flags findet man unter http://www.kernel.org/pub/linux/docs/lkml/\#s1-18.
Die Paketversion 1.4.7.dfsg1- behebt diesen Fehler, ist aber erst in Ubuntu 8.10 (Intrepid Ibex) enthalten (Release am 30.10.2008).
Als erstes muss das Modul für Ubuntu kompiliert werden. Falls es noch nicht installiert ist, dazu mit $> aptitude install module-assistant einspielen.
Dann mit $> m-a prepare openafs das herunterladen von allen zum kompilieren des opeafs-Kernelmoduls notwenidgen Paketen veranlassen. Hiernach kann mit $> m-a a-i openafs das ensprechende module erstellt werden.
Anschließend noch mit $> aptitude install openafs-client openafs-krb5 den OpenAFS client für Linux installieren und konfigurieren.
Der Zellenname für G4T3 ist g4t3.de, der primäre file- und volumeserver ist data.g4t3.de.
Der Client kann ruhig mit dem Rest des Systems gestartet werden, jedoch ist hier noch eine kleine Korrektur vonnöten, wie auch aus folgendem Bugreport zu entnehmen ist: https://bugs.launchpad.net/ubuntu/+source/openafs/+bug/318605. Das Setzen der Option AFS_DYNROOT=true in der Datei /etc/openafs/afs.conf.client ermöglicht das fehlerfreie Funktionieren von AFS.
Sollten diese Einstellungen aufgrund des installtionsmechanismus nicht abgefragt werden (Gentoo, Debian mit entsprechenden debconf-Einstellungen), so muss der Zellenname (g4t3.de) in /etc/openafs/ThisCell eingetragen werden, z.B. mit $> echo ’g4t3.de’ > /etc/openafs/ThisCell. Weiterhin muss der g4t3.de fileserver in die /etc/openafs/CellServDB eingefügt sein.
Der dazugehörige Ausschnitt:
>g4t3.de
193.34.68.212 # data.g4t3.de
Eine passende Datei kann auch direkt von http://g4t3.de/download/CellServDB heruntergeladen werden.
Anschließend noch den client starten (mit $> /etc/init.d/openafs-client start) und es kann losgehen. Der AFS-Namensraum wird normalerweise in /afs gemountet.
Allgemeines Vorgehen:
Spezielle Fehlerfälle: