openldap-technical

openldap-technical@openldap.org

18 participants
9785 discussions

Lock conflicts?
by rzhou44＠tutamail.com 12 Mar '24

12 Mar '24

At work we have a program that actively reads/writes into LMDB file. This program uses MDB_NOLOCK (why, I'm not sure yet). Can I safely read/write to this LMDB file using my own programs or mdb_ command line tools? I worry that those (which by default use lock files) could conflict with the manual locking of the existing program and cause data corruptions. Thanks -Zhou

2 3

Configure replication without a plaintext password.
by mbalakri＠opentext.com 08 Mar '24

08 Mar '24

How to configure olcSyncrepl without a plaintext password? I tried using credentials="{SSHA256}jRlrKRCcrhYo7SqbPDc5WkoSxaHc8y/e0DPWaAnveUkQpQ7wEOWhsw==" format. Does olcSyncrepl accepts password in {SSHA256} format?

5 8

LMDB fix sized key and data question
by anton＠pcloud.com 07 Mar '24

07 Mar '24

Hello, I'm designing an application that will use LMDB. All (or almost all) of my databases will have a fixed size integer key (64bit) and fixed size data. Data is larger than a single integer but generally in 16-32 bytes range (range is for different databases, each database has a fixed data format). I'll not have duplicate key records. I'll mostly insert and retrieve single records. The question is would I benefit and should I use MDB_DUPSORT|MDB_DUPFIXED? Also the documentation says that MDB_DUPFIXED may only be used with MDB_DUPSORT. However I see code that specifically checks for MDB_DUPFIXED without MDB_DUPSORT and only then sets a flag for DUPFIXED records. However I did not get too deep in the code. https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L7743 My point is that with fixed sized keys and values the btree may chose not to store record sizes, may not use pointers for the binary search but to search values instead and so on. Is that the optimization that is being done for MDB_DUPFIXED or is it something that only concerns duplicate values? Best, Anton

2 1

Counter concurrency access
by Pascal Jakobi 06 Mar '24

06 Mar '24

Hi there I am creating a program that needs to increment a counter. Typically a serial number has to be incremented every time I create a certificate. The problem is to handle concurrent access. Fundamentally I need to 1/ read the counter 2/ increment it. Therefore no one must be provided access to the counter during these two operations. Therefore I need to set a lock before the read operation and release it after the update. Is there a way to do this with OL ? I am conscious of the ldapmodify features thanks to Clement, however, this will not lock the read. Thks in adv. P

2 2

slapo-translucent bug?
by Marco Esposito M. 05 Mar '24

05 Mar '24

Dear openldap-technical, I have encountered an issue with slapo-translucent and I am trying to determine whether it is a problem with my configuration or a bug. By mistake, I opened a ticket on OpenLDAP ITS, and rightfully, I have been redirected here. https://bugs.openldap.org/show_bug.cgi?id=10184 The problem is as follows: the results from a translucent OpenLDAP server do not return any entry when a single attribute is present in the query filter. This attribute has been previously modified and is present in the local database of the translucent OpenLDAP server. To better explain the issue, I have set up an environment with containers. The repository is as follows: https://github.com/voidloop/openldap-bug To bring up the environment, two commands are needed: % make submodules % make docker-run Three containers will be running: upstream: a simple LDAP server with a couple of users, listening on port 51389/tcp. buggy: the translucent server from upstream with the problematic behavior, listening on port 52389/tcp. compiled: the translucent server from upstream recompiled with the modified code where I suspect there might be an issue, listening on port 53389/tcp. The containers are simple Fedora instances with OpenLDAP. Once the following ldapmodify command is executed: % ldapmodify -x -D cn=buggy,dc=example,dc=com -w password -H ldap://:52389 <<EOF dn: uid=ciccio,ou=people,dc=example,dc=com changetype: modify replace: uidNumber uidNumber: 99 EOF The following occurs: 1) Querying servers without filters: ------------------------------------------------------------------------------- Server "upstream" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:51389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "buggy" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:52389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 99 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "compiled" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:53389 -b ou=people,dc=example,dc=com uid=ciccio # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: ALL # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount uid: ciccio cn: Ciccio Bello sn: Bello uidNumber: 99 gidNumber: 1000 homeDirectory: /home/ciccio # search result search: 2 result: 0 Success # numResponses: 2 So far, everything is okay, no anomalous behavior. The issue arises when a filter is introduced. 2) Querying servers with a filter ------------------------------------------------------------------------------- Server "upstream" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:51389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com uidNumber: 1000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------------------------------------------------- Translucent server "buggy" (!!) ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:52389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # search result search: 2 result: 0 Success # numResponses: 1 ------------------------------------------------------------------------------- Translucent server "compiled" ------------------------------------------------------------------------------- % ldapsearch -x -H ldap://:53389 -b ou=people,dc=example,dc=com uid=ciccio uidNumber # extended LDIF # # LDAPv3 # base <ou=people,dc=example,dc=com> with scope subtree # filter: uid=ciccio # requesting: uidNumber # # ciccio, people, example.com dn: uid=ciccio,ou=people,dc=example,dc=com uidNumber: 99 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Why does this behavior occur? I expect the "buggy" server to return the uidNumber attribute. The version of OpenLDAP in the container is the one installed with the Fedora package manager. Server configurations are available in the Git repository, but for convenience, I am listing them here: upstream: https://github.com/voidloop/openldap-bug/blob/main/upstream/slapd.ldif https://github.com/voidloop/openldap-bug/blob/main/upstream/entries.ldif buggy: https://github.com/voidloop/openldap-bug/blob/main/buggy/slapd.ldif compiled: https://github.com/voidloop/openldap-bug/blob/main/compiled/slapd.ldif The source code modification is as follows: % diff openldap/servers/slapd/overlays/translucent.c translucent.c -u --- openldap/servers/slapd/overlays/translucent.c 2024-02-29 11:30:52.620837844 +0100 +++ translucent.c 2024-02-29 11:14:11.274843929 +0100 @@ -928,16 +928,7 @@ /* send it now */ rs->sr_entry = re; rs->sr_flags |= REP_ENTRY_MUSTBEFREED; - if ( test_f ) { - rc = test_filter( op, rs->sr_entry, tc->orig ); - if ( rc == LDAP_COMPARE_TRUE ) { - rc = SLAP_CB_CONTINUE; - } else { - rc = 0; - } - } else { - rc = SLAP_CB_CONTINUE; - } + rc = SLAP_CB_CONTINUE; } } else if ( le ) { /* Only a local entry: remote was deleted I have also found posts from individuals who have identified the same issue, but either received no response or the response was unsatisfactory: https://openldap.org/lists/openldap-technical/201304/msg00069.html https://www.openldap.org/lists/openldap-bugs/200905/msg00159.html https://www.openldap.org/lists/openldap-technical/201106/msg00036.html Thank you for your attention, and I apologize for the lengthy message. Marco

2 2

OpenLDAP SQL
by kimkihoon 05 Mar '24

05 Mar '24

I'm trying to use mysql external db server for openLDAP db. I just read this README file from openldap github(https://github.com/openldap/openldap/blob/master/servers/slapd/back-… But it seems only localhost server can be used. Can anyone tell me how? Thx for the help

3 2

Fwd: New Ldap 2.6.6 in Kubernetes
by Jignesh Patel 01 Mar '24

01 Mar '24

We have set up a new docker OpenLDAP Version 2.6.6 on Kubernetes. We could migrate all the data except the following two attributes *authTimestamp* and *lastLoginTime* not working in personalized schema. How to configure them?

2 1

Disable uniqueness for mail Attribute
by CALDEIRA JAVIEL Sandro 01 Mar '24

01 Mar '24

Hi, I have a legacy ldap instance (openlda-2.4) which has in the same redundant user info containing mail attribute among others (objectclass: inetOrgPerson) in 2 different ous (objectclass: organizationalUnit). I know it is a bad design for ldap users structure but I am not allowed to change it in a short time. When I tried to migrate this ldap database to openldap 2.6 I realize this is not possible anymore. I identified it is just related to mail attribute because if I omit mail attribute or use a different value for mail, then all data is imported properly. Error from phpldapadmin: Attribute value would not be unique This update has been or will be cancelled, it would result in an attribute value not being unique. You might like to search the LDAP server for the offending entry. (Search) warn LDIF text import Could not add object cn=*****,ou=Users,ou=TRG01,dc=***,dc=*****,dc=** LDAP said: Success Error number: 0x00 (LDAP_SUCCESS) Description: The operation completed successfully.

3 9

memberOf with groupOfNames
by Stefan Kania 01 Mar '24

01 Mar '24

Hi to all, up to now I only used: olcDlAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames to dynamically add the Attribute memberOf to all members of a groupOfURLs. Is it possible to do the same with members for groupOfNames and groupOfUniqueNames? I yes, can someone please post the syntax? Stefan

2 3

All LDAP content is not replicating to Node2 with replication message 'not new enough, ignored'
by mbalakri＠opentext.com 15 Feb '24

15 Feb '24

Hello, We need some help to resolve the intermittent sync replication issue. We have configured mirror mode replication with two nodes. Node1 syncrepl {0}rid=1 provider=ldaps://AWPCISQL22.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="60 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCISQL22.otxlab.net-key.pvk" Node2 syncrepl {0}rid=2 provider=ldaps://AWPCTHA1.otxlab.net:6366 type=refreshAndPersist searchbase="o=otxlab.net" schemachecking=off bindmethod=simple binddn="cn=Directory Manager,o=otxlab.net" credentials=d retry="60 10 300 +" timeout=60 tls_reqcert=never tls_cacert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_cert="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-cert.cer" tls_key="C:\Program Files\OpenText\CARS\defaultInst\certificates\AWPCTHA1.otxlab.net-key.pvk" olcMultiProvider is ON. We have tested replication and observed that inserting an entry into Node1 syncs to Node2, and adding an entry to Node2 syncs to Node1. Similarly, delete and update operations are working as expected. However, during continuous updates to Node1 (while both Node1 and Node2 are running, and operations like importing an .ldif file from JXplorer to Node1), some entries are not syncing to Node1. The replication logs show the following message: "rid=002 entry 'cn=GetCollection,cn=Method Set ISVPackage,cn=Cordys ESBServer,cn=cordys,cn=defaultInst,o=otxlab.net' csn=20231124172411.004202Z#000000#001#000000 not new enough, ignored" We created ticket 10136 to address this issue but did not identify the root cause initially. Upon analysis, we found that all entries producing the "not new enough, ignored" message are not syncing to Node2. We were previously using OpenLDAP 2.4 version, and this scenario worked correctly. However, we started noticing the issue after upgrading to OpenLDAP 2.5.13 version. Upon reviewing the syncrepl defect fixes, we identified this fix: https://git.openldap.org/openldap/openldap/-/commit/8d428f3163e56f90cb84cdd…, which appears to be causing the problem. We reverted this fix locally, rebuilt OpenLDAP, and tested it. The issue is not reproducible with the reverted fix. In summary, the basic scenario of adding entries to Node1 is not syncing to Node2 sometimes. Do you have any suggestions to avoid this issue?

1 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical