Um nicht abhängig von der Verfügbarkeit externer Paketquellen zu sein und/oder die Verteilung von Paketen an viele Clients bei beschränkter Bandbreite der Internetanbindung zu beschleunigen, kann ein lokaler Mirror der benötigten Paketquellen eingerichtet werden.

Diese Anleitung beschreibt die Einrichtung eines Mirrors für Ubuntu Personal Package Archives (PPA) mit apt-mirror.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

Es werden Kenntnisse im Umgang mit Linux und der APT-Paketverwaltung vorausgesetzt.

Pakete

Die folgender Pakete müssen installiert werden.

Ubuntu 16.04

bash$ sudo apt-get install apt-mirror

Einrichtung

Nach der Installation der Pakete müssen lediglich die zu spiegelnden PPAs konfiguriert werden.
Um Zugriff auf den Mirror durch die Clients zur Verfügung zu stellen wird ebenfalls ein Webserver, wie z.B. Apache oder Nginx benötigt.

Siehe auch https://wiki.ubuntuusers.de/apt-mirror/ für weitere Informationen.

Konfiguration von apt-mirror

Die Konfiguration wird am Beispiel des PHP PPAs von Ondřej Surý durchgeführt und kann leicht auf weitere PPAs erweitert werden.

bash$ cat /etc/apt/mirror.list
############# config ##################
set base_path    /var/spool/apt-mirror
set mirror_path  $base_path/mirror
set skel_path    $base_path/skel
set var_path     $base_path/var
set cleanscript $var_path/clean.sh
#set postmirror_script $var_path/postmirror.sh
#set run_postmirror 0

set limit_rate 500K # 10 * 500K = 5000K = 5M => 50MBit
set nthreads     10
set _tilde 0
############# end config ##############

# PHP
deb http://ppa.launchpad.net/ondrej/php/ubuntu xenial main 
deb http://ppa.launchpad.net/ondrej/php/ubuntu trusty main 
deb http://ppa.launchpad.net/ondrej/php/ubuntu bionic main 
clean http://ppa.launchpad.net/ondrej/php/ubuntu

Automatische Synchronisation per Cronjob

Das apt-mirror Paket liefert gleich einen passenden Cronjob mit, der nur noch aktiviert werden muss.

bash$ cat /etc/cron.d/apt-mirror
#
# Regular cron jobs for the apt-mirror package
#
0 4 * * * apt-mirror /usr/bin/apt-mirror > /var/spool/apt-mirror/var/cron.log

Bereitstellen der Pakete

Damit Clients den Mirror nutzen können muss serverseitig die Pakete per HTTP freigegeben werden (z.B. mittels Apache oder Nginx).
Die Installation des entsprechenden Webservers vorausgesetzt ist hierfür nur noch ein entsprechender Symlink notwendig.

Zum Beispiel

bash$ ln -s /var/spool/apt-mirror/mirror/ /var/www/html/

Einbinden auf den Clients

Um den Mirror zu nutzen, kann eine entsprechende Datei unter /etc/apt/sources.list.d/ erstellt werden.
Wegen https://bugs.launchpad.net/ubuntu/+source/apt-mirror/+bug/1586573 muss (sofern der Bug noch besteht) auf das hashbasierte Abrufen der Pakete verzichtet werden.

bash$ cat /etc/apt/sources.list.d/mirror-php.list
deb [arch=amd64 by-hash=no] http://[your-server]/mirror/ppa.launchpad.net/ondrej/php/ubuntu bionic main

Test

Die Synchronisation kann zum Test jederzeit manuell gestartet werden.

bash$ sudo -u apt-mirror apt-mirror

Downloading 42 index files using 10 threads...
Begin time: Thu Nov 15 12:02:43 2018
[10]... [9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]... [0]... 
End time: Thu Nov 15 12:02:43 2018

Processing translation indexes: [TTT]

Downloading 9 translation files using 9 threads...
Begin time: Thu Nov 15 12:02:43 2018
[9]... [8]... [7]... [6]... [5]... [4]... [3]... [2]... [1]... [0]... 
End time: Thu Nov 15 12:02:43 2018

Processing DEP-11 indexes: [DDD]

Downloading 0 dep11 files using 0 threads...
Begin time: Thu Nov 15 12:02:43 2018
[0]... 
End time: Thu Nov 15 12:02:43 2018

Processing indexes: [PPP]

0 bytes will be downloaded into archive.
Downloading 0 archive files using 0 threads...
Begin time: Thu Nov 15 12:02:43 2018
[0]... 
End time: Thu Nov 15 12:02:43 2018

0 bytes in 0 files and 0 directories can be freed.
Run /var/spool/apt-mirror/var/clean.sh for this purpose.

Running the Post Mirror script ...
(/var/spool/apt-mirror/var/postmirror.sh)


Post Mirror script has completed. See above output for any possible errors.

Problembehebung

Falsche Dateirechte nach Ausführung als root

APT-mirror legt beim Aufruf verschiedene Dateien mit den Rechten des aufrufenden Benutzers an. Da der Cronjob allerdings als Benutzer apt-mirror läuft klappt der Zugriff im Anschluss nicht mehr.
Zur Behebung kann man sich ein kleines Bash Script anlegen, dass man im Anschluss ausführt.

bash$ cat /root/fix-apt-mirror-permissions.sh 
#!/bin/bash
chown -R apt-mirror:apt-mirror /var/spool/apt-mirror/
chmod -R u=rwX,g=rwX,o=rX /var/spool/apt-mirror/

Bei der Verwendung von Windows-Netzlaufwerken (Shares) unter Linux ist einiges zu beachten, um eine reibungslose Funktion sicherzustellen.
Neben den verschiedenen Methoden einen Mount unter Linux generell zu realisieren, sind auch einige Eigenheiten von Windows/Linux zu beachten.

Diese Anleitung beschreibt einige gängige Varianten, um Windows-Netzlaufwerke unter Ubuntu einzubinden und liefert unter Anderem auch Beispiele für die Nutzung mit der FAUAD.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

Es werden root-Zugriff auf den Rechner und allgemeine Kenntnisse im Umgang mit der Linux-Konsole vorausgesetzt.

Für Varianten mit Kerberos Authentifizierung ist die Einrichtung Kerberos erforderlich.
Entsprechende Hinweise zur Konfiguration von Kerbero finden Sie unter „Kerberos Grundkonfiguration„.

Pakete

Die folgenden Pakete müssen installiert werden.

CIFS unter Ubuntu 20.04 und höher

Für das Common Internet File System (CIFS) werden folgende Pakete benötigt.

bash$ sudo apt-get install cifs-utils

GVFS unter Ubuntu 20.04 und höher

Für Gnome Virtual Filesystem (GVFS) werden folgende Pakete benötigt.
Bei einer Standard Ubuntu-Desktop Installation sind diese Pakete in der Regel schon als Teil von ubuntu-desktop vorinstalliert.

bash$ sudo apt-get install gvfs gvfs-bin gvfs-backends gvfs-fuse

FUSE unter Ubuntu 20.04 und höher

Für Nutzung des Filesystem in USErspace (FUSE) werden folgende Pakete benötigt.
Bei einer Standard Ubuntu-Desktop Installation sind diese Pakete in der Regel schon als Teil von ubuntu-desktop vorinstalliert.

bash$ sudo apt-get install fuse

Besonderheiten zu Windows Distributed File Services (DFS) und der FAUAD

Windows (und damit auch die FAUAD) nutzen ein Feature namens Distributed File Services (DFS), um die von diversen Shares genutzten Pfade auf konkrete Dateiserver zu Mappen, die dann letztendlich den Dienst stellen. DFS-Pfade erkennt man an der Nutzung von fauad.fau.de als Servernamen.

Leider ist die Unterstützung dieses Features in den Linux-Implementierungen des CIFS-Protokolls nicht komplett integriert. Der empfohlene Workaround ist die direkte Nutzung der entsprechenden Dateiserver anstatt des DFS-Pfades (inkl. der genannten Nachteile bei Umstellungen).

Detaillierte Erklärung

Der Vorteil dieses Systems liegt daran, das bei Umzug eines Dateidienstes auf einen neuen Server lediglich das Mapping des bestehenden DFS-Pfades angepasst werden muss. Alle angebundenen Clients bleiben von der Änderung verschont, da diese weiterhin den ungeänderten DFS-Pfad nutzen und über das angepasste Mapping automatisch auf den neuen, aktualisierten Dateiserver geleitet werden.

Speziell wird in der FAUAD eine Aufteilung der Rechner auf mehrere Sites vorgenommen, die von der aktuellen CIFS Implementierung nicht beachtet wird. Daher kommt es bei Nutzung von DFS-Pfaden in CIFS-Mounts zu dem geht/geht-nicht Phänomen – je nachdem, ob man zufällig auf einem Domänenkontroller in der richtigen Site landet, oder eben nicht.

Einrichtung

Mountvorgänge für das Common Internet File System (CIFS) mittels mount.cifs können in der Regel nur mit root-Rechten durchgeführt werden.
Der Zugriff kann dann – je nach Dateirechten – als normaler Benutzer erfolgen.

Um auch als unprivilegierter Benutzer Netzlaufwerke einhängen zu können stehen ebenfalls verschiedene Möglichkeiten zur Verfügung. Zum Beispiel ermöglicht das Gnome Virtual Filesystem (GVFS) schon seit längerem das Einbinden von diversen Netzlaufwerkstypen über die graphische Oberfläche ohne besondere Rechte. Als Grundlage des gvfs-fuse Moduls soll auch das Filesystem in USErspace (FUSE) nicht unerwähnt bleiben.

Die Folgenden Abschnitte zeigen wie man die häufigsten Anwendungsfälle mit den verschiedenen Tools  bewältigen kann und geht auf Vor- und Nachteile, sowie die Besonderheiten der Lösungen ein.

Zunächst kann man zwischen zwei großen Hauptkategorien unterscheiden: systemweites oder benutzerbezogenes Einrichten eines Netzlaufwerkes

Systemweite Einrichtung

Das systemweite Einhängen von Netzlaufwerken ermöglicht den Zugriff durch alle Benutzer des Systems (passende Benutzer-/Dateirechte vorausgesetzt), kann aber nur als Administrator mit root-Rechten vorgenommen werden.

Manuelles Einhängen mit dediziertem Benutzer

Ein einfaches Beispiel ist das Einhängen mittels des mount Befehls auf der Konsole.

# mount
bash$ sudo mount -t cifs -o user=$USER,uid=$UID,gid=0,file_mode=0660,dir_mode=0770,domain=FAUAD,noserverino,nodfs,vers=2.1 //projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share /mnt/projekte
Password for $USER@//projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share: ********

# check rights (uid/gid are mapped as access rights for the mountpoint)
bash$ ls -aldn /mnt/projekte
drwxr-xr-x 2 $UID 0 0 Mai 15 14:08 /mnt/projekte/

# umount
bash$ sudo umount /mnt/projekte

Der Einhängepunkt ist so zwar generell durch den Benutzer uid=$USER und alle Mitglieder der Gruppe gid=0 nutzbar, allerdings gelten auf dem Dateiserver lediglich die Rechte des Benutzers user=$USER mit dem der Mount aufgebaut wurde, egal welcher Benutzer auf Client-Seite den Zugriff durchführt.

Zudem ist der Mount nicht persistent, wird also nach Verlust des Mounts nicht wiederhergestellt.

Manuelles Einhängen mit Kerberos-Authentifizierung

Im Prinzip funktioniert dieser Mount ähnlich dem vorhergehenden, mit dem Unterschied, das die Authentifizierung gegen den Dateiserver diesmal nicht mit manuell einzugebenden Daten und nur einem Benutzer erfolgt.
Stattdessen kann jeder per Kerberos authentifizierte Benutzer des System mit den Rechten seines eigenen Prinzipals auf den Dateiserver zugreifen.
Siehe hierzu auch Kerberos Grundkonfiguration zur Einrichtung von Kerberos auf Ihrem System.

bash$ sudo mount -t cifs -o domain=FAUAD,sec=krb5,cruid=$UID,multiuser,noserverino,nodfs,vers=2.1 //projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share /mnt/projekte

Möglich wird dies durch die Option multiuser:

multiuser
Map user accesses to individual credentials when accessing the server. By default, CIFS mounts only use a
single set of user credentials (the mount credentials) when accessing a share. With this option, the client
instead creates a new session with the server using the user’s credentials whenever a new user accesses the
mount. Further accesses by that user will also use those credentials.  Because the kernel cannot prompt
for passwords, multiuser mounts are limited to mounts using sec= options that don’t require passwords.

