5:13 p.m.
To test, trigger any NSS operation with SSSD configured with a domain
that can't yield subdomains. The current git HEAD returns an error when
parsing the message returned from the Data Provider.
The patch also renames the "done" label to "immediate" because
"done"
is mostly used for both success and failure cases and refactors some
DEBUG statements that were too long to fit into the 80-characters limit
(enforced by our code guidelines as well as the fact that lines too long
don't fit into vertical split on my laptop screen)
6:39 p.m.
On Wed, 2012-05-09 at 00:13 +0200, Jakub Hrozek wrote:
To test, trigger any NSS operation with SSSD configured with a
domain
that can't yield subdomains. The current git HEAD returns an error when
parsing the message returned from the Data Provider.
The patch also renames the "done" label to "immediate" because
"done"
is mostly used for both success and failure cases and refactors some
DEBUG statements that were too long to fit into the 80-characters limit
(enforced by our code guidelines as well as the fact that lines too long
don't fit into vertical split on my laptop screen)
Nack
This is much too noisy. Right now, for any NSS action that goes to the
back-end for a domain that doesn't implement subdomain support, we're
seeing:
(Wed May 9 19:35:40 2012) [sssd[be[adtest]]] [be_get_subdomains]
(0x0400): Got get subdomains [not forced][]
(Wed May 9 19:35:40 2012) [sssd[be[adtest]]] [be_get_subdomains]
(0x0020): Undefined backend target.
(Wed May 9 19:35:40 2012) [sssd[be[adtest]]] [be_get_subdomains]
(0x1000): Request processed. Returned 3,19,Subdomains back end target is
not configured
We should not be calling be_get_subdomains() this often, but I realize
that may not be feasible to change right now. However, we REALLY need to
make sure we're not failing at debug level 2 (SSSDBG_CRIT_FAILURE) when
we have an undefined backend target for subdomains.
Maybe we should just add a dummy subdomain provider that just returns no
subdomains and make that the default?
5:51 a.m.
On Wed, May 09, 2012 at 07:39:46PM -0400, Stephen Gallagher wrote:
On Wed, 2012-05-09 at 00:13 +0200, Jakub Hrozek wrote:
> To test, trigger any NSS operation with SSSD configured with a domain
> that can't yield subdomains. The current git HEAD returns an error when
> parsing the message returned from the Data Provider.
>
> The patch also renames the "done" label to "immediate" because
"done"
> is mostly used for both success and failure cases and refactors some
> DEBUG statements that were too long to fit into the 80-characters limit
> (enforced by our code guidelines as well as the fact that lines too long
> don't fit into vertical split on my laptop screen)
Nack
This is much too noisy. Right now, for any NSS action that goes to the
back-end for a domain that doesn't implement subdomain support, we're
seeing:
(Wed May 9 19:35:40 2012) [sssd[be[adtest]]] [be_get_subdomains]
(0x0400): Got get subdomains [not forced][]
(Wed May 9 19:35:40 2012) [sssd[be[adtest]]] [be_get_subdomains]
(0x0020): Undefined backend target.
(Wed May 9 19:35:40 2012) [sssd[be[adtest]]] [be_get_subdomains]
(0x1000): Request processed. Returned 3,19,Subdomains back end target is
not configured
We should not be calling be_get_subdomains() this often, but I realize
that may not be feasible to change right now. However, we REALLY need to
make sure we're not failing at debug level 2 (SSSDBG_CRIT_FAILURE) when
we have an undefined backend target for subdomains.
I know, I complained during the subdomains review. I should have been
more persistent. New patch with this fix is attached.
Maybe we should just add a dummy subdomain provider that just returns no
subdomains and make that the default?
I agree we should do this for all providers byt IPA. For IPA, I think it
is convenient to detect the subdomains at runtime in case a trust is
added.
3972
days inactive
3974
days old
sssd-devel@lists.fedorahosted.org
5 comments
2 participants
participants (2)
-
Jakub Hrozek -
Stephen Gallagher