Podman Container als systemd-Dienste automatisch starten

Hat man eine Applikation in einen Container verpackt und kann diese erfolgreich mit podman laufen lassen, soll diese vermutlich auch bei einem Neustart des Hosts automatisch gestartet werden.

Podman liefert dazu die Werkzeuge, um die Systemd-Service-Units zu generieren.

In dem Beispiel betreibe ich einen Container mit dem Namen App1. Mit dem Kommando:

podman generate systemd --name App1 --files --new

[--name Es wird der Name des Containers verwendet und nicht die Container-ID

--files Die Ausgabe erfolgt in Dateien, statt auf STDOUT]

wird die Service-Unit-Datei im lokalen Verzeichnis erstellt:

container-App1.service

Es ist zwingend nötig die Datei in sein Homeverzeichnis unter .config/systemd/user/ zu kopieren:

cp conatiner-App 1.service ~USER/.config/systemd/user/

Bevor nun mit systemctl der Container gestartet wrid, muss sichergestellt sein, dass der ursprüngliche Container gestoppt ist.

podman stop App1

Auch das Container Image darf nicht mehr vorhanden sein:

podman rm App1

Ab jetzt kann der Container mit den systemd-Tools administriert werden:

systemctl --user daemon-reload

systemctl --user start container-App1

systemctl --user enable container-App1

Damit der Service nun auch gestartet werden kann, wenn der User nicht eingeloggt ist, muss noch folgendes Kommando ausgeführt werden:

loginctl enable-linger USERNAME

Der Dienst kann nun mit systemctl verwaltet werden und wird bei einem Rechnerneustart automatisch gestartet.

Der bind / named DNS Server

Anders als ich es oft höre, ist die Konfiguration von einem bind9 DNS Server wirklich nicht schwierig. Eine einfach Grundkonfiguration für das lokale Netzwerk ist schnell erstellt und ermöglicht die Namensauflösung lokaler Server/Clients im Netzwerk und auch die Namensauflösung im Internet.

Als erstes muss natürlich die Software installiert werden:

sudo dnf install bind bind-utils

Die Konfigurationsdateien befinden sich dann hier:

/etc/named.conf --> Hauptkonfiguration des named-Servers

/var/named --> Zonen und Reverse-Zonen Dateien

Bei anderen Linux-Distributionen die nicht von RedHat abgeleitet sind, können die Pfade unterschiedlich sein.

/etc/named.conf

options {

                listen-on port 53 { any; };

                listen-on-v6 port 53 { none; };

                directory "/var/named" ;

                forward first;

                forwarders {

                8.8.8.8;

                8.8.4.4;

                };

};

zone "beispiel.lokal" {

            type master;

            file "beispiel.zone";

};

zone "2.168.192.in-addr.arpa" {

            type master;

            file "beispiel.rzone";

};

Der Options-Block definiert auf welchen Port der DNS-Server lauschen soll und das Verzeichnis wo die Zonen-Dateien zu finden. Die Forwarder sind öffentliche DNS-Server, welche befragt werden sollen, wenn eine Adresse angefragt wird, die nicht aus den lokalen Netz stammt. Die IP-Adressen 8.8.8.8 und 8.8.4.4 stammen von den google-DNS Servern (primary und secondary).

Die Zone beispiel.lokal sagt dem DNS-Server, in welcher Datei er Informationen zur Namensauflösung findet. Dadurch das der Pfad /var/named/ schon im ersten Block definiert ist, reicht hier der Dateiname aus. Der DNS Server sucht die Datei dann unter /var/named/beispiel.zone.

Die Zone 2.168.192.in-addr.arpa definiert die Reverse-Lookup Datei für das Netz 192.168.2/24.

/var/named/beispiel.zone

$ttl 3600

beispiel.lokal. IN SOA ns.beispiel.lokal. admin.beispiel.lokal. (

1636891000

3600

600

1209600

3600 )

beispiel.lokal. IN NS desk.beispiel.lokal.

ovirt.beispiel.lokal. IN A 192.168.2.201

desk IN A 192.168.2.202

nfs.beispiel.lokal. IN CNAME desk.beispiel.lokal.

ovirt.beispiel.lokal IN A 192.168.2.201

desk.beispiel.lokal IN A 192.168.2.202

/var/named/beispiel.rzone

$ttl 3600

2.168.192.in-addr.arpa. IN SOA desk.beispiel.lokal. admin.beispiel.lokal. (

1637015958

3600

600

1209600

3600 )

2.168.192.in-addr.arpa. IN NS desk.beispiel.lokal.

202.2.168.192.in-addr.arpa. IN PTR desk.beispiel.lokal.

201.2.168.192.in-addr.arpa. IN PTR ovirt.beispiel.lokal.

SELinux Fehlersuche- und Behebung

SELinux Teil IV

Im letzten Teil der SELinux-Reihe will ich anhand von einem Beispiel demonstrieren, wie man SELinux-Probleme aufdeckt und behebt.

Eine Kunde hat einen neuen Webserver installiert, der auf Port 85 seinen Dienst zur Verfügung stellen soll. Aus irgendeinem Grund aber lässt sich der Apache-httpd-Server nicht starten.

Der httpd Server startet nicht

Als erstes prüfe ich, ob es ein SELinux Problem ist. Ich schalte SELinux in den permissive Modus und versuche erneut den Webserver zu starten:

SELinux permissive Mode / Webserverstart

Tatsächlich hat das Problem mit SELinux zu tun. Ich bringe SELinux wieder in den enforcing Modus und begebe mich an die Fehlersuche.

Ein Blick in die Logfiles ist sicherlich erstmal eine gute Idee:

journalctl -u httpd

grep httpd /var/log/audit/audit.log | more

ausearch -c 'httpd' --raw

und zum guten Schluss auch noch in /var/log/messages

grep httpd /var/log/messages | less

Nov 10 13:42:10 rocky setroubleshoot[10596]: SELinux is preventing /usr/sbin/httpd from name_bind access on the tcp_socket port 85.#012#012*****  Plugin bind_ports (99.5 confidence) suggests   ************************#012#012If you want to allow /usr/sbin/httpd to bind to network port 85#012Then you need to modify the port type.#012Do#012# semanage port -a -t PORT_TYPE -p tcp 85#012    where PORT_TYPE is one of the following: http_cache_port_t, http_port_t, jboss_management_port_t, jboss_messaging_port_t, ntop_port_t, puppet_port_t.#012#012*****  Plugin catchall (1.49 confidence) suggests   **************************#012#012If you believe that httpd should be allowed name_bind access on the port 85 tcp_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'httpd' --raw | audit2allow -M my-httpd#012# semodule -X 300 -i my-httpd.pp#012

Hier haben wir nicht nur den Fehler gefunden, sondern bekommen auch noch eine Lösung vorgeschlagen, welche ich auch gleich mal ausprobiere:

ausearch -c 'httpd' --raw | audit2allow -M my-httpd

Es wurden zwei Dateien erzeugt (my-httpd.pp, my-httpd.te) welche mit semodule in die SELinux Datenbank importiert werden.

Der Apache Webserver startet nun und SELinux ist aktiv.

SSH Passwortübergabe in Skripten

Grundsätzlich gilt: Es sollten niemals Passwörter im Klartext übergeben oder übers Netz geschickt werden. Wer SSH nutzt, sollte auf den passwortlosen Verbindungsaufbau mit öffentlichen und privaten Schlüsseln setzen. Manchmal muss man aber nur mal schnell was skripten, damit man einmalig irgendwelche Tasks auf anderen Hosts ausführen kann.

Für Trainings stelle ich oft Linux-Server in public-Clouds bereit, welche initial konfiguriert werden müssen, bevor ich mit Automatismen alle Einstellungen vornehme.

Beim Aufbau einer SSH-Verbindung ist es nicht möglich das Passwort an SSH zu streamen oder es direkt mitzugeben.

Dafür gibt es aber zum Glück ein Tools namens sshpass.

Die Syntax ist ganz einfach:

sshpass [ -p | -f | -e ] ssh user@beispiel.host

Parameter sind:

-p Das Passwort wird mit im Kommando übergeben

-f Das Passwort steht in einer Datei in der ersten Zeile

-e Das Passwort steht in der Environmentvariabel SSHPASS

Beispiele:

sshpass -p passwort ssh user@beispiel.host

--

echo "passwort" > secret.file

sshpass -f secret.file ssh user@beispiel.host

--

SSHPASS=passwort

sshpass -e ssh user@beispiel.host

Ändern des Tastaturlayouts

Vielleicht geht es auch genau wie mir. Ihr sitzt vor einem fremden Terminal, zum Beispiel beim Kunden, und das Tastaturlayout ist auf Englisch eingestellt. Mir passiert das häufig bei Kunden in den Niederlanden. Wie kann ich das Layout nun schnell und einfach ändern?

Bei den RedHat basierten Distributionen (RHEL, Centos, Rocky Linux und weitere) geht das zum Glück ganz einfach. Dazu gibt es das Kommando localectl.

Mit localectl status wird euch angezeigt, welches Layout aktiv ist.

[root@rocky html]# localectl status
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: de-nodeadkeys
      X11 Layout: de
     X11 Variant: nodeadkeys

localectl list-keymaps werden die verfügbaren Layouts gelistet

[root@rocky html]# localectl list-keymaps

ANSI-dvorak

al

al-plisi

amiga-de

amiga-us

applkey

at

at-mac

[...]

und setzen lässt sich das Layout mit localectl set-keymap

[root@rocky html]# localectl set-keymap de-nodeadkeys

[root@rocky html]# localectl status

   System Locale: LANG=de_DE.UTF-8

       VC Keymap: de-nodeadkeys

      X11 Layout: de

       X11 Model: pc105

     X11 Options: terminate:ctrl_alt_bksp

SELinux Booleschiche Werte

SELinux Teil III

Einige SELinux Regeln lassen sich ganz einfach aktivieren oder deaktivieren (0 oder 1 = boolesche Werte). Administratoren können damit sehr einfach Feinabstimmungen vornehmen.

In der Tabelle, aus dem SELinux Teil II Blog, habe ich die passenden Kommandos schon aufgeführt. Sie lauten getsebool, setsebool und semanage boolean.

Das Kommando getsebool -a liefert eine Liste, welche einfach aktiviert/deaktiviert werden können. In dem Beispiel suche ich mir alles raus, was mit httpd zu tun hat:

[root@rocky conf]# getsebool -a | grep httpd
httpd_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_connect_ftp --> off
httpd_can_connect_ldap --> off
httpd_can_connect_mythtv --> off
httpd_can_connect_zabbix --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_dbus_sssd --> off
httpd_dontaudit_search_dirs --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_graceful_shutdown --> off
httpd_manage_ipa --> off
httpd_mod_auth_ntlm_winbind --> off
httpd_mod_auth_pam --> off
httpd_read_user_content --> off
httpd_run_ipa --> off
httpd_run_preupgrade --> off
httpd_run_stickshift --> off
httpd_serve_cobbler_files --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_sys_script_anon_write --> off
httpd_tmp_exec --> off
httpd_tty_comm --> off
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_fusefs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
httpd_use_opencryptoki --> off
httpd_use_openstack --> off
httpd_use_sasl --> off
httpd_verify_dns --> off
[root@rocky conf]#

Die gezielte Abfrage zu einem gesetzten Boolean erfolgt einfach mit getsebool:

[root@rocky conf]# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off

Etwas genauer mit einer kurzen Beschreibung geht es mit semanage boolen:

[root@rocky conf]# semanage boolean -l | grep httpd_enable_homedirs

httpd_enable_homedirs          (aus  ,  aus)  Allow httpd to enable homedirs

Genauso einfach ist es einen Wert zu ändern:

[root@rocky conf]# setsebool httpd_enable_homedirs on

[root@rocky conf]#

[root@rocky conf]# getsebool httpd_enable_homedirs

httpd_enable_homedirs --> on

Mit der Option -P, also setsebool -P httpd_enable_homedirs on, würde der Wert in der SELinux Datenbank mit übernommen werden und stünde auch nach einem Reboot wieder bereit.

Mit der oben gezeigten Beispielregel httpd_enable_homedirs wird es einem Webserver erlaubt, Webinhalte aus den USERHOME -Verzeichnissen zu präsentieren.

SELinux Dateikontext

SELinux Teil II

SELinux Kontext

Ordner und Dateien tragen einen SELinux-Label der wie folgt aufgebaut ist:

SELinux_User : Rolle : Type : Level File

Beispiel:

Wir betrachten einmal den Apache-Webserver, welcher mit dem Kontext httpd_t läuft:

ps axZ | grep httpd

system_u:system_r:httpd_t:s0  115777 ? Ss 0:00 /usr/sbin/httpd -DFORGROUND

Dazu werfen wir noch einen Blick das Verzeichnis /var/www/html an:

ls -dZ /var/www/html

system_u:object_r:httpd_sys_content_t:s0   /var/www/html

Wir stellen fest, dass der Apache-Webserver mit dem Kontext httpd_t läuft und das Verzeichnis /var/www/html den Dateikontext httpd_sys_content_t besitzt.

Wenn SELinux aktiv ist, existiert eine Regel, die besagt, dass der httpd-Prozess mit dem Kontext http_t auf das Verzeichnis /var/www/html mit dem Dateikontext httpd_sys_content_t Zugriff hat. Der Webserver darf aber nicht auf das Verzeichnis (Beispiel) /tmp oder /var/tmp mit dem Dateikontext tmp_t zugreifen.

Ein böswilliger Angreifer, der nun irgendwie den httpd-Prozess kompromittiert und damit zumindest die Rechte des Users apache und der Gruppe apache erhält, ist in seinem tun und handeln dennoch stark eingeschränkt. SELinux sei Dank.

Anpassen der SELinux Kontexte

Unser Apache-Webserver soll nun nicht mehr seinen Inhalt unter /var/www/html finden, sondern ganz einfach unter /wwwinhalt. Die Konfigdatei für den Apache wird dementsprechend angepasst und das Verzeichnis angelegt:

mkdir /wwwinhalt

Wir stellen fest, dass der Webserver zwar startet aber beim Versuch die Webseite abzurufen, kommt es zu einem Fehler.

curl http://localhost --> Access denied

Wir schauen uns das Verzeichnis /wwwinhalt nochmal genau an

ls -dZ /wwwinhalt

unconfined_u:object_r:default_t:s0 /wwwinhalt/

und stellen fest, dass der Typkontext (default_t) nicht zum Webserver passt. Der Typkontext muss geändert werden.

Dazu wird zuerst ein Eintrag in der SELinux-Datenbank erzeugt (semange fcontext) und dann dieser Eintrag auf dem Verzeichnis /wwwinhalt angewendet (restorecon):

semange fcontext Befehle:

Option	Beschreibung
-a , --add	Einen Datensatz hinzufügen
-l, --list	Datensatz anzeigen
-d, --delete	Einen Datensatz löschen

Die Schreibweise '/wwwinhalt(/.*)?' ist leider sehr gewöhnungsbedürftig und ich habe keine Idee, warum man das nicht mit konventioneller Schreibweise gelöst hat. 

Jetzt wo der Kontext-Typ auf dem Verzeichnis /wwwinhalt auf http_sys_content_t gesetzt ist, darf der Webserver die Dateien lesen und im Web präsentieren.

Das Problem hätte man mit dem Kommando chcon (change context) temporär lösen können. Damit hätte man aber keinen Eintrag in der SELinux-Datenbank erzeugt. Nach einem Reboot wäre das Verzeichnis also wieder mit dem Inhalt dieser Datenbank gelabelt worden und der Webserver hätte seine Berechtigung wieder verloren. 

Kommando	Beschreibung
SELinux Modi verwalten
getenforce	Liefert den Betriebsmodus von SELinux zurück
sestatus	Wie getenforce mit weiteren Informationen
setenforce	Setzt den SELinux-Modus temporär
Kontext Verwalten
chcon	Ändert den Dateikontext
restorecon	Ändert den Dateikontext mit den Informationen aus dem /etc/selinux/targeted/contexts/files Verzeichnis
semange	Ändert den Dateikontext (mit fcontext)
Verwalten der SELinux Policies
seinfo	Informationen über SE-Policy Komponenten
semanage	Verwalten der Policy-Datenbank
sesearch	Sucht nach Regeln in der SELinux-Datenbank
Boolean Verwaltung
getsebool	Zeigt Booleans an
setsebool	Setzt Booleans
semange	Ändert Booleans in der Policy Datenbank
Fehlersuche
sealert	Suchtool für Fehler

Weiter geht es mit SELinux im Teil III

SELinux Modi

SELinux Teil I

Security Enhanced Linux (SELinux) ist eine weitere Schicht in der Systemsicherheit und erweitert die Sicherheitsmechanismen in RHEL basierten Linux Systemen. 

SELinux beantwortet in erster Linie die Frage:

Kann ein SUBJEKT etwas AUSFÜHREN auf diesem OBJEKT (engl.: May subject do action to object?)?

Beispiel: Darf der Webserver auf direkt auf die Datenbank zugreifen oder hat der Prozess der Datenbank Zugriff auf das Verzeichnis des Webservers? Nein. Der Webserver darf nur Dateien aus dem Verzeichnis /var/www/html lesen, während die Datenbank nur auf /data/mysql Zugriff bekommt. Sollte es einem Angreifer gelingen Prozessowner vom Webserver oder der Datenbank zu werden, so sind seine Zugriffsrechte dennoch stark eingeschränkt, auch wenn die Elementare Rechtevergabe des Linux-Systems (Datei-/Ordner-Berechtigungen) den Zugriff zulassen würde.

Quelle: Redhat.com

SELinux kennt drei Modi:

1. Enforcing ist der Defaultmodus und überwacht das ganze System
2. Der Permissive-Modus arbeitet wie der Enforcing-Modus, verbietet aber keine Zugriffe. Dieser Modus wird für Debugging-Aufgaben genutzt und ist nicht für Produktivsysteme geeignet.
3. Ausgeschaltet (DISABLED). SELinux macht gar nichts.

Einstellen des SELinux-Modus permanent (bleibt auch nach einem Reboot gesetzt)

In der Konfigdatei /etc/selinux/config

Änderungen in dieser Konfigdatei sind nach dem nächsten Reboot des Systems aktiv.

Den aktuellen Status von SELinux prüft man mit den beiden Kommandos

sestatus oder

getenforce

Beide liefern die gewünschte Information zurück, jedoch ist sestatus dabei etwas detaillierter:

SELinux Modus während des Bootvorgangs einstellen

Während des Bootvorgangs können im Bootmenü Kernelparameter übergeben werden, welche die SELinux Modi beeinflussen:

enforcing=0 --> Startet das System im Permissiv-Modus

 
selinux=0 --> Veranlasst den Kernel keine SELinux-Komponenten zu laden

 
autorelabel=1 --> SELinux wird das ganze System (Ordner, Dateien, Ports ..) durchlaufen und mit den SELinux-Content aus der SELinux Datenbank relabeln. 

Das "relabeln" hat folgenden Hintergrund. SELinux merkt natürlich, wenn ein Linux-System nicht in einem anderen Modus gebootet worden ist, als es eigentlich vorgesehen war. Hat man den Bootvorgang zum Beispiel durch ein rd.break als Bootparameter unterbrochen und das root-Passwort neu gesetzt, so wird SELinux davon in Kenntnis gesetzt.

 
Das kann aber auch bedeuten, dass ein Angreifer sich Zugriff auf das System ermöglicht und Dateien manipuliert hat, indem er SELinux Berechtigungen auf den Daten ändert.

Für jeden Ordner, jede Datei hält SELinux einen Eintrag in einer Datenbank vor, woraus hervorgeht wie die SELinux-Rechte auszusehen haben. Beim relabeln werden diese Rechte auf allen Ordnern und Dateien wieder gesetzt, sodass sämtliche manuellen Änderungen unwirksam werden.

ACHTUNG: Wenn man selbst SELinux-Rechte auf Dateien ändert, kann es passieren, dass diese Rechte wieder zurück gesetzt werden, wenn ein relabel durchgeführt wird!!! Daher müssen Änderungen auch in der SELinux-DB bekannt gemacht werden.

Weiter geht es im SELinux Teil II

          

Autofs

Es gibt gute Gründe, warum man sich autofs ansehen sollte. Das einfachste Beispiel sind Benutzer-Verzeichnisse (z.B. /home). Normalerweise hat jeder Server seine eigenes Home-Verzeichnis und jeder Benutzer hat dort Platz um Dateien abzulegen. Wenn sich ein Benutzer aber nun auf einem weiteren Server einloggt, stehen ihm diese Dateien nicht mehr zur Verfügung. Da macht es Sinn, dass man dem User eine NFS-Freigabe konfiguriert, welche auf jedem Server automatisch gemountet wird, sobald sich der User einloggt und darauf zugreift. Der User hat somit seine Dateien überall zur Verfügung, egal wo er angemeldet ist.

Denkbar ist ein solches Szenario auch in einer skalierbaren Umgebung, wo ggf. Server dazu gestartet werden, wenn es zu einem Performance-Engpass kommt. Solche Lösungen werden gerne in public Clouds genutzt.

Natürlich wäre es möglich auch jedem Server die NFS-Freigabe statisch zu mounten (Stichwort fstab), jedoch würde das unnötige Systemressourcen kosten.

Die Einrichtung ist einfach. Zunächst muss man die notwendige Software installieren. Unter RHEL 8 funktioniert das so:

dnf install autofs

Im ersten Beispiel soll die NFS-Freigabe nfs-server:/share/firma-lw auf jedem weiteren Server unter /firma/share gemountet werden, sobald ein Benutzer darauf zugreift.

Es sind zwei Konfigdateien notwendig, bevor der Automounter loslegen kann:

1. Eine MASTER-Datei unter /etc/auto.master.d/ Die Datei kann einen beliebigen Namen haben, sie muss aber die Endung .autofs haben. In diesem Beispiel verwende ich den Namen firma.autofs:

#/etc/auto.master.d/firma.autofs

/firma /etc/auto.firma.autofs

Der Inhalt der Datei ist ganz einfach aufgebaut. Die erste Spalte enthält das Verzeichnis, wo der Automounter aktiv werden soll (/firma) und die zweite Spalte enthält einen Verweis auf die dazugehörige Datei mit den Mountanweisungen.

#/etc/auto.firma.autofs

share    -rw,sync    nfs-server:/share/firma-lw

Auch hier ist der Aufbau nicht kompliziert. Die erste Spalte bezeichnet den Bereitstellungspunkt (in den Manpages als Key bezeichnet), dann folgen die Mountoptionen beginnend mit einem "-" und in der dritten Spalte die Freigabe die angebunden werden soll.

Zusammengefasst bedeutet das:
Unter dem Verzeichnis /firma (aus /etc/auto.master.d/firma.autofs) wird automatisch ein Unterverzeichnis share (aus /etc/auto.firma.autofs) bereit gestellt, welches die Freigabe des NFS-Servers gemounted hat. Der Server bindet die Freigabe also unter /firma/share an. Dabei muss das Unterverzeichnis share nicht existieren. Der Automounter legt es selbst an.

Im letzten Schritt muss nun der Service gestartet werden:

systemctl enable --now autofs

Ein ls auf dem Verzeichnis /firma zeigt zunächst ein leeres Verzeichnis an. Wenn ich aber jetzt in das Verzeichnis /firma/share wechsel (cd /firma/share) hat der Automounter den Mount erfolgreich ausgeführt und ich sehe die freigegeben Daten.

Und jetzt etwas mehr Dynamic bitte

Eingeleitet habe ich diesen Artikel mit dem Beispiel der User-Home-Verzeichnisse. Generell kann ich natürlich das komplette Verzeichnis /home exportieren und von den Servern mounten lassen. Aber es geht noch etwas schlanker, denn es ist ja nicht notwendig, dass gleich alle User-Home-Verzeichnisse bereitgestellt werden.

Als Beispiel erstelle ich eine neue Automounter-Datei unter /etc/auto.master.d und nenne sie home.autofs mit folgendem Inhalt:

#/etc/auto.master.d/home.autofs

/export/home    /etc/home.automount

Die User-Verzeichnisse sollen also unter /export/home angebunden werden, Informationen dazu werden aus der Datei /etc/home.automount entnommen, deren Inhalt so aussieht:

#/etc/home.automount

*     -rw,sync     NFS-Server:/home/&

Achtet auf das "&" am Ende der Zeile. das "&" steht hier für einen Platzhalter des jeweiligen User-Verzeichnisses.

Den Service neu starten:

systemctl restart autofs

Sehen wie es funktioniert:

Zuerst sehen wir, dass der Automounter /etc/home.automount aktiv hat. Der Benutzer User1 hat als Home-Verzeichnis /export/home/user1 konfiguriert (passwd). Nachdem sich der Benutzer User1 eingeloggt hat, sehen wir das gemountete Verzeichnis /export/home/user1. 

Wenn sich der User wieder abgemeldet hat, verschwindet nach einer Zeit der Mount wieder.