- openldap-bugs - openldap.org

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|hyc(a)openldap.org |ondra(a)mistotebe.net --- Comment #16 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Assigning to Ondrej for the load balancer portion -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 77adb192 by Howard Chu at 2021-09-27T16:54:24+00:00 ITS#6949 honor specified loglevel, not just debuglevel But skip calls to syslog() if logfile_only is set. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9709] New: Invalid link for Symas website
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9709 Issue ID: 9709 Summary: Invalid link for Symas website Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The Symas website link in the powered by portion is invalid. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9705] New: synprov put add info into wrong cookie while performing test059-consumer-config
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9705 Issue ID: 9705 Summary: synprov put add info into wrong cookie while performing test059-consumer-config Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: gil77for(a)gmail.com Target Milestone: --- There is an issue with syncrepl and syncprov working together in parallel. The issue can be seen in provider LDAP server logs of test059-consumer-config. For linux this problem does not cause the test to malfunction, but it may cause replication to malfunction on other systems (or possibly on linux in a different situation from the test). In case of OpenVMS we have this issue. The problem is detected under the following circumstances, followed by a step-by-step description of the actions in test 059 that lead to malfunction: 1. Adding replication configuration for the dn: olcDatabase={1}ldif,cn=config dn: olcDatabase={1}ldif,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: {0}rid=001 provider=ldap://localhost:9001/ binddn="cn=config" bindmethod=simple credentials=******** searchbase="cn=schema,cn=config" type=refreshAndPersist retry="3 5 300 5" timeout=3 suffixmassage="cn=schema,cn=config,cn=consumer" this registers a syncInfo structure with the parameter rid=001 inside the syncrepl engine. the corresponding syncCookie and cookieState are also created inside this structure 2. adding includes by ldapadd to the configuration, this causes {1}ldif,cn=config to be filled on the provider and register this adding in rid=001 syncInfo cookies with sid=001: include: file:///LDAP$SCHEMA:core.ldif include: file:///LDAP$SCHEMA:cosine.ldif include: file:///LDAP$SCHEMA:inetorgperson.ldif include: file:///LDAP$SCHEMA:openldap.ldif include: file:///LDAP$SCHEMA:nis.ldif 3. Adding replication configuration for the dn: olcDatabase={1}mdb,cn=config,cn=consumer: dn: olcDatabase={1}mdb,cn=config,cn=consumer objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {1}mdb olcSuffix: dc=example,dc=com olcDbDirectory: [.testdir.db_2_a] olcRootDN: cn=Manager,dc=example,dc=com olcRootPW: secret olcSyncRepl: rid=002 provider=ldap://localhost:9001/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="3 5 300 5" timeout=3 olcUpdateRef: ldap://localhost:9001/ this registers new syncInfo structure with the parameter rid=002 inside the syncrepl engine. Should also be added info into cookies of this structure but this is the issue. The info about {1}mdb,cn=config,cn=consumer is added to the cookie of structure with rid=001 (!!!). Thus the cookie about {1}ldif is overrides by this new cookie data. It can be seen in provider server logs (was run on linux): …… 61275c7d ldif_back_add: "olcDatabase={1}mdb,cn=config,cn=consumer" 61275c7d oc_check_required entry (olcDatabase={1}mdb,cn=config,cn=consumer), objectClass "olcMdbConfig" …… 61275c7d slap_get_csn: conn=1007 op=3 generated new csn=20210826091853.649104Z#000000#001#000000 manage=1 61275c7d slap_queue_csn: queueing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000 61275c7d ldif_write_entry: wrote entry "olcDatabase={1}mdb,cn=config,cn=consumer" 61275c7d ldif_back_add: err: 0 text: 61275c7d send_ldap_result: conn=1007 op=3 p=3 61275c7d send_ldap_result: err=0 matched="" text="" 61275c7d conn=1007 op=3 syncprov_matchops: recording uuid for dn=olcDatabase={1}mdb,cn=config,cn=consumer on opc=0x7fcdf4001608 …… 61275c7d slap_graduate_commit_csn: removing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000 61275c7d conn=1004 op=1 syncprov_sendresp: cookie=rid=001,sid=001,csn=20210826091853.649104Z#000000#001#000000 61275c7d conn=1004 op=1 syncprov_sendresp: sending LDAP_SYNC_ADD, dn=olcDatabase={1}mdb,cn=config,cn=consumer …… rid=002 should be there! When running on linux, this does not cause a problem for the test, because syncprov task works later than the ldif database replication on consumer by syncrepl task. And the overlapped cookie entry does not matter anymore. In our case (OpenVMS) the order of asynchronous tasks (syncrepl and syncprov) is different and overwriting the cookie leads to loss of ldif database replication and failure of the test. The consumer does not receive scheme data. The differences in the order of tasks are caused by the features of pthreads library implementation for the VMS. But it should not matter for LDAP operation. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9703] New: init_config_ocs: register_oc failed
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9703 Issue ID: 9703 Summary: init_config_ocs: register_oc failed Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: goudal(a)enseirb.fr Target Milestone: --- Hello, I just compiled openldap2.5.7 from source with the following command : ./configure '--enable-overlays' '--enable-crypt' '--with-tls' '--enable-backends' '--with-cyrus-sasl' '--disable-ndb' '--enable-modules' Distribution is Ubuntu20.04 When I start slapd it exits with the error init_config_ocs: register_oc failed With -d -1 flag I got the the following : 6149e48c.212556fe 0x7f20fc933740 wt_back_initialize: initialize WiredTiger backend 6149e48c.21544f14 0x7f20fc933740 wt_back_initialize: WiredTiger 2.9.3: (June 26, 2017) 6149e48c.21558481 0x7f20fc933740 register_oc: objectclass "( OLcfgDbOc:9.1 NAME 'olcWtConfig' DESC 'Wt backend configuration' SUP olcDatabaseConfig MUST olcDbDirectory MAY ( olcWtConfig $ olcDbIndex ) )": Inconsistent duplicate \ objectClass, 1.3.6.1.4.1.4203.1.12.2.4.2.9.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9690] New: 2.5.7: test suite is failing
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9690 Issue ID: 9690 Summary: 2.5.7: test suite is failing Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: kloczko.tomasz(a)gmail.com Target Milestone: --- Created attachment 842 --> https://bugs.openldap.org/attachment.cgi?id=842&action=edit Test suite log Source code configured with below options: %configure \ --disable-debug \ --disable-ndb \ --disable-slp \ --disable-sql \ --disable-wt \ --disable-static \ --enable-backends=mod \ --enable-bdb=yes \ --enable-cleartext \ --enable-crypt \ --enable-dynacl \ --enable-dynamic \ --enable-hdb \ --enable-lmpasswd \ --enable-mdb=yes \ --enable-modules \ --enable-monitor \ --enable-overlays=mod \ --enable-rewrite \ --enable-rlookups \ --enable-slapi \ --enable-spasswd \ --libexecdir=%{_libdir} \ --with-cyrus-sasl \ --with-gnu-ld \ --without-fetch \ --with-pic \ --with-threads \ %{nil} Test suite log is in attachment Please let me know if you need more details or want me to perform some diasgnostics. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6097 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.1 |2.6.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6097 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |2.6.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9704] New: Failing Configuration of OpenLDAP
by openldap-its＠openldap.org 22 Sep '21

22 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9704 Issue ID: 9704 Summary: Failing Configuration of OpenLDAP Product: OpenLDAP Version: 2.5.7 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: narendra.challa(a)cscs.ch Target Milestone: --- Created attachment 845 --> https://bugs.openldap.org/attachment.cgi?id=845&action=edit Error Hi There, I am new to OpenLDAP and followed the steps mentioned in this quick start guide as it is https://www.openldap.org/doc/admin25/quickstart.html but failing the configuration of OpenLDAP. I followed the below steps on CentOS 8 with 2.5.7 and successfully installed but while configuring facing issues, please correct me if I am doing this in the wrong way. 1. Created a Linux user dedicated to OpenLDAP with the name "nchalla" which has sudo permissions. 2. Login with Root user and created a folder /u01 3. change permissions on /u01 (for time being granted 777 ( 4. change ownership of /u01 to "nchalla" 5. downloaded the tarball and extracted the OpenLDAP 2.5.7 7. downloaded the required developer libraries 8. Logged in as nchalla and navigated to the OpenLDAP 2.5.7 extracted folder and start compiling and installing with the below commands ./configure --prefix=/u01/ldap make depend make make test (all tests were passed) make install 9. Started the configuration following the below steps a. created a folder /u01/ldap/etc/slapd.d b. updated the slapd.ldif with our domain name c. navigate to /u01/ldap and executed the command below, sbin/slapadd -n 0 -F /u01/ldap/etc/slapd.d -l /u01/ldap/etc/openldap/slapd.ldif which is throwing error messages -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9701] New: OpenLDAP replica skips few items while synchronization
by openldap-its＠openldap.org 21 Sep '21

21 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9701 Issue ID: 9701 Summary: OpenLDAP replica skips few items while synchronization Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mgkrishnan(a)gmail.com Target Milestone: --- I have an OpenLdap cluster with 6 nodes, when an item is added/deleted in the master, the synchronization kicks in and the changes are replicated to other slave nodes in the cluster, but sometimes one of the slave cluster nodes (the same node all the time) misses the updates and hence there is a difference between this slave node and the rest of the slave nodes and the master, so sometimes when the request goes to the unsynchronized slave it yields invalid results. In the problematic slave's ldap logs, there is no error information during this operation to the master which explains the miss, so cant figure out what has caused this problem, bringing down that slave and re-add does not help either. What could be the root cause of this issue ? -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 20 Sep '21

20 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/412 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9698] New: per database olcSecurity: tls=0 does not override olcSecurity: tls=1 from the frontend
by openldap-its＠openldap.org 20 Sep '21

20 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9698 Issue ID: 9698 Summary: per database olcSecurity: tls=0 does not override olcSecurity: tls=1 from the frontend Product: OpenLDAP Version: 2.5.7 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I have these databases: cn=config frontend,cn=config mdb/suffix o=A,cn=config mdb/suffix o=B,cn=confix slapd listens on port 389. I want to make sure, that • all requests to suffix o=A are served after STARTTLS, as these come from the wild internet. • all requests to suffix o=B do not have to utilize STARTTLS (ldaps), as these are local to the machine, and • if a request to the root DSE is made, without using STARTTLS, the client shall gets “ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required”. To enforce STARTTLS for suffix o=A I put there `olcSecurity: tls=1`. If I set dn: olcDatabase=frontend,cn=config olcAccess: to dn="" by tls_ssf=256 * read and the rootDSE is requested without STARTTLS, the result is just empty, rather than “ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required”. To get the “confidentiality required” for the root DSE I have to put dn: olcDatabase=frontend,cn=config olcSecurity: tls=1 or dn: cn=config olcSecurity: tls=1 It was unclear to me which one shall I use, but both serve the same purpose. Now, I want to enable no-STARTTLS to suffix o=B. I put there “olcSecurity: tls=0”. Irrespective, if only cn=config, or only olcDatabase=frontend,cn=config contain “olcSecurity: tls=1” the “olcSecurity: tls=0” in suffix o=B is not enacted. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 17 Sep '21

17 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Generally, it looks like this feature was implemented using slapd options and ignoring the slapd configured loglevel. This is problematic in that it: a) Breaks the longstanding expectation of being able to control logging via the loglevel/olcLogLevel settings in slapd.conf/cn=config b) Requires a restart to change the logging level c) Is going to be a multi-step issue on systemd based systems, as the debug level would need to be modified in the systemd overrides configuration file. I.e., one cannot simply do even a slapd restart to change the loglevel with this implementation. Generally expectation: a) loglevel continues to control logging b) it is possible to change the loglevel on the fly without restarting slapd c) It is not necessary to fiddle with the -d option to slapd to get logging. Setting -s 0 seems fine. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 17 Sep '21

17 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |CONFIRMED --- Comment #12 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Unable to get this to work in master. Set up a generic slapd with cn=config Did an ldapmodify to set the logging options: ldapmodify -x -H ldapi:/// -D cn=config -w secret dn: cn=config changetype: modify add: olcLogFile olcLogFile: /var/symas/slapd.log - add: olcLogFileOnly olcLogFileOnly: TRUE - add: olcLogFileRotate olcLogFileRotate: 12 10 1 modifying entry "cn=config" Logfile is created, but nothing is logged to it. Restarted slapd, still nothing logged to it. Explicitly set the loglevel to stats sync Still nothing logged to it. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9697] New: healthcare software development
by openldap-its＠openldap.org 16 Sep '21

16 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9697 Issue ID: 9697 Summary: healthcare software development Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ritesh.patil732(a)gmail.com Target Milestone: --- https://mobisoftinfotech.com/industry/healthcare-software-development -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 15 Sep '21

15 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- For reference, with the test008 config, timings for progs/slapd-tester -H ldap://:9011 -D cn=manager,dc=example,dc=com -w secret -d testdata -P progs -l 1000 -s0 -dnone 18.92 seconds -s0 -d256 23.37 seconds -s0 -d256 + rotate 27.00 seconds -s256 -dnone 45.33 seconds Logfile params were logfile testrun/logfile logfile-rotate 12 10 1 logfile-only true -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9464] New: Test suite file conf.sh tries to sed unused items
by openldap-its＠openldap.org 15 Sep '21

15 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9464 Issue ID: 9464 Summary: Test suite file conf.sh tries to sed unused items Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The conf.sh script tries to sed values that are not meant for replacement but instead are environment variables handled by run.in and defines.sh. This should be deleted from conf.sh -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9694] New: Can Delta-sync’s changelog be based on a sessionlog?
by openldap-its＠openldap.org 15 Sep '21

15 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9694 Issue ID: 9694 Summary: Can Delta-sync’s changelog be based on a sessionlog? Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- In the replication terminology, the terms sessionlog and accesslog are used. sessionlog is created by the syncprov-overlay/syncprov-sessionlog directive; accesslog is created in first place by the accesslog overlay. Delta-syncrepl introduces an additional term: changelog. The example at https://www.openldap.org/devel/admin/replication.html#Delta-syncrepl%20Prov… uses accesslog for the changelog. The documentation is unclear, whether the changelog must be backed on accesslog-database, or it can be backed also on a sessionlog. (⇔Is delta-sync happy just with a sessionlog?) The documentation in slapo-syncprov(5) for syncprov-nopresent says “This value should only be set TRUE for a syncprov instance on top of a log database (such as one managed by the accesslog overlay).” Is sessionlog a log database? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7595] OpenLDAP lacks a ECDHE key generation callback
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=7595 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9687 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7595] OpenLDAP lacks a ECDHE key generation callback
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=7595 --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #1) > Some background info in this thread > http://openssl.6102.n7.nabble.com/Problem-with-cipher-suite-ECDHE-ECDSA- > AES256-SHA384-td42229.html nabble.com seems to have reorganized their domains and the above URL is now broken. The same thread is available at https://www.mail-archive.com/openssl-users@openssl.org/msg69181.html > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Re25: • 2a537ad0 by Ondřej Kuzník at 2021-09-14T16:17:45+00:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • ea92405a by Ondřej Kuzník at 2021-09-14T16:17:25+00:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8341] Matching rules for 'namingContexts'
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8341 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • bfe3d19e by Ondřej Kuzník at 2021-09-09T10:26:06+01:00 ITS#8341 Allow normalised values for namingContexts in cn=monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9619] New: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file
by openldap-its＠openldap.org 14 Sep '21

14 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9619 Issue ID: 9619 Summary: mdb_env_copy2 with MDB_CP_COMPACT in mdb.master3 produces corrupt mdb file Product: LMDB Version: 0.9.29 Hardware: All OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- When copying an LMDB database with mdb_env_copy2 with the MDB_CP_COMPACT with mdb.master3, the resulting mdb file seems to be corrupt and when using it in LMDB, I get segmentation faults. Copying without the compacting flag seems to work fine. I apologize, I know this is not a very good issue report, as I haven't had a chance to actually narrow this down to a more reproducible/isolated case, or look for how to patch. I thought I would report in case there are any ideas on what could cause this. The segmentation faults always seem to be memory write faults (as opposed to try fault on trying to read). Or perhaps the current backup/copying functionality is eventually going to be replaced by incremental backup/copying anyway (https://twitter.com/hyc_symas/status/1315651814096875520). I'll try to update this if I get a chance to investigate more, but otherwise feel free to ignore/consider low-priority since the work around is easy. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 13 Sep '21

13 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE25: commit a00ec090bdcdfdb390ace2238f581ad147e5974f Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Tue Jun 1 13:56:58 2021 +0100 ITS#6467 Free uuid list after we're finished -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs