Re: commit: ldap/servers/slapd daemon.c slap.h aclparse.c acl.c
by Pierangelo Masarati
ando(a)OpenLDAP.org wrote:
> implement full IPv6 support in ACLs; use URL notation (as suggested by Howard) to disambiguate parsing (ITS#4756)
>
OK, I see this breaks sasl_server_new() where it expects IPv6
iplocalport and ipremoteport in the form ip;port regardless of IPv4/6.
I'll back part of this fix up.
p.
16 years, 12 months
Dropping slurpd, manage/Relax control
by Howard Chu
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/
16 years, 12 months
Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Howard Chu
石斌(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/
16 years, 12 months
Re: (ITS#4778) Problem using Berkeley DB replication in OpenLDAP
by Quanah Gibson-Mount
--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
16 years, 12 months
Re: commit: ldap/servers/slapd/back-bdb add.c cache.c
by Howard Chu
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/
16 years, 12 months
New Admin Guide TOC
by Gavin Henry
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/
16 years, 12 months
SDF (Was: [Please Authorise] Permission to use your glossary as a starting point for OpenLDAP docs addition?)
by Kurt D. Zeilenga
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
17 years
Adding vendor-specific ldap_set_options
by Eric Clements
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
17 years
Re: [Please Authorise] Permission to use your glossary as a starting point for OpenLDAP docs addition?
by Kurt D. Zeilenga
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
17 years
Re: (ITS#4770) monitoringslapd.sdf patch
by Kurt D. Zeilenga
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
17 years
