openldap-devel

openldap-devel@openldap.org

1418 discussions

back-config and slapadd
by Ralf Haferkamp 29 Mar '07

29 Mar '07

Hi, I am currently trying to initialize the back-config database by slapadd-ing a small ldif-File (based on the slapd.ldif from CVS HEAD). However I ran into various issues with regard to the ordering of the different database objects and it unclear to me how exactly this is supposed to work. The sample slapd.ldif from CVS does not contain any ordering information (the "{digit}" string). It can be slapadd-ed it with out any problem. But after starting slapd (or any slaptool) I see some strange effects, e.g. I suddenly have two frontend-databases in back-config (one with index -1 and the other without any index). In order to try to fix this I'd like to find out how slapadd-ing back-config databases is supposed to work. 1. Should slapadd work with LDIF files that do not have any ordering numbers for the databases in them? 2. Should slapadd work with LDIF files that does not explicitly contain the mandatory cn=frontend and cn=config databases? I'd assume yes as the answer for both questions. The current code however shows all kinds of weird behaviour with regard to both points and I'd like to fix that. -- Ralf

2 3

eXtreme customization of slapd
by Pierangelo Masarati 25 Mar '07

25 Mar '07

I have some requests for further slapd customization opportunities. Some of the customizations are really "custom", in the sense that they could break syntax and schema checking the way it is done now. In some cases even decoding the packet could break, so I'm a bit hesitant and I'd like, if possible, to be able to design custom code as little intrusive and as advantageous for OpenLDAP as possible, even at the cost of heavy slapd rewriting that is of general usefulness. First idea: instead of calling do_*(), add yet another pseudo-database layer, much like the "frontend" database, called the "decoding layer" database, which could be replaced (rather than augmented) by other analogous components. In this case, the custom slapd could do almost everything to an incoming packet, as soon as it is presented to the frontend and to the backends in a consistent manner. Advantages: total freedom; disadvantages: risks lots of code duplication and so. Second idea: "staggerize" packet decoding. For example, when a request comes in, just decode the DN; "sanitize" (i.e. parse and validate) it as little as possible; then pass control to an intermediate layer, which could actually be an overlay, right after database selection. At this point, it would be up to some code at this layer to do the rest of the decoding, including relaxing some checks or allowing some violations (I believe this is part of some requests from the Samba developers, and similar issues were raised by Luke Howard with respect to compatibility with some M$ "extensions"). Advantages: could be a first step towards per-database schema; potential for less code duplication. Disadvantages: could need extensive work to split current code as required. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

2 1

Re: commit: ldap/libraries/libldap gnutls.c getdn.c tls.c
by Howard Chu 23 Mar '07

23 Mar '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > getdn.c 1.136 -> 1.137 > tls.c 1.146 -> 1.147 > Added Files: > gnutls.c NONE -> 1.1 > > Log Message: > Preliminary GNUtls support. gnutls.c will merge back into tls.c later. The basic functionality is all working; if you replace tls.c with gnutls.c in the Makefile everything builds and runs. I decided to move the ldap_X509dn2bv() function into tls.c for now, since there's a different version for GNUtls. (I have not added gnutls.c to the Makefile, you can set it manually if you feel like testing this.) The GNUtls version parses the DER certificate directly, using liblber. I think this may be the best way to go moving forward. I intend to remove the OpenSSL-specific DN parser in favor of this approach. This also means we can replace the OpenSSL-dependent code in slapd/schema_init.c for the certificate validator and normalizer with generic liblber stuff. If any 3rd party code is using ldap_X509dn2bv() they're going to break. I suppose we could keep the old API around and use a new function name instead... There's still a few missing pieces in the GNUtls support: I haven't tested any Diffie-Hellman exchanges yet. There is no support for session caching yet. GNUtls needs to read CRLs from a file, you can't just point it at a directory - so we need a config directive for this. (this also means that the TLSCACertificatePath directive doesn't work) GNUtls doesn't provide any API for parsing cipher suites/algorithm names. At present I have no idea how to make these end-user configurable, will probably have to write a patch for GNUtls. There's no API equivalent to the RandFile option; I have no idea how to seed GNUtls's PRNG. Since most platforms just use /dev/urandom this isn't a big deal. Certificate verification isn't present yet. Wondering if we should silently accept the no-op directives or error out on them (TLSCACertificatePath, TLSRandFile). Just ignoring them for now. -- -- 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

Expected behavior of mirrormode
by Jesse W. Hathaway 22 Mar '07

22 Mar '07

I am testing the new mirromode feature in 2.4.4alpha and have run into some unexpected behavior: 1) If mirrormode is on in the config when slapd starts it fails to synchronize with the producer, this is unexpected behavior syncrepl rid=545 provider=ldap://ns3 type=refreshAndPersist searchbase="dc=chappy,dc=com" schemachecking=off bindmethod=simple binddn="cn=admin,dc=chappy,dc=com" credentials=secret mirrormode on 2) If mirrormode is off in the config when the consumer slapd starts the consumer slapd synchronizes with the producer, if mirrormode is then turned on dynamically, synchronization continues and the consumer is writable by anyone, this is expected behavior 3) After mirror mode is set dynamically, if the consumer slapd is restarted, then the consumer will no longer sync with the producer, this is unexpected behavior Are these bugs or by design? thanks, Jesse

1 0

back-sql - table lock
by marek-openldap 21 Mar '07

21 Mar '07

Hi I successfuly created connection from OpenLDAP to my Informix database. I can see everything in LDAP Browser:) I have noticed that when slapd is running I cannot insert data into table using sql client. I get error from my db: 243: Could not position within a table (user). 113: ISAM error: the file is locked. Is there any lock or transaction isolation level problem? Regards Marek

1 0

Confusion about the schedule of work threads in OpenLDAP?
by 石斌(Seuler.shi) 18 Mar '07

18 Mar '07

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:)

2 1

RFC: New Admin Guide Layout
by Gavin Henry 18 Mar '07

18 Mar '07

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 9.1.2. back-ldap Configuration 9.1.2. Further Information 9.3. LDIF 9.1.1. Overview 9.1.2. back-ldif Configuration 9.1.2. Further Information 9.4. Metadirectory 9.1.1. Overview 9.1.2. back-meta Configuration 9.1.2. Further Information 9.5. Monitor 9.1.1. Overview 9.1.2. back-monitor Configuration 9.1.2. Further Information 9.6. Relay 9.1.1. Overview 9.1.2. back-relay Configuration 9.1.2. Further Information 9.7. Perl/Shell 9.1.1. Overview 9.1.2. back-perl/back-shell Configuration 9.1.2. Further Information 9.8. SQL 9.1.1. Overview 9.1.2. back-sql Configuration 9.1.2. Further Information 9.9. Senarios 10. Overlays 10.1. Access Logging 10.1.1. Overview 10.1.2. Access Logging Configuration 10.2. Audit Logging 10.2.1. Overview 10.2.2. Audit Logging Configuration 10.3. Constraints 10.3.1. Overview 10.3.2. Constraint Configuration 10.4. Dynamic Directory Services 10.4.1. Overview 10.4.2. Dynamic Directory Service Configuration 10.5. Dynamic Groups 10.5.1. Overview 10.5.2. Dynamic Group Configuration 10.6. Dynamic Lists 10.6.1. Overview 10.6.2. Dynamic List Configuration 10.7. The Proxy Cache Engine 10.7.1. Overview 10.7.2. Proxy Cache Configuration 10.7.1.1. Setting cache parameters 10.7.2.1. Defining attribute sets 10.7.3.1. Specifying cacheable templates 10.7.4.1. Example 10.8. Password Policies 10.8.1. Overview 10.8.2. Password Policy Configuration 10.9. Referential Integrity 10.9.1. Overview 10.9.2. Referential Integrity Configuration 10.10. Return Code 10.10.1. Overview 10.10.2. Return Code Configuration 10.11. Rewrite/Remap 10.11.1. Overview 10.11.2. Rewrite/Remap Configuration 10.12. Sync Provider 10.12.1. Overview 10.12.2. Sync Provider Configuration 10.13. Translucent Proxy 10.13.1. Overview 10.13.2. Translucent Proxy Configuration 10.14. Attribute Uniqueness 10.14.1. Overview 10.14.2. Attribute Uniqueness Configuration 10.15. Value Sorting 10.15.1. Overview 10.15.2. Value Sorting Configuration 10.16. Overlay Stacking 10.16.1. Overview 10.16.2. Example Senarios 11. Schema Specification 11.1. Distributed Schema Files 11.2. Extending Schema 11.2.1. Object Identifiers 11.2.2. Naming Elements 11.2.3. Local schema file 11.2.4. Attribute Type Specification 11.2.5. Object Class Specification 11.2.6. OID Macros 12. Security Considerations 12.1. Network Security 12.1.1. Selective Listening 12.1.2. IP Firewall 12.1.3. TCP Wrappers 12.2. Data Integrity and Confidentiality Protection 11.2.1. Security Strength Factors 12.3. Authentication Methods 12.3.1. "simple" method 12.3.2. SASL method 13. Using SASL 13.1. SASL Security Considerations 13.2. SASL Authentication 13.2.1. GSSAPI 13.2.2. KERBEROS_V4 13.2.3. DIGEST-MD5 13.2.4. Mapping Authentication Identities 13.2.5. Direct Mapping 13.2.6. Search-based mappings 13.3. SASL Proxy Authorization 13.3.1. Uses of Proxy Authorization 13.3.2. SASL Authorization Identities 13.3.3. Proxy Authorization Rules 14. Using TLS 14.1. TLS Certificates 14.1.1. Generic Certificate Generation Methods 14.1.2. Server Certificates 14.1.3. Client Certificates 14.2. TLS Configuration 14.2.1. Server Configuration 14.2.2. Client Configuration 15. Constructing a Distributed Directory Service 15.1. Subordinate Knowledge Information 15.2. Superior Knowledge Information 15.3. The ManageDsaIT Control 16. Replication 16.1. Replication Strategies 16.2. Replication types 16.2.1. slurpd replication 16.2.2. syncrepl replication 16.2.3. delta-syncrepl replication 16.2.4. N-Way Multi-Master 16.2.5. MirrorMode 16.3. Replication with Slurpd 16.3.1. Overview 16.3.2. Replication Logs 16.3.3. Command-Line Options 16.3.4. Configuring slurpd and a slave slapd instance 16.3.4.1. Set up the master slapd 16.3.4.2. Set up the slave slapd 16.3.4.3. Shut down the master server 16.3.4.4. Copy the master slapd's database to the slave 16.3.4.5. Configure the master slapd for replication 16.3.4.6. Restart the master slapd and start the slave slapd 16.3.4.7. Start slurpd 16.3.5. Advanced slurpd Operation 16.3.5.1. Replication errors 16.3.5.2. One-shot mode and reject files 16.4. LDAP Sync Replication 16.4.1. The LDAP Content Synchronization Protocol 16.4.2. Syncrepl Details 16.4.3. Configuring Syncrepl 16.4.3.1. Set up the provider slapd 16.4.3.2. Set up the consumer slapd 16.4.3.3. Start the provider and the consumer slapd 16.4.3.4. Delta SyncRepl Replication Configuration 16.5. N-Way Multi-Master 16.6. MirrorMode 17. Maintenance 17.1. Directory Backups 17.2. Berkeley DB Logs 17.3. Checkpointing 18. Monitoring 18.1. Monitor configuration via cn=config(5) 18.2. Monitor configuration via slapd.conf(5) 18.3. Accessing Monitoring Information 18.4. Monitor Information 18.4.1. Backends 18.4.2. Connections 18.4.3. Databases 18.4.4. Listener 18.4.5. Log 18.4.6. Operations 18.4.7. Overlays 18.4.8. SASL 18.4.9. Statistics 18.4.10. Threads 18.4.11. Time 18.4.12. TLS 18.4.13. Waiters 19. Tuning 19.1. Performance Factors 19.1.1. Memory 19.1.2. Disks 19.1.3. Network Topology 19.1.4. Directory Layout Design 19.1.5. Expected Usage 19.2. Indexes 19.3. Tuning Logging 19.4. BDB/HDB database cache size 20. Troubleshooting 20.1. Checklist 20.2. User or Software errors? 20.3. How to contact the OpenLDAP project 20.4. How to present your problem 20.5. Commercial Support A. Configuration File Examples A.1. slapd.conf A.2. ldap.conf A.3. a-n-other B. Glossary A.1. Terms A.2. Related Organizations A.3. Related Products A.4. References C. Generic configure Instructions D. OpenLDAP Software Copyright Notices C.1. OpenLDAP Copyright Notice C.2. Additional Copyright Notice C.3. University of Michigan Copyright Notice R. OpenLDAP Public License Thanks, Gavin. -- 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/

1 1

Automatic code documentation: doxygen?
by Pierangelo Masarati 08 Mar '07

08 Mar '07

I'm trying to automatically document OpenLDAP code. Since I ha previous experience with doxygen and C++, which looks pretty reliable and versatile, I made some experiments, with less than encouraging results. One of the key issues I'm facing is the need to handle the somewhat quite involved use we often make of #defines. Doxygen allows sophisticated pre-processing, with lots of flexibility, which required a bit of carving before, for instance, getting anything out of slap.h. Another issue is that we made some inconsistent use of typedefs for structures. For example, many key structures are typedef'd as typedef struct foo bar; This is very misleading, because doxygen documents that structure as "foo", while most of the times it's used as "bar". Maybe renaming typedefs like typedef struct bar bar; would simplify things, so that the original and the typedef'd names match. I'd rename things only in those cases the original name is never used in practice. For example, I wouldn't touch "struct berval", since it's used almost everywhere, while "BerValue" is seldom used. On the contrary, I don't think "struct slap_attr_name" is ever used in the code, while its typedef "AttributeDescription" is consistently used everywhere. The same is true for "Connection", "Operation", "SlapReply" and so. If anyone is interested in doxygen docs, I'll be happy to share my Doxyfile as soon as it's consolidated. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

3 4

A Survey on Defect Management Practices in Free/Open Source Software (fwd)
by Quanah Gibson-Mount 06 Mar '07

06 Mar '07

------------ Forwarded Message ------------ Date: Wednesday, March 07, 2007 8:22 PM +0530 From: anugupta(a)pu.ac.in To: vnc-tight-devel(a)lists.sourceforge.net Subject: A Survey on Defect Management Practices in Free/Open Source Software Dear VNC Tight Contributors, I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenance in carrying out a study to identify practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta(a)pu.ac.in anugupta98(a)gmail.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ VNC-Tight-devel mailing list VNC-Tight-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel ---------- End Forwarded Message ---------- -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

filter preprocessing for performance improvement
by Eric Irrgang 05 Mar '07

05 Mar '07

I wonder if it might be reasonable for the slapd frontend to do some preprocessing of search filters to recognize no-ops and such. Most specifically, any search filter of the form (&(objectclass=*)(filter2)) can be reduced to (filter2), right? I have a problem in that the first time someone performs a search for 'objectclass=*' after slapd is restarted, the server is really bogged down for a while. Once the search has completed once, this is not a problem. I assume that's due to the IDL cache. However, I currently have to keep the server unavailable after restarting slapd for upwards of half an hour while I do an 'objectclass=*' search the first time. I suppose a followup might be some preevaluation of ACLs before performing easily-recognized searches. For instance, the backend should not have to cope with a search for objectclass=* if the user doesn't have read access to anything as is often the case with an anonymous bind. -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

5 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel