openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#6535) OpenLDAP fails to build with back-ndb enabled
by giesen＠snickers.org 26 Apr '10

26 Apr '10

Full_Name: Gary T. Giesen Version: 2.4.21 OS: RHEL 6 Beta 1 URL: Submission from: (NULL) (66.135.102.175) OpenLDAP 2.4.21 (as well as 2.4.19) fails to configure or build on RHEL6 with back-ndb support enabled. I've solved the problem with configure by applying a modified version of the patch found here: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2010-March/184248.html However, when building, I get the following error: cd back-ndb; make -w all make[3]: Entering directory `/home/ggiesen/openldap-2.4.21/servers/slapd/back-ndb' rm -f version.c ../../../build/mkversion -v "2.4.21" back_ndb > version.c /bin/sh ../../../libtool --tag=disable-shared --mode=compile g++ -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/usr/include/mysql -I/usr/include/mysql/storage/ndb -I/usr/include/mysql/storage/ndb/ndbapi -c init.cpp g++ -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/usr/include/mysql -I/usr/include/mysql/storage/ndb -I/usr/include/mysql/storage/ndb/ndbapi -c init.cpp -o init.o init.cpp:65: error: expected constructor, destructor, or type conversion before '*' token init.cpp: In function 'int ndb_back_initialize(BackendInfo*)': init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:376: error: 'ndb_lastrow_code' was not declared in this scope init.cpp:376: error: expected type-specifier before 'NdbInterpretedCode' init.cpp:376: error: expected ';' before 'NdbInterpretedCode' make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/home/ggiesen/openldap-2.4.21/servers/slapd/back-ndb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/home/ggiesen/openldap-2.4.21/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/ggiesen/openldap-2.4.21/servers' make: *** [all-common] Error 1 This occurs with rebuilding the 2.4.19 SRPM, using the openldap.org 2.4.19 tarball, and the openldap 2.4.21 tarball. I'm using the Redhat-supplied mysql-cluster.

1 0

(ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠OpenLDAP.org 26 Apr '10

26 Apr '10

Full_Name: Quanah Gibson-Mount Version: 2.4.21 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The following if/elif clause in liblutil is wrong: #ifdef HAVE_SETSID (void) setsid(); #elif TIOCNOTTY if ( (sd = open( "/dev/tty", O_RDWR )) != -1 ) { (void) ioctl( sd, TIOCNOTTY, NULL ); (void) close( sd ); } #endif The elif should be #elif defined(TIOCNOTTY)

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by Ralf Haferkamp 26 Apr '10

26 Apr '10

It seems the fix (in r1.169 of back-bdb/dn2id.c, unfortunately the commit messages did refer the wrong ITS :( ) didn't make in into 2.4.22. Was it overlooked or left out intentionally?

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by rein＠basefarm.no 26 Apr '10

26 Apr '10

On 04/25/2010 12:49 AM, hyc(a)symas.com wrote: > Also in terms of logical abstraction the current behavior is wrong; the > frontend should of course generate the default_referral responses but > updateref is a per-backend item and should be generated at the backend layer. > Ideally this would all have been fixed to behave correctly by moving all > replication support into an overlay, where it properly belongs. As an interim > step it would be trivial to write an updateref overlay that supersedes the > current updateref behavior. Updateref processing should imo be kept out of any replication modules, it is needed in databases where syncrepl isn't configured too. I'm using it on my subordinate databases (with an artificial updatedn so that slapd accepts it..) when syncrepl is configured on the superior glue database without managing all of the subordinate databases. I.e, the infamous test058... I was having the same "chain only on some of the databases" requirement and is using a patch that allows it. I consider this patch more of a hack than a correct solution, which is why I haven't contributed it. A separate updateref overlay apear to me as the best solution. But for what it's worth, my patch is now in: ftp://ftp.openldap.org/incoming/rein-ITS6531.patch An advantage with this patch over a new overlay is that it should be usable without any configuration changes (provided the chain overlay have already been configured in the databases and found to not work as expected there that is ... ;-). Rein

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by masarati＠aero.polimi.it 25 Apr '10

25 Apr '10

[snip] >> Although redesigning referral generation in slapd could streamline >> things, >> I don't quite see what issues can't be addressed using a global instance >> of slapo-chain. You can configure referral chasing differently for >> different domains using the chain-uri directive. I favor fixing only >> what's actually broken. > > The request revolves around having different behavior for different > databases. > With a global slapo-chain you cannot turn off referral chasing; URIs that > are > not explicitly configured will still be chased. > > Also in terms of logical abstraction the current behavior is wrong; the > frontend should of course generate the default_referral responses but > updateref is a per-backend item and should be generated at the backend > layer. > Ideally this would all have been fixed to behave correctly by moving all > replication support into an overlay, where it properly belongs. As an > interim > step it would be trivial to write an updateref overlay that supersedes the > current updateref behavior. As I said, I recognize the usefulness of such a change: I first moved replication into an overlay (ITS#4261). I'm questioning its need for the case at hand. Perhaps allowing slapo-chain to ignore some URIs would be easier to implement, and generally useful in other applications. In any case, I might spare some time to revitalize (ITS#4261), now that slurpd is no longer around and thus things simplify significantly. p.

1 0

Re: (ITS#6533) add rid to syncrepl config logs
by masarati＠aero.polimi.it 25 Apr '10

25 Apr '10

Patched in HEAD. Thanks, p.

1 0

(ITS#6533) add rid to syncrepl config logs
by jonathan＠phillipoux.net 25 Apr '10

25 Apr '10

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-syncrepl-log-20100425.patch Submission from: (NULL) (88.164.187.72) Hi, Currently, when a syncrepl statement is added, the following is output on log level config: Config: ** successfully added syncrepl "ldap://localhost:9011/" In the case of setups replicating several databases from the same server (multimaster with cn=config and a database for example), this leads to confusing identical messages. I attach a patch to add the RID to this line, like this: Config: ** successfully added syncrepl "ldap://localhost:9011/" (rid=001) Please consider this for inclusion. Thanks, Jonathan

1 0

(ITS#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 25 Apr '10

25 Apr '10

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch Submission from: (NULL) (2001:470:9feb:ff02:f435:4e97:f213:bc9e) In regard to http://www.openldap.org/lists/openldap-technical/201004/msg00228.html I've uploaded a patch which enables support for octetStringOrderingMatch to be used in combination with extensible match filters. According RFC4517 section 4.1 the following ordering matching rules currently available in slapd are affected by this patch: caseIgnoreOrderingMatch caseExactOrderingMatch In addition I've added this kind of support to generalizedTimeOrderingMatch, too. The patch can be downloaded here: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch Note: RFC4517 section 4.1 also lists some substring matching rules which also SHOULD be supported in extensible match filters. slapd as well as my patch currently do not offer support for them.

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com 24 Apr '10

24 Apr '10

masarati(a)aero.polimi.it wrote: >> Full_Name: Ryan Steele >> Version: 2.4.18 >> OS: Ubuntu Server >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (207.106.239.81) >> >> >> Per conversation on the #openldap IRC channel on Freenode with Howard Chu, >> it >> has been deemed appropriate to modify the behavior of updateref to answer >> referrals on the backend. This would allow one to use updateref to >> automatically chase referrals for individual backends, instead of it being >> all >> or nothing. Here is the tail end of the channel conversation: >> >> >> <hyc> when you configure an updateref on a backend, that referral is only >> generated in the frontend so putting the overlay on the database, misses >> it... >> >> <rgsteele> Well, I am intending to set an updateref on that backend >> >> <hyc> then you have a problem >> >> <rgsteele> Hm, so you can't do automatic referrals on individual backends >> then? >> >> <rgsteele> That was my original question, or at least the intent of it. >> >> <hyc> not using updateref, no >> >> <rgsteele> Does your response imply there's another way? >> >> <hyc> probably we should fix updateref to be generated at the backend >> level >> >> <rgsteele> That would be good - I'd be happy to write tests or something >> to help >> with that. >> >> <hyc> the "other way" is the normal referral mechanism - using referral >> entries >> inside a database >> >> <hyc> but like I said, updateref is a relic, we've carried it forward >> without >> really adapting it >> >> <hyc> probably should file an ITS about this >> >> <rgsteele> Interesting, I wasn't aware of that method. I'll have to do >> some >> research on that - thanks! Also, is there anything I can do to help get >> the >> process of fixing updateref to generate referrals on the backend? >> >> <rgsteele> I can file the ITS if you like? >> >> <hyc> go ahead > > It is correct that referrals are generated by the frontend, but the > frontend uses information contained in the updateref of each database. > The slapo-chain needs to be global, in order to intercept those referrals. > > Although redesigning referral generation in slapd could streamline things, > I don't quite see what issues can't be addressed using a global instance > of slapo-chain. You can configure referral chasing differently for > different domains using the chain-uri directive. I favor fixing only > what's actually broken. The request revolves around having different behavior for different databases. With a global slapo-chain you cannot turn off referral chasing; URIs that are not explicitly configured will still be chased. Also in terms of logical abstraction the current behavior is wrong; the frontend should of course generate the default_referral responses but updateref is a per-backend item and should be generated at the backend layer. Ideally this would all have been fixed to behave correctly by moving all replication support into an overlay, where it properly belongs. As an interim step it would be trivial to write an updateref overlay that supersedes the current updateref behavior. -- -- 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#6531) Modify updateref to generate referrals on the backend
by masarati＠aero.polimi.it 24 Apr '10

24 Apr '10

> Full_Name: Ryan Steele > Version: 2.4.18 > OS: Ubuntu Server > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.106.239.81) > > > Per conversation on the #openldap IRC channel on Freenode with Howard Chu, > it > has been deemed appropriate to modify the behavior of updateref to answer > referrals on the backend. This would allow one to use updateref to > automatically chase referrals for individual backends, instead of it being > all > or nothing. Here is the tail end of the channel conversation: > > > <hyc> when you configure an updateref on a backend, that referral is only > generated in the frontend so putting the overlay on the database, misses > it... > > <rgsteele> Well, I am intending to set an updateref on that backend > > <hyc> then you have a problem > > <rgsteele> Hm, so you can't do automatic referrals on individual backends > then? > > <rgsteele> That was my original question, or at least the intent of it. > > <hyc> not using updateref, no > > <rgsteele> Does your response imply there's another way? > > <hyc> probably we should fix updateref to be generated at the backend > level > > <rgsteele> That would be good - I'd be happy to write tests or something > to help > with that. > > <hyc> the "other way" is the normal referral mechanism - using referral > entries > inside a database > > <hyc> but like I said, updateref is a relic, we've carried it forward > without > really adapting it > > <hyc> probably should file an ITS about this > > <rgsteele> Interesting, I wasn't aware of that method. I'll have to do > some > research on that - thanks! Also, is there anything I can do to help get > the > process of fixing updateref to generate referrals on the backend? > > <rgsteele> I can file the ITS if you like? > > <hyc> go ahead It is correct that referrals are generated by the frontend, but the frontend uses information contained in the updateref of each database. The slapo-chain needs to be global, in order to intercept those referrals. Although redesigning referral generation in slapd could streamline things, I don't quite see what issues can't be addressed using a global instance of slapo-chain. You can configure referral chasing differently for different domains using the chain-uri directive. I favor fixing only what's actually broken. p.

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