openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by masarati＠aero.polimi.it 27 Apr '10

27 Apr '10

> Full_Name: Mayashankar Mishra > Version: 2.4.21 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.122.110.8) > > > Hi, > > I have to upgrade the openldap from version 2.2.26 to 2.4.21 > All goes fine except for the arl[authority revocation list] failed to get > added > in new database. > > I see the binary version of arl from old openldap, its fine. > > When i try to upload the same on openldap 2.4.21 it provides the error > Root error: [LDAP: error code 21 - authorityRevocationList;binary: value > #0 > invalid per syntax] > > > Note the same arl when added in older version of openldap works fine > > Any guess what could be the reason This is not a bug, but likely invalid data. Certificate list syntax validator and all related routines were stubs until 2.4, so basically everything was treated as valid. Now the syntax is validated thoroughly. This ITS will be closed. Please continue discussion on openldap-software, if needed. Only in case a valid certificate list is not correctly validated (i.e. you detect an actual bug in that code), this ITS can be revitalized. p.

1 0

(ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by mmishra＠isabel.be 27 Apr '10

27 Apr '10

Full_Name: Mayashankar Mishra Version: 2.4.21 OS: rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.122.110.8) Hi, I have to upgrade the openldap from version 2.2.26 to 2.4.21 All goes fine except for the arl[authority revocation list] failed to get added in new database. I see the binary version of arl from old openldap, its fine. When i try to upload the same on openldap 2.4.21 it provides the error Root error: [LDAP: error code 21 - authorityRevocationList;binary: value #0 invalid per syntax] Note the same arl when added in older version of openldap works fine Any guess what could be the reason

1 0

(ITS#6536) Autogroup overlay enhancement
by raphael.ouazana＠linagora.com 27 Apr '10

27 Apr '10

Full_Name: Raphael Ouazana Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-100427.patch Submission from: (NULL) (213.41.232.151) Hi, The attached patch allow the autogroup overlay to handle correctly the attr part of the URL ldap://dc=example,dc=com?attr?sub?(filter). Before this patch, the attr part was simply ignored. Now the group entry is populated by the values of the attribute attr in the resulting entries. Implementation details: Some cases (modify, delete) are harder to handle when you store values instead of dn. In this cases the overlay try to detect if groups have been modified and then simply refresh them. This can cause performance hits if the search specified by the URL deals with an important number of entries. Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#6535) OpenLDAP fails to build with back-ndb enabled
by hyc＠symas.com 26 Apr '10

26 Apr '10

giesen(a)snickers.org wrote: > 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 That patch is invalid. The current code configures and builds properly with a recent mysql-cluster. It was developed originally against cluster 6.0.x. I have tested it again with the current MySQL Cluster 7.1.3 available here http://mysql.com/downloads/cluster/ > However, when building, I get the following error: > 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. Your MySQL package is obsolete by at least 2 years. This ITS will be closed. If you need more assistance talk to your distro vendor. As a side note, if your distro vendor is unable to help you, supported RPMs of OpenLDAP with back-ndb are available from Symas Corp. -- -- 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#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

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