Failed to load LDAP module

[alpapan]

Hello

Having just updated to the both Ubuntu 20.04 I did a fresh install of Galaxy, (upgrading from 16.something). Using Python 3.6.11

I'm breaking my head around this for a few hours. For some reason I get Failed to load LDAP module (see below for error) even though I have installed python-ldap

I tried both conda install python-ldap whilst inside galaxy's environment (it installs ldap3-.2) and pip install ldap3-2.8.1 (after checking the github issues).

I first tried the 20.01 and then the dev branch (20.05 i believe). I tried checking if any of my old config files were invalid.
Any pointers how to debug this and figure out would be most appreciated....

thank you
alexie

galaxy.web.framework.decorators ERROR 2020-10-13 21:19:33,193 [p:15363,w:2,m:0] [uWSGIWorker2Core4] Uncaught exception in exposed API method:
Traceback (most recent call last):
  File "lib/galaxy/web/framework/decorators.py", line 294, in decorator
    rval = func(self, trans, *args, **kwargs)
  File "lib/galaxy/webapps/galaxy/controllers/user.py", line 122, in login
    return self.__validate_login(trans, payload, **kwd)
  File "lib/galaxy/webapps/galaxy/controllers/user.py", line 147, in __validate_login
    message, user = self.__autoregistration(trans, login, password)
  File "lib/galaxy/webapps/galaxy/controllers/user.py", line 89, in __autoregistration
    autoreg = trans.app.auth_manager.check_auto_registration(trans, login, password)
  File "lib/galaxy/auth/__init__.py", line 63, in check_auto_registration
    auth_results = provider.authenticate(email, username, password, options)
  File "lib/galaxy/auth/providers/ldap_ad.py", line 204, in authenticate
    failure_mode, params = self.ldap_search(email, username, options)
  File "lib/galaxy/auth/providers/ldap_ad.py", line 121, in ldap_search
    raise RuntimeError("Failed to load LDAP module: %s", str(ldap_import_exc))
RuntimeError: ('Failed to load LDAP module: %s', "No module named 'ldap'")

[alpapan]

Also I ought to say;
conda installs the module here: ./.conda/envs/galaxy/
pip install verifies:

Requirement already satisfied: ldap3 in ./.conda/envs/galaxy/lib/python3.6/site-packages (2.8.1)
Requirement already satisfied: pyasn1>=0.4.6 in ./.conda/envs/galaxy/lib/python3.6/site-packages (from ldap3) (0.4.8)

However Galaxy when it runs, it checks here: ./.venv/lib/python3.6/site-packages/

I ought to say that I do all this having done sudo su -l galaxy and conda activate galaxy.

Python and I are not friends.... what am i doing wrong?

[alpapan]

And this is galaxy's ~/.venv/pyvenv.cfg. hence being lost on what i'm doing wrong

home = /scratch/sysadmin/galaxy/.conda/envs/galaxy
implementation = CPython
version_info = 3.6.11.final.0
virtualenv = 20.0.33
include-system-site-packages = false
base-prefix = /scratch/sysadmin/galaxy/.conda/envs/galaxy
base-exec-prefix = /scratch/sysadmin/galaxy/.conda/envs/galaxy
base-executable = /scratch/sysadmin/galaxy/.conda/envs/galaxy/bin/python

[alpapan]

OK adding python-ldap==2.4.44 in the requirements.txt solved that issue.

If this was the right way, IDK.

Perhaps if it was in the documentation somewhere (e.g. https://docs.galaxyproject.org/en/master/admin/production.html)...

[nsoranzo]

@alpapan conda is the wrong way, all Galaxy dependencies should be installed in its virtual environment (.venv by default) via pip.
python-ldap should be automatically be installed at the version specified in lib/galaxy/dependencies/conditional-requirements.txt when you have an ldap or activedirectory authenticator in config/auth_conf.xml . The code to do that is in lib/galaxy/dependencies/__init__.py .
I suppose the automatic installation of python-ldap was failing for some reason, this should appear in the Galaxy startup logs (or when running ./scripts/common_startup.sh ) straight after the normal wheel installation.

[alpapan]

Hello

It sadly didn't do it automatically. Auth_conf was correctly including ldap.
It didn't show that it tried to install the dependency via pip (i tried dozens of times as i was trying to figure it out).

Before I tried writing this issue, i had also tried running ./scripts/common_startup.sh but to no avail.