openldap-bugs November 2011

openldap-bugs@openldap.org

22 participants
92 discussions

Re: (ITS#6962) Download down?
by h.b.furuseth＠usit.uio.no 30 Nov '11

30 Nov '11

h.b.furuseth(a)usit.uio.no writes: >demian.djrn(a)gmail.com writes: >> all mirrors are down, i can't download the program. > > The mirror list needs to be updated. These are down or obsolete: > > Costa Rica: No /openldap directory. Still missing in the directory listing at <http://mirrors.ucr.ac.cr/>. > Italy: Unknown host it.openldap.org. > Korea: No route to host ftp.holywar.net; TTL exceeded. > Portugal: Last update was in 2008. I notice these have been removed from the mirror list now. -- Hallvard

1 0

(ITS#7102) slapd segfaults on slapo-dds refresh with syncprov enabled
by dieter＠dkluenter.de 30 Nov '11

30 Nov '11

Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) slapd crashes with segmentation fault on a slapo-dds refresh operation, if syncprov is enabled and configured (gdb) bt #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 #4 0x000000000045e292 in slap_send_ldap_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:915 #5 0x000000000048aedb in fe_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:237 #6 0x000000000048ab57 in do_extended (op=0x7f01d8013530, rs=0x7f01e6a34a30) at extended.c:177 #7 0x0000000000446a15 in connection_operation (ctx=0x7f01e6a34b60, arg_v=0x7f01d8013530) at connection.c:1138 #8 0x0000000000446fb3 in connection_read_thread (ctx=0x7f01e6a34b60, argv=0x10) at connection.c:1274 #9 0x00007f01f5929fc0 in ldap_int_thread_pool_wrapper (xpool=0x91d540) at tpool.c:685 #10 0x00007f01f48f0a3f in start_thread (arg=0x7f01e6a35700) at pthread_create.c:297 #11 0x00007f01f3c1166d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x0000000000000000 in ?? () (gdb) frame 0 #0 0x00000000004dd429 in slap_get_commit_csn (op=0x7f01d8013530, maxcsn=0x7f01e6a346d0, foundit=0x7f01e6a346cc) at ctxcsn.c:59 59 LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { (gdb) frame 1 #1 0x00007f01f0d0a401 in syncprov_op_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at syncprov.c:1793 1793 slap_get_commit_csn( op, &maxcsn, &foundit ); (gdb) frame 2 #2 0x000000000045cbff in slap_response_play (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:505 505 rc = op->o_callback->sc_response( op, rs ); (gdb) frame 3 #3 0x000000000045ce24 in send_ldap_response (op=0x7f01d8013530, rs=0x7f01e6a34a30) at result.c:580 580 rc = slap_response_play( op, rs ); (gdb) -Dieter

1 0

(ITS#7101) test001 no longer supports back-ldif
by h.b.furuseth＠usit.uio.no 29 Nov '11

29 Nov '11

Full_Name: Hallvard B Furuseth Version: 2.4.28 OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard test001-slapadd now breaks with back-ldif, since it uses unordered slapadd which back-ldif does not support. Also 'rm -f $DBDIR1/*' should be 'rm -rf' for back-ldif.

1 0

Re: (ITS#7098) OpenLDAP crashes when changing OID value in schema definition in cn=config
by hyc＠symas.com 29 Nov '11

29 Nov '11

nick(a)eurobjects.com wrote: > Full_Name: Nikolaos Milas > Version: 2.4.26 (LTB RPM) > OS: CentOS 5.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.251.204.222) > > > We use the following schema (among others): Thanks for the report, this is now fixed in git master. > > DN: cn={5}postfix,cn=schema,cn=config > objectClass: olcSchemaConfig > cn: {5}postfix > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' > DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines > the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {2}( 1.3.6.1.4.1.25260.1.002 NAME 'mailacceptinguser' DESC > 'Defines if this user accepts mail' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > olcAttributeTypes: {3}( 1.3.6.1.4.1.25260.1.003 NAME 'aliasInactive' DESC 'A > flag, for marking the alias as not in use' EQUALITY booleanMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) > olcObjectClasses: {0}( 1.3.6.1.4.1.25260.1.1.100 NAME 'virtualaccount' DESC > 'Holds mail info for a virtual account' STRUCTURAL MUST ( owner $ > mailacceptinggeneralid $ maildrop $ cn ) MAY ( description $ aliasInactive ) ) > olcObjectClasses: {1}( 1.3.6.1.4.1.25260.1.1.101 NAME 'maillist' DESC 'Virtual > account for holding mailing list info' STRUCTURAL MUST ( mailacceptinggeneralid > $ maildrop $ cn ) MAY ( owner $ description $ aliasInactive ) ) > olcObjectClasses: {2}( 1.3.6.1.4.1.25260.1.1.102 NAME 'mailAccount' DESC 'Email > account details' AUXILIARY MUST ( mailacceptinguser $ maildrop $ cn ) MAY ( > mailacceptinggeneralid $ aliasInactive ) ) > olcObjectClasses: {3}( 1.3.6.1.4.1.25260.1.1.105 NAME 'virtualbox' DESC 'Mailbox > for system use' STRUCTURAL MUST ( owner $ mail $ uid $ cn ) MAY description ) > > We run: > # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange1 > > where /root/work/schemachange1: > dn: cn={5}postfix,cn=schema,cn=config > changetype: modify > delete: olcAttributeTypes > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' > DESC 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > - > add: olcAttributeTypes > olcAttributeTypes: {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC > 'Defines an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > This is successful: > [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange1 > ldap_initialize( ldap://localhost ) > Enter LDAP Password: > delete olcAttributeTypes: > {0}( 1.3.6.1.4.1.25260.1.000 NAME 'mailacceptinggeneralid' DESC 'Defines > an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > add olcAttributeTypes: > {0}( 1.3.6.1.4.1.25260.1.0 NAME 'mailacceptinggeneralid' DESC 'Defines > an address that we accept mail for' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > modifying entry "cn={5}postfix,cn=schema,cn=config" > modify complete > > However, then we try to run: > # /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange2 > > where /root/work/schemachange2: > dn: cn={5}postfix,cn=schema,cn=config > changetype: modify > delete: olcAttributeTypes > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines > the address mail goes to' EQUALITY caseIgnoreMatch SUBSTR > caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > - > add: olcAttributeTypes > olcAttributeTypes: {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the > address mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > and this causes an OpenLDAP crash: > [root@ldap work]# /usr/local/openldap/bin/ldapmodify -h localhost -x -v -W -D > "cn=admin,cn=config" -f /root/work/schemachange2 > ldap_initialize( ldap://localhost ) > Enter LDAP Password: > delete olcAttributeTypes: > {1}( 1.3.6.1.4.1.25260.1.001 NAME 'maildrop' DESC 'Defines the address > mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 ) > add olcAttributeTypes: > {1}( 1.3.6.1.4.1.25260.1.1 NAME 'maildrop' DESC 'Defines the address > mail goes to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 ) > modifying entry "cn={5}postfix,cn=schema,cn=config" > > This hangs, and we interrupt with Ctrl-C. > > gdb reports: -- -- 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#7099) slapadd segfaults with back-mdb and slapo-dds
by hyc＠symas.com 29 Nov '11

29 Nov '11

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.38.5.243) > > > back-mdb tries to read entry databases prior to initialisation, which leeds to > segmatation fault slapo-dds was misbehaving, fixed now in master. Overlays that hook the db_open entry point are required to check for (slapMode & SLAP_TOOL_MODE) and exit as a no-op in that case. slapo-dds was not doing this. It caused slapcat to crash as well. This problem was triggered by using the dds-max_dynamocObjects setting, which makes slapo-dds fire off a search at startup to find entries to expire/delete. Of course this operation fails in slapcat anyway, since the database is opened read-only. > > output of slapadd -d-1 > [...] > 4ed4888e slapadd startup: initiated. > 4ed4888e backend_startup_one: starting "o=avci,c=de" > 4ed4888e mdb_db_open: "o=avci,c=de" > 4ed4888e mdb_db_open: database "o=avci,c=de": > dbenv_open(/home/dieter/openldap/var/ldap-dds). > 4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))" > 4ed4888e begin get_filter > 4ed4888e AND > 4ed4888e begin get_filter_list > 4ed4888e begin get_filter > 4ed4888e EQUALITY > 4ed4888e end get_filter 0 > 4ed4888e begin get_filter > 4ed4888e LE > 4ed4888e end get_filter 0 > 4ed4888e end get_filter_list > 4ed4888e end get_filter 0 > Speicherzugriffsfehler > > the appropriate slapo-dds configuration: > [...] > overlay dds > dds-max-ttl 86400 > dds-min-ttl 0 > dds-default-ttl 3600 > dds-interval 1800 > dds-tolerance 60 > dds-max-dynamicObjects 100 > dds-state TRUE > [...] > > -Dieter > > -- -- 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#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 29 Nov '11

29 Nov '11

Pierangelo Masarati wrote: > Good point. I overlooked this in my original interpretation. I'll look into > this, time permitting. Thanks, p. Take your time. Nothing urgent. I'm just playing with it for interop testing (refresh operation and plugin classes in web2ldap). Ciao, Michael.

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by masarati＠aero.polimi.it 29 Nov '11

29 Nov '11

On 11/29/2011 02:34 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.15.82) > > > As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a > dynamicObject entry. But slapo-dds always returns the same value for entryTTL > (last refreshTTL). Another server implementation returns decreasing values for > entryTTL which would be IMO the correct behaviour. Good point. I overlooked this in my original interpretation. I'll look into this, time permitting. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 29 Nov '11

29 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.15.82) As I read RFC 2589 the attribute entryTTL contains the actual time-to-live of a dynamicObject entry. But slapo-dds always returns the same value for entryTTL (last refreshTTL). Another server implementation returns decreasing values for entryTTL which would be IMO the correct behaviour.

1 0

Re: (ITS#7097) freebsd 8.2 sql.h not found when file is actualy in /usr/local/include
by hyc＠symas.com 29 Nov '11

29 Nov '11

paul(a)scom.ca wrote: > Full_Name: Paul Kudla > Version: 2.4.23& 2.4.28 > OS: Freebsd 8.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.171.154.78) > > > Simply put openldap will not configure > > How do i get it to find the sql.h file > > 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 sql.h usability... no > checking sql.h presence... no > checking for sql.h... no > configure: error: could not locate SQL headers > > installed UnixODBC version unixODBC-2.3.1 > > > [00:28:54] root@ldap /usr/local/src/openldap-2.4.23 > # ll /usr/local/include/sql.h > -rw-r--r-- 1 root wheel 32305 Nov 28 11:58 /usr/local/include/sql.h > > [00:34:18] root@ldap /usr/local/src/openldap-2.4.23 > # > > this issue googles alot without any clear explanation. > > have no problem contributing to the cause - let me know how. Read the INSTALL document. Set the CPPFLAGS variable correctly. No bug here, 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

(ITS#7099) slapadd segfaults with back-mdb and slapo-dds
by dieter＠dkluenter.de 29 Nov '11

29 Nov '11

Full_Name: Dieter Kluenter Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.38.5.243) back-mdb tries to read entry databases prior to initialisation, which leeds to segmatation fault output of slapadd -d-1 [...] 4ed4888e slapadd startup: initiated. 4ed4888e backend_startup_one: starting "o=avci,c=de" 4ed4888e mdb_db_open: "o=avci,c=de" 4ed4888e mdb_db_open: database "o=avci,c=de": dbenv_open(/home/dieter/openldap/var/ldap-dds). 4ed4888e str2filter "(&(objectClass=dynamicObject)(entryExpireTimestamp<=20111129072258Z))" 4ed4888e begin get_filter 4ed4888e AND 4ed4888e begin get_filter_list 4ed4888e begin get_filter 4ed4888e EQUALITY 4ed4888e end get_filter 0 4ed4888e begin get_filter 4ed4888e LE 4ed4888e end get_filter 0 4ed4888e end get_filter_list 4ed4888e end get_filter 0 Speicherzugriffsfehler the appropriate slapo-dds configuration: [...] overlay dds dds-max-ttl 86400 dds-min-ttl 0 dds-default-ttl 3600 dds-interval 1800 dds-tolerance 60 dds-max-dynamicObjects 100 dds-state TRUE [...] -Dieter

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2011