python-ldap-dev — discussion among developers

Re: Win32 support (was: Strange behavior in Python-LDAP 2.0.0pre04)

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

Michael Ströder wrote:

> Mauro Cicognini wrote:
> > P.S. This happens because I've finally managed to compile
> > python-ldap under native Windows 32 (no Cygwin)
>
> That's good news!
>
> Can you package some Win32 binaries?
> Maybe we can incorporate the necessary changes if any into python-ldap?
>
I had to write a new setup.cfg; I don't know if one could just insert a 
win32 section in the existing one and make it work automagically. Maybe 
so, since setup.py is custom too.

That's not the end of the story, though. I need some help with 
distutils, and here's why.

On one hand, the actual LDAP (and LBER) libraries are made static; 
moreover, I was able to build them so that they link the correct shared 
objects (MSVCRT.DLL, i.e. the same that Python needs).
This way I could fold them into the _ldap shared object (_ldap.pyd) and 
not have bizarre runtime errors.

On the other hand, the SASL library gets built as a DLL; I can make it 
into a static library, although I don't really know if it would work; 
but the real problem is that the LDAP and LBER code looks for SASL 
support in a shared object.

I don't have time to delve into this and find out if OpenLDAP could be 
tweaked to support a statically linked SASL library, and, besides, the 
build procedure is already complex enough (and officially experimental: 
your mileage may vary).

So I just put my LIBSASL.DLL into the Windows system directory; it works :-)

However, to replicate this arrangement on other machines I'd have to 
tell distutils that a) the binary distribution needs to include 
LIBSASL.DLL, too; and b) when installing it, it needs to go somewhere on 
the PATH. I have no idea how.

Any suggestions?

Thanks,
Mauro

Re: Strange behavior in Python-LDAP 2.0.0pre04

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

Mauro Cicognini wrote:
>> The goal was to 
>> turn all sync API calls into async API calls to avoid having to use 
>> the module-wide lock too long. (OpenLDAP 2 libs are not thread-safe.) 
>> The code is somewhat clunky and everybody is invited to dig into that.
> 
> I have always used the async versions of the calls for the same reason. 
> In fact I've never resorted to calling result() with all=0 so far, just 
> because my result sets are (usually) on the smaller side.

Just use the search_s() or search_st() methods which are solely 
implemented in ldap.ldapobject.LDAPObject. I completely removed 
them from the C module part.

Set trace_level=1 when calling ldap.initialize() to track all the 
python-ldap API calls.

> So it's OK if I change the result() implementation within ldapobject.py?
> My idea would be to make result() always return what's expected in the 
> docos, i.e. always a tuple, emulating the 1.x behavior (and avoiding the 
> breakage in my existing code).

You're welcome to dig into that and find the bug I've made. But 
please keep in mind as requirement that the C implementation 
should never be called with all=1.

Note that ldap.ldapobject.LDAPObject.*_s() and 
ldap.ldapobject.LDAPObject.search_st() will also need some 
tweaking after fixing the bug in ldap.ldapobject.LDAPObject.result().

Ciao, Michael.

Re: Strange behavior in Python-LDAP 2.0.0pre04

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

Michael Ströder wrote:

> I noticed it and wanted to change it long ago but did not discuss that 
> here. Thanks for reminding me about this open issue. I guess others 
> didn't notice it since nobody calls result() with all=1. Instead 
> others are using e.g. search_s() instead I guess.

This is a welcome reassurance. I'm not going crazy then ;-)

> I've implemented LDAPObject.result() in ldap.ldapobject which is 
> mainly a wrapper around the internal result() method. The original 
> result() is never called with all=1. Instead LDAPObject.result() 
> handles that internally (also the timeout parameter). The goal was to 
> turn all sync API calls into async API calls to avoid having to use 
> the module-wide lock too long. (OpenLDAP 2 libs are not thread-safe.) 
> The code is somewhat clunky and everybody is invited to dig into that.

I have always used the async versions of the calls for the same reason. 
In fact I've never resorted to calling result() with all=0 so far, just 
because my result sets are (usually) on the smaller side.

So it's OK if I change the result() implementation within ldapobject.py?
My idea would be to make result() always return what's expected in the 
docos, i.e. always a tuple, emulating the 1.x behavior (and avoiding the 
breakage in my existing code).

Suggestions, anyone?

Mauro

Win32 support (was: Strange behavior in Python-LDAP 2.0.0pre04)

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

Mauro Cicognini wrote:
 > P.S. This happens because I've finally managed to compile
 > python-ldap under native Windows 32 (no Cygwin)

That's good news!

Can you package some Win32 binaries?
Maybe we can incorporate the necessary changes if any into 
python-ldap?

Ciao, Michael.

Re: Strange behavior in Python-LDAP 2.0.0pre04

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

Mauro Cicognini wrote:
> I'd wish to bring to your attention a bizarre thing that I noticed 
> yesterday.
> 
> The documentation, at chapter 1.1.5.1 "LDAP operations", in the 
> description of the result() method, states that
> 
> [...]
> The result() method returns a tuple of the form |(/result-type/, 
> /result-data/)|.
> [...]
> 
> Now, I found that this isn't always true in the current (2.0.0pre04) 
> implementation: in fact, when result() is called with the 'all' 
> parameter set to non-zero (which BTW is the default), it returns just 
> the /result-data/ part.

You're absolutely right.

> I'd like to point out again that calling result() with all=0 would 
> return a tuple as documented, instead.
> Moreover, the 1.x version of PythonLDAP result() worked 'correctly', 
> i.e. exactly as documented in all cases.
> 
> I think it's strange that nobody noticed this so far,

I noticed it and wanted to change it long ago but did not discuss 
that here. Thanks for reminding me about this open issue. I guess 
others didn't notice it since nobody calls result() with all=1. 
Instead others are using e.g. search_s() instead I guess.

I've implemented LDAPObject.result() in ldap.ldapobject which is 
mainly a wrapper around the internal result() method. The original 
result() is never called with all=1. Instead LDAPObject.result() 
handles that internally (also the timeout parameter). The goal was 
to turn all sync API calls into async API calls to avoid having to 
use the module-wide lock too long. (OpenLDAP 2 libs are not 
thread-safe.) The code is somewhat clunky and everybody is invited 
to dig into that.

Ciao, Michael.

Strange behavior in Python-LDAP 2.0.0pre04

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

Hi all,
I'd wish to bring to your attention a bizarre thing that I noticed 
yesterday.

The documentation, at chapter 1.1.5.1 "LDAP operations", in the 
description of the result() method, states that

[...]
The result() method returns a tuple of the form |(/result-type/, 
/result-data/)|.
[...]

Now, I found that this isn't always true in the current (2.0.0pre04) 
implementation: in fact, when result() is called with the 'all' 
parameter set to non-zero (which BTW is the default), it returns just 
the /result-data/ part.

In other words, in this case the method returns just a list instead of a 
(string, list) tuple. This breaks all of my code that uses asynchronous 
methods, like for instance this snippet:

    l = ldap.open(LDAPServer)
    msgid = l.simple_bind(username, password)
    status,res = l.result(msgid, all=1, timeout=60)
    if status != 'RES_BIND':
        return -1

will always raise a UnpackTuple exception, since the return value of 
result() will be [] instead of ('RES_BIND', None) as I expected.

Someone may argue that the 'all' parameter is only significant in 
search() responses; this is true, but it still shouldn't cause 
undocumented behavior in the called function, IMHO.
Anyway, this snippet breaks too:

    msgid =
    l.search("o=myCompany.com",ldap.SCOPE_SUBTREE,'uid=a*',['cn','mail'])
    status,res = l.result(msgid, all=1, timeout=60)
    if status != 'RES_SEARCH_RESULT':
        return -1


I tried to figure out if something was wrong on my part, or if I was 
calling some other method in the wrong way, but it appears everything is 
correct and that in fact it's the result() implementation within 
ldapobject.py that does this: the underlying C calls are correct, and 
they return the right data structure.
The code in the result() implementation, if returning all data, simply 
appears to throw away the result type; it builds a list containing all 
results, and returns just that.

I'd like to point out again that calling result() with all=0 would 
return a tuple as documented, instead.
Moreover, the 1.x version of PythonLDAP result() worked 'correctly', 
i.e. exactly as documented in all cases.

I think it's strange that nobody noticed this so far, so I do think I'm 
doing something wrong, or that I missed the discussion on this list 
about changing the result() behavior.

May anyone shed light on this subject?

Thank you in advance

Mauro Cicognini

P.S. This happens because I've finally managed to compile python-ldap 
under native Windows 32 (no Cygwin) and I was doing a bit of testing. 
This was the only problem I noticed so far, but it doesn't look to be 
related to the C part at all...

Re: fetching the structure / obejctClass defs

[Hans A. <Han...@Ph...>]

On Montag, 3. Juni 2002 13:23, Michael Ströder wrote:

> I'd like to see a base class for a LDAP syntax with a method
> validate() which is called when setting the attribute value. More
> or less like I'm doing form parameter validation in PyWebLib. Also
> one could emulate comparison of values by implementing __cmp__().
> With such a vehicle it would be easy to implement new syntaxes by
> just implementing these two methods.

So this would mean that we change the implementation from "syntaxes are 
instances of the syntax class" to "syntaxes are subclasses an 
(abstract) syntax base class". Which objects would then instanciate the 
syntax classes? Maybe some kind of attribute class instances, through 
multiple inheritance?

This is btw. not the only place where we have to decide if we want to 
use inheritance or instanciation for schema information. The same thing 
holds for objectClasses, etc! For objectClasses, inheritance seems to 
make sense, since they inherit from each other, and I think it would be 
possible (in python), to build a class hirachy from server information 
"on the fly". However, this is quite contrary to what I am used to (and 
I think many other programmers, too): Usually, I consider the class 
hirachy as part of the API, which is static.

> You hit one of the famous problems in schema handling. The good
> news is that it seems you understood the problem... ;-)

Too bad. Seems to be a lot of work, then!

-- 
Han...@Ph...

Re: fetching the structure / obejctClass defs

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

Hans Aschauer wrote:
> I just took a deeper look at the sources, and 
> the code seems to look like hand-coded regular expressions.

Uurgs!

I'd like to see a base class for a LDAP syntax with a method 
validate() which is called when setting the attribute value. More 
or less like I'm doing form parameter validation in PyWebLib. Also 
one could emulate comparison of values by implementing __cmp__(). 
With such a vehicle it would be easy to implement new syntaxes by 
just implementing these two methods.

> BTW: Do you know of a more or less complete list of syntax descriptions? 
 > [..]
> many syntaxes there are BNF definitions (which is just fine), but 
> sometimes they reference material which I cannont find online (e.g. the 
> syntax for telefon numbers, 1.3.6.1.4.1.1466.115.121.1.50, is described 
> in E.123). 

You hit one of the famous problems in schema handling. The good 
news is that it seems you understood the problem... ;-)

 > I know sites like http://www.alvestrand.no/objectid/top.html

That's the best I'd come up with.

Ciao, Michael.

Re: fetching the structure / obejctClass defs

[Hans A. <Han...@Ph...>]

On Sonntag, 2. Juni 2002 20:31, Michael Ströder wrote:

> Hans Aschauer wrote:

[...]

>  > Does anybody know of some high-level overview (i.e. tutorial
>  > style, not RFC's) on this basic-encoding-rules thing (and, if
>  > possible, how it is used in (open)ldap)?
>
> There's something called "A Layman's Introduction to BER, DER and
> ASN.1" on RSA's web site.

Thank you!

> Hmm, then it does not make sense to me. Also I believe that we can
> come up with a better Pythonic design if we define thoroughly
> thought Python classes.

Ok, I think you are right. I just took a deeper look at the sources, and 
the code seems to look like hand-coded regular expressions. Rewriting 
this in python does really make sense...

BTW: Do you know of a more or less complete list of syntax descriptions? 
I know sites like http://www.alvestrand.no/objectid/top.html, and for 
many syntaxes there are BNF definitions (which is just fine), but 
sometimes they reference material which I cannont find online (e.g. the 
syntax for telefon numbers, 1.3.6.1.4.1.1466.115.121.1.50, is described 
in E.123). 

