python-ldap-dev — discussion among developers

Re: tarball vs. download URL

[Michael S. <mi...@st...>]

Jens Vagelpohl wrote:
> 
> On Apr 7, 2009, at 13:48 , Michael Ströder wrote:
> 
>> Jens Vagelpohl wrote:
>>> While we're on the topic of packaging, I have one more request:
>>>
>>> Please upload the software (the tarball) to PyPI instead of using the
>>> Sourceforge URL as download URL.
>> Does that look correct to you?
> 
>> http://pypi.python.org/pypi/python-ldap/2.3.6
> 
> Yes, that's great, thanks a lot! :-)

And please remind me to do it for newer releases if I forgot it... ;-)

Anyway in the long run python-ldap should move away from SF anyway. The
new web UI is even worse...

Ciao, Michael.

Re: tarball vs. download URL

[Jens V. <je...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 7, 2009, at 13:48 , Michael Ströder wrote:

> Jens Vagelpohl wrote:
>> While we're on the topic of packaging, I have one more request:
>>
>> Please upload the software (the tarball) to PyPI instead of using the
>> Sourceforge URL as download URL.
>
> Does that look correct to you?
>
> http://pypi.python.org/pypi/python-ldap/2.3.6

Yes, that's great, thanks a lot! :-)

jens


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknbQPAACgkQRAx5nvEhZLJJuACdHtAr5NVNwrJ5OL7G4AsMTPmm
lEcAoKAqDgk1Bpwzb2wwkluLRoA5uAa0
=cdtX
-----END PGP SIGNATURE-----

Re: tarball vs. download URL

[Michael S. <mi...@st...>]

Jens Vagelpohl wrote:
> While we're on the topic of packaging, I have one more request:
> 
> Please upload the software (the tarball) to PyPI instead of using the  
> Sourceforge URL as download URL.

Does that look correct to you?

http://pypi.python.org/pypi/python-ldap/2.3.6

Ciao, Michael.

ldapsearch vs. python-ldap

[James <ja...@cs...>]

Hey,
I'm trying to use python-ldap to do something that works with the
ldapsearch command line tool. I've posted code samples, can someone
point out why the python-ldap fails? What is different about what
python-ldap is doing. It seems that it forgets that it just _did_ bind
successfully...
thanks in advance,

_James
ja...@cs...


# from a command line you can successfully run:
# $ # ldapsearch -x -b "<your dc...>" -D "place\<shortname>" -h <host>
-p 389 -W
"(&(objectcategory=person)(objectclass=user)(samaccountname=<shortname>))"
# <enter password>
# <see results>

# however this doesn't work:
import ldap
import sys
import getpass

l = ldap.initialize('ldap://<host>:389')

try:
	#l.simple_bind_s('fir...@ex...', getpass.getpass())
l.simple_bind_s('<place>\<shortname>', getpass.getpass())			# Works

except Exception, e:
	print e
	print 'Bind Failed'
	sys.exit(1)

try:
	r = l.search_s('dc=<dc...>', ldap.SCOPE_SUBTREE,
'(&(objectcategory=person)(objectclass=user)(samaccountname=<shortname>))', ['*'])

except Exception, e:
	print e
	# this prints:
	# {'info': '00000000: LdapErr: DSID-0C090627, comment: In order to
perform this operation a successful bind must be completed on the
connection., data 0, vece', 'desc': 'Operations error'}
	print 'Search Died'
	sys.exit(1)

for x in r:
	print x

tarball vs. download URL

[Jens V. <je...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While we're on the topic of packaging, I have one more request:

Please upload the software (the tarball) to PyPI instead of using the  
Sourceforge URL as download URL. While setuptools itself can (at least  
most of the time) interact with SourceForge, software that replicates  
Egg servers is normally unable to do so. So if people set up a egg  
server mirror all those Sourceforge download URLs turn into pumpkins  
and those packages must be managed manually. Huge pain. So pretty  
please, don't use Sourceforge download URLs. Upload the tarball into  
PyPI.

jens


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknaHxcACgkQRAx5nvEhZLKxdQCfVoJJNnSlw+Agx/nXkWLRlPEO
nqYAn12YEoUSZDdsvUL3FMPNvsT3vnZI
=zCJB
-----END PGP SIGNATURE-----

Re: Anyone packaged python-ldap as part of a bigger package ?

[Jens V. <je...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 6, 2009, at 16:21 , Michael Ströder wrote:

> Jens Vagelpohl wrote:
>> For the customers' needs it's perfectly fine to just go with an older
>> version of python- ldap.
>
> As long as there aren't any security holes in older versions of
> python-ldap and/or libldap. Nobody will fix them.

I know all that. Think of a server that's on the LAN and not on the  
internet. No security issues expected, and there is no expectation  
that the old library will be secure. So really no worries whatsoever  
from that side.


>> Sometimes I've had to resort to building OpenLDAP separately, just to
>> use python-ldap, and just because I wanted to use the python-ldap egg
>> and the only eggs available are 2.3.x. Seems a bit silly, don't you
>> think?
>
> No, personally I don't think so. Given that even OpenLDAP 2.3 is  
> almost
> out-of-service it's wiser to go with a more recent version.

If you're maintaining older systems that have worked very well in the  
past and that don't have any benefit from later security/functionality  
enhancements (e.g. they don't need to be secured) then it becomes  
counterproductive to ask the customer to upgrade. Especially when  
there's no need to upgrade apart from "then I will have an easier time  
installing python-ldap".


> Hmm, will think about it. If someone has a urgent need I could provide
> older releases.

That's not the issue, though :-)  I know I can find them through  
Google, or by asking you. I'm only asking for an *easy* way of getting  
them that integrates well with automated buildouts - like eggs in a  
sane place such as PyPI.

jens


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknaEasACgkQRAx5nvEhZLJpcQCfYSswi8mSKsL3yZ15cnCajUQb
LJQAn2KYt4OPUGh1Ihx3y9FgvfFNlbD7
=flwK
-----END PGP SIGNATURE-----

Re: Anyone packaged python-ldap as part of a bigger package ?

[Michael S. <mi...@st...>]

Jens Vagelpohl wrote:
> On Apr 6, 2009, at 14:55 , Michael Ströder wrote:
>> Jens Vagelpohl wrote:
>>> On Apr 6, 2009, at 14:10 , Michael Ströder wrote:
>>>
>>>>> It's not always wise to go with the latest.
>>>> At the moment it is (within the 2.3 series).
>>> Unfortunately that's not true. I've ben in many situations where I
>>> really needed older versions (like 2.0.8 or 2.1.x),
>> Can you please tell us why?
> 
> Simple example: A server with an old version of OpenLDAP on it, like  
> 2.2.x, which I don't control and cannot upgrade.

I suspected something like this. ;-)

> For the customers' needs it's perfectly fine to just go with an older
> version of python- ldap.

As long as there aren't any security holes in older versions of
python-ldap and/or libldap. Nobody will fix them.

> Sometimes I've had to resort to building OpenLDAP separately, just to  
> use python-ldap, and just because I wanted to use the python-ldap egg  
> and the only eggs available are 2.3.x. Seems a bit silly, don't you  
> think?

No, personally I don't think so. Given that even OpenLDAP 2.3 is almost
out-of-service it's wiser to go with a more recent version.

> I'm not asking you to spend extra time and put old versions onto PyPI  
> now. What I would like to see is a policy of making sure once a  
> release is on PyPI it's not removed, ever. That way automated  
> buildouts can rely on finding the versions they have configured in.

Hmm, will think about it. If someone has a urgent need I could provide
older releases.

> And if you wanted to share PyPI admin duties I'd be happy to find  
> older versions and upload them to PyPI as well.

Noted. Thanks.

Ciao, Michael.

Re: Anyone packaged python-ldap as part of a bigger package ?

[Jens V. <je...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

P.S.: To avoid any confusion, I'm not arguing for official support for  
old versions. Just an easy way (like PyPI) to get hold of them.  
SourceForge is, in my very personal opinion, garbage. You never know  
which mirror holds what. You never know if a URL you had one moment  
will work the next. On PyPI, URLs work unless someone takes the  
explicit step of deleting a package.

jens


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknZ/y8ACgkQRAx5nvEhZLK/rwCfaaew7Qw7ufA4tVRciQj0LDuV
+qYAnRcAyAsba6pGfAuY2cN5UhFsYz7S
=efE6
-----END PGP SIGNATURE-----

Re: Anyone packaged python-ldap as part of a bigger package ?

[Jens V. <je...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 6, 2009, at 14:55 , Michael Ströder wrote:

> Jens Vagelpohl wrote:
>>
>> On Apr 6, 2009, at 14:10 , Michael Ströder wrote:
>>
>>>> It's not always wise to go with the latest.
>>> At the moment it is (within the 2.3 series).
>>
>> Unfortunately that's not true. I've ben in many situations where I
>> really needed older versions (like 2.0.8 or 2.1.x),
>
> Can you please tell us why?

Simple example: A server with an old version of OpenLDAP on it, like  
2.2.x, which I don't control and cannot upgrade. For the customers'  
needs it's perfectly fine to just go with an older version of python- 
ldap.

Sometimes I've had to resort to building OpenLDAP separately, just to  
use python-ldap, and just because I wanted to use the python-ldap egg  
and the only eggs available are 2.3.x. Seems a bit silly, don't you  
think?

I'm not asking you to spend extra time and put old versions onto PyPI  
now. What I would like to see is a policy of making sure once a  
release is on PyPI it's not removed, ever. That way automated  
buildouts can rely on finding the versions they have configured in.  
And if you wanted to share PyPI admin duties I'd be happy to find  
older versions and upload them to PyPI as well.

jens


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknZ/m4ACgkQRAx5nvEhZLKWCQCfb1YUkDMBrkBUShgtVyBM5F5F
70YAoKbrtlIhR/X/AWCyDWaY+F5uTMM+
=amn5
-----END PGP SIGNATURE-----

Re: Anyone packaged python-ldap as part of a bigger package ?

[Michael S. <mi...@st...>]

Jens Vagelpohl wrote:
> 
> On Apr 6, 2009, at 14:10 , Michael Ströder wrote:
> 
>>> It's not always wise to go with the latest.
>> At the moment it is (within the 2.3 series).
> 
> Unfortunately that's not true. I've ben in many situations where I  
> really needed older versions (like 2.0.8 or 2.1.x),

Can you please tell us why?

Ciao, Michael.

Re: Anyone packaged python-ldap as part of a bigger package ?

[Jens V. <je...@da...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 6, 2009, at 14:10 , Michael Ströder wrote:

>> It's not always wise to go with the latest.
>
> At the moment it is (within the 2.3 series).


Unfortunately that's not true. I've ben in many situations where I  
really needed older versions (like 2.0.8 or 2.1.x), but it was a real  
drag to find them. It certainly was not possible to get them off PyPI,  
which is (at least for me) the easiest way to integrate any Python  
package.

jens



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknZ9AoACgkQRAx5nvEhZLKhmACfVXGygOtyWPRbkWePdUja6i/U
cEIAoIBnoBJINi4M2moE7dkKMqya/8L8
=hT4Y
-----END PGP SIGNATURE-----

Re: Anyone packaged python-ldap as part of a bigger package ?

[Michael S. <mi...@st...>]

Roland Hedberg wrote:
> 
> On Apr 6, 2009, at 9:37, Michael Ströder wrote:
> 
>> Roland Hedberg wrote:
>>> One problem I've already found is that there doesn't seem to exist a
>>> simple stable FTP/HTTP URL that points to the latest distribution.
>>
>> Do you need a URL which is always the same but points to the latest
>> tar.gz file?
> 
> I'd prefer to be able to pick the version I want.

Hmm, at the moment I hide older releases from the download area. Also
there is the idea to move away from Sourceforge anyway in the long run.

> It's not always wise to go with the latest.

At the moment it is (within the 2.3 series).

Still I'd recommend to stick with setuptools and integrate this with
your own installation procedure. I'm maintaining python-ldap's PyPI
record. It will always point to the right python-ldap distribution.

Ciao, Michael.

Re: Anyone packaged python-ldap as part of a bigger package ?

[Roland H. <rol...@ad...>]

On Apr 6, 2009, at 9:37, Michael Ströder wrote:

> Roland Hedberg wrote:
>> One problem I've already found is that there doesn't seem to exist a
>> simple stable FTP/HTTP URL that points to the latest distribution.
>
> Do you need a URL which is always the same but points to the latest
> tar.gz file?


I'd prefer to be able to pick the version I want.
It's not always wise to go with the latest.

--Roland

Re: Anyone packaged python-ldap as part of a bigger package ?

[Michael S. <mi...@st...>]

Roland Hedberg wrote:
> One problem I've already found is that there doesn't seem to exist a  
> simple stable FTP/HTTP URL that points to the latest distribution.

Do you need a URL which is always the same but points to the latest
tar.gz file?

Ciao, Michael.

Anyone packaged python-ldap as part of a bigger package ?

[Roland H. <rol...@ad...>]

Hi!

My goal: to 'bundle' pyton-ldap as part of a service distribution.

The necessary software for this distribution is a among other a set of  
Python packages like python-ldap, Twisted and rdflib and a a couple of  
packages I've developed in python myself, but to get the full service  
functionality I will have to include a graph database written in Java  
and possibly also an Apache server.

easy_install seems to me to be limited to handle distributions of  
python packages and to handle their dependences on other python  
packages, but this is far from what I need.

So, I'm looking at buildout from Zope.

More specifically I'm contemplating writing a buildout recipe for  
installing python-ldap.
Running such a recipe would not only result in fetching python-ldap by  
ftp or http from a site but could also include doing configuration  
before installation as well as after.

Anyone done anything like this ?

One problem I've already found is that there doesn't seem to exist a  
simple stable FTP/HTTP URL that points to the latest distribution.

--Roland

SASL bind problem

[Ashwin <cyb...@ya...>]

Hello,
I am using python-ldap to bind using SASL with DIGEST-MD5 authentication. My program:

#!/usr/bin/python
import ldap.sasl

username = 'user'
pw = 'pass''
url = "ldap://example.com/"
bind = "dc=www,dc=example,dc=com"

def doit():
    con = ldap.initialize(url)
    auth_tok = ldap.sasl.digest_md5(username, pw)
    ret = con.sasl_interactive_bind_s(bind, auth_tok)

    print "bind:", ret
    ret = con.unbind()

    return

doit()
doit()

The first bind is successful, the second one fails (with INVALID_CREDENTIALS):
bind: 0
Traceback (most recent call last):
  File "./ldaptest.py", line 21, in <module>
    doit()
  File "./ldaptest.py", line 12, in doit
    ret = con.sasl_interactive_bind_s(bind, auth_tok)
  File "/usr/lib/python2.5/site-packages/ldap/ldapobject.py", line 219, in sasl_interactive_bind_s
    return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls),sasl_flags)
  File "/usr/lib/python2.5/site-packages/ldap/ldapobject.py", line 97, in _ldap_call
    result = func(*args,**kwargs)
ldap.INVALID_CREDENTIALS: {'info': '80090308: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 57, vece', 'desc': 'Invalid credentials'}

It looks like that the credentials(nonce) are being cached and the server does not like this (it is a Windows server). Is there are way to ask the library to not cache the credentials? I ran wireshark and it confirms that on the first call to bind, only "sasl:mechanism" is sent. However, on the second call to bind, credentials are also being sent which confuses the server as it has not yet sent the challenge (via saslBindInProgress). 

Thanks!
Ashwin


      

Re: Recursive ldap lookups

[Michael S. <mi...@st...>]

Fredrik Melander wrote:
> I was wondering if/how I can make recursive lookups in my ldap-tree
> (corresponding to the -C option of ldapsearch),

Which ldapsearch tool are you talking about? OpenLDAP's command-line
tool ldapsearch does not have an option -C. Do you have several
implementations of ldapsearch on your system?

> i.e.  my ldap-server doesn't have the information I'm asking for, but
> happens to know which other ldap searver that has it, and thus
> forwards my request to that server.

Are you talking about client-chasing of LDAPv3 referrals? Yes, you can
do it by processing the LDAP URLs returned in search continuations
yourself. You have to check the result type to be
ldap.RES_SEARCH_REFERENCE. You can then use module 'ldapurl' to parse
the referral URL in the result.

Note that the concept of client-chasing referral chasing is seriously
broken since the LDAPv3 standard does not specify which credentials to
use when connecting to the server specified in the referral URL. My
web2ldap therefore raises a bind form to interactively ask the user what
to do in this case. So I'd rather recommend to configure your LDAP
server to chase the referral with well-defined credentials if it
supports chaining or however it's called in your LDAP server (which one?).

Also note that there are some security implications if you allow your
users to maintain referral entries on your LDAP server (buzzword: user
self-service).

Ciao, Michael.

Recursive ldap lookups

[Fredrik M. <mel...@df...>]

Hi, list!
I was wondering if/how I can make recursive lookups in my ldap-tree
(corresponding to the -C option of ldapsearch), i.e.  my ldap-server
doesn't have the information I'm asking for, but happens to know which
other ldap searver that has it, and thus forwards my request to that server.

Thanks in advance!

Regards,
Fredrik

Re: Segfault in LDAPerror() when errnum is out of bounds

[Michael S. <mi...@st...>]

Sean Burford wrote:
> 2009/3/20 Michael Ströder <mi...@st...
> <mailto:mi...@st...>>
> 
>     Your patch and a couple of other minor changes are now in CVS HEAD.
> 
> errors.c still looks the same, has the patch been submitted?

Oops. Yes, forgot to committ it. Done now.

http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/errors.c?r1=1.19&r2=1.20

Ciao, Michael.

Re: Segfault in LDAPerror() when errnum is out of bounds

[Sean B. <uni...@gm...>]

2009/3/20 Michael Ströder <mi...@st...>

> Your patch and a couple of other minor changes are now in CVS HEAD.


errors.c still looks the same, has the patch been submitted?
http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/errors.c?view=markup

-- 
Thanks,
Sean Burford

Re: Segfault in LDAPerror() when errnum is out of bounds

[Michael S. <mi...@st...>]

Sean Burford wrote:
> 
> 2009/3/20 Michael Ströder <mi...@st...
> <mailto:mi...@st...>>
> 
>     many thanks for digging through this. Does that mean your issues with
>     syncrepl controls and l_ldap_result3() are fixed?
> 
> Yeah.  There are still mysteries, but RefreshOnly works well enough for now.
> 
> I'm wondering why controls are stripped from search results (it would be
> nice to get the control that says whether a syncrepl result is an
> add/modify or delete for example).  Is this just a side effect of
> optimisation of the usual code path?

I did not write that code. It' still mystery to me especially since I
don't like programming C. Maybe David could enlighten us. When support
for LDAPv3 controls was added I already had some doubts...

>     Any particular reason why you're using python-ldap 2.3.1 which is almost
>     two years old?
> 
> 
> It came with my distro.

Please upgrade, especially when providing patches. There have been
numerous fixes since then:

http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/CHANGES?revision=1.183&view=markup

Your patch and a couple of other minor changes are now in CVS HEAD.
There should be no compability issues between 2.3.1 and a recent
python-ldap release.

Ciao, Michael.

Re: Segfault in LDAPerror() when errnum is out of bounds

[Sean B. <uni...@gm...>]

Hi,

2009/3/20 Michael Ströder <mi...@st...>

> many thanks for digging through this. Does that mean your issues with
> syncrepl controls and l_ldap_result3() are fixed?


Yeah.  There are still mysteries, but RefreshOnly works well enough for now.

I'm wondering why controls are stripped from search results (it would be
nice to get the control that says whether a syncrepl result is an add/modify
or delete for example).  Is this just a side effect of optimisation of the
usual code path?

Any particular reason why you're using python-ldap 2.3.1 which is almost
> two years old?


It came with my distro.


> Sean Burford wrote:
> > When LDAPError receives an errnum from ldap_get_option(l,
> > LDAP_OPT_ERROR_NUMBER, &errnum) that is out of bounds it causes a
> > segfault.  I have attached a script that triggers it and patch that
> > fixes it.
>
> So after applying your patch I get this generic LDAPError exception
> below. This is definitely more robust.


Glad to help.

-- 
Thanks,
Sean Burford

Re: Segfault in LDAPerror() when errnum is out of bounds

[Michael S. <mi...@st...>]

Sean,

many thanks for digging through this. Does that mean your issues with
syncrepl controls and l_ldap_result3() are fixed?

Any particular reason why you're using python-ldap 2.3.1 which is almost
two years old?

Sean Burford wrote:
> When LDAPError receives an errnum from ldap_get_option(l,
> LDAP_OPT_ERROR_NUMBER, &errnum) that is out of bounds it causes a
> segfault.  I have attached a script that triggers it and patch that
> fixes it.

So after applying your patch I get this generic LDAPError exception
below. This is definitely more robust.

ldap.LDAPError: {'info': 'sync cookie is stale', 'desc': 'Content Sync
Refresh Required'}

Anyway I'd see some benefit adding also the syncrepl error codes to let
the application catch specific exceptions. Unfortunately errobjects in
Modules/errors.c is a simple array. Bumping up LDAP_ERROR_MAX to
LDAP_SYNC_REFRESH_REQUIRED would be pretty naively waste a lot of space.

Ciao, Michael.

Segfault in LDAPerror() when errnum is out of bounds

[Sean B. <uni...@gm...>]

Hi,

When LDAPError receives an errnum from ldap_get_option(l,
LDAP_OPT_ERROR_NUMBER, &errnum) that is out of bounds it causes a segfault.
I have attached a script that triggers it and patch that fixes it.

The test script requires an ldap URI and a BaseDN on the command line.  The
ldap server can be OpenLDAP 2.3 or 2.4 and the BaseDN should be configured
with a syncprov overlay and have syncprov-reloadhint TRUE.  eg:
/tmp/ldap-segfault.py ldap://ldap.example.com dc=example,dc=com

After patching _ldap.so we get a valid Exception:
Traceback (most recent call last):
  File "/tmp/ldap-segfault.py", line 39, in ?
    rtype, rdata, rmsgid, serverctrls = conn.result3(all=1, timeout=60)
  File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 438, in
result3
    rtype, rdata, rmsgid, serverctrls =
self._ldap_call(self._l.result3,msgid,all,timeout)
  File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 97, in
_ldap_call
    result = func(*args,**kwargs)
ldap.LDAPError: {'info': 'sync cookie is stale', 'desc': 'Content Sync
Refresh Required'}

-- 
Thanks,
Sean Burford

Re: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl

[Michael S. <mi...@st...>]

Zhang Huangbin wrote:
> 
> A personal question:

Cc: to the list since this could be of general interest.

> when will you release a new version?

It would be no big deal to release a new version tonight if it's
important for your project to use a released version with a definite
version number you can reference in your docs.

I'd like others who reported the problem to confirm that it works for
them now.

Ciao, Michael.