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