openldap-bugs

openldap-bugs@openldap.org

1 participants
20955 discussions

Re: (ITS#4862) Doxygen support
by ghenry＠suretecsystems.com 08 Mar '07

08 Mar '07

<quote who="ando(a)sys-net.it"> > Full_Name: Pierangelo Masarati > Version: HEAD (almost irrelevant) > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/openldap-doxygen.tar.gz > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > I've updated a simple doxygen configuration file that allows to create a > (hopefully) complete and useful browsable tree of OpenLDAP software. The > current configuration is quite redundant, since it includes sources in the > tree, > and may take a while to process. It needs "doxygen" and "dot" (the latter > can > be disabled by setting HAVE_DOT to "no", if unavailable, at the expense of > loosing the graphical description of relations between data types and > files). > > To "install": > - cd into the root of the source tree > - untar openldap-doxygen.tar.gz > > this puts a couple .html files in doc/devel, and Doxyfile in the root of > the > source tree. Edit this to customize. > > Finally, run doxygen from the root of the source tree (and be patient). > > Documents will be installed in doc/source_html. Edit Doxyfile to > customize. > Enjoy. > > p. Wow! That rules and looks great. Brilliant work. Thoughts on polishing this up and adding something to the main site with an announcement sometime? "OpenLDAP goes Doxygen" ;-) Gavin. -- 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#4862) Doxygen support
by ando＠sys-net.it 08 Mar '07

08 Mar '07

Full_Name: Pierangelo Masarati Version: HEAD (almost irrelevant) OS: irrelevant URL: ftp://ftp.openldap.org/incoming/openldap-doxygen.tar.gz Submission from: (NULL) (81.72.89.40) Submitted by: ando I've updated a simple doxygen configuration file that allows to create a (hopefully) complete and useful browsable tree of OpenLDAP software. The current configuration is quite redundant, since it includes sources in the tree, and may take a while to process. It needs "doxygen" and "dot" (the latter can be disabled by setting HAVE_DOT to "no", if unavailable, at the expense of loosing the graphical description of relations between data types and files). To "install": - cd into the root of the source tree - untar openldap-doxygen.tar.gz this puts a couple .html files in doc/devel, and Doxyfile in the root of the source tree. Edit this to customize. Finally, run doxygen from the root of the source tree (and be patient). Documents will be installed in doc/source_html. Edit Doxyfile to customize. Enjoy. p.

1 0

(ITS#4861) Issue with referrals in proxy backends
by ando＠sys-net.it 08 Mar '07

08 Mar '07

Full_Name: Pierangelo Masarati Version: re23 + patches from HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando I've received reports of issues with referrals returned from a third-party DSA to OpenLDAP's proxy backends. Apparently, in some cases the response contained referrals with a return code different from LDAP_REFERRAL. Although I can't prove it (it seems to be non-deterministic), I've strenghtened the proxy backends code so that it rejects those responses instead of sending them thru send_ldap_result(), which triggers an assertion. p.

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 08 Mar '07

08 Mar '07

On Jeu 8 mars 2007 01:00, Pierangelo Masarati wrote: > raphael.ouazana(a)linagora.com wrote: > > I see at least 2 issues in this patch: > > 1) the use of dnParent() in place on malloc'd data would lead to memory > corruption, because at some point the value of the set will be freed, > but the bv_val of that value would no longer point to the beginning of a > malloc()'ed block. You should rather use AC_MEMCPY() to move the > parent's DN at the beginning of the malloc()'ed memory block. > > 2) when trimming a set of DNs to some ancestor, DNs with common > ancestors could result in duplicate set values. I'm not sure this > currently has any adverse effect on set evaluation, but I'd consider it > bad anyway. You should eliminate duplicates, in case any arises. Fixing these issues, I saw that set_parent will be very similar to set_chase. Do you think I should create a new gatherer instead of ? Regards, Raphael Ouazana.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 07 Mar '07

07 Mar '07

raphael.ouazana(a)linagora.com wrote: I see at least 2 issues in this patch: 1) the use of dnParent() in place on malloc'd data would lead to memory corruption, because at some point the value of the set will be freed, but the bv_val of that value would no longer point to the beginning of a malloc()'ed block. You should rather use AC_MEMCPY() to move the parent's DN at the beginning of the malloc()'ed memory block. 2) when trimming a set of DNs to some ancestor, DNs with common ancestors could result in duplicate set values. I'm not sure this currently has any adverse effect on set evaluation, but I'd consider it bad anyway. You should eliminate duplicates, in case any arises. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

(ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 07 Mar '07

07 Mar '07

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-070307.patch Submission from: (NULL) (82.225.231.106) Hi, This patch creates a new operator for sets : /- It allows to get the nth parent of all the elements of a set. For example, if user is cn=user,ou=people,dc=example,dc=com : user/-1 : resolves to set {ou=people,dc=example,dc=com} user/-2 : resolves to set {dc=example,dc=com} Of course it works the same for sets of more than 1 element. It is very useful when ACLs depends on hierarchy. Legal notice : This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2007 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 07 Mar '07

07 Mar '07

--On Wednesday, March 07, 2007 2:32 PM -0800 Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: > > > --On Wednesday, March 07, 2007 2:28 PM -0800 Howard Chu <hyc(a)symas.com> > wrote: > >> >> ---- <quanah(a)stanford.edu> wrote: >>> What I want to do, is put subtree based accesslog's on my replica >>> servers. We have multiple downstream systems that pull data from the >>> directory. This would allow them to "sit and listen" to the changes >>> made in their subtrees of interest, using the syncrepl protocol. >> >> Uh huh. That's what search filters are for. If that's the only motivation >> for this ITS, then we can close it right now. >> >> ldapsearch -b cn=log >> (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu) > > That doesn't do a never ending search that catches every write as it > occurs. Although I guess a syncrepl search could use the filter ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 07 Mar '07

07 Mar '07

--On Wednesday, March 07, 2007 2:28 PM -0800 Howard Chu <hyc(a)symas.com> wrote: > > ---- <quanah(a)stanford.edu> wrote: >> What I want to do, is put subtree based accesslog's on my replica >> servers. We have multiple downstream systems that pull data from the >> directory. This would allow them to "sit and listen" to the changes >> made in their subtrees of interest, using the syncrepl protocol. > > Uh huh. That's what search filters are for. If that's the only motivation > for this ITS, then we can close it right now. > > ldapsearch -b cn=log > (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu) That doesn't do a never ending search that catches every write as it occurs. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4857) Subtree accesslog support
by hyc＠symas.com 07 Mar '07

07 Mar '07

---- <quanah(a)stanford.edu> wrote: > What I want to do, is put subtree based accesslog's on my replica servers. > We have multiple downstream systems that pull data from the directory. > This would allow them to "sit and listen" to the changes made in their > subtrees of interest, using the syncrepl protocol. Uh huh. That's what search filters are for. If that's the only motivation for this ITS, then we can close it right now. ldapsearch -b cn=log (reqDN:dnsubtreematch:=ou=accounts,dc=stanford,dc=edu) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support

1 0

Re: (ITS#4857) Subtree accesslog support
by quanah＠stanford.edu 07 Mar '07

07 Mar '07

--On Wednesday, March 07, 2007 5:09 PM +0000 Frank.Swasey(a)uvm.edu wrote: > This is a cryptographically signed message in MIME format. > > --------------ms050409020803020407000508 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > On 3/6/07 6:31 PM, quanah(a)stanford.edu wrote: >> I was looking at adding access log configurations to my main database >> that would log operations based on subtree. For example, I'd like to >> have all operations on "cn=accounts,dc=stanford,dc=edu" go into one >> accesslog, and operations on "cn=people,dc=stanford,dc=edu" go into >> another accesslog. My root is "dc=stanford,dc=edu". There doesn't seem >> to be a way with the way accesslog is currently designed to do this. I >> believe it would be a useful feature. > > I have wished for a similar capability. However, have always been > stopped from proceeding to look at modifying the code because all my > consumers need to replicate the full database. > > However, it would be nice to be able to break things apart and have > them expire out of the accesslog at different times. For instance, our > sendmail spam blocking rules live for a max of several hours and so I > could expire those from the accesslog after 8 hours, but the core > (people, groups, accounts) I'd like to keep for a couple days to make > certain they get to the replica servers. > > Is that the same kind of thing you are thinking of Quanah? Hi Frank, Actually, no, it isn't. ;) What I want to do, is put subtree based accesslog's on my replica servers. We have multiple downstream systems that pull data from the directory. This would allow them to "sit and listen" to the changes made in their subtrees of interest, using the syncrepl protocol. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

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