- openldap-bugs - openldap.org

(ITS#6431) LDAP Server disabled
by yimnara＠khaouchuly.com 15 Dec '09

15 Dec '09

Full_Name: Yim Nara Version: 2.1.0 OS: Window 2003 server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.248.180.59) LDAP server Disabled Tue 2009-12-15 10:14:45: [LDAP] Error adding 'MDaemon(a)khaouchuly.com' to LDAP address book. Tue 2009-12-15 10:14:45: [LDAP] Error 1: Operations error. Tue 2009-12-15 10:14:45: [LDAP] 0 address records exported, 0 address records already existed, 41 errors.

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 15 Dec '09

15 Dec '09

--On Saturday, December 12, 2009 5:48 PM +0000 quanah(a)zimbra.com wrote: >># 0=C2=A0 0x000000000066f891 in ?? () >> (gdb) > > So where's the thr apply all bt command inside gdb? You've just loaded Please provide the backtrace as noted if you want this to be further investigated. Thanks! Again, after you run: gdb </slapd> <core> You then need to run: thr apply all bt To get a backtrace of all threads, and then submit that to the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 13 Dec '09

13 Dec '09

Now it is OK. Build was successful and slapd is working fine. No more delays on start of TLS/SSL queries. Thanks Pavel

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 12 Dec '09

12 Dec '09

--On Saturday, December 12, 2009 1:16 PM +0330 afshin afzali=20 <a.afzali2003(a)gmail.com> wrote: > Hi, > It is makes no difference except that the 'Bus error' replaced with > 'Segmentation fault'. Also I've used the 'make clean' to cleanup my > installation. Any suggestion ? > > Regards, > =C2=A0 > > > [root@dc1 libexec]# gdb --core=3Dcore.12305 > GNU gdb Fedora (6.8-37.el5) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law.=C2=A0 Type "show > copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Core was generated by `./slapd -d5'. > Program terminated with signal 11, Segmentation fault. > [New process 12313] > [New process 12314] > [New process 12312] > [New process 12311] > [New process 12310] > [New process 12309] > [New process 12308] > [New process 12307] > [New process 12305] ># 0=C2=A0 0x000000000066f891 in ?? () > (gdb) So where's the thr apply all bt command inside gdb? You've just loaded the = core, you haven't asked for any information. Also, keep replies to the bug tracker (i.e., CC it as well) if you want=20 help. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 12 Dec '09

12 Dec '09

--On Friday, December 11, 2009 9:22 PM +0000 pali(a)tmapy.cz wrote: > > --=-NIKZplg5L6FNssI2Xw1S > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > It has worked (in 2.4.18, 2.4.19, 2.4.20) with the same configs. Please re-sync RE24. There was missed commit sync'd in tonight. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by hyc＠symas.com 12 Dec '09

12 Dec '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Thread 1 (Thread 20774): > OK. The patch for #6419 that was backported from HEAD needs some additional > stuff that isn't yet in RE24. > Fixed now in RE24, 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

Re: (ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by hyc＠symas.com 12 Dec '09

12 Dec '09

michael(a)stroeder.com wrote: > Thread 1 (Thread 20774): > #0 0x00002ad97f0974e5 in raise () from /lib64/libc.so.6 > #1 0x00002ad97f0989b0 in abort () from /lib64/libc.so.6 > #2 0x00002ad97f09024a in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000429e29 in slap_cf_aux_table_unparse (src=0x7f3120, > bv=0x7fffc98185f0, tab0=<value optimized out>) at config.c:1447 > #4 0x000000000048885d in syncrepl_unparse (si=0x7f30f0, bv=0x7fffc9818650) at > syncrepl.c:4582 > #5 0x000000000048e1bb in syncrepl_config (c=<value optimized out>) at > syncrepl.c:4748 > #6 0x000000000042ad06 in config_get_vals (cf=0x724240, c=0x5126) at config.c:443 > #7 0x0000000000422c43 in config_build_attrs (e=<value optimized out>, > at=0x7ba628, ad=0x7a31d0, ct=0x724240, c=0x7fffc9818830) at bconfig.c:6033 > #8 0x0000000000423014 in config_build_entry (op=<value optimized out>, > rs=<value optimized out>, parent=<value optimized out>, > c=0x7fffc9818830, rdn=0x7fffc981a110, main=0x724860, extra=0x2ad98199d7a0) > at bconfig.c:6139 > #9 0x0000000000427261 in config_back_db_open (be=<value optimized out>, > cr=<value optimized out>) at bconfig.c:6527 > #10 0x0000000000441949 in backend_startup_one (be=0x7bc400, cr=0x7fffc981a180) > at backend.c:224 > #11 0x0000000000441c2b in backend_startup (be=0x7bc400) at backend.c:325 > #12 0x000000000041ae46 in main (argc=8, argv=0x7fffc981a488) at main.c:947 OK. The patch for #6419 that was backported from HEAD needs some additional stuff that isn't yet in RE24. -- -- 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#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by michael＠stroeder.com 12 Dec '09

12 Dec '09

Thread 1 (Thread 20774): #0 0x00002ad97f0974e5 in raise () from /lib64/libc.so.6 #1 0x00002ad97f0989b0 in abort () from /lib64/libc.so.6 #2 0x00002ad97f09024a in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000429e29 in slap_cf_aux_table_unparse (src=0x7f3120, bv=0x7fffc98185f0, tab0=<value optimized out>) at config.c:1447 #4 0x000000000048885d in syncrepl_unparse (si=0x7f30f0, bv=0x7fffc9818650) at syncrepl.c:4582 #5 0x000000000048e1bb in syncrepl_config (c=<value optimized out>) at syncrepl.c:4748 #6 0x000000000042ad06 in config_get_vals (cf=0x724240, c=0x5126) at config.c:443 #7 0x0000000000422c43 in config_build_attrs (e=<value optimized out>, at=0x7ba628, ad=0x7a31d0, ct=0x724240, c=0x7fffc9818830) at bconfig.c:6033 #8 0x0000000000423014 in config_build_entry (op=<value optimized out>, rs=<value optimized out>, parent=<value optimized out>, c=0x7fffc9818830, rdn=0x7fffc981a110, main=0x724860, extra=0x2ad98199d7a0) at bconfig.c:6139 #9 0x0000000000427261 in config_back_db_open (be=<value optimized out>, cr=<value optimized out>) at bconfig.c:6527 #10 0x0000000000441949 in backend_startup_one (be=0x7bc400, cr=0x7fffc981a180) at backend.c:224 #11 0x0000000000441c2b in backend_startup (be=0x7bc400) at backend.c:325 #12 0x000000000041ae46 in main (argc=8, argv=0x7fffc981a488) at main.c:947

1 0

(ITS#6430) test017-syncreplication-refresh: line 86: 20774 Aborted
by michael＠stroeder.com 12 Dec '09

12 Dec '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.2 (x86_64) URL: Submission from: (NULL) (84.163.120.34) >>>>> Starting test017-syncreplication-refresh for bdb... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9012... ./scripts/test017-syncreplication-refresh: line 86: 20774 Aborted (core dumped) $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 Using ldapsearch to check that consumer slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test017-syncreplication-refresh: line 102: kill: (20774) - No such process >>>>> ./scripts/test017-syncreplication-refresh failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 11 Dec '09

11 Dec '09

--=-NIKZplg5L6FNssI2Xw1S Content-Type: text/plain Content-Transfer-Encoding: 7bit It has worked (in 2.4.18, 2.4.19, 2.4.20) with the same configs. Pavel --=-NIKZplg5L6FNssI2Xw1S Content-Disposition: attachment; filename="slapd.conf" Content-Type: text/plain; name="slapd.conf"; charset="UTF-8" Content-Transfer-Encoding: 7bit # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap24/schema/corba.schema include /etc/openldap24/schema/core.schema include /etc/openldap24/schema/cosine.schema include /etc/openldap24/schema/duaconf.schema include /etc/openldap24/schema/dyngroup.schema include /etc/openldap24/schema/inetorgperson.schema include /etc/openldap24/schema/java.schema include /etc/openldap24/schema/misc.schema include /etc/openldap24/schema/nis.schema include /etc/openldap24/schema/openldap.schema include /etc/openldap24/schema/ppolicy.schema include /etc/openldap24/schema/collective.schema include /etc/openldap24/schema/samba.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap24/slapd.pid argsfile /var/run/openldap24/slapd.args # Load dynamic backend modules: # modulepath /usr/lib/openldap24 # or /usr/lib64/openldap24 # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCACertificateFile /etc/pki/tls/cacert.pem # TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateFile /etc/pki/tls/certs/ldap3.ldapnet.tmapy.cz-cert.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap3.ldapnet.tmapy.cz-key.pem # 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! # Define global ACLs to disable default read access and provide default # behaviour for samba/pam use include /etc/openldap24/slapd.access.conf # Provide write access to replicators, and cover access to any other # attributes (default anonymous read access may be undesirable) access to dn.subtree="dc=tmapy,dc=cz" by group="cn=Replicator,ou=Group,dc=tmapy,dc=cz" write by users read by anonymous read # loglevel <integer> # Specify the level at which debugging statements and # operation statistics should be syslogged (currently # 1 trace function calls # 2 debug packet handling # 4 heavy trace debugging # 8 connection management # 16 print out packets sent and received # 32 search filter processing # 64 configuration file processing # 128 access control list processing # 256 stats log # connections/operations/results # 512 stats log entries sent # 1024 print communication with shell # backends # 2048 entry parsing # 1 + 2 + 8 + 16 + 32 + 64 + 128 + 256 # loglevel 507 # 16 + 256 # loglevel 272 # 8 + 16 + 128 + 256 # loglevel 408 # 16 + 128 + 256 # loglevel 400 # 2 + 8 + 64 + 256 # loglevel 330 # 8 + 128 # loglevel 136 # 128 + 256 # loglevel 384 # loglevel 128 loglevel 0 ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=tmapy,dc=cz" checkpoint 1024 15 rootdn "cn=Manager,dc=tmapy,dc=cz" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret rootpw heslo # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap24/tmapy.cz # Indices to maintain for this database 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 # Replicas of this database #replogfile /var/lib/ldap24/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # # enable monitoring # database monitor # # # allow onlu rootdn to read the monitor # access to * # by dn.exact="cn=Manager,dc=tmapy,dc=cz" read # by * none # syncrepl directives ServerID 11 syncrepl rid=001 provider=ldap://ldap1.ldapnet.tmapy.cz:389 starttls=yes bindmethod=simple binddn="cn=Manager,dc=tmapy,dc=cz" credentials=heslo searchbase="dc=tmapy,dc=cz" schemachecking=on type=refreshAndPersist retry="5 5 300 5" timeout=1 --=-NIKZplg5L6FNssI2Xw1S Content-Disposition: attachment; filename="slapd.access.conf" Content-Type: text/plain; name="slapd.access.conf"; charset="UTF-8" Content-Transfer-Encoding: 7bit # This configuration file contains default ACLs that attempt to cater # to most setups, specifically unix authentication, samba-s ldapsam backend # and allowing users to have a shared address book # If these ACLs don-t meet your needs, please do not modify the file in-place, # but rather make a copy, and change the include directive in slapd.conf # This file is *not* marked as noreplace, so it will be replaced during an # upgrade, this is done so that we can ensure that the ACLs are in sync with # the schema files they require. # The root DIT should be accessible to all clients access to dn.exact="" by * read # So should the schema access to dn.subtree="cn=Subschema" by * read # Generic ACLs # These ACLs should work well for any domain-based (ie dc=,dc=) suffix, # but need adjustment and testing for any other suffix # Note that these ACLs allow anonymous read access to most non-password # attributes, you may want to prevent leakage of this information by # removing the "by anonymous read" lines # Regex-based ACLs also impose a performance penalty, replace # for example dn.regex="^([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" with # dn.subtree="ou=People,dc=example,dc=com" and all $2-s with dc=example,dc=com # if you need the extra performance # Protect passwords, using a regex so we can have generic accounts with # write access # Openldap will not authenticate against non-userPassword attributes # but we would have to duplicate most rules ... access to dn.regex="^([^,]*,)?ou=[^,]+,(dc=[^,]+(,dc=[^,]+)*)$" attrs=sambaLMPassword,sambaNTPassword,userPassword,sambaPasswordHistory,sambaPwdLastSet,shadowLastChange,shadowMax by self write by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by anonymous auth by * none # ACL allowing samba domain controllers to write their domain info access to dn.regex="^sambaDomainName=([^,]+),(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,sambaDomain,uidNumber,gidNumber by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # ACL allowing samba domain controllers to add user accounts access to dn.regex="^([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixAccount,sambaSamAccount by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # allow users to modify their own "address book" entries: access to dn.regex="([^,]+,)?ou=People,(dc=[^,]+(,dc=[^,]+)*)$" attrs=inetOrgPerson,mail by self write by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba domain controllers to create groups and group mappings access to dn.regex="^([^,]+,)?ou=Group,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixGroup,sambaGroupMapping by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba domain controllers to create machine accounts access to dn.regex="^([^,]+,)?ou=Hosts,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,posixAccount,inetOrgperson,sambaSamAccount by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow samba to create idmap entries access to dn.regex="^([^,]+,)?ou=Idmap,(dc=[^,]+(,dc=[^,]+)*)$" attrs=entry,children,sambaIdmapEntry by dn.exact,expand="uid=root,ou=People,$2" write by group.expand="cn=Domain Controllers,ou=Group,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read # Allow users in the domain to add entries to the "global address book": # For use with Evolution, the attrs list could be modified to be: # attrs=children,entry,inetOrgPerson,evolutionperson,calEntry # if evolutionperson.schema and calendar.schema are available access to dn.regex="^([^,]+,)?ou=Contacts,(dc=[^,]+(,dc=[^,]+)*)$" attrs=children,entry,inetOrgPerson by dn.sub,expand="ou=People,$2" write by group.expand="cn=Replicator,ou=Group,$2" write by users read by anonymous read --=-NIKZplg5L6FNssI2Xw1S--

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 11 Dec '09

11 Dec '09

--On Friday, December 11, 2009 4:05 PM +0000 pali(a)tmapy.cz wrote: > How can I download this particular revision? > > I'm not familiar with CVS > > I've found this: > http://www.openldap.org/software/repo.html#AnonCVS > > I've tried this > > CVSROOT=":pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP" > cvs login > cvs -z3 checkout -P -rOPENLDAP_REL_ENG_2_4 ldap > > but after build I cannot start it, it is crashing > > [root@ldap3 ~]# slaptest24 -f /etc/openldap24/slapd.conf -F /tmp/test > -d1 Please supply your configuration file that is causing slapd to assert. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6429) New mirror
by mirror＠artfiles.org 11 Dec '09

11 Dec '09

Full_Name: Artfiles New Media GmbH Version: OS: URL: Submission from: (NULL) (80.252.98.63) Hello, here are the facts about our mirror: * URL of mirror: http://artfiles.org/openldap.org * Hosting institution, country and city where the mirror is located: Artfiles New Media GmbH, Hamburg, Germany * Contact email address: mirror(a)artfiles.org * Update frequency: daily With best regards Artfiles New Media GmbH Andreas Worbs

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 11 Dec '09

11 Dec '09

How can I download this particular revision? I'm not familiar with CVS I've found this: http://www.openldap.org/software/repo.html#AnonCVS I've tried this CVSROOT=":pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP" cvs login cvs -z3 checkout -P -rOPENLDAP_REL_ENG_2_4 ldap but after build I cannot start it, it is crashing [root@ldap3 ~]# slaptest24 -f /etc/openldap24/slapd.conf -F /tmp/test -d1 finishes with this: oc_check_allowed type "createTimestamp" oc_check_allowed type "entryCSN" oc_check_allowed type "modifiersName" oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 config_build_entry: "olcDatabase={1}bdb" slaptest24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Aborted or with LANG=cs_CZ.UTF-8 oc_check_allowed type "modifyTimestamp" ldif_back_add: err: 68 text: send_ldap_result: conn=-1 op=0 p=0 config_build_entry: "olcDatabase={1}bdb" slaptest24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Neúspěšně ukončen (SIGABRT) similar is slapd [root@ldap3 ~]# slapd24 -f /etc/openldap24/slapd.conf -d 1 slapd24 startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=module{0}" config_build_entry: "cn=schema" config_build_entry: "cn={0}corba" config_build_entry: "cn={1}core" config_build_entry: "cn={2}cosine" config_build_entry: "cn={3}duaconf" config_build_entry: "cn={4}dyngroup" config_build_entry: "cn={5}inetorgperson" config_build_entry: "cn={6}java" config_build_entry: "cn={7}misc" config_build_entry: "cn={8}nis" config_build_entry: "cn={9}openldap" config_build_entry: "cn={10}ppolicy" config_build_entry: "cn={11}collective" config_build_entry: "cn={12}samba" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" slapd24: ../../../servers/slapd/config.c:1447: slap_cf_aux_table_unparse: Assertion `0' failed. Neúspěšně ukončen (SIGABRT) I don't use cn=config, I have only slapd.conf. Is it the reason? Pavel

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 11 Dec '09

11 Dec '09

On Thu, Dec 10, 2009 at 08:21:20AM -0800, Quanah Gibson-Mount wrote: >Well, now 2.4.20 is current (just to note). Right. I'm now running this version. The results below are with 2.4.20, and not 2.4.19. >What we'll need for resolving your issue is: > >(a) Your configuration files (minus passwords) # egrep -v '^#|^$' etc/openldap/slapd.conf TLSCertificateFile <removed>.crt TLSCertificateKeyFile <removed>.key TLSCACertificateFile <removed>.ca include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include /usr/local/ldap/etc/openldap/schema/nis.schema include /usr/local/ldap/etc/openldap/schema/qmail.schema include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema include /usr/local/ldap/etc/openldap/schema/mod_vhost_ldap.schema include /usr/local/ldap/etc/openldap/schema/monsternett_vhost_ldap.schema include /usr/local/ldap/etc/openldap/schema/sql_user.schema include /usr/local/ldap/etc/openldap/schema/using_space.schema pidfile /usr/local/ldap/var/run/slapd/slapd.pid argsfile /usr/local/ldap/var/run/slapd/slapd.args loglevel stats modulepath /usr/local/ldap/lib moduleload back_hdb sizelimit 99999 tool-threads 8 threads 16 concurrency 32 backend hdb database hdb suffix "dc=<removed>" directory "/usr/local/ldap/var/openldap-data" cachesize 60000 dbconfig set_cachesize 0 52428800 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 index objectclass,sn eq index cn,uniqueMember,memberUid,uidNumber,gidNumber pres,eq index uid,mail,associatedDomain,mailAlternateAddress,apacheServerName,apacheServerAlias,apacheSuexecUid pres,eq,sub lastmod on checkpoint 512 30 access to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=<removed>" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=<removed>" write by * read >(b) A backtrace from gdb of a crash. Since this is a *live* server, I don't want to run it through gdb if I don't have to. Also, the server doesn't really crash, it just hangs, using 100% of one CPU core. We currently have a script that checks if ldapsearch succeeds, and if not, it restarts slapd. AFAIK, if we would have done this via gdb directly, the ports would still be open, and slapd wouldn't be able to start, which means I would have to sit there for an hour to quickly be able to run a backtrace, so slapd could be restarted instantly :) Anyway, instead, I made it dump a core (by sending killall -11 slapd in my script). I hope this is sufficient. --- gdb core bt start --- (gdb) thread apply all bt Thread 18 (process 7691): #0 0x00007ff212f77b78 in epoll_wait () from /lib/libc.so.6 #1 0x000000000041c618 in slapd_daemon_task (ptr=<value optimized out>) at daemon.c:2465 #2 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007ff212f775ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 17 (process 7692): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x410f6670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x2732490, rs=0x41277ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x2732490, rs=0x41277ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x2732490, rs=0x41277ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x2732490, rs=0x41277ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x41277df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x41277df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 16 (process 7694): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x418f7670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x285ba50, rs=0x41a78ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x285ba50, rs=0x41a78ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x285ba50, rs=0x41a78ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x285ba50, rs=0x41a78ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x41a78df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x41a78df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 15 (process 7695): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x42947670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1e40163b0, rs=0x42ac8ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1e40163b0, rs=0x42ac8ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x42ac8df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x42ac8df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 14 (process 7699): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x43148670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42babf0, rs=0x432c9ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42babf0, rs=0x432c9ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x432c9df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x432c9df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 13 (process 7700): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x43949670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x16e57b0, rs=0x43acaca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x16e57b0, rs=0x43acaca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x16e57b0, rs=0x43acaca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x16e57b0, rs=0x43acaca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x43acadf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x43acadf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 12 (process 7715): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4414a670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e7260, rs=0x442cbca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e7260, rs=0x442cbca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x442cbdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x442cbdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 11 (process 7864): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4494b670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x1b731b0, rs=0x44accca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x1b731b0, rs=0x44accca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x1b731b0, rs=0x44accca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x1b731b0, rs=0x44accca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x44accdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x44accdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 10 (process 8395): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4514c670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1e4038380, rs=0x452cdca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1e4038380, rs=0x452cdca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x452cddf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x452cddf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 9 (process 8808): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4594d670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1fcac89e0, rs=0x45aceca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1fcac89e0, rs=0x45aceca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x45acedf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x45acedf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 8 (process 9706): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4614e670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414b4d0, rs=0x462cfca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414b4d0, rs=0x462cfca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414b4d0, rs=0x462cfca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414b4d0, rs=0x462cfca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x462cfdf0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x462cfdf0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 7 (process 10771): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x4694f670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414c100, rs=0x46ad0ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414c100, rs=0x46ad0ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414c100, rs=0x46ad0ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414c100, rs=0x46ad0ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x46ad0df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x46ad0df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 6 (process 11742): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x47150670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e8640, rs=0x472d1ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e8640, rs=0x472d1ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x472d1df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x472d1df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 5 (process 11743): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x47951670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x414c610, rs=0x47ad2ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x414c610, rs=0x47ad2ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x414c610, rs=0x47ad2ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x414c610, rs=0x47ad2ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x47ad2df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x47ad2df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 4 (process 18180): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x48152670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x4376ee0, rs=0x482d3ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x4376ee0, rs=0x482d3ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x482d3df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x482d3df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 3 (process 18190): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x48953670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42d4510, rs=0x48ad4ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42d4510, rs=0x48ad4ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x48ad4df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x48ad4df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 2 (process 18200): #0 0x00007ff214c53d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x000000000042efc5 in send_ldap_ber (op=<value optimized out>, ber=0x49154670) at result.c:225 #2 0x0000000000430d00 in slap_send_search_entry (op=0x7ff1f42e78e0, rs=0x492d5ca0) at result.c:1260 #3 0x000000000049df00 in hdb_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:961 #4 0x0000000000421491 in fe_op_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:366 #5 0x0000000000421c8c in do_search (op=0x7ff1f42e78e0, rs=0x492d5ca0) at search.c:217 #6 0x000000000041efff in connection_operation (ctx=0x492d5df0, arg_v=<value optimized out>) at connection.c:1109 #7 0x000000000041fcdd in connection_read_thread (ctx=0x492d5df0, argv=<value optimized out>) at connection.c:1245 #8 0x00000000004eae20 in ldap_int_thread_pool_wrapper (xpool=<value optimized out>) at tpool.c:685 #9 0x00007ff214c4ffc7 in start_thread () from /lib/libpthread.so.0 #10 0x00007ff212f775ad in clone () from /lib/libc.so.6 #11 0x0000000000000000 in ?? () Thread 1 (process 7690): #0 0x00007ff214c50715 in pthread_join () from /lib/libpthread.so.0 #1 0x0000000000419c4c in slapd_daemon () at daemon.c:2840 #2 0x0000000000407d8a in main (argc=7, argv=0x7fff1d3caa88) at main.c:961 --- gdb core bt end --- I guess the last part in the treads are caused by me sending a SIGSEGV, i.e. every thread was inside clone () after slapd started hanging? Well, I'll leave the analysis to the experts I think :-) -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by quanah＠zimbra.com 11 Dec '09

11 Dec '09

--On Thursday, December 10, 2009 3:13 PM +0000 pavel.lisy(a)tmapy.cz wrote: > Today I've tried go back to 2.4.18 release and in the same configuration > there isn't this bug. > > So it is problem in 2.4.19 and 2.4.20. Please try CVS RE24, there's a fix to TLS in there that may be the cause. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 1:02 PM +0330 afshin afzali <a.afzali2003(a)gmail.com> wrote: > Hi Quanah > > I did reconfigure with --enable-debug, but just could get this: To build with debugging symbols, you need to use a CFLAGS value of -g, like: CFLAGS="-g" ./configure <whatever options you use> make depend make make install DESTDIR=/my/path/to/install STRIP="" The STRIP="" ensures none of the debugging symbols inserted by gcc get stripped out. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by quanah＠zimbra.com 10 Dec '09

10 Dec '09

--On Thursday, December 10, 2009 10:44 AM +0100 Helge Milde <helge(a)monsternett.no> wrote: > I have now installed openldap 2.4.19 from source (default configuration > except for --enable-crypt=yes). > ># slapd -V > @(#) $OpenLDAP: slapd 2.4.19 (Dec 9 2009 22:46:15) $ > > But unfortunately, the bug is still there. Nothing has changed at all.. > It has crashed 10 times since I did the migration 10 hours ago. It > usually crashes 1-2 times at night, and 10-20 times during work hours > (when the servers have more load). Well, now 2.4.20 is current (just to note). What we'll need for resolving your issue is: (a) Your configuration files (minus passwords) (b) A backtrace from gdb of a crash. Make sure you build OpenLDAP with debugging symbols (using CFLAGS of -g) and when you run make install, make sure you use STRIP="", like: make install DESTDIR=/my/path/to/install STRIP="" Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pavel.lisy＠tmapy.cz 10 Dec '09

10 Dec '09

Today I've tried go back to 2.4.18 release and in the same configuration there isn't this bug. So it is problem in 2.4.19 and 2.4.20. Pavel

1 0

(ITS#6428) modification to global limits require a restart to take effect
by rhafer＠suse.de 10 Dec '09

10 Dec '09

Full_Name: Ralf Haferkamp Version: 2.4.20, HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.231.132) Changes to the global limits in "olcDatabase=frontend,cn=config" don't take effect database until slapd is restarted. I am working on a fix.

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 10 Dec '09

10 Dec '09

I have now installed openldap 2.4.19 from source (default configuration except for --enable-crypt=yes). # slapd -V @(#) $OpenLDAP: slapd 2.4.19 (Dec 9 2009 22:46:15) $ But unfortunately, the bug is still there. Nothing has changed at all.. It has crashed 10 times since I did the migration 10 hours ago. It usually crashes 1-2 times at night, and 10-20 times during work hours (when the servers have more load). When I migrated, I recreated the database by typing: # oldbin/slapcat > db.ldif # newbin/slapadd < db.ldif # (under the new openldap/slapd user) So I can't imagine the database can be corrupt in any way, which I initially thought when I first sent this bug report. It still dies on the same queries as before, in the middle of iterating through ou=users,.. or ou=groups,.., which both have ~1.8k entries. These queries comes from proftpd, which does a "getent passwd" and "getent group" every time a customer logs in. I tried to reproduce this manually again, launching 8 processes, constantly querying ou=users and ou=groups, 2 using a unix socket locally and 6 using ldaps://hostname/ remotely, but it still won't break down when I do that. This causes *alot* more load than proftpd does, but the crashes seem to only happen "randomly". Any suggestions on what I can do to figure out this problem? The LDAP server is live and in use in two servers with 2-3k users, so I can't mess with it *too* much. On Fri, Oct 02, 2009 at 09:28:25PM +0000, quanah(a)zimbra.com wrote: >--On Friday, October 02, 2009 8:54 PM +0000 hyc(a)symas.com wrote: > > >> strace is useless. Use gdb and get a trace of all running threads when >> this occurs. >> >> http://www.openldap.org/faq/data/cache/59.html > > >You also need to test against a current release of OpenLDAP, like OpenLDAP >2.4.18. > >--Quanah > > >-- > >Quanah Gibson-Mount >Principal Software Engineer >Zimbra, Inc >-------------------- >Zimbra :: the leader in open source messaging and collaboration > > -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 10 Dec '09

10 Dec '09

hyc(a)symas.com wrote: > masarati(a)aero.polimi.it wrote: >> The problem is that back-relay presents slapo-rwm(3) an entry with both >> REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a >> consequence, the entry is released (namely, freed) before it is returned >> by the frontend. As far as I understand, the two flags should be mutually >> exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is >> supposed to be a copy of an entry that may need to be released, or an >> entry created from scratch and thus not stored anywhere. I have a quick >> fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when >> REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in >> tracking where the issue occurs. Unless I track it, I'll commit the quick >> fix. > > We already have ITS#5340 for issues with these flags... Right. I asked him to open an ITS because I though the error was in slapo-rwm; my first fix was in that area. Soon after, I realized the error was in slapo-dynlist, related to ITS#5340. p.

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 10 Dec '09

10 Dec '09

I wrote: > Otherwise it should use rs_ensure_entry_modifiable(). Currently > it's still wrong: Discards the old entry without obeying sr_flags. Unless dynlist_sc_save_entry() handles it, I haven't yet tried to figure out the state when it is called. But it looks wrong: it saves and clears rs->sr_entry without saving/clearing (rs->sr_flags & REP_ENTRY_MASK). Here is a draft for what rs_ensure_entry_modifiable() usage is supposed to look like, though I haven't tested it well and I'm going home now. I'm unsure of the translucent code. rwm looks a bit weird, but that's mostly to assert that some functions that receive rs won't modify it. I haven't touched dynlist, don't know what entry ownership is there. http://folk.uio.no/hbf/OpenLDAP/slapreply-draft.diff -- Hallvard

1 0

Re: (ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 10 Dec '09

10 Dec '09

ldapwhoami has the same behaviour [root@ldap1 ~]# time ldapwhoami -xZZh ldap1.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m4.835s user 0m0.021s sys 0m0.012s [root@ldap1 ~]# time ldapwhoami -xZZh ldap2.ldapnet.tmapy.cz anonymous Result: Success (0) real 0m0.042s user 0m0.023s sys 0m0.013s

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 10 Dec '09

10 Dec '09

I've been trying to do too much at once in this ITS. My macros can be simplified to at least use functions for the exposed API. Since we now have commits related to this (ITS#6423), there's no reason not to use a common function for the new commits, instead of trying to get it right each time. I've committed a variant of this, so far unused: slap.h REP_ENTRY_MUSTFLUSH, result.c rs_replace_entry(), rs_ensure_entry_modifiable() When an overlay can wants to update rs->sr_entry it can use these. Exception: Some code may want to temporarily replace the entry and later restore it. That should be by a push/pop of sr_entry and (sr_flags & REP_ENTRY_MASK) together. That is, push: <save rs->sr_entry and rs->rs_flags>; rs->sr_flags &= ~REP_ENTRY_MASK; rs->sr_entry = new entry; rs->sr_flags |= new entryflags, if any; pop: rs_replace_entry(op, rs, on, <old entry>); rs->sr_flags |= (<saved flags> & REP_ENTRY_MASK); Maybe this is what dynlist.c:dynlist_prepare_entry() wants to do? I don't see why else it waits to the end of the function to set rs->sr_flags/sr_entry to the _new_ flags and entry. Otherwise it should use rs_ensure_entry_modifiable(). Currently it's still wrong: Discards the old entry without obeying sr_flags. I don't know what overlay to pass to entry_modifiable though. -- Hallvard

1 0

(ITS#6427) ldapsearch with delay (on the same machine over TLS/SSL only)
by pali＠tmapy.cz 10 Dec '09

10 Dec '09

Full_Name: Pavel Lisy Version: 2.4.19 or 2.4.20 OS: linux - CentOS4/5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.132.159.239) I have my rpm built on source from Fedora 12. ldapsearch have delay on start, slapd is heavy loaded (up to 90% proc) on the same machine over TLS/SSL only (numbers below) [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m2.610s user 0m0.029s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-z.log 2>&1 real 0m2.700s user 0m0.026s sys 0m0.013s [root@ldap1 ~]# time ldapsearch24 -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search.log 2>&1 real 0m0.021s user 0m0.010s sys 0m0.008s [root@ldap1 ~]# time ldapsearch24 -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2.log 2>&1 real 0m0.027s user 0m0.009s sys 0m0.014s [root@ldap1 ~]# time ldapsearch24 -Z -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-z.log 2>&1 real 0m0.070s user 0m0.028s sys 0m0.020s [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-l2-zz.log 2>&1 real 0m0.048s user 0m0.026s sys 0m0.017s This means: delay is there when I query from the same machine over TLS/SSL, not across machines. I suppose it is bug but I cannot find where it is. When I've changed in slapd.conf "loglevel 0" to "loglevel 1" delay is gone [root@ldap1 ~]# time ldapsearch24 -ZZ -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w heslo -d 1 > search-zz.log 2>&1 real 0m0.315s user 0m0.030s sys 0m0.025s When I start ldapsearch24 through strace delay was in part with stars: ------------ cut --------------- munmap(0x2b2edf8b1000, 4096) = 0 brk(0x15747000) = 0x15747000 write(2, "TLS trace: SSL_connect:before/co"..., 53TLS trace: SSL_connect:before/connect initialization ) = 53 open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4 fstat(4, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0 poll([{fd=4, events=POLLIN}], 1, 10) = 1 ([{fd=4, revents=POLLIN}]) read(4, "D~j?,\274k\310mx\336\t\17k\207Q\322\0369SDB\260\241bd6[R}6\201"..., 48) = 48 close(4) = 0 getuid() = 0 write(3, "\200t\1\3\1\0K\0\0\0 \0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0\300"..., 118 *********************************************** DELAY 2s HERE *********************************************** ) = 118 write(2, "TLS trace: SSL_connect:SSLv2/v3 "..., 53TLS trace: SSL_connect:SSLv2/v3 write client hello A ) = 53 read(3, "\26\3\1\0J\2\0", 7) = 7 read(3, "\0F\3\1K \10\5\232\0\3\2\354\235\351\233\276\31\242\302\217\214\35\32\370cGH\342\277\7;"..., 72) = 7 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 49TLS trace: SSL_connect:SSLv3 read server hello A ) = 49 read(3, "\26\3\1\6\303", 5) = 5 read(3, "\v\0\6\277\0\6\274\0\2\2500\202\2\2440\202\2\r\2\3\20\0\0010\r\6\t*\206H\206\367"..., 1731) = 1731 write(2, "TLS certificate verification: de"..., 191TLS certificate verification: depth: 1, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS certificate verification: de"..., 146TLS certificate verification: depth: 0, err: 0, subject: / write(2, " issuer: /O=T-MAPY spol. s r.o./"..., 143 issuer: /O=T-MAPY spol. s r.o./OU=ldapnet/emailAddress=pa ) = 143 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 55TLS trace: SSL_connect:SSLv3 read server certificate A ) = 55 read(3, "\26\3\1\0\4", 5) = 5 read(3, "\16\0\0\0", 4) = 4 write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 48TLS trace: SSL_connect:SSLv3 read server done A ) = 48 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 57TLS trace: SSL_connect:SSLv3 write client key exchange A ) = 57 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 56TLS trace: SSL_connect:SSLv3 write change cipher spec A ) = 56 write(2, "TLS trace: SSL_connect:SSLv3 wri"..., 46TLS trace: SSL_connect:SSLv3 write finished A ) = 46 write(3, "\26\3\1\0\206\20\0\0\202\0\200\202\365\233\356\r\26\27\330\251\17\330\331\3362\23\231\211`\\\262\32 write(2, "TLS trace: SSL_connect:SSLv3 flu"..., 40TLS trace: SSL_connect:SSLv3 flush data ) = 40 read(3, "\24\3\1\0\1", 5) = 5 read(3, "\1", 1) = 1 read(3, "\26\3\1\0000", 5) = 5 read(3, "\353;\20\337y\307&\331\207@#\265\314\267\240\244\177P\223\216\221\216!\"G \27\265R\3078l"..., 48) = write(2, "TLS trace: SSL_connect:SSLv3 rea"..., 45TLS trace: SSL_connect:SSLv3 read finished A ) = 45 write(2, "ldap_sasl_bind\n", 15ldap_sasl_bind ) = 15 write(2, "ldap_send_initial_request\n", 26ldap_send_initial_request ) = 26 write(2, "ldap_send_server_request\n", 25ldap_send_server_request ) = 25 write(2, "ber_scanf fmt ({it) ber:\n", 25ber_scanf fmt ({it) ber: ) = 25 write(2, "ber_scanf fmt ({i) ber:\n", 24ber_scanf fmt ({i) ber: ) = 24 write(2, "ber_flush2: 44 bytes to sd 3\n", 29ber_flush2: 44 bytes to sd 3 ) = 29 write(3, "\27\3\1\0 \217\244v\31\275A\232=\300\357\330\312*\316)\311\23\242\260\350n\353\373\221\204B\v"..., write(2, "ldap_result ld 0x156816c0 msgid "..., 34ldap_result ld 0x156816c0 msgid 2 ) = 34 write(2, "wait4msg ld 0x156816c0 msgid 2 ("..., 50wait4msg ld 0x156816c0 msgid 2 (infinite timeout) ) = 50 write(2, "wait4msg continue ld 0x156816c0 "..., 46wait4msg continue ld 0x156816c0 msgid 2 all 1 ) = 46 write(2, "** ld 0x156816c0 Connections:\n", 30** ld 0x156816c0 Connections: ) = 30 write(2, "* host: ldap1.ldapnet.tmapy.cz "..., 53* host: ldap1.ldapnet.tmapy.cz port: 389 (default) ) = 53 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected ) = 31 write(2, " last used: Wed Dec 9 21:26:51"..., 39 last used: Wed Dec 9 21:26:51 2009 ------------ cut --------------- How can I debug it more? I will send more details if you want.

1 0

Re: (ITS#6426) slapd crash with 'Bus error'
by quanah＠zimbra.com 09 Dec '09

09 Dec '09

--On Wednesday, December 09, 2009 12:56 PM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: 2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > Bus error > [root@dc1 openldap]# Please provide a GDB backtrace of the crash with full debugging symbols. Thanks --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by h.b.furuseth＠usit.uio.no 09 Dec '09

09 Dec '09

hyc(a)symas.com writes: > We already have ITS#5340 for issues with these flags... I'll follow up there. Looking again, I think it can be simplified. -- Hallvard

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by leo＠strike.wu.ac.at 09 Dec '09

09 Dec '09

On 12/08/2009 07:31 PM, masarati(a)aero.polimi.it wrote: > Fixed in HEAD; the fix is in overlays/dynlist.c 1.68->1.69 > > Please test and report. Thanks, p. Thanks! At least the dynlist overlay works fine now. (Couldn't test slapo-collect and slapo-overlay.) Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria

1 0

(ITS#6426) slapd crash with 'Bus error'
by a.afzali2003＠gmail.com 09 Dec '09

09 Dec '09

Full_Name: afshin afzali Version: 2.4.19 OS: CentOS 5 - 64Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.182.20.153) I use "Apache Directory Studio" to manage my directory service. Randomly I used an invalid attribute ( cn ) to create an country object. Regards, -- afshin >>> slap_listener(ldap:///) connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 42 contents: op tag 0x60, time 1260363040 ber_get_next conn=0 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnPrettyNormal: <cn=root,dc=callee,dc=ir>, <cn=root,dc=callee,dc=ir> do_bind: version=3 dn="cn=root,dc=callee,dc=ir" method=128 ==> ndb_back_bind: dn: cn=root,dc=callee,dc=ir do_bind: v3 bind: "cn=root,dc=callee,dc=ir" to "cn=root,dc=callee,dc=ir" send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 56 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 0 3 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: subschemaSubentry => send_search_entry: conn 0 dn="" ber_flush2: 68 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 96 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=2 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=Subschema> => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 <<< dnPrettyNormal: <cn=Subschema>, <cn=subschema> SRCH "cn=Subschema" 0 3 0 0 0 ber_scanf fmt ({mm}) ber: filter: (objectClass=subschema) ber_scanf fmt ({M}}) ber: attrs: createTimestamp modifyTimestamp => send_search_entry: conn 0 dn="cn=Subschema" ber_flush2: 127 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=2 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=3 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 174 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=3 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=Subschema> => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 <<< dnPrettyNormal: <cn=Subschema>, <cn=subschema> SRCH "cn=Subschema" 0 3 0 0 0 ber_scanf fmt ({mm}) ber: filter: (objectClass=subschema) ber_scanf fmt ({M}}) ber: attrs: objectClasses attributeTypes ldapSyntaxes matchingRules matchingRuleUse createTimestamp modifyTimestamp => send_search_entry: conn 0 dn="cn=Subschema" ber_flush2: 71646 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=3 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=4 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 221 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=4 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 0 0 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: namingContexts subschemaSubentry supportedLDAPVersion supportedSASLMechanisms supportedExtension supportedControl supportedFeatures vendorName vendorVersion + objectClass => send_search_entry: conn 0 dn="" ber_flush2: 797 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=4 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=5 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 40 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=5 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 0 0 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: * => send_search_entry: conn 0 dn="" ber_flush2: 70 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=5 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=6 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 79 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=6 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=Subschema> => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 <<< dnPrettyNormal: <cn=Subschema>, <cn=subschema> SRCH "cn=Subschema" 0 3 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass => send_search_entry: conn 0 dn="cn=Subschema" ber_flush2: 104 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=6 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=7 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 76 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=7 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 <<< dnPrettyNormal: <cn=config>, <cn=config> SRCH "cn=config" 0 3 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass ==> limits_get: conn=0 op=7 self="cn=root,dc=callee,dc=ir" this="cn=config" send_ldap_result: conn=0 op=7 p=3 send_ldap_result: err=32 matched="" text="" send_ldap_response: msgid=8 tag=101 err=32 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 82 contents: op tag 0x63, time 1260363040 ber_get_next conn=0 op=8 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=callee,dc=ir> => ldap_bv2dn(dc=callee,dc=ir,0) <= ldap_bv2dn(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 <<< dnPrettyNormal: <dc=callee,dc=ir>, <dc=callee,dc=ir> SRCH "dc=callee,dc=ir" 0 3 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> => send_search_entry: conn 0 dn="dc=callee,dc=ir" ber_flush2: 122 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=8 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=9 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 55 contents: op tag 0x63, time 1260363055 ber_get_next conn=0 op=9 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <dc=callee,dc=ir> => ldap_bv2dn(dc=callee,dc=ir,0) <= ldap_bv2dn(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=callee,dc=ir)=0 <<< dnPrettyNormal: <dc=callee,dc=ir>, <dc=callee,dc=ir> SRCH "dc=callee,dc=ir" 0 3 0 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: * >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> >>> dnNormalize: <cn=root,dc=callee,dc=ir> => ldap_bv2dn(cn=root,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=root,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=root,dc=callee,dc=ir)=0 <<< dnNormalize: <cn=root,dc=callee,dc=ir> => send_search_entry: conn 0 dn="dc=callee,dc=ir" ber_flush2: 138 bytes to sd 13 <= send_search_entry: conn 0 exit. send_ldap_result: conn=0 op=9 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=10 tag=101 err=0 ber_flush2: 22 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 95 contents: op tag 0x63, time 1260363086 ber_get_next conn=0 op=10 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir> => ldap_bv2dn(cn=myCountry,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=mycountry,dc=callee,dc=ir)=0 <<< dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir>, <cn=mycountry,dc=callee,dc=ir> SRCH "cn=myCountry,dc=callee,dc=ir" 0 0 1 0 0 ber_scanf fmt (m) ber: filter: (objectClass=*) ber_scanf fmt ({M}}) ber: attrs: hasSubordinates objectClass send_ldap_result: conn=0 op=10 p=3 send_ldap_result: err=32 matched="dc=callee,dc=ir" text="" send_ldap_response: msgid=11 tag=101 err=32 ber_flush2: 37 bytes to sd 13 connection_get(13) connection_get(13): got connid=0 connection_read(13): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 87 contents: op tag 0x68, time 1260363100 ber_get_next conn=0 op=11 do_add ber_scanf fmt ({m) ber: conn=0 op=11 do_add: dn (cn=myCountry,dc=callee,dc=ir) ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt (}) ber: >>> dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir> => ldap_bv2dn(cn=myCountry,dc=callee,dc=ir,0) <= ldap_bv2dn(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=myCountry,dc=callee,dc=ir)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=mycountry,dc=callee,dc=ir)=0 <<< dnPrettyNormal: <cn=myCountry,dc=callee,dc=ir>, <cn=mycountry,dc=callee,dc=ir> ==> ndb_back_add: cn=myCountry,dc=callee,dc=ir oc_check_required entry (cn=myCountry,dc=callee,dc=ir), objectClass "country" Entry (cn=myCountry,dc=callee,dc=ir): object class 'country' requires attribute 'c' ndb_back_add: entry failed schema check: object class 'country' requires attribute 'c' (65) send_ldap_result: conn=0 op=11 p=3 send_ldap_result: err=65 matched="" text="object class 'country' requires attribute 'c'" send_ldap_response: msgid=12 tag=105 err=65 ber_flush2: 67 bytes to sd 13 Bus error [root@dc1 openldap]#

1 0

Re: (ITS#6389) Allow setting syncrepl keepalive
by masarati＠aero.polimi.it 09 Dec '09

09 Dec '09

quanah(a)zimbra.com wrote: > When configuring a replica using syncrepl, it should be possible to have an > option that sets the keepalive used for the tcp connection between the replica > and master. Support for this was added to libldap, but no corresponding support > was added to the syncrepl stanza. I'd suggest a keyword like "keepalive" for > configuring this, based in seconds. A fix is in HEAD (it's been there for a while); please test. Thanks, p.

1 0

Re: (ITS#6037) errno in signal handlers
by hyc＠symas.com 09 Dec '09

09 Dec '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Signal handlers slapd/daemon.c:slap_sig_shutdown()/slap_sig_wake() need > to save/restore errno, since they call functions that can modify errno. > > And/or possibly they need sock_errno() - sock_errset() from ac/socket.h, > since they use tcp_write()? I don't know if that's safe inside signal > handlers, or if Windows itself saves/restores this code around signal > handlers. Windows doesn't really have signals in the first place. SIGTERM/SIGINT are simulated by the C runtime library, none of the other signals are really supported... All of the "support" is synchronous only - can only be invoked by raise(). I don't think there's any issue here. (An exception - I wrote a patch for the MSYS 1.11 runtime to propagate SIGINT/SIGTERM to other processes. The patch only works on win32, not win64 because I never got a decent win64 build environment working... But if you're using MSYS, it is possible to send these signals to a running slapd and have it shutdown cleanly. Otherwise, signals don't really exist for native Windows apps...) > slapd/main.c:wait4child() can loop forever after EINTR, since it checks > for errno even when the waitpid returns 0. I don't know if there is > a good reason it does that. Some of the commits have my name on them > but I think I copied it from elsewhere. > > > Anyway, I'm doing the minimal changes now: save/restore errno, and > set errno=0 in each loop iteration instead of before the loop. > Anyone with better ideas can take it from there. Good enough. 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

Re: ITS#6423 slapo-rwm and dynlist overlay
by hyc＠symas.com 09 Dec '09

09 Dec '09

masarati(a)aero.polimi.it wrote: > The problem is that back-relay presents slapo-rwm(3) an entry with both > REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a > consequence, the entry is released (namely, freed) before it is returned > by the frontend. As far as I understand, the two flags should be mutually > exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is > supposed to be a copy of an entry that may need to be released, or an > entry created from scratch and thus not stored anywhere. I have a quick > fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when > REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in > tracking where the issue occurs. Unless I track it, I'll commit the quick > fix. We already have ITS#5340 for issues with these flags... -- -- 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

ldapsearch with delay (on the same machine over TLS/SSL only)
by Pavel Lisy 08 Dec '09

08 Dec '09

Hello I've found one problem I have latest openldap release 2.4.3 (but it is similar on former versions too). There is small delay (1-2s) on beginning when I query ldap server from the same machine over TLS or SSL. Without SSL is no delay. Is it bug or is it normal? How can I debug it more? QUERY with delay: from ldap1 to ldap1 (the same machine) [root@ldap1 ~]# ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d QUERY without delay: from ldap1 to ldap1 (the same machine without TLS) [root@ldap1 ~]# ldapsearch24 -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d from ldap1 to ldap2 [root@ldap1 ~]# ldapsearch24 -Z -h ldap2.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d from ldap2 to ldap1 [root@ldap2 ~]# ldapsearch24 -Z -h ldap1.ldapnet.tmapy.cz -x -s sub -D "cn=Manager,dc=tmapy,dc=cz" -b 'dc=tmapy,dc=cz' -w p*****d I think my DNS/hosts settings are correct My testing environment: servers: ldap1.ldapnet.tmapy.cz ldap2.ldapnet.tmapy.cz ldap3.ldapnet.tmapy.cz from ldap1 config: slapd.conf TLSCACertificateFile /etc/pki/tls/cacert.pem TLSCertificateFile /etc/pki/tls/certs/ldap1.ldapnet.tmapy.cz-cert.pem TLSCertificateKeyFile /etc/pki/tls/private/ldap1.ldapnet.tmapy.cz-key.pem [root@ldap1 ~]# hostname ldap1.ldapnet.tmapy.cz [root@ldap1 ~]# grep ldap1 /etc/hosts 192.168.241.10 ldap1.ldapnet.tmapy.cz [root@ldap1 ~]# ifconfig eth0 eth0 inet adr:192.168.241.10 Všesměr:192.168.241.255 Maska:255.255.255.0 [root@ldap1 ~]# grep ldap1 /etc/pki/tls/certs/ldap1.ldapnet.tmapy.cz-cert.pem Subject: C=CS, ST=Kraj kralovehradecky, O=T-MAPY spol. s r.o.,OU=ldapnet, CN=ldap1.ldapnet.tmapy.cz Pavel Lisy -- Pavel Lisy <pali(a)tmapy.cz>

3 4

Re: (ITS#6425) Uninitialized var in syncrepl
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

h.b.furuseth(a)usit.uio.no writes: > In syncrepl.c lines 1001-1010: Also in equivalent code around line 820. -- Hallvard

1 0

(ITS#6425) Uninitialized var in syncrepl
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.20 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In syncrepl.c lines 1001-1010: LDAPControl **next; rctrlp = ldap_control_find( LDAP_CONTROL_SYNC_DONE, rctrls, &next ); if ( next && ldap_control_find( LDAP_CONTROL_SYNC_DONE, next, NULL ) ) 'next' in the last line is uninitalized if 2nd line failed. Seen in testrun/srv2/valgrind.* with './run -b null test050' and and slapd under valgrind.

1 0

ITS#6423 slapo-collect & slapo-valsort could suffer from the same issue
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

This should now be fixed in HEAD, collect.c 1.17 <- 1.16 valsort.c 1.27 <- 1.26 please review and test. p.

1 0

Re: ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Fixed in HEAD; the fix is in overlays/dynlist.c 1.68->1.69 Please test and report. Thanks, p.

1 0

(ITS#6424) slapd-meta pseudoroot* directives deprecated
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.247) Submitted by: ando The man page erroneously reports them. A fix is coming. See also ITS#6418. p.

1 0

ITS#6423 slapo-rwm and dynlist overlay
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

The problem is that back-relay presents slapo-rwm(3) an entry with both REP_ENTRY_MODIFIABLE and REP_ENTRY_MUSTRELEASE flags set. As a consequence, the entry is released (namely, freed) before it is returned by the frontend. As far as I understand, the two flags should be mutually exclusive. As soon as one entry is marked as REP_ENTRY_MODIFIABLE, it is supposed to be a copy of an entry that may need to be released, or an entry created from scratch and thus not stored anywhere. I have a quick fix to your problem, that consists in ignoring REP_ENTRY_MUSTRELEASE when REP_ENTRY_MODIFIABLE is also set. However, a better fix would consist in tracking where the issue occurs. Unless I track it, I'll commit the quick fix. p.

1 0

(ITS#6423) slapo-rwm and dynlist overlay
by leo＠strike.wu.ac.at 08 Dec '09

08 Dec '09

Full_Name: Leo Bergolth Version: 2.4.20 OS: linux URL: http://leo.kloburg.at/tmp/dynlist-rwm.log Submission from: (NULL) (137.208.89.66) When using the relay backend, entries that have attributes expanded by the dynlist overlay are not shown in the virtual naming context. (Not even those attributes that are not created dynamically, only an empty dn is shown for those entries.) Example: # real naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu-wien,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: cn=dynlisttest,ou=LDAPgroups,dc=wu-wien,dc=ac,dc=at objectClass: wuDynGroupOfNames objectClass: groupOfURLs objectClass: top cn: dynlisttest memberURL: ldap:///dc=wu-wien,dc=ac,dc=at??sub?(&(objectclass=wuPerson)(uid=be rgolth*)) member: uid=bergolth,ou=users,dc=wu-wien,dc=ac,dc=at member: uid=bergolth2,ou=LDAPusers,dc=wu-wien,dc=ac,dc=at -------------------- 8< -------------------- # virtual naming context: -------------------- 8< -------------------- $ ldapsearch -LLL -h bach-s49 -b 'dc=wu,dc=ac,dc=at' -x '(cn=dynlisttest)' dn: -------------------- 8< -------------------- According to Pierangelo Maserati it seems to be a bug in slapo-rwm. http://thread.gmane.org/gmane.network.openldap.technical/207/focus=210 # dynlist config: -------------------- 8< -------------------- dn: olcOverlay={0}dynlist,olcDatabase={1}bdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}posixGroup labeledURI memberUid:uid olcDlAttrSet: {1}wuDynGroupOfNames memberURL member -------------------- 8< -------------------- # relay rwm config: -------------------- 8< -------------------- dn: olcOverlay={0}rwm,olcDatabase={3}relay,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "dc=wu-wien,dc=ac,dc=at" -------------------- 8< -------------------- The debug output of the second ldapsearch can be found at the specified URL. Thanks, --leo

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 7:19 PM +0330 afshin afzali <a.afzali2003(a)gmail.com> wrote: > Hi, > Thanks for your reply. After inspection in config.log, I found that ld > could not find libstdc++ although it there in /usr/lib and /usr/lib64. I > just add a symbolic link to libstdc++.so.6.0.8 then bingo! THE ISSUE HAS > RESOLVED > > Best Regards, I've closed this ITS based on the response. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6422) configure does not locate ndbclient library
by quanah＠zimbra.com 08 Dec '09

08 Dec '09

--On Tuesday, December 08, 2009 9:47 AM +0000 a.afzali2003(a)gmail.com wrote: > Full_Name: afshin afzali > Version: openldap-2.4.19 > OS: CentOS 5 - 64Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (94.182.20.153) > > > Hi Guys, > As you can find bellow, although I've installed MySQL-Cluster-gpl-Devel > package (there is mysql_config & ndbclient library), counfigure does not > locate ndbclient library. Also I've upgrade libtools! > > Best Regards, > -- Afshin > > > > [root@dc1 openldap-2.4.19]# mysql_config --libs > -rdynamic -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc > [root@dc1 openldap-2.4.19]# ls -l /usr/lib64/mysql/ > total 51780 > -rw-r--r-- 1 root root 10786 Nov 17 03:50 libdbug.a > -rw-r--r-- 1 root root 1056714 Nov 17 03:50 libheap.a > -rw-r--r-- 1 root root 120260 Nov 16 21:39 libmygcc.a > -rw-r--r-- 1 root root 3801024 Nov 17 03:50 libmyisam.a > -rw-r--r-- 1 root root 1417762 Nov 17 03:50 libmyisammrg.a > -rw-r--r-- 1 root root 10142882 Nov 17 03:50 libmysqlclient.a > -rwxr-xr-x 1 root root 1034 Nov 17 03:50 libmysqlclient.la > -rw-r--r-- 1 root root 10143082 Nov 17 03:50 libmysqlclient_r.a > -rwxr-xr-x 1 root root 1080 Nov 17 03:50 libmysqlclient_r.la > -rw-r--r-- 1 root root 2554406 Nov 17 03:49 libmystrings.a > -rw-r--r-- 1 root root 1799740 Nov 17 03:50 libmysys.a > -rw-r--r-- 1 root root 21375162 Nov 17 03:50 libndbclient.a > -rwxr-xr-x 1 root root 1427 Nov 17 03:50 libndbclient.la > -rw-r--r-- 1 root root 90374 Nov 17 03:50 libvio.a > -rw-r--r-- 1 root root 308548 Nov 17 03:49 libz.a > -rwxr-xr-x 1 root root 878 Nov 17 03:49 libz.la > [root@dc1 openldap-2.4.19]# ./configure --enable-ndb --disable-bdb > --disable-hdb > Configuring OpenLDAP 2.4.19-Release ... > checking for ndb_init in -lndbclient... no > configure: error: could not locate ndbclient library > [root@dc1 openldap-2.4.19]# And what does the config.log show for why this linking failed? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 08 Dec '09

08 Dec '09

Am Dienstag 08 Dezember 2009 11:53:41 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: > >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > >>> ------------------------------------ > >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > >>> type="refreshAndPersist" starttls=critical bindmethod="simple" > >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > >>> ------------------------------------ > >>> > >>> Question is if this is a bug in the documentation or in the code. I > >>> think it's the latter. > >> > >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 > >> -> 1.509. Can you please test and let us know the result? > > > > It solves the problem only partially. It still doesn't work when using > > "ldaps://" uris AFAICS. > > The code was assuming that at least one of the other TLS config keywords > would also be used in these situations. Most of the time the slapd TLS > config would only be appropriate for server use, and would need to be > overridden when acting as a client. > > Anyway, this is now fixed in HEAD. Confirmed. -- Ralf

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by hyc＠symas.com 08 Dec '09

08 Dec '09

rhafer(a)suse.de wrote: > Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: >> --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: >>> ------------------------------------ >>> olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" >>> type="refreshAndPersist" starttls=critical bindmethod="simple" >>> binddn="uid=syncrepl,dc=test" credentials="XXXXXX" >>> ------------------------------------ >>> >>> Question is if this is a bug in the documentation or in the code. I think >>> it's the latter. >> >> Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> >> 1.509. Can you please test and let us know the result? > It solves the problem only partially. It still doesn't work when using > "ldaps://" uris AFAICS. The code was assuming that at least one of the other TLS config keywords would also be used in these situations. Most of the time the slapd TLS config would only be appropriate for server use, and would need to be overridden when acting as a client. Anyway, this is now fixed in HEAD. -- -- 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

(ITS#6422) configure does not locate ndbclient library
by a.afzali2003＠gmail.com 08 Dec '09

08 Dec '09

Full_Name: afshin afzali Version: openldap-2.4.19 OS: CentOS 5 - 64Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.182.20.153) Hi Guys, As you can find bellow, although I've installed MySQL-Cluster-gpl-Devel package (there is mysql_config & ndbclient library), counfigure does not locate ndbclient library. Also I've upgrade libtools! Best Regards, -- Afshin [root@dc1 openldap-2.4.19]# mysql_config --libs -rdynamic -L/usr/lib64/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lmygcc [root@dc1 openldap-2.4.19]# ls -l /usr/lib64/mysql/ total 51780 -rw-r--r-- 1 root root 10786 Nov 17 03:50 libdbug.a -rw-r--r-- 1 root root 1056714 Nov 17 03:50 libheap.a -rw-r--r-- 1 root root 120260 Nov 16 21:39 libmygcc.a -rw-r--r-- 1 root root 3801024 Nov 17 03:50 libmyisam.a -rw-r--r-- 1 root root 1417762 Nov 17 03:50 libmyisammrg.a -rw-r--r-- 1 root root 10142882 Nov 17 03:50 libmysqlclient.a -rwxr-xr-x 1 root root 1034 Nov 17 03:50 libmysqlclient.la -rw-r--r-- 1 root root 10143082 Nov 17 03:50 libmysqlclient_r.a -rwxr-xr-x 1 root root 1080 Nov 17 03:50 libmysqlclient_r.la -rw-r--r-- 1 root root 2554406 Nov 17 03:49 libmystrings.a -rw-r--r-- 1 root root 1799740 Nov 17 03:50 libmysys.a -rw-r--r-- 1 root root 21375162 Nov 17 03:50 libndbclient.a -rwxr-xr-x 1 root root 1427 Nov 17 03:50 libndbclient.la -rw-r--r-- 1 root root 90374 Nov 17 03:50 libvio.a -rw-r--r-- 1 root root 308548 Nov 17 03:49 libz.a -rwxr-xr-x 1 root root 878 Nov 17 03:49 libz.la [root@dc1 openldap-2.4.19]# ./configure --enable-ndb --disable-bdb --disable-hdb Configuring OpenLDAP 2.4.19-Release ... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking configure arguments... done checking for cc... cc checking for ar... ar checking for style of include used by make... GNU checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking dependency style of cc... none checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from cc object... ok checking for objdir... .libs checking for ranlib... ranlib checking for strip... strip checking if cc static flag works... yes checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC checking if cc PIC flag -fPIC works... yes checking if cc supports -c -o file.o... yes checking whether the cc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... cat: ld.so.conf.d/*.conf: No such file or directory GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool checking how to run the C preprocessor... cc -E checking whether we are using MS Visual C++... no checking for be_app in -lbe... no checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes checking for cc option to accept ISO C89... (cached) none needed checking dependency style of cc... (cached) none checking for cc depend flag... -M checking for afopen in -ls... no checking for EBCDIC... no checking for ANSI C header files... yes checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for sys/wait.h that is POSIX.1 compatible... yes checking whether termios.h defines TIOCGWINSZ... no checking whether sys/ioctl.h defines TIOCGWINSZ... yes checking arpa/inet.h usability... yes checking arpa/inet.h presence... yes checking for arpa/inet.h... yes checking arpa/nameser.h usability... yes checking arpa/nameser.h presence... yes checking for arpa/nameser.h... yes checking assert.h usability... yes checking assert.h presence... yes checking for assert.h... yes checking bits/types.h usability... yes checking bits/types.h presence... yes checking for bits/types.h... yes checking conio.h usability... no checking conio.h presence... no checking for conio.h... no checking crypt.h usability... yes checking crypt.h presence... yes checking for crypt.h... yes checking direct.h usability... no checking direct.h presence... no checking for direct.h... no checking errno.h usability... yes checking errno.h presence... yes checking for errno.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking filio.h usability... no checking filio.h presence... no checking for filio.h... no checking getopt.h usability... yes checking getopt.h presence... yes checking for getopt.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking io.h usability... no checking io.h presence... no checking for io.h... no checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking malloc.h usability... yes checking malloc.h presence... yes checking for malloc.h... yes checking for memory.h... (cached) yes checking psap.h usability... no checking psap.h presence... no checking for psap.h... no checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking process.h usability... no checking process.h presence... no checking for process.h... no checking sgtty.h usability... yes checking sgtty.h presence... yes checking for sgtty.h... yes checking shadow.h usability... yes checking shadow.h presence... yes checking for shadow.h... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for string.h... (cached) yes checking for strings.h... (cached) yes checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking sys/fstyp.h usability... no checking sys/fstyp.h presence... no checking for sys/fstyp.h... no checking sys/errno.h usability... yes checking sys/errno.h presence... yes checking for sys/errno.h... yes checking sys/ioctl.h usability... yes checking sys/ioctl.h presence... yes checking for sys/ioctl.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/privgrp.h usability... no checking sys/privgrp.h presence... no checking for sys/privgrp.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for sys/stat.h... (cached) yes checking sys/syslog.h usability... yes checking sys/syslog.h presence... yes checking for sys/syslog.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking for sys/types.h... (cached) yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/vmount.h usability... no checking sys/vmount.h presence... no checking for sys/vmount.h... no checking syslog.h usability... yes checking syslog.h presence... yes checking for syslog.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking for resolv.h... yes checking for netinet/tcp.h... yes checking for sys/ucred.h... no checking for sigaction... yes checking for sigset... yes checking for socket... yes checking for select... yes checking for sys/select.h... (cached) yes checking for sys/socket.h... (cached) yes checking types of arguments for select... int,fd_set *,struct timeval * checking for poll... yes checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/epoll.h usability... yes checking sys/epoll.h presence... yes checking for sys/epoll.h... yes checking for epoll system call... yes checking sys/devpoll.h usability... no checking sys/devpoll.h presence... no checking for sys/devpoll.h... no checking declaration of sys_errlist... yes checking for strerror... yes checking for strerror_r... yes checking non-posix strerror_r... no checking for regex.h... yes checking for library containing regfree... none required checking for compatible POSIX regex... yes checking sys/uuid.h usability... no checking sys/uuid.h presence... no checking for sys/uuid.h... no checking uuid/uuid.h usability... yes checking uuid/uuid.h presence... yes checking for uuid/uuid.h... yes checking for library containing uuid_generate... -luuid checking for library containing uuid_unparse_lower... none required checking for resolver link (default)... no checking for resolver link (-lresolv)... yes checking for hstrerror... yes checking for getaddrinfo... yes checking for getnameinfo... yes checking for gai_strerror... yes checking for inet_ntop... yes checking INET6_ADDRSTRLEN... yes checking struct sockaddr_storage... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... yes checking OpenSSL library version (CRL checking capability)... yes checking for _beginthread... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking POSIX thread version... 10 checking for LinuxThreads pthread.h... no checking for GNU Pth pthread.h... no checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking for pthread_create in default libraries... no checking for pthread link with -kthread... no checking for pthread link with -pthread... yes checking for sched_yield... yes checking for pthread_yield... yes checking for thr_yield... no checking for pthread_kill... yes checking for pthread_rwlock_destroy with <pthread.h>... yes checking for pthread_detach with <pthread.h>... yes checking for pthread_setconcurrency... yes checking for pthread_getconcurrency... yes checking for thr_setconcurrency... no checking for thr_getconcurrency... no checking for pthread_kill_other_threads_np... no checking for LinuxThreads implementation... no checking for LinuxThreads consistency... no checking if pthread_create() works... yes checking if select yields when using pthreads... yes checking for thread specific errno... yes checking for thread specific h_errno... yes checking for ctime_r... yes checking for gethostbyname_r... yes checking for gethostbyaddr_r... yes checking number of arguments of ctime_r... 2 checking number of arguments of gethostbyname_r... 6 checking number of arguments of gethostbyaddr_r... 8 checking for openlog... yes checking for mysql_config... yes checking for NdbApi.hpp... yes checking for ndb_init in -lndbclient... no configure: error: could not locate ndbclient library [root@dc1 openldap-2.4.19]#

1 0

Re: (ITS#6419) bindconf parser doesn't apply tls-defaults as documented
by rhafer＠suse.de 08 Dec '09

08 Dec '09

Am Montag 07 Dezember 2009 21:22:08 schrieb quanah(a)zimbra.com: > --On Monday, December 07, 2009 2:24 PM +0000 rhafer(a)suse.de wrote: > > ------------------------------------ > > olcSyncrepl: {0}rid=1 provider="ldap://master/" searchbase="dc=test" > > type="refreshAndPersist" starttls=critical bindmethod="simple" > > binddn="uid=syncrepl,dc=test" credentials="XXXXXX" > > ------------------------------------ > > > > Question is if this is a bug in the documentation or in the code. I think > > it's the latter. > > Howard believes this is fixed in head with servers/slapd/config.c 1.508 -> > 1.509. Can you please test and let us know the result? It solves the problem only partially. It still doesn't work when using "ldaps://" uris AFAICS. regards, Ralf

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

masarati(a)aero.polimi.it writes: > This fix allows the overlay to use poorly formatted data > since we cannot prevent the user from using it. Which is what I suspect is a misfeature... > A better fix would be to intercept write operations that modify entries in > a manner that would trigger slapo-dynlist(5), and be picky about how URLs > are written. This would not fix existing databases, nor handle cases > where slapo-dynlist(5) is configured using slapd-config(5). Yesbut... LDAP URLs can come from many sources and be used in many contexts; I suppose this would in practice need to treat URL-valued attributes as if they had an URL syntax. I guess we could as an extension, turned on by default. > Or, we could simply become picky about how LDAP URIs are written in general. Yup. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

> masarati(a)aero.polimi.it writes: >> Well, the fact is that memberURL is stored in the data. As soon as we >> accept that value, we need to deal with it. The current behavior of >> slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be >> parsed). We should rather reject values like this when written in the >> database, but this would probably break other applications. So I >> believe the fix is better than silently ignoring these values. > > I disagree. Data validation in LDAP is generally the user's job, LDAP > syntaxes are very rough in that regard. > > If this is a fix to make dynlist compatible with the rest of OpenLDAP's > handling of URLs in data (e.g. the ref attribute), then this is a good > fix and I'm way to late to complain. But in my view, if this fix is > introducing an incompatibility with the LDAP spec, then it's not. Data validation is the user's responsibility, but here we're using user data (an LDAP URI) to perform internal operations, so if we want to be strict, we should do it when the user writes the data, not when we are going to use it. This fix allows the overlay to use poorly formatted data since we cannot prevent the user from using it. A better fix would be to intercept write operations that modify entries in a manner that would trigger slapo-dynlist(5), and be picky about how URLs are written. This would not fix existing databases, nor handle cases where slapo-dynlist(5) is configured using slapd-config(5). Or, we could simply become picky about how LDAP URIs are written in general. p.

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by h.b.furuseth＠usit.uio.no 08 Dec '09

08 Dec '09

masarati(a)aero.polimi.it writes: > Well, the fact is that memberURL is stored in the data. As soon as we > accept that value, we need to deal with it. The current behavior of > slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be > parsed). We should rather reject values like this when written in the > database, but this would probably break other applications. So I > believe the fix is better than silently ignoring these values. I disagree. Data validation in LDAP is generally the user's job, LDAP syntaxes are very rough in that regard. If this is a fix to make dynlist compatible with the rest of OpenLDAP's handling of URLs in data (e.g. the ref attribute), then this is a good fix and I'm way to late to complain. But in my view, if this fix is introducing an incompatibility with the LDAP spec, then it's not. -- Hallvard

1 0

Re: (ITS#6421) simple filter with no brackets breaks slapo-dynlist(5)
by masarati＠aero.polimi.it 08 Dec '09

08 Dec '09

> masarati(a)aero.polimi.it writes: >> When a memberURL contains a simple filter with no brackets, like >> >> ldap:///ou=People,dc=example,dc=com???objectClass=person >> slapo-dynlist(5) is unable to build the composite filter needed >> for the related internal search. >> >> A fix is coming. > > Are you sure that's a good idea to fix? > > It's not a valid LDAP filter, even though OpenLDAP accepts it in > many places. That we accept it from users in tools is fair enough, > but I'm not sure it's a good idea to accept them on the server side. > > Makes them one step closer to interoperability problems if they > reach other servers that do not slap on the necessary parens. Well, the fact is that memberURL is stored in the data. As soon as we accept that value, we need to deal with it. The current behavior of slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be parsed). We should rather reject values like this when written in the database, but this would probably break other applications. So I believe the fix is better than silently ignoring these values. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs