AutoFS

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 14.04/16.04/18.04

bash$ sudo apt-get install autofs

Aufbau

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

/home.local/* Anlage lokaler Homes, manuelle Verwaltung

Hier können je nach Bedarf Home-Verzeichnisse auf dem Server selbst z.B. für lokale Kennungen angelegt werden.

/home/* Verwaltung durch AutoFS zum Mount von externen Homes

Hier können verschiedene Mount-Points für Nutzer-Homes zur Verfügung gestellt werden, um es beispielsweise den Nutzern zu ermöglichen auf verschiedene Home-Filer (z.B. RRZE-Home und Lehrstuhl-Home) zuzugreifen.

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

Für das Linux Home unter rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome werden zukünftig nur noch krb5p Verbindungen unterstützt! Bitte passen Sie Ihre Konfiguration ggf. entsprechend an.

  • 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

Das Namensschema sieht vor Ihre Homes unter Ihrem offiziellen Präfix – auch Mail/AD-Präfix genannt – zur Verfügung zu stellen, um Namenskollisionen zu vermeiden

# Home mounts

# Archiv
archiv -wsize=32768,rsize=32768 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

# 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 14.04 / Upstart

bash$ sudo service autofs restart

Ubuntu 16.04/18.04 / 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.

Es wird nicht die aktive Konfiguration angezeigt, sondern zum Zeitpunkt des Aufrufes aus den Konfigurationsdateien direkt erzeugt

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 | -wsize=32768,rsize=32768 faunfs.rrze.uni-erlangen.de:/samfs_shome/campus
  archive | -wsize=32768,rsize=32768 alexandria.rrze.uni-erlangen.de:/archiv/archiv
  studhome | -wsize=32768,rsize=32768 faunfs.rrze.uni-erlangen.de:/samfs_shome/campus
  rzleg | -fstype=nfs4,minorversion=1,sec=sys rrzenfs4.rrze.uni-erlangen.de:/export/linuxhome.sys
  rrze | -wsize=32768,rsize=32768 faunfs.rrze.uni-erlangen.de:/samfs_mhome/rrze
  archiv | -wsize=32768,rsize=32768 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/&

...

 

NFSv4 Server

Beschreibt die Einrichtung eines NFSv4 Fileservers unter Ubuntu.

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

Pakete für Ubuntu 14.04/16.04/18.04

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.

Im Gegensatz zu NFSv3 verwendet NFSv4 immer ein pseudo-root! Verwendet man die falschen Pfade auf den Clients kann unter Umständen ein automatisches Fallback auf NFSv3 passieren.

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

Das RRZE empfiehlt nur mittels krb5p verschlüsselte Verbindungen zu verwenden.

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

Beachten Sie die Referenzierung des Mountpunkts relativ zum Pseudo-root des Servers ohne vorangestelltes „/export“!

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


 

Docker

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

Voraussetzungen

Pakete für Ubuntu 18.04

# one-liner 
bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install docker-ce

Konfiguration

Bitte den verwendeten Adressbereich unbedingt wie unten beschrieben konfigurieren.
Es gibt Netze an der FAU, die mit dem Default-Adressbereich kollidieren!

Docker Bridge

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.

Um den Netzbereich anzupassen sind die folgenden Schritte notwendig.

Ubuntu 14.04 (Upstart)

/etc/default/docker:

...
DOCKER_OPTS="--bip=169.254.254.1/24"
...
bash # service docker restart

Ubuntu 16.04 (Systemd)

1. Docker-Daemon Konfiguration anpassen

bash$ sudo systemctl edit docker

2. Folgenden Inhalt einfügen

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

Fortsetzung ab Punkt 3 für Ubuntu 18.04

Ubuntu 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 🙂

Startskripte

Docker-Container mit dem Linux Initsystem starten

Ubuntu 16.04/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

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 folgende Methode fügt eine Benutzerkennung bei der Anmeldung dynamisch zur benötigten lokalen docker Gruppe hinzu und funktioniert deshalb auch mit LDAP-basierten Kennungen und der lokalen docker Gruppe (siehe auch https://help.ubuntu.com/community/LDAPClientAuthentication#Assign_local_groups_to_users).
Sollten Sie einer lokale Kennung verwenden, kann diese natürlich auch direkt der lokalen docker Gruppe hinzugefügt werden.

Sie müssen sich Abmelden und neu Anmelden, damit diese Änderung aktiv wird!

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

 

Installation des rrzelinux CLI Tools

Diese Anleitung beschreibt die Installation des rrzelinux Kommandozeileninterfaces (CLI) für Administratoren nicht vom RRZE verwalteter Rechner.

Das rrzelinux CLI Tool ermöglicht Ihnen beliebige Rechner unterhalb Ihrer DNS Domain in Eigenverantwortung an die RRZE-Infrastruktur (z.B. LDAP/Kerberos) anzubinden. Diese Option ist besonders interessant, falls Sie keine Fremdadministration durch das RRZE wünschen, oder ein nicht vom RRZE unterstütztes System betreiben, das dennoch die Infrastruktur des RRZE nutzen soll.

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 Anleitung erfüllt sein.

FAU-CA Zertifikat

Das FAU-CA Zertifikat muss installiert sein (siehe FAU-CA Zertifikat einbinden).

Linux Admin Zugang

Um das rrzelinux CLI Tool zur Verwaltung von Rechnern innerhalb Ihrer DNS-Domain nutzen zu können, benötigen Sie eine entsprechende Berechtigung als IT-Betreuer (für Ihre Org.-Einheit).

Für den Login verwenden Sie – nach entsprechender Freischaltung – bitte Ihre IdM-Hauptkennung und Passwort.

Sollten Sie Beratung zum Linux Adminzugang oder dem rrzelinux Tool benötigen, wenden Sie sich gerne an rrze-linux@fau.de, um einen Termin zu vereinbaren.

Die Beantragung muss vom Leiter der Organisationseinheit erfolgen, für welche Sie als IT-Betreuer eingetragen werden möchten (z.B. per Mail an rrze-linux@fau.de).
Bitte achten Sie darauf, dass folgende Informationen enthalten sind:

  • Die IdM-Kennung des Nutzers, der als IT-Betreuer eingetragen werden soll
  • Die FAU.org Nummer der Organisationseinheit für die o.g. Kennung  als IT-Betreuer eingetragen werden soll
  • Eine Liste der freizuschaltenden DNS-Subdomains, welche Sie für Ihre Rechner verwenden möchten
    (kann auch später erweitert oder nachgereicht werden)

Präfixe

Die verwendete Rechtestruktur ordnet jedem Rechner ein Präfix zu, dass bei allen Aktionen mit angegeben werden muss.
Ein oder mehrere Präfixe werden wiederum einer Organisationseinheit der FAU zugeordnet.

Es handelt sich dabei, um dieselben Präfixe, die auch zur Bildung von Mailadressen, Systemgruppen und im Active Directory der FAU (FAUAD) zum Einsatz kommen.
Weitere Informationen zum Einsatz und zur Beantragung von Präfixen finden Sie unter https://www.rrze.fau.de/internet-e-mail/e-mail/funktionsadressen/nicht-personenbezogene-e-mail-adressen/.

Sollten Sie noch kein Präfix besitzen, dass zur Verwaltung Ihrer Rechner verwendet werden kann, so müssen Sie dieses ggf. noch beantragen.

Idealerweise beginnt auch der Rechnername mit dem ihm zugeordneten Präfix, gefolgt von einem ‚-‚ als Trenner.
Das ist aber (noch) keine harte Anforderung.

IT-Betreuer

Als IT-Betreuer (siehe https://www.rrze.fau.de/infocenter/rahmenbedingungen/it-beauftragte/) haben Sie Zugriff auf alle Rechner, die einem Präfix zugeordnet sind, das in Ihrem Betreuungsbereich liegt. Der Betreuungsbereich wird aus dem FAU.org Baum ermittelt und erstreckt sich von der betreuten Org.-Einheit hierarchisch nach unten.

rrzelinux

Wichtig

Bitte stellen Sie vor der Benutzung des rrzelinux Tools sicher, dass für Ihren Rechner der vollständige FQDN konfiguriert ist.

bash$ hostname -f
myhost.rrze.uni-erlangen.de  <-- korrekter FQDN

bash$ hostname -f
myhost <-- falsch, nur Kurzname

So können Sie den Hostnamen Ihres Rechners korrigieren:

bash$ echo "myhost.rrze.uni-erlangen.de" > /etc/hostname
bash$ hostname -F /etc/hostname

Installation

bash$ sudo wget -O - https://linux.rrze.fau.de/tools/rrzelinux/install | bash
bash$ rrzelinux -h
RRZE Linux management command line tool (1.0.4)

usage: rrzelinux prefix command fqdn|%.[%|domain] [options]

update: sudo rrzelinux update

description: command line utility to manage RRZE Linux host entries

parameters:
  prefix          the prefix to use
  command         see section 'commands' below
  fqdn            defaults to 'hostname -f' if none specified
  %.[%|domain]    select/filter for all hosts / all hosts in a specific domain
  options         see section 'options' below

commands:
  create          create host entry for LDAP access from a self-administered machine
  kerberize       create kerberos principals and download keytab for dns name
                  (use -k to specify principals, default: host,nfs)

  join            join host (create + kerberize)
  leave|remove    remove host (and kerberos principals)

  info            show host information
  list            list all hosts for the current/specified/all domain(s)
  keytab          download keytab only

  update          update this tool to the latest version (needs root)

options:
  -h              print this help
  -v              print version info
  -u username     username with administrative rights for RRZE linux
  -p password     password
  -k              specify service principals to generate (default: host,nfs)
  -n              do not download anything, just make the changes
  -c              no colors
  -d              be verbose/debugging
  -q              be quiet

 Update

bash$ sudo rrzelinux update

Update verfügbar:

rrzelinux: New version available: rrzelinux 1.0.4 6713327ed9063f9fa6f38d6f90375ece
Update to latest version now? (y/n) y
rrzelinux: Performing self-update...
Done.

Kein Update verfügbar:

rrzelinux: Already at the latest version (1.0.4).

Kurzanleitungen

Hier finden Sie Hilfestellungen für häufig benötigte Funktionen des rrzelinux Kommandozeilenwerkzeugs.

Hostinformationen abrufen

Sollten Sie das LDAP-Passwort Ihres Hosts vergessen haben, so können Sie wie folgt die Informationen erneut erhalten:

bash$ rrzelinux [PRÄFIX] info
Username: [Benutzer mit Rechten für das gewählte Präfix]
Password: *****

Mit Ausnahme des Hostnamens sollte die Ausgabe in etwa so aussehen:

rrzelinux: Host infos for test.rrze.uni-erlangen.de were gathered successfully (id=906)
key                value
=================  ====================================================================

hostname           test
domain             rrze.uni-erlangen.de

owner              rrze
description        Remotely created host entry (by rrze)
group              ZS-Server

config             UNMANAGED
ldap               LDAP

binddn             cn=test.rrze.uni-erlangen.de,ou=host,ou=profile,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
password           [Passwort]
krb realm          -
krb services       -

updated            2016-11-25 15:51:39.346
created            2016-11-25 15:51:39.14

Kerberos Join durchführen

Um per Kerberos authentifizierte Dienste Anbieten zu können muss Ihr System entsprechende Service-Principals vom LINUXKDC abrufen.
Hierfür müssen Sie Ihr System in der Rechnerverwaltung des Linux-Teams anlegen (create) und die Kerberos Funktionalität aktivieren (kerberize). Beides in einem Schritt erledigt der der join-Befehl.

bash$ rrzelinux [PRÄFIX] join
Username: [Benutzer mit Rechten für das gewählte Präfix]
Password: *****
rrzelinux: Host test.rrze.uni-erlangen.de was joined successfully (id=905)
rrzelinux: Saved keytab to: /tmp/krb5.keytab
rrzelinux: LDAP password is: [Passwort]

Die erzeugte Keytab muss abschließend noch an den richtigen Platz verschoben werden.

bash$ sudo mv -bv /tmp/krb5.keytab /etc/krb5.keytab
bash$ sudo chown root:root /etc/krb5.keytab

Das LDAP Passwort kann für eine Anbindung an den zentralen LDAP Server des RRZE verwendet werden, wird aber für Kerberos zunächst nicht benötigt.
Mehr Informationen zur LDAP Anbindung erhalten Sie auf der Seite zur SSSD Konfiguration.

Kerberos Konfiguration nachträglich hinzufügen

Existiert der entsprechende Host bereits (angelegt z. B. durch create) und soll jetzt für Kerberos konfiguriert werden kann dies wie folgt auch nachträglich geschehen.

bash$ rrzelinux [PRÄFIX] kerberize 
Username: [Benutzer mit Rechten für das gewählte Präfix] 
Password: *****

Kerberos Keytab erneut abrufen

Sollten Sie Ihre Keytab gelöscht haben, so können Sie diese wie folgt erneut erhalten.

Bitte beachten Sie, das der Host zum erneuten abrufen der Keytab bereits durch ein erfolgreiches join oder create/kerberize Kommando entsprechend für Kerberos konfiguriert sein muss.

bash$ rrzelinux [PRÄFIX] keytab
Username: [Benutzer mit Rechten für das gewählte Präfix] 
Password: *****
rrzelinux: Got keytab(s) of 1 entries for test.rrze.uni-erlangen.de
rrzelinux: 
rrzelinux: Kerberos keytab information
rrzelinux: ---------------------------
rrzelinux: Saved keytab to temporary location: /tmp/rrzelinux_krb5_keytab.AlD2sns1b
rrzelinux: Install in system with:
rrzelinux:     sudo mv -bv /tmp/rrzelinux_krb5_keytab.AlD2sns1b /etc/krb5.keytab && sudo chown root:root /etc/krb5.keytab

SSSD Konfiguration

Das RRZE verwendet den System Security Services Daemon (SSSD) zur Benutzerauthentifizierung für alle Ubuntu Systeme.

Diese Anleitung beschreibt das Anlegen des Hosteintrags zum Zugriff auf die RRZE LDAP-Server für einen selbstverwalteten Rechner und die Installation und Konfiguration des SSSD zur Benutzerauthentifizierung 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 Anleitung der erfüllt sein.

FAU-CA Zertifikat einbinden

Die LDAP-Server des RRZE erlauben nur SSL verschlüsselten Zugriff via LDAPS (636) oder STARTTLS (389). Damit der Zugriff funktioniert müssen Sie das Zertifikat der Zertifizierungsstelle der FAU (FAU-CA) einbinden.

Folgen Sie dafür den unter FAU-CA Zertifikat einbinden beschriebenen Schritte bevor Sie diese Anleitung fortsetzen.

rrzelinux CLI Tool

Falls Sie kein Betreuungsangebot des RRZE gebucht haben (Serverhousing oder -hosting) wird im Verlauf der Installation wird das rrzelinux CLI Tool benötigt, um den Host-Eintrag Ihres Systems zu erzeugen.
Bitte führen Sie in diesem Fall im Vorfeld die Installation wie unter Installation des rrzelinux CLI Tools beschrieben durch.

Pakete

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

bash$ sudo DEBIAN_FRONTEND=noninteractive apt-get install sssd sssd-tools libnss-sss libnss-ldap ldap-utils libpam-sss

Linux Hosteintrag erzeugen (entfällt für Housing/Hosting-Kunden)

Für den Zugriff auf die zentralen LDAP Server des RRZE muss ein rechnerspezifischer Host-Eintrag mit Passwort erzeugt werden.
Die Zugangsdaten dürfen nur auf dem damit verbundenen Rechner und nur zur Durchführung der Nutzerauthentifizierung verwendet werden!

Housing oder Hosting Kunden können diesen Schritt überspringen. Der Hosteintrag wird durch unsere Mitarbeiter angelegt und die Zugangsdaten an Sie übermittelt.

Benötigen  Sie Zugriff auf unseren LDAP Server zu anderen Zwecken, kontaktieren Sie uns bitte per Mail an rrze-linux@fau.de.
Wir werden Ihr Anliegen prüfen und ggf. für Ihren Einsatzzweck einen separaten Zugang einrichten.

Bei Missbrauch des Zugangs behalten wir uns vor diesen ohne Vorwarnung zu sperren.

Initiale Einrichtung

bash$ rrzelinux [PRÄFIX] create 
Username: [Benutzer mit "create"-Rechten] 
Password: *****

Mit Ausnahme des Hostnamens sollte die Ausgabe in etwa so aussehen:

rrzelinux: Host test.rrze.uni-erlangen.de was created successfully (id=906)
rrzelinux: LDAP bind DN is: cn=test.rrze.uni-erlangen.de,ou=host,ou=profile,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
rrzelinux: LDAP password is: [systemgeneriertes Passwort]

Der LDAP Bind-DN und Passwort kann für eine Anbindung an den zentralen LDAP Server des RRZE verwendet werden.

LDAP Passwort vergessen

Sollten Sie das LDAP-Passwort Ihres Hosts vergessen haben, so können Sie wie folgt die Informationen erneut erhalten:

bash$ rrzelinux [PRÄFIX] info
Username: [Benutzer mit "info"-Rechten]
Password: *****

Mit Ausnahme des Hostnamens sollte die Ausgabe in etwa so aussehen:

rrzelinux: Host infos for test.rrze.uni-erlangen.de were gathered successfully (id=906)
key                value
=================  ====================================================================

hostname           test
domain             rrze.uni-erlangen.de

owner              rrze
description        Remotely created host entry (by rrze)
group              ZS-Server

config             UNMANAGED
ldap               LDAP

binddn             cn=test.rrze.uni-erlangen.de,ou=host,ou=profile,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
password           [systemgeneriertes Passwort]
krb realm          -
krb services       -

updated            2016-11-25 15:51:39.346
created            2016-11-25 15:51:39.14

SSSD Konfiguration

Zur Konfiguration des SSSD gehen Sie wie folgt vor:

bash$ cd /etc/sssd
bash$ sudo cp sssd.conf sssd.conf_old
bash$ sudo vi sssd.conf

Der Inhalt der Datei /etc/sssd/sssd.conf könnte in etwa so aussehen (RRZE-Standard Konfiguration):

[sssd]
debug_level = 3

config_file_version = 2
services = nss,pam

domains = LINUXLDAP

[nss]
debug_level = 3
filter_users = root
filter_groups = root

[pam]
debug_level = 3
filter_users = root
filter_groups = root

[domain/LINUXLDAP]
debug_level = 3

# optional: use this to override the configured per-user home from the ldap
#override_homedir = /home.local/%u

# With this as false, a simple "getent passwd" for testing won't work. You must do getent passwd user@domain.com
enumerate = false
cache_credentials = true

# cache cleanup operation removes cached entries that were not used for a while - unneccessary
ldap_purge_cache_timeout = 0

# makes all groups appear as empty (getent group), thus downloading only information about the group objects themselves and not their members
# this drastically improves performance with large ldap groups!
ignore_group_members = True

id_provider = ldap
auth_provider = ldap

ldap_uri = ldap://linuxldap.rrze.uni-erlangen.de
ldap_search_base = ou=linux,dc=rrze,dc=uni-erlangen,dc=de
ldap_id_use_start_tls = true
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

# This parameter requires that the ldap server presents a completely validated certificate chain. If you're testing or don't care, use 'allow' or 'never'.
# you need to install and trust the FAU-CA certificate for this to work!
ldap_tls_reqcert = demand
#ldap_tls_reqcert = never

# Bind credentials
ldap_default_bind_dn = [siehe Ausgabe des rrzelinux CLI Tool]
ldap_default_authtok = [siehe Ausgabe des rrzelinux CLI Tool]

ldap_user_search_base = ou=people,ou=linux,dc=rrze,dc=uni-erlangen,dc=de
ldap_group_search_base = ou=group,ou=linux,dc=rrze,dc=uni-erlangen,dc=de

bash$ sudo chmod 700 sssd.conf

Die gegebenen Konfiguration stellt die Empfehlung des RRZE dar.
Sie können die Konfiguration jedoch – falls nötig –  an Ihren Anwendungsfall anpassen.
Weiteren Informationen zu den verschiedenen Optionen erhalten Sie auf der sssd.conf Manpage.

Achten Sie darauf die mit „[ ]“ gekennzeichneten Passagen durch die entsprechenden Daten aus dem rrzelinux Tool zu ersetzen.

Restart der Dienste

Damit die vorgenommene Konfiguration aktiv wird müssen die betroffenen Dienste neu gestartet werden.

Ubuntu 14.04

bash$ sudo service sssd restart

Ubuntu 16.04/18.04/20.04

bash$ sudo systemctl restart sssd.service

NSSWITCH Anpassen

Die Name Service Switch (NSS) Konfiguration bestimmt verschiedene Quellen zur Namensauflösung.
Um den SSSD zur Namensauflösung für die zur Authentifizierung benötigten Daten zu konfigurieren müssen einige Anpassungen vorgenommen werden:

bash$ cd /etc
bash$ sudo cp nsswitch.conf nsswitch.conf_old
bash$ sudo vi nsswitch.conf

Der Inhalt der /etc/nsswitch.conf sollte dann für die betreffenden Datenbanken so aussehen:

passwd: files sss
shadow: files sss
group: files sss
netgroup: sss

Test

Nachdem alle Schritte durchgeführt wurden kann die Konfiguration noch auf korrekte Funktion überprüft werden.

Benutzer- und Gruppenauflösung

Dieser Test stellt sicher, dass die LDAP-Anbindung funktioniert und Benutzer- und Gruppeninformationen abgerufen werden können.
Statt der beispielhaft verwendeten Kennung „yc14omec“ können Sie auch Ihre eigene Kennung verwenden.

bash$ id yc14omec
uid=52014(yc14omec) gid=100000(fau_user) Gruppen=100000(fau_user)

Der Test ist erfolgreich, wenn die Ausgabe das Mapping auf die uidNumber und die Gruppenmitgliedschaften korrekt anzeigt.

Performante Gruppenauflösung

Dieser Test überprüft beziehungsweise demonstriert den Effekt der Konfigurationsoption ignore_group_members = true. Bei Abruf einer Gruppe werden aus Performanzgründen standardmäßig keine Mitglieder geliefert.
Dieses Verhalten ist erwünscht, da es sonst aufgrund der hohen Anzahl an Gruppenmitgliedern bei manchen Gruppen zu erheblichen Verzögerungen beim Einloggen kommen kann.

bash$ getent group rrze_linux
fau_user:*:100000:

Der Test ist erfolgreich, wenn keine Mitglieder der Gruppe angezeigt werden.

 

Fehlerbehebung

Bei Problemen mit der Gruppenauflösung oder generell „seltsamen“ Verhalten des SSSD kann zur Behebung versucht werden den Cache zu löschen.

Die sanfte Variante (funktioniert manchmal):

bash$ sudo sss_cache -E

Die harte Variante (funktioniert meistens):

# Ubuntu 14.04/16.04
bash$ sudo su
bash$ service sssd stop && rm /var/lib/sss/db/* && service sssd start
bash$ exit

# Ubuntu 18.04/20.04
bash$ sudo su
bash$ systemctl stop sssd && rm /var/lib/sss/db/* && systemctl start sssd
bash$ exit

 

FAU-CA Zertifikat einbinden

Diese Anleitung beschreibt die Installation der FAU-CA Zertifikatskette in einem Ubuntu System, so dass das System in Zukunft allen Zertifikaten, die von der FAU-CA ausgestellt wurden vertraut.

Der DFN hat eine neue CA eingeführt, daher muss zusätzlich zur alten Chain auch noch die neue Chain importiert werden, um alle von der FAU ausgegebenen Zertifikate zu unterstützen!

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.

Pakete

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

bash$ sudo apt-get install openssl ssl-cert ca-certificates

Installation

Die Installation erfolgt durch Download der FAU-CA Zertifikatskette und anschließende Installation im Ubuntu System.

Ubuntu 14.04/16.04/18.04

bash$ sudo wget https://pki.pca.dfn.de/uni-erlangen-nuernberg-ca/pub/cacert/chain.txt -O /usr/local/share/ca-certificates/fauca-chain-old.crt

bash$ sudo wget https://pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt -O /usr/local/share/ca-certificates/fauca-chain.crt

bash$ sudo update-ca-certificates

Ubuntu 14.04/16.04/18.04 (über proxy)

bash$ sudo https_proxy=http://proxy.rrze.uni-erlangen.de wget https://pki.pca.dfn.de/uni-erlangen-nuernberg-ca/pub/cacert/chain.txt -O /usr/local/share/ca-certificates/fauca-chain-old.crt

bash$ sudo https_proxy=http://proxy.rrze.uni-erlangen.de wget https://pki.pca.dfn.de/dfn-ca-global-g2/pub/cacert/chain.txt -O /usr/local/share/ca-certificates/fauca-chain.crt 

bash$ sudo update-ca-certificates

Java Support

Java verwendet eigenen eigenen Truststore in dem vertrauenswürdige Zertifikate abgelegt werden.
Um Java Anwendungen auch von der Validität der FAU Zertifikate zu überzeugen können diese wie folgt auch dort eingebunden werden.

Ubuntu 14.04/16.04/18.04

Die folgenden Befehle importieren exemplarisch das alte und das neue FAU-CA Zertifikat in den OpenJDK 8 Truststore.
Der Pfad zum Truststore kann ggf. je nach verwendeter Java Version und Implementierung abweichen und muss ggf. angepasst werden.

Das Standard-Passwort für diesen Truststore ist tatsächlich „changeit“ und muss genauso eingegeben werden.

bash$ sudo keytool -importcert -noprompt -storepass changeit -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts -alias fauca-chain-old -file /usr/local/share/ca-certificates/fauca-chain-old.crt

bash$ sudo keytool -importcert -noprompt -storepass changeit -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts -alias fauca-chain -file /usr/local/share/ca-certificates/fauca-chain.crt

Test

Der Test prüft ob nach Aktualisierung der Liste der vertrauenswürdigen CA-Zertifikaten auch das FAU-CA Zertifikat enthalten ist.

System

bash$ grep FAU-CA /etc/ssl/certs/ca-certificates.crt
subject= /C=DE/ST=Bayern/L=Erlangen/O=Universitaet Erlangen-Nuernberg/OU=RRZE/CN=FAU-CA/emailAddress=ca@rrze.uni-erlangen.de

bash$ grep "DFN-Verein Certification Authority 2" /etc/ssl/certs/ca-certificates.crt
subject= /C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2

Der Test ist erfolgreich, wenn die jeweils angegebene Zeichenkette gefunden wird.

Java

bash$ keytool -v -list -storepass changeit -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts | grep "CN=DFN-Verein PCA Global - G01"

Aussteller: CN=DFN-Verein PCA Global - G01, OU=DFN-PKI, O=DFN-Verein, C=DE
bash$ keytool -v -list -storepass changeit -keystore /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts | grep "CN=DFN-Verein Certification Authority 2"

Aussteller: CN=DFN-Verein Certification Authority 2, OU=DFN-PKI, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., C=DE