python-ldap-dev Mailing List for python-ldap (Page 42)

Yes, we did it !

My test case is working with your CVS !
I put it at the end.

And what about the idea to put the

try:
except ldap.SERVER_DOWN,e:
   SimpleLDAPObject.unbind_s(self)

in the function _ldap_call too ?
This will correct also SimpleLDAPObject ?


import sys, os, time
import ldap, ldapurl

host=3D'localhost'
port=3D389
who=3D'cn=3Dnobody,cn=3Dinternal,dc=3Dasxnet,dc=3Dloc'
cred=3D'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc'
dn=3D'dc=3Dasxnet,dc=3Dloc'

def ldap_service(action):
    os.system('/kolab/bin/openpkg rc openldap %s' % action)
    if action.endswith('start'):
        time.sleep(1)

def check_connection():
    whoami=3Dl.whoami_s()
    print 'whoami', whoami
    # this search dont give any result as anonymous, but well if
loggged as nobody
    #result=3Dl.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE,
"(member=3Dcn=3Ddomain.maintainer
mydomain.loc,cn=3Dinternal,dc=3Dasxnet,dc=3Dloc)")
    #print 'search', result

ldap_url=3Dldapurl.LDAPUrl('ldap://%s:%d/%s' % (host, port, dn))
ldap_url.applyDefaults({
    'who': who,
    'cred' : cred, })

# to be sure the server is up
ldap_service('stop')
ldap_service('start')

l=3Dldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl(),1) # I
dont use ReconnectLDAPObject !
l.simple_bind_s(ldap_url.who, ldap_url.cred)
check_connection()

print 'Wait 120s'
time.sleep(120)
check_connection()

print 'restart service'
ldap_service('stop')
ldap_service('start')
check_connection()

print 'stop service'
ldap_service('stop')
try:
    check_connection()
except ldap.SERVER_DOWN:
    print 'check failed, OK'

print 'restart service'
ldap_service('start')
check_connection()




On 1/27/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> >
> > The problem is the failed statement has initiated a new connection
> > (when the server is down)
> > calling initialize (that doesn't fail) and bind that fail but is in a
> > try: except:  block in ReconnectLDAPObject.reconnect() !
> > Then the server restart and the next statement get advantages of the
> > work done initialize
>
> Yes. Inspired by you mentioning libldap I remembered that unbind_s()
> should be called when handling ldap.SERVER_DOWN exception to completely
> drop the whole connection context.
>
> Please test the version I've committed some minutes ago.
> Thanks again.
>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Alain Spineux wrote:
> 
> The problem is the failed statement has initiated a new connection
> (when the server is down)
> calling initialize (that doesn't fail) and bind that fail but is in a
> try: except:  block in ReconnectLDAPObject.reconnect() !
> Then the server restart and the next statement get advantages of the
> work done initialize

Yes. Inspired by you mentioning libldap I remembered that unbind_s()
should be called when handling ldap.SERVER_DOWN exception to completely
drop the whole connection context.

Please test the version I've committed some minutes ago.
Thanks again.

Ciao, Michael.

Yes I got it !

The problem is the failed statement has initiated a new connection
(when the server is down)
calling initialize (that doesn't fail) and bind that fail but is in a
try: except:  block in ReconnectLDAPObject.reconnect() !
Then the server restart and the next statement get advantages of the
work done initialize


# first stop the service
ldap_service('stop')
# initiate a connection
l=3Dldap.initialize(ldap_url.initializeUrl()) # I dont use ReconnectLDAPObj=
ect !
try:
    l.simple_bind_s(ldap_url.who, ldap_url.cred)
except ldap.SERVER_DOWN:
    pass # bind fail like in ReconnectLDAPObject.reconnect()
ldap_service('start')
check_connection() # that return an empty string


The probleme is initialize don't initialize any connection !
from  "man 3 ldap" :

       The  basic  interaction  is  as  follows.  A session handle is creat=
ed
       using ldap_initialize(3) and set the protocol version to 3 by  calli=
ng
       ldap_set_option(3).  The underlying session is established first ope=
r-
       ation is issued.  This would generally be a Start TLS or  Bind  oper=
a-
       tion.

The problem is that the first operation after Initialize will never
put the connection into failing
state when server is down!
The problem is probably into libldap into the "auto connect at first
operation" like
described into man 3 ldap

This let us do something like

l=3Dldap.initialize(ldap_url.initializeUrl()) # I dont use ReconnectLDAPObj=
ect !

while True:
    try:
        l.simple_bind_s(ldap_url.who, ldap_url.cred)
    except ldap.SERVER_DOWN:
        time.sleep(1)
    else:
        break
print 'Connected'

I don't know if this is a feature or a bug into libldap !

Then the logic of my patch look to be the good one. I still need to
verify it once more.

I go to sleep now


On 1/26/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> > When testing ReconnectLDAPObject I found a bug.
> > The object doesn't reconnect after a main failure !
> > [..]
> > I thing the main probleme is here !
> > Look !
>
> Yes, I can reproduce your observation. Thanks for pointing it out.
>
> > l=3Dldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl())
> > print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectCla=
ss=3D*)")
> >
> > this work too ! And don't give any error while their is no bind !
> > work like if l.simple_bind_s('', '') where used just before the search =
!
>
> Yes, this works as intended in LDAPv3. In opposite to LDAPv2 you MAY
> send a LDAP request without prior bind request.
>
> > I wrote a patch but this is only a workaround that detect the main
> > failure, set a flag and force a reconnect before any request if the
> > flag is set.
>
> Where's the patch? Can't figure out why it does not send the formerly
> sent bind request. It has all the data around. And if you take the
> server down it will re-send the bind request.
>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Alain Spineux wrote:
>>
>> Where's the patch?
> This is still only a workin "draft" I need to reread it's logic,
> anyway I add it at the end

Got your point now.
But still I don't find an elegant solution without having to handle a
'disconnected' flag in several methods.

> I thing libldap open a new connection, but libldap dont store anything
> about the credential and then cannot authenticate with the good user !
> I will try to reproduce this in C with libc

Yes, it's a bug in ReconnectLDAPObject. It doesn't have anything to do
with libldap.

Ciao, Michael.

On 1/26/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> > When testing ReconnectLDAPObject I found a bug.
> > The object doesn't reconnect after a main failure !
> > [..]
> > I thing the main probleme is here !
> > Look !
>
> Yes, I can reproduce your observation. Thanks for pointing it out.

Don't forget we are on the same boat Captain ! :-)
>
> > l=3Dldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl())
> > print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectCla=
ss=3D*)")
> >
> > this work too ! And don't give any error while their is no bind !
> > work like if l.simple_bind_s('', '') where used just before the search =
!
>
> Yes, this works as intended in LDAPv3. In opposite to LDAPv2 you MAY
> send a LDAP request without prior bind request.
>
> > I wrote a patch but this is only a workaround that detect the main
> > failure, set a flag and force a reconnect before any request if the
> > flag is set.
>
> Where's the patch?
This is still only a workin "draft" I need to reread it's logic,
anyway I add it at the end
> Can't figure out why it does not send the formerly
> sent bind request. It has all the data around. And if you take the
> server down it will re-send the bind request.

The trick is it doesn't try to reconnect AFTER the main failure (or
BEFORE the next statement) !
Because the first try (of the next ldap statement) doesn't generate
any error, it doesn't try to reconnect and then give the answer as is
! But this is the answer it got like an unauthenticated user !

Look, this is the tcpdump of the last statement !
00:14:21.109514 IP 127.0.0.1.36250 > 127.0.0.1.ldap: S
1795648490:1795648490(0) win 00:14:21.110352 IP 127.0.0.1.ldap >
127.0.0.1.36250: S 1793421325:1793421325(0) ack 1795648491 win 32768
<mss 16396,sackOK,timestamp 516494160 516494159,nop,wscale 7>
00:14:21.110430 IP 127.0.0.1.36250 > 127.0.0.1.ldap: . ack 1 win 257
<nop,nop,timestamp 516494160 516494160>

You can identify the well known 3-way handshaking ! This is a new connectio=
n !
I thing libldap open a new connection, but libldap dont store anything
about the credential and then cannot authenticate with the good user !
I will try to reproduce this in C with libc

Here is the patch (including my whoami_s() )

*** ldapobject.py.disconnet     Fri Jan 26 22:22:57 2007
--- ldapobject.py.orig  Fri Jan 26 13:42:59 2007
***************
*** 678,684 ****
      self._retry_delay =3D retry_delay
      self._start_tls =3D 0
      self._reconnects_done =3D 0L
-     self._disconnected=3DTrue

    def __getstate__(self):
      """return data representation for pickled object"""
--- 678,683 ----
***************
*** 723,730 ****
            self.start_tls_s()
          # Repeat last simple or SASL bind
          self._apply_last_bind()
!       except Exception, e:
!         self._disconnected=3DTrue
          if __debug__ and self._trace_level>=3D1:
            self._trace_file.write('*** %d. reconnect to %s failed\n' % (
              self._retry_max-reconnect_counter+1,uri
--- 722,728 ----
            self.start_tls_s()
          # Repeat last simple or SASL bind
          self._apply_last_bind()
!       except:
          if __debug__ and self._trace_level>=3D1:
            self._trace_file.write('*** %d. reconnect to %s failed\n' % (
              self._retry_max-reconnect_counter+1,uri
***************
*** 736,742 ****
            self._trace_file.write('=3D> delay %s...\n' % (self._retry_dela=
y))
          time.sleep(self._retry_delay)
        else:
-         self._disconnected=3DFalse
          if __debug__ and self._trace_level>=3D1:
            self._trace_file.write('*** %d. reconnect to %s
successful, last operation will be repeated\n' % (
              self._retry_max-reconnect_counter+1,uri
--- 734,739 ----
***************
*** 745,762 ****
          break

    def _apply_method_s(self,func,*args,**kwargs):
!     if self._disconnected:
        self.reconnect(self._uri)
        # Re-try last operation
        return func(self,*args,**kwargs)
-     else:
-         try:
-           return func(self,*args,**kwargs)
-         except ldap.SERVER_DOWN:
-           # Reconnect
-           self.reconnect(self._uri)
-           # Re-try last operation
-           return func(self,*args,**kwargs)

    def set_option(self,option,invalue):
      self._options[option] =3D invalue
--- 742,754 ----
          break

    def _apply_method_s(self,func,*args,**kwargs):
!     try:
!       return func(self,*args,**kwargs)
!     except ldap.SERVER_DOWN:
!       # Reconnect
        self.reconnect(self._uri)
        # Re-try last operation
        return func(self,*args,**kwargs)

    def set_option(self,option,invalue):
      self._options[option] =3D invalue
***************
*** 764,772 ****

    def simple_bind_s(self,*args,**kwargs):
      self._last_bind =3D (self.simple_bind_s,args,kwargs)
!     result=3DSimpleLDAPObject.simple_bind_s(self,*args,**kwargs)
!     self._disconnected=3DFalse
!     return result

    def start_tls_s(self):
      res =3D SimpleLDAPObject.start_tls_s(self)
--- 756,762 ----

    def simple_bind_s(self,*args,**kwargs):
      self._last_bind =3D (self.simple_bind_s,args,kwargs)
!     return SimpleLDAPObject.simple_bind_s(self,*args,**kwargs)

    def start_tls_s(self):
      res =3D SimpleLDAPObject.start_tls_s(self)
***************
*** 778,786 ****
      sasl_interactive_bind_s(who, auth) -> None
      """
      self._last_bind =3D (self.sasl_interactive_bind_s,args,kwargs)
!     result=3DSimpleLDAPObject.sasl_interactive_bind_s(self,*args,**kwargs=
)
!     self._disconnected=3DFalse
!     return result

    def add_ext_s(self,*args,**kwargs):
      return self._apply_method_s(SimpleLDAPObject.add_ext_s,*args,**kwargs=
)
--- 768,774 ----
      sasl_interactive_bind_s(who, auth) -> None
      """
      self._last_bind =3D (self.sasl_interactive_bind_s,args,kwargs)
!     return SimpleLDAPObject.sasl_interactive_bind_s(self,*args,**kwargs)

    def add_ext_s(self,*args,**kwargs):
      return self._apply_method_s(SimpleLDAPObject.add_ext_s,*args,**kwargs=
)
***************
*** 800,808 ****
    def search_ext_s(self,*args,**kwargs):
      return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwa=
rgs)

-   def whoami_s(self,*args,**kwargs):
-     return self._apply_method_s(SimpleLDAPObject.whoami_s,*args,**kwargs)
-

  class SmartLDAPObject(ReconnectLDAPObject):
    """
--- 788,793 ----



--
Alain Spineux
aspineux gmail com
May the sources be with you

Alain Spineux wrote:
> When testing ReconnectLDAPObject I found a bug.
> The object doesn't reconnect after a main failure !
> [..]
> I thing the main probleme is here !
> Look !

Yes, I can reproduce your observation. Thanks for pointing it out.

> l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl())
> print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectClass=*)")
> 
> this work too ! And don't give any error while their is no bind !
> work like if l.simple_bind_s('', '') where used just before the search !

Yes, this works as intended in LDAPv3. In opposite to LDAPv2 you MAY
send a LDAP request without prior bind request.

> I wrote a patch but this is only a workaround that detect the main
> failure, set a flag and force a reconnect before any request if the
> flag is set.

Where's the patch? Can't figure out why it does not send the formerly
sent bind request. It has all the data around. And if you take the
server down it will re-send the bind request.

Ciao, Michael.

Thanks for these useful details

On 1/26/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> >
> > I use whoami_s() like a ping, to know if the server is still up.
>
> This requires support for "Who am I?" extended operation (see RFC 4532)
> at the server's side which is not implemented in all server products.
>
> > Do you know a better way ?
>
> If it's an LDAPv3 server you could simply read the rootDSE.
> Some servers implement special monitoring entries (e.g. cn=3DMonitor
> implemented by OpenLDAP's back-monitor).
>
> You have to think about detailed error handling.
>
> But this all depends on which requirements you have.
> How general? How many details?
>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

When testing ReconnectLDAPObject I found a bug.
The object doesn't reconnect after a main failure !

If I shutdown the ldap server and try a request, I get a
ldap.SERVER_DOWN, this is correct. (this is what I call the main
failure)
But if I restart the server, and retry the same request (with the same
object), I get an empty answer but no error!
I'm expecting a correct answer or an error (exception)!
I have a full script that show the problem at the end.
It look the object is in an incoherent state after the main failure,
in fact in an unauthenticated state ! I thing this is a problem with
libldap or openldap, not with python code.

I thing the main probleme is here !
Look !

l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl())
l.simple_bind_s('cn=nobody,cn=internal,dc=asxnet,dc=loc', '***********')
print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectClass=*)")

works and return all object anonymous can get, but

l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl())
print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE, "(objectClass=*)")

this work too ! And don't give any error while their is no bind !
work like if l.simple_bind_s('', '') where used just before the search !

I wrote a patch but this is only a workaround that detect the main
failure, set a flag and force a reconnect before any request if the
flag is set.

Here is the output of my test case
I use a modified python-ldap, that include the patch posted in my
previous post that enable reconnect to work with whoami_s()

-- without debuging --

OpenPKG: stop: openldap.
OpenPKG: start: openldap.
Connected
whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc
OpenPKG: stop: openldap.
OpenPKG: start: openldap.
whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc
reconnect ok
OpenPKG: stop: openldap.
ok: ldap.SERVER_DOWN, server is realy down
OpenPKG: start: openldap.
whoami
It look i'am connected, but like anonymous

-- with debuging --

OpenPKG: stop: openldap.
OpenPKG: start: openldap.
*** ldap://localhost:389 - ReconnectLDAPObject.set_option ((17, 3),{})
*** ldap://localhost:389 - ReconnectLDAPObject.simple_bind
(('cn=nobody,cn=internal,dc=asxnet,dc=loc',
'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc', None, None),{})
*** ldap://localhost:389 - ReconnectLDAPObject.result3 ((1, 1, -1),{})
Connected
*** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{})
whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc
OpenPKG: stop: openldap.
OpenPKG: start: openldap.
*** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{})
*** Try 1. reconnect to ldap://localhost:389...
*** ldap://localhost:389 - ReconnectLDAPObject.set_option ((17, 3),{})
*** ldap://localhost:389 - ReconnectLDAPObject.simple_bind
(('cn=nobody,cn=internal,dc=asxnet,dc=loc',
'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc', None, None),{})
*** ldap://localhost:389 - ReconnectLDAPObject.result3 ((1, 1, -1),{})
*** 1. reconnect to ldap://localhost:389 successful, last operation
will be repeated
*** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{})
whoami dn:cn=nobody,cn=internal,dc=asxnet,dc=loc
reconnect ok
OpenPKG: stop: openldap.
*** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{})
*** Try 1. reconnect to ldap://localhost:389...
*** ldap://localhost:389 - ReconnectLDAPObject.set_option ((17, 3),{})
*** ldap://localhost:389 - ReconnectLDAPObject.simple_bind
(('cn=nobody,cn=internal,dc=asxnet,dc=loc',
'iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc', None, None),{})
*** 1. reconnect to ldap://localhost:389 failed
ok: ldap.SERVER_DOWN, server is realy down
OpenPKG: start: openldap.
*** ldap://localhost:389 - ReconnectLDAPObject.whoami_s ((None, None),{})
whoami
It look i'am connected, but like anonymous

---- and finaly my test case ----

import sys, os, time
import ldap, ldapurl

host='localhost'
port=389
who='cn=nobody,cn=internal,dc=asxnet,dc=loc'
cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc'
dn='dc=asxnet,dc=loc'

def ldap_service(action):
    os.system('/kolab/bin/openpkg rc openldap %s' % action)
    if action.endswith('start'):
        time.sleep(1)

def check_connection():
    whoami=l.whoami_s()
    print 'whoami', whoami
    # this search dont give any result as anonymous, but well if
loggged as nobody
    #result=l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE,
"(member=cn=domain.maintainer
mydomain.loc,cn=internal,dc=asxnet,dc=loc)")
    #print 'search', result

ldap_url=ldapurl.LDAPUrl('ldap://%s:%d/%s' % (host, port, dn))
ldap_url.applyDefaults({
    'who': who,
    'cred' : cred, })

# to be sure the server is up
ldap_service('stop')
ldap_service('start')

l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl(), 1)
# l=ldap.ldapobject.LDAPObject(ldap_url.initializeUrl())
l.simple_bind_s(ldap_url.who, ldap_url.cred)
print 'Connected'

check_connection()

ldap_service('stop')
ldap_service('start')

try:
    check_connection()
except ldap.SERVER_DOWN:
    print "Error: ldap.SERVER_DOWN !"
else:
    print "reconnect ok"

ldap_service('stop')

try:
    check_connection()
except ldap.SERVER_DOWN:
    print "ok: ldap.SERVER_DOWN, server is realy down"

ldap_service('start')

check_connection()

print "It look i'am connected, but like anonymous"








import sys, os, time
import ldap, ldapurl

host='localhost'
port=389
who='cn=nobody,cn=internal,dc=asxnet,dc=loc'
cred='iMmTWz5pJ+lwY7i6M/BU61ngo1aBLyqQhRrrKbEc'
dn='dc=asxnet,dc=loc'

def ldap_service(action):
    os.system('/kolab/bin/openpkg rc openldap %s' % action)
    if action.endswith('start'):
        time.sleep(1)

def check_connection():
    #print 'search', l.search_s(ldap_url.dn, ldap.SCOPE_SUBTREE,
"(member=cn=domain.maintainer
mydomain.loc,cn=internal,dc=asxnet,dc=loc)")
    print 'whoami', l.whoami_s()

ldap_url=ldapurl.LDAPUrl('ldap://%s:%d/%s' % (host, port, dn))
ldap_url.applyDefaults({
    'who': who,
    'cred' : cred, })

ldap_service('stop')
ldap_service('start')

l=ldap.ldapobject.ReconnectLDAPObject(ldap_url.initializeUrl())
# l=ldap.ldapobject.LDAPObject(ldap_url.initializeUrl())
l.simple_bind_s(ldap_url.who, ldap_url.cred)
print 'Connected'

check_connection()

ldap_service('stop')
ldap_service('start')

try:
    check_connection()
except ldap.SERVER_DOWN:
    print "Error: ldap.SERVER_DOWN !"

ldap_service('stop')

try:
    check_connection()
except ldap.SERVER_DOWN:
    print "Ok: ldap.SERVER_DOWN"

ldap_service('start')

check_connection()


ANY Comments ?


--
Alain Spineux
aspineux gmail com
May the sources be with you

Alain Spineux wrote:
> 
> I use whoami_s() like a ping, to know if the server is still up.

This requires support for "Who am I?" extended operation (see RFC 4532)
at the server's side which is not implemented in all server products.

> Do you know a better way ?

If it's an LDAPv3 server you could simply read the rootDSE.
Some servers implement special monitoring entries (e.g. cn=Monitor
implemented by OpenLDAP's back-monitor).

You have to think about detailed error handling.

But this all depends on which requirements you have.
How general? How many details?

Ciao, Michael.

Alain Spineux wrote:
> ReconnectLDAPObject.whoami_s() is not protected again disconnection !
> Maybe someone forgot to redefine this method into ReconnectLDAPObject !

Thanks for pointing this out. I've committed it to CVS. Please test.

Ciao, Michael.

ReconnectLDAPObject.whoami_s() is not protected again disconnection !
Maybe someone forgot to redefine this method into ReconnectLDAPObject !

Here is the patch

*** /usr/lib/python2.4/site-packages/ldap/ldapobject.py.orig    Fri
Jan 26 13:42:59 2007
--- /usr/lib/python2.4/site-packages/ldap/ldapobject.py Fri Jan 26 13:46:12 2007
***************
*** 788,793 ****
--- 788,796 ----
    def search_ext_s(self,*args,**kwargs):
      return self._apply_method_s(SimpleLDAPObject.search_ext_s,*args,**kwargs)

+   def whoami_s(self,*args,**kwargs):
+     return self._apply_method_s(SimpleLDAPObject.whoami_s,*args,**kwargs)
+

  class SmartLDAPObject(ReconnectLDAPObject):
    """


I use whoami_s() like a ping, to know if the server is still up. Do
you know a better way ?



--
Alain Spineux
aspineux gmail com
May the sources be with you

Anil Jangity wrote:
> Whats the recommend way to make modifications to an LDAP entry?

In general
1. you should do as many modifications in a single modify as possible
since a single modify operations is atomic.
2. you should try to avoid mods which need equality matching rules at
the server side for sorting out specific attribute values.

> Right now I am using ldap.modify (MOD_ADD,  MOD_DELETE, or
> MOD_REPLACE) but it seems cumbersome because there are multiple
> possiblities for each modification depending on wether its a
> multi-value attribute or single-value or required attribute or
> optional attribute...

Maybe the output of function ldap.modlist.modifyModlist() gives you some
ideas:

http://python-ldap.sourceforge.net/doc/python-ldap/module-ldap.modlist.html

> It would be nice if there is a class available to simply pass in the
> DN, and the *new* LDIF and it would be taken care of.

Not LDIF. ldap.modlist.modifyModlist() handles dictionaries.

> I am just
> looking through some documentation and I guess something like
> ldif.LDIFWriter().

It's fairly easy to glue ldif.LDIFReader() and
ldap.modlist.modifyModlist() together.

Ciao, Michael.

Whats the recommend way to make modifications to an LDAP entry?

Right now I am using ldap.modify (MOD_ADD,  MOD_DELETE, or
MOD_REPLACE) but it seems cumbersome because there are multiple
possiblities for each modification depending on wether its a
multi-value attribute or single-value or required attribute or
optional attribute...

This is a rough code of what I am talking about:
# optional attr
if attribute not in newentry:
  MOD_DELETE
if new_attribute and old_attribute are diff:
  if old_attr is None:
     MOD_ADD
  else:
     MOD_REPLACE

# required attributes
....


It would be nice if there is a class available to simply pass in the
DN, and the *new* LDIF and it would be taken care of. I am just
looking through some documentation and I guess something like
ldif.LDIFWriter().

Unless I am missing something that is there already....

Thanks.

Jonathan Bowman wrote:
> 
> You wrote a while back:
> 
>>Regarding 2.:
>>I asked Howard Chu, OpenLDAP core developer whether it's possible to
>>build Cyrus-SASL on Win32 based on the MingW tool chain. He said they're
>>doing it all the time with Symas' product. Additionally one would have
>>to clarify the situation for Kerberos libs (preferrably heimdal).
> 
> Would this fellow be willing to share instructions on how to do so? I
> would be happy to contact him, if so.

You could simply ask on the openldap-software mailing list.

Ciao, Michael.

Michael,

You wrote a while back:

> Regarding 2.:
> I asked Howard Chu, OpenLDAP core developer whether it's possible to
> build Cyrus-SASL on Win32 based on the MingW tool chain. He said they're
> doing it all the time with Symas' product. Additionally one would have
> to clarify the situation for Kerberos libs (preferrably heimdal).

Would this fellow be willing to share instructions on how to do so? I
would be happy to contact him, if so.

Thanks,
Jonathan

Michael Ströder wrote:
> Anil wrote:
>   
>> Will python-ldap package ever support other ldap servers?
>>     
>
> Short answer: Yes.
>
> Longer answer:
> My web2ldap uses python-ldap. I used this tool with a wide range of
> different server products. This page should give you a rough idea:
> http://www.web2ldap.de/compability.html
>
>   
>> (primarily I 
>> am thinking of Sun's directory or  the OpenDS)
>>     
>
> I'm not aware of any issues with this specific LDAP server regarding
> access with python-ldap.
>   
I use python-ldap with Red Hat and Fedora DS quite a bit, and it works 
just fine.  Should work for all of the Netscape/iPlanet/Sun servers, 
since they are all very similar.
>   
>> I've compiled python-ldap using openldap and have used it against them 
>> but one specific method I am concerned with is the modrdn/renames. Not 
>> sure they work well with Sun's directory.
>>     
>
> Can you please elaborate. What issues are you seeing?
>   
Up until Sun DS 5.2, none of the Netscape derived servers supported 
modrdn with new superior.  Could that be the issue you are seeing?
> Ciao, Michael.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
>
>   

Anil wrote:
> Will python-ldap package ever support other ldap servers?

Short answer: Yes.

Longer answer:
My web2ldap uses python-ldap. I used this tool with a wide range of
different server products. This page should give you a rough idea:
http://www.web2ldap.de/compability.html

> (primarily I 
> am thinking of Sun's directory or  the OpenDS)

I'm not aware of any issues with this specific LDAP server regarding
access with python-ldap.

> I've compiled python-ldap using openldap and have used it against them 
> but one specific method I am concerned with is the modrdn/renames. Not 
> sure they work well with Sun's directory.

Can you please elaborate. What issues are you seeing?

Ciao, Michael.

Will python-ldap package ever support other ldap servers? (primarily I 
am thinking of Sun's directory or  the OpenDS)

I've compiled python-ldap using openldap and have used it against them 
but one specific method I am concerned with is the modrdn/renames. Not 
sure they work well with Sun's directory. I know PHP didn't handle this 
too well.

Lionel,

Lionel Porcheron wrote:
> 
> One of Ubuntu users send us a patch on your documentation (see
> attached). Can you check it and see if it is appropriate and in this
> case include it in your future releases.
> 
> The original bug is reachable here :
> https://bugs.launchpad.net/distros/ubuntu/+source/python-ldap/+bug/73615

Thanks for pointing that out. But actually the __doc__ string has more
appropriate wording which I will use in the docs:

>>> import ldap
>>> print ldap.ldapobject.LDAPObject.modrdn.__doc__

    modrdn(dn, newrdn [,delold=1]) -> int
    modrdn_s(dn, newrdn [,delold=1]) -> None
        Perform a modify RDN operation. These routines take dn, the
        DN of the entry whose RDN is to be changed, and newrdn, the
        new RDN to give to the entry. The optional parameter delold
        is used to specify whether the old RDN should be kept as
        an attribute of the entry or not.  The asynchronous version
        returns the initiated message id.

        This operation is emulated by rename() and rename_s() methods
        since the modrdn2* routines in the C library are deprecated.

Ciao, Michael.

Vitaliyi wrote:
> I found out that ldap.modify_s behaves strangely, at least from my
> point of view:
> 
> l.modify_s(dn,[(ldap.MOD_REPLACE,'someAttr',str(whatever))])
> will drop attribute,

You SHOULD NOT use this form because attributes are most times supposed
to be multi-valued.

> but with list  ([str(whatever)]), parameter do as expected.

You SHOULD implement it with list.

It was a bad design decision to even accept strings.

Ciao, Michael.

I found out that ldap.modify_s behaves strangely, at least from my
point of view:

l.modify_s(dn,[(ldap.MOD_REPLACE,'someAttr',str(whatever))])
will drop attribute, but with list  ([str(whatever)]), parameter do as expected.

gee...@aa... wrote:
> 
> Everything works fine if I'm linking against the shared version
> of python....
> 
> I've no idea why it's not working with the static version?????

I have also no idea.

Ciao, Michael.

Hi,

Here is part of my makefile:

VERSION =3D Python-2.5

VERSION=5FLDAP =3D python-ldap-2.2.1

compile: .python .python-ldap

python:        makefile.python .glibc $(VERSION).Setup.local
                $(EXTRACT=5FPACKAGE) && \
                        $(CP) ../$(VERSION).Setup.local=20
Modules/Setup.local && \
                        ./configure --prefix=3D/usr --enable-shared=3Dno &&=
 \
                        make && \
                        make install=20
                cp $(VERSION)/libpython2.5.a /usr/lib/libpython.a
                (cd /usr/include; $(LN) -sf python2.5 python )
                touch .python=20


.python-ldap: makefile.python .python .sasl .glibc .openldap=20
python-ldap.setup.cfg
        (rm -rf $(VERSION=5FLDAP)  ||  /bin/true)  && \
        tar xjf $(ARCHIVE=5FPACKAGES)/$(VERSION=5FLDAP).tar.bz2  && \
        cd $(VERSION=5FLDAP) && \
                $(CP) ../python-ldap.setup.cfg setup.cfg && \
                python setup.py build && \
                python setup.py install
        rm -rf $(VERSION=5FLDAP)
        touch .python-ldap


And my setup.cfg

# Example for setup.cfg
# You have to edit this file to reflect your system configuation
# $Id: setup.cfg.suse-linux,v 1.1 2003/08/20 10:04:34 stroeder Exp $

[=5Fldap]
# Section for compiling the C extension module
# for wrapping OpenLDAP 2 libs

library=5Fdirs =3D /usr/lib/ /usr/lib/sasl2/
include=5Fdirs =3D /usr/include/sasl/ /usr/include/sasl2/
extra=5Fcompile=5Fargs =3D
extra=5Fobjects =3D

# Example for full-featured SuSE build:
# Support for StartTLS/LDAPS, SASL bind and reentrant libldap=5Fr.
# This needs recent OpenLDAP 2.0.26+ or 2.1.3+ built with
#./configure --with-cyrus-sasl --with-tls
libs =3D python ldap=5Fr lber sasl2 ssl crypto resolv dl db m util pthread

[install]
# Installation options
compile =3D 1
optimize =3D 1

Everything is done in a chroot-ed environment...when building python-ldap, =

it uses
the newly installed python includes....
The test application is linked against the static version libpython.a

Thanks,
Geert




Michael Str=F6der <mi...@st...>=20
Sent by: pyt...@li...
12/18/2006 11:40 AM

To
gee...@aa...
cc
pyt...@li...
Subject
Re: Fw: crash in PyImport=5FImport (Unsigned Mail)






gee...@aa... wrote:
>
> -> Python and python-ldap are recompiled for my environment
> (python generates the static library....)

Did you tweak the file setup.cfg?
Can you please elaborate on how static linking is to be done?
How is the embedded Python built?

Ciao, Michael.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share=20
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Python-LDAP-dev mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

gee...@aa... wrote:
> 
> -> Python and python-ldap are recompiled for my environment
> (python generates the static library....)

Did you tweak the file setup.cfg?
Can you please elaborate on how static linking is to be done?
How is the embedded Python built?

Ciao, Michael.

Hi,

Unfortunately, it doesn't work with these releases...

The crash happens when importing the python script
(and no function is called...)
Are there any ldapobject created and deleted at that time?
(No bind is done before the crash...)

Regards,
Geert




Michael Str=F6der <mi...@st...>=20
Sent by: pyt...@li...
12/18/2006 10:18 AM

To
gee...@aa...
cc
pyt...@li...
Subject
Re: Fw: crash in PyImport=5FImport (Plain) (Unsigned Mail)






gee...@aa... wrote:
>
> I've been using the following versions of python and python-ldap
>
> python: 2.5
> python-ldap 2.2.1

And now it works? (see SF#1575329)

Ciao, Michael.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share=20
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Python-LDAP-dev mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev