- openldap-bugs - openldap.org

(ITS#7444) Check the return value of ldap_pvt_thread_set_concurrency
by tixu＠cs.ucsd.edu 16 Nov '12

16 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, Still the verbosity idea. In the current version of slapd, when handling users' "concurrency" setting, slapd does not check the return value of "ldap_pvt_thread_set_concurrency" (essentially the return value of "pthread_setconcurrency") to see whether the setting is successful or not. So when the user setting is inappropriate (i.e., too big), slapd says nothing. But users have no way to be aware of such configuration failure. I suggest to check and notify users in this case. Here's the patch: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:52:37.211421828 -0800 @@ -1530,7 +1530,14 @@ break; case CFG_CONCUR: - ldap_pvt_thread_set_concurrency(c->value_int); + + if(ldap_pvt_thread_set_concurrency(c->value_int) != 0) { + snprintf( c->cr_msg, sizeof( c->cr_msg ), + "concurrency=%d is not valid; using the default setting", + c->value_int ); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0 ); + + } break; case CFG_THREADS:

1 0

(ITS#7443) Data range of index_intlen
by tixu＠cs.ucsd.edu 16 Nov '12

16 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, I suggest to make the verbosity upon changing users' configuration settings, especially some of the configuration specifications are not written in the manpage. It's too strong to assume that all the users carefully read the source code. This can save users' time to diagnose why slapd does not behave as their expectation. This ITS is for the "index_intlen" directive. ---------- What the manpage says ---------- index_intlen <integer> Specify the key length for ordered integer indices. The most significant bytes of the binary integer will be used for index keys. The default value is 4, which provides exact indexing for 31 bit values. A floating point representation is used to index too large values. ------------------------------------------------------ Actually, 4 is not only the default value but also the minimum value. From the source code, I knew the index_intlen is with the data range [4, 255]. Any out-of-range value will be converted to the boundaries without notifying users. Here's the patch I proposed: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:10:40.111362005 -0800 @@ -1754,10 +1754,16 @@ break; case CFG_IX_INTLEN: - if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) + if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d smaller than minimum value %d --> auto convert to the minimum.", c->value_int, SLAP_INDEX_INTLEN_DEFAULT); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = SLAP_INDEX_INTLEN_DEFAULT; - else if ( c->value_int > 255 ) + } + else if ( c->value_int > 255 ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d larger than maximum value 255 --> auto convert to the maximum.", c->value_int); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = 255; + } index_intlen = c->value_int; index_intlen_strlen = SLAP_INDEX_INTLEN_STRLEN( index_intlen );

1 0

(ITS#7442) Data range of index_intlen
by tixu＠cs.ucsd.edu 16 Nov '12

16 Nov '12

Full_Name: Tianyin Xu Version: 2.4.33 OS: Ubuntu 12.04 (actually doesn't matter) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2607:f720:1300:1241:590b:49c:889f:7b21) Hi, all, I suggest to make the verbosity upon changing users' configuration settings, especially some of the configuration specifications are not written in the manpage. It's too strong to assume that all the users carefully read the source code. This can save users' time to diagnose why slapd does not behave as their expectation. This ITS is for the "index_intlen" directive. ---------- What the manpage says ---------- index_intlen <integer> Specify the key length for ordered integer indices. The most significant bytes of the binary integer will be used for index keys. The default value is 4, which provides exact indexing for 31 bit values. A floating point representation is used to index too large values. ------------------------------------------------------ Actually, 4 is not only the default value but also the minimum value. From the source code, I knew the index_intlen is with the data range [4, 255]. Any out-of-range value will be converted to the boundaries without notifying users. Here's the patch I proposed: --- ../openldap-2.4.33/servers/slapd/bconfig.c 2012-10-10 05:18:49.000000000 -0700 +++ servers/slapd/bconfig.c 2012-11-16 14:10:40.111362005 -0800 @@ -1754,10 +1754,16 @@ break; case CFG_IX_INTLEN: - if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) + if ( c->value_int < SLAP_INDEX_INTLEN_DEFAULT ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d smaller than minimum value %d --> auto convert to the minimum.", c->value_int, SLAP_INDEX_INTLEN_DEFAULT); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = SLAP_INDEX_INTLEN_DEFAULT; - else if ( c->value_int > 255 ) + } + else if ( c->value_int > 255 ) { + snprintf( c->cr_msg, sizeof(c->cr_msg), "index_intlen=%d larger than maximum value 255 --> auto convert to the maximum.", c->value_int); + Debug(LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->cr_msg, 0); c->value_int = 255; + } index_intlen = c->value_int; index_intlen_strlen = SLAP_INDEX_INTLEN_STRLEN( index_intlen );

1 0

(ITS#7441) cn=config filters ignore {number}
by h.b.furuseth＠usit.uio.no 16 Nov '12

16 Nov '12

Full_Name: Hallvard B Furuseth Version: 2.4.33 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard cn=config ignores the {number} prefix in filters: "(olcDatabase={2}hdb)" -> matches all HDB databases "(olcdatabase={2})" -> none ldapcompare does the opposite: "olcdatabase:{2}hdb" -> TRUE (at DN olcdatabase={2}hdb,cn=config) "olcdatabase:{2} -> FALSE "olcdatabase:hdb" -> FALSE

1 0

Re: (ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 16 Nov '12

16 Nov '12

I just uploaded a slightly updated patch to: ftp://ftp.openldap.org/incoming/rhafer-20121116-Use-non-blocking-IO-during-… The code is now only enabled when LDAP_USE_NON_BLOCKING_TLS is defined. Mainly because NSS and GNUTLS show some issues with not-blocking sockets. See my mail on -devel. Additionally the non-blocking handshake is only done if LDAP_OPT_TIMEOUT is set. Previously I used LDAP_OPT_NETWORK_TIMEOUT but IMO LDAP_OPT_TIMEOUT is the better choice. On Thu, Nov 01, 2012 at 05:36:54PM +0000, rhafer(a)suse.de wrote: > I've just uploaded: > > ftp://ftp.openldap.org/incoming/rhafer-Use-non-blocking-IO-during-SSL-Hands… > [..] Ralf

1 0

Re: (ITS#7440) ssl/tls replication not working
by quanah＠zimbra.com 15 Nov '12

15 Nov '12

--On Friday, November 16, 2012 12:17 AM +0000 beni.anil(a)gmail.com wrote: > Please let me know if i am going wrong. As I already told you. Use the openldap-technical mailing list. This ITS will be closed, again. <http://www.openldap.org/lists/mm/listinfo/openldap-technical> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7440) ssl/tls replication not working
by beni.anil＠gmail.com 15 Nov '12

15 Nov '12

Full_Name: Version: 2.4.20 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.245.72.156) Hi List While configuring openldap replication with ssl. I am getting below log messages TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1069 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1070 fd=15 ACCEPT from IP=10.242.151.17:44531 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1070 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1071 fd=15 ACCEPT from IP=10.242.151.17:44533 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1071 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying i am using self singed certificates. when i do search # ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://10.xx.xx.x' -ZZ ldap_url_parse_ext(ldaps://10.xx.xx.x) ldap_create ldap_url_parse_ext(ldaps://10.xx.xx.x:636/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 10.xx.xx.x:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.xx.xx.x:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1942aa0 msgid 1 wait4msg ld 0x1942aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x1942aa0 msgid 1 all 1 ** ld 0x1942aa0 Connections: * host: 10.243.129.6 port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 11:58:52 2012 ** ld 0x1942aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1942aa0 request count 1 (abandoned 0) ** ld 0x1942aa0 Response Queue: Empty ld 0x1942aa0 response count 0 ldap_chkResponseList ld 0x1942aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x1942aa0 NULL ldap_int_select read1msg: ld 0x1942aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x1942aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1942aa0 0 new referrals read1msg: mark request completed, ld 0x1942aa0 msgid 1 request done: ld 0x1942aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started ]# ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://localhost' -ZZ ldap_url_parse_ext(ldaps://localhost) ldap_create ldap_url_parse_ext(ldaps://localhost:636/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x2172aa0 msgid 1 wait4msg ld 0x2172aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x2172aa0 msgid 1 all 1 ** ld 0x2172aa0 Connections: * host: localhost port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 12:14:16 2012 ** ld 0x2172aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x2172aa0 request count 1 (abandoned 0) ** ld 0x2172aa0 Response Queue: Empty ld 0x2172aa0 response count 0 ldap_chkResponseList ld 0x2172aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x2172aa0 NULL ldap_int_select read1msg: ld 0x2172aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x2172aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x2172aa0 0 new referrals read1msg: mark request completed, ld 0x2172aa0 msgid 1 request done: ld 0x2172aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started slapd.conf # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /apps/openldap/var/run/slapd.pid argsfile /apps/openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /app/openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read #access to * #by self write #by users read #by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ### logging ### logfile /apps/logs/ldap loglevel 16640 ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=ibm,dc=com" # Restrict userPassword to be used for authentication only, but allow users to modify # their own passwords. access to attrs=userPassword by self write by * auth # Simple ACL granting read access to the world access to * by * read rootdn "cn=Manager,dc=ibm,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}dXDFS3TAzYf8DrDSYWY ################## SSL ########################################## # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateKeyFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem # #################################################################### #Replication Configuration overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index entryCSN,entryUUID eq serverid 2 ## DR ldap server replication syncrepl rid=444 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 syncrepl rid=777 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 #### mirrormode true ####ache Entries ##### cachesize 3000000 lastmod on checkpoint 128 15 concurrency 100 #database monitor # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /apps/openldap/var/openldap-data # Indices to maintain #index objectClass eq index mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type eq index givenName,sn,city,question,behavValue,cn,extName sub index displayName approx my ldap.conf file URI ldaps://localhost BASE dc=ibm,dc=com ssl start_tls ssl on tls_checkpeer no TLS_REQCERT allow tls_cacertfile /apps/openldap/etc/openldap/certs/mmprodam04.pem tls_cacertdir /apps/openldap/etc/openldap/certs I am using self signed certificate, Please let me know if i am going wrong.

1 0

(ITS#7439) crash in rwm when tree is syncrepl synced and database ldap with rwm inside same tree
by glen＠delfi.ee 15 Nov '12

15 Nov '12

Full_Name: Elan Ruusamäe Version: 2.4.33 OS: PLD Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.131.56.149) i'm setting up my tree so that People has one subtree via database ldap as ou=something,ou=People,dc=example (subordinate), and and i have also whole dc=example setup replica as syncrepl. and if i have both (syncrepl and the database ldap) enabled slapd crashes also the database ldap is rwm rewritten to match tree it's linked into --- slapd.conf ---: include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/nis.schema include /usr/share/openldap/schema/misc.schema include /usr/share/openldap/schema/rfc2739.schema include /usr/share/openldap/schema/courier.schema include /usr/share/openldap/schema/horde.schema include /usr/share/openldap/schema/openssh-lpk.schema include /usr/share/openldap/schema/samba.schema include /usr/share/openldap/schema/sudo.schema include /etc/openldap/schema/local.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args allow bind_v2 loglevel -1 modulepath /usr/lib64/openldap moduleload back_bdb.la moduleload back_ldap.la moduleload back_monitor.la moduleload back_relay.la moduleload rwm.la moduleload syncprov.la moduleload translucent.la include /etc/openldap/slapd-ad.conf include /etc/openldap/slapd-db.conf --- slapd-ad.conf ---: database ldap suffix "ou=Basement,ou=People,dc=example,dc=net" uri "ldap://a.b.c.d/" idassert-bind bindmethod=simple binddn=CN=glen,OU=Serviceaccounts,OU=Technical,DC=example,DC=org credentials=OBFUSCATED idle-timeout 1800 subordinate chase-referrals no rebind-as-user yes overlay rwm rwm-suffixmassage "ou=Basement,ou=People,dc=example,dc=net" "ou=Technical,dc=example,dc=org" rwm-map objectclass account user rwm-map attribute uidNumber employeeID rwm-map attribute gidNumber primaryGroupID rwm-map attribute uid sAMAccountName rwm-map attribute physicalDeliveryOfficeName rwm-map attribute cn name rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute company company rwm-map attribute entry entry rwm-map attribute title title rwm-map attribute givenName givenName rwm-map attribute homeDirectory homeDirectory rwm-map attribute displayName displayName rwm-map attribute dn distinguishedName rwm-map attribute userPassword unicodePassword rwm-map attribute departmentNumber department rwm-map attribute member member rwm-map attribute manager managedby rwm-map attribute sambaProfilePath profilePath rwm-map attribute * --- slapd-db.conf ---: database bdb suffix "dc=example,dc=net" rootdn "cn=Manager,dc=example,dc=net" rootpw OBFUSCATED directory /var/lib/openldap-data index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN,entryUUID eq dbconfig set_cachesize 0 268435456 1 dbconfig set_lg_bsize 2097152 include /etc/openldap/slapd-syncrepl.conf --- slapd-syncrepl.conf ---: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 sizelimit 10000 syncrepl rid=7 provider=ldap://ldap searchbase="dc=example,dc=net" type=refreshOnly interval=00:00:01:00 retry="120 +" scope=sub attrs="*" bindmethod=simple binddn="cn=replica,ou=Service Users,dc=example,dc=net" credentials=OBFUSCATED trace obtained as (altho glibc MALLOC_CHECK_ kicks in and gdb has no chance): # gdb --args slapd -u slapd -g slapd -h "ldap:/// ldapi:///" -d -1 (gdb) r ... 50a55ca9 => access_allowed: search access to "uid=user1,ou=People,dc=example,dc=net" "entryUUID" requested 50a55ca9 <= root access granted 50a55ca9 => access_allowed: search access granted by manage(=mwrscxd) 50a55ca9 <= test_filter 6 50a55ca9 => bdb_dn2id_children("uid=user1,ou=people,dc=example,dc=net") 50a55ca9 <= bdb_dn2id_children("uid=user1,ou=people,dc=example,dc=net"): no (-30989) 50a55ca9 send_ldap_result: conn=-1 op=0 p=3 50a55ca9 send_ldap_result: err=0 matched="" text="" 50a55ca9 ==> rewrite_context_apply [depth=1] string='ou=Basement,ou=People,dc=example,dc=net' 50a55ca9 ==> rewrite_rule_apply rule='((.+),)?ou=Basement,[ ]?ou=People,[ ]?dc=delfi,[ ]?dc=net$' string='ou=Basement,ou=People,dc=example,dc=net' [1 pass(es)] 50a55ca9 ==> rewrite_context_apply [depth=1] res={0,'ou=Serviceaccounts,ou=Technical,dc=example,dc=org'} 50a55ca9 [rw] searchDN: "ou=Basement,ou=People,dc=example,dc=net" -> "ou=Serviceaccounts,ou=Technical,dc=example,dc=org" 50a55ca9 >>> dnPrettyNormal: <ou=Serviceaccounts,ou=Technical,dc=example,dc=org> => ldap_bv2dn(ou=Serviceaccounts,ou=Technical,dc=example,dc=org,0) <= ldap_bv2dn(ou=Serviceaccounts,ou=Technical,dc=example,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=Serviceaccounts,ou=Technical,dc=example,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=serviceaccounts,ou=technical,dc=example,dc=org)=0 50a55ca9 <<< dnPrettyNormal: <ou=Serviceaccounts,ou=Technical,dc=example,dc=org>, <ou=serviceaccounts,ou=technical,dc=example,dc=org> *** glibc detected *** /usr/sbin/slapd: free(): invalid pointer: 0x00007fffd011c037 *** 50a55ca9 daemon: epoll: listen=11 active_threads=0 tvp=zero 50a55ca9 daemon: epoll: listen=12 active_threads=0 tvp=zero 50a55ca9 daemon: epoll: listen=13 active_threads=0 tvp=zero ======= Backtrace: ========= /lib64/libc.so.6(+0x79df6)[0x7ffff61d8df6] /usr/sbin/slapd(ava_free+0x2e)[0x5555555ac43e] /usr/sbin/slapd(filter_free_x+0x13a)[0x55555559317a] /usr/lib64/openldap/rwm-2.4.so.2(+0x9c6d)[0x7ffff1d82c6d] /usr/lib64/openldap/rwm-2.4.so.2(rwm_filter_map_rewrite+0x26)[0x7ffff1d839c6] /usr/lib64/openldap/rwm-2.4.so.2(+0x5461)[0x7ffff1d7e461] /usr/sbin/slapd(overlay_op_walk+0x4a)[0x5555555fc23a] /usr/sbin/slapd(+0xa83cb)[0x5555555fc3cb] /usr/sbin/slapd(+0xa6812)[0x5555555fa812] /usr/sbin/slapd(overlay_op_walk+0x4a)[0x5555555fc23a] /usr/sbin/slapd(+0xa83cb)[0x5555555fc3cb] /usr/sbin/slapd(+0x9d253)[0x5555555f1253] /usr/sbin/slapd(+0xa11b8)[0x5555555f51b8] /usr/lib64/libldap_r-2.4.so.2(+0x119b3)[0x7ffff7b9a9b3] /lib64/libpthread.so.0(+0x8034)[0x7ffff6512034] /lib64/libc.so.6(clone+0x6d)[0x7ffff62477ad] ======= Memory map: ======== 555555554000-55555567c000 r-xp 00000000 fd:00 20850901 /usr/sbin/slapd 55555587c000-55555587f000 r--p 00128000 fd:00 20850901 /usr/sbin/slapd 55555587f000-555555886000 rw-p 0012b000 fd:00 20850901 /usr/sbin/slapd 555555886000-555555c3f000 rw-p 00000000 00:00 0 [heap] 7fffd0000000-7fffd015e000 rw-p 00000000 00:00 0 7fffd015e000-7fffd4000000 ---p 00000000 00:00 0 7fffd67fe000-7fffd77ff000 rw-p 00000000 00:00 0 7fffd77ff000-7fffd7800000 ---p 00000000 00:00 0 7fffd7800000-7fffd8000000 rw-p 00000000 00:00 0 7fffd8000000-7fffd8021000 rw-p 00000000 00:00 0 7fffd8021000-7fffdc000000 ---p 00000000 00:00 0 7fffdc3a7000-7fffdc3bc000 r-xp 00000000 fd:00 21096302 /lib64/libgcc_s.so.1 7fffdc3bc000-7fffdc5bb000 ---p 00015000 fd:00 21096302 /lib64/libgcc_s.so.1 7fffdc5bb000-7fffdc5bc000 rw-p 00014000 fd:00 21096302 /lib64/libgcc_s.so.1 7fffdc5bc000-7fffdc5bd000 ---p 00000000 00:00 0 7fffdc5bd000-7fffdcdbd000 rw-p 00000000 00:00 0 7fffdcdbd000-7fffdcdc5000 rw-s 00000000 fd:00 33596447 /var/lib/openldap-data/__db.006 7fffdcdc5000-7fffdce77000 rw-s 00000000 fd:00 33596446 /var/lib/openldap-data/__db.005 7fffdce77000-7fffdd0b7000 rw-s 00000000 fd:00 38665430 /var/lib/openldap-data/__db.004 7fffdd0b7000-7ffff10b9000 rw-s 00000000 fd:00 38665429 /var/lib/openldap-data/__db.003 7ffff10b9000-7ffff1965000 rw-s 00000000 fd:00 33952840 /var/lib/openldap-data/__db.002 7ffff1965000-7ffff196b000 r-xp 00000000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff196b000-7ffff1b6a000 ---p 00006000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff1b6a000-7ffff1b6b000 r--p 00005000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff1b6b000-7ffff1b6c000 rw-p 00006000 fd:00 36390022 /usr/lib64/openldap/translucent-2.4.so.2.8.5 7ffff1b6c000-7ffff1b78000 r-xp 00000000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1b78000-7ffff1d77000 ---p 0000c000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1d77000-7ffff1d78000 r--p 0000b000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1d78000-7ffff1d79000 rw-p 0000c000 fd:00 36390017 /usr/lib64/openldap/syncprov-2.4.so.2.8.5 7ffff1d79000-7ffff1d87000 r-xp 00000000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1d87000-7ffff1f86000 ---p 0000e000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1f86000-7ffff1f87000 r--p 0000d000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1f87000-7ffff1f88000 rw-p 0000e000 fd:00 36389997 /usr/lib64/openldap/rwm-2.4.so.2.8.5 7ffff1f88000-7ffff1f8b000 r-xp 00000000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff1f8b000-7ffff218a000 ---p 00003000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff218a000-7ffff218b000 r--p 00002000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff218b000-7ffff218c000 rw-p 00003000 fd:00 36390027 /usr/lib64/openldap/back_relay-2.4.so.2.8.5 7ffff218c000-7ffff21a4000 r-xp 00000000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff21a4000-7ffff23a4000 ---p 00018000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff23a4000-7ffff23a5000 r--p 00018000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff23a5000-7ffff23a7000 rw-p 00019000 fd:00 36390012 /usr/lib64/openldap/back_monitor-2.4.so.2.8.5 7ffff23a7000-7ffff23ab000 rw-p 00000000 00:00 0 7ffff23ab000-7ffff23cf000 r-xp 00000000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff23cf000-7ffff25ce000 ---p 00024000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff25ce000-7ffff25cf000 r--p 00023000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff25cf000-7ffff25d1000 rw-p 00024000 fd:00 36390007 /usr/lib64/openldap/back_ldap-2.4.so.2.8.5 7ffff25d1000-7ffff25d2000 rw-p 00000000 00:00 0 7ffff25d2000-7ffff26ff000 r-xp 00000000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff26ff000-7ffff28ff000 ---p 0012d000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff28ff000-7ffff2901000 r--p 0012d000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff2901000-7ffff2904000 rw-p 0012f000 fd:00 36389991 /usr/lib64/libslapd_db-4.6.so 7ffff2904000-7ffff292f000 r-xp 00000000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff292f000-7ffff2b2f000 ---p 0002b000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff2b2f000-7ffff2b30000 r--p 0002b000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff2b30000-7ffff2b31000 rw-p 0002c000 fd:00 36390002 /usr/lib64/openldap/back_bdb-2.4.so.2.8.5 7ffff2b31000-7ffff2b4a000 rw-p 00000000 00:00 0 7ffff2b4a000-7ffff2b4e000 r-xp 00000000 fd:00 38016672 /usr/lib64/sasl2/libplain.so.2.0.25 7ffff2b4e000-7ffff2d4d000 ---p 00004000 fd:00 38016672 /usr/lib64/sasl2/libplain.so.2.0.25 7ffff2d4d000-7ffff2d4e000 rw-p 00003000 fd:00 38016672 /usr/lib64/sasl2/libplain.so.2.0.25 7ffff2d4e000-7ffff2d52000 r-xp 00000000 fd:00 37882936 /usr/lib64/sasl2/liblogin.so.2.0.25 7ffff2d52000-7ffff2f51000 ---p 00004000 fd:00 37882936 /usr/lib64/sasl2/liblogin.so.2.0.25 7ffff2f51000-7ffff2f52000 rw-p 00003000 fd:00 37882936 /usr/lib64/sasl2/liblogin.so.2.0.25 Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffd7fff700 (LWP 15473)] 0x00007ffff6194395 in raise () from /lib64/libc.so.6 (gdb)

1 0

Re: (ITS#7438) ssl/tls replication not working
by quanah＠zimbra.com 15 Nov '12

15 Nov '12

--On Thursday, November 15, 2012 5:27 PM +0000 beni.anil(a)gmail.com wrote: > Full_Name: > Version: 2.4.20 > OS: RHEL 6.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (14.140.116.135) The ITS system is for filing bug reports. For configuration issues such as yours, please use the openldap-technical mailing list. I will note that your reported version of OpenLDAP is extremely old. Although this may be unrelated to the issue you are facing, you would be well served to use something current. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7438) ssl/tls replication not working
by beni.anil＠gmail.com 15 Nov '12

15 Nov '12

Full_Name: Version: 2.4.20 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (14.140.116.135) Hi List While configuring openldap replication with ssl. I am getting below log messages TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1069 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1070 fd=15 ACCEPT from IP=10.242.151.17:44531 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1070 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying conn=1071 fd=15 ACCEPT from IP=10.242.151.17:44533 (IP=0.0.0.0:636) TLS: can't accept: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol. conn=1071 fd=15 closed (TLS negotiation failure) slap_client_connect: URI=ldap://10.242.151.17:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.242.151.17:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=777 rc -1 retrying slap_client_connect: URI=ldap://10.243.129.6:636 Warning, ldap_start_tls failed (-1) slap_client_connect: URI=ldap://10.243.129.6:636 DN="cn=manager,dc=idm,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=444 rc -1 retrying i am using self singed certificates. when i do search # ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://10.xx.xx.x' -ZZ ldap_url_parse_ext(ldaps://10.xx.xx.x) ldap_create ldap_url_parse_ext(ldaps://10.xx.xx.x:636/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 10.xx.xx.x:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.xx.xx.x:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar178(a)sapient.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x1942aa0 msgid 1 wait4msg ld 0x1942aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x1942aa0 msgid 1 all 1 ** ld 0x1942aa0 Connections: * host: 10.243.129.6 port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 11:58:52 2012 ** ld 0x1942aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x1942aa0 request count 1 (abandoned 0) ** ld 0x1942aa0 Response Queue: Empty ld 0x1942aa0 response count 0 ldap_chkResponseList ld 0x1942aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x1942aa0 NULL ldap_int_select read1msg: ld 0x1942aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x1942aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x1942aa0 0 new referrals read1msg: mark request completed, ld 0x1942aa0 msgid 1 request done: ld 0x1942aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started ]# ldapsearch -d 1 -x -b "dc=ibm,dc=com" -H 'ldaps://localhost' -ZZ ldap_url_parse_ext(ldaps://localhost) ldap_create ldap_url_parse_ext(ldaps://localhost:636/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAPIENT/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS certificate verification: Error, self signed certificate TLS certificate verification: depth: 0, err: 18, subject: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com, issuer: /C=IN/ST=HR/L=GGN/O=SAP/OU=ISST/CN=localhost/emailAddress=akumar(a)sap.com TLS trace: SSL_connect:SSLv3 read server certificate A TLS trace: SSL_connect:SSLv3 read server done A TLS trace: SSL_connect:SSLv3 write client key exchange A TLS trace: SSL_connect:SSLv3 write change cipher spec A TLS trace: SSL_connect:SSLv3 write finished A TLS trace: SSL_connect:SSLv3 flush data TLS trace: SSL_connect:SSLv3 read server session ticket A TLS trace: SSL_connect:SSLv3 read finished A TLS: unable to get peer certificate. ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x2172aa0 msgid 1 wait4msg ld 0x2172aa0 msgid 1 (infinite timeout) wait4msg continue ld 0x2172aa0 msgid 1 all 1 ** ld 0x2172aa0 Connections: * host: localhost port: 636 (default) refcnt: 2 status: Connected last used: Thu Nov 15 12:14:16 2012 ** ld 0x2172aa0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x2172aa0 request count 1 (abandoned 0) ** ld 0x2172aa0 Response Queue: Empty ld 0x2172aa0 response count 0 ldap_chkResponseList ld 0x2172aa0 msgid 1 all 1 ldap_chkResponseList returns ld 0x2172aa0 NULL ldap_int_select read1msg: ld 0x2172aa0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 31 contents: read1msg: ld 0x2172aa0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x2172aa0 0 new referrals read1msg: mark request completed, ld 0x2172aa0 msgid 1 request done: ld 0x2172aa0 msgid 1 res_errno: 1, res_error: <TLS already started>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Operations error (1) additional info: TLS already started slapd.conf # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /apps/openldap/var/run/slapd.pid argsfile /apps/openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /app/openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read #access to * #by self write #by users read #by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ### logging ### logfile /apps/logs/ldap loglevel 16640 ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=ibm,dc=com" # Restrict userPassword to be used for authentication only, but allow users to modify # their own passwords. access to attrs=userPassword by self write by * auth # Simple ACL granting read access to the world access to * by * read rootdn "cn=Manager,dc=ibm,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}dXDFS3TAzYf8DrDSYWY ################## SSL ########################################## # TLSCipherSuite HIGH:MEDIUM:+SSLv3 TLSCACertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem TLSCertificateKeyFile /apps/openldap/etc/openldap/certs/mmprodadm04.pem # #################################################################### #Replication Configuration overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index entryCSN,entryUUID eq serverid 2 ## DR ldap server replication syncrepl rid=444 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 syncrepl rid=777 provider=ldap://10.x.x.x:636 binddn="cn=Manager,dc=ibm,dc=com" bindmethod=simple credentials=xxxxxxxxx starttls=yes tls_reqcert=never searchbase="dc=ibm,dc=com" type=refreshAndPersist retry="5 5 300 +" interval=00:00:00:10 #### mirrormode true ####ache Entries ##### cachesize 3000000 lastmod on checkpoint 128 15 concurrency 100 #database monitor # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /apps/openldap/var/openldap-data # Indices to maintain #index objectClass eq index mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type eq index givenName,sn,city,question,behavValue,cn,extName sub index displayName approx my ldap.conf file URI ldaps://localhost BASE dc=ibm,dc=com ssl start_tls ssl on tls_checkpeer no TLS_REQCERT allow tls_cacertfile /apps/openldap/etc/openldap/certs/mmprodam04.pem tls_cacertdir /apps/openldap/etc/openldap/certs I am using self signed certificate, Please let me know if i am going wrong.

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 14 Nov '12

14 Nov '12

Michael Ströder wrote: > Jan Synacek wrote: >> On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: >>> FYI: I sent output of bt full to Jan with some data stripped because of >>> privacy concerns. >>> >>> Note that the entry for which constraint checking is done is added to the >>> database. So something might be wrong *after* the check. >> >> Can you please try the attached patch? > > It seems to work. But I will test it during the next days more thoroughly. No more seg faults so far in my setup which uses slapo-constraints quite heavily. So I'd appreciate if Jan's patch lands in RE24 branch. Ciao, Michael.

1 0

Re: (ITS#7436) slapo-deref not working
by rhafer＠suse.de 14 Nov '12

14 Nov '12

On Fri, Nov 09, 2012 at 02:51:59PM +0000, rhafer(a)suse.de wrote: > pcache still missing I was wrong, pcache isn't affected by this problem.

1 0

(ITS#7437) Request to submit EnMasse project to OpenLDAP
by shawn.mckinney＠joshuatreesoftware.us 10 Nov '12

10 Nov '12

Full_Name: Shawn McKinney Version: all OS: all URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.34.196.221) Hello, We have created a new application, called EnMasse. EnMasse is a web application that implements RESTful Web services to interface with Fortress/OpenLDAP. EnMasse was built using established Open Source technologies including Apache CXF (web services stack), Spring Framework (glue), Maven (dependencies) and JAXB (data binding layer) and runs inside any reasonably compliant Java Servlets container. EnMasses service access decisions are made using declarative Java EE and Spring security policy hooks that are wired to connect back to the Fortress RBAC component itself. This product has not been published and we would like to release it as one of the products under OpenLDAP family of products. What we would like from OpenLDAP foundation is the following: 1. Separate GIT project called EnMasse. 2. Mailing list for developers and users to communicate with project team. 3. Issue tracking for EnMasse project. 4. Project page for overview and how to find out more information. I have uploaded one package, entitled enmasse-openldap-submission.zip to our FTP server that contains the source, documentation and other items for you to look at. host: joshuatreesoftware.us user: jtreeguest pw: Guest123 Everything under the /target folder contain generated project artifacts including deployable web archive (war) and javadoc. These artifacts will not be checked into GIT. The source is located /src folder in the package. Statement of origin for submitted works: The contributed EnMasse works described above were provided by JoshuaTree Software, LLC and referenced in this ITS were created by JoshuaTree Software, LLC, who is the exclusive owner of the contributed works. The contributed works are made available as indicated in the copyright and license statements attached to the work. Sincerely, Shawn McKinney Principal, JoshuaTree Software, LLC

1 0

Re: (ITS#7435) telexNumber
by quanah＠zimbra.com 09 Nov '12

09 Nov '12

--On Friday, November 09, 2012 6:59 AM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Roy Luckow >> Version: 2.4.30 >> OS: Win Server 2003 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.4.225.4) >> >> >> LDAP Search for attribute "telexNumber" doesn't work. >> If I do a search filter "(telexNumber=*)" --> Then I get my results >> (total of >> 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the >> Message "No entries matched" > > This is by design: "telexNumber" has no matching rule. This ITS will be > closed. I would note that you can force matching rules to apply to a particular attribute during a search. You might try the matching rules for telephoneNumber. Hope this helps, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7436) slapo-deref not working
by rhafer＠suse.de 09 Nov '12

09 Nov '12

Fixed slapo-deref. pcache still missing.

1 0

Re: (ITS#7436) slapo-deref not working
by rhafer＠suse.de 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 02:04:13PM +0000, ralf(a)OpenLDAP.org wrote: > Independ of whether the slapo-deref beign configured or not it always returns > "Critical extension is unavailable" to the client. > > This is because it doesn't call overlay_register_control anywhere in its code. > Fix is underway. The PCACHE_CONTROL_PRIVDB control defined in slapo-pcache seems to suffer the same problem. (though that's still hidden behind LDAP_DEVEL)

1 0

(ITS#7436) slapo-deref not working
by ralf＠OpenLDAP.org 09 Nov '12

09 Nov '12

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.118.144.197) Submitted by: ralf Independ of whether the slapo-deref beign configured or not it always returns "Critical extension is unavailable" to the client. This is because it doesn't call overlay_register_control anywhere in its code. Fix is underway.

1 0

Re: (ITS#7435) telexNumber
by masarati＠aero.polimi.it 08 Nov '12

08 Nov '12

> Full_Name: Roy Luckow > Version: 2.4.30 > OS: Win Server 2003 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.4.225.4) > > > LDAP Search for attribute "telexNumber" doesn't work. > If I do a search filter "(telexNumber=*)" --> Then I get my results (total > of > 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the > Message "No entries matched" This is by design: "telexNumber" has no matching rule. This ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7435) telexNumber
by Roy.Luckow＠swmh.de 08 Nov '12

08 Nov '12

Full_Name: Roy Luckow Version: 2.4.30 OS: Win Server 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.4.225.4) LDAP Search for attribute "telexNumber" doesn't work. If I do a search filter "(telexNumber=*)" --> Then I get my results (total of 4600 hits). If I set the search as "(telexNumber=*1*)" --> Then I get the Message "No entries matched"

1 0

Re: (ITS#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 08 Nov '12

08 Nov '12

--On Friday, November 09, 2012 2:10 AM +0000 quanah(a)zimbra.com wrote: > --On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > >> Full_Name: Barry Lance >> Version: 2.4.28 >> OS: Ubuntu 12.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (70.226.37.226) >> > > Hi Barry, Hi Barry, Are you sure you aren't hitting: Fixed slapd-ldap idassert bind handling (ITS#7403) Fixed in OpenLDAP 2.4.33? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7434) idassert-bind fails after restarting slapd
by quanah＠zimbra.com 08 Nov '12

08 Nov '12

--On Friday, November 09, 2012 1:55 AM +0000 blance3459(a)hotmail.com wrote: > Full_Name: Barry Lance > Version: 2.4.28 > OS: Ubuntu 12.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (70.226.37.226) > Hi Barry, Thanks for the report. I would note that OpenLDAP 2.4.28 is 5 releases old at this point. I don't see anything specific in the CHANGES file between 2.4.28 and 2.4.33 for this issue, but it may be fixed and not logged in there. Confirming that the behavior persists with 2.4.33 would be helpful. Also, don't confuse encoding with encryption. ;) It is standard in LDIF for data to be base64 encoded if the attribute value requires it based on the characters in the data. You can use various tools to decode the attribute value back out. Regards, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7434) idassert-bind fails after restarting slapd
by blance3459＠hotmail.com 08 Nov '12

08 Nov '12

Full_Name: Barry Lance Version: 2.4.28 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.226.37.226) Two servers: Master (192.168.1.1) and Replica (192.168.1.2) both running slap 2.4.28 and ubuntu 12.04. Replica is a replication partner of Master using syncrepl. Replication is working fine. When I attempt to add a chain overlay to Replica to send all writes over to the master, it works exactly as expected allowing both normal users and the rootdn to make appropriate changes. However, once I either reboot the replica server or restart slapd, the chain overlay fails to allow any changes on the master. Looking at syslog shows that before the reboot/restart the requesting users' dn is proxied over as expected. After the restarting slapd or rebooting Replica, all changes are proxied anonymously (dn=""). I am using simple binds at this point in the project, but it doesn't seems to matter if I proxy in the clear, ldaps, or TLS the result is the same. All three methods can successfully negotiate a connection. I've even tried switching between using the rootdn and a different user as the binddn in my overlay, but the result is still the same no matter what I use for the binddn. When I look at my config, I notice that "chain-idassert-bind" appears to be hashed or encrypted in thew config. Is that normal? Just seems really odd that my config would work immediately when added, but fail after the the daemon has been restarted. Am I missing something really silly? Hopefully, someone can assist me on this. I've been driving myself crazy trying to figure out why this behavior is occurring. Disclaimer: I am using openldap as part of my capstone project for graduation. I'm not asking for anyone to do my "homework" for me, I'm just stuck on this one issue that I would love to resolve so I can move on to the Kerberos phase of my project (and maybe even study for an exam coming up in my algorithms class next week). Here is my overlay config using the rootDN and TLS (on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self starttls=critical tls_cacert=/etc/ssl/certs/cacert.pem tls_reqcert=demand And without TLS (also on Replica): dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend, cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.net/" olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=(secret) mode=self

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 08 Nov '12

08 Nov '12

Jan Synacek wrote: > On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: >> FYI: I sent output of bt full to Jan with some data stripped because of >> privacy concerns. >> >> Note that the entry for which constraint checking is done is added to the >> database. So something might be wrong *after* the check. > > Can you please try the attached patch? It seems to work. But I will test it during the next days more thoroughly. Ciao, Michael.

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by jsynacek＠redhat.com 08 Nov '12

08 Nov '12

This is a multi-part message in MIME format. --------------000604070905040801090708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/08/2012 08:14 AM, michael(a)stroeder.com wrote: > FYI: I sent output of bt full to Jan with some data stripped because of > privacy concerns. > > Note that the entry for which constraint checking is done is added to the > database. So something might be wrong *after* the check. > > Ciao, Michael. > > Can you please try the attached patch? If it doesn't fix the issue (or breaks something else that I'm not aware of) I will need a reproducer config and data. Thank you, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat --------------000604070905040801090708 Content-Type: text/x-patch; name="tmp.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tmp.patch" diff --git a/servers/slapd/overlays/constraint.c b/servers/slapd/overlays/constraint.c index ee8911b..f2c645c 100644 --- a/servers/slapd/overlays/constraint.c +++ b/servers/slapd/overlays/constraint.c @@ -935,10 +935,6 @@ constraint_update( Operation *op, SlapReply *rs ) /* Do we need to count attributes? */ for(cp = c; cp; cp = cp->ap_next) { - if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { - continue; - } - if (cp->count != 0) { if (rc != 0 || target_entry == NULL) { Debug(LDAP_DEBUG_TRACE, @@ -950,6 +946,10 @@ constraint_update( Operation *op, SlapReply *rs ) goto mod_violation; } + if (cp->restrict_lud && constraint_check_restrict(op, cp, target_entry) == 0) { + continue; + } + is_v = constraint_check_count_violation(m, target_entry, cp); Debug(LDAP_DEBUG_TRACE, --------------000604070905040801090708--

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 07 Nov '12

07 Nov '12

FYI: I sent output of bt full to Jan with some data stripped because of privacy concerns. Note that the entry for which constraint checking is done is added to the database. So something might be wrong *after* the check. Ciao, Michael.

1 0

Re: (ITS#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by quanah＠zimbra.com 06 Nov '12

06 Nov '12

--On Tuesday, November 06, 2012 5:36 PM +0000 vb4607(a)att.com wrote: > Full_Name: Venkatesh Baglodi > Version: 2.4.32 > OS: Red Hat Enterprise Linux Server release 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (139.76.64.65) > > > We have been facing frequent memory utilization issues with OpenLDAP > 2.4.32 in our production environment (multi-master mode, 6 servers), > which requires OpenLDAP server instances to be restarted almost every > week. Utilization starts at a lower percentage to start with (2-3%), but > then gradually moves up and never comes down. We have been using OpenLDAP > 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux > Server release 5.5 (Tikanga). Are there any known issues with this > version? Are you using the default glibc malloc, instead of tcmalloc? That would be a common mistake that results in this sort of behavior. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7433) OpenLDAP 2.4.32 - possible memory leak at high load
by vb4607＠att.com 06 Nov '12

06 Nov '12

Full_Name: Venkatesh Baglodi Version: 2.4.32 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.76.64.65) We have been facing frequent memory utilization issues with OpenLDAP 2.4.32 in our production environment (multi-master mode, 6 servers), which requires OpenLDAP server instances to be restarted almost every week. Utilization starts at a lower percentage to start with (2-3%), but then gradually moves up and never comes down. We have been using OpenLDAP 2.4.32 with hdb backend (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). Are there any known issues with this version?

1 0

Re: (ITS#7432) slapd crashes when removing members from a large group
by hyc＠symas.com 05 Nov '12

05 Nov '12

marvin.mundry(a)uni-hamburg.de wrote: > Full_Name: Marvin Mundry > Version: 2.4.33 > OS: Ubuntu 12.10 > URL: https://idmswiki.rrz.uni-hamburg.de:8005/debug.tar.bz > Submission from: (NULL) (134.100.2.183) > Thanks for the report. The crash has been fixed in git, but your test runs into another (known) issue in MDB. You're working with a very large entry, which libmdb stores in overflow pages. In the current version of libmdb, freespace management for overflow pages is not fully implemented, so every time you update the entry libmdb will always use new pages (instead of reusing old pages). Thus, after a few hundred operations, your 1GB map will be exhausted. It looks like you won't be able to use back-mdb until this feature is fully implemented in libmdb. > i have slapcat'ed my production environment and slapadded it into an back_mdb > database. > > when deleting members one by one from a large group (48428 Members), after some > transactions slapd crashes. > when i slapadd my dit to an mdb without having an eq index configured for > "member" the removal of members works fine. > > when doing the same thing (member indexed, slapadding members, starting slapd, > removing group members one by one) on a hdb, slapd does not crash. > > sortvals is set for members as otherwise deletion operations would take a very > long time > > i failed to reproduce the problem without initially slapadding the data from my > production environment into the mdb. > > i have removed all configuration settings not neccessary to reproduce the bug > > the debug.tar.bz should contain everything that is neccessary (including a > description) to reproduce the problem. additionally the file contains a coredump > and the full trace output > > slapd.conf: > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/rfc2307bis.schema > pidfile /usr/local/var/run/slapd.pid > argsfile /usr/local/var/run/slapd.args > modulepath /usr/local/libexec/openldap > moduleload back_mdb.la > sortvals member > database mdb > suffix "dc=test,dc=com" > rootdn "cn=admin,dc=test,dc=com" > rootpw secret > directory /usr/local/etc/openldap/test123db/AL > index member eq > maxsize 1000000000 > > > last lines of slapd -d Trace: > 5096b5ae oc_check_allowed type "modifyTimestamp" > 5096b5ae sl_malloc 8: ch_malloc #this line repeats 28450 times > 5096b5ae => mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > 5096b5ae <= mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com > > build options: > CFLAGS=-O0 -d > ./configure --enable-dynamic=yes --enable-syslog=yes --enable-slapd=yes > --enable-dynacl=yes --enable-crypt=yes --enable-modules=yes --enable-rewrite=ye > s --enable-bdb=mod --enable-hdb=mod --enable-ldap=mod --enable-mdb=mod > --enable-meta=mod --enable-monitor=mod --enable-overlays=mod --with-tls=openssl > > --enable-debug > > (gdb) bt: > #0 0x000002fc000002fa in ?? () > #1 0x000002ff000002fd in ?? () > #2 0x0000030200000300 in ?? () > #3 0x0000030500000303 in ?? () > #4 0x0000030800000306 in ?? () > #5 0x0000030b00000309 in ?? () > #6 0x00007f1400000312 in ?? () > #7 0x0000009cffffffbf in ?? () > #8 0x00007f1400000011 in ?? () > #9 0x00000000000102a3 in ?? () > #10 0x00007f140c101880 in ?? () > #11 0x00007f140883c200 in ?? () > #12 0x0000000000000891 in ?? () > #13 0x00007f14155ef060 in ?? () > #14 0x00007f14523dd5a6 in ?? () > #15 0x00007f1451fa1010 in ?? () > #16 0x00000000523dd2a7 in ?? () > #17 0x00007f14155ef390 in ?? () > #18 0x0000000000000000 in ?? () > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by jsynacek＠redhat.com 05 Nov '12

05 Nov '12

On 11/04/2012 05:33 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 > OS: openSUSE 12.2 x86_64 > URL: > Submission from: (NULL) (79.227.185.139) > > > I get a seg fault when adding group entries with some regex-constrained > attributes. This is RE24 with the recent fixes for slapo-constraint. The > constraint setup works with 2.4.31. > > Strange thing is that the entry is added to the database. So it seems to me that > the seg fault happens after that while checking constraints for what > slapo-memberof does? > > As often this is a complex customer setup. So it's not that easy to narrow down > the config and strip aways private customer data in a full traceback. I will do > if really necessary. > > Maybe this gives a first hint where to look: > > No symbol "info" in current context. > (gdb) info threads > Id Target Id Frame > 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () > from /lib64/libc.so.6 > 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () > from /lib64/libpthread.so.0 > 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in > constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at > constraint.c:713 > Hello Michael, can you please provide a full backtrace of thread 1? A quick look suggest that there's something wrong, because constraint_check_restrict probably should not be called with e=0x0, but I'm unable to tell anything else with such restricted information. Also, if the problem is in my fix, it should be fairly easily reproducible with just a few slapadds with the right data. Cheers, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7432) slapd crashes when removing members from a large group
by marvin.mundry＠uni-hamburg.de 05 Nov '12

05 Nov '12

Full_Name: Marvin Mundry Version: 2.4.33 OS: Ubuntu 12.10 URL: https://idmswiki.rrz.uni-hamburg.de:8005/debug.tar.bz Submission from: (NULL) (134.100.2.183) i have slapcat'ed my production environment and slapadded it into an back_mdb database. when deleting members one by one from a large group (48428 Members), after some transactions slapd crashes. when i slapadd my dit to an mdb without having an eq index configured for "member" the removal of members works fine. when doing the same thing (member indexed, slapadding members, starting slapd, removing group members one by one) on a hdb, slapd does not crash. sortvals is set for members as otherwise deletion operations would take a very long time i failed to reproduce the problem without initially slapadding the data from my production environment into the mdb. i have removed all configuration settings not neccessary to reproduce the bug the debug.tar.bz should contain everything that is neccessary (including a description) to reproduce the problem. additionally the file contains a coredump and the full trace output slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/rfc2307bis.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload back_mdb.la sortvals member database mdb suffix "dc=test,dc=com" rootdn "cn=admin,dc=test,dc=com" rootpw secret directory /usr/local/etc/openldap/test123db/AL index member eq maxsize 1000000000 last lines of slapd -d Trace: 5096b5ae oc_check_allowed type "modifyTimestamp" 5096b5ae sl_malloc 8: ch_malloc #this line repeats 28450 times 5096b5ae => mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com 5096b5ae <= mdb_entry_encode(0x00010170): cn=gr97503,ou=groups,dc=test,dc=com build options: CFLAGS=-O0 -d ./configure --enable-dynamic=yes --enable-syslog=yes --enable-slapd=yes --enable-dynacl=yes --enable-crypt=yes --enable-modules=yes --enable-rewrite=ye s --enable-bdb=mod --enable-hdb=mod --enable-ldap=mod --enable-mdb=mod --enable-meta=mod --enable-monitor=mod --enable-overlays=mod --with-tls=openssl --enable-debug (gdb) bt: #0 0x000002fc000002fa in ?? () #1 0x000002ff000002fd in ?? () #2 0x0000030200000300 in ?? () #3 0x0000030500000303 in ?? () #4 0x0000030800000306 in ?? () #5 0x0000030b00000309 in ?? () #6 0x00007f1400000312 in ?? () #7 0x0000009cffffffbf in ?? () #8 0x00007f1400000011 in ?? () #9 0x00000000000102a3 in ?? () #10 0x00007f140c101880 in ?? () #11 0x00007f140883c200 in ?? () #12 0x0000000000000891 in ?? () #13 0x00007f14155ef060 in ?? () #14 0x00007f14523dd5a6 in ?? () #15 0x00007f1451fa1010 in ?? () #16 0x00000000523dd2a7 in ?? () #17 0x00007f14155ef390 in ?? () #18 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7418) slapo-constraint are broken
by michael＠stroeder.com 04 Nov '12

04 Nov '12

This is a cryptographically signed message in MIME format. --------------ms020504060001080007040306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The recent fix for ITS#7418 might have caused another regression causing = a seg fault. Please have a look at http://www.openldap.org/its/index.cgi?findid=3D7431 Ciao, Michael. --------------ms020504060001080007040306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMTA0MTcxNTA3WjAjBgkq hkiG9w0BCQQxFgQU2S6ujsV//DKe24vs3qNZa3mUkuEwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAR/l43ew8i8amA4dE9byAvbfTT50nLLLVOMrTVoCFZk2trkOiFPhWPY3QcsEYncUPTrpI GHaDDCvnrsOp0S5bW3QOXkt0thuE95BFHoOsk6LQATGuCp6hz2WskWx8sJsLQ72zfoJY9Zne H8+0BkBF/otrgACAGEGJgSTiM/ay4IMAmt7JLyGdVSUQZErjP+GbSv7p+wFbQTdMyiUTTGuG OihXeKuKkiZ9CLKdYpjlVQYw5/cxzDWV27Iba0XylKDx1FyhjoWoHaKNpW6BgDSy2xTjWa/I GH2wb4CzyhDkjc3pHmgTSdtIVZ7fqvwgsssWfVV/BeDV4tUH2OZwflJrCgAAAAAAAA== --------------ms020504060001080007040306--

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

It also works when using constraint.c of OpenLDAP release 2.4.33. Maybe it's caused by fix for ITS#7418?

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

It works when using constraint.c of OpenLDAP release 2.4.32.

1 0

(ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

Full_Name: Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 OS: openSUSE 12.2 x86_64 URL: Submission from: (NULL) (79.227.185.139) I get a seg fault when adding group entries with some regex-constrained attributes. This is RE24 with the recent fixes for slapo-constraint. The constraint setup works with 2.4.31. Strange thing is that the entry is added to the database. So it seems to me that the seg fault happens after that while checking constraints for what slapo-memberof does? As often this is a complex customer setup. So it's not that easy to narrow down the config and strip aways private customer data in a full traceback. I will do if really necessary. Maybe this gives a first hint where to look: No symbol "info" in current context. (gdb) info threads Id Target Id Frame 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () from /lib64/libc.so.6 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () from /lib64/libpthread.so.0 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at constraint.c:713

1 0

(ITS#7430) building with gnutls-3.0.x fails
by travisghansen＠yahoo.com 03 Nov '12

03 Nov '12

Full_Name: Travis Glenn Hansen Version: openldap-2.4.33 OS: gentoo ~arch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.248.41.91) http://www.gnu.org/software/gnutls/manual/html_node/Upgrading-from-previous… It appears a handful of calls have new/updated renditions per the above link including (but not limited to) gnutls_certificate_get_x509_cas. Thanks! libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/apitest apitest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [ftest] Error 1 make[2]: *** Waiting for unfinished jobs.... libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/dntest dntest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/urltest urltest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/ltest test.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [dntest] Error 1 ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [urltest] Error 1 ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [ltest] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries' make: *** [all-common] Error 1

1 0

(ITS#7429) MDB crashing with slapo-valsort
by marco.pizzoli＠gmail.com 02 Nov '12

02 Nov '12

Full_Name: Marco Pizzoli Version: 2.4.33 OS: Linux 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) Hi, I'm aware I'm not providing a complete bug report, but as I wrote on the mailing list I'm in a situation where I simply can't do it. Feel free to close if not enough information will be provided or try to ask me other infos if it could be worth the doing. I slapadd-ed a pre-existent OpenLDAP database (2.4.16) on a new test system (2.4.33). The new setup uses back-mdb as database. I created a second specular system and successfully completed a sync-replication from the first of the servers. Repeated the procedure (drop/populate the db) 5 or 6 times, without any problem. I decided to enable the valsort overlay, instanciated on the mdb db. My configuration was simply: overlay valsort valsort-attr member dc=company,dc=XX alpha-ascend Now I have the slave always crashing at almost 70% of progress. I produced a "bt full" (which I can't copy/paste here) of the core and I can see in the "mdb_search <cut> search.c:352" section a lot of rows similar to this one: isc{ bv_val = 0x8 <Address 0x8 out of bounds>}, {bv_len = 140172391141264, bv_val = 0x7f7c6e041000 <Address 0x7f7c6e041000 out of bounds>},[cut] I would be happy to provide other infos but I can't copy paste the entire "bt full" output. I'm sorry about that. Thanks Marco Pizzoli

1 0

AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 02 Nov '12

02 Nov '12

Hi Howard, today, i have tested the patch. 1) make test -> successful 2) sync in small example -> successful 3) sync in the real configuration -> successful, too Thanks to all, Sascha

1 0

Re: (ITS#7426) contraints blocks syncreplication
by hyc＠symas.com 01 Nov '12

01 Nov '12

michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> Sascha.Kuehndel(a)deka.de wrote: >>> the problem is the order of the sync process. >>> First the users are sync. At this moment the consumer don't have any group entry. >>> So the constraints checks the dekanetZielgruppenDN against a not existing subtree. >>> The result is: the user entry is not added. >> >> Yes, but that's irrelevant. Even if the groups were fully replicated already, >> if the provider sent an invalid user, this constraint overlay on the consumer >> would correctly reject it and replication would still break. > > IMO Sascha says that the group and user entries were written in correct order > to the first provider, successfully passed the constraints there but are then > replicated in different order to the second provider which also checks the > same constraints again. Since the order is significant for the constraint it > fails on the second provider. (Both are configured with same constraints.) > > The solution would be to not check constraints for replicated ops. It's > similar to the problem space when/whether to apply slapo-refint, > slapo-memberof etc. in case of replicated ops. OK, that sounds fine. The corresponding fix is now in git master, please test. commit b4126863a4443630392afc50de65b0c90de2304f -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7426) contraints blocks syncreplication
by michael＠stroeder.com 01 Nov '12

01 Nov '12

hyc(a)symas.com wrote: > Sascha.Kuehndel(a)deka.de wrote: >> the problem is the order of the sync process. >> First the users are sync. At this moment the consumer don't have any group entry. >> So the constraints checks the dekanetZielgruppenDN against a not existing subtree. >> The result is: the user entry is not added. > > Yes, but that's irrelevant. Even if the groups were fully replicated already, > if the provider sent an invalid user, this constraint overlay on the consumer > would correctly reject it and replication would still break. IMO Sascha says that the group and user entries were written in correct order to the first provider, successfully passed the constraints there but are then replicated in different order to the second provider which also checks the same constraints again. Since the order is significant for the constraint it fails on the second provider. (Both are configured with same constraints.) The solution would be to not check constraints for replicated ops. It's similar to the problem space when/whether to apply slapo-refint, slapo-memberof etc. in case of replicated ops. Ciao, Michael.

1 0

Re: (ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 01 Nov '12

01 Nov '12

I've just uploaded: ftp://ftp.openldap.org/incoming/rhafer-Use-non-blocking-IO-during-SSL-Hands… which tries to address the issue. If LDAP_OPT_NETWORK_TIMEOUT is set ldap_int_tls_start will switch to non-blocking IO and call ldap_int_tls_connect as often as needed unless it times out inbetween. Currently I have only tested this with openssl but AFAICS this should also work with the NSS and gnutls backends Please review and comment. Ralf

1 0

(ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 01 Nov '12

01 Nov '12

Full_Name: Ralf Haferkamp Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.80.202) Currently libldap is using blocking IO when performing the SSL handshake for ldaps:// connections (and when performing the StartTLS operation). The can lead to the client blocking forever in the ssl lib (in SSL_connect in case of openssl) if e.g. the server for whatever reason stops responding. It would be very helpful if libldap would use non-blocking IO during the handshake at least when LDAP_OPT_NETWORK_TIMEOUT (or LDAP_OPT_TIMEOUT?) are set.

1 0

Re: AW: WG: AW: (ITS#7426) contraints blocks syncreplication
by quanah＠zimbra.com 01 Nov '12

01 Nov '12

--On Thursday, November 01, 2012 4:47 PM +0000 Sascha.Kuehndel(a)deka.de wrote: > Hi, > > in real it is a multi-master-replication. > So the constraints have to define on both sides. If you could provide your exact config and the LDIF files you are loading, that would help. Please strip out any passwords and other individual identifying information. Thanks. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

AW: WG: AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

Hi, in real it is a multi-master-replication. So the constraints have to define on both sides. I have check the entry, more than one time. (many more) so i really sure, it is valid. (changed the attribute to another value and back on the procurer) I think it is a tricky timing problem, and it appears only in special situations. I found it, in a restore of a system with an backup. After imported it in the procurer1, I started the second one. At the next morning the sync wasn't complete. And I wondered why. Another test shows the problem, a little bit more. I changed the order of the entries in the initial.ldif (groups in front of users), and the sync works. In the last message, was a little type. In the database only 6 entries (not 56) Sascha PS: sorry my English is not very well

1 0

Re: WG: AW: (ITS#7426) contraints blocks syncreplication
by quanah＠zimbra.com 01 Nov '12

01 Nov '12

--On Thursday, November 01, 2012 3:03 PM +0000 Sascha.Kuehndel(a)deka.de wrote: > --_002_F12A906A1F17554CB9CDFC8F4779F3C469A7704B2BEXCCREX9dekag_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi Howard, > > Sorry for the much "!" > > I have written a new config, only with constraint and replication. > I have reduce the database to 56 entries. > > In this configuration I can reproduce this error. > > my steps. > 1. F1> slapadd -f slapd.conf -f initial.ldif 2. F1> slapd -h > ldap://0.0.0.0= :4001 -f slapd.conf 3. F1> slapd -h ldap://0.0.0.0:4002 > -f slapd.conf Your message isn't particularly clear on what it is you are doing now. As Howard noted, it is only valid to have slapo-constraint on the provider, and not on any of the replicas. Using slapadd does not necessarily guarantee that your entry is valid, as slapadd can bypass some overlay checks. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7427) Bogus entries with syncrepl/MMR
by hyc＠OpenLDAP.org 01 Nov '12

01 Nov '12

Full_Name: Howard Chu Version: 2.4.33 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.96.255) Submitted by: hyc Related to ITS#7052 and #7162. We still see cases where some entries that were deleted on a master are resurrected on a consumer. This happens when a single consumer is talking to a pair of masters which are mirroring each other, and the consumer gets an old batch of updates from one master, duplicating updates it already received from the other master. The spurious Adds are being accepted because they were sent with no cookie CSN. These ops are embedded in a string of other old ops, which have cookie CSNs that are correctly being ignored. The fix is to set a flag to remember when we've seen an old op, and unset the flag when we're caught up. Then, for any ops that are received without a cookie CSN, if the flag is set, this means we're in the middle of a stream of old ops, and this op should be ignored.

1 0

WG: AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

--_002_F12A906A1F17554CB9CDFC8F4779F3C469A7704B2BEXCCREX9dekag_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Howard, Sorry for the much "!" I have written a new config, only with constraint and replication. I have reduce the database to 56 entries. In this configuration I can reproduce this error. my steps. 1. F1> slapadd -f slapd.conf -f initial.ldif 2. F1> slapd -h ldap://0.0.0.0= :4001 -f slapd.conf 3. F1> slapd -h ldap://0.0.0.0:4002 -f slapd.conf In the log of F2, the sync stops with the first user. And this moment the r= oot-entry and ou=3Dusers is synced, only. I hope you can reproduce the error, too. Sascha PS: tested with 2.4.32 have the problem, too. --_002_F12A906A1F17554CB9CDFC8F4779F3C469A7704B2BEXCCREX9dekag_ Content-Type: application/x-tar; name="ITS_7426.tar" Content-Description: ITS_7426.tar Content-Disposition: attachment; filename="ITS_7426.tar"; size=10240; creation-date="Thu, 01 Nov 2012 14:56:56 GMT"; modification-date="Thu, 01 Nov 2012 14:55:43 GMT" Content-Transfer-Encoding: base64 RjEvc2xhcGQuY29uZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDA2NDQAMDAwMDYw NQAwMDAwMDAxADAwMDAwMDAyNDM1ADEyMDQ0NTAzNzA2ADAwMTQxMTUAMAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhcgAwMHNfc2xhcGQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAb3RoZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwMDAwADAwMDAw MDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAj IFNjaGVtYXRhIGF1cyBkZXIgT3BlbkxEQVAtRGlzdHJpYnV0aW9uCmluY2x1ZGUJICAgICAgICAg ICAgICAgICBzbGFwZC9ldGMvb3BlbmxkYXAvc2NoZW1hL2NvcmUuc2NoZW1hCmluY2x1ZGUJICAg ICAgICAgICAgICAgICBzbGFwZC9ldGMvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKCiMg TG9hZCBtb2R1bGVzCm1vZHVsZXBhdGggICAgICAgICAgICAgICBzbGFwZC9saWJleGVjL29wZW5s ZGFwCm1vZHVsZWxvYWQgICAgICAgICAgICAgICBiYWNrX2hkYi5sYQptb2R1bGVsb2FkICAgICAg ICAgICAgICAgY29uc3RyYWludC5sYQptb2R1bGVsb2FkICAgICAgICAgICAgICAgc3luY3Byb3Yu bGEKCiMgQmFzZSBrb25maWd1cmF0aW9uCnBpZGZpbGUgICAgICAgICAgICAgICAgICBzbGFwZC5w aWQKYXJnc2ZpbGUgICAgICAgICAgICAgICAgIHNsYXBkLmFyZ3MKCiMgRGF0YWJhc2UKZGF0YWJh c2UgICAgICAgICAgICAgICAgIGhkYgoKc3VmZml4ICAgICAgICAgICAgICAgICAgICJvdT1kZWth LGRjPWV4YW1wbGUsZGM9Y29tIgpkaXJlY3RvcnkgICAgICAgICAgICAgICAgZXhhbXBsZQpyb290 ZG4gICAgICAgICAgICAgICAgICAgImNuPXJvb3Qsb3U9ZGVrYSxkYz1leGFtcGxlLGRjPWNvbSIK cm9vdHB3ICAgICAgICAgICAgICAgICAgIHJvb3QKCm92ZXJsYXkgY29uc3RyYWludApjb25zdHJh aW50X2F0dHJpYnV0ZSBhc3NvY2lhdGVkTmFtZSB1cmkKICBsZGFwOi8vL291PWdyb3VwLG91PWRl a2EsZGM9ZXhhbXBsZSxkYz1jb20/ZW50cnlETj9vbmU/KG9iamVjdENsYXNzPWFjY291bnQpCiAg cmVzdHJpY3Q9bGRhcDovLy9vdT11c2VyLG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20/P29uZQoK CmluZGV4ICAgICAgICAgICAgICAgICAgICBlbnRyeUNTTiBlcQppbmRleCAgICAgICAgICAgICAg ICAgICAgZW50cnlVVUlEIGVxCgpvdmVybGF5IHN5bmNwcm92CnN5bmNwcm92LWNoZWNrcG9pbnQg ICAgICAxMDAgNQpzeW5jcHJvdi1zZXNzaW9ubG9nICAgICAgMTAwCnN5bmNwcm92LXJlbG9hZGhp bnQgICAgICBUUlVFCnN5bmNyZXBsCiAgICByaWQ9MDAxCiAgICBwcm92aWRlcj1sZGFwOi8vbG9j YWxob3N0OjQwMDIKICAgIGNyZWRlbnRpYWxzPXJvb3QKICAgIGJpbmRkbj0iY249cm9vdCxvdT1k ZWthLGRjPWV4YW1wbGUsZGM9Y29tIgogICAgYmluZG1ldGhvZD1zaW1wbGUKICAgIHNlYXJjaGJh c2U9Im91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20iCiAgICBzY2hlbWFjaGVja2luZz1vbgogICAg dHlwZT1yZWZyZXNoQW5kUGVyc2lzdAogICAgcmV0cnk9IjMwICsiCm1pcnJvcm1vZGUgb24KAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGMS9p bml0aWFsLmxkaWYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDY0NAAwMDAwNjA1ADAw MDAwMDEAMDAwMDAwMDI3MjIAMTIwNDQ1MDM0NjEAMDAxNDQzMQAwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyADAwc19zbGFwZAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABvdGhlcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMDAwMDAAMDAwMDAwMAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRuOiBv dT1kZWthLGRjPWV4YW1wbGUsZGM9Y29tCm91OiBkZWthbmV0Cm9iamVjdENsYXNzOiBvcmdhbml6 YXRpb25hbFVuaXQKc3RydWN0dXJhbE9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKZW50 cnlVVUlEOiA3YjlkZDlkMi1iMGJjLTEwMzEtOWYyNS0wNTliZWIwYmI1M2MKZW50cnlDU046IDIw MTIxMDIyMTc0ODUwLjgxMDQ2N1ojMDAwMDAwIzAwMCMwMDAwMDAKCmRuOiBvdT11c2VyLG91PWRl a2EsZGM9ZXhhbXBsZSxkYz1jb20Kb3U6IEJlbnV0emVyCm9iamVjdENsYXNzOiBvcmdhbml6YXRp b25hbFVuaXQKc3RydWN0dXJhbE9iamVjdENsYXNzOiBvcmdhbml6YXRpb25hbFVuaXQKZW50cnlV VUlEOiA4YWQ4Y2ExMC1iMGJjLTEwMzEtOWYzYS0wNTliZWIwYmI1M2MKZW50cnlDU046IDIwMTIx MDIyMTc0OTE2LjM2MjU1NVojMDAwMDAwIzAwMCMwMDAwMDAKCmRuOiBkYz0xLG91PXVzZXIsb3U9 ZGVrYSxkYz1leGFtcGxlLGRjPWNvbQpkYzogMQpvYmplY3RDbGFzczogZG9tYWluCm9iamVjdENs YXNzOiB0b3AKYXNzb2NpYXRlZE5hbWU6IHVpZD0xNCxvdT1ncm91cCxvdT1kZWthLGRjPWV4YW1w bGUsZGM9Y29tCnN0cnVjdHVyYWxPYmplY3RDbGFzczogZG9tYWluCmVudHJ5VVVJRDogNzg4MGQw ZTYtYjBjMi0xMDMxLTg5NWItYTFhM2YyZmJhY2I3CmVudHJ5Q1NOOiAyMDEyMTAyMjE4MzE0Mi41 NjcyNzlaIzAwMDAwMCMwMDAjMDAwMDAwCgpkbjogZGM9MixvdT11c2VyLG91PWRla2EsZGM9ZXhh bXBsZSxkYz1jb20KZGM6IDIKb2JqZWN0Q2xhc3M6IGRvbWFpbgpvYmplY3RDbGFzczogdG9wCmFz c29jaWF0ZWROYW1lOiB1aWQ9MTQsb3U9Z3JvdXAsb3U9ZGVrYSxkYz1leGFtcGxlLGRjPWNvbQpz dHJ1Y3R1cmFsT2JqZWN0Q2xhc3M6IGRvbWFpbgplbnRyeVVVSUQ6IDgwNDE1MjU2LWIwYzItMTAz MS04OTVjLWExYTNmMmZiYWNiNwplbnRyeUNTTjogMjAxMjEwMjIxODMxNTUuNTczMDU4WiMwMDAw MDAjMDAwIzAwMDAwMAoKZG46IG91PWdyb3VwLG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20Kb3U6 IFppZWxncnVwcGVuCmRlc2NyaXB0aW9uOiBDb250YWluZXIgZnVlciBaaWVsZ3J1cHBlbmVpbnRy YWVnZQpvYmplY3RDbGFzczogb3JnYW5pemF0aW9uYWxVbml0CnN0cnVjdHVyYWxPYmplY3RDbGFz czogb3JnYW5pemF0aW9uYWxVbml0CmVudHJ5VVVJRDogODQwNTExMTItYjBiYy0xMDMxLTlmMjYt MDU5YmViMGJiNTNjCmVudHJ5Q1NOOiAyMDEyMTAyMjE3NDkwNC45MDg2NjBaIzAwMDAwMCMwMDAj MDAwMDAwCgpkbjogdWlkPTE0LG91PWdyb3VwLG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20KdWlk OiAxNApvYmplY3RDbGFzczogYWNjb3VudApvYmplY3RDbGFzczogdG9wCnN0cnVjdHVyYWxPYmpl Y3RDbGFzczogYWNjb3VudAplbnRyeVVVSUQ6IDg0N2VhYzVjLWIwYmMtMTAzMS05ZjM2LTA1OWJl YjBiYjUzYwplbnRyeUNTTjogMjAxMjEwMjIxNzUxMjcuNzIyNzQ3WiMwMDAwMDAjMDAwIzAwMDAw MAoKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEYyL3NsYXBk LmNvbmYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwNjQ0ADAwMDA2MDUAMDAwMDAw MQAwMDAwMDAwMjQzNQAxMjA0NDUwNDI2MAAwMDE0MTEyADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIAMDBzX3NsYXBkAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAG90aGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwMDAwMAAwMDAwMDAwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIyBTY2hlbWF0 YSBhdXMgZGVyIE9wZW5MREFQLURpc3RyaWJ1dGlvbgppbmNsdWRlCSAgICAgICAgICAgICAgICAg c2xhcGQvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQppbmNsdWRlCSAgICAgICAgICAg ICAgICAgc2xhcGQvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3NpbmUuc2NoZW1hCgojIExvYWQgbW9k dWxlcwptb2R1bGVwYXRoICAgICAgICAgICAgICAgc2xhcGQvbGliZXhlYy9vcGVubGRhcAptb2R1 bGVsb2FkICAgICAgICAgICAgICAgYmFja19oZGIubGEKbW9kdWxlbG9hZCAgICAgICAgICAgICAg IGNvbnN0cmFpbnQubGEKbW9kdWxlbG9hZCAgICAgICAgICAgICAgIHN5bmNwcm92LmxhCgojIEJh c2Uga29uZmlndXJhdGlvbgpwaWRmaWxlICAgICAgICAgICAgICAgICAgc2xhcGQucGlkCmFyZ3Nm aWxlICAgICAgICAgICAgICAgICBzbGFwZC5hcmdzCgojIERhdGFiYXNlCmRhdGFiYXNlICAgICAg ICAgICAgICAgICBoZGIKCnN1ZmZpeCAgICAgICAgICAgICAgICAgICAib3U9ZGVrYSxkYz1leGFt cGxlLGRjPWNvbSIKZGlyZWN0b3J5ICAgICAgICAgICAgICAgIGV4YW1wbGUKcm9vdGRuICAgICAg ICAgICAgICAgICAgICJjbj1yb290LG91PWRla2EsZGM9ZXhhbXBsZSxkYz1jb20iCnJvb3RwdyAg ICAgICAgICAgICAgICAgICByb290CgpvdmVybGF5IGNvbnN0cmFpbnQKY29uc3RyYWludF9hdHRy aWJ1dGUgYXNzb2NpYXRlZE5hbWUgdXJpCiAgbGRhcDovLy9vdT1ncm91cCxvdT1kZWthLGRjPWV4 YW1wbGUsZGM9Y29tP2VudHJ5RE4/b25lPyhvYmplY3RDbGFzcz1hY2NvdW50KQogIHJlc3RyaWN0 PWxkYXA6Ly8vb3U9dXNlcixvdT1kZWthLGRjPWV4YW1wbGUsZGM9Y29tPz9vbmUKCgppbmRleCAg ICAgICAgICAgICAgICAgICAgZW50cnlDU04gZXEKaW5kZXggICAgICAgICAgICAgICAgICAgIGVu dHJ5VVVJRCBlcQoKb3ZlcmxheSBzeW5jcHJvdgpzeW5jcHJvdi1jaGVja3BvaW50ICAgICAgMTAw IDUKc3luY3Byb3Ytc2Vzc2lvbmxvZyAgICAgIDEwMApzeW5jcHJvdi1yZWxvYWRoaW50ICAgICAg VFJVRQpzeW5jcmVwbAogICAgcmlkPTAwMQogICAgcHJvdmlkZXI9bGRhcDovL2xvY2FsaG9zdDo0 MDAxCiAgICBjcmVkZW50aWFscz1yb290CiAgICBiaW5kZG49ImNuPXJvb3Qsb3U9ZGVrYSxkYz1l eGFtcGxlLGRjPWNvbSIKICAgIGJpbmRtZXRob2Q9c2ltcGxlCiAgICBzZWFyY2hiYXNlPSJvdT1k ZWthLGRjPWV4YW1wbGUsZGM9Y29tIgogICAgc2NoZW1hY2hlY2tpbmc9b24KICAgIHR5cGU9cmVm cmVzaEFuZFBlcnNpc3QKICAgIHJldHJ5PSIzMCArIgptaXJyb3Jtb2RlIG9uCgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --_002_F12A906A1F17554CB9CDFC8F4779F3C469A7704B2BEXCCREX9dekag_--

1 0

AW: AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

> Yes, but that's irrelevant. Even if the groups were fully replicated already I have tested the user entry on provider (with constraints active) the entry is accepted! So the entry is valid! Sascha

1 0

Re: AW: (ITS#7426) contraints blocks syncreplication
by hyc＠symas.com 01 Nov '12

01 Nov '12

Sascha.Kuehndel(a)deka.de wrote: > Hi, > > the problem is the order of the sync process. > First the users are sync. At this moment the consumer don't have any group entry. > So the constraints checks the dekanetZielgruppenDN against a not existing subtree. > The result is: the user entry is not added. Yes, but that's irrelevant. Even if the groups were fully replicated already, if the provider sent an invalid user, this constraint overlay on the consumer would correctly reject it and replication would still break. The config is nonsensical. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 01 Nov '12

01 Nov '12

Hi, the problem is the order of the sync process. First the users are sync. At this moment the consumer don't have any group entry. So the constraints checks the dekanetZielgruppenDN against a not existing subtree. The result is: the user entry is not added. Sascha

1 0

Re: (ITS#7426) contraints blocks syncreplication
by hyc＠symas.com 01 Nov '12

01 Nov '12

sascha.kuehndel(a)deka.de wrote: > Full_Name: Sascha Kuehndel > Version: 2.4.33 + ITS#7418 > OS: HP-UX 11.31 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.166.104.102) > > > Hallo, > > the constraints seams to block the sync-replication. > > constraint_attribute dekanetZielgruppenDN uri > ldap:///ou=Zielgruppen,ou=dekanet,dc=dekager,dc=dekabank,dc=extern?entryDN?one?(objectClass=dekanetZielgruppe) > restrict=ldap:///ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern??one Seems this is an improper config. If you already have constraints enforced on the provider, then only valid entries may be replicated, so constraints on the consumer are superfluous. > the replication syncs the users in ou=Benutzer first, and later the groups of > ou=Zielgruppen. > The be_add of the user failed in the consumer, until commenting out the > constraint. > > here the relevant part of the log file > 50c84eff syncrepl_message_to_entry: rid=002 DN: > uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern, UUID: XXX-UUID > 50c84eff syncrepl_entry: rid=002 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) > 50c84eff syncrepl_entry: rid=002 inserted UUID XXX-UUID > 50c84eff syncrepl_entry: rid=002 be_search (0) > 50c84eff syncrepl_entry: rid=002 > uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern > 50c84f00 slap_queue_csn: queing 6000000000a1d9c0 > 20120926141541.717811Z#000000#002#000000 > 50c84f00 slap_graduate_commit_csn: removing 6000000012baa390 > 20120926141541.717811Z#000000#002#000000 > 50c84f00 null_callback : error code 0x13 > 50c84f00 syncrepl_entry: rid=002 be_add > uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern (19) > 50c84f00 syncrepl_entry: rid=002 be_add > uid=XXX,ou=Benutzer,ou=dekanet,dc=dekager,dc=dekabank,dc=extern failed (19) > 50c84f00 do_syncrepl: rid=002 rc 19 retrying > > > Greets, > Sascha > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs