https://bugs.openldap.org/show_bug.cgi?id=10026
--- Comment #13 from Ondřej Kuzník ondra@mistotebe.net --- On Sat, Jun 13, 2026 at 02:29:50PM +0000, openldap-its@openldap.org wrote:
Still had a bunch of errors setting up the test environment. After spending about an hour to get thru that, still getting zero output from tester.py.
You need to be more explicit about the steps to setup the environment.
It installs some python packages, namely python-ldap, so libldap development libraries need to exist, we went over that in comment #6. After that, there is no other requirement apart from python itself. If you want the convenience of a one-line virtual env setup, the equivalent of `whatprovides virtualenv` for your distro to get the suggested scripts (in this case `virtualenv`) would get you that.
You need to be much more explicit about the steps the test script is performing and what should be seen at each step.
It is doing what's described in comment #1, sets up a provider that's also a consumer replicating from 2 other servers that force it to lie to its consumers.
If you want to do it by hand, you'll have to read the script's outline (lines 537-612), the reason the script exists is that you need perfect control over the message sequencing across two syncrepl sessions to confuse syncprov and why one of the LDAP servers is written in Python to achieve this.
Or you can run test050 repeatedly and hope that you get the right conditions to happen just like our CI manages every so often. When this was reported, test050 had been stumbling across other bugs as well.
You should not assume any distro-provided LDAP packages are installed on any developer's machine.
After we went over this once, I would have assumed you wouldn't get stuck on the same thing again?
As for the failed run, are you sure there's no other slapd listening on ports 1389, 2389 or 3389?
Assuming you have a slapd running you want to debug, I have updated the setup to add a `-w`/`--wait` option so you can attach gdb to the server you're interested in, it's 3389 that this test forces to misbehave through an entirely reasonable ordering of messages.
Again, checking with a minimal clean environment with Debian Trixie (e.g. a container), then following just works 100% of the time for me. Add `--wait` and/or `--workdir <path>` when you want to interfere.
---- 8< ---- sed -i -e 's/Types: deb/Types: deb deb-src/' /etc/apt/sources.list.d/debian.sources apt update DEBIAN_FRONTEND=noninteractive apt install -y wget git libldap-dev virtualenv DEBIAN_FRONTEND=noninteractive apt build-dep -y openldap
git clone https://git.openldap.org/openldap/openldap wget 'https://bugs.openldap.org/attachment.cgi?id=1156' -O test050.tgz
pushd openldap ./configure --enable-harness --enable-modules && make depend && make popd
tar xf test050.tgz pushd test050 virtualenv ./venv source ./venv/bin/activate pip install -r ./requirements.txt TOP_SRCDIR=../openldap ./tester.py ---- 8< ----