On 08/27/2018 11:03 AM, Jakub Hrozek wrote:
> On 24 Aug 2018, at 14:39, Chris Kowalczyk
<ckowalczyk(a)suse.com> wrote:
>
> On 08/21/2018 03:56 PM, Jakub Hrozek wrote:
>>> On 21 Aug 2018, at 13:08, Chris Kowalczyk <ckowalczyk(a)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