On Mon, Jul 14, 2014 at 7:21 PM, Jakub Hrozek <jhrozek@redhat.com> wrote:
On Fri, Jun 27, 2014 at 09:44:34AM +0300, Noam Meltzer wrote:
> Follow patches are the code implementing design document:
> https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin
> Changes compared to v2 of this patch:
>  * rebase over rev. 8ca18752 (current master)
>  * remove man pages from the patch (will be sent separately)
>  * add new contact details for plugin author
>  * code style
>  * remove sss_nfs_make_request() wrapper
>  * fix typo in reply_to_name(): REPLY_ID_OFFSET -> REPLY_NAME_OFFSET

Thanks for these changes! The patches look good with one nitpick, which
I can fix locally before pushing and one packaging question. I'll ask
those inline when replying to the patches themselves.

But more importantly, I have a question on testing the patches. I admit
my NFS internals knowledge is quite lacking, so maybe these are basic
questions..how exactly do I make sure the plugin mapping functions are
called? I tried attaching gdb to rpc.idmapd and doing various operations
to the file (ls, echo "foo" >> file) etc but still no luck. Disabling
the sss nsswitch plugin just yields UIDs and GIDs on the client (which

For my test, I configured a server and a client. I can mount the shares
just fine, I see I'm using NFSv4 in the mount(8) output. I can see the
sss plugin was loaded, because journalctl -u nfs-idmap.service says:
Jul 14 12:01:21 master.ipa.example.com rpc.idmapd[24320]: rpc.idmapd:
sss_nfs_init: use memcache: 1
Jul 14 12:01:21 master.ipa.example.com rpc.idmapd[24320]: rpc.idmapd:
libnfsidmap: loaded plugin /lib64/libnfsidmap/sss_nfs.so for method

My idmapd.conf file looks quite simple:
Verbosity = 2
Domain = ipa.example.com

Nobody-User = nfsnobody
Nobody-Group = nfsnobody

Method = sss_nfs



I guess I could also ask -- where does the rpc.idmapd daemon hook into
the system? When exactly are the translation functions called?

The idmapd.conf looks good (assuming that your LDAP domain really is ipa.example.com).

Regarding how rpc.idmapd operation:
1. There's the feature wiki: https://fedorahosted.org/sssd/wiki/DesignDocs/rpc.idmapd%20plugin
I'm not sure that it answers your question though. (so I'll make sure to update it following this email thread)

2. rpc.idmapd listens for events (queries) from the kernel over a named pipe. once such an event arrives, rpc.idmapd will start the mapping process using libnfsidmap.
libnfsidmap on its turn will dlopen(3) the relevant plugin (sss_nfs in our case) and call the relevant functions from 'struct trans_func'.

How to test:
libnfsidmap.git comes with a small C code named "libtest.c" which allows you to directly test the various function from 'struct trans_func'.
I modified this code a bit to match our needs (and attached to this email).
compile/link with:
gcc -o libtest libtest.c  -lnfsidmap

run like this:
$ ./libtest noam@localdomain 0 users@localdomain 101

expected output:
input: user=noam@localdomain uid=0 group=users@localdomain gid=101
nfs4_name_to_uid: username noam@localdomain has uid 1000
nfs4_name_to_gid: username users@localdomain has gid 100
nfs4_uid_to_name: uid 0 has name root@localdomain
nfs4_gid_to_name: gid 101 has name libuuid@localdomain

Unfortunately, I don't have an LDAP environment at the moment to test it myself. So what you see here is the result of the default idmapd.conf running with the "nss" plugin (going to /etc/passwd ...)


Thank you for your help.
sssd-devel mailing list