Full_Name: Gavin Henry
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.159.59.85)
Submitted by: ghenry
We need a better title ;-)
<TITLE>OpenLDAP, Title</TITLE>
Gavin.
Full_Name: Gavin Henry
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.159.59.85)
Submitted by: ghenry
Dear all,
Not sure if I already requested this (can't find the ITS), but can we set up
something to do a weekly doc generation for
http://www.openldap.org/devel/admin/
Thanks.
ando(a)sys-net.it wrote:
>> Howard Chu a écrit :
>
>> Unfortunately, it's currently heavily dependant on one of our customer's
>> specific schema extensions and data tree structure. The ACLs in use
>> implement a lot of the logic specific to their environment, therefore I
>> can't send them as is.
>>
>> However, I will see if I can "translate" some of the more complicated
>> ACLs (with sets) to perform on a simple data set for inclusion in the
>> test suite.
>>
>> Could some examples such as these also fit your documentation request
>> for sets and their applications [1]? Assuming this is the case, I will
>> try and provide at least a subset of our test set soon.
>>
>> Cheers,
>> Jon
>>
>> [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html
>
> Let me state first that right now I believe sets do not belong to
> slapd(8); they should rather move into a module, under the dynacl
> umbrella. And, as such, they should be documented separately from
> slapd.access(5), mostly because having them in slapd.access(5) would sort
> of encourage unexperienced people into (ab-)using them.
>
> Also, I'd like sets' users to document them (especially in terms of useful
> hints, scenarios, case studies and so), as they probably best know what
> one can gain from their use. Otherwise, a bare description of the syntax,
> although necessary, would hardly be useful to most of the users.
>
> p.
>
Agreed. Once decided, we can discuss where they would fit in the Admin
guide.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
> Full_Name: Mark
> Version: 2.3.38
> OS: Suse Linux 10.01
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (84.128.87.178)
>
>
> ** Problem
> test001-slapdadd fails with segmentation fault.
>
> ** Environment
> Suse Linux 10.1
> Berkly DB 4.6.21
> Openldap 2.3.38
OpenLDAP 2.3 does not support Berkeley > 4.6.9; this issue has been risen
dozens of times, but apprently browsing archives for known issues has
become unfashionable.
Please either upgrade to OpenLDAP 2.4 or downgrade to Berkeley < 4.6.
This ITS will be closed.
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
---------------------------------------
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.203.230.29)
Submitted by: ando
This is a feature request for stats and monitoring capabilities for pcache;
basically:
- the number of cached queries
- the number of cached entries
- possibly, a list of cached queries in cachedQueryURL form
- how many times each cached query was used instead of re-running the request
- the ratio answerable / cacheable for each cacheable query
- some global figure like the average response time (send searchResult time -
start caching time) for each query, and the overall average.
Adding per-query info could be done by either extending the cachedQueryURL
format or by adding a child entry for each cached query (like connections and
other dynamic info).
p.
> Howard Chu a écrit :
> Unfortunately, it's currently heavily dependant on one of our customer's
> specific schema extensions and data tree structure. The ACLs in use
> implement a lot of the logic specific to their environment, therefore I
> can't send them as is.
>
> However, I will see if I can "translate" some of the more complicated
> ACLs (with sets) to perform on a simple data set for inclusion in the
> test suite.
>
> Could some examples such as these also fit your documentation request
> for sets and their applications [1]? Assuming this is the case, I will
> try and provide at least a subset of our test set soon.
>
> Cheers,
> Jon
>
> [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html
Let me state first that right now I believe sets do not belong to
slapd(8); they should rather move into a module, under the dynacl
umbrella. And, as such, they should be documented separately from
slapd.access(5), mostly because having them in slapd.access(5) would sort
of encourage unexperienced people into (ab-)using them.
Also, I'd like sets' users to document them (especially in terms of useful
hints, scenarios, case studies and so), as they probably best know what
one can gain from their use. Otherwise, a bare description of the syntax,
although necessary, would hardly be useful to most of the users.
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
---------------------------------------
jclarke(a)linagora.com wrote:
> However, I will see if I can "translate" some of the more complicated
> ACLs (with sets) to perform on a simple data set for inclusion in the
> test suite.
>
> Could some examples such as these also fit your documentation request
> for sets and their applications [1]? Assuming this is the case, I will
> try and provide at least a subset of our test set soon.
Absolutely. Thanks...
>
> Cheers,
> Jon
>
> [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html
--
-- 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/
Howard Chu a écrit :
> jclarke(a)linagora.com wrote:
>> Got this one: it was a double-free in sets.c occuring after a
>> slap_set_join() with lset or rset empty - the non empty set was
>> returned, and then freed, causing a double-free error or segfault.
>>
>> The patch attached corrects this problem on RE23 and HEAD for me and
>> doesn't have any side effects on our test set. However, it may not be
>> the "right" way - please correct if necessary!
>
> Is your test set something you can clean up for inclusion in our test
> suite?
Unfortunately, it's currently heavily dependant on one of our customer's
specific schema extensions and data tree structure. The ACLs in use
implement a lot of the logic specific to their environment, therefore I
can't send them as is.
However, I will see if I can "translate" some of the more complicated
ACLs (with sets) to perform on a simple data set for inclusion in the
test suite.
Could some examples such as these also fit your documentation request
for sets and their applications [1]? Assuming this is the case, I will
try and provide at least a subset of our test set soon.
Cheers,
Jon
[1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html
--
Jonathan Clarke
Cellule OSSA - Groupe LINAGORA
27 rue de Berri, 75008 Paris
Tél: 01 58 18 68 28, fax: 01 58 18 68 29
http://www.linagora.com - http://www.08000linux.com
> jclarke(a)linagora.com a écrit :
>> Pierangelo Masarati a écrit :
>>> Should be fixed now in HEAD/re24/re23. Please test. p.
>>
>> I've been testing (at last, sorry for the delay), and I've come across
>> another memory problem. Backtrace is below, and valgrind output is
>> attached.
>
> Got this one: it was a double-free in sets.c occuring after a
> slap_set_join() with lset or rset empty - the non empty set was
> returned, and then freed, causing a double-free error or segfault.
>
> The patch attached corrects this problem on RE23 and HEAD for me and
> doesn't have any side effects on our test set. However, it may not be
> the "right" way - please correct if necessary!
Thanks for spotting it - I had no time to look at your last report. I'll
check the fix and eventually apply it.
> Your recent fixes have solved all the issues from our test cases we were
> encountering. Thank you very much for them.
Sure. Cheers, 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
---------------------------------------
jclarke(a)linagora.com wrote:
> Got this one: it was a double-free in sets.c occuring after a
> slap_set_join() with lset or rset empty - the non empty set was
> returned, and then freed, causing a double-free error or segfault.
>
> The patch attached corrects this problem on RE23 and HEAD for me and
> doesn't have any side effects on our test set. However, it may not be
> the "right" way - please correct if necessary!
Is your test set something you can clean up for inclusion in our test suite?
> Your recent fixes have solved all the issues from our test cases we were
> encountering. Thank you very much for them.
>
> Jon
--
-- 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/