Hello,
Found another problem related to idmapping, I think. One of our users
reported chgrp had stopped working (under 3.4.44, coming from 3.2.11).
I reproduced it under krb5i (I can send the cap if necessary). The
SETATTR call is failing because it is not using the domain as set in
idmapd.conf, but the domain of the host instead.
So, for example, our domain is csupomona.edu. Trying to run "chgrp
csupomona testfile" should set the group to [email protected],
but the NFS layer is sending [email protected] (the subdomain
of the host).
The idmapper seems to know what's going on, as the -vvv output produces:
nfsidmap[3598]: key: 0x3df841e type: group value: 17730 timeout 600
nfsidmap[3598]: libnfsidmap: using domain: csupomona.edu
nfsidmap[3598]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch
Am I missing some simple host configuration or is this a deeper issue?
Hi Brian,
I'm sorry it took so long to reply to you, but you haven't been forgotten! I've set up kerberos using freeipa on my own test system but I haven't been able to reproduce the bug you're seeing. I had it working by using my kerberos domain set in /etc/idmap.conf and I saw the new domain go over the wire when I changed it in idmap.conf. Do I need to do anything more to mimic your setup?
- Bryan
On 07/18/2013 08:41 PM, Brian De Wolf wrote:
> Hello,
>
> Found another problem related to idmapping, I think. One of our users
> reported chgrp had stopped working (under 3.4.44, coming from 3.2.11).
> I reproduced it under krb5i (I can send the cap if necessary). The
> SETATTR call is failing because it is not using the domain as set in
> idmapd.conf, but the domain of the host instead.
>
> So, for example, our domain is csupomona.edu. Trying to run "chgrp
> csupomona testfile" should set the group to [email protected],
> but the NFS layer is sending [email protected] (the subdomain
> of the host).
>
> The idmapper seems to know what's going on, as the -vvv output produces:
>
> nfsidmap[3598]: key: 0x3df841e type: group value: 17730 timeout 600
> nfsidmap[3598]: libnfsidmap: using domain: csupomona.edu
> nfsidmap[3598]: libnfsidmap: loaded plugin /usr/lib64/libnfsidmap/nsswitch.so for method nsswitch
>
> Am I missing some simple host configuration or is this a deeper issue?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Thu, 15 Aug 2013 10:25:55 -0700
Bryan Schumaker <[email protected]> wrote:
> Have you made sure to reboot or restart idmapd after making changes
> to /etc/idmap.conf? The only time I've been able to reproduce this
> is when the config file has been changed but not reloaded.
>
Well, I finally dove into libnfsidmap and nfs-utils and tracked it down
to a bug in nfs-utils. Sorry, I should have said we were still on
nfs-utils-1.2.6, which seems to be pretty old by now. This looks like
the commit that fixed it:
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=fd27c638898010438d404cd17120729ef1d680e2
This change is in 1.2.7 and, after upgrading to it on my test box,
chgrp works once again. Sorry for the noise, I should have tried
upgrading nfs-utils first (at least I know a lot about the new idmapper
now!).
Thanks for the help,
Brian
On 08/06/2013 10:53 PM, Brian De Wolf wrote:
> On Tue, 6 Aug 2013 13:07:49 -0700
> Bryan Schumaker <[email protected]> wrote:
>
>> Hi Brian,
>>
>> I'm sorry it took so long to reply to you, but you haven't been
>> forgotten! I've set up kerberos using freeipa on my own test system
>> but I haven't been able to reproduce the bug you're seeing. I had it
>> working by using my kerberos domain set in /etc/idmap.conf and I saw
>> the new domain go over the wire when I changed it in idmap.conf. Do
>> I need to do anything more to mimic your setup?
>>
>
> Thanks for responding! It seems like DNS might be where the wrong
> kerberos domain is coming from. Is your test client in the same domain
> as your kerberos realm? My clients aren't, and the subdomain they're
> in is what is sent in the NFS requests.
>
> I was able to test this by preferring files for hosts in nsswitch.conf
> and overriding the host's name in /etc/hosts. Normally the host is
> under unx.csupomona.edu. Moving the host to csupomona.edu in hosts
> (and rebooting) causes chgrp to start working. When I revert the
> nsswitch and hosts changes chgrp keeps working until another reboot.
>
> I hope this helps you reproduce this issue. Let me know if there is
> any other information you need.
>
Have you made sure to reboot or restart idmapd after making changes to /etc/idmap.conf? The only time I've been able to reproduce this is when the config file has been changed but not reloaded.
Bryan
On Tue, 6 Aug 2013 13:07:49 -0700
Bryan Schumaker <[email protected]> wrote:
> Hi Brian,
>
> I'm sorry it took so long to reply to you, but you haven't been
> forgotten! I've set up kerberos using freeipa on my own test system
> but I haven't been able to reproduce the bug you're seeing. I had it
> working by using my kerberos domain set in /etc/idmap.conf and I saw
> the new domain go over the wire when I changed it in idmap.conf. Do
> I need to do anything more to mimic your setup?
>
Thanks for responding! It seems like DNS might be where the wrong
kerberos domain is coming from. Is your test client in the same domain
as your kerberos realm? My clients aren't, and the subdomain they're
in is what is sent in the NFS requests.
I was able to test this by preferring files for hosts in nsswitch.conf
and overriding the host's name in /etc/hosts. Normally the host is
under unx.csupomona.edu. Moving the host to csupomona.edu in hosts
(and rebooting) causes chgrp to start working. When I revert the
nsswitch and hosts changes chgrp keeps working until another reboot.
I hope this helps you reproduce this issue. Let me know if there is
any other information you need.