this patchset takes the current SRV lookup code and converts it into a
plugin. Next waves will add custom plugin for IPA and AD.
Introduce new plugin interface.
First SRV lookup plugin.
Replaces current code with a plugin code. I originally wanted to remove
resolve_srv_* functions completely and call the plugin in
fo_resolve_service_send() directly but that proved to be harder and
more error sensitive than I expected.
This got me thinking, we should create a refactoring ticket for the
failover code. It has become quite complex and hard to read and
understand because it lacks a lot of comments. Also many things there
seems very hackish to me.
Set SRV lookup plugin for all providers. This is done as a separate
patch because it will be reverted once each provider has its own plugin.
I also would like to discuss where we can set the plugin in the future.
At the moment we have one failover context for the whole backend. But
the backend can be configured to run several different providers at the
same time. The plugin itself is made per provider - you have different
plugin for IPA and different for LDAP.
I think we should have failover context per provider. My idea is to
create a new module constructor e.g. sssm_ipa_init(). This will be
called only once before all other sssm_ipa_*_init() functions and it
will initialize IPA-wise failover context.
We can also use it to initialize sdap_id_ctx instead of calling
sssm_ipa_id_init from other places.
This is Abhishek Kumar Singh. I want to apply for Gsoc this year. I have
sound Knowledge of C, C++, Python, bash script, pytest, unit testing
framework, code coverage. Currently am learning cmocka unit testing
I will start with the idea "SSSD Test Suite Coverage" as a part of my Gsoc
2013 Proposal, which includes writing unit tests for SSSD using cmocka
library. I had a discussion with Jakub Hrozek(jhrozek) who is my mentor.
Please guide me through your valuable suggestions.
Commit should say it all.
We do not have any security issue (that I know off) with the current
code, but I want to tighten up the privileges more given we do not need
the additional capabilities in the krb5_child anyway.
Simo Sorce * Red Hat, Inc * New York