headers
Steve Dickson | 3 Nov 2008 14:51
Picon
Favicon

Re: [PATCH]:

J. Bruce Fields wrote:
> On Fri, Oct 24, 2008 at 01:31:57PM -0400, Steve Dickson wrote:
>> [As requested, here is the debugging portion broken out of
>> the 6th patch in the "Dynamic Pseudo Root" patch series.]
>>
>> Added dprintk to the top and bottom of both expkey_parse() and
>> svc_export_parse(). The top dprintks shows what rpc.mountd gave
>> to the routines to parse. These match up well with the current
>> debugging statements in the rpc.mount routines nfsd_export()
>> and nfsd_fh(). 
>>
>> The bottom two dprintks show when either routine error out. This
>> was very useful in debugging why exports failed or hang.
> 
> 
> Did you try experiment with strace very much before trying this?
> Something like
> 
> 	strace -e read,write -s 1000 -p `pidof rpc.gssd`
> 
> will show the contents of the upcalls and downcalls and any returned
> error, so I'm not convinced that dprintk's of the upcall/downcall data
> are necessary.
> 
No, I have not, but it does look interesting and I'll give it try. 

But I also think its important to have one united debugging interface
that gives meaningful information when its turned on. 

For example, today you turn on export debugging with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joerg Ullmann | 4 Nov 2008 13:44
Picon

nfs4 with kerberos, fails: "access denied by server"

Hello,

I try to setup NFSv4 with Kerberos. I use this howto
https://help.ubuntu.com/community/NFSv4Howto and it works without
Kerberos but not with it.

on the client:

I try to mount with this: "mount -t nfs4 ntws28:/ /mnt" and I get after
waiting for 3 sec: "mount.nfs4: access denied by server while mounting
ntws28:/" - always.

I can successfull call something like "kinit testuser" "kinit -f
testuser", "kinit -k nfs/ntws29.mmm.local" or "kinit -k
host/ntws29.mmm.local". klist say's alwas nice looking things like:

***
root <at> ntws29:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/ntws29.mmm.local <at> MMM.LOCAL

Valid starting     Expires            Service principal
11/04/08 13:07:15  11/04/08 23:07:15  krbtgt/MMM.LOCAL <at> MMM.LOCAL
         renew until 11/05/08 13:07:18

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
***

I have not idea whats happen but I think I do something wrong because
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kevin Coffman | 4 Nov 2008 18:00
Picon
Gravatar

Re: nfs4 with kerberos, fails: "access denied by server"

Hello

On Tue, Nov 4, 2008 at 7:44 AM, Joerg Ullmann <ullmann <at> nt.upb.de> wrote:
> Hello,
>
> I try to setup NFSv4 with Kerberos. I use this howto
> https://help.ubuntu.com/community/NFSv4Howto and it works without
> Kerberos but not with it.
>
> on the client:
>
> I try to mount with this: "mount -t nfs4 ntws28:/ /mnt" and I get after
> waiting for 3 sec: "mount.nfs4: access denied by server while mounting
> ntws28:/" - always.
>
> ***
> /var/log/krb5/kdc.log
>
> Nov 04 13:29:14 ntws28 krb5kdc[2237](info): listening on fd 7: udp
> 131.234.222.228.88
> Nov 04 13:29:14 ntws28 krb5kdc[2237](info): listening on fd 8: udp
> 131.234.222.228.750
> krb5kdc: Cannot assign requested address - Cannot bind server socket to
> port 88 address fe80::20c:29ff:fe99:ecce%eth0
> Nov 04 13:29:14 ntws28 krb5kdc[2237](info): set up 2 sockets
> Nov 04 13:29:14 ntws28 krb5kdc[2238](info): commencing operation
> Nov 04 13:34:14 ntws28 krb5kdc[2238](info): AS_REQ (1 etypes {1})
> 131.234.222.229: ISSUE: authtime 1225802054, etypes {rep=1 tkt=18
> ses=1}, host/ntws29.mmm.local <at> MMM.LOCAL for krbtgt/MMM.LOCAL <at> MMM.LOCAL
(Continue reading)

Permalink | Reply | 2 comments |
headers
michael65000 | 5 Nov 2008 07:21
Picon

Re: Machine Credentials Not Acquired at Boot

michael65000 wrote:
> Kevin Coffman wrote:
>   
>> On Mon, Oct 27, 2008 at 12:56 AM, michael65000 <michael65000 <at> cox.net> wrote:
>>   
>>     
>>> I am working with Ubuntu Hardy 8.04, kernel 2.6.24-19 generic on a
>>> dual-core machine. I am trying to set up an all-in-one server for a
>>> small network.
>>>
>>> Let's call the server machine "Big Red" and the test client machine
>>> "Castoff".
>>>
>>> My problem is that I have a configuration that works for NFSv4 with MIT
>>> Kerberos, but only with a manual "mount" command on "BigRed" after I
>>> boot up.
>>>
>>> To my limited view, the problem appears to be that the NFS server,
>>> (which is physically on the same machine, BigRed, as the Kerberos KDC),
>>> does not obtain a machine credential ticket for kerberos principal
>>> nfs/BigRed from the KDC when starting up.
>>>
>>> When the client, Castoff, tries to connect to BigRed, it obtains a
>>> ticket from the KDC for principal nfs/Castoff, but cannot connect to the
>>> NFS server on BigRed because BigRed cannot identify itself without a
>>> ticket.
>>>
>>> To work around this, I have to log in and do a manual self-referential
>>> "mount" command on BigRed, which forces the NFS client on BigRed to
>>> obtain a ticket for principal nfs/BigRed so it can talk to the NFS
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alexander Piavka | 5 Nov 2008 13:27
Picon
Picon
Favicon

rpc nfs4 quota is not shown then nfs4 pseudo filesystem is mounted


  Hi,

  If have the following on nfs4 server:

raid-srv ~ # cat /etc/exports
/freespace       <at> hosts(ro,fsid=0,root_squash,no_subtree_check,sync)
/freespace/staff    <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)
/freespace/stud     <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)
/freespace/msc      <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)
/freespace/phd      <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)
/freespace/postdoc  <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)
/freespace/others   <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)
/freespace/segel    <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)
/freespace/projects      <at> hosts(rw,nohide,no_root_squash,no_subtree_check,sync,mp)

  Then i mount the pseudo filesystem at /freespace everything works fine, 
except that no quota is reprted for real filesystems under /freespace

amdsrv1 ~ # mount -t nfs4
raid-srv:/ on /freespace type nfs4 (rw,nosuid,ac,proto=tcp,hard,intr,bg,rsize=32768,wsize=32768,addr=132.72.41.65)
amdsrv1 ~ # quota -v -u piavka
Disk quotas for user piavka (uid 1785):
      Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
amdsrv1 ~ #

  Then I mount each file system separately, it works ok.

amdsrv2 ~ # mount -t nfs4
raid-srv:/staff on /freespace/staff type nfs4 (rw,nosuid,ac,proto=tcp,hard,intr,bg,rsize=32768,wsize=32768,addr=132.72.41.65)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joerg Ullmann | 5 Nov 2008 14:49
Picon

Re: nfs4 with kerberos, fails: "access denied by server"

Hello,

thank you very much for your answer!

Kevin Coffman wrote:
> From the client, rpc.gssd should be requesting a TGT (AS_REQ).  Then
> it should use that to get a service ticket (TGS_REQ) for the server,
> nfs/ntw28.mmm.local <at> MMM.LOCAL.  I don't see either of those here.

Maybe the nfs client or mount.nfs4 don't ask for the next part of the 
authentication?

>> [libdefaults]
>>         default_realm = MMM.LOCAL
>>         default_tgs_enctypes = des-cbc-crc
>>         default_tkt_enctypes = des-cbc-crc
> 
> Despite what that Howto says, the previous two lines should not be
> necessary and should not be used.  These lines limit ALL kerberos
> services to using DES.  Limiting the nfs keys to DES while creating
> the keytabs ("ktadd -e des-cbc-crc:normal -k /root/keytab.nfs-client
> nfs/nfs-client.domain") is all that is necessary.  NFS is likely the
> only service on the machine that needs to be limited to DES.

okay, I've delete the two lines.

>> [realms]
>>         MMM.LOCAL = {
>>                 kdc = ntws28
>>                 admin_server = ntws28
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Coffman | 5 Nov 2008 16:07
Picon
Gravatar

Re: nfs4 with kerberos, fails: "access denied by server"

Hello Joerg,
From your symptoms, it appears that the clnt directories are being
created and then destroyed without ever queueing an upcall to create a
context.

I don't recall the reasons this might happen.  You might enable kernel
debugging to see if that provides a hint.  Use one or both of the
following and check syslog messages during the mount.

sudo echo 32767 > /proc/sys/sunrpc/rpc_debug
sudo echo 65535 > /proc/sys/sunrpc/nfs_debug

K.C.

On Wed, Nov 5, 2008 at 8:49 AM, Joerg Ullmann <ullmann <at> nt.upb.de> wrote:
> Hello,
>
> thank you very much for your answer!
>
> Kevin Coffman wrote:
>>
>> From the client, rpc.gssd should be requesting a TGT (AS_REQ).  Then
>> it should use that to get a service ticket (TGS_REQ) for the server,
>> nfs/ntw28.mmm.local <at> MMM.LOCAL.  I don't see either of those here.
>
> Maybe the nfs client or mount.nfs4 don't ask for the next part of the
> authentication?
>
>>> [libdefaults]
>>>        default_realm = MMM.LOCAL
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Coffman | 5 Nov 2008 17:26
Picon
Gravatar

Re: Machine Credentials Not Acquired at Boot

On Wed, Nov 5, 2008 at 1:21 AM, michael65000 <michael65000 <at> cox.net> wrote:
> michael65000 wrote:
>>
>> Kevin Coffman wrote:
>>
>>>
>>> On Mon, Oct 27, 2008 at 12:56 AM, michael65000 <michael65000 <at> cox.net>
>>> wrote:
>>>
>>>>
>>>> I am working with Ubuntu Hardy 8.04, kernel 2.6.24-19 generic on a
>>>> dual-core machine. I am trying to set up an all-in-one server for a
>>>> small network.
>>>>
>>>> Let's call the server machine "Big Red" and the test client machine
>>>> "Castoff".
>>>>
>>>> My problem is that I have a configuration that works for NFSv4 with MIT
>>>> Kerberos, but only with a manual "mount" command on "BigRed" after I
>>>> boot up.
>>>>
>>>> To my limited view, the problem appears to be that the NFS server,
>>>> (which is physically on the same machine, BigRed, as the Kerberos KDC),
>>>> does not obtain a machine credential ticket for kerberos principal
>>>> nfs/BigRed from the KDC when starting up.
>>>>
>>>> When the client, Castoff, tries to connect to BigRed, it obtains a
>>>> ticket from the KDC for principal nfs/Castoff, but cannot connect to the
>>>> NFS server on BigRed because BigRed cannot identify itself without a
>>>> ticket.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike | 9 Nov 2008 20:57
Picon

Re: Machine Credentials Not Acquired at Boot

Kevin Coffman wrote:
Hello Michael, I'm sorry, I should have noticed this before. The client should get a TGT (AS_REQ) from the KDC for principal nfs/Castoff and then use that to get a service ticket (TGS_REQ) from the KDC for the service nfs/BigRed. It presents that service ticket to the server to authenticate itself. The server uses its key in the keytab (the nfs/BigRed key) to validate the incoming request from the client. The server never has to talk to the KDC. However, you are saying that the client is able to mount the server only after the server has mounted itself first, correct? How is the client machine mounting the server? (automount, or manual mount?) I have no idea how doing the self-referential mount on the server changes anything for the client, but I think we should be looking closer at the client, not the server. What messages do you get from gssd on the client when it fails, and
then when it works after the self-referential mount.
K.C.

K.C.,

I think you are right that I have been misinterpreting things. I have found a few errors on the client and increased the verbosity on some things like idmap, and these changes are improving my understanding, but I am still having the same basic problem.

My objective is to boot the server, and then the client, and have the client mount the server automatically during the boot sequence using fstab. Once I get that working, I might move on and try to automount something.

The BigRed server has the line:

/home/exports/family *.pointlist.shp(sec=krb5,rw,async,fsid=0,crossmnt)

in its export file, which I think should export the directory /home/exports/family and all subdirectories as file system 0 to all clients in the pointlist.shp domain. Correct?

The Castoff client has the line:

BigRed.pointlist.shp:/testmetestme /home/testmetestme nfs4 sec=krb5

in its fstab file, which I think should mount the server directory /home/exports/family/testmetestme at client location /home/testmetestme. Correct?

OK, then. Pardon the length, but here is a typical session:

I boot the client, and I see no messages in any of the client logs indicating NFS is doing anything. However, I do see the following message on the server's krb5kdc log:


BigRed krb5kdc[5586](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.1.112: ISSUE: authtime 1226018558, etypes {rep=16 tkt=16 ses=16}, nfs/Castoff.pointlist.shp <at> POINTLIST.SHP for krbtgt/POINTLIST.SHP <at> POINTLIST.SHP


So, then I go to the Castoff client and attempt a manual mount:


sudobuddy <at> Castoff:~$ sudo mount -a -t nfs4
[sudo] password for sudobuddy:
mount.nfs4: access denied while mounting BigRed.pointlist.shp:/testmetestme


The following appears in the logs on the client:


Nov  8 22:31:40 Castoff rpc.idmapd[3703]: New client: 4
Nov  8 22:31:40 Castoff rpc.idmapd[3703]: Opened /var/lib/nfs/rpc_pipefs/nfs/clnt4/idmap
Nov  8 22:31:40 Castoff rpc.idmapd[3703]: New client: 5
Nov  8 22:31:40 Castoff rpc.gssd[3727]: handling krb5 upcall
Nov  8 22:31:40 Castoff rpc.gssd[3727]: Full hostname for 'BigRed.pointlist.shp' is 'BigRed.pointlist.shp'
Nov  8 22:31:40 Castoff rpc.gssd[3727]: Full hostname for 'Castoff.pointlist.shp' is 'Castoff.pointlist.shp'
Nov  8 22:31:40 Castoff rpc.gssd[3727]: Key table entry not found while getting keytab entry for 'root/Castoff.pointlist.shp <at> POINTLIST.SHP'
Nov  8 22:31:40 Castoff rpc.gssd[3727]: Success getting keytab entry for 'nfs/Castoff.pointlist.shp <at> POINTLIST.SHP'
Nov  8 22:31:40 Castoff rpc.gssd[3727]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_POINTLIST.SHP' are good until 1226287005
Nov  8 22:31:40 Castoff rpc.gssd[3727]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_POINTLIST.SHP' are good until 1226287005
Nov  8 22:31:40 Castoff rpc.gssd[3727]: using FILE:/tmp/krb5cc_machine_POINTLIST.SHP as credentials cache for machine creds
Nov  8 22:31:40 Castoff rpc.gssd[3727]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_POINTLIST.SHP
Nov  8 22:31:40 Castoff rpc.gssd[3727]: creating context using fsuid 0 (save_uid 0)
Nov  8 22:31:40 Castoff rpc.gssd[3727]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 22:31:40 Castoff rpc.gssd[3727]: WARNING: Failed while limiting krb5 encryption types for user with uid 0
Nov  8 22:31:40 Castoff rpc.gssd[3727]: WARNING: Failed to create krb5 context for user with uid 0 with credentials cache FILE:/tmp/krb5cc_machine_POINTLIST.SHP for server BigRed.pointlist.shp
Nov  8 22:31:40 Castoff rpc.gssd[3727]: WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server BigRed.pointlist.shp
Nov  8 22:31:40 Castoff rpc.gssd[3727]: doing error downcall
Nov  8 22:31:40 Castoff rpc.gssd[3727]: Failed to write error downcall!
Nov  8 22:31:40 Castoff rpc.idmapd[3703]: Stale client: 5
Nov  8 22:31:40 Castoff rpc.idmapd[3703]: ^I-> closed /var/lib/nfs/rpc_pipefs/nfs/clnt5/idmap
Nov  8 22:31:40 Castoff rpc.gssd[3727]: destroying client clnt5
Nov  8 22:31:40 Castoff rpc.idmapd[3703]: Stale client: 4
Nov  8 22:31:40 Castoff rpc.idmapd[3703]: ^I-> closed /var/lib/nfs/rpc_pipefs/nfs/clnt4/idmap
Nov  8 22:31:40 Castoff rpc.gssd[3727]: destroying client clnt4

Nothing new appears in the logs on the server. 

On the client, I give the following commands:

sudobuddy <at> Castoff:~$ sudo /etc/init.d/portmap restart
sudobuddy <at> Castoff:~$ sudo /etc/init.d/nfs-common restart

followed by:

sudobuddy <at> Castoff:~$ sudo mount -a -t nfs4
sudobuddy <at> Castoff:~$

This time, as you see I do not get the access denied error. So:

sudobuddy <at> Castoff:~$ cd /home
sudobuddy <at> Castoff:/home$ cd testmetestme
bash: cd: testmetestme/: Permission denied
sudobuddy <at> Castoff:/home$

OK. This looks good. The mount has worked, but I cannot look into it because I am currently logged in as sudobuddy and not testmetestme, right?

Let's look at the log for the mount command:
------------------------------------------------------------------------------------------------------------------------------------------------
Nov  8 22:36:04 Castoff rpc.gssd[3727]: WARNING: No credentials cache found while destroying credential cache 'FILE:/tmp/krb5cc_machine_POINTLIST.SHP'
Nov  8 22:36:04 Castoff rpc.gssd[3727]: exiting on signal 15
Nov  8 22:36:04 Castoff rpc.statd[3612]: Caught signal 15, un-registering and exiting.
Nov  8 22:36:05 Castoff rpc.statd[6044]: Version 1.1.2 Starting
Nov  8 22:36:05 Castoff rpc.idmapd[6051]: libnfsidmap: using domain: pointlist.shp
Nov  8 22:36:05 Castoff rpc.idmapd[6051]: libnfsidmap: using translation method: nsswitch
Nov  8 22:36:05 Castoff rpc.idmapd[6052]: Expiration time is 600 seconds.
Nov  8 22:36:05 Castoff rpc.idmapd[6052]: nfsdopenone: Opening /proc/net/rpc/nfs4.nametoid/channel failed: errno 2 (No such file or directory)
Nov  8 22:36:05 Castoff rpc.gssd[6055]: rpcsec_gss: debug level is 3
Nov  8 22:36:06 Castoff rpc.gssd[6056]: WARNING: gssd_obtain_kernel_krb5_info: Unable to open '/var/lib/nfs/rpc_pipefs/krb5_info'. Unable to determine Kerberos encryption types supported by the kernel; using defaults (1,3,2).
Nov  8 22:36:06 Castoff rpc.gssd[6056]: beginning poll
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: New client: 6
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: Opened /var/lib/nfs/rpc_pipefs/nfs/clnt6/idmap
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: New client: 7
Nov  8 22:36:22 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 22:36:22 Castoff rpc.gssd[6056]: Full hostname for 'BigRed.pointlist.shp' is 'BigRed.pointlist.shp'
Nov  8 22:36:22 Castoff rpc.gssd[6056]: Full hostname for 'Castoff.pointlist.shp' is 'Castoff.pointlist.shp'
Nov  8 22:36:22 Castoff rpc.gssd[6056]: Key table entry not found while getting keytab entry for 'root/Castoff.pointlist.shp <at> POINTLIST.SHP'
Nov  8 22:36:22 Castoff rpc.gssd[6056]: Success getting keytab entry for 'nfs/Castoff.pointlist.shp <at> POINTLIST.SHP'
Nov  8 22:36:22 Castoff rpc.gssd[6056]: Successfully obtained machine credentials for principal 'nfs/Castoff.pointlist.shp <at> POINTLIST.SHP' stored in ccache 'FILE:/tmp/krb5cc_machine_POINTLIST.SHP'
Nov  8 22:36:22 Castoff rpc.gssd[6056]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_POINTLIST.SHP' are good until 1226288182
Nov  8 22:36:22 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_machine_POINTLIST.SHP as credentials cache for machine creds
Nov  8 22:36:22 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_POINTLIST.SHP
Nov  8 22:36:22 Castoff rpc.gssd[6056]: creating context using fsuid 0 (save_uid 0)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: creating tcp client for server BigRed.pointlist.shp
Nov  8 22:36:22 Castoff rpc.gssd[6056]: creating context with server nfs <at> BigRed.pointlist.shp
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_create_default()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_create()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: authgss_create: name is 0x8058a28
Nov  8 22:36:22 Castoff rpc.gssd[6056]: authgss_create: gd->name is 0x8059e90
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_refresh()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: struct rpc_gss_sec:
Nov  8 22:36:22 Castoff rpc.gssd[6056]:      mechanism_OID: { 1 2 134 72 134 247 18 1 2 2 }
Nov  8 22:36:22 Castoff rpc.gssd[6056]:      qop: 0
Nov  8 22:36:22 Castoff rpc.gssd[6056]:      service: 1
Nov  8 22:36:22 Castoff rpc.gssd[6056]:      cred: 0x80594e0
Nov  8 22:36:22 Castoff rpc.gssd[6056]:      req_flags: 00000002
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_marshal()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: encode success ((nil):0)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: xdr_rpc_gss_cred: encode success (v 1, proc 1, seq 0, svc 1, ctx (nil):0)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_wrap()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: encode success (0x806acb8:487)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: xdr_rpc_gss_init_args: encode success (token 0x806acb8:487)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_validate()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_unwrap()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: decode success (0x806a798:4)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: decode success (0x8059820:114)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: xdr_rpc_gss_init_res decode success (ctx 0x806a798:4, maj 0, min 0, win 128, token 0x8059820:114)
Nov  8 22:36:22 Castoff rpc.gssd[6056]: authgss_create_default: freeing name 0x8058a28
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_get_private_data()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: DEBUG: serialize_krb5_ctx: lucid version!
Nov  8 22:36:22 Castoff rpc.gssd[6056]: prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
Nov  8 22:36:22 Castoff rpc.gssd[6056]: doing downcall
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_free_private_data()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_destroy()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: in authgss_destroy_context()
Nov  8 22:36:22 Castoff rpc.gssd[6056]: authgss_destroy: freeing name 0x8059e90
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: nss_getpwnam: name '0' domain 'pointlist.shp': resulting localname '(null)'
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: nss_getpwnam: name '0' does not map into domain 'pointlist.shp'
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: Client 6: (user) name "0" -> id "65534"
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: Client 6: (group) name "0" -> id "65534"
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: nss_getpwnam: name '1002' domain 'pointlist.shp': resulting localname '(null)'
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: nss_getpwnam: name '1002' does not map into domain 'pointlist.shp'
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: Client 6: (user) name "1002" -> id "65534"
Nov  8 22:36:22 Castoff rpc.idmapd[6052]: Client 6: (group) name "100" -> id "65534"
Nov  8 22:36:23 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 22:36:23 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 22:36:23 Castoff rpc.gssd[6056]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed while limiting krb5 encryption types for user with uid 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed to create krb5 context for user with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: doing error downcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: Failed to write error downcall!
Nov  8 22:36:23 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 22:36:23 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 22:36:23 Castoff rpc.gssd[6056]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed while limiting krb5 encryption types for user with uid 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed to create krb5 context for user with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: doing error downcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: Failed to write error downcall!
Nov  8 22:36:23 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 22:36:23 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 22:36:23 Castoff rpc.gssd[6056]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed while limiting krb5 encryption types for user with uid 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed to create krb5 context for user with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: doing error downcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: Failed to write error downcall!
Nov  8 22:36:23 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 22:36:23 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 22:36:23 Castoff rpc.gssd[6056]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed while limiting krb5 encryption types for user with uid 1000
Nov  8 22:36:23 Castoff rpc.gssd[6056]: WARNING: Failed to create krb5 context for user with uid 1000 for server BigRed.pointlist.shp
Nov  8 22:36:23 Castoff rpc.gssd[6056]: doing error downcall
Nov  8 22:36:23 Castoff rpc.gssd[6056]: Failed to write error downcall!
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hmmm. Maybe it didn't work. Here is the log for the cd command:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Nov  8 23:09:34 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 23:09:34 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 23:09:34 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 23:09:34 Castoff rpc.gssd[6056]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 23:09:34 Castoff rpc.gssd[6056]: WARNING: Failed while limiting krb5 encryption types for user with uid 1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: WARNING: Failed to create krb5 context for user with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: doing error downcall
Nov  8 23:09:34 Castoff rpc.gssd[6056]: Failed to write error downcall!
Nov  8 23:09:34 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 23:09:34 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 23:09:34 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 23:09:34 Castoff rpc.gssd[6056]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 23:09:34 Castoff rpc.gssd[6056]: WARNING: Failed while limiting krb5 encryption types for user with uid 1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: WARNING: Failed to create krb5 context for user with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: doing error downcall
Nov  8 23:09:34 Castoff rpc.gssd[6056]: Failed to write error downcall!
Nov  8 23:09:34 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 23:09:34 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 23:09:34 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 23:09:34 Castoff rpc.gssd[6056]: ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - No credentials cache found
Nov  8 23:09:34 Castoff rpc.gssd[6056]: WARNING: Failed while limiting krb5 encryption types for user with uid 1000
Nov  8 23:09:34 Castoff rpc.gssd[6056]: WARNING: Failed to create krb5 context for user with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:09:34 Castoff rpc.gssd[6056]: doing error downcall
Nov  8 23:09:34 Castoff rpc.gssd[6056]: Failed to write error downcall!

------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Alright. UID 0 is root. UID 1000 is sudobuddy, and UID 1002 is testmetestme.
sudobuddy and root have no corresponding kerberos principals.
testmetestme does have a kerberos principal.

So, let's try this:

sudobuddy <at> Castoff:/home$ kinit testmetestme
Password for testmetestme <at> MONET.SHP:
sudobuddy <at> Castoff:/home$ cd /testmetestme
sudobuddy <at> Castoff:/home/testmetestme$ ls
Desktop  Documents  Examples  Music  Pictures  Public  Templates  Videos
sudobuddy <at> Castoff:/home/testmetestme$ cd Documents/
sudobuddy <at> Castoff:/home/testmetestme/Documents$ ls
directorymounted  testfile2.doc  testfile.doc  testfile.odt
sudobuddy <at> Castoff:/home/testmetestme/Documents$ ls -l
total 124
-rw-r--r-- 1 nobody nogroup     27 2008-10-26 19:31 directorymounted
-rw-r--r-- 1 nobody nogroup   2310 2008-10-26 19:31 testfile2.doc
-rw-r--r-- 1 nobody nogroup 103936 2008-10-26 19:31 testfile.doc
-rw-r--r-- 1 nobody nogroup   7468 2008-10-26 19:31 testfile.odt
sudobuddy <at> Castoff:/home/testmetestme/Documents$

OK. So the testmetestme directory is mounted, but the ownership and permissions are wrong.

Back to the log:

---------------------------------------------------------------------------------------------------------------------------------------------------

Nov  8 23:11:17 Castoff rpc.gssd[6056]: handling krb5 upcall
Nov  8 23:11:17 Castoff rpc.gssd[6056]: getting credentials for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:11:17 Castoff rpc.gssd[6056]: CC file 'krb5cc_1000' being considered
Nov  8 23:11:17 Castoff rpc.gssd[6056]: CC file 'krb5cc_1000' matches owner check and has mtime of 1226203867
Nov  8 23:11:17 Castoff rpc.gssd[6056]: CC file 'krb5cc_machine_POINTLIST.SHP' being considered
Nov  8 23:11:17 Castoff rpc.gssd[6056]: '/tmp/krb5cc_machine_POINTLIST.SHP' owned by 0, not 1000
Nov  8 23:11:17 Castoff rpc.gssd[6056]: using FILE:/tmp/krb5cc_1000 as credentials cache for client with uid 1000 for server BigRed.pointlist.shp
Nov  8 23:11:17 Castoff rpc.gssd[6056]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1000
Nov  8 23:11:17 Castoff rpc.gssd[6056]: creating context using fsuid 1000 (save_uid 0)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: creating tcp client for server BigRed.pointlist.shp
Nov  8 23:11:17 Castoff rpc.gssd[6056]: creating context with server nfs <at> BigRed.pointlist.shp
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_create_default()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_create()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: authgss_create: name is 0x8058a40
Nov  8 23:11:17 Castoff rpc.gssd[6056]: authgss_create: gd->name is 0x8058138
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_refresh()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: struct rpc_gss_sec:
Nov  8 23:11:17 Castoff rpc.gssd[6056]:      mechanism_OID: { 1 2 134 72 134 247 18 1 2 2 }
Nov  8 23:11:17 Castoff rpc.gssd[6056]:      qop: 0
Nov  8 23:11:17 Castoff rpc.gssd[6056]:      service: 1
Nov  8 23:11:17 Castoff rpc.gssd[6056]:      cred: 0x8059ee8
Nov  8 23:11:17 Castoff rpc.gssd[6056]:      req_flags: 00000002
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_marshal()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: encode success ((nil):0)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: xdr_rpc_gss_cred: encode success (v 1, proc 1, seq 0, svc 1, ctx (nil):0)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_wrap()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: encode success (0x80597e8:490)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: xdr_rpc_gss_init_args: encode success (token 0x80597e8:490)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_validate()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_unwrap()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: decode success (0x8059eb0:4)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: xdr_rpc_gss_buf: decode success (0x8059720:114)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: xdr_rpc_gss_init_res decode success (ctx 0x8059eb0:4, maj 0, min 0, win 128, token 0x8059720:114)
Nov  8 23:11:17 Castoff rpc.gssd[6056]: authgss_create_default: freeing name 0x8058a40
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_get_private_data()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: DEBUG: serialize_krb5_ctx: lucid version!
Nov  8 23:11:17 Castoff rpc.gssd[6056]: prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8
Nov  8 23:11:17 Castoff rpc.gssd[6056]: doing downcall
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_free_private_data()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_destroy()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: in authgss_destroy_context()
Nov  8 23:11:17 Castoff rpc.gssd[6056]: authgss_destroy: freeing name 0x8058138
Nov  8 23:11:17 Castoff rpc.idmapd[6052]: nss_getpwnam: name '1002' domain 'pointlist.shp': resulting localname '(null)'
Nov  8 23:11:17 Castoff rpc.idmapd[6052]: nss_getpwnam: name '1002' does not map into domain 'pointlist.shp'
Nov  8 23:11:17 Castoff rpc.idmapd[6052]: Client 6: (user) name "1002" -> id "65534"
Nov  8 23:11:17 Castoff rpc.idmapd[6052]: Client 6: (group) name "100" -> id "65534"
Nov  8 23:13:16 Castoff rpc.idmapd[6052]: nss_getpwnam: name '0' domain 'pointlist.shp': resulting localname '(null)'
Nov  8 23:13:16 Castoff rpc.idmapd[6052]: nss_getpwnam: name '0' does not map into domain 'pointlist.shp'
Nov  8 23:13:16 Castoff rpc.idmapd[6052]: Client 6: (user) name "0" -> id "65534"
Nov  8 23:13:16 Castoff rpc.idmapd[6052]: Client 6: (group) name "0" -> id "65534"

------------------------------------------------------------------------------------------------------------------------------------------------------------

This is typical. I have done the same basic thing with many minor variations, but this illustrates the essential problems:

1. The mount does not work on boot.
2. The first manual mount does not work.
3. After restarting portmap and nfs-common the mount does work, but,
4. Ownership and permissions are messed up.

I had thought the first items 1 through 3 were somehow due to lack of credentials on the server, but apparently I was wrong.

One more thing:

sudobuddy <at> Castoff:/home/testmetestme/Documents$ getent passwd | grep home
syslog:x:102:103::/home/syslog:/bin/false
klog:x:103:104::/home/klog:/bin/false
sudobuddy:x:1000:1000:Mike,,,:/home/sudobuddy:/bin/bash
ntp:x:113:124::/home/ntp:/bin/false
michael3:x:1001:100:me,,,,:/home/michael3:/bin/bash
testmetestme:x:1002:100:noone,,,,:/home/testmetestme:/bin/bash
ntp:x:112:124:ntp:/home/ntp:/bin/false
sudobuddy <at> Castoff:/home/testmetestme/Documents$

So I am not sure why the error:

Nov  8 23:11:17 Castoff rpc.idmapd[6052]: nss_getpwnam: name '1002' domain 'pointlist.shp': resulting localname '(null)'
Nov  8 23:11:17 Castoff rpc.idmapd[6052]: nss_getpwnam: name '1002' does not map into domain 'pointlist.shp'

keeps showing up.

Thanks,

Michael

_______________________________________________
NFSv4 mailing list
NFSv4 <at> linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
Permalink | Reply | 5 comments |
headers
Steve Dickson | 10 Nov 2008 13:29
Picon
Favicon

[PATCH 0/9] Dynamic Pseudo Root - Release 3

Here is the next set of dynamic pseudo root patches. I believe I've
address every issue that was outstanding. 

The following is just a summary of what has changed since the last release. 
To get an understanding of why these patches are needed and how the code 
works, please read my previous patch introductions in the prior releases.
The easiest way of do that is to doing a search of "Dynamic Pseudo Root" 
on this mailing list.

In this release I've made the following changes:

    * The kernel processes UUIDs before user settable FSIDS which causes
      the FSIDs get ignored when mountd sets both of them. In this release 
      if FSIDs are set, mountd will only give the kernel the FSID. If the 
      FSID is not set, then mountd will send down the UUID. The removes a 
      previous kernel change.

    * Although it took a couple swings of Bruce's clue-bat, I finally realized
      why it was bad to create negative export cache entries. So the kernel patch
      no longer created negative cache entries; instead it checks to ensure
      lookups that result in a negative dentry error out verses sending them
      up to mountd.

    * UUIDs are used to define file systems, not directories in
      file systems. So I had to incorporate inode numbers in the UUID
      mapping to differentiate exported directories that are the
      same file system. 

    * Its not clear as to why three different styles of file handles are  
      supported [FSID, UUIDS, Devices IDs] but they are. So this patch series 
      includes the mapping of device ids of pseudo root directories to device
      ids of exported directories. Note: This code will, most likely, will never 
      be used since both FSIDS and UUIDS are process first in the kernel and mountd
      will always use one or the other. Actually I had to comment a chuck of 
      kernel code  to test this. But, to complete the circle of life I figured 
      it was needed. :-)

Patch summary:
    Patch 1 - Support routines    (did not change)
    Patch 2 - The v4root routines (did not change)
    Patch 3 - Hooks in mountd     (did not change)
    Patch 4 - The mapping of uuids 
    Patch 5 - Either UUID or FSIDS 
    Patch 6 - Always used the real UUID (Bug fix)
    Patch 7 - Use inums in uuid mapping
    Patch 8 - Device id mapping
    Patch 9 - The kernel patch (which did shrink)

Note: all this patches can be found on the 'v4root_rel3' branch
      on my git tree at:
          git://linux-nfs.org/~steved/nfs-utils-exp.git

Comments/Suggestions/Acceptance?

steved.
Permalink | Reply | 10 comments |

Gmane