openldap-bugs

openldap-bugs@openldap.org

1 participants
21002 discussions

(ITS#5501) syncprov/glue crash with RE24 CVS
by mark.cave-ayland＠siriusit.co.uk 08 May '08

08 May '08

Full_Name: Mark Cave-Ayland Version: 2.4.8cvs-RE24-2008-05-06 OS: RHEL4, x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.207.197.142) Hi there, We've located a segfault in openldap 2.4.8cvs RE24 branch from 2 days ago (which we believe is almost exactly the same as the 2.4.9 release) when using a combination of glue/syncprov. Details from the slapd log and the gdb core file can be found here: http://pastebin.siriusit.co.uk/openldap-bug-20080508.txt More information from the gdb core file can be obtained upon request. Many thanks, Mark.

1 0

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

07 May '08

Le Jeu 8 mai 2008 00:03, Howard Chu a écrit : > 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? Yes, at least two things: - one CPU is about at 100% - logs from slapd.1.log and slapd.2.log are slowly increasing It seems to be an infinite loop between the first slapd and the second slapd, where the second is always active. I'm sorry I won't be able to access the logs until Tuesday, and all the processes are now killed. Regards, Raphaël Ouazana.

1 0

Re: (ITS#5500) comments in cn=config entries
by hyc＠symas.com 07 May '08

07 May '08

h.b.furuseth(a)usit.uio.no wrote: > 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. The X-ORDERED flag obviously cannot be added to existing schema elements; you need to define a new attribute. -- -- 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#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

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