Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[gssproxy] Try to load the auth_rpcgss module before starting #84

Closed
wants to merge 1 commit into from

Conversation

Alphix
Copy link
Contributor

@Alphix Alphix commented Oct 16, 2023

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: <some_path>, 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

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: <some_path>, 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>
@Alphix Alphix force-pushed the update-systemd-service branch from 067622f to 42a33bf Compare October 16, 2023 22:15
@simo5
Copy link
Contributor

simo5 commented Oct 17, 2023

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

@simo5
Copy link
Contributor

simo5 commented Oct 17, 2023

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

@Alphix
Copy link
Contributor Author

Alphix commented Oct 18, 2023

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
Copy link
Contributor Author

Alphix commented Oct 18, 2023

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
Copy link
Contributor Author

Alphix commented Oct 18, 2023

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

@simo5
Copy link
Contributor

simo5 commented Oct 18, 2023

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
Copy link
Contributor Author

Alphix commented Oct 18, 2023

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:

gssproxy/src/gp_init.c

Lines 255 to 280 in f52e60f

static void hup_handler(verto_ctx *vctx UNUSED, verto_ev *ev)
{
int ret;
struct gssproxy_ctx *gpctx;
struct gp_config *new_config, *old_config;
gpctx = verto_get_private(ev);
GPDEBUG("Received SIGHUP; re-reading config.\n");
new_config = read_config(gpctx->config_file, gpctx->config_dir,
gpctx->config_socket, gpctx->daemonize);
if (!new_config) {
GPERROR("Error reading new configuration on SIGHUP; keeping old "
"configuration instead!\n");
return;
}
old_config = gpctx->config;
gpctx->config = new_config;
ret = init_sockets(gpctx, old_config);
if (ret != 0) {
exit(ret);
}
/* conditionally reload kernel interface */
init_proc_nfsd(gpctx->config);

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
Copy link
Contributor

simo5 commented Oct 18, 2023

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
Copy link
Contributor

simo5 commented Oct 18, 2023

Replaced by #85

@simo5 simo5 closed this Oct 18, 2023
@Alphix Alphix deleted the update-systemd-service branch October 19, 2023 10:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants