headers
Trond Myklebust | 1 Feb 2006 02:07
Picon
Picon

New NFS_ALL...

There is a new set of client patches for 2.6.16-rc1. See

 http://client.linux-nfs.org/Linux-2.6.x/2.6.16-rc1/

  * Fix various rpc_pipefs bugs
  * A couple of attribute cache consistency fixes
  * various NLM fixes.

Note that I haven't yet integrated Chuck's patches, as I wanted to rush
something out for people to test the rpc_pipefs fixes (to see if the
Oopses are gone). Expect a new NFS_ALL, therefore, as soon as I finish
reviewing his fixes.

Cheers,
  Trond
Permalink | Reply | 0 comments |
headers
Suresh Jayaraman | 1 Feb 2006 11:34
Picon
Favicon

Re: newpynfs test failures

>>> "J. Bruce Fields" <bfields <at> fieldses.org> 1/31/2006 11:52:47 pm >>>
On Tue, Jan 31, 2006 at 10:08:14AM -0800, Frank Filz wrote:
>> I'm running the newpynfs tests and getting several failures.
> That's normal.  A lot of them are minor and/or not planned to be
fixed.

Could you please provide info. on failures which are planned not to be

fixed? Will be helpful to ignore those tests and we can work on the
other failures.

>> Are any failures expected, or is there a list of expected failures
>>somewhere?
> You might want to look at Bryce's test results for comparison.

I had gone through this. IMHO we should not ignore all. Few of them
are crucial but, may be minor.

Thanks,
Suresh
Permalink | Reply | 2 comments |
headers
Fredric Isaman | 1 Feb 2006 15:21
Picon
Favicon

Re: newpynfs test failures


On Wed, 1 Feb 2006, Suresh Jayaraman wrote:

> >>> "J. Bruce Fields" <bfields <at> fieldses.org> 1/31/2006 11:52:47 pm >>>
> On Tue, Jan 31, 2006 at 10:08:14AM -0800, Frank Filz wrote:
> >> I'm running the newpynfs tests and getting several failures.
> > That's normal.  A lot of them are minor and/or not planned to be
> fixed.
>
> Could you please provide info. on failures which are planned not to be
>
> fixed? Will be helpful to ignore those tests and we can work on the
> other failures.
>

One obvious set of failures that are not planned to be fixed are the utf8
tests.  You can skip those by adding 'noutf8' to the end of the flags
list.

	Fred
Permalink | Reply | 0 comments |
headers
Ronan Mullally | 1 Feb 2006 16:35
Picon
Picon

Debian/Sarge vs NetApp, idmap problem

Hi,

I've been using NFS and filers for years, but am new to NFSv4.  This is
probably an FAQ, but I haven't come across anything which help so far.

I'm configuring a Debian Sarge EM64T box running 2.6.12 to mount from
a filer.  I've upgraded / replaced a number of the standard packages:

  libnfsidmap1  0.12-1        (CITI)
  libgssapi1    0.7-1         (CITI)
  librpcsecgss1 0.7-1         (CITI)
  nfs-common    1.0.8-rc1-1   (CITI)
  mount         2.12r-5.1nfs4 (Debian Experimental)

I'm only after an AUTH_SYS setup, I've no need for Kerberos at present.

I'm running rpc.gssd -m (which I'm assuming I can skip for an AUTH_SYS
setup - correct?) and rpc.idmapd on the client.  Should I be running any
other daemons?

The filer has the following in its exports file:

 /vol/vol0/test -rw,root=w.x.y.z,sec=sys

I can successfully mount a filesystem from the filer with:

 mount -t nfs4 a.b.c.d:/vol/vol0/test /mnt/test

However, everything under /mnt/test is owned by nobody:nogroup.  Files
I create on the filer do have the correct ownership when viewed via an
(Continue reading)

Permalink | Reply | 8 comments |
headers
Trond Myklebust | 1 Feb 2006 17:38
Picon
Picon

Re: Debian/Sarge vs NetApp, idmap problem

On Wed, 2006-02-01 at 15:35 +0000, Ronan Mullally wrote:
> I'm running rpc.gssd -m (which I'm assuming I can skip for an AUTH_SYS
> setup - correct?) and rpc.idmapd on the client.  Should I be running any
> other daemons?
> 
> The filer has the following in its exports file:
> 
>  /vol/vol0/test -rw,root=w.x.y.z,sec=sys
> 
> I can successfully mount a filesystem from the filer with:
> 
>  mount -t nfs4 a.b.c.d:/vol/vol0/test /mnt/test
> 
> However, everything under /mnt/test is owned by nobody:nogroup.  Files
> I create on the filer do have the correct ownership when viewed via an
> NFSv3 mount.  I can change the ownership displayed using the idmap.conf
> file, so I'm assuming the issue is with idmap rather than the underlying
> NFSv4.
> 
> I've put:
> 
>  [Translation]
> 
>  Method = nsswitch
> 
> into the idmap.conf file (but not made any changes to nsswitch.conf) but
> it's made no difference.
> 
> Can anybody point me in the right direction?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ronan Mullally | 1 Feb 2006 17:53
Picon
Picon

Re: Debian/Sarge vs NetApp, idmap problem

Hej Trond,

On Wed, 1 Feb 2006, Trond Myklebust wrote:

> You need to ensure that the filer and the idmap.conf file both use the
> same domain.
>
> On the filer, check using
>
> 		options nfs.v4.id.domain
>
> and on the client, check that the "Domain =" field is set correctly
> in /etc/idmapd.conf

I was about to write a reply claming I didn't think this was it - I have
the same domain defined on both the filer and the debian box.

*However*, given that the paint isn't yet dry on this install, I've not
got around to setting up DNS for the private address space used.

A bit of digging around uncovered the fact that whilst I *do* have entries
in /etc/hosts on both devices, the FQDN on each line was *not* the first
name listed - ie I've got:

  1.2.3.4	filer filer.domain

rather than

  1.2.3.4	filer.domain filer
(Continue reading)

Permalink | Reply | 6 comments |
headers
J. Bruce Fields | 1 Feb 2006 18:11

linux-2.6.16-rc1-CITI_NFS4_ALL-1

http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/2.6.16--rc11
Changes since 2.6.15-CITI_NFS4_ALL-3:
	* Update to 2.6.16-rc1 and Trond's latest
	* Modify fslocations to get information from export downcall (untested)
	* Fix lockd/nfsd circular module dependency

There are bugs that keep server-side krb5i/p from working currently.  I'll
release another version as soon as that gets fixed--later today with luck....

--b.
Permalink | Reply | 2 comments |
headers
Ronan Mullally | 1 Feb 2006 22:07
Picon
Picon

Re: Debian/Sarge vs NetApp, idmap problem

Right, I'm a muppet.  It's not a DNS issue.  I'd managed to unmount the
directory and mistake normal ext3 behaviour for a working nfsv4 idmap.

Back to square one.

As Trond suggested the nfs v4 domains match on both the filer and in
idmapd.conf.   My conf file is below:

  [General]

  Verbosity = 0
  Pipefs-Directory = /var/lib/nfs/rpc_pipefs
  Domain = dom.ain

  [Translation]

  Method = nsswitch

  [Mapping]

  Nobody-User = nobody
  Nobody-Group = nogroup

I've got the following mounted from my fstab:

  rpc_pipefs      /var/lib/nfs/rpc_pipefs rpc_pipefs      defaults  0 0
  nfsd            /proc/fs/nfsd           nfsd            defaults  0 0

And all I can see from rpc.idmapd -v -v -v is:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Kevin Coffman | 1 Feb 2006 22:20
Picon
Favicon

Re: Debian/Sarge vs NetApp, idmap problem

I'm not sure this will make the difference since the filer is sending
"nobody", but your domain names do not match as you suggest they do?

>   [General]
>
>   Verbosity = 0
>   Pipefs-Directory = /var/lib/nfs/rpc_pipefs
>   Domain = dom.ain

>   nfs.v4.id.domain             efs.edu.ie

"dom.ain" does not match "efs.edu.ie"

You are correct that you should not need rpc.gssd running for auth=sys

On 2/1/06, Ronan Mullally <ronan <at> iol.ie> wrote:
> Right, I'm a muppet.  It's not a DNS issue.  I'd managed to unmount the
> directory and mistake normal ext3 behaviour for a working nfsv4 idmap.
>
> Back to square one.
>
> As Trond suggested the nfs v4 domains match on both the filer and in
> idmapd.conf.   My conf file is below:
>
>   [General]
>
>   Verbosity = 0
>   Pipefs-Directory = /var/lib/nfs/rpc_pipefs
>   Domain = dom.ain
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Trond Myklebust | 1 Feb 2006 22:41
Picon
Picon

Re: Debian/Sarge vs NetApp, idmap problem

On Wed, 2006-02-01 at 21:07 +0000, Ronan Mullally wrote:

>   [General]
> 
>   Verbosity = 0
>   Pipefs-Directory = /var/lib/nfs/rpc_pipefs
>   Domain = dom.ain
<snip>
>   nfs.v4.id.domain             efs.edu.ie

These two don't match. As I said in my earlier mail, they _must_ match
up in order for NFS idmapping to work.

Cheers,
  Trond
Permalink | Reply | 0 comments |

Gmane