python-ldap-dev — discussion among developers

Re: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a released

[Rich M. <ric...@gm...>]

On 03/07/2011 10:35 AM, Michael Ströder wrote:
> Rich Megginson wrote:
>>    On 03/06/2011 06:14 PM, Chaos Eternal wrote:
>>> should we re-implement python-ldap on pyasn and get rid of depends on
>>> openldap libs?
>>>
>> I vote no.  Why would you want to do that?  How would you implement
>> TLS/SSL?  How would you implement SASL/GSSAPI?  How would you keep up
>> with openldap client library development, which is the reference
>> standard for LDAP in the FOSS world?
> David and me already thought about this two years ago. And for the same
> reasons Rich mentioned I won't go that route because it's simply too much work
> to get it right. Additionally there's the performance aspect.
>
> BTW: There is already a pure-Python LDAP module called 'ldaptor'.
> http://eagain.net/talks/ldaptor/index.html
>
> But I'm currently using pyasn1 for certain LDAPv3 extended operations/controls
> and therefore I am thinking about adding some of the basic LDAP-related ASN.1
> stuff to python-ldap 2.4.x. But this would introduce a dependency on pyasn1.
> Pros/Cons?
RHEL does not include pyasn1.  But it is extremely useful for 
extops/controls - doing BER codec by hand is not fun.  A mid-way 
approach would be to expose the liblber ber_scanf/ber_printf and support 
functions in python.

If you do decide that it is necessary for python-ldap to use pyasn1, we 
can work on getting it into RHEL.  The Fedora python-pyasn1 maintainer 
is one of the guys on the freeipa team which uses python-ldap heavily.
> Ciao, Michael.

Re: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a released

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

Rich Megginson wrote:
>   On 03/06/2011 06:14 PM, Chaos Eternal wrote:
>>
>> should we re-implement python-ldap on pyasn and get rid of depends on
>> openldap libs?
>>
> I vote no.  Why would you want to do that?  How would you implement
> TLS/SSL?  How would you implement SASL/GSSAPI?  How would you keep up
> with openldap client library development, which is the reference
> standard for LDAP in the FOSS world?

David and me already thought about this two years ago. And for the same
reasons Rich mentioned I won't go that route because it's simply too much work
to get it right. Additionally there's the performance aspect.

BTW: There is already a pure-Python LDAP module called 'ldaptor'.
http://eagain.net/talks/ldaptor/index.html

But I'm currently using pyasn1 for certain LDAPv3 extended operations/controls
and therefore I am thinking about adding some of the basic LDAP-related ASN.1
stuff to python-ldap 2.4.x. But this would introduce a dependency on pyasn1.
Pros/Cons?

Ciao, Michael.

Re: Minimum version of OpenLDAP libs for python-ldap 2.4.x?

[Rich M. <ric...@gm...>]

On 03/04/2011 12:17 PM, Michael Ströder wrote:
> (Cc:-ed python-ldap-dev again)
>
> Chris Dukes wrote:
>> On Fri, Mar 04, 2011 at 07:45:15PM +0100, Michael Ströder wrote:
>>> Again it's time to think about the minimum required version of OpenLDAP libs
>>> to be used for building upcoming python-ldap 2.4.0. I'd vote for strictly
>>> requiring a fairly recent version in the OpenLDAP 2.4.x release series. I know
>>> that this rules out using packages provided in RHEL 5 or similar old
>>> enterprise Linux distros.
>>>
>>> I'm asking because support for the assertion control was fixed/extended in
>>> HEAD but it relies on OpenLDAP 2.4.11+. Currently it's hidden behind a
>>> #ifdef LIBLDAP_HAS_ASSERTION_CONTROL_FUNC
>>> but I generally don't like to have features which are there or not there
>>> depending on the build.
I am in favor of having python-ldap 2.4 support openldap 2.4
>> No newer than what initially shipped with RHEL 6.0
> RHEL 6 is fairly new.
RHEL 6 has openldap 2.4.19 - RHEL 6.1 will have openldap 2.4.23 + many 
of the patches that ended up in .24.
>> I deal with production systems and boneheaded management that wants
>> worthless support contracts for items like the OS.
>> For the ones that don't ship OpenLDAP, requiring a new version isn't much of
>> an issue.  However, for the ones that do ship OpenLDAP it's the choice between
>> the support nightmare of "That part isn't at a supported version" when
>> something unrelated breaks and the support nightmare of maintaining a couple
>> custom chroots with a horribly de-skilled set of admins.
> Believe me I know all this quite well from various discussion with my customer
> and their admins. But strictly speaking in support terms you would not even be
> allowed to install a self-compiled version of python-ldap. And Red Hat won't
> provide an update of python-ldap 2.4.x for RHEL 6.0 anyway.
It would be difficult, but not entirely out of the question.  There are 
several new projects in RHEL6 like ipa that use python-ldap pretty heavily.
>> It's more work, and more parts to break, but I'd suggest tinkering around to
>> see if the version # can be pulled from the OpenLDAP library and have some
>> python class implementations that depend on the version to change whether
>> they return an supported version exception.
> This could be done and in some parts it's already done in python-ldap and my
> web2ldap. But...
>
> Normally dependencies are:
> pkg A ver. x depends on pkg B ver. y
>
> With you suggestion above this gets even worse:
> pkg A ver. x depends on pkg B ver. y built with options m, n, etc.
>
> So imagine how to write that in a decent operational manual.
>
> Or the whole chain of components treat everything optionally which is a
> nightmare to maintain in code and makes users quite unhappy...
>
> Ciao, Michael.
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a released

[Rich M. <ric...@gm...>]

On 03/06/2011 06:14 PM, Chaos Eternal wrote:
>
> should we re-implement python-ldap on pyasn and get rid of depends on 
> openldap libs?
>
I vote no.  Why would you want to do that?  How would you implement 
TLS/SSL?  How would you implement SASL/GSSAPI?  How would you keep up 
with openldap client library development, which is the reference 
standard for LDAP in the FOSS world?
> ---------- Forwarded message ----------
> From: "Ilya Etingof" <il...@gl... <mailto:il...@gl...>>
> Date: Mar 7, 2011 12:18 AM
> Subject: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a 
> released
> To: <pya...@li... 
> <mailto:pya...@li...>>
>
>
> This is to let you know that pyasn1-0.0.13a has been released. This new
> release brings the following major changes:
>
> * Very significant performance improvement on frequent operations
> * ASN.1 ANY type is fully supported
> * Enclosed documentation re-written and now covers many aspects
> * Minor bugfixes and improvements (see CHANGES)
>
> Another project news is that all ASN.1 protocol modules, previously
> distributed with pyasn1 as examples, were stripped off pyasn1 library and
> are now distributed alone.
>
> These modules were re-written to be importable and installable, thus
> easily used by other applications.
>
> The following protocol modules are now shipped with the pyasn1-modules
> package:
>
> * X.509
> * PKCS#7
> * OCSP
> * SNMP
> * SSH keys
>
> For each module a simple command-line tool is also included to help you
> test the them right away.
>
> -ilya
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> pyasn1-users mailing list
> pya...@li... 
> <mailto:pya...@li...>
> https://lists.sourceforge.net/lists/listinfo/pyasn1-users
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a released

[Chaos E. <cha...@gm...>]

should we re-implement python-ldap on pyasn and get rid of depends on
openldap libs?
---------- Forwarded message ----------
From: "Ilya Etingof" <il...@gl...>
Date: Mar 7, 2011 12:18 AM
Subject: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a released
To: <pya...@li...>


This is to let you know that pyasn1-0.0.13a has been released. This new
release brings the following major changes:

* Very significant performance improvement on frequent operations
* ASN.1 ANY type is fully supported
* Enclosed documentation re-written and now covers many aspects
* Minor bugfixes and improvements (see CHANGES)

Another project news is that all ASN.1 protocol modules, previously
distributed with pyasn1 as examples, were stripped off pyasn1 library and
are now distributed alone.

These modules were re-written to be importable and installable, thus
easily used by other applications.

The following protocol modules are now shipped with the pyasn1-modules
package:

* X.509
* PKCS#7
* OCSP
* SNMP
* SSH keys

For each module a simple command-line tool is also included to help you
test the them right away.

-ilya

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
pyasn1-users mailing list
pya...@li...
https://lists.sourceforge.net/lists/listinfo/pyasn1-users

Re: Minimum version of OpenLDAP libs for python-ldap 2.4.x?

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

Zhang Huangbin wrote:
> 
> On Mar 5, 2011, at 2:45 AM, Michael Ströder wrote:
> 
>> Again it's time to think about the minimum required version of OpenLDAP libs
>> to be used for building upcoming python-ldap 2.4.0.
> 
> Does it mean py-ldap-2.4.0 won't support OpenLDAP-2.3.x series?

Yes.

> Debian 5, RHEL/CentOS 5 ships OpenLDAP-2.3.x.

Well, python-ldap 2.3.x will still be around. So if you're using this distros
you have to stick with python-ldap 2.3.x which IMHO is sufficient to run the
applications implemented on top of python-ldap so far. Applications requiring
new features will need new python-ldap and therefore newer OpenLDAP libs. This
is a common practice.

> I don't think it's a good strategy to force sys admin to compile/install
> openldap-2.4 on  production server, if they want to update openldap, they
> have to compile again and again.

Well, as said: If you don't want to compile on systems you won't install new
python-ldap 2.4 anyway on these old systems.

Ciao, Michael.

Re: Minimum version of OpenLDAP libs for python-ldap 2.4.x?

[Zhang H. <zhb...@gm...>]

On Mar 5, 2011, at 2:45 AM, Michael Ströder wrote:

> Again it's time to think about the minimum required version of OpenLDAP libs
> to be used for building upcoming python-ldap 2.4.0.

Does it mean py-ldap-2.4.0 won't support OpenLDAP-2.3.x series?

Debian 5, RHEL/CentOS 5 ships OpenLDAP-2.3.x.

I don't think it's a good strategy to force sys admin to compile/install openldap-2.4 on  production server, if they want to update openldap, they have to compile again and again.

Re: Minimum version of OpenLDAP libs for python-ldap 2.4.x?

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

(Cc:-ed python-ldap-dev again)

Chris Dukes wrote:
> On Fri, Mar 04, 2011 at 07:45:15PM +0100, Michael Ströder wrote:
>> Again it's time to think about the minimum required version of OpenLDAP libs
>> to be used for building upcoming python-ldap 2.4.0. I'd vote for strictly
>> requiring a fairly recent version in the OpenLDAP 2.4.x release series. I know
>> that this rules out using packages provided in RHEL 5 or similar old
>> enterprise Linux distros.
>>
>> I'm asking because support for the assertion control was fixed/extended in
>> HEAD but it relies on OpenLDAP 2.4.11+. Currently it's hidden behind a
>> #ifdef LIBLDAP_HAS_ASSERTION_CONTROL_FUNC
>> but I generally don't like to have features which are there or not there
>> depending on the build.
> 
> No newer than what initially shipped with RHEL 6.0

RHEL 6 is fairly new.

> I deal with production systems and boneheaded management that wants 
> worthless support contracts for items like the OS.
> For the ones that don't ship OpenLDAP, requiring a new version isn't much of
> an issue.  However, for the ones that do ship OpenLDAP it's the choice between
> the support nightmare of "That part isn't at a supported version" when
> something unrelated breaks and the support nightmare of maintaining a couple
> custom chroots with a horribly de-skilled set of admins.

Believe me I know all this quite well from various discussion with my customer
and their admins. But strictly speaking in support terms you would not even be
allowed to install a self-compiled version of python-ldap. And Red Hat won't
provide an update of python-ldap 2.4.x for RHEL 6.0 anyway.

> It's more work, and more parts to break, but I'd suggest tinkering around to
> see if the version # can be pulled from the OpenLDAP library and have some
> python class implementations that depend on the version to change whether
> they return an supported version exception.

This could be done and in some parts it's already done in python-ldap and my
web2ldap. But...

Normally dependencies are:
pkg A ver. x depends on pkg B ver. y

With you suggestion above this gets even worse:
pkg A ver. x depends on pkg B ver. y built with options m, n, etc.

So imagine how to write that in a decent operational manual.

Or the whole chain of components treat everything optionally which is a
nightmare to maintain in code and makes users quite unhappy...

Ciao, Michael.

Minimum version of OpenLDAP libs for python-ldap 2.4.x?

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

HI!

Again it's time to think about the minimum required version of OpenLDAP libs
to be used for building upcoming python-ldap 2.4.0. I'd vote for strictly
requiring a fairly recent version in the OpenLDAP 2.4.x release series. I know
that this rules out using packages provided in RHEL 5 or similar old
enterprise Linux distros.

I'm asking because support for the assertion control was fixed/extended in
HEAD but it relies on OpenLDAP 2.4.11+. Currently it's hidden behind a
#ifdef LIBLDAP_HAS_ASSERTION_CONTROL_FUNC
but I generally don't like to have features which are there or not there
depending on the build.

The above is only one example. I could think of more features to be added. And
I think the feature set of python-ldap 2.4.0 should be as independent from the
build options as possible.

Ciao, Michael.

Re: please review encode_assertion_control()

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

Michael Ströder wrote:
> Rich Megginson wrote:
>> On 03/03/2011 01:28 PM, Michael Ströder wrote:
>>> Could somebody please look what's wrong with
>>> encode_assertion_control() in
>>> Modules/ldapcontrol.c? It seg faults.
>>     err =
>> ldap_create_assertion_control_value(NULL,assertion_filterstr,&ctrl_val);
>> The NULL should be an LDAP* and it must be valid.
>>
>> It needs the LDAP* handle because it calls ldap_alloc_ber_with_options()
>> to allocate the BER for the control value.
> 
> Thanks for the hint. But how can I create a LDAP* handle locally without
> having to pass in the connection object as argument?

Seems calling ldap_create() did the trick:

$ python -c "import ldap;print
repr(ldap.encode_assertion_control('(objectClass=*)'))"
'\x87\x0bobjectClass'

Not sure whether error checking is correct though.

Ciao, Michael.

Re: please review encode_assertion_control()

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

Rich Megginson wrote:
> On 03/03/2011 01:28 PM, Michael Ströder wrote:
>> Could somebody please look what's wrong with
>> encode_assertion_control() in
>> Modules/ldapcontrol.c? It seg faults.
>     err =
> ldap_create_assertion_control_value(NULL,assertion_filterstr,&ctrl_val);
> The NULL should be an LDAP* and it must be valid.
> 
> It needs the LDAP* handle because it calls ldap_alloc_ber_with_options()
> to allocate the BER for the control value.

Thanks for the hint. But how can I create a LDAP* handle locally without
having to pass in the connection object as argument?

Ciao, Michael.

Sync State Control question

[Gregory F. <gre...@sa...>]

Hello,

When i delete a Member Uid attr form an entry with Luma, my python ldap
client receive a sync data, but how to get Sync State Control Value who
says that a deletion occurs (sync state value = 3).

I need to know what modification was made, add, delete, modify ?
Also why sever controls field is empty in the output and those controls
appear at the last elements of result data ?

I am using python-ldap version 2.4.0 and openldap version 2.4.23

Thanks for your answers.





==== THE CODE ====

import _ldap, ldap
import logging
import pprint
import re
import sys
import struct

import _ldap
from ldap.controls import LDAPControl
from ldap.cidict import cidict


class SyncStateControl(LDAPControl):
    """
    The Sync State Control is an LDAP Control [RFC4511] where the
    controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the
    controlValue, an OCTET STRING, contains a BER-encoded syncStateValue.
    The criticality is FALSE.

      syncStateValue ::= SEQUENCE {
          state ENUMERATED {
              present (0),
              add (1),
              modify (2),
              delete (3)
          },
          entryUUID syncUUID,
          cookie    syncCookie OPTIONAL
      }

    The Sync State Control is only applicable to SearchResultEntry and
    SearchResultReference Messages.
    """
    controlType = '1.3.6.1.4.1.4203.1.9.1.2'

    def __init__(self, controlType='1.3.6.1.4.1.4203.1.9.1.2',
                 criticality=False, controlValue=None,
encodedControlValue=None):

        LDAPControl.__init__(self, self.controlType, criticality,
                             controlValue, encodedControlValue)

    def encodeControlValue(self, value):
        print 'STATE encode'

    def decodeControlValue(self, value):
        print 'STATE decode'



class SyncDoneControl(LDAPControl):
    """
    The Sync Done Control is an LDAP Control [RFC4511] where the
    controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the
    controlValue contains a BER-encoded syncDoneValue.  The criticality
    is FALSE (and hence absent).

      syncDoneValue ::= SEQUENCE {
          cookie          syncCookie OPTIONAL,
          refreshDeletes  BOOLEAN DEFAULT FALSE
      }

    The Sync Done Control is only applicable to the SearchResultDone
    Message.
    """
    controlType = '1.3.6.1.4.1.4203.1.9.1.3'

    def __init__(self, controlType='1.3.6.1.4.1.4203.1.9.1.3',
                 criticality=False, controlValue=None,
encodedControlValue=None):

        LDAPControl.__init__(self, self.controlType, criticality,
                             controlValue, encodedControlValue)

    def encodeControlValue(self, value):
        print 'DONE encode'

    def decodeControlValue(self, value):
        print 'DONE decode'


class SyncRequestControl(LDAPControl):
  # The Sync Request Control is an LDAP Control [RFC4511] where the
  # controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the
  # controlValue, an OCTET STRING, contains a BER-encoded
  # syncRequestValue.  The criticality field is either TRUE or FALSE.
  #   syncRequestValue ::= SEQUENCE {
  #     mode ENUMERATED {
  #                      -- 0 unused
  #                      refreshOnly       (1),
  #                      -- 2 reserved
  #                      refreshAndPersist (3)
  #     },
  #     cookie     syncCookie OPTIONAL,
  #     reloadHint BOOLEAN DEFAULT FALSE
  #   }
  # The Sync Request Control is only applicable to the SearchRequest
Message.

  controlType='1.3.6.1.4.1.4203.1.9.1.1'

  def __init__(self, controlType='1.3.6.1.4.1.4203.1.9.1.1',
               criticality=False,
               controlValue=None, encodedControlValue=None):
    ldap.controls.LDAPControl.__init__(self, self.controlType, criticality,
                                       controlValue, encodedControlValue)

  def encodeControlValue(self, value):
    # 30 31          Sequence tag (len=0x31)
    #       0a 01 01 Enumerated (len=0x01) value 0x01 (RefreshOnly)
    #       04 2C    Octet String (len=0x2C) value 'csn=...,rid=000'
    #                63 73 6e 3d 32 30 30 39 30 33 31 36 31 39 35 35
    #                30 39 5a 23 30 30 30 30 30 30 23 30 30 23 30 30
    #                30 30 30 30 2c 72 69 64 3d 30 30 30
    # return value
    mode, cookie, reload_hint = value

    # Enumerated (len=0x01) value 0x01 (RefreshOnly)
    result_content = struct.pack('BBB', 0x0A, 0x01, mode)

    # Octet String (optional)
    if cookie:
      result_content += struct.pack('BB', 0x04, len(cookie))
      result_content += cookie

    # Boolean (optional)
    if reload_hint:
      result_content += struct.pack('BBB', 0x01, 0x01, 0xFF)

    # Sequence tag
    result_header = struct.pack('BB', 0x30, len(result_content))

    return result_header + result_content

ldap.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3)
ldap.set_option(ldap.OPT_REFERRALS, 0)
ldap.controls.knownLDAPControls[SyncRequestControl.controlType] =
SyncRequestControl
ldap.controls.knownLDAPControls[SyncStateControl.controlType]   =
SyncStateControl
ldap.controls.knownLDAPControls[SyncDoneControl.controlType]    =
SyncDoneControl



conn = ldap.initialize('ldap://localhost', trace_level=0)
cookie = ''

cv = (3, cookie, False)
sync_req_ctrl=SyncRequestControl(criticality=False, controlValue=cv)
server_ctrls = (sync_req_ctrl,)


base =
"cn=the_cn_value,ou=the_ou_value,customAttr=custom_att_value,ou=bla,dc=example,dc=com"
op_id  = conn.search_ext(base,
                         ldap.SCOPE_SUBTREE,
                         '(objectClass=*)', [ '*', '+' ],
                         serverctrls = server_ctrls )

msg_id=op_id
all=0
timeout=60
add_ctrls=1
add_intermediates=1
add_extop=0
res_type, res_data, res_msgid, srv_ctrls, resp_name, resp_value =
conn.result4(msg_id,all,timeout,
add_ctrls,
add_intermediates,
add_extop)
print "res_type <%s>: "%res_type

while res_type:
    print "res_type <%s>: "%res_type
    print "res_data <%s>: "%pprint.pformat(res_data)
    print "res_msgid <%s>: "%res_msgid
    print "srv_ctrls <%s>: "%srv_ctrls
    print "resp_name <%s>: "%resp_name
    print "resp_value <%s>: "%resp_value
    print ''
    timeout=-1
    res_type, res_data, res_msgid, srv_ctrls, resp_name, resp_value =
conn.result4(msg_id,all,timeout,
add_ctrls,
add_intermediates,
add_extop)


==== THE OUTPUT ====


### Here The full synchronization because we send no cookie ####

res_type <100>:
res_type <100>:
res_data
<[('cn=the_cn_value,ou=the_ou_value,customAttr=custom_att_value,ou=bla,dc=example,dc=com',
  {
   'createTimestamp': ['20110301165220Z'],
   'entryCSN': ['20110303171738.236445Z#000000#002#000000'],
   'entryDN':
['cn=the_cn_value,ou=the_ou_value,customAttr=custom_att_value,ou=bla,dc=example,dc=com'],
   'entryUUID': ['c9446cba-d14e-47ab-bf95-5f08d5f85ea1'],
   'gidNumber': ['22035'],
   'hasSubordinates': ['FALSE'],
   'memberUid': ['memberUid 1', 'Member Uid 2', 'Member Uid 3'],
   'modifyTimestamp': ['20110303171738Z'],
   'subschemaSubentry': ['cn=Subschema']},
  [('1.3.6.1.4.1.4203.1.9.1.2',
    0,

'0\x15\n\x01\x01\x04\x10\xc9Dl\xba\xd1NG\xab\xbf\x95_\x08\xd5\xf8^\xa1')])]>:

res_msgid <1>:
srv_ctrls <[]>:
resp_name <None>:
resp_value <None>:


#### LAST Entry is an Intermediate result: Note that server controls are
empty !  ####

res_type <121>:
res_data <[(121,
  '1.3.6.1.4.1.4203.1.9.1.4',
  '\xa2>\x04<rid=000,sid=002,csn=20110303171738.236445Z#000000#002#000000',
  [])]>:
res_msgid <1>:
srv_ctrls <[]>:
resp_name <None>:
resp_value <None>:


#### AFTER A MemberUID deletion. Again Note that server ctrls are empty !
#####


res_type <100>:
res_data
<[('cn=the_cn_value,ou=the_ou_value,customAttr=custom_att_value,ou=bla,dc=example,dc=com',
  {
   'createTimestamp': ['20110301165220Z'],
   'entryCSN': ['20110303171931.545263Z#000000#002#000000'],
   'entryDN':
['cn=the_cn_value,ou=the_ou_value,customAttr=custom_att_value,ou=bla,dc=example,dc=com'],
   'entryUUID': ['c9446cba-d14e-47ab-bf95-5f08d5f85ea1'],
   'gidNumber': ['22035'],
   'hasSubordinates': ['FALSE'],
   'memberUid': ['memberUid 1', 'Member Uid 2'],  ### DELETION of Member
Uid 3
   'modifyTimestamp': ['20110303171931Z'],
   'subschemaSubentry': ['cn=Subschema']},
  [('1.3.6.1.4.1.4203.1.9.1.2',
    0,

'0S\n\x01\x02\x04\x10\xc9Dl\xba\xd1NG\xab\xbf\x95_\x08\xd5\xf8^\xa1\x04<rid=000,sid=002,csn=20110303171931.545263Z#000000#002#000000')])]>:

res_msgid <1>:
srv_ctrls <[]>:
resp_name <None>:
resp_value <None>:




#
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractère privé. S'ils ne vous sont
pas destinés, nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
informer l'expéditeur et de supprimer immédiatement de votre système
informatique ce courriel ainsi que tous les documents qui y sont attachés."


                               ******

" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."
#

Re: please review encode_assertion_control()

[Rich M. <ric...@gm...>]

On 03/03/2011 01:28 PM, Michael Ströder wrote:
> HI!
>
> (Sigh!) I'm not a C programmer.
>
> Could somebody please look what's wrong with encode_assertion_control() in
> Modules/ldapcontrol.c? It seg faults.
     err = 
ldap_create_assertion_control_value(NULL,assertion_filterstr,&ctrl_val);
The NULL should be an LDAP* and it must be valid.

It needs the LDAP* handle because it calls ldap_alloc_ber_with_options() 
to allocate the BER for the control value.
> $ python -c "import ldap;print
> repr(ldap.encode_assertion_control('(objectClass=*)'))"
> Segmentation fault (core dumped)
>
> You have to set
>
> extra_compile_args = -g -DLIBLDAP_HAS_ASSERTION_CONTROL_FUNC
>
> in setup.cfg and have a fairly recent OpenLDAP 2.4 installation to get it
> compiled.
>
> Ciao, Michael.
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

please review encode_assertion_control()

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

HI!

(Sigh!) I'm not a C programmer.

Could somebody please look what's wrong with encode_assertion_control() in
Modules/ldapcontrol.c? It seg faults.

$ python -c "import ldap;print
repr(ldap.encode_assertion_control('(objectClass=*)'))"
Segmentation fault (core dumped)

You have to set

extra_compile_args = -g -DLIBLDAP_HAS_ASSERTION_CONTROL_FUNC

in setup.cfg and have a fairly recent OpenLDAP 2.4 installation to get it
compiled.

Ciao, Michael.

Re: LDAP for Python 3.x

[Dusan S. <ste...@ds...>]

Hi Michael,

I will try do it.

Dusan


On 01/03/11 at 09:15pm, Michael Ströder wrote:
> Dusan Stefanik wrote:
> > I decided to take python-ldap-2.3.13 few days ago and I made som changes to get it work on python3.
> > Now I have working version for python3 (tested on Ubuntu 10.4 LTS x64 and Debian Squeeze x64).
> > 
> > You can try it. It can be start point for new branche of python-ldap-py3.
> > 
> > I made only few tests (bind,search,del,add) - successfully.
> 
> Thanks for working on that. But given the fact that CVS HEAD now contains lots
> of changes in Modules/ compared to 2.3.13 I'd really prefer to receive patches
> against CVS HEAD. Would you mind doing so?
> 
> Ciao, Michael.
> 

Re: 2.4.0 patches need review

[Rich M. <ric...@gm...>]

On 03/01/2011 01:13 PM, Michael Ströder wrote:
> Rich Megginson wrote:
>> About the arguments and return values to result4 - with the current code
>> I have to do something like this:
>>
>>      rtype, rdata, rmsgid, decoded_serverctrls, extop_rspoid,
>> extop_rspval = srv.result4(msgid, 0, -1, 1)
>>
>> That is, I only want the decoded_serverctrls, but I have to add items
>> for extop_rspoid and extop_rspval even though I don't want them, because
>> result4 always returns a 6-tuple, regardless of what the caller wants.
>> Maybe this is the convention, to have to provide all of the optional
>> return values, to make it consistent that result4 always returns a
>> 6-tuple?  Because it would be pretty easy for result4 to look at its
>> arguments and do something like:
>> if add_extop:
>>    return a 6-tuple
>> else:
>>    return a 4-tuple
> Look at the convenience wrapper method LDAPObject.extop_result() I've added
> recently. A similar method could be easily added for the case where the caller
> knows that one does not expect a ext op result. I consider this to be a more
> readable approach than looking at an argument.
Ok.  Sounds good.
> More ideas: I'd like to let the result-methods decode the response controls
> and ext op responses received. I'm thinking of adding a new optional keyword
> argument where one can pass in a dict([oid:class]) which can be used to
> automagically let the result method return instances of LDAPControl or
> ExtendedResponse.
>
> I'm also thinking about splitting LDAPControl into RequestControl and
> ResponseControl.
Both good ideas.
> More comments welcome.
>
> Ciao, Michael.

Re: LDAP for Python 3.x

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

Dusan Stefanik wrote:
> I decided to take python-ldap-2.3.13 few days ago and I made som changes to get it work on python3.
> Now I have working version for python3 (tested on Ubuntu 10.4 LTS x64 and Debian Squeeze x64).
> 
> You can try it. It can be start point for new branche of python-ldap-py3.
> 
> I made only few tests (bind,search,del,add) - successfully.

Thanks for working on that. But given the fact that CVS HEAD now contains lots
of changes in Modules/ compared to 2.3.13 I'd really prefer to receive patches
against CVS HEAD. Would you mind doing so?

Ciao, Michael.

Re: 2.4.0 patches need review

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

Rich Megginson wrote:
> About the arguments and return values to result4 - with the current code
> I have to do something like this:
> 
>     rtype, rdata, rmsgid, decoded_serverctrls, extop_rspoid,
> extop_rspval = srv.result4(msgid, 0, -1, 1)
> 
> That is, I only want the decoded_serverctrls, but I have to add items
> for extop_rspoid and extop_rspval even though I don't want them, because
> result4 always returns a 6-tuple, regardless of what the caller wants. 
> Maybe this is the convention, to have to provide all of the optional
> return values, to make it consistent that result4 always returns a
> 6-tuple?  Because it would be pretty easy for result4 to look at its
> arguments and do something like:
> if add_extop:
>   return a 6-tuple
> else:
>   return a 4-tuple

Look at the convenience wrapper method LDAPObject.extop_result() I've added
recently. A similar method could be easily added for the case where the caller
knows that one does not expect a ext op result. I consider this to be a more
readable approach than looking at an argument.

More ideas: I'd like to let the result-methods decode the response controls
and ext op responses received. I'm thinking of adding a new optional keyword
argument where one can pass in a dict([oid:class]) which can be used to
automagically let the result method return instances of LDAPControl or
ExtendedResponse.

I'm also thinking about splitting LDAPControl into RequestControl and
ResponseControl.

More comments welcome.

Ciao, Michael.

Re: 2.4.0 patches need review

[Rich M. <ric...@gm...>]

On 02/21/2011 02:29 PM, Michael Ströder wrote:
> HI!
>
> I've committed a larger patch contributed by Rich Megginson fixing SF#2829057
> [1] and adding generic support LDAPv3 extended operations. Many thanks to him.
>
> I've done some tests for [1] by successfully using the LDAP persistent search
> control against eDirectory and OpenDJ (OpenDS fork) and receive/decode the
> response control. Also a case which does not seem to work with recent
> python-ldap 2.3.13.
>
> But I think this large patch needs much more review and some decision
> regarding the arguments passed to and results returned by method
> LDAPObject.result4().
I've tested with 389 - extops work fine - dereference control (per entry 
return control) works fine.

About the arguments and return values to result4 - with the current code 
I have to do something like this:

     rtype, rdata, rmsgid, decoded_serverctrls, extop_rspoid, 
extop_rspval = srv.result4(msgid, 0, -1, 1)

That is, I only want the decoded_serverctrls, but I have to add items 
for extop_rspoid and extop_rspval even though I don't want them, because 
result4 always returns a 6-tuple, regardless of what the caller wants.  
Maybe this is the convention, to have to provide all of the optional 
return values, to make it consistent that result4 always returns a 
6-tuple?  Because it would be pretty easy for result4 to look at its 
arguments and do something like:
if add_extop:
   return a 6-tuple
else:
   return a 4-tuple

> So I'd like to encourage all the list readers to checkout CVS HEAD and play
> with it.
>
> Ciao, Michael.
>
> [1]
> http://sourceforge.net/tracker/?func=detail&aid=2829057&group_id=2072&atid=352072
>
> ------------------------------------------------------------------------------
> Index, Search&  Analyze Logs and other IT data in Real-Time with Splunk
> Collect, index and harness all the fast moving IT data generated by your
> applications, servers and devices whether physical, virtual or in the cloud.
> Deliver compliance at lower cost and gain new business insights.
> Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Re: LDAP for Python 3.x

[Dusan S. <ste...@ds...>]

Hi,


I decided to take python-ldap-2.3.13 few days ago and I made som changes to get it work on python3.
Now I have working version for python3 (tested on Ubuntu 10.4 LTS x64 and Debian Squeeze x64).

You can try it. It can be start point for new branche of python-ldap-py3.

I made only few tests (bind,search,del,add) - successfully.

Regards,

Dusan

LDAP for Python 3.x

[Yeargan, Y. <ya...@un...>]

Michael, have you made a decision about whether to start an entirely new code base for Python 3.x?

I have a small need for a threaded application using LDAP. Now that Python 3.2 has addressed some issues with threading and the GIL, I'd like to pursue this. Of course, I'll need an LDAP module to continue. I may be able to help a little with the porting, but it seems the biggest decision is whether to start a new project or not.

Yancey

2.4.0 patches need review

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

HI!

I've committed a larger patch contributed by Rich Megginson fixing SF#2829057
[1] and adding generic support LDAPv3 extended operations. Many thanks to him.

I've done some tests for [1] by successfully using the LDAP persistent search
control against eDirectory and OpenDJ (OpenDS fork) and receive/decode the
response control. Also a case which does not seem to work with recent
python-ldap 2.3.13.

But I think this large patch needs much more review and some decision
regarding the arguments passed to and results returned by method
LDAPObject.result4().

So I'd like to encourage all the list readers to checkout CVS HEAD and play
with it.

Ciao, Michael.

[1]
http://sourceforge.net/tracker/?func=detail&aid=2829057&group_id=2072&atid=352072

ANN: python-ldap-2.3.13

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

Find a new release of python-ldap:

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

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

Note: This is the last release with this feature set. From now on only very
urgent fixes are going into release series 2.3.x.

Project's web site:

  http://www.python-ldap.org/

Ciao, Michael.

----------------------------------------------------------------
Released 2.3.13 2011-02-19

Changes since 2.3.12:

Modules/
* Correct #ifdef-statement for LDAP_OPT_X_TLS_CRLFILE in
  constants.c fixes build with older OpenLDAP libs
* Support for LDAP_OPT_DEFBASE (see SF#3072016, thanks to Johannes)

Re: python-ldap hanging for 15 minutes under certain conditions

[Michael W. <esi...@gm...>]

Hi

On 7 February 2011 19:29, Rich Megginson <ric...@gm...> wrote:
> On 02/05/2011 01:42 PM, Michael Wood wrote:
>>
>> Hi
>>
>> On 4 February 2011 17:35, Rich Megginson<ric...@gm...>  wrote:
>>>
>>> On 02/03/2011 11:59 PM, Michael Wood wrote:
>>>>
>>>> On 4 February 2011 08:32, James Andrewartha<ja...@da...>    wrote:
>>
>> [...]
>>>>>
>>>>> Debian uses GnuTLS because OpenSSL has the non-GPL compatible
>>>>> advertising clause, and libldap is linked into many GPL applications.
>>>>> So
>>>>
>>>> Ah, good point.
>>>>
>>>>> the solutions are fix the OpenSSL licensing or make GnuTLS not suck; I
>>>>
>>>> Or switch to something else.
>>>
>>> OpenLDAP 2.4.23 supports Mozilla NSS (triple licensed GPLv2+/LGPLv2+/MPL)
>>> for crypto
>>> Fedora 14 and later use this instead of OpenSSL
>>
>> Interesting.  But co-incidentally, there's a thread currently on the
>> libcurl mailing list about comparisons between different SSL/TLS libs
>> that are supported by libcurl.  Howard Chu posted about GnuTLS and
>> later about NSS.  In the NSS message he said:
>>
>> "I understand that RedHat is now building their OpenLDAP packages with our
>> MozNSS support. I don't believe this combination is ready for primetime by
>> any
>> measure. They still don't even have release quality code for handling PEM
>> files, and their current experimental code crashes/misbehaves in common
>> (for
>> OpenSSL) deployment scenarios.
>
> No doubt Howard has been alarmed by the frequency of my patch submissions
> and the severity of the bugs they fix.

Ah, sorry for opening up a can of worms :)

>> https://bugzilla.mozilla.org/show_bug.cgi?id=402712
>
> This is for adding the PEMNSS module to Mozilla NSS upstream.  The code has
> been used for years now, first in nss_compat_ossl (a library wrapper that
> implements OpenSSL APIs with Mozilla NSS code) and in libnsspem in
> RHEL/Fedora (part of the RHEL/Fedora nss package).

I am not wedded to PEM.  Perhaps NSS is the answer.  Now someone just
needs to convince Debian and/or Ubuntu of that :)  I have no idea if
anyone's tried.

>> https://bugzilla.redhat.com/show_bug.cgi?id=642433"
>
> This has already been fixed both in OpenLDAP upstream and in current
> RHEL/Fedora code.
>
> IMHO OpenLDAP with MozNSS is close to being stable.  I'm not just saying
> that - I'm prepared to "put my money where my mouth is" and so is my
> employer, Red Hat, who has committed to using OpenLDAP with MozNSS in Fedora
> and RHEL.  Also note that two of the core Mozilla NSS developers, including
> those working on Mozilla PEMNSS, are also Red Hat employees.

OK

> You can also use OpenLDAP with MozNSS without using PEM files at all if you
> are concerned about using the libnsspem module -
> http://www.openldap.org/faq/index.cgi?file=1514

Well, as I said above, I'm not wedded to PEM.  I am using Ubuntu for
reasons not related to OpenLDAP and so would prefer to use official
Ubuntu packages rather than compiling OpenLDAP myself and then having
to keep it up to date.  So for me, I think it would be best if Ubuntu
switched to an SSL library for OpenLDAP that did not cause me problems
like I had when using python-ldap -> OpenLDAP -> GnuTLS.  Of course,
the chances of Ubuntu switching just because I think it would be best
are minimal :)  Especially because I am not intimately familiar with
all the issues.

> Why is Fedora/Red Hat doing this at all?  Why bother?
>  https://fedoraproject.org/wiki/FedoraCryptoConsolidation

Thanks for that link.  I agree it's a worthy goal and it sounds like
NSS is the way to go.  I hope Debian and Ubuntu follow suit.

-- 
Michael Wood <esi...@gm...>

Re: python-ldap hanging for 15 minutes under certain conditions

[Rich M. <ric...@gm...>]

On 02/05/2011 01:42 PM, Michael Wood wrote:
> Hi
>
> On 4 February 2011 17:35, Rich Megginson<ric...@gm...>  wrote:
>> On 02/03/2011 11:59 PM, Michael Wood wrote:
>>> On 4 February 2011 08:32, James Andrewartha<ja...@da...>    wrote:
> [...]
>>>> Debian uses GnuTLS because OpenSSL has the non-GPL compatible
>>>> advertising clause, and libldap is linked into many GPL applications. So
>>> Ah, good point.
>>>
>>>> the solutions are fix the OpenSSL licensing or make GnuTLS not suck; I
>>> Or switch to something else.
>> OpenLDAP 2.4.23 supports Mozilla NSS (triple licensed GPLv2+/LGPLv2+/MPL)
>> for crypto
>> Fedora 14 and later use this instead of OpenSSL
> Interesting.  But co-incidentally, there's a thread currently on the
> libcurl mailing list about comparisons between different SSL/TLS libs
> that are supported by libcurl.  Howard Chu posted about GnuTLS and
> later about NSS.  In the NSS message he said:
>
> "I understand that RedHat is now building their OpenLDAP packages with our
> MozNSS support. I don't believe this combination is ready for primetime by any
> measure. They still don't even have release quality code for handling PEM
> files, and their current experimental code crashes/misbehaves in common (for
> OpenSSL) deployment scenarios.
No doubt Howard has been alarmed by the frequency of my patch 
submissions and the severity of the bugs they fix.
> https://bugzilla.mozilla.org/show_bug.cgi?id=402712
This is for adding the PEMNSS module to Mozilla NSS upstream.  The code 
has been used for years now, first in nss_compat_ossl (a library wrapper 
that implements OpenSSL APIs with Mozilla NSS code) and in libnsspem in 
RHEL/Fedora (part of the RHEL/Fedora nss package).
> https://bugzilla.redhat.com/show_bug.cgi?id=642433"
This has already been fixed both in OpenLDAP upstream and in current 
RHEL/Fedora code.

IMHO OpenLDAP with MozNSS is close to being stable.  I'm not just saying 
that - I'm prepared to "put my money where my mouth is" and so is my 
employer, Red Hat, who has committed to using OpenLDAP with MozNSS in 
Fedora and RHEL.  Also note that two of the core Mozilla NSS developers, 
including those working on Mozilla PEMNSS, are also Red Hat employees.

You can also use OpenLDAP with MozNSS without using PEM files at all if 
you are concerned about using the libnsspem module - 
http://www.openldap.org/faq/index.cgi?file=1514

Why is Fedora/Red Hat doing this at all?  Why bother?  
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
> Here's the link to the message in libcurl's mailing list archive:
> http://curl.haxx.se/mail/lib-2011-02/0043.html
>