openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by thomas.wunder＠swt-bamberg.de 12 Apr '10

12 Apr '10

Full_Name: Thomas Wunder Version: 2.4.17 OS: debian sqeueeze amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.13.106.69) Hi! I'm currently using the rwm overlay to filter the objects from my ou=students,dc=uni-bamberg,dc=de directory by their "o"-attribute and project the result to ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de Therefore I use the following section within my slapd.conf (before the "database hdb..." section): database relay suffix "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" overlay rwm #rwm-rewriteEngine on rwm-suffixmassage "ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de" "ou=students,dc=uni-bamberg,dc=de" rwm-rewriteContext bindDN rwm-rewriteRule ".*" "cn=ldapadmin,dc=uni-bamberg,dc=de" ":@" rwm-rewriteContext searchFilter rwm-rewriteRule "(.*)" "(&(o=swt)$1)" ":@I" searchFilter rewriting works perfectly but I also need to rewrite the bindDN as every operation within ou=students,dc=uni-bamberg,dc=de needs to be carried out by a particular user (cn=ldapadmin,dc=uni-bamberg,dc=de) (the reason is that i don't want any user other than ldapadmin to be able to write ou=students,dc=uni-bamberg,dc=de but they should be able to modifiy entries within ou=students,ou=people,ou=swt,ou=wiai,dc=uni-bamberg,dc=de) according to the logs and the error reply messages there seems to be no binndn rewriting done... It looks like the rule never matches. Is my rule not general enough to match each possible bindDN-String? Is "cn=ldapadmin,dc=uni-bamberg,dc=de" (replacement string for the bindDN) not well formatted (does it expect something else)? Does the overlay "relay" prevent the replacement of the bindDN? As you can see I don't have any idea what might be causing my problem and I hope you can help me.

1 0

Re: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by hyc＠symas.com 11 Apr '10

11 Apr '10

