openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6515) A lot of dead links on main page of OpenLDAP man.
by hyc＠symas.com 12 Apr '10

12 Apr '10

mitroko(a)gmail.com wrote: > Full_Name: Dmitry Stremkouski > Version: > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.84.189.132) > > > Hello guys. The part of OpenLDAP Manual (wich can be found here - > http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken > links. > Please correct. The 2.3 release is no longer maintained. This doc will not be updated. > FE: http://www.alvestrand.no/harald/objectid/ - dead > A: http://www.bsa-global.com/ - dead (doesn't look good enough for global OID > authority) > A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but futher, > IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) > > Thanks. -- -- 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#6516) Proxy backends normalize ordered attrs incorrectly
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

> They need to use ordered_value_*() functions instead. Fixed in HEAD. p.

1 0

(ITS#6516) Proxy backends normalize ordered attrs incorrectly
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.199) Submitted by: ando They need to use ordered_value_*() functions instead. A patch is coming. p.

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by masarati＠aero.polimi.it 12 Apr '10

12 Apr '10

>> Full_Name: Peter Marschall >> Version: 2.4.21 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/Peter-Marschall-100411.patch >> Submission from: (NULL) (94.217.135.20) >> >> >> Hi, >> >> Playing around with dynacl/aci a bit I cam across the following issue: >> >> Searches that do not contain the attribute OpenLDAPaci in the list of >> attribues >> queried, omit objects. > > dynacl/aci (as the original aci code it's based on) relies on the fact > that the entry is complete. This is the case when the entry is stored > locally, e.g. in back-bdb/hdb. Otherwise, no mechanism is in place to > retrieve operational attributes. Please note that in the latter case, > even ACL rules based on, say, createTimestamp or so would operate > incorrectly. > > My guess is that you're trying to use ACIs with a non-local storage. In > that case your analysis is correct. Can you provide your (sanitized) > configuration? > > The "right" solution is much more general, not only related to dynacl. > Slapd needs to know in advance what (operational) attributes are required > for policy enforcing, and they need to be added to requested attrs when > entries are collected from remote storage. Your patch seems to fix your > specific need, but it is clearly inefficient. Automatically detecting what attributes need to be added to requests for proxying sounds like an overkill. Probably, a reasonable workaround could be to add a configuration directive that lists what attributes need to be added to requests. This directive should be honored by proxy backends and in general by all those backends that do not pass back complete entries to the frontend. In the case of proxy backends its use would be straightforward, since requested attrs need to be mapped anyway in the request. Adding some more would not be a big deal. Things might be a bit more complicated in case of, say, special configurations like proxycache, where ACIs would need to be added to all attribute templates, and so. Yet another reason to avoid ACIs :) p.

1 0

Re: (ITS#6514) bindDN-rewriting with rwm+relay doesn't seem to work
by masarati＠aero.polimi.it 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) I don't see a clear evidence of a bug. Software usage questions must be directed to the openldap-software list. Moreover, I just tried your verbatim configuration with the most recent code (while you're using an older release), and it seems to work as expected. This ITS will be closed. p. > 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#6507) backglue and paged results issue
by jonathan＠phillipoux.net 12 Apr '10

12 Apr '10

Le 08/04/2010 19:26, masarati(a)aero.polimi.it a écrit : >> Ah yes, just saw this. Sorry, my email seems to be slow today (weird). >> >> Similar to my patch, but I'm unsure about the second part: >> >> } else if ( op->o_bd != gi->gi_n[0].gn_be ) { >> /* if cookie not empty, it's again this database's turn */ >> op->o_conn->c_pagedresults_state.ps_be = op->o_bd; >> } >> >> If the cookie is not empty, then it should again be this database's >> turn, even it this is this last database. >> >> This makes a search that stops in the middle of results from last >> database with a valid cookie fall back to the first database on >> continuation, and thus loop forever. >> >> Would you consider removing the else if? > > Well, it's not that simple. The fact is that paged results state is being > handled in two ways: when the database is back-bdb/hdb, the cookie is an > ID, and it's stored in ps_cookie; otherwise (e.g. back-ldap), it's a > berval, stored in ps_cookieval. I need to handle both cases. I think I > made it. > > Now, ps_cookie in c_pagedresults_state is initialized to NOID; back-bdb > will set it to 0 first, and then to whatever value it needs. Other > backends, that use ps_cookieval, will not touch it. So when ps_cookie == > NOID one needs to look at ps_cookieval (and parse it as needed), otherwise > ps_cookie suffices. You'll need to update backglue.c, controls.c and > back-bdb/search.c. > > Now it passes all cases I checked, both with local glued databases and > with back-null/back-ldap as in your example. Right - I'd missed that, regarding this difference between hdb/bdb databases and others. Thanks for the explanation! Just tested your lasted patch set, and it all works great for me, in various different scenarios. Thanks a lot. Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by richm＠stanfordalumni.org 12 Apr '10

12 Apr '10

hyc(a)symas.com wrote: > 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? > I guess it doesn't really matter. It may change if the PEM module decides to change its name, but that is not likely. > (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. > See above - it doesn't matter to me either, it could be #define'd or even hard coded in the module init string. Just let me know. > I've committed the patch as-is. If any other tweaks are needed let us know. > Thanks for working on this. > Thanks!

1 0

(ITS#6515) A lot of dead links on main page of OpenLDAP man.
by mitroko＠gmail.com 12 Apr '10

12 Apr '10

Full_Name: Dmitry Stremkouski Version: OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.84.189.132) Hello guys. The part of OpenLDAP Manual (wich can be found here - http://www.openldap.org/doc/admin23/schema.html) contains a lot of broken links. Please correct. FE: http://www.alvestrand.no/harald/objectid/ - dead A: http://www.bsa-global.com/ - dead (doesn't look good enough for global OID authority) A: http://www.iana.org/cgi-bin/enterprise.pl - should be (redirect, but futher, IMHO, will be dead, try http://pen.iana.org/pen/PenApplication.page) Thanks.

1 0

(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 12 Apr '10

12 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

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