Bug 45495 - Can not join when LDAP backend is mdb
Can not join when LDAP backend is mdb
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.2
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on: 31907
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-06 17:01 CEST by Nico Stöckigt
Modified: 2020-07-03 20:52 CEST (History)
1 user (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.034
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2017100621000275
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nico Stöckigt univentionstaff 2017-10-06 17:01:39 CEST
In a customer environment a join failed due to the ppolicy was not found. The LDAP backend was set to mdb so in the 40univention-ldap-server_database the following statement skips the creation:

-----
40univention-ldap-server_database
---8<---
if configRegistry.get('ldap/database/type') == "mdb" and configRegistry.is_true('ldap/ppolicy', False):|  if configRegistry.is_true('ldap/ppolicy', False):                                                      
          print "moduleload\tppolicy.so"

if configRegistry.get('ldap/database/type') == "mdb" and configRegistry.is_true('ldap/ppolicy', False):|  if configRegistry.is_true('ldap/ppolicy', False):
          print "overlay\t\tppolicy"                                                                     |          print "overlay\t\tppolicy"
          if configRegistry.is_true('ldap/ppolicy/enabled', False):                                      |          if configRegistry.is_true('ldap/ppolicy/enabled', False):
                  ppolicy_default = 'cn=default,cn=ppolicy,cn=univention,%(ldap/base)s' % configRegistry |                  ppolicy_default = 'cn=default,cn=ppolicy,cn=univention,%(ldap/base)s' % configRegistry
                  print 'ppolicy_default\t"%s"' % configRegistry.get('ldap/ppolicy/default', ppolicy_defa|                  print 'ppolicy_default\t"%s"' % configRegistry.get('ldap/ppolicy/default', ppolicy_defa
--->8---
Comment 1 Arvid Requate univentionstaff 2017-10-10 19:00:14 CEST
This restriction has explicitly be added in

commit 2ccf72d992ad7f6627152d6992735ef712ca9286

during the last stages of fixing Bug #31907. I don't recall the reason, why it shouldn't have worked with bdb.
Comment 2 Arvid Requate univentionstaff 2017-10-10 19:06:16 CEST
Maybe I didn't understand the bug report, as I cannot read the snippet. What is that, a patch proposal?


Also, you write that the backend was set to mdb, then the condition

configRegistry.get('ldap/database/type') == "mdb"

should be fulfilled, should it it?
Comment 3 Nico Stöckigt univentionstaff 2017-10-11 10:29:23 CEST
(In reply to Arvid Requate from comment #2)
> Maybe I didn't understand the bug report, as I cannot read the snippet. What
> is that, a patch proposal?
> 
> 
> Also, you write that the backend was set to mdb, then the condition
> 
> configRegistry.get('ldap/database/type') == "mdb"
> 
> should be fulfilled, should it it?

The Snippet was a bit screwed up - see https://bepasty.knut.univention.de/x3HjaNEb for a tidy version

Infact the customer still uses _bdb_ (mdb was a typo in hurry).

So he worked around the situation by changing the join-Script '40univention-ldap-server_database' as mentioned in the Snippet above!
Comment 4 Arvid Requate univentionstaff 2017-10-11 13:17:28 CEST
Ok, see comment 1, there was some problem with bdb and ppolicy. From my emails from 2014-10-22 I see that I found a fix for that issue ( I guess for ~/svn/patches/openldap/4.0-0-0-ucs/2.4.40-1/70_ppolicy_udm_lock.patch ), but I don't know how the problem was. All I know is that we never fixed it. So I do not recommend removing the restriction to mdb, as it may have an unknown side effect in combination with bdb.
Comment 5 Arvid Requate univentionstaff 2017-10-11 13:22:31 CEST
I found the problem report from 2014-10-20. At that time Jenkins-CI tests showed that the ucs-test/tests/10_ldap/50ppolicy_account_lockout left the slapd unresponsive. So, definitely not recommended without further checks.
Comment 6 Ingo Steuwer univentionstaff 2020-07-03 20:52:02 CEST
This issue has been filed against UCS 4.2.

UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.