Bug 1076255

Summary:	Unable to set fs.nfs.nfs_callback_tcpport via sysctl at startup using systemd-sysctl.service
Product:	[Fedora] Fedora	Reporter:	Raman Gupta <rocketraman>
Component:	nfs-utils	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	adm.fkt.physik, bfields, gansalmon, itamar, jlayton, johannbg, jonathan, kernel-maint, lnykryn, madhu.chinakonda, mchehab, msekleta, plautrba, steved, systemd-maint, vpavlin, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-26 01:15:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Raman Gupta 2014-03-13 22:53:02 UTC

Description of problem:

The NFS client delegation port is set to a random value by default. If an NFS client is running a firewall, the server will attempt (repeatedly, as per bug #1073196) to connect to that delegation port on the client and fail.

The solution to this is to set the port to a fixed value via sysctl i.e.:

fs.nfs.nfs_callback_tcpport = xxxx

However, doing this via a file in /etc/sysctl.d/ which is read by systemd systemd-sysctl.service at startup does not work correctly, since this value appears to be undefined by the kernel when systemd-sysctl.service is executed. The value only appears in /proc/sys once an NFS fs has been mounted.

Systemd does not report any errors at startup time (which is in itself an annoying problem as the sysop has no indication of why the value was not set properly), but when running:

SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/systemd-sysctl

the output states that fs.nfs.nfs_callback_tcpport does not exist.

Version-Release number of selected component (if applicable):

# rpm -q systemd
systemd-208-15.fc20.x86_64

# uname -a
Linux edison 3.13.6-200.fc20.x86_64 #1 SMP Fri Mar 7 17:02:28 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:

100% of the time. Simply reboot.

Steps to Reproduce:
1. Define /etc/sysctl.d/nfs.conf containing a fixed port e.g.:

fs.nfs.nfs_callback_tcpport = 4005

2. Reboot

3. Mount an NFS fs

Actual results:

The callback port is "0", i.e. random.

Expected results:

The callback port should be configurable.

Additional info:

Comment 1 Raman Gupta 2014-03-18 15:41:57 UTC

Forcing NFS to version 4.1 works around the problem, as in NFS 4.1 the client creates the callback channel, and so the callback port is no longer necessary.

Mount options:

-tnfs4 -ominorversion=1

But I'm not sure why 4.1 needs to be forced anyway, it seems like it should be enabled by default:

# cat /proc/fs/nfsd/versions 
-2 +3 +4 +4.1 -4.2

Comment 2 Lennart Poettering 2014-03-19 01:23:27 UTC

The systemd sysctl variable logic doesn't work for "dynamic" sysctls that come and go, and I am pretty sure we shouldn't have anything like that ever. 

The NFS folks really need to deal with this one. or stop doing magic sysctls that come and go.

Comment 3 Raman Gupta 2014-03-19 06:47:23 UTC

Thanks Lennart. That makes sense.

For the NFS folks: this is even worse than Lennart describes -- this sysctl only shows up *after* a mount command is executed. So one has to mount before one can change the callback port sysctl. That's really dumb.

Comment 4 Jeff Layton 2014-03-19 10:35:50 UTC

That's not exactly true. It shows up when nfsv4.ko is plugged in, it's just that the mount in your case is triggering that module load as well.

The best way to configure this is to use the nfs.ko module parm:

    parm:           callback_tcpport:portnr

So dropping a file that has contents like this in /etc/modprobe.d ought to do it:

    options nfs callback_tcpport=4005

...but I haven't the time to test it at the moment.

Comment 5 Raman Gupta 2014-03-26 01:15:22 UTC

(In reply to Jeff Layton from comment #4)
> That's not exactly true. It shows up when nfsv4.ko is plugged in, it's just
> that the mount in your case is triggering that module load as well.
> 
> The best way to configure this is to use the nfs.ko module parm:
> 
>     parm:           callback_tcpport:portnr

Jeff, thanks, that explains the proper way to set the callback port. I'll close this as WONTFIX, given Lennart's comments and that explanation.