- openldap-bugs - openldap.org

[Issue 9543] New: Patch : Customize CN check on TLS
by openldap-its＠openldap.org 01 May '21

01 May '21

https://bugs.openldap.org/show_bug.cgi?id=9543 Issue ID: 9543 Summary: Patch : Customize CN check on TLS Product: OpenLDAP Version: unspecified Hardware: i386 OS: Other Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- Created attachment 821 --> https://bugs.openldap.org/attachment.cgi?id=821&action=edit Patch on master Hi, I added a feature that allow to customize the domain name on TLS hostname verification. With it, we can use an IP that comes from our DNS resolver. It is mainly used when we want launch test units with a private server where the IP and domains are private. In our case, we use our own dns resolver (internal code) which give us an IP that is passed to LDAP. As we know the domain name but not LDAP, we pass it to it for checking (it's not an ignore option) Here is the commit from our repository (based from 2.4): https://gitlab.linphone.org/BC/public/external/openldap/-/commit/a4fef2181c… Here is the branch from the HEAD of your current master (one commit, parent 60b7dc731ce9f2424a4a56d78ae99270a3c6239c) https://gitlab.linphone.org/BC/public/external/openldap/-/tree/feature/host… Here is the branch from the HEAD of OPENLDAP_REL_ENG_2_4 (one commit, parent faf2c4e78641f69df3fdea5f97ddb058946f2051) https://gitlab.linphone.org/BC/public/external/openldap/-/tree/feature/host… I attached the diff on master Regards -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

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

1 0

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

1 0

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8078 --- Comment #2 from nivanova(a)symas.com <nivanova(a)symas.com> --- I don't think this is actually a bug. This is not what network_timeout is meant for. The timeout value for receiving a response is actually the per-operation timeouts, and these are, in fact, honored. ldap_result is called with a tv of LDAP_BACK_RESULT_UTIMEOUT to avoid multiple threads getting stuck waiting for the same connection to become available, but the call is repeated until the configured operation timeout is reached. This is how both back-ldap and back-meta operate, and it is by design. network-timeout is provided (by setting LDAP_OPT_NETWORK_TIMEOUT) to ldap_pvt_poll when a new connection is created or an ldap request is sent. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9533] New: OpenLdap hangs when creating many databases
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9533 Issue ID: 9533 Summary: OpenLdap hangs when creating many databases Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: akrush24(a)gmail.com Target Milestone: --- I initialize openldap cluster with config: ``` dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /run/openldap/slapd.pid olcArgsFile: /run/openldap/slapd.args olcServerID: 1 ldaps://ldap.ldap01.xxx.ru:637 olcServerID: 2 ldaps://ldap.ldap02.xxx.ru:637 olcServerID: 3 ldaps://ldap.ldap03.xxx.ru:637 olcTLSCACertificateFile: /etc/openldap/ssl/ca.pem olcTLSCertificateKeyFile: /etc/openldap/ssl/private.key olcTLSCertificateFile: /etc/openldap/ssl/server.crt dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.so olcModuleload: syncprov.so 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/inetorgperson.ldif include: file:///etc/openldap/schema/nis.ldif dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage olcRootPW: Ohtheis7ur9Qua6e olcSyncRepl: rid=001 provider=ldaps://ldap.ldap01.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://ldap.ldap02.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://ldap.ldap03.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov ``` Then I try to create many bases in a loop: My base template: ``` /etc/openldap/conf.d # cat > newdb.ldiff.template <<EOF! dn: olcDatabase={#DITID#}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {#DITID#}mdb olcSuffix: dc=devmail,dc=srv,dc=local olcDbMaxSize: 1073741824 olcRootDN: cn=admin,dc=devmail,dc=srv,dc=local olcRootPW: 123 olcDbDirectory: /var/lib/openldap/openldap-data/ olcDbIndex: objectClass eq olcSyncRepl: rid=001 provider=ldaps://ldap.ldap01.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://ldap.ldap02.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://ldap.ldap03.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={#DITID#}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov EOF! ``` For example 100 dbs ``` for I in $(seq 1 100);do sed -e "s/devmail/devmail${I}/g" -e "s/#DITID#/${I}/g" ./newdb.ldiff.template > newdb${I}.ldiff ldapmodify -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi -Y EXTERNAL -f ./newdb${I}.ldiff done ``` As a result my cluster first slows down and then nodes hang up. Logs show nothing, no activity. Connect via ldapmodify or other cli utilities just hangs. In such a situation rebooting a single node of the cluster helps, until the cluster becomes unresponsive once again. Please tell me what could be the problem? Could my cluster configuration be incorrect? The problem manifests itself only in situation where I have many databases, e.g. more than 10. With one-two dbs all works as expected. I have also tried using different in-built database backends, to no avail. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9513] New: Enhanced debug output
by openldap-its＠openldap.org 23 Apr '21

23 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9513 Issue ID: 9513 Summary: Enhanced debug output Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- While debugging ITS#9479 I needed more information on which threads were doing what actions. Also, when looking for delays/hangs/race conditions, the 1-second granularity of the debug msg timestamp was inadequate. And also, some of the debug output for the Search operation was being done in separate Debug calls for a single line of output. This gets jumbled up pretty badly if other threads are printing output as well. New patch set will extend the debug timestamp to have fractional seconds too; it will use clock_gettime for nanosecond resolution if available, otherwise use gettimeofday for microsecond resolution. Also tweak the Search debug output to only use one Debug invocation per line of output. This is MR!279. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9470] New: Add homedir overlay to core
by openldap-its＠openldap.org 22 Apr '21

22 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9470 Issue ID: 9470 Summary: Add homedir overlay to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its homedir overlay as a core overlay Home directory provisioning overlay The homedir overlay causes slapd to notice changes involving RFC-2307bis style user-objects and make appropriate changes to the local filesystem. This can be performed on both master and replica systems, so it is possible to perform remote home directory provisioning. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 20 Apr '21

20 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8707 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #31 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 629cafc9 by Ondřej Kuzník at 2021-04-20T22:54:19+00:00 ITS#8707 Add systemd service notification support • f3501534 by SATOH Fumiyasu at 2021-04-20T22:54:19+00:00 ITS#8707 - Add slapd.service and lloadd.service for systemd • 0786f6d5 by Quanah Gibson-Mount at 2021-04-20T22:54:19+00:00 ITS#8707 - Update CI/CD for systemd notification support • 72caa56a by Ondřej Kuzník at 2021-04-20T22:54:19+00:00 ITS#8707 systemd notifications from lloadd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9528] New: liblmdb throws away environment CFLAGS
by openldap-its＠openldap.org 20 Apr '21

20 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9528 Issue ID: 9528 Summary: liblmdb throws away environment CFLAGS Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When building LMDB, specified hardening flags are thrown away due to the Makefile overriding CFLAGS: Makefile:CFLAGS = $(THREADS) $(OPT) $(W) $(XCFLAGS) -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 15 Apr '21

15 Apr '21

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

1 0

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 15 Apr '21

15 Apr '21

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

1 0

[Issue 8847] New LDAP URL syntax to support binding to specific IP address at client side
by openldap-its＠openldap.org 15 Apr '21

15 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8847 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.3 |2.5.4 --- Comment #44 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 7df2a0f3 by Ondřej Kuzník at 2021-04-15T15:16:19+01:00 ITS#8847 Allocate a large enough buffer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 14 Apr '21

14 Apr '21

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

1 0

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 14 Apr '21

14 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8721 --- Comment #5 from Shawn McKinney <smckinney(a)symas.com> --- It has been observed that the quarantine is reset on each search, even if the server is restarted. Another scenario 1. stop louie 2. perform search, 20 second quarantine starts 3. start louie 4. perform another search before quarantine lifts, it resets to another 20 seconds -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8736] Add test script for cn=config replication using delta-sync
by openldap-its＠openldap.org 14 Apr '21

14 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8736 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 093d966f by Quanah Gibson-Mount at 2021-04-14T02:56:48+00:00 ITS#8736 - Add test script using delta-syncrepl for cn=config replication -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8179] LMDB: Feature Request: mdb_env_check_mapsize(env)
by openldap-its＠openldap.org 13 Apr '21

13 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8179 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Leonardo Lopes from comment #1) > Hello. > > I can't say if this is really a bug, but this is one of the (very) few > results I could find while serching the internet for MDB_MAP_RESIZED error > in OpenLDAP. Don't hijack stuff. Direct your question to openldap-technical(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8179] LMDB: Feature Request: mdb_env_check_mapsize(env)
by openldap-its＠openldap.org 13 Apr '21

13 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8179 --- Comment #1 from Leonardo Lopes <leonardo(a)cefetmg.br> --- Hello. I can't say if this is really a bug, but this is one of the (very) few results I could find while serching the internet for MDB_MAP_RESIZED error in OpenLDAP. I'll describe my setup and the circumstances of the error. I have OpenLDAP/LMDB installed from Debian 10 default packages in a amd64 box. The package versions are: - liblmdb: 0.9.22-1 - slapd: 2.4.47 Along with the usual settings, I chose the mdb backend with maxsize = 7516192768 (7GB). The on-disk base size (the data.mdb file) is 134MB. I also have loglevel = stats Everything seems to work flawless and fast, so all of sudden syslog prints the this message: Apr 9 15:06:09 vm-ldap-01 slapd[12826]: mdb_opinfo_get: err MDB_MAP_RESIZED: Database contents grew beyond environment mapsize(-30785) and seconds later, the slapd daemon stop to answer all requests. For the record, my workload is essentially reads with ~1000k SRCH ops, ~750k BIND ops and only ~100 ADD/DEL/MOD ops in a typical day. I tried to relate the error with anything possible, but no success. All I have is that when the error occurs, there were always an ADD operation logged right before. As I said, search the internet were of almost no help, except for this bug report and for the source code. After read the sources and the context of occurrence for the MDB_MAP_RESIZED error, I thought it may really be a bug. Thanks for your consideration. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9523] New: In OpenLDAP, the password length check counts accented characters (UTF-8) as two characters instead of one
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9523 Issue ID: 9523 Summary: In OpenLDAP, the password length check counts accented characters (UTF-8) as two characters instead of one Product: OpenLDAP Version: 2.4.40 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: anand.b.krishnamohan(a)gmail.com Target Milestone: --- In OpenLDAP, the password length check counts accented characters (eg. è which has UTF-8 Encoding of 0xC3 0xA8) as two characters instead of one. As a result, if users enter accented characters, they can create passwords that are shorter than the minimum length specified in the password policy. We tested it directly in Apache Directory Studio and the same result. Is this a bug or is there any setting in LDAP which makes sure the encoding is happening in UTF-16? Steps to reproduce 1. Access the LDAP in Apache Directory studio 2. Have the password policy to accept more than 8 characters 3. Try to update the password for a user to "àbcdefg" (7 characters) Expected result: Fails with the error password length should be greater than 8 Actual result: It accepts the password -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8586] load cert+chain from TLSCertificateFile
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8586 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 680091b5 by Andreas Schulze at 2021-04-12T20:32:09+01:00 ITS#8586 load cert+chain from TLSCertificateFile • e16b0a73 by Howard Chu at 2021-04-12T20:32:12+01:00 ITS#8586 server cert manpage tweaks -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7786] Impossible to modify cn=config if olcDbDirectory doesn't exist
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=7786 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.3 |2.5.4 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • c29f0315 by Ondřej Kuzník at 2021-04-12T16:28:49+00:00 ITS#7786 Allow parsing of invalid entries when schema checking off -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8586] load cert+chain from TLSCertificateFile
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8586 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED --- Comment #12 from Howard Chu <hyc(a)openldap.org> --- fixed in master -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8721 --- Comment #4 from Shawn McKinney <smckinney(a)symas.com> --- Can reproduce proxy not lifting quarantine if the searches continue during quarantine period. Once the operations stop, the quarantine will lift after the specified elapsed time. For example: Three servers: a. huey (proxy) b. dewey (backend server) c. louie (backend server) 1. Stop louie 2. Issue search to huey, only dewey's entries in result set (as expected) 3. Start louie 4. Issue searches before louie's quarantine expires (e.g. 20 seconds) 5. Louie will remain in quarantine while the search ops continue 6. Stop search ops 7. Wait 20 seconds 8. Louie's quarantine expires 9. Start searches again, all of dewey and louie entries now in result set -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8721 --- Comment #3 from Shawn McKinney <smckinney(a)symas.com> --- Cannot reproduce scenario. Details: $OpenLDAP: slapd 2.5.3 Proxy config: ``` gsfile "/var/run/openldap/slapd.args" loglevel stats sync threads 8 ### modules modulepath /opt/openldap25/lib/openldap moduleload back_meta moduleload back_ldap ### schemas include /opt/openldap25/etc/openldap/schema/core.schema include /opt/openldap25/etc/openldap/schema/cosine.schema sizelimit unlimited timelimit unlimited database meta suffix "" quarantine 20,+ rootdn "dc=example,dc=com" rootpw "F00F1ghters" uri ldap://dewey/ou=Groups,dc=example,dc=com uri "ldap://louie/ou=bar,dc=example,dc=com" access to * by * read ``` 1st search (all three servers running): ``` $ ldapsearch -H ldap://huey -D "dc=example,dc=com" -w F00F1ghters -b "dc=example,dc=com" -s sub objectclass=* # Groups, example.com dn: ou=Groups,dc=example,dc=com objectClass: organizationalUnit ou: Groups description: Group container # foo, Groups, example.com dn: cn=foo,ou=Groups,dc=example,dc=com member: cn=service-user,ou=admin,dc=example,dc=com cn: foo objectClass: groupOfNames objectClass: top # bar, example.com dn: ou=bar,dc=example,dc=com ou: bar objectClass: organizationalUnit objectClass: top # bar, bar, example.com dn: cn=bar,ou=bar,dc=example,dc=com cn: bar sn: bar objectClass: person objectClass: top # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 ``` 2nd search, louie not running, same search op: ``` # Groups, example.com dn: ou=Groups,dc=example,dc=com objectClass: organizationalUnit ou: Groups description: Group container # foo, Groups, example.com dn: cn=foo,ou=Groups,dc=example,dc=com member: cn=service-user,ou=admin,dc=example,dc=com cn: foo objectClass: groupOfNames objectClass: top # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 ``` Proxy server logs shows louie has been quarantined: ``` Apr 12 16:59:41 huey slapd[110695]: conn=1004 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 12 16:59:41 huey slapd[110695]: conn=1004 op=1 meta_back_retry[1]: retrying URI="ldap://louie" DN="". Apr 12 16:59:41 huey slapd[110695]: conn=1004 op=1 meta_back_quarantine[1]: enter. ``` 3rd search, louie restarted, after waiting 20 seconds: proxy server, louie exits quarantine: ``` Apr 12 17:02:01 huey slapd[110695]: conn=1005 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 12 17:02:01 huey slapd[110695]: conn=1005 op=1 meta_back_init_one_conn[1]: quarantine retry block #0 try #0. Apr 12 17:02:01 huey slapd[110695]: conn=1005 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000020 etime=0.004103 nentries=4 text= Apr 12 17:02:01 huey slapd[110695]: conn=1005 op=1 meta_back_quarantine[1]: exit. ``` search returns all results as expected: ``` # Groups, example.com dn: ou=Groups,dc=example,dc=com objectClass: organizationalUnit ou: Groups description: Group container # foo, Groups, example.com dn: cn=foo,ou=Groups,dc=example,dc=com member: cn=service-user,ou=admin,dc=example,dc=com cn: foo objectClass: groupOfNames objectClass: top # bar, example.com dn: ou=bar,dc=example,dc=com ou: bar objectClass: organizationalUnit objectClass: top # bar, bar, example.com dn: cn=bar,ou=bar,dc=example,dc=com cn: bar sn: bar objectClass: person objectClass: top # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7259] slapo-policy count bytes not characters
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=7259 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anand.b.krishnamohan@gmail. | |com --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- *** Issue 9523 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8736] Add test script for cn=config replication using delta-sync
by openldap-its＠openldap.org 12 Apr '21

12 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8736 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ondra(a)mistotebe.net |quanah(a)openldap.org -- 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