Re: rpcbind behavior on Fedora 7

Re: rpcbind behavior on Fedora 7

[Steve Dickson]

Sorry for the delayed response... I was traveling...

Chuck Lever wrote:
> I was trying out the mount.nfs test case for another bug (see attached). 
>  The test case didn't work against a Fedora 7 server.  Trying to mount 
> with UDP against a specific port just hangs.  So I tried an rpcinfo 
> against it to see what the current configuration was.
In /etc/netconfig switch the order of the udp/tcp and udp6/tcp6
entries making the udp/tcp entires first. Similar to:

--- /etc/netconfig.orig   2005-05-18 01:10:50.000000000 -0400
+++ /etc/netconfig    2007-07-24 09:45:40.000000000 -0400
@@ -10,10 +10,10 @@
  # The <device> and <nametoaddr_libs> fields are always empty in this
  # implementation.
  #
-udp6       tpi_clts      v     inet6    udp     -       -
-tcp6       tpi_cots_ord  v     inet6    tcp     -       -
  udp        tpi_clts      v     inet     udp     -       -
  tcp        tpi_cots_ord  v     inet     tcp     -       -
+udp6       tpi_clts      v     inet6    udp     -       -
+tcp6       tpi_cots_ord  v     inet6    tcp     -       -
  rawip      tpi_raw       -     inet      -      -       -
  local      tpi_cots_ord  -     loopback  -      -       -
  unix       tpi_cots_ord  -     loopback  -      -       -


steved.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Status of mount.nfs

[Steinar H. Gunderson]

Hi,

util-linux 2.13 drops support for NFS mounts:

  Release highlights:
  ------------------
   mount(8) doesn't include NFS client code anymore. Don't forget to
   install nfs-utils 1.1.0 or newer with /sbin/[u]mount.{nfs,nfs4}.

However, the last I can find in nfs-utils changelog about this is:

  commit 99414bd3eecf93f23c378d3bb3d45bc98f364abc
  Author: Neil Brown <neilb@suse.de>
  Date:   Sat Jul 8 09:41:58 2006 +1000
  
      Disable building/installing mount.nfs by default.
      
      mount.nfs does not yet support 'user' option and some others.
      To make it support this we need to make it setuid-root, and
      some security isses need to be resolved before that can be done
      safely.

What's the current recommendation for distributions with regard to NFS
mounting?

/* Steinar */
-- 
Homepage: http://www.sesse.net/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status of mount.nfs

[Neil Brown]

On Sunday July 8, sesse@debian.org wrote:
> Hi,
> 
> util-linux 2.13 drops support for NFS mounts:
> 
>   Release highlights:
>   ------------------
>    mount(8) doesn't include NFS client code anymore. Don't forget to
>    install nfs-utils 1.1.0 or newer with /sbin/[u]mount.{nfs,nfs4}.
> 
> However, the last I can find in nfs-utils changelog about this is:
> 
>   commit 99414bd3eecf93f23c378d3bb3d45bc98f364abc
>   Author: Neil Brown <neilb@suse.de>
>   Date:   Sat Jul 8 09:41:58 2006 +1000
>   
>       Disable building/installing mount.nfs by default.
>       
>       mount.nfs does not yet support 'user' option and some others.
>       To make it support this we need to make it setuid-root, and
>       some security isses need to be resolved before that can be done
>       safely.

I wonder why you didn't find:
commit b3b111b1bd5fbc678419bf1964b6093045081139
Author: Neil Brown <neilb@suse.de>
Date:   Tue Mar 20 14:18:41 2007 +1100

    Build mount.nfs by default, and install setuid
    
    Also fix a few bugs that came up in initial testing.

> 
> What's the current recommendation for distributions with regard to NFS
> mounting?

nfs-utils-1.1.0 builds and install mount.nfs by default, and should be
used with the new util-linux.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status of mount.nfs

[Steinar H. Gunderson]

On Mon, Jul 09, 2007 at 01:17:19PM +1000, Neil Brown wrote:
> nfs-utils-1.1.0 builds and install mount.nfs by default, and should be
> used with the new util-linux.

Just a few experiences with this after a week or so with the new default in
Debian:

 - The new mount is really more picky in several aspects. Most notably, it
   refuses to mount anything unless rpc.statd is running, which broke our
   NFS mounting on boot. Also, it seems to be less forgiving about portmapper
   registration; cfs (an encrypted filesystem based off NFS, it seems) sets
   up a server on port 3049 and expects "-o port=3049,nfsvers=2" to work. The
   new mount.nfs searches for a portmapper unless the udp option is also
   correctly set. I'm slightly surprised at this increase in strictness,
   given that I thought it was essentially the same code.
 - If you forget to install it suid (we strip suid bits automatically) you
   will of course break user mounts. :-)
 - The umount exit status is broken, which will cause odd failures on umount
   from the GNOME drive manager (basically, an empty error dialog box). Apply
   the patch I posted here earlier.

I guess that's all the traps I've fell into for now; I hope they'll make it
easier to make the move for other distributions.
 
/* Steinar */
-- 
Homepage: http://www.sesse.net/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status of mount.nfs

[Neil Brown]

On Sunday July 15, sesse@debian.org wrote:
> On Mon, Jul 09, 2007 at 01:17:19PM +1000, Neil Brown wrote:
> > nfs-utils-1.1.0 builds and install mount.nfs by default, and should be
> > used with the new util-linux.
> 
> Just a few experiences with this after a week or so with the new default in
> Debian:

Thanks for sharing.

> 
>  - The new mount is really more picky in several aspects. Most notably, it
>    refuses to mount anything unless rpc.statd is running, which broke our
>    NFS mounting on boot.

Is this simply because you were mounting NFS filesystems before
running statd?  In that case, maybe we should say that it "highlighted
that your NFS mounting on boot was already broken" ?? :-)
If you need to nfsmount '/' or '/var', you should mount them with
"-o nolock"  and then statd won't be needed.

>                          Also, it seems to be less forgiving about portmapper
>    registration; cfs (an encrypted filesystem based off NFS, it seems) sets
>    up a server on port 3049 and expects "-o port=3049,nfsvers=2" to work. The
>    new mount.nfs searches for a portmapper unless the udp option is also
>    correctly set.

I'm a bit confused here.  I would expect that to avoid portmap being
used, you would need to set both 'port' and 'mountport' on the command
line.  It shouldn't have anything to do with whether UDP is set.  Can
you say a bit more about what you discovered here?

>                   I'm slightly surprised at this increase in strictness,
>    given that I thought it was essentially the same code.

It is based on the same code but with quite a number of fixes and
"improvements".  It is entirely possible that some regressions were
introduced, though I tried to do a reasonable amount of testing and
review.


>  - If you forget to install it suid (we strip suid bits automatically) you
>    will of course break user mounts. :-)

and if you forget to install the new man pages, you will have
incomplete documentation :-)
nfs-common  1:1.1.0-9  does not have mount.nfs and umount.nfs man pages.


>  - The umount exit status is broken, which will cause odd failures on umount
>    from the GNOME drive manager (basically, an empty error dialog box). Apply
>    the patch I posted here earlier.

Thanks for this fix.

> 
> I guess that's all the traps I've fell into for now; I hope they'll make it
> easier to make the move for other distributions.

Thanks a lot!

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status of mount.nfs

[Steinar H. Gunderson]

On Mon, Jul 16, 2007 at 11:13:14AM +1000, Neil Brown wrote:
> Is this simply because you were mounting NFS filesystems before
> running statd?  In that case, maybe we should say that it "highlighted
> that your NFS mounting on boot was already broken" ?? :-)

Yes, we were. I'm in the process of patching the boot process now, so you
could probably shed light on a related issue: Do we need to start portmap
before statd or not? The comments in the old code is slightly cryptic :-)

>>                          Also, it seems to be less forgiving about portmapper
>>    registration; cfs (an encrypted filesystem based off NFS, it seems) sets
>>    up a server on port 3049 and expects "-o port=3049,nfsvers=2" to work. The
>>    new mount.nfs searches for a portmapper unless the udp option is also
>>    correctly set.
> I'm a bit confused here.  I would expect that to avoid portmap being
> used, you would need to set both 'port' and 'mountport' on the command
> line.  It shouldn't have anything to do with whether UDP is set.  Can
> you say a bit more about what you discovered here?

Well, I have no idea how these things work at all, I just traced through the
code and saw what would make it work :-) cfs runs as its own NFS daemon, on
port 3049, but does not seem to register with the portmapper. The mount
command given, without "-o udp", gives:

  mount: mount to NFS server 'localhost' failed: RPC Error: Success.

The error seems to originate from probe_nfsport(), which also has a line
saying

  if (pmap->pm_vers && pmap->pm_prot && pmap->pm_port)
          return 1;

which indicates that if version+protocol+port are all set beforehand, don't
probe -- and indeed, that works. I stopped debugging the issue there.

>>  - If you forget to install it suid (we strip suid bits automatically) you
>>    will of course break user mounts. :-)
> and if you forget to install the new man pages, you will have
> incomplete documentation :-)
> nfs-common  1:1.1.0-9  does not have mount.nfs and umount.nfs man pages.

Thanks, nice catch. I'll be sure to fix that in the next upload.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status of mount.nfs

[Neil Brown]

On Monday July 16, sesse@debian.org wrote:
> On Mon, Jul 16, 2007 at 11:13:14AM +1000, Neil Brown wrote:
> > Is this simply because you were mounting NFS filesystems before
> > running statd?  In that case, maybe we should say that it "highlighted
> > that your NFS mounting on boot was already broken" ?? :-)
> 
> Yes, we were. I'm in the process of patching the boot process now, so you
> could probably shed light on a related issue: Do we need to start portmap
> before statd or not? The comments in the old code is slightly cryptic :-)

Yes.  Portmap should be one of the first things started after basic
networking is up.  You might even be able to start it before that, but
I'm not sure.  You need it before any RPC service which includes
statd, lockd, nfsd, ypbind, ...
You can mount an NFS filesystem with '-o nolocks' before portmap, but
that it about all.

> 
> >>                          Also, it seems to be less forgiving about portmapper
> >>    registration; cfs (an encrypted filesystem based off NFS, it seems) sets
> >>    up a server on port 3049 and expects "-o port=3049,nfsvers=2" to work. The
> >>    new mount.nfs searches for a portmapper unless the udp option is also
> >>    correctly set.
> > I'm a bit confused here.  I would expect that to avoid portmap being
> > used, you would need to set both 'port' and 'mountport' on the command
> > line.  It shouldn't have anything to do with whether UDP is set.  Can
> > you say a bit more about what you discovered here?
> 
> Well, I have no idea how these things work at all, I just traced through the
> code and saw what would make it work :-) cfs runs as its own NFS daemon, on
> port 3049, but does not seem to register with the portmapper. The mount
> command given, without "-o udp", gives:
> 
>   mount: mount to NFS server 'localhost' failed: RPC Error: Success.
> 
> The error seems to originate from probe_nfsport(), which also has a line
> saying
> 
>   if (pmap->pm_vers && pmap->pm_prot && pmap->pm_port)
>           return 1;
> 
> which indicates that if version+protocol+port are all set beforehand, don't
> probe -- and indeed, that works. I stopped debugging the issue there.

Hmmm.... That code looks a little odd.  If you say you want udp, it
will still probe for tcp first.  That doesn't hurt as UDP and TCP
always use the same port: 2049.  But it is still odd.  I wonder if it
is needed at all.

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status of mount.nfs

[Steinar H. Gunderson]

On Mon, Jul 16, 2007 at 08:15:19PM +1000, Neil Brown wrote:
> Hmmm.... That code looks a little odd.  If you say you want udp, it
> will still probe for tcp first.  That doesn't hurt as UDP and TCP
> always use the same port: 2049.  But it is still odd.  I wonder if it
> is needed at all.

It seems it broke for a more normal situation as well:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433881

Giving the "udp" option helped the user, though, but I don't really see why
the behavior changed.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Status of mount.nfs

[Steinar H. Gunderson]

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

On Mon, Jul 23, 2007 at 06:13:42PM -0400, Chuck Lever wrote:
> It would help if we could take a look at a clean network trace of the bad 
> and the good mount operations.

It was quite simple to test this myself. I started the kernel server on a
machine, then shut down portmap. First I did:

  fugl:~> sudo mount -t nfs -o port=2049,mountport=901,nfsvers=3 192.168.0.101:/ /mnt
  mount: mount to NFS server '192.168.0.101' failed: System Error: Connection refused.

The dump is attached as "default.dump". Then I did

  fugl:~> sudo mount -t nfs -o port=2049,mountport=901,nfsvers=3,udp 192.168.0.101:/ /mnt 

which is attached as "udp.dump".

Note that in default.dump, UDP is simply never tried at all. I believe that
to be a bug.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

[-- Attachment #2: default.dump --]
[-- Type: application/octet-stream, Size: 356 bytes --]

[-- Attachment #3: udp.dump --]
[-- Type: application/octet-stream, Size: 2376 bytes --]

[-- Attachment #4: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #5: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

rpcbind behavior on Fedora 7

[Chuck Lever]

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

Hi Steve-

I was trying out the mount.nfs test case for another bug (see below). 
The test case didn't work against a Fedora 7 server.  Trying to mount 
with UDP against a specific port just hangs.  So I tried an rpcinfo 
against it to see what the current rocbind configuration was.

 > [root@picasso ~]# rpcinfo ingres
 >    program version netid     address                service    owner
 >     100000    4    tcp6      ::.0.111               portmapper superuser
 >     100000    3    tcp6      ::.0.111               portmapper superuser
 >     100000    2    tcp6      ::.0.111               portmapper superuser
 >     100000    4    udp6      ::.0.111               portmapper superuser
 >     100000    3    udp6      ::.0.111               portmapper superuser
 >     100000    2    udp6      ::.0.111               portmapper superuser
 >     100000    4    local     /v                     portmapper superuser
 >     100000    3    local     /v                     portmapper superuser
 >     100000    2    local     /v                     portmapper superuser
 >     100024    1    udp6      ::.2.222               status     unknown
 >     100024    1    tcp6      ::.2.225               status     unknown
 >     100021    1    tcp6      ::.170.233             nlockmgr   unknown
 >     100021    3    tcp6      ::.170.233             nlockmgr   unknown
 >     100021    4    tcp6      ::.170.233             nlockmgr   unknown
 >     100011    1    udp6      ::.3.158               rquotad    unknown
 >     100011    2    udp6      ::.3.158               rquotad    unknown
 >     100011    1    tcp6      ::.3.161               rquotad    unknown
 >     100011    2    tcp6      ::.3.161               rquotad    unknown
 >     100021    1    udp6      ::.128.0               nlockmgr   unknown
 >     100021    3    udp6      ::.128.0               nlockmgr   unknown
 >     100021    4    udp6      ::.128.0               nlockmgr   unknown
 >     100003    2    udp6      ::.8.1                 nfs        unknown
 >     100003    3    udp6      ::.8.1                 nfs        unknown
 >     100003    4    udp6      ::.8.1                 nfs        unknown
 >     100003    2    tcp6      ::.8.1                 nfs        unknown
 >     100003    3    tcp6      ::.8.1                 nfs        unknown
 >     100003    4    tcp6      ::.8.1                 nfs        unknown
 >     100005    1    udp6      ::.2.135               mountd     unknown
 >     100005    1    tcp6      ::.2.138               mountd     unknown
 >     100005    2    udp6      ::.2.135               mountd     unknown
 >     100005    2    tcp6      ::.2.138               mountd     unknown
 >     100005    3    udp6      ::.2.135               mountd     unknown
 >     100005    3    tcp6      ::.2.138               mountd     unknown
 > [root@picasso ~]#

Um.  Ok, where are the IPv4 entries?

I've now completely shut off IPv6 initialization and autoconfiguration 
on the only network interface on the system and rebooted several times 
(I wasn't using the IPv6 networking stuff yet anyway).  I still get *no* 
udp4 or tcp4 entries in the rpcbind database.  The NFS service on this 
system is all IPv4 (it's a Linux NFS server).

How are these getting registered?

Steinar H. Gunderson wrote:
> On Mon, Jul 23, 2007 at 06:13:42PM -0400, Chuck Lever wrote:
>> It would help if we could take a look at a clean network trace of the bad 
>> and the good mount operations.
> 
> It was quite simple to test this myself. I started the kernel server on a
> machine, then shut down portmap. First I did:
> 
>   fugl:~> sudo mount -t nfs -o port=2049,mountport=901,nfsvers=3 192.168.0.101:/ /mnt
>   mount: mount to NFS server '192.168.0.101' failed: System Error: Connection refused.
> 
> The dump is attached as "default.dump". Then I did
> 
>   fugl:~> sudo mount -t nfs -o port=2049,mountport=901,nfsvers=3,udp 192.168.0.101:/ /mnt 
> 
> which is attached as "udp.dump".
> 
> Note that in default.dump, UDP is simply never tried at all. I believe that
> to be a bug.
> 
> /* Steinar */

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs