openldap-devel

openldap-devel@openldap.org

1416 discussions

OpenLDAP Overlay API
by micky 11 Apr '08

11 Apr '08

Hello, exists a OpenLDAP API Documentation to develop a Overlay (like smbk5pwd)? We just started to explore the source-code (smbk5pwd.c), but we noticed that the struct's and function syntax aren't easy to unterstand - We need a description. Like the smbk5pwd module, we want to develop a analog module for Asterisk. -- Greets Michael

3 2

Proxied attribute descriptions initialization
by Jonathan Clarke 11 Apr '08

11 Apr '08

The feature introduced in 2.3 [1] to map undefined attributes from proxies as "proxied" attribute descriptions enables searches with filters using attributes that have no local definition. For example, given slapd with a back-ldap pointing to an Active Directory (AD) server, this features makes searches with a filter of "(samAccountName=login)" work with no extra configuration, and without explicitly adding samAccountName to local schema. However, such searches will be passed on to the AD server only if a previous search result contained the attributes in question (samAccountName) and was not based on a filter containing the attribute. Otherwise, the filter is considered invalid and replaced with "(?=undefined)" in the logs, and passed to the AD server as "(!(objectclass=*))". This means that the same search, on the same data, can return different results at different times, depending on whether or not a previous search had succeeded and returned given attribute (samAccountName). Currently, we have worked around this problem by either: - running a bogus ldapsearch just after starting slapd, that returns this attribute - adding the attribute description to a local schema What is the general opinion on working around this issue? Might there be a way to implement something that ensures this happens automatically? I'm thinking of delegating filter checking to proxied servers for ldap backends, or automatically fetching schemas from them... Any experience, ideas? Thanks in advance. Best regards, Jonathan [1]http://www.openldap.org/its/index.cgi/Software%20Enhancements?id=3959 -- Jonathan Clarke Open Source Software Assurance (OSSA) - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

2 1

Socket-level timeouts?
by Chris Adams 11 Apr '08

11 Apr '08

We've noticed hard failures on both our Linux and Mac workstations when an LDAP server fails in a way which causes it to stop responding but leave a connection open (e.g. lock contention, disk failure). This usually ends up requiring the system to be rebooted because a key system process will probably have made a call which is waiting on a read() which might take days to fail. I've created a patch simply calls setsockopt() to set SO_SNDTIMEO| SO_RCVTIMEO when LDAP_OPT_NETWORK_TIMEOUT has been set. This appears to produce the desired result on Linux (both with pam_ldap and the ldap utilities) and OS X (within the DirectoryService plugin). Is there a drawback to this approach which I've missed? It appears that the issue has come up in the past but there's no solution that I can see (certainly nothing else uses socket-level timeouts). I'd like to find a solution for this as it's by far the biggest source of Linux downtime in our environment. Thanks, Chris

4 7

security-related gcc bug
by Michael Ströder 08 Apr '08

08 Apr '08

HI! Did anyone already take not of this? Are parts of OpenLDAP's code affected? [Bug c/27180] New: pointer arithmetic overflow handling broken http://gcc.gnu.org/ml/gcc-bugs/2006-04/msg01297.html US-CERT - Vulnerability Note VU#162289: gcc silently discards some wraparound checks http://www.kb.cert.org/vuls/id/162289 Ciao, Michael.

5 9

OpenLDAP Developer's Day - Dublin 2008 (early call for participation)
by Howard Chu 07 Apr '08

07 Apr '08

The OpenLDAP Project is tentatively planning on hosting a developers' day conference in Dublin, Ireland in late July / early August (most likely weekend of August 2-3, and August 4). Those interested in speaking at the conference are encouraged to contact <project(a)openldap.org> with a specific proposal (title, abstract, duration). Discounts will be available to speakers. A formal (and more widely distributed) call for participation will be made once conference details are firmed up a bit (like we fix the date...). Organizations interested in sponsoring this event are encouraged to contact project(a)openldap.org. Currently we've got an agreement with HEAnet to host the event, and Symas will be sponsoring some of the activity. At the moment it's been suggested that we conduct two events - an ODD conference with presentations as we've done in the past, and also a code-sprint where we all grind thru a bunch of code together. Feel free to email me with suggestions. -- -- 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

glue entries
by Hallvard B Furuseth 01 Apr '08

01 Apr '08

What are glue entries and how do they work in OpenLDAP? The manageDSAit code in back-bdb is intertwined with is_entry_glue() calls which I don't know what to make of. The only glue I can see bdb create seems to be a fake entry named "" if that is the database suffix. And I don't see any mention of glue entries in other backends. -- Hallvard

2 1

Re: commit: ldap/servers/slapd/overlays auditlog.c
by Pierangelo Masarati 29 Mar '08

29 Mar '08

Rein Tollevik wrote: >> On a slightly related note, but I only noticed because it's near the >> patched lines - if sizeof(time_t) != sizeof(long) then the fprintf >> argument is going to break. I think you should simply keep stamp >> declared as long and let the compiler promote the return value from >> slap_get_time() if it needs to. > > Yes, that is a potential problem that should be fixed. Although I would > prefer it as an explicit cast, as that imho must better tells the random > reader that the programmer har thought about it. I.e, to keep stamp as > a long variable and cast the slap_get_time() return value, or as I would > prefer it to cast the stamp argument in the fprintf statements. I've fixed it the other way. I prefer to use types as they should, and only cast them for printing reasons, to make clear where the "hack" is. In this case, the sole purpose was printing it, so it would have been fine the other way 'round as well, though. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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 ---------------------------------------

