Le 13/05/2010 23:13, Guillaume Rousse a écrit : > Le 13/05/2010 14:55, Kevin Coffman a écrit : >> On Thu, May 13, 2010 at 5:09 AM, Guillaume Rousse >> <Guillaume.Rousse@xxxxxxxx> wrote: >>> Le 13/05/2010 01:21, Kevin Coffman a écrit : >>>> On Wed, May 12, 2010 at 5:37 PM, Guillaume Rousse >>>> <Guillaume.Rousse@xxxxxxxx> wrote: >>>>> Le 05/05/2010 23:18, Guillaume Rousse a écrit : >>>>>> I'm attaching network capture, even I can't figure additional >>>>>> information from it by myself. >>>>> Reading https://bugzilla.redhat.com/show_bug.cgi?id=562807, I rebuild >>>>> libtirpc with patch applied and -DDEBUG. Unfortunatly, it doesn't bring >>>>> additional information about the server-side failure :( >>>> >>>> It looks to me like fflush(), called in qword_eol(), may be returning >>>> the number of bytes flushed (95) rather than zero for success? I >>>> don't immediately see any changes that would cause this. But I >>>> haven't looked extensively... >>> Not necessarily a change: I never used a kerberized server sofar, only >>> clients. >> >> Well, I've not seen that issue before, so I assumed it was a change. >> I looked back a bit, but didn't see: what versions of nfs-utils and >> kernel are on the server? > The same on both sides: kernel 2.6.33.3 + nfs-utils 1.2.2 Hello. I finally managed to understand the issue: I also need rpc.svcgssd _and_ rpc.gssd on server side, whereas I thought rpc.gssd was needed on client side only (http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos). Is this expected behaviour ? -- BOFH excuse #255: Standing room only on the bus.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
