openldap-bugs

openldap-bugs@openldap.org

1 participants
21063 discussions

(ITS#7809) cross-compiling and openldap-thread-check.m4
by stenn＠ntp.org 03 Mar '14

03 Mar '14

Full_Name: Harlan Stenn Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.155.158.122) openldap-thread-check.m4 seems to hand-code an equivalent of AC_ARG_WITH() processing for the with_yielding_select stuff. This code has at least one typo and at least one bug; it does not work in the case where one is cross-compiling. Before I go and submit a patch that would convert this macro to using AC_ARG_WITH, I figured I should ask to see why things were done the way they were.

1 0

RE: (ITS#7807) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com 01 Mar '14

01 Mar '14

--_b67832eb-f95f-44fc-96d8-4e1d626f474b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First of all thank you for your quick answer. =20 Before I posted the question I've read the man pages several times trying t= o understand how slapd-meta runs. I don't speak english very well (as you c= an see) so it's probably that i've don't understand it completly. =20 As I've tried to explain in my question=2C I used idassert-bind before and = it runs ok=2C but I don't understand why I've to use an administrative acco= unt to connect the proxy with the targets if I only want to passthrough the= credentials of the user that was authenticated on the proxy. So I tried to= use rebind-as-user thinking it was the solution but as you say this is for= another use. =20 Only for confirm what I'm doing. Is this the correct directive for what I'm= trying to do? idassert-bind mode=3Dself bindmethod=3Dsimple binddn=3D"cn=3Dadminuser=2Cou= =3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentials=3D"password of admin user" =20 Regards =20 > Date: Fri=2C 28 Feb 2014 21:23:52 +0100 > From: pierangelo.masarati(a)polimi.it > To: theedgeu2(a)live.com > CC: openldap-its(a)openldap.org > Subject: Re: (ITS#7807) rebind-as-user in slapd-meta not running >=20 > On 02/28/2014 11:00 AM=2C 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=3Dusers=2C dc=3Dtest=2C dc=3Dcom (here resides all accounts= ) > > > > * Target1: ou=3Dtarget1=2C dc=3Dtest=2C dc=3Dcom > > > > * Target2: ou=3Dtarget2=2C dc=3Dtest=2C dc=3Dcom > > > > These 3 suffix are on 3 differents instances. > > > > The instances where target1 and target2 are also have another suffix: o= u=3Dusers=2C > > dc=3Dtest=2C dc=3Dcom. This suffix is replicated from the first instanc= e (Users) > > > > Normally=2C the users connect throught the proxy=2C 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=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" > > uri "ldap://192.168.1.34:3891/ou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" > > > > suffix "ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom" > > uri "ldap://192.168.1.34:3892/ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom" > > > > suffix "ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" > > uri "ldap://192.168.1.34:3893/ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" > > > > When a user connects to the proxy with cn=3Duser1=2Cou=3Dusers=2Cdc=3Dt= est=2Cdc=3Dcom=2C the > > user is validated against the first target (ou=3Dusers) and can search = over this > > suffix=2C but if this user try to search something over other target (f= or example > > ou=3Dtarget1) the proxy does not use the credentials of the user and do= an > > anonymous bind to target1=2C 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=3Dself bindmethod=3Dsimple > > binddn=3D"cn=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentia= ls=3D"password" and runs > > ok=2C but I prefer not to use an administrative account to connect the = proxy with > > the targets. > > > > Is there something I'm missing? >=20 > Yes=2C you did not read slapd-meta(5) man page. rebind-as-user is used i= n=20 > a totally different context. What you need is idassert-bind. >=20 >=20 > Please direct further conversation to <openldap-technical(a)openldap.org>.= =20 > This ITS will be closed. >=20 > p. >=20 >=20 > --=20 > Pierangelo Masarati > Associate Professor > Dipartimento di Scienze e Tecnologie Aerospaziali > Politecnico di Milano = --_b67832eb-f95f-44fc-96d8-4e1d626f474b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'> First of all thank you for y= our quick answer. &nbsp=3B Before I posted the question I've read the= man pages several times trying to understand how slapd-meta runs. I don't = speak english very well (as you can see) so it's probably that i've don't u= nderstand it completly. &nbsp=3B As I've tried to&nbsp=3Bexplain in m= y question=2C I used idassert-bind before and it runs ok=2C but I don't und= erstand why I've to use an administrative account to connect the proxy with= the targets if I only want to passthrough the credentials of the user that= was authenticated on the proxy. So I tried to use rebind-as-user thinking = it was the solution but as you say this is for another use. &nbsp=3B = Only for confirm what I'm doing. Is this the correct directive for what I'm= trying to do? idassert-bind mode=3Dself bindmethod=3Dsimple binddn=3D"c= n=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentials=3D"password = of admin user" &nbsp=3B Regards &nbsp=3B <div>&gt=3B Date: Fri= =2C 28 Feb 2014 21:23:52 +0100 &gt=3B From: pierangelo.masarati(a)polimi.i= t &gt=3B To: theedgeu2(a)live.com &gt=3B CC: openldap-its(a)openldap.org<= br>&gt=3B Subject: Re: (ITS#7807) rebind-as-user in slapd-meta not running<= br>&gt=3B &gt=3B On 02/28/2014 11:00 AM=2C theedgeu2(a)live.com wrote:<br= >&gt=3B &gt=3B Full_Name: Angel Martinez &gt=3B &gt=3B Version: 2.4.39<b= r>&gt=3B &gt=3B OS: Red Hat Linux 6.4 &gt=3B &gt=3B URL: ftp://ftp.openl= dap.org/incoming/ &gt=3B &gt=3B Submission from: (NULL) (217.71.18.36)<b= r>&gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B I'm trying to configure a= LDAP proxy with slapd-meta. &gt=3B &gt=3B &gt=3B &gt=3B I have sever= al suffixs over several instances that shares the same user &gt=3B &gt= =3B accounts. It's posible that one user had access to several targets. = &gt=3B &gt=3B &gt=3B &gt=3B The targets are: &gt=3B &gt=3B &gt=3B = &gt=3B * Users: ou=3Dusers=2C dc=3Dtest=2C dc=3Dcom (here resides all accou= nts) &gt=3B &gt=3B &gt=3B &gt=3B * Target1: ou=3Dtarget1=2C dc=3Dtest= =2C dc=3Dcom &gt=3B &gt=3B &gt=3B &gt=3B * Target2: ou=3Dtarget2=2C d= c=3Dtest=2C dc=3Dcom &gt=3B &gt=3B &gt=3B &gt=3B These 3 suffix are o= n 3 differents instances. &gt=3B &gt=3B &gt=3B &gt=3B The instances w= here target1 and target2 are also have another suffix: ou=3Dusers=2C &gt= =3B &gt=3B dc=3Dtest=2C dc=3Dcom. This suffix is replicated from the first = instance (Users) &gt=3B &gt=3B &gt=3B &gt=3B Normally=2C the users co= nnect throught the proxy=2C but sometimes will connect &gt=3B &gt=3B dir= ectly to the others instances. &gt=3B &gt=3B &gt=3B &gt=3B Basically = this is the slapd.conf of the proxy: &gt=3B &gt=3B &gt=3B &gt=3B data= base meta &gt=3B &gt=3B chase-referrals yes &gt=3B &gt=3B rebind-as-u= ser yes &gt=3B &gt=3B &gt=3B &gt=3B suffix "ou=3Dusers=2Cdc=3Dtest= =2Cdc=3Dcom" &gt=3B &gt=3B uri "ldap://192.168.1.34:3891/ou=3Dusers= =2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B &gt=3B &gt=3B suffix "ou=3Dt= arget1=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B uri "ldap://192.168.1.= 34:3892/ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B &gt=3B &gt= =3B suffix "ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B uri = "ldap://192.168.1.34:3893/ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B = &gt=3B &gt=3B &gt=3B When a user connects to the proxy with cn=3Duser1= =2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom=2C the &gt=3B &gt=3B user is valida= ted against the first target (ou=3Dusers) and can search over this &gt= =3B &gt=3B suffix=2C but if this user try to search something over other ta= rget (for example &gt=3B &gt=3B ou=3Dtarget1) the proxy does not use the= credentials of the user and do an &gt=3B &gt=3B anonymous bind to targe= t1=2C so the search doesn't run. &gt=3B &gt=3B &gt=3B &gt=3B I though= t that rebind-as-user resolve this but doesn't run. &gt=3B &gt=3B &gt= =3B &gt=3B I've tried using idassert-bind mode=3Dself bindmethod=3Dsimple<b= r>&gt=3B &gt=3B binddn=3D"cn=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dco= m" credentials=3D"password" and runs &gt=3B &gt=3B ok=2C but I prefer no= t to use an administrative account to connect the proxy with &gt=3B &gt= =3B the targets. &gt=3B &gt=3B &gt=3B &gt=3B Is there something I'm m= issing? &gt=3B &gt=3B Yes=2C you did not read slapd-meta(5) man page= . rebind-as-user is used in &gt=3B a totally different context. What = you need is idassert-bind. &gt=3B &gt=3B &gt=3B Please direct fu= rther conversation to &lt=3Bopenldap-technical(a)openldap.org&gt=3Bt=3B. &gt= =3B This ITS will be closed. &gt=3B &gt=3B p. &gt=3B &gt=3B= &gt=3B -- &gt=3B Pierangelo Masarati &gt=3B Associate Professor= &gt=3B Dipartimento di Scienze e Tecnologie Aerospaziali &gt=3B Poli= tecnico di Milano </div> </div></body> </html>= --_b67832eb-f95f-44fc-96d8-4e1d626f474b_--

1 0

ITS#7788
by michael＠stroeder.com 01 Mar '14

01 Mar '14

I do not consider this to be a bug. I'd vote for closing it as "won't fix".

1 0

Re: (ITS#7801) test033-glue-syncrepl with bdb/hdb gets stuck on ppc64
by hyc＠symas.com 28 Feb '14

28 Feb '14

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/

1 0

Re: (ITS#7807) rebind-as-user in slapd-meta not running
by pierangelo.masarati＠polimi.it 28 Feb '14

28 Feb '14

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

1 0

(ITS#7808)
by theEdgeU2＠live.com 28 Feb '14

28 Feb '14

I'm sorry but ITS#7807 is the same as this. Regards

1 0

(ITS#7808) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com 28 Feb '14

28 Feb '14

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

1 0

(ITS#7807) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com 28 Feb '14

28 Feb '14

1 0

RE: (ITS#7805) fatal region error detected; run recovery
by quanah＠zimbra.com 27 Feb '14

27 Feb '14

--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

1 0

Re: (ITS#7805) fatal region error detected; run recovery
by ualex73＠gmail.com 27 Feb '14

27 Feb '14

--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. </div><div class=3D"gmail_extra"> <div class=3D= "gmail_quote">2014-02-27 9:24 GMT+01:00 <<a href=3D"m= ailto:venkatachalam.dk@accenture.com" target=3D"_blank">venkatachalam.dk@ac= centure.com</a>>: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Hi , Below is the LDAP version used in the server , I have provided wrongly , ve= rsion 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 <div><div class=3D"h5"> -----Original Message----- From: Quanah Gibson-Mount [mailto:<a href=3D"mailto:quanah@zimbra.com">quan= ah(a)zimbra.com</a>] Sent: 26 February 2014 23:11 To: Dk, Venkatachalam; <a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a> Subject: Re: (ITS#7805) fatal region error detected; run recovery --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: > Full_Name: Venkatachalam > Version: 2.4.3.1 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. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: =A0the leader in open source messaging and collaboration </div></div>________________________________ 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. . ___________________________________________________________________________= ___________ <a href=3D"http://www.accenture.com" target=3D"_blank">www.accenture.com</a= > </blockquote></div> </div> --001a11c2f5ea1bbd3804f35f38ba--

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