1 0

Re: commit: ldap/servers/slapd/overlays auditlog.c
by Howard Chu 29 Mar '08

29 Mar '08

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > Modified Files: > auditlog.c 1.17 -> 1.18 > > Log Message: > avoid system call when not needed (ITS#5441) On a slightly related note, but I only noticed because it's near the patched lines - if sizeof(time_t) != sizeof(long) then the fprintf argument is going to break. I think you should simply keep stamp declared as long and let the compiler promote the return value from slap_get_time() if it needs to. -- -- 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

commit sizes, coding conventions, and back-ldif
by Hallvard B Furuseth 23 Mar '08

23 Mar '08

My patch to back-ldif/ldif.c for ITS#5408 is larger than the ldif.c file itself, which has left me wondering what to do with monster pathces: Should they be split up in stepwise commits so it's easier to see the logic of each change? When reading patches, I vastly prefer them split up that way, but I don't know how much that is worth in the CVS tree. E.g. first a commit which preserves the program logic including bugs and just moves code around, then one with a bugfix which now can be small and easy to read, then one for the next bug, and so on. Besides being more work, one problem with that approach is that one can make an error in an poorly tested intermediate version - since that version was never intended to be used anyway. Also I don't know what impact it has on CVS merging. Also, what's the thereshold for when it makes sense to reformat and rearrange code just for the sake of readability? back-ldif ihas no consistent coding style. Normally it's "don't reformat, it makes CVS merges harder". In this case it was easy with some of it - I touch more than half of the lines anyway, so I could just as well reformat those and a few more to something closer to the OpenLDAP conventions (to the degree I understand them). But maybe in this case I should just as well reformat it all, and maybe also it's a good time time to split back-ldif up in 9 files of ~100-300 lines instead of one of ~1500 lines. (Regarding CVS merges, the HEAD and RE24 versions are equal, but RE23 differs.) Another extreme example was a recent change to a big chunk of code, where the only change was to wrap the code in a new if-test and indent it. It would have been nice with a a comment in the commit, or a 1-line commit + a cosmetic commit. Regarding formatting, when I do it I'd prefer to do it right - but I've never quite figured out what the preferred conventions are. We've had a style threads before but I don't remember if any of them got very far. So I thought I'd list some rules and confusions of my own that I've noticed. * Generous whitespace: - Around parens in control statements - "if ( x )" etc. - Inside non-empty parens in function calls, sometimes sizeof, sometimes inside []. - Usually around binary operators. However often but not always whitespace between two parens are omitted - e.g. "foo( bar( baz ))". Is there some preferred guideline about that? How about whitespace around parens that are for grouping? E.g. "if ( (ch = getc(f)) != EOF )". * Similarly generous use of {} for if statements etc, usually used even when enclosing just a single statement. * Indent 1 tab for continuation lines with the same paren level, e.g. x = foo( bar, baz ); y = one ? two : three; BTW, emacs will format this the OpenLDAP way: wups( foo, bar ); but if there is anything after the '(' it aligns bar with it: wups( foo, bar ); OpenLDAP code often does put arguments after the '(' but to my eyes it looks easier to read without that, in addition to making emacs happy. Complex multi-line statements require more creativity, but I can't tell what, if any, ideas lie behind their indentation (beyond trying to avoid such statements). Don't know if e.g. this is OpenLDAPpy: if ( (one( two, three ) && (four || (five && six))) ) * Tab-width = 4 columns. Makes a difference for when to break lines (keeping line length < 80), how to align comments after code on a line, and to align declarations and multi-line statements. It doesn't hurt to try to keep code nice-looking with tab width 8 too. (E.g. comments above statements instead of aligned to the right, and often do not align variables in declarations.) * Indent with tabs, not spaces. * Usually align comments/decls to the right of code with tabs too, but not always. (If we used space to align after code, it would stay aligned regardless of tab-width.) * Function names at first column in function definitions. -- Hallvard

2 3

printing Sleepycat version always
by Aaron Richton 22 Mar '08

22 Mar '08

[purposefully on -devel for discussion] Any opinions on: --- init.c~ 2008-03-12 10:02:44.000000000 -0400 +++ init.c 2008-03-12 10:03:16.000000000 -0400 @@ -712,7 +712,7 @@ return -1; } - Debug( LDAP_DEBUG_TRACE, LDAP_XSTRING(bdb_back_initialize) + Debug( LDAP_DEBUG_ANY, LDAP_XSTRING(bdb_back_initialize) ": %s\n", version, 0, 0 ); } I'm definitely one for 'quiet' software, but knowing the version of libdb is a really nice detail when assisting users of OpenLDAP. This would make it that much easier to have them find it. I'd argue there's a bit of precedent: main.c: Debug( LDAP_DEBUG_ANY, "%s", Versionstr, 0, 0 ); The negative, of course, is the noise. But what's ~60 bytes in this day and age?

5 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel