From esiotrot at gmail.com  Thu Feb  3 12:34:36 2011
From: esiotrot at gmail.com (Michael Wood)
Date: Thu, 3 Feb 2011 13:34:36 +0200
Subject: python-ldap hanging for 15 minutes under certain conditions
Message-ID: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>

Hi

I'm trying to do a search against Samba 4's LDAP server and it works,
but the bind and search are both successful, everything hangs when I
try to unbind from the LDAP server.  If anyone could enlighten me I
would be grateful.

I've run into the same issue on various different Linux machines with
a range of OpenLDAP and python-ldap versions, but it seems to work
fine on a Mac running Leopard.

e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
python-ldap 2.3.10-1ubuntu1.

I've also tried upgrading python-ldap to 2.3.12, but that does not
seep to have helped.

def test(username, password):
    base = "DC=example,DC=com"
    userbase = "CN=Users," + base
    userdn = "CN=%s,%s" % (username, userbase)
    ldap_server = "ldap://example.com"
    conn = ldap.initialize(ldap_server)
    conn.set_option(ldap.OPT_REFERRALS, 0) # Doesn't appear to make a difference
    conn.start_tls_s()
    try:
        conn.simple_bind_s(userdn, password)
        logging.debug("Bind succeeded for '%s'", username)
    except ldap.LDAPError, e:
        logging.warn("Authentication failed for '%s'", username)
        return False
    res = conn.search_s("CN=Some Group,CN=Users,DC=bluebird,DC=co,DC=za",
                        ldap.SCOPE_BASE, filterstr="(member=%s)" % userdn,
                        attrlist=["member"])
    if len(res) != 1:
        logging.debug("User '%s' is not in the Some Group group", username)
        conn.unbind()
        return False
    logging.debug("User '%s' appears to be in the Some Group group", username)
    conn.unbind() # <- hangs here for 15 minutes.
    logging.debug("Unbound.")
    return True

-- 
Michael Wood <esiotrot at gmail.com>



From rich.megginson at gmail.com  Thu Feb  3 17:16:16 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Thu, 03 Feb 2011 09:16:16 -0700
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
Message-ID: <4D4AD4D0.1010702@gmail.com>

On 02/03/2011 04:34 AM, Michael Wood wrote:
> Hi
>
> I'm trying to do a search against Samba 4's LDAP server and it works,
> but the bind and search are both successful, everything hangs when I
> try to unbind from the LDAP server.  If anyone could enlighten me I
> would be grateful.
>
> I've run into the same issue on various different Linux machines with
> a range of OpenLDAP and python-ldap versions, but it seems to work
> fine on a Mac running Leopard.
>
> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
> python-ldap 2.3.10-1ubuntu1.
>
> I've also tried upgrading python-ldap to 2.3.12, but that does not
> seep to have helped.
Try enabling ldap debug logging - before the first call to 
ldap.initialize, add this:
ldap.set_option(ldap.OPT_DEBUG_LEVEL, 1)

> def test(username, password):
>      base = "DC=example,DC=com"
>      userbase = "CN=Users," + base
>      userdn = "CN=%s,%s" % (username, userbase)
>      ldap_server = "ldap://example.com"
>      conn = ldap.initialize(ldap_server)
>      conn.set_option(ldap.OPT_REFERRALS, 0) # Doesn't appear to make a difference
>      conn.start_tls_s()
>      try:
>          conn.simple_bind_s(userdn, password)
>          logging.debug("Bind succeeded for '%s'", username)
>      except ldap.LDAPError, e:
>          logging.warn("Authentication failed for '%s'", username)
>          return False
>      res = conn.search_s("CN=Some Group,CN=Users,DC=bluebird,DC=co,DC=za",
>                          ldap.SCOPE_BASE, filterstr="(member=%s)" % userdn,
>                          attrlist=["member"])
>      if len(res) != 1:
>          logging.debug("User '%s' is not in the Some Group group", username)
>          conn.unbind()
>          return False
>      logging.debug("User '%s' appears to be in the Some Group group", username)
>      conn.unbind() #<- hangs here for 15 minutes.
>      logging.debug("Unbound.")
>      return True
>




From esiotrot at gmail.com  Thu Feb  3 18:42:38 2011
From: esiotrot at gmail.com (Michael Wood)
Date: Thu, 3 Feb 2011 19:42:38 +0200
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D4AD4D0.1010702@gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
	<4D4AD4D0.1010702@gmail.com>
Message-ID: <AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>

Hi

On 3 February 2011 18:16, Rich Megginson <rich.megginson at gmail.com> wrote:
> On 02/03/2011 04:34 AM, Michael Wood wrote:
>> Hi
>>
>> I'm trying to do a search against Samba 4's LDAP server and it works,
>> but the bind and search are both successful, everything hangs when I
>> try to unbind from the LDAP server. ?If anyone could enlighten me I
>> would be grateful.
>>
>> I've run into the same issue on various different Linux machines with
>> a range of OpenLDAP and python-ldap versions, but it seems to work
>> fine on a Mac running Leopard.
>>
>> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
>> python-ldap 2.3.10-1ubuntu1.
>>
>> I've also tried upgrading python-ldap to 2.3.12, but that does not
>> seep to have helped.
> Try enabling ldap debug logging - before the first call to
> ldap.initialize, add this:
> ldap.set_option(ldap.OPT_DEBUG_LEVEL, 1)

Thanks for the suggestion.  I'll give it a try tomorrow.

In the mean time, someone pointed me at this:

http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6673&selectid=6673&usearchives=1

It did not seem to match my situation because it talks about broken
TCP connections: "When a network connection to the LDAP server fails
(is severed with iptables in my set-up)"

But I thought it was worth a try to recompile OpenLDAP and link with
OpenSSL instead of GnuTLS.

After doing that, the problem went away!

So this seems not to have anything to do with python-ldap.

-- 
Michael Wood <esiotrot at gmail.com>



From michael at stroeder.com  Thu Feb  3 20:31:36 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 03 Feb 2011 20:31:36 +0100
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>	<4D4AD4D0.1010702@gmail.com> <AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
Message-ID: <4D4B0298.1040709@stroeder.com>

Michael Wood wrote:
> On 3 February 2011 18:16, Rich Megginson <rich.megginson at gmail.com> wrote:
>> On 02/03/2011 04:34 AM, Michael Wood wrote:
>>> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
>>> python-ldap 2.3.10-1ubuntu1.
> [..]
> But I thought it was worth a try to recompile OpenLDAP and link with
> OpenSSL instead of GnuTLS.
> 
> After doing that, the problem went away!

That was my first idea when I read that you're using Ubuntu (based on Debian).
There have been so many issues with OpenLDAP linked with GnuTLS during the
last years. I really wonder why the Debian folks force everybody to use this.
IMO that's a major issue with Debian.

Ciao, Michael.

From michael at stroeder.com  Thu Feb  3 20:31:36 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 03 Feb 2011 20:31:36 +0100
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>	<4D4AD4D0.1010702@gmail.com>
	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
Message-ID: <4D4B0298.1040709@stroeder.com>

Michael Wood wrote:
> On 3 February 2011 18:16, Rich Megginson <rich.megginson at gmail.com> wrote:
>> On 02/03/2011 04:34 AM, Michael Wood wrote:
>>> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
>>> python-ldap 2.3.10-1ubuntu1.
> [..]
> But I thought it was worth a try to recompile OpenLDAP and link with
> OpenSSL instead of GnuTLS.
> 
> After doing that, the problem went away!

That was my first idea when I read that you're using Ubuntu (based on Debian).
There have been so many issues with OpenLDAP linked with GnuTLS during the
last years. I really wonder why the Debian folks force everybody to use this.
IMO that's a major issue with Debian.

Ciao, Michael.



From esiotrot at gmail.com  Thu Feb  3 21:05:53 2011
From: esiotrot at gmail.com (Michael Wood)
Date: Thu, 3 Feb 2011 22:05:53 +0200
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D4B0298.1040709@stroeder.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
 <4D4AD4D0.1010702@gmail.com> <AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
 <4D4B0298.1040709@stroeder.com>
Message-ID: <AANLkTi=h+fXRVAmB3tuAE870fqeHyz2GGh5oH_u=MXGW@mail.gmail.com>

Hi

2011/2/3 Michael Str?der <michael at stroeder.com>:
> Michael Wood wrote:
>> On 3 February 2011 18:16, Rich Megginson <rich.megginson at gmail.com> wrote:
>>> On 02/03/2011 04:34 AM, Michael Wood wrote:
>>>> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
>>>> python-ldap 2.3.10-1ubuntu1.
>> [..]
>> But I thought it was worth a try to recompile OpenLDAP and link with
>> OpenSSL instead of GnuTLS.
>>
>> After doing that, the problem went away!
>
> That was my first idea when I read that you're using Ubuntu (based on Debian).
> There have been so many issues with OpenLDAP linked with GnuTLS during the
> last years. I really wonder why the Debian folks force everybody to use this.
> IMO that's a major issue with Debian.

OK, well, next time I'll know.

I suppose it's one way to get GnuTLS to improve :)

The strange thing is that ldapsearch on the command line did not have
the same problem.

Thanks.

-- 
Michael Wood <esiotrot at gmail.com>


From jamesa at daa.com.au  Fri Feb  4 07:32:51 2011
From: jamesa at daa.com.au (James Andrewartha)
Date: Fri, 04 Feb 2011 14:32:51 +0800
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D4B0298.1040709@stroeder.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>	<4D4AD4D0.1010702@gmail.com>	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
	<4D4B0298.1040709@stroeder.com>
Message-ID: <4D4B9D93.5090806@daa.com.au>

On 04/02/11 03:31, Michael Str?der wrote:
> Michael Wood wrote:
>> On 3 February 2011 18:16, Rich Megginson <rich.megginson at gmail.com> wrote:
>>> On 02/03/2011 04:34 AM, Michael Wood wrote:
>>>> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
>>>> python-ldap 2.3.10-1ubuntu1.
>> [..]
>> But I thought it was worth a try to recompile OpenLDAP and link with
>> OpenSSL instead of GnuTLS.
>>
>> After doing that, the problem went away!
> 
> That was my first idea when I read that you're using Ubuntu (based on Debian).
> There have been so many issues with OpenLDAP linked with GnuTLS during the
> last years. I really wonder why the Debian folks force everybody to use this.
> IMO that's a major issue with Debian.

Debian uses GnuTLS because OpenSSL has the non-GPL compatible
advertising clause, and libldap is linked into many GPL applications. So
the solutions are fix the OpenSSL licensing or make GnuTLS not suck; I
have no hope of either occurring.

James Andrewartha




From esiotrot at gmail.com  Fri Feb  4 07:59:04 2011
From: esiotrot at gmail.com (Michael Wood)
Date: Fri, 4 Feb 2011 08:59:04 +0200
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D4B9D93.5090806@daa.com.au>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
	<4D4AD4D0.1010702@gmail.com>
	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
	<4D4B0298.1040709@stroeder.com> <4D4B9D93.5090806@daa.com.au>
Message-ID: <AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>

On 4 February 2011 08:32, James Andrewartha <jamesa at daa.com.au> wrote:
> On 04/02/11 03:31, Michael Str?der wrote:
>> Michael Wood wrote:
>>> On 3 February 2011 18:16, Rich Megginson <rich.megginson at gmail.com> wrote:
>>>> On 02/03/2011 04:34 AM, Michael Wood wrote:
>>>>> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
>>>>> python-ldap 2.3.10-1ubuntu1.
>>> [..]
>>> But I thought it was worth a try to recompile OpenLDAP and link with
>>> OpenSSL instead of GnuTLS.
>>>
>>> After doing that, the problem went away!
>>
>> That was my first idea when I read that you're using Ubuntu (based on Debian).
>> There have been so many issues with OpenLDAP linked with GnuTLS during the
>> last years. I really wonder why the Debian folks force everybody to use this.
>> IMO that's a major issue with Debian.
>
> Debian uses GnuTLS because OpenSSL has the non-GPL compatible
> advertising clause, and libldap is linked into many GPL applications. So

Ah, good point.

> the solutions are fix the OpenSSL licensing or make GnuTLS not suck; I

Or switch to something else.

> have no hope of either occurring.

I understand your lack of hope wrt. the licensing situation and I
suppose switching to another SSL/TLS library is unlikely at this
point.  I do hold out some hope that issues like this in GnuTLS (or in
the software using GnuTLS?) can get fixed, though.

-- 
Michael Wood <esiotrot at gmail.com>



From rich.megginson at gmail.com  Fri Feb  4 16:35:49 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Fri, 04 Feb 2011 08:35:49 -0700
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>	<4D4AD4D0.1010702@gmail.com>	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>	<4D4B0298.1040709@stroeder.com>
	<4D4B9D93.5090806@daa.com.au>
	<AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>
Message-ID: <4D4C1CD5.9000202@gmail.com>

On 02/03/2011 11:59 PM, Michael Wood wrote:
> On 4 February 2011 08:32, James Andrewartha<jamesa at daa.com.au>  wrote:
>> On 04/02/11 03:31, Michael Str?der wrote:
>>> Michael Wood wrote:
>>>> On 3 February 2011 18:16, Rich Megginson<rich.megginson at gmail.com>  wrote:
>>>>> On 02/03/2011 04:34 AM, Michael Wood wrote:
>>>>>> e.g. Ubuntu Lucid Lynx with libldap2-dev version 2.4.21-0ubuntu5.3 and
>>>>>> python-ldap 2.3.10-1ubuntu1.
>>>> [..]
>>>> But I thought it was worth a try to recompile OpenLDAP and link with
>>>> OpenSSL instead of GnuTLS.
>>>>
>>>> After doing that, the problem went away!
>>> That was my first idea when I read that you're using Ubuntu (based on Debian).
>>> There have been so many issues with OpenLDAP linked with GnuTLS during the
>>> last years. I really wonder why the Debian folks force everybody to use this.
>>> IMO that's a major issue with Debian.
>> Debian uses GnuTLS because OpenSSL has the non-GPL compatible
>> advertising clause, and libldap is linked into many GPL applications. So
> Ah, good point.
>
>> the solutions are fix the OpenSSL licensing or make GnuTLS not suck; I
> Or switch to something else.
OpenLDAP 2.4.23 supports Mozilla NSS (triple licensed 
GPLv2+/LGPLv2+/MPL) for crypto
Fedora 14 and later use this instead of OpenSSL
>> have no hope of either occurring.
> I understand your lack of hope wrt. the licensing situation and I
> suppose switching to another SSL/TLS library is unlikely at this
> point.  I do hold out some hope that issues like this in GnuTLS (or in
> the software using GnuTLS?) can get fixed, though.
>




From michael at stroeder.com  Fri Feb  4 17:12:55 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Feb 2011 17:12:55 +0100
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>	<4D4AD4D0.1010702@gmail.com>	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>	<4D4B0298.1040709@stroeder.com> <4D4B9D93.5090806@daa.com.au> <AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>
Message-ID: <4D4C2587.1050408@stroeder.com>

Michael Wood wrote:
> I do hold out some hope that issues like this in GnuTLS (or in
> the software using GnuTLS?) can get fixed, though.

The issues with GnuTLS are known since years now........

I suspect that everybody setting up a serious (Open-)LDAP deployment just
builds with OpenSSL and therefore nobody is using GnuTLS seriously. So nobody
sees a benefit for investing in getting GnuTLS improved.

Ciao, Michael.

From rich.megginson at gmail.com  Fri Feb  4 17:22:31 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Fri, 04 Feb 2011 09:22:31 -0700
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D4C262B.8070706@stroeder.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>	<4D4AD4D0.1010702@gmail.com>	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>	<4D4B0298.1040709@stroeder.com>	<4D4B9D93.5090806@daa.com.au>	<AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com> <4D4C1CD5.9000202@gmail.com> <4D4C262B.8070706@stroeder.com>
Message-ID: <4D4C27C7.9090901@gmail.com>

On 02/04/2011 09:15 AM, Michael Str?der wrote:
> Rich Megginson wrote:
>> OpenLDAP 2.4.23 supports Mozilla NSS (triple licensed
>> GPLv2+/LGPLv2+/MPL) for crypto
>> Fedora 14 and later use this instead of OpenSSL
> I see some benefits using Mozilla NSS especially with LDAP clients. But I
> wonder whether we could use it from python-ldap via OpenLDAP just like Mozilla
> clients use it.
Yes.  I've been using it for a while like that.  For more information: 
http://www.openldap.org/faq/index.cgi?file=1514
> I'm thinking of support for PKCS#11 tokens and adding trusted
> certs.
See the above FAQ - there is some information there about use of tokens 
other than the default builtin softtoken.
> Ciao, Michael.


From michael at stroeder.com  Fri Feb  4 17:15:39 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Feb 2011 17:15:39 +0100
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D4C1CD5.9000202@gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>	<4D4AD4D0.1010702@gmail.com>	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>	<4D4B0298.1040709@stroeder.com>	<4D4B9D93.5090806@daa.com.au>	<AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com> <4D4C1CD5.9000202@gmail.com>
Message-ID: <4D4C262B.8070706@stroeder.com>

Rich Megginson wrote:
> OpenLDAP 2.4.23 supports Mozilla NSS (triple licensed 
> GPLv2+/LGPLv2+/MPL) for crypto
> Fedora 14 and later use this instead of OpenSSL

I see some benefits using Mozilla NSS especially with LDAP clients. But I
wonder whether we could use it from python-ldap via OpenLDAP just like Mozilla
clients use it. I'm thinking of support for PKCS#11 tokens and adding trusted
certs.

Ciao, Michael.

From esiotrot at gmail.com  Sat Feb  5 21:42:59 2011
From: esiotrot at gmail.com (Michael Wood)
Date: Sat, 5 Feb 2011 22:42:59 +0200
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D4C1CD5.9000202@gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
	<4D4AD4D0.1010702@gmail.com>
	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
	<4D4B0298.1040709@stroeder.com> <4D4B9D93.5090806@daa.com.au>
	<AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>
	<4D4C1CD5.9000202@gmail.com>
Message-ID: <AANLkTimZNPHO48=Seayz1ujpNp16KtyPw5XVkoK_3Zus@mail.gmail.com>

Hi

On 4 February 2011 17:35, Rich Megginson <rich.megginson at gmail.com> wrote:
> On 02/03/2011 11:59 PM, Michael Wood wrote:
>>
>> On 4 February 2011 08:32, James Andrewartha<jamesa at daa.com.au> ?wrote:
[...]
>>> Debian uses GnuTLS because OpenSSL has the non-GPL compatible
>>> advertising clause, and libldap is linked into many GPL applications. So
>>
>> Ah, good point.
>>
>>> the solutions are fix the OpenSSL licensing or make GnuTLS not suck; I
>>
>> Or switch to something else.
>
> OpenLDAP 2.4.23 supports Mozilla NSS (triple licensed GPLv2+/LGPLv2+/MPL)
> for crypto
> Fedora 14 and later use this instead of OpenSSL

Interesting.  But co-incidentally, there's a thread currently on the
libcurl mailing list about comparisons between different SSL/TLS libs
that are supported by libcurl.  Howard Chu posted about GnuTLS and
later about NSS.  In the NSS message he said:

"I understand that RedHat is now building their OpenLDAP packages with our
MozNSS support. I don't believe this combination is ready for primetime by any
measure. They still don't even have release quality code for handling PEM
files, and their current experimental code crashes/misbehaves in common (for
OpenSSL) deployment scenarios.

https://bugzilla.mozilla.org/show_bug.cgi?id=402712
https://bugzilla.redhat.com/show_bug.cgi?id=642433"

Here's the link to the message in libcurl's mailing list archive:
http://curl.haxx.se/mail/lib-2011-02/0043.html

-- 
Michael Wood <esiotrot at gmail.com>



From rich.megginson at gmail.com  Mon Feb  7 18:29:59 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Mon, 07 Feb 2011 10:29:59 -0700
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <AANLkTimZNPHO48=Seayz1ujpNp16KtyPw5XVkoK_3Zus@mail.gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
	<4D4AD4D0.1010702@gmail.com>
	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
	<4D4B0298.1040709@stroeder.com> <4D4B9D93.5090806@daa.com.au>
	<AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>
	<4D4C1CD5.9000202@gmail.com>
	<AANLkTimZNPHO48=Seayz1ujpNp16KtyPw5XVkoK_3Zus@mail.gmail.com>
Message-ID: <4D502C17.8010801@gmail.com>

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

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

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

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




From esiotrot at gmail.com  Tue Feb  8 09:10:52 2011
From: esiotrot at gmail.com (Michael Wood)
Date: Tue, 8 Feb 2011 10:10:52 +0200
Subject: python-ldap hanging for 15 minutes under certain conditions
In-Reply-To: <4D502C17.8010801@gmail.com>
References: <AANLkTint5ewDEtoXsCeRwBeNOx0A1sKaFOGfvA_kydPt@mail.gmail.com>
	<4D4AD4D0.1010702@gmail.com>
	<AANLkTikYB0X3VhLHEZN=ixWRYyqbz7oPdp=m4hAD23Go@mail.gmail.com>
	<4D4B0298.1040709@stroeder.com> <4D4B9D93.5090806@daa.com.au>
	<AANLkTi=yAsEh5ky6N40FNE8VS6zUvROVpykh0FN6u3nX@mail.gmail.com>
	<4D4C1CD5.9000202@gmail.com>
	<AANLkTimZNPHO48=Seayz1ujpNp16KtyPw5XVkoK_3Zus@mail.gmail.com>
	<4D502C17.8010801@gmail.com>
Message-ID: <AANLkTinWrRBpDsE2esLoAKQPRtETbWNUaDEB4DwVczM+@mail.gmail.com>

Hi

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

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

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

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

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

OK

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

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

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

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

-- 
Michael Wood <esiotrot at gmail.com>



From michael at stroeder.com  Sat Feb 19 15:52:14 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 19 Feb 2011 15:52:14 +0100
Subject: ANN: python-ldap-2.3.13
Message-ID: <4D5FD91E.9040006@stroeder.com>

Find a new release of python-ldap:

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

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

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

Project's web site:

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

Ciao, Michael.



From michael at stroeder.com  Mon Feb 21 22:29:41 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 21 Feb 2011 22:29:41 +0100
Subject: 2.4.0 patches need review
Message-ID: <4D62D945.4040700@stroeder.com>

HI!

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

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

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

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

Ciao, Michael.

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

From yancey at unt.edu  Tue Feb 22 17:30:41 2011
From: yancey at unt.edu (Yeargan, Yancey)
Date: Tue, 22 Feb 2011 10:30:41 -0600
Subject: LDAP for Python 3.x
Message-ID: <4C2AA1E5-49E9-4CB9-BA2D-EA2EECF70F7A@unt.edu>


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

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

Yancey




From stefanik at dscon.sk  Wed Feb 23 22:06:51 2011
From: stefanik at dscon.sk (Dusan Stefanik)
Date: Wed, 23 Feb 2011 22:06:51 +0100
Subject: LDAP for Python 3.x
Message-ID: <20110223210650.GA22921@portos>


Hi,


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

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

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

Regards,

Dusan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-ldap-2.3.13-py3k.diff
Type: text/x-diff
Size: 25611 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20110223/4c6a7e8c/attachment.diff>

From rich.megginson at gmail.com  Tue Mar  1 21:03:19 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Tue, 01 Mar 2011 13:03:19 -0700
Subject: 2.4.0 patches need review
In-Reply-To: <4D62D945.4040700@stroeder.com>
References: <4D62D945.4040700@stroeder.com>
Message-ID: <4D6D5107.4040407@gmail.com>

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

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

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

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

> So I'd like to encourage all the list readers to checkout CVS HEAD and play
> with it.
>
> Ciao, Michael.
>
> [1]
> http://sourceforge.net/tracker/?func=detail&aid=2829057&group_id=2072&atid=352072
>
> 

From michael at stroeder.com  Tue Mar  1 21:13:14 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 01 Mar 2011 21:13:14 +0100
Subject: 2.4.0 patches need review
In-Reply-To: <4D6D5107.4040407@gmail.com>
References: <4D62D945.4040700@stroeder.com> <4D6D5107.4040407@gmail.com>
Message-ID: <4D6D535A.4090100@stroeder.com>

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

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

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

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

More comments welcome.

Ciao, Michael.

From michael at stroeder.com  Tue Mar  1 21:15:20 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 01 Mar 2011 21:15:20 +0100
Subject: LDAP for Python 3.x
In-Reply-To: <20110223210650.GA22921@portos>
References: <20110223210650.GA22921@portos>
Message-ID: <4D6D53D8.5030704@stroeder.com>

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

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

Ciao, Michael.

From rich.megginson at gmail.com  Tue Mar  1 21:23:41 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Tue, 01 Mar 2011 13:23:41 -0700
Subject: 2.4.0 patches need review
In-Reply-To: <4D6D535A.4090100@stroeder.com>
References: <4D62D945.4040700@stroeder.com> <4D6D5107.4040407@gmail.com> <4D6D535A.4090100@stroeder.com>
Message-ID: <4D6D55CD.5040408@gmail.com>

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


From stefanik at dscon.sk  Wed Mar  2 10:32:18 2011
From: stefanik at dscon.sk (Dusan Stefanik)
Date: Wed, 2 Mar 2011 10:32:18 +0100
Subject: LDAP for Python 3.x
In-Reply-To: <4D6D53D8.5030704@stroeder.com>
References: <20110223210650.GA22921@portos>
 <4D6D53D8.5030704@stroeder.com>
Message-ID: <20110302093218.GC3842@portos>

Hi Michael,

I will try do it.

Dusan


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


From michael at stroeder.com  Thu Mar  3 21:28:34 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 03 Mar 2011 21:28:34 +0100
Subject: please review encode_assertion_control()
Message-ID: <4D6FF9F2.40007@stroeder.com>

HI!

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

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

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

You have to set

extra_compile_args = -g -DLIBLDAP_HAS_ASSERTION_CONTROL_FUNC

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

Ciao, Michael.

From rich.megginson at gmail.com  Thu Mar  3 21:59:38 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Thu, 03 Mar 2011 13:59:38 -0700
Subject: please review encode_assertion_control()
In-Reply-To: <4D6FF9F2.40007@stroeder.com>
References: <4D6FF9F2.40007@stroeder.com>
Message-ID: <4D70013A.3040606@gmail.com>

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

It needs the LDAP* handle because it calls ldap_alloc_ber_with_options() 
to allocate the BER for the control value.
> $ python -c "import ldap;print
> repr(ldap.encode_assertion_control('(objectClass=*)'))"
> Segmentation fault (core dumped)
>
> You have to set
>
> extra_compile_args = -g -DLIBLDAP_HAS_ASSERTION_CONTROL_FUNC
>
> in setup.cfg and have a fairly recent OpenLDAP 2.4 installation to get it
> compiled.
>
> Ciao, Michael.
>
> 

From gregory.faruch at sagemcom.com  Fri Mar  4 11:46:50 2011
From: gregory.faruch at sagemcom.com (Gregory FARUCH)
Date: Fri, 4 Mar 2011 11:46:50 +0100
Subject: Sync State Control question
Message-ID: <24397_1299235615_4D70C31E_24397_100_2_OF6F125240.C9F87166-ONC1257849.00387B0D-C1257849.003B386A@sagemcom.com>


Hello,

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

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

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

Thanks for your answers.





==== THE CODE ====

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

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


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

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

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

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

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

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

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



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

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

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

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

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

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

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


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

  controlType='1.3.6.1.4.1.4203.1.9.1.1'

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

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

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

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

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

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

    return result_header + result_content

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



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

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


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

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

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


==== THE OUTPUT ====


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

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

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

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


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

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


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


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

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

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




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


                               ******

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



From michael at stroeder.com  Fri Mar  4 14:15:02 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2011 14:15:02 +0100
Subject: please review encode_assertion_control()
In-Reply-To: <4D70013A.3040606@gmail.com>
References: <4D6FF9F2.40007@stroeder.com> <4D70013A.3040606@gmail.com>
Message-ID: <4D70E5D6.6090509@stroeder.com>

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

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

Ciao, Michael.

From michael at stroeder.com  Fri Mar  4 14:37:09 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2011 14:37:09 +0100
Subject: please review encode_assertion_control()
In-Reply-To: <4D70E5D6.6090509@stroeder.com>
References: <4D6FF9F2.40007@stroeder.com> <4D70013A.3040606@gmail.com> <4D70E5D6.6090509@stroeder.com>
Message-ID: <4D70EB05.4060308@stroeder.com>

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

Seems calling ldap_create() did the trick:

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

Not sure whether error checking is correct though.

Ciao, Michael.

From michael at stroeder.com  Fri Mar  4 19:45:15 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2011 19:45:15 +0100
Subject: Minimum version of OpenLDAP libs for python-ldap 2.4.x?
Message-ID: <4D71333B.7010105@stroeder.com>

HI!

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

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

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

Ciao, Michael.

From michael at stroeder.com  Fri Mar  4 20:17:44 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 04 Mar 2011 20:17:44 +0100
Subject: Minimum version of OpenLDAP libs for python-ldap 2.4.x?
In-Reply-To: <20110304190253.GM28572@ZenIV.linux.org.uk>
References: <4D71333B.7010105@stroeder.com> <20110304190253.GM28572@ZenIV.linux.org.uk>
Message-ID: <4D713AD8.7060401@stroeder.com>

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

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

RHEL 6 is fairly new.

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

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

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

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

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

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

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

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

Ciao, Michael.

From zhbmaillistonly at gmail.com  Sat Mar  5 04:08:33 2011
From: zhbmaillistonly at gmail.com (Zhang Huangbin)
Date: Sat, 5 Mar 2011 11:08:33 +0800
Subject: Minimum version of OpenLDAP libs for python-ldap 2.4.x?
In-Reply-To: <4D71333B.7010105@stroeder.com>
References: <4D71333B.7010105@stroeder.com>
Message-ID: <27138684-DC07-4915-97E2-7B883D2793E7@gmail.com>


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

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

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

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

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


From michael at stroeder.com  Sat Mar  5 15:19:14 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Sat, 05 Mar 2011 15:19:14 +0100
Subject: Minimum version of OpenLDAP libs for python-ldap 2.4.x?
In-Reply-To: <27138684-DC07-4915-97E2-7B883D2793E7@gmail.com>
References: <4D71333B.7010105@stroeder.com> <27138684-DC07-4915-97E2-7B883D2793E7@gmail.com>
Message-ID: <4D724662.1010404@stroeder.com>

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

Yes.

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

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

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

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

Ciao, Michael.

From chaoseternal at gmail.com  Mon Mar  7 02:14:25 2011
From: chaoseternal at gmail.com (Chaos Eternal)
Date: Mon, 7 Mar 2011 09:14:25 +0800
Subject: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a
	released
In-Reply-To: <alpine.LNX.2.00.1103061908440.26811@cray.glas.net>
References: <alpine.LNX.2.00.1103061908440.26811@cray.glas.net>
Message-ID: <AANLkTikv_QYGgm6XfMzH7XuCvc3iG=RKhu+uD65SnH0B@mail.gmail.com>

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


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

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

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

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

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

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

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

-ilya

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
pyasn1-users mailing list
pyasn1-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyasn1-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20110307/65328e82/attachment.html>

From rich.megginson at gmail.com  Mon Mar  7 18:05:20 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Mon, 07 Mar 2011 10:05:20 -0700
Subject: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a
	released
In-Reply-To: <AANLkTikv_QYGgm6XfMzH7XuCvc3iG=RKhu+uD65SnH0B@mail.gmail.com>
References: <alpine.LNX.2.00.1103061908440.26811@cray.glas.net>
	<AANLkTikv_QYGgm6XfMzH7XuCvc3iG=RKhu+uD65SnH0B@mail.gmail.com>
Message-ID: <4D751050.7050402@gmail.com>

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

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

From rich.megginson at gmail.com  Mon Mar  7 18:10:58 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Mon, 07 Mar 2011 10:10:58 -0700
Subject: Minimum version of OpenLDAP libs for python-ldap 2.4.x?
In-Reply-To: <4D713AD8.7060401@stroeder.com>
References: <4D71333B.7010105@stroeder.com>	<20110304190253.GM28572@ZenIV.linux.org.uk>
	<4D713AD8.7060401@stroeder.com>
Message-ID: <4D7511A2.6070000@gmail.com>

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

From michael at stroeder.com  Mon Mar  7 18:35:19 2011
From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=)
Date: Mon, 07 Mar 2011 18:35:19 +0100
Subject: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a
 released
In-Reply-To: <4D751050.7050402@gmail.com>
References: <alpine.LNX.2.00.1103061908440.26811@cray.glas.net>	<AANLkTikv_QYGgm6XfMzH7XuCvc3iG=RKhu+uD65SnH0B@mail.gmail.com> <4D751050.7050402@gmail.com>
Message-ID: <4D751757.4050404@stroeder.com>

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

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

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

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

Ciao, Michael.

From rich.megginson at gmail.com  Mon Mar  7 18:53:00 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Mon, 07 Mar 2011 10:53:00 -0700
Subject: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a
	released
In-Reply-To: <4D751757.4050404@stroeder.com>
References: <alpine.LNX.2.00.1103061908440.26811@cray.glas.net>	<AANLkTikv_QYGgm6XfMzH7XuCvc3iG=RKhu+uD65SnH0B@mail.gmail.com>
	<4D751050.7050402@gmail.com> <4D751757.4050404@stroeder.com>
Message-ID: <4D751B7C.7010107@gmail.com>

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

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




From michael at stroeder.com  Mon Mar  7 19:19:36 2011
From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=)
Date: Mon, 07 Mar 2011 19:19:36 +0100
Subject: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a
 released
In-Reply-To: <4D751B7C.7010107@gmail.com>
References: <alpine.LNX.2.00.1103061908440.26811@cray.glas.net>	<AANLkTikv_QYGgm6XfMzH7XuCvc3iG=RKhu+uD65SnH0B@mail.gmail.com>	<4D751050.7050402@gmail.com> <4D751757.4050404@stroeder.com> <4D751B7C.7010107@gmail.com>
Message-ID: <4D7521B8.2060000@stroeder.com>

Rich Megginson wrote:
> RHEL does not include pyasn1.  But it is extremely useful for 
> extops/controls - doing BER codec by hand is not fun.

Yupp!

>  A mid-way 
> approach would be to expose the liblber ber_scanf/ber_printf and support 
> functions in python.

Also an idea we already had. But I'm not a C programmer. So I'll stay away
from that myself.

But I will happily add a nice Python layer on top of your code. ;-}
Make the C wrapper code as lean as possible.

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

Noted.

Ciao, Michael.

From rich.megginson at gmail.com  Mon Mar  7 19:33:01 2011
From: rich.megginson at gmail.com (Rich Megginson)
Date: Mon, 07 Mar 2011 11:33:01 -0700
Subject: Fwd: [pyasn1-users] ANN: pyasn1-0.0.13a & pyasn1-modules-0.0.1a
 released
In-Reply-To: <4D7521B8.2060000@stroeder.com>
References: <alpine.LNX.2.00.1103061908440.26811@cray.glas.net>	<AANLkTikv_QYGgm6XfMzH7XuCvc3iG=RKhu+uD65SnH0B@mail.gmail.com>	<4D751050.7050402@gmail.com> <4D751757.4050404@stroeder.com> <4D751B7C.7010107@gmail.com> <4D7521B8.2060000@stroeder.com>
Message-ID: <4D7524DD.8070504@gmail.com>

On 03/07/2011 11:19 AM, Michael Str?der wrote:
> Rich Megginson wrote:
>> RHEL does not include pyasn1.  But it is extremely useful for
>> extops/controls - doing BER codec by hand is not fun.
> Yupp!
>
>>   A mid-way
>> approach would be to expose the liblber ber_scanf/ber_printf and support
>> functions in python.
> Also an idea we already had. But I'm not a C programmer. So I'll stay away
> from that myself.
>
> But I will happily add a nice Python layer on top of your code. ;-}
> Make the C wrapper code as lean as possible.
The biggest problem I see is how to pass in arguments to the varadic 
functions ber_scanf and ber_printf from python without completely 
rewriting those functions to accept an array of format specifiers and a 
corresponding array of values/pointers.  It may be easier to just bite 
the bullet and add pyasn1 . . .
>> If you do decide that it is necessary for python-ldap to use pyasn1, we
>> can work on getting it into RHEL.  The Fedora python-pyasn1 maintainer
>> is one of the guys on the freeipa team which uses python-ldap heavily.
> Noted.
>
> Ciao, Michael.


From vanmeeuwen at kolabsys.com  Fri Mar 11 12:06:08 2011
From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems))
Date: Fri, 11 Mar 2011 11:06:08 +0000
Subject: python-ldap as replication client
Message-ID: <201103111106.10017.vanmeeuwen@kolabsys.com>

Hello dear list members,

Please allow me to thank you and shortly introduce myself as I'm new to the 
list; My name is Jeroen van Meeuwen, I'm Dutch and I live in the United 
Kingdom, where I work for a Swiss company in Free Software groupware 
solutions, Kolab Systems.

I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to python-ldap's 
ldap.controls, and while I do have some experience in several areas, 
admittedly compared to you I'm probably the most under-qualified programmer to 
actually do it.

That said, I first wanted to ask whether something like python-ldap becoming a 
replication client (through server controls) was feasible in your opinion(s). 
I think RFC 3928[1] is the corresponding standard. Another standard was 
proposed in RFC 4533[2] but that one bounced in favor of the former.

Thanks in advance,

Kind regards,

Jeroen van Meeuwen

[1] http://tools.ietf.org/html/rfc3928
[2] http://tools.ietf.org/html/rfc4533

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20110311/0104ca89/attachment.html>

From michael at stroeder.com  Fri Mar 11 13:40:00 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 11 Mar 2011 13:40:00 +0100
Subject: python-ldap as replication client
In-Reply-To: <201103111106.10017.vanmeeuwen@kolabsys.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>
Message-ID: <4D7A1820.1010304@stroeder.com>

Jeroen van Meeuwen (Kolab Systems) wrote:
> I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to
> python-ldap's ldap.controls, and while I do have some experience in
> several areas, admittedly compared to you I'm probably the most
> under-qualified programmer to actually do it.

You're always welcome to send demo code and get it commented here.

> That said, I first wanted to ask whether something like python-ldap
> becoming a replication client (through server controls) was feasible in
> your opinion(s).

No matter which sync protocol you implement it's very likely that you need
python-LDAP from CVS HEAD (will be python 2.4) since this version contains
code to extract response controls from intermediate responses. Beware that
this may still be subject of API changes especially regarding ldap.controls
and ldap.extop.

Some additional ASN.1 work for encoding/decoding controls is needed too. I'm
currently using pyasn1.sf.net for that which is outside python-ldap.

> I think RFC 3928[1] is the corresponding standard.
> Another standard was proposed in RFC 4533[2] but that one bounced in
> favor of the former.

Which sync protocol standard suits your needs depends on the LDAP server your
application is talking to.

If you use the OpenLDAP server the OpenLDAP developers strongly recommend
syncrepl. There were already some people here implementing syncrepl (RFC 4533)
based on python-ldap.

Personally I'm currently using LDAP persistent search retrieving data from a
Novell eDirectory server since this is the control this server supports.

Other LDAP servers have other sync controls, e.g. MS AD implemented the
proprietary DirSync control, etc.

Ciao, Michael.

From vanmeeuwen at kolabsys.com  Fri Mar 11 15:03:42 2011
From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems))
Date: Fri, 11 Mar 2011 14:03:42 +0000
Subject: python-ldap as replication client
In-Reply-To: <4D7A1820.1010304@stroeder.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com> <4D7A1820.1010304@stroeder.com>
Message-ID: <201103111403.45382.vanmeeuwen@kolabsys.com>

Michael Str?der wrote:
> Jeroen van Meeuwen (Kolab Systems) wrote:
> > I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to
> > python-ldap's ldap.controls, and while I do have some experience in
> > several areas, admittedly compared to you I'm probably the most
> > under-qualified programmer to actually do it.
> 
> You're always welcome to send demo code and get it commented here.
> 

Thanks! I feel all warm and fuzzy and welcome ;-)

> > That said, I first wanted to ask whether something like python-ldap
> > becoming a replication client (through server controls) was feasible in
> > your opinion(s).
> 
> No matter which sync protocol you implement it's very likely that you need
> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
> code to extract response controls from intermediate responses. Beware that
> this may still be subject of API changes especially regarding ldap.controls
> and ldap.extop.
> 

Sure, that is fair enough. I was planning on doing any work based on CVS HEAD 
anyways, as I always consider it easier to upgrade (too) late then it is to 
stick with a modified, unsupported version forever ;-)

> Some additional ASN.1 work for encoding/decoding controls is needed too.
> I'm currently using pyasn1.sf.net for that which is outside python-ldap.
> 
> > I think RFC 3928[1] is the corresponding standard.
> > Another standard was proposed in RFC 4533[2] but that one bounced in
> > favor of the former.
> 
> Which sync protocol standard suits your needs depends on the LDAP server
> your application is talking to.
> 
> If you use the OpenLDAP server the OpenLDAP developers strongly recommend
> syncrepl. There were already some people here implementing syncrepl (RFC
> 4533) based on python-ldap.
> 

I'd be very interested in this work. Do you have a reference, perhaps? I can 
find some coversations on the topic, but no code / show-case implementation.

That said, it's interesting people have implemented this based on RFC 4533; 
Would you agree or disagree implementing the superseeded may actually be a bad 
thing to do for python-ldap, or would you wish any such implementation to be 
compatible with 4533 as well, somehow?

> Personally I'm currently using LDAP persistent search retrieving data from
> a Novell eDirectory server since this is the control this server supports.
> 

I'm successfully using the paging search results control[1] (against python-
ldap version 2.3.10) against a (simulated) very large LDAP tree, after which I 
realized this type of iteration does in no way apply any changes to the tree 
as instantly as the daemon being a replication client.

> Other LDAP servers have other sync controls, e.g. MS AD implemented the
> proprietary DirSync control, etc.
> 

I'll stick to the Free and RFC compatible for now, if that's OK with you? ;-)

Kind regards,

Jeroen van Meeuwen

[1] http://git.kolab.org/pykolab/tree/pykolab/auth/ldap/__init__.py#n150

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20110311/71a463ed/attachment.html>

From brunson at brunson.com  Fri Mar 11 18:25:47 2011
From: brunson at brunson.com (Eric Brunson)
Date: Fri, 11 Mar 2011 10:25:47 -0700
Subject: python-ldap as replication client
In-Reply-To: <4D7A1820.1010304@stroeder.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>
	<4D7A1820.1010304@stroeder.com>
Message-ID: <4D7A5B1B.3010504@brunson.com>

On 03/11/2011 05:40 AM, Michael Str?der wrote:
> Jeroen van Meeuwen (Kolab Systems) wrote:
>> I'm looking to implement LDAP_CONTROL_SYNC(*) capabilities to
>> python-ldap's ldap.controls, and while I do have some experience in
>> several areas, admittedly compared to you I'm probably the most
>> under-qualified programmer to actually do it.
> You're always welcome to send demo code and get it commented here.
>
>> That said, I first wanted to ask whether something like python-ldap
>> becoming a replication client (through server controls) was feasible in
>> your opinion(s).
> No matter which sync protocol you implement it's very likely that you need
> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
> code to extract response controls from intermediate responses. Beware that
> this may still be subject of API changes especially regarding ldap.controls
> and ldap.extop.
>
> Some additional ASN.1 work for encoding/decoding controls is needed too. I'm
> currently using pyasn1.sf.net for that which is outside python-ldap.
>
>> I think RFC 3928[1] is the corresponding standard.
>> Another standard was proposed in RFC 4533[2] but that one bounced in
>> favor of the former.
> Which sync protocol standard suits your needs depends on the LDAP server your
> application is talking to.
>
> If you use the OpenLDAP server the OpenLDAP developers strongly recommend
> syncrepl. There were already some people here implementing syncrepl (RFC 4533)
> based on python-ldap.

I'm currently working on a project that requires me to do a syncrepl 
from python and after much, much reading I'm afraid that the python-ldap 
library does not implement 4533 correctly.

Sync cookies are only retrieved by python-ldap if they are returned in a 
server control, however this is only the case in an 
LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The 
protocol passes both deletes and presence records in 
LDAP_RES_INTERMEDIATE packets, which don't get returned to the python 
caller as they don't have LDAP entries in them, and cookies are also 
returned in these intermediate result packets, but not in a server 
control, so those are missed.

To see the proper handling of the syncrepl protocol it's instructional 
to read through the do_syncrep2 found in the file 
servers/slapd/syncrepl.c of the openldap source.  I'm working on moving 
that code over to a new function in the python-ldap module, but I'm not 
sure whether my company is going to allow me to release the code back to 
the project.  If I do it, they probably will.  If we pay someone else to 
do it, possibly not.

In any case, a python-LDAP syncrepl client can be made to work, but if 
there are deletes during a period when the client is not connected I 
believe they will be lost during the catchup phase of the sync.

I'm certainly not an OpenLDAP nor a python-LDAP expert, so if I'm 
mistaken about anything I've said above, please feel free to set me 
straight.  I just thought it would be good to share the caveat as I 
understand it.

Sincerely,
e.

> Personally I'm currently using LDAP persistent search retrieving data from a
> Novell eDirectory server since this is the control this server supports.
>
> Other LDAP servers have other sync controls, e.g. MS AD implemented the
> proprietary DirSync control, etc.
>
> Ciao, Michael.
>
> 

From michael at stroeder.com  Fri Mar 11 19:00:58 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 11 Mar 2011 19:00:58 +0100
Subject: python-ldap as replication client
In-Reply-To: <4D7A5B1B.3010504@brunson.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>	<4D7A1820.1010304@stroeder.com> <4D7A5B1B.3010504@brunson.com>
Message-ID: <4D7A635A.40303@stroeder.com>

Eric Brunson wrote:
> On 03/11/2011 05:40 AM, Michael Str?der wrote:
>> No matter which sync protocol you implement it's very likely that you need
>> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
>> code to extract response controls from intermediate responses.
> 
> I'm currently working on a project that requires me to do a syncrepl 
> from python and after much, much reading I'm afraid that the python-ldap 
> library does not implement 4533 correctly.
> 
> Sync cookies are only retrieved by python-ldap if they are returned in a 
> server control, however this is only the case in an 
> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The 
> protocol passes both deletes and presence records in 
> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python 
> caller as they don't have LDAP entries in them, and cookies are also 
> returned in these intermediate result packets, but not in a server 
> control, so those are missed.

The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
possible with python-ldap. If you think the current implementation in CVS HEAD
still has deficiencies regarding controls in intermediate responses I happily
will review a patch. ;-)

Ciao, Michael.

From brunson at brunson.com  Fri Mar 11 19:23:35 2011
From: brunson at brunson.com (Eric Brunson)
Date: Fri, 11 Mar 2011 11:23:35 -0700
Subject: python-ldap as replication client
In-Reply-To: <4D7A635A.40303@stroeder.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>	<4D7A1820.1010304@stroeder.com> <4D7A5B1B.3010504@brunson.com> <4D7A635A.40303@stroeder.com>
Message-ID: <4D7A68A7.6050807@brunson.com>

On 03/11/2011 11:00 AM, Michael Str?der wrote:
> Eric Brunson wrote:
>> On 03/11/2011 05:40 AM, Michael Str?der wrote:
>>> No matter which sync protocol you implement it's very likely that you need
>>> python-LDAP from CVS HEAD (will be python 2.4) since this version contains
>>> code to extract response controls from intermediate responses.
>> I'm currently working on a project that requires me to do a syncrepl
>> from python and after much, much reading I'm afraid that the python-ldap
>> library does not implement 4533 correctly.
>>
>> Sync cookies are only retrieved by python-ldap if they are returned in a
>> server control, however this is only the case in an
>> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The
>> protocol passes both deletes and presence records in
>> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python
>> caller as they don't have LDAP entries in them, and cookies are also
>> returned in these intermediate result packets, but not in a server
>> control, so those are missed.
> The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
> possible with python-ldap. If you think the current implementation in CVS HEAD
> still has deficiencies regarding controls in intermediate responses I happily
> will review a patch. ;-)

Wow, Michael, that is super awesome news.  I'll check the CVS head, try 
it out and get back to you.

Sincerely,
e.


From michael at stroeder.com  Fri Mar 11 19:24:54 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 11 Mar 2011 19:24:54 +0100
Subject: python-ldap as replication client
In-Reply-To: <4D7A68A7.6050807@brunson.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>	<4D7A1820.1010304@stroeder.com> <4D7A5B1B.3010504@brunson.com> <4D7A635A.40303@stroeder.com> <4D7A68A7.6050807@brunson.com>
Message-ID: <4D7A68F6.7090200@stroeder.com>

Eric Brunson wrote:
> On 03/11/2011 11:00 AM, Michael Str?der wrote:
>> Eric Brunson wrote:
>>> On 03/11/2011 05:40 AM, Michael Str?der wrote:
>>>> No matter which sync protocol you implement it's very likely that
>>>> you need
>>>> python-LDAP from CVS HEAD (will be python 2.4) since this version
>>>> contains
>>>> code to extract response controls from intermediate responses.
>>> I'm currently working on a project that requires me to do a syncrepl
>>> from python and after much, much reading I'm afraid that the python-ldap
>>> library does not implement 4533 correctly.
>>>
>>> Sync cookies are only retrieved by python-ldap if they are returned in a
>>> server control, however this is only the case in an
>>> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The
>>> protocol passes both deletes and presence records in
>>> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python
>>> caller as they don't have LDAP entries in them, and cookies are also
>>> returned in these intermediate result packets, but not in a server
>>> control, so those are missed.
>> The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
>> possible with python-ldap. If you think the current implementation in
>> CVS HEAD
>> still has deficiencies regarding controls in intermediate responses I
>> happily
>> will review a patch. ;-)
> 
> Wow, Michael, that is super awesome news.  I'll check the CVS head, try
> it out and get back to you.

Make sure to set the right arguments for LDAPObject.result4().

Ciao, Michael.

From rahul at synovel.com  Fri Mar 18 07:18:29 2011
From: rahul at synovel.com (Rahul Amaram)
Date: Fri, 18 Mar 2011 11:48:29 +0530
Subject: Modifying multiple dns with a single function call
Message-ID: <4D82F935.9060501@synovel.com>

Hi,
I would like to know if it possible to modify multiple dns at once i.e. 
via a single modify_s request.

I might need to update about 10,000 entries and I was wondering about 
the best way to do this.

Any suggestions/feedback on how best this could be achieved using 
python-ldap would be very useful.

Thanks,
Rahul.



From michael at stroeder.com  Fri Mar 18 10:55:56 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 18 Mar 2011 10:55:56 +0100
Subject: Modifying multiple dns with a single function call
In-Reply-To: <4D82F935.9060501@synovel.com>
References: <4D82F935.9060501@synovel.com>
Message-ID: <4D832C2C.3060403@stroeder.com>

Rahul Amaram wrote:
> I would like to know if it possible to modify multiple dns at once i.e. 
> via a single modify_s request.

Yes, if you mean (multiple) DN-valued attribute values in a single entry.

No, if you mean the DNs of multiple entries.

> I might need to update about 10,000 entries and I was wondering about 
> the best way to do this.

One by one...

This can get tricky if you have a hierarchy of DNs and you have to rename
superior entries.

Ciao, Michael.

From rahul at synovel.com  Fri Mar 18 13:16:22 2011
From: rahul at synovel.com (Rahul Amaram)
Date: Fri, 18 Mar 2011 17:46:22 +0530
Subject: Modifying multiple dns with a single function call
In-Reply-To: <4D832C2C.3060403@stroeder.com>
References: <4D82F935.9060501@synovel.com> <4D832C2C.3060403@stroeder.com>
Message-ID: <4D834D16.5030909@synovel.com>

I am looking for something like this.

dn: cn=User1,dc=example,dc=com
changetype: modify
replace: mail
mail: user1 at example.com

dn: cn=User2,dc=example,dc=com
changetype: modify
replace: mail
mail: user2 at example.com

dn: cn=User3,dc=example,dc=com
changetype: modify
replace: mail
mail: user3 at example.com

I want to make all the above changes with a single function call. Is 
this possible or should I call modify_s once for each dn entry?

Regards,
Rahul.

On Friday 18 March 2011 03:25 PM, Michael Str?der wrote:
> Rahul Amaram wrote:
>> I would like to know if it possible to modify multiple dns at once i.e.
>> via a single modify_s request.
>
> Yes, if you mean (multiple) DN-valued attribute values in a single entry.
>
> No, if you mean the DNs of multiple entries.
>
>> I might need to update about 10,000 entries and I was wondering about
>> the best way to do this.
>
> One by one...
>
> This can get tricky if you have a hierarchy of DNs and you have to rename
> superior entries.
>
> Ciao, Michael.



From michael at stroeder.com  Fri Mar 18 13:49:24 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Fri, 18 Mar 2011 13:49:24 +0100
Subject: Modifying multiple dns with a single function call
In-Reply-To: <4D834D16.5030909@synovel.com>
References: <4D82F935.9060501@synovel.com> <4D832C2C.3060403@stroeder.com> <4D834D16.5030909@synovel.com>
Message-ID: <4D8354D4.4040604@stroeder.com>

Rahul Amaram wrote:
> I am looking for something like this.
> 
> dn: cn=User1,dc=example,dc=com
> changetype: modify
> replace: mail
> mail: user1 at example.com
> 
> dn: cn=User2,dc=example,dc=com
> changetype: modify
> replace: mail
> mail: user2 at example.com
> 
> dn: cn=User3,dc=example,dc=com
> changetype: modify
> replace: mail
> mail: user3 at example.com
> 
> I want to make all the above changes with a single function call. Is 
> this possible

No.

> or should I call modify_s once for each dn entry?

Yes.

Ciao, Michael.

From michael at stroeder.com  Mon Mar 21 19:48:06 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Mon, 21 Mar 2011 19:48:06 +0100
Subject: Roadmap for python-ldap 2.4
Message-ID: <4D879D66.4010802@stroeder.com>

HI!

I'd like to get final release 2.4.0 out begin of May and I'm currently
thinking of what should still to be added. Focus is still Python 2.x.

There are some considerations which I'm not sure about yet:

1. Unicode support for DNs, filter strings, etc. but not entry attributes!
(Everybody asking for the latter should check the mailing list archive first.)

2. Split LDAPControl into separate classes LDAPRequestControl and
LDAPResponseControl.

3. OID-based registry especially for response controls so they can be decoded
on-the-fly when received before being returned to the calling application.

4. Use module logging for debug trace messages. I've already added the *very*
simple sub-module ldap.logger.

5. Use pyasn1 to implement more controls and extended operations.

Input welcome.

Ciao, Michael.

From brunson at brunson.com  Tue Mar 22 21:59:05 2011
From: brunson at brunson.com (Eric Brunson)
Date: Tue, 22 Mar 2011 14:59:05 -0600
Subject: python-ldap as replication client
In-Reply-To: <4D7A68F6.7090200@stroeder.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>	<4D7A1820.1010304@stroeder.com> <4D7A5B1B.3010504@brunson.com> <4D7A635A.40303@stroeder.com> <4D7A68A7.6050807@brunson.com> <4D7A68F6.7090200@stroeder.com>
Message-ID: <4D890D99.8050003@brunson.com>

On 03/11/2011 11:24 AM, Michael Str?der wrote:
> Eric Brunson wrote:
>> On 03/11/2011 11:00 AM, Michael Str?der wrote:
>>> Eric Brunson wrote:
>>>> On 03/11/2011 05:40 AM, Michael Str?der wrote:
>>>>> No matter which sync protocol you implement it's very likely that
>>>>> you need
>>>>> python-LDAP from CVS HEAD (will be python 2.4) since this version
>>>>> contains
>>>>> code to extract response controls from intermediate responses.
>>>> I'm currently working on a project that requires me to do a syncrepl
>>>> from python and after much, much reading I'm afraid that the python-ldap
>>>> library does not implement 4533 correctly.
>>>>
>>>> Sync cookies are only retrieved by python-ldap if they are returned in a
>>>> server control, however this is only the case in an
>>>> LDAP_RES_SEARCH_RESULT or an LDAP_RES_SEARCH_ENTRY packets.  The
>>>> protocol passes both deletes and presence records in
>>>> LDAP_RES_INTERMEDIATE packets, which don't get returned to the python
>>>> caller as they don't have LDAP entries in them, and cookies are also
>>>> returned in these intermediate result packets, but not in a server
>>>> control, so those are missed.
>>> The patches in CVS HEAD were contributed by Rich exactly to make syncrepl
>>> possible with python-ldap. If you think the current implementation in
>>> CVS HEAD
>>> still has deficiencies regarding controls in intermediate responses I
>>> happily
>>> will review a patch. ;-)
>> Wow, Michael, that is super awesome news.  I'll check the CVS head, try
>> it out and get back to you.
> Make sure to set the right arguments for LDAPObject.result4().
>
> Ciao, Michael.

Michael and all,

The new code works great, thanks so much for the new features.

I do have one issue, and maybe I'm just not looking in the correct 
place.  The Sync Info Message returns a syncInfoValue which is a BER 
encoded ASN.1 CHOICE structure:

    syncInfoValue ::= CHOICE {
               newcookie      [0] syncCookie,
               refreshDelete  [1] SEQUENCE {
                   cookie         syncCookie OPTIONAL,
                   refreshDone    BOOLEAN DEFAULT TRUE
               },
               refreshPresent [2] SEQUENCE {
                   cookie         syncCookie OPTIONAL,
                   refreshDone    BOOLEAN DEFAULT TRUE
               },
               syncIdSet      [3] SEQUENCE {
                   cookie         syncCookie OPTIONAL,
                   refreshDeletes BOOLEAN DEFAULT FALSE,
                   syncUUIDs      SET OF syncUUID
               }
           }

The data is returned and I've been able to successfully decode it with 
the PyASN1 BER codec, but I can't find any indication of the choice 
index being returned in the value.   I don't know that the refreshDelete 
and the refreshPresent are distinguishable from each other without 
additional information, but I see that the value being returned from 
result4() is simply what ldap_parse_intermediate() returns, without any 
indication of the choice index.  Looking at the raw BER encoded packet 
in wireshark, it would seem that the two bytes before the data being 
returned have the index embedded in the second byte.

I'm sure this must simply be something I'm overlooking.  Any help?

Thanks,
e.

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

From michael at stroeder.com  Wed Mar 23 08:11:59 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Wed, 23 Mar 2011 08:11:59 +0100
Subject: python-ldap as replication client
In-Reply-To: <4D890D99.8050003@brunson.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>	<4D7A1820.1010304@stroeder.com> <4D7A5B1B.3010504@brunson.com> <4D7A635A.40303@stroeder.com> <4D7A68A7.6050807@brunson.com> <4D7A68F6.7090200@stroeder.com> <4D890D99.8050003@brunson.com>
Message-ID: <4D899D3F.3080707@stroeder.com>

Eric Brunson wrote:
> The new code works great, thanks so much for the new features.
> 
> I do have one issue, and maybe I'm just not looking in the correct
> place.  The Sync Info Message returns a syncInfoValue which is a BER
> encoded ASN.1 CHOICE structure:
> 
>     syncInfoValue ::= CHOICE {
>               newcookie      [0] syncCookie,
>               refreshDelete  [1] SEQUENCE {
>                   cookie         syncCookie OPTIONAL,
>                   refreshDone    BOOLEAN DEFAULT TRUE
>               },
>               refreshPresent [2] SEQUENCE {
>                   cookie         syncCookie OPTIONAL,
>                   refreshDone    BOOLEAN DEFAULT TRUE
>               },
>               syncIdSet      [3] SEQUENCE {
>                   cookie         syncCookie OPTIONAL,
>                   refreshDeletes BOOLEAN DEFAULT FALSE,
>                   syncUUIDs      SET OF syncUUID
>               }
>           }
> 
> The data is returned and I've been able to successfully decode it with
> the PyASN1 BER codec, but I can't find any indication of the choice
> index being returned in the value.   I don't know that the refreshDelete
> and the refreshPresent are distinguishable from each other without
> additional information, but I see that the value being returned from
> result4() is simply what ldap_parse_intermediate() returns, without any
> indication of the choice index.  Looking at the raw BER encoded packet
> in wireshark, it would seem that the two bytes before the data being
> returned have the index embedded in the second byte.
> 
> I'm sure this must simply be something I'm overlooking.  Any help?

Could you share a short script demonstrating this?

Ciao, Michael.

From brunson at brunson.com  Wed Mar 23 17:38:33 2011
From: brunson at brunson.com (Eric Brunson)
Date: Wed, 23 Mar 2011 10:38:33 -0600
Subject: python-ldap as replication client
In-Reply-To: <4D899D3F.3080707@stroeder.com>
References: <201103111106.10017.vanmeeuwen@kolabsys.com>	<4D7A1820.1010304@stroeder.com> <4D7A5B1B.3010504@brunson.com> <4D7A635A.40303@stroeder.com> <4D7A68A7.6050807@brunson.com> <4D7A68F6.7090200@stroeder.com> <4D890D99.8050003@brunson.com> <4D899D3F.3080707@stroeder.com>
Message-ID: <4D8A2209.1090701@brunson.com>

On 03/23/2011 01:11 AM, Michael Str?der wrote:
> Eric Brunson wrote:
>> The new code works great, thanks so much for the new features.
>>
>> I do have one issue, and maybe I'm just not looking in the correct
>> place.  The Sync Info Message returns a syncInfoValue which is a BER
>> encoded ASN.1 CHOICE structure:
>>
>>      syncInfoValue ::= CHOICE {
>>                newcookie      [0] syncCookie,
>>                refreshDelete  [1] SEQUENCE {
>>                    cookie         syncCookie OPTIONAL,
>>                    refreshDone    BOOLEAN DEFAULT TRUE
>>                },
>>                refreshPresent [2] SEQUENCE {
>>                    cookie         syncCookie OPTIONAL,
>>                    refreshDone    BOOLEAN DEFAULT TRUE
>>                },
>>                syncIdSet      [3] SEQUENCE {
>>                    cookie         syncCookie OPTIONAL,
>>                    refreshDeletes BOOLEAN DEFAULT FALSE,
>>                    syncUUIDs      SET OF syncUUID
>>                }
>>            }
>>
>> The data is returned and I've been able to successfully decode it with
>> the PyASN1 BER codec, but I can't find any indication of the choice
>> index being returned in the value.   I don't know that the refreshDelete
>> and the refreshPresent are distinguishable from each other without
>> additional information, but I see that the value being returned from
>> result4() is simply what ldap_parse_intermediate() returns, without any
>> indication of the choice index.  Looking at the raw BER encoded packet
>> in wireshark, it would seem that the two bytes before the data being
>> returned have the index embedded in the second byte.
>>
>> I'm sure this must simply be something I'm overlooking.  Any help?
> Could you share a short script demonstrating this?

I've done some more reading and I think I'm mistaken about there being 
some sort of index indicating the type of choice that was encoded.  The 
documentation for the PyASN library implies that the decoder has to 
infer the choice based on the structure of the data, which seems odd.

Thanks for the reply, I'll get back to you when I figure something out.

e.


From michael at stroeder.com  Tue Mar 29 10:37:52 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Tue, 29 Mar 2011 10:37:52 +0200
Subject: ldap.controls in python-ldap 2.4
Message-ID: <4D919A60.6070306@stroeder.com>

HI!

Since I'm working more with LDAPv3 controls now I've cleaned up sub-module
ldap.controls. Still work in progress...

Unfortunately it would be too cumbersome to maintain backward compability. So
python-ldap 2.4 will very likely break applications working with LDAPv3
controls. My application code will also be heavily affected.

I can understand that this will make many people unhappy. But IMO it's the
only way to clean up this mess and come up with a much more convenient API for
dealing with controls. Better to do it now than later.

Ciao, Michael.

From bob at brandt.ie  Thu Mar 31 12:51:52 2011
From: bob at brandt.ie (Bob Brandt)
Date: Thu, 31 Mar 2011 11:51:52 +0100
Subject: Load Balance and Redundant LDAP config
Message-ID: <AANLkTik+vOU0Ne5APpS0bBqFtFBWAJ5_aqO99R57R1TT@mail.gmail.com>

I apologize if this is not the right place to ask this question...

I am looking to modify my LDAP scripts to be both Redundant and Load
Balancing!

For example I have a RADIUS server which runs a python script to retrieve
user's attributes from LDAP once they are authenticated.

Right now, I have a script that has a list of LDAP servers and uses the
first one that responses, but the problem is all later requests, use that
single LDAP server. If that server were to fail, the script fails.

I guess my main question is: Is there a preferred method of supplying
Redundancy and/or Load Balancing? (I don't really want to reinvent the
wheel)

However, if I must reinvent the wheel, I am thinking along the lines of
opening multiple connections the each server and programmically switching
between thed different connections as they come up.

Does this sound right? Any suggestions?

Thanks
Bob



-- 
What's the point of having a rapier wit if I can't use it to stab people? -
Jeph Jacques
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20110331/6e3987ea/attachment.html>

From michael at stroeder.com  Thu Mar 31 21:23:04 2011
From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Date: Thu, 31 Mar 2011 21:23:04 +0200
Subject: ldap.controls in python-ldap 2.4
In-Reply-To: <4D919A60.6070306@stroeder.com>
References: <4D919A60.6070306@stroeder.com>
Message-ID: <4D94D498.7040203@stroeder.com>

Michael Str?der wrote:
> Since I'm working more with LDAPv3 controls now I've cleaned up sub-module
> ldap.controls. Still work in progress...

Now I've checked in the modifications and updated Demo/page_control.py to make
use of the slightly new API. Also some related constants' names are now
aligned with OpenLDAP's ldap.h. Please check out HEAD and comment.

Ciao, Michael.