openldap-devel

openldap-devel@openldap.org

1431 discussions

Dropping slurpd, manage/Relax control
by Howard Chu 14 Dec '06

14 Dec '06

One feature that's still needed in some cases (e.g., using syncrepl to push updates to another slave thru back-ldap) is an updatedn identity with the privilege to write to unmodifiable operational attributes. I guess this isn't something the Relax control is intended to allow. We can keep using the updatedn but it feels like this is something that should be generalized. E.g. one might want to have a cluster of servers sending updates to each other, with a unique identity for each server, and all of them with privilege to write to operational attributes. I think the updatedn feature captures the idea ("this identity is a DSA") but it just needs to be more flexibly configured. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

3 4

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Howard Chu 14 Dec '06

14 Dec '06

石斌(Seuler.shi) wrote: > I just solve the problem and the BDB replication can work well with the > OpenLDAP. > > The back-bdb caching mechanism is not removed. I will test the > performance while > deploying back-bdb configuration in OpenLDAP. Have fun testing. You're getting well ahead of yourself; first you have to demonstrate that your code is correct, before testing its performance. Some of the most common replication scenarios for OpenLDAP will immediately fail with BDB replication, simply because BDB assumes identical configurations on all servers. As such, any performance measurements you make are purely academic. If you're looking for a good learning exercise, why not write some code that will actually be useful... > ----Seuler > > > 2006/12/14, Howard Chu <hyc(a)symas.com <mailto:hyc@symas.com>>: > > This is a pointless exercise. > > > --On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi )" > > <seuler.shi(a)gmail.com <mailto:seuler.shi@gmail.com>> wrote: > > >> Dear Quanah: > >> > >> Because the replication features provided by > OpenLDAP do not > >> meet our software requirement. > >> If there are N slaves and 1 master in a replication > group in > >> BDB, once the master crashes, a new > >> master will be elected by BDB and the replication > group can > >> still work well. All the parameters > >> concerning master election in BDB can be configured > by user. > >> This will be more portable. > > OpenLDAP mirrormode allows automatic promotion of a slave to a master. > > Using LDAP for the control protocol is far more portable. It provides an > open, standard protocol for managing all of the servers. Using > back-config on each server will allow you to tune all of the server > parameters, including the underlying BDB parameters, from anywhere on > the network, using any of a variety of LDAP-enabled clients. > > Using LDAP for the replication protocol is far more portable. It allows > data to be replicated to any LDAP-aware server, not just other OpenLDAP > servers. > > Relying solely on BDB replication does not provide such power or > flexibility. > > >> As the replication mechanism reaches synchronizations by > >> transferring write requests to the replicas, > >> this may be less efficient compared with BDB > replication. So > >> we need to compare these two method. > > Transmitting a single LDAP write operation over the network is far more > bandwidth-efficient than transmitting the many database pages that will > be dirtied by a single LDAP write operation. > > >> Would you tell me why OpenLDAP do not support BDB > >> replication? > > Because BDB replication offers no advantages for OpenLDAP's use cases. > > >> BDB replication mechanism will operate slave databases > >> directly without inform the upper layer LDAP. > >> The information such as index, ID and so on > maintained by > >> OpenLDAP may be inconsistent with the > >> content of database. I try to mend the source code of > >> OpenLDAP to let every "ldapsearch" operation > >> find entry info in database directly, but I failed:( > >> > >> I am expecting your comments. > > The only way to make it work is by removing all of the back-bdb caching > mechanisms. Performance will be extremely slow. You will lose a > significant degree of usability and gain no benefit in return for this > effort. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Quanah Gibson-Mount 14 Dec '06

14 Dec '06

--On Thursday, December 14, 2006 3:58 PM +0800 "石斌(Seuler.shi)" <seuler.shi(a)gmail.com> wrote: > > I have solved the problem just now. The BDB replication can work well > with OpenLDAP. I doubt that it really does. In any case, if you want to discuss this, keep it to openldap-devel and not my address. --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: commit: ldap/servers/slapd/back-bdb add.c cache.c
by Howard Chu 12 Dec '06

12 Dec '06

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb > > Modified Files: > add.c 1.160 -> 1.161 > cache.c 1.126 -> 1.127 > > Log Message: > Tweak bei_state so cache_lru_add doesn't ever try to free just-added > entries. This allows us to use the frontend's entry directly instead > of having to entry_dup it before adding to the cache. I remember regretting having to use entry_dup here in the first place, 'way back when. Removing it shaves another minute off my test; the ldapadd that took an hour and 33 minutes now completes in just 5 minutes. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

2 2

New Admin Guide TOC
by Gavin Henry 11 Dec '06

11 Dec '06

Dear all, Just working on a proposal for a new TOC, which is basically a re-arranged version of the existing one with new sections. If you have had an idea/wish for a section for the guide, please let me know and I'll add it to the proposal. Anyone have an docs lying around unfinished they want to let me know about? Also, could we allow the TOC to have 3 layers, instead of the current 2? This would help find things quickly e.g. Replication Replication Strategies Syncrepl Delta Syncrepl Recommended Solutions Backends back-monitor Overview Configuration back-hdb etc. Lastly, is it easy to do an index linking back to over sections? Is that just like "back-monitor: {{SECT Backends}}" Thanks. -- 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/

2 2

SDF (Was: [Please Authorise] Permission to use your glossary as a starting point for OpenLDAP docs addition?)
by Kurt D. Zeilenga 09 Dec '06

09 Dec '06

At 03:04 AM 12/8/2006, Gavin Henry wrote: >Are we concerned with the sdf format in anyway? About the format, no. >Is it still maintained? Not actively. >Can we do everything we want with it? No. But s/want/need/, then yes. >But I have absolutely no objections to sticking with sdf. For now, sticking with SDF is best. But after we upgrade some more critical pieces of infrastructure, like the issue tracker and FAQ, we can come back to this. Kurt

2 1

Adding vendor-specific ldap_set_options
by Eric Clements 08 Dec '06

08 Dec '06

Hello, I am interested in adding a specific ldap_set_option to the OpenLDAP source that would be classified as a "vendor" specific option to take advantage of platform features. I see various ranges in the ldap.h file, but no range called out specifically for vendor extensions. Is there a particular range that should be used to prevent conflicts with future OpenLDAP development? Thank you, Eric Clements

2 1

Re: [Please Authorise] Permission to use your glossary as a starting point for OpenLDAP docs addition?
by Kurt D. Zeilenga 08 Dec '06

08 Dec '06

At 07:53 AM 12/7/2006, Gavin Henry wrote: >> How much do you want to tell? That is, do you want to provide >> more than an overview of LDAP? That is, do you want to write >> document discussing LDAP basics? > >Do you think this would benefit potential users? Certainly a good document discussing LDAP basics might benefit users of OpenLDAP Software.... if you want to write something like this, go for it. I'd suggest doing so as a separate document. >My original point was intended to do a wee paragraph for each item in the >glossary, much like the previous LDAP link I sent and for example, what >you would find in the glossary of "Programming Perl". Understand. >What we have just now is really "Acronyms and Abbreviations". Yes. I meant it only as a starting point, as it contains many of the terms one might one to define in a glossary. While some of the tables now in the Appendix A may be useful (like references), not sure if they all are. Presently I'm thinking that the General LDAP FAQ is a good place to develop a glossary. I also think it best to write it from scratch. Many of definitions you referenced are pretty bad. I rather base most of the definitions from the LDAP Technical Specification. Kurt

2 1

Re: (ITS#4770) monitoringslapd.sdf patch
by Kurt D. Zeilenga 08 Dec '06

08 Dec '06

At 01:23 PM 12/7/2006, hyc(a)symas.com wrote: >ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.30 >> OS: FC6 >> URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch >> Submission from: (NULL) (212.159.59.85) >> >> >> Hi all, >> >> Monitoring section updated. Please review and provide feedback. >> >> Thanks, >> >> Gavin. >> >> (http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch) >> >At the moment the only comment I have is regarding back-monitor itself, >not the doc: I question the decision to define the monitor info >attributes as operational instead of user attributes. Requiring the use >of "+" to return all of the monitored info seems pretty unfriendly, >particularly since it causes the return of actual operational attributes >that are completely irrelevant to the purpose of monitoring. I.e., the >monitor info should be considered to be dynamically generated user >attributes, not operational attributes. [moved to devel] Well, from a data model perspective, the attributes seems to belong to directory system agent, not user applications. Their values do change at the whim of the directory system agent. Also, if they were user applications attributes, they couldn't disallow user modification in their descriptions (modification would have to be denied by other means). I do note that these attributes really should have usage dSAOperation not directoryOperation. -- Kurt

3 3

Re: Thoughts on doxygen for Devel Docs/API?
by Kurt D. Zeilenga 07 Dec '06

07 Dec '06

At 08:36 AM 12/7/2006, Gavin Henry wrote: >That one's obviously for the future, I concur that consideration on this one should be deferred. - Kurt

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel