NFS4 Export

[pixel]

systemctl restart rpc-svcgssd.service

ich versuche das auch gerade einzurichten. Beim dritten Befehl erhalte ich jedoch einen Fehler:

root@tux:~# systemctl restart rpc-svcgssd.service
Failed to restart rpc-svcgssd.service: Unit rpc-svcgssd.service is masked.

Was ist da verkehrt?

[pixel]

udm kerberos/kdcentry create \ --position “$BASE” \ --set name="$PRINCIPAL" \ --set generateRandomPassword=1

kadmin -l ext_keytab -k /etc/krb5.keytab “$PRINCIPAL”

sed -i -re ‘s/#?(NEED_SVCGSSD=).*/\1yes/’ \ /etc/univention/templates/files/etc/default/nfs-kernel-server ucr commit /etc/default/nfs-kernel-server service nfs-kernel-server restart

Sind diese Schritte im besagten Szenario (NFS4, Samba4, Kerberos) auch auszuführen?

[pixel]

udm kerberos/kdcentry create \ --position “$BASE” \ --set name="$PRINCIPAL" \ --set generateRandomPassword=1

kadmin -l ext_keytab -k /etc/krb5.keytab “$PRINCIPAL”

sed -i -re ‘s/#?(NEED_SVCGSSD=).*/\1yes/’ \ /etc/univention/templates/files/etc/default/nfs-kernel-server ucr commit /etc/default/nfs-kernel-server service nfs-kernel-server restart

Bis auf diese Schritte habe ich alles gemacht. Bekomme die o.g. Meldung beim Versuch den Service neu zu starten und beim Versuch am Client zu mounten:

root@pc001:~# mount -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: requested NFS version or transport protocol is not supported

echo ‘/home gss/krb5i(rw,sync,no_subtree_check)’ >>/etc/exports

Das krb5i scheint das Problem zu sein:

Dez 06 16:03:11 tux exportfs[26033]: exportfs: unknown flavor krbi
Dez 06 16:03:11 tux systemd[1]: nfs-server.service: Control process exited, code=exited status=1
Dez 06 16:03:11 tux systemd[1]: Failed to start NFS server and services.
-- Subject: Unit nfs-server.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit nfs-server.service has failed.

Für die einzelnen Freigaben kann man Kerberos bereits über die UMC aktivieren (Tab “Erweiterte Einstellungen” -> “Erweiterte NFS-Einstellungen” -> “sec=krbi” eintragen).

Der Fehler kam daher

[SirTux]

ich versuche das auch gerade einzurichten. Beim dritten Befehl erhalte ich jedoch einen Fehler:

root@tux:~# systemctl restart rpc-svcgssd.service
Failed to restart rpc-svcgssd.service: Unit rpc-svcgssd.service is masked.

Was ist da verkehrt?

Der Dienst wurde deaktiviert und muß daher erst aktiviert werden:

systemctl unmask rpc-svcgssd.service
systemctl enable rpc-svcgssd.service
systemctl start rpc-svcgssd.service

[pixel]

systemctl enable rpc-svcgssd.service

root@tux:/data# systemctl enable rpc-svcgssd.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

[SirTux]

systemctl enable rpc-svcgssd.service

Ok seems that isn’t required

[pixel]

Here is a summary of the steps I took:

++ Auf dem Server (Master) ++

+ Export-Root auf dem Server anlegen +

Datei /etc/exports

"/home" -rw,root_squash,sync,no_subtree_check,sec=krb5i


FQDN="$(hostname -f)"
DOMAIN="$(dnsdomainname)"
REALM="$(ucr get kerberos/realm)"
PRINCIPAL="nfs/${FQDN}@${REALM}"
BASE="cn=kerberos,$(ucr get ldap/base)"

udm kerberos/kdcentry create --position "$BASE" --set name="$PRINCIPAL" --set generateRandomPassword=1

/usr/share/univention-samba4/scripts/create_spn_account.sh --samaccountname "nfs-$HOSTNAME" --serviceprincipalname "nfs/$(hostname -f)" --privatekeytab nfs.keytab

ktutil copy /var/lib/samba/private/nfs.keytab /etc/krb5.keytab

systemctl try-reload-or-restart nfs-server.service

samba-tool spn add nfs/tux.gehr.lan/gerh.lan tux\$

/etc/univention/templates/files/etc/default/nfs-kernel-server

NEED_SVCGSSD=yes

ucr commit /etc/default/nfs-kernel-server



/etc/univention/templates/files/etc/default/nfs-common
NEED_STATD=no

ucr commit /etc/default/nfs-common


++ Auf dem Client ++

systemctl restart rpc-gssd.service
kinit Administrator

Wenn ich nun auf dem Client versuche das Home zu mounten erhalte ich lediglich:

root@pc001:~# showmount -e tux.gehr.lan
Export list for tux.gehr.lan:
/home *
root@pc001:~# mount -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: an incorrect mount option was specified

[SirTux]

udm kerberos/kdcentry create --position “$BASE” --set name="$PRINCIPAL" --set generateRandomPassword=1

Das ist Quatsch. Relevant wird es erst ab diesem Beitrag:

NFS4 Export

Ausser Dokumentation wird sich hier leider erst einmal wegen anderer Prioritäten nichts weiter tun. Für Samba4 muss man abweichend folgendes machen, weil Samba4 seine eigene Kerberos-Implementierung hat. Die basiert zwar auf Heimdal und die Heimdal-Tools tun auch alle so, als würden sie es richtig machen, aber wegen Detailunterschiede geht es dann eben doch nicht. AD ordnet die Kerberos-Prinzipale für einen Dienst jeweils einem eigenen Benutzerkonto zu - deswegen gibt es z.B. in einem Standar…

EDIT: Ich verstehe übrigens nicht, wieso es Univention immer noch nicht geschafft hat, das Join-Script 81univention-nfs-server.inst so anzupassen, daß da dieser läppische Service-Principal automatisch angelegt wird. Für DNS gehts doch auch …

[pixel]

Das ist Quatsch. Relevant wird es erst ab diesem Beitrag:

ok, habe ich entfernt. Das war ja mein Frage welche Schritte aus welchem Beitrag … Aber der Rest passt?

[pixel]

Wenn ich wieder die “alte” Syntax in der /etc/exportfs nutze, wie sie auch im oberen Teil genannt ist:

/home  gss/krb5i(rw,sync,no_subtree_check)

kommt beim mounten wieder:

mount.nfs4: access denied by server while mounting tux.gehr.lan:/home

[SirTux]

Also gut. Das paßt:

/usr/share/univention-samba4/scripts/create_spn_account.sh  --samaccountname "nfs-$HOSTNAME"  --serviceprincipalname "nfs/$(hostname -f)" --privatekeytab nfs-$hostname.keytab
ktutil copy /var/lib/samba/private/nfs.keytab /etc/krb5.keytab
systemctl unmask rpc-svcgssd.service
systemctl restart rpc-svcgssd.service

Danach über die UMC an der jeweiligen Freigabe die Option sec=krb5p setzen (“Erweiterte NFS-Einstellungen”). Am Client mußt du diesbezüglich nichts machen. Das ist nur notwendig, wenn mehrere Optionen zur Auswahl stehen (z.B. sec=krb5i:krb5p).

Aber dein Problem ist wahrscheinlich, daß der Client keine Keytab hat. Das macht der Join-Assistent leider nicht. Ich habe meinen Workarround hier irgendwo publiziert …

EDIT: Da ist es:

SPN-Account für NFS Server

Ich habe mir ein opsi-Paket dafür gebaut. Die erforderlichen Debian-Pakete habe ich mir von UCC geholt. Hier sind die relevanten Sektionen: [ShellInAnIcon_install_keytab_32] set -x apt install %SCRIPTPATH%/keytab/python-support_1.0.15.19.201606061039_all.deb -y apt install %SCRIPTPATH%/keytab/python-univention-heimdal_6.0.1-1.59.201606071248_i386.deb -y [ShellInAnIcon_install_keytab_64] set -x apt install %SCRIPTPATH%/keytab/python-support_1.0.15.19.201606061039_all.deb -y apt install %SCRIPTP…

[pixel]

Danach über die UMC an der jeweiligen Freigabe die Option sec=krb5p setzen (“Erweiterte NFS-Einstellungen”).

Also für das Home nochmal zusätzlich die Freigabe im UMC erstellen. Ich würde “sec=krb5i” nutzen.

Aber dein Problem ist wahrscheinlich, daß der Client keine Keytab hat. Das macht der Join-Assistent leider nicht. Ich habe meinen Workarround hier irgendwo publiziert …

Da ist von OPSI-Paket die Rede. Da kann ich nicht ganz folgen. Wie bekomme ich den Keytab per Hand auf den Client?

[pixel]

[SirTux]

Da ist von OPSI-Paket die Rede. Da kann ich nicht ganz folgen. Wie bekomme ich den Keytab per Hand auf den Client?

