openldap-technical

openldap-technical@openldap.org

17 participants
9883 discussions

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

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

OlcLimits : sizelimit exceeded (openldap 2.5.16)
by bourguijl＠gmail.com 03 Mar '25

03 Mar '25

Dears, I've an issue with one user for which I set its limits to "unlimited" but which get err=4 (sizelimit exceeded). This is in the context of a META ldap fronted to a ldap backend. If I do the ldapsearch of this user in CLI directly on the ldap backend where the OlcLimits are set for it, this works perfectly, no err=4 errors but if this ldapsearch comes from the META ldap frontend with the same user which is used in the olcDbIDAssertBind as Binddn, it's failling with err=4 !!?? I did check ldap logs at back end and they are identical in both cases except the err=4. I don't see what can be the cause ?? Any help will be appreciate !! Thx in advance, Jean-Luc.

2 1

How to start debugging olcAuthzRegexp?
by Windl, Ulrich 03 Mar '25

03 Mar '25

Hi! I tried to remove the credentials from my syncrepl configuration using certificate authentication instead. To do so I added a user certificate for my own user and tried ldapwhoami to verify that it works. Unfortunately it does not. I read quite a lot on the subject, and either all the descriptions are all poorly written and incomplete, or it must be very simple to get it running. However I failed so far. My suspect is that my olcAuthzRegexp does not properly map the certificate's name to the user, or the mapping is not called at all. Can anybody provide a sample configuration for the client user to verify the configuration, and maybe give an example on the server side to get it working. What I have tried so far is having a ~/ldaprc with: TLS_REQCERT demand TLS_CACERT ./User-CA.crt TLS_CERT ./uid=user.crt TLS_KEY ./uid=user.pem LDAPSASL_MECH external And I tried the command "ldapwhoami -H ldap://FQHN -D uid=user,cn=gssapi,cn=auth -Z -v" I tried these olcAuthzRegexp: olcAuthzRegexp: {1} "C=DE,...,O=...,uid=([^,]+)" uid=$1,ou=people,dc=...,dc==de olcAuthzRegexp: {2} "^uid=([^,]+),cn=gssapi,cn=auth$" uid=$1,ou=people,dc=...,dc=de (I left out the details of the certificate and directory contexts) Kind regards, Ulrich Windl

4 3

manual page slapd-mdb.5 and "maxsize"
by Windl, Ulrich 03 Mar '25

03 Mar '25

Migrating to OpenLDAP 2.5 and MDB I hit the default 10MB limit (when trying to import a 6.8MB LDIF). Seeking how to extend the size online, I found: maxsize <bytes><https://manpages.debian.org/testing/slapd/slapd-mdb.5.en.html#maxsize> Specify the maximum size of the database in bytes. A memory map of this size is allocated at startup time and the database will not be allowed to grow beyond this size. The default is 10485760 bytes. This setting may be changed upward if the configured limit needs to be increased. However it's completely non-obvious that the name for cn=config is "olcDbMaxSize" (and not "olcMaxssize"). (The final MDB file size was about 23MB, including the indices) Kind regards, Ulrich Windl

4 6

← Newer
1
2
3
4
5
6
7
8
9
...
989
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical