-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] ldap module broken after upgrade to 3006.2 #64962
Comments
Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar. |
Do you have the same versions of Is it |
Hi @gvalkov, it seems that openldap is trying to use the |
Hi @MKLeb. Thank you for looking into this. I already migrated our FreeIPA extpillar to use the pure-python ldap3 module (it's somewhat confusing that salt's ldap3 module is still based on the native bindings). Before that, I had this workaround that patched import lief
lib = lief.parse("/lib64/libldap.so.2")
sym = next(i for i in lib.imported_symbols if i.name == "EVP_md2")
lib.remove_dynamic_symbol(sym)
lib.write("/opt/saltstack/salt/lib//libldap.so.2") |
As I also had this issue and based on @gvalkovr comment's, here is what I did to workaround this problem. System is running salt version 3006.4 (Sulfur) on OS Red Hat Enterprise Linux release 9.3 (Plow) To confirm the error, I ran the following command /opt/saltstack/salt/bin/python3 -c 'import ldap' As expected, it throw the following
So, I nstalled salt-pip install lief Then edited file in I'v added the following on top of the line 34 before import lief
lib = lief.parse("/lib64/libldap.so.2")
sym = next(i for i in lib.imported_symbols if i.name == "EVP_md2")
lib.remove_dynamic_symbol(sym)
lib.write("/opt/saltstack/salt/lib/libldap.so.2") Restarted services systemctl restart salt-master.service salt-minion.service salt-api.service It generated segfault errors in syslog output
Again, edited file in Removed the lines previously added near line 34 before And again, restarted services systemctl restart salt-master.service salt-minion.service salt-api.service Re-ran the following /opt/saltstack/salt/bin/python3 -c 'import ldap' Then voilà, this time no output nor errors and no more error such as |
Also present in 3007.1 |
Confirming 3007.1 is affected. I need to roll back; LDAP eauth is the only enterprise-level auth option available and it is incredibly broken. My team cannot use the API whatsoever.
|
Okay, I have this working in my lab environment. I've identified two things.
#!/usr/bin/env python3
import datetime
import grp
import os
import pathlib
import pwd
import shutil
##
import dbus # dnf -y install python3-dbus
##
import lief # https://pypi.org/project/lief/
# https://github.com/saltstack/salt/issues/64962
salt_root = pathlib.Path('/opt/saltstack')
src_lib = pathlib.Path('/lib64/libldap.so.2')
dst_lib = salt_root.joinpath('salt', 'lib', 'libldap.so.2')
uname = 'salt'
gname = 'salt'
lib = lief.parse(str(src_lib))
sym = next(i for i in lib.imported_symbols if i.name == 'EVP_md2')
if sym:
# Get the Salt services from DBus.
sysbus = dbus.SystemBus()
sysd = sysbus.get_object('org.freedesktop.systemd1', '/org/freedesktop/systemd1')
mgr = dbus.Interface(sysd, 'org.freedesktop.systemd1.Manager')
svcs = []
for i in mgr.ListUnits():
# first element is unit name.
if not str(i[0]).startswith('salt-'):
continue
svc = sysbus.get_object('org.freedesktop.systemd1', object_path = mgr.GetUnit(str(i[0])))
props = dbus.Interface(svc, dbus_interface = 'org.freedesktop.DBus.Properties')
state = props.Get('org.freedesktop.systemd1.Unit', 'ActiveState')
if str(state) == 'active':
svcs.append(i[0])
# Get the user/group
u = pwd.getpwnam(uname)
g = grp.getgrnam(gname)
# Modify
print('Modifications necessary.')
if svcs:
# Stop the services first.
for sn in svcs:
mgr.StopUnit(sn, 'replace')
if dst_lib.exists():
# 3.10 deprecated .utcnow().
#dst_lib_bak = pathlib.Path(str(dst_lib) + '.bak_{0}'.format(datetime.datetime.now(datetime.UTC).timestamp()))
dst_lib_bak = pathlib.Path(str(dst_lib) + '.bak_{0}'.format(datetime.datetime.utcnow().timestamp()))
os.rename(dst_lib, dst_lib_bak)
print('Destination file {0} exists; backed up to {1}.'.format(dst_lib, dst_lib_bak))
lib.remove_dynamic_symbol(sym)
lib.write(str(dst_lib))
os.chown(dst_lib, u.pw_uid, g.gr_gid)
os.chmod(dst_lib, src_lib.stat().st_mode)
# Before we restart services, we also want to remove any python caches.
for root, dirs, files in os.walk(salt_root):
for f in files:
if f.lower().endswith('.pyc'):
fpath = os.path.join(root, f)
os.remove(fpath)
print('Removed file {0}'.format(fpath))
if '__pycache__' in dirs:
dpath = os.path.join(root, '__pycache__')
shutil.rmtree(dpath)
print('Removed directory {0}'.format(dpath))
# And then start the units that were started before.
if svcs:
for sn in svcs:
mgr.RestartUnit(sn, 'replace')
print('Done.') |
@nf-brentsaner Are you able to test this on a current nightly build? |
I tried with latest 3007 on RHEL9 and it still fails. |
md2 is required for the python-ldap module. Using the python-ldap module is currently the only supported way to run ldap within Salt. fixes saltstack/salt#64962
This appears to be having an impact on the libvirt module as well. This issue is not present in 3006.1. Running the script from nf-brentsaner resolves the issue. Prior to running the script:
After running the script
|
Description
On a clean install of 3006.2 on AlmaLinux 9, the
ldap
module fails to import with the following error:It works with 3006.1, as well as the system Python.
Steps to Reproduce the behavior
Repeating the above with
bootstrap-salt.sh stable 3006.1
works as expected. For now we're switching to theldap3
module in our external pillars.The text was updated successfully, but these errors were encountered: