Bug 652233
Summary: | qpid tools bad behaviour if PLAIN authentication is forced | ||
---|---|---|---|
Product: | Red Hat Enterprise MRG | Reporter: | Lubos Trilety <ltrilety> |
Component: | qpid-qmf | Assignee: | Ken Giusti <kgiusti> |
Status: | CLOSED ERRATA | QA Contact: | Lubos Trilety <ltrilety> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.3 | CC: | freznice, gsim, iboverma, jneedle, jsarenik, kgiusti, tross |
Target Milestone: | 2.1 | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | python-qmf-0.9.1073306-1, qpid-tools-0.9.1078967-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-06-23 15:42:47 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Lubos Trilety
2010-11-11 12:46:18 UTC
This bug is not dependant on architecture the same behaviour is observed on both x86_64 and i386 architectures. The described scenario is relevant for RHEL5, for RHEL4 it was very similar only the error message was slightly different, on RHEL4 it is: Failed: ConnectionFailed: (None, 'No acceptable SASL authentication mechanism available') instead of: Failed: ConnectionFailed - (None, 'SASL error: Error in sasl_client_start (-4) SASL(-4): no mechanism available: No worthy mechs found') The bug was detected on these sasl and qpid packages: cyrus-sasl-plain-2.1.22-5.el5_4.3 cyrus-sasl-2.1.22-5.el5_4.3 saslwrapper-devel-0.1.934605-2.el5 cyrus-sasl-plain-2.1.22-5.el5_4.3 saslwrapper-0.1.934605-2.el5 ruby-saslwrapper-0.1.934605-2.el5 cyrus-sasl-lib-2.1.22-5.el5_4.3 cyrus-sasl-lib-2.1.22-5.el5_4.3 cyrus-sasl-devel-2.1.22-5.el5_4.3 python-saslwrapper-0.1.934605-2.el5 cyrus-sasl-devel-2.1.22-5.el5_4.3 qpid-cpp-server-store-0.7.946106-19.el5 qpid-cpp-server-devel-0.7.946106-19.el5 qpid-tests-0.7.946106-1.el5 qpid-cpp-server-0.7.946106-19.el5 python-qpid-0.7.946106-14.el5 qpid-cpp-client-ssl-0.7.946106-19.el5 qpid-cpp-server-xml-0.7.946106-19.el5 qpid-cpp-client-devel-docs-0.7.946106-19.el5 qpid-cpp-mrg-debuginfo-0.7.946106-19.el5 qpid-java-client-0.7.946106-12.el5 qpid-cpp-client-0.7.946106-19.el5 qpid-cpp-server-ssl-0.7.946106-19.el5 qpid-cpp-server-cluster-0.7.946106-19.el5 qpid-cpp-client-devel-0.7.946106-19.el5 qpid-tools-0.7.946106-11.el5 qpid-java-common-0.7.946106-12.el5 qpid-java-example-0.7.946106-12.el5 How are you supplying the user name and password? [1] If I omit the user name and password, I get similar results to what you are getting. If I add the user name and password to the URL, I can use qpid-stat with SASL without difficulty: qpid-stat -c guest/guest@localhost:5672 Connections client-addr cproc cpid auth connected idle msgIn msgOut =============================================================================== 127.0.0.1:54085 qpid-stat 30413 guest@QPID 0s 0s 203 0 [1] http://www.ietf.org/rfc/rfc4616.txt That's the point to not supply user name and password. There are two possible solutions: First use default user name and password (guest/guest) if PLAIN mechanism is forced. Second print correct error. Definitely not something like: "no mechanism available: No worthy mechs found". (In case of qpid-printevents and qpid-tool the tool doesn't print anything, but it should, because it's not connected to broker) (In reply to comment #3) > That's the point to not supply user name and password. > > There are two possible solutions: > First use default user name and password (guest/guest) if PLAIN mechanism is > forced. I don't think the tools should do this. If you enable a SASL mechanism that requires a user name and password, I expect the system to require a name and password. > Second print correct error. Definitely not something like: "no mechanism > available: No worthy mechs found". We simply use cyrus sasl as a framework, this is not a message that is generated by the tools themselves. I think these tools should continue to treat authentication as a black box. > (In case of qpid-printevents and qpid-tool > the tool doesn't print anything, but it should, because it's not connected to > broker) It's not an error for qpid-printevents and qpid-tool to run without being connected to a broker. These tools are designed for environments in which brokers may come up and go down, so you can start them, then start a broker, take the broker down, etc. However, when a broker is available and these tools fail to connect due to an authentication error, these tools should report that error. In upstream revision 1052086, I added a few things that you may find helpful: 1. I added some log messages to the QMF console. If a connection can't be made because no broker is available, it is logged as a warning. If a connection can't be made because of a SASL authentication error, it is logged as an error. 2. I set the default logging level to ERROR for both qpid-tool and qpid-printevents. This means the user sees an error for SASL authentication, but not for a broker that is not running yet. 3. I added a --require-connection option to qpid-printevents. If a connection can not be established, the program exits. 4. I have added a --log-level option to qpid-printevents. Examples: $ ./qpid-printevents --sasl-mechanism PLAIN nonexistent-broker => Not an error. Waits for the broker to be started. $ ./qpid-printevents --sasl-mechanism PLAIN localhost 2010-12-22 17:07:18,365 ERROR Could not connect to broker localhost:5672 (None, 'No acceptable SASL authentication mechanism available') => Connection error condition in output - SASL authentication failed because user name and password are not supplied. But qpid-printevents keeps running, waiting for you to start the broker. $ ./qpid-printevents --sasl-mechanism PLAIN --log-level critical => Connection error condition in output - SASL authentication failed because user name and password are not supplied. No output in this case, because the log level has been set to critical. $ ./qpid-printevents --sasl-mechanism PLAIN --require-connection localhost 2010-12-22 17:11:03,791 ERROR Could not connect to broker localhost:5672 (None, 'No acceptable SASL authentication mechanism available') Failed: ConnectionFailed - (None, 'No acceptable SASL authentication mechanism available') => Connection error condition. qpid-printevents terminates because --require-connection was specified. Revision 1052086 was reverted. A simpler fix has been made in revision 1057195. If the broker is not up, you get errors like this: $ ./qpid-printevents localhost:41234 Fri Jan 7 22:30:22 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 [Errno 111] Connection refused Fri Jan 7 22:30:23 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 [Errno 111] Connection refused Tested on:
qpid-tools-0.10-4.el6
qpid-tools-0.10-5.el5
'auth=yes' in /etc/qpidd.conf was set
qpid-printevents works fine
# qpid-printevents localhost:41234
Thu May 26 08:30:50 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 (111, 'Connection refused')
Thu May 26 08:30:51 2011 NOTIC qpid-printevents:brokerConnectionFailed broker=localhost:41234 (111, 'Connection refused')
but qpidd-tool still doesn't print any error
# qpid-tool localhost:41234
Management Tool for QPID
qpid: schema
QMF Classes:
qpid: list
Summary of Objects by Type:
>>> ASSIGNED
Missed 2.0 release train - pushing out to next release. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0890.html |