openldap-bugs May 2007

openldap-bugs@openldap.org

42 participants
156 discussions

RE: (ITS#4934) Port change
by Babu.Suresh＠pacificlife.com 02 May '07

02 May '07

Thank you..this was resolved after I implemented ACL in slapd.conf. _babu -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Wednesday, May 02, 2007 9:20 AM To: Suresh, Babu; openldap-its(a)openldap.org Subject: Re: (ITS#4934) Port change --On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

Re: (ITS#4934) Port change
by quanah＠zimbra.com 02 May '07

02 May '07

--On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4930) slaptest should be quiet on success
by quanah＠zimbra.com 02 May '07

02 May '07

--On April 18, 2007 9:42:20 AM +0000 jsafranek(a)redhat.com wrote: > Full_Name: Jan Safranek > Version: 2.3.35 > OS: Linux (Fedora 6) > URL: > Submission from: (NULL) (62.40.79.66) > > > The 'slaptest' tool is a bit verbose, it sends 'config file testing > succeeded' to stderr. IMHO it should do not output anything, especially > to stderr, if everything is all right. > > Here is a small patch, causing the slaptest to display the aforementioned > message only if -v switch is used: > > Index: servers/slapd/slaptest.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v > retrieving revision 1.9 > diff -r1.9 slaptest.c > 107c107,108 > < fprintf( stderr, "config file testing succeeded\n"); > --- >> if (verbose) >> fprintf( stderr, "config file testing succeeded\n"); The point of slaptest is to tell users whether or not things are okay. Having slaptest exit with nothing displayed somewhat defeats that purpose... --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 02 May '07

02 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard As far as I can tell from tpool.c, ldap_pvt_thread_pool_destroy() will act prematurely if another thread pauses: ldap_pvt_thread_pool_destroy (...) { ... if ( pool->ltp_open_count ) { ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); ldap_pvt_thread_cond_wait(&pool->ltp_cond, &pool->ltp_mutex); } ... since ldap_pvt_thread_pool_resume() broadcasts on the same mutex. Also ldap_pvt_thread_pool_resume() will reset ltp_state to RUNNING instead of FINISHING/STOPPING. If that can happen, the fix would be: (a) use while() instead of if(), (b) keep an ltp_unpaused_state along with ltp_pause which is _pause does not change and _resume copies to ltp_state, or just remove LDAP_INT_THREAD_POOL_PAUSING in favor of an ltp_pausing flag. (And possibly some code which currently checks ltp_state ought to check ltp_unpaused_state instead, I'm not sure.) (c) if _destroy() can be called while LDAP_INT_THREAD_POOL_PAUSING, I think the other if()s around ltp_cond need to be while() too.

1 0

Re: (ITS#4942) configurable filter blocking
by hyc＠symas.com 01 May '07

01 May '07

quanah(a)zimbra.com wrote: > ----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: >> quanah(a)OpenLDAP.org writes: >>> For example, I may want to block subfinal indices on the >>> "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. >> I should have added: Unless you've got a better answer than me for >> why this is better than the "unchecked" limit, it might be more >> useful to block "suAffiliation" from getting a "subfinal" index. >> Then use the "unchecked" limit to block too general searches. > > Hi Hallvard, > > My reasoning comes from this: At my previous job we had a tree rooted at "dc=stanford,dc=edu". Controlling the indexing to allow/block certain types of searches has been very important, and the directory well tuned to that purpose. The following subtrees are what exist: cn=people, cn=accounts, and cn=organizations. cn=organizations is the newest subtree, and additional indexing had to be added on attributes that used to be indexed differently in the person tree. There is no desire to split the trees apart into their own databases, but indexing is per database (not per subtree). > > For example, displayName used to be indexed "eq" only. Now with organizations, we need to change the index to "eq,sub". So it would be nice to block substring filters of displayName in the cn=people tree, etc. > > --Quanah Should be simple enough to write an overlay that can be configured with a URI and filter types to block. Just return Unwilling to Perform for any matching patterns. Certainly not something that needs to be added to the core code. -- -- 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/

1 0

Re: (ITS#4942) configurable filter blocking
by quanah＠zimbra.com 30 Apr '07

30 Apr '07

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > quanah(a)OpenLDAP.org writes: > > For example, I may want to block subfinal indices on the > > "suAffiliation" attribute in the cn=people,dc=stanford,dc=edu tree. > > I should have added: Unless you've got a better answer than me for > why this is better than the "unchecked" limit, it might be more > useful to block "suAffiliation" from getting a "subfinal" index. > Then use the "unchecked" limit to block too general searches. Hi Hallvard, My reasoning comes from this: At my previous job we had a tree rooted at "dc=stanford,dc=edu". Controlling the indexing to allow/block certain types of searches has been very important, and the directory well tuned to that purpose. The following subtrees are what exist: cn=people, cn=accounts, and cn=organizations. cn=organizations is the newest subtree, and additional indexing had to be added on attributes that used to be indexed differently in the person tree. There is no desire to split the trees apart into their own databases, but indexing is per database (not per subtree). For example, displayName used to be indexed "eq" only. Now with organizations, we need to change the index to "eq,sub". So it would be nice to block substring filters of displayName in the cn=people tree, etc. --Quanah

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2007