Hans 

-- 
Han...@Ph...

Re: fetching the structure / obejctClass defs

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

Hans Aschauer wrote:
 >
 > Michael, what do you think, would it be worth the effort
 > digging into
 > the openldap sources in order to pythonize the server-side
 > syntax checking and attribute matching facilities for client
 > use?

Only if the API is not subject to continous changes. We have to
ask that on OpenLDAP-software mailing list. I suspect the answer
of Kurt is "don't rely on that API".

 > [One hour later after scanning the openldap sources] I think I
 > could do it, but for this I would need to teach myself
 > "something" about BER.

Hmm, if someone is digging into ber.h we're very near to an
approach where we re-implement parts of the LDAP protocol engine.

 > Does anybody know of some high-level overview (i.e. tutorial
 > style, not RFC's) on this basic-encoding-rules thing (and, if
 > possible, how it is used in (open)ldap)?

There's something called "A Layman's Introduction to BER, DER and
ASN.1" on RSA's web site.

 > The disadvantage of this borrow-code-from-openldap-approach is
 > that we will face some licensing fun, and that we will get more
 > entangled with
 > the openldap server (i.e. syntax checking is only available for
 >  syntaxes supported by the openldap server, etc.)

Hmm, then it does not make sense to me. Also I believe that we can
come up with a better Pythonic design if we define thoroughly
thought Python classes.

Ciao, Michael.

FYI: Linuxtag

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

HI!

BTW: Anyone who wants to ask me personally about python-ldap 
programming or web2ldap can do so at the Crypto booth at Linuxtag 
2002 in Karlsruhe, Germany from 2002-06-06 until 2002-06-09.

http://www.linuxtag.de

Ciao, Michael.

Re: fetching the structure / obejctClass defs

[Hans A. <Han...@Ph...>]

On Mittwoch, 29. Mai 2002 13:40, Michael Ströder wrote:

[...]

> Now I can only do case-insensitive string matching which is most
> times right. But in a completely correct implementation the
> matching should be done according to the matching rules defined
> for these attributes used.

Michael, what do you think, would it be worth the effort digging into 
the openldap sources in order to pythonize the server-side syntax 
checking and attribute matching facilities for client use? 

[One hour later after scanning the openldap sources] I think I could do 
it, but for this I would need to teach myself "something" about BER. 
Does anybody know of some high-level overview (i.e. tutorial style, not 
RFC's) on this basic-encoding-rules thing (and, if possible, how it is 
used in (open)ldap)?  

The disadvantage of this borrow-code-from-openldap-approach is that we 
will face some licensing fun, and that we will get more entangled with 
the openldap server (i.e. syntax checking is only available for 
syntaxes supported by the openldap server, etc.)


Hans

-- 
Han...@Ph...

Re: fetching the structure / obejctClass defs

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

je...@ne... wrote:
> On Mon, May 27, 2002 at 08:36:11PM +0200, Michael Str=F6der wrote:
>=20
>>BTW: Just fetching objectClass definition is the easy part of the=20
>>show. We have to think about how to implement and register known=20
>>LDAP syntaxes for displaying, matching and input handling.
>=20
> What do you mean by 'matching'? Matching different values in reversed
> polish notation according to their syntaxes and matching rules? Is that=

> not supposed to be done by the LDAP server?

Yes it's done by the LDAP server when processing search and=20
compare requests. But it's also handy for having it at the=20
client-side. E.g. in recent web2ldap I'm checking for=20
characteristic attributes (attributes used for forming RDN) and=20
disallow modifying it in the normal modify input form since weird=20
things can happen on various LDAP servers.

Now I can only do case-insensitive string matching which is most=20
times right. But in a completely correct implementation the=20
matching should be done according to the matching rules defined=20
for these attributes used.

> And what about 'input
> handling' -- client-side classchecking?

Syntax checking of attribute values in user's input.

> I guess I'm totally wrong, but I
> have no idea how schema parsing might be usefull except displaying
> available classes and attributetypes...

Think of displaying attribute values in a UI. It helps if you have=20
knowledge about the syntax used: normal UTF-8 strings vs. ASCII=20
strings, E-mail addresses as mailto:-link  or URLs as active links=20
or...

Ciao, Michael.

Re: fetching the structure / obejctClass defs

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

Tjabo Kloppenburg wrote:
> 
>>I've recently checked in the patches contributed by Hans Aschauer
>>which wraps the schema parser function in OpenLDAP 2 libs and
>>provide a new sub module ldap.schema...
 >
> so this is part of python-ldap?

It *will be* part of python-ldap. It's not ready to
be released yet.

BTW: Just fetching objectClass definition is the easy part of the 
show. We have to think about how to implement and register known 
LDAP syntaxes for displaying, matching and input handling.

Ciao, Michael.

Re: problem with modify using python-ldap

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

Howard Chu wrote:
 >>    do_modify: dn (iuEduUPID=9900000004,ou=people,dc=iu,dc=edu)
 >>    modifications:
 >>            delete: iuEduMailDeliveryTo
 >>            add: iuEduMailDeliveryTo
 >>    ldbm_back_modify:
 >>    ldbm_modify_internal: delete
 >>    removing entire attribute iuEduMailDeliveryTo
 >>    ldbm_modify_internal: add
 >>    ldbm_modify_internal: replace
 >>    ldbm_modify_internal: replace
 >>    ldap_read: want=1 error=Resource temporarily unavailable
 >> **** hangs for about 9 seconds here ****
 >>    send_ldap_result: 0::
 >
> The "Resource Unavailable" message means a system call failed with errno =
> EAGAIN. In this case, ldap_read was trying to read from the connection and
> there was no data available. Sounds like the python library isn't flushing
> the entire LDAP request out to the network.

Hmm, I have no clue why that happens. I've never had this problem 
except with some very strange LDAP servers like bigfoot's.

Howard, how to make sure the LDAP request is flushed?

Allan, if this problem occurs again can you post the relevant 
snippets of your Python code and can you also use trace_level=1 
when calling ldap.open() or ldap.initialize() which writes a trace 
log containing all the python-ldap API calls (maybe solely on 
python-ldap-dev).

Ciao, Michael.

Re: Size limit exceeded

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

Igor Stroh wrote:
> 
> I've got a little problem here with big result sets returned by the
> search_s method... my slapd has a sizelimit set to 500 (default
> value)... now the thing is, I have about 20.000 entries returned by a
> search query and I really need _all_ of them...

Several possibilities:
1. Ask the admin to increase the size limit.
2. Do several searches.

 > so is there a
> possibility to say 'give me just result[start:offset] records for this
> search'?

No. You can just limit search by everything you can mention in a 
LDAP search filter. A general LDAP forum is more appropriate to 
discuss this.

 > I mean I could increase the sizelimit for the ldap server but
> that would affect other applications then my python apps

Some LDAP servers can impose different size limits for different 
bind DNs. Usually the Manager DN is not affected by size limits 
and ACLs.

Ciao, Michael.

Size limit exceeded

[Igor S. <st...@sc...>]

Hi there,

I've got a little problem here with big result sets returned by the
search_s method... my slapd has a sizelimit set to 500 (default
value)... now the thing is, I have about 20.000 entries returned by a
search query and I really need _all_ of them... so is there a
possibility to say 'give me just result[start:offset] records for this
search'? I mean I could increase the sizelimit for the ldap server but
that would affect other applications then my python apps (e.g. GQ)
either which I definitely want to avoid... Also, I could run the query
asynchronously using search() instead of search_s(), but that would
require to rewrite a whole bunch of my apps... Any suggestions?

TIA,
Igor
--=20
ScanPlus GmbH NOC Ulm - Germany - Griesbadgasse 7-13 - D 89073 Ulm
TEL +49 731 920 13 100 - FAX +49 731 920 13 290
eMail: su...@sc...
Amtsgericht Ulm - HRB3220 - Geschaeftsfuehrer: Juergen Hoermann

Re: start TLS

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

David Margrave wrote:
> 
> but I can't find any reference anywhere for how to configure a client with
> a local store of 'trusted root CA certificates'.  This means that a
> man-in-the-middle attack is still possible.

You can set it globally.

ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,'/etc/ssl.crt/cacerts.pem')

or

ldap.set_option(ldap.OPT_X_TLS_CACERTDIR,'/etc/ssl.crt')

I didn't succeed setting it for a specific LDAP connection but I 
may have done something wrong.

> Can anyone provide a bit of insight?  Maybe the python-ldap module could
> be made a bit more flexible than client apps like ldapsearch in this
> regard, say by giving the developer the option of providing certificate
> verification callbacks, etc. 

IMHO we have to rely on what the OpenLDAP 2 libs are exposing. 
Certificate validation is IMHO incomplete at the moment e.g. CRL 
checking is not supported.

In theory OpenSSL's SSL context structure would allow to set such 
a call-back function. But i doubt we can access that safely 
through OpenLDAP's API.

Off course you're welcome to dig into this and find a better solution.

Ciao, Michael.

RE: problem with modify using python-ldap

[Allan S. <as...@in...>]

On Wed, 22 May 2002, Howard Chu wrote:

> The "Resource Unavailable" message means a system call failed with errno
> = EAGAIN. In this case, ldap_read was trying to read from the connection
> and there was no data available. Sounds like the python library isn't
> flushing the entire LDAP request out to the network.
>
> The fact that the behavior changes with debug level set to 1 is
> disturbing.  It sounds like some kind of race condition is involved,
> because there should not be any ldap_read's occurring between the modify
> completing and sending its result. You didn't specify which version of
> RedHat Linux you're using, but I'd guess you're on 7.0 or 7.1 with a
> buggy threads library.

It is RedHat 7.2.  I am not seeing this anymore, the last hour or so.
Have not changed anything, but start and stop slapd a bunch of times with
different debugging levels.  It's back to my normal 256 at this time, and
everything is working.  ???

Allan

RE: problem with modify using python-ldap

[Howard C. <hy...@hi...>]

The "Resource Unavailable" message means a system call failed with errno =
EAGAIN. In this case, ldap_read was trying to read from the connection and
there was no data available. Sounds like the python library isn't flushing
the entire LDAP request out to the network.

The fact that the behavior changes with debug level set to 1 is disturbing.
It sounds like some kind of race condition is involved, because there should
not be any ldap_read's occurring between the modify completing and sending
its result. You didn't specify which version of RedHat Linux you're using,
but I'd guess you're on 7.0 or 7.1 with a buggy threads library.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: own...@Op...
> [mailto:own...@Op...]On Behalf Of Allan Streib

> Using python-ldap-python-ldap-2.0.0pre04 with Python 2.2.1, and OpenLDAP
> 2.0.23 on RedHat Linux.
>
> Deleting and adding an attribute is taking 9 seconds.  The same actions
> using ldapmodify(1) on the command line complete virtually instantly.
>
> Oddly, the behavior does not manifest if log level 1 (trace function
> calls) is enabled.  Here is a log snip at level 6 (heavy trace debugging
> plus debug packet handling).  This first snip is with ldapmodify(1) as the
> client:
>
>     do_modify: dn (iuEduUPID=9900000004,ou=people,dc=iu,dc=edu)
>     modifications:
>             delete: iuEduMailDeliveryTo
>             add: iuEduMailDeliveryTo
>     ldbm_back_modify:
>     ldbm_modify_internal: delete
>     removing entire attribute iuEduMailDeliveryTo
>     ldbm_modify_internal: add
>     ldbm_modify_internal: replace
>     ldbm_modify_internal: replace
>     send_ldap_result: 0::
>
> Now with python-ldap's modify_s operation as the client:
>
>     do_modify: dn (iuEduUPID=9900000004,ou=people,dc=iu,dc=edu)
>     modifications:
>             delete: iuEduMailDeliveryTo
>             add: iuEduMailDeliveryTo
>     ldbm_back_modify:
>     ldbm_modify_internal: delete
>     removing entire attribute iuEduMailDeliveryTo
>     ldbm_modify_internal: add
>     ldbm_modify_internal: replace
>     ldbm_modify_internal: replace
>     ldap_read: want=1 error=Resource temporarily unavailable
>  **** hangs for about 9 seconds here ****
>     send_ldap_result: 0::
>
> Ultimately the modifications succeed.  The difference I see is that
> "Resource temporarily unavailable" message -- what is that resource?
>
> Any ideas for further troubleshooting?
>
> Thanks,
>
> Allan
>

problem with modify using python-ldap

[Allan S. <as...@in...>]

Using python-ldap-python-ldap-2.0.0pre04 with Python 2.2.1, and OpenLDAP
2.0.23 on RedHat Linux.

Deleting and adding an attribute is taking 9 seconds.  The same actions
using ldapmodify(1) on the command line complete virtually instantly.

Oddly, the behavior does not manifest if log level 1 (trace function
calls) is enabled.  Here is a log snip at level 6 (heavy trace debugging
plus debug packet handling).  This first snip is with ldapmodify(1) as the
client:

    do_modify: dn (iuEduUPID=9900000004,ou=people,dc=iu,dc=edu)
    modifications:
            delete: iuEduMailDeliveryTo
            add: iuEduMailDeliveryTo
    ldbm_back_modify:
    ldbm_modify_internal: delete
    removing entire attribute iuEduMailDeliveryTo
    ldbm_modify_internal: add
    ldbm_modify_internal: replace
    ldbm_modify_internal: replace
    send_ldap_result: 0::

Now with python-ldap's modify_s operation as the client:

    do_modify: dn (iuEduUPID=9900000004,ou=people,dc=iu,dc=edu)
    modifications:
            delete: iuEduMailDeliveryTo
            add: iuEduMailDeliveryTo
    ldbm_back_modify:
    ldbm_modify_internal: delete
    removing entire attribute iuEduMailDeliveryTo
    ldbm_modify_internal: add
    ldbm_modify_internal: replace
    ldbm_modify_internal: replace
    ldap_read: want=1 error=Resource temporarily unavailable
 **** hangs for about 9 seconds here ****
    send_ldap_result: 0::

Ultimately the modifications succeed.  The difference I see is that
"Resource temporarily unavailable" message -- what is that resource?

Any ideas for further troubleshooting?

Thanks,

Allan

Re: fetching the structure / obejctClass defs

[Tjabo K. <t.k...@bi...>]

hi,

> I've recently checked in the patches contributed by Hans Aschauer
> which wraps the schema parser function in OpenLDAP 2 libs and
> provide a new sub module ldap.schema...

so this is part of python-ldap?


tk.

-- 
Mit freundlichem Gruß
 
Tjabo Kloppenburg - billiton internet services GmbH
Entwicklung+Technik
--------------------------------------------------------------
direct phone: 0271/30386-19 direct mail: t.k...@bi...
Weitere Informationen finden Sie unter http://www.billiton.de/

Re: fetching the structure / obejctClass defs

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

Igor Stroh wrote:
> 
> actually it is, but the representation type of attributeTypes and
> objectClasses is 'string', so you get a list of strings that you first
> have to parse somehow if you want to utilize it... see [1], it works for
> me, but I'm pretty sure I left some schema attributes (like STRUCTURAL
> etc.) out, so I might just as well fail to return correct values for
> your own objectClass... it parses 'person' pretty neat though...

I've recently checked in the patches contributed by Hans Aschauer 
which wraps the schema parser function in OpenLDAP 2 libs and 
provide a new sub module ldap.schema.

I also made some changes to the Python parts which I will check in 
this weekend.

Well, full LDAPv3 schema support goes far beyond just knowing 
which attribute types are required/allowed. Especially it would be 
very interesting to implement a set of syntaxes with their 
matching rules. This would allow to check the syntax of data input 
and display the data with more a-priori knowledge.

Ciao, Michael.

Re: python-ldap-2.0.0pre04

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

