Re: RFC: New Admin Guide Layout
I forgot a debugging slapd section in Troubleshooting and a Migration section for moving from slapd.conf to slapd.d dirs etc. Gavin. > Dear All, > > We all know the docs weaknesses, I've started this to try and > address them, as more and more people are using our docs as > an excuse not to use OpenLDAP. We all know that is wrong, but > my goal is to equal or surpass the quality of the software with > the docs. > > Details: > > Changes: > > * Deeper TOC > * When to use LDAP and age old question of LDAP vs RDBMS > * Incorporated many FAQ-O-MATIC topics (for above also) > * Answers to Common mailing list topics and IRC #ldap topics > * Generic TLS Cert Generation Methods > > == Maybe create an Advanced section for below? (currently in same heading > level as the rest) == > > * Included all Overlays and Backends > * More Replication discussions/strategies, include N-Way MultiMaster and > MirrorMode (no sublevels yet) > * Re-ordered layout > * New sections: Maintainence, Tuning, Troubleshooting and Example > Configuration Files in the Appendix (light on sub-levels). > > > This is obviously just the start, but a good place to be in I think. It's > a lot easier to write peices once we have a topic list to tick off. > > Feel free to chop and change ordering etc. It's a start. > > Now we need to delegate! ;-) > > > > New version: > > Table of Contents > > Preface > 1. Introduction to OpenLDAP Directory Services > 1.1. What is a directory service? > 1.2. What is LDAP? > 1.3. How does LDAP work? > 1.4. What about X.500? > 1.5. What is the difference between LDAPv2 and LDAPv3? > 1.6. When should I use LDAP? > 1.7. When should I not use LDAP? > 1.8. LDAP vs RDBMS > 1.9. What is slapd and what can it do? > 2. A Quick-Start Guide > 3. The Big Picture - Configuration Choices > 3.1. Local Directory Service > 3.2. Local Directory Service with Referrals > 3.3. Replicated Directory Service > 3.4. Distributed Local Directory Service > 4. Building and Installing OpenLDAP Software > 4.1. Obtaining and Extracting the Software > 4.2. Prerequisite software > 4.2.1. Transport Layer Security > 4.2.2. Simple Authentication and Security Layer > 4.2.3. Kerberos Authentication Service > 4.2.4. Database Software > 4.2.5. Threads > 4.2.6. TCP Wrappers > 4.3. Running configure > 4.4. Building the Software > 4.5. Testing the Software > 4.6. Installing the Software > 5. Configuring slapd > 5.1. Configuration Layout > 5.2. Configuration Directives > 5.2.1. cn=config > 5.2.2. cn=include > 5.2.3. cn=module > 5.2.4. cn=schema > 5.2.5. Backend-specific Directives > 5.2.6. Database-specific Directives > 5.2.7. BDB and HDB Database Directives > 5.3. Access Control > 5.3.1. What to control access to > 5.3.2. Who to grant access to > 5.3.3. The access to grant > 5.3.4. Access Control Evaluation > 5.3.5. Access Control Examples > 5.3.6. Access Control Ordering > 5.4. Configuration Example > 6. The slapd Configuration File > 6.1. Configuration File Format > 6.2. Configuration File Directives > 6.2.1. Global Directives > 6.2.2. General Backend Directives > 6.2.3. General Database Directives > 6.2.4. BDB and HDB Database Directives > 6.3. The access Configuration Directive > 6.3.1. What to control access to > 6.3.2. Who to grant access to > 6.3.3. The access to grant > 6.3.4. Access Control Evaluation > 6.3.5. Access Control Examples > 6.4. Configuration File Example > 7. Running slapd > 7.1. Command-Line Options > 7.2. Starting slapd > 7.3. Stopping slapd > 8. Database Creation and Maintenance Tools > 8.1. Creating a database over LDAP > 8.2. Creating a database off-line > 8.2.1. The slapadd program > 8.2.2. The slapindex program > 8.2.3. The slapcat program > 8.3. The LDIF text entry format > 9. Backends > 9.1. Berkeley DB backends >9.1.1. Overview >9.1.2. back-bdb/back-hdb Configuration >9.1.2. Further Information > 9.2. LDAP >9.1.1. Overview >
Confusion about the schedule of work threads in OpenLDAP?
In the OpenLDAP, the incoming requests are first inserted in a list and then assigned to the work threads. Take a scenario as follow, there are T1,T2,T3,...Tn requests in order, T1 2 is a "modify request", and T3 is a "search request".If these request are serially handled one by one, then T3 will get the updated info by T2. But if the requests are assigned to work threads and handled concurrently, will the following case happen? T2 and T3 are assigned to Thread A and Thread B, but Thread B is scheduled before A. So T2 is handled after T3. And later request, T3 will never get the newly updated info? If this case can never happend, how does OpenLDAP guarantee the incoming requests are handled in order even if the work threads are scheduled randomly? Thanks a lot:)
Re: Confusion about the schedule of work threads in OpenLDAP?
石斌(Seuler.shi) wrote: In the OpenLDAP, the incoming requests are first inserted in a list and then assigned to the work threads. Take a scenario as follow, there are T1,T2,T3,...Tn requests in order, T1 2 is a "modify request", and T3 is a "search request".If these request are serially handled one by one, then T3 will get the updated info by T2. But if the requests are assigned to work threads and handled concurrently, will the following case happen? T2 and T3 are assigned to Thread A and Thread B, but Thread B is scheduled before A. So T2 is handled after T3. And later request, T3 will never get the newly updated info? If this case can never happend, how does OpenLDAP guarantee the incoming requests are handled in order even if the work threads are scheduled randomly? In general there are no guarantees. You can use the PostRead control if you need to retrieve the content of an entry immediately after modifying it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/
