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

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.

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.

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

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

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.

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

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