J. Bruce Fields | 1 Sep 19:30 2007

linux-2.6.23-rc5-CITI_NFS4_ALL-1

http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/2.6.23-rc5-1/linux-2.6.23-rc5-CITI_NFS4_ALL-1.diff

Changes since 2.6.23-rc3-CITI_NFS4_ALL-1
	- update to 2.6.23-rc5 and Trond's latest
	- support for gss callbacks on server and client (also requires
	  nfs-utils patches)
	- patch from David Gilbert adding source address to sunrpc svc
	  errors
Simon Wilkinson | 2 Sep 12:18 2007
Picon
Picon

Re: conflict between heimdal and umich gssapi library and their consequences


On 1 Sep 2007, at 18:07, Russ Allbery wrote:

>
> The UMich library
> adds nothing so far as I know other than the ability to dynamically  
> chose
> Kerberos implementations, which given the problems it's causing  
> doesn't
> strike me as worth it.

Historically, the UMich library has caused no end of grief. When I  
ended up having to deal with it, it didn't implement all of the  
GSSAPI functions, and would call exit() if it's configuration file  
was missing or corrupt. Both Firefox and Thunderbird now check to see  
which GSSAPI library they have dynamically loaded, and disable GSSAPI  
functionality if it's the UMich one.

Cheers,

Simon.
Kevin Coffman | 3 Sep 00:57 2007
Picon

Re: conflict between heimdal and umich gssapi library and their consequences

On 9/1/07, Russ Allbery <rra <at> stanford.edu> wrote:
>
> I'm fairly sure that for right now Debian is just living with the problem
> and conflicting the libraries.  That makes Heimdal almost unusable in
> Debian since the UMich GSS-API indirection layer gets pulled in by the
> NFSv4 support, which is part of standard.
>
> I'm still of the opinion that UMich was at fault here and they need to
> rename their GSS-API library to something else.  Heimdal was using that
> library name first, and regardless of how much more "generic" they think
> their indirection layer is, taking a shared library name that's already in
> use is frankly rather rude.  Picking a different SONAME version to start
> with clearly isn't sufficient, as we now see.

I regret any inconvenience our libgssapi library has caused.  We used
the obvious name and had no malicious intent.

I will rename our library to libgssglue which will require a change in
librpcsecgss and will require nfs-utils to be reconfigured and
recompiled (no source changes required).  I will put out new versions
on Tuesday.

K.C.
Russ Allbery | 3 Sep 04:09 2007
Picon

Re: conflict between heimdal and umich gssapi library and their consequences

"Kevin Coffman" <kwc <at> citi.umich.edu> writes:
> On 9/1/07, Russ Allbery <rra <at> stanford.edu> wrote:

>> I'm fairly sure that for right now Debian is just living with the
>> problem and conflicting the libraries.  That makes Heimdal almost
>> unusable in Debian since the UMich GSS-API indirection layer gets
>> pulled in by the NFSv4 support, which is part of standard.

>> I'm still of the opinion that UMich was at fault here and they need to
>> rename their GSS-API library to something else.  Heimdal was using that
>> library name first, and regardless of how much more "generic" they
>> think their indirection layer is, taking a shared library name that's
>> already in use is frankly rather rude.  Picking a different SONAME
>> version to start with clearly isn't sufficient, as we now see.

> I regret any inconvenience our libgssapi library has caused.  We used
> the obvious name and had no malicious intent.

Since I'm one of the people who have been particularly vocal in
complaining here, let me say publicly that I never thought there was any
malicious intent here at all, or anything other than an unfortunate
choice.  The name *is* an obvious one to use, and the Heimdal library had
a different SONAME originally, so they didn't conflict to start with.

Dealing with multiple libraries that implement the same API is difficult.
To some extent, although this is water way under the bridge at this point,
I have the same complaint about whichever was second between MIT Kerberos
and Heimdal (I think Heimdal, but I'm not positive and don't want to
assume) and the naming of libkrb5.  It would be nice if there were a
libkrb5_mit and libkrb5_heimdal or the like, although in that case at
(Continue reading)

Aníbal Monsalve Salazar | 3 Sep 04:31 2007
Picon

Re: conflict between heimdal and umich gssapi library and their consequences

On Sun, Sep 02, 2007 at 06:57:24PM -0400, Kevin Coffman wrote:
>I will rename our library to libgssglue which will require a change in
>librpcsecgss and will require nfs-utils to be reconfigured and
>recompiled (no source changes required).  I will put out new versions
>on Tuesday.

I'll make the changes in debian.

Thank you very much.

Best Regards,

Aníbal Monsalve Salazar
--

-- 
http://v7w.com/anibal
_______________________________________________
NFSv4 mailing list
NFSv4 <at> linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
J. Bruce Fields | 3 Sep 05:40 2007

Re: conflict between heimdal and umich gssapi library and their consequences

On Sun, Sep 02, 2007 at 06:57:24PM -0400, Kevin Coffman wrote:
> On 9/1/07, Russ Allbery <rra <at> stanford.edu> wrote:
> >
> > I'm fairly sure that for right now Debian is just living with the problem
> > and conflicting the libraries.  That makes Heimdal almost unusable in
> > Debian since the UMich GSS-API indirection layer gets pulled in by the
> > NFSv4 support, which is part of standard.
> >
> > I'm still of the opinion that UMich was at fault here and they need to
> > rename their GSS-API library to something else.  Heimdal was using that
> > library name first, and regardless of how much more "generic" they think
> > their indirection layer is, taking a shared library name that's already in
> > use is frankly rather rude.  Picking a different SONAME version to start
> > with clearly isn't sufficient, as we now see.
> 
> I regret any inconvenience our libgssapi library has caused.  We used
> the obvious name and had no malicious intent.

I think this was my fault originally, so Kevin shouldn't take the blame.

All that code originally lived in nfs-utils and was statically linked
against rpc.gssd/svcgssd.  Probably it should have stayed there--nobody
else is likely to use it for now anyway....

--b.
Guillaume Rousse | 3 Sep 09:52 2007
Picon
Picon

Re: conflict between heimdal and umich gssapi library and their consequences

Russ Allbery a écrit :
>> I will rename our library to libgssglue which will require a change in
>> librpcsecgss and will require nfs-utils to be reconfigured and
>> recompiled (no source changes required).  I will put out new versions on
>> Tuesday.
> 
> Thank you very much for this.  I think this is the right solution in the
> long run.
Many thanks also, it saves us a lot of trouble.
--

-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62
Dimitri Puzin | 3 Sep 16:09 2007
Picon

Re: another strange problem with current -rc4 kernel

Trond Myklebust schrieb:
> On Thu, 2007-08-30 at 14:42 +0200, Dimitri Puzin wrote:
>> Hi all,
>>
>> the OOPS I wrote about recently seems to be fixed after applying
>> http://client.linux-nfs.org/Linux-2.6.x/2.6.22/linux-2.6.22-010-fix_nfs_reval_fsid.dif
>> to the 2.6.22.x kernel as well as with current -rc4 without additional
>> patching (Thanks Trond :).
>>
>> Another subtle thing appears with the current -rc kernel though. After a
>> while (couple of hours) the keyboard stops responding. It only reacts to
>> sysrq, no other input. Mouse/touchpad however works, as well as ssh and
>> other services. The machine can't be rebooted, it stops reacting after
>> sending KILL to all processes. The effect appears only when some (at
>> least one) nfs4 shares are mounted. I've applied the current patchset
>> from
>> http://client.linux-nfs.org/Linux-2.6.x/2.6.23-rc3/linux-2.6.23-NFS_ALL.dif
>> but that doesn't fix the problem. If no nfs4 shares are mounted, the
>> system runs without problems for days.
>>
>> Now I am not sure how to debug this. The machines don't throw any
>> OOPSes/BUGs. I can reproduce it here on all systems, there is an x86 as
>> well as x86_64 and PPC box I tested so far showing the same behavior.
>>
>> Any ideas/suggestions?
> 
> Sounds like the problem that was fixed by this patch:
> 
>   http://client.linux-nfs.org/Linux-2.6.x/2.6.23-rc4/linux-2.6.23-001-fix_cancel_work_hang.dif
This fixes it, thanks. Now I am applying the last complete diff to all
(Continue reading)

Gerald Macinenti | 3 Sep 16:53 2007
Picon

Re: NFSV4 + Kerberos: server not responding

J. Bruce Fields wrote:
> On Wed, Aug 29, 2007 at 06:05:16PM +0200, Gerald Macinenti wrote:
>> I've got two problems with my NFS4 server:
>> - sometimes exports can't be mounted from any clients
>> - sometimes some clients can mount and see the exported files tree but 
>> cannot open files
>>
>> In the first case, restarting NFS on the server solves the problem, but in 
>> the second one, the only solution I found is to restart the client host.
>>
>> The interesting logs on the server are:
>>
>> Aug 29 17:50:09 server_name kernel: nfs4_cb: server /server_ip AUTH_GSS 1 
>> not responding, timed out
>> Aug 29 17:51:17 server_name kernel: nfs4_cb: server /server_ip AUTH_GSS 
>> 1� not responding, timed out
>> Aug 29 17:52:24 server_name kernel: nfs4_cb: server /server_ip AUTH_GSS 
>> 1*v*+w,�.w)�'{%})y(#|""w&�-{'�%y&$|�||{~|||}z 
>> $z"� {"~ u-|5t4-|!�x$}.u9�+x)�+y!�$|#~"{ �z"!z � 
>> {~{}| y!}|}"z!%w*}*w,~&{} x%}&w)|-z(�"z{}$ not responding, 
>> timed out
> 
> There have been fixes since 2.6.20 then which should have addressed the
> problem of garbage in the logs.  Could you retest with a more recent
> kernel? (2.6.22 or later?)
Upgrading to 2.6.22 seems to have solved the first problem, I don't have 
to restart the nfs service anymore, thank you
> 
> The other problems I'm not sure of the cause.
unfortunately this second problem is still not solved, I'm looking to 
(Continue reading)

J. Bruce Fields | 3 Sep 17:08 2007

Re: NFSV4 + Kerberos: server not responding

On Mon, Sep 03, 2007 at 04:53:23PM +0200, Gerald Macinenti wrote:
> J. Bruce Fields wrote:
>> There have been fixes since 2.6.20 then which should have addressed the
>> problem of garbage in the logs.  Could you retest with a more recent
>> kernel? (2.6.22 or later?)
> Upgrading to 2.6.22 seems to have solved the first problem, I don't have to 
> restart the nfs service anymore, thank you

OK, thanks.

>> The other problems I'm not sure of the cause.
> unfortunately this second problem is still not solved, I'm looking to know 
> how I could debug it...

So, the second problem was:

>>> - sometimes some clients can mount and see the exported files tree but 
>>> cannot open files

Could you summarize the details?  What code is the client running?  What
happens when you try to open files?  (Is there an error, or does the
open call hang?)  Can you tell anything about what situations it happens
in?

--b.

Gmane