openldap-technical

openldap-technical@openldap.org

11 participants
9979 discussions

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 16 Feb '24

16 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

The unique overlay: enforcing uniqueness in the union of trees
by Norman Gray 15 Feb '24

15 Feb '24

Greetings. How should I use the 'unique' overlay to enforce uniqueness of an attribute across two trees? I'd have thought that the following would work, to enforce uniqueness across ou=dept1 and ou=dept2, but it doesn't seem to. dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept1,o=example?uidnumber?sub ldap:///ou=dept2,o=example?uidnumber?sub (and cf, slapd/overlays/unique.c:unique_new_domain). When I configure a server with this, and load two entities with the same uidNumber, the server doesn't object. I'm clearly misunderstanding something. The slapo-unique(5) manpage suggests that having two URIs juxtaposed like this is syntactically OK, but it doesn't make clear the semantics of this. I'd guessed that the above configuration would create a 'domain' which is the union of the two subtrees, but that doesn't seem to be the case. Another thing that such a line could potentially specify is that a tuple of attributes is unique. For example that 'olcUniqueUri: ldap:///?sn?sub ldap:///?cn?sub' specifies that (sn,cn) is unique. There's nothing in the slapo-unique manpage that would back up this interpretation, though. Or is the above configuration in fact equivalent to olcUniqueURI: ldap:///ou=dept1,o=example?uidnumber?sub olcUniqueURI: ldap:///ou=dept2,o=example?uidnumber?sub which would enforce uniqueness of uidnumber on trees ou=dept1 and ou=dept2 separately. I take it that this isn't so, because the manpage talks of multiple 'domains', each of which can have multiple URIs. In the example below, if I instead add user uid=u2,ou=dept1,o=example, then a duplicated uidNumber is indeed rejected in the ldapadd step (so the overlay is active). I see an older thread [1] on this topic, but that refers only to a single URI in the olcUniqueURI attribute. That was resolved by adding an index on the relevant attribute, but that index is included in the configuration below. (The goal here is to enforce uniqueness of uidNumber attributes in (dept1 union dept2) and (dept1 union dept3), but permit duplication in dept2 and dept3.) Thanks for any illumination, Norman [1] https://www.openldap.org/lists/openldap-technical/201808/msg00016.html Witness: % cat uniqueness-test-config.ldif dn: cn=config objectclass: olcGlobal cn: config olcPidFile: /tmp/uniquenesstest/slapd.pid dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModuleload: back_mdb.la olcModuleload: unique dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/nis.ldif dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcSuffix: o=example olcRootDN: cn=admin,o=example olcRootPW: dummypass olcDbIndex: default eq olcDbIndex: objectclass olcDbIndex: uidNumber eq olcDbDirectory: /tmp/uniquenesstest/data dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept1,o=example?uidNumber?sub ldap:///ou=dept2,o=example?uidNumber?sub % cat uniqueness-test-data.ldif dn: o=example objectClass: organization o: example dn: ou=dept1,o=example objectclass: organizationalunit ou: dept1 dn: uid=u1,ou=dept1,o=example objectclass: person objectclass: posixAccount sn: Two cn: User One uid: u1 uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/u1 dn: ou=dept2,o=example objectclass: organizationalunit ou: dept2 dn: uid=u2,ou=dept2,o=example objectclass: person objectclass: posixAccount sn: Two cn: User Two uid: u2 uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/u2 % slapadd -v -F /tmp/uniquenesstest/slapd.d -n0 -l uniqueness-test-config.ldif added: "cn=config" (00000001) added: "cn=module{0},cn=config" (00000001) added: "cn=schema,cn=config" (00000001) added: "cn={0}core,cn=schema,cn=config" (00000001) added: "cn={1}cosine,cn=schema,cn=config" (00000001) added: "cn={2}nis,cn=schema,cn=config" (00000001) added: "olcDatabase={1}mdb,cn=config" (00000001) added: "olcOverlay={0}unique,olcDatabase={1}mdb,cn=config" (00000001) Closing DB... % slapd -F /tmp/uniquenesstest/slapd.d % ldapadd -x -H ldap:/// -D cn=admin,o=example -w dummypass -f uniqueness-test-data.ldif adding new entry "o=example" adding new entry "ou=dept1,o=example" adding new entry "uid=u1,ou=dept1,o=example" adding new entry "ou=dept2,o=example" adding new entry "uid=u2,ou=dept2,o=example" % ldapsearch -LLL -H ldap:/// -b o=example '(objectclass=person)' uidnumber dn: uid=u1,ou=dept1,o=example uidNumber: 1000 dn: uid=u2,ou=dept2,o=example uidNumber: 1000 % slapd -VVV @(#) $OpenLDAP: slapd 2.6.7 (Jan 1 1980 00:00:00) $ openldap Included static overlays: accesslog syncprov unique Included static backends: config ldif monitor mdb relay -- Norman Gray : https://nxg.me.uk

3 5

postscript(subject:I lost all data(perhaps))
by 長田泰志 13 Feb '24

13 Feb '24

Sorry! There was something missing in the question you asked earlier, so I'll add it. c.The method of restoring the slave (2.6.3) system uses ldapadd to restore the backup data obtained by ldapsearch, so the entryUUID has been changed. thank you! -- ***************************************************** 　アイクラフト株式会社顧客サービス部長田　泰志〒650-0034 神戸市中央区京町83 三宮センチュリービル13F TEL:078-391-2900 FAX:078-391-2901 *****************************************************

2 1

I lost all data(perhaps)
by Yasushi Nagata 12 Feb '24

12 Feb '24

Hi 2/6 I lost all user's data of slave system The following events I had 3 system I would do System migration from centos7 to rhel9 and from openldap 2.4.44 to 2.6.3 The following pair of a. and b. c. system data is restored from b.system a.main system 2.4.44 b.slave system 2.4.44 c.slave system 2.6.3 d.main system 2.6.3 First I exchange b. and c. In the plan,I exchange a. and d. After updating data for b. and c. after this but,I'm having problems with other systems. Second I exchnge c, and b. for recovery b.system output the following log Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cd691a-c2e3-1038-83eb-bdd677e9197b, dn o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34ce0d16-c2e3-1038-83ec-bdd677e9197b, dn cn=Manager,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34ce8e3a-c2e3-1038-83ed-bdd677e9197b, dn ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cef0aa-c2e3-1038-83ee-bdd677e9197b, dn ou=Organizations,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cf0c52-c2e3-1038-83ef-bdd677e9197b, dn ou=SystemAccounts,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 34cf2fca-c2e3-1038-83f0-bdd677e9197b, dn cn=Replication,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 present UUID 34cf4cf8-c2e3-1038-83f1-bdd677e9197b, dn cn=ReplMaster,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe3138e-db18-1038-8977-3f4cb5ea988e, dn xxuid=000001,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe36d98-db18-1038-8978-3f4cb5ea988e, dn xxuid=000003,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe3aaa6-db18-1038-8979-3f4cb5ea988e, dn xxuid=000005,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe3e35e-db18-1038-897a-3f4cb5ea988e, dn xxuid=000008,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe41e32-db18-1038-897b-3f4cb5ea988e, dn xxuid=000009,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe468c4-db18-1038-897c-3f4cb5ea988e, dn xxuid=000011,ou=Users,o=XXXXX,c=jp Feb 6 18:43:59 XXXX slapd[17571]: nonpresent_callback: rid=002 nonpresent UUID 8fe4bb3a-db18-1038-897d-3f4cb5ea988e, dn xxuid=000012,ou=Users,o=XXXXX,c=jp omitted(Probably all users) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000011,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000009,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000008,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000005,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000003,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete xxuid=000001,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete cn=Replication,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete ou=SystemAccounts,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete ou=Organizations,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete ou=Users,o=XXXXX,c=jp (66) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete cn=Manager,o=XXXXX,c=jp (0) Feb 6 18:44:41 XXXX slapd[17571]: syncrepl_del_nonpresent: rid=002 be_delete o=XXXXX,c=jp (66) omitted(Probably all users) Feb 6 18:58:54 als2 slapd[17571]: do_syncrep2: rid=002 cookie=rid=002,sid=001,csn=20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: syncrepl_message_to_entry: rid=002 DN: xxuid=210769,ou=Users,o=XXXXX,c=jp, UUID: 58017300-5914-103e-95a8-5fc7e6f750ea Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 be_search (0) Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 xxuid=210769,ou=Users,o=XXXXX,c=jp Feb 6 18:58:54 als2 slapd[17571]: slap_queue_csn: queueing 0x7ffb3c69f9b0 20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: slap_graduate_commit_csn: removing 0x7ffb3c69f9b0 20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: syncrepl_entry: rid=002 be_modify xxuid=210769,ou=Users,o=XXXXX,c=jp (0) Feb 6 18:58:54 als2 slapd[17571]: slap_queue_csn: queueing 0x7ffb3c55ca70 20240206095854.540617Z#000000#001#000000 Feb 6 18:58:54 als2 slapd[17571]: slap_graduate_commit_csn: removing 0x7ffb3c55ca70 20240206095854.540617Z#000000#001#000000 Feb 6 18:59:05 als2 slapd[17571]: conn=1022 fd=29 ACCEPT from IP=XXX.XXX.XXX.XXX:35812 (IP=0.0.0.0:389) Feb 6 18:59:05 als2 slapd[17571]: conn=1022 op=0 BIND dn="cn=replication,o=XXXXX,c=jp" method=128 Feb 6 18:59:05 als2 slapd[17571]: conn=1022 op=0 RESULT tag=97 err=49 text= Feb 6 18:59:05 als2 slapd[17571]: conn=1022 op=1 UNBIND Feb 6 18:59:05 als2 slapd[17571]: conn=1022 fd=29 closed omitted(Probably all users) "Replication" user is set for syncrepl. What happened? Did I get hit by an oddball Syncrepl behavior? or Did I miss exchange. If this is bug,openldap 2.6.3 will be solved? Since both the main and slave systems were restored at the checkpoint, only the slave system remains in the log. Thanks for your time, Takashi

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical