openldap-devel

openldap-devel@openldap.org

1 participants
1421 discussions

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 07 Mar '07

07 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

deprecated functions
by Quanah Gibson-Mount 02 Mar '07

02 Mar '07

I'm interested in updating Net::LDAPapi so that it no longer uses the deprecated C API. ldap.h is nicely commented on the replacement functions for just about all of the deprecated functions, except for: ldap_sort_entries ldap_sort_values ldap_sort_strcasecmp of which Net::LDAPapi only uses ldap_sort_entries. Is there a replacement function for this? If not, any thoughts on what the steps are to duplicate that functionality? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

2 2

Re: [Kerberos] Kerberos + OpenLDAP (fwd)
by Quanah Gibson-Mount 01 Mar '07

01 Mar '07

To keep OpenLDAP in on this loop... --Quanah ------------ Forwarded Message ------------ Date: Thursday, March 01, 2007 5:10 PM -0500 From: Sam Hartman <hartmans(a)mit.edu> To: Quanah Gibson-Mount <quanah(a)stanford.edu> Cc: Apache Directory Developers List <dev(a)directory.apache.org>, g.w(a)hurderos.org, krbdev(a)MIT.EDU Subject: Re: [Kerberos] Kerberos + OpenLDAP 1) I'd really like to see interested individuals work on the LDAP schema in the IETF. The effort has floundered for lack of people driving it. 2) I'd really love to see an ldap plugin that used some schema and called kadm5_* interfaces--I.E. a way to replace kadmind with openldap even in situations where the ldap kdb layer was not used. ---------- 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

Re: Config file statement ordering (Was: (ITS#4848) Another slapd startup segfault)
by Howard Chu 26 Feb '07

26 Feb '07

Pierangelo Masarati wrote: > For back-meta, I'd like to create children entries for each target; in > this case, an overlay with specific per-target behavior, would need to > either create a similar tree, or to append entries to targets'. This is > really going to mess up back-config. Still, I think having separate > entries makes sense. That's how I made, for example, the monitor > interface to "foobar" overlay... Speaking of which, ITS#4789, were you actually suggesting that back-monitor also use olcDatabase={x}foo to name its database entries? That would change its apparent behavior quite a bit from 2.3. As I mentioned before, I chose not to use a cn=Databases container in back-config because I didn't want to have to deal with creating a lot of do-nothing infrastructure entries. Philosophically I also prefer RDNs that use task-specific attributes; I've always thought cn was too overused... And if we're using olcDatabase, then e.g. olcDatabase={1}foo,cn=databases,cn=monitor is just redundant information, we already know foo is a database so we don't need the container to remind us of that. -- -- 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/

2 1

Config file statement ordering (Was: (ITS#4848) Another slapd startup segfault)
by Pierangelo Masarati 24 Feb '07

24 Feb '07

ando(a)sys-net.it wrote: > The above had nothing to do with your problem. Your problem is related > to the fact that you intermixed overlay and database configuration > statements, so the idletimeout statement after the accesslog overlay > instantiation was causing invalid memory write (beyond the private data > of the accesslog overlay instead of in the private data of the bdb > database) resulting in heap corruption. > > Maybe it hasn't been stressed enough, but the order of directives is: I believe the problem is here: ========================================================================= diff -u -r1.341.2.25 config.c --- servers/slapd/config.c 8 Feb 2007 12:31:24 -0000 1.341.2.25 +++ servers/slapd/config.c 24 Feb 2007 13:29:42 -0000 @@ -308,13 +308,28 @@ return(0); } if(arg_type & ARG_OFFSET) { - if (c->be && (!overlay_is_over(c->be) || - ((slap_overinfo *)c->be->bd_info)->oi_orig == c->bi)) - ptr = c->be->be_private; - else if (c->bi) + if ( c->be ) { + if (!overlay_is_over(c->be) || + ((slap_overinfo *)c->be->bd_info)->oi_orig == c->bi) + { + ptr = c->be->be_private; + + } else { + snprintf( c->msg, sizeof( c->msg ), + "<%s> statement outside scope " + "(after overlay?)", + c->argv[0] ); + Debug(LDAP_DEBUG_CONFIG, "%s: %s!\n", + c->log, c->msg, 0); + return(ARG_BAD_CONF); + } + + } else if ( c->bi ) { ptr = c->bi->bi_private; - else { - snprintf( c->msg, sizeof( c->msg ), "<%s> offset is missing base pointer", + + } else { + snprintf( c->msg, sizeof( c->msg ), + "<%s> offset is missing base pointer", c->argv[0] ); Debug(LDAP_DEBUG_CONFIG, "%s: %s!\n", c->log, c->msg, 0); ========================================================================= that is, if both the database and the overlay allow back-config, there are cases in which config_set_vals() can be called with (arg_type & ARG_OFFSET) and the c->be points to the database's structure while c->bi points to the overlay's structure, and the config statement refers to the database although appearing after the overlay's instantiation. This is Bad (TM) and should be avoided. However, for example, I have special needs in back-meta that require to allow overlay instantiation __before__ the database configuration is complete (in that case, I need an overlay to be instantiated before targets are defined, so that the overlay can get per-target configuration parameters much like the underlying database does). This may defer introduction of back-config support for back-meta. Comments? 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 3

openldap-2.4.4alpha available [corrected]
by OpenLDAP Project 17 Feb '07

17 Feb '07

See http://www.openldap.org/software/download/ Please report problems using the Issue Tracking System. http://www.openldap.org/its/ -- OpenLDAP Project [previous post had incorrect version number]

1 0

openldap-2.4.3alpha available
by OpenLDAP Project 17 Feb '07

17 Feb '07

See http://www.openldap.org/software/download/ Please report problems using the Issue Tracking System. http://www.openldap.org/its/ -- OpenLDAP Project

1 0

liblber additions
by Howard Chu 16 Feb '07

16 Feb '07

We have a port of GNUtls support for OpenLDAP underway. Their certificate DN parsing APIs are pretty bad. Rather than use their APIs I've modified libldap's ldap_X509dn2bv function to take a DN in DER form, directly from the certificate, and parse it directly using liblber. For that purpose I've needed to add a few new tag definitions as well as a decoder for BER-encoded OIDs. Not sure if these should be ber_pvt definitions or just public. Since a typical LDAP program rarely is faced with real ASN.1 structures it seems we don't need to expose them. Comments? Also as a side-effect, we can support certificate parsing, to implement the certificate-related component matching rules, without needing OpenSSL or any other crypto library. I.e., I have a complete certificate parser using liblber. (The code is trivial. We probably should have done this from the start...) Something I'd like to revisit - when using liblber and parsing in-place, our parse is destructive because we NUL-terminate all octet strings. I'm considering changing this behavior, to leave the original BER data unmodified. At present it seems this change would have the greatest effect on Debug output, where we pass ber->bv_val's for printing without any further qualification. Any thoughts? as an aside - the fact that GNUtls' certificate DN handling is broken is worrisome, since issuer DNs are an integral part of certificate path validation. Until we have time to dig deeper into that code and patch all the problems, it would be a good idea to avoid using GNUtls. -- -- 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/

2 1

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