Hide Forgot
Description of problem: "qpid-config -a guest/guest@<host>" command execution from one to another different server behaves the normal way (the command is executed) in the most of the cases; in some cases the execution exits/fails with an exception (see "Additional info" chapter below). In these cases the "ANONYMOUS" method is used for authentication on the remote server (host). I think that the command should be pass always, as user guest is available on the remote machine. This defect may have some link to bug 675713. Version-Release number of selected component (if applicable): [root@dhcp-37-203 ~]# rpm -qa | grep qpid | sort python-qpid-0.7.946106-15.el5 qpid-cpp-client-0.7.946106-28.el5 qpid-cpp-client-devel-0.7.946106-28.el5 qpid-cpp-client-devel-docs-0.7.946106-28.el5 qpid-cpp-client-ssl-0.7.946106-28.el5 qpid-cpp-server-0.7.946106-28.el5 qpid-cpp-server-cluster-0.7.946106-28.el5 qpid-cpp-server-devel-0.7.946106-28.el5 qpid-cpp-server-ssl-0.7.946106-28.el5 qpid-cpp-server-store-0.7.946106-28.el5 qpid-cpp-server-xml-0.7.946106-28.el5 qpid-java-client-0.7.946106-15.el5 qpid-java-common-0.7.946106-15.el5 qpid-java-example-0.7.946106-15.el5 qpid-tools-0.7.946106-12.el5 How reproducible: Sometimes, depends on machine. Steps to Reproduce: 1.[root@dhcp-37-203 ~]# qpid-config -a guest/guest.37.202 See below Actual results: In some cases the "qpid-config" command exits with exception for user guest. Expected results: The command should not exit with exception for user guest. Additional info: See below terminal transcript... [root@dhcp-37-200 ~]# cat /etc/qpidd.conf log-enable=info+ log-to-file=/tmp/qpidd.log truncate=yes auth=yes [root@dhcp-37-203 ~]# qpid-config -a guest/guest.37.200 Total Exchanges: 8 topic: 3 headers: 1 fanout: 1 direct: 3 Total Queues: 5 durable: 0 non-durable: 5 [root@dhcp-37-202 ~]# cat /etc/qpidd.conf #log-enable=info+ log-enable=debug+ log-to-file=/tmp/qpidd.log truncate=yes auth=yes [root@dhcp-37-203 ~]# qpid-config -a guest/guest.37.202 Failed: SessionException: ExecutionException(error_code=403, command_id=serial(29), class_code=0, command_code=0, field_index=0, description=u'unauthorized-access: authorised user id : anonymous@QPID but user id in message declared as guest (qpid/broker/SemanticState.cpp:473)', error_info={}, channel=1, id=serial(2)) [root@dhcp-37-202 ~]# sasldblistusers2 -f /var/lib/qpidd/qpidd.sasldb guest@QPID: userPassword [root@dhcp-37-202 ~]# rpm -V qpid-cpp-server S.5....T c /etc/qpidd.conf
The crux of the problem here is a disconnect between the requested user-id (guest) and the authenticated user-id (anonymous). This is a bug in the Python console library in that it tags outgoing messages with the requested user-id even though it's possible that the SASL layer might choose a mechanism that uses a different identity.
Fixed upstream in revision 1071138.
The bug has not repeated any more on machines running Rhel4-i386, Rhel4-x86_64, Rhel5-i386 or Rhel5-x86_64 (tested version: qpid-tools-0.10.1). This bug occurred during executing the command "qpid-config -a guest/guest@<host>" from a machine running Rhel4 (i386 or x86_64) to a machine running Rhel6 (i386 or x86_64). This behaviour is most probably related to bug 692045.
The faulty behaviour does not repeat anymore; tested on Rhel4, Rhel5 and Rhel6 (on i386 and x86-64 platforms in all cases). Tested packages: python-qpid-qmf-0.10-6 python-qpid-0.10-1 qpid-cpp-client-devel-docs-0.10-3 qpid-cpp-client-devel-0.10-3 qpid-cpp-client-rdma-0.10-3 qpid-cpp-client-ssl-0.10-3 qpid-cpp-client-0.10-3 qpid-cpp-server-cluster-0.10-3 qpid-cpp-server-devel-0.10-3 qpid-cpp-server-rdma-0.10-3 qpid-cpp-server-ssl-0.10-3 qpid-cpp-server-store-0.10-3 qpid-cpp-server-xml-0.10-3 qpid-cpp-server-0.10-3 qpid-java-client-0.10-2 qpid-java-common-0.10-2 qpid-java-example-0.10-2 qpid-qmf-devel-0.10-6 qpid-qmf-0.10-6 qpid-tests-0.10-1 qpid-tools-0.10-2 rh-qpid-cpp-tests-0.10-3 ruby-qpid-qmf-0.10-6 ruby-qpid-0.7.946106-2 --> VERIFIED
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