From davidgab283 at gmail.com  Thu Jan  7 09:15:06 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Thu, 7 Jan 2016 15:15:06 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
Message-ID: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>

Dears,

I am using this python application
<https://github.com/rbarrois/python-ldap/blob/master/Demo/pyasn1/syncrepl.py>
and
I want run it parallely with other application.
The problem is that I am blocked in this procedure 'syncrepl_poll'.
In other words, when this procedure is called no other operation/procedure
is made !!
Could you please tell me how to use the aformentionned application without
having a blocking issue in 'syncrepl_poll' procedure.

Thanks in advance.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160107/c516986b/attachment.html>

From michael at stroeder.com  Thu Jan  7 09:47:50 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 7 Jan 2016 15:47:50 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
Message-ID: <568E7A96.4080002@stroeder.com>

David Gabriel wrote:
> I am using this python application
> <https://github.com/rbarrois/python-ldap/blob/master/Demo/pyasn1/syncrepl.py>

Note that this is a rather basic demo.

> and
> I want run it parallely with other application.

It's not entirely clear what you exactly mean.

> The problem is that I am blocked in this procedure 'syncrepl_poll'.
> In other words, when this procedure is called no other operation/procedure
> is made !!
> Could you please tell me how to use the aformentionned application without
> having a blocking issue in 'syncrepl_poll' procedure.

Simply use different LDAP connections.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160107/0477e2e3/attachment.bin>

From davidgab283 at gmail.com  Thu Jan  7 10:06:55 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Thu, 7 Jan 2016 16:06:55 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <568E7A96.4080002@stroeder.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
Message-ID: <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>

Thanks Michael for your answer.
I tried to create one thread that executes the syncrepl application and
parallely I have other program (that does not deal with ldap) that I want
to run.
I think the 'syncrepl_poll' procedure is not asynchronous in such way that
allows other application to run at the same time.
Is it possible to replace 'syncrepl_poll' or update it to enable parallel
threading.

Thanks in advance.
Kind regards

2016-01-07 15:47 GMT+01:00 Michael Str?der <michael at stroeder.com>:

> David Gabriel wrote:
> > I am using this python application
> > <
> https://github.com/rbarrois/python-ldap/blob/master/Demo/pyasn1/syncrepl.py
> >
>
> Note that this is a rather basic demo.
>
> > and
> > I want run it parallely with other application.
>
> It's not entirely clear what you exactly mean.
>
> > The problem is that I am blocked in this procedure 'syncrepl_poll'.
> > In other words, when this procedure is called no other
> operation/procedure
> > is made !!
> > Could you please tell me how to use the aformentionned application
> without
> > having a blocking issue in 'syncrepl_poll' procedure.
>
> Simply use different LDAP connections.
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160107/43b36f29/attachment.html>

From davidgab283 at gmail.com  Fri Jan  8 05:40:37 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Fri, 8 Jan 2016 02:40:37 -0800
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
Message-ID: <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>

Dears

Is there any way to enable the running of the syncrepl_poll procedure *in
parallel* with other applications (non python-ldap applications) ?
In fact I tried several manner to execute this procedure using threads and
eventlets but always my program is blocking at syncrepl_poll procedure and
it does not execute any other procedure.
In other words I want that my program be updated from any change in my ldap
db and parallely it should handle other events coming from non ldap events.
Is there any other way to do this without using syncrepl_poll procedure ?

Please any help is welcome.
I am really blocked at this point !!

Thanks in advance.
Best regards

2016-01-07 7:06 GMT-08:00 David Gabriel <davidgab283 at gmail.com>:

> Thanks Michael for your answer.
> I tried to create one thread that executes the syncrepl application and
> parallely I have other program (that does not deal with ldap) that I want
> to run.
> I think the 'syncrepl_poll' procedure is not asynchronous in such way
> that allows other application to run at the same time.
> Is it possible to replace 'syncrepl_poll' or update it to enable parallel
> threading.
>
> Thanks in advance.
> Kind regards
>
> 2016-01-07 15:47 GMT+01:00 Michael Str?der <michael at stroeder.com>:
>
>> David Gabriel wrote:
>> > I am using this python application
>> > <
>> https://github.com/rbarrois/python-ldap/blob/master/Demo/pyasn1/syncrepl.py
>> >
>>
>> Note that this is a rather basic demo.
>>
>> > and
>> > I want run it parallely with other application.
>>
>> It's not entirely clear what you exactly mean.
>>
>> > The problem is that I am blocked in this procedure 'syncrepl_poll'.
>> > In other words, when this procedure is called no other
>> operation/procedure
>> > is made !!
>> > Could you please tell me how to use the aformentionned application
>> without
>> > having a blocking issue in 'syncrepl_poll' procedure.
>>
>> Simply use different LDAP connections.
>>
>> Ciao, Michael.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160108/2868b583/attachment.html>

From davidgab283 at gmail.com  Fri Jan  8 08:59:59 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Fri, 8 Jan 2016 05:59:59 -0800
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
Message-ID: <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>

Hi all

After some investigation in the source code I think the function 'result4'
located in the file ldapobject.py is the responsible of this blocking
behaviour.
And to be more precise this is the blocking call: ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
Is there any way to ensure the update from ldap data base without causing
the blocking of other processes ?
Is there an asynchronous version of the syncrepl client ?
I notice the presence of this function: def
result(self,msgid=ldap.RES_ANY,all=1,timeout=None): that uses result2
function.

Please advise me how to fix my issue ?
Thank you very much.
Kind regards

2016-01-08 2:40 GMT-08:00 David Gabriel <davidgab283 at gmail.com>:

> Dears
>
> Is there any way to enable the running of the syncrepl_poll procedure *in
> parallel* with other applications (non python-ldap applications) ?
> In fact I tried several manner to execute this procedure using threads and
> eventlets but always my program is blocking at syncrepl_poll procedure and
> it does not execute any other procedure.
> In other words I want that my program be updated from any change in my
> ldap db and parallely it should handle other events coming from non ldap
> events.
> Is there any other way to do this without using syncrepl_poll procedure ?
>
> Please any help is welcome.
> I am really blocked at this point !!
>
> Thanks in advance.
> Best regards
>
> 2016-01-07 7:06 GMT-08:00 David Gabriel <davidgab283 at gmail.com>:
>
>> Thanks Michael for your answer.
>> I tried to create one thread that executes the syncrepl application and
>> parallely I have other program (that does not deal with ldap) that I want
>> to run.
>> I think the 'syncrepl_poll' procedure is not asynchronous in such way
>> that allows other application to run at the same time.
>> Is it possible to replace 'syncrepl_poll' or update it to enable
>> parallel threading.
>>
>> Thanks in advance.
>> Kind regards
>>
>> 2016-01-07 15:47 GMT+01:00 Michael Str?der <michael at stroeder.com>:
>>
>>> David Gabriel wrote:
>>> > I am using this python application
>>> > <
>>> https://github.com/rbarrois/python-ldap/blob/master/Demo/pyasn1/syncrepl.py
>>> >
>>>
>>> Note that this is a rather basic demo.
>>>
>>> > and
>>> > I want run it parallely with other application.
>>>
>>> It's not entirely clear what you exactly mean.
>>>
>>> > The problem is that I am blocked in this procedure 'syncrepl_poll'.
>>> > In other words, when this procedure is called no other
>>> operation/procedure
>>> > is made !!
>>> > Could you please tell me how to use the aformentionned application
>>> without
>>> > having a blocking issue in 'syncrepl_poll' procedure.
>>>
>>> Simply use different LDAP connections.
>>>
>>> Ciao, Michael.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160108/7ee14f27/attachment.html>

From michael at stroeder.com  Fri Jan  8 10:56:30 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 8 Jan 2016 16:56:30 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
Message-ID: <568FDC2E.3050503@stroeder.com>

David Gabriel wrote:
> After some investigation in the source code I think the function 'result4'
> located in the file ldapobject.py is the responsible of this blocking
> behaviour.

1. Please note that I personally do not feel responsible for the code *fork* on
github.

2. You did not tell us any other relevant details like
- OS
- Python version
- python-ldap version (from where?)
- whether python-ldap is linked against libldap_r etc.

While method LDAPObject.result4() is called in a blocking manner it's IMHO
likely not the cause for your code not being executed in parallel.

Frankly I don't see any reason why it's not possible to run the blocking
syncrepl client code in one thread and having other code running in separate
threads.

It might help if you would post a *small* code example with threads illustrating
what you're trying to achieve and which shows your blocking issue.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160108/951a6651/attachment-0001.bin>

From davidgab283 at gmail.com  Fri Jan  8 11:47:39 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Fri, 8 Jan 2016 08:47:39 -0800
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <568FDC2E.3050503@stroeder.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
Message-ID: <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>

I am under ubuntu, python2.7, I have installed python-ldap few mounths ago
..
Here is my code:

#!/usr/bin/python

# Import the python-ldap modules
import ldap,ldapurl
# Import specific classes from python-ldap
from ldap.ldapobject import ReconnectLDAPObject
from ldap.syncrepl import SyncreplConsumer

# Import modules from Python standard lib
import shelve,signal,time,sys,logging
import eventlet
import thread

# Global state
watcher_running = True
ldap_connection = False



class SyncReplConsumer(ReconnectLDAPObject,SyncreplConsumer):
    """
    Syncrepl Consumer interface
    """
    def __init__(self,db_path,*args,**kwargs):
        # Initialise the LDAP Connection first
        ldap.ldapobject.ReconnectLDAPObject.__init__(self, *args, **kwargs)
        # Now prepare the data store
        self.__data = shelve.open(db_path, 'c')
        # We need this for later internal use
        self.__presentUUIDs = dict()

    def __del__(self):
            # Close the data store properly to avoid corruption
            self.__data.close()

    def syncrepl_get_cookie(self):
        if 'cookie' in self.__data:
            return self.__data['cookie']

    def syncrepl_set_cookie(self,cookie):
        self.__data['cookie'] = cookie

    def syncrepl_entry(self,dn,attributes,uuid):
        global result
        # First we determine the type of change we have here (and store
away the previous data for later if needed)
        previous_attributes = dict()
        if uuid in self.__data:
            change_type = 'modify'
            previous_attributes = self.__data[uuid]
        else:
            change_type = 'add'
        # Now we store our knowledge of the existence of this entry
(including the DN as an attribute for convenience)
        attributes['dn'] = dn
        self.__data[uuid] = attributes
        # Debugging
        print 'Detected', change_type, 'of entry:', dn
        # If we have a cookie then this is not our first time being run, so
it must be a change
        if 'ldap_cookie' in self.__data:
                self.perform_application_sync(dn, attributes,
previous_attributes)

    def syncrepl_delete(self,uuids):
        global result
        # Make sure we know about the UUID being deleted, just in case...
        uuids = [uuid for uuid in uuids if uuid in self.__data]
        # Delete all the UUID values we know of
        for uuid in uuids:
            print 'Detected deletion of entry:', self.__data[uuid]['dn']
            del self.__data[uuid]

    def syncrepl_present(self,uuids,refreshDeletes=False):
        # If we have not been given any UUID values, then we have recieved
all the present controls...
        if uuids is None:
            # We only do things if refreshDeletes is false as the syncrepl
extension will call syncrepl_delete instead when it detects a delete notice
            if refreshDeletes is False:
                deletedEntries = [uuid for uuid in self.__data.keys() if
uuid not in self.__presentUUIDs and uuid != 'ldap_cookie']
                self.syncrepl_delete( deletedEntries )
            # Phase is now completed, reset the list
            self.__presentUUIDs = {}
        else:
            # Note down all the UUIDs we have been sent
            for uuid in uuids:
                    self.__presentUUIDs[uuid] = True

    def perform_application_sync(self,dn,attributes,previous_attributes):
        print 'Performing application sync for:', dn
        return True


# Shutdown handler
#def commenceShutdown(signum, stack):
def commenceShutdown():
    # Declare the needed global variables
    global watcher_running, ldap_connection
    print 'Shutting down!'

    # We are no longer running
    watcher_running = False

    # Tear down the server connection
    if( ldap_connection ):
            del ldap_connection

    # Shutdown
    sys.exit(0)

def mainOfSyncrepl(threadName):
    # Time to actually begin execution
    # Install our signal handlers
#    signal.signal(signal.SIGTERM,commenceShutdown)
#    signal.signal(signal.SIGINT,commenceShutdown)
    try:
      ldap_url =
ldapurl.LDAPUrl('ldap://Address/dc=test,dc=com?*?sub?(objectClass=*)?bindname=cn=admin%2cdc=test%2cdc=com,X-BINDPW=password')#ldapurl.LDAPUrl(sys.argv[1])
    #  ldap_url = ldapurl.LDAPUrl(link)
      database_path = 'example.com'#sys.argv[2]
    #  database_path = pathName
    except IndexError,e:
      print 'Usage: syncrepl-client.py <LDAP URL> <pathname of database>'
      sys.exit(1)
    except ValueError,e:
      print 'Error parsing command-line arguments:',str(e)
      sys.exit(1)

    while watcher_running:
        print 'Connecting to LDAP server now...'
        # Prepare the LDAP server connection (triggers the connection as
well)
        ldap_connection =
SyncReplConsumer(database_path,ldap_url.initializeUrl())

        # Now we login to the LDAP server
        try:
        ldap_connection.simple_bind_s(ldap_url.who,ldap_url.cred)
        except ldap.INVALID_CREDENTIALS, e:
        print 'Login to LDAP server failed: ', str(e)
        sys.exit(1)
        except ldap.SERVER_DOWN:
        continue

        # Commence the syncing
        print 'Commencing sync process'
        ldap_search = ldap_connection.syncrepl_search(
          ldap_url.dn or '',
          ldap_url.scope or ldap.SCOPE_SUBTREE,
          mode = 'refreshAndPersist',
          filterstr = ldap_url.filterstr or '(objectClass=*)'
        )
        print 'After syncrepl_search.'
        try:
        while ldap_connection.syncrepl_poll( all = 1, msgid = ldap_search):
            pass
        except KeyboardInterrupt:
        # User asked to exit
        commenceShutdown()
        pass
        except Exception, e:
        # Handle any exception
        if watcher_running:
            print 'Encountered a problem, going to retry. Error:', str(e)
            time.sleep(5)
        pass

# Define a function for the 2nd thread
def print_time(ThreadName):
        count = 0
    delay = 3
        while 1:#count < 5:
            count += 1
            print "%s: %s" % (ThreadName, time.ctime(time.time()) )
            time.sleep(delay)



print 'Before call threads'

syncreplEvt1 = eventlet.spawn(mainOfSyncrepl, "Thread-1",)
syncreplEvt2 = eventlet.spawn(print_time, "Thread-2",)
#syncreplEvt3 = eventlet.spawn(print_time, "Thread-3",)

print 'After call threads'

syncreplEvt1.wait()
syncreplEvt2.wait()
#syncreplEvt3.wait()

2016-01-08 7:56 GMT-08:00 Michael Str?der <michael at stroeder.com>:

> David Gabriel wrote:
> > After some investigation in the source code I think the function
> 'result4'
> > located in the file ldapobject.py is the responsible of this blocking
> > behaviour.
>
> 1. Please note that I personally do not feel responsible for the code
> *fork* on
> github.
>
> 2. You did not tell us any other relevant details like
> - OS
> - Python version
> - python-ldap version (from where?)
> - whether python-ldap is linked against libldap_r etc.
>
> While method LDAPObject.result4() is called in a blocking manner it's IMHO
> likely not the cause for your code not being executed in parallel.
>
> Frankly I don't see any reason why it's not possible to run the blocking
> syncrepl client code in one thread and having other code running in
> separate
> threads.
>
> It might help if you would post a *small* code example with threads
> illustrating
> what you're trying to achieve and which shows your blocking issue.
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160108/e235d5f7/attachment.html>

From michael at stroeder.com  Fri Jan  8 12:09:03 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 8 Jan 2016 18:09:03 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
Message-ID: <568FED2F.6040608@stroeder.com>

David Gabriel wrote:
> Here is my code:

Please send code longer than 10 lines as attachement. Otherwise I have to edit
all the line-wrapping.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160108/160be360/attachment.bin>

From davidgab283 at gmail.com  Sun Jan 10 04:19:57 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Sun, 10 Jan 2016 10:19:57 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <568FED2F.6040608@stroeder.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
 <568FED2F.6040608@stroeder.com>
Message-ID: <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>

Thanks Michael.
Kindly find attached my source code.

Best regards

2016-01-08 18:09 GMT+01:00 Michael Str?der <michael at stroeder.com>:

> David Gabriel wrote:
> > Here is my code:
>
> Please send code longer than 10 lines as attachement. Otherwise I have to
> edit
> all the line-wrapping.
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160110/476fbbf7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: syncrepl3.py
Type: text/x-python
Size: 6422 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160110/476fbbf7/attachment.py>

From michael at stroeder.com  Mon Jan 11 08:49:43 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 11 Jan 2016 14:49:43 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
 <568FED2F.6040608@stroeder.com>
 <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>
Message-ID: <5693B2F7.30206@stroeder.com>

David Gabriel wrote:
> Thanks Michael.
> Kindly find attached my source code.

This results in:

python -tt tmp/syncrepl3.py 'ldapi://dc=stroeder,dc=de'
  File "tmp/syncrepl3.py", line 58
    previous_attributes = dict()
                               ^
TabError: inconsistent use of tabs and spaces in indentation

Don't use tabs (see PEP-8).

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160111/fa1c3652/attachment.bin>

From michael at stroeder.com  Mon Jan 11 08:51:42 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 11 Jan 2016 14:51:42 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <5693B2F7.30206@stroeder.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
 <568FED2F.6040608@stroeder.com>
 <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>
 <5693B2F7.30206@stroeder.com>
Message-ID: <5693B36E.8060203@stroeder.com>

Michael Str?der wrote:
> David Gabriel wrote:
>> Thanks Michael.
>> Kindly find attached my source code.
> 
> This results in:
> 
> python -tt tmp/syncrepl3.py 'ldapi://dc=stroeder,dc=de'
>   File "tmp/syncrepl3.py", line 58
>     previous_attributes = dict()
>                                ^
> TabError: inconsistent use of tabs and spaces in indentation
> 
> Don't use tabs (see PEP-8).

And opening LDAP connection in the while-loop (line 138) looks also bogus.

Ciao, Michael.


From davidgab283 at gmail.com  Tue Jan 12 04:27:23 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Tue, 12 Jan 2016 01:27:23 -0800
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <5693B36E.8060203@stroeder.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
 <568FED2F.6040608@stroeder.com>
 <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>
 <5693B2F7.30206@stroeder.com> <5693B36E.8060203@stroeder.com>
Message-ID: <CAMyzk1f0t=vnJoVJkgQ7S1tuvMd4WKqYNgs6xft1DjLxbRy1TQ@mail.gmail.com>

Dear Michael and all

Thank you very much for your help ...
Kindy find attached my source file.
I replaced all tabs and I fixed the bugs related to this modification.
Please note the presence of 3 threads including the syncrepl one.
When I disable the creation of the syncrepl thread (comment the evt1 lines)
the program is alternating the execution of evt3 and evt2. However when I
enable it the program is executing only the syncrepl thread and not the 3
threads.

Please help me to fix this issue.
Thanks in advance.
Regards

2016-01-11 5:51 GMT-08:00 Michael Str?der <michael at stroeder.com>:

> Michael Str?der wrote:
> > David Gabriel wrote:
> >> Thanks Michael.
> >> Kindly find attached my source code.
> >
> > This results in:
> >
> > python -tt tmp/syncrepl3.py 'ldapi://dc=stroeder,dc=de'
> >   File "tmp/syncrepl3.py", line 58
> >     previous_attributes = dict()
> >                                ^
> > TabError: inconsistent use of tabs and spaces in indentation
> >
> > Don't use tabs (see PEP-8).
>
> And opening LDAP connection in the while-loop (line 138) looks also bogus.
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160112/d0840f62/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: syncrepl4.py
Type: text/x-python
Size: 6650 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160112/d0840f62/attachment.py>

From davidgab283 at gmail.com  Tue Jan 12 11:30:31 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Tue, 12 Jan 2016 08:30:31 -0800
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1f0t=vnJoVJkgQ7S1tuvMd4WKqYNgs6xft1DjLxbRy1TQ@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
 <568FED2F.6040608@stroeder.com>
 <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>
 <5693B2F7.30206@stroeder.com> <5693B36E.8060203@stroeder.com>
 <CAMyzk1f0t=vnJoVJkgQ7S1tuvMd4WKqYNgs6xft1DjLxbRy1TQ@mail.gmail.com>
Message-ID: <CAMyzk1dtyfcr9=XzpOEtEMMieXZ-AN1LvvGUX6_9gOpZmfFaTw@mail.gmail.com>

Please let me add one detail.
When I add this instruction: eventlet.sleep(5) after this line: print
'Detected', change_type, 'of entry:', dn (or this one print 'Detected
deletion of entry:', self.__data[uuid]['dn']) the other threads (evt2 and
evt3) are executed as well for some time.
After few seconds the program is blocked an other time in evt1 untill a new
update is triggered from the ldap data base.

Please tell me how shall I fix this issue.
Thanks in advance.

2016-01-12 1:27 GMT-08:00 David Gabriel <davidgab283 at gmail.com>:

> Dear Michael and all
>
> Thank you very much for your help ...
> Kindy find attached my source file.
> I replaced all tabs and I fixed the bugs related to this modification.
> Please note the presence of 3 threads including the syncrepl one.
> When I disable the creation of the syncrepl thread (comment the evt1
> lines) the program is alternating the execution of evt3 and evt2. However
> when I enable it the program is executing only the syncrepl thread and not
> the 3 threads.
>
> Please help me to fix this issue.
> Thanks in advance.
> Regards
>
> 2016-01-11 5:51 GMT-08:00 Michael Str?der <michael at stroeder.com>:
>
>> Michael Str?der wrote:
>> > David Gabriel wrote:
>> >> Thanks Michael.
>> >> Kindly find attached my source code.
>> >
>> > This results in:
>> >
>> > python -tt tmp/syncrepl3.py 'ldapi://dc=stroeder,dc=de'
>> >   File "tmp/syncrepl3.py", line 58
>> >     previous_attributes = dict()
>> >                                ^
>> > TabError: inconsistent use of tabs and spaces in indentation
>> >
>> > Don't use tabs (see PEP-8).
>>
>> And opening LDAP connection in the while-loop (line 138) looks also bogus.
>>
>> Ciao, Michael.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160112/ad388a4e/attachment.html>

From davidgab283 at gmail.com  Fri Jan 15 04:16:22 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Fri, 15 Jan 2016 10:16:22 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1dtyfcr9=XzpOEtEMMieXZ-AN1LvvGUX6_9gOpZmfFaTw@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
 <568FED2F.6040608@stroeder.com>
 <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>
 <5693B2F7.30206@stroeder.com> <5693B36E.8060203@stroeder.com>
 <CAMyzk1f0t=vnJoVJkgQ7S1tuvMd4WKqYNgs6xft1DjLxbRy1TQ@mail.gmail.com>
 <CAMyzk1dtyfcr9=XzpOEtEMMieXZ-AN1LvvGUX6_9gOpZmfFaTw@mail.gmail.com>
Message-ID: <CAMyzk1dj7FByWPQsw-+S1ZJdwP40o_vnjYgXjRAFLdsdkwNxUw@mail.gmail.com>

Dears

Please do you have any idea how to define the syncrepl program in such way
to enable the use of eventlet without getting the blocking behavior.
Please let me know whether there is a fix for this issue or not.
Really I am blocked at this step for days !!

Thanks in advance.
Best regards

2016-01-12 17:30 GMT+01:00 David Gabriel <davidgab283 at gmail.com>:

> Please let me add one detail.
> When I add this instruction: eventlet.sleep(5) after this line: print
> 'Detected', change_type, 'of entry:', dn (or this one print 'Detected
> deletion of entry:', self.__data[uuid]['dn']) the other threads (evt2 and
> evt3) are executed as well for some time.
> After few seconds the program is blocked an other time in evt1 untill a
> new update is triggered from the ldap data base.
>
> Please tell me how shall I fix this issue.
> Thanks in advance.
>
> 2016-01-12 1:27 GMT-08:00 David Gabriel <davidgab283 at gmail.com>:
>
>> Dear Michael and all
>>
>> Thank you very much for your help ...
>> Kindy find attached my source file.
>> I replaced all tabs and I fixed the bugs related to this modification.
>> Please note the presence of 3 threads including the syncrepl one.
>> When I disable the creation of the syncrepl thread (comment the evt1
>> lines) the program is alternating the execution of evt3 and evt2. However
>> when I enable it the program is executing only the syncrepl thread and not
>> the 3 threads.
>>
>> Please help me to fix this issue.
>> Thanks in advance.
>> Regards
>>
>> 2016-01-11 5:51 GMT-08:00 Michael Str?der <michael at stroeder.com>:
>>
>>> Michael Str?der wrote:
>>> > David Gabriel wrote:
>>> >> Thanks Michael.
>>> >> Kindly find attached my source code.
>>> >
>>> > This results in:
>>> >
>>> > python -tt tmp/syncrepl3.py 'ldapi://dc=stroeder,dc=de'
>>> >   File "tmp/syncrepl3.py", line 58
>>> >     previous_attributes = dict()
>>> >                                ^
>>> > TabError: inconsistent use of tabs and spaces in indentation
>>> >
>>> > Don't use tabs (see PEP-8).
>>>
>>> And opening LDAP connection in the while-loop (line 138) looks also
>>> bogus.
>>>
>>> Ciao, Michael.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160115/a16fe204/attachment.html>

From elmir at unity3d.com  Fri Jan 15 09:14:33 2016
From: elmir at unity3d.com (Elmir Jagudin)
Date: Fri, 15 Jan 2016 15:14:33 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
Message-ID: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>

Hi

Here is a patch that fixes issue with corrupted search attributes while
using LDAPObject.search_s().

The problem happens when converting attrlist argument from python list to C
char ** array. The problematic code is in attrs_from_List() function in
Modules/LDAPObject.c:

    attrs[i] = PyString_AsString(item);
    Py_DECREF(item);

If the item happens to have ref count 1 before executing the above, the
pointer assigned to attrs[i] will become invalid. The LDAP search request
send out will possibly have mangled search attributes.

I run into this problem while using some LDAP code under pypy. Here is a
simple script that reproduces the problem:

https://gist.github.com/elmirjagudin/6d7aadaa1825901ed73d

In the attached patch I have modified the conversion from python to C type
to use PySequence_Fast* functions. Using PySequence_Fast() call we fetch a
pointer to a temporary python sequence object. We keep track of the object
and decrement the it's ref counter after the call to underlying
ldap_search_ext() C function. Thus we keep attrs pointers valid during that
call.


Regards,
Elmir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160115/a1913646/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-corrupt-search-attrs.patch
Type: text/x-patch
Size: 4263 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160115/a1913646/attachment.bin>

From michael at stroeder.com  Sat Jan 16 14:10:18 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 16 Jan 2016 20:10:18 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
References: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
Message-ID: <569A959A.3080002@stroeder.com>

Elmir,

sorry for following-up so late.

Elmir Jagudin wrote:
> Here is a patch that fixes issue with corrupted search attributes while
> using LDAPObject.search_s().

Many thanks for your patch.

I've committed your fix to CVS HEAD. Please test.

Be able to use python-ldap with pypy is important. Therefore I plan to release
this fix in release 2.4.23 pretty soon.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160116/472c8143/attachment.bin>

From michael at stroeder.com  Sun Jan 17 05:14:17 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sun, 17 Jan 2016 11:14:17 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <569A959A.3080002@stroeder.com>
References: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
 <569A959A.3080002@stroeder.com>
Message-ID: <569B6979.9030803@stroeder.com>

Michael Str?der wrote:
> Elmir,
> 
> sorry for following-up so late.
> 
> Elmir Jagudin wrote:
>> Here is a patch that fixes issue with corrupted search attributes while
>> using LDAPObject.search_s().
> 
> Many thanks for your patch.
> 
> I've committed your fix to CVS HEAD. Please test.
> 
> Be able to use python-ldap with pypy is important. Therefore I plan to release
> this fix in release 2.4.23 pretty soon.

I've tested my web2ldap with pypy 4.0.1 and this fix. It seems to work.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160117/90d5ba1b/attachment.bin>

From michael at stroeder.com  Sun Jan 17 09:36:00 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sun, 17 Jan 2016 15:36:00 +0100
Subject: [python-ldap] ANN: python-ldap 2.4.23
Message-ID: <569BA6D0.7080600@stroeder.com>

Find a new release of python-ldap:

  https://pypi.python.org/pypi/python-ldap/2.4.23

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, LDAP URLs and LDAPv3 schema).

Project's web site:

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

Checksums:

md5sum python-ldap-2.4.23.tar.gz
3a53d482fd628500ceebe7eca7ace34c

sha1sum python-ldap-2.4.23.tar.gz
39d3f1004e414369d623ea68fd21fee3517355bf

sha256sum python-ldap-2.4.23.tar.gz
7f0406bd7acbdde6ff9ba91b3c9aefb22864d24c3fb35a92baf2e3ab6bf251a4

Ciao, Michael.

----------------------------------------------------------------
Released 2.4.23 2016-01-17

Changes since 2.4.22:

Modules/
* Ref count issue in attrs_from_List() was fixed
  (thanks to Elmir Jagudin)

From michael at stroeder.com  Sun Jan 17 15:12:43 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sun, 17 Jan 2016 21:12:43 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
References: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
Message-ID: <569BF5BB.9030801@stroeder.com>

Elmir Jagudin wrote:
> Here is a patch that fixes issue with corrupted search attributes while
> using LDAPObject.search_s().

There's a problem with your patch:
It does not handle attrlist=None correctly.

This script fails with:
TypeError: expected list of strings or None

--------------------- snip ---------------------
import ldap

l = ldap.initialize('ldapi://',trace_level=2)
l.sasl_external_bind_s()

l.search_s(
    'dc=stroeder,dc=de',
    ldap.SCOPE_BASE,
    '(objectClass=*)',
    attrlist=None
)
--------------------- snip ---------------------

Could you please send in a revised patch *soon*?

Note:
I definitely don't want to automagically replace attrlist=None by attrlist=['*']
in the Python wrapper class because some LDAP servers may (incorrectly) treat
these cases differently.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160117/773ea7f5/attachment.bin>

From michael at stroeder.com  Sun Jan 17 15:15:39 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sun, 17 Jan 2016 21:15:39 +0100
Subject: [python-ldap] ANN: python-ldap 2.4.23
In-Reply-To: <569BA6D0.7080600@stroeder.com>
References: <569BA6D0.7080600@stroeder.com>
Message-ID: <569BF66B.5020702@stroeder.com>

Michael Str?der wrote:
> Find a new release of python-ldap:
> 
>   https://pypi.python.org/pypi/python-ldap/2.4.23

Sorry, I had to withdraw this release because of a serious regression I did not
notice before.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160117/2445b311/attachment.bin>

From papachoco at gmail.com  Sun Jan 17 15:49:34 2016
From: papachoco at gmail.com (Carlos Sanchez)
Date: Sun, 17 Jan 2016 14:49:34 -0600
Subject: [python-ldap] [PATCH] fix corrupted search attributes
Message-ID: <CAHZqGS-XBWoDDH3SkKroVdWkTsoQBMuDVFciwGu+4gJ045iWdw@mail.gmail.com>

Hello,

I am still seeing a TypeError (see below) with python_ldap-2.4.23 in python
2.7.11 (MacOSX - El capitan) using openldap-2.4.43.tgz

Thanks a lot

Carlos

/Users/csanchez/buildout/develop-eggs/python_ldap-2.4.23-py2.7-macosx-10.11-x86_64.egg/ldap/ldapobject.py(106)_ldap_call()

args = (u'OU=Accounts,DC=sooner,DC=net,DC=ou,DC=edu', 2,
u'sAMAccountName=cald3307', None, 0, None, None, -1, 0)

self = LDAP Connector (connected) -

func = <built-in method search_ext of LDAP object at 0x117c50fd0>

TypeError: 'expected list of strings or None?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160117/78d17f8c/attachment.html>

From michael at stroeder.com  Sun Jan 17 15:57:59 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sun, 17 Jan 2016 21:57:59 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <CAHZqGS-XBWoDDH3SkKroVdWkTsoQBMuDVFciwGu+4gJ045iWdw@mail.gmail.com>
References: <CAHZqGS-XBWoDDH3SkKroVdWkTsoQBMuDVFciwGu+4gJ045iWdw@mail.gmail.com>
Message-ID: <569C0057.9070405@stroeder.com>

Carlos Sanchez wrote:
> I am still seeing a TypeError (see below) with python_ldap-2.4.23 in python
> 2.7.11 (MacOSX - El capitan) using openldap-2.4.43.tgz

Yes, during the next days everybody should still stay with 2.4.22.

I've committed a work-around to CVS:
http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.149&r2=1.150

Let's see whether Elmir will update his patch.
Either I will release 2.4.24 with the work-around above or with another fix.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160117/7f17623b/attachment-0001.bin>

From elmir at unity3d.com  Mon Jan 18 04:17:10 2016
From: elmir at unity3d.com (Elmir Jagudin)
Date: Mon, 18 Jan 2016 10:17:10 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <569BF5BB.9030801@stroeder.com>
References: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
 <569BF5BB.9030801@stroeder.com>
Message-ID: <CAN1hHsq_+7P=ocXxBgzsQeyXroBho4EdEgjrnhm9SCi2p193dg@mail.gmail.com>

On Sun, Jan 17, 2016 at 9:12 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Elmir Jagudin wrote:
> > Here is a patch that fixes issue with corrupted search attributes while
> > using LDAPObject.search_s().
>
> There's a problem with your patch:
> It does not handle attrlist=None correctly.
>

Yepp, I missed that use case. Here comes second version of the patch, where
this problem is fixed.

/Elmir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160118/0b81f055/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-corrupt-search-attrs-2.patch
Type: text/x-patch
Size: 3818 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160118/0b81f055/attachment.bin>

From michael at stroeder.com  Mon Jan 18 08:55:22 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 18 Jan 2016 14:55:22 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <CAN1hHsq_+7P=ocXxBgzsQeyXroBho4EdEgjrnhm9SCi2p193dg@mail.gmail.com>
References: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
 <569BF5BB.9030801@stroeder.com>
 <CAN1hHsq_+7P=ocXxBgzsQeyXroBho4EdEgjrnhm9SCi2p193dg@mail.gmail.com>
Message-ID: <569CEECA.4030107@stroeder.com>

Elmir Jagudin wrote:
> On Sun, Jan 17, 2016 at 9:12 PM, Michael Str?der <michael at stroeder.com>
> wrote:
> 
>> Elmir Jagudin wrote:
>>> Here is a patch that fixes issue with corrupted search attributes while
>>> using LDAPObject.search_s().
>>
>> There's a problem with your patch:
>> It does not handle attrlist=None correctly.
>>
> 
> Yepp, I missed that use case. Here comes second version of the patch, where
> this problem is fixed.

Committed to CVS:
http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/LDAPObject.c?r1=1.92&r2=1.93

I'd like to release 2.4.24 with this regression fix today.
So please test.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160118/42dd55ee/attachment.bin>

From elmir at unity3d.com  Mon Jan 18 09:49:10 2016
From: elmir at unity3d.com (Elmir Jagudin)
Date: Mon, 18 Jan 2016 15:49:10 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <569CEECA.4030107@stroeder.com>
References: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
 <569BF5BB.9030801@stroeder.com>
 <CAN1hHsq_+7P=ocXxBgzsQeyXroBho4EdEgjrnhm9SCi2p193dg@mail.gmail.com>
 <569CEECA.4030107@stroeder.com>
Message-ID: <CAN1hHso4DE7X-DRys8ZeRGKPjpiNCQL4ugVkgfgJ_0rgMCJSUQ@mail.gmail.com>

On Mon, Jan 18, 2016 at 2:55 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Elmir Jagudin wrote:
> > On Sun, Jan 17, 2016 at 9:12 PM, Michael Str?der <michael at stroeder.com>
> > wrote:
> >
> >> Elmir Jagudin wrote:
> >>> Here is a patch that fixes issue with corrupted search attributes while
> >>> using LDAPObject.search_s().
> >>
> >> There's a problem with your patch:
> >> It does not handle attrlist=None correctly.
> >>
> >
> > Yepp, I missed that use case. Here comes second version of the patch,
> where
> > this problem is fixed.
>
> Committed to CVS:
>
> http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/LDAPObject.c?r1=1.92&r2=1.93
>
> I'd like to release 2.4.24 with this regression fix today.
> So please test.
>
>
I did some testing from CVS head. I don't see any problems.

/Elmir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160118/de1892c0/attachment.html>

From davidgab283 at gmail.com  Mon Jan 18 10:07:07 2016
From: davidgab283 at gmail.com (David Gabriel)
Date: Mon, 18 Jan 2016 16:07:07 +0100
Subject: [python-ldap] SyncreplConsumer running in parallel with other
 application
In-Reply-To: <CAMyzk1dj7FByWPQsw-+S1ZJdwP40o_vnjYgXjRAFLdsdkwNxUw@mail.gmail.com>
References: <CAMyzk1fEttqDjA7_j0OhPBjUEqFpcjdkwiUwhgZSjqu1nxL20w@mail.gmail.com>
 <568E7A96.4080002@stroeder.com>
 <CAMyzk1fhWyAsus467fkXjuA1S0ykvLuhXmisrXpvxECJNsSqmw@mail.gmail.com>
 <CAMyzk1fjKeUM5VjsdswREbu4cfVSBM6Q496kj3TnniVaa3Ra6Q@mail.gmail.com>
 <CAMyzk1cadX0PNere6xJGqA7EdReAB85xWJMDMx4C+tMK=gO6dQ@mail.gmail.com>
 <568FDC2E.3050503@stroeder.com>
 <CAMyzk1fi9NHR8V88bdKANCRQ-xvOVwtB_Y871ZyVJG_gJhdGpg@mail.gmail.com>
 <568FED2F.6040608@stroeder.com>
 <CAMyzk1dLFSMbrOQ2=HEmX1BGhjhbfW8x3cHOOhhgYH4asmFr3A@mail.gmail.com>
 <5693B2F7.30206@stroeder.com> <5693B36E.8060203@stroeder.com>
 <CAMyzk1f0t=vnJoVJkgQ7S1tuvMd4WKqYNgs6xft1DjLxbRy1TQ@mail.gmail.com>
 <CAMyzk1dtyfcr9=XzpOEtEMMieXZ-AN1LvvGUX6_9gOpZmfFaTw@mail.gmail.com>
 <CAMyzk1dj7FByWPQsw-+S1ZJdwP40o_vnjYgXjRAFLdsdkwNxUw@mail.gmail.com>
Message-ID: <CAMyzk1dzn87N2rafL5_XA6cc=qufz+-GWvgw-MpknrNpbsyVfQ@mail.gmail.com>

Dears,

Let me add one more detail: When I add these two lines to check whether my
modules are monkey_patched or not I get *False* as a result.
I think it is strange to get this result since I patched my modules at the
beginning using: eventlet.monkey_patch() as detailed here
<http://eventlet.net/doc/patching.html#import-green>.

print "*****is_monkey_patched(ldap.syncrepl) : %s*****" %
eventlet.patcher.is_monkey_patched('ldap.syncrepl')
print "*****is_monkey_patched(ldap.ldapobject) : %s*****" %
eventlet.patcher.is_monkey_patched('ldap.ldapobject')


Please advise me how to fix this issue.
Kind regards.

2016-01-15 10:16 GMT+01:00 David Gabriel <davidgab283 at gmail.com>:

> Dears
>
> Please do you have any idea how to define the syncrepl program in such way
> to enable the use of eventlet without getting the blocking behavior.
> Please let me know whether there is a fix for this issue or not.
> Really I am blocked at this step for days !!
>
> Thanks in advance.
> Best regards
>
> 2016-01-12 17:30 GMT+01:00 David Gabriel <davidgab283 at gmail.com>:
>
>> Please let me add one detail.
>> When I add this instruction: eventlet.sleep(5) after this line: print
>> 'Detected', change_type, 'of entry:', dn (or this one print 'Detected
>> deletion of entry:', self.__data[uuid]['dn']) the other threads (evt2 and
>> evt3) are executed as well for some time.
>> After few seconds the program is blocked an other time in evt1 untill a
>> new update is triggered from the ldap data base.
>>
>> Please tell me how shall I fix this issue.
>> Thanks in advance.
>>
>> 2016-01-12 1:27 GMT-08:00 David Gabriel <davidgab283 at gmail.com>:
>>
>>> Dear Michael and all
>>>
>>> Thank you very much for your help ...
>>> Kindy find attached my source file.
>>> I replaced all tabs and I fixed the bugs related to this modification.
>>> Please note the presence of 3 threads including the syncrepl one.
>>> When I disable the creation of the syncrepl thread (comment the evt1
>>> lines) the program is alternating the execution of evt3 and evt2. However
>>> when I enable it the program is executing only the syncrepl thread and not
>>> the 3 threads.
>>>
>>> Please help me to fix this issue.
>>> Thanks in advance.
>>> Regards
>>>
>>> 2016-01-11 5:51 GMT-08:00 Michael Str?der <michael at stroeder.com>:
>>>
>>>> Michael Str?der wrote:
>>>> > David Gabriel wrote:
>>>> >> Thanks Michael.
>>>> >> Kindly find attached my source code.
>>>> >
>>>> > This results in:
>>>> >
>>>> > python -tt tmp/syncrepl3.py 'ldapi://dc=stroeder,dc=de'
>>>> >   File "tmp/syncrepl3.py", line 58
>>>> >     previous_attributes = dict()
>>>> >                                ^
>>>> > TabError: inconsistent use of tabs and spaces in indentation
>>>> >
>>>> > Don't use tabs (see PEP-8).
>>>>
>>>> And opening LDAP connection in the while-loop (line 138) looks also
>>>> bogus.
>>>>
>>>> Ciao, Michael.
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160118/a1f9aa0d/attachment-0001.html>

From michael at stroeder.com  Tue Jan 19 04:53:05 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 19 Jan 2016 10:53:05 +0100
Subject: [python-ldap] ANN: python-ldap 2.4.25
Message-ID: <569E0781.9040302@stroeder.com>

Find a new release of python-ldap:

  https://pypi.python.org/pypi/python-ldap/2.4.25

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, LDAP URLs and LDAPv3 schema).

Project's web site:

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

Checksums:

md5sum python-ldap-2.4.25.tar.gz
21523bf21dbe566e0259030f66f7a487

sha1sum python-ldap-2.4.25.tar.gz
fa058ef9d77e4081d260c4972f6f2a5d4c45f36b

sha256sum python-ldap-2.4.25.tar.gz
62d00dbc86f3f9b21beacd9b826e8f9895f900637a60a6d4e7ab59a1cdc64e56

Ciao, Michael.

----------------------------------------------------------------
Released 2.4.25 2016-01-18

Changes since 2.4.23:
(2.4.24 is missing because of foolish pypi version madness)

Lib/
* Fix for attrlist=None regression introduced in 2.4.23
  by ref count patch

----------------------------------------------------------------
Released 2.4.23 2016-01-17

Changes since 2.4.22:

Modules/
* Ref count issue in attrs_from_List() was fixed
  (thanks to Elmir Jagudin)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160119/1d9234cf/attachment.bin>

From elmir at unity3d.com  Wed Jan 20 04:48:57 2016
From: elmir at unity3d.com (Elmir Jagudin)
Date: Wed, 20 Jan 2016 10:48:57 +0100
Subject: [python-ldap] [PATCH] fix corrupted search attributes
In-Reply-To: <CAN1hHso4DE7X-DRys8ZeRGKPjpiNCQL4ugVkgfgJ_0rgMCJSUQ@mail.gmail.com>
References: <CAN1hHspwCDkhn1gDbHks6RLrWr6xFqVBOGmC7QDUZ79_vNt=4Q@mail.gmail.com>
 <569BF5BB.9030801@stroeder.com>
 <CAN1hHsq_+7P=ocXxBgzsQeyXroBho4EdEgjrnhm9SCi2p193dg@mail.gmail.com>
 <569CEECA.4030107@stroeder.com>
 <CAN1hHso4DE7X-DRys8ZeRGKPjpiNCQL4ugVkgfgJ_0rgMCJSUQ@mail.gmail.com>
Message-ID: <CAN1hHsp+SgVpEcnoC67tW3Zoc3paaqb3OM5XEQ1tg0grH1Tx1A@mail.gmail.com>

On Mon, Jan 18, 2016 at 3:49 PM, Elmir Jagudin <elmir at unity3d.com> wrote:

>
>
> On Mon, Jan 18, 2016 at 2:55 PM, Michael Str?der <michael at stroeder.com>
> wrote:
>
>> Elmir Jagudin wrote:
>> > On Sun, Jan 17, 2016 at 9:12 PM, Michael Str?der <michael at stroeder.com>
>> > wrote:
>> >
>> >> Elmir Jagudin wrote:
>> >>> Here is a patch that fixes issue with corrupted search attributes
>> while
>> >>> using LDAPObject.search_s().
>> >>
>> >> There's a problem with your patch:
>> >> It does not handle attrlist=None correctly.
>> >>
>> >
>> > Yepp, I missed that use case. Here comes second version of the patch,
>> where
>> > this problem is fixed.
>>
>> Committed to CVS:
>>
>> http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/LDAPObject.c?r1=1.92&r2=1.93
>>
>> I'd like to release 2.4.24 with this regression fix today.
>> So please test.
>>
>>
> I did some testing from CVS head. I don't see any problems.
>

I just tested the official 2.4.25 release. It solves my LDAP login problems
and all seems peachy.

Thanks for the new release and sorry for messing up the 2.4.24 release :P

/Elmir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160120/51c8a401/attachment.html>

From pviktori at redhat.com  Tue Jan 26 04:39:45 2016
From: pviktori at redhat.com (Petr Viktorin)
Date: Tue, 26 Jan 2016 10:39:45 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <565F0E62.7000500@wechall.net>
References: <565F0E62.7000500@wechall.net>
Message-ID: <56A73EE1.4070904@redhat.com>

On 12/02/2015 04:29 PM, Space One wrote:
> Hello,
> 
> how can I check if a connection is still valid? Is there some
> no-operation which is really fast?
> I tried to just use whoami_s() but this segfaults always:
> 
> python-ldap 2.4.16-0.1
> Python 2.7.3 (default, Jul  2 2014, 15:00:03)
> [GCC 4.7.2] on linux2
>>>> import ldap
>>>> lo = ldap.initialize("ldap://0.0.0.0:7389")
>>>> lo.unbind_s()
>>>> lo.whoami_s()
> python: whoami.c:68: ldap_whoami: Assertion `(
> (ld)->ldc->ldc_options.ldo_valid == 0x2 )' failed.
> Aborted

Hello,
Christian Heimes wrote a patch to fix the segfault. Could you please
review it?


-- 
Petr Viktorin
-- 
https://github.com/pyldap/pyldap/pull/30

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Validate-LDAP-connection-in-whoami_s.patch
Type: text/x-patch
Size: 1535 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160126/835719c3/attachment.bin>

From michael at stroeder.com  Tue Jan 26 06:06:12 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 26 Jan 2016 12:06:12 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A73EE1.4070904@redhat.com>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
Message-ID: <56A75324.9090209@stroeder.com>

Petr Viktorin wrote:
> On 12/02/2015 04:29 PM, Space One wrote:
>> how can I check if a connection is still valid? Is there some
>> no-operation which is really fast?
>> I tried to just use whoami_s() but this segfaults always:

Thanks for the patch. Fix for Modules/LDAPObject.c will be released in 2.4.26.

I also wonder whether ldap.ldapobject.LDAPObject.unbind_ext() should simply
remove class attribute LDAPObject._l and a check be added to method
LDAPObject._ldap_call(). That would be an approach which protects any C method
implementation from being called for invalid LDAP connection.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160126/51dc32a5/attachment.bin>

From pviktori at redhat.com  Tue Jan 26 09:23:37 2016
From: pviktori at redhat.com (Petr Viktorin)
Date: Tue, 26 Jan 2016 15:23:37 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A75324.9090209@stroeder.com>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com>
Message-ID: <56A78169.7070405@redhat.com>

On 01/26/2016 12:06 PM, Michael Str?der wrote:
> Petr Viktorin wrote:
>> On 12/02/2015 04:29 PM, Space One wrote:
>>> how can I check if a connection is still valid? Is there some
>>> no-operation which is really fast?
>>> I tried to just use whoami_s() but this segfaults always:
> 
> Thanks for the patch. Fix for Modules/LDAPObject.c will be released in 2.4.26.
> 
> I also wonder whether ldap.ldapobject.LDAPObject.unbind_ext() should simply
> remove class attribute LDAPObject._l and a check be added to method
> LDAPObject._ldap_call(). That would be an approach which protects any C method
> implementation from being called for invalid LDAP connection.

Right, that would make it safer.

To address the original question, perhaps LDAPObject should grow a
utility method/attribute for checking if the _l is still there?


-- 
Petr Viktorin

From michael at stroeder.com  Tue Jan 26 10:01:03 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 26 Jan 2016 16:01:03 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A78169.7070405@redhat.com>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
Message-ID: <56A78A2F.3030008@stroeder.com>

Petr Viktorin wrote:
> On 01/26/2016 12:06 PM, Michael Str?der wrote:
>> Petr Viktorin wrote:
>>> On 12/02/2015 04:29 PM, Space One wrote:
>>>> how can I check if a connection is still valid? Is there some
>>>> no-operation which is really fast?
>>>> I tried to just use whoami_s() but this segfaults always:
>>
>> Thanks for the patch. Fix for Modules/LDAPObject.c will be released in 2.4.26.
>>
>> I also wonder whether ldap.ldapobject.LDAPObject.unbind_ext() should simply
>> remove class attribute LDAPObject._l and a check be added to method
>> LDAPObject._ldap_call(). That would be an approach which protects any C method
>> implementation from being called for invalid LDAP connection.
> 
> Right, that would make it safer.

Done.

http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.151&r2=1.152

I did not add raising a specific exception in LDAPObject._ldap_call() yet.
It will currently just raise AttributeError like this:

Traceback (most recent call last):
  File "/home/michael/tmp/test.py", line 6, in <module>
    l.whoami_s()
  File
"/home/michael/Proj/python-ldap/python-ldap/build/lib.linux-x86_64-2.7/ldap/ldapobject.py",
line 643, in whoami_s
    return self._ldap_call(self._l.whoami_s,serverctrls,clientctrls)
  File
"/home/michael/Proj/python-ldap/python-ldap/build/lib.linux-x86_64-2.7/ldap/ldapobject.py",
line 136, in __getattr__
    self.__class__.__name__,repr(name)
AttributeError: SimpleLDAPObject has no attribute '_l'

Let me know what you think. There might also be some corner-case within
ReconnectLDAPObject which I did not investigate yet.

> To address the original question, perhaps LDAPObject should grow a
> utility method/attribute for checking if the _l is still there?

I'd prefer people to write correct application code. ;-)

Seriously: Such a utility method/attribute might lead people to believe it's
something which has to be checked regularly. IMHO it's not. The calling code has
to be fixed.

But of course python-ldap must *never* seg fault if the calling code is wrong.
So thanks again for pointing this out.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160126/8d044f3b/attachment-0001.bin>

From space at wechall.net  Tue Jan 26 10:10:17 2016
From: space at wechall.net (Space One)
Date: Tue, 26 Jan 2016 16:10:17 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A78A2F.3030008@stroeder.com>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com>
Message-ID: <56A78C59.6060802@wechall.net>

AttributeError is IMHO not good, please better raise ldap.SERVER_DOWN so
that one can handle it.

Am 26.01.2016 um 16:01 schrieb Michael Str?der:
> Petr Viktorin wrote:
>> On 01/26/2016 12:06 PM, Michael Str?der wrote:
>>> Petr Viktorin wrote:
>>>> On 12/02/2015 04:29 PM, Space One wrote:
>>>>> how can I check if a connection is still valid? Is there some
>>>>> no-operation which is really fast?
>>>>> I tried to just use whoami_s() but this segfaults always:
>>> Thanks for the patch. Fix for Modules/LDAPObject.c will be released in 2.4.26.
>>>
>>> I also wonder whether ldap.ldapobject.LDAPObject.unbind_ext() should simply
>>> remove class attribute LDAPObject._l and a check be added to method
>>> LDAPObject._ldap_call(). That would be an approach which protects any C method
>>> implementation from being called for invalid LDAP connection.
>> Right, that would make it safer.
> Done.
>
> http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.151&r2=1.152
>
> I did not add raising a specific exception in LDAPObject._ldap_call() yet.
> It will currently just raise AttributeError like this:
>
> Traceback (most recent call last):
>   File "/home/michael/tmp/test.py", line 6, in <module>
>     l.whoami_s()
>   File
> "/home/michael/Proj/python-ldap/python-ldap/build/lib.linux-x86_64-2.7/ldap/ldapobject.py",
> line 643, in whoami_s
>     return self._ldap_call(self._l.whoami_s,serverctrls,clientctrls)
>   File
> "/home/michael/Proj/python-ldap/python-ldap/build/lib.linux-x86_64-2.7/ldap/ldapobject.py",
> line 136, in __getattr__
>     self.__class__.__name__,repr(name)
> AttributeError: SimpleLDAPObject has no attribute '_l'
>
> Let me know what you think. There might also be some corner-case within
> ReconnectLDAPObject which I did not investigate yet.
>
>> To address the original question, perhaps LDAPObject should grow a
>> utility method/attribute for checking if the _l is still there?
> I'd prefer people to write correct application code. ;-)
>
> Seriously: Such a utility method/attribute might lead people to believe it's
> something which has to be checked regularly. IMHO it's not. The calling code has
> to be fixed.
>
> But of course python-ldap must *never* seg fault if the calling code is wrong.
> So thanks again for pointing this out.
>
> Ciao, Michael.
>
>
>
>
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160126/3d4fbe5e/attachment.html>

From michael at stroeder.com  Tue Jan 26 10:21:05 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 26 Jan 2016 16:21:05 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A78C59.6060802@wechall.net>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com> <56A78C59.6060802@wechall.net>
Message-ID: <56A78EE1.8050608@stroeder.com>

Space One wrote:
> AttributeError is IMHO not good, please better raise ldap.SERVER_DOWN so
> that one can handle it.

I consider ldap.SERVER_DOWN to be inappropriate in this case because it
indicates an error the application can recover from by proper reconnect.

But in case the application calls some LDAPObject method *after* unbinding then
the application's code has to be fixed. This is a different case!

Ciao, Michael.

> Am 26.01.2016 um 16:01 schrieb Michael Str?der:
>> Petr Viktorin wrote:
>>> On 01/26/2016 12:06 PM, Michael Str?der wrote:
>>>> Petr Viktorin wrote:
>>>>> On 12/02/2015 04:29 PM, Space One wrote:
>>>>>> how can I check if a connection is still valid? Is there some
>>>>>> no-operation which is really fast?
>>>>>> I tried to just use whoami_s() but this segfaults always:
>>>> Thanks for the patch. Fix for Modules/LDAPObject.c will be released in 2.4.26.
>>>>
>>>> I also wonder whether ldap.ldapobject.LDAPObject.unbind_ext() should simply
>>>> remove class attribute LDAPObject._l and a check be added to method
>>>> LDAPObject._ldap_call(). That would be an approach which protects any C method
>>>> implementation from being called for invalid LDAP connection.
>>> Right, that would make it safer.
>> Done.
>>
>> http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.151&r2=1.152
>>
>> I did not add raising a specific exception in LDAPObject._ldap_call() yet.
>> It will currently just raise AttributeError like this:
>>
>> Traceback (most recent call last):
>>   File "/home/michael/tmp/test.py", line 6, in <module>
>>     l.whoami_s()
>>   File
>> "/home/michael/Proj/python-ldap/python-ldap/build/lib.linux-x86_64-2.7/ldap/ldapobject.py",
>> line 643, in whoami_s
>>     return self._ldap_call(self._l.whoami_s,serverctrls,clientctrls)
>>   File
>> "/home/michael/Proj/python-ldap/python-ldap/build/lib.linux-x86_64-2.7/ldap/ldapobject.py",
>> line 136, in __getattr__
>>     self.__class__.__name__,repr(name)
>> AttributeError: SimpleLDAPObject has no attribute '_l'
>>
>> Let me know what you think. There might also be some corner-case within
>> ReconnectLDAPObject which I did not investigate yet.
>>
>>> To address the original question, perhaps LDAPObject should grow a
>>> utility method/attribute for checking if the _l is still there?
>> I'd prefer people to write correct application code. ;-)
>>
>> Seriously: Such a utility method/attribute might lead people to believe it's
>> something which has to be checked regularly. IMHO it's not. The calling code has
>> to be fixed.
>>
>> But of course python-ldap must *never* seg fault if the calling code is wrong.
>> So thanks again for pointing this out.
>>
>> Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160126/b45c4cfb/attachment.bin>

From michael at stroeder.com  Tue Jan 26 10:40:24 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 26 Jan 2016 16:40:24 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A79058.3070402@wechall.net>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com> <56A78C59.6060802@wechall.net>
 <56A78EE1.8050608@stroeder.com> <56A79058.3070402@wechall.net>
Message-ID: <56A79368.1080404@stroeder.com>

HI!

(please stay on python-ldap list so others comment as well)

Space One wrote:
> 
> Am 26.01.2016 um 16:21 schrieb Michael Str?der:
>> Space One wrote:
>>> AttributeError is IMHO not good, please better raise ldap.SERVER_DOWN so
>>> that one can handle it.
>> I consider ldap.SERVER_DOWN to be inappropriate in this case because it
>> indicates an error the application can recover from by proper reconnect.
>>
>> But in case the application calls some LDAPObject method *after* unbinding then
>> the application's code has to be fixed. This is a different case!
>
> We are speaking about ldap.ldapobject.ReconnectLDAPObject, right?

Not limited to ReconnectLDAPObject.

> This class somehow unbind()s itself.

I never experienced such a seg fault when using ReconnectLDAPObject and I'm
using it a lot. Therefore I assume there's no problem inside this class.
Especially it won't call any LDAPObject method after internal unbind without
internally setting up new connection object.

> If you aren't okay with ldap.SERVER_DOWN please don't use AttributeError
> but some new exception like ldap.UNBOUND_CONNECTION.
> 
> As the intial thread says I want a way to clearly be able to
> differentitate if the connection is still valid and handle things if
> not. AttributeError would not be nice in that scenario as I don't want
> to catch all AttributeErrors.

Your application MUST NOT catch this exception and simply re-try!

Your application MUST avoid to use an LDAPObject instance after calling
LDAPObject.unbind_ext() and friends! So if this (unhandled) exception ever
happens it indicates a bug in your application logic and you have to fix your
calling code.

The only thing python-ldap did wrong is the seg fault.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160126/73a13bbd/attachment-0001.bin>

From pviktori at redhat.com  Tue Jan 26 13:11:50 2016
From: pviktori at redhat.com (Petr Viktorin)
Date: Tue, 26 Jan 2016 19:11:50 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A79368.1080404@stroeder.com>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com> <56A78C59.6060802@wechall.net>
 <56A78EE1.8050608@stroeder.com> <56A79058.3070402@wechall.net>
 <56A79368.1080404@stroeder.com>
Message-ID: <56A7B6E6.8090802@redhat.com>

On 01/26/2016 04:40 PM, Michael Str?der wrote:
> HI!
> 
> (please stay on python-ldap list so others comment as well)
> 
> Space One wrote:
>>
>> Am 26.01.2016 um 16:21 schrieb Michael Str?der:
>>> Space One wrote:
>>>> AttributeError is IMHO not good, please better raise ldap.SERVER_DOWN so
>>>> that one can handle it.
>>> I consider ldap.SERVER_DOWN to be inappropriate in this case because it
>>> indicates an error the application can recover from by proper reconnect.
>>>
>>> But in case the application calls some LDAPObject method *after* unbinding then
>>> the application's code has to be fixed. This is a different case!
>>
>> We are speaking about ldap.ldapobject.ReconnectLDAPObject, right?
> 
> Not limited to ReconnectLDAPObject.
> 
>> This class somehow unbind()s itself.
> 
> I never experienced such a seg fault when using ReconnectLDAPObject and I'm
> using it a lot. Therefore I assume there's no problem inside this class.
> Especially it won't call any LDAPObject method after internal unbind without
> internally setting up new connection object.
> 
>> If you aren't okay with ldap.SERVER_DOWN please don't use AttributeError
>> but some new exception like ldap.UNBOUND_CONNECTION.
>>
>> As the intial thread says I want a way to clearly be able to
>> differentitate if the connection is still valid and handle things if
>> not. AttributeError would not be nice in that scenario as I don't want
>> to catch all AttributeErrors.
> 
> Your application MUST NOT catch this exception and simply re-try!
> 
> Your application MUST avoid to use an LDAPObject instance after calling
> LDAPObject.unbind_ext() and friends! So if this (unhandled) exception ever
> happens it indicates a bug in your application logic and you have to fix your
> calling code.
> 
> The only thing python-ldap did wrong is the seg fault.
> 
> Ciao, Michael.

Indeed. The only code that should be catching this exception is the test
that verifies python-ldap doesn't segfault. That test could be a bit
more specific if the exception was not a generic AttributeError.

Also, a generic exception means any code that expects AttributeError
will now catch this as well. Not too likely in good code, but one more
reason to use a specific exception.

I'm not insisting though.

-- 
Petr Viktorin


From pbengtsson at mozilla.com  Thu Feb  4 16:43:15 2016
From: pbengtsson at mozilla.com (Peter Bengtsson)
Date: Thu, 4 Feb 2016 16:43:15 -0500
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
Message-ID: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>

I'm on OSX 10.11.3 and I installed python-ldap 2.4.25 with pip in a
virtualenv. And I always get this error:

>>> import ldap
>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, '/path/to.crt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 133, in set_option
    return _ldap_function_call(None,_ldap.set_option,option,invalue)
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 64, in _ldap_function_call
    result = func(*args,**kwargs)
ValueError: option error

It doesn't matter what the value of that option is.
It does not happen when installed on Ubuntu.

Axel here, http://stackoverflow.com/a/29101851/205832 said he managed to
make the problem go away by downloading the tarball and adding /usr/local
to setup.cfg. That did not help for me.

For what it's worth, I *have* /usr/include/sasl/ on my disk.

Peter


-- 
Peter Bengtsson
Mozilla Tools & Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160204/069f841d/attachment.html>

From michael at stroeder.com  Fri Feb  5 02:14:52 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 5 Feb 2016 08:14:52 +0100
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
Message-ID: <56B44BEC.90006@stroeder.com>

Peter Bengtsson wrote:
> I'm on OSX 10.11.3 and I installed python-ldap 2.4.25 with pip in a
> virtualenv. And I always get this error:
> 
>>>> import ldap
>>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, '/path/to.crt')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 133, in set_option
>     return _ldap_function_call(None,_ldap.set_option,option,invalue)
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 64, in _ldap_function_call
>     result = func(*args,**kwargs)
> ValueError: option error

Most times this happens if the cert file does not exist.

> It doesn't matter what the value of that option is.
> It does not happen when installed on Ubuntu.

Hmm.

> Axel here, http://stackoverflow.com/a/29101851/205832 said he managed to
> make the problem go away by downloading the tarball and adding /usr/local
> to setup.cfg. That did not help for me.

That sounds like a strange solution to me. But I have no personal experience
with with Max OS X.

Ciao, Michael.

P.S.: Please subscribe to the low-traffic python-ldap mailing list. So all the
answers really reach you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160205/39021b5d/attachment.bin>

From jephte.clain at univ-reunion.fr  Sat Feb  6 04:40:55 2016
From: jephte.clain at univ-reunion.fr (Jephte Clain)
Date: Sat, 6 Feb 2016 13:40:55 +0400
Subject: [python-ldap] feature request: be more lenient in LDIFParser
Message-ID: <CAPas2jRFkc1_s=sSSHHJiVX78voT1Y_URhQaL8+LFdP0YpLrFA@mail.gmail.com>

hello,

FYI, I made feature request #18 on
http://sourceforge.net/p/python-ldap/feature-requests/18/ to make
LDIFParser more lenient

here is the description of the feature and the patch is attached:
----------------8<----------------
from the "be lenient with what you parse, be strict in what you write"
departement, I attach a patch which support ldif input with several
blank and/or comment lines between objects
I don't know if this behavior is correct wrt the LDIF standard, but it
is useful for me, because I have LDIF files with comments written by
humans, e.g:

# silly example
dn: uid=one,dc=tld
uid: one

# another silly example
dn: uid=two,dc=tld
uid: two

with the current parser, uid=two is not read because there are two
"blanks" lines before
----------------8<----------------

BTW, is there any plan to migrate python-ldap development to github or
any other similar service based on git?
It has been a long time since I last used CVS. These are all good memories :-)

very best regards,

-- 
Jepht? CLAIN | D?veloppeur, Int?grateur d'applications
Service Syst?me d'Information
Direction des Syst?mes d'Information
T?l: +262 262 93 86 31 || Gsm: +262 692 29 58 24
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldif.py.patch
Type: text/x-patch
Size: 1448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160206/ce4c2011/attachment.bin>

From pbengtsson at mozilla.com  Sat Feb  6 13:53:54 2016
From: pbengtsson at mozilla.com (Peter Bengtsson)
Date: Sat, 6 Feb 2016 13:53:54 -0500
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
Message-ID: <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>

Sending this again. Hopefully, when subscribed to the mailing list
correctly this time.

On Fri, Feb 5, 2016 at 9:00 AM, Peter Bengtsson <pbengtsson at mozilla.com>
wrote:

>
>
> On Fri, Feb 5, 2016 at 2:14 AM, Michael Str?der <michael at stroeder.com>
> wrote:
>
>> Peter Bengtsson wrote:
>> > I'm on OSX 10.11.3 and I installed python-ldap 2.4.25 with pip in a
>> > virtualenv. And I always get this error:
>> >
>> >>>> import ldap
>> >>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, '/path/to.crt')
>> > Traceback (most recent call last):
>> >   File "<stdin>", line 1, in <module>
>> >   File
>> >
>> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
>> > line 133, in set_option
>> >     return _ldap_function_call(None,_ldap.set_option,option,invalue)
>> >   File
>> >
>> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
>> > line 64, in _ldap_function_call
>> >     result = func(*args,**kwargs)
>> > ValueError: option error
>>
>> Most times this happens if the cert file does not exist.
>>
>>
> Wouldn't/Shouldn't that yield a IOError then if it tries to read a file
> that doesn't exist?
>
> Either way, see:
>
> (medlem) :~/dev/MOZILLA/MEDLEM/ldap-bind/medlem$ ls -l
> total 40
> -rw-r--r--  1 peterbe  staff    64 Feb  4 11:48 bind_credentials.txt
> -rw-r--r--  1 peterbe  staff  4676 Feb  4 11:46 ldapproxy-medlem.crt
> -rw-r--r--  1 peterbe  staff  1188 Feb  4 11:46 ldapproxy-medlem.csr
> -rw-r--r--  1 peterbe  staff  1675 Feb  4 11:46 ldapproxy-medlem.key
>
> (medlem) :~/dev/MOZILLA/MEDLEM/ldap-bind/medlem$ python
> Python 2.7.11 (default, Jan 20 2016, 12:30:21)
> [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> assert os.path.isfile('ldapproxy-medlem.crt')
> >>> import ldap
> >>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, 'ldapproxy-medlem.crt')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 133, in set_option
>     return _ldap_function_call(None,_ldap.set_option,option,invalue)
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 64, in _ldap_function_call
>     result = func(*args,**kwargs)
> ValueError: option error
> >>>
>
>
> The file clearly exists.
>
>
>> > It doesn't matter what the value of that option is.
>> > It does not happen when installed on Ubuntu.
>>
>> Hmm.
>>
>> > Axel here, http://stackoverflow.com/a/29101851/205832 said he managed
>> to
>> > make the problem go away by downloading the tarball and adding
>> /usr/local
>> > to setup.cfg. That did not help for me.
>>
>> That sounds like a strange solution to me. But I have no personal
>> experience
>> with with Max OS X.
>>
>> Ciao, Michael.
>>
>> P.S.: Please subscribe to the low-traffic python-ldap mailing list. So
>> all the
>> answers really reach you.
>>
>>
> I am subscribed.
>
>
> --
> Peter Bengtsson
> Mozilla Tools & Services
>



-- 
Peter Bengtsson
Mozilla Tools & Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160206/cf954ae5/attachment.html>

From michael at stroeder.com  Sun Feb  7 10:31:42 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sun, 7 Feb 2016 16:31:42 +0100
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
Message-ID: <56B7635E.8010108@stroeder.com>

Peter Bengtsson wrote:
>> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
>>> line 64, in _ldap_function_call
>>>     result = func(*args,**kwargs)
>>> ValueError: option error
>>
>> Most times this happens if the cert file does not exist.
>
> Wouldn't/Shouldn't that yield a IOError then if it tries to read a file
> that doesn't exist?

The option values are all directly passed to OpenLDAP's libldap which does not
know about Python's IOError exception. Also actual use of the options within
libldap is lazy. Which means the error occurs when you send the first real LDAP
operation through a LDAPObject instance.

>>>> import os
>>>> assert os.path.isfile('ldapproxy-medlem.crt')
>>>> import ldap
>>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, 'ldapproxy-medlem.crt')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 133, in set_option
>     return _ldap_function_call(None,_ldap.set_option,option,invalue)
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 64, in _ldap_function_call
>     result = func(*args,**kwargs)
> ValueError: option error
>
> The file clearly exists.

Hmm, did you also try the same with the full path name?

Anyway I'm on Linux and therefore cannot comment on any specific things
regarding the Mac OS X installations.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160207/86274eb8/attachment.bin>

From pbengtsson at mozilla.com  Mon Feb  8 08:49:54 2016
From: pbengtsson at mozilla.com (Peter Bengtsson)
Date: Mon, 8 Feb 2016 08:49:54 -0500
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <56B7635E.8010108@stroeder.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
 <56B7635E.8010108@stroeder.com>
Message-ID: <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>

On Sun, Feb 7, 2016 at 10:31 AM, Michael Str?der <michael at stroeder.com>
wrote:

> Peter Bengtsson wrote:
> >>
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> >>> line 64, in _ldap_function_call
> >>>     result = func(*args,**kwargs)
> >>> ValueError: option error
> >>
> >> Most times this happens if the cert file does not exist.
> >
> > Wouldn't/Shouldn't that yield a IOError then if it tries to read a file
> > that doesn't exist?
>
> The option values are all directly passed to OpenLDAP's libldap which does
> not
> know about Python's IOError exception. Also actual use of the options
> within
> libldap is lazy. Which means the error occurs when you send the first real
> LDAP
> operation through a LDAPObject instance.
>
>
I can set other options. For example,

>>> import ldap
>>> ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_DEMAND)
>>> ldap.set_option(ldap.OPT_DEBUG_LEVEL, 4095)
>>>


> >>>> import os
> >>>> assert os.path.isfile('ldapproxy-medlem.crt')
> >>>> import ldap
> >>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, 'ldapproxy-medlem.crt')
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> >   File
> >
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> > line 133, in set_option
> >     return _ldap_function_call(None,_ldap.set_option,option,invalue)
> >   File
> >
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> > line 64, in _ldap_function_call
> >     result = func(*args,**kwargs)
> > ValueError: option error
> >
> > The file clearly exists.
>
> Hmm, did you also try the same with the full path name?
>
>
>>> import os
>>> os.path.isfile('ldapproxy-medlem.crt')
True
>>> os.path.abspath('ldapproxy-medlem.crt')
'/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'
>>> import ldap
>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE,
'/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 133, in set_option
    return _ldap_function_call(None,_ldap.set_option,option,invalue)
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 64, in _ldap_function_call
    result = func(*args,**kwargs)
ValueError: option error
>>>



> Anyway I'm on Linux and therefore cannot comment on any specific things
> regarding the Mac OS X installations.
>
>
I wonder if there's a way to enable more debug or tracing to get a more
descriptive error. It could very well be that the there's something wrong
with the file. For example, its chmod. Or the fact that it starts with...:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9 (0x9)
    Signature Algorithm: sha1WithRSAEncryption
  ...

and not...:
-----BEGIN CERTIFICATE-----
MIIEETCCAvmgAwIBAgIBCTANBgkq...



-- 
Peter Bengtsson
Mozilla Tools & Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160208/992ce53a/attachment.html>

From michael at stroeder.com  Mon Feb  8 12:01:05 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 8 Feb 2016 18:01:05 +0100
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
 <56B7635E.8010108@stroeder.com>
 <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>
Message-ID: <56B8C9D1.8050302@stroeder.com>

Peter Bengtsson wrote:
> I wonder if there's a way to enable more debug or tracing to get a more
> descriptive error.

Please examine Demo/initialize.py to see how to turn on python-ldap's internal
trace log and/or libldap's debug log.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160208/59b75c2a/attachment.bin>

From pbengtsson at mozilla.com  Mon Feb  8 14:05:05 2016
From: pbengtsson at mozilla.com (Peter Bengtsson)
Date: Mon, 8 Feb 2016 14:05:05 -0500
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <56B8C9D1.8050302@stroeder.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
 <56B7635E.8010108@stroeder.com>
 <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>
 <56B8C9D1.8050302@stroeder.com>
Message-ID: <CALTBac1Rn9+8LTdGEVuoLi-JcO2-xz7RDrDBRCQiJUqyybYC6w@mail.gmail.com>

On Mon, Feb 8, 2016 at 12:01 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Peter Bengtsson wrote:
> > I wonder if there's a way to enable more debug or tracing to get a more
> > descriptive error.
>
> Please examine Demo/initialize.py to see how to turn on python-ldap's
> internal
> trace log and/or libldap's debug log.
>
>
The error happens before initialize, but I played with setting _trace_level

>>> import ldap
>>> ldap._trace_level = 7
>>>
CACERTFILE='/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'
>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
*** _ldap.set_option ((24578,

'/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'),
 {})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 133, in set_option
    return _ldap_function_call(None,_ldap.set_option,option,invalue)
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 64, in _ldap_function_call
    result = func(*args,**kwargs)
ValueError: option error




> Ciao, Michael.
>
>
>


-- 
Peter Bengtsson
Mozilla Tools & Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160208/0385031e/attachment.html>

From michael at stroeder.com  Tue Feb  9 04:03:06 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 9 Feb 2016 10:03:06 +0100
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <CALTBac1Rn9+8LTdGEVuoLi-JcO2-xz7RDrDBRCQiJUqyybYC6w@mail.gmail.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
 <56B7635E.8010108@stroeder.com>
 <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>
 <56B8C9D1.8050302@stroeder.com>
 <CALTBac1Rn9+8LTdGEVuoLi-JcO2-xz7RDrDBRCQiJUqyybYC6w@mail.gmail.com>
Message-ID: <56B9AB4A.1080108@stroeder.com>

Peter Bengtsson wrote:
> The error happens before initialize, but I played with setting _trace_level
> 
>>>> import ldap
>>>> ldap._trace_level = 7
>>>>
> CACERTFILE='/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'
>>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
> *** _ldap.set_option ((24578,
> 
> '/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'),
>  {})
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 133, in set_option
>     return _ldap_function_call(None,_ldap.set_option,option,invalue)
>   File
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> line 64, in _ldap_function_call
>     result = func(*args,**kwargs)
> ValueError: option error

Note that python-ldap's tracing only logs the Python API calls.

In this particular case it'd be more helpful to enable libldap's own logging
like this:

ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160209/fa124dc4/attachment-0001.bin>

From jephte.clain at univ-reunion.fr  Tue Feb  9 05:31:22 2016
From: jephte.clain at univ-reunion.fr (Jephte Clain)
Date: Tue, 09 Feb 2016 14:31:22 +0400
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <56B9AB4A.1080108@stroeder.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
 <56B7635E.8010108@stroeder.com>
 <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>
 <56B8C9D1.8050302@stroeder.com>
 <CALTBac1Rn9+8LTdGEVuoLi-JcO2-xz7RDrDBRCQiJUqyybYC6w@mail.gmail.com>
 <56B9AB4A.1080108@stroeder.com>
Message-ID: <56B9BFFA.7040705@univ-reunion.fr>

Le 09/02/2016 13:03, Michael Str?der a ?crit :
>
> Note that python-ldap's tracing only logs the Python API calls.
>
> In this particular case it'd be more helpful to enable libldap's own logging
> like this:
>
> ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
>
> Ciao, Michael.
>
Hello,

when debugging is enabled this way, where are the log written? I guess 
stderr but I didn't find the info in the docs.
Is it possible to choose another fd to write the logs to?

thanks in advance, regards,
Jepht? CLAIN

-- 
*Jepht? CLAIN | D?veloppeur, Int?grateur d'applications*
Service Syst?mes d'Information
Direction des Syst?mes d'Information <http://dsi.univ-reunion.fr>
T?l: +262 262 93 86 31 <tel:+262262938631> || Gsm: +262 692 29 58 24 
<tel:+262692295824>
www.univ-reunion.fr <http://www.univ-reunion.fr> || Facebook 
<http://www.facebook.com/pages/Universit%C3%A9-de-La-R%C3%A9union-OFFICIEL/197176816990430> 
|| Twitter <http://twitter.com/univ_reunion>

From michael at stroeder.com  Tue Feb  9 06:59:26 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 9 Feb 2016 12:59:26 +0100
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <56B9BFFA.7040705@univ-reunion.fr>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
 <56B7635E.8010108@stroeder.com>
 <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>
 <56B8C9D1.8050302@stroeder.com>
 <CALTBac1Rn9+8LTdGEVuoLi-JcO2-xz7RDrDBRCQiJUqyybYC6w@mail.gmail.com>
 <56B9AB4A.1080108@stroeder.com> <56B9BFFA.7040705@univ-reunion.fr>
Message-ID: <56B9D49E.3050503@stroeder.com>

Jephte Clain wrote:
> Le 09/02/2016 13:03, Michael Str?der a ?crit :
>>
>> Note that python-ldap's tracing only logs the Python API calls.
>>
>> In this particular case it'd be more helpful to enable libldap's own logging
>> like this:
>>
>> ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
> 
> when debugging is enabled this way, where are the log written?

Good question.

> I guess stderr

Yes. Note that with OpenLDAP command-line tools you use -d to specify the same
debug level and redirecting stderr to /dev/null suppresses the debug log on the
console:

ldapsearch -d 255 [..some args..] > /dev/null

> but I didn't find the info in the docs.

Hmm, I tried to find some information in the OpenLDAP man pages but there seems
to be none.

> Is it possible to choose another fd to write the logs to?

I don't think so.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160209/5562a172/attachment.bin>

From pbengtsson at mozilla.com  Tue Feb  9 07:19:39 2016
From: pbengtsson at mozilla.com (Peter Bengtsson)
Date: Tue, 9 Feb 2016 07:19:39 -0500
Subject: [python-ldap] ValueError: option error on trying to set
 OPT_X_TLS_CACERTFILE
In-Reply-To: <56B9AB4A.1080108@stroeder.com>
References: <CALTBac2bqvTzseG9XFn-4u=3MaXm9sYeTOw+8A+xnG3asmh5cQ@mail.gmail.com>
 <56B44BEC.90006@stroeder.com>
 <CALTBac15+MeVqCV7N3goMBuwGYFKW=Sh786SoiuPVYECo0vg_g@mail.gmail.com>
 <CALTBac3=8Ny=EbeJuziP6Km1_WMJuHr0suvKdRCTSxpgKMqimw@mail.gmail.com>
 <56B7635E.8010108@stroeder.com>
 <CALTBac332DzpWGa-AOZ2D3L8geuka6cO9DJbAUKemCMWk2U=TA@mail.gmail.com>
 <56B8C9D1.8050302@stroeder.com>
 <CALTBac1Rn9+8LTdGEVuoLi-JcO2-xz7RDrDBRCQiJUqyybYC6w@mail.gmail.com>
 <56B9AB4A.1080108@stroeder.com>
Message-ID: <CALTBac2mtdGMqEwU0Mo3vfEtu5OFO=MAA4uYYBS32e0XcYFB+A@mail.gmail.com>

On Tue, Feb 9, 2016 at 4:03 AM, Michael Str?der <michael at stroeder.com>
wrote:

> Peter Bengtsson wrote:
> > The error happens before initialize, but I played with setting
> _trace_level
> >
> >>>> import ldap
> >>>> ldap._trace_level = 7
> >>>>
> >
> CACERTFILE='/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'
> >>>> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
> > *** _ldap.set_option ((24578,
> >
> >
> '/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'),
> >  {})
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> >   File
> >
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> > line 133, in set_option
> >     return _ldap_function_call(None,_ldap.set_option,option,invalue)
> >   File
> >
> "/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
> > line 64, in _ldap_function_call
> >     result = func(*args,**kwargs)
> > ValueError: option error
>
> Note that python-ldap's tracing only logs the Python API calls.
>
> In this particular case it'd be more helpful to enable libldap's own
> logging
> like this:
>
> ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
>
>
No luck :(

(medlem) :~/dev/MOZILLA/MEDLEM/ldap-bind/medlem$ cat test.py
import ldap
ldap.set_option(ldap.OPT_DEBUG_LEVEL,255)
CACERTFILE='/Users/peterbe/dev/MOZILLA/MEDLEM/ldap-bind/medlem/ldapproxy-medlem.crt'
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
(medlem) :~/dev/MOZILLA/MEDLEM/ldap-bind/medlem$ python test.py
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 133, in set_option
    return _ldap_function_call(None,_ldap.set_option,option,invalue)
  File
"/Users/peterbe/virtualenvs/medlem/lib/python2.7/site-packages/python_ldap-2.4.25-py2.7-macosx-10.11-x86_64.egg/ldap/functions.py",
line 64, in _ldap_function_call
    result = func(*args,**kwargs)
ValueError: option error

Nothing comes out on stderr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160209/cd843792/attachment.html>

From william at blackhats.net.au  Wed Feb 17 23:58:04 2016
From: william at blackhats.net.au (William)
Date: Thu, 18 Feb 2016 14:58:04 +1000
Subject: [python-ldap] Modlist with a replace sometimes fails
Message-ID: <1455771484.19414.112.camel@blackhats.net.au>

Hi,

I noticed that the code for modlist does the following:

line 111:?
? ? ? if replace_attr_value:
? ? ? ? modlist.append((ldap.MOD_DELETE,attrtype,None))
? ? ? ? modlist.append((ldap.MOD_ADD,attrtype,new_value))

This often fails on certain ldap servers, especially with configuration
directives as they cannot be removed before the add takes place.

I would like to ask that either this be fixed to:

line 111:?
? ? ? if replace_attr_value:
????????modlist.append((ldap.MOD_REPLACE,attrtype,new_value))

Or if there is a reason to distinguish this behaviour than a boolean or int flag
in the modlist signature be added similar to the?ignore_oldexistent=0 flag. IE
replace_is_add_delete=True/False. This way Administrators can control the
behaviour.


Thanks!


-- 
William <william at blackhats.net.au>


From michael at stroeder.com  Thu Feb 18 03:30:30 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 18 Feb 2016 09:30:30 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <1455771484.19414.112.camel@blackhats.net.au>
References: <1455771484.19414.112.camel@blackhats.net.au>
Message-ID: <56C58126.2070007@stroeder.com>

William wrote:
> I noticed that the code for modlist does the following:
> 
> line 111: 
>       if replace_attr_value:
>         modlist.append((ldap.MOD_DELETE,attrtype,None))
>         modlist.append((ldap.MOD_ADD,attrtype,new_value))
> 
> This often fails on certain ldap servers, especially with configuration
> directives as they cannot be removed before the add takes place.

Could you please give more details:
- LDAP server vendor and exact version
- attribute for which this fails

> I would like to ask that either this be fixed to:
> 
> line 111: 
>       if replace_attr_value:
>         modlist.append((ldap.MOD_REPLACE,attrtype,new_value))

It's probably time to add that to the FAQ:

https://mail.python.org/pipermail/python-ldap/2008q3/002342.html

Note that you don't have to use ldap.modlist.modifyModlist() and your
application can generate your own modlist when tweaking special attributes.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160218/acfa7655/attachment.bin>

From jephte.clain at univ-reunion.fr  Thu Feb 18 06:45:07 2016
From: jephte.clain at univ-reunion.fr (Jephte Clain)
Date: Thu, 18 Feb 2016 15:45:07 +0400
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <56C58126.2070007@stroeder.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
Message-ID: <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>

hello,
just chiming in to check that I understand correctly...

2016-02-18 12:30 GMT+04:00 Michael Str?der <michael at stroeder.com>:
> William wrote:
>> I noticed that the code for modlist does the following:
>>
>> line 111:
>>       if replace_attr_value:
>>         modlist.append((ldap.MOD_DELETE,attrtype,None))
>>         modlist.append((ldap.MOD_ADD,attrtype,new_value))
>>
>> This often fails on certain ldap servers, especially with configuration
>> directives as they cannot be removed before the add takes place.
>
> Could you please give more details:
> - LDAP server vendor and exact version
> - attribute for which this fails
>
>> I would like to ask that either this be fixed to:
>>
>> line 111:
>>       if replace_attr_value:
>>         modlist.append((ldap.MOD_REPLACE,attrtype,new_value))
>
> It's probably time to add that to the FAQ:
>
> https://mail.python.org/pipermail/python-ldap/2008q3/002342.html

Are you saying that

dn: xxx
changetype: modify
replace: attr
attr: value

requires attr to have an equality matching rule? why not, I mean one
don't care what the previous value is as it is replaced???
Or did I fail to understand properly?

FYI, on OpenLDAP, under the cn=config database, there are some
attributes that a required to exist. You can't just delete then add
them: you have to replace them.
But indeed, I have never seen such a behavior on a "regular" database.

have a good day, regards,
Jepht? CLAIN

>
> Note that you don't have to use ldap.modlist.modifyModlist() and your
> application can generate your own modlist when tweaking special attributes.
>

-- 
Jepht? CLAIN | D?veloppeur, Int?grateur d'applications
Service Syst?me d'Information
Direction des Syst?mes d'Information
T?l: +262 262 93 86 31 || Gsm: +262 692 29 58 24

From michael at stroeder.com  Thu Feb 18 07:32:56 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 18 Feb 2016 13:32:56 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
Message-ID: <56C5B9F8.7010000@stroeder.com>

Jephte Clain wrote:
> hello,
> just chiming in to check that I understand correctly...
> 
> 2016-02-18 12:30 GMT+04:00 Michael Str?der <michael at stroeder.com>:
>> William wrote:
>>> I noticed that the code for modlist does the following:
>>>
>>> line 111:
>>>       if replace_attr_value:
>>>         modlist.append((ldap.MOD_DELETE,attrtype,None))
>>>         modlist.append((ldap.MOD_ADD,attrtype,new_value))
>>>
>>> This often fails on certain ldap servers, especially with configuration
>>> directives as they cannot be removed before the add takes place.
>>
>> Could you please give more details:
>> - LDAP server vendor and exact version
>> - attribute for which this fails
>>
>>> I would like to ask that either this be fixed to:
>>>
>>> line 111:
>>>       if replace_attr_value:
>>>         modlist.append((ldap.MOD_REPLACE,attrtype,new_value))
>>
>> It's probably time to add that to the FAQ:
>>
>> https://mail.python.org/pipermail/python-ldap/2008q3/002342.html
> 
> Are you saying that
> 
> dn: xxx
> changetype: modify
> replace: attr
> attr: value
> 
> requires attr to have an equality matching rule?

Yes. There's reason why ldap.modlist.modifyModlist() works like this. Actually I
used ldap.MOD_REPLACE in older versions but this did not work. So I've changed
it many years ago:

http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/modlist.py?r1=1.4&r2=1.5

> why not, I mean one
> don't care what the previous value is as it is replaced???

It does not matter what you or I consider to be reasonable.
What counts is how LDAP servers process the modify requests.

> FYI, on OpenLDAP, under the cn=config database, there are some
> attributes that a required to exist.

This should be no issue.

> You can't just delete then add
> them: you have to replace them.

I have some doubts.

Please give more details:
- OpenLDAP version
- *exact* modify operation
- *exact* error message
- preferrably test code illustrating the issue

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160218/13543f84/attachment-0001.bin>

From william at blackhats.net.au  Thu Feb 18 18:23:39 2016
From: william at blackhats.net.au (William)
Date: Fri, 19 Feb 2016 09:23:39 +1000
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <56C5B9F8.7010000@stroeder.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com>
Message-ID: <1455837819.19414.139.camel@blackhats.net.au>


> Please give more details:
> - OpenLDAP version
> - *exact* modify operation
> - *exact* error message
> - preferrably test code illustrating the issue

389-ds-1.3.5-git-master. The replace was replacing nsslapd-cachememsize on the
ldbm backend instance.

It rejects the op, because you can't delete the nsslapd-cachememsize, only
replace.

The issue is there are *many* attributes like this in cn=config on 389-ds that
can only be replaced, and block deletes.

I propsed a patch to pyldap yesterday for this:


This leaves the *default* behaviour to be the current delete -> add method. It
adds a boolean flag to the operation allowing someone to select if they want to
use replace instead.?

The reason I do *not* want to manually craft the modlist is that would mean
practically re-implementing all of modlist, as our testing framework has an ldap
entry wrapper. I'm writing it to have a dict of data, then .save() to commit the
object based on modlist.modifyModlist(). Especially for handling our cn=config
entries, the ability to use mod_replace is vital.


diff --git a/Lib/ldap/modlist.py b/Lib/ldap/modlist.py
index 0053a3f..a56c3e5 100644
--- a/Lib/ldap/modlist.py
+++ b/Lib/ldap/modlist.py
@@ -49,7 +49,7 @@ def addModlist(entry,ignore_attr_types=None):
?
?
?def modifyModlist(
-??old_entry,new_entry,ignore_attr_types=None,ignore_oldexistent=0,case_ignore_at
tr_types=None
+??old_entry,new_entry,ignore_attr_types=None,ignore_oldexistent=0,case_ignore_at
tr_types=None,replace_is_add_then_delete=True
?):
???"""
???Build differential modify list for calling LDAPObject.modify()/modify_s()
@@ -69,6 +69,10 @@ def modifyModlist(
???case_ignore_attr_types
???????List of attribute type names for which comparison will be made
???????case-insensitive
+??replace_is_add_then_delete
+??????Determines if a replace operation is carried out as add then delete
+??????or if it is a pure ldap replace. This can have behavioural affects on
+??????certain ldap servers and object types IE configuration directories.
???"""
???ignore_attr_types = list_dict(map(lower,(ignore_attr_types or [])))
???case_ignore_attr_types = list_dict(map(lower,(case_ignore_attr_types or [])))
@@ -111,8 +115,11 @@ def modifyModlist(
???????????????replace_attr_value = 1
???????????????break
???????if replace_attr_value:
-????????modlist.append((ldap.MOD_DELETE,attrtype,None))
-????????modlist.append((ldap.MOD_ADD,attrtype,new_value))
+????????if replace_is_add_then_delete:
+??????????modlist.append((ldap.MOD_DELETE,attrtype,None))
+??????????modlist.append((ldap.MOD_ADD,attrtype,new_value))
+????????else:
+??????????modlist.append((ldap.MOD_REPLACE,attrtype,new_value))
?????elif old_value and not new_value:
???????# Completely delete an existing attribute
???????modlist.append((ldap.MOD_DELETE,attrtype,None))


-- 
William <william at blackhats.net.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160219/946fc8d1/attachment.sig>

From michael at stroeder.com  Fri Feb 19 02:05:10 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 19 Feb 2016 08:05:10 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <1455837819.19414.139.camel@blackhats.net.au>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com> <1455837819.19414.139.camel@blackhats.net.au>
Message-ID: <56C6BEA6.9060909@stroeder.com>

William wrote:
>> Please give more details:
>> - OpenLDAP version
>> - *exact* modify operation
>> - *exact* error message
>> - preferrably test code illustrating the issue
> 
> 389-ds-1.3.5-git-master. The replace was replacing nsslapd-cachememsize on the
> ldbm backend instance.

Which error message did 389-DS return?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160219/f3bbc7c5/attachment.bin>

From michael at stroeder.com  Tue Feb 23 15:46:08 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 23 Feb 2016 21:46:08 +0100
Subject: [python-ldap] State of Mac OS X support
Message-ID: <56CCC510.4080208@stroeder.com>

HI!

What's the current state of running python-ldap on Mac OS X?

The download page still links to a receipt for compiling libldap separately.

Is that still state-of-the-art?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160223/cc9fbf1c/attachment.bin>

From michael at stroeder.com  Tue Feb 23 15:54:46 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 23 Feb 2016 21:54:46 +0100
Subject: [python-ldap] HTTPS etc.
Message-ID: <56CCC716.2060401@stroeder.com>

HI!

Some of you might have noticed that python-ldap.org web site moved, especially
to make it accessible via HTTPS.
FWIW: I also updated many links to reference HTTPS instead of HTTP.

I know, the stylesheet still needs some love. So do not comment on that for now.
But please report false information, HTML markup errors, and dead links.

Ciao, Michael.


From michael at stroeder.com  Tue Feb 23 15:51:03 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Tue, 23 Feb 2016 21:51:03 +0100
Subject: [python-ldap] Overhauling FAQ
Message-ID: <56CCC637.2000508@stroeder.com>

HI!

Looking at the python-ldap FAQ most items in there are not relevant anymore.
Therefore I'm inclined to drop (almost) all of them.

What do you think?

Contributions of currently interesting Q&A welcome.

Ciao, Michael.


From mailinglist0 at skurfer.com  Tue Feb 23 21:05:45 2016
From: mailinglist0 at skurfer.com (Rob McBroom)
Date: Tue, 23 Feb 2016 21:05:45 -0500
Subject: [python-ldap] State of Mac OS X support
In-Reply-To: <56CCC510.4080208@stroeder.com>
References: <56CCC510.4080208@stroeder.com>
Message-ID: <2265F905-B18E-4DE8-BF59-CF0B4E8FEB37@skurfer.com>

On 23 Feb 2016, at 15:46, Michael Str?der wrote:

> What's the current state of running python-ldap on Mac OS X?
>
> The download page still links to a receipt for compiling libldap 
> separately.
>
> Is that still state-of-the-art?

I wrote that. It was true for 10.7, but 10.8 and everything after have 
worked as expected. That is, you can just install the package normally 
(assuming you have the dev tools installed).

I mentioned that, but maybe you missed it. :-)

http://projects.skurfer.com/posts/2011/python_ldap_lion/#comment-623977984

-- 
Rob McBroom
http://www.skurfer.com/

From hahn at univention.de  Wed Feb 24 01:33:08 2016
From: hahn at univention.de (Philipp Hahn)
Date: Wed, 24 Feb 2016 07:33:08 +0100
Subject: [python-ldap] HTTPS etc.
In-Reply-To: <56CCC716.2060401@stroeder.com>
References: <56CCC716.2060401@stroeder.com>
Message-ID: <56CD4EA4.1070005@univention.de>

Hello,

Am 23.02.2016 um 21:54 schrieb Michael Str?der:
> Some of you might have noticed that python-ldap.org web site moved, especially
> to make it accessible via HTTPS.

As you seem to spend time on the infrastructure, what about moving from
CVS to some distributed VCS, preferable git?

Philipp

From michael at stroeder.com  Wed Feb 24 04:04:02 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 24 Feb 2016 10:04:02 +0100
Subject: [python-ldap] State of Mac OS X support
In-Reply-To: <2265F905-B18E-4DE8-BF59-CF0B4E8FEB37@skurfer.com>
References: <56CCC510.4080208@stroeder.com>
 <2265F905-B18E-4DE8-BF59-CF0B4E8FEB37@skurfer.com>
Message-ID: <56CD7202.2080603@stroeder.com>

Rob McBroom wrote:
> On 23 Feb 2016, at 15:46, Michael Str?der wrote:
> 
>> What's the current state of running python-ldap on Mac OS X?
>>
>> The download page still links to a receipt for compiling libldap separately.
>>
>> Is that still state-of-the-art?
> 
> I wrote that. It was true for 10.7, but 10.8 and everything after have worked as
> expected. That is, you can just install the package normally (assuming you have
> the dev tools installed).
> 
> I mentioned that, but maybe you missed it. :-)
> 
> http://projects.skurfer.com/posts/2011/python_ldap_lion/#comment-623977984

I usually ignore even blog posts. But blog comments I never read.

I'm not familiar with Mac OS X at all and never will be.
Therefore it would be nice if you contribute a small text summarizing the
current situation to be added on the download page.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160224/3aca3be3/attachment-0001.bin>

From michael at stroeder.com  Wed Feb 24 04:05:03 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 24 Feb 2016 10:05:03 +0100
Subject: [python-ldap] HTTPS etc.
In-Reply-To: <56CD4EA4.1070005@univention.de>
References: <56CCC716.2060401@stroeder.com> <56CD4EA4.1070005@univention.de>
Message-ID: <56CD723F.1080101@stroeder.com>

Philipp Hahn wrote:
> Hello,
> 
> Am 23.02.2016 um 21:54 schrieb Michael Str?der:
>> Some of you might have noticed that python-ldap.org web site moved, especially
>> to make it accessible via HTTPS.
> 
> As you seem to spend time on the infrastructure, what about moving from
> CVS to some distributed VCS,

baby steps...

> preferable git?

mercurial...

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160224/6f8b13d9/attachment.bin>

From mailinglist0 at skurfer.com  Wed Feb 24 07:38:07 2016
From: mailinglist0 at skurfer.com (Rob McBroom)
Date: Wed, 24 Feb 2016 07:38:07 -0500
Subject: [python-ldap] State of Mac OS X support
In-Reply-To: <56CD7202.2080603@stroeder.com>
References: <56CCC510.4080208@stroeder.com>
 <2265F905-B18E-4DE8-BF59-CF0B4E8FEB37@skurfer.com>
 <56CD7202.2080603@stroeder.com>
Message-ID: <2085313A-B5A4-4337-A57C-63BF541DFFEC@skurfer.com>

On 24 Feb 2016, at 4:04, Michael Str?der wrote:

> I usually ignore even blog posts. But blog comments I never read.

I have a browser plug-in called ?Shut Up!? that does its best to 
hide comments on every site. :-)

> Therefore it would be nice if you contribute a small text summarizing 
> the
> current situation to be added on the download page.

You can just use PyPI with setuptools, as recommended at the top of the 
page, but you?ll probably want a note about the prerequisites since it 
won?t work out of the box.

For that, I would just recreate the third bullet-point from Homebrew?s 
docs:

https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Installation.md#requirements

-- 
Rob McBroom
http://www.skurfer.com/

From michael at stroeder.com  Wed Feb 24 08:22:30 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 24 Feb 2016 14:22:30 +0100
Subject: [python-ldap] State of Mac OS X support
In-Reply-To: <2085313A-B5A4-4337-A57C-63BF541DFFEC@skurfer.com>
References: <56CCC510.4080208@stroeder.com>
 <2265F905-B18E-4DE8-BF59-CF0B4E8FEB37@skurfer.com>
 <56CD7202.2080603@stroeder.com>
 <2085313A-B5A4-4337-A57C-63BF541DFFEC@skurfer.com>
Message-ID: <56CDAE96.3030202@stroeder.com>

Rob McBroom wrote:
> On 24 Feb 2016, at 4:04, Michael Str?der wrote:
> 
>> I usually ignore even blog posts. But blog comments I never read.
> 
> I have a browser plug-in called ?Shut Up!? that does its best to hide comments
> on every site. :-)
> 
>> Therefore it would be nice if you contribute a small text summarizing the
>> current situation to be added on the download page.
> 
> You can just use PyPI with setuptools, as recommended at the top of the page,
> but you?ll probably want a note about the prerequisites since it won?t work out
> of the box.
> 
> For that, I would just recreate the third bullet-point from Homebrew?s docs:
> 
> https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Installation.md#requirements

Please let us be more precise since I'm not familiar with all those terms:

Are you referring to this text?

"Command Line Tools for Xcode: xcode-select --install,
https://developer.apple.com/downloads or Xcode 3"

Or is the whole homebrew system needed?

Would a sentence like "install xcode and then install via pip" summarize it?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160224/62a562be/attachment.bin>

From mailinglist0 at skurfer.com  Wed Feb 24 08:53:27 2016
From: mailinglist0 at skurfer.com (Rob McBroom)
Date: Wed, 24 Feb 2016 08:53:27 -0500
Subject: [python-ldap] State of Mac OS X support
In-Reply-To: <56CDAE96.3030202@stroeder.com>
References: <56CCC510.4080208@stroeder.com>
 <2265F905-B18E-4DE8-BF59-CF0B4E8FEB37@skurfer.com>
 <56CD7202.2080603@stroeder.com>
 <2085313A-B5A4-4337-A57C-63BF541DFFEC@skurfer.com>
 <56CDAE96.3030202@stroeder.com>
Message-ID: <00EE5C9A-E665-49A1-AE43-7A352A748BD5@skurfer.com>

On 24 Feb 2016, at 8:22, Michael Str?der wrote:

> Are you referring to this text?
>
> "Command Line Tools for Xcode: xcode-select --install,
> https://developer.apple.com/downloads or Xcode 3"

Yes.

> Or is the whole homebrew system needed?

No, Homebrew is not needed. I just knew they would have a good summary 
of what you *do* need.

> Would a sentence like "install xcode and then install via pip" 
> summarize it?

Technically, yes.

But it might be nice to let people know they don?t necessarily need 
the multi-gigabyte Xcode IDE. If all you?re doing is Python stuff, you 
probably only need what they call the Command Line Tools, which can be 
installed with `xcode-select --install`.

Maybe you should just say something like ?Set up a suitable 
development environment by running `xcode-select --install`. When 
that?s done, you can install Python-LDAP from PyPI.?

People that need the full-blown Xcode can probably figure out how to get 
it, and it doesn?t conflict with the Command Line Tools, so it won?t 
hurt if they install both.

-- 
Rob McBroom
http://www.skurfer.com/

From jdennis at redhat.com  Wed Feb 24 08:49:51 2016
From: jdennis at redhat.com (John Dennis)
Date: Wed, 24 Feb 2016 08:49:51 -0500
Subject: [python-ldap] HTTPS etc.
In-Reply-To: <56CD723F.1080101@stroeder.com>
References: <56CCC716.2060401@stroeder.com> <56CD4EA4.1070005@univention.de>
 <56CD723F.1080101@stroeder.com>
Message-ID: <56CDB4FF.7050707@redhat.com>

On 02/24/2016 04:05 AM, Michael Str?der wrote:
> Philipp Hahn wrote:
>> Hello,
>>
>> Am 23.02.2016 um 21:54 schrieb Michael Str?der:
>>> Some of you might have noticed that python-ldap.org web site moved, especially
>>> to make it accessible via HTTPS.
>>
>> As you seem to spend time on the infrastructure, what about moving from
>> CVS to some distributed VCS,
>
> baby steps...
>
>> preferable git?
>
> mercurial...

As the project leader it's your choice but I would strongly encourage 
git over mercurial. Why? The vast majority of open source projects I 
work with use git, mercurial is the odd exception. That means git is 
familiar, comfortable and enjoys a wide array of 3rd party tools. Every 
time I have to work with mercurial I get stuck because nothing is 
familiar. Not sure how others feel but I would prefer to be an expert in 
only one source code control system.

-- 
John

From michael at stroeder.com  Wed Feb 24 09:01:30 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 24 Feb 2016 15:01:30 +0100
Subject: [python-ldap] State of Mac OS X support
In-Reply-To: <00EE5C9A-E665-49A1-AE43-7A352A748BD5@skurfer.com>
References: <56CCC510.4080208@stroeder.com>
 <2265F905-B18E-4DE8-BF59-CF0B4E8FEB37@skurfer.com>
 <56CD7202.2080603@stroeder.com>
 <2085313A-B5A4-4337-A57C-63BF541DFFEC@skurfer.com>
 <56CDAE96.3030202@stroeder.com>
 <00EE5C9A-E665-49A1-AE43-7A352A748BD5@skurfer.com>
Message-ID: <56CDB7BA.6090609@stroeder.com>

Rob McBroom wrote:
> Set up a suitable development environment by running `xcode-select --install`.
> When that?s done, you can install Python-LDAP from PyPI.

/bin/done

https://www.python-ldap.org/download.html#macosx

Thanks.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160224/c2daeba1/attachment.bin>

From mailinglist0 at skurfer.com  Wed Feb 24 09:15:08 2016
From: mailinglist0 at skurfer.com (Rob McBroom)
Date: Wed, 24 Feb 2016 09:15:08 -0500
Subject: [python-ldap] HTTPS etc.
In-Reply-To: <56CDB4FF.7050707@redhat.com>
References: <56CCC716.2060401@stroeder.com> <56CD4EA4.1070005@univention.de>
 <56CD723F.1080101@stroeder.com> <56CDB4FF.7050707@redhat.com>
Message-ID: <1912A776-9E73-4318-9524-BC780331A1C8@skurfer.com>

On 24 Feb 2016, at 8:49, John Dennis wrote:

> As the project leader it's your choice but I would strongly encourage 
> git over mercurial.

Many have said the same thing in the past, and I agree for what it?s 
worth.

Note that we?re just recommending Git, but not necessarily GitHub.

-- 
Rob McBroom
http://www.skurfer.com/

From bdauvergne at entrouvert.com  Wed Feb 24 09:25:50 2016
From: bdauvergne at entrouvert.com (Benjamin Dauvergne)
Date: Wed, 24 Feb 2016 15:25:50 +0100
Subject: [python-ldap] HTTPS etc.
In-Reply-To: <1912A776-9E73-4318-9524-BC780331A1C8@skurfer.com>
References: <56CCC716.2060401@stroeder.com> <56CD4EA4.1070005@univention.de>
 <56CD723F.1080101@stroeder.com> <56CDB4FF.7050707@redhat.com>
 <1912A776-9E73-4318-9524-BC780331A1C8@skurfer.com>
Message-ID: <20160224142550.GL19589@dor-lomin.entrouvert.com>

Le 02/24, Rob McBroom a ?crit :
> On 24 Feb 2016, at 8:49, John Dennis wrote:
> 
> >As the project leader it's your choice but I would strongly encourage git
> >over mercurial.
> 
> Many have said the same thing in the past, and I agree for what it?s worth.
> 
> Note that we?re just recommending Git, but not necessarily GitHub.

+1

For what it's worth, OpenLDAP moved to git 5 years ago now :)

-- 
Benjamin Dauvergne - Tel Entrouvert: 01 43 35 01 35 - Tel perso: 01 84 16 24 53

From akshaymohit2001 at gmail.com  Mon Feb 29 11:27:17 2016
From: akshaymohit2001 at gmail.com (Akshay Mohit)
Date: Mon, 29 Feb 2016 21:57:17 +0530
Subject: [python-ldap] wx in Python 3.5
Message-ID: <CAHjzW_C+jjk69VzfCYx=cdLQtRY7Q_uPYvRN9zBM-hJi9XHfBA@mail.gmail.com>

Hi,

I wanted to install wx in Python 3.5.0
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32
bit (Intel)] on win32

I am getting the following error:-

C:\Users\makshay\AppData\Local\Programs\Python\Python35-32\Scripts>pip.exe
install --upgrade --trusted-host wxpython.org --pre -f
http://wxpython.org/Phoenix/snapshot-builds/ wxPython_Phoenix
Collecting wxPython-Phoenix
  Retrying (Retry(total=4, connect=None, read=None, redirect=None)) after
connection broken by
'ConnectTimeoutError(<pip._vendor.requests.packages.urllib3.connection.HTTPConnection
object at 0x037E3F10>, 'Connection to wxpython.org timed out. (connect
timeout=15)')': /Phoenix/snapshot-builds/
  Downloading
http://wxpython.org/Phoenix/snapshot-builds/wxPython_Phoenix-3.0.3.dev1927+e07098d.tar.gz
(41.1MB)
    100% |################################| 41.1MB 188kB/s
Installing collected packages: wxPython-Phoenix
  Running setup.py install for wxPython-Phoenix ... error
    Complete output from command
c:\users\makshay\appdata\local\programs\python\python35-32\python.exe -u -c
"import setuptools,
tokenize;__file__='C:\\Users\\makshay\\AppData\\Local\\Temp\\pip-build-yt8mmtg8\\wxPython-Phoenix\\setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))"
install --record
C:\Users\makshay\AppData\Local\Temp\pip-qi7hs2w7-record\install-record.txt
--single-version-externally-managed --compile:
    running install
    running build
    WARNING: Building this way assumes that all generated files have been
    generated already.  If that is not the case then use build.py directly
    to generate the source and perform the build stage.  You can use
    --skip-build with the bdist_* or install commands to avoid this
    message and the wxWidgets and Phoenix build steps in the future.

    c:\users\makshay\appdata\local\programs\python\python35-32\python.exe
-u build.py build
    Build using:
"c:\users\makshay\appdata\local\programs\python\python35-32\python.exe"
    3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32 bit
(Intel)]
    Python's architecture is 32bit
    cfg.VERSION: 3.0.3.dev1927+e07098d

    Running command: build
    Running command: build_wx
    Command
'"c:\users\makshay\appdata\local\programs\python\python35-32\python.exe" -c
"import distutils.msvc9compiler as msvc; mc = msvc.MSVCCompiler();
mc.initialize(); print(mc.cc)"' failed with exit code 1.
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File
"c:\users\makshay\appdata\local\programs\python\python35-32\lib\distutils\msvc9compiler.py",
line 374, in initialize
        vc_env = query_vcvarsall(VERSION, plat_spec)
      File
"c:\users\makshay\appdata\local\programs\python\python35-32\lib\distutils\msvc9compiler.py",
line 262, in query_vcvarsall
        raise DistutilsPlatformError("Unable to find vcvarsall.bat")
    distutils.errors.DistutilsPlatformError: Unable to find vcvarsall.bat
    Finished command: build_wx (0.152s)
    Finished command: build (0.152s)
    Command
'c:\users\makshay\appdata\local\programs\python\python35-32\python.exe -u
build.py build' failed with exit code 1.

    ----------------------------------------
Command
"c:\users\makshay\appdata\local\programs\python\python35-32\python.exe -u
-c "import setuptools,
tokenize;__file__='C:\\Users\\makshay\\AppData\\Local\\Temp\\pip-build-yt8mmtg8\\wxPython-Phoenix\\setup.py';exec(compile(getattr(tokenize,
'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))"
install --record
C:\Users\makshay\AppData\Local\Temp\pip-qi7hs2w7-record\install-record.txt
--single-version-externally-managed --compile" failed with error code 1 in
C:\Users\makshay\AppData\Local\Temp\pip-build-yt8mmtg8\wxPython-Phoenix

C:\Users\makshay\AppData\Local\Programs\Python\Python35-32\Scripts>

C:\Users\makshay\AppData\Local\Programs\Python\Python35-32\Scripts>pip
install -U --pre -f http://wxpython.org/Phoenix/snapshot-builds/
wxPython_Phoenix
Collecting wxPython-Phoenix
  The repository located at wxpython.org is not a trusted or secure host
and is being ignored. If this repository is available via HTTPS it is
recommended to use HTTPS instead, otherwise you may silence this warning
and allow it anyways with '--trusted-host wxpython.org'.
  Could not find a version that satisfies the requirement wxPython-Phoenix
(from versions: )
No matching distribution found for wxPython-Phoenix

Any help would be appreciated.

Thanks,
Akshay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160229/bb52eb89/attachment.html>

From michael at stroeder.com  Mon Feb 29 11:59:28 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 29 Feb 2016 17:59:28 +0100
Subject: [python-ldap] wx in Python 3.5
In-Reply-To: <CAHjzW_C+jjk69VzfCYx=cdLQtRY7Q_uPYvRN9zBM-hJi9XHfBA@mail.gmail.com>
References: <CAHjzW_C+jjk69VzfCYx=cdLQtRY7Q_uPYvRN9zBM-hJi9XHfBA@mail.gmail.com>
Message-ID: <56D478F0.3020905@stroeder.com>

Akshay Mohit wrote:
> I wanted to install wx in Python 3.5.0
> Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32
> bit (Intel)] on win32
> 
> I am getting the following error:-
> [..pip output snipped..]

Are you sure you posted to the right list?

1. python-ldap from https://python-ldap.org does not run with Python 3.

2. I did not see the substring "ldap" in your pip output at all.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160229/bb790efb/attachment.bin>

From akshaymohit2001 at gmail.com  Tue Mar  1 00:08:19 2016
From: akshaymohit2001 at gmail.com (Akshay Mohit)
Date: Tue, 1 Mar 2016 10:38:19 +0530
Subject: [python-ldap] wx in Python 3.5
In-Reply-To: <56D478F0.3020905@stroeder.com>
References: <CAHjzW_C+jjk69VzfCYx=cdLQtRY7Q_uPYvRN9zBM-hJi9XHfBA@mail.gmail.com>
 <56D478F0.3020905@stroeder.com>
Message-ID: <CAHjzW_CY9ECJmRcgZmPDJoeBfuOtKJCfG5+LrJKR2owKP7-Khw@mail.gmail.com>

My bad. I will send it to the right forum. BTW thanks for the suggestion.

-Akshay

On Mon, Feb 29, 2016 at 10:29 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Akshay Mohit wrote:
> > I wanted to install wx in Python 3.5.0
> > Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32
> > bit (Intel)] on win32
> >
> > I am getting the following error:-
> > [..pip output snipped..]
>
> Are you sure you posted to the right list?
>
> 1. python-ldap from https://python-ldap.org does not run with Python 3.
>
> 2. I did not see the substring "ldap" in your pip output at all.
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160301/d28eb417/attachment.html>

From william at blackhats.net.au  Tue Mar  1 23:04:43 2016
From: william at blackhats.net.au (William)
Date: Wed, 02 Mar 2016 14:04:43 +1000
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <1455837819.19414.139.camel@blackhats.net.au>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com>
 <1455837819.19414.139.camel@blackhats.net.au>
Message-ID: <1456891483.27476.114.camel@blackhats.net.au>

Hi,

I never heard back about whether the below patch is acceptable. I do not change
the default behaviour, only add the ability to use MOD_REPLACE if the user wishes
it.

Thanks,

On Fri, 2016-02-19 at 09:23 +1000, William wrote:
> diff --git a/Lib/ldap/modlist.py b/Lib/ldap/modlist.py
> index 0053a3f..a56c3e5 100644
> --- a/Lib/ldap/modlist.py
> +++ b/Lib/ldap/modlist.py
> @@ -49,7 +49,7 @@ def addModlist(entry,ignore_attr_types=None):
> ?
> ?
> ?def modifyModlist(
> -??old_entry,new_entry,ignore_attr_types=None,ignore_oldexistent=0,case_ignore_
> at
> tr_types=None
> +??old_entry,new_entry,ignore_attr_types=None,ignore_oldexistent=0,case_ignore_
> at
> tr_types=None,replace_is_add_then_delete=True
> ?):
> ???"""
> ???Build differential modify list for calling LDAPObject.modify()/modify_s()
> @@ -69,6 +69,10 @@ def modifyModlist(
> ???case_ignore_attr_types
> ???????List of attribute type names for which comparison will be made
> ???????case-insensitive
> +??replace_is_add_then_delete
> +??????Determines if a replace operation is carried out as add then delete
> +??????or if it is a pure ldap replace. This can have behavioural affects on
> +??????certain ldap servers and object types IE configuration directories.
> ???"""
> ???ignore_attr_types = list_dict(map(lower,(ignore_attr_types or [])))
> ???case_ignore_attr_types = list_dict(map(lower,(case_ignore_attr_types or
> [])))
> @@ -111,8 +115,11 @@ def modifyModlist(
> ???????????????replace_attr_value = 1
> ???????????????break
> ???????if replace_attr_value:
> -????????modlist.append((ldap.MOD_DELETE,attrtype,None))
> -????????modlist.append((ldap.MOD_ADD,attrtype,new_value))
> +????????if replace_is_add_then_delete:
> +??????????modlist.append((ldap.MOD_DELETE,attrtype,None))
> +??????????modlist.append((ldap.MOD_ADD,attrtype,new_value))
> +????????else:
> +??????????modlist.append((ldap.MOD_REPLACE,attrtype,new_value))
> ?????elif old_value and not new_value:
> ???????# Completely delete an existing attribute
> ???????modlist.append((ldap.MOD_DELETE,attrtype,None))
> 

-- 
William <william at blackhats.net.au>


From michael at stroeder.com  Thu Mar  3 10:32:15 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 3 Mar 2016 16:32:15 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <1456891483.27476.114.camel@blackhats.net.au>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com> <1455837819.19414.139.camel@blackhats.net.au>
 <1456891483.27476.114.camel@blackhats.net.au>
Message-ID: <56D858FF.7080305@stroeder.com>

William wrote:
> I never heard back about whether the below patch is acceptable. I do not change
> the default behaviour, only add the ability to use MOD_REPLACE if the user wishes
> it.

Even though this small change does not change the default behaviour it might be
actually used and people will ask here when running into problems. We had
discussions about that function before. I suspect your patch will open a can of
worms leading to more patches for upcoming corner-cases. Also I don't have a
test server running 389-DS. So it's hard for me to test corner-cases.

So if this is an urgent need in your project then you can easily overload this
function with your own implementation. Even with your patch you have to touch
your code.

In general it seems that this function might not fit everybody's needs. So I'll
add an interop note in the docs about this:

   .. note::
      Replacing attribute values is always done with a
      :py:const:`ldap.MOD_DELETE`/:py:const:`ldap.MOD_ADD` pair instead of
      :py:const:`ldap.MOD_REPLACE` to work-around potential issues with
      attributes for which no EQUALITY matching rule are defined in the
      server's subschema.  This works correctly in most situations but
      rarely fails with some LDAP servers implementing (schema) checks on
      transient state entry during processing the modify operation.

Ciao, Michael.

P.S.: IMO 389-DS should be fixed.

--
Michael Str?der
E-Mail: michael at stroeder.com
https://www.stroeder.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160303/db5ce111/attachment.bin>

From william at blackhats.net.au  Thu Mar  3 16:17:23 2016
From: william at blackhats.net.au (William)
Date: Fri, 04 Mar 2016 07:17:23 +1000
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <56D858FF.7080305@stroeder.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com>
 <1455837819.19414.139.camel@blackhats.net.au>
 <1456891483.27476.114.camel@blackhats.net.au>
 <56D858FF.7080305@stroeder.com>
Message-ID: <1457039843.21796.15.camel@blackhats.net.au>

On Thu, 2016-03-03 at 16:32 +0100, Michael Str?der wrote:
> 
> William wrote:
> > 
> > 
> > I never heard back about whether the below patch is acceptable. I do not
> > change
> > the default behaviour, only add the ability to use MOD_REPLACE if the user
> > wishes
> > it.
> Even though this small change does not change the default behaviour it might be
> actually used and people will ask here when running into problems. We had
> discussions about that function before. I suspect your patch will open a can of
> worms leading to more patches for upcoming corner-cases. Also I don't have a
> test server running 389-DS. So it's hard for me to test corner-cases.
But people can also use delete_s? modrdn_s? They can even use mod_replace in
modify if they build the list themself.

People will always be able to shoot themselves with your code, and can then ask
questions like "why did this not work".

This is the point of clear, documentation.

So perhaps consider the patch, and also expand the documentation around the
modlist functions to say "the default is this and WHY" and what the risks of
mod_replace are. People should be able to take responsibility for their own
actions.

> 
> 
> So if this is an urgent need in your project then you can easily overload this
> function with your own implementation. Even with your patch you have to touch
> your code.
Yes, but I'll need to overload all of the modlist building function: Which is
quite excessive to maintain ....

> 
> 
> In general it seems that this function might not fit everybody's needs. So I'll
> add an interop note in the docs about this:
> 
> ???.. note::
> ??????Replacing attribute values is always done with a
> ??????:py:const:`ldap.MOD_DELETE`/:py:const:`ldap.MOD_ADD` pair instead of
> ??????:py:const:`ldap.MOD_REPLACE` to work-around potential issues with
> ??????attributes for which no EQUALITY matching rule are defined in the
> ??????server's subschema.??This works correctly in most situations but
> ??????rarely fails with some LDAP servers implementing (schema) checks on
> ??????transient state entry during processing the modify operation.
Which servers have the issue with MOD_REPLACE in question? I don't believe that
389-ds is one of them ...

> 
> 
> Ciao, Michael.
> 
> P.S.: IMO 389-DS should be fixed.
This is a tough request. The value in question is for database cache sizing: It
would be "silly" to allow it to be deleted, as when it's deleted it would have to
set a default value of some kind. Then there is the question of what is the
default etc. There is also the question of whether the team would allow such a
"risky" change to be accepted.?

I believe that openldap has similar restrictions on deletion of some values in
their cn=config partition, but I don't run openldap so I cannot comment on what
they are.?


-- 
William <william at blackhats.net.au>


From michael at stroeder.com  Thu Mar  3 17:13:05 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 3 Mar 2016 23:13:05 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <1457039843.21796.15.camel@blackhats.net.au>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com> <1455837819.19414.139.camel@blackhats.net.au>
 <1456891483.27476.114.camel@blackhats.net.au> <56D858FF.7080305@stroeder.com>
 <1457039843.21796.15.camel@blackhats.net.au>
Message-ID: <56D8B6F1.5050800@stroeder.com>

William wrote:
> On Thu, 2016-03-03 at 16:32 +0100, Michael Str?der wrote:
>> William wrote:
>>> I never heard back about whether the below patch is acceptable. I do not
>>> change
>>> the default behaviour, only add the ability to use MOD_REPLACE if the user
>>> wishes
>>> it.
>> Even though this small change does not change the default behaviour it might be
>> actually used and people will ask here when running into problems. We had
>> discussions about that function before. I suspect your patch will open a can of
>> worms leading to more patches for upcoming corner-cases. Also I don't have a
>> test server running 389-DS. So it's hard for me to test corner-cases.
>
> But people can also use delete_s? modrdn_s? They can even use mod_replace in
> modify if they build the list themself.
> People will always be able to shoot themselves with your code, and can then ask
> questions like "why did this not work".

Note that I always stayed away from implementing a object-LDAP-mapper for the
very same reason.

> This is the point of clear, documentation.

And that's why I've added a clear interop note.

>> So if this is an urgent need in your project then you can easily overload this
>> function with your own implementation. Even with your patch you have to touch
>> your code.
>
> Yes, but I'll need to overload all of the modlist building function: Which is
> quite excessive to maintain ....

1. This function was not changed for years. So it's not hard to maintain a local
fork in your code base.

2. It will give you more flexibility for your needs. I suspect that there will
be more modifications needed for your LDAP server deployment later.

Sometimes I forked some python-ldap code in web2ldap or somewhere else to test
what's really needed in the long run. If it's really mature I port it back to
python-ldap (can take some time).

>> In general it seems that this function might not fit everybody's needs. So I'll
>> add an interop note in the docs about this:
>>
>>    .. note::
>>       Replacing attribute values is always done with a
>>       :py:const:`ldap.MOD_DELETE`/:py:const:`ldap.MOD_ADD` pair instead of
>>       :py:const:`ldap.MOD_REPLACE` to work-around potential issues with
>>       attributes for which no EQUALITY matching rule are defined in the
>>       server's subschema.  This works correctly in most situations but
>>       rarely fails with some LDAP servers implementing (schema) checks on
>>       transient state entry during processing the modify operation.
>
> Which servers have the issue with MOD_REPLACE in question?

Several in case the attribute does not have an EQUALITY matching rule.

> I don't believe that 389-ds is one of them ...

Maybe. I cannot test.

>> P.S.: IMO 389-DS should be fixed.
> This is a tough request. The value in question is for database cache sizing: It
> would be "silly" to allow it to be deleted, as when it's deleted it would have to
> set a default value of some kind.

Note that a MOD_DELETE/MOD_ADD pair should not result in an attribute to be
completely removed in the *final* state of an entry.

See also:

https://tools.ietf.org/html/rfc4511#section-4.6

     [..] While individual
     modifications may violate certain aspects of the directory schema
     (such as the object class definition and Directory Information Tree
     (DIT) content rule), the resulting entry after the entire list of
     modifications is performed MUST conform to the requirements of the
     directory model and controlling schema [RFC4512].

> I believe that openldap has similar restrictions on deletion of some values in
> their cn=config partition, but I don't run openldap so I cannot comment on what
> they are. 

AFAICS OpenLDAP does not perform object class schema check on intermediate state
of an entry. It does schema checking on the final state of an entry after
applying all modifications. And IMHO that's how it should work.

Ciao, Michael.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160303/eaef2ecb/attachment.bin>

From pspacek at redhat.com  Fri Mar  4 04:16:46 2016
From: pspacek at redhat.com (Petr Spacek)
Date: Fri, 4 Mar 2016 10:16:46 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <56D8B6F1.5050800@stroeder.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com> <1455837819.19414.139.camel@blackhats.net.au>
 <1456891483.27476.114.camel@blackhats.net.au> <56D858FF.7080305@stroeder.com>
 <1457039843.21796.15.camel@blackhats.net.au> <56D8B6F1.5050800@stroeder.com>
Message-ID: <56D9527E.7080103@redhat.com>

On 3.3.2016 23:13, Michael Str?der wrote:
> William wrote:
>> On Thu, 2016-03-03 at 16:32 +0100, Michael Str?der wrote:
>>> William wrote:
>>>> I never heard back about whether the below patch is acceptable. I do not
>>>> change
>>>> the default behaviour, only add the ability to use MOD_REPLACE if the user
>>>> wishes
>>>> it.
>>> Even though this small change does not change the default behaviour it might be
>>> actually used and people will ask here when running into problems. We had
>>> discussions about that function before. I suspect your patch will open a can of
>>> worms leading to more patches for upcoming corner-cases. Also I don't have a
>>> test server running 389-DS. So it's hard for me to test corner-cases.
>>
>> But people can also use delete_s? modrdn_s? They can even use mod_replace in
>> modify if they build the list themself.
>> People will always be able to shoot themselves with your code, and can then ask
>> questions like "why did this not work".
> 
> Note that I always stayed away from implementing a object-LDAP-mapper for the
> very same reason.
> 
>> This is the point of clear, documentation.
> 
> And that's why I've added a clear interop note.
> 
>>> So if this is an urgent need in your project then you can easily overload this
>>> function with your own implementation. Even with your patch you have to touch
>>> your code.
>>
>> Yes, but I'll need to overload all of the modlist building function: Which is
>> quite excessive to maintain ....
> 
> 1. This function was not changed for years. So it's not hard to maintain a local
> fork in your code base.
> 
> 2. It will give you more flexibility for your needs. I suspect that there will
> be more modifications needed for your LDAP server deployment later.
> 
> Sometimes I forked some python-ldap code in web2ldap or somewhere else to test
> what's really needed in the long run. If it's really mature I port it back to
> python-ldap (can take some time).
> 
>>> In general it seems that this function might not fit everybody's needs. So I'll
>>> add an interop note in the docs about this:
>>>
>>>    .. note::
>>>       Replacing attribute values is always done with a
>>>       :py:const:`ldap.MOD_DELETE`/:py:const:`ldap.MOD_ADD` pair instead of
>>>       :py:const:`ldap.MOD_REPLACE` to work-around potential issues with
>>>       attributes for which no EQUALITY matching rule are defined in the
>>>       server's subschema.  This works correctly in most situations but
>>>       rarely fails with some LDAP servers implementing (schema) checks on
>>>       transient state entry during processing the modify operation.
>>
>> Which servers have the issue with MOD_REPLACE in question?
> 
> Several in case the attribute does not have an EQUALITY matching rule.
> 
>> I don't believe that 389-ds is one of them ...
> 
> Maybe. I cannot test.

Feel free to play with this one:
ldap://ipa.demo1.freeipa.org
BIND DN: uid=admin,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org
BIND password: Secret123

The server is wiped clean every day at 05:00 UTC.

Petr Spacek @ Red Hat


>>> P.S.: IMO 389-DS should be fixed.
>> This is a tough request. The value in question is for database cache sizing: It
>> would be "silly" to allow it to be deleted, as when it's deleted it would have to
>> set a default value of some kind.
> 
> Note that a MOD_DELETE/MOD_ADD pair should not result in an attribute to be
> completely removed in the *final* state of an entry.
> 
> See also:
> 
> https://tools.ietf.org/html/rfc4511#section-4.6
> 
>      [..] While individual
>      modifications may violate certain aspects of the directory schema
>      (such as the object class definition and Directory Information Tree
>      (DIT) content rule), the resulting entry after the entire list of
>      modifications is performed MUST conform to the requirements of the
>      directory model and controlling schema [RFC4512].
> 
>> I believe that openldap has similar restrictions on deletion of some values in
>> their cn=config partition, but I don't run openldap so I cannot comment on what
>> they are. 
> 
> AFAICS OpenLDAP does not perform object class schema check on intermediate state
> of an entry. It does schema checking on the final state of an entry after
> applying all modifications. And IMHO that's how it should work.
> 
> Ciao, Michael.

From michael at stroeder.com  Fri Mar  4 04:37:51 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 4 Mar 2016 10:37:51 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <56D9527E.7080103@redhat.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56C5B9F8.7010000@stroeder.com> <1455837819.19414.139.camel@blackhats.net.au>
 <1456891483.27476.114.camel@blackhats.net.au> <56D858FF.7080305@stroeder.com>
 <1457039843.21796.15.camel@blackhats.net.au> <56D8B6F1.5050800@stroeder.com>
 <56D9527E.7080103@redhat.com>
Message-ID: <56D9576F.4080304@stroeder.com>

Petr Spacek wrote:
> Feel free to play with this one:
> ldap://ipa.demo1.freeipa.org
> BIND DN: uid=admin,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org
> BIND password: Secret123

Yes, I know: https://web2ldap.de/demo.html#freeipa.org
;-)

But the demo server does not allow accessing cn=config.
And William has issues with certain attributes in cn=config.

FWIW this modification in the normal backend simply worked:

-----------------------------------------------------------------
dn: uid=test,cn=users,cn=accounts,dc=demo1,dc=freeipa,dc=org
changetype: modify
delete: uidNumber
-
add: uidNumber
uidNumber: 1120000042
-
delete: gidNumber
-
add: gidNumber
gidNumber: 1120000017
-

-----------------------------------------------------------------

This modification was generated by web2ldap. As you can see always the whole
MUST attributes are removed with MOD_DELETE and the new list is added with
MOD_ADD. This is because 389-DS does not publish any matching rule information
in its subschema.

Note that web2ldap has a schema-aware variant of ldap.modlist.modifyModlist()
which looks at EQUALITY matching rules.

Here's an example of a similar modification generated by web2ldap when server is
OpenLDAP:

-----------------------------------------------------------------
dn: cn=Fred Feuerstein,ou=Testing,dc=stroeder,dc=de
changetype: modify
delete: uidNumber
uidNumber: 540
-
add: uidNumber
uidNumber: 23540
-
delete: gidNumber
gidNumber: 100
-
add: gidNumber
gidNumber: 9000
-

-----------------------------------------------------------------

As you can see removed attribute values are explicitly listed in the MOD_DELETE
part. This is done for provoking failure in case of concurrent write access to
the entry. Well, the best way to deal with concurrent write access is the
Assertion Control (see RFC 4528). But this is also not supported by 389-DS.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160304/d70e3857/attachment.bin>

From michael at stroeder.com  Fri Mar  4 13:19:45 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 4 Mar 2016 19:19:45 +0100
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
Message-ID: <56D9D1C1.9070301@stroeder.com>

Jephte Clain wrote:
> FYI, on OpenLDAP, under the cn=config database, there are some
> attributes that a required to exist. You can't just delete then add
> them: you have to replace them.

Not true.

Successfully tested this modification with OpenLDAP 2.4.44:

---------------- snip ----------------
dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcDbDirectory
-
add: olcDbDirectory
olcDbDirectory: /home/openldap/accesslog
-

---------------- snip ----------------

'olcDbDirectory' is MUST in this 'olcMdbConfig' entry.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160304/a5d1c96f/attachment.bin>

From jephte.clain at univ-reunion.fr  Fri Mar  4 23:10:55 2016
From: jephte.clain at univ-reunion.fr (Jephte Clain)
Date: Sat, 5 Mar 2016 08:10:55 +0400
Subject: [python-ldap] Modlist with a replace sometimes fails
In-Reply-To: <56D9D1C1.9070301@stroeder.com>
References: <1455771484.19414.112.camel@blackhats.net.au>
 <56C58126.2070007@stroeder.com>
 <CAPas2jR-F=OQbG4zx7r7JznLmaL2GLox+_3gLMVhwqVYghkwRA@mail.gmail.com>
 <56D9D1C1.9070301@stroeder.com>
Message-ID: <CAPas2jTXdZXPfhRoPaMHwbZFKtkFo8DvUGNpqeA00z4jxb4Ydw@mail.gmail.com>

hello,

I have been very busy and not able to answer before, sorry.
indeed I was not able to reproduce the error I've had with a previous
version (don't remember which one)
so you were right, and I'm glad to update my knowledge with current facts

best regards,

2016-03-04 22:19 GMT+04:00 Michael Str?der <michael at stroeder.com>:
> Jephte Clain wrote:
>> FYI, on OpenLDAP, under the cn=config database, there are some
>> attributes that a required to exist. You can't just delete then add
>> them: you have to replace them.
>
> Not true.
>
> Successfully tested this modification with OpenLDAP 2.4.44:
>
> ---------------- snip ----------------
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> delete: olcDbDirectory
> -
> add: olcDbDirectory
> olcDbDirectory: /home/openldap/accesslog
> -
>
> ---------------- snip ----------------
>
> 'olcDbDirectory' is MUST in this 'olcMdbConfig' entry.
>
> Ciao, Michael.
>



-- 
Jepht? CLAIN | D?veloppeur, Int?grateur d'applications
Service Syst?me d'Information
Direction des Syst?mes d'Information
T?l: +262 262 93 86 31 || Gsm: +262 692 29 58 24

From michael at stroeder.com  Wed Mar  9 03:33:46 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 9 Mar 2016 09:33:46 +0100
Subject: [python-ldap] FYI: python-ldap.org transistion process
Message-ID: <56DFDFEA.4060000@stroeder.com>

HI!

Please note that domain python-ldap.org is currently unreachable because it is
transferred to another domain registrar. The new provider is working on that.

I hope this transistion period does not take too long.

Sorry for the inconvenience.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160309/067b47a5/attachment.bin>

From michael at stroeder.com  Wed Mar  9 05:22:11 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 9 Mar 2016 11:22:11 +0100
Subject: [python-ldap] FYI: python-ldap.org transistion process
In-Reply-To: <56DFDFEA.4060000@stroeder.com>
References: <56DFDFEA.4060000@stroeder.com>
Message-ID: <56DFF953.6070102@stroeder.com>

Michael Str?der wrote:
> Please note that domain python-ldap.org is currently unreachable because it is
> transferred to another domain registrar. The new provider is working on that.
> 
> I hope this transistion period does not take too long.

Domain is up and running again.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160309/355852ae/attachment.bin>

From space at wechall.net  Fri Mar 11 02:22:20 2016
From: space at wechall.net (Space One)
Date: Fri, 11 Mar 2016 08:22:20 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56A7B6E6.8090802@redhat.com>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com> <56A78C59.6060802@wechall.net>
 <56A78EE1.8050608@stroeder.com> <56A79058.3070402@wechall.net>
 <56A79368.1080404@stroeder.com> <56A7B6E6.8090802@redhat.com>
Message-ID: <56E2722C.8040407@wechall.net>

Sorry but that change SUCKS!

Now we received tracebacks from our customers with this error:

  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 918,
in search_ext_s
    return
self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 865,
in _apply_method_s
    self.reconnect(self._uri,retry_max=self._retry_max,retry_delay=self._retry_delay)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 843,
in reconnect
    SimpleLDAPObject.unbind_s(self)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 600,
in unbind_s
    return self.unbind_ext_s(None,None)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 591,
in unbind_ext_s
    msgid = self.unbind_ext(serverctrls,clientctrls)
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 588,
in unbind_ext
    return
self._ldap_call(self._l.unbind_ext,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
  File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 136,
in __getattr__
    self.__class__.__name__,repr(name)
AttributeError: ReconnectLDAPObject has no attribute '_l'

We can't handle all AttributeError's - 1. it could hide a lot of other
errors. 2. It wouldn't be future-proof if the code changes somewhen and
raise something else (e.g. TypeError due to NoneType) instead or the
variable '_l' changes so that one cannot inspect the frame/str(exc).

Also the question here is why the reconnection did fail but didn't raise
anything (our code doesn't call unbind() anywhere!).

Best regards
spaceone

Am 26.01.2016 um 19:11 schrieb Petr Viktorin:
> On 01/26/2016 04:40 PM, Michael Str?der wrote:
>> HI!
>>
>> (please stay on python-ldap list so others comment as well)
>>
>> Space One wrote:
>>> Am 26.01.2016 um 16:21 schrieb Michael Str?der:
>>>> Space One wrote:
>>>>> AttributeError is IMHO not good, please better raise ldap.SERVER_DOWN so
>>>>> that one can handle it.
>>>> I consider ldap.SERVER_DOWN to be inappropriate in this case because it
>>>> indicates an error the application can recover from by proper reconnect.
>>>>
>>>> But in case the application calls some LDAPObject method *after* unbinding then
>>>> the application's code has to be fixed. This is a different case!
>>> We are speaking about ldap.ldapobject.ReconnectLDAPObject, right?
>> Not limited to ReconnectLDAPObject.
>>
>>> This class somehow unbind()s itself.
>> I never experienced such a seg fault when using ReconnectLDAPObject and I'm
>> using it a lot. Therefore I assume there's no problem inside this class.
>> Especially it won't call any LDAPObject method after internal unbind without
>> internally setting up new connection object.
>>
>>> If you aren't okay with ldap.SERVER_DOWN please don't use AttributeError
>>> but some new exception like ldap.UNBOUND_CONNECTION.
>>>
>>> As the intial thread says I want a way to clearly be able to
>>> differentitate if the connection is still valid and handle things if
>>> not. AttributeError would not be nice in that scenario as I don't want
>>> to catch all AttributeErrors.
>> Your application MUST NOT catch this exception and simply re-try!
>>
>> Your application MUST avoid to use an LDAPObject instance after calling
>> LDAPObject.unbind_ext() and friends! So if this (unhandled) exception ever
>> happens it indicates a bug in your application logic and you have to fix your
>> calling code.
>>
>> The only thing python-ldap did wrong is the seg fault.
>>
>> Ciao, Michael.
> Indeed. The only code that should be catching this exception is the test
> that verifies python-ldap doesn't segfault. That test could be a bit
> more specific if the exception was not a generic AttributeError.
>
> Also, a generic exception means any code that expects AttributeError
> will now catch this as well. Not too likely in good code, but one more
> reason to use a specific exception.
>
> I'm not insisting though.
>


From michael at stroeder.com  Fri Mar 11 03:48:24 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 11 Mar 2016 09:48:24 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56E2722C.8040407@wechall.net>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com> <56A78C59.6060802@wechall.net>
 <56A78EE1.8050608@stroeder.com> <56A79058.3070402@wechall.net>
 <56A79368.1080404@stroeder.com> <56A7B6E6.8090802@redhat.com>
 <56E2722C.8040407@wechall.net>
Message-ID: <56E28658.7010908@stroeder.com>

Space One wrote:
> Sorry but that change SUCKS!

Thank you for using python-ldap.

> Now we received tracebacks from our customers with this error:
> 
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 918,
> in search_ext_s
>     return
> self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs)
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 865,
> in _apply_method_s
>     self.reconnect(self._uri,retry_max=self._retry_max,retry_delay=self._retry_delay)
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 843,
> in reconnect
>     SimpleLDAPObject.unbind_s(self)
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 600,
> in unbind_s
>     return self.unbind_ext_s(None,None)
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 591,
> in unbind_ext_s
>     msgid = self.unbind_ext(serverctrls,clientctrls)
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 588,
> in unbind_ext
>     return
> self._ldap_call(self._l.unbind_ext,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 136,
> in __getattr__
>     self.__class__.__name__,repr(name)
> AttributeError: ReconnectLDAPObject has no attribute '_l'

Do you expect anybody to draw a serious conclusion from this traceback excerpt?

> We can't handle all AttributeError's - 1. it could hide a lot of other
> errors. 2. It wouldn't be future-proof if the code changes somewhen and
> raise something else (e.g. TypeError due to NoneType) instead or the
> variable '_l' changes so that one cannot inspect the frame/str(exc).
> 
> Also the question here is why the reconnection did fail but didn't raise
> anything (our code doesn't call unbind() anywhere!).

My customers never have this issue. Why? ;-)

As said in this thread numerous times: If you invoke unbind method the
LDAPObject instance is NOT VALID anymore. You MUST NOT use this instance later.
Period.

=> Fix your code. Then AttributeError will not be raised.

(python-ldap SHOULD NOT seg fault in this case so your application continues to
run. Thanks to Petr's patch this has been fix.)

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160311/79929935/attachment.bin>

From space at wechall.net  Fri Mar 11 04:51:47 2016
From: space at wechall.net (Space One)
Date: Fri, 11 Mar 2016 10:51:47 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56E28658.7010908@stroeder.com>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com> <56A78C59.6060802@wechall.net>
 <56A78EE1.8050608@stroeder.com> <56A79058.3070402@wechall.net>
 <56A79368.1080404@stroeder.com> <56A7B6E6.8090802@redhat.com>
 <56E2722C.8040407@wechall.net> <56E28658.7010908@stroeder.com>
Message-ID: <56E29533.4080609@wechall.net>

As I already told: I don't call unbind(). Nowhere. Maybe the
python-ldap-reconnection class does somehwere.
I can't remove the instance everywhere if it is not "valid" anymore -
because it might be referenced anywhere in the very large code base.
Python-ldap also doesn't provide a method to check if the connection is
currently bound.

Am 11.03.2016 um 09:48 schrieb Michael Str?der:
> Space One wrote:
>> Sorry but that change SUCKS!
> Thank you for using python-ldap.
>
>> Now we received tracebacks from our customers with this error:
>>
>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 918,
>> in search_ext_s
>>     return
>> self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs)
>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 865,
>> in _apply_method_s
>>     self.reconnect(self._uri,retry_max=self._retry_max,retry_delay=self._retry_delay)
>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 843,
>> in reconnect
>>     SimpleLDAPObject.unbind_s(self)
>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 600,
>> in unbind_s
>>     return self.unbind_ext_s(None,None)
>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 591,
>> in unbind_ext_s
>>     msgid = self.unbind_ext(serverctrls,clientctrls)
>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 588,
>> in unbind_ext
>>     return
>> self._ldap_call(self._l.unbind_ext,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))
>>   File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 136,
>> in __getattr__
>>     self.__class__.__name__,repr(name)
>> AttributeError: ReconnectLDAPObject has no attribute '_l'
> Do you expect anybody to draw a serious conclusion from this traceback excerpt?
>
>> We can't handle all AttributeError's - 1. it could hide a lot of other
>> errors. 2. It wouldn't be future-proof if the code changes somewhen and
>> raise something else (e.g. TypeError due to NoneType) instead or the
>> variable '_l' changes so that one cannot inspect the frame/str(exc).
>>
>> Also the question here is why the reconnection did fail but didn't raise
>> anything (our code doesn't call unbind() anywhere!).
> My customers never have this issue. Why? ;-)
>
> As said in this thread numerous times: If you invoke unbind method the
> LDAPObject instance is NOT VALID anymore. You MUST NOT use this instance later.
> Period.
>
> => Fix your code. Then AttributeError will not be raised.
>
> (python-ldap SHOULD NOT seg fault in this case so your application continues to
> run. Thanks to Petr's patch this has been fix.)
>
> Ciao, Michael.
>


From michael at stroeder.com  Fri Mar 11 07:47:10 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Fri, 11 Mar 2016 13:47:10 +0100
Subject: [python-ldap] segfault/Abort for operations with unbound
 connection
In-Reply-To: <56E29533.4080609@wechall.net>
References: <565F0E62.7000500@wechall.net> <56A73EE1.4070904@redhat.com>
 <56A75324.9090209@stroeder.com> <56A78169.7070405@redhat.com>
 <56A78A2F.3030008@stroeder.com> <56A78C59.6060802@wechall.net>
 <56A78EE1.8050608@stroeder.com> <56A79058.3070402@wechall.net>
 <56A79368.1080404@stroeder.com> <56A7B6E6.8090802@redhat.com>
 <56E2722C.8040407@wechall.net> <56E28658.7010908@stroeder.com>
 <56E29533.4080609@wechall.net>
Message-ID: <56E2BE4E.6000008@stroeder.com>

Space One wrote:
> As I already told: I don't call unbind(). Nowhere. Maybe the
> python-ldap-reconnection class does somehwere.

Try this:
http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.152&r2=1.153

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160311/b88a03d0/attachment-0001.bin>

From dwmaillist at gmail.com  Thu Mar 17 15:40:26 2016
From: dwmaillist at gmail.com (Daniel Watrous)
Date: Thu, 17 Mar 2016 14:40:26 -0500
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not working
Message-ID: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>

Hi,

I am able to make a connection to my LDAPS server with my own certificate
setting the following option on Linux
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)

However, on Windows the same approach fails with
SERVER_DOWN: {'info': 'error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed (unable to
get issuer certificate)', 'desc': "Can't contact LDAP server"}

It seems that either python-ldap can't follow the Windows based path to the
certificate OR python-ldap has a hard dependency on a Linux library that
isn't available on Windows.

Any help getting this working on Windows is appreciated. Here's a larger
snippet from my script

try:
    ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, pathtocacertfile)
    ld = ldap.initialize(host)
    ld.simple_bind_s(binduser,bindpw)
except ldap.LDAPError, error_message:
    print "Couldn't Connect. %s " % error_message

filter = ('(userPrincipalName=aperson at example.com)')
attrs = ['cn']

r = ld.search_s(base, scope, filter, attrs)


Couldn't Connect. {'info': 'error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed (unable to
get issuer certificate)', 'desc': "Can't contact LDAP server"}
Traceback (most recent call last):
  File
"C:\Users\watrous\Documents\GitHub\helion-onboarding-automation\test-ad.py",
line 23, in <module>
    r = ld.search_s(base, scope, filter, attrs)
  File "C:\Python27\lib\site-packages\ldap\ldapobject.py", line 597, in
search_s
    return
self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout=self.timeout)
  File "C:\Python27\lib\site-packages\ldap\ldapobject.py", line 590, in
search_ext_s
    msgid =
self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit)
  File "C:\Python27\lib\site-packages\ldap\ldapobject.py", line 586, in
search_ext
    timeout,sizelimit,
  File "C:\Python27\lib\site-packages\ldap\ldapobject.py", line 106, in
_ldap_call
    result = func(*args,**kwargs)
SERVER_DOWN: {'info': 'error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed (unable to
get issuer certificate)', 'desc': "Can't contact LDAP server"}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/0816cea0/attachment.html>

From michael at stroeder.com  Thu Mar 17 15:48:45 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 17 Mar 2016 20:48:45 +0100
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
Message-ID: <56EB0A1D.7050704@stroeder.com>

Daniel Watrous wrote:
> I am able to make a connection to my LDAPS server with my own certificate
> setting the following option on Linux
> ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)

Good.

> However, on Windows the same approach fails with
> SERVER_DOWN: {'info': 'error:14090086:SSL
> routines:ssl3_get_server_certificate:certificate verify failed (unable to
> get issuer certificate)', 'desc': "Can't contact LDAP server"}
> 
> It seems that either python-ldap can't follow the Windows based path to the
> certificate OR python-ldap has a hard dependency on a Linux library that
> isn't available on Windows.

The good news is that the 'info' message is actually generated by the OpenSSL
libs. AFAIK Waldemar compiles OpenSSL into his python-ldap builds for Windows.

OpenSSL simply cannot find the CA cert needed to validate the LDAP server cert.

> Any help getting this working on Windows is appreciated. Here's a larger
> snippet from my script
> 
> try:
>     ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, pathtocacertfile)

What's the content of var pathtocacertfile?
Does it contain a Windows path name?
Does the referenced file really contain the CA cert?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/7c1b2208/attachment.bin>

From dwmaillist at gmail.com  Thu Mar 17 16:11:33 2016
From: dwmaillist at gmail.com (Daniel Watrous)
Date: Thu, 17 Mar 2016 15:11:33 -0500
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <56EB0A1D.7050704@stroeder.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
Message-ID: <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>

It's a path to a windows file.

[Dbg]>>> print pathtocacertfile
C:\Users\me\Documents\GitHub\automation\ephemeralca-cacert.crt

The exact same file works as expected on Linux, so the cert file is valid.

>>> import ldap
>>> ldap.__version__
'2.4.25'

Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)]
on win32.

On Thu, Mar 17, 2016 at 2:48 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Daniel Watrous wrote:
> > I am able to make a connection to my LDAPS server with my own certificate
> > setting the following option on Linux
> > ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, CACERTFILE)
>
> Good.
>
> > However, on Windows the same approach fails with
> > SERVER_DOWN: {'info': 'error:14090086:SSL
> > routines:ssl3_get_server_certificate:certificate verify failed (unable to
> > get issuer certificate)', 'desc': "Can't contact LDAP server"}
> >
> > It seems that either python-ldap can't follow the Windows based path to
> the
> > certificate OR python-ldap has a hard dependency on a Linux library that
> > isn't available on Windows.
>
> The good news is that the 'info' message is actually generated by the
> OpenSSL
> libs. AFAIK Waldemar compiles OpenSSL into his python-ldap builds for
> Windows.
>
> OpenSSL simply cannot find the CA cert needed to validate the LDAP server
> cert.
>
> > Any help getting this working on Windows is appreciated. Here's a larger
> > snippet from my script
> >
> > try:
> >     ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, pathtocacertfile)
>
> What's the content of var pathtocacertfile?
> Does it contain a Windows path name?
> Does the referenced file really contain the CA cert?
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/52d7ac91/attachment-0001.html>

From michael at stroeder.com  Thu Mar 17 16:18:46 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 17 Mar 2016 21:18:46 +0100
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
Message-ID: <56EB1126.6010408@stroeder.com>

Daniel Watrous wrote:
> It's a path to a windows file.
> 
> [Dbg]>>> print pathtocacertfile
> C:\Users\me\Documents\GitHub\automation\ephemeralca-cacert.crt
                                          ^^^^^^^^^^^^^^^^
This file name makes me curious:
Is it a standard RSA cert?
Or ECDSA or....?

Not sure which OpenSSL version Waldemar uses in his Win32 builds.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/e1080cb4/attachment.bin>

From dwmaillist at gmail.com  Thu Mar 17 16:23:43 2016
From: dwmaillist at gmail.com (Daniel Watrous)
Date: Thu, 17 Mar 2016 15:23:43 -0500
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <56EB1126.6010408@stroeder.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
Message-ID: <CAHSC4g2tYZY1jH_qLSmT7xaAAA6O2qPT_oE6tUMBxa4MS4B8Zw@mail.gmail.com>

Aside from the goofy (meaningless) filename, it's a standard format cert
file. I'm not sure how to tell if it's RSA or something else.

So you think this is an issue with openssl and not the path or some windows
thing?

Daniel

On Thu, Mar 17, 2016 at 3:18 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Daniel Watrous wrote:
> > It's a path to a windows file.
> >
> > [Dbg]>>> print pathtocacertfile
> > C:\Users\me\Documents\GitHub\automation\ephemeralca-cacert.crt
>                                           ^^^^^^^^^^^^^^^^
> This file name makes me curious:
> Is it a standard RSA cert?
> Or ECDSA or....?
>
> Not sure which OpenSSL version Waldemar uses in his Win32 builds.
>
> Ciao, Michael.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/b8d07cc2/attachment.html>

From pbengtsson at mozilla.com  Thu Mar 17 16:29:57 2016
From: pbengtsson at mozilla.com (Peter Bengtsson)
Date: Thu, 17 Mar 2016 16:29:57 -0400
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CAHSC4g2tYZY1jH_qLSmT7xaAAA6O2qPT_oE6tUMBxa4MS4B8Zw@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CAHSC4g2tYZY1jH_qLSmT7xaAAA6O2qPT_oE6tUMBxa4MS4B8Zw@mail.gmail.com>
Message-ID: <CALTBac0ZOKwunPpAbqxd5hi+n3afHq98Qgmg+wu3bbQ1rURkWg@mail.gmail.com>

For what it's worth, I have the same problem on OSX.
I get "option error" when trying to set the path to the cert file
https://mail.python.org/pipermail/python-ldap/2016q1/003691.html

It's still not solved.

On Thu, Mar 17, 2016 at 4:23 PM, Daniel Watrous <dwmaillist at gmail.com>
wrote:

> Aside from the goofy (meaningless) filename, it's a standard format cert
> file. I'm not sure how to tell if it's RSA or something else.
>
> So you think this is an issue with openssl and not the path or some
> windows thing?
>
> Daniel
>
> On Thu, Mar 17, 2016 at 3:18 PM, Michael Str?der <michael at stroeder.com>
> wrote:
>
>> Daniel Watrous wrote:
>> > It's a path to a windows file.
>> >
>> > [Dbg]>>> print pathtocacertfile
>> > C:\Users\me\Documents\GitHub\automation\ephemeralca-cacert.crt
>>                                           ^^^^^^^^^^^^^^^^
>> This file name makes me curious:
>> Is it a standard RSA cert?
>> Or ECDSA or....?
>>
>> Not sure which OpenSSL version Waldemar uses in his Win32 builds.
>>
>> Ciao, Michael.
>>
>>
>
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap
>
>


-- 
Peter Bengtsson
Mozilla Tools & Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/4e1fe53d/attachment.html>

From waldemar.osuch at gmail.com  Thu Mar 17 16:32:43 2016
From: waldemar.osuch at gmail.com (Waldemar Osuch)
Date: Thu, 17 Mar 2016 14:32:43 -0600
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <56EB1126.6010408@stroeder.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
Message-ID: <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>

On Thu, Mar 17, 2016 at 2:18 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Not sure which OpenSSL version Waldemar uses in his Win32 builds.


I don't remember the OpenSSL version unfortunately and I don't have access
to the build machine at the moment.
But I've noticed something in the email thread.  The Python version line

> Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)]
on win32.

Suggests it is not a build from PyPi.  We do not have 64 bit builds there.
Is it a build from Christoph Gohlke by any chance?

Waldemar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/24bc4534/attachment-0001.html>

From dwmaillist at gmail.com  Thu Mar 17 16:34:59 2016
From: dwmaillist at gmail.com (Daniel Watrous)
Date: Thu, 17 Mar 2016 15:34:59 -0500
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
Message-ID: <CAHSC4g2=HWD_V8vmBmBMGBnKiePF2AD08qnGvJyWxvLBD_iAgg@mail.gmail.com>

That line is the referring to the Python build, which I got from python.org.

Daniel

On Thu, Mar 17, 2016 at 3:32 PM, Waldemar Osuch <waldemar.osuch at gmail.com>
wrote:

>
> On Thu, Mar 17, 2016 at 2:18 PM, Michael Str?der <michael at stroeder.com>
> wrote:
>
>> Not sure which OpenSSL version Waldemar uses in his Win32 builds.
>
>
> I don't remember the OpenSSL version unfortunately and I don't have access
> to the build machine at the moment.
> But I've noticed something in the email thread.  The Python version line
>
> > Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit
> (AMD64)] on win32.
>
> Suggests it is not a build from PyPi.  We do not have 64 bit builds there.
> Is it a build from Christoph Gohlke by any chance?
>
> Waldemar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/dd3da4b4/attachment.html>

From michael at stroeder.com  Thu Mar 17 16:38:52 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 17 Mar 2016 21:38:52 +0100
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CAHSC4g2tYZY1jH_qLSmT7xaAAA6O2qPT_oE6tUMBxa4MS4B8Zw@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CAHSC4g2tYZY1jH_qLSmT7xaAAA6O2qPT_oE6tUMBxa4MS4B8Zw@mail.gmail.com>
Message-ID: <56EB15DC.1000605@stroeder.com>

Daniel Watrous wrote:
> Aside from the goofy (meaningless) filename, it's a standard format cert
> file. I'm not sure how to tell if it's RSA or something else.

openssl x509 -in /path/to/ephemeralca-cacert.crt -noout -text

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/80c2e642/attachment.bin>

From waldemar.osuch at gmail.com  Thu Mar 17 16:39:48 2016
From: waldemar.osuch at gmail.com (Waldemar Osuch)
Date: Thu, 17 Mar 2016 14:39:48 -0600
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CAHSC4g2=HWD_V8vmBmBMGBnKiePF2AD08qnGvJyWxvLBD_iAgg@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
 <CAHSC4g2=HWD_V8vmBmBMGBnKiePF2AD08qnGvJyWxvLBD_iAgg@mail.gmail.com>
Message-ID: <CACvfz+V4JX76YZYNtuZ3oixCWzsDLqt=st13XEF8Y_iS4-CDFA@mail.gmail.com>

On Thu, Mar 17, 2016 at 2:34 PM, Daniel Watrous <dwmaillist at gmail.com>
wrote:

> That line is the referring to the Python build, which I got from
> python.org.
>

Understood,  what I was referring to was the python-ldap version.  PyPi has
only win32 builds.
[https://pypi.python.org/pypi/python-ldap/2.4.25], not amd64.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/1be7f020/attachment.html>

From dwmaillist at gmail.com  Thu Mar 17 16:43:50 2016
From: dwmaillist at gmail.com (Daniel Watrous)
Date: Thu, 17 Mar 2016 15:43:50 -0500
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CACvfz+V4JX76YZYNtuZ3oixCWzsDLqt=st13XEF8Y_iS4-CDFA@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
 <CAHSC4g2=HWD_V8vmBmBMGBnKiePF2AD08qnGvJyWxvLBD_iAgg@mail.gmail.com>
 <CACvfz+V4JX76YZYNtuZ3oixCWzsDLqt=st13XEF8Y_iS4-CDFA@mail.gmail.com>
Message-ID: <CAHSC4g2bR=Z4q3ZQoKJAxWP691K7U--T1BnvyRigg=bjpkMWZw@mail.gmail.com>

That's correct. I downloaded it here:
http://www.lfd.uci.edu/~gohlke/pythonlibs/#python-ldap

To Michael's question,

        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)

Daniel

On Thu, Mar 17, 2016 at 3:39 PM, Waldemar Osuch <waldemar.osuch at gmail.com>
wrote:

>
> On Thu, Mar 17, 2016 at 2:34 PM, Daniel Watrous <dwmaillist at gmail.com>
> wrote:
>
>> That line is the referring to the Python build, which I got from
>> python.org.
>>
>
> Understood,  what I was referring to was the python-ldap version.  PyPi
> has only win32 builds.
> [https://pypi.python.org/pypi/python-ldap/2.4.25], not amd64.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/a371e191/attachment-0001.html>

From michael at stroeder.com  Thu Mar 17 16:55:46 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Thu, 17 Mar 2016 21:55:46 +0100
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
Message-ID: <56EB19D2.7070706@stroeder.com>

Waldemar Osuch wrote:
> On Thu, Mar 17, 2016 at 2:18 PM, Michael Str?der <michael at stroeder.com>
> wrote:
> 
>> Not sure which OpenSSL version Waldemar uses in his Win32 builds.
> 
> I don't remember the OpenSSL version unfortunately and I don't have access
> to the build machine at the moment.

Given all the security OpenSSL fixes during the last months it's indeed relevant
to keep an eye on that.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/9a1b0a31/attachment.bin>

From dwmaillist at gmail.com  Thu Mar 17 16:58:34 2016
From: dwmaillist at gmail.com (Daniel Watrous)
Date: Thu, 17 Mar 2016 15:58:34 -0500
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <56EB19D2.7070706@stroeder.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
 <56EB19D2.7070706@stroeder.com>
Message-ID: <CAHSC4g1vgMyXu3TqV_WLA0y7Z73MbFKgAKAmaZd2dA-Vhrzo2g@mail.gmail.com>

I just installed the 32bit version of python 2.7.11 and used pip to install
python-ldap. I get the same error when running my script.

On Thu, Mar 17, 2016 at 3:55 PM, Michael Str?der <michael at stroeder.com>
wrote:

> Waldemar Osuch wrote:
> > On Thu, Mar 17, 2016 at 2:18 PM, Michael Str?der <michael at stroeder.com>
> > wrote:
> >
> >> Not sure which OpenSSL version Waldemar uses in his Win32 builds.
> >
> > I don't remember the OpenSSL version unfortunately and I don't have
> access
> > to the build machine at the moment.
>
> Given all the security OpenSSL fixes during the last months it's indeed
> relevant
> to keep an eye on that.
>
> Ciao, Michael.
>
>
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/a8ca7226/attachment.html>

From waldemar.osuch at gmail.com  Thu Mar 17 17:01:41 2016
From: waldemar.osuch at gmail.com (Waldemar Osuch)
Date: Thu, 17 Mar 2016 15:01:41 -0600
Subject: [python-ldap] python ldap windows OPT_X_TLS_CACERTFILE not
 working
In-Reply-To: <CAHSC4g1vgMyXu3TqV_WLA0y7Z73MbFKgAKAmaZd2dA-Vhrzo2g@mail.gmail.com>
References: <CAHSC4g3KYPrkjM1bi_QRfUcwng5Zh-aT92DHoBSOjJHUnsQ6EQ@mail.gmail.com>
 <56EB0A1D.7050704@stroeder.com>
 <CAHSC4g2JgwRQ9-Vr-VizczP8opCz0HdCcVTaFVjmXG=_XCE2xQ@mail.gmail.com>
 <56EB1126.6010408@stroeder.com>
 <CACvfz+WpGtgfog1vjFkZ-J4vJ5tgZXMgVCQ54vFynUX4rWBcAA@mail.gmail.com>
 <56EB19D2.7070706@stroeder.com>
 <CAHSC4g1vgMyXu3TqV_WLA0y7Z73MbFKgAKAmaZd2dA-Vhrzo2g@mail.gmail.com>
Message-ID: <CACvfz+XxtRoXQJCBJ70CVZ76zscdWQSJ64U6W_YY19s4vTV3Dg@mail.gmail.com>

On Thu, Mar 17, 2016 at 2:58 PM, Daniel Watrous <dwmaillist at gmail.com>
wrote:

> I get the same error when running my script.


I know it is not very helpful but at least you know the problems is not
directly caused by build :-/
w/o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160317/c7d30ca0/attachment.html>

From subhashini.tatipamula at gmail.com  Tue Mar 22 07:19:46 2016
From: subhashini.tatipamula at gmail.com (SUBHASHINI TATIPAMULA)
Date: Tue, 22 Mar 2016 11:19:46 +0000 (UTC)
Subject: [python-ldap] AD objectGUID conversion to string
References: <CAHYqR4JWBVgb1vhVbTwSyuYVVAqZZegJnkVJ09RqsokWUSJBYw@mail.gmail.com>
 <541C83AE.5050404@stroeder.com>
 <CAHYqR4+4C2JXwkmLeS7hM8B93cTmEtbUFB8Ss-tyXzt=3EqZ7g@mail.gmail.com>
 <0355e02342a146279991d48ec624630c@exch.activenetwerx.com>
 <5421D0C4.6080207@stroeder.com>
 <f3e316a860e74e60ac7f39138255258a@exch.activenetwerx.com>
 <54227ECA.3090504@stroeder.com>
Message-ID: <loom.20160322T121822-25@post.gmane.org>

Michael Str?der <michael at ...> writes:

> 
> Joseph L. Casale wrote:
> >>> Data in AD is typically utf-16 encoded.
> >>
> >> No! The LDAP interface of MS AD is LDAPv3 compliant and therefore uses 
UTF-8
> >> for LDAP syntax DirectoryString.
> > 
> > Well, to be specific I referred to data _in_ AD, not data _on the wire_. 
To be honest
> > it wasn't even relevant in this case but more for cases like setting 
unicodePwd.
> 
> Yes, 'unicodePwd' is very badly designed. Double quotes as single-byte 
ASCII
> chars enclosing the UTF-16 low-endian password value. Yuck!
> 
> But all other DirectoryString values are simply UTF-8.
> 
> Ciao, Michael.
> 
> 
> Attachment (smime.p7s): application/pkcs7-signature, 2398 bytes
> 
> _______________________________________________
> python-ldap mailing list
> python-ldap at ...
> https://mail.python.org/mailman/listinfo/python-ldap
> 


oracle_raw16_guid = 
'\x04\xb3\x97\xf4\xf7\xdc\x8bL\xa1\x08\xadk}\xfb\x1a\xa9'
import binascii
user_guid = binascii.hexlify(oracle_raw16_guid)

From michael at stroeder.com  Wed Mar 23 13:33:31 2016
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 23 Mar 2016 18:33:31 +0100
Subject: [python-ldap] feature request: be more lenient in LDIFParser
In-Reply-To: <CAPas2jRFkc1_s=sSSHHJiVX78voT1Y_URhQaL8+LFdP0YpLrFA@mail.gmail.com>
References: <CAPas2jRFkc1_s=sSSHHJiVX78voT1Y_URhQaL8+LFdP0YpLrFA@mail.gmail.com>
Message-ID: <56F2D36B.4040802@stroeder.com>

Jephte Clain wrote:
> FYI, I made feature request #18 on
> http://sourceforge.net/p/python-ldap/feature-requests/18/ to make
> LDIFParser more lenient

I saw your feature request and patch.

> from the "be lenient with what you parse, be strict in what you write"
> departement, I attach a patch which support ldif input with several
> blank and/or comment lines between objects
> I don't know if this behavior is correct wrt the LDIF standard, but it
> is useful for me, because I have LDIF files with comments written by
> humans, e.g:

Even line-folded comments are parsed correctly (I've added a test-case to
Tests/t_ldif.py).

> # silly example
> dn: uid=one,dc=tld
> uid: one
> 
> # another silly example
> dn: uid=two,dc=tld
> uid: two
>
> with the current parser, uid=two is not read because there are two
> "blanks" lines before

The example above parses correctly.
You probably meant:

------------------------ snip ------------------------
# silly example
dn: uid=one,dc=tld
uid: one


# another silly example
dn: uid=two,dc=tld
uid: two

------------------------ snip ------------------------

Anyway, please test CVS HEAD.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20160323/973734d2/attachment.bin>