Re: (ITS#7801) test033-glue-syncrepl with bdb/hdb gets stuck on ppc64
by hyc＠symas.com
jsynacek(a)redhat.com wrote:
> Full_Name: Jan Synacek
> Version: 2.4.39
> OS: GNU/Linux
> URL:
> Submission from: (NULL) (209.132.186.34)
>
>
> I configured openldap with --enable-bdb, --enable-hdb and --enable-mdb. No other
> options were used.
> Reproduced on a ppc64 system with kernel 3.10.0.
>
> # ./run -b hdb test033-glue-syncrepl
> Cleaning up test run directory leftover from previous run.
> Running ./scripts/test033-glue-syncrepl for hdb...
> running defines.sh
> Running slapadd to build glued slapd databases...
> Starting slapd 1 on TCP/IP port 9011...
> Using ldapsearch to check that slapd 1 is running...
> Starting slapd 2 on TCP/IP port 9012...
> Using ldapsearch to check that slapd 2 is running...
> Using ldapadd to populate subtree="ou=Information Technology
> Division,ou=People,dc=example,dc=com" on port 9011...
> Using ldapadd to populate subtree="ou=Groups,dc=example,dc=com" on port 9012...
>
> After that, there is no output.
First thing to look at is a gdb stack trace of both slapds, to see what
threads are actually stuck and where. Also look at the log files in the
testrun directory to see what was the last operation being performed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 7 months
Re: (ITS#7807) rebind-as-user in slapd-meta not running
by pierangelo.masarati＠polimi.it
On 02/28/2014 11:00 AM, theedgeu2(a)live.com wrote:
> Full_Name: Angel Martinez
> Version: 2.4.39
> OS: Red Hat Linux 6.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (217.71.18.36)
>
>
> I'm trying to configure a LDAP proxy with slapd-meta.
>
> I have several suffixs over several instances that shares the same user
> accounts. It's posible that one user had access to several targets.
>
> The targets are:
>
> * Users: ou=users, dc=test, dc=com (here resides all accounts)
>
> * Target1: ou=target1, dc=test, dc=com
>
> * Target2: ou=target2, dc=test, dc=com
>
> These 3 suffix are on 3 differents instances.
>
> The instances where target1 and target2 are also have another suffix: ou=users,
> dc=test, dc=com. This suffix is replicated from the first instance (Users)
>
> Normally, the users connect throught the proxy, but sometimes will connect
> directly to the others instances.
>
> Basically this is the slapd.conf of the proxy:
>
> database meta
> chase-referrals yes
> rebind-as-user yes
>
> suffix "ou=users,dc=test,dc=com"
> uri "ldap://192.168.1.34:3891/ou=users,dc=test,dc=com"
>
> suffix "ou=target1,dc=test,dc=com"
> uri "ldap://192.168.1.34:3892/ou=target1,dc=test,dc=com"
>
> suffix "ou=target2,dc=test,dc=com"
> uri "ldap://192.168.1.34:3893/ou=target2,dc=test,dc=com"
>
> When a user connects to the proxy with cn=user1,ou=users,dc=test,dc=com, the
> user is validated against the first target (ou=users) and can search over this
> suffix, but if this user try to search something over other target (for example
> ou=target1) the proxy does not use the credentials of the user and do an
> anonymous bind to target1, so the search doesn't run.
>
> I thought that rebind-as-user resolve this but doesn't run.
>
> I've tried using idassert-bind mode=self bindmethod=simple
> binddn="cn=adminuser,ou=users,dc=test,dc=com" credentials="password" and runs
> ok, but I prefer not to use an administrative account to connect the proxy with
> the targets.
>
> Is there something I'm missing?
Yes, you did not read slapd-meta(5) man page. rebind-as-user is used in
a totally different context. What you need is idassert-bind.
Please direct further conversation to <openldap-technical(a)openldap.org>.
This ITS will be closed.
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
9 years, 7 months
(ITS#7808)
by theEdgeU2＠live.com
I'm sorry but ITS#7807 is the same as this.
Regards
9 years, 7 months
(ITS#7808) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com
Full_Name: Angel Martinez
Version: 2.4.39
OS: Red Hat Linux 6.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (217.71.18.36)
I'm trying to configure a LDAP proxy with slapd-meta.
I have several suffixs over several instances that shares the same user
accounts. It's posible that one user had access to several targets.
The targets are:
* Users: ou=users, dc=test, dc=com (here resides all accounts)
* Target1: ou=target1, dc=test, dc=com
* Target2: ou=target2, dc=test, dc=com
These 3 suffix are on 3 differents instances.
The instances where target1 and target2 are also have another suffix: ou=users,
dc=test, dc=com. This suffix is replicated from the first instance (Users)
Normally, the users connect throught the proxy, but sometimes will connect
directly to the others instances.
Basically this is the slapd.conf of the proxy:
database meta
chase-referrals yes
rebind-as-user yes
suffix "ou=users,dc=test,dc=com"
uri "ldap://192.168.1.34:3891/ou=users,dc=test,dc=com"
suffix "ou=target1,dc=test,dc=com"
uri "ldap://192.168.1.34:3892/ou=target1,dc=test,dc=com"
suffix "ou=target2,dc=test,dc=com"
uri "ldap://192.168.1.34:3893/ou=target2,dc=test,dc=com"
When a user connects to the proxy with cn=user1,ou=users,dc=test,dc=com, the
user is validated against the first target (ou=users) and can search over this
suffix, but if this user try to search something over other target (for example
ou=target1) the proxy does not use the credentials of the user and do an
anonymous bind to target1, so the search doesn't run.
I thought that rebind-as-user resolve this but doesn't run.
I've tried using idassert-bind mode=self bindmethod=simple
binddn="cn=adminuser,ou=users,dc=test,dc=com" credentials="password" and runs
ok, but I prefer not to use an administrative account to connect the proxy with
the targets.
Is there something I'm missing?
Thanks
9 years, 7 months
(ITS#7807) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com
Full_Name: Angel Martinez
Version: 2.4.39
OS: Red Hat Linux 6.4
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (217.71.18.36)
I'm trying to configure a LDAP proxy with slapd-meta.
I have several suffixs over several instances that shares the same user
accounts. It's posible that one user had access to several targets.
The targets are:
* Users: ou=users, dc=test, dc=com (here resides all accounts)
* Target1: ou=target1, dc=test, dc=com
* Target2: ou=target2, dc=test, dc=com
These 3 suffix are on 3 differents instances.
The instances where target1 and target2 are also have another suffix: ou=users,
dc=test, dc=com. This suffix is replicated from the first instance (Users)
Normally, the users connect throught the proxy, but sometimes will connect
directly to the others instances.
Basically this is the slapd.conf of the proxy:
database meta
chase-referrals yes
rebind-as-user yes
suffix "ou=users,dc=test,dc=com"
uri "ldap://192.168.1.34:3891/ou=users,dc=test,dc=com"
suffix "ou=target1,dc=test,dc=com"
uri "ldap://192.168.1.34:3892/ou=target1,dc=test,dc=com"
suffix "ou=target2,dc=test,dc=com"
uri "ldap://192.168.1.34:3893/ou=target2,dc=test,dc=com"
When a user connects to the proxy with cn=user1,ou=users,dc=test,dc=com, the
user is validated against the first target (ou=users) and can search over this
suffix, but if this user try to search something over other target (for example
ou=target1) the proxy does not use the credentials of the user and do an
anonymous bind to target1, so the search doesn't run.
I thought that rebind-as-user resolve this but doesn't run.
I've tried using idassert-bind mode=self bindmethod=simple
binddn="cn=adminuser,ou=users,dc=test,dc=com" credentials="password" and runs
ok, but I prefer not to use an administrative account to connect the proxy with
the targets.
Is there something I'm missing?
Thanks
9 years, 7 months
RE: (ITS#7805) fatal region error detected; run recovery
by quanah＠zimbra.com
--On Thursday, February 27, 2014 8:22 AM +0000
venkatachalam.dk(a)accenture.com wrote:
> Hi ,
>
> Below is the LDAP version used in the server , I have provided wrongly ,
> version is : 2.3.43-12
>
> openldap-clients-2.3.43-12.el5
> openldap-2.3.43-12.el5
> openldap-2.3.43-12.el5
OpenLDAP 2.3 reached end of life in 2008. The current supported release
series is OpenLDAP 2.4. I.e., you're using a release that hasn't been had
any further development in nearly 6 years. I'd strongly advise you to look
at the packages from Symas or the LTB project if you are unable to compile
OpenLDAP yourself. If you wish to continue using the utterly broken and
outdated packages provided by RedHat, then you need to file tickets with
RedHat for support.
Regards,
Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 7 months
Re: (ITS#7805) fatal region error detected; run recovery
by ualex73＠gmail.com
--001a11c2f5ea1bbd3804f35f38ba
Content-Type: text/plain; charset=ISO-8859-1
This is a RedHat supplied version, so you need to contact them for support.
2014-02-27 9:24 GMT+01:00 <venkatachalam.dk(a)accenture.com>:
> Hi ,
>
> Below is the LDAP version used in the server , I have provided wrongly ,
> version is : 2.3.43-12
>
> openldap-clients-2.3.43-12.el5
> openldap-2.3.43-12.el5
> openldap-2.3.43-12.el5
>
> Thanks
> Venkat
>
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: 26 February 2014 23:11
> To: Dk, Venkatachalam; openldap-its(a)openldap.org
> Subject: Re: (ITS#7805) fatal region error detected; run recovery
>
> --On Wednesday, February 26, 2014 10:17 AM +0000
> venkatachalam.dk(a)accenture.com wrote:
>
> > Full_Name: Venkatachalam
> > Version: 2.4.3.1
>
> There is no such OpenLDAP release. If you are using the build provided by
> RHEL, then the correct contact is RedHat. Generally, it is very wise to
> avoid RH's build of OpenLDAP.
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Where allowed
> by local law, electronic communications with Accenture and its affiliates,
> including e-mail and instant messaging (including content), may be scanned
> by our systems for the purposes of information security and assessment of
> internal compliance with Accenture policy. .
>
> ______________________________________________________________________________________
>
> www.accenture.com
>
>
>
>
--001a11c2f5ea1bbd3804f35f38ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is a RedHat supplied version, so you need to contact =
them for support.<br></div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">2014-02-27 9:24 GMT+01:00 <span dir=3D"ltr"><<a href=3D"m=
ailto:venkatachalam.dk@accenture.com" target=3D"_blank">venkatachalam.dk@ac=
centure.com</a>></span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi ,<br>
<br>
Below is the LDAP version used in the server , I have provided wrongly , ve=
rsion is : 2.3.43-12<br>
<br>
openldap-clients-2.3.43-12.el5<br>
openldap-2.3.43-12.el5<br>
openldap-2.3.43-12.el5<br>
<br>
Thanks<br>
Venkat<br>
<div><div class=3D"h5"><br>
-----Original Message-----<br>
From: Quanah Gibson-Mount [mailto:<a href=3D"mailto:quanah@zimbra.com">quan=
ah(a)zimbra.com</a>]<br>
Sent: 26 February 2014 23:11<br>
To: Dk, Venkatachalam; <a href=3D"mailto:openldap-its@openldap.org">openlda=
p-its(a)openldap.org</a><br>
Subject: Re: (ITS#7805) fatal region error detected; run recovery<br>
<br>
--On Wednesday, February 26, 2014 10:17 AM +0000 <a href=3D"mailto:venkatac=
halam.dk(a)accenture.com">venkatachalam.dk(a)accenture.com</a> wrote:<br>
<br>
> Full_Name: Venkatachalam<br>
> Version: 2.4.3.1<br>
<br>
There is no such OpenLDAP release. =A0If you are using the build provided b=
y RHEL, then the correct contact is RedHat. =A0Generally, it is very wise t=
o avoid RH's build of OpenLDAP.<br>
<br>
--Quanah<br>
<br>
<br>
<br>
--<br>
<br>
Quanah Gibson-Mount<br>
Architect - Server<br>
Zimbra, Inc.<br>
--------------------<br>
Zimbra :: =A0the leader in open source messaging and collaboration<br>
<br>
<br>
</div></div>________________________________<br>
<br>
This message is for the designated recipient only and may contain privilege=
d, proprietary, or otherwise confidential information. If you have received=
it in error, please notify the sender immediately and delete the original.=
Any other use of the e-mail by you is prohibited. Where allowed by local l=
aw, electronic communications with Accenture and its affiliates, including =
e-mail and instant messaging (including content), may be scanned by our sys=
tems for the purposes of information security and assessment of internal co=
mpliance with Accenture policy. .<br>
___________________________________________________________________________=
___________<br>
<br>
<a href=3D"http://www.accenture.com" target=3D"_blank">www.accenture.com</a=
><br>
<br>
<br>
<br>
</blockquote></div><br></div>
--001a11c2f5ea1bbd3804f35f38ba--
9 years, 7 months
RE: (ITS#7805) fatal region error detected; run recovery
by venkatachalam.dk＠accenture.com
Hi ,
Below is the LDAP version used in the server , I have provided wrongly , version is : 2.3.43-12
openldap-clients-2.3.43-12.el5
openldap-2.3.43-12.el5
openldap-2.3.43-12.el5
Thanks
Venkat
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: 26 February 2014 23:11
To: Dk, Venkatachalam; openldap-its(a)openldap.org
Subject: Re: (ITS#7805) fatal region error detected; run recovery
--On Wednesday, February 26, 2014 10:17 AM +0000 venkatachalam.dk(a)accenture.com wrote:
> Full_Name: Venkatachalam
> Version: 2.4.3.1
There is no such OpenLDAP release. If you are using the build provided by RHEL, then the correct contact is RedHat. Generally, it is very wise to avoid RH's build of OpenLDAP.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. .
______________________________________________________________________________________
www.accenture.com
9 years, 7 months
Re: (ITS#7806) memory leak in contrib/ldapc++/LDAPAsynConnection.cpp
by hyc＠symas.com
kevpatt(a)khptech.com wrote:
> Full_Name: Kevin H. Patterson
> Version: git master HEAD
> OS: macosx 10.9.1
> URL: http://campus.hartland.edu/temp/0001-fixed-memory-leak-in-LDAPAsynConnect...
> Submission from: (NULL) (65.207.4.130)
>
>
> In libldapcpp, there is a memory leak in the LDAPAsynConnection class.
> ldap_initialize() allocates memory which is never freed. This memory (ld
> structure) should be freed by a call to ldap_unbind() in the class destructor
> and other places where the ld structure is replaced with a new one.
>
> I have included a patch against git master HEAD below.
Thanks for the patch, committed to master.
>
> ---
>
>>From c9b4b1a2638eec20f35c2eae31f0471cc61a21ff Mon Sep 17 00:00:00 2001
> From: "Kevin H. Patterson" <kevpatt(a)khptech.com>
> Date: Wed, 26 Feb 2014 13:08:24 -0500
> Subject: [PATCH] fixed memory leak in LDAPAsynConnection.cpp
>
> ---
> contrib/ldapc++/src/LDAPAsynConnection.cpp | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/contrib/ldapc++/src/LDAPAsynConnection.cpp
> b/contrib/ldapc++/src/LDAPAsynConnection.cpp
> index 894f8ba..582d2b5 100644
> --- a/contrib/ldapc++/src/LDAPAsynConnection.cpp
> +++ b/contrib/ldapc++/src/LDAPAsynConnection.cpp
> @@ -43,7 +43,10 @@ LDAPAsynConnection::LDAPAsynConnection(const string& url, int
> port,
> this->setConstraints(cons);
> }
>
> -LDAPAsynConnection::~LDAPAsynConnection(){}
> +LDAPAsynConnection::~LDAPAsynConnection(){
> + unbind();
> + delete m_constr;
> +}
>
> void LDAPAsynConnection::init(const string& hostname, int port){
> DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::init" << endl);
> @@ -51,6 +54,8 @@ void LDAPAsynConnection::init(const string& hostname, int
> port){
> " hostname:" << hostname << endl
> << " port:" << port << endl);
>
> + unbind();
> +
> m_uri.setScheme("ldap");
> m_uri.setHost(hostname);
> m_uri.setPort(port);
> @@ -66,6 +71,8 @@ void LDAPAsynConnection::init(const string& hostname, int
> port){
> }
>
> void LDAPAsynConnection::initialize(const std::string& uri){
> + unbind();
> +
> m_uri.setURLString(uri);
> int ret = ldap_initialize(&cur_session, m_uri.getURLString().c_str());
> if ( ret != LDAP_SUCCESS ) {
> @@ -277,6 +284,7 @@ void LDAPAsynConnection::unbind(){
>
> void LDAPAsynConnection::setConstraints(LDAPConstraints *cons){
> DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::setConstraints()" << endl);
> + delete m_constr;
> m_constr=cons;
> }
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 7 months
(ITS#7806) memory leak in contrib/ldapc++/LDAPAsynConnection.cpp
by kevpatt＠khptech.com
Full_Name: Kevin H. Patterson
Version: git master HEAD
OS: macosx 10.9.1
URL: http://campus.hartland.edu/temp/0001-fixed-memory-leak-in-LDAPAsynConnect...
Submission from: (NULL) (65.207.4.130)
In libldapcpp, there is a memory leak in the LDAPAsynConnection class.
ldap_initialize() allocates memory which is never freed. This memory (ld
structure) should be freed by a call to ldap_unbind() in the class destructor
and other places where the ld structure is replaced with a new one.
I have included a patch against git master HEAD below.
---
>From c9b4b1a2638eec20f35c2eae31f0471cc61a21ff Mon Sep 17 00:00:00 2001
From: "Kevin H. Patterson" <kevpatt(a)khptech.com>
Date: Wed, 26 Feb 2014 13:08:24 -0500
Subject: [PATCH] fixed memory leak in LDAPAsynConnection.cpp
---
contrib/ldapc++/src/LDAPAsynConnection.cpp | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/contrib/ldapc++/src/LDAPAsynConnection.cpp
b/contrib/ldapc++/src/LDAPAsynConnection.cpp
index 894f8ba..582d2b5 100644
--- a/contrib/ldapc++/src/LDAPAsynConnection.cpp
+++ b/contrib/ldapc++/src/LDAPAsynConnection.cpp
@@ -43,7 +43,10 @@ LDAPAsynConnection::LDAPAsynConnection(const string& url, int
port,
this->setConstraints(cons);
}
-LDAPAsynConnection::~LDAPAsynConnection(){}
+LDAPAsynConnection::~LDAPAsynConnection(){
+ unbind();
+ delete m_constr;
+}
void LDAPAsynConnection::init(const string& hostname, int port){
DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::init" << endl);
@@ -51,6 +54,8 @@ void LDAPAsynConnection::init(const string& hostname, int
port){
" hostname:" << hostname << endl
<< " port:" << port << endl);
+ unbind();
+
m_uri.setScheme("ldap");
m_uri.setHost(hostname);
m_uri.setPort(port);
@@ -66,6 +71,8 @@ void LDAPAsynConnection::init(const string& hostname, int
port){
}
void LDAPAsynConnection::initialize(const std::string& uri){
+ unbind();
+
m_uri.setURLString(uri);
int ret = ldap_initialize(&cur_session, m_uri.getURLString().c_str());
if ( ret != LDAP_SUCCESS ) {
@@ -277,6 +284,7 @@ void LDAPAsynConnection::unbind(){
void LDAPAsynConnection::setConstraints(LDAPConstraints *cons){
DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::setConstraints()" << endl);
+ delete m_constr;
m_constr=cons;
}
--
1.8.3.4 (Apple Git-47)
9 years, 7 months