Indem du es von Hand ausführst. Die Abhängigkeiten habe ich vom UCC übernommen.

[pixel]

Mir ist leider nicht klar wie ich das tun soll

[pixel]

ich versuch’s mir mal zusammen zu reimen. Die Pakete:

python-univention-heimdal
python-support

sind ja auf dem Master installiert. Das:

hostname="$(hostname)"
kvno="$(ldapsearch -x -D "$binddn$" -w "$bindpwd$" "(&(objectClass=univentionHost)(cn=$hostname))" krb5KeyVersionNumber | sed -n 's/^krb5KeyVersionNumber: \(.*\)$/\1/p')"

schreibt ja die Versions-Nummer in die Variable “kvno”.
Das:

[ -e /etc/krb5.keytab ] && mv /etc/krb5.keytab "/etc/krb5.keytab.old_$(date +%F-%S%M%S)"

erstellt ein Backup. Kann ich diese Zeile einfach so am Master in die Shell schreiben?
Und dann rufe ich am Master:

/usr/lib/univention-heimdal/univention-create-keytab --keytab="/etc/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname$" --kvno=$kvno --password="$(cat /etc/machine.secret)"

auf um einen Dump des Keytab zu erstellen?

Und wohin wird dieser geschrieben bzw. was kopiere ich dann auch den Client?

Also ich habe am Master:

kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)

[ -e /etc/krb5.keytab ] && mv /etc/krb5.keytab "/etc/krb5.keytab.old_$(date +%F-%S%M%S)"

/usr/lib/univention-heimdal/univention-create-keytab --keytab="/etc/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname$" --kvno=$kvno --password="$(cat /etc/machine.secret)"

ausgeführt. Nun müsste ich “nur noch” wissen wie ich diesen Keytab auf den Client bekomme

[SirTux]

Kann sein, daß du die so auf dem DC Master erstellen kannst:

hostname="clienthostname"
domainname="x.y"
scp $hostname:/etc/machine.secret /tmp
kvno="$(ldapsearch -x -D "uid=Administrator,cn=users,dc=x,dc=y" -w "MeinGeheimesPasswort!11eelf" "(&(objectClass=univentionHost)(cn=$hostname))" krb5KeyVersionNumber | sed -n 's/^krb5KeyVersionNumber: \(.*\)$/\1/p')"
/usr/lib/univention-heimdal/univention-create-keytab --keytab="/tmp/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname" --kvno=$kvno --password="$(cat /tmp/machine.secret)"
scp /tmp/krb5.keytab $hostname:/etc/krb5.keytab
ssh $hostname chmod 600 /etc/krb5.keytab
rm /tmp/machine.secret
rm tmp/krb5.keytab 

[pixel]

kvno="$(ldapsearch -x -D “uid=Administrator,cn=users,dc=gehr,dc=lan” -w “xxxxxx” “(&(objectClass=univentionHost)(cn=$hostname))” krb5KeyVersionNumber | sed -n ‘s/^krb5KeyVersionNumber: (.*)$/\1/p’)"

Da kommt:

ldap_bind: Invalid credentials (49)

Passwort für den Administrator habe ich anstelle der xxxxx korrekt eingesetzt

[pixel]

So:

hostname="pc001"
domainname="gehr.lan"
scp $hostname:/etc/machine.secret /tmp

kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)

/usr/lib/univention-heimdal/univention-create-keytab --keytab="/tmp/krb5.keytab" --principal="host/$hostname.$domainname$" --alias="host/$hostname.$domainname" --kvno=$kvno --password="$(cat /tmp/machine.secret)"

scp /tmp/krb5.keytab $hostname:/etc/krb5.keytab
ssh $hostname chmod 600 /etc/krb5.keytab
rm /tmp/machine.secret
rm tmp/krb5.keytab

funktioniert zumindest der Ablauf. Ich kann jedoch nicht beurteilen ob die Variable kvno dadurch mit dem richtigen Wert gefüllt wird. Beide Systeme neu gestartet:

oot@pc001:~# mount -vvv -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: timeout set for Fri Dec  6 21:01:09 2019
mount.nfs4: trying text-based options 'sec=krb5i,vers=4.2,addr=192.168.24.5,clientaddr=192.168.24.111'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting tux.gehr.lan:/home

[SirTux]

Ob die Keytab etwas sinnvolles enthält könntest du testen, ob du dich per Kerberos am SSH-Daemon vom Client authentifizieren kannst (muß aber manuell aktiviert werden).