impyla: SASL Error: no mechanism available: No worthy mechs found

When trying to connect to an Impala Server, the following error happens:

>>> from impala.dbapi import connect
>>> conn = connect(host='xxxxxxxxxx', port=21050, user='xxxxxx', password='xxxxxx', auth_mechanism='LDAP')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.6/site-packages/impala/dbapi.py", line 82, in connect
    auth_mechanism=auth_mechanism)
  File "/usr/local/lib/python2.6/site-packages/impala/hiveserver2.py", line 586, in connect
    transport.open()
  File "/usr/local/lib/python2.6/site-packages/thrift_sasl/__init__.py", line 72, in open
    message=("Could not start SASL: %s" % self.sasl.getError()))
thrift.transport.TTransport.TTransportException: Could not start SASL: Error in sasl_client_start (-4) SASL(-4): no mechanism available: No worthy mechs found

Even with all LDAP dependencies installed.

About this issue

  • Original URL
  • State: open
  • Created 9 years ago
  • Comments: 46 (14 by maintainers)

Commits related to this issue

Most upvoted comments

for what it’s worth, this solved it for me

apt-get install libsasl2-dev libsasl2-2 libsasl2-modules-gssapi-mit

running python in Docker

I have this working now on a CentOS install of Anaconda. I think that the critical aspect in getting this functioning was installing several sasl related packages on CentOS itself.

cyrus-sasl.x86_64        
cyrus-sasl-devel.x86_64  
cyrus-sasl-gs2.x86_64    
cyrus-sasl-gssapi.x86_64 
cyrus-sasl-ldap.x86_64   
cyrus-sasl-lib.x86_64    
cyrus-sasl-md5.x86_64    
cyrus-sasl-ntlm.x86_64   
cyrus-sasl-plain.x86_64  
cyrus-sasl-scram.x86_64  
cyrus-sasl-sql.x86_64    
python-saslwrapper.x86_64
ruby-saslwrapper.x86_64  
saslwrapper.x86_64       
saslwrapper-devel.x86_64 
$conda list 
impyla                    0.13.8                    <pip>
thrift                    0.9.3                     <pip>
thrift-sasl               0.2.0                     <pip>
thriftpy                  0.3.8                     <pip>
sasl                      0.2.1                     <pip>

I was unable to compile SASL on Windows (or any of the CentOS) packages, so leveraged the CentOS VM to connect to the Kerberos cluster.

After successfully running a kinit, I am able to connect with the following string:

con = impala.connect(host='xxxxxxxxxxxxx', port=21050, auth_mechanism='GSSAPI',
               kerberos_service_name='impala')

LDAP conection works as well:

con = impala.connect(host='xxxxxx', 
                             port=21050,
                             database='xxxxxx',
                             timeout=20,
                             use_ssl=True,
                             ca_cert='/home/user/cert.pem',
                             user='xxxxx', password=pwd,
                             auth_mechanism='PLAIN')

If it can help anyone, here’s a dockerfile for python 3.7

FROM python:3.7

RUN apt-get update && apt-get install -y --no-install-recommends \
		libsasl2-dev \
		libsasl2-2\ 
		libsasl2-modules-gssapi-mit\
	&& rm -rf /var/lib/apt/lists/*

WORKDIR /usr/src/app

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD [ "python", "./cluster.py" ]

I ran the following command and it fixed my issue. There might be some issues on redhat with missing dependencies

yum install cyrus-sasl-md5 cyrus-sasl-plain cyrus-sasl-gssapi cyrus-sasl-devel -y

There’s a workaround for LDAP connection problem. You need to do yum install saslwrapper and saslwrapper-devel, then connect to impala with PLAIN mechanism.

impala.dbapi.connect(host='localhost', user="xxx", password="xxx", auth_mechanism="PLAIN")

If you don’t install saslwrapper, you will get a timeout error.

When trying GSSAPI to connect to a secured CDH Hive instance then I get the following

/usr/lib/python3.5/site-packages/impala/dbapi.py in connect(host, port, database, timeout, use_ssl, ca_cert, auth_mechanism, user, password, kerberos_service_name, use_ldap, ldap_user, ldap_password, use_kerberos, protocol)
    145                           ca_cert=ca_cert, user=user, password=password,
    146                           kerberos_service_name=kerberos_service_name,
--> 147                           auth_mechanism=auth_mechanism)
    148     return hs2.HiveServer2Connection(service, default_db=database)
    149 

/usr/lib/python3.5/site-packages/impala/hiveserver2.py in connect(host, port, timeout, use_ssl, ca_cert, user, password, kerberos_service_name, auth_mechanism)
    636     transport = get_transport(sock, host, kerberos_service_name,
    637                               auth_mechanism, user, password)
--> 638     transport.open()
    639     protocol = TBinaryProtocol(transport)
    640     if six.PY2:

/usr/lib/python3.5/site-packages/thrift_sasl/__init__.py in open(self)
     70     if not ret:
     71       raise TTransportException(type=TTransportException.NOT_OPEN,
---> 72         message=("Could not start SASL: %s" % self.sasl.getError()))
     73 
     74     # Send initial response

TTransportException: TTransportException(message="Could not start SASL: b'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)'", type=1)

From beeline it is working fine.

So the easiest (although less performant) solution is to uninstall the Sasl python library and install puresasl and kerberos.

Puresasl doesn’t require any changes deps for plain Auth and impyla will fall back to using it.

Sounds like we should try to get conda-forge builds of cyrus-sasl possibly (I’m not sure what folks’ general thoughts on handling security libraries). I’m not sure when I’ll have time to work on it, though

Just a note, I believe that the pertinent issue here is the use of Anaconda. The install of the cyrus packages, which would normally provide the necessities for GSSAPI, is providing bindings for the system python, not the Anaconda python. I say this as someone who is facing a similar challenge with another package requiring sasl running under Anaconda.

@richban Can you try using this slightly forked version of python-sasl (which uses Cython instead of SWIG for wrapping): https://github.com/cloudera/python-sasl

@richban We’ve tried all thinkable dependencies, without success.