View previous topic :: View next topic |
Author |
Message |
chris.c.hogan Apprentice
Joined: 02 Oct 2005 Posts: 189
|
Posted: Mon Oct 03, 2011 2:53 pm Post subject: nfs.idmap missing? |
|
|
I thought I'd try out the new kernel option: Use the new idmapper upcall routine.
I must admit, I'm not sure what this changes from just running rpc.idmapd. But trying out new features is how I learn...
The documentation says to modify /etc/request-key.conf with the following:
Code: |
create id_resolver * * /usr/sbin/nfs.idmap %k %d 600
|
However, nfs.idmap does not exist on my system. Does anyone know which package/version provides it? Is this maybe part of NFS4.1?
I have the following packages installed:
Code: |
[ebuild R ~] net-libs/libnfsidmap-0.24 USE="ldap -static-libs" 0 kB
[ebuild R ] sys-apps/keyutils-1.2-r2 0 kB
[ebuild R ~] net-fs/nfs-utils-1.2.4 USE="caps ipv6 kerberos nfsidmap nfsv3 nfsv4 tcpd -nfsv41" 0 kB
|
Thanks for any information. |
|
Back to top |
|
|
LinuxTom l33t
Joined: 26 Mar 2006 Posts: 798
|
Posted: Thu Feb 23, 2012 7:16 am Post subject: |
|
|
Code: | ~# equery f nfs-utils | grep idmap
/etc/init.d/rpc.idmapd
/usr/sbin/nfsidmap
/usr/sbin/rpc.idmapd
/usr/share/man/man8/idmapd.8.bz2
/usr/share/man/man8/nfsidmap.8.bz2
/usr/share/man/man8/rpc.idmapd.8.bz2 |
Did you get it to run? I despair. See here and here. |
|
Back to top |
|
|
ojbyer n00b
Joined: 07 Sep 2005 Posts: 41
|
Posted: Sun Apr 22, 2012 11:03 pm Post subject: Re: nfs.idmap missing? |
|
|
chris.c.hogan wrote: | The documentation says to modify /etc/request-key.conf with the following:
Code: |
create id_resolver * * /usr/sbin/nfs.idmap %k %d 600
|
However, nfs.idmap does not exist on my system. Does anyone know which package/version provides it? Is this maybe part of NFS4.1? | The kernel documentation is a lie designed to trick you. The correct line is: Code: |
create id_resolver * * /usr/sbin/nfsidmap %k %d 600
| With this you will no longer need to start /etc/init.d/rpc.idmapd, however the nfsmount script uses black magic to scan /etc/fstab and will force rpc.idmapd into the dependencies anyway if it sees an nfs4 filesystem there so if you want to stop that you'll have to resort to surgery on the init script. |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3525
|
Posted: Mon Apr 23, 2012 12:57 pm Post subject: |
|
|
Very interesting to see this thread....
I noticed the new kernel option for the idmap upcall recently, and cross-checked it against the newer version of nfs-utils. This looks like a bit of a pain to me, because as far as I can tell, you have to upgrade the kernel config AND nfs-utils with the right USE flag at the same time. At that point, it looks to me as if you can't boot any older kernel that doesn't have the new upcall configured. It's all or nothing.
They both have to be in sync, or no working NFS. Or at least that's my impression.
Is this correct?
Does changing to the new idmap upcall make any improvement?
It sounds as if ojbyer has completed the process, and is running correctly. True? Anyone else? _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
ojbyer n00b
Joined: 07 Sep 2005 Posts: 41
|
Posted: Mon Apr 23, 2012 1:42 pm Post subject: |
|
|
It's ok to have both rpc.idmapd running and still use the new upcall routine. In fact, the kernel option has been removed and starting with 3.4 kernels onward it is supposed to switch between the two methods automagically: https://github.com/torvalds/linux/commit/e6499c6f4b5f56a16f8b8ef60529c1da28b13aea
The only reason to remove rpc.idmapd from your init scripts is if you never plan on running an older kernel that does not have the new upcall routine configured. |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3525
|
Posted: Mon Apr 23, 2012 1:57 pm Post subject: |
|
|
I like this - it's a better way to do it. I think I'll just sit on my hands until I move a system to 3.4, then try the new nfs-utils with the right USE flags. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3525
|
Posted: Sun Apr 29, 2012 7:52 pm Post subject: |
|
|
Just did 3.4 this afternoon, and it still has that config item. Haven't gotten around to fiddling with nfs-utils yet. I think I'll get nfs-utils rebuilt with the new USE flag, keep rpc.idmapd running, and then try the new option. That seems to be about the safest way, to me. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
Tinitus Veteran
Joined: 20 Sep 2004 Posts: 1754
|
Posted: Mon Feb 25, 2013 8:22 pm Post subject: |
|
|
Hello,
is your nfs idmap working? If yes can you please post your config? Here it will not work. |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3525
|
Posted: Tue Feb 26, 2013 1:11 am Post subject: |
|
|
To be honest, I completely forgot about this thread. I've never switched to nor enabled the new method - I'm using nfsidmap the same way I have for years, and have made no changes to/for it. (and it's still working the same) I must also add that my first exposure to a networked filesystem was AFS at work. I've always kept my /etc/passwd files "harmonized" across all of my machines, at least for the userids with a home directory that need nfs. My impression is that that bypasses much of the need for nfsidmap, though I do know that when it's not running, nothing works and the IDs all map to some big and incorrect number. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
|