there is patch solving  attached.
It is possible that we will have similiar problem with other local keys,
so I wrote special function for adding key to list of missing with
condition if it is needed or not.
attched patch is an integration test for regression #3093.
I prepared a test and I let someone else to fix it :-)
I will try to find more bugs in downstream tests.
BTW we might move test from test_ts_cache somewhere else.
But it was the fastest way how to write a test without enumeration.
First patch, see attached.
This is for easy fix from ticket
I am going on the assumption that if the first 2 characters of ad_server
are digits then it is likely an IP address and not hostname. If you have
a better idea for this please let me know.
The failure is about missing dependencies, unrelated to these patches.
It depends on the sssctl failover patches due to changes in attaching
dbus message to a talloc context. Now it is possible to also free the
message with both dbus_message_unref() and talloc_free(). Since the
sssctl patches are already in late review process I didn't want to
Failover patches for the sssctl tool. The output looks like:
[master.ipa.pb: ~]$ sudo sssctl domain-status ad.pb
Online status: Online
AD Global Catalog: root-dc.ad.pb
AD Domain Controller: root-dc.ad.pb
Discovered AD Global Catalog servers:
Discovered AD Domain Controller servers:
Discovered IPA servers:
This is the best output format I could thing of so far, but I'm opened
the attached patch fixes:
We have a user that can not login with
enforced GPO because of this. I do not
think it is a common issue, I could not
create groupPolicyContainer with gPCMachineExtensionNames
containing only whitespaces, but you can
create it with a script and the blank
value is not an error so we should handle it
properly (and maybe thre is a way in the
GUI maze to create such GPOs as well, I just
could not find it).
I was able to reproduce the same "sssd log path"
the user has and this patch fixed the issue.
please see the attached patches. I'm not sure how this bug got in,
because in the patch that broke the functionality
(eef359b508b898ae99d2bf292a43f0f295a2ba5e) I said in the commit message
that I did the change that is only implemented in the first attached
patch. My guess is that the rebasing after the DP patches were merged
To make sure we don't regress, I added more tests and switched the tests
to calling the DP handler.
attached patch fixes acces denied after activating user in 389ds.
Jakub had some comments/ideas in ticket but I think it's better to discuss
about virtual attributes and timestamp cache on mailing list.