openldap-technical June 2023

openldap-technical@openldap.org

30 participants
37 discussions

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Op 12-06-2023 om 17:29 schreef Quanah Gibson-Mount: > It appears you are using the historic back-hdb or back-bdb backend to > OpenLDAP. These backends are particularly susceptible to corruption. > You should migrate to using the supported backend (back-mdb). You > should also upgrade to a supported release series (2.5 or 2.6) as 2.4 > hasn't been supported for a few years. Yes we are in the middle of migrating. :-) The old structure still uses bdb, yes. While working on new (RHEL9) servers with symas-repo 2.5 openldap, things started happening with the 'old' (but still production) ldap. Thank you very much for your insights! Kind regards!

1 0

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Hi Quanah, Thanks for the swift reponse! I think I do, yes, see, from consumer one: olcSyncrepl: {0}rid=202 provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcSyncrepl: {1}rid=201 provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389 olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389 And the second consumer looks similar. Thanks again! On Mon, 12 Jun 2023 at 15:56, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > > --On Monday, June 12, 2023 3:23 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Is there any explanation, why I would be unable to obtain these > > contextCSN attributes through an ldapsearch? > > Do you have the syncprov overlay instantiated on the database on the > consumers? > > --Quanah > > > >

2 1

no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 12 Jun '23

12 Jun '23

Hi, We have a 4-machine setup with two providers (replicating between each other) and two consumers (for client access) that both replicate from both providers, type=refreshAndPersist I'm trying to write a script to monitor replication, using the contextCSN attribute. ldapsearch on the providers gives the expected the contextCSN attributes: contextCSN: 20230612115901.693614Z#000000#001#000000 contextCSN: 20230612115904.937471Z#000000#002#000000 However, the same ldapsearch on the consumers gives *no* contextCSN attributes *at all*. But when using slapcat to check directly on the consumers databases, we *can* see the attributes, and they are also up-to-date: contextCSN: 20230612115801.572594Z#000000#001#000000 contextCSN: 20230612115804.594419Z#000000#002#000000 Is there any explanation, why I would be unable to obtain these contextCSN attributes through an ldapsearch? This is RHEL7.9, with openldap 2.4.44 Thanks!

2 1

back-ldap proxy doesn't forward response from upstream server
by Sven Feyerabend 12 Jun '23

12 Jun '23

Hello everyone, I have set up two slapd instances in mirror mode. As described in the documentation I used another slapd instance with ldap backend to proxy the requests and provide failover capabilities in case one of the upstream servers becomes unavailable. Now I have the curious situation, that the proxy correctly forwards the search request from a client to the upstream server but doesn't return the result. I can see in the log that the upstream server responds with one entry: SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.001134 nentries=1 The proxy however does not forward this result to the client: SEARCH RESULT tag=101 err=0 qtime=0.000034 etime=0.001730 nentries=0 The client (ldapsearch for test purposes) then gives me the following result: # search result search: 2 result: 0 Success I don't understand what I did wrong. I imported the correct schema into the proxy instance, my config of the ldap backend on the proxy is as follows: # {2}ldap, config dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLdapConfig olcDatabase: {2}ldap olcSuffix: ROOT_SUFFIX_OF_UPSTREAM_DIRECTORY olcDbURI: ldap://openldap-test-0.ldap-test:1389,ldap://openldap-test-1.ldap-test:1389 Does anyone know how to solve this? Some help would be appreciated greatly. Thanks in advance and kind regards Sven

2 1

"pwdHistory" Attribute Is Not Getting Deleted
by Nagesh Nikavade (EXT-NSB) 11 Jun '23

11 Jun '23

Hello Team, We have upgraded from openldap2.4.52 to openldap2.6.2 in our system. With new openldap2.6.2 version, "pwdHistory" attribute isn't being deleted. I have executed the below command: ldapmodify -x -y /opt/Nokia_BP/etc/ldapfiles/fssecldap.ldaproot -D uid=fsLDAPRoot,ou=People,fsFragmentId=Security,fsClusterId=ClusterRoot >/dev/null<<EOF dn: uid=Nemuadmin,ou=People,fsFragmentId=Security,fsClusterId=ClusterRoot changetype: modify delete: pwdHistory EOF I was able to delete "pwdHistory" in old openldap2.4.52 with the same command. Anything got changed regarding this(pwdHistory) in new openldap2.6.2 ? Or is there any other way to delete the "pwdHistory". Thanks in advance. Best Regards, Nagesh

2 1

mdb_txn_abort() thread
by Sam Dave 08 Jun '23

08 Jun '23

Hi, The documentation for mdb_txn_begin() says "A transaction and its cursors must only be used by a single thread, and a thread may only have a single transaction at a time.". Does this also hold for mdb_txn_abort() for read-write transactions? I.e. does the abort also have to happen on the same OS thread as all the previous things (begin, put, etc.)? - Samuel

2 9

argon2 as builtin module?
by Geert Hendrickx 02 Jun '23

02 Jun '23

Hi I was wondering why the argon2 password module can only be built as a dynamic module, and not statically into the slapd binary, like other backends and overlays can be. That would for example make it easier to use slappasswd -h {ARGON2} without having to specify -o module-load=argon2 and module-path etc. Is it because you want to avoid link dependencies on 3rd party libsodium or libargon2 directly in slapd (and slappasswd) itself? Or just because it was previously a contrib module, and just copied over like that? By the way, while looking at the code, I noticed a typo in configure.ac: > if test "$ol_enable_argon2" = "yes" ; then > SLAPD_DYNAMIC_PWMODS="$SLAPD_DYNAMIC_PWDMODS argon2.la" > fi ^^ ^^^ It's referencing two different variables there, which is harmless today, but will be a build bug once multiple password modules become available. SLAPD_DYNAMIC_PWMODS is the correct one. Geert

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2023