Menu
▾
▴
python-ldap-dev
|
From: Joe L. <jl...@op...> - 2002-07-05 16:38:48
|
I'll downloaded the isos for limbo, the first RedHat 8.0 beta release. Its a true .0 release, in that a lot of major changes are in the works. Primarily, they have migrated their whole installation system from python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means that at least for this vendor, a CVS release of python-ldap will be the bare minimum requirement. My guess is that 8.0 may be an August release, or perhaps later. Regardless, the list will get more questions about OpenLDAP 2.1.x in the future. The good news is that Python 1.5.x is going away and so my RPMs won't need to deal with "python == python-1.5.x and python2 == python 2.x.y?" notation.. |
|
From: <mi...@st...> - 2002-07-05 17:15:35
|
Joe Little wrote: > I'll downloaded the isos for limbo, the first RedHat 8.0 beta release. > > Its a true .0 release, in that a lot of major changes are in the works. > Primarily, they have migrated their whole installation system from > python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP > 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means > that at least for this vendor, a CVS release of python-ldap will be the > bare minimum requirement. My guess is that 8.0 may be an August release, > or perhaps later. Regardless, the list will get more questions about > OpenLDAP 2.1.x in the future. Now how about testing the current CVS instead of counting version numbers? Did you read about my problems with OpenLDAP 2.1.x libs? I filed two bug reports to OpenLDAP's ITS related to problems I found when working on python-ldap during the last days. So far I had no feedback from list members when requesting tests during the last days! :-( Red Hat is famous for packaging premature software into RPMs such causing a 1st-level support nightmare on mailing lists which they simply don't have to pay (e.g. the gcc catastrophy). Sorry, Red Hat nor any other Linux distributors' packaging decisions will influence my schedule. Joe, if you want to push things forward then there are several things to dig into: 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x libs. 2. Find huge memory leaks reported to the list. 3. Dig into thread-safety issues with libldap_r. Despite your personal conversation with Luke I have some doubts that this is really solved. 4. Test build process with several flavors of OpenLDAP (./configure --help to give you an idea). 5. Clean up the nightmare of DEFINE's used. 6. At least test the CVS version! Not to speak of adding new features... Ciao, Michael. |
|
From: Joe L. <jl...@op...> - 2002-07-05 17:35:19
|
Yeah.. I know there is a lot to do. I was just relating what I saw in = one of my primary tasks (maintain a university's Linux distro). I = sincerely hope to dig into builds against 2.1.x and libldap_r. I also = noted the issue with OpenLDAP and the problem report, and will await = whatever they respond to. I just don't have much code to test OpenLDAP = 2.1 or any version against. I need to get sufficient code that will = provide bug reports. As to the mem leaks, I'm at a loss as to how to tackle that one on = Python. On Friday, July 5, 2002, at 10:15 AM, Michael Str=F6der wrote: > Joe Little wrote: >> I'll downloaded the isos for limbo, the first RedHat 8.0 beta = release. >> Its a true .0 release, in that a lot of major changes are in the = works. Primarily, they have migrated their whole installation system = from python 1.5.x to 2.2.x. Along with this, they have adopted OpenLDAP = 2.1.2, and their compat libs are only for OpenLDAP 1.2.13. This means = that at least for this vendor, a CVS release of python-ldap will be the = bare minimum requirement. My guess is that 8.0 may be an August release, = or perhaps later. Regardless, the list will get more questions about = OpenLDAP 2.1.x in the future. > > Now how about testing the current CVS instead of counting version = numbers? Did you read about my problems with OpenLDAP 2.1.x libs? I = filed two bug reports to OpenLDAP's ITS related to problems I found when = working on python-ldap during the last days. > > So far I had no feedback from list members when requesting tests = during the last days! :-( > > Red Hat is famous for packaging premature software into RPMs such = causing a 1st-level support nightmare on mailing lists which they simply = don't have to pay (e.g. the gcc catastrophy). > > Sorry, Red Hat nor any other Linux distributors' packaging decisions = will influence my schedule. > > Joe, if you want to push things forward then there are several things = to dig into: > > 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x = libs. > > 2. Find huge memory leaks reported to the list. > > 3. Dig into thread-safety issues with libldap_r. Despite your personal = conversation with Luke I have some doubts that this is really solved. > > 4. Test build process with several flavors of OpenLDAP (./configure = --help to give you an idea). > > 5. Clean up the nightmare of DEFINE's used. > > 6. At least test the CVS version! > > Not to speak of adding new features... > > Ciao, Michael. |
|
From: <mi...@st...> - 2002-07-05 17:49:19
|
I forgot something. Several things to dig into: 0. At least test the CVS version! 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP 2.1.x libs. 2. Find huge memory leaks reported to the list. 3. Dig into thread-safety issues with libldap_r. Despite your personal conversation with Luke I have some doubts that this is really solved. 4. Test build process with several flavors of OpenLDAP (./configure --help to give you an idea). 5. Clean up the nightmare of DEFINE's used. 6. Find subtle problem with search continuations blocking the search in ldap.async when using the latest CVS versions. Ciao, Michael. |
|
From: <mi...@st...> - 2002-07-11 19:31:11
|
Michael Str=F6der wrote:
>=20
> 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP
> 2.1.x libs.
Now this turned out to be a problem with ldap.explode_dn() and=20
errornous handling of NON-ASCII chars in DNs (e.g. for search=20
root) in OpenLDAP servers 1.x and 2.0.x.
Unlike former versions ldap_explode_dn() returns escaped values if=20
the DN of OpenLDAP 2.1.x returns contains NON-ASCII chars. This is=20
valid according to RFC2253 but causes compability problems with=20
old OpenLDAP servers. The older OpenLDAP servers do not match the=20
escaped values in DNs properly.
See the following trace log of a situation hitting in web2ldap=20
when accessing OpenLDAP 2.0.x (it works e.g. against Netscape=20
Directory 4.1x):
*** _ldap.<built-in function explode_dn> (('cn=3DMichael
>Str\xc3\xb6...@st...,ou=3DTesting,dc=3Dstroeder,d=
c=3Dcom',
>0),{})
>=3D> result: ['cn=3DMichael Str\\C3\\B6d...@st...'=
,
>'ou=3DTesting', 'dc=3Dstroeder', 'dc=3Dcom']
>*** ldap.ldapobject.SimpleLDAPObject.search (('cn=3DMichael
>Str\\C3\\B6d...@st...,ou=3DTesting,dc=3Dstroeder,d=
c=3Dcom',
>0, '(objectclass=3D*)', ['cn'], 0),{})
>=3D> result: 1
>*** ldap.ldapobject.SimpleLDAPObject.result ((1, 1, -1),{})
>=3D> LDAPError: {'info': '', 'matched':
>'ou=3DTesting,dc=3Dstroeder,dc=3Dcom', 'desc': 'No such object'}
Note also that ldap_explode_dn() is marked as deprecated in=20
OpenLDAP 2.1.x's ldap.h.
Ciao, Michael.
|
|
From: Joe L. <jl...@op...> - 2002-07-11 19:38:33
|
I've worked with the latest CVS code a bit. Hope to have more code to =
push it soon. I did note the new 2.1.3 update too, and saw the libldap_r =
build fix. Did you get a separate email from Kurt saying that it was =
going to be addressed in a 2.0.x release as well?
On Thursday, July 11, 2002, at 10:54 AM, Michael Str=F6der wrote:
> Michael Str=F6der wrote:
>> 1. Solve problems with NON-ASCII chars in DN when using OpenLDAP
>> 2.1.x libs.
>
> Now this turned out to be a problem with ldap.explode_dn() and =
errornous handling of NON-ASCII chars in DNs (e.g. for search root) in =
OpenLDAP servers 1.x and 2.0.x.
>
> Unlike former versions ldap_explode_dn() returns escaped values if the =
DN of OpenLDAP 2.1.x returns contains NON-ASCII chars. This is valid =
according to RFC2253 but causes compability problems with old OpenLDAP =
servers. The older OpenLDAP servers do not match the escaped values in =
DNs properly.
>
> See the following trace log of a situation hitting in web2ldap when =
accessing OpenLDAP 2.0.x (it works e.g. against Netscape Directory =
4.1x):
>
> *** _ldap.<built-in function explode_dn> (('cn=3DMichael
> =
>Str\xc3\xb6...@st...,ou=3DTesting,dc=3Dstroeder,dc=3D=
com',
> >0),{})
> >=3D> result: ['cn=3DMichael =
Str\\C3\\B6d...@st...',
> >'ou=3DTesting', 'dc=3Dstroeder', 'dc=3Dcom']
> >*** ldap.ldapobject.SimpleLDAPObject.search (('cn=3DMichael
> =
>Str\\C3\\B6d...@st...,ou=3DTesting,dc=3Dstroeder,dc=3D=
com',
> >0, '(objectclass=3D*)', ['cn'], 0),{})
> >=3D> result: 1
> >*** ldap.ldapobject.SimpleLDAPObject.result ((1, 1, -1),{})
> >=3D> LDAPError: {'info': '', 'matched':
> >'ou=3DTesting,dc=3Dstroeder,dc=3Dcom', 'desc': 'No such object'}
>
> Note also that ldap_explode_dn() is marked as deprecated in OpenLDAP =
2.1.x's ldap.h.
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
|
|
From: <mi...@st...> - 2002-07-18 12:55:02
|
Joe Little wrote: > I did note the new 2.1.3 update too, and saw the libldap_r > build fix. Did you get a separate email from Kurt saying that it was > going to be addressed in a 2.0.x release as well? The fix appeared in the REL_ENG_2 either. ---------------------------- revision 1.57 date: 2002/07/08 22:34:41; author: kurt; state: Exp; lines: +8 -7 ITS#1922: add references.lo ---------------------------- No release yet. Ciao, Michael. |
Thanks for helping keep SourceForge clean.
X