On Mon, Jul 14, 2014 at 09:58:11PM +0300, Noam Meltzer wrote:
On Mon, Jul 14, 2014 at 7:21 PM, Jakub Hrozek
<jhrozek(a)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
> is
>
> 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
> sss_nfs
>
> My idmapd.conf file looks quite simple:
> --------------------
> [General]
> Verbosity = 2
> Domain =
ipa.example.com
>
> [Mapping]
> Nobody-User = nfsnobody
> Nobody-Group = nfsnobody
>
> [Translation]
> Method = sss_nfs
>
> [Static]
>
> [UMICH_SCHEMA]
> --------------------
>
> 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)
I'm aware of the design document, but I was more interested in some
user-facing documentation. Something we could give to the admins to tell
them what are the benefits and how to leverage them.
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.
OK, thanks, that's very helpful, but how/when does the kernel receive
the event ? How can I trigger that even as admin or a user using NFS
client+server ? For instance, if you run "ls -l", is there anything more
than the id->name conversion using getpwuid() ? I realize these might be
basic questions, so feel free to point me to docs..
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
Thank you, I will test using the program so far.
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 ...)
np, I can test with your program. Thanks again.