bcolston(a)xtec.com wrote: > Provider slapd configuration (partial): > serverID 000 > database bdb > suffix "dc=authentx" > rootdn "SUPPRESSED" > rootpw SUPPRESSED > directory /authentx/db/ldap/authentx-sync1 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 5000 This patch will probably work: diff -u -r1.309 syncprov.c --- syncprov.c 21 Jan 2010 12:33:21 -0000 1.309 +++ syncprov.c 12 Apr 2010 01:33:02 -0000 @@ -1878,7 +1878,7 @@ } /* Add any log records */ - if ( si->si_logs && op->o_tag != LDAP_REQ_ADD ) { + if ( si->si_logs ) { syncprov_add_slog( op ); } leave: ldap_pvt_thread_mutex_unlock( &si->si_resp_mutex ); But I have not tested it. The session log was originally only intended to record deletes, since they require the most work to find otherwise. Recording adds is just a shortcut since the original behavior works as designed. -- -- 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

Re: (ITS#6498) SLAPI functions missing
by hyc＠symas.com 11 Apr '10

11 Apr '10

maci(a)satgnu.net wrote: > Full_Name: Marcel Wysocki > Version: 2.4.21 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.79.126.162) > > > I noticed that all of the SLAPI functions do manipulate LDAPMod** are missing. > from the fedora ds slapi-plugin.h: > there might be some more missing. most of it can be found in fedora ds's > modutils.c > should be worth porting to openldap Patches welcome. If you're suggesting a copy/paste from FedoraDS's code then the patch must be submitted by someone who has ownership rights on the Fedora code. -- -- 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

Re: (ITS#6483) [PATCH] Properly use #elif
by hyc＠symas.com 11 Apr '10

11 Apr '10

delphij(a)FreeBSD.org wrote: > Full_Name: Xin LI > Version: -HEAD > OS: FreeBSD/amd64 > URL: http://people.freebsd.org/~delphij/misc/openldap-elif.diff > Submission from: (NULL) (206.40.55.65) > > > OpenLDAP uses several #elif to test if a macro is being defined, which should be > spelled as #elif defined. > > Here is a patch against CVS -HEAD. > > Index: include/ac/regex.h > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/regex.h,v > retrieving revision 1.20 > diff -u -p -u -p -r1.20 regex.h > --- include/ac/regex.h 21 Jan 2009 23:40:18 -0000 1.20 > +++ include/ac/regex.h 1 Mar 2010 20:12:52 -0000 > @@ -28,7 +28,7 @@ > */ > #error "No POSIX REGEX available." > > -#elif HAVE_GNUREGEX_H > +#elif defined(HAVE_GNUREGEX_H) > /* system has GNU gnuregex.h */ > # include<gnuregex.h> > #else That patch is incorrect. Autoconf HAVE_xx macros must be defined to 1 to actually be used, some scripts may also define them to 0. The current test is correct. Closing this ITS. -- -- 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

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by hyc＠symas.com 11 Apr '10

11 Apr '10

crispy(a)cluenet.org wrote: > Hi, any word on if this can be incorporated? Committed in HEAD, thanks for the patch. -- -- 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

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

>> >>> Sorry about that. You can find it here: >>> http://rmeggins.fedorapeople.org/ldifutil.c >> >> Gotit, thanks. I have one first comment: the public API does not >> generally expose the memory context. I'm renaming >> ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating >> the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. > > tested and applied to HEAD; please test. Thanks, p. More comments: 1) perhaps it may be worth providing a function that converts a LDIFRecord structure into a string, and one that sends it to a stream 2) I note you put LDAPMod **lr_mods; /* list of mods for LDAP_REQ_MODIFY, LDAP_REQ_ADD */ struct berval lr_newrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ struct berval lr_newsuperior; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ int lr_deleteoldrdn; /* LDAP_REQ_MODDN, LDAP_REQ_MODRDN, LDAP_REQ_RENAME */ /* the following are for future support */ struct berval lr_extop_oid; /* LDAP_REQ_EXTENDED */ struct berval lr_extop_data; /* LDAP_REQ_EXTENDED */ struct berval lr_cmp_attr; /* LDAP_REQ_COMPARE */ struct berval lr_cmp_bvalue; /* LDAP_REQ_COMPARE */ in the structure; the last four are not used right now. I think it would make sense to group struct members by op in substructures, and then put them in a union, to stress the fact that they're mutually exclusive. Much like Howard did for the corresponding substructures in the Operation struct in slapd. p.

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 11 Apr '10

11 Apr '10

rmeggins(a)redhat.com wrote: > Any update on this? Sorry I must've missed your last reply, I thought we were still waiting on you. Why is pem_mod_name needed as an independent variable? Since it's const I presume it will not be changing in the future? (Not asking for a change here, just want to understand its purpose.) Actually, since it and pem_library are only used once each, I would probably just #define it instead. But again, just want to know first how constant it really is. I've committed the patch as-is. If any other tweaks are needed let us know. Thanks for working on this. -- -- 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

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> >> Sorry about that. You can find it here: >> http://rmeggins.fedorapeople.org/ldifutil.c > > Gotit, thanks. I have one first comment: the public API does not > generally expose the memory context. I'm renaming > ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating > the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. tested and applied to HEAD; please test. Thanks, p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by masarati＠aero.polimi.it 11 Apr '10

11 Apr '10

> Sorry about that. You can find it here: > http://rmeggins.fedorapeople.org/ldifutil.c Gotit, thanks. I have one first comment: the public API does not generally expose the memory context. I'm renaming ldap_parse_ldif_record() as ldap_parse_ldif_record_x(), and eliminating the void *ctx arg from ldap_parse_ldif_record(), if you don't mind. p.

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by richm＠stanfordalumni.org 11 Apr '10

11 Apr '10

On Sun, Apr 11, 2010 at 10:07 AM, <masarati(a)aero.polimi.it> wrote: >> Full_Name: Rich Megginson >> Version: CVS HEAD (2.4.21+) >> OS: Fedora >> URL: >> ftp://ftp.openldap.org/incoming/openldap-2.4.21-libldif-and-new-ldif-api= -20100409.patch > > Rich, > > ldifutil.c seems to be missing in that file. =A0Can you provide it? =A0Ei= ther > a separate file, or a new version of the patch is fine. Sorry about that. You can find it here: http://rmeggins.fedorapeople.org/ldifutil.c > > Thanks, p. > > >> This patch allows liblutil to provide the LDIF reading and writing >> functions as >> public APIs in a libldif, and exposes ldif.h to the public API. =A0This >> patch also creates >> a new LDAP API for parsing raw LDIF records into higher level LDAP >> structures >> such as LDAPMod and LDAPControl - ldap_parse_ldif_record() - and changes >> ldapmodify.c to use the new API. >> >> =A0 =A0 This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat, Inc.. Red Hat, Inc. has not >> assigned rights and/or interest in this work to any party. I, Richard >> Megginson am authorized by Red Hat, Inc., my employer, to release this >> work under the following terms. >> >> =A0 =A0 Red Hat, Inc. hereby place the following modifications to OpenLD= AP >> Software (and only these modifications) into the public domain. Hence, >> these modifications may be freely used and/or redistributed for any >> purpose with or without attribution and/or other notice. >> >> >> >> >> > > > > > > >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs