(ITS#5500) comments in cn=config entries
by h.b.furuseth＠usit.uio.no
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.
15 years, 6 months
Re: (ITS#5499) slapd-perl man page
by h.b.furuseth＠usit.uio.no
I wrote:
> + * bind DN, or "" for anonymous bind
Duh, sorry. Anonymous bind is handled by the frontend, of course.
--
Hallvard
15 years, 6 months
Re: (ITS#5499) slapd-perl man page
by h.b.furuseth＠usit.uio.no
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
15 years, 6 months
Re: (ITS#5497) back-sql with base64 encoded attributes
by h.b.furuseth＠usit.uio.no
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
15 years, 6 months
(ITS#5499) slapd-perl man page
by Alexander.lelyakin＠googlemail.com
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).
15 years, 6 months
Re: (ITS#5498) "Issue Tracking" -> "Bugs" @ webpage
by Kurt＠OpenLDAP.org
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
15 years, 6 months
Re: (ITS#5470) Sporadic failures with RE24
by raphael.ouazana＠linagora.com
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.
15 years, 6 months
Re: (ITS#5470) Sporadic failures with RE24
by quanah＠zimbra.com
--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
15 years, 6 months
