Bug 618504 - Cannot submit abrt bugs
Cannot submit abrt bugs
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xmlrpc-c (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Enrico Scholz
Fedora Extras Quality Assurance
RejectedBlocker
:
Depends On:
Blocks: F14Beta/F14BetaBlocker
  Show dependency treegraph
 
Reported: 2010-07-27 01:36 EDT by Nicolas Mailhot
Modified: 2010-09-07 10:08 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-07 10:08:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2010-07-27 01:36:53 EDT
Description of problem:

abrt bugzilla submission stopped working

Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error

Bugzilla URL was
https://bugzilla.redhat.com

In non SSL mode

Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: HTTP response code is 301, not 200

Bugzilla URL was
http://bugzilla.redhat.com

Version-Release number of selected component (if applicable):
abrt-plugin-bugzilla-1.1.10-2.fc14.x86_64
abrt-addon-ccpp-1.1.10-2.fc14.x86_64
abrt-desktop-1.1.10-2.fc14.x86_64
abrt-gui-1.1.10-2.fc14.x86_64
abrt-1.1.10-2.fc14.x86_64
abrt-plugin-logger-1.1.10-2.fc14.x86_64
abrt-addon-python-1.1.10-2.fc14.x86_64
abrt-libs-1.1.10-2.fc14.x86_64
abrt-plugin-runapp-1.1.10-2.fc14.x86_64
abrt-addon-kerneloops-1.1.10-2.fc14.x86_64
Comment 1 Jens Petersen 2010-07-27 03:41:52 EDT
Please add a pointer to a specific Alpha Release criteria
when adding an alpha blocker.
Comment 2 Nikola Pajkovsky 2010-07-27 07:27:36 EDT
Actually it's not abrt fault that xmlrpc-c can't provide automatic redirect (301 Moved Permanently). It should be fixed on xmlrpc-c or curl
Comment 3 Nicolas Mailhot 2010-07-27 13:03:07 EDT
(In reply to comment #1)
> Please add a pointer to a specific Alpha Release criteria
> when adding an alpha blocker.    

abrt not being able to talk to Fedora bugzilla falls under the "dramatically reduces test coverage" criterium, I think

http://fedoraproject.org/wiki/Fedora_13_Alpha_Release_Criteria#Alpha_Blocker_Bugs
Comment 5 Jens Petersen 2010-07-27 20:46:27 EDT
Thanks - it is working for me though.
Comment 6 Jens Petersen 2010-07-27 20:47:26 EDT
Anyone else?  I don't think this is an ALpha blocker.
Comment 7 Adam Williamson 2010-07-28 23:51:09 EDT
Damn, I remember this has come up before and we didn't codify a criterion to cover it.

I personally think we *need* abrt to work for Alpha, but in this case it works, there's a problem with submission, so I don't think this is quite a blocker. I'd definitely like to have it fixed, though.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 8 Enrico Scholz 2010-07-29 05:40:59 EDT
it's probably trivial by adding a patch which sets CURLOPT_FOLLOWLOCATION + CURLOPT_POSTREDIR.

Nevertheless, rfc 2616 says

   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user...

e.g. the correct way would be that xmlrpc-c reports the redirection to abrt, abrt asks the user whether to follow it and issues the new request.


There are security considerations too, e.g. when there would be a redirection to bugzilla.fedoraproject.org, the CURLOPT_UNRESTRICTED_AUTH must be set too.  But user entered password for bugzilla.redhat.com only and might not want that it is transferred to another server.


Why not use the correct URI in /etc/abrt/plugins/Bugzilla.conf?
Comment 9 Nicolas Mailhot 2010-07-29 13:07:05 EDT
(In reply to comment #8)
 
> Why not use the correct URI in /etc/abrt/plugins/Bugzilla.conf?    


/etc/abrt/plugins/Bugzilla.conf only rerefences the root bugzilla address, ie https://bugzilla.redhat.com

This is correct as it's probably the only thing the user knows

I have no idea why this results in a redirection
Comment 10 Enrico Scholz 2010-07-29 14:27:47 EDT
I updated rawhide and added a patch; but it fails to build atm
Comment 11 Nikola Pajkovsky 2010-07-30 03:30:27 EDT
(In reply to comment #8)
> it's probably trivial by adding a patch which sets CURLOPT_FOLLOWLOCATION +
> CURLOPT_POSTREDIR.
> 
> Nevertheless, rfc 2616 says
> 
>    If the 301 status code is received in response to a request other
>    than GET or HEAD, the user agent MUST NOT automatically redirect the
>    request unless it can be confirmed by the user...
> 
> e.g. the correct way would be that xmlrpc-c reports the redirection to abrt,
> abrt asks the user whether to follow it and issues the new request.
> 

Yes, this will help a lot.

> 
> There are security considerations too, e.g. when there would be a redirection
> to bugzilla.fedoraproject.org, the CURLOPT_UNRESTRICTED_AUTH must be set too. 
> But user entered password for bugzilla.redhat.com only and might not want that
> it is transferred to another server.
> 
> 
> Why not use the correct URI in /etc/abrt/plugins/Bugzilla.conf?

    

> /etc/abrt/plugins/Bugzilla.conf only rerefences the root bugzilla address, ie
> https://bugzilla.redhat.com

Also look at gui settings. Gui stores URI into gnome-keyring
Comment 12 Bug Zapper 2010-07-30 08:52:22 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Adam Williamson 2010-07-30 12:30:16 EDT
As per my comment above and the criteria, this is not a blocker, and we don't think we should add a criterion to make it one (though we probably will for Beta or Final). We certainly would like to see it fixed before Alpha, though. It would be best to have it fixed by Tuesday to make sure that happens. Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Nicolas Mailhot 2010-07-30 12:52:33 EDT
(In reply to comment #11)

> > /etc/abrt/plugins/Bugzilla.conf only rerefences the root bugzilla address, ie
> > https://bugzilla.redhat.com
> 
> Also look at gui settings. Gui stores URI into gnome-keyring    

The GUI settings is the same (I started there)
Comment 15 Enrico Scholz 2010-07-30 14:07:02 EDT
feel free to request a build of the rawhide version. atm, the buildSRPMFromSCM phase fails with an obscure error (http://koji.stg.fedoraproject.org/koji/taskinfo?taskID=2239275) and I am not sure whether I have time to retry it at the weekend or debug the new build process further.
Comment 16 Nikola Pajkovsky 2010-07-31 07:30:39 EDT
(In reply to comment #15)
> feel free to request a build of the rawhide version. atm, the buildSRPMFromSCM
> phase fails with an obscure error
> (http://koji.stg.fedoraproject.org/koji/taskinfo?taskID=2239275) and I am not
> sure whether I have time to retry it at the weekend or debug the new build
> process further.    

Err, dist-git problem or maybe you have an old fedpkg. Send me directly patch and I will make a build for a testing purpose.
Comment 17 James Laska 2010-08-02 11:50:21 EDT
Moving to F14Beta per comment#13.  There is discussion on test@lists.fedoraproject.org about appropriately prioritizing ABRT failures (see http://lists.fedoraproject.org/pipermail/test/2010-July/092322.html).
Comment 18 Nicolas Mailhot 2010-08-04 13:12:20 EDT
with
xmlrpc-c-1.23.01-1400.svn1958.fc14.x86_64
xmlrpc-c-c++-1.23.01-1400.svn1958.fc14.x86_64
xmlrpc-c-client++-1.23.01-1400.svn1958.fc14.x86_64
xmlrpc-c-client-1.23.01-1400.svn1958.fc14.x86_64

in non-ssl mode, abrt gui now fails with

abrt-gui:   settings:{'Bugzilla': {'SSLVerify': 'no', 'Enabled': 'yes', 'BugzillaURL': 'http://bugzilla.redhat.com/', 'Login': 'x', 'Password': 'y', 'RatingRequired': 'yes'}, 'KerneloopsReporter': {'InformAllUsers': 'yes', 'SysLogFile': '/var/log/messages', 'Enabled': 'yes', 'SubmitURL': 'http://submit.kerneloops.org/submitoops.php'}, 'Logger': {'Enabled': 'yes', 'AppendLogs': 'yes', 'LogPath': '/var/log/abrt.log'}}
abrt-gui: Report() returned
abrt-gui: Update:Connexion à bugzilla...
abrt-gui: Warning:Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error
abrt-gui: Update:Reporting via 'Bugzilla' was not successful: Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error
Comment 19 Nicolas Mailhot 2010-08-04 13:16:29 EDT
And in SSL mode, it fails with

abrt-gui:   settings:{'Bugzilla': {'SSLVerify': 'yes', 'Enabled': 'yes', 'BugzillaURL': 'https://bugzilla.redhat.com/', 'Login': 'x', 'Password': 'y', 'RatingRequired': 'yes'}, 'KerneloopsReporter': {'InformAllUsers': 'yes', 'SysLogFile': '/var/log/messages', 'Enabled': 'yes', 'SubmitURL': 'http://submit.kerneloops.org/submitoops.php'}, 'Logger': {'Enabled': 'yes', 'AppendLogs': 'yes', 'LogPath': '/var/log/abrt.log'}}
abrt-gui: Report() returned
abrt-gui: Update:Connexion à bugzilla...
abrt-gui: Warning:Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error
abrt-gui: Update:Reporting via 'Bugzilla' was not successful: Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the HTTP POST transaction.  SSL connect error
Comment 20 Enrico Scholz 2010-08-04 17:06:29 EDT
can you please set $XMLRPC_TRACE_CURL env?

service abrtd stop
env XMLRPC_TRACE_CURL=1 abrtd -dv

Else, can you trace the network traffic in non-ssl mode and check where the 301 is redirecting to?
Comment 21 Nicolas Mailhot 2010-08-05 01:39:43 EDT
I have no idea what env XMLRPC_TRACE_CURL=1 abrtd -dv
 did, but I can not reproduce the bug anymore (I did restart the abrtd service yesterday after the xmlrpc-c update)
Comment 22 Enrico Scholz 2010-08-05 05:26:02 EDT
Do you mean that the bug is completely gone, or only when XMLRPC_TRACE_CURL is set?  In latter case, there is very likely a bug (vs. missing feature as reported initially) and problem should be analysed with valgrind or so.
Comment 23 Denys Vlasenko 2010-08-05 12:47:11 EDT
(In reply to comment #19)
> abrt-gui: Warning:Cannot login. Check Edit->Plugins->Bugzilla and
> /etc/abrt/plugins/Bugzilla.conf. Server said: libcurl failed to execute the
> HTTP POST transaction.  SSL connect error

This is a problem staring at us right here: xmlrpc's error description is somewhat vague: "SSL error". What kind of SSL error?

Please improve it...
Comment 24 Nicolas Mailhot 2010-08-05 14:15:20 EDT
(In reply to comment #22)
> Do you mean that the bug is completely gone, or only when XMLRPC_TRACE_CURL is
> set?  In latter case, there is very likely a bug (vs. missing feature as
> reported initially) and problem should be analysed with valgrind or so.    

I mean I tried it with XMLRPC_TRACE_CURL and it succeeded

Then I started the abrtd service (wasted an hour crashing something and collecting enough debuginfos from koji for abrt to accept the new trace) and it succeeded too.

I still works now

I could not say if XMLRPC_TRACE_CURL unstuck something, if the redirect is gone server-side, of if one of the few other rpms I installed from koji in the meanwhile fixed the problem, but the problem is gone
Comment 25 Enrico Scholz 2010-08-15 18:52:02 EDT
> xmlrpc's error description is
> somewhat vague: "SSL error". What kind of SSL error?
>
> Please improve it...

that's a problem in curl's nss part; its Curl_nss_connect() function does not fill error information in some execution paths (e.g. when PR_NewTCPSocket() or the setup of various SSL options fails) and returns a generic CURLE_SSL_CONNECT_ERROR only. At a first glance, handling of SSL_ForceHandshakeWithTimeout() errors might return this error too in some cases

feel free to reassign this bug to the curl component or create a new report.
Comment 26 Adam Williamson 2010-08-27 12:10:06 EDT
Discussed at today's blocker review meeting. We're tentatively accepting this while we decide whether to accept the proposed criterion that abrt must be able to report bugs at Beta stage.

Do we know exactly what's happening with this yet? Is this a general bug that affects everyone or something specific to Nicolas?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 27 Adam Williamson 2010-09-03 12:20:29 EDT
Discussed at today's blocker review meeting. I've filed several bugs via abrt over the last week, so this obviously isn't a complete showstopper. We could really do with knowing exactly what causes this problem and how likely people are to run into it, to decide if it's a blocker.
Comment 28 James Laska 2010-09-03 12:27:45 EDT
I just ran through several ABRT test cases on my F-14 system, and ABRT behaved as expected.  For a quick example ... http://fedoraproject.org/wiki/QA:Testcase_ABRT_CCPP_addon
Comment 29 Nicolas Mailhot 2010-09-04 18:00:35 EDT
(In reply to comment #26)
> Is this a general bug that
> affects everyone or something specific to Nicolas?

As I wrote in comment 14, I can not reproduce it any more with latest testing updates
Comment 30 James Laska 2010-09-07 10:08:19 EDT
(In reply to comment #29)
> (In reply to comment #26)
> > Is this a general bug that
> > affects everyone or something specific to Nicolas?
> 
> As I wrote in comment 14, I can not reproduce it any more with latest testing
> updates

Thanks for the feedback Nicolas!  I'm going to mark this issue as CLOSED CURRENTRELEASE.  Please re-open if the reported issue resurfaces.

Note You need to log in before you can comment on or make changes to this bug.