Well that's awkward. We need the version to know what functions we can actually call based on the remote version ... I'm not sure what's the right answer here ....

Does it really have to be on every BIND? There are only a handful places in the lib389 code where we need to care about the DS version, which are handled by ds_is_older()/ds_is_newer().

No it doesn't have to be every bind - the current design should only call ds_is_older/newer() when needed. So in this case ... maybe it's needed? I suspect it'll be in Account when it's trying to determine if we are on a 1.4.x to have new schema and what's possible.

Okay so looking at your reproducer, it's pretty clear what's happening.

As you build the second UserAccount from:

    # Bind should be successful
    conn = user.bind(password)
    UserAccount(topo.standalone, f'uid=tuser,ou=people,{DEFAULT_SUFFIX}').set('userPassword', 'my_new_password')

This has to pass through init(), which is calling:

        if ds_is_older('1.3.7', instance=instance):
            self._create_objectclasses.append('inetUser')
        else:
            self._create_objectclasses.append('nsMemberOf')
        if not ds_is_older('1.4.0', instance=instance):
            self._create_objectclasses.append('nsAccount')
        user_compare_exclude = [
            'nsUniqueId',
            'modifyTimestamp',
            'createTimestamp',
            'entrydn'
        ]

This is because we don't know how you plan to use the UserAccount type, if you are making a new object or not at this point - it's just the nature of how it works. So this means you'll always call the ds_is_older etc.

I believe the way the CLI tools avoid this is by calling Account instead, because account as the base class can do the password reset regardless of the actual object class type (which is kind of the point ....). We use UserAccount for "specific" tasks to those types like creation and modification that requires the awareness of the class structure, but Account works on "anything" that needs reset or locking.

So I think that this doesn't affect the CLI tools/callers when they need to reset the password as it avoids the ds_is_older call.

It doesn't work with plain Account too:

  /workspace/ds/test_reproducer.py(40)test_change_pw()
-> assert user.bind(password)
  /workspace/ds/src/lib389/lib389/idm/account.py(207)bind()
-> inst_clone.open(*args, **kwargs)
  /workspace/ds/src/lib389/lib389/__init__.py(1089)open()
-> self.__add_brookers__()
  /workspace/ds/src/lib389/lib389/__init__.py(355)__add_brookers__()
-> self.monitorldbm = MonitorLDBM(self)
> /workspace/ds/src/lib389/lib389/monitor.py(123)__init__()
-> if not ds_is_older("1.4.0", instance=instance):
(Pdb) 

As you can see, we hit ds_is_older() anyway, because at the end of open() we call __add_brookers__() which calls MonitorLDBM().

What I don't understand is why we do ldapsearch for vendorVersion before we look it up in defaults.inf?

Because we can't guarantee we are on a machine with a defaults.inf - imagine a remote client or admin workstation with lib389 only, and no 389-ds-base? Or a situation where you have a 389-ds-base but the version isn't the same? So we have to look it up from the rootdse, not the defaults.inf because it may not be there or may be incorrect.

The whole add_brookers method is awful and I wish we could remove it, because it shouldn't be in that path at all :|

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3918

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.