openldap-technical

openldap-technical@openldap.org

18 participants
9837 discussions

accesslog seemingly needs a lot of space
by Windl, Ulrich 14 Mar '25

14 Mar '25

Hi! Trying to convert my syncrepl configuration to a delta syncrepl configuration, the slave runs out of accesslog space during initial sync. For the main database about 30MB should be enough, but I configured 50MB, also for the accesslog files. It seems sync continues even if accesslog periodically complains like this: slapd[13951]: => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) slapd[13951]: conn=-1 op=0 accesslog_response: got result 0x50 adding log entry reqStart=20250314110032.000187Z,cn=changelog-1 From stat I guess that accesslog needs at least three times as much space as the main database does: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259467 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.303713632 +0100 Modify: 2025-03-14 12:01:08.417328586 +0100 Change: 2025-03-14 12:01:08.417328586 +0100 Birth: 2025-03-14 11:57:46.303713632 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 52424704 Blocks: 102392 IO Block: 4096 regular file Device: 33h/51d Inode: 259471 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.323713395 +0100 Modify: 2025-03-14 12:01:08.425328492 +0100 Change: 2025-03-14 12:01:08.425328492 +0100 Birth: 2025-03-14 11:57:46.323713395 +0100 Shouldn't (assuming the sync happens entry-by-entry) the accesslog have about the same size as the main database after initial sync (when all databases were empty)? When setting the size of the accesslog database to twice the size of the database it succeeded which stats like this: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259514 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.278545521 +0100 Modify: 2025-03-14 12:45:03.558274733 +0100 Change: 2025-03-14 12:45:03.558274733 +0100 Birth: 2025-03-14 12:39:01.278545521 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 89657344 Blocks: 175112 IO Block: 4096 regular file Device: 33h/51d Inode: 259518 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.298545286 +0100 Modify: 2025-03-14 12:45:03.566274639 +0100 Change: 2025-03-14 12:45:03.566274639 +0100 Birth: 2025-03-14 12:39:01.298545286 +0100 So the blocks in the accesslog are roughly four times (3.91 ) as much as in the original database. Is there any doc making statements about the proportion? (I'm a fan of "small is beautiful" instead of "bigger is better") Kind regards, Ulrich Windl

2 1

Trying to set 'olcPasswordHash' I get "ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed"
by Windl, Ulrich 14 Mar '25

14 Mar '25

Hi! After having loaded pw-sha2 in oOpenmLDAp 2.5, I tried to set a new default hashing schema, but I fail to do so using dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcPasswordHash olcPasswordHash: {SSHA256} olcPasswordHash: {SSHA} ---- modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed Before I had tried "replace" instead of "add", and I tried to place both values in one line as suggested by slapd-config: olcPasswordHash: <hash> [<hash>...] This option configures one or more hashes to be used in generation of user passwords stored in the userPassword attribute during processing of LDAP Password Modify Extended Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}. The manual page also states: This setting is only allowed in the frontend entry. I'm running out of ideas. Kind regards, Ulrich Windl

3 8

Re: consumer replication not recovering
by Ondřej Kuzník 14 Mar '25

14 Mar '25

On Wed, Mar 12, 2025 at 03:10:12PM -0400, Suresh Veliveli wrote: > Here it is. Hi Suresh, I apologise for not really getting back to you for a while, rest assured I'm still thinking about it. However I'm still confused what might be happening and don't have much in terms of advice yet except that yes, the two (replication effectively stopping and the crash) seem to be two symptoms of the same issue. It looks like you're building OpenLDAP yourself, would you be able to apply a patch or two adding extra information to the sync logs that might help us trace this better? Are you able to compile and run OpenLDAP with -fsanitize=address in CFLAGS or an equivalent? > [root@...] # gdb ... > Reading symbols from /var/services/openldap/libexec/slapd... > BFD: warning: > /var/users/suresh.a/core.slapd.3003.bea19f5a376843abb488dce68d6e81af.5036.1741456520000000 > has a segment extending past end of file > [...] > warning: Error reading shared library list entry at 0x696e6e75723a5652 > Cannot access memory at address 0x69626f6e6e613a5e > Cannot access memory at address 0x69626f6e6e613a56 > Failed to read a valid object file image from memory. > [...] > Thread 2 (LWP 5036): > #0 0x00007f792d8868ba in ?? () > No symbol table info available. > Backtrace stopped: Cannot access memory at address 0x7ffebb22d9a0 I am a little concerned by the above warnings and the fact gdb is unable to extract any stack information at all from most threads. Doesn't seem to correspond what I'd usually see even when debugging information is missing. > Thread 1 (LWP 7650): > #0 connection_abandon (c=0x7f79158a5ba8) at connection.c:714 > o = 0x7f5fa0148170 > next = 0x7f5f90010300 In this frame, would you be able to print the following and paste/attach them here? - '*c' - '*o' - '*o->o_hdr' Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Request for Guidance on Upgrading from 2.4.x(BDB with ppolicy) to 2.6.9
by anilkumar.pathuri7＠gmail.com 13 Mar '25

13 Mar '25

Dear LDAP Community, We are planning to upgrade our setup from OpenLDAP 2.4.x to 2.6.9 (latest version) and would appreciate your guidance on the following: Is a direct upgrade from 2.4.x to 2.6.9 possible, or are there intermediate steps required? We are currently using BDB with ppolicy. Does 2.6.9 support BDB, or is migration to MDB mandatory? Is ppolicy still supported in 2.6.9? Are the ppolicy module and schema included in 2.6.9, or do they need to be obtained externally? If a migration from BDB with ppolicy to MDB with ppolicy is required, could you kindly provide step-by-step guidance? We greatly appreciate any insights, documentation, or recommendations you can share. Thank you for your support! Regards, Anil P

3 3

Re: consumer replication net recovering
by Suresh Veliveli 12 Mar '25

12 Mar '25

This is another instance where replication stops. Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060050.594465Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=xxxx,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=xxxxx,ou=People,dc=georgetown,dc=edu (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_message_to_entry: rid=143 DN: uid=xxxxx,ou=People,dc=georgetown,dc=edu, UUID: db41232e-527d-103f-995c-4344349468b5 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060104.603554Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=yyyyy,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=yyyy,ou=People,dc=georgetown,dc=edu (0) No "syncrep_" messages were logged after the above. Regards, Suresh On Mon, Dec 23, 2024 at 2:42 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 5:46 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have these but no syncrepl_sync. > > > > > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_message_to_entry: > > rid=129 DN: uid=xxxx,ou=xxxx,dc=georgetown,dc=edu, UUID: > > 37387976-3ae0-103f-94fc-3b4be3361dc7 > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_entry: rid=129 > > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > > csn=20241212135921.652395Z#000000#000#000000 tid 0x7f671b7fe640 > > Yes sorry, that was a typo on my end. > > "syncrepl_" sync messages. Specifically you want to see the ones that > have > "be_" in them, but not "be_search". I.e., be_add, be_modify, etc. They > show the result of the operation, something like: > > syncrepl_entry: rid=100 be_modify <DN> (<result code>) > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

5 30

LMDB: issues when resizing via set_mapsize
by Stefan de Konink 12 Mar '25

12 Mar '25

Hi, Some background; a Windows user of my open source ETL software complained about the huge files. Under Linux I don't have any issues, but I wanted to resolve this issue by implementing automatic growth via a pattern: MapFullError, set_mapsize, apply writing batch again. This week I entered a bug[1] which was stated as not a bug in LMDB. Today I ended up in build/lib/mdb.c:5966: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() which also seem I am not the only one hitting, and several fixes have been introduced. The issue does not occur every time when the resize takes place, but can be consistently reproduced given the same input. The error will then occur at the same place. When my initial size is big enough, not to resize there is no issue. In short I am using py-lmdb to access a read only env, and in a second thread a write function is launched which reads out a queue. Upon the MapFullError I am linearly increasing the mapsize, and continue with the failed batch. I have four dupSort tables, the rest is ordinary. I was pointed in the bug at the documentation. One sentence struck me: "It may be called at later times if no transactions are active in this process." My assumption was that if I would have two independent env's I could do whatever I wanted in the first, and the second could do its resize. Does the documentation suggest that the full application must finish all its transactions independent of env? [1] https://bugs.openldap.org/show_bug.cgi?id=10316 -- Stefan

2 1

ldap proxy
by fred750164＠gmail.com 11 Mar '25

11 Mar '25

I want to set up an architecture that allows a client to query an LDAP backend via an LDAP proxy. I want the query from the client to be unsecured, but the proxied communication between the LDAP proxy and the LDAP backend to be secured through mutual TLS authentication via SASL EXTERNAL. What configurations need to be implemented on the LDAP proxy and the LDAP backend? I saw in the slapd-ldap(5) documentation that the idassert-bind parameter could be used on the LDAP proxy for the TLS connection via SASL EXTERNAL, and in the slapd.conf(5) documentation that the authz-regexp parameter could be used on the LDAP backend to allow querying with a DN extracted from the certificate on this LDAP backend. However, I am struggling to set it up. I use openldap 2.4. slapd.conf on proxy server: [...] Database ldap suffix dc=test,dc=com uri ldaps://mytest.com:636 idassert-bind mode=self bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/certs/server.crt tls_key=/etc/openldap/certs/server.key tls_cacert=/etc/ssl/certs/ca-bundle.crt tls_cacertdir=/etc/ssl/certs tls_crlcheck=none tls_reqcert=allow [...] slapd.conf on backend server: [...] # Modules moduleload back_mdb moduleload authz-regexp # TLS TLSCACertificateFile /opt/openldap/etc/openldap/certs/ca-certificates.crt TLSCertificateFile /opt/openldap/etc/openldap/certs/backend.crt TLSCertificateKeyFile /opt/openldap/etc/openldap/certs/backend.key TLSCipherSuite HIGH TLSVerifyClient demand sasl-Host mytest.com sasl-realm EXTERNAL authz-regexp ".*" "cn=user1,dc=test,dc=com" [...] proxy: ldapsearch -H ldaps://mytest.com -b "dc=appli,dc=test,dc=com" -Y EXTERNAL -ZZ ldap_start_tls: Can't contact LDAP server (-1) backend: 67895427.2b4074ce 0x7f7e6bffe6c0 TLS: can't accept: error:0A0000C7:SSL routines::peer did not return a certificate. Any help would be appreciated.

7 38

meta backend : forward the credentials to the server ?
by carnival＠protonmail.com 07 Mar '25

07 Mar '25

Hello, I'm trying to configure a proxy with slapd-meta. I have my data on a OpenLDAP server ldap-1.example.org and my meta backend setup on ldap-proxy.example.org. Here is the main part of my conf : # {2}meta, config dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=test,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=bind,dc=test,dc=com olcRootPW: password olcDbRebindAsUser: FALSE # {0}uri, {2}meta, config dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config objectClass: olcMetaTargetConfig olcMetaSub: {0}uri olcDbURI: "ldap://ldap-1.example.org:389/ou=dpt,dc=test,dc=com" olcDbIDAssertBind: mode=none flags=non-prescriptive,proxy-authz-non-critical b indmethod=simple timeout=0 network-timeout=0 binddn="cn=manager" cr edentials="password" keepalive=0:0:0 olcDbRewrite: {0}suffixmassage "ou=dpt,dc=test,dc=com" "ou=dpt,dc=test,dc= com" olcDbRebindAsUser: FALSE It's work fine, when I do a ldapsearch on ldap-proxy.example.org I retrieve my data stored on ldap-1.example.org. But in order to do that, I'm forced to use unique and administrative accounts : cn=bind,dc=test,dc=com for my proxy and cn=manager for my main LDAP server. For security reasons, I would like to avoid using an admin account for binding and instead use any user credentials I choose to connect to the target servers for searches beyond the first target (my proxy). For example, if I have an account named ou=account,dc=test,dc=com on my LDAP server, I would like to bind my proxy directly with this account and dynamically propagate the credentials for verification on my LDAP server, returning the results if the credentials are correct. I thought that "rebind-as-user YES" would resolve this, but it doesn't work. Is there something I'm missing? Thanks ! Arthur

1 0

Getting details for "TLS trace: SSL3 alert read:fatal:unsupported certificate"
by Windl, Ulrich 06 Mar '25

06 Mar '25

Hi! After "playing" significant time with certificate authentication, I managed to authenticate one user. However when I tried to authenticate a different user with a similar certificate, I see a TLS trace: SSL3 alert read:fatal:unsupported certificate Error. Can I can some details about the "usupportedness" of my certificate? The only thing I could think if is that uid of the newer certificate has a CN that is three characters longer than the one that worked. A more complete trace for ldapwhoami woul look like this: ... ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS trace: SSL_connect:TLSv1.3 read encrypted extensions TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS certificate verification: depth: 2, err: 0, subject: /.... Root-CA (2018), issuer: /... Root-CA (2018) TLS certificate verification: depth: 1, err: 0, subject: /... Host-CA (2018), issuer: /... Root-CA (2018) TLS certificate verification: depth: 0, err: 0, subject: /... FQHN, issuer: /... Host-CA (2018) TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:TLSv1.3 read server certificate verify TLS trace: SSL_connect:SSLv3/TLS read finished TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write client certificate TLS trace: SSL_connect:SSLv3/TLS write certificate verify TLS trace: SSL_connect:SSLv3/TLS write finished ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_int_sasl_open: host=FQHN SASL/EXTERNAL authentication started ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 26 bytes to sd 3 ldap_msgfree ldap_result ld 0x56432476ac30 msgid 2 wait4msg ld 0x56432476ac30 msgid 2 (infinite timeout) wait4msg continue ld 0x56432476ac30 msgid 2 all 1 ** ld 0x56432476ac30 Connections: * host: FQHN port: 389 (default) * from: IP=172.20.16.36:57868 refcnt: 2 status: Connected last used: Wed Mar 5 15:42:03 2025 ** ld 0x56432476ac30 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x56432476ac30 request count 1 (abandoned 0) ** ld 0x56432476ac30 Response Queue: Empty ld 0x56432476ac30 response count 0 ldap_chkResponseList ld 0x56432476ac30 msgid 2 all 1 ldap_chkResponseList returns ld 0x56432476ac30 NULL ldap_int_select read1msg: ld 0x56432476ac30 msgid 2 all 1 ber_get_next TLS trace: SSL3 alert read:fatal:unsupported certificate ber_get_next failed, errno=0. ldap_err2string ldap_sasl_interactive_bind: Can't contact LDAP server (-1) ... Kind regards, Ulrich Windl

3 5

Q: Uniqueness of syncrepl rid
by Windl, Ulrich 04 Mar '25

04 Mar '25

Hi! I have a question on the uniqueness of rid in syncrepl: Do they have to be globally unique, or just unique within a database (olcDatabase config)? Kind regards, Ulrich Windl

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical