RE: (ITS#4934) Port change
by Babu.Suresh＠pacificlife.com
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.
==============================================================================
16 years, 1 month
Re: (ITS#4934) Port change
by quanah＠zimbra.com
--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
16 years, 1 month
Re: (ITS#4930) slaptest should be quiet on success
by quanah＠zimbra.com
--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
16 years, 1 month
(ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no
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.
16 years, 1 month
Re: (ITS#4942) configurable filter blocking
by hyc＠symas.com
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/
16 years, 1 month
Re: (ITS#4942) configurable filter blocking
by quanah＠zimbra.com
----- "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
16 years, 1 month