I'm aware of the design document, but I was more interested in someOn Mon, Jul 14, 2014 at 09:58:11PM +0300, Noam Meltzer wrote:
> 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
> > 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]
> > nk --------------------
> )>
> > 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)
user-facing documentation. Something we could give to the admins to tell
them what are the benefits and how to leverage them.
>OK, thanks, that's very helpful, but how/when does the kernel receive
> 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.
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..
Thank you, I will test using the program so far.
> 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
np, I can test with your program. Thanks again.
>
>
> 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 ...)