please see attached patch set which contains some refactoring which is
in my opinion quite safe. It doesn't touch the recursive call of
pam_reply() as I think that changing that would be more risky change.
We have 19 patches in 1.11 branch on top of latest release (1.11.7)
I went through bugs filed against 1.11 branch and filter
crashes and the most important bugs.
Attached are cherrry-picked patches from 1.12/master
So we can release the latest 1.11 version. It will be just a bug-fix release.
So some conservative distribution can use it or in another words.
we don't want have 1.11 branch neither in unreleased not in unclosed state :-)
BTW I test packages with LDAP KRB5 and AD test. Of course there are any
regressions because it is a bug fix only release.
I noticed this bug while working on the SSH fix with
default_domain_suffix. It turns out our filter_users/filter_groups don't
work well in this scenario, which might have effect on the server load
even. Attached are patches that re-initialize negcache with filter_lists
contents after the subdomains are (re)discovered. All patches have
see the attached patches for ticket
Removing the user during cleanup task completely
removes that user from local database, so that
user is no longer part of any group in sysdb.
Such user may, or may not have been removed from
LDAP so the only way to figure out is check
on the next refresh otherwise we may get
The third patch adds integration test for this
Apply and run the intgcheck without the first 2
patches to see the failed test (you will also see that
all the tests after this failed one will end with
errors as well, that is probably due to incomplete
clean up after the ldap tests and I do not intend to
solve this as part of this patchset but will
investigate it later).
Senior Principal Intern
The attached patch enforces make check failures for the CI coverage build, so
we can catch more test failures.
I think this should also be applied onto sssd-1-12.
NOTE: CI won't pass with this patch ATM, as test_ipa_subdom_server needs to be
I was reprodicing other bug and it took me some time to find out why I was not
able to resolve user. RID was bigger than range size.
I saw just general message about id mapping failer
[sdap_save_user] (0x0400): Processing user matthewbe
[sdap_save_user] (0x1000): Mapping user [matthewbe] objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to unix ID
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
[S-1-5-21-2997650941-1802118864-3094776726-200065] to a UNIX ID
Default range size is 200000
[sdap_save_user] (0x0020): Failed to save user [matthewbe]
[sdap_save_users] (0x0040): Failed to store user 0. Ignoring.
Feel free to propose better debug message. I think it would simplify debugging.
Hi guys, I spent some time working at this ticket
https://fedorahosted.org/sssd/ticket/1108 and I think it's finally
ready to be reviewed by others.
Description of the problem and scope of the changes can be found in
the commit message. I also wrote some unit tests but the patch is a
quite long already so I think it would be better to send the tests as
an another patch. Or should I create a patch for each modified file?
as we're stabilizing the 1.13 branch and before we plan what we want to
work on during the 1.14 development, we should use that time to write
some more tests!
Here are some areas where we could add tests. Please discuss or add your
ideas, I would like to turn this list into tickets we can start
* Extend the LDAP provider tests with more dynamic test cases.
- add a user to a group, run sss_cache, assert id user displays the
new group and getent group displays the new member
- conversely with removing users from groups
* Background refresh
- could be built atop the LDAP NSS tests as well. I think we have
all the infrastructure in place.
* Local overrides integration test:
- this could be relatively easy, just call the overrides tool and
request the entry. Could be built atop the existing LDAP tests
or even use the local provider.
* Add a KDC
- until we have a pam_wrapper, this would only be useful to test
ldap_child, but adding the KDC instantiation might be worth it
- there is a protorype of KDC instantiation on the list for some
time now, since we enabled rootless SSSD
* IFP - could we reuse the existing sbus tests to spawn a custom bus?
* SUDO - can we trick sudo into connecting to our test sssd instance?
I think the order of priority is roughly as above. I think the LDAP
provider is critical enough to be well tested. The refresh and local
override tests might be nice to have because we would be refactoring the
NSS responder in 1.14, so we should have it tested.
I'll be happy to hear other opionions, though!