Retrieve remote groups information using SSSD InfoPipe (#2240) #2279
Conversation
|
@FroggyFlox Apologies for the major hold up on my part with this pr. Again as per your more recent AD/LDAP related additions/improvements I'm not currently in a position either practically or experience wise to test this in any meaningful way in the near future. So I'm leaning towards a merge as-is to get this out soon in the testing channel only, again so we can get the community feedback from those on the forum, for example, who are far more knowledgeable in this area. I have test build with these changes in place and all looked to be working as expected but I've only tested the more common non AD arrangement re group function. However you excellent report of your own testing is reassuring enough for a testing channel release. Well done on tracking this down and owning the issue, and the idea of the fail through is nice and I think should work well in this case. Thanks for the explanation. As per your detailed additional package info I've already added these to the rpm requirements ready for the merge. |
Fixes #2240
Fixes #1580
@phillxnet, ready for review
As detailed in #2240, we currently fail to fetch and list groups information after joining and AD or LDAP server, until a machine or rockstor service restart. This has been tracked down to some issue with
grpnot being able to fetch the groups information of such remote users until after agunicornor rockstor service restart. This pull request (PR) thus proposes to implement a fail-over mechanism to fetch this groups information in such cases based on the D-Bus API of SSSD: InfoPipe.Logic and implementation
Overall description
The error described in #2240 occurs when trying to fetch the groups information of a remote user. This ultimately boils down the fact that we are using two different approaches to fetch users and groups. While users are fetched from the system database using
getent passwd, the groups information is based on the pythongrpmodule. As the former sees remote users (in these conditions) but the latter does not, we end up in a situation where we askgrpto retrieve information on a group it doesn't know, thereby causing the error.As a result, this PR proposes to implement a new way to fetch the groups information based on the D-Bus API built in SSSD: InfoPipe. Instead of completely replacing the existing way we fetch groups, this PR proposes to use the InfoPipe-based mechanisms as a fail-over if
grpfails to fetch this information.Implementation details
New packages needed
This PR requires 2 additional packages:
sssd-dbus: the D-Bus responder of SSSDpython-dbus-python: dbus python moduleNew functions
Two new functions based on InfoPipe are added:
ifp_get_groupname(gid): given a gid, retrieve the groupname from InfoPipeifp_get_groups(): use InfoPipe to list all remote groupsAs we also need to activate the
ifpservice in SSSD config, this PR includes a new function to customize the services declared in/etc/sssd/sssd.conf. We also improve the existingappend_to_line()helper function to make it slightly more smart by verifying the desired customization is not already present before writing it.As mentioned above, the
ifp-based logic is implemented only as fail-over mechanism in casegrpfails to retrieve the required information. This is particularly important asifpseems to only see remote (AD/LDAP) groups, and requires thesssdservice to be up and running (and therefore the Rockstor machine to have already joined an AD/LDAP server). We thus cannot useifpas the default mechanism to fetch users/groups information. This PR thus proposes to include these in atry/exceptblock:getent passwd, including its primarygid.tryto retrieve groupname usinggrp(pre-PR mechanism).ifpSimilarly, we now retrieve and list all groups (triggered when visiting the Groups page):
grptryto fetch groups fromifpifpin step 2 to the list of step 1 if not already presentDemonstration
ifpservice is indeed defined in sssd.conf:# head /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam, ifp domains = samdom.example.com (...)Visit the Groups page and see the AD groups being listed:
Visit the Users page and see all AD users being listed:
The same has been verified after joining an LDAP server.
Important: the
ifp-based methods have been verified to be triggered only right after joining an AD/LDAP server'; upon restarting the rockstor service, all user and group information was retrieved by the primary mechanisms.Miscellaneous
Although this issue fixes #2240 and #1580, it doesn't fix #1817 as the current PR represents more a workaround than a true fix for the root cause of these issues, which seems to relate to some caching and/or env issue related to
gunicorn(explaining why agunicornrestart "fixes" all the problem.Testing
The full suite of tests yields:
Leap 15.2 (ISO install):
Full Testing Outputs
Leap15.2 (ISO install)