[PATCH] runqemu-export-rootfs: don't change RPC ports

[PATCH] runqemu-export-rootfs: don't change RPC ports

[Cody P Schafer]

The mountprog & nfsprog options given are not supported in the linux
kernel, and the only references I can find to them are in the nfs-utils
source, which notes:

  "mountprog" is supported only by the legacy mount command.  The
  kernel mount client does not support this option.

(and similar for nfsprog).

The kernel (which is what parses `nfsroot=<arg>` when using nfsroot)
has no understanding of nfsprog or mountprog.

The result of this is that trying to mount filesystems exported by
runqemu-export-rootfs in modern kernels (at least in 4.2 and later, and
probably more like 2.6.20 and later) doesn't actually work.

I'm honestly not sure how anyone was using this for nfsroot support.
Maybe an initramfs with a version of nfs-utils that could handle the
mountprog/nfsprog option was in use? Not sure.

Signed-off-by: Cody P Schafer <dev@codyps.com>
---
 scripts/runqemu-export-rootfs | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs
index c7992d8223..70cdcdbb13 100755
--- a/scripts/runqemu-export-rootfs
+++ b/scripts/runqemu-export-rootfs
@@ -77,10 +77,6 @@ if [ ! -d "$PSEUDO_LOCALSTATEDIR" ]; then
 	exit 1	
 fi
 
-# rpc.mountd RPC port
-MOUNTD_RPCPORT=${MOUNTD_RPCPORT:=$[ 21111 + $NFS_INSTANCE ]}
-# rpc.nfsd RPC port
-NFSD_RPCPORT=${NFSD_RPCPORT:=$[ 11111 + $NFS_INSTANCE ]}
 # NFS server port number
 NFSD_PORT=${NFSD_PORT:=$[ 3049 + 2 * $NFS_INSTANCE ]}
 # mountd port number
@@ -88,7 +84,7 @@ MOUNTD_PORT=${MOUNTD_PORT:=$[ 3048 + 2 * $NFS_INSTANCE ]}
 
 ## For debugging you would additionally add
 ## --debug all
-UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -x $NFSD_RPCPORT -n $NFSD_PORT -y $MOUNTD_RPCPORT -m $MOUNTD_PORT"
+UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -n $NFSD_PORT -m $MOUNTD_PORT"
 
 # See how we were called.
 case "$1" in
@@ -130,7 +126,7 @@ case "$1" in
 	fi
 	echo " "
 	echo "On your target please remember to add the following options for NFS"
-	echo "nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,mountprog=$MOUNTD_RPCPORT,nfsprog=$NFSD_RPCPORT,udp,mountport=$MOUNTD_PORT"
+	echo "nfsroot=IP_ADDRESS:$NFS_EXPORT_DIR,nfsvers=3,port=$NFSD_PORT,udp,mountport=$MOUNTD_PORT"
 	;;
   stop)
 	if [ -f "$NFSPID" ]; then
-- 
2.13.0

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Cody P Schafer]

> The result of this is that trying to mount filesystems exported by
> runqemu-export-rootfs in modern kernels (at least in 4.2 and later, and
> probably more like 2.6.20 and later) doesn't actually work.

To clarify, when using nfsroot with the current kernel & unfsd
options, my boot stops, waits for the nfs root to appear, and then
times out. When trying to mount normally (ie: via `mount -t nfs` of a
very recent vintage in arch-linux), I get immediate "protocol family
not supported" errors.

With this change, both mount methods (nfsroot with new kernel options
and normally mount) work without issue.

> I'm honestly not sure how anyone was using this for nfsroot support.
> Maybe an initramfs with a version of nfs-utils that could handle the
> mountprog/nfsprog option was in use? Not sure.

Or is there some yocto kernel patch to enable support for it? I'm
running a custom kernel.

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

On Wed, May 31, 2017 at 1:04 AM, Cody P Schafer <dev@codyps.com> wrote:

> > The result of this is that trying to mount filesystems exported by
> > runqemu-export-rootfs in modern kernels (at least in 4.2 and later, and
> > probably more like 2.6.20 and later) doesn't actually work.
>
> To clarify, when using nfsroot with the current kernel & unfsd
> options, my boot stops, waits for the nfs root to appear, and then
> times out. When trying to mount normally (ie: via `mount -t nfs` of a
> very recent vintage in arch-linux), I get immediate "protocol family
> not supported" errors.
>
> With this change, both mount methods (nfsroot with new kernel options
> and normally mount) work without issue.
>
> > I'm honestly not sure how anyone was using this for nfsroot support.
> > Maybe an initramfs with a version of nfs-utils that could handle the
> > mountprog/nfsprog option was in use? Not sure.
>
> Or is there some yocto kernel patch to enable support for it? I'm
> running a custom kernel.
>


There's a patch that we've had for years to allow alternate RPC ports
to work with userspace NFS and co-exist with existing NFS servers.

This would have an impact on that functionality, so if we do need to
change those ports, the existing ones should be maintained with some
sort of option to change the nfsroot line.

Bruce


> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 2682 bytes --]

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Cody P Schafer]

> There's a patch that we've had for years to allow alternate RPC ports
> to work with userspace NFS and co-exist with existing NFS servers.

Ah, I see (I should have checked that sooner). "NFS: allow nfs root
mount to use alternate rpc ports". I can likely just pull that into my
kernel and have things work fine without changes to
runqemu-export-rootfs.

> This would have an impact on that functionality, so if we do need to
> change those ports, the existing ones should be maintained with some
> sort of option to change the nfsroot line.

Yep, that makes sense.

That said: it isn't completely clear to me that a seperate rpc program
number (aka RPC port) is needed to avoid conflicts between 2 nfs
instances in this case:

 - we don't have unfsd register with rpcbind (-p option), so the rpc
program numbers won't conflict there.
 - using nfsroot implicitly adds the 'nolock' option, so there isn't a
conflict there
 - I did my tests with the nfs kernel server running. There wasn't an
immdiate issue observed with mounting and accessing both a kernel
provided export & a unfsd provided export (using
runqemu-export-rootfs) at the same time.

Still, I'm not too familiar with all of the ins and outs of nfs. Is
there somewhere I've overlooked where the program numbers could
conflict?

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Mark Hatle]

On 5/31/17 11:07 AM, Cody P Schafer wrote:
>> There's a patch that we've had for years to allow alternate RPC ports
>> to work with userspace NFS and co-exist with existing NFS servers.
> 
> Ah, I see (I should have checked that sooner). "NFS: allow nfs root
> mount to use alternate rpc ports". I can likely just pull that into my
> kernel and have things work fine without changes to
> runqemu-export-rootfs.
> 
>> This would have an impact on that functionality, so if we do need to
>> change those ports, the existing ones should be maintained with some
>> sort of option to change the nfsroot line.
> 
> Yep, that makes sense.
> 
> That said: it isn't completely clear to me that a seperate rpc program
> number (aka RPC port) is needed to avoid conflicts between 2 nfs
> instances in this case:
> 
>  - we don't have unfsd register with rpcbind (-p option), so the rpc
> program numbers won't conflict there.
>  - using nfsroot implicitly adds the 'nolock' option, so there isn't a
> conflict there
>  - I did my tests with the nfs kernel server running. There wasn't an
> immdiate issue observed with mounting and accessing both a kernel
> provided export & a unfsd provided export (using
> runqemu-export-rootfs) at the same time.
> 
> Still, I'm not too familiar with all of the ins and outs of nfs. Is
> there somewhere I've overlooked where the program numbers could
> conflict?
> 

Non-root user can't create privileged ports.

Multiple nfs-servers and/or developers on the same machine could end up with
port conflicts, so we need to make sure the ports can 'change'.

Of course running this on a machine that has a traditional NFS server will also
cause a conflict.   The various rpmbind and other options may reduce the
likelihood of a conflict -- but they can still occur.  It's better to use unique
port information on a per-use basis to avoid any potential conflicts or
privileged port requirements.

--Mark

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Cody P Schafer]

> Non-root user can't create privileged ports.

I presume you're speaking about tcp/udp ports here? (having the
program numbers referred to as "RPC ports" in some contexts confuses
things). Or does unfsd tell the kernel about it's rpc program numbers
(called "RPC ports" in the script) somehow & restrict them too?

If it is the first, it isn't clear why that is relevant: I'm not
trying to have unfsd use privileged tcp/udp ports (it's already using
non-privlidged tcp/udp ports). I'm trying to drop the custom rpc
program numbers (which are referred to as "RPC Ports" in the script).

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Mark Hatle]

On 5/31/17 12:20 PM, Cody P Schafer wrote:
>> Non-root user can't create privileged ports.
> 
> I presume you're speaking about tcp/udp ports here? (having the
> program numbers referred to as "RPC ports" in some contexts confuses
> things). Or does unfsd tell the kernel about it's rpc program numbers
> (called "RPC ports" in the script) somehow & restrict them too?
> 
> If it is the first, it isn't clear why that is relevant: I'm not
> trying to have unfsd use privileged tcp/udp ports (it's already using
> non-privlidged tcp/udp ports). I'm trying to drop the custom rpc
> program numbers (which are referred to as "RPC Ports" in the script).
> 

RPC Ports are just the bindings into rpcbind.   The tcp/udp ports are the ones
that typically conflict and why this was all done to begin with.

--Mark

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Cody P Schafer]

> RPC Ports are just the bindings into rpcbind.   The tcp/udp ports are the ones
> that typically conflict and why this was all done to begin with.

Ok, then it doesn't sound like that is a conflict or a "privileged
ports" issue, and it is safe to drop the custom rpc program numbers
("RPC Ports") from `unfsd`s arguments & the kernel parameters.

As I've noted, runqemu-export-rootfs does not register with rpcbind
(we pass the `-p` flag to `unfsd`).

Or is there something else system-wide which is keeping a list of rpc
program numbers?

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Mark Hatle]

On 5/31/17 3:27 PM, Cody P Schafer wrote:
>> RPC Ports are just the bindings into rpcbind.   The tcp/udp ports are the ones
>> that typically conflict and why this was all done to begin with.
> 
> Ok, then it doesn't sound like that is a conflict or a "privileged
> ports" issue, and it is safe to drop the custom rpc program numbers
> ("RPC Ports") from `unfsd`s arguments & the kernel parameters.
> 
> As I've noted, runqemu-export-rootfs does not register with rpcbind
> (we pass the `-p` flag to `unfsd`).

The rpcbind runs on a privileged port (usually).  So either you have to 're-use'
the system wide on or run your own.  On many environments, with a system wide
one, you will clash if someone else is offering the same services.  So you are
forced to run your own and/or register then with a different set of port numbers.

This is absolutely needed in a multi-user or 'locked system' configuration where
the user does not have permission to run these types of things.

--Mark

> Or is there something else system-wide which is keeping a list of rpc
> program numbers?
> 

Re: [PATCH] runqemu-export-rootfs: don't change RPC ports

[Cody P Schafer]

On Thu, Jun 1, 2017 at 1:02 PM, Mark Hatle <mark.hatle@windriver.com> wrote:

>
> The rpcbind runs on a privileged port (usually).  So either you have to 're-use'
> the system wide on or run your own.  On many environments, with a system wide
> one, you will clash if someone else is offering the same services.  So you are
> forced to run your own and/or register then with a different set of port numbers.
>
> This is absolutely needed in a multi-user or 'locked system' configuration where
> the user does not have permission to run these types of things.

unfsd does not include rpcbind, it optionally uses the system's rpcbind.

In the runqemu-export-rootfs case, unfsd does not use any rpcbind at all.

Still not seeing anything that would require runqemu-export-rootfs to
use custom rpc program numbers.