Re: [Freeipa-devel] user-friendly 'IPA internal error' message
On 23.4.2015 14:10, Simo Sorce wrote: > On Thu, 2015-04-23 at 07:28 +0200, Jan Cholasta wrote: >> Dne 22.4.2015 v 15:32 Simo Sorce napsal(a): >>> On Wed, 2015-04-22 at 09:59 +0200, 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. On a related note, I would also like the server to send tracebacks to the client if debugging is enabled on the server. >>> >>> I am not too hot on this idea, unless there is a specific switch to >>> allow sending tracebacks (default to off). >> >> Emphasis on "if debugging is enabled". > > If I enable debugging on the server, I still may not want all clients to > receive backtraces, especially if I am trying to resolve a problem in > production. Good point, I agree with Simo on this. It should be a separate switch. -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
On Thu, 2015-04-23 at 07:28 +0200, Jan Cholasta wrote: > Dne 22.4.2015 v 15:32 Simo Sorce napsal(a): > > On Wed, 2015-04-22 at 09:59 +0200, 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. > >> > >> On a related note, I would also like the server to send tracebacks to > >> the client if debugging is enabled on the server. > > > > I am not too hot on this idea, unless there is a specific switch to > > allow sending tracebacks (default to off). > > Emphasis on "if debugging is enabled". If I enable debugging on the server, I still may not want all clients to receive backtraces, especially if I am trying to resolve a problem in production. 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
On 04/22/2015 04:47 PM, 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. This is something I was looking as a side gig, even posted a request for ideas or requirements on freeipa-users list: https://www.redhat.com/archives/freeipa-users/2015-March/msg00940.html but so far there were no responses. The centralized logging solutions like ELK server and derivatives can reveal some stuff, but you need to tell it what should it correlate together and maybe display. If you have any ideas how to improve the Troubleshooting by this mean, I would be very interested in it. > b) develop troubleshooting documentation as cases come up and are > solved, indexed by symptom I am encouraging everyone to keep updating the Troubleshooting page, when they came to a case with problem root cause that is not yet present on that page. We need to make Troubleshooting page as actual as possible, it may be already helping a lot, by people simply googling it and not asking on freeipa-users at all because the issue is resolved. > c) keep helping our beloved users :-) > > Simo. > -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
Dne 22.4.2015 v 15:32 Simo Sorce napsal(a): On Wed, 2015-04-22 at 09:59 +0200, 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. On a related note, I would also like the server to send tracebacks to the client if debugging is enabled on the server. I am not too hot on this idea, unless there is a specific switch to allow sending tracebacks (default to off). Emphasis on "if debugging is enabled". -- Jan Cholasta -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
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 ev
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
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? -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
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 :-) 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
On 22.4.2015 16:08, 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? Right, it is relatively simple if it happens during installation. The problem is that InternalError does not happen only during installation. It can happen at any client at any time. What specific information from the proposed text 'See httpd error log on server %s for more details.' can do some harm? Petr^2 Spacek > 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. > > rob -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
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. rob -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
On Wed, 2015-04-22 at 09:59 +0200, 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. > > On a related note, I would also like the server to send tracebacks to > the client if debugging is enabled on the server. I am not too hot on this idea, unless there is a specific switch to allow sending tracebacks (default to off). 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
On 22.4.2015 09:59, 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. > > On a related note, I would also like the server to send tracebacks to the > client if debugging is enabled on the server. https://fedorahosted.org/freeipa/ticket/4998 -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] user-friendly 'IPA internal error' message
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. On a related note, I would also like the server to send tracebacks to the client if debugging is enabled on the server. -- Jan Cholasta -- 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
[Freeipa-devel] user-friendly 'IPA internal error' message
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? -- Petr^2 Spacek -- 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
