please see attached patch which is result of discussion in thread:
LDAP: tokengroups do not work with id_provider=ldap
>>>>>>>> Anyhow, find_subdomain_by_sid is misnamed, we routinely use the function
>>>>>>>> to find the primary domain.
>>>>>>> I think find_subdomain_by_sid() does what the name says and of course it
>>>>>>> can return the primary domain as long as the SID of the domain is know
>>>>> fwiw, this was my concern, the function is named "find_subdomain" yet it
>>>>> can find both main domain and subdomain. But I won't bikeshed any further.
>>>> ah, sorry, now I see your point. I agree that the name misleading but I
>>>> think this can be fixed after the release.
> Would 's/find_subdomain_by_sid/find_domain_by_sid/' be a sufficient
The attached patch implements a workflow change in which policy settings retrieved by the gpo_child are stored in local files under the /var/lib/sss/gpo_cache directory (where the full path is based on the gpo's modified file_sys_path).
Before this patch, the gpo_child retrieved the smb data, parsed it into policy settings, and returned the policy settings to the backend (i.e. no local files were written). With this patch, in order to keep the gpo_child as simple as possible, the gpo_child now simply retrieves the smb data and stores it to a local file, which is later read by the backend and parsed into policy settings by the backend.
Note that this patch does not add support for offline mode nor make use of the sysdb cache, both of which will be implemented in a subsequent patch.
the attached (unpolished, see my question below) patches fix
also known as:
Let me explain the problem first -- if SSSD starts before messagebus is
up, the InfoPipe responder fails to start and doesn't retry, so the
system bus service is simply not there.
A simple solution would be to start messagebus before SSSD. But I don't
think that is a robust solution, because the messagebus configuration
can reference user names, which the SSSD provides. So at the time
messagebus is up, the identities should be resolvable -- which means the
NSS responder and the back ends must be up.
The attached patches take advantage of bus activation messagebus
provides. If the interface InfoPipe provides is not registered on the
bus when requested, messagebus signals the sssd, which tells the IFP
responder to retry the system bus connection.
Currently, the WIP patches use sss_debuglevel which sends HUP to the
sssd process, but I think USR2 (aka "go online") would be better. So the
final patch version would include a helper binary that would do nothing
but singal the monitor..
I have one question to discuss though.. is it OK to use signals for the
IPC? An alternative might be to let IFP spawn a client socket and implement
only a single 'command' to retry the connection. But that seems like an
overkill to me. The disadvantage of the signal is that it's also used to
reset the online status so in theory there might be some timeouts in the
offline case, though.
In the 1.13 timeframe, we will be implementing socket-based activation.
I think it would be nice to make the IFP responder bus-activated as part
of that effort. But in the traditional schema where monitor manages all
the processes, the changes to make InfoPipe bus-activated instead of
managed by the monitor would be too invasive (I've tried to do that
please see attached patch.
This patch was previously written for BZ 1059423. But it now seems that
more detailed logging information is generally useful for issues that
are emerging from this area lately.