On (29/06/15 18:13), Jakub Hrozek wrote:
>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]
^^^^^^^^^^
The last part is single variable
filter. I don't think we need to
split it
> [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.
This one is doable short term.
>- same for authentication
the same as above
>- 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.
the same as above
>- 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.
>
This one is not doable in short term.
Please consider AD provider and error causedb by "replacing" groups
after tokengroups. But I agree that in long term we shoudl do it.
>- anything that causes SSSD to fail to start should also emit a syslog
> message. Admins don't really know about sssd debug logs.
We just need to enable logging to journald by default
+ change debug level. But it requires to fix previous point.
>- our man pages are not structured well, especially the LDAP man page is
> too big and contains too many options.
Do you have an idea how to split man pages?
We do not have one long man page.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5),
sssd-ipa(5), sssd-ad(5), sssd-sudo(5),sss_cache(8), sss_debuglevel(8),
sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8),
sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8),
sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8),
sss_ssh_knownhostsproxy(8),sssd-ifp(5),pam_sss(8). sss_rpcidmapd(5)
The main problem is that people needn't know about them
and/or they needn't know where to start.
>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.
The best way how to get familiar with sssd is to fix few bugs
in different part of sssd :-)
LS
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
