openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Re: consumer replication net recovering
by Suresh Veliveli 13 Jan '25

13 Jan '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)

3 10

acl question
by Frédéric Goudal 13 Jan '25

13 Jan '25

Hello, I’m working on the acl on my ldap, and I have found a rule that puzzle me on it’s last statement : by * +0 break Well as 0 means no access what does +0 mean ? On my opinion it does nothing and the statement is equivalent to : by * break Am I correct or do I miss something ? f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 2

LDAP Tools don't use LDAP.conf
by maudez.eric＠neuf.fr 13 Jan '25

13 Jan '25

I notice that the ldap.conf file is not used with commands ldapsearch, ldapwhoami (ldap tools). An environment variable (LDAPCONF) was set and pointing to the file (/etc/openldap/ldap.conf) but it doesn't work. On the other hand, using the information provided in an ldaprc file works. How to ensure the LDAP.conf file is taken into account because I need it for a mutual authentication connection with the use of LDAPS for SASL EXTERNAL. I'm using an openldap 2.6.6 version on CentOS.

9 23

Re: [EXT] Re: consumer replication not recovering
by Suresh Veliveli 11 Jan '25

11 Jan '25

I got the debug info this time. Whenever I restart a stuck replica it is crashing the master. Hope the following will be helpful. Regards, Suresh ------------------- Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/var/services/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /var/serv'. Program terminated with signal SIGSEGV, Segmentation fault. #0 connection_abandon (c=0x7f27364cf0e8) at connection.c:714 714 op.orn_msgid = o->o_msgid; [Current thread is 1 (Thread 0x7f0d98cf5640 (LWP 2460))] (gdb) bt full #0 connection_abandon (c=0x7f27364cf0e8) at connection.c:714 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} o = 0x7f0d8413eab0 next = 0x7f0d74137490 op = {o_hdr = 0x7f0d98cf45e0, o_tag = 80, o_time = 0, o_tincr = 0, o_tusec = 0, o_qtime = {tv_sec = 0, tv_usec = 0}, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = { rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0, rs_newDN = {bv_len = 0, bv_val = 0x0}, rs_nnewDN = {bv_len = 0, bv_val = 0x0}}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = { stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 143657, oh_conn = 0x7f27364cf0e8, oh_msgid = 0, oh_protocol = 0, oh_tid = 0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\000' <repeats 255 times>} #1 0x00000000004460d5 in connection_closing (c=0x7f27364cf0e8, why=0x5db380 <conn_lost_str> "connection lost") at connection.c:785 __PRETTY_FUNCTION__ = "connection_closing" #2 0x0000000000447d18 in connection_read (s=25, cri=0x7f0d98cf49a0) at connection.c:1453 rc = -2 c = 0x7f27364cf0e8 __PRETTY_FUNCTION__ = "connection_read" #3 0x000000000044741b in connection_read_thread (ctx=0x7f0d98cf49f0, argv=0x19) at connection.c:1260 rc = 0 cri = {op = 0x7f0d74137490, func = 0x0, arg = 0x0, ctx = 0x7f0d98cf49f0, nullop = 0} s = 25 --Type <RET> for more, q to quit, c to continue without paging--c #4 0x00007f274ee74bed in ldap_int_thread_pool_wrapper (xpool=0xc9b0c0) at tpool.c:1059 pq = 0xc9b0c0 pool = 0xc9afc0 task = 0x7f0da01c5960 work_list = 0xc9b130 ctx = {ltu_pq = 0xc9b0c0, ltu_id = 139696375027264, ltu_key = {{ltk_key = 0x4be35e <slap_sl_mem_init>, ltk_data = 0x7f0d90000b60, ltk_free = 0x4be177 <slap_sl_mem_destroy>}, {ltk_key = 0x4466db <operation_counter_init>, ltk_data = 0x7f0d90100bb0, ltk_free = 0x44652a <conn_counter_destroy>}, {ltk_key = 0xf79390, ltk_data = 0x7f0d90101170, ltk_free = 0x539d95 <mdb_reader_free>}, {ltk_key = 0x519179 <search_stack>, ltk_data = 0x7f0d8a5fe010, ltk_free = 0x519155 <search_stack_free>}, {ltk_key = 0x515d3d <scope_chunk_get>, ltk_data = 0x7f0d981f4010, ltk_free = 0x515cf3 <scope_chunk_free>}, {ltk_key = 0x46103b <slap_op_free>, ltk_data = 0x7f0dc8694410, ltk_free = 0x460f8b <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 26 times>}} kctx = 0x0 i = 32 keyslot = 521 hash = 1213313545 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0x00007f274e489c02 in start_thread () from /lib64/libc.so.6 No symbol table info available. #6 0x00007f274e50ec40 in clone3 () from /lib64/libc.so.6 No symbol table info available. (gdb) On Wed, Jan 8, 2025 at 7:38 AM Suresh Veliveli < Suresh.Veliveli(a)georgetown.edu> wrote: > Hi Ulrich, > > Quanah helped to build one with debug and not stripped. > > Thanks, > Suresh > > On Wed, Jan 8, 2025 at 2:29 AM Windl, Ulrich <u.windl(a)ukr.de> wrote: > >> Hi! >> >> >> >> I don’t know the details of the build process, but sometimes RPM strips >> the binaries. Otherwis you could look for strip or a corresponding option >> in the Makefiles. >> >> >> >> Ulrich >> >> >> >> *From:* Suresh Veliveli <Suresh.Veliveli(a)georgetown.edu> >> *Sent:* Tuesday, January 7, 2025 8:22 PM >> *To:* Quanah Gibson-Mount <quanah(a)fast-mail.org> >> *Cc:* Windl, Ulrich <u.windl(a)ukr.de> >> *Subject:* [EXT] Re: consumer replication not recovering >> >> >> >> I used "make STRIP="" install" but it still installed the stripped >> version. I understand your suggestion. I don't have the appropriate access >> on my end to install Symas packages. I can only install the ones I build >> with a prefix limited to /var/services directory. >> >> >> >> Thanks, >> Suresh >> >> >> >> On Tue, Jan 7, 2025 at 2:07 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> >> wrote: >> >> >> >> --On Tuesday, January 7, 2025 11:22 AM -0500 Suresh Veliveli >> <Suresh.Veliveli(a)georgetown.edu> wrote: >> >> > >> > I downloaded the src - openldap-apkg26.tar.gz, removed the optimization >> > flags (export CFLAGS='-g'), configure, build and install, but still >> > installed the stripped version. Am I missing something? >> > >> > >> > [root@aaa-dev-gcp-1 libexec]# file slapd >> > slapd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically >> > linked, interpreter /lib64/ld-linux-x86-64.so.2, >> > BuildID[sha1]=547e20101751207ad48cc96006ea51e7610c7a1c, for GNU/Linux >> > 3.2.0, stripped >> >> This is basic software building, but: >> >> make STRIP="" install >> >> I still suggest using the Symas packages over building things yourself. >> >> --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) >> > > > -- > 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) > -- 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)

1 0

Unable to get the contextCSN
by Frédéric Goudal 08 Jan '25

08 Jan '25

Hello, I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $ It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000 where the csn is correct. What is strange is that if I try to get the contextCSN, from the directoryI have no value returned : /usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN # # search result search: 2 result: 0 Success # numResponses: 1 The olcSyncrepl value is : {0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbServiceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates I have several other secondary ldap from the same source, with the same confiiguration, except the filter is (objectClass=*) and there is no attrs value. I suspect the error is on the attrs or filter but what do I miss ? thanks in advance f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

3 6

Enabling PPolicy on a live LDAP...
by Marco Gaiarin 08 Jan '25

08 Jan '25

I need to enable PPolicy overlay to control passord policy on an existing LDAP installation. I have to expect some 'breakage'? Or policy attributes get defined only explicitly and have decent default? Speaking plainly: i have to expect to be cut off of my LDAP account immediately because i have my password old? Thanks. --

2 1

Re: [EXT] Re: Replication issues with openldap 2.5 {resolved}
by Ulises Gonzalez Horta 07 Jan '25

07 Jan '25

Can you please give an explanation of the full meaning?? That way we can learn because online it refers to invalid credentials, providing the user is good, then the password is what left over See this example where I intentionally put the wrong password root@nm03-lab-roc1:~/openldap_config_tree/2.1_replication# ldapsearch -Z -LLL -H ldap://servert:389 -D "uid=user,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=* ugonzalezhorta(a)breezeline.com)" cn Enter LDAP Password: ldap_bind: Invalid credentials (49) Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com> On Fri, Jan 3, 2025 at 2:16 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 3, 2025 8:49 AM -0500 Ulises Gonzalez Horta > <ugonzalezhorta(a)breezeline.com> wrote: > > > > > > > Yeah, the error message was misleading here, error 49 is wrong password, > > but I knew for sure the password was right. > > Maybe a log entry as the one you suggested will help you fast pinpoint > > the issue > > That's not what result code 49 means. > > --Quanah > >

2 2

monitoring MMR sync
by Dave 07 Jan '25

07 Jan '25

Hello Everyone, Hope you are enjoying the day. Was curious what people are doing to monitor their MMR clusters being out of sync. At least the implementation we found and have been trying is using telegraf and the [ldap_org](https://github.com/falon/CSI-telegraf-plugins/blob/master/plugins… plugin to gather all objects on each ldap master and compare their count. How is the community doing it? Any better way to go about this? Any input is appreciated! Best, Dave

6 7

Re: consumer replication not recovering
by Suresh Veliveli 07 Jan '25

07 Jan '25

It was "bdb". For migration, we did a clean install, used "slapcat" to export the db and "slapadd" to import. We used this procedure a number of times in the past when we switched OS, for upgrades etc. Do you have a recommended procedure in mind? Regards, Suresh On Mon, Jan 6, 2025 at 6:36 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, January 6, 2025 10:33 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > We just had another instance like this. Any suggestions? > > > > > > Thanks, > > Suresh > > > > > > On Fri, Jan 3, 2025 at 4:52 PM Suresh Veliveli > > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > > We did an upgrade from 2.6.3 to 2.6.7 at the same time, changing the > > backend db to "mdb". I think that's when we started to notice that > > consumer replication is not recovering. So we upgraded again to 2.6.8 to > > now 2.6.9. > > What backend were you using on 2.6.3 before migrating to mdb? At this > point, I'd suspect your migration may not have been executed correctly. > > --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)

1 0

Re: consumer replication not recovering
by Suresh Veliveli 07 Jan '25

07 Jan '25

We did an upgrade from 2.6.3 to 2.6.7 at the same time, changing the backend db to "mdb". I think that's when we started to notice that consumer replication is not recovering. So we upgraded again to 2.6.8 to now 2.6.9. Thanks, Suresh On Fri, Jan 3, 2025 at 2:19 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, January 3, 2025 7:52 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > The OS is Rock9, AWS EC2 instance. > > Question - Was this working on an earlier OpenLDAP version, and just > started having issues with 2.6.9? I was re-reading your initial post and > that wasn't clear. > > Thanks! > > --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)

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical