Description of problem: The qpid python client fails GSSAPI authentication in the case user and credentials are valid. There are observed continuous failure of python qpid client on RHEL 5.5 i386 / x86_64 following ways: RHEL 5.5 i386: ('...Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)') qc_client.py --conn-auth-mechanism GSSAPI -p 49759 --user 343u2psaofS6PpWa3hZMn --broker pogolinux-1.rhts.eng.rdu.redhat.com Cannot connect to the broker pogolinux-1.rhts.eng.rdu.redhat.com:49759 Traceback (most recent call last): File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 236, in connect self.connection.start(); File "/usr/lib/python2.4/site-packages/qpid/connection.py", line 152, in start raise ConnectionFailed(*self.close_code) ConnectionFailed: (None, 'SASL error: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)') Traceback (most recent call last): File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 30, in ? sys.exit(main()); File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 18, in main qc.connect(); File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 243, in connect raise QcException(e); qc_lib.QcException: <qpid.connection.ConnectionFailed instance at 0xb7dfb2ec> Exception qc_lib.QcException: <qc_lib.QcException instance at 0xb7dfb2ec> in <bound method qc_client.__del__ of <qc_lib.qc_client object at 0xb7e9b c8c>> ignored ecode:1 RHEL 5.5 x86_64 ('...Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 7)'): qc_client.py --conn-auth-mechanism GSSAPI -p 41042 --user EH0ncsAo3bT7EkT6XgBc --broker tyan-gt24-04.rhts.eng.bos.redhat.com Cannot connect to the broker tyan-gt24-04.rhts.eng.bos.redhat.com:41042 Traceback (most recent call last): File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 236, in connect self.connection.start(); File "/usr/lib/python2.4/site-packages/qpid/connection.py", line 152, in start raise ConnectionFailed(*self.close_code) ConnectionFailed: (None, 'SASL error: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Unknown code krb5 7)') Traceback (most recent call last): File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 30, in ? sys.exit(main()); File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_client.py", line 18, in main qc.connect(); File "/mnt/tests/distribution/MRG/Messaging/qpid_common/clients/python/qc_lib.py", line 243, in connect raise QcException(e); qc_lib.QcException: <qpid.connection.ConnectionFailed instance at 0x2aedc7291d88> Exception qc_lib.QcException: <qc_lib.QcException instance at 0x9409dd0> in <bound method qc_client.__del__ of <qc_lib.qc_client object at 0x2aedc7 28b910>> ignored ecode:1 I believe the printed error messages are misleading, but I might be wrong. The client used for GSSAPI authentication is simple qc_client.py which can be found here: http://cvs.devel.redhat.com/cgi-bin/cvsweb.cgi/tests/distribution/MRG/Messaging/qpid_common/clients/python/ Connection's host parameter is set to FQDN or ip (equal to broker host name) of the machine where kerberos daemons are running: def connect(self): try: self.socket = qpid.util.connect(self.options.broker_host, self.options.broker_port); conn_opts_dict = { }; # optional authentication assignments if(self.options.conn_auth_mechanism == 'GSSAPI'): conn_opts_dict['host'] = self.options.broker_host; if(self.options.auth_user != None): conn_opts_dict['username'] = self.options.auth_user; if(self.options.auth_pass != None): conn_opts_dict['password'] = self.options.auth_pass; if(self.options.conn_auth_mechanism != None): conn_opts_dict['mechanism'] = self.options.conn_auth_mechanism; if(self.options.conn_auth_service != None): conn_opts_dict['service'] = self.options.conn_auth_service; if(self.options.conn_auth_min_ssf != None): conn_opts_dict['min_ssf'] = self.options.conn_auth_min_ssf; if(self.options.conn_auth_max_ssf != None): conn_opts_dict['max_ssf'] = self.options.conn_auth_max_ssf; self.connection = Connection( sock = self.socket, heartbeat = self.options.conn_heartbeat, locale = self.options.conn_locale, **conn_opts_dict ); # start connection and session # --------------------------------------------------------------------- self.connection.start(); The test was passing, but suddenly with one of the last releases it started to fail. Version-Release number of selected component (if applicable): python-qmf-0.7.946106-5.el5 python-qpid-0.7.946106-4.el5 python-saslwrapper-0.1.934605-2.el5 qmf-0.7.946106-6.el5 qmf-devel-0.7.946106-6.el5 qpid-cpp-client*-0.7.946106-6.el5 qpid-cpp-server*-0.7.946106-6.el5 qpid-java-*-0.7.946106-5.el5 qpid-tests-0.7.946106-1.el5 qpid-tools-0.7.946106-6.el5 but seen also on the very last packages from devel repo. How reproducible: 100% Steps to Reproduce: 0. All necessary kerberos, cyrus-sasl and saslwrapper packages are installed. Kerberos service is set-up for current machine for admin user admin and unprivileged user EH0nc 1. User get's his kerberos ticket using kinit 2. Broker (qpidd) is started up with --auth yes 3. qpid python client is executed to get connection to the broker using GSSAPI authentication: qc_client.py --conn-auth-mechanism GSSAPI -p 41042 --user EH0ncs \ --broker tyan-gt24-04.rhts.eng.bos.redhat.com Actual results: Qpid python client (low level API) fails GSSAPI authentication under normal conditions when it should pass. Expected results: Qpid python client (low level API) should pass GSSAPI authentication under normal conditions. Additional info: See more detailed info on the following links: https://beaker.engineering.redhat.com/logs/2010/09/7009/12443/146859///TESTOUT.log https://beaker.engineering.redhat.com/logs/2010/09/7009/12443/146859///log.tar.bz2 or https://beaker.engineering.redhat.com/logs/2010/72/8372/14934/183553///TESTOUT.log https://beaker.engineering.redhat.com/logs/2010/72/8372/14934/183553///log.tar.bz2
Created attachment 435519 [details] simple test script Works for me using attached script (modified from one of the old examples) and latest packages in -devel (python-qpid-0.7.946106-9.el5, python-saslwrapper-0.1.934605-2.el5). The 'Server not found in Kerberos database' error suggests that the principal for the qpidd service on the given machine has not been created. Might that have expired? Has the qc_client.py code changed at all?
I'm going to retest, there were some changes to qc_client.py, but I believe those were harmless. The changes made to qc_client.py are passing dynamically arguments to Connection, passing there dictionary with dynamic Connection's argument. I need doublecheck, the only change I can see is that I do not pass password as it is not needed in krb case. An update soon.
I performed retest of the case and found following issue: The comment 1 client works as expected, because Connection's 'service' parameter is explicitly defined as 'qpidd'. The qc_client.py now performs also testing of default values, so the Connection code changed from below mode 0 to mode 3: if (mode==0): connection = Connection (sock=socket, username=options.auth_user, mechanism=options.conn_auth_mechanism, host=options.broker_host, service=options.conn_auth_service); elif(mode==1): connection = Connection (sock=socket, username=options.auth_user, mechanism=options.conn_auth_mechanism, host=options.broker_host); elif(mode==2): connection = Connection (sock=socket, username=options.auth_user, mechanism=options.conn_auth_mechanism, host=options.broker_host, service='qpidd'); elif(mode==3): conn_opts_dict = { }; if(options.conn_auth_mechanism == 'GSSAPI'): conn_opts_dict['host'] = options.broker_host; if(options.auth_user != None): conn_opts_dict['username'] = options.auth_user; if(options.conn_auth_mechanism != None): conn_opts_dict['mechanism'] = options.conn_auth_mechanism; if(options.conn_auth_service != None): conn_opts_dict['service'] = options.conn_auth_service; connection = Connection (sock=socket, **conn_opts_dict); Conclusion: The qpid python GSSAPI authentication works as expected if Connection's service parameter is explicitly specified. The remaining question: To my understanding Connection's service parameter should default to 'qpidd' anyway, so explicit assignment is not needed. Am I right?
The behavior was discussed and agreed that Connection's service parameter should default to 'qpidd'. To avoid confusion closing this bug as CLOSED/NOTABUG and created new one with appropriate description of the failure and setting i.e bug 621527.