Nach erfolgreichem Mount können nun alle per Kerberos authentifizierten Benutzer des Systems auf das Netzlaufwerk mit ihren eigenen Benutzerrechten zugreifen.
Allerdings ist der Mount noch immer nicht persistent und wird bei einem Verbindungsabbruch nicht wiederhergestellt.

Automatisches Einhängen mit autofs

AutoFS ermöglicht die das automatische Ein- und Aushängen von Netzlaufwerken bei Bedarf und ermöglicht es auch Mounts nach Verbindungsabbrüchen wiederherzustellen.
Beachten Sie bitte hierzu  bitte zunächst die Hinweise zum Betrieb von AutoFS am RRZE.

Ein zu den bisherigen Beispielen passender Eintrag in der Datei /etc/auto.proj könnte zum Beispiel wie folgt aussehen:

bash$ sudo vi /etc/auto.proj
projekte -fstype=cifs,domain=FAUAD,sec=krb5,multiuser,cruid=$UID,noserverino,nodfs,vers=2.1 ://projekte.rrze.uni-erlangen.de/rrze_projekte/RRZE-Share

Vergessen Sie nicht nach Änderungen der Konfiguration den autofs Dienst neu zu starten.

Die Verwendung von AutoFS ist vom RRZE für die meisten Fälle empfohlen.

Benutzerbezogene Einrichtung

Das benutzerbezogene Einhängen von Netzlaufwerken ermöglicht lediglich den Zugriff durch den aktuellen Benutzer und kann ohne Administratorrechte durchgeführt werden.

Halbautomatisches Einhängen mittels GVS

Siehe  Gnome Samba Client.

Um Softwarepakete auf Debian-basierten Systemen (wie zB Ubuntu) zu verwalten kommt in der Regel das Paketverwaltungsystem rund um APT (Advanced Packaging Tool) zum Einsatz.  Dieses sehr mächtige System bietet eine Reihe von Möglichkeiten Pakete zu installieren und aktuell zu halten.

Diese Anleitung beschreibt das vom RRZE empfohlene Vorgehen im Umgang mit der APT Paketverwaltung und gibt Lösungsvorschläge für einige häufig auftretende Szenarien.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte, bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

Es werden grundlegende Kenntnisse im Umgang mit Ubuntu und der Kommandozeile vorausgesetzt.

Die Verwendung der erweiterten Funktionen wird nur erfahrenen Anwendern empfohlen.

Pakete

Folgender Pakete für Ubuntu 16.04/18.04 müssen installiert werden:

bash$ sudo apt-get install apt

Basisfunktionen

Hier soll auf die wichtigsten Kommandos und Abläufe im täglichen Umgang mit der APT Paketverwaltung eingegangen werden.
Weitere Informationen finden Sie auch auf der Ubuntu APT Übersichtsseite.

Paketquellen einrichten und aktualisieren

Die Konfiguration der APT Paketquellen findet sich unter /etc/apt/sources.list bzw. /etc/apt/sources.list.d/.

Sollten hier Erweiterungen um neue Paketquellen vorgenommen werden, empfiehlt es sich eine neue Datei mit thematisch passendem Namen und der Endung .list unter /etc/apt/sources.list.d/ anzulegen und die entsprechenden Repositories dort zu erfassen.
Die Datei /etc/apt/sources.list wird eher für die System-/Basiskonfiguration der Ubuntu Paketquellen verwendet und sollte nicht für externe Repositories „missbraucht“ werden.

Sobald Änderungen an den Paketquellen vorgenommen wurden oder die letzte Aktualisierung schon eine Weile her ist sollten die Paketinformationen aktualisiert werden bevor neue Pakete installiert oder Aktualisierungen eingespielt werden.

Die Aktualisierung der Paketquellen erfolgt mittels

bash$ sudo apt update

Pakete finden/installieren/entfernen

System aktuell halten

Einzelne Pakete von der Aktualisierung ausnehmen

Regelmäßige Aufräumarbeiten

Erweiterte Funktionen

Die hier beschriebenen Funktionen sollten nur von erfahrenen Anwendern verwendet werden, die wissen was sie tun.

Paketversion festziehen / Updates verhindern

Um Updates von Paketen zu verhindern können diese auf hold gesetzt werden:

bash$ sudo apt-mark hold firefox

Oder zum erneuten freigeben für Updates:

bash$ sudo apt-mark unhold firefox

Siehe auch https://wiki.ubuntuusers.de/apt/apt-Kommandos/ für weitere Informationen.

Priorisierung von Paketen und Paketquellen mit Apt-Pinning

Ein wesentlich mächtigeres Werkzeug um zu steuern wie Pakete installiert werden, ist das Apt-Pinning.
Hier kann in einer oder mehreren Konfigurationsdateien unter /etc/apt/preferences.d/ das Verhalten von APT beeinflusst werden.

TODO

Siehe auch https://wiki.ubuntuusers.de/Apt-Pinning/ für weitere Informationen.

Werte für Pin-Priority

Die Werte für Pin-Priority müssen positive oder negative ganze Zahlen sein. Sie werden wie folgt interpretiert:

• größer 999: Version wird in jedem Fall installiert, auch wenn das einen Downgrade des Paketes nach sich zieht
• von 990 bis 999 – Version wird installiert, auch wenn sie nicht zum Release gehört, es sei denn ein aktuelleres Pakete ist bereits installiert
• von 500 bis 989 – Version wird installiert, es sei denn, es gibt eine Version, die zum Release gehört oder eine aktuellere Version ist bereits installiert
• von 100 bis 499 – Version wird installiert, es sei denn, es gibt eine aktuellere die nicht zum Release gehört oder die bereits installierte Version ist aktueller
• von 1 bis 99 – Version wird nur dann installiert, wenn es keine bereits installierte gibt
• negativer Wert – Version wird nicht installiert

Das Paket mit der höchsten Punktzahl wird immer bevorzugt.

Beispiel: Pakete aus externen PPAs beschränken (inkl. erzwungenem Downgrade)

Diese Beispiel schlägt eine Möglichkeit vor, wie der Einfluss von externen Paketquellen eingeschränkt werden kann.
Besonders ist hier die Nutzung der Pin-Priority > 1000, um ebenfalls ein Downgrade bereits eingeschleppter Fremdpakete auf die offiziellen Ubuntu Versionen möglich zu machen.

bash$ sudo vi /etc/apt/preferences.d/LP-PPA

# Manually deployed packages in the RRZE RepRepo instance
Package: *
Pin: release o=RRZE Reprepro
Pin-Priority: 2000

# Saltstack PPA
Package: *
Pin: release o=SaltStack
Pin-Priority: 2000

# The local source (e.g. manually installed packages or packages that are not in any repo anymore)
Package: *
Pin: release a=now
Pin-Priority: 1900

# Ondrej Apache2 PPA
Package: *
Pin: release o=LP-PPA-ondrej-apache2
Pin-Priority: 1500

# Ondrej PHP PPA
Package: *
Pin: release o=LP-PPA-ondrej-php
Pin-Priority: 1500

Package: openssl
Pin: release o=LP-PPA-*
Pin-Priority: -1

# Official "Ubuntu" repos
Package: *
Pin: release l=Ubuntu
Pin-Priority: 1000

Um Systeme mit sensiblen Daten vor unbefugtem Zugriff zu schützen, können beim RRZE besondere Netzzugriffsfilter (ACLs) beantragt werden, die über netzseitige Hardware-Firewalls realisiert werden. In manchen Fällen kann es dennoch sinnvoll sein zusätzlich eine lokale Firewall zu pflegen, um zum Beispiel erhöhte Sicherheitsanforderungen oder sich häufig ändernde Regeln abbilden zu können.

Diese Anleitung beschreibt das vom RRZE empfohlene Anlegen und Verwalten einer IP-Tables basierten lokalen Firewall unter Ubuntu.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Voraussetzungen

Es werden Kenntnisse im Umgang mit Firewalls im Allgemeinen und IP-Tables im Speziellen vorausgesetzt.

Pakete

Die folgenden Pakete müssen installiert werden.

Ubuntu 16.04

bash$ sudo apt-get install netfilter-persistent iptables-persistent

Ubuntu 18.04

bash$ sudo apt-get install netfilter-persistent iptables-persistent

Einrichtung

Das netfilter-persistent Paket liefert bereits einige Möglichkeiten, um Firewall-Regeln aus dem laufenden Betrieb zu persistieren und beim Systemstart wieder zu laden.
Eine kurze Einführung in die wichtigsten Funktionen finden Sie unten.
Für weitere Informationen besuchen Sie am besten die Ubuntu Manpage zu netfilter-persistent

Systemdienst einrichten

Der netfilter-persistent Dienst wird über die Plugins in /usr/share/netfilter-persistent/plugins.d/ konfiguriert.
Die Aufrufe des Init-Systems werden im Wesentlichen an alle verfügbaren Plugins der Reihe nach weitergereicht.

Der netfilter-persistent Dienst kennt die folgenden Aufrufe:

# Load firewall rules from /etc/iptables/rules.v[4|6]
# IMPORTANT: stop can be called but is essentially a no-op
bash$ sudo systemctl start netfilter-persistent

# Flush the firewall rules
bash$ sudo netfilter-persistent flush

# Show some status info
bash$ sudo systemctl status netfilter-persistent

# Enable loading of configured rules on startup
bash$ sudo systemctl enable netfilter-persistent

Regeln erstellen/persistieren

Um Firewall Regeln zu erstellen nutzt man am besten die iptables Kommandos, um die Firewall manuell zu konfigurieren.
Eine bestehende Konfiguration kann dann mittels

bash$ sudo systemctl save netfilter-persistent

gespeichert werden.
Nach dem Speichern kann die Konfiguration in den Dateien /etc/iptables/rules.v4 bzw /etc/iptables/rules.v6 wiedergefunden werden.
Weitere Änderungen können – dem Format folgend – auch direkt in diesen Dateien vorgenommen werden.

Beim Systemstart wird die Firewall aus den Regeln dieser Dateien wieder aufgebaut.

Regeln flushen/Firewall deaktivieren

Um die Regeln der Firewall komplett zu entladen und somit die Firewall zu deaktivieren, kann man entweder das entsprechende netfilter-persistent Kommando oder direkt IP-Tables verwenden.
WICHTIG: Ein Stoppen des netfilter-persistent Dienstes bewirkt kein deaktivieren der Firewall!

bash$ sudo netfilter-persistent flush
bash$ sudo iptables -F

Erweiterung um benutzerdefinierte Skripte

Um es beispielsweise zu ermöglichen, dynamische Firewallregeln aus einem Bash-Skript zu laden oder zu generieren kann auch der Plugin-Mechanismus von netfilter-persistent, um ein Plugin zum Aufruf eines entsprechenden Bash-Skriptes erweitert werden.

Die beiden nötigen Dateien samt Inhalt können nach folgender Anleitung erstellt werden.
Im Anschluss nicht vergessen die entsprechenden Regeln zu definieren!

Skript für benutzerdefinierte Regeln

# create rules.custom skript and fill it with your firewall rules/generation script
bash$ sudo touch /etc/iptables/rules.custom
bash$ sudo chmod +x /etc/iptables/rules.custom
bash$ sudo vi /etc/iptables/rules.custom 
#!/bin/bash
set -e 
rc=0

load_rules() {
        # add config here
        echo "Called load_rules()!"   
}

flush_rules() {
        # add config here
        echo "Called flush_rules()!" 
}

case "$1" in
start)
        load_rules
        ;;
stop|flush)
        flush_rules
        ;;
*)
    echo "Usage: $0 {start|stop|flush}" >&2
    exit 1
    ;;
esac

exit $rc

Plugin für netfilter-persistent

# create netfilter-persistent plugin to execute your rules.custom script
bash$ sudo vi /usr/share/netfilter-persistent/plugins.d/99-custom
#!/bin/sh
set -e
rc=0

load_rules(){
	if [ ! -x /etc/iptables/rules.custom ]; then
		echo "Warning: skipping rules.custom (no rules to load)"
	else
		/etc/iptables/rules.custom start 2> /dev/null
		if [ $? -ne 0 ]; then
			rc=1
		fi
	fi
}

flush_rules(){
	if [ ! -x /etc/iptables/rules.custom ]; then
		echo "Warning: skipping rules.custom (no rules to flush)"
	else
		/etc/iptables/rules.custom flush 2> /dev/null
		if [ $? -ne 0 ]; then
			rc=1
		fi
	fi
}

case "$1" in
start|restart|reload|force-reload)
	load_rules
	;;
save)
	echo "Warning: skipping save_rules on rules.custom - not supported!"
	;;
stop)
	# Why? because if stop is used, the firewall gets flushed for a variable
	# amount of time during package upgrades, leaving the machine vulnerable
	# It's also not always desirable to flush during purge
	echo "Automatic flushing disabled, use \"flush\" instead of \"stop\""
	;;
flush)
	flush_rules
	;;
*)
    echo "Usage: $0 {start|restart|reload|force-reload|save|flush}" >&2
    exit 1
    ;;
esac

exit $rc

Test

Testen Sie die korrekte Initialisierung der Firewall einfach mit

bash$ sudo iptables -L

Das RRZE stellt für die FAU den Windows-Druckserver FAUPRINT bereit, der zum authentifizierten Drucken auf den angeschlossenen Geräten genutzt werden kann.
Für RRZE-betreute Geräte stellt dies die empfohlene Art der Anbindung dar und ist auch für Linux-Systeme empfohlen.

Die Nutzung von FAUPRINT erlaubt das authentifizierte Drucken auf Geräten, für die Sie die entsprechenden Berechtigungen besitzen. Optional ist auch eine Abrechnung bzw. Verwaltung von Druckkontingenten über die Software Papercut möglich (aktuell nur für CIP-Pools / Studierende). Hierfür fallen allerdings zusätzliche Kosten an.
Kontaktieren Sie uns diesbezüglich gerne für weitere Informationen.

Die Authentifizierung erfolgt wahlweise per IdM-Benutzername und Kennwort oder Kerberos.

Voraussetzungen

Pakete für Ubuntu ab 20.04

# one-liner
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get -y install samba-common samba python3-smbc smbclient

Kerberos

Voraussetzung für die Nutzung der Kerberos-Authentifizierung 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.

Achten Sie besonders darauf, dass auch die folgenden Anpassungen durchgeführt wurden:

bash$ cat /etc/krb5.conf
...
[domain_realm]
    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
...

Des Weiteren muss für das Drucken über Kerberos ein angepasster ksmb Backend-Handler installiert werden.
Der folgende Handler ist für die Verwendung mit FAUPRINT angepasst und kann nicht als allgemeiner Handler verwendet werden.

bash$ sudo vi /usr/lib/cups/backend/ksmb

#!/bin/bash
if [ $# -eq 0 ]; then
 echo "network ksmb ""Unknown"" ""Windows Printer via SAMBA using Kerberos"""
 exit 0
fi

REALM=FAUAD.FAU.DE
LOGFILE=/var/log/cups/krb5-smb_log
LOGPREFIX="[$$]"

CUPSBACKENDPATH=${0%/*}

# Options: smbspool {job} {user} {title} {copies} {options} [filename]
BACKEND_JOB="$1"
BACKEND_USER="$2"
BACKEND_TITLE="$3"
BACKEND_COPIES="$4"
BACKEND_OPTIONS="$5"
BACKEND_USERID=$(id -u "$BACKEND_USER")

# fix handling in case multiple ccache files are available
# Use newest as authentication source
KRB5FILE=$(find /tmp/ -mindepth 1 -maxdepth 1 -name "krb5cc_*" -user "$BACKEND_USER" -printf "%A@ %p\n" | sort -n | tail -n 1 | cut -d' ' -f2-)

if [ -z "$KRB5FILE" ]; then
 echo "$LOGPREFIX: ERROR: No valid credential cache found" >> "$LOGFILE"
 echo "$LOGPREFIX: exit 2 (CUPS_BACKEND_AUTH_REQUIRED)" >> "$LOGFILE"
 exit 2 # CUPS_BACKEND_AUTH_REQUIRED
fi
export KRB5CCNAME="FILE:$KRB5FILE"

# Dirty hack: Required if cross-realm ticket does not (yet) exist
DEVICE_URI_NOPREFIX="${DEVICE_URI#*//}"
PRINC="${DEVICE_URI_NOPREFIX%%/*}"
kvno cifs/$PRINC@$REALM >> "$LOGFILE"

# DEVICE_URI *must* begin with "smb://" otherwise odd errors will occur
export DEVICE_URI="smb://${DEVICE_URI_NOPREFIX}"

# Settings can be passed from backend to scheduler using
# stderr. Look here for details ("Communicating with the Scheduler"):
# https://www.cups.org/doc/api-filter.html
BACKEND_STDERR=$(${CUPSBACKENDPATH}/smb "$BACKEND_JOB" "$BACKEND_USER" "$BACKEND_TITLE" "$BACKEND_COPIES" "$BACKEND_OPTIONS" 2> /dev/stdout > /dev/null)
BACKEND_EXIT=$?

echo "$BACKEND_STDERR" | sed -e s+^+"$LOGPREFIX: stderr: "+ >> "$LOGFILE"

# Prevent smb backend from re-enabling username/password authentication
BACKEND_STDERR=$(echo "$BACKEND_STDERR" | sed 's/^ATTR: auth-info-required=.*/ATTR: auth-info-required=negotiate/')

echo "$BACKEND_STDERR" > /dev/stderr
exit "$BACKEND_EXIT"

Zuletzt nicht vergessen, die Rechte noch korrekt zu setzen.

bash$ sudo chmod 700 /usr/lib/cups/backend/ksmb

Konfiguration

Arbeitsgruppe konfigurieren

Damit die Authentifizierung an der FAUAD Domain klappt muss die Arbeitsgruppe auf dem Linux-Client entspechend konfiguriert werden:

bash$ sudo mv /etc/samba/smb.conf /etc/samba/smb.conf-$(date +%F)
bash$ sudo echo "[global]\n\tworkgroup = FAUAD\n" | tee /etc/samba/smb.conf
[global]
workgroup = FAUAD

Mit diesen Einstellungen können Kennungen bei Benutzung von SAMBA jetzt gegen die korrekte Domain authentifiziert werden.

Verfügbare Drucker finden

Das RRZE betreibt zur Lastverteilung mehrere Druckserver:

• fauprint.rrze.uni-erlangen.de
• fauprint2.rrze.uni-erlangen.de
• wisoprint.wiso.uni-erlangen.de
• wisoprint2.wiso.uni-erlangen.de

Um eine Liste der verfügbaren Drucker zu erhalten, können Sie eine entsprechende Abfrage an den FAUPRINT Druckdienst absetzen.

# mit Kerberos
bash$ kinit
...
bash$ smbclient -L fauprint.rrze.uni-erlangen.de --use-kerberos=required -N
Domain=[FAUAD] OS=[Windows Server 2012 R2 Standard 9600] Server=[Windows Server 2012 R2 Standard 6.3]
Sharename Type Comment
 --------- ---- -------
 ADMIN$ Disk Remote Admin
...

# ohne Kerberos
bash$ smbclient -L fauprint.rrze.uni-erlangen.de -U FAUAD/$USER
Enter FAUAD/$USER's password: 
Domain=[FAUAD] OS=[Windows Server 2012 R2 Standard 9600] Server=[Windows Server 2012 R2 Standard 6.3]
Sharename Type Comment
 --------- ---- -------
 ADMIN$ Disk Remote Admin
...

Suchen Sie in der Ausgabe nach Freigaben mit dem Typ Printer.
Diese können Sie dann im nächsten Schritt zur Bildung des Druckpfades verwenden.

Drucker hinzufügen

Informationen zur Einrichtung von CUPS Druckern inkl. einer Anleitung, um den richtigen Treiber zu finden, erhalten Sie unter CUPS Druckereinrichtung mit lpadmin

Im Folgenden sind einige Beispiele aufgeführt, um den Beispieldrucker aus oben genannter Dokumentation mit und ohne Kerberos-Authentifizierung einzurichten.
Der Unterschied besteht jeweils in der Einstellung für auth-info-required und dem verwendeten Backend Handler (jeweils fett hervorgehoben).

Beispiel 1

# mit Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-m foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd \
-o 'auth-info-required=negotiate' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "ksmb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035"

# ohne Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-m foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd \
-o 'auth-info-required=username,password' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035"

Beispiel 2

# mit Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rzpr-2035-lex-cs510de \
-m openprinting-ppds:0/ppd/openprinting/Lexmark/Lexmark_CS510_Series.ppd \
-o 'auth-info-required=negotiate' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "ksmb://fauprint2.rrze.uni-erlangen.de/rzpr-2035-lex-cs510de" \
-D "Lexmark CS510de" \
-L "RRZE, 2.035"



# ohne Kerberos
bash$ sudo /usr/sbin/lpadmin \
-p rzpr-2035-lex-cs510de \
-m openprinting-ppds:0/ppd/openprinting/Lexmark/Lexmark_CS510_Series.ppd \
-o 'auth-info-required=username,password' \
-o 'media=A4' \
-o 'sides=two-sided-long-edge' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint2.rrze.uni-erlangen.de/rzpr-2035-lex-cs510de" \
-D "Lexmark CS510de" \
-L "RRZE, 2.035"

Neben den verschiedenen grafischen Hilfsmitteln können CUPS Drucker auch vollständig über die Kommandozeile eingerichtet werden. Diese Art der Einrichtung lässt sich besser dokumentieren und nachstellen als die Nutzung der sich häufig ändernden grafischen Werkzeuge. Außerdem erleichtert dies auch die automatische Verteilung der Druckerkonfiguration über eine Konfigurationsverwaltung wie Saltstack oder Ähnliches.

Für betreute CIP-Pools oder Workstations können Druckerkonfigurationen nach Ihren Vorgaben auch automatisiert verteilt werden.
Kontaktieren Sie uns gerne für weitere Informationen.

Voraussetzungen

Pakete für Ubuntu 16.04/18.04

# one-liner 
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install cups-client

Verwendete Kommandos

lpadmin    https://www.cups.org/doc/man-lpadmin.html
lpinfo     https://www.cups.org/doc/man-lpinfo.html
lpoptions  https://www.cups.org/doc/man-lpoptions.html

Konfiguration

Beschreibung der Kommandos für verschiedene Einsatzszenarios.

Beispielhaft soll der Drucker Lexmark MX610de per FAUPRINT eingerichtet werden.

Generischen Druckertreiber finden/installieren

Um einen passenden Treiber im System zu finden kann man eine entsprechende Abfrage absetzen, wobei man den Hersteller und die Modellbezeichnung des Druckers als Suchparameter angibt.
Das Ergebnis ist eine Liste der passenden Treiber bestehend aus Pfad zur PPD-Datei und der Modellbezeichnung.
Da es sich bei unserem Beispiel-Modell um einen Lexmark MX610de handelt könnten wir den letzten Treiber aus der Liste wählen und den angegebenen PPD-Pfad in der weiteren Einrichtung verwenden.

bash$ lpinfo --make-and-model "Lexmark MX610" -m
foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610-Postscript.ppd Lexmark MX610 Foomatic/Postscript
openprinting-ppds:0/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
openprinting-ppds:1/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
openprinting-ppds:2/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
openprinting-ppds:3/ppd/openprinting/Lexmark/Lexmark_MX610_Series.ppd Lexmark MX610 Series
foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd Lexmark MX610de Foomatic/Postscript

Herstellerspezifischen Druckertreiber finden/installieren

Sollte kein passender Treiber verfügbar sein, oder der vorhandene Treiber nicht die nötige Funktionalität bieten, kann man oft auf den Webseiten des Druckerherstellers auch für das jeweilige Modell spezifische Linux-Treiber herunterladen.
Dabei ist es oft nicht wichtig genau die richtige Software für eine bestimmte Distribution zu wählen. Es muss normalerweise sogar gar keine Software installiert werden.
Entscheidend ist irgendwie an die PPD-Datei zu kommen!

Für den Lexmark MX610de findet sich z. B. auch ein passender Treiber auf der Lexmark Homepage, den man nach dem extrahieren aus dem heruntergeladenen Archiv im System installieren und verwenden kann. Nach erfolgreicher Installation liefert die Abfrage liefert unter den schon bekannten Optionen auch den neu installierten Treiber.
Diesen verwenden wir nun in der weiteren Einrichtung des Druckers.

bash$ sudo cp /tmp/Lexmark_MX610_Series.ppd /usr/share/cups/model/
bash$ sudo chmod 644 /usr/share/cups/model/Lexmark_MX610_Series.ppd
bash$ lpinfo --make-and-model "Lexmark MX610" -m
...
Lexmark_MX610_Series.ppd Lexmark MX610 Series
...

Fehlende Druckerfilter installieren

Manchmal benötigen die Druckertreiber des Herstellers noch zusätzlich Filter zur Verarbeitung der Druckaufträge. Hinweise auf fehlende Filter geben häufig die Logdatei unter /var/log/cups/error_log oder auch die Statusanzeige des Druckers in den entsprechenden grafischen Benutzeroberflächen.

In diesem Fall war der fehlende Filter ebenfalls im heruntergeladenen Archiv des Herstellers enthalten und konnte nach dem Entpacken wie folgt nachinstalliert werden.

# Check the logfile for recent filter errors
bash$ sudo tail -n50 /var/log/cups/error_log | grep -i filter
E [03/May/2018:14:30:59 +0200] rrze-lexmark-mx610de: Datei \"/usr/lib/cups/filter/fax-pnh-filter\" nicht verfügbar: No such file or directory
E [03/May/2018:14:30:59 +0200] rrze-lexmark-mx610de: Datei \"/usr/lib/cups/filter/CommandFileFilterG2\" nicht verfügbar: No such file or directory
E [03/May/2018:14:31:56 +0200] rrze-lexmark-mx610de: Datei \"/usr/lib/cups/filter/CommandFileFilterG2\" nicht verfügbar: No such file or directory

# Install previously extracted filters
bash$ sudo cp /tmp/CommandFileFilterG2 /usr/lib/cups/filter/
bash$ sudo chmod 755 /usr/lib/cups/filter/CommandFileFilterG2

bash$ sudo cp /tmp/fax-pnh-filter /usr/lib/cups/filter/
bash$ sudo chmod 755 /usr/lib/cups/filter/fax-pnh-filter2

Der Drucker sollte jetzt funktionieren.

Drucker hinzufügen

Nach Auswahl des entsprechenden PPD-Pfades kann der Drucker nun im System angelegt werden.
Dabei können auch diverse Standardeinstellungen gleich mit angegeben werden.

Beispiel mit generischem Foomatic Treiber:

bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-o 'printer-is-shared=false' \
-o 'auth-info-required=none' \
-o 'media=A4' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035" \
-m foomatic-db-compressed-ppds:0/ppd/foomatic-ppd/Lexmark-MX610de-Postscript.ppd

Beispiel mit Treiber vom Hersteller:

bash$ sudo /usr/sbin/lpadmin \
-p rrze-lexmark-mx610de \
-o 'printer-is-shared=false' \
-o 'auth-info-required=none' \
-o 'media=A4' \
-o 'Two-Sided Printing=DuplexNoTumble' \
-E \
-v "smb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de" \
-D "Lexmark MX610de" \
-L "RRZE, R2.035" \
-m Lexmark_MX610_Series.ppd

Tests

Prüfen der Einstellungen

Anzeige der Einstellungen in einer Zeile:

bash$ lpoptions -p rrze-lexmark-mx610de
auth-info-required=negotiate copies=1 device-uri=ksmb://fauprint.rrze.uni-erlangen.de/rzpr-2035-lex-ms610de finishings=3 job-cancel-after=10800 job-hold-until=no-hold job-priority=50 job-sheets=none,none marker-change-time=0 number-up=1 printer-commands=ReportLevels,AutoConfigure printer-info='Lexmark MX610de' printer-is-accepting-jobs=true printer-is-shared=false printer-location='RRZE, R2.035' printer-make-and-model='Lexmark MX610 Series' printer-state=3 printer-state-change-time=1525351551 printer-state-reasons=none printer-type=10522836 printer-uri-supported=ipp://localhost/printers/rrze-lexmark-mx610de

Alternativ geht es auch etwas ausführlicher bzw. mit Anzeige von spezifischeren Einstellungen des Druckers:

bash$ lpoptions -p rrze-lexmark-mx610de -l
PageSize/Media Size: Letter Legal 8.5x13.4028 B5 *A4 Executive A5 A6 FanFoldGermanLegal Statement EnvMonarch Env9 Env10 EnvDL EnvC5 ISOB5 OthEnv Custom.WIDTHxHEIGHT
InputSlot/Media Source: *Tray1 Tray2 Tray3 Tray4 MultipurposeFeeder ManualPaper ManualEnv
OptDuplex/Duplexer: False *True
OptFlash/Flash: *False True
OptTray2/Tray 2: *False True
OptTray3/Tray 3: *False True
OptTray4/Tray 4: *False True
OptMultipurposeFeeder/Multipurpose Feeder: False *True
OptStapler/Staple: *False True
PnH/Print and Hold: *False Verify Repeat Reserve Custom.PASSCODE
FaxNumber/Fax Number: *False Custom.STRING
Duplex/Duplex: None *DuplexNoTumble DuplexTumble
Collate/Collation: *True False
SepPages/Separator Pages: *PrinterS NoneF Jobs Copies Pages
SepSource/Separator Source: *PrinterS Tray1 Tray2 Tray3 Tray4 MultipurposeFeeder
OutputBin/Output Bin: *PrinterS StandardBin
StapleJob/Staple Job: *PrinterS FalseM TrueM
LXResolution/Resolution: 1200dpi 604x600dpi *602x600dpi 600dpi
Halftone/Halftone: *PrinterS FalseF TrueF
TonerDarkness/Toner Darkness: *PrinterS 1 2 3 4 5 6 7 8 9 10
LexPixelBoost/Pixel Boost: *PrinterS False Fonts Horizontally Vertically BothDirections
LexMirror/Mirror: True *False
ColorMode/Color Mode: *PrinterS TrueM
LexBrightness/Brightness: PrinterS -6 -5 -4 -3 -2 -1 *0 +1 +2 +3 +4 +5 +6
LexContrast/Contrast: PrinterS *0 1 2 3 4 5
GrayCorrection/Gray Correction: *PrinterS Manual FalseM
MediaType/Paper Type: *PrinterS Plain Colored Transparency Card Labels Bond Letterhead Preprint RoughEnvelope Envelope Recycled Light Heavy Rough Custom1 Custom2 Custom3 Custom4 Custom5 Custom6
LexBlankPage/Print Blank Pages: *PrinterS False True

Das RRZE betreibt eine redundante LDAP-Server Infrastruktur mit dem primären Zweck der Authentifizierung von Benutzern angebundener Linux-Systeme. Obwohl dies der Haupteinsatzzweck ist, können prinzipiell auch andere Systeme/Software die Benutzerbasis zur Authentifizierung nutzen.

Diese Anleitung beschreibt die Voraussetzungen zur Nutzung des LinuxLDAP und den grundlegenden Aufbau der Daten im Verzeichnisdienst, so dass eine eigenständige Konfiguration der jeweils anzubinden Systeme/Software möglich ist.

Vorbereitung

Bitte prüfen Sie die vorbereitenden Schritte bevor Sie versuchen einzelne Teile der Anleitung durchzuführen.
In der Regel müssen diese Voraussetzungen für ein sinnvolles Umsetzen der Anleitung erfüllt sein.

Prüfen der Voraussetzungen

Bevor Sie weiter vorgehen, sollten Sie prüfen ob eine Anbindung ihres Systems/Software überhaupt sinnvoll möglich ist bzw. ob Sie eine Maschinenkennung benötigen oder nicht.

Restriktionen

Der RRZE LinuxLDAP Server gewährt keinen Zugriff auf die Passwort-Hashes der Benutzer!
Das bedeutet, das eine Authentifizierung nur mittels LDAP-BIND als der jeweils zu authentifizierende Benutzer möglich ist.

Einige Anwendungen bieten nur die Möglichkeit eine Art Admin-Zugang zum LDAP Server zu konfigurieren, um dann auf diesem Wege das Passwort des Benutzers mit dem im LDAP abgelegten Passwort zu vergleichen. Zum Schutz der Daten unserer Benutzer können wir diese Art der Authentifizierung nicht unterstützen.

Benutzerkennung vs. Maschinenkennung

Nach erfolgreichem LDAP-BIND haben Sie lesenden Zugriff auf Ihren eigenen Benutzereintrag im LDAP (und einige Teilbäume mit frei verfügbaren Daten, die hier keine Rolle spielen).
Neben diversen linuxspezifischen Attributen enthält der Benutzereintrag ebenfalls eine Liste der Gruppenzugehörigkeiten des Benutzers.

Sofern es Ihre Anwendung erlaubt, könnten Sie so bereits eine Benutzerauthentifizierung und Rechtevergabe basierend auf den Gruppenattributen des Benutzers einrichten.

In der Regel benötigen die meisten Anwendungen nach dem Login via LDAP-BIND jedoch (leider) einen Benutzer, mit dem Sie nach dem Posix-Standard (RFC2307) die Gruppenzugehörigkeiten mittels einer Suche über alle verfügbaren Gruppen ermitteln können. Sollte das bei Ihnen ebenfalls der Fall sein, so benötigen Sie einer Maschinenkennung, welche diese Rechte besitzt (siehe nächster Absatz).

Maschinenkennung für LinuxLDAP erhalten

Zur Regulierung des Zugangs zum LinuxLDAP wird eine sog. Maschinenkennung verwendet.
Die Maschinenkennung enthält den FQDN der Maschine auf dem Ihre Dienste laufen sollen und kann für alle Dienste auf diesem Rechner zur Authentifizierung gegen den LinuxLDAP verwendete werden.

Verwenden Sie eine spezifische Maschinenkennung nicht auf anderen Systemen!

Um eine entsprechende Maschinenkennung zu erhalten bzw. selbst anlegen zu können benötigen Sie einen Zugang als IT-Betreuer zu unserer Rechnerverwaltung. Wie Sie diesen erhalten und eine Maschinenkennung mittels unseres Kommandozeilentools anlegen können ist unter Installation des rrzelinux CLI Tools beschrieben.

Sofern Sie nicht selbst IT-Betreuer an Ihrer Einrichtung sind können Sie sich den Zugang auch von einem IT-Betreuer Ihrer Einrichtung anlegen und die Zugangsdaten aushändigen lassen.

Empfohlene Software

Um sich einen Überblick über die Struktur und des Verzeichnisdienstes zu schaffen und ggf. zu konfigurierende Suchfilter testen zu können empfehlen wir die Installation des Apache Directory Studio (ApacheDS).

Der  Download kann von der offiziellen Homepage unter http://directory.apache.org/studio/ erfolgen.
Wir empfehlen den Einsatz der letzten 1.x Version (1.5.3 zum Stand 12.07.2017), welche bei den „Older Versions“ unter http://directory.apache.org/studio/download-old-versions.html zu finden ist.

Anbindung

Im Folgenden wird kurz der Aufbau des Verzeichnisdienstes beschrieben und danach einige Tipps zur Anbindung einiger Software-Produkte gegeben.

Aufbau des Verzeichnisdienstes

Aus Sicherheitsgründen erlaubt der LinuxLDAP ausschließlich den SSL gesicherten Zugriff in den Varianten LDAPS und STARTLS.

Alle relevanten Daten zur Benutzerauthentifizierung und -authorisierung finden sich in den Teilbäumen people und group.

Daraus ergeben sich die folgenden Eckdaten:

Benutzereinträge

Benutzereinträge befinden sich flach im Teilbaum people.
Jeder Benutzer hat nach einem BIND Zugriff auf die Daten seines eigenen Eintrags.

Die wichtigsten Attribute sind:

Anmerkungen zum Attribut fauUidType

Neben der Hauptkennung existieren auch diverse Sonderkennungen wie kp (Kontaktpersonen), wm (Webmaster), fu (Funktionskennungen), usw.
Diese sind „unpersönlich“ und können somit unter bestimmten Umständen an andere Personen weitergegeben werden.

Der Wert user markiert persönliche IdM-Hauptkennungen. Diese bleiben für Ihre gesamte Lebenszeit mit derselben Person verbunden und können nicht weitergegeben werden.

In der Regel empfiehlt sich daher praktisch immer eine Filterung auf (fauUidType=user) vorzunehmen, um nur einen Login mittels der IdM-Hauptkennung zuzulassen.

Gruppeneinträge

Gruppeneinträge befinden sich flach im Teilbaum group.

Die wichtigsten Attribute sind:

Tipps zur Anbindung

Hier finden Sie eine Sammlung gängiger Konfigurationsparameter.
Die Sammlung kann in Zukunft ggf. noch wachsen.

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