Daniel Pocock schrieb am Mittwoch, den 14. Dezember um 09:38 Uhr: > They stopped including rpc-svcgssd in the default build as of 1.3.2 and > recommended gssproxy[1] instead.
Yes, gssproxy is a working drop-in replacement for rpc.svcgssd in case of the nfs4-server use case. Note, that they are mutually exclusive. Once gssproxy has been used on a machine a reboot is requeired to go back to rpc.svcgssd again. As I already wrote in my bug-report I consider rpc.svcgssd broken. This said it would be a good idea to remove it from the nfs-package alltogether. Instead a "Recommends: gssproxy" can be added. I am currently running a custom quick-and dirty debian package of gssproxy compiled for debian stable and the original version of nfs-common (1.2.8-9). I can also try running this with a backport of nfs-common 1.3.4 on my test-vm. For running an NFS-server /etc/gssproxy/gssproxy.conf looks like this here: --cut-- [gssproxy] [service/nfs-server] mechs = krb5 socket = /run/gssproxy.sock cred_store = keytab:/etc/krb5.keytab trusted = yes kernel_nfsd = yes euid = 0 --cut-- The most simple test-setup for kerberized nfs4 might be the following: 3 virtual machines: 1. A Samba 4 ADDC 2. An nfs-server 3. An nfs-client Machines 2 and 3 need to be bound to Samba 4 ADDC using nslcd or sssd for UID-mapping. Regards Sven -- Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety (Benjamin Franklin) /me is giggls@ircnet, http://sven.gegg.us/ on the Web