[PATCHES] PAM: refactor pam_reply
by Pavel Reichl
Hello,
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.
Thanks!
7 years, 5 months
[PATCHES] [sssd-1.11] Fixes suitable for latest release
by Lukas Slebodnik
ehlo,
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.
LS
7 years, 7 months
[PATCH] Improve negcache with subdomains
by Jakub Hrozek
Hi,
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
tests.
7 years, 8 months
[PATCH] CI: Enforce coverage make check failures
by Nikolai Kondrashov
Hi everyone,
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
fixed first.
Nick
7 years, 10 months
[PATCH] LDAP: Inform about small range size
by Lukas Slebodnik
ehlo,
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.
LS
7 years, 11 months
[PATCH] SUDO: Support the IPA schema
by Michal Šrubař
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?
7 years, 11 months
RFC: Improving the debug messages
by Jakub Hrozek
Hi,
I spent many hours debugging SSSD in different scenarios last week and I
admit it wasn't always easy -- and I have the source code knowledge I
can use. I imagine it's considerably harder for users and admins..
So this is a brainstorm request on how can we make debugging with SSSD
easier. Maybe there are some low-hanging fruits that can be fixed
easily. Off the top of my head:
- it should be easier to see start and end of a request in the back end.
Instead of:
[be_get_account_info] (0x0200): Got request for [0x1001][1][name=admin]
[acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Success)
We could make the debug messages more explicit:
[be_get_account_info] (0x0200): Received request for [object=user][key=name][value=admin]
[acctinfo_callback] (0x0200): Finished request for [object=user][key=name][value=admin]. Returned 0,0,Success
Then we could document the messages in our troubleshooting document.
Please note I'm not proposing to turn debug messages into any kind of
API and keep them the same forever, but decorate the usual flow with
messages that make sense without source level knowledge.
- same for authentication
- same for responder cache requests. We seem to have gotten better with
the new cache_req code there, so this is mostly about using the new
code in all responders. But also the commands we receive from sockets
should be printed in human-readable form.
- Running sssd in environment where all actions complete successfully
should emit no debug messages. Default log level should be moved to
SSSDBG_OP_FAILURE or CRIT_FAILURE. (This basically amounts to checking
all OP, FATAL and CRIT failure messages..)
The reason is that sometimes sssd fails, but because logging is
totally silent, we don't know what happened at all. Currently we have
a couple of small bugs where we might print a loud DEBUG message just
because we search for an entry which is not there etc.
- anything that causes SSSD to fail to start should also emit a syslog
message. Admins don't really know about sssd debug logs.
- our man pages are not structured well, especially the LDAP man page is
too big and contains too many options.
One reason I'm bringing this up now is that we'll have a new SSSD developer
starting soon and these might be nice tasks to start with AND they're
also needed.
7 years, 12 months
[PATCH] [sssd-1.11] pysss_nss_idmap: Use wrapper for older python
by Lukas Slebodnik
ehlo,
we dropped support for old version of python (<2.6)
in recent version of sssd. It should work in 1.11 branch
but there was a small issue in pysss_nss_idmap bindings.
Attached is a simple patch wich reuse our internal python wrappers.
LS
7 years, 12 months
