- openldap-bugs - openldap.org

(ITS#4952) null CSN due to CSN length mismatch in updateCookie
by donn＠u.washington.edu 09 May '07

09 May '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) syncrepl_updateCookie finds CSN values in syncCookie and si->si_cookieState. Numerically, the syncCookie CSN is lesser, but it compares greater because it's longer: syncCookie->ctxcsn: 20070508130333Z#000000#00#000000 si->si_cookieState->cs_vals[0]: 20070507215402.502403Z#000000#000#000000 Eventually slap_queue_csn() gets a null CSN, and slapd aborts. I am pretty sure the former explains the latter. The only thing that doesn't fit is that gdb reports "j" == 20936000, where I expect 0, but I think everything else adds up - numcsns is 1, cs_num is 1, the two sids are the same (0). Evidently this format difference is entryCSN vs. contextCSN. The unusual order may be due to entries modified in the master with explicit entryCSN values. I guess that's not supported, but it seems to have exposed a bug here - I assume you want a comparison between dates, not format lengths. To reproduce (I'm guessing): modify master directory with explicit entryCSN values that are later than its contextCSN.

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

Actually, tpool.c is quite buggy. I'm fixing some of them, and will summarize the rest later. -- Regards, Hallvard

1 0

Re: (ITS#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

I wrote: > That said, it's indeed a reasonable cleanup. I'll do that and some > others shortly. Fixed in the cvs HEAD version. There are a few cases left though - in particular, do anyone know if #if DOS/MACOS/HAVE_WINSOCK can be replaced with #ifdef? I'm not touching them without word from someone who knows OpenLDAP on these platforms. Besides, I still don't know if the "issues" you refer to are just compiler warnings, or errors - or if the one macro you reported was a special case. So while allowing -Wundef to catch macro typos is worthwhile, I likely won't do anything more unless I hear a reason to. And I'd like to know what Plan 9 C says about this program: > BTW, will 9 C accept this (when you do not define FOO/BAR)? What > error/warning messages, if any? > > #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ > int main() { return 2; } > #elif BAR > int main() { return 1; } > #else > int main() { return 0; } > #endif -- Regards, Hallvard

1 0

Re: (ITS#4937) chain overlay bugs with Statslog & ldbm/ldif databases
by h.b.furuseth＠usit.uio.no 09 May '07

09 May '07

hyc(a)symas.com writes: > This seems to be a known limitation, see the FIXME in slapd/compare.c, > near SLAP_COMPARE_IN_FRONTEND. At least, that explains the problem > for back-ldif, which does not provide its own compare entry point. Looks like a bug to me, and that the correct fix is be to delete that code and let the current back-ldif return an error. Maybe it could be split out to a separate function which backends can set be_compare to if they have a be_attribute(), or something like that? > As for back-ldbm, there is a missing referral_rewrite call in > back-ldbm/referral.c. I don't consider it worthwhile to fix back-ldbm, > but you're welcome to fix it if you wish. I might, though actually I'm more concerned with failed tests than fixing ldbm at the moment:-) Will look later. However: > Just have a look at back-bdb/referral.c for the correct code. There is no correct code as yet, note the bogus logging I mentioned. -- Regards, Hallvard

1 0

(ITS#4951) [contrib] RADIUS password module fixes
by richton＠nbcs.rutgers.edu 09 May '07

09 May '07

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: https://www.nbcs.rutgers.edu/~richton/richton-20070508-radius.patch Submission from: (NULL) (68.196.250.105) Please find at this address a patch against the RADIUS contrib module. This patch addresses two issues: * libradius makes use of MT-Unsafe calls, so a protecting mutex is added. * config_filename could be passed to rad_config without initialization (when accepting the default). I, Aaron Richton, hereby place these modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 08 May '07

08 May '07

On Tue, May 08, 2007 at 08:42:24PM +0200, Pierangelo Masarati wrote: > ahasenack(a)terra.com.br wrote: > > > The monitor backend attributes and object classes, when loaded, should also be > > exported in the subschema entries at the server. > > > > I know of one ldap client that breaks because of this: luma. It says it can't > > display the cn=monitor entries because it doesn't know the object classes or > > attributes. I guess it uses this info to determine how to show each entry. > > The schema is not exposed since it's considered experimental. To expose > it, you need to #define LDAP_DEVEL. It doesn't see a good idea for me to define LDAP_DEVEL just to get this schema published: probably many other things in openldap would change.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by ando＠sys-net.it 08 May '07

08 May '07

ahasenack(a)terra.com.br wrote: > The monitor backend attributes and object classes, when loaded, should also be > exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it can't > display the cn=monitor entries because it doesn't know the object classes or > attributes. I guess it uses this info to determine how to show each entry. The schema is not exposed since it's considered experimental. To expose it, you need to #define LDAP_DEVEL. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 07 May '07

07 May '07

On Fri, 4 May 2007, hyc(a)symas.com wrote: >> Either the conversion should put all of the loglevel masks in the same >> olcLogLevel value or cn=config should AND all of the olcLogLevel values. > > You mean OR of course, not AND. Yes, sorry. OR, +, mask, that's what I mean. It must have been Friday. -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

1 0

Re: (ITS#4950) error LDAP Server
by quanah＠zimbra.com 07 May '07

07 May '07

--On Monday, May 07, 2007 11:03 AM +0000 thuanpvm(a)blitzgrp.com wrote: > Full_Name: Phan Van Minh Thuan > Version: 2.3.35 > OS: Linux Enterprise 4.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (58.186.92.53) > > > Dear Sirs, > > When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W > -f /usr/local/etc/openldap/schema/initial.ldif, the error display: > Enter LDAP password: > ldap_bin: Can't contact LDAP server (-1) > > Looking forward to hearing from you soon The ITS system is for submitting bugs about the software. You appear to be having a configuration/usage problem. Please subscribe to openldap-software(a)openldap.org and describe the problems you are having there. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4950) error LDAP Server
by thuanpvm＠blitzgrp.com 07 May '07

07 May '07

Full_Name: Phan Van Minh Thuan Version: 2.3.35 OS: Linux Enterprise 4.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (58.186.92.53) Dear Sirs, When I submit ldapadd -x -D "cn=Manager, dc=blitzcie,dc=dyndns,dc=org" -W -f /usr/local/etc/openldap/schema/initial.ldif, the error display: Enter LDAP password: ldap_bin: Can't contact LDAP server (-1) Looking forward to hearing from you soon Many Thanks. Thuan

1 0

Re: (ITS#4933) syncrepl unlimited timeout vs. .ldaprc
by hyc＠symas.com 05 May '07

05 May '07

donn(a)u.washington.edu wrote: > Full_Name: Donn Cave > Version: 2.4.4 > OS: Red Hat RHEL 3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.95.135.150) > > > Appears to me that unless timelimit value passed to ldap_search_ext() is > positive, the ld_timelimit from .ldaprc overrides, so there's no way for > syncrepl ldap_sync_search() to literally specify "unlimited". > > To duplicate: configure syncrepl timelimit=unlimited; edit /.ldaprc -> > "TIMELIMIT 23"; start replica slapd with a sufficiently large replication > backlog; observe timeout at 23 seconds. > > To kludge: use extravagantly large value instead: if (si->si_tlimit > 0) > timeout.tv_sec = si->tlimit; else timeout.tv_sec = 31536000; > > and pass &timeout unconditionally. Hmmm. I guess this is a consequence of changing the timeout representation in the LDAP handle. I suppose we can just make the syncrepl consumer do an explicit ldap_set_option() on its session handles to override any .ldaprc setting. Will have to play with this a bit to see how we can maintain backward compatibility. -- -- Howard Chu Chief Architect, 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#4948) #if/#elif argument in .../include/ac/time.h
by h.b.furuseth＠usit.uio.no 05 May '07

05 May '07

lucio(a)proxima.alt.za writes: > Whether the existing format is legitimate or not is a matter for the C > standards, but I believe that the alternative would be both clearer > and more portable. It's legitimate. In #if/#elif statements, an undefined macro (without arguments) has the value 0 in a correct compiler. That said, it's indeed a reasonable cleanup. I'll do that and some others shortly. Allows us to compile with 'gcc -Wundef' without too much noise too. I'll tests I'm not sure about alone (in particular Windows stuff), in case it's supposed to be OK to compile with '-D<macro name>=0' so a change from #if to #ifdef would change OpenLDAP's behavior. Maybe someone else can have a look at that. > The Plan 9 C pre-processor has a definite issue with it and it seems a > reasonable change to implement. There may be other places where a > similar change would be beneficial, I'll identify them as I > encountered and will provide a comprehensive list on demand. Please be specific: Give the exact error/warning message, and make clear whether it _is_ a warning or an error. BTW, will 9 C accept this (when you do not define FOO/BAR)? What error/warning messages, if any? #if defined(FOO) && FOO /* Guard #if FOO with defined(FOO) */ int main() { return 2; } #elif BAR int main() { return 1; } #else int main() { return 0; } #endif -- Regards, Hallvard

1 0

Re: (ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by hyc＠symas.com 05 May '07

05 May '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.35 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.93.52) > > > When a slapd.conf file is converted to cn=config with -f and -F the loglevel > parameter gets converted into multiple olcLogLevel=keyword attribute/value > pairs. However, only the last one in the configuration seems to apply. > Manually updating > dn: cn=config > changetype: modify > replace: olcLogLevel > olcLogLevel: keyword1 keyword2 ... > - > > gets the intended logging behavior. > > Either the conversion should put all of the loglevel masks in the same > olcLogLevel value or cn=config should AND all of the olcLogLevel values. You mean OR of course, not AND. Yes, the code only does ORs correctly when multiple levels are set at once. Oops. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 04 May '07

04 May '07

Full_Name: Eric Irrgang Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.93.52) When a slapd.conf file is converted to cn=config with -f and -F the loglevel parameter gets converted into multiple olcLogLevel=keyword attribute/value pairs. However, only the last one in the configuration seems to apply. Manually updating dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: keyword1 keyword2 ... - gets the intended logging behavior. Either the conversion should put all of the loglevel masks in the same olcLogLevel value or cn=config should AND all of the olcLogLevel values.

1 0

(ITS#4948) #if/#elif argument in .../include/ac/time.h
by lucio＠proxima.alt.za 04 May '07

04 May '07

Full_Name: Lucio De Re Version: 2.3.35 and earlier OS: Plan 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.255.250) The arguments on lines 20 and 23 (#if and #elif, respectively) in .../include/ac/time.h ought to be surrounded with "defined()". Whether the existing format is legitimate or not is a matter for the C standards, but I believe that the alternative would be both clearer and more portable. The Plan 9 C pre-processor has a definite issue with it and it seems a reasonable change to implement. There may be other places where a similar change would be beneficial, I'll identify them as I encountered and will provide a comprehensive list on demand. Naturally, there are many other issues applicable specific to porting OpenLDAP to Plan 9, but these seem trivial enough to warrant addressing in a broader context.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by quanah＠zimbra.com 04 May '07

04 May '07

--On Friday, May 04, 2007 2:39 PM +0000 ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > (enhancement, or minor) > > The monitor backend attributes and object classes, when loaded, should > also be exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it > can't display the cn=monitor entries because it doesn't know the object > classes or attributes. I guess it uses this info to determine how to show > each entry. Not disagreeing, but making the assumption that cn=subschema is readable is also a broken behavior on the luma side. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 04 May '07

04 May '07

Full_Name: Andreas Hasenack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) (enhancement, or minor) The monitor backend attributes and object classes, when loaded, should also be exported in the subschema entries at the server. I know of one ldap client that breaks because of this: luma. It says it can't display the cn=monitor entries because it doesn't know the object classes or attributes. I guess it uses this info to determine how to show each entry.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by ghenry＠suretecsystems.com 04 May '07

04 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >>> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >>> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >>> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >>> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >>> symbol lookup error: >>> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >>> ldap_back_proxy_authz_ctrl >> >> Howard debugged this on IRC and it turns out that our (mine and >> _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd >> without the unixodbc lib fixes it. > > Yes, so there are two potential issues - the unixodbc shared library seems > to > be statically linked with an older version of libltdl. I didn't run into > this > problem on my build because I don't have that odbc library. Anyway, due to > the link order of the libraries, the lt_dlopen in this library gets used > before the linker resolves to the system's libltdl.so, and it seems that > this > version of lt_dlopen doesn't automatically export the symbols of modules > that > it loads. > > I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is > because there is a new dependency in 2.3.33 between back-meta and > back-ldap. > > The other part of this is that the slapd binary should not be getting > linked > against -lodbc when back_sql is built as a module. > > Although, if back-sql is built statically, and other backends are dynamic, > this problem may still crop up. It seems that fixing -lodbc would be > required > then. I've hit this same problem tonight (no sql though): ./scripts/test030-relay: line 78: kill: (7779) - No such process >>>>> ./scripts/test030-relay failed (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make: *** [test] Error 2 slapd.1.log: /home/suretec/src/openldap-2.3.35/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Config options were: env CC=/usr/local/bin/gcc CPPFLAGS="-I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/include/sasl" \ LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/lib/sasl2" \ LIBS="-ldl" \ LD_LIBRARY_PATH="/usr/local/ssl/lib /usr/local/BerkeleyDB.4.2/lib /usr/local/lib/sasl2" ./configure \ --prefix=/usr/local --enable-slapd --enable-syslog \ --enable-dynamic --enable-rewrite --disable-sql --disable-ipv6 --disable-shell \ --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers On Debian Sarge 3.1 with custom compiled: openssl-0.9.8e cyrus-sasl-2.1.22 db-4.2.52 heimdal-0.8.1 I can't get past it. Any debug advice? 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

(ITS#4945) slapd drops connections during search results
by mhardin＠symas.com 03 May '07

03 May '07

Full_Name: Matthew Hardin Version: 2.3.35 OS: Windows 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.67.85) If Winsock returns EWOULDBLOCK while sending search results to a client, slapd will stop sending results and close the connection. The problem is in openldap/servers/slapd/result.c at line 173, where it incorrectly checks errno. It should be checking sock_errno(). I note that HEAD already does this.

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by hyc＠symas.com 03 May '07

03 May '07

Looks like your OpenSSL library depends on -ldl. That's an OpenSSL build problem, not OpenLDAP. Can probably get around it by adding -ldl to LIBS on the configure invocation. This ITS will be closed. ghenry(a)suretecsystems.com wrote: > <quote who="Howard Chu"> >> It works for me. Check your config.log to see why it didn't link. > > Here's the main probs: > > configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include > -I/usr/local/BerkeleyDB.4.2/include conftest.c > configure:19507: $? = 0 > configure:19527: result: yes > configure:19562: checking for openssl/ssl.h > configure:19569: result: yes > configure:19584: checking for SSL_library_init in -lssl > configure:19614: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lresolv >&5 > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function > `dlfcn_bind_func': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function > `dlfcn_bind_func': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function > `dlfcn_bind_var': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function > `dlfcn_bind_var': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function > `dlfcn_unload': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function > `dlfcn_load': > : undefined reference to `dlopen' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function > `dlfcn_load': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function > `dlfcn_load': > : undefined reference to `dlerror' > collect2: ld returned 1 exit status > configure:19620: $? = 1 > configure: failed program was: > | /* confdefs.h. * > > | char SSL_library_init (); > | int > | main () > | { > | SSL_library_init (); > | ; > | return 0; > | } > configure:19646: result: no > configure:19657: checking for ssl3_accept in -lssl > configure:19687: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lRSAglue -lrsaref -lresolv >&5 > /usr/bin/ld: cannot find -lRSAglue > collect2: ld returned 1 exit status > configure:19693: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > > > Like I said, this didn't happen in 0.9.7, will check my built options with > 0.9.8 > > Gavin. > > > -- -- Howard Chu Chief Architect, 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#4944) 2.3.35 and openssl-0.9.8e
by ghenry＠suretecsystems.com 03 May '07

03 May '07

<quote who="Howard Chu"> > It works for me. Check your config.log to see why it didn't link. Here's the main probs: configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include conftest.c configure:19507: $? = 0 configure:19527: result: yes configure:19562: checking for openssl/ssl.h configure:19569: result: yes configure:19584: checking for SSL_library_init in -lssl configure:19614: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lresolv >&5 /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function `dlfcn_bind_func': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function `dlfcn_unload': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function `dlfcn_load': : undefined reference to `dlerror' collect2: ld returned 1 exit status configure:19620: $? = 1 configure: failed program was: | /* confdefs.h. * | char SSL_library_init (); | int | main () | { | SSL_library_init (); | ; | return 0; | } configure:19646: result: no configure:19657: checking for ssl3_accept in -lssl configure:19687: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lRSAglue -lrsaref -lresolv >&5 /usr/bin/ld: cannot find -lRSAglue collect2: ld returned 1 exit status configure:19693: $? = 1 configure: failed program was: | /* confdefs.h. */ Like I said, this didn't happen in 0.9.7, will check my built options with 0.9.8 Gavin.

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by hyc＠symas.com 03 May '07

03 May '07

It works for me. Check your config.log to see why it didn't link. ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.35 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > Just a heads up to say I couldn't get 2.3.35 to compile with openssl 0.9.8e, > only latest 0.9.7m: > > env CC=gcc CPPFLAGS="-I/usr/local/ssl/include" \ > LDFLAGS="-L/usr/local/ssl/lib" \ > LD_LIBRARY_PATH="/usr/local/ssl/lib" ./configure \ > --prefix=/usr/local --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ > --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ > --disable-sql --with-threads --enable-modules --enable-backends=mod \ > --enable-overlays=mod --with-tls --enable-wrappers > > 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... no > checking for ssl3_accept in -lssl... no > checking OpenSSL library version (CRL checking capability)... yes > configure: error: Could not locate TLS/SSL package > > > You probably already know ;-) > > Gavin. > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4944) 2.3.35 and openssl-0.9.8e
by ghenry＠suretecsystems.com 03 May '07

03 May '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, Just a heads up to say I couldn't get 2.3.35 to compile with openssl 0.9.8e, only latest 0.9.7m: env CC=gcc CPPFLAGS="-I/usr/local/ssl/include" \ LDFLAGS="-L/usr/local/ssl/lib" \ LD_LIBRARY_PATH="/usr/local/ssl/lib" ./configure \ --prefix=/usr/local --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ --disable-sql --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers 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... no checking for ssl3_accept in -lssl... no checking OpenSSL library version (CRL checking capability)... yes configure: error: Could not locate TLS/SSL package You probably already know ;-) Gavin.

1 0

RE: (ITS#4934) Port change
by Babu.Suresh＠pacificlife.com 02 May '07

02 May '07

Thank you..this was resolved after I implemented ACL in slapd.conf. _babu -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Wednesday, May 02, 2007 9:20 AM To: Suresh, Babu; openldap-its(a)openldap.org Subject: Re: (ITS#4934) Port change --On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

Re: (ITS#4934) Port change
by quanah＠zimbra.com 02 May '07

02 May '07

--On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs