[gssproxy] Try to load the auth_rpcgss module before starting

[Alphix]

If you install gssproxy before nfs-kernel-server (or whatever the equivalent package is named on non-Debian distros), the auth_rpcgss module will typically not be loaded.

This leads to output like this: systemd[1]: Starting gssproxy.service - GSSAPI Proxy Daemon... gssproxy[1519]: [2023/10/16 20:47:33]: Debug Level changed to 3 gssproxy[1519]: k5tracer_thread started! gssproxy[1519]: [2023/10/16 20:47:33]: Service: nfs-server, Keytab: , Enctype: 18 gssproxy[1521]: [2023/10/16 20:47:33]: Kernel doesn't support GSS-Proxy (can't open /proc/net/rpc/use-gss-proxy: 2 (No such file or directory)) gssproxy[1521]: [2023/10/16 20:47:33]: Problem with kernel communication! NFS server will not work systemd[1]: Started gssproxy.service - GSSAPI Proxy Daemon. gssproxy[1521]: [2023/10/16 20:47:33]: Initialization complete.

And gssproxy won't work properly until the nfs kernel server package(s) have been installed and gssproxy has been restarted (which is kind of difficult to debug) since it won't try opening /proc/net/rpc/use-gss-proxy again.

Signed-off-by: David Härdeman david@hardeman.nu

[simo5]

Was there a recent change in nfs-utils? Because this was not an issue before.

[simo5]

Anyway, doesn't this force rpc_authgss to always be loaded even if the NFS server is not being used?

[Alphix]

Was there a recent change in nfs-utils? Because this was not an issue before.

It's only an issue if you take a fresh system (a future NFS server) and install/configure/start gssproxy before installing nfs-utils. The effect will be non-working Kerberized NFS (with no information in the relevant logs as to why unless gssproxy is running at debug level 3) until gssproxy is restarted.

[Alphix]

Anyway, doesn't this force rpc_authgss to always be loaded even if the NFS server is not being used?

Yeah, that's true, not sure what the best way to approach this would be. Having gssproxy call out to modprobe isn't nice...but a silently non-working Kerberized NFS server is also not very user-friendly. Perhaps add the changes to the .service file but commented out....

Adding an After=nfs-server.service stanza won't work because (on my Debian system at least), the nfs-server.service file already contains:

# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service rpc-svcgssd.service
After=rpc-gssd.service gssproxy.service rpc-svcgssd.service

auth-rpcgss-module.service comes from the package nfs-common and reads:

# We want to start gss-proxy on kernels that support it and rpc.svcgssd
# on those that don't.  Those services check for support by checking
# for existence of the path /proc/net/rpc/use-gss-proxy.  Before they
# can perform that check, they need this module loaded.  (Unless
# rpcsec_gss support is built directly into the kernel, in which case this
# unit will fail.  But that's OK.)
[Unit]
Description=Kernel Module supporting RPCSEC_GSS
DefaultDependencies=no
Before=gssproxy.service rpc-svcgssd.service rpc-gssd.service
Wants=gssproxy.service rpc-gssd.service
ConditionPathExists=/etc/krb5.keytab
ConditionVirtualization=!container

[Service]
Type=oneshot
ExecStart=/sbin/modprobe -q auth_rpcgss
RemainAfterExit=yes

[Alphix]

Adding some retry logic for opening /proc/net/rpc/use-gss-proxy to gssproxy might be a better solution...

[simo5]

Maybe we reopen on a SIGHUP and change the nfs util service file to ping the gss-proxy ? Is a SIGHUP something we can instruct systemd to send this way ?

[Alphix]

Maybe we reopen on a SIGHUP and change the nfs util service file to ping the gss-proxy ? Is a SIGHUP something we can instruct systemd to send this way ?

Looking at the code, a SIGHUP already causes a new attempt to poke /proc/net/rpc/use-gss-proxy:

https://github.com/gssapi/gssproxy/blob/f52e60fad1e202a8f9c06ec6ce8bada69c62c93c/src/gp_init.c#L255-L280

Perhaps an ExecStartPre=killall -SIGHUP /usr/sbin/gssproxy in nfs-server.service or ExecStartPost=killall -SIGHUP /usr/sbin/gssproxy in auth-rpcgss-module.service could do the trick (the latter seems saner).

As an alternative, I've prepared a separate PR with changes to gssproxy to make it retry poking /proc/net/rpc/use-gss-proxy, see PR #85

[simo5]

Perhaps an ExecStartPre=killall -SIGHUP /usr/sbin/gssproxy in nfs-server.service or ExecStartPost=killall -SIGHUP /usr/sbin/gssproxy in auth-rpcgss-module.service could do the trick (the latter seems saner).

I agree the latter is saner, I would pursue that within nfs-utils on top of your proposed #85

[simo5]

Replaced by #85