python-ldap-dev — discussion among developers

Re: small fix for cidict.get()

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

Lars Damerow wrote:
> 
> Attached is a patch that makes cidict.get() act more like the regular
> dictionary get method. failobj shouldn't always need to be specified by the
> caller.

Good catch! Committed to CVS.

Ciao, Michael.

small fix for cidict.get()

[Lars D. <la...@pi...>]

Hello!

Attached is a patch that makes cidict.get() act more like the regular
dictionary get method. failobj shouldn't always need to be specified by the
caller.

cheers,
lars

___________________________________________________________
lars damerow
button pusher
pixar animation studios
la...@pi...

"I'll have my lunch now; a single pillow of shredded wheat, some steamed toast,
and a dodo egg."
                                                    Montgomery Burns

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
> Michael Str=F6der wrote:
>=20
>> >BTW Michael, how would you let the different setp.cfg versions co-exi=
st?
>> I think Build/ is the right place.=20
>=20
> Right. I'd create a "Build/win32" dir and put the setup.cfg there.

Already checked in Build/setup.cfg.win32 and Build/setup.cfg.suse-linux a=
nd=20
added it to MANIFEST.in.

> Obviously the main dir should have pointers to let people know they=20
> should look into "Build/<platform>".

Already added comment to INSTALL.

>> We should stick with one way which is DistUtils.
>=20
> OK. I guess you can zap directory "Win32" from the CVS tree altogether,=
=20
> then.

Was never in the normal source distribution anyway.

>>> I did have to extend setup.py a bit; I attach the unified diff here.
>>
>> Hmm, can web apply changes one-by-one? I'd really like to see in the=20
>> diff what was changed.
>=20
> Right. I attach a file where I try to let changes stand out more.

I already checked in your previous diffs. In the end it wasn't that hard =
to=20
figure out what has changed. But just as advice for next time...

> 1. I needed extra options for the linker; so I added "extra_link_args" =

> to the class definition and passed it to the constructor.
> 2. I hijacked the "data files" mechanism in Distutils to carry over the=
=20
> Cyrus-SASL DLL. I added "extra_files" to the class definition and passe=
d=20
> it to setup() as the "data_files" param. I also had to add a loop to=20
> process that setting in the setup.cfg.
> 3. I added the library names I got under Win32 for LDAP (oldap_r) and=20
> SASL (libsasl) to the macro-definition logic.

Noted.

>> error: build_py: supplying both 'packages' and 'py_modules' options is=
=20
>> not allowed=20
>=20
> Hmmm, this is unfortunate. I wasn't aware of this limitation. I wonder =
why?

I wonder why, too. :-/

> If so, let's revert to the old style.

Already done.


> However, there's one file missing=20
> from the manually-built list (ldap/filter.py). Is this intentional?

Ouch! Good catch! Fixed.

I will now test your Win32 build...

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Michael Str=F6der wrote:

> >BTW Michael, how would you let the different setp.cfg versions co-exis=
t?
> I think Build/ is the right place.=20

Right. I'd create a "Build/win32" dir and put the setup.cfg there.=20
Obviously the main dir should have pointers to let people know they=20
should look into "Build/<platform>".

> We should stick with one way which is DistUtils.

OK. I guess you can zap directory "Win32" from the CVS tree altogether,=20
then.

>> I did have to extend setup.py a bit; I attach the unified diff here.
>
> Hmm, can web apply changes one-by-one? I'd really like to see in the=20
> diff what was changed.

Right. I attach a file where I try to let changes stand out more.
The changes I had to insert are:
1. I needed extra options for the linker; so I added "extra_link_args"=20
to the class definition and passed it to the constructor.
2. I hijacked the "data files" mechanism in Distutils to carry over the=20
Cyrus-SASL DLL. I added "extra_files" to the class definition and passed =

it to setup() as the "data_files" param. I also had to add a loop to=20
process that setting in the setup.cfg.
3. I added the library names I got under Win32 for LDAP (oldap_r) and=20
SASL (libsasl) to the macro-definition logic.

> ... avoid DistUtils warning messages. Unfortunately this doesn't work=20
> with Python versions prior 2.3.
>
> error: build_py: supplying both 'packages' and 'py_modules' options is =

> not allowed=20

Hmmm, this is unfortunate. I wasn't aware of this limitation. I wonder wh=
y?
If so, let's revert to the old style. However, there's one file missing=20
from the manually-built list (ldap/filter.py). Is this intentional?

> Which version of Cyrus SASL?

I got it from their CVS a few days ago; so it must be later than 2.1.2=20
which is the latest source tarball available on their site.
I didn't use 2.1.2 because it has serious problems building on Windows,=20
whereas the CVS version builds like a charm out of the box.

> Is the name 'libsasl' also version dependent like on Linux/Unices=20
> (sasl vs. sasl2)?

It appears not to; in fact, the MSVC project files included with the=20
sources build a DLL called LIBSASL without any indication of the version.=


> Could you please send it to me personally? I will make it available as =

> public download with experimental status.=20

Done. You'll get it in a separate message ;-)

Mauro

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
> it looks like I do have a setup.cfg that builds correctly under win32.

Thanks for working on it.

> (BTW Michael, how would you let the different setp.cfg versions 
> co-exist?

I think Build/ is the right place.

> Should we put the Win32 one under the Win32 directory?

No. Now that everything seems to work with DistUtils I'd like to abandon 
this directory completely.

> That 
> particular directory used to host the old build files that I had cobbled 
> together manually to build python-ldap 1.x. In fact I could also provide 
> the new versions of those, for those folks who are more comfortable with 
> the GUI

No. We should stick with one way which is DistUtils.

> I did have to extend setup.py a bit; I attach the unified diff here.

Hmm, can web apply changes one-by-one? I'd really like to see in the diff 
what was changed.

> In fact, I also think that it's better to put the whole of "ldap" and 
> "ldap.schema" as "packages" (in distutils jargon) rather than inserting 
> every individual file by hand into setup.py as a "module".

I already tried this to avoid DistUtils warning messages. Unfortunately this 
doesn't work with Python versions prior 2.3.

error: build_py: supplying both 'packages' and 'py_modules' options is not 
allowed

> Many 
> more lines seem to have changed but it's just an artefact of having 
> reformatted the whole file to use consistently 4-space tabs everywhere. 

Hmm, I'd like to see every single change...

> Now, what I have is a nice graphical installer of Python-ldap 2.0.0pre14 
> for Python 2.3.

Note that this is the CVS version. There's no release of 2.0.0pre14 yet.

 > I made it install the SASL DLL.

Which version of Cyrus SASL? Is the name 'libsasl' also version dependent 
like on Linux/Unices (sasl vs. sasl2)?

> So, please anyone interested let me know and I'll mail you the setup 
> exe.

Could you please send it to me personally? I will make it available as 
public download with experimental status.

> I'd attach it here but I doubt that it would be very interesting 
> for the majority of the readers of this list.

Glad you didn't... ;-)

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Hi all,
it looks like I do have a setup.cfg that builds correctly under win32. I 
attach it here.
(BTW Michael, how would you let the different setp.cfg versions 
co-exist? Should we put the Win32 one under the Win32 directory? That 
particular directory used to host the old build files that I had cobbled 
together manually to build python-ldap 1.x. In fact I could also provide 
the new versions of those, for those folks who are more comfortable with 
the GUI (which does not build the nice graphical installer, though)).

I did have to extend setup.py a bit; I attach the unified diff here.
In fact, I also think that it's better to put the whole of "ldap" and 
"ldap.schema" as "packages" (in distutils jargon) rather than inserting 
every individual file by hand into setup.py as a "module". So I took the 
liberty of changing that, too, and that is reflected into the diff. Many 
more lines seem to have changed but it's just an artefact of having 
reformatted the whole file to use consistently 4-space tabs everywhere. 
Please forgive me if this conflicts with anyone else's tabbing style.

The only feature missing at this time is SSL support; the OpenLDAP guys 
haven't finished the port for Win32 and there are also "political" 
tangles so it isn't clear what's going to happen. I do hope they will 
get their act together sometime in the near future, since they claim 
that Windows is now one of the "officially supported" platforms. So I 
hope for interesting developments Very Soon Now.

Now, what I have is a nice graphical installer of Python-ldap 2.0.0pre14 
for Python 2.3. All one had to do is download it and double-click it. I 
was amazed at the amount of work the distutils guys have done; it even 
plugs in nicely with the "uninstall" features of Windows. As an added 
convenience, I made it install the SASL DLL. LDAP support is linked in 
statically, which is handier.

I have built python-ldap (and everything else) using the new .NET 
compiler, which is different than the version used to build the Python 
distribution; however, in my tests everything runs smoothly. I'd love to 
have someone else test my work, since I have limited testing possibilities.

So, please anyone interested let me know and I'll mail you the setup 
exe. I'd attach it here but I doubt that it would be very interesting 
for the majority of the readers of this list.

BR,
Mauro

Re: SASL EXTERNAL Authentication

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

James Collier wrote:
 >
 > cat >> sasl.py
 >
 > class sasl_external(sasl):
 >     """This class handles SASL EXTERNAL
 >      (i.e. X.509 client certificate)
 >      authentication."""
 >     def __init__(self):
 >         sasl.__init__(self, {}, "EXTERNAL")

Many thanks for your contribution. I've committed it to CVS but with class 
name ldap.sasl.external.

I've added building a dictionary ldap.sasl.saslmech_handler_class for all 
the known SASL mechs from class definitions.

$ python -c "import ldap.sasl; print ldap.sasl.saslmech_handler_class"
{'DIGEST-MD5': <class ldap.sasl.digest_md5 at 0x81de00c>, 'EXTERNAL': <class 
ldap.sasl.external at 0x81ddbec>, 'GSSAPI': <class ldap.sasl.gssapi at 
0x81de4a4>}

As usual please test.

Ciao, Michael.

SASL EXTERNAL Authentication

[James C. <jco...@ya...>]

Many thanks to the authors for python-ldap - a very
clean and comprehensive wrapping.

I'd nevertheless like to request a small extension to
offer explicit support of  SASL EXTERNAL
authentication (i.e. bind authentication with
credentials inherited from TLS client certification).

As an indication of how clean python-ldap is, I've
tested the following trivial snippet and it works
perfectly (no callback is needed in this case).

If anyone feels it's worthwhile putting this in
permanently I'd appreciate it.  While it may be
trivial, having such explicit support encourages
package builders to support SASL/EXTERNAL in turn when
they come to build on top of python_ldap.

...............

cat >> sasl.py

class sasl_external(sasl):
    """This class handles SASL EXTERNAL 
     (i.e. X.509 client certificate)
     authentication."""
    def __init__(self):
        sasl.__init__(self, {}, "EXTERNAL")

................

   -- James Collier.


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
 >
 >> I can also modify setup.py to properly build the two-tuple list of
 >> defines from a line (see attached diff)
 >>
 >> defines = WIN32
 >
 > As I said, I would like this. I second your implementation.
 > [..]
 >>>    3. It appears that any library path under "library_dirs" for some
 >>>       reason gets copied over to "runtime_library_dirs", which makes no
 >>>       sense to me.
 >>
 >> No clue why David did it. I removed it and it stills builds under
 >> Linux. I'd appreciate if others test it on different platforms.
 >
 > I removed it too, and didn't hurt. I'm wondering too.

Ok, checked in both changes in setup.py.

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Michael Str=F6der wrote:

> Mauro,
>
> thanks for your response. I'm very much interested in getting these=20
> issues solved.
>
> Mauro Cicognini wrote:
>
>> I attach the old setup.cfg from PythonLDAP 2.0.0pre04 that used to=20
>> work perfectly. I *had* hacked setup.py a little bit then, to make it =

>> simple to define symbols. BTW, the particular symbol I need is just=20
>> "WIN32".
>
>
> Can you please post your setup.py hack?

Well, it really is functionally identical to the modifications in your=20
diff that do the same thing :-)

What I added was:

if cfg.has_section('_ldap'):
    if cfg.has_option('_ldap', 'class'):
        LDAP_CLASS =3D eval(cfg.get('_ldap', 'class'))
    else:
        LDAP_CLASS =3D OpenLDAP2
    for name in LDAP_CLASS.__dict__.keys():
        if cfg.has_option('_ldap', name):
            setattr(LDAP_CLASS, name, string.split(cfg.get('_ldap', name)=
))
+   if cfg.has_option('_ldap', 'defines'):
+      for defname in string.split(cfg.get('_ldap', 'defines')):
+          LDAP_CLASS.defines.append((defname, None))

but I like your solution better.

>    1. There's no way (AFAIK) to simply "define" a preprocessor symbol
>
>>       within setup.cfg. The distutils scripts expect to have a list of=

>>       one- or two-element tuples, but the parser has no way to pull
>>       those from the .cfg. Besides, the one-element tuple means to
>>       "undefine" the symbol, whereas I'd like to just "define" it
>>       without giving it a value, which is unnecessary. I managed to
>>       insert it using a crude hack within setup.py (just as I had done=

>>       with the earlier version), but I do not like this solution.
>
>
> Wouldn't
>
> extra_compile_args =3D -DWIN32
>
> help?

As I said, I am not familiar with distutils at all. Yes, it would help,=20
I only wasn't really thinking <:-)

>
> I can also modify setup.py to properly build the two-tuple list of=20
> defines from a line (see attached diff)
>
> defines =3D WIN32

As I said, I would like this. I second your implementation.

>
>>    2. The "HAVE_XXX" symbol definition in setup.py is Linux-centric:
>>       since the libraries under Windows have slightly different names
>>       (for instance, "olber32" instead of just "lber"), those symbols
>>       would just not get defined. This however was simple enough to fi=
x.
>
>
> Mainly the HAVE_LIBLDAP_R is of interest. How's the libldap_r called=20
> on Windows? Additionally you can try to manually set -DHAVE_LIBLDAP_R=20
> etc. in setup.cfg.

The current OpenLDAP version calls it oldap_r.lib.

>
>>    3. It appears that any library path under "library_dirs" for some
>>       reason gets copied over to "runtime_library_dirs", which makes n=
o
>>       sense to me.
>
>
> No clue why David did it. I removed it and it stills builds under=20
> Linux. I'd appreciate if others test it on different platforms.

I removed it too, and didn't hurt. I'm wondering too.

>
>>    4. The linker get called without the default libraries, and in such=
 a
>>       way that a whole lot of symbols are found twice, so it just barf=
s
>>       and never links.
>
>
> Any clue how to solve that?

None whatsoever :-(

I'll work on this more next week, I'll let you know.

>
> My goal is to have a setup.py which is suitable to build python-ldap=20
> on any platform with a platform-specific setup.cfg.

Me too. I loved the friendly binary installer I got with 2.0.0pre04 :-)

> So let's sort out the issues together. I don't have a Win32 system to=20
> test a build therefore your input is highly appreciated. I've attached =

> a unified diff for setup.py. Please test.

I will, more on this next week (tomorrow is a national holiday here ;-).

Thanks a lot and keep up the great work.

BR,
Mauro

Re: Win32 Binaries?

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

Mauro,

thanks for your response. I'm very much interested in getting these issues 
solved.

Mauro Cicognini wrote:
> I attach the old setup.cfg from PythonLDAP 2.0.0pre04 that used to work 
> perfectly. I *had* hacked setup.py a little bit then, to make it simple 
> to define symbols. BTW, the particular symbol I need is just "WIN32".

Can you please post your setup.py hack?

>    1. There's no way (AFAIK) to simply "define" a preprocessor symbol
>       within setup.cfg. The distutils scripts expect to have a list of
>       one- or two-element tuples, but the parser has no way to pull
>       those from the .cfg. Besides, the one-element tuple means to
>       "undefine" the symbol, whereas I'd like to just "define" it
>       without giving it a value, which is unnecessary. I managed to
>       insert it using a crude hack within setup.py (just as I had done
>       with the earlier version), but I do not like this solution.

Wouldn't

extra_compile_args = -DWIN32

help?

I can also modify setup.py to properly build the two-tuple list of defines 
from a line (see attached diff)

defines = WIN32

>    2. The "HAVE_XXX" symbol definition in setup.py is Linux-centric:
>       since the libraries under Windows have slightly different names
>       (for instance, "olber32" instead of just "lber"), those symbols
>       would just not get defined. This however was simple enough to fix.

Mainly the HAVE_LIBLDAP_R is of interest. How's the libldap_r called on 
Windows? Additionally you can try to manually set -DHAVE_LIBLDAP_R etc. in 
setup.cfg.

>    3. It appears that any library path under "library_dirs" for some
>       reason gets copied over to "runtime_library_dirs", which makes no
>       sense to me.

No clue why David did it. I removed it and it stills builds under Linux. I'd 
appreciate if others test it on different platforms.

>    4. The linker get called without the default libraries, and in such a
>       way that a whole lot of symbols are found twice, so it just barfs
>       and never links.

Any clue how to solve that?

> After these unsuccessful attempts, I had modified setup.py (which could 
> be OK)

Please post your modifications to setup.py. Proposals welcome.

> but I had also started changing the default Python library 
> scripts, and I'm not comfortable with this.

This is certainly no option.

> So I pulled up the old MSVC 
> project I used for PythonLDAP 1.x, worked on it for a while and got the 
> library to compile nicely.

My goal is to have a setup.py which is suitable to build python-ldap on any 
platform with a platform-specific setup.cfg. So let's sort out the issues 
together. I don't have a Win32 system to test a build therefore your input 
is highly appreciated.

I've attached a unified diff for setup.py. Please test.

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

# Section for compiling the C extension module
# for wrapping OpenLDAP 2 libs

[_ldap]
class = OpenLDAP2
library_dirs = D:/users/mcicogni/sviluppo/openldap/openldap-2.0.23/Release D:/users/mcicogni/sviluppo/openldap/cyrus-sasl-1.5.27/win32/libsasl/Release
include_dirs = D:/users/mcicogni/sviluppo/openldap/openldap-2.0.23/include
libs = olber32 oldap32 ws2_32 libsasl
defines = WIN32

# Installation options

[install]

compile = 1
optimize = 1

Re: Win32 Binaries?

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

Mauro Cicognini wrote:
> 
> I have finally managed and gathered the time to compile Python LDAP on 
> Win32, too.
> [..]
> This is because for some reason the distutils script does not work 
> anymore with my old setup.cfg which used to work beautifully with Python 
> 2.2.
> Is there anyone familiar with these topics that can lend me a hand?

I'm not really familiar with compiling under Win32 but I'd be interested in 
finding out the issues with setup.cfg.

Can you please post your old setup.cfg and the one the build went fine with?

Ciao, Michael.

Re: Win32 Binaries?

[Mauro C. <mci...@si...>]

Jerry Lee wrote:

> Hi All,
>
> Just got this e-mail from Volker Wend who has built Win32 binaries of 
> python-ldap here
> http://www.zope.org/Members/volkerw/LdapWin32/python-ldap-2.0.0pre11.win32.zip/view 
>
> They were built against Python 2.1 and I need something built against 2.2
>
> ------------------
> I have the Python2.2 Binaries already working. I just forgot to upload 
> those
> to zope.org, Since they are now transitioning to a new site. I will wait
> untill that is finished...
>
> Regarding building OpenLdap and Python LDAP: I compiled the OpenLdap 
> Library
> myself and then python-ldap. Its too long to explain ...
> ------------------
> Thanks Volker!
>
> Jerry.

Hi everybody,
I have finally managed and gathered the time to compile Python LDAP on 
Win32, too.

I pulled the sources from CVS two days ago and compiled against all of 
the new versions of OpenLDAP (2.1.22) and Python (2.3) (and the very 
latest cyrus-sasl, for that matter).
I did not link OpenSSL in since I'm waiting for feedback from the 
OpenLDAP developers: just compiling *that* under Windows is a pain, as 
Volker probably knows... and I'm not sure how to pull the SSL/TLS 
support in properly.

If anyone's interested, I have the binaries available now. I will post 
them on my homepage (http://www.siosistemi.it/~mcicogni/) today or 
tomorrow, although they lack a nice installer.

This is because for some reason the distutils script does not work 
anymore with my old setup.cfg which used to work beautifully with Python 
2.2.
Is there anyone familiar with these topics that can lend me a hand?

Thanks in advance,
Mauro

performance issues with ldapsearch vs l.search(...)

[<bjo...@it...>]

For synchronization with some relational authorative datastore, I have
to search the ldap-server now and then (from cron). From the same
computer, to the same ldap-server, with no load (not production yet) I
get very different use of time.

ldapsearch (from openldap's ldapsearch.c):
$time ldapsearch -h ldap -x -b "ou=3Dusers,dc=3Dntnu,dc=3Dno" \
"objectClass=3DposixAccount" uid > /dev/null=20

# numResponses: 26876
# numEntries: 26875

real    0m14.560s
user    0m3.390s
sys     0m0.820s

python-ldap:
# start-script
import ldap
l =3D ldap.open("ldap")
l.simple_bind_s("","")
res =3D l.search_s("ou=3Dusers,dc=3Dexample,dc=3Dcom",ldap.SCOPE_SUBTREE,=
"objectClass=3DposixAccount",["uid"])
print len(res), ' records returned'
l.unbind()
# end script

$ time python ldap-test.py
26875  records returned

real    1m6.524s
user    0m59.580s
sys     0m1.640s

second run with python-ldap:
real    0m58.190s
user    0m52.390s
sys     0m1.620s

Why the big difference? Running truss and strace on the searches, I find
that ldapsearch fetch all entries in one retrieve, while python-ldap
fetch one entry by one.=20

ldapsearch is behaving the same way as pythonldap if I add e.g. '-S uid'=20
(sort by uid)

In python-ldap:
LDAPObject.c: line 684
in function: l_ldap_result( LDAPObject* self, PyObject *args )
    int all =3D 1;
        ^^^^^^^^
does this actually mean anything, and if so - what?

Any suggestions on how to fix LDAPObject.c to fetch the result all in
one chunk? Or am I looking in the wrong file or something?

--
Regards

Bj=F8rn Ove Gr=F8tan

Re: filter an boolean value

[<joe...@he...>]

On Wed, 6 Aug 2003 15:14:21 +0200
"J=F6rg, Sch=FCtter" <joe...@he...> wrote:

> Hello listmembers
>=20
> attributetype ( 1.3.6.1.4.1.10817.200.25
>         NAME 'HeraeusItemPaidUp'
>         DESC 'Item has been paid'
          EQUALITY booleanMatch
>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
>         SINGLE-VALUE )

Ooops, this error has nothing to do with python. I missed the equality
line in the shema.


Gru=DF
  J=F6rg Sch=FCtter

--=20
Dipl.-Ing. J=F6rg Sch=FCtter                                           -
Email   Joe...@he...
Systemspezialist Internet, Sicherheit

filter an boolean value

[<joe...@he...>]

Hello listmembers

I hope this is the right mailing list for my problem.

With python-ldap (1.9.999.pre13-1, Debian sid) I try to search for a
value in my openldap server. Here is the search filter:
'(&(&(objectclass=3DHeraeusWwwProxy)(uid=3D%s))(HeraeusItemPaidUp=3D*))' %
(user,)

What is the right value to replace the wildcard? I only want to find
values where this item is true since HeraeusItemPaidUp is defined as a
boolean value. TRUE, true, True, 1 and chr(1) failed.


attributetype ( 1.3.6.1.4.1.10817.200.25
        NAME 'HeraeusItemPaidUp'
        DESC 'Item has been paid'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
        SINGLE-VALUE )


Regards
  J=F6rg

--=20
Dipl.-Ing. J=F6rg Sch=FCtter                                           -
Email   Joe...@he...
Systemspezialist Internet, Sicherheit

Re: pyldap and openldap 2.1.22

[Andrew T. <ajt...@op...>]

On Wed, 2003-08-06 at 17:44, Michael Str=F6der wrote:
> Andrew Thomson wrote:
>  > On Wed, 2003-08-06 at 16:30, Michael Str=F6der wrote:
>  >
>  >>Did you edit setup.cfg to point to your OpenLDAP client libs?
>  >
>  > I admit that i'm still using the freebsd ports to compile this..
>=20
> Since I have no clue about FreeBSD I can't help. Please ask the maintaine=
r=20
> of the FreeBSD port.
>=20
>  > the port does go through an updated the setup.cfg with the locations o=
f
>  > the ldap libraries and includes.
>  >
>  > # Section for compiling the C extension module
>  > # for wrapping OpenLDAP 2 libs
>  >
>  > [_ldap]
>  > class =3D OpenLDAP2
>  > library_dirs =3D /usr/local/lib
>  > include_dirs =3D /usr/local/include
>  > libs =3D lber ldap
>=20
> Can you find ldap.h in /usr/local/include ?
>=20
>  > The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of
>  > newer versions had been released..
>=20
> 2.0.0pre04 is pretty ancient and I'm rather reluctant giving support for=20
> outdated versions.
>=20

thanks again Michael,

I hacked up the freebsd port for py-ldap and got it to install with the
latest version!

pkg_info| grep ldap
openldap-2.1.22     Open source LDAP client and server software
py23-ldap2-2.0.0pre13 An LDAP module for python, for OpenLDAP2

I'll tell you what, this new version of openldap isn't so carefree with
this structual objectclass business..

anyway, thanks for the assistance.

ajt.


> Ciao, Michael.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>=20

Re: pyldap and openldap 2.1.22

[Andrew T. <ajt...@op...>]

Thanks Michael,

I'll look at updating the port!!

-rw-r--r--  1 root  wheel  39901 Aug  5 13:13 ldap.h
athomson# pwd
/usr/local/include

cheers,

ajt.

On Wed, 2003-08-06 at 17:44, Michael Str=F6der wrote:
> Andrew Thomson wrote:
>  > On Wed, 2003-08-06 at 16:30, Michael Str=F6der wrote:
>  >
>  >>Did you edit setup.cfg to point to your OpenLDAP client libs?
>  >
>  > I admit that i'm still using the freebsd ports to compile this..
>=20
> Since I have no clue about FreeBSD I can't help. Please ask the maintaine=
r=20
> of the FreeBSD port.
>=20
>  > the port does go through an updated the setup.cfg with the locations o=
f
>  > the ldap libraries and includes.
>  >
>  > # Section for compiling the C extension module
>  > # for wrapping OpenLDAP 2 libs
>  >
>  > [_ldap]
>  > class =3D OpenLDAP2
>  > library_dirs =3D /usr/local/lib
>  > include_dirs =3D /usr/local/include
>  > libs =3D lber ldap
>=20
> Can you find ldap.h in /usr/local/include ?
>=20
>  > The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of
>  > newer versions had been released..
>=20
> 2.0.0pre04 is pretty ancient and I'm rather reluctant giving support for=20
> outdated versions.
>=20
> Ciao, Michael.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>=20

Re: pyldap and openldap 2.1.22

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

Andrew Thomson wrote:
 > On Wed, 2003-08-06 at 16:30, Michael Str=F6der wrote:
 >
 >>Did you edit setup.cfg to point to your OpenLDAP client libs?
 >
 > I admit that i'm still using the freebsd ports to compile this..

Since I have no clue about FreeBSD I can't help. Please ask the maintaine=
r=20
of the FreeBSD port.

 > the port does go through an updated the setup.cfg with the locations o=
f
 > the ldap libraries and includes.
 >
 > # Section for compiling the C extension module
 > # for wrapping OpenLDAP 2 libs
 >
 > [_ldap]
 > class =3D OpenLDAP2
 > library_dirs =3D /usr/local/lib
 > include_dirs =3D /usr/local/include
 > libs =3D lber ldap

Can you find ldap.h in /usr/local/include ?

 > The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of
 > newer versions had been released..

2.0.0pre04 is pretty ancient and I'm rather reluctant giving support for =

outdated versions.

Ciao, Michael.

Re: pyldap and openldap 2.1.22

[Andrew T. <ajt...@op...>]

On Wed, 2003-08-06 at 16:30, Michael Str=F6der wrote:
> Andrew Thomson wrote:
>  > Just carrying on from my previous query.. any suggestions here.. this =
is
>  > when I'm trying to build pyldap.
>  >
>  > EQUEST -DLDAPMODULE_VERSION=3D2.0.0pre04 -IModules -I/usr/local/includ=
e
>  > -I/usr/local/include/python2.3 -c Modules/constants.c -o
>  > build/temp.freebsd-5.0-RELEASE-p7-i386-2.3/Modules/constants.o
>  > Modules/constants.c: In function `LDAPinit_constants':
>  > Modules/constants.c:171: `LDAP_FILT_MAXSIZ' undeclared (first use in
>  > this function)
>=20
> This does give very much information.
>=20
> Did you edit setup.cfg to point to your OpenLDAP client libs?
>=20
> Ciao, Michael.
>=20

I admit that i'm still using the freebsd ports to compile this..

the port does go through an updated the setup.cfg with the locations of
the ldap libraries and includes.

# Section for compiling the C extension module
# for wrapping OpenLDAP 2 libs

[_ldap]
class =3D OpenLDAP2
library_dirs =3D /usr/local/lib
include_dirs =3D /usr/local/include
libs =3D lber ldap

# Installation options

[install]

compile =3D 1
optimize =3D 1

The port is sitting at py23-ldap2-2.0.0pre04.. I noticed a couple of
newer versions had been released..

thanks for the help,

ajt.

>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/=
01
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>=20

Re: pyldap and openldap 2.1.22

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

Andrew Thomson wrote:
 > Just carrying on from my previous query.. any suggestions here.. this is
 > when I'm trying to build pyldap.
 >
 > EQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModules -I/usr/local/include
 > -I/usr/local/include/python2.3 -c Modules/constants.c -o
 > build/temp.freebsd-5.0-RELEASE-p7-i386-2.3/Modules/constants.o
 > Modules/constants.c: In function `LDAPinit_constants':
 > Modules/constants.c:171: `LDAP_FILT_MAXSIZ' undeclared (first use in
 > this function)

This does give very much information.

Did you edit setup.cfg to point to your OpenLDAP client libs?

Ciao, Michael.

pyldap and openldap 2.1.22

[Andrew T. <ajt...@op...>]

Just carrying on from my previous query.. any suggestions here.. this is
when I'm trying to build pyldap.

thanks,

ajt.

EQUEST -DLDAPMODULE_VERSION=2.0.0pre04 -IModules -I/usr/local/include
-I/usr/local/include/python2.3 -c Modules/constants.c -o
build/temp.freebsd-5.0-RELEASE-p7-i386-2.3/Modules/constants.o
Modules/constants.c: In function `LDAPinit_constants':
Modules/constants.c:171: `LDAP_FILT_MAXSIZ' undeclared (first use in
this function)

Win32 Binaries?

[Jerry L. <te...@ho...>]

Hi All,

Just got this e-mail from Volker Wend who has built Win32 binaries of 
python-ldap here
http://www.zope.org/Members/volkerw/LdapWin32/python-ldap-2.0.0pre11.win32.zip/view
They were built against Python 2.1 and I need something built against 2.2

------------------
I have the Python2.2 Binaries already working. I just forgot to upload those
to zope.org, Since they are now transitioning to a new site. I will wait
untill that is finished...

Regarding building OpenLdap and Python LDAP: I compiled the OpenLdap Library
myself and then python-ldap. Its too long to explain ...
------------------
Thanks Volker!

Jerry.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: Performance penalty for using python-ldap

[<bjo...@it...>]

Ed .:
> Hi,
>=20
> I was tuning an LDAP directory for a client last week and had cause to =
run=20
> some before and after benchmarks.
>=20
> Basically for a 3000 entry directory I wrote a python script which did =
the=20
> following:
>=20
> listed each entry using the filter (cn=3D*) using python-ldap and also=20
> invoking the shell to use the ldapsearch command. These were done twice=
:=20
> running all attributes an just returning the cn attribute
>=20
> did 3000 random lookups using (cn=3Dexact-match), and then (cn=3Dexact-=
match*)=20
> again using python-ldap and the ldapsearch command.
>=20
> The searches were run twice on unloaded machines, the first time to=20
> populate caches, the second time as a rough best-performance figure
>=20
> The findings were somewhat surprising.
>=20
> In the list whole directory search. ldap-search was generally and=20
> consistently at least 30% faster than python-ldap. I.e. these figures a=
pply=20
> before and after tuning the directory. Remember the python searches are=
=20
> pre-bound while ldapsearch binds each time it is called.
>=20
> In the random lookup test, the performance figures were comparable but =
this=20
> compares calling python-ldap to do a search against spawning a shell,=20
> running ldpasearch, binding then doing the search, i.e. the command lin=
e=20
> search has a LOT more overhead.
>=20
> I'm happy to run some tests to identify the cause to see if we can fix =
it,=20
> any suggestions where to start?

Just ran through some tests of my own. I have a function that leaps
through one ou (ou=3Dusers,dc=3Dmydomain,dc=3Dcom), finds every entry wit=
h
objectclass=3DposixAccount and get the uid of that account using the
function search_ext_s

The result from the search is asigned a variable named 'res', and then
the funcion quits. Execution time from this python-script is aprox.
1m30s. Running the same query with ldapsearch from OpenLDAP-package, the
query executes, prints output to console and exits in some 30s or so.=20

Total amount of entries found with that objectClass is aprox. 27k.

> General conclusions from my tests:
>=20
> python-ldap has a suprising performance penalty
>=20
> searching is helped by having ample cache (doh!)

I'm using OpenLDAP 2.1.22 with BerkeleyDB 4.1.25 with latest patch.
While using BDB as backend, OpenLDAP cannot handle caching - BDB has to.
Found a mail on the openldap-software@-mailinglist describing this issue
and how to setup caching for BDB. That did not help my ldap-search from
withing python, nor with ldapsearch.

> returning 1 attribute is much faster than returning all of them (doh!)

Here I got help from a fellow worker...
Well... when running ldapsearch (from OpenLDAP) and supply the argument
'-S uid' for sorting, we got a result in about 40s. When applying the
argument -S - it seems like ldapsearch fetches one by one into some
kind of datastructure and sort it before viewing.=20

Now, it seems like the python-ldap module does the same thing. Fetching
the result - one by one. Like ldapsearch does with -S <attr> as
argument.=20

Is there any way to force search_ext_s to fetch all at once and not one
by one other than changing the source-code to pyton-ldap?


--
Regards

Bj=F8rn Ove Gr=F8tan
"Resistance is futile.  You will be assimilated."