On Wed, 2015-04-22 at 18:08 +0300, Alexander Bokovoy wrote: > On Wed, 22 Apr 2015, Simo Sorce wrote: > >On Wed, 2015-04-22 at 17:16 +0300, Alexander Bokovoy wrote: > >> On Wed, 22 Apr 2015, Rob Crittenden wrote: > >> >Jan Cholasta wrote: > >> >> Dne 22.4.2015 v 09:05 Petr Spacek napsal(a): > >> >>> Hello, > >> >>> > >> >>> looking at freeipa-users list, following kind of conversation is quite > >> >>> common: > >> >>> > >> >>> user: 'IPA reports an internal error, what should I do?' > >> >>> dev: 'see HTTPd error log on the IPA server' > >> >>> user: 'what server?' > >> >>> dev: 'enable debugging on client and see which server was contacted' > >> >>> > >> >>> > >> >>> Can we make InternalError more useful and eliminate this kind of > >> >>> ping-pong? > >> >>> > >> >>> Looking at sources: > >> >>> $ git grep 'class .*InternalError' > >> >>> ipalib/errors.py:class InternalError(PublicError): > >> >>> ipalib/errors.py:class ServerInternalError(PublicError): > >> >>> > >> >>> $ git grep ServerInternalError > >> >>> ipalib/errors.py:class ServerInternalError(PublicError): > >> >>> ipalib/errors.py: >>> raise > >> >>> ServerInternalError(server='https://localhost') > >> >>> ipalib/errors.py: ServerInternalError: an internal error has > >> >>> occurred on > >> >>> server at 'https://localhost' > >> >>> > >> >>> Apparently somebody was thinking about it in the past but > >> >>> ServerInternalError > >> >>> is not used anywhere. > >> >>> > >> >>> How hard would it be to translate InternalError on client side to > >> >>> ServerInternalError with appropriate server name? > >> >>> > >> >>> Can we extend InternalError with text like this? > >> >>> 'See httpd error log on server %s for more details.' > >> >>> > >> >>> Does it make sense? Should I open a ticket about this? > >> >>> > >> >> > >> >> It's a good idea. > >> > > >> >I don't know. How many people ask about CA install failures without > >> >looking into /var/log/*-install.log even though it states within just a > >> >few lines of output this is where all the logging goes? > >> > > >> >The terseness was done on purpose. > >> > > >> >> On a related note, I would also like the server to send tracebacks to > >> >> the client if debugging is enabled on the server. > >> > > >> >Call me conservative but this was a conscious choice originally as well. > >> >The traceback is in the logs. The admin has the logs. > >> I agree with Rob. Literally every single case when people report 'CA > >> install fails' ends up with people asking us instead of looking into > >> logs. There seems to general unwillingness to invest into understanding > >> of what is being done and why things might fail. > > > >I have to say this is a completely incorrect way of looking at it. > > > >People may be willing, but we are suffering of our own success. > > > >We've made an incredibly complex system, easy enough for people that do > >not fully understand it to use, and well *that* was the intention! So > >huzzah! But ... > > > >But it come with the pricetag that users do not understand it fully, and > >even knowing *where* logs are is not obvious, and it is not even obvious > >what component is to look at when something breaks. > > > >so I think it is unfair to say people are unwilling to look at logs, > >some may be, but I bet most simply do not know where to start even. > >Also keep in mind you only see the percentage of users that have > >trouble, those that *so* look at the logs and figure out themselves, or > >are good at searching and fin the solution reported by a previous user > >on their own do not show up. > > > >The long term solutions can only be: > >a) centralize logging of the various components so that there is a > >single place to go and look and correlate errors even for the untrained. > >b) develop troubleshooting documentation as cases come up and are > >solved, indexed by symptom > >c) keep helping our beloved users :-) > A story is always multi-fold. > > We need to fix installer issues where crashes in a single > component do not leave unprocessed results that cannot be interpreted > properly by a higher level code to suggest where to look for details and > what to do with them. > > However, majority of issues don't really require passing through > tracebacks from server to client. For example, timeout issues with CA > install due to lacking entropy wouldn't be solved by passing through a > traceback. It requires understanding what happens -- and even when we > print a message warning about lack of entropy, it is ignored, as we > print a lot of text during install. > > We have https://www.freeipa.org/page/Troubleshooting page to help here. > It is the first result in Google for 'freeipa troubleshooting', 'freeipa > trouble', 'freeipa issue', 'freeipa problem', 'freeipa install problem'. > It has a lot of content, indexed by symptom. Yet, amount of 'I have a > problem' without looking into logs is substantial. Should we add an > explicit link to the page above in every installer error output?
I think that may be a very good idea, giving pointers like that is usually a good help to novices. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
