openldap-bugs May 2008

openldap-bugs@openldap.org

54 participants
208 discussions

Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com 07 May '08

07 May '08

raphael.ouazana(a)linagora.com wrote: > It is not really hung, it is more in an infinite loop. Nothing in this trace indicates a loop; all of the threads are in wait states. Is there anything in the logs that indicates a loop? -- -- 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#5500) comments in cn=config entries
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard One problem with back-config is that comments in slapd.conf are lost when converting to cn=config, and cn=config does not offer attributes in which to put comments. So I suggest: Add something like 'MAY ( description $ info )' to object class olcConfig, and slapd.conf keywords with the same name. description to describe the slapd entry, info for other notes about it. The slapd.conf keywords would allow admins to "upgrade" most comments in slapd.conf before converting to cn=config. They'll need to insert any context into the comments though, and preferably move frontend directives with comments in slapd.conf to an explicit frontend database. I think it'd be best if these attribute names do not have a prefix like "olc", so they'll stand out a bit from the rest. Thus the suggestion to stick to preexisting RFCed attributes. However the attribute for general notes ('info') should probably be treated as X-ORDERED 'VALUES', I haven't checked if it's inconvenient to do that with a preexisting attribute without that feature. The valsort overlay does, but I don' suggest to require valsort.

1 0

Re: (ITS#5499) slapd-perl man page
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

I wrote: > + * bind DN, or "" for anonymous bind Duh, sorry. Anonymous bind is handled by the frontend, of course. -- Hallvard

1 0

Re: (ITS#5499) slapd-perl man page
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Alexander.lelyakin(a)googlemail.com writes: > Man page slapd-perl does not contain ANY information on 'bind' method. Wow. That doc is 9 years old and you are the first to notice. Thanks for the report. > Also it is not clear: Is there any possibility for perl backend to get > connection information, for example IP addres of client (for > implementation own access control schemes). No. Except for Bind, what you see in the manpage is what you get. Also the manpage should mention LDIF format for Search entries. Like this, I think - but I (or someone) needs to test before committing. Index: doc/man/man5/slapd-perl.5 =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/doc/man/man5/slapd-perl.5,v retrieving revision 1.7 diff -u -2 -r1.7 doc/man/man5/slapd-perl.5 --- doc/man/man5/slapd-perl.5 4 Jul 2005 04:57:11 -0000 1.7 +++ doc/man/man5/slapd-perl.5 7 May 2008 17:01:30 -0000 @@ -24,4 +24,5 @@ .nf * new # creates a new object, + * bind # does a simple bind, * search # performs the ldap search, * compare # does a compare, @@ -52,4 +53,15 @@ method receives the class name as argument. .TP +.B bind +This method is called when the client requests a Simple Bind, +except Simple Bind as the rootdn when rootpw is set in slapd.conf. +Its arguments are as follows. +.nf + * object reference + * bind DN, or "" for anonymous bind + * password, or "" for no password +.fi +.LP +.TP .B search This method is called when a search request comes from a client. @@ -68,4 +80,8 @@ .LP Return value: (resultcode, ldif-entry, ldif-entry, ...) + +Each ldif-entry is a string starting with "dn:" in +.BR ldif (5) +format. .TP .B compare @@ -96,5 +112,5 @@ .nf * object reference - * entry in string format + * entry record in \fBldif\fP(5) string format .fi .LP @@ -187,3 +203,4 @@ .BR slapd.conf (5), .BR slapd (8), -.BR perl (1). +.BR perl (1), +.BR ldif (5). -- Hallvard

1 0

Re: (ITS#5497) back-sql with base64 encoded attributes
by h.b.furuseth＠usit.uio.no 07 May '08

07 May '08

Pavel Kislinger writes: > This is an imperfection of back-sql. It doesn't exist any way > how to say to slapd, which attributes are base64 encoded. No. base64 has nothing to do with attribute definitions, nor with anything else in LDAP except the LDIF file format. (Some backends make use of the LDIF format internally instead of a more efficient format. What you just said is that back-sql is not one of them.) So: > (...) It doesn't matter, no LDIF file is imported to back-sql. Exactly. Looks to me like you need to read up on LDAP and LDIF. E.g. the LDAP wikipedia article. Then, if you still have trouble, please take this to the openldap-software list. -- Hallvard

1 0

(ITS#5499) slapd-perl man page
by Alexander.lelyakin＠googlemail.com 07 May '08

07 May '08

Full_Name: Alexander Lelyakin Version: Any OS: linux URL: Submission from: (NULL) (141.52.232.84) Man page slapd-perl does not contain ANY information on 'bind' method. Also it is not clear: Is there any possibility for perl backend to get connection information, for example IP addres of client (for implementation own access control schemes).

1 0

Re: (ITS#5497) back-sql with base64 encoded attributes
by kislinger＠kn.vutbr.cz 07 May '08

07 May '08

This is an imperfection of back-sql. It doesn't exist any way how to say to slapd, which attributes are base64 encoded. Here are configuration files, that I am using. Look at "cn", "sn" attributes in "usi.sql" especialy. advanced schemas: http://printer.kn.vutbr.cz/~orim/dbmail.schema http://printer.kn.vutbr.cz/~orim/usi.schema SQL scripts http://printer.kn.vutbr.cz/~orim/ldap.sql backsql_create.sql http://printer.kn.vutbr.cz/~orim/usi.sql slapd.conf http://printer.kn.vutbr.cz/~orim/slapd.conf Hallvard B Furuseth napsal(a): > Please use the mailinglist (openldap-source and -technical) for > questions about using the software. This does not look like a bug, > which is what the ITS system is for. This ITS will be closed. > > Since I'm writing anyway though: > Textual attributes in LDAP are as UTF-8. I'm not sure what chacter > encoding you are using, but I assume it't something else. > utf-8 > As for base64, that's merely part of the LDIF file format, not how the > value is represented in LDAP (nor SQL I presume). The '::' after the > attribute names tells the client which reads the LDIF to base64-decode > the provided value. > > It doesn't matter, no LDIF file is imported to back-sql. Record are inserted into MySQL (4 metadata tables).

1 0

Re: (ITS#5498) "Issue Tracking" -> "Bugs" @ webpage
by Kurt＠OpenLDAP.org 07 May '08

07 May '08

On May 7, 2008, at 7:12 AM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > I suggest the "Issue Tracking" link on on http://www.openldap.org is > renamed to "Bugs" or "Bugs/patches". A user problem is after all an > "issue" too, and obviously they don't all read the text in later text > about what kind of issues ITS is for. > > "Bugs" is also wrong (incomplete), but I expect most people are used > to > looking under Bugs about enhancements/contributions. > > I'm sure this has been mentioned before, but I couldn't find where > or if > anything came of it. No matter it is called, some users will file user problems using the system. I seriously doubt renaming the issue tracker to something else will significant reduce these instances. -- Kurt

1 0

Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com 07 May '08

07 May '08

Hi, Le Mer 7 mai 2008 16:11, Quanah Gibson-Mount a écrit : > --On Wednesday, May 07, 2008 12:44 PM +0000 raphael.ouazana(a)linagora.com > wrote: > >> Currently testing new RE24. I have now a slapd process stuck at 100% : >> \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb >> \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F slapd.d -h >> ldap://localhost:9011/ -d 261 >> \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h >> ldap://localhost:9012/ -d 261 >> \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h >> ldap://localhost:9013/ -d 261 >> \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb >> \_ ../clients/tools/ldapsearch -P 3 -x -LLL -H >> ldap://localhost:9013/ -s base -b cn=Ursula Hampster,ou=Alumni >> Association,ou=People,dc=example,dc=com (objectClass=*) >> \_ awk /^dn:/ {print "OK"} >> >> Do you need some debugging info (strace, gdb, log, or other) ? > > Please provide a gdb backtrace of the hung process. It is not really hung, it is more in an infinite loop. Here is the backtrace: (gdb) thread apply all bt Thread 5 (Thread 0xb7ad5b90 (LWP 6028)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7d14676 in epoll_wait () from /lib/tls/i686/cmov/libc.so.6 #2 0x080600bb in slapd_daemon_task (ptr=0x0) at daemon.c:2281 #3 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 4 (Thread 0xb76d4b90 (LWP 6030)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da9aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0807302b in send_ldap_ber (conn=0xb7ad6b28, ber=0xb76d2e98) at result.c:188 #3 0x08075256 in slap_send_search_entry (op=0x8252af0, rs=0xb76d4178) at result.c:1200 #4 0x08056418 in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x828bf48, depth=0) at bconfig.c:3507 #5 0x080563e4 in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x828bf48, depth=1) at bconfig.c:3516 #6 0x080563be in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x82527c0, depth=0) at bconfig.c:3511 #7 0x080563e4 in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x82527c0, depth=1) at bconfig.c:3516 #8 0x080563be in config_send (op=0x8252af0, rs=0xb76d4178, ce=0x824fc80, depth=0) at bconfig.c:3511 #9 0x080564e4 in config_back_search (op=0x8252af0, rs=0xb76d4178) at bconfig.c:5261 #10 0x08065283 in fe_op_search (op=0x8252af0, rs=0xb76d4178) at search.c:366 #11 0x08065af7 in do_search (op=0x8252af0, rs=0xb76d4178) at search.c:217 #12 0x0806312f in connection_operation (ctx=0xb76d4248, arg_v=0x8252af0) at connection.c:1084 #13 0x080639bf in connection_read_thread (ctx=0xb76d4248, argv=0x8) at connection.c:1211 #14 0x0812fb48 in ldap_int_thread_pool_wrapper (xpool=0x822cae8) at tpool.c:663 #15 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #16 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 3 (Thread 0xb71d2b90 (LWP 6034)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da9aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0812fbb5 in ldap_int_thread_pool_wrapper (xpool=0x822cae8) at tpool.c:654 #3 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #4 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 2 (Thread 0xb6dd1b90 (LWP 6035)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da9aa5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0812f4c2 in handle_pause (tpool=<value optimized out>, do_pause=1) at tpool.c:738 #3 0x08054abf in config_back_add (op=0xb6dd0dd4, rs=0xb6dd0728) at bconfig.c:4548 ---Type <return> to continue, or q <return> to quit--- #4 0x080bb70f in syncrepl_entry (si=0x8255888, op=0xb6dd0dd4, entry=0x823ffec, modlist=0xb6dd0b44, syncstate=1, syncUUID=0xb6dd0b0c, syncCSN=0x0) at syncrepl.c:2108 #5 0x080be0d9 in do_syncrep2 (op=0xb6dd0dd4, si=0x8255888) at syncrepl.c:862 #6 0x080bfec4 in do_syncrepl (ctx=0xb6dd1248, arg=0x8255ac8) at syncrepl.c:1276 #7 0x08063a06 in connection_read_thread (ctx=0xb6dd1248, argv=0x9) at connection.c:1213 #8 0x0812fb48 in ldap_int_thread_pool_wrapper (xpool=0x822cae8) at tpool.c:663 #9 0xb7da54fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #10 0xb7d13e5e in clone () from /lib/tls/i686/cmov/libc.so.6 Thread 1 (Thread 0xb7c3c6b0 (LWP 6024)): #0 0xb7eef410 in __kernel_vsyscall () #1 0xb7da6775 in pthread_join () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x0805d633 in slapd_daemon () at daemon.c:2644 #3 0x0804c597 in main (argc=8, argv=0xbfaefcc4) at main.c:946 #0 0xb7eef410 in __kernel_vsyscall () (gdb) Regards, Raphaël Ouazana.

1 0

Re: (ITS#5470) Sporadic failures with RE24
by quanah＠zimbra.com 07 May '08

07 May '08

--On Wednesday, May 07, 2008 12:44 PM +0000 raphael.ouazana(a)linagora.com wrote: > Currently testing new RE24. I have now a slapd process stuck at 100% : > \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb > \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F slapd.d -h > ldap://localhost:9011/ -d 261 > \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h > ldap://localhost:9012/ -d 261 > \_ /tmp/openldap/tests/../servers/slapd/slapd -s0 -F ./slapd.d -h > ldap://localhost:9013/ -d 261 > \_ /bin/sh ./scripts/test050-syncrepl-multimaster hdb > \_ ../clients/tools/ldapsearch -P 3 -x -LLL -H > ldap://localhost:9013/ -s base -b cn=Ursula Hampster,ou=Alumni > Association,ou=People,dc=example,dc=com (objectClass=*) > \_ awk /^dn:/ {print "OK"} > > Do you need some debugging info (strace, gdb, log, or other) ? Please provide a gdb backtrace of the hung process. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2008