Jel...@Bi... wrote:
> 
> I  just tried it once more. First I cleared the site-packages folder.
> Then I began with python-ldap-2.0.0pre04.tar.gz.
> After having installed I still get that
> ImportError: Failure linking new module

I have no idea about Mac OSX. Under Linux I would try ldd to check 
if the shared libs are found.

Ciao, Michael.

Re: fetching the structure / obejctClass defs

[Igor S. <st...@sc...>]

Heya,

On Fre, 2002-05-17 at 11:45, Tjabo Kloppenburg wrote:
> is it possible to fetch a list of all supported objectClasses and their a=
ttribs
> from an openLDAP server using python-ldap?
>=20
> how?

actually it is, but the representation type of attributeTypes and
objectClasses is 'string', so you get a list of strings that you first
have to parse somehow if you want to utilize it... see [1], it works for
me, but I'm pretty sure I left some schema attributes (like STRUCTURAL
etc.) out, so I might just as well fail to return correct values for
your own objectClass... it parses 'person' pretty neat though...


HTH,
Igor

[1]:
#!/usr/bin/python2.1
import ldap
import string
import re

# bind credentials
ADMIN_DN =3D "<admin dn>"
ADMIN_PW =3D "<admin bind pw>"
# which objectClass(es) should we look for
O_CLASSES =3D ['person']

# some global RE objects
search_oid          =3D re.compile("^\\( (?P<oid>\d.*\d) .*")
search_name         =3D re.compile(".* NAME '(?P<name>[a-zA-Z0-9_]+)' .*")
search_desc         =3D re.compile(".* DESC '(?P<desc>.*)' .*")
search_must_attr    =3D
re.compile(".*\s?MUST\s?\\(\s?(?P<must_attr>[a-zA-Z0-9_$\
           ]+)\s?\\)\s?.*")
search_may_attr      =3D
re.compile(".*\s?MAY\s?\\(\s?(?P<may_attr>[a-zA-Z0-9_$ ]+)\s?\\)\s?.*")

def init_all():
    filter =3D ".*NAME '%s'.*" % O_CLASSES[0]
    del O_CLASSES[0]
    for cl in O_CLASSES:
        filter +=3D "|.*NAME '%s'.*" % O_CLASSES[0]

    ls =3D re.compile(filter, re.I)

    con =3D ldap.open("212.75.33.146")
    con.simple_bind_s(ADMIN_DN,ADMIN_PW)

    entries =3D con.search_s("cn=3DSubschema", ldap.SCOPE_BASE, \
                     "objectclass=3Dsubschema", ['objectclasses'])
    ocs =3D entries[0][1]['objectClasses']
    return [oc for oc in ocs if ls.search(oc)]

def parseIt():
    ocs =3D init_all()
    ret =3D {}
    for i in ocs:
        key =3D search_name.sub("\g<name>", i)
        ret[key] =3D {}
        ret[key]['OID'] =3D search_oid.sub("\g<oid>", i)
        if search_desc.search(i):
            ret[key]['DESC'] =3D search_desc.sub("\g<desc>", i)
        else:
            ret[key]['DESC'] =3D ""
        if search_must_attr.search(i):
            ret[key]['MUST'] =3D [attr.strip() for attr in \
            string.split(search_must_attr.sub("\g<must_attr>", i), "$")]
        else:
            ret[key]['MUST'] =3D []
        if search_may_attr.search(i):
            ret[key]['MAY'] =3D [attr.strip() for attr in \=20
            string.split(search_may_attr.sub("\g<may_attr>", i), "$")]
        else:
            ret[key]['MAY'] =3D []

    return ret

def getAllAttributes():
    attrs =3D []
    ocs =3D parseIt()
    for key in ocs.keys():
            attrs =3D attrs + ocs[key]['MUST'] + ocs[key]['MAY']
    return attrs


--=20
ScanPlus GmbH NOC Ulm - Germany - Griesbadgasse 7-13 - D 89073 Ulm
TEL +49 731 920 13 100 - FAX +49 731 920 13 290
eMail: su...@sc...
Amtsgericht Ulm - HRB3220 - Geschaeftsfuehrer: Juergen Hoermann