Ein evtl. schon vorhandenes Kerberos Ticket kann auch über den Webbrowser zur Authentifizierung an Webseiten genutzt werden. Da der zentrale WebSSO Dienst der FAU diese Art der Authentifizierung unterstützt können somit alle angebundenen Webseiten ohne weitere Anpassungen ebenfalls davon Gebrauch machen.

Nach erfolgter Konfiguration Ihres Browsers, bedeutet dies, dass Sie automatisch via Kerberos am WebSSO Dienst der FAU angemeldet werden, sobald Sie auf eine entsprechend angebundene Webseite zugreifen – ohne zusätzliche Passworteingabe.

Voraussetzungen

Voraussetzung für diese Anleitung ist eine funktionierende Grundkonfiguration von Kerberos für Ihr System. Falls noch nicht geschehen, führen Sie bitte die entsprechenden Einrichtungsschritte wie beschrieben durch, bevor Sie dieser Anleitung weiter folgen.

Ob Ihr System korrekt konfiguriert ist, können Sie wie folgt prüfen.

bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_Zn59m9
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting Expires Service principal
01.06.2017 14:30:51 02.06.2017 00:30:51 krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

Der Aufruf von klist sollte eine ähnliche Ausgabe wie im Beispiel als Ergebnis liefern.

Konfiguration

In der Regel übermitteln die gängigen Webbrowser ein evtl. vorhandenes Kerberos Ticket aus Sicherheitsgründen nicht automatisch. Um die Übermittlung für bestimmte Domains freizuschalten bedarf es je nach Browser einiger spezieller Einstellungen.

In den unten aufgeführten Konfigurationsbeispielen wird jeweils der zentrale WebSSO Dienst der FAU freigeschalten. Für andere Dienste, die nicht das zentrale SSO nutzen sind zusätzliche Einträge erforderlich.

Mozilla Firefox

Zur Konfiguration von Mozilla Firefox gehen Sie bitte wie folgt vor.

• Geben Sie in die Adressleiste Ihres Browsers about:config ein
• Bestätigen Sie die Sicherheitswarnung
• Suchen Sie nach negotiate
• Passen Sie die folgende Einträge an

network.negotiate-auth.delegation-uris = .sso.uni-erlangen.de,.sso.fau.de
network.negotiate-auth.trusted-uris = .sso.uni-erlangen.de,.sso.fau.de

So sollte es am Ende aussehen.

Chromium

Zur Konfiguration von Chromium gehen Sie bitte wie folgt vor.

bash$ sudo vi /etc/chromium-browser/default
...
CHROMIUM_FLAGS="--auth-server-whitelist=.sso.uni-erlangen.de,.sso.fau.de --auth-negotiate-delegate-whitelist=.sso.uni-erlangen.de,.sso.fau.de"
..

Google Chrome

Zur Konfiguration von Google Chrome gehen Sie bitte wie folgt vor.

bash$ sudo mkdir -m 755 -p /etc/opt/chrome/policies/managed
bash$ sudo vi /etc/opt/chrome/policies/managed/kerberos.json 
{ 
     "AuthServerWhitelist": "*.sso.uni-erlangen.de,*.sso.fau.de", 
     "AuthNegotiateDelegateWhitelist": "*.sso.uni-erlangen.de,*.sso.fau.de" 
}
bash$ sudo chmod o+rx /etc/opt/chrome/policies/managed/kerberos.json

Kerberos Tickets haben eine begrenzte Laufzeit und müssen vor Ablauf durch eine erneute Passworteingabe erneuert werden. Der RRZE-Standard sieht eine Ticketlaufzeit von 10 Stunden vor, was für einen normalen Arbeitstag ausreichend ist.
Bei länger laufenden Prozessen, z.B. Simulationen oder sonstige aufwendige Berechnungen kann das Ablaufen des Kerberos Tickets jedoch zu Problemen führen.

Im Folgenden werden die Probleme beschrieben, die bei langlaufenden Prozessen im Zusammenhang mit Kerberos auftreten können und Lösungsmöglichkeiten aufgezeigt.

Problembeschreibung

In der Standardkonfiguration des LINUXKDC ist definiert, das ein Ticket maximal 10 Stunden gültig ist und bis auf maximal 7 Tage verlängert werden kann. (Dies entspricht übrigens auch den Windows-Standardwerten: https://technet.microsoft.com/en-us/library/dd277401.aspx)

Das heißt alle 10 Stunden muss ein Benutzer sein Passwort eingeben, um sein Ticket zu erneuern. Das kann z.B. implizit beim Entsperren des Bildschirms passieren oder explizit durch den Aufruf von kinit (siehe unten) oder erneutes Einloggen. Sperrt man ab und zu seinen Bildschirm (z.B. in der Mittagspause), so wird hier beim Entsperren ein neues Ticket vergeben und es entstehen keine Probleme.

Durch Zusatztools wie krenew (siehe unten) kann eine automatisierte Verlängerung des Tickets auf die maximale Laufzeit von 7 Tagen erreicht werden.

Für Prozesse, die über einen längeren Zeitraum Berechnungen anstellen und auf ein gültiges Ticket (z.B. zum Zugriff auf das Home-Verzeichnis) angewiesen sind, kann ein ablaufendes Ticket allerdings zum Problem werden. Eigentlich möchte man sicherstellen, dass das Ticket bis zur Beendigung des Prozesses nicht abläuft.

Lösungsmöglichkeiten

Verschiedene Strategien für langlaufende Prozesse mit Kerberos.

Verlängerte Ticketlaufzeit anfordern (max. 24 Stunden Laufzeit)

Mit kinit kann explizit ein neues Ticket beim LINUXKDC angefordert werden.

Unter Verwendung bestimmter Optionen kann ein länger laufendes bzw. ein spezielles, verlängerbares Ticket erworben werden, um damit langlaufende Prozesse auszuführen. Im Folgenden werden einige Anwendungsszenarien dokumentiert.

Ticket erneuern

Dies ist der Standard-Weg, um ein neues Ticket mit der Standardlaufzeit von 10 Stunden anzufordern oder ein bestehendes zu erneuern.

bash$ kinit
Password for [Kennung]@LINUX.FAU.DE:

bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting       Expires              Service principal
05.04.2017 15:33:55  06.04.2017 01:33:55  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

Ticket mit erweiterter/definierter Laufzeit anfordern

Die Standardlaufzeit von 10 Stunden ist ein eine clientseitige Beschränkung, die mit einem Parameter auf das serverseitige Limit von 24 Stunden angehoben werden kann.

# Ticket mit einer Laufzeit (lifetime) von 24 Stunden anfordern (=maximal mögliche Laufzeit ohne Verlängerung)
bash$ kinit -l 24h
Password for [Kennung]@LINUX.FAU.DE:

bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting       Expires              Service principal
05.04.2017 15:38:13  06.04.2017 15:38:13  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

Verlängerbares Ticket anfordern

Sollte das immer noch nicht ausreichen, kann ein spezielles, verlängerbares Ticket angefordert werden. Dieses kann für maximal 7 Tage ohne Passworteingabe, aber durch Verwendung von krenew, gültig gehalten werden.

# Ticket mit Verlängerungsmöglichkeit (renewable) auf 7 Tage anfordern (=maximal mögliche Verlängerung)
bash$ kinit -r 7d
Password for [Kennung]@LINUX.FAU.DE:

bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE

05.04.2017 15:40:37  06.04.2017 01:40:37  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
	renew until 12.04.2017 15:40:37

Der Einsatz von krenew wird im folgenden Absatz beschrieben.

Automatisierte Verlängerung durchführen (max. 7 Tage Laufzeit)

Eine Möglichkeit zur automatisierten Verlängerung von Tickets ist die Verwendung von krenew.

So kann automatisiert z.B. jede Stunde geprüft werden, ob das aktuelle Ticket bald abläuft und ggf. eine Verlängerung des Tickets beim LINUXKDC angefordert werden.

Voraussetzung hierfür ist die Verwendung eines erneuerbaren (renewable) Tickets. Wie Sie ein solches Ticket anfordern können finden Sie oben in der Dokumentation zum Befehl kinit (siehe oben).

Installation und Anwendung können wie folgt durchgeführt werden.

bash$ sudo apt-get install kstart
...

bash$ klist
Ticket cache: FILE:/tmp/krb5cc_[UID]_kZe3jz
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting       Expires              Service principal
05.04.2017 12:49:29  05.04.2017 22:49:29  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE
	renew until 12.04.2017 12:49:29

bash$ krenew -v -- sh -c './compute_job.sh >> compute_job.log'
krenew: renewing credentials for [Kennung]@LINUX.FAU.DE

Die Zeile
renew until 12.04.2017 12:49:29
zeigt an bis wann der Job abgeschlossen sein muss, bzw. wie lange das Ticket maximal verlängert werden kann.

Wichtig!

If a command is given, krenew makes a copy of the ticket cache and
creates a private ticket cache just for that command, thus isolating it
from later destruction of the original ticket cache.  This allows
krenew to maintain authentication for a command even if, for example,
the user running the command logs out and OpenSSH destroys their
original ticket cache.

(Auszug aus der Manpage zu krenew)

Das bedeutet, dass das Kommando auch z.B. nach Beendigung einer SSH-Session noch über ein gültiges Ticket verfügt.
Allerdings wird dadurch auch verhindert, dass durch ein erneutes Einloggen beziehungsweise einen Aufruf von kinit das „Kommando-Ticket“ verlängert wird.

Nur lokale Ressourcen verwenden (unbegrenzte Laufzeit)

Durch Verwendung lokaler Ressourcen kann die Abhängigkeit von einem gültigen Kerberos Ticket vermieden werden.
In der Praxis bedeutet das normalerweise, dass alle nötigen Daten auf einer lokalen Festplatte vorgehalten werden müssen oder zumindest nicht im Home-Laufwerk oder einem anderen Netzlaufwerk, das Keberos verwendet, abgelegt sein dürfen.

Falls dies praktikabel ist, stellt es die stabilste Variante dar und ermöglicht eine unbegrenzte Laufzeit des Prozesses.

Diese Anleitung beschreibt die vom RRZE empfohlene Grundkonfiguration zur Anbindung eines Ubuntu-Systems an die Kerberos Infrastruktur des RRZE. Die meisten Schritte sind allerdings allgemeingültig uns können für eigene Installationen leicht angepasst werden.

Nach Durchführung aller Schritte wird bei Systemanmeldung automatisch ein Kerberos-Ticket zur Verfügung gestellt und Anmeldungen per SSH an und von dem System sind per Kerberos-Authentifizierung möglich. Außerdem können CIFS und NFSv4 Netzlaufwerke kerberos-authentifiziert eingebunden werden.

Pakete für Ubuntu 20.04 und höher

# i-want-it-all one-liner
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install krb5-user libsasl2-modules-gssapi-mit libpam-krb5 nfs-common keyutils cifs-utils openssh-server openssh-client

# single services

# for kerberos login authentication
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install krb5-user libpam-krb5 

# for kerberized ssh logins (client + server side)
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install openssh-server openssh-client

# for kerberos nfsv4 mounts
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install nfs-common keyutils 

# for kerberized windows cifs mounts
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install cifs-utils 

# to enable kerberos support via GSSAPI for various software packages (e.g. pidgin)
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install libsasl2-modules-gssapi-mit

Kerberos Join (LINUX.FAU.DE) / Download der Keytab

Der Kerberos Join ermöglicht eine Anbindung des Clients an die LDAP Infrastruktur des RRZE, sowie den Bezug einer Keytab mit ServicePrincipals, um eigene Dienste mit Kerberos-Authentifizierung anzubieten. Klassischerweise ist das unter Linux z.B. der Host-Principal für per Kerberos authentifizierte SSH Logins auf dem Client.

Der Join (genauer: eine Keytab mit NFS-Principal) wird ebenfalls benötigt, um NFSv4-Freigaben einbinden zu können.

Die entsprechende Anleitung zur Aktivierung von Kerberos für Ihr System finden Sie auf der Seite des rrzelinux Kommandozeilenwerkzeugs unter „Kerberos Join durchführen„.

Konfiguration

Einrichtung der verschiedenen Dienste.

Kerberos

Die Grundkonfiguration für Kerberos an der FAU ist können Sie nach folgendem Beispiel übernehmen.
Bitte beachten Sie die Kommentare und führen Sie ggf. notwendige Anpassungen durch.

bash$ for i in $(grep -l minimum_uid=1000 /etc/pam.d/* | grep -v -e bak -e old); do echo $i; sudo sed -i -e 's/minimum_uid=1000/minimum_uid=2000/' $i; done

bash$ sudo cp /etc/krb5.conf /etc/krb5.conf_old
bash$ sudo vi /etc/krb5.conf

[libdefaults]
    default_realm = LINUX.FAU.DE
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

    # maximum is 24h - but client defaults to 10h
    ticket_lifetime = 10h


[realms]
    FAUAD.FAU.DE = {
        kdc = fauad.fau.de:88
        auth_to_local = RULE:[1:$1]
        auth_to_local = DEFAULT
    }
    LINUX.FAU.DE = {
        kdc = linuxkdc.rrze.uni-erlangen.de:88
        auth_to_local = RULE:[1:$1]
        auth_to_local = DEFAULT
    }
    EXCH.FAU.DE = {
        kdc = exch.fau.de:88
        auth_to_local = RULE:[1:$1]
        auth_to_local = DEFAULT
    }
    UBAD.FAU.DE = {
        kdc = ubad.fau.de:88
        auth_to_local = RULE:[1:$1]
        auth_to_local = DEFAULT
    }

[domain_realm]
    # Add domain-realm mappings here
    # Additional mapping are necessary to map hostnames to a kerberos realm other than 
    # the default realm set below
    # Examples:
    # some-windows-host.xyz.uni-erlangen.de = FAUAD.FAU.DE
    # some-linux-host.xyz.uni-erlangen.de = LINUX.FAU.DE
    # ...

    # some usual windows hosts
    mordor.rrze.uni-erlangen.de = FAUAD.FAU.DE
    moloch.rrze.uni-erlangen.de = FAUAD.FAU.DE
    home.rrze.uni-erlangen.de = FAUAD.FAU.DE
    projekte.rrze.uni-erlangen.de = FAUAD.FAU.DE
    fauprint.rrze.uni-erlangen.de = FAUAD.FAU.DE
    fauprint2.rrze.uni-erlangen.de = FAUAD.FAU.DE
    wisoprint.wiso.uni-erlangen.de = FAUAD.FAU.DE
    wisoprint2.wiso.uni-erlangen.de = FAUAD.FAU.DE
    rocky.rrze.uni-erlangen.de = FAUAD.FAU.DE
    newton.wiso.uni-erlangen.de = FAUAD.FAU.DE
    fausmb.rrze.uni-erlangen.de = FAUAD.FAU.DE
    mecke12.rrze.uni-erlangen.de = FAUAD.FAU.DE
    godzilla.rrze.uni-erlangen.de = FAUAD.FAU.DE
    .exch.fau.de = EXCH.FAU.DE
    .ubad.fau.de = UBAD.FAU.DE

     # choose what should be the default below

     # if not specified otherwise - all hosts will be seen as members of the FAUAD.FAU.DE realm by default
     #.fau.de = FAUAD.FAU.DE
     #.uni-erlangen.de = FAUAD.FAU.DE

     # if not specified otherwise - all hosts will be seen as members of the LINUX.FAU.DE realm by default
    .fau.de = LINUX.FAU.DE
    .uni-erlangen.de = LINUX.FAU.DE

[login]
    #krb4_convert = true
    #krb4_get_tickets = false

[logging]
     kdc = SYSLOG:INFO:DAEMON
     admin_server = SYSLOG:INFO:DAEMON
     default = SYSLOG:INFO:DAEMON

SSH Client

Folgende Einstellungen ermöglichen das kerberos-authentifizierte Einloggen auf anderen Systemen via SSH.

bash$ sudo cp /etc/ssh/ssh_config /etc/ssh/ssh_config_old
bash$ sudo vi /etc/ssh/ssh_config
...
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
GSSAPITrustDns yes 
...

SSH Server

Folgende Einstellungen ermöglichen das kerberos-authentifizierte Einloggen  von anderen Systemen via SSH.

bash$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_old
bash$ sudo vi /etc/ssh/sshd_config
...
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
...

NFS Client

Folgende Einstellungen konfigurieren das Name-Id-Mapping für NFSv4 Netzlaufwerke.

bash$ sudo cp /etc/idmapd.conf /etc/idmapd.conf_old
bash$ sudo vi /etc/idmapd.conf

[General]
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs

# have no fear - we only need fauad.fau.de as single unified namespace!
Domain = fauad.fau.de
Local-Realms = LINUX.FAU.DE,FAUAD.FAU.DE
    
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

CIFS Client

Folgende Einstellungen ermöglichen das kerberos-authentifizierte Einbinden von CIFS Netzlaufwerken.

bash$ sudo cp /etc/request-key.conf /etc/request-key.conf_old
bash$ sudo vi /etc/request-key.conf
...
create  cifs.spnego     *       *               /usr/sbin/cifs.upcall -t %k
...

bash$ sudo cp /etc/request-key.d/cifs.spnego.conf /etc/request-key.d/cifs.spnego.conf_old
bash$ sudo vi /etc/request-key.d/cifs.spnego.conf

create  cifs.spnego     *       *               /usr/sbin/cifs.upcall -t %k

Generic Security Api (GSS)

Stellen Sie sicher der der gssd gestartet ist:

bash$ ps aux | grep gssd
root 1760 0.8 0.0 43796 3852 ? Ss Nov15 112:24 /usr/sbin/rpc.gssd

Sollte das nicht der Fall sein , so starten Sie den gssd mittels

# Ubuntu 20.04 und höher
bash$ sudo systemctl start rpc-gssd

Restart/Reboot

Nach der Umstellung auf Kerberos – insbesondere bei Verwendung der NFS/CIFS Funktionalität – ist ein Reboot dringend empfohlen. Generell können Tests mit falschen oder unvollständigen Konfigurationen dazu führen, dass der Kernel ungültige Informationen cached und dadurch darauffolgende Versuche – sogar mit korrekter Konfiguration – fehlschlagen. Leider scheint der einzig effektive Weg ein Reboot zu sein, um sicher zu gehen, dass jegliche Caches geleert sind (Stichwort: Kernel keyring).

Test

Um die korrekte Einrichtung zu verifizieren können die hier beschriebenen Tests durchgeführt werden.

Kerberos

bash$ kinit [Kennung]
bash$ klist

Ticket cache: FILE:/tmp/krb5cc_[UID]_qdIQWB
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting       Expires              Service principal
17.11.2016 16:07:22  18.11.2016 16:07:22  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

SSH Client

bash$ ssh dialog.rrze.uni-erlangen.de

# login success

bash$ klist

Ticket cache: FILE:/tmp/krb5cc_[UID]_fNDrEQQxAx
Default principal: [Kennung]@LINUX.FAU.DE

Valid starting       Expires              Service principal
17.11.2016 17:16:44  18.11.2016 16:07:22  krbtgt/LINUX.FAU.DE@LINUX.FAU.DE

NFS

bash$ sudo mkdir /mnt/rzlin
bash$ sudo mount -t nfs4 -o minorversion=1,sec=krb5p rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome /mnt/rzlin
bash$ sudo su $USER
bash$ cd /mnt/rrzelinuxhome/$USER
bash$ ls -al

insgesamt 1116
drwx------   52 [Kennung] fau_user        12288 Nov 17 17:16 .
drwx-----x 6254 root     root            483328 Nov 17 15:05 ..
...

bash$ exit
bash$ sudo umount /mnt/rzlin
bash$ sudo rmdir /mnt/rzlin

CIFS

bash$ id

uid=[UID]([KENNUNG]) gid=100000(fau_user) Gruppen=100000(fau_user),...

# root werden
bash$ sudo su 
bash$ mkdir -p /mnt/rzwin/[KENNUNG]

# WICHTIG: Der Mount-Befehl benötigt root-Rechte aber die Felder [KENNUNG]/[UID] (siehe Ausgabe des "id" Befehls) müssen auf einen unprivilegierten Zugang verweisen, für den ein Home-Verzeichnis tatsächlich existiert.
bash$ mount -t cifs -o user=[KENNUNG],domain=FAUAD,sec=krb5,cruid=[UID],multiuser,noserverino,nodfs,vers=2.1 //home.rrze.uni-erlangen.de/[KENNUNG] /mnt/rzwin/[KENNUNG]

# Anmerkung für Ubuntu 17.10:
# Scheinbar ist hier außerdem die Angabe der SMB Version erforderlich
# Beispiel: -o vers=2.1

bash$ su [KENNUNG]
bash$ cd /mnt/rzwin/[KENNUNG]
bash$ ls -al
...

bash$ exit
bash$ umount /mnt/rzwin/[KENNUNG]
bash$ rmdir /mnt/rzwin/[KENNUNG]
bash$ rmdir /mnt/rzwin

Autofs – oft auch automounter genannt – ermöglicht es nach entsprechender Konfiguration, Einhängevorgänge allein durch den Zugriff auf den entsprechenden Zielpfad im Dateisystem automatisch durchführen zu lassen.
Der Einhängevorgang erfordert keine root-Rechte mehr, da er vom autofs Prozess durchgeführt wird.

Pakete für Ubuntu 20.04 und höher

bash$ sudo apt-get install autofs

Aufbau

Die folgenden Beispiele setzen voraus, dass die Strukturierung der Home-Laufwerke nach folgendem Aufbau erfolgt.

Konfiguration

Im Folgenden wird eine Beispielkonfiguration vorgestellt, die in ähnlicher Form auch auf den Servern des RRZE im Einsatz ist.
Enthalten sind diverse Dateien zur Konfiguration von Einhängepunkten und einige Beispiele für Fileserver, die evtl. nützlich sein könnten.

Bitte beachten Sie, dass nicht alle Einhängepunkte exakt zu übernehmen sind!
Sehr wahrscheinlich werden Sie Anpassungen an Ihre Gegebenheiten vornehmen müssen. Die Dateistruktur sollte nach Möglichkeit jedoch beibehalten werden, um den Support im Fehlerfall zu vereinfachen.

Die Beispielkonfiguration umfasst die folgenden Dateien mit jeweiligem Inhalt.

/etc/auto.master

• erster Einsprungpunkt in die Konfiguration der Einhängepunkte
• lokale Konfiguration von Einhängepunkten
• hier ist der Platz, um weitere Einhängepunkte zu konfigurieren oder Dateien zu referenzieren

# Home mounts
/home /etc/auto.home --ghost

# Wildcard mounts for RRZE windows homes
/home/rzwin /etc/auto.rzwin

# Project mounts 
# (optional for respective projects)
#/proj /etc/auto.proj --ghost

# Generic network mounts 
# (optional) 
#/net /etc/auto.net --ghost

/etc/auto.home

• Einhängepunkte für diverse Home-Filer unter /home/$prefix
• generell nützlich, vor allem wenn Personen Homes an verschiedenen Einrichtungen besitzen
• hier können Sie auch Ihren eigenen Home-Filer unter Ihrem Präfix einfügen
• kann auf das nötige Minimum reduziert werden

# Home mounts

# Archiv
archiv alexandria.rrze.uni-erlangen.de:/archiv/archiv

# NFSv4 RRZE linuxhome
rzlin -fstype=nfs4,minorversion=1,sec=krb5p rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome
rzleg -fstype=nfs4,minorversion=1,sec=sys rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome.sys

# CIFS RRZE windowshome
# see auto.rzwin

/etc/auto.rzwin

• Einhängen von RRZE Windows-Homes (siehe auch Windows Shares unter Linux einbinden)

# Wildcard mounts for windows homes

# CIFS Windows home filer (rrzefiler.rrze.uni-erlangen.de)
* -fstype=cifs,user=$USER,domain=FAUAD,sec=krb5,cruid=$UID,multiuser,noserverino,vers=2.1 ://home.rrze.uni-erlangen.de/&

/etc/auto.proj

• optional (bei Verwendung auch in auto.master aktivieren)
• Einhängepunkte für Projekt-Filer
• momentan keine öffentlichen Beispiele für Projekt-Filer vorhanden, Sie können hier jedoch eigene Einträge ergänzen

/etc/auto.net

• optional (bei Verwendung auch in auto.master aktivieren)
• Einhängepunkte für sonstige Netzlaufwerke
• momentan keine öffentlichen Beispiele für sonstige Filer vorhanden, Sie können hier jedoch eigene Einträge ergänzen

Dienst neu starten

Nach erfolgter Konfiguration ist der autofs Dienst neu zu starten

Ubuntu 20.04 und höher / Systemd

bash$ sudo systemctl restart autofs

Fehlersuche

Bei Problemen können einige Ansätze zur Fehlersuche/-behebung abgearbeitet werden.

Logs

Ein guter Anhaltspunkt bei Problemen mit Einhängepunkten ist immer das syslog.

bash$ less /var/log/syslog

Konfiguration

Mit folgendem Befehl lässt sich die Konfiguration anhand des Inhaltes der obigen Dateien anzeigen.

bash$ sudo automount -m 
autofs dump map information
===========================

global options: none configured
Mount point: /home

source(s):

  instance type(s): file 
  map: /etc/auto.home

  rzlin | -fstype=nfs4,minorversion=1,sec=krb5p rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome
  campus | faunfs.rrze.uni-erlangen.de:/samfs_shome/campus
  archive | alexandria.rrze.uni-erlangen.de:/archiv/archiv
  studhome | faunfs.rrze.uni-erlangen.de:/samfs_shome/campus
  rzleg | -fstype=nfs4,minorversion=1,sec=sys rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome.sys
  rrze | faunfs.rrze.uni-erlangen.de:/samfs_mhome/rrze
  archiv | alexandria.rrze.uni-erlangen.de:/archiv/archiv


Mount point: /home/rzwin

source(s):

  instance type(s): file 
  map: /etc/auto.rrzewindowshome

  * | -fstype=cifs,user=$USER,domain=FAUAD,sec=krb5,cruid=$UID,multiuser,noserverino ://home.rrze.uni-erlangen.de/&

...

Beschreibt die Einrichtung eines NFSv4 Fileservers unter Ubuntu.

Siehe auch das offizielle Ubuntu NFSv4Howto für weitere Infos.

Pakete für Ubuntu 20.04 und höher

bash$ sudo apt-get install nfs-kernel-server

Konfiguration

Beschreibt die weitere Konfiguration des NFSv4 Servers.

Kerberos

Ihr Server muss für Kerberos konfiguriert sein!
Für Hilfe bei der Konfiguration von Kerberos folgen Sie bitte der Anleitung zur Anbindung Ihres Client/Servers an die RRZE-Infrastruktur.

Für den Betrieb mit Kerberos muss auch ein entsprechender Service-Principal für NFS vorhanden sein.
Prüfen Sie dies bitte mit folgendem Befehl.

bash$ sudo klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   ...
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (aes256-cts-hmac-sha1-96) 
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (aes128-cts-hmac-sha1-96) 
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (des3-cbc-sha1) 
   2 nfs/[IHR SERVER]@LINUX.FAU.DE (arcfour-hmac)

Darüber hinaus sind Anpassungen an den folgenden beiden Dateien nötig.

bash$ sudo vi /etc/default/nfs-common

...
NEED_GSSD=yes
...

bash$ sudo vi /etc/default/nfs-kernel-server

...
NEED_SVCGSSD="yes"
...

Damit ist die Konfiguration von Kerberos bezüglich des NFSv4 Servers abgeschlossen.

Vorbereiten des pseudo-root Verzeichnisses für Exports

Durch Konfiguration eines pseudo-root Verzeichnisses für NFS Exports wird der exportierte Pfad unabhängig vom echten Pfad auf dem Server.
Das erleichtert ggf. einen später notwendigen Umzug der Daten.

Zur Vorbereitung erstellt man ein Verzeichnis, das alle späteren Exports enthalten soll und fasst dort alle Daten mittels Bind-Mounts zusammen.

bash$ mkdir /export
bash$ mount --bind /some/nested/data/dir /export/sys
...

Die Bind-Mounts müssen in der /etc/fstab eingetragen werden, damit die Exports nach dem nächsten Reboot wieder genauso zur Verfügung gestellt werden können.

bash$ cat /etc/fstab
....
/some/nested/data/dir /export/sys none bind
...

Exportierte Verzeichnisse

Die freizugebenden Verzeichnisse werden wie folgt konfiguriert.
Der erste Eintrag markiert dabei das Basisverzeichnis des pseudo-root Dateisystems durch die Option fsid=0.

bash$ sudo vi /etc/exports

# Pseudo-root für NFSv4
/export                               169.254.0.0/255.255.255.128(rw,no_subtree_check,fsid=0,crossmnt)

# Beispiel für Export mit Kerberos-Authentifizierung und Verschlüsselung
/export/krb5_enc                      169.254.0.0/255.255.255.128(rw,async,sec=krb5p,no_subtree_check)

# Beispiel für Export mit Kerberos-Authentifizierung und nur Integritätscheck
/export/krb5_int                      169.254.0.0/255.255.255.128(rw,async,sec=krb5i,no_subtree_check)

# Beispiel für Export mit Kerberos-Authentifizierung und Verschlüsselung (präferiert) und nur Integritätscheck als Fallback
/export/krb5_enc_or_int               169.254.0.0/255.255.255.128(rw,async,sec=krb5p:krb5i,no_subtree_check)

# Beispiel für Export mit nur Kerberos-Authentifizierung
/export/krb5                          169.254.0.0/255.255.255.128(rw,async,sec=krb5,no_subtree_check)

# Beispiel für Export ohne Kerberos-Authentifizierung
/export/sys                           169.254.0.0/255.255.255.128(rw,async,sec=sys,no_subtree_check)
...

Mit folgendem Befehl können Sie die exportierten Verzeichnisse anhand der oben vorgenommenen Konfiguration aktualisieren (Re-export).

bash$ sudo exportfs -rv
exporting 169.254.0.0/255.255.255.128:/export/krb5_enc
exporting 169.254.0.0/255.255.255.128:/export/krb5_int
exporting 169.254.0.0/255.255.255.128:/export/krb5
exporting 169.254.0.0/255.255.255.128:/export/sys

Nach erfolgreicher Aktualisierung (oder auch jederzeit zur Überprüfung) können Sie die aktuell aktiven exportierten Verzeichnisse wie folgt abfragen.

bash$ sudo exportfs -v
/export/krb5_enc 169.254.0.0/255.255.255.128(rw,async,sec=krb5p,no_subtree_check)
/export/krb5_int 169.254.0.0/255.255.255.128(rw,async,sec=krb5i,no_subtree_check)
/export/krb5 169.254.0.0/255.255.255.128(rw,async,sec=krb5,no_subtree_check)
/export/sys 169.254.0.0/255.255.255.128(rw,async,sec=sys,no_subtree_check)

Test

Der mount Befehl liefert leider oft nicht die besten Fehlermeldungen, was die Diagnose im Fehlerfall erschwert.
Generell wird empfohlen zum Testen immer die -v Option zu setzen, um mehr Informationen über die ausgeführten Aktionen zu bekommen.
Außerdem ist ein explizites Anfordern der NFS Version zB mit -t nfs4 oder -o vers=4 statt dem generischen -t nfs ratsam.

Einbinden von Exports auf dem Client

Beispielaufruf:

bash$ mount -v -t nfs4 server:/sys /mnt/sys

Ein erfolgreicher Mount mit NFSv4.2 sollte in etwa folgende Ausgabe liefern.
Man beachte die Angabe des Exports auf dem Server relativ zum pseudo-root.

bash$ mount -v -t nfs server:/sys /mnt/sys
mount.nfs: timeout set for Tue Nov  6 12:29:36 2018
mount.nfs: trying text-based options 'vers=4.2,addr=131.188.xxx.xxx,clientaddr=10.188.xxx.xxx'

Ein fehlerhafter Mount mit Fallback auf NFSv3 sieht in etwa so aus.
Man beachte die Angabe des Exports auf dem Server als absoluten Pfad, was durch NFSv4 nicht mehr unterstützt wird und nach einem entsprechenden Fehler den Fallback zu NFSv3 auslöst.

bash$ mount -v -t nfs server:/export/sys /mnt/sys
mount.nfs: timeout set for Tue Nov  6 12:29:20 2018
mount.nfs: trying text-based options 'vers=4.2,addr=131.188.xxx.xxx,clientaddr=10.188.xxx.xxx'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'addr=131.188.xxx.xxx'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 131.188.xxx.xxx prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 131.188.xxx.xxx prog 100005 vers 3 prot UDP port 45103

Der Einsatz von Docker erfreut sich steigender Beliebtheit.
Diese Seite gibt Hilfestellungen und Hinweise zum Betrieb von Docker-Containern an der FAU.

Inhalt

Schnellzugriff auf wichtige Themen:

• Docker-Netzwerk einrichten (Wichtig!)
  vermeidet Probleme durch IP-Kollisionen im FAU Netz
• Dockerhub-Mirror einrichten
  vermeidet Probleme durch Rate-Limiting von Dockerhub ab 1.4.2025

TL;DR Hier können Sie ein Skript zur vollautomatischen Installation herunterladen.

Voraussetzungen

Die offizielle Anleitung zur Installation von Docker finden Sie unter https://docs.docker.com/engine/install/ubuntu/.

Das RRZE bietet auch einen APT Mirror des Docker Repositories an, der wie folgt genutzt werden kann:

Pakete für Ubuntu

# Remove potentially obsolete docker sources
sudo rm -f /etc/apt/sources.list.d/rrze-mirror-docker.list /etc/apt/sources.list.d/rrze-mirror-docker.sources

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL http://homespun.rrze.uni-erlangen.de/mirror/download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
sudo tee /etc/apt/sources.list.d/rrze-mirror-docker.sources > /dev/null <<EOF
Types: deb
URIs: http://homespun.rrze.uni-erlangen.de/mirror/download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Options: by-hash=no
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt-get update

# Cleanup old 
# https://docs.docker.com/engine/install/ubuntu/
sudo apt remove docker.io docker-compose docker-compose-v2 docker-doc podman-docker
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Konfiguration

Hier finden Sie wichtige Hinweise zur korrekten Konfiguration Ihres Docker-Setups im FAU Netz.

Docker Bridge/Netzbereich

Docker verwendet ein eigenes Subnetz das über die Docker-Bridge docker0 mit dem restlichen Netzwerk kommuniziert.
Standardmäßig verwendet dieses Subnetz den Adressbereich 172.17.0.0/16
Um Kollisionen mit bereits verwendeten Adressbereichen auszuschließen wird empfohlen einen Bereich aus nicht-routbaren LinkLocal Adressen für Docker zu verwenden (zB 169.254.254.1/24).

bash$ cat << EOF | sudo tee -a /etc/netplan/02-idrac.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    idrac:
      addresses: [169.254.0.2/24]
EOF

bash$ sudo netplan apply

Um den Netzbereich anzupassen sind die folgenden Schritte notwendig.

Ubuntu ab 18.04 (Systemd)

1. Docker-Daemon Konfiguration anpassen

bash$ sudo systemctl edit docker

2. Folgenden Inhalt einfügen

[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H unix:// --bip=169.254.254.1/24
# Ende

3. Überprüfen der Konfiguration

bash$ sudo cat /etc/systemd/system/docker.service.d/override.conf
...
bash$ sudo systemctl cat docker
...

4. Neustart des Docker-Daemons (ACHTUNG: Startet auch alle Container neu!)

bash$ sudo systemctl restart docker

5. Überprüfen der docker0 IP

bash$ ip address show docker0
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:06:dd:bb:5c brd ff:ff:ff:ff:ff:ff
    inet 169.254.254.1/24 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:6ff:fedd:bb5c/64 scope link 
       valid_lft forever preferred_lft forever

Das wars 🙂

Docker Daemon / Dockerhub Mirror

Um den Nutzern an der FAU weiterhin einen schnellen Zugriff auf Images von Dockerhub zu ermöglichen, stellt das RRZE einen zentralen Dockerhub Mirror bereit. Dieser ist als Pull-Through Cache für Dockerhub Images konfiguriert (siehe auch https://docs.docker.com/docker-hub/image-library/mirror/). Bei Nutzung des zentralen Dockerhub Mirror werden Images über einen zentralen, unlimitierten Account von Dockerhub abgerufen und dann für 180 Tage zwischengespeichert.

Es wird allen Nutzern an der FAU empfohlen die entsprechende Konfiguration zur Nutzung der Dockerhub Mirrors zu verwenden:

sudo tee /etc/docker/daemon.json <<'EOF'
{
  "registry-mirrors": [
    "https://dockerhub-mirror3.rrze.uni-erlangen.de",
    "https://dockerhub-mirror2.rrze.uni-erlangen.de",
    "https://dockerhub-mirror1.rrze.uni-erlangen.de"
  ]
}
EOF

sudo systemctl restart docker

Die Reihenfolge der Mirrors kann zur Lastverteilung ggf. verändert werden. Es sollten aber immer alle drei eingetragen werden, da bei Wartungsarbeiten zeitweise auch mal ein Mirror offline sein kann.
Es wird jeweils der erste Mirror verwendet, der eine erfolgreiche Antwort liefert. Als letztes wird automatisch versucht das Image von Dockerhub abzurufen.

Leider ist zum aktuellen Stand nicht bekannt wie man auf Client-Seite einfach prüfen kann, ob die konfigurierten Mirrors erfolgreich verwendet wurden.

Startskripte

Docker-Container mit dem Linux Initsystem starten

Ubuntu ab 18.04 (Systemd)

Als Basis für eigene Anpassungen empfehlen wir zum Beispiel folgendes Init-Skript zum automatischen Anlegen und starten eines neuen Containers basierend auf einem existierenden Docker-Image.
Alle Informationen zum Erstellen des Containers sind im Skript bereits enthalten.
So benötigt man für einfache Setups kein zusätzliches Tool, wie docker-compose, um die Konfiguration der Container zu verwalten.

1. Startskript erstellen

bash$ cat /etc/systemd/system/docker.openldap.service

[Unit]
Description=OpenLDAP
Requires=docker.service
After=docker.service

[Service]
User=root
Restart=on-failure
RestartSec=10
ExecStartPre=-/usr/bin/docker stop openldap
ExecStartPre=-/usr/bin/docker rm openldap

ExecStart=/usr/bin/docker run \
--name openldap \
-h openldap.example.net \
-p 10.20.30.40:389:389 \
-p 10.20.30.40:636:636 \
-v /opt/apps/openldap/logs/:/var/log \
YOUR-REGISTRY/openldap:latest

ExecStop=-/usr/bin/docker stop openldap

[Install]
WantedBy=multi-user.target

2. Starten des Containers

bash$ sudo systemctl daemon-reload
bash$ sudo systemctl enable docker.openldap # <-- beim Booten automatisch starten
bash$ sudo systemctl start docker.openldap

3. Update des Images von der Registry

bash$ sudo docker pull YOUR-REGISTRY/openldap:latest

latest: Pulling from openldap
9fb6c798fa41: Already exists
3b61febd4aef: Already exists
....
f93db066217e: Pull complete
Digest: sha256:17059dc182304950aab5ca13bb6373b7d7efc0ff7641382cf75cb621f6e7734f
Status: Downloaded newer image for YOUR-REGISTRY/openldap:latest

bash$ sudo systemctl restart docker.openldap

Rechteverwaltung / docker-Gruppe

Um auch normalen Benutzern – außer root – den Zugriff auf den Docker-Daemon zu gewähren, kann man diese in die Gruppe docker aufnehmen.

Die docker Gruppe wird nach Installation des Docker Pakets automatisch als lokale Gruppe erstellt.
Danach können Sie Kennungen mit folgendem Kommando zur Gruppe hinzufügen:

bash$ sudo usermod -aG docker $KENNUNG

pam_group (obsolet)

Die folgende Methode fügt eine Benutzerkennung bei der Anmeldung dynamisch zur benötigten lokalen docker Gruppe hinzu (siehe auch https://help.ubuntu.com/community/LDAPClientAuthentication#Assign_local_groups_to_users).

bash$ echo '*;*;[KENNUNG];Al0000-2400;docker' >> /etc/security/group.conf

bash$ cat /etc/security/group.conf
...
*;*;[KENNUNG];Al0000-2400;docker