openldap-technical August 2024

openldap-technical@openldap.org

19 participants
21 discussions

Push-based synchronization & dynamic attributes
by Benjamin Renard 13 Aug '24

13 Aug '24

Hello, Since updating our LDAP infrastructure to OpenLDAP 2.5 (2.5.13 from the Debian repository), we have encountered desynchronization issues with certain objects. The synchronization in place is in push mode as documented in the official documentation (https://www.openldap.org/doc/admin25/replication.html#Syncrepl%20Proxy). The problem seems to stem from the fact that we are using dynamic attributes via the dynlist overlay, and the master server attempts to push these dynamic attributes to the slave servers when modifications are made to these objects, which the slaves refuse. Log extract from one of our slave servers: Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 MOD dn="uid=ele-ladon-test,ou=contracts,o=easter-eggs" Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 MOD attr=eeTechnicalContact eeStartDate eeStorageDisks entryCSN modifiersName modifyTimestamp eeContractId eeContractIncludedService Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 RESULT tag=103 err=16 qtime=0.000022 etime=0.000536 text=modify/delete: eeContractId: no such attribute Note: The attribute eeContractId is a dynamic attribute of the object in question. Previously, with OpenLDAP 2.4, we did not have this issue, and the attributes were dynamic (and therefore managed by dynlist) on both our master server and slave servers. To immediately resolve this problem, we have removed the dynlist configuration on our slave servers. These attributes are therefore "static" on our slave servers, and desynchronizations are potentially possible. How can we correctly manage this situation? Please note that some of the affected attributes are both static on certain objects and dynamic on others, so we cannot simply exclude them completely from synchronization. Thank you in advance. -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

1 0

Help using the memberOf overlay
by awoestmann＠intevation.de 12 Aug '24

12 Aug '24

Hi everyone, i am trying to set up a OpenLDAP (2.6.7 in a Ubuntu noble container) with the memberOf Overlay activated. Adding the users and groups seems to work fine but i was not yet able to activate the overlay and query the memberships of a given user. I am using the following ldif to load the overlay: dn: cn=module,cn=config cn: module objectClass: olcModuleList olcModuleLoad: memberof olcModulePath: /usr/lib/ldap dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf The config is added using "slapadd -n0 -l /path/to/ldif", after that i add the users using slapadd. To check if the overlay works i am trying to query the memberOf attribute using ldapvi: "ldapvi --discover "(uid=exampleUid)" memberOf" Does anyone has a hint for me what i am doing wrong? Best regards, Alexander

5 5

LMDB write commit time hockey-sticks
by Alec Matusis 12 Aug '24

12 Aug '24

Problem: Our application first writes data into LMDB. After the data is written, the LMDB is used in the read-only mode. Our problem is that writing commit time hockey-sticks. Here is the graph on the machine with 128GB of RAM: https://i.imgur.com/py83dRV.jpeg (happens at 3200) We used a virtual machine with 16 GB, to wait less for this hockey-stick: https://i.imgur.com/CYohM3O.jpeg (red curve is the commit time, happens at 3080; the lmdb env stats are on the bottom graph. Size on the top graph is total program size from /proc/[pid]/statm) . We tried various combinations of environment flags: MDB_WRITEMAP, MDB_MAPASYNC, MDB_NOSYNC and MDB_NOMETASYNC. We also tried increasing mapsize. Nothing seems to matter (e.g. https://i.imgur.com/MkZJkxp.jpeg with 64G mapsize and MDB_NOSYNC), the best combination seems to be without any flags at all. Smaller mapsizes are worse, but increasing mapsize above 4GB in a 16GB RAM machine doesn't seem to gain anything. Can you recommend a way to prevent or delay this hockey-stick when we are in the write-only, append-only regime? We just want to write the data to disk fast, we don’t even need mmap() here, we will need it in the read-only mode later. Details: The environment contains two databases, one with no flags (keys are 32 bytes, values are 8 byte integers), second one with MDB_INTEGERKEY (keys are 8 byte integers, values are 32 bytes, uses MDB_APPEND for writing). All commits are similar sized, 6000-8000 pages (page size is 4096). Each commit therefore is ~400k keys total for boths dbs, (7000*4096/((32+8)*2). The VM has no disk swap, from perf output here https://i.imgur.com/zuTGawz.jpeg we can see that the machine is under page swap load. On a VM with 16GB RAM, hockey-stick happens when the LMDB size is only 1.5GB, 12% of the available RAM. Detailed stats: Below is the excerpt from the application log on each commit, the same data is plotted in the linked graphs above. Memory stats are from. /proc/[pid]/statm , lmdb stats are from the environment.“Difference” the time the commit takes, it degrades from 45 seconds to 3+ minutes. Final LMDB size in this log is pgs_in_use 448993*4096 = 1.84GB. Start of log before write degradation: 2024-08-09 02:26:19 [INFO][src/importer.rs:198] File 3054: 132932384 bytes. Memory stats: Size: 27540910 pages, Resident: 286072 pages, Shared: 99484 pages, Text: 981 pages, Data: 191849 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 108959 last_txnid 18 max_readers 126 num_readers 1 free_pgs 56171 pgs_in_use 52788 Difference: 0 min 44 sec 2024-08-09 02:27:03 [INFO][src/importer.rs:198] File 3055: 133951354 bytes. Memory stats: Size: 27541730 pages, Resident: 298463 pages, Shared: 111020 pages, Text: 981 pages, Data: 192669 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pg s 0 last_pgno 121928 last_txnid 19 max_readers 126 num_readers 1 free_pgs 62881 pgs_in_use 59047 Difference: 0 min 48 sec 2024-08-09 02:27:51 [INFO][src/importer.rs:198] File 3056: 133218473 bytes. Memory stats: Size: 27543735 pages, Resident: 313441 pages, Shared: 123980 pages, Text: 981 pages, Data: 194674 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pg s 0 last_pgno 133243 last_txnid 20 max_readers 126 num_readers 1 free_pgs 69672 pgs_in_use 63571 Difference: 0 min 40 sec …… End of log after write degradation: 2024-08-09 04:39:33 [INFO][src/importer.rs:198] File 3127: 132694310 bytes. Memory stats: Size: 27654397 pages, Resident: 1028693 pages, Shared: 727992 pages, Text: 981 pages, Data: 305336 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 745440 last_txnid 91 max_readers 126 num_readers 1 free_pgs 308699 pgs_in_use 436741 Difference: 2 min 36 sec 2024-08-09 04:42:09 [INFO][src/importer.rs:198] File 3128: 133418687 bytes. Memory stats: Size: 27654397 pages, Resident: 1033516 pages, Shared: 732815 pages, Text: 981 pages, Data: 305336 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 745440 last_txnid 92 max_readers 126 num_readers 1 free_pgs 304043 pgs_in_use 441397 Difference: 3 min 18 sec 2024-08-09 04:45:27 [INFO][src/importer.rs:198] File 3129: 133118782 bytes. Memory stats: Size: 27654397 pages, Resident: 1043876 pages, Shared: 743175 pages, Text: 981 pages, Data: 305336 pages, lmdb: dict_env: branch_pgs 0 leaf_pgs 1 of_pgs 0 last_pgno 762922 last_txnid 93 max_readers 126 num_readers 1 free_pgs 313929 pgs_in_use 448993

1 0

ppolicy: passing operational attribute changes from replica to provider
by Nick Urbanik 08 Aug '24

08 Aug '24

Dear Team, I love your work. in man(5) slapo-ppolicy we see: "In general, authentication attempts on a replica server only affect the copy of the operational attributes on that replica and will not affect any attributes for a user's entry on the provider." I would prefer to have the replica send the changes to the provider. Is the chain overlay the right approach for this?

2 1

Understanding LDAP vs shadow password policies
by Windl, Ulrich 08 Aug '24

08 Aug '24

Hi! I'm writing a tool that checks password policy provided by LDAP against the attributes defines in shadowAccount. For example shadowLastChange vs. pwdChangedTime. For one account I see: pwdChangedTime 20240806150232Z shadowLastChange 16000 (I have no idea where that 16000 came from, but the difference is almost 10 years if I understood it correctly) Sorry, for the ignorance, but *who* is expected to update those attributes on password change (assuming UNIX/Linux "passwd" is being used)? Could it be a permission problem when isn't updated? Also it seems to me that the "old LDAP client" is using shadowAccount attributes to display an expiration warning, while the newer sssd seems to use the LDAP password policy attributes instead. The original reason for writing the tool was users complaining that they didn't get a warning when their password was expired and grace logins were being used (and eventually the account being locked). I have a similar question: How many failed login attempts (pwdFailureTime) are being stored, and who will remove the attributes? We have a setting that at most 10 bad authentication attempts (pwdMaxFailure ) are allowed, and that the failed attempts will be deleted after two weeks (pwdFailureCountInterval). However one user has 15 authentication failures recorded, and the first one is like 10 years old. Our platform is Linux (SLES 12/15), BTW. Regards, Ulrich

1 0

Re: Maximum Replicating Consumers
by Erik de Waard 06 Aug '24

06 Aug '24

Curious what's the rationale of using syncrepl over delta-syncrepl? We have 40 consumers (5GB data (and using syncrepl) no problems, but was interested in switching.. thought it might be more efficient. On Sat, Aug 3, 2024, 05:10 Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, August 2, 2024 9:15 PM +0000 thomaswilliampritchard(a)gmail.com > wrote: > > > OpenLDAP 2.4.56 (we are working to upgrade to OpenLDAP 2.5 LTS) > > Known issue with OpenLDAP 2.4 series. > > > We are configured with delta-syncrepl. > > I would recommend upgrading to the latest OpenLDAP 2.6 release and > switching to standard syncrepl. If you don't want to build OpenLDAP > yourself, the Symas packages are what I use in production. > > --Quanah >

3 3

Help debugging sync issue with accesslog
by BECOT Jérôme 06 Aug '24

06 Aug '24

Hello, We face sync issue between two servers (2.5.14) in mirrormode with accesslog. Some updates on groups are not replicated because the modification is not added to the accesslog where the modification is applied. There is no plain error when we ADD some groups (they are added to the DIT) but after enabling the 'sync' log level, we an see these errors: Aug 5 15:20:18 server1 slapd[15489]: conn=12173218 op=8040 accesslog_response: got result 0x50 adding log entry reqStart=20240805132018.000093Z,cn=accesslog We could find that it is probably due to olcAccessLogSuccess: TRUE, but the log follows with a normal result: Aug 5 15:20:18 server1 slapd[15489]: conn=12173218 op=8040 RESULT tag=105 err=0 qtime=0.000019 etime=0.034941 text= If we later update the group, a fullsync happens and the group is created on the other server. Since increasing loglevel may overwhelm the server, I didn't blindly try any other loglevels. How should I test and debug what makes the accesslog entry rejected (and thus, the object is not replicated) ? Thanks Jerome

3 3

Maximum Replicating Consumers
by thomaswilliampritchard＠gmail.com 05 Aug '24

05 Aug '24

Hi Friends, Is there a hard limit on the number of consumers that can replicate from a provider? I have a 3 provider master multi master configuration where each consumer is aware of all 3 providers and replicate with refreshAndPersist. Over time we find that the consumers stop getting updates from providers. We enabled keepalive on our replication configs and see that keepalive takes effect. After the idle timer expires keepalive seems to think the connection is still active. Is it possible the providers simply stop pushing changes to some consumers, or fail to push to some at a high number of consumers? What would be the potential failures modes of providers who are expected to push to a high number of consumers? Thanks for the considerations, Tom

2 9

Ordering index and integerOrderingMatch rule
by thierryblaise＠hotmail.com 05 Aug '24

05 Aug '24

Hi everyone, I posting again about my issue on my v2.5.18 OpenLDAP installation on RHEL8. I'm required by an editor to add a custom structural class to the LDAP schema, and especially afterwards to add an index on one interger attribute part of the new class. To that end, in openLdap, I think it means : 1) to my knowledge and following documentation (https://www.openldap.org/doc/admin25/schema.html#Attribute%20Type%20Specifi…), I need to declare an ordering matching rule in attribute definition of the schema. However, when I do that with the following olcAttributeTypes definition : olcAttributeTypes: ( 1.3.6.1.4.1.xxx.x.x.xxx NAME 'last-modified' DESC 'Object Last Modified Time' ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) and try to import the ldif containing this definition, the following error appears: modifying entry "cn={5}clients,cn=schema,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: olcAttributeTypes: AttributeType inappropriate matching rule: "integerOrderingMatch" I tried with all documented OrderingMatch rules in case, but same error modulo name of OrderingMatch rule appears each time, as if syntax and rule of the attribute don't match. Note that I tested the attribute definition without the ORDERING rule, the attribute is correctly added, but search with operators "<=" and ">=" are not working. 2) add an index to y MDB database through, for example, the following ldif: dn: olcDatabase={1}mdb,cn=config add: olcDbIndex olcDbIndex: last-modified <indexKeyword> However, here, I can't find the index keyword needed for ordering in the documentation... don't know if this is even supported. Can somebody please help me on those two topics ? Regards,

3 5

ldap_simple_bind_s is failing after setting LDAP_OPT_NETWORK_TIMEOUT value
by venugopal chinnakotla 05 Aug '24

05 Aug '24

Hi Team, We are working on migration of nsldap C sdk to OpenLDAP C sdk for our application client code. We are using OpenLDAP 2.6.7. As part of this migration activity, we are replacing one of the timeout values. Without setting LDAP_OPT_NETWORK_TIMEOUT value, ldap bind is working fine and application functionality also working well with bind, search and other operations. After setting LDAP_OPT_NETWORK_TIMEOUT value, ldap_simple_bind_s is failing with return code -1 (LDAP error -1-Unknown Error). Here is the snippet. struct timeval tv = { 20, 0 }; ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, (void *) &tv); lderr = ldap_simple_bind_s( ld, (char *)AdminDN, (char *)AdminPW); Here we are getting bind failure with return code as -1. But without setting LDAP_OPT_NETWORK_TIMEOUT, the bind function is working well. Could you help us to fix this issue? or let me know if I am missing anything here? -- Thanks, *c.venugopal*

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2024