On 08/27/2018 11:03 AM, Jakub Hrozek wrote: >> On 24 Aug 2018, at 14:39, Chris Kowalczyk <ckowalc...@suse.com> wrote: >> >> On 08/21/2018 03:56 PM, Jakub Hrozek wrote: >>>> On 21 Aug 2018, at 13:08, Chris Kowalczyk <ckowalc...@suse.com> wrote: >>>> >>>> Hello All, >>>> >>>> I was wondering if there are any plans of adding more maps -specifically >>>> networks or hosts- to NSS in sssd? >>>> >>>> >>>> As far as I know, it supports already the most important ones, like >>>> users, groups etc: >>>> >>>> https://docs.pagure.org/SSSD.sssd/users/ldap_with_ad.html#etc-nsswitch-conf >>>> >>>> >>>> I have also found later commits for adding netgroups: >>>> >>>> https://github.com/SSSD/sssd/commit/f128b7b865062da662127712935dcc58bd022384 >>>> >>>> https://github.com/SSSD/sssd/commit/ef39c0adcb61b16f9edc7beb4cdc8f3b0d5a8f15 >>>> >>>> >>>> But as far as I was able to find out, there was no works for networks or >>>> hosts. Is this something we would be interested to have in sssd, or for >>>> some reasons we wouldn't care about it? >>> We’ve planned on adding additional maps to SSSD for ages, the work was just >>> never assigned sufficient priority and manpower to be actually done. >>> >>> Patches are welcome :) >> Thank for this response, this is basically what I suspected ;) >> >> Could you briefly point me to other files/areas which would be related >> to such a change. Did I miss anything for netgroups? > Netgroups are already implemented. The client side (the NSS module) part > lives at src/sss_client/nss_netgroup.c. This is what gets loaded into the > application (e.g. getent if you call getent netgroup foobar). Then the clent > part contacts sssd_nss over a UNIX socket, there the NSS code lives at > src/responder/nss/nss_protocol_netgr.c, > src/responder/common/cache_req/plugins/cache_req_netgroup_by_name.c plus > there are some other areas shared with the other lookup types. Hello,
Thanks! >> Would it be easy to >> find such locations/commits for groups or users? > Not sure about commits, sssd is already so old^Wstable and much of the code > was rewritten from its initial implementation. But I wonder if you’re asking > about how should you understand the code flow better? Would it help to > resurrect the internals document we had on the old wiki? You mentioned that it would be good to combine those different kinds of 'sources' into some common generic mechanism, which is a good idea, so I was just wondering if you could point me to some files/areas in code which should be updated - just to have an idea how much it would be :) How about some links to this old wiki resources? >>> One thing we’ve talked about the last time this topic came up was that >>> since the interfaces, at least as far as the NSS interface is concerned are >>> often quite similar to one another, we should consider sharing a lot of >>> code or even employing some code generator.. >> Of course, this sounds good. Would you have any preferences about the >> design? >> > I would start with a design page that describes some or even all of the > interfaces you’d like to implement from the NSS point of view. This would be > helpful in the sense that we would get a better grasp of how are the maps > similar to each other or how do they differ. You mentioned hosts and > networks, so maybe pointing out the setnetend/endnetent/getnetbyname > functions and the hosts database (gethostby/sethostend/endhostent). I suspect > there might be some overlap with the netgroup code. > > Then, I would document in the design page how do the objects look like when > stored in LDAP with popular schemas (rfc2307, rfc2307bis). Using this, we > could define the “schema” for how the objects would be stored in the internal > database. I know that nss-pam-ldapd already has support for both hosts and > networks, so setting up a server with some host and network objects and > setting up a nss-pam-ldapd client would be a good start. > > Next, I would implement the sysdb (the sssd cache) API and the code that > looks up the objects in the cache. We wouldn’t have to even implement the > part that looks up the objects in LDAP at that point, we could instead inject > the objects to the cache with ldb tools (e.g. ldbadd), but having the cache > code and the NSS client code would then enable us to actually have a workable > prototype where if you add the objects to the cache, you can actually query > them from the system using getent and we could even write tests for the > lookups. > > The last part would then to write the part that actually looks up the objects > on the server and stores them in the cache. > > This is all a lot of work and I see that for someone not familiar with SSSD > code, this is really overwhelming. I can’t say I will have any or much time > to work on this myself, but I would like to help at least as far as some > guidance goes. We can even chat on hangouts or whatever chat is popular these > days.. > > But as I said above, phase one in my mind is to actually set this up with a > tool that already handles these NSS maps, like nss-pam-ldapd, document how > the objects look like and what interfaces need to be implemented in SSSD. > Then we would have a better understanding of what actually needs to be > implemented, what can be reused etc. > Thanks Jakub, this was really helpful! Yeahh, it will be some work but I would be glad to dive into it. Perhaps i will harass you with more questions in the future.. Regards, Chris _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
