openldap-bugs April 2022

openldap-bugs@openldap.org

1 participants
117 discussions

[Issue 9737] New: ldapdelete unable to prune LDAP subentries
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9737 Issue ID: 9737 Summary: ldapdelete unable to prune LDAP subentries Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: neuroc0der(a)gmail.com Target Milestone: --- ldapdelete has a builtin capability to prune LDAP subentries (RFC 3672) by utilizing LDAP subentries control when tracking children however currently that logic does not work in the code and pruning always fails with 66 / 'not allowed on non-leaf'. the test case for this is a normal parent entry which has LDAP subentry type children underneath. the patch below addresses this issue. From ba29cbf20804d1c73cc0b5ab16549c4faba75a9e Mon Sep 17 00:00:00 2001 From: Anton Bobrov <antbob(a)users.noreply.github.com> Date: Thu, 4 Nov 2021 17:27:34 +0100 Subject: [PATCH] ldapdelete unable to prune LDAP subentries --- clients/tools/ldapdelete.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/clients/tools/ldapdelete.c b/clients/tools/ldapdelete.c index 8aa8e8c12..1a93aaadf 100644 --- a/clients/tools/ldapdelete.c +++ b/clients/tools/ldapdelete.c @@ -279,8 +279,13 @@ retry:; } rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 ); + if( rc != LDAP_SUCCESS ) { + fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n", + prog, ldap_err2string( rc ), rc ); + return rc; + } - switch ( rc ) { + switch ( code ) { case LDAP_SUCCESS: break; @@ -292,9 +297,7 @@ retry:; /* fallthru */ default: - fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n", - prog, ldap_err2string( rc ), rc ); - return rc; + break; } if( code != LDAP_SUCCESS ) { -- 2.31.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9787] New: 2.6.1 segfault in slaptest when logfile-format param is set
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9787 Issue ID: 9787 Summary: 2.6.1 segfault in slaptest when logfile-format param is set Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Segfault in slaptest when any value for logfile-format is set. debug, syslog-utc, etc. This doesn’t occur during slapd startup. Only in slaptest. Observed on U20 and R8 platforms. slapd.conf ``` logfile "/var/symas/openldap-data/openldap26.log" logfile-only on # segfaults when any value for: logfile-format syslog-utc ``` Backtrace: ``` #0 0x00007f8fca27f685 in __strlen_avx2 () from /lib64/libc.so.6 #1 0x000055df6eaddedf in config_logging (c=<optimized out>) at logging.c:731 #2 0x000055df6ea9fe33 in config_set_vals (Conf=0x55df6edbe348 <config_back_cf_table+3432>, c=0x55df70bc4080) at config.c:378 #3 0x000055df6eaa3010 in read_config_file (fname=fname@entry=0x7ffe8f3a4706 "/opt/symas/etc/openldap/slapd.conf", depth=depth@entry=0, cf=cf@entry=0x0, cft=cft@entry=0x55df6edbd5e0 <config_back_cf_table>) at config.c:908 #4 0x000055df6ea98b98 in read_config (fname=fname@entry=0x7ffe8f3a4706 "/opt/symas/etc/openldap/slapd.conf", dir=dir@entry=0x0) at bconfig.c:4519 #5 0x000055df6eb29946 in slap_tool_init (progname=progname@entry=0x55df6eb50da3 "slaptest", tool=tool@entry=8, argc=4, argv=0x7ffe8f3a28f8) at slapcommon.c:682 #6 0x000055df6eb2c27e in slaptest (argc=<optimized out>, argv=<optimized out>) at slaptest.c:99 #7 0x000055df6ea8baea in main (argc=4, argv=0x7ffe8f3a28f8) at main.c:287 (gdb ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9780] New: Documenting sticky session support in 2.6
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9780 Issue ID: 9780 Summary: Documenting sticky session support in 2.6 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://www.openldap.org/doc/admin26/loadbalancer.html contains the documentation for lload version 2.6. It says: • 2.6 release of lloadd will include sticky sessions (coherency). Since this is the documentation for version 2.6, the documentation shall say what is included in v2.6, not what will be included in v2.6. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9790] New: Build failure with GCC 4.1 and 4.3
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9790 Issue ID: 9790 Summary: Build failure with GCC 4.1 and 4.3 Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- In file included from ../../include/lutil.h:21, from passwd.c:60: ../../include/ac/socket.h:247: error: redefinition of typedef 'Sockaddr' ../../include/ldap_pvt.h:188: error: previous declaration of 'Sockaddr' was here -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9788] New: make warns about disabling/resetting jobserver
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9788 Issue ID: 9788 Summary: make warns about disabling/resetting jobserver Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- Running make -j8 issues the following warning for each directory with make 4.3: make[2]: warning: -j8 forced in submake: resetting jobserver mode. with make 4.2.1: make[3]: warning: -jN forced in submake: disabling jobserver mode. With make 3.82 there is no warning, but the jobserver flags are duplicated for each nested directory. e.g.: cd back-monitor && make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 -j all On my env this is fixed by removing all the occurrences of $(MFLAGS) from build/dir.mk. MFLAGS is picked up by make when it exists, and there is no need to pass it explicitly. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9831] New: connection_next() can skip an active connection
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9831 Issue ID: 9831 Summary: connection_next() can skip an active connection Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Uncovered by running test056 under interesting conditions repeatedly. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9809] New: slapo-pcache: incorrect call to monitor unregister_entry
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9809 Issue ID: 9809 Summary: slapo-pcache: incorrect call to monitor unregister_entry Product: OpenLDAP Version: 2.4.18 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Also an incorrect check for whether monitoring was initialized, thus calling unregister_entry_callback when there's nothing to unregister. The incorrect call causes a SEGV. The incorrect call is also present in back-mdb, but never invoked because it correctly sees there's nothing to unregister. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9811] New: slapadd silently fails when importing ldif file including another one
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9811 Issue ID: 9811 Summary: slapadd silently fails when importing ldif file including another one Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- This issue is about openldap 2.5.11. (not tested on 2.6) When importing a new configuration from an ldif file, for example by this command: slapadd -n0 -F /usr/local/openldap/etc/openldap/slapd.d -l /var/backups/openldap/config-00000000000000.ldif the command answers by a 0 result code but the cn=config database is not fully imported. Also there is no special message displayed. The complete config-00000000000000.ldif file is below. The problem is in the custom.ldif included from config-00000000000000.ldif For example, the problem appears if the custom.ldif is this one: ``` # Custom ldif schema ``` or if the custom.ldif is that one (with an end-of-line at the end): ``` # Custom ldif schema dn: cn=custom,cn=schema,cn=config objectClass: olcSchemaConfig cn: custom ``` The expected behaviour should be to return an error code, and to display the corresponding message on stdout. Here is the full config-00000000000000.ldif file: ``` dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /usr/local/openldap/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcListenerThreads: 1 olcLocalSSF: 71 olcPidFile: /usr/local/openldap/var/run/slapd.pid olcReadOnly: FALSE olcSaslHost: 127.0.0.1 olcSaslSecProps: none olcServerID: 1 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificateFile: /etc/ssl/certs/ca-certificates.crt olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key olcTLSCRLCheck: none olcTLSVerifyClient: allow olcTLSProtocolMin: 3.3 olcToolThreads: 1 olcWriteTimeout: 0 olcLogLevel: stats dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/openldap/lib64/:/usr/local/openldap/libexec/openldap/ olcModuleLoad: argon2.la olcModuleLoad: pw-pbkdf2.la olcModuleLoad: back_mdb.la olcModuleLoad: dynlist.la olcModuleLoad: ppolicy.la olcModuleLoad: syncprov.la olcModuleLoad: unique.la olcModuleLoad: refint.la dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/openldap/etc/openldap/schema/core.ldif include: file:///usr/local/openldap/etc/openldap/schema/cosine.ldif include: file:///usr/local/openldap/etc/openldap/schema/nis.ldif include: file:///usr/local/openldap/etc/openldap/schema/inetorgperson.ldif include: file:///usr/local/openldap/etc/openldap/schema/dyngroup.ldif include: file:///usr/local/openldap/etc/openldap/schema/custom.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: to dn.base="" by * read olcAccess: to dn.base="cn=Subschema" by * read olcAccess: to * by self write by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSecurity: ssf=128 olcSizeLimit: 500 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcPasswordHash: {ARGON2} olcSortVals: member dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$eBzdIP+Zv/H/TmAw0xTXOg$JNQR9asBjEX5XYcTuqygvIY5S3iH43uqaqWQa9e0jNU olcSyncUseSubentry: FALSE olcMonitoring: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/openldap/var/openldap-data olcSuffix: dc=my-organization,dc=com olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=my-organization,dc=com olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$22H7iUTEuPMmwYnLr07PjQ$257rNncoS6L/k4HUXmROU7p2SfinVjfjFeUz4pK8gEw olcSyncUseSubentry: FALSE olcLastBind: TRUE olcMonitoring: TRUE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbMaxSize: 4294967296 dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=my-organization,dc=com olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE dn: olcOverlay={2}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {2}refint olcRefintAttribute: member olcRefintNothing: cn=nothing,dc=my-organization,dc=com dn: olcOverlay={3}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {3}dynlist olcDlAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames* dn: olcDatabase={2}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}monitor olcRootDN: cn=monitor olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$f1aoIjM0CjWwGIyBAsjzyw$j+1bYxs+CYOPR2lXrvamB7yFzSX/nNMiVwIn7vwPRVw olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9803] New: liblber: assertion( ber->ber_buf == NULL ); failed
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9803 Issue ID: 9803 Summary: liblber: assertion( ber->ber_buf == NULL ); failed Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: jengelh(a)inai.de Target Milestone: --- libraries/liblber/io.c function ber_get_next contains a line assert( ber->ber_buf == NULL ); and with a larger application that uses libldap-2.4.46, I am running into that sporadically. I have no idea how that happens, but it seems probable the LDAP server (of which there is also no info on) is sending something that is interpreted as invalid and ber_buf does not get freed, so it's set on the next invocation. ``` (gdb) zcore: io.c:514: ber_get_next: Assertion `ber->ber_buf == NULL' failed. Thread 40 "rpc/34" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffd6ff8700 (LWP 18485)] (gdb) up #1 0x00007ffff20fb585 in abort () from /lib64/libc.so.6 (gdb) #2 0x00007ffff20f285a in __assert_fail_base () from /lib64/libc.so.6 (gdb) #3 0x00007ffff20f28d2 in __assert_fail () from /lib64/libc.so.6 (gdb) #4 0x00007fffee0f48a1 in ber_get_next (sb=0x6040000aa650, len=len@entry=0x7fffd6ff61c8, ber=ber@entry=0x6070000b0360) at io.c:514 514 assert( ber->ber_buf == NULL ); (gdb) p ber $1 = (BerElement *) 0x6070000b0360 (gdb) p *ber $2 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 116, ber_len = 78, ber_usertag = 0, ber_buf = 0x6070000b03d0 "cP", ber_ptr = 0x6070000b03d0 "cP", ber_end = 0x6070000b041e "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} (gdb) up #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) up #6 wait4msg (result=0x7fffd6ff6348, timeout=<optimized out>, all=1, msgid=<optimized out>, ld=0x6040000aa610) at result.c:365 365 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) #7 ldap_result (ld=ld@entry=0x6040000aa610, msgid=<optimized out>, all=all@entry=1, timeout=timeout@entry=0x0, result=result@entry=0x7fffd6ff6348) at result.c:120 120 rc = wait4msg( ld, msgid, all, timeout, result ); (gdb) p result $3 = (LDAPMessage **) 0x7fffd6ff6348 (gdb) p result[0] $4 = (LDAPMessage *) 0x0 (gdb) dow #6 wait4msg (result=0x7fffd6ff6348, timeout=<optimized out>, all=1, msgid=<optimized out>, ld=0x6040000aa610) at result.c:365 365 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) dow #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) p ber $5 = <optimized out> (gdb) dow #4 0x00007fffee0f48a1 in ber_get_next (sb=0x6040000aa650, len=len@entry=0x7fffd6ff61c8, ber=ber@entry=0x6070000b0360) at io.c:514 514 assert( ber->ber_buf == NULL ); (gdb) l 509 * 510 * We expect tag and len to be at most 32 bits wide. 511 */ 512 513 if (ber->ber_rwptr == NULL) { 514 assert( ber->ber_buf == NULL ); 515 ber->ber_rwptr = (char *) &ber->ber_len-1; 516 ber->ber_ptr = ber->ber_rwptr; 517 ber->ber_tag = 0; 518 } (gdb) p ber $6 = (BerElement *) 0x6070000b0360 (gdb) p ber[0] $7 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 116, ber_len = 78, ber_usertag = 0, ber_buf = 0x6070000b03d0 "cP", ber_ptr = 0x6070000b03d0 "cP", ber_end = 0x6070000b041e "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} (gdb) p ber->ber_buf $8 = 0x6070000b03d0 "cP" (gdb) up #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) p len $10 = 99 (gdb) p lc $11 = (LDAPConn *) 0x6080001182a0 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9802] New: Segfault while changing configuration in OpenLDAP 2.6.1
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9802 Issue ID: 9802 Summary: Segfault while changing configuration in OpenLDAP 2.6.1 Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: manuel.flury(a)gmail.com Target Milestone: --- Created attachment 878 --> https://bugs.openldap.org/attachment.cgi?id=878&action=edit GDB traces and olcConfig Dear all, I am trying to configure back_meta for testing virtual directory. Attached is my config. It may not make sense. Trying to change configuration under olcMetaSub={0}uri,olcDatabase={1}meta,cn=config From : {5}rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=people,dc=domain,dc=two,dc=com\")}$1$2" ":" To: {5}rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=mynetworkpeople,o=my.example.com\")}$1$2" ":" I get a segfault. Please find attached the gdb traces. Before segfault, slapd is able to log the following messages: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on 1 descriptor Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on:Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: 10rFeb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: read active on 10 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: connection_get(10): got connid=1000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: connection_read(10): checking for input on id=1000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: op tag 0x66, time 1645812518 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 do_modify Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on 1 descriptor Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: >>> dnPrettyNormal: <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on:Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: <<< dnPrettyNormal: <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config>, <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 MOD dn="olcMetaSub={0}uri,olcDatabase={1}meta,cn=config" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 MOD attr=olcDbRewrite olcDbRewrite Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: slap_get_csn: conn=1000 op=14 generated new csn=20220225180838.334352Z#000000#001#000000 manage=1 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: slap_queue_csn: queueing 0x7f030c140330 20220225180838.334352Z#000000#001#000000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_required entry (olcMetaSub={0}uri,olcDatabase={1}meta,cn=config), objectClass "olcMetaTargetConfig" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "objectClass" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcMetaSub" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbURI" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbIDAssertBind" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbRewrite" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbKeepalive" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbBindTimeout" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbCancel" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbChaseReferrals" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNoRefs" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNoUndefFilter" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNretries" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbProtocolVersion" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbRebindAsUser" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbSessionTrackingRequest" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbTFSupport" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "structuralObjectClass" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "entryUUID" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "creatorsName" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "createTimestamp" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "entryCSN" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "modifiersName" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "modifyTimestamp" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: >>> dnPrettyNormal: <dc=my,dc=example,dc=com> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: <<< dnPrettyNormal: <dc=my,dc=example,dc=com>, <dc=my,dc=example,dc=com> Best Regards -- You are receiving this mail because: You are on the CC list for the issue.

1 19

← Newer
1
...
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2022