openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: commit: ldap/servers/slapd/back-sock config.c
by Howard Chu 03 Feb '11

03 Feb '11

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-sock > > Modified Files: > config.c 1.11 -> 1.12 > > Log Message: > As an overlay, always return SLAP_CB_CONTINUE Alternatively, we can use the actual return code from the external program, and document that those programs should return SLAP_CB_CONTINUE if they don't want to override the normal flow of processing. Thoughts? We could write a similar wrapper for back-perl, but a few other loose ends need to be addressed there still. First, this business of arbitrary junk in slapd.conf being fed into the perl module - I suggest this be replaced by an actual "perlconfig" directive whose arguments are passed on. Then we can convert all of that to cn=config without any further mess. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 3

LDAP Transactions RFC alignment
by Daniel Otero 03 Feb '11

03 Feb '11

Hi, I'm interested in implementing LDAP Transactions as specified in RFC 5805. I've checked there is something implemented in the client side, slapd and back-bdb dated in 2006, as the RFC is of March 2010 I would like to know how aligned is the current implementation in branch 2.4 with regards the RFC 5805. I also use the back-meta to proxy to remote LDAP servers, AFAIK currently there is no support for LDAP transactions in back-meta. Is there any plan to extend the back-meta with support for LDAP transactions? Regards /Dani

3 2

Contradictory comments in slap_cleanup_play()
by Hallvard B Furuseth 02 Feb '11

02 Feb '11

Since result.c rev 1.287 (ando), slap_cleanup_play() has said: /* a new callback has been inserted * after the existing one; repair the list */ /* a new callback has been inserted * in place of the existing one; repair the list */ 1.287 introduced 2nd comment. I assume 1st should be removed, rather than joining them to "...after or in place of the existing one"? -- Hallvard

1 0

Re: commit: ldap/servers/slapd/back-ldap search.c
by Howard Chu 29 Jan '11

29 Jan '11

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-ldap > > Modified Files: > search.c 1.273 -> 1.274 > > Log Message: > handle undefined objectClass values in search filters (ITS#6814) Hmm. ava.c has been using the "(?attr=value)" format and SLAPD_FILTER_UNDEFINED flag since 2006. Munging ought to handle any attr=value, not just "(?objectclass=)". Seems like we should just add a flag to filter2bv that tells it to generate a regular filter string that libldap will parse and forget about this other munging process. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: commit: ldap/servers/slapd/back-sock compare.c modify.c
by Howard Chu 28 Jan '11

28 Jan '11

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-sock > > Modified Files: > compare.c 1.8 -> 1.9 > modify.c 1.6 -> 1.7 > > Log Message: > Fix a couple FIXMEs: use ldif_put to allow for binary values in > compare and modify. Note that line wrapping is disabled; presumably > existing code expects the compare argument to use only a single line. > The manpage should be updated to note whether standard LDIF with > default line wrapping is expected or not. (Add uses default width already.) The same patch and considerations should also be applied to back-shell, but I'm not bothering at the moment since I consider back-shell obsolete. Anyone else is welcome to patch it if they feel like it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#6801
by Quanah Gibson-Mount 26 Jan '11

26 Jan '11

Should this new feature be added to the RE24 queue? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

More items for RE24
by Hallvard B Furuseth 26 Jan '11

26 Jan '11

ITS#6760 is in RE24, though I never marked it Test. Did someone review it as requested in the ITS? Wishes: ITS#6739 broken do_syncrep2(). Partial fix which can stand alone, so this no longer breaks: CPPFLAGS=-DLDAP_THREAD_DEBUG ./configure ./run -b ldif test019 crashed because a thread unlocked another thread's mutex. ITS#6792 (rwm suppressed LDAP response message). ITS#6793 (bad free in back-ldap on matchedDN change). Could add ITS#6727 to the ITS#6632 line in CHANGES, it's a dup. I've marked Release. -- Hallvard

3 4

RE24 testing call #3 (OL 2.4.24)
by Quanah Gibson-Mount 17 Jan '11

17 Jan '11

Fixes to the dreaded solaris hang with back-monitor included. Please test. :) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

7 12

Re: commit: ldap/servers/slapd/overlays rwm.c
by Hallvard B Furuseth 17 Jan '11

17 Jan '11

ando(a)OpenLDAP.org writes: > rwm.c 1.138 -> 1.139 > make sure rwm_response returns SLAP_CB_CONTINUE (ITS#6792, as indicated by Hallvard) Why the new 'default: rwm_matched( op, rs );'? So you can rewrite matchedDN in responses to Abandon and Unbind? :-) -- Hallvard

1 0

librewrite & co vs. logging & ldap-int.h
by Hallvard B Furuseth 13 Jan '11

13 Jan '11

The ITS#6625 patch causes preprocessor warnings about conflicts with ldap-int.h, so I'm looking again at old ITS#5421 to kill off #include "...libldap/ldap-int.h" These occur in librewrite, rwm, back-ldap and back-meta. The #include is for two things: Expose struct ldapmsg & LDAP_FREE, the need of which I've just removed in HEAD, and set up libldap logging. I expect the slapd components just as well can drop the #include and use slapd logging? back-*/search.c then need lber-int.h instead. librewrite still needs the #define ldap_debug in ldap-int.h. Instead we could either: (1) use liblber logging in librewrite, (2) or throw the code LDAP_INT_IN_KERNEL .. #endif /* LDAP_DEBUG */ out of ldap-int.h to a separate file, either include/ldap_log.h or something like libldap/ldap-int-log.h. This file would not expose structs with different definitions depending on LDAP_R_COMPILE & co. Since the file when not LDAP_INT_IN_KERNEL does need to refer ldap_debug to ldap_int_global_options.ldo_debug, that can be done with: /* This struct starts with the same members as ldapoptions */ struct ldapoptions_prefix { short ldo_valid; int ldo_debug; }; #define ldap_debug \ (*(int *) ((char *) &ldap_int_global_options \ + offsetof(struct ldapoptions_prefix, ldo_debug))) struct ldapoptions; LDAP_V ( struct ldapoptions ) ldap_int_global_options; Opinions? Put it in ldap-int.h, or ldap_log.h? Maybe the latter only if #defined LDAP_LIBRARY_LOGGING (defined by the user)? -- Hallvard

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel