- openldap-bugs - openldap.org

Re: (ITS#4737) "overlay not found"
by ando＠sys-net.it 07 Nov '06

07 Nov '06

mmollet(a)westar.com wrote: > Full_Name: Matthieu Mollet > Version: 2.2.13 > OS: Centos 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.45.242.10) > > > Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that > comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd > slapd fails with "overlay smbk5pwd not found" > the syntax "<keyword> = <value>" has never been implemented in OpenLDAP software; the keyword "module" has never been supported as well. I suggest you read at least slapd.conf(5) (but I suspect you need to read more) before considering the possibility of a software bug. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4737) "overlay not found"
by Kurt＠OpenLDAP.org 07 Nov '06

07 Nov '06

At 09:19 AM 11/7/2006, mmollet(a)westar.com wrote: >Full_Name: Matthieu Mollet >Version: 2.2.13 >OS: Centos 4 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (208.45.242.10) > > >Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that >comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd >slapd fails with "overlay smbk5pwd not found" While there is no indication that this behavior is due to a bug in OpenLDAP Software and 2.2 is Historic, there seems this report should be closed. If you believe this behavior due to a bug in OpenLDAP Software, I suggest you duplicate it in the latest 2.3 release and then file a new bug report that elaborates on why you believe the behavior is due to a bug in OpenLDAP Software.

1 0

(ITS#4737) "overlay not found"
by mmollet＠westar.com 07 Nov '06

07 Nov '06

Full_Name: Matthieu Mollet Version: 2.2.13 OS: Centos 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.45.242.10) Built the smbk5pwd.la overlay and installed it with the 2.2.13 openldap that comes with Centos. Added module = pathto/smbk5pwd.la and overlay = smbk5pwd slapd fails with "overlay smbk5pwd not found"

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 06 Nov '06

06 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. I've sync'd the connection manager in RE23 with HEAD. Please test RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4736) writewaiter == 1 in connection_destroy
by hyc＠symas.com 06 Nov '06

06 Nov '06

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: 2.3.28 > OS: Solaris 9 > URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt > Submission from: (NULL) (68.196.250.61) > > > 822 assert( c->c_writewaiter == 0); > > Unfortunately writewaiter == 1, the assertion catches, byebye... > > This happened earlier with 2.3.27 (see > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt > advised upgrading to 2.3.28, which was running when this caught today. See > https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the > 2.3.28 trace, not that it looks all too different. There have been no changes to the connection management since 2.3.27, so it makes sense that the traces look the same. A number of fixes have gone into HEAD along these lines, but they haven't been backported to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4736) writewaiter == 1 in connection_destroy
by richton＠nbcs.rutgers.edu 06 Nov '06

06 Nov '06

Full_Name: Aaron Richton Version: 2.3.28 OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt Submission from: (NULL) (68.196.250.61) 822 assert( c->c_writewaiter == 0); Unfortunately writewaiter == 1, the assertion catches, byebye... This happened earlier with 2.3.27 (see https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt). Kurt advised upgrading to 2.3.28, which was running when this caught today. See https://www.nbcs.rutgers.edu/~richton/richton-20061106-backtrace.txt for the 2.3.28 trace, not that it looks all too different.

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 06 Nov '06

06 Nov '06

--On Tuesday, November 07, 2006 12:35 AM +0000 quanah(a)stanford.edu wrote: > I've finally figured out how to reproduce this -- The problem is related > to the log purging done by access log. Here is what I did: After applying the commit to HEAD to my source, behavior after log purge was correct. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4704) accesslog database fails to store contextCSN at shutdown
by quanah＠stanford.edu 06 Nov '06

06 Nov '06

I've finally figured out how to reproduce this -- The problem is related to the log purging done by access log. Here is what I did: Make changes to the database, that were replicated. Everything is happy. Shut down slapd, modify the logpurge parameter so that log purging is done. Restart slapd Verified that log purging was done, and that everything was still happily in sync. Stop slapd, restart slapd Now the access log DB has generated a new CSN that is in the future of the suffix stored CSN. So it appears that somehow the logpurge operation either causes a new contextCSN to be written at the time the server is shut down, or it erases the contextCSN held by the accesslog db. Now, this is when I restarted slapd: Nov 6 16:27:14 ldap-dev0 slapd[27400]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd However, the contextCSN that was generated is: contextCSN: 20061107002625Z#000000#00#000000 This matches the time at which I started slapd when log purging was run: Nov 6 16:26:25 ldap-dev0 slapd[27385]: @(#) $OpenLDAP: slapd 2.3.28 (Oct 26 2006 13:41:27) $ ^Iquanah@ldap-uat00.stanford.edu:/usr/local/build/openldap-2.3.28/servers/slapd so I'd say that when log purge is run, it resets the contextCSN in the accesslog DB to the time at which slapd last started... --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4734) Segmentation fault
by hyc＠symas.com 06 Nov '06

06 Nov '06

Christopher Moore wrote: >> This trace indicates that an attribute in the given entry had NULL for >> its AttributeDescription, which is pretty much a "this-can't-happen" >> situation. It would probably be useful to look at the contents of the >> Entry e in frame 2, and all of its attributes. How was this database >> created, how was the entry created? >> > > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the > database was created by open-xchange. > Here is entry e in frame 2. I hope this is what you are after: > (gdb) frame 2 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > 797 for(a = attrs_find( e->e_attrs, desc ); > (gdb) print *e > $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 > "c=open-xchange,dc=org"}, > e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, > e_ocflags = 0, e_bv = { > bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, > e_private = 0x8265e90} > (gdb) Apparently you are using the OpenLDAP 2.2 database files with OpenLDAP 2.3. This is not supported since the database format changed between 2.2 and 2.3; you have to export with 2.2 slapcat and import with 2.3 slapadd as described in the docs on upgrading. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

RE: (ITS#4734) Segmentation fault
by chris＠linuxepos.com 06 Nov '06

06 Nov '06

> chris(a)linuxepos.com wrote: > > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { > > (gdb) where > > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > > #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 > > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) > at > > filterentry.c:797 > > #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:853 > > #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:355 > > #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at > search.c:217 > > #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) > at > > connection.c:1307 > > #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at > tpool.c:478 > > #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 > > #9 0x4038d4a7 in __clone () from /lib/libc.so.6 > > (gdb) > > This trace indicates that an attribute in the given entry had NULL for > its AttributeDescription, which is pretty much a "this-can't-happen" > situation. It would probably be useful to look at the contents of the > Entry e in frame 2, and all of its attributes. How was this database > created, how was the entry created? > I forgot to mention that I have just upgraded from Openldap 2.2.23 and the database was created by open-xchange. Here is entry e in frame 2. I hope this is what you are after: (gdb) frame 2 #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at filterentry.c:797 797 for(a = attrs_find( e->e_attrs, desc ); (gdb) print *e $1 = {e_id = 16777216, e_name = {bv_len = 100, bv_val = 0x8265ef5 "c=open-xchange,dc=org"}, e_nname = {bv_len = 103, bv_val = 0x8265f5b "e"}, e_attrs = 0x8266168, e_ocflags = 0, e_bv = { bv_len = 585, bv_val = 0x8265ef0 "\202\001è\026dc=open-xchange,dc=org"}, e_private = 0x8265e90} (gdb) _________________________________________________________________________________ Scanned by an Igaware Box - protecting computers from viruses, spam, spyware and other Internet junk. For more information visit http://www.igaware.com/security.html _________________________________________________________________________________

1 0

Re: (ITS#4735) configure choice of ODBC
by ando＠sys-net.it 06 Nov '06

06 Nov '06

rk(a)owen.sj.ca.us wrote: > Full_Name: R.K. Owen > Version: HEAD > OS: linux > URL: ftp://ftp.openldap.org/incoming/rkowen-061106.patch > Submission from: (NULL) (66.87.79.68) > > > When using the back-sql with the Oracle XE DB, the Oracle ODBC library > libsqora.so.10.1 was designed to be linked against the unixODBC interface > library instead of the iODBC interface library. This can be demonstrated by > using the unixODBC isql tool which will allow successful interactive querying > of the Oracle DB. However, when trying to start up the slapd daemon with 'slapd > -d 1' the daemon will quit with an error claiming: > Message: [iODBC][Driver Manager] > /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: > undefined symbol: bcuMsgBoxError > > The cause for this is that the configure script will first search for iodbc, > then odbc, and thus cause slapd to be built against the iodbc library. > By adding the -with-odbc option the configure script will allow the > administrator to choose which library to use in a flexible way: > > --with-odbc=iodbc # current default (-liodbc) > --with-odbc=odbc # try -lodbc > --with-odbc=/usr/lib/libodbc.so.1 # link against the shared object library > > The changes have been made to the source configure.in file and uploaded as a > patch. > > The patch is not acceptable, since it requires to specify the desired OBDC support, which is counter-intuitive, as most of the RDBMS have drivers or allow to use drivers for both implementations of ODBC. However, your need is clear. I've designed a different fix, which requires to set --with-odbc to the preferred sequence of ODBCs to try (iodbc | unixodbc), while the default (auto) tries the original sequence. It is now committed to HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4735) configure choice of ODBC
by rk＠owen.sj.ca.us 06 Nov '06

06 Nov '06

Full_Name: R.K. Owen Version: HEAD OS: linux URL: ftp://ftp.openldap.org/incoming/rkowen-061106.patch Submission from: (NULL) (66.87.79.68) When using the back-sql with the Oracle XE DB, the Oracle ODBC library libsqora.so.10.1 was designed to be linked against the unixODBC interface library instead of the iODBC interface library. This can be demonstrated by using the unixODBC isql tool which will allow successful interactive querying of the Oracle DB. However, when trying to start up the slapd daemon with 'slapd -d 1' the daemon will quit with an error claiming: Message: [iODBC][Driver Manager] /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: undefined symbol: bcuMsgBoxError The cause for this is that the configure script will first search for iodbc, then odbc, and thus cause slapd to be built against the iodbc library. By adding the -with-odbc option the configure script will allow the administrator to choose which library to use in a flexible way: --with-odbc=iodbc # current default (-liodbc) --with-odbc=odbc # try -lodbc --with-odbc=/usr/lib/libodbc.so.1 # link against the shared object library The changes have been made to the source configure.in file and uploaded as a patch.

1 0

Re: (ITS#4734) Segmentation fault
by hyc＠symas.com 06 Nov '06

06 Nov '06

chris(a)linuxepos.com wrote: > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { > (gdb) where > #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 > #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 > #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at > filterentry.c:797 > #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:853 > #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:355 > #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:217 > #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) at > connection.c:1307 > #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at tpool.c:478 > #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 > #9 0x4038d4a7 in __clone () from /lib/libc.so.6 > (gdb) This trace indicates that an attribute in the given entry had NULL for its AttributeDescription, which is pretty much a "this-can't-happen" situation. It would probably be useful to look at the contents of the Entry e in frame 2, and all of its attributes. How was this database created, how was the entry created? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4734) Segmentation fault
by chris＠linuxepos.com 06 Nov '06

06 Nov '06

Full_Name: Christopher Moore Version: 2.3.27 OS: Linux 2.4.31 URL: Submission from: (NULL) (62.49.7.243) Hi, I'm recieving a repeatable Segmentation fault when I try to connect to the ldap server as indicated with this excerpt of gdb trace: Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.3/lib/libdb-4.3.so Reading symbols from /usr/local/lib/libsasl2.so.2...done. Loaded symbols for /usr/local/lib/libsasl2.so.2 Reading symbols from /usr/local/lib/libssl.so.0.9.7...done. Loaded symbols for /usr/local/lib/libssl.so.0.9.7 Reading symbols from /usr/local/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/local/lib/libcrypto.so.0.9.7 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/local/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/local/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/local/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/local/lib/sasl2/libotp.so.2...done. Loaded symbols for /usr/lib/sasl2/libotp.so.2 Reading symbols from /usr/local/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/local/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/local/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 489 for ( a = sub->ad_type; a; a=a->sat_sup ) { (gdb) where #0 is_ad_subtype (sub=0x0, super=0x81eafb0) at ad.c:489 #1 0x0806952e in attrs_find (a=0x8266168, desc=0x81eafb0) at attr.c:347 #2 0x0807e491 in test_filter (op=0x8265c88, e=0x8266140, f=0x40d3b14c) at filterentry.c:797 #3 0x080c83cf in bdb_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:853 #4 0x080632b9 in fe_op_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:355 #5 0x08062a44 in do_search (op=0x8265c88, rs=0x40d3a8bc) at search.c:217 #6 0x08061218 in connection_operation (ctx=0x40d3a93c, arg_v=0x8265c88) at connection.c:1307 #7 0x08133ff8 in ldap_int_thread_pool_wrapper (xpool=0x81f1558) at tpool.c:478 #8 0x40263d70 in pthread_start_thread (arg=0x40d3abe0) at manager.c:301 #9 0x4038d4a7 in __clone () from /lib/libc.so.6 (gdb)

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by ghenry＠suretecsystems.com 05 Nov '06

05 Nov '06

<quote who="daveh(a)ci.com.au"> >> Do you mind if I do some clean up on it? >> >> Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and >> assumptions been made with opening files and system commands etc. > > You might also highlight the fact that it seems to require at least 5.8 > (due to the "qw()" lists). Well, according to the method I always use to check that, Perl::MinimumVersion, we get: perlver ldap-stats.pl -------------------------------------------- | file | explicit | syntax | external | | -------------------------------------------- | | ldap-stats.pl | ~ | v5.6.0 | n/a | | -------------------------------------------- | | Minimum explicit version : ~ | | Minimum syntax version : v5.6.0 | | Minimum version of perl : v5.6.0 | -------------------------------------------- > > I also don't like hard-wiring "/usr/bin/perl", as the system Perls are > rarely up to date. My favourite technique is: > > #! /usr/bin/env perl -w > > which finds Perl from $PATH. > > Or just hard-wire "/usr/local/bin/perl" and let the sysadmin sort it > out... Sounds good. env method is best I suppose, but there are others as listed at: http://perldoc.perl.org/perlrun.html#DESCRIPTION Almost finished that cleanup. It's taken a bit longer than expected. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

RE: (ITS#3460) Adding LDAP statistics script to contrib directory
by daveh＠ci.com.au 05 Nov '06

05 Nov '06

> Do you mind if I do some clean up on it? > > Mainly Perl::Critic and Perl::Tidy. There's a few tests missing and > assumptions been made with opening files and system commands etc. You might also highlight the fact that it seems to require at least 5.8 (due to the "qw()" lists). I also don't like hard-wiring "/usr/bin/perl", as the system Perls are rarely up to date. My favourite technique is: #! /usr/bin/env perl -w which finds Perl from $PATH. Or just hard-wire "/usr/local/bin/perl" and let the sysadmin sort it out... -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

(ITS#4733) back-config should populate defaults
by hyc＠OpenLDAP.org 05 Nov '06

05 Nov '06

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc If a minimal LDIF is slapadd'd to create the slapd configuration, any parameters that are not specified on input will take on their default values. However, these defaults will not be present in the config entries and will not be visible upon subsequent slapcat/ldapsearch. It would be nicer if after each entry is loaded from slapd.d and parsed, the entire entry is regenerated internally, with all defaults populated.

1 0

Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com 05 Nov '06

05 Nov '06

It seems you can close this ITS. I followed Howard's advice and started over with a new CVS working dir. Ciao, Michael.

1 0

Re: (ITS#4731) Build without modules fails
by michael＠stroeder.com 05 Nov '06

05 Nov '06

Howard Chu wrote: > A fresh pull (as of 2 minutes ago) builds fine for me. > > If the problem you're running into is that distclean left something from > your previous build, then you need to tell us what your previous build > invocation was as well. > > I suggest you try building with a separate object directory, so that you > can just rm -rf the object tree when you want a fresh build. Ok, it seems the build worked with a fresh CVS working dir. You can close this ITS. I'll file another one for make distclean though... Ciao, Michael.

1 0

Re: (ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 04 Nov '06

04 Nov '06

Still coring in 2.3.28 + connection code from HEAD. Backtrace: (gdb) info threads 10 process 25180 0x00002ae257d12e2c in pthread_join () from /lib/libpthread.so.0 9 process 25184 0x00002ae257ef2b2c in epoll_wait () from /lib/libc.so.6 8 process 25186 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 25188 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 25189 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 25190 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 25212 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 25213 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 25216 0x00002ae257d144e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 25185 0x00002ae257ed27dd in fnmatch () from /lib/libc.so.6 (gdb) thread 1 [Switching to thread 1 (process 25185)]#7 0x00000000004457f6 in slap_acl_get (a=Variable "a" is not available. ) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) bt #0 0x00002ae257ed27dd in fnmatch () from /lib/libc.so.6 #1 0x00002ae257eddd22 in re_exec () from /lib/libc.so.6 #2 0x00002ae257edb70b in re_exec () from /lib/libc.so.6 #3 0x00002ae257ed9d83 in re_exec () from /lib/libc.so.6 #4 0x00002ae257ed8526 in re_exec () from /lib/libc.so.6 #5 0x00002ae257ed7e83 in re_exec () from /lib/libc.so.6 #6 0x00002ae257ed74a6 in regexec () from /lib/libc.so.6 #7 0x00000000004457f6 in slap_acl_get (a=Variable "a" is not available. ) at acl.c:874 #8 0x0000000000445eb3 in slap_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:221 #9 0x0000000000447dd1 in fe_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:318 #10 0x0000000000444620 in access_allowed_mask (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x0) at acl.c:429 #11 0x00000000004356f1 in slap_send_search_entry (op=0x2aaaab0e03c8, rs=0x40ffeee0) at result.c:894 #12 0x00002ae2596f4894 in hdb_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:878 #13 0x0000000000429502 in fe_op_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:355 #14 0x0000000000429d42 in do_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:217 #15 0x0000000000427a0f in connection_operation (ctx=Variable "ctx" is not available. ) at connection.c:1109 #16 0x0000000000427dd4 in connection_read_thread (ctx=0x40fff030, argv=Variable "argv" is not available. ) at connection.c:1236 (gdb) frame 7 #7 0x00000000004457f6 in slap_acl_get (a=Variable "a" is not available. ) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) frame 8 #8 0x0000000000445eb3 in slap_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:221 221 while ( ( a = slap_acl_get( a, &count, op, e, desc, val, (gdb) frame 9 #9 0x0000000000447dd1 in fe_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:318 318 rc = slap_access_allowed( op, e, desc, val, access, state, maskp ); (gdb) frame 10 #10 0x0000000000444620 in access_allowed_mask (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x0) at acl.c:429 429 ret = frontendDB->bd_info->bi_access_allowed( op, e, (gdb) frame 11 #11 0x00000000004356f1 in slap_send_search_entry (op=0x2aaaab0e03c8, rs=0x40ffeee0) at result.c:894 894 if ( ! access_allowed( op, rs->sr_entry, (gdb) frame 12 #12 0x00002ae2596f4894 in hdb_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:878 878 rs->sr_err = send_search_entry( op, rs ); (gdb) frame 13 #13 0x0000000000429502 in fe_op_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:355 355 (op->o_bd->be_search)( op, rs ); (gdb) frame 14 #14 0x0000000000429d42 in do_search (op=0x2aaaab0e03c8, rs=0x40ffeee0) at search.c:217 217 rs->sr_err = frontendDB->be_search( op, rs ); (gdb) frame 15 #15 0x0000000000427a0f in connection_operation (ctx=Variable "ctx" is not available. ) at connection.c:1109 1109 rc = (*(opfun[opidx]))( op, &rs ); (gdb) frame 16 #16 0x0000000000427dd4 in connection_read_thread (ctx=0x40fff030, argv=Variable "argv" is not available. ) at connection.c:1236 1236 rc = (long)connection_operation( ctx, cri.op ); (gdb) frame 17 #17 0x00002ae2572c5724 in ldap_int_thread_pool_wrapper (xpool=0x2ae258ac0080) at tpool.c:478 478 ctx->ltc_start_routine(ltc_key, ctx->ltc_arg); (gdb) frame 8 #8 0x0000000000445eb3 in slap_access_allowed (op=0x2aaaab0e03c8, e=0x2ae359f442c8, desc=0x2ae2586e3d88, val=0x2aaab6d68fb8, access=ACL_READ, state=0x40e7d500, maskp=0x40e7d448) at acl.c:221 221 while ( ( a = slap_acl_get( a, &count, op, e, desc, val, (gdb) print *a $2 = {acl_filter = 0x0, acl_dn_style = ACL_STYLE_CHILDREN, acl_dn_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_dn_pat = { bv_len = 18, bv_val = 0x2ae2586ce858 "dc=stanford,dc=edu"}, acl_attrs = 0x2ae258640080, acl_attrval_mr = 0x0, acl_attrval_style = ACL_STYLE_REGEX, acl_attrval_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_attrval = {bv_len = 0, bv_val = 0x0}, acl_access = 0x2ae258ae9e20, acl_next = 0x2ae258ac55c0} --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4732) slapd.d man page missing
by hyc＠symas.com 03 Nov '06

03 Nov '06

This is already ITS#3812. This ITS will be closed as a dup. ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Not listed at: > > http://www.openldap.org/software/man.cgi?query=(5)&sektion=&apropos=1&manpa… > > As mentioned at: > > http://www.openldap.org/doc/admin23/slapdconf2.html > > Thanks. > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4732) slapd.d man page missing
by ghenry＠suretecsystems.com 03 Nov '06

03 Nov '06

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Not listed at: http://www.openldap.org/software/man.cgi?query=(5)&sektion=&apropos=1&manpa… As mentioned at: http://www.openldap.org/doc/admin23/slapdconf2.html Thanks.

1 0

Re: (ITS#4731) Build without modules fails
by hyc＠symas.com 03 Nov '06

03 Nov '06

A fresh pull (as of 2 minutes ago) builds fine for me. If the problem you're running into is that distclean left something from your previous build, then you need to tell us what your previous build invocation was as well. I suggest you try building with a separate object directory, so that you can just rm -rf the object tree when you want a fresh build. e.g. mkdir head cd head cvs co ... cd .. mkdir obj cd obj ../head/configure ... make depend; make Personally I have never used "make distclean" ... michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: SuSE Linux 10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.30.198) > > > I tried to build without modules (after make distclean): > > ./configure \ > --prefix=${PREFIX} \ > --enable-dynamic \ > --enable-modules=no \ > --enable-backends=yes \ > --enable-overlays=yes \ > --enable-cleartext \ > --enable-crypt=yes \ > --enable-debug=yes \ > --enable-kpasswd=yes \ > --enable-lmpasswd=yes \ > --enable-rewrite=yes \ > --enable-rlookups=yes \ > --enable-slapi=yes \ > --enable-slp=yes \ > --enable-spasswd=yes \ > --enable-wrappers=no \ > --enable-aci=yes \ > --with-cyrus-sasl=yes \ > --with-kerberos=yes \ > --with-readline=yes \ > --with-threads=yes \ > --with-tls=yes > > > But build fails: > > cc -g -O0 -I../../../include -I../../../include -I.. -I./.. -I./../slapi > -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c version.c > -o version.o > ar ruv libback_monitor.a `echo init.lo search.lo compare.lo modify.lo bind.lo > operational.lo cache.lo entry.lo backend.lo database.lo thread.lo conn.lo rww.lo > log.lo operation.lo sent.lo listener.lo time.lo overlay.lo | sed 's/\.lo/.o/g'` > version.o > ar: creating libback_monitor.a > ar: init.o: No such file or directory > make[3]: *** [libback_monitor.a] Error 1 > make[3]: Leaving directory > `/home/michael/src/openldap-HEAD/ldap/servers/slapd/back-monitor' > make[2]: *** [.backend] Error 1 > make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers' > make: *** [all-common] Error 1 > > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4731) Build without modules fails
by michael＠stroeder.com 03 Nov '06

03 Nov '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.30.198) I tried to build without modules (after make distclean): ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-modules=no \ --enable-backends=yes \ --enable-overlays=yes \ --enable-cleartext \ --enable-crypt=yes \ --enable-debug=yes \ --enable-kpasswd=yes \ --enable-lmpasswd=yes \ --enable-rewrite=yes \ --enable-rlookups=yes \ --enable-slapi=yes \ --enable-slp=yes \ --enable-spasswd=yes \ --enable-wrappers=no \ --enable-aci=yes \ --with-cyrus-sasl=yes \ --with-kerberos=yes \ --with-readline=yes \ --with-threads=yes \ --with-tls=yes But build fails: cc -g -O0 -I../../../include -I../../../include -I.. -I./.. -I./../slapi -I/opt/bdb-4.5/include -I/opt/sasl/include -I/opt/heimdal/include -c version.c -o version.o ar ruv libback_monitor.a `echo init.lo search.lo compare.lo modify.lo bind.lo operational.lo cache.lo entry.lo backend.lo database.lo thread.lo conn.lo rww.lo log.lo operation.lo sent.lo listener.lo time.lo overlay.lo | sed 's/\.lo/.o/g'` version.o ar: creating libback_monitor.a ar: init.o: No such file or directory make[3]: *** [libback_monitor.a] Error 1 make[3]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd/back-monitor' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/servers' make: *** [all-common] Error 1

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by peter＠adpm.de 03 Nov '06

03 Nov '06

Hi, On Thursday, 2. November 2006 20:42, Quanah Gibson-Mount wrote: > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release > for the work you've done with this script? :) Granted ! Peter -- Peter Marschall peter(a)adpm.de

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs