From michael at stroeder.com Tue Jan 2 17:02:58 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Jan 2007 17:02:58 +0100 Subject: patch for documentation In-Reply-To: <45756FCF.4010408@alveonet.org> References: <45756FCF.4010408@alveonet.org> Message-ID: <459A8232.9000107@stroeder.com> 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. From anilj at entic.net Fri Jan 5 03:28:44 2007 From: anilj at entic.net (Anil) Date: Thu, 04 Jan 2007 18:28:44 -0800 Subject: other ldap servers Message-ID: <459DB7DC.9060905@entic.net> 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. From michael at stroeder.com Fri Jan 5 03:36:02 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 05 Jan 2007 03:36:02 +0100 Subject: other ldap servers In-Reply-To: <459DB7DC.9060905@entic.net> References: <459DB7DC.9060905@entic.net> Message-ID: <459DB992.7070102@stroeder.com> 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. From rich.megginson at gmail.com Fri Jan 5 05:25:46 2007 From: rich.megginson at gmail.com (Rich Megginson) Date: Thu, 04 Jan 2007 21:25:46 -0700 Subject: other ldap servers In-Reply-To: <459DB992.7070102@stroeder.com> References: <459DB7DC.9060905@entic.net> <459DB992.7070102@stroeder.com> Message-ID: <459DD34A.9060206@gmail.com> 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. > > From bowmanj at users.sourceforge.net Fri Jan 19 02:31:54 2007 From: bowmanj at users.sourceforge.net (Jonathan Bowman) Date: Thu, 18 Jan 2007 20:31:54 -0500 Subject: winldap? In-Reply-To: <457E99DC.9090703@stroeder.com> References: <7a2b5dfb0612111126g6d631561k3fb9edfa8c1176a8@mail.gmail.com> <457E99DC.9090703@stroeder.com> Message-ID: <7a2b5dfb0701181731m2bd770cekd00e68cb07744083@mail.gmail.com> 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 From michael at stroeder.com Fri Jan 19 07:20:04 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 19 Jan 2007 07:20:04 +0100 Subject: winldap? In-Reply-To: <7a2b5dfb0701181731m2bd770cekd00e68cb07744083@mail.gmail.com> References: <7a2b5dfb0612111126g6d631561k3fb9edfa8c1176a8@mail.gmail.com> <457E99DC.9090703@stroeder.com> <7a2b5dfb0701181731m2bd770cekd00e68cb07744083@mail.gmail.com> Message-ID: <45B06314.9060300@stroeder.com> 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. From anilj at entic.net Fri Jan 19 20:21:10 2007 From: anilj at entic.net (Anil Jangity) Date: Fri, 19 Jan 2007 11:21:10 -0800 Subject: best way to make mods to entries Message-ID: 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. From michael at stroeder.com Mon Jan 22 10:46:30 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 22 Jan 2007 10:46:30 +0100 Subject: best way to make mods to entries In-Reply-To: References: Message-ID: <45B487F6.9020201@stroeder.com> 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. From aspineux at gmail.com Fri Jan 26 14:47:41 2007 From: aspineux at gmail.com (Alain Spineux) Date: Fri, 26 Jan 2007 14:47:41 +0100 Subject: patch for ReconnectLDAPObject.whoami_s() Message-ID: <71fe4e760701260547t5921a837q9af08ac131af8e35@mail.gmail.com> 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 From michael at stroeder.com Fri Jan 26 15:13:10 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Jan 2007 15:13:10 +0100 Subject: patch for ReconnectLDAPObject.whoami_s() In-Reply-To: <71fe4e760701260547t5921a837q9af08ac131af8e35@mail.gmail.com> References: <71fe4e760701260547t5921a837q9af08ac131af8e35@mail.gmail.com> Message-ID: <45BA0C76.6000606@stroeder.com> 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. From michael at stroeder.com Fri Jan 26 15:25:57 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Jan 2007 15:25:57 +0100 Subject: Monitoring LDAP server (was: patch for ReconnectLDAPObject.whoami_s()) In-Reply-To: <71fe4e760701260547t5921a837q9af08ac131af8e35@mail.gmail.com> References: <71fe4e760701260547t5921a837q9af08ac131af8e35@mail.gmail.com> Message-ID: <45BA0F75.4050806@stroeder.com> 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. From aspineux at gmail.com Fri Jan 26 22:39:37 2007 From: aspineux at gmail.com (Alain Spineux) Date: Fri, 26 Jan 2007 22:39:37 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure Message-ID: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> 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 From aspineux at gmail.com Fri Jan 26 23:05:12 2007 From: aspineux at gmail.com (Alain Spineux) Date: Fri, 26 Jan 2007 23:05:12 +0100 Subject: Monitoring LDAP server (was: patch for ReconnectLDAPObject.whoami_s()) In-Reply-To: <45BA0F75.4050806@stroeder.com> References: <71fe4e760701260547t5921a837q9af08ac131af8e35@mail.gmail.com> <45BA0F75.4050806@stroeder.com> Message-ID: <71fe4e760701261405i6135a6c0n9fdbac0a86a6b42a@mail.gmail.com> Thanks for these useful details On 1/26/07, Michael Str?der 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=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 aspineux gmail com May the sources be with you From michael at stroeder.com Fri Jan 26 23:44:05 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Jan 2007 23:44:05 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> Message-ID: <45BA8435.4040102@stroeder.com> 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. From aspineux at gmail.com Sat Jan 27 00:23:00 2007 From: aspineux at gmail.com (Alain Spineux) Date: Sat, 27 Jan 2007 00:23:00 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <45BA8435.4040102@stroeder.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> Message-ID: <71fe4e760701261523x666e0464g7bbfbe6e6719ebd6@mail.gmail.com> On 1/26/07, Michael Str?der 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=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? 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 00:14:21.110430 IP 127.0.0.1.36250 > 127.0.0.1.ldap: . ack 1 win 257 You can identify the well known 3-way handshaking ! This is a new connection ! 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 = retry_delay self._start_tls = 0 self._reconnects_done = 0L - self._disconnected=True 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=True if __debug__ and self._trace_level>=1: 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>=1: self._trace_file.write('*** %d. reconnect to %s failed\n' % ( self._retry_max-reconnect_counter+1,uri *************** *** 736,742 **** self._trace_file.write('=> delay %s...\n' % (self._retry_delay)) time.sleep(self._retry_delay) else: - self._disconnected=False if __debug__ and self._trace_level>=1: 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] = 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] = invalue *************** *** 764,772 **** def simple_bind_s(self,*args,**kwargs): self._last_bind = (self.simple_bind_s,args,kwargs) ! result=SimpleLDAPObject.simple_bind_s(self,*args,**kwargs) ! self._disconnected=False ! return result def start_tls_s(self): res = SimpleLDAPObject.start_tls_s(self) --- 756,762 ---- def simple_bind_s(self,*args,**kwargs): self._last_bind = (self.simple_bind_s,args,kwargs) ! return SimpleLDAPObject.simple_bind_s(self,*args,**kwargs) def start_tls_s(self): res = SimpleLDAPObject.start_tls_s(self) *************** *** 778,786 **** sasl_interactive_bind_s(who, auth) -> None """ self._last_bind = (self.sasl_interactive_bind_s,args,kwargs) ! result=SimpleLDAPObject.sasl_interactive_bind_s(self,*args,**kwargs) ! self._disconnected=False ! 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 = (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,**kwargs) - 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 From aspineux at gmail.com Sat Jan 27 01:57:49 2007 From: aspineux at gmail.com (Alain Spineux) Date: Sat, 27 Jan 2007 01:57:49 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <45BA8435.4040102@stroeder.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> Message-ID: <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> 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=ldap.initialize(ldap_url.initializeUrl()) # I dont use ReconnectLDAPObject ! 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 created using ldap_initialize(3) and set the protocol version to 3 by calling ldap_set_option(3). The underlying session is established first oper- ation is issued. This would generally be a Start TLS or Bind opera- 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=ldap.initialize(ldap_url.initializeUrl()) # I dont use ReconnectLDAPObject ! 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?der 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=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. > -- -- Alain Spineux aspineux gmail com May the sources be with you From michael at stroeder.com Sat Jan 27 01:39:43 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 27 Jan 2007 01:39:43 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <71fe4e760701261523x666e0464g7bbfbe6e6719ebd6@mail.gmail.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> <71fe4e760701261523x666e0464g7bbfbe6e6719ebd6@mail.gmail.com> Message-ID: <45BA9F4F.7030502@stroeder.com> 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. From michael at stroeder.com Sat Jan 27 02:00:56 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 27 Jan 2007 02:00:56 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> Message-ID: <45BAA448.40403@stroeder.com> 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. From aspineux at gmail.com Sun Jan 28 02:06:47 2007 From: aspineux at gmail.com (Alain Spineux) Date: Sun, 28 Jan 2007 02:06:47 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <816c7e0a80ac70bf6dba69c1da579fdc@stroeder.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> <45BAA448.40403@stroeder.com> <71fe4e760701270359l39d125b4m1d5a161f60467def@mail.gmail.com> <816c7e0a80ac70bf6dba69c1da579fdc@stroeder.com> Message-ID: <71fe4e760701271706h7678575v6e5e4dddedaf0897@mail.gmail.com> This is a good point of view! Anyway I try my _LAST_ arguments. Python is a language made to help and facilitate the developer work : - the developer dont need to test the result of any function, python (or the library) raise an exception if something is wrong. - the developer dont need to worry about the memory allocation, the garbage collector do it for him. - the developer dont need to close a file, the system do it for him when the object is released - the developer don't need to worry for long living LDAP connection, ReconnectLDAPObject auto reconnect automatically for him :-) - python-ldap is also thread safe ..... Then why does the developer have to encapsulate any ldap statement into a try: except ldap.SERVER_DOWN,e: SimpleLDAPObject.unbind_s(self) whereas the library can do it for him Anyway we made a good job ! Tanks for your support. On 1/27/07, "Michael Str?der" wrote: > On 12:59:58 pm 2007-01-27 "Alain Spineux" wrote: > > > > 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 ? > > There is nothing wrong with SimpleLDAPObject. The application is supposed > to catch and handle ldap.SERVER_DOWN. Additionally SimpleLDAPObject and > ReconnectLDAPObject shall behave in the same way. And IMO they do now. > > Ciao, Michael. > > -- -- Alain Spineux aspineux gmail com May the sources be with you From aspineux at gmail.com Sun Jan 28 02:41:34 2007 From: aspineux at gmail.com (Alain Spineux) Date: Sun, 28 Jan 2007 02:41:34 +0100 Subject: about how python-ldap is trade safe. Message-ID: <71fe4e760701271741u658661ebr9a3ba8a137b87ab2@mail.gmail.com> Hello I was a little afraid by the advertisement I found Thread-lock: Basically calls into the LDAP lib are serialized by the module-wide lock _ldapmodule_lock. and wanted to know more about this. Finally I found every object contains its own lock ! (if the used ldap library is reentrant) and their was no bottleneck. I was happy :-) But _ldap_function_call is still used to call _ldap.initialize at some place [root at fc6-eg ldap]# grep _ldap.initialize *.py ldapobject.py: self._l = ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri) ldapobject.py: self._l = ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri) ldapobject.py: self._l = self._ldap_call(_ldap.initialize,self._uri) why not to replace the use of _ldap_function_call by the more appropriate _ldap_call, already used in the last line ! And that way debugging will provide and uri for initialise call! here is the patch *** ldap.orig/ldapobject.py Sat Jan 27 01:57:50 2007 --- ldap/ldapobject.py Sun Jan 28 02:34:56 2007 *************** *** 66,72 **** self._trace_stack_limit = trace_stack_limit self._uri = uri self._ldap_object_lock = self._ldap_lock() ! self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri) self.timeout = -1 self.protocol_version = ldap.VERSION3 --- 66,73 ---- self._trace_stack_limit = trace_stack_limit self._uri = uri self._ldap_object_lock = self._ldap_lock() ! self._l = self._ldap_call(_ldap.initialize,self._uri) ! self.timeout = -1 self.protocol_version = ldap.VERSION3 *************** *** 732,738 **** )) try: # Do the connect ! self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri) self._restore_options() # StartTLS extended operation in case this was called before if self._start_tls: --- 733,740 ---- )) try: # Do the connect ! self._l = self._ldap_call(_ldap.initialize,self._uri) ! self._restore_options() # StartTLS extended operation in case this was called before if self._start_tls: -- Alain Spineux aspineux gmail com May the sources be with you From aspineux at gmail.com Sat Jan 27 12:59:58 2007 From: aspineux at gmail.com (Alain Spineux) Date: Sat, 27 Jan 2007 12:59:58 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <45BAA448.40403@stroeder.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> <45BAA448.40403@stroeder.com> Message-ID: <71fe4e760701270359l39d125b4m1d5a161f60467def@mail.gmail.com> 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='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) # 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?der 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. > -- -- Alain Spineux aspineux gmail com May the sources be with you From michael at stroeder.com Sat Jan 27 21:52:29 2007 From: michael at stroeder.com (=?UTF-8?B?Ik1pY2hhZWwgU3Ryw7ZkZXIi?=) Date: Sat, 27 Jan 2007 21:52:29 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <71fe4e760701270359l39d125b4m1d5a161f60467def@mail.gmail.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> <45BAA448.40403@stroeder.com> <71fe4e760701270359l39d125b4m1d5a161f60467def@mail.gmail.com> Message-ID: <816c7e0a80ac70bf6dba69c1da579fdc@stroeder.com> On 12:59:58 pm 2007-01-27 "Alain Spineux" wrote: > > 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 ? There is nothing wrong with SimpleLDAPObject. The application is supposed to catch and handle ldap.SERVER_DOWN. Additionally SimpleLDAPObject and ReconnectLDAPObject shall behave in the same way. And IMO they do now. Ciao, Michael. From michael at stroeder.com Mon Jan 29 11:56:18 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Jan 2007 11:56:18 +0100 Subject: about how python-ldap is trade safe. In-Reply-To: <71fe4e760701271741u658661ebr9a3ba8a137b87ab2@mail.gmail.com> References: <71fe4e760701271741u658661ebr9a3ba8a137b87ab2@mail.gmail.com> Message-ID: <45BDD2D2.5020802@stroeder.com> Alain, thanks for reviewing the code of ldapobject.py thoroughly. Alain Spineux wrote: > > Finally I found every object contains its own lock ! (if the used ldap > library is reentrant) > and their was no bottleneck. I was happy :-) Yes, if linked against libldap_r (check your setup.cfg). > But _ldap_function_call is still used to call _ldap.initialize at some place > > [root at fc6-eg ldap]# grep _ldap.initialize *.py > ldapobject.py: self._l = > ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri) > ldapobject.py: self._l = > ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri) > ldapobject.py: self._l = self._ldap_call(_ldap.initialize,self._uri) > > why not to replace the use of _ldap_function_call by the more > appropriate _ldap_call, already used in the last line ! Hmm, IMO it's the other way round. I'd rather consider it a stupid copy&paste bug that self._ldap_call() is invoked for wrapping _ldap.initialize() within SmartLDAPObject. I've fixed and committed this. Please review OpenLDAP's ldap.h. You'll find that ldap_initialize() is a completely different thing. > And that way > debugging will provide and uri for initialise call! ldap.functions._ldap_function_call() also can produce debug output. But you have to explicitly set module vars ldap._trace_level, ldap._trace_file and ldap._trace_stack_limit to enable it. The latter two being optional off course. Ciao, Michael. From michael at stroeder.com Mon Jan 29 12:10:11 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Jan 2007 12:10:11 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <71fe4e760701271706h7678575v6e5e4dddedaf0897@mail.gmail.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> <45BAA448.40403@stroeder.com> <71fe4e760701270359l39d125b4m1d5a161f60467def@mail.gmail.com> <816c7e0a80ac70bf6dba69c1da579fdc@stroeder.com> <71fe4e760701271706h7678575v6e5e4dddedaf0897@mail.gmail.com> Message-ID: <45BDD613.2080209@stroeder.com> Alain Spineux wrote: > > Python is a language made to help and facilitate the developer work : > - the developer dont need to test the result of any function, python > (or the library) raise an exception if something is wrong. > - the developer dont need to worry about the memory allocation, the > garbage collector do it for him. > - the developer dont need to close a file, the system do it for him > when the object is released > - the developer don't need to worry for long living LDAP connection, > ReconnectLDAPObject auto reconnect automatically for him :-) > - python-ldap is also thread safe ..... Your list rather arguments for adding SimpleLDAPObject.__del__() if not implemented yet (I have to look at it). > Then why does the developer have to encapsulate any ldap statement into a > > try: > except ldap.SERVER_DOWN,e: > SimpleLDAPObject.unbind_s(self) Because in case of ldap.SERVER_DOWN the application might have some means for fail-over, smart error handling or similar. python-ldap is rather low-level. I expect application developers to wrap something around SimpleLDAPObject which better suits there needs. And I'd like to avoid breaking existing code. Calling unbind_s() twice raises ldap.LDAPError: LDAP connection invalid Do you have an overview how other database modules handle such cases? Ciao, Michael. From aspineux at gmail.com Mon Jan 29 15:27:52 2007 From: aspineux at gmail.com (Alain Spineux) Date: Mon, 29 Jan 2007 15:27:52 +0100 Subject: ReconnectLDAPObject doesn't reconnect after main failure In-Reply-To: <45BDD613.2080209@stroeder.com> References: <71fe4e760701261339s532fe087v83d7b133ae227077@mail.gmail.com> <45BA8435.4040102@stroeder.com> <71fe4e760701261657s71747857r1960ccba5998e817@mail.gmail.com> <45BAA448.40403@stroeder.com> <71fe4e760701270359l39d125b4m1d5a161f60467def@mail.gmail.com> <816c7e0a80ac70bf6dba69c1da579fdc@stroeder.com> <71fe4e760701271706h7678575v6e5e4dddedaf0897@mail.gmail.com> <45BDD613.2080209@stroeder.com> Message-ID: <71fe4e760701290627m785d3accwfa23cc6878643505@mail.gmail.com> Convinced :-) Best regards. On 1/29/07, Michael Str?der wrote: > Alain Spineux wrote: > > > > Python is a language made to help and facilitate the developer work : > > - the developer dont need to test the result of any function, python > > (or the library) raise an exception if something is wrong. > > - the developer dont need to worry about the memory allocation, the > > garbage collector do it for him. > > - the developer dont need to close a file, the system do it for him > > when the object is released > > - the developer don't need to worry for long living LDAP connection, > > ReconnectLDAPObject auto reconnect automatically for him :-) > > - python-ldap is also thread safe ..... > > Your list rather arguments for adding SimpleLDAPObject.__del__() if not > implemented yet (I have to look at it). > > > Then why does the developer have to encapsulate any ldap statement into a > > > > try: > > except ldap.SERVER_DOWN,e: > > SimpleLDAPObject.unbind_s(self) > > Because in case of ldap.SERVER_DOWN the application might have some > means for fail-over, smart error handling or similar. python-ldap is > rather low-level. I expect application developers to wrap something > around SimpleLDAPObject which better suits there needs. > > And I'd like to avoid breaking existing code. Calling unbind_s() twice > raises > ldap.LDAPError: LDAP connection invalid > > Do you have an overview how other database modules handle such cases? > > Ciao, Michael. > -- -- Alain Spineux aspineux gmail com May the sources be with you From bowmanj at users.sourceforge.net Sat Feb 10 14:28:12 2007 From: bowmanj at users.sourceforge.net (Jonathan Bowman) Date: Sat, 10 Feb 2007 08:28:12 -0500 Subject: Compiling on windows Message-ID: <7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0@mail.gmail.com> I have been trying to build python-ldap on Windows. First, I need to build openldap on Windows using openssl, heimdal (kerberos 5, gssapi, etc.), and cyrus-sasl. I am doing this using mingw (as I assume that is what python-ldap uses). OpenSSL is not a problem, but then I get stuck on heimdal, which keeps me from compiling cyrus-sasl. Should I be using MIT Kerberos instead? (I do not know how to build MIT Kerberos using mingw). I am using MSYS, heimdal has a problem with sockets on Windows. Can anyone give me any hints at all? At this point, I do not know how to do this without getting involved in altering significant source code in heimdal, which is beyond my means. Thanks for any response, Jonathan Bowman From anilj at entic.net Sun Feb 11 03:20:42 2007 From: anilj at entic.net (Anil Jangity) Date: Sat, 10 Feb 2007 18:20:42 -0800 Subject: Compiling on windows In-Reply-To: <7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0@mail.gmail.com> References: <7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0@mail.gmail.com> Message-ID: There is a windows python-ldap (2.0.6 py 2.4) available here: http://www.agescibs.org/mauro/ But its a little old... Anyone working on getting one up for python 2.5 and latest python-ldap release? On 2/10/07, Jonathan Bowman wrote: > I have been trying to build python-ldap on Windows. First, I need to > build openldap on Windows using openssl, heimdal (kerberos 5, gssapi, > etc.), and cyrus-sasl. I am doing this using mingw (as I assume that > is what python-ldap uses). > > OpenSSL is not a problem, but then I get stuck on heimdal, which keeps > me from compiling cyrus-sasl. Should I be using MIT Kerberos instead? > (I do not know how to build MIT Kerberos using mingw). I am using > MSYS, heimdal has a problem with sockets on Windows. > > Can anyone give me any hints at all? At this point, I do not know how > to do this without getting involved in altering significant source > code in heimdal, which is beyond my means. > > Thanks for any response, > Jonathan Bowman > > From bowmanj at users.sourceforge.net Mon Feb 12 22:04:29 2007 From: bowmanj at users.sourceforge.net (Jonathan Bowman) Date: Mon, 12 Feb 2007 16:04:29 -0500 Subject: Compiling on windows In-Reply-To: References: <7a2b5dfb0702100528t64cfeaf0gd7859338f998a0d0@mail.gmail.com> Message-ID: <7a2b5dfb0702121304m53a06eb0rbc446971045a18d4@mail.gmail.com> Yes, exactly. While we are at it, can we try to compile in sasl support? The catch, so far, is, again, heimdal. It is not winsock aware. However, I have heard that it can be done. I am just stuck as to how. Perhaps I should just ask a couple simple questions: Should we use heimdal or MIT kerberos? I have been assuming heimdal, as MIT kerberos does not compile with mingw/msys. Should we use mingw/msys, or vc++? I have been assuming mingw/msys. Is there a way to get mingw to use MIT kerberos libraries compiled with vc++? If anyone can point me in the right direction, I would be grateful. Thanks, Jonathan Bowman On 2/10/07, Anil Jangity wrote: > There is a windows python-ldap (2.0.6 py 2.4) available here: > http://www.agescibs.org/mauro/ > > But its a little old... > > Anyone working on getting one up for python 2.5 and latest python-ldap release? > > On 2/10/07, Jonathan Bowman wrote: > > I have been trying to build python-ldap on Windows. First, I need to > > build openldap on Windows using openssl, heimdal (kerberos 5, gssapi, > > etc.), and cyrus-sasl. I am doing this using mingw (as I assume that > > is what python-ldap uses). > > > > OpenSSL is not a problem, but then I get stuck on heimdal, which keeps > > me from compiling cyrus-sasl. Should I be using MIT Kerberos instead? > > (I do not know how to build MIT Kerberos using mingw). I am using > > MSYS, heimdal has a problem with sockets on Windows. > > > > Can anyone give me any hints at all? At this point, I do not know how > > to do this without getting involved in altering significant source > > code in heimdal, which is beyond my means. > > > > Thanks for any response, > > Jonathan Bowman > > > > From jphthierry at free.fr Mon Feb 19 09:08:43 2007 From: jphthierry at free.fr (jphthierry at free.fr) Date: Mon, 19 Feb 2007 09:08:43 +0100 Subject: Newbie and encoding Message-ID: <1171872523.45d95b0b5bf23@imp.free.fr> Hi, I was used to work with phpldapadmin, then discovered luma. Now I need something more specific to my needs, and thus interested in python-ldap. Starting was really easy :-) Unfortunately, I discovered a bug in my application this week-end: I can not use 8 bits chars in search or add functions while I have no issue with these characters in Luma :-( It seems to be related to string encoding. Luma makes an intensive use of the "unicode" function. So I tried that piece of code but without success: >>> import ldap >>> CON=ldap.open('localhost.localdomain') >>> CON.simple_bind_s('','') >>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th?*)') exceptions.UnicodeEncodeError Traceback (most recent call last) /home/jpht/informatique/programmation/python/scripts/under_development/ /usr/lib/python2.3/site-packages/ldap/ldapobject.py in search_s(self, base, scope, filterstr, attrlist, attrsonly) 466 467 def search_s(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0): --> 468 return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,timeout=self.timeout) 469 470 def search_st(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0,timeout=-1): /usr/lib/python2.3/site-packages/ldap/ldapobject.py in search_ext_s(self, base, scope, filterstr, attrlist, attrsonly, serverctrls, clientctrls, timeout, sizelimit) 459 460 def search_ext_s(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0,serverctrls=None,clientctrls=None,timeout=-1,sizelimit=0): --> 461 msgid = self._ldap_call(self._l.search_ext,base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit) 462 return self.result(msgid,all=1,timeout=timeout)[1] 463 /usr/lib/python2.3/site-packages/ldap/ldapobject.py in _ldap_call(self, func, *args, **kwargs) 92 try: 93 try: ---> 94 result = func(*args,**kwargs) 95 finally: 96 self._ldap_object_lock.release() UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6: ordinal not in range(128) I went quickly through this list, but was not sure of understanding the answer ;-( Could someone help me? Jean-Philippe P.S.: I am running slapd 2.2.23 and python-ldap 2.0.4 (debian sarge) From bjorn.grotan at itea.ntnu.no Mon Feb 19 09:18:06 2007 From: bjorn.grotan at itea.ntnu.no (Bjorn Ove Grotan) Date: Mon, 19 Feb 2007 09:18:06 +0100 Subject: Newbie and encoding In-Reply-To: <1171872523.45d95b0b5bf23@imp.free.fr> References: <1171872523.45d95b0b5bf23@imp.free.fr> Message-ID: <20070219081806.GA9384@itea.ntnu.no> jphthierry at free.fr: > Hi, > > I was used to work with phpldapadmin, then discovered luma. Now I need something > more specific to my needs, and thus interested in python-ldap. > > Starting was really easy :-) Unfortunately, I discovered a bug in my application > this week-end: I can not use 8 bits chars in search or add functions while I > have no issue with these characters in Luma :-( It seems to be related to string > encoding. Luma makes an intensive use of the "unicode" function. So I tried that > piece of code but without success: > > >>> import ldap > >>> CON=ldap.open('localhost.localdomain') > >>> CON.simple_bind_s('','') > >>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th?)') > UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6: > ordinal not in range(128) LDAP uses utf8 - so convert any umlauts or whatever to utf8 before doing a query. Mostly anything can be converted _to_ utf8, but not will convert back to the encoding you came from. def utf8_encode(str): return unicode(str, "iso-8859-1").encode("utf-8") def utf8_decode(str): return unicode(str, "utf-8").encode("iso-8859-1") Usage: filter = utf8_encode('cn=Bj?rn Ove Gr?tan') Just change from iso-8859-1 to whatever encoding you use by default. -- Regards Bj?rn Ove Gr?tan Luma Debian Maintainer From michael at stroeder.com Mon Feb 19 12:04:46 2007 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Mon, 19 Feb 2007 12:04:46 +0100 Subject: Newbie and encoding In-Reply-To: <1171872523.45d95b0b5bf23@imp.free.fr> References: <1171872523.45d95b0b5bf23@imp.free.fr> Message-ID: <45D9844E.8090700@stroeder.com> jphthierry at free.fr wrote: > > I can not use 8 bits chars in search or add functions while I > have no issue with these characters in Luma :-( It seems to be related to string > encoding. Luma makes an intensive use of the "unicode" function. So I tried that > piece of code but without success: > >>>> import ldap >>>> CON=ldap.open('localhost.localdomain') >>>> CON.simple_bind_s('','') >>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th?*)') You have to pass raw strings to python-ldap since the API does not handle Unicode strings automatically. So something like u'(cn=th?*)'.encode('utf-8'). Not sure what the ? is in your e-mail though. Therefore I'd recommend not to directly write 8-bit chars into the Python source code. Rather use the escaping \x.. Complete example with my last name within Python shell and shell charset being UTF-8. Python 2.5 (r25:51908, Nov 27 2006, 19:14:46) [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> ustr=unicode('Str?der','utf-8') >>> ustr u'Str\xf6der' >>> ustr.encode('utf-8') 'Str\xc3\xb6der' >>> Ciao, Michael. From jphthierry at free.fr Mon Feb 19 21:02:22 2007 From: jphthierry at free.fr (Jean-Philippe THIERRY) Date: Mon, 19 Feb 2007 21:02:22 +0100 Subject: Newbie and encoding In-Reply-To: <45D9844E.8090700@stroeder.com> References: <1171872523.45d95b0b5bf23@imp.free.fr> <45D9844E.8090700@stroeder.com> Message-ID: <20070219210222.2c6abe19.jphthierry@free.fr> On Mon, 19 Feb 2007 12:04:46 +0100 Michael Str?der wrote: > jphthierry at free.fr wrote: > > > > I can not use 8 bits chars in search or add functions while I > > have no issue with these characters in Luma :-( It seems to be related to string > > encoding. Luma makes an intensive use of the "unicode" function. So I tried that > > piece of code but without success: > > > >>>> import ldap > >>>> CON=ldap.open('localhost.localdomain') > >>>> CON.simple_bind_s('','') > >>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th?*)') > > You have to pass raw strings to python-ldap since the API does not > handle Unicode strings automatically. > > So something like u'(cn=th?*)'.encode('utf-8'). > > Not sure what the ? is in your e-mail though. Therefore I'd recommend > not to directly write 8-bit chars into the Python source code. Rather > use the escaping \x.. > > Complete example with my last name within Python shell and shell charset > being UTF-8. > > Python 2.5 (r25:51908, Nov 27 2006, 19:14:46) > [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> ustr=unicode('Str?der','utf-8') > >>> ustr > u'Str\xf6der' > >>> ustr.encode('utf-8') > 'Str\xc3\xb6der' > >>> > > Ciao, Michael. > Thanks to you (and Bjorn ;-)). It works far better now. Life would have been far easier if English was full of strange chars :-) Jean-Philippe From sakagami at gmail.com Tue Feb 20 17:24:42 2007 From: sakagami at gmail.com (Hiroki Sakagami) Date: Wed, 21 Feb 2007 01:24:42 +0900 Subject: python-ldap and asyncore Message-ID: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> Hi, I'm trying to use python-ldap with asyncore event loop. Since asyncore's event source is a socket object, I can't use search() and result() style polling. Is it possible to access a socket object in the LDAPObject instance? Regards, -- Hiroki Sakagami From aspineux at gmail.com Thu Feb 22 14:06:36 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 22 Feb 2007 14:06:36 +0100 Subject: python-ldap and asyncore In-Reply-To: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> References: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> Message-ID: <71fe4e760702220506s558c0bc6hdce96d0abb186028@mail.gmail.com> http://www.openldap.org/lists/openldap-software/200102/msg00290.html hope this help On 2/20/07, Hiroki Sakagami wrote: > Hi, > > I'm trying to use python-ldap with asyncore event loop. Since > asyncore's event source is a socket object, I can't use search() and > result() style polling. Is it possible to access a socket object in > the LDAPObject instance? > > Regards, > > -- > Hiroki Sakagami > > From anilj at entic.net Sat Feb 24 04:14:04 2007 From: anilj at entic.net (Anil Jangity) Date: Fri, 23 Feb 2007 19:14:04 -0800 Subject: peculiar problem Message-ID: (thanks for all the help in my previous posts) Hi, I am seeing a peculiar problem in this area of the code. I don't know exactly how to reproduce it. It almost like I have to wait a while and I see this problem. url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?')) try: print url ldap_url = ldapurl.LDAPUrl(url) print ldap_url.attrs print attr except ValueError: print "Bad URL" The output is: ldap://somehost.com:389/ou=People, o=entic.net?uid?one?mail=anilj at entic.net? [u'uid'] uid Error - : ('expected string in list', u'uid') I am not sure if this is with my Pylons (web development framework) or something specific to python-ldap. Let me know if you can give me pointers on how I can try to troubleshoot this. Thanks, Anil From michael at stroeder.com Sun Feb 25 14:00:51 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 25 Feb 2007 14:00:51 +0100 Subject: peculiar problem In-Reply-To: References: Message-ID: <45E18883.3010101@stroeder.com> Anil Jangity wrote: > (thanks for all the help in my previous posts) > > Hi, > > I am seeing a peculiar problem in this area of the code. I don't know > exactly how to reproduce it. It almost like I have to wait a while and > I see this problem. > > url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?')) > try: > print url > ldap_url = ldapurl.LDAPUrl(url) > print ldap_url.attrs > print attr > except ValueError: > print "Bad URL" > > The output is: > > ldap://somehost.com:389/ou=People, o=entic.net?uid?one?mail=anilj at entic.net? > [u'uid'] > uid > Error - : ('expected string in list', u'uid') I can't reproduce the error since you didn't provide enough code. But this simply works regarding module ldapurl: >>> u=u'ldap://somehost.com:389/ou=People, o=entic.net?uid?one?mail=anilj at entic.net?' >>> ldap_url=ldapurl.LDAPUrl(u) >>> ldap_url.attrs [u'uid'] Ciao, Michael. From michael at stroeder.com Sun Feb 25 14:07:33 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 25 Feb 2007 14:07:33 +0100 Subject: peculiar problem In-Reply-To: References: Message-ID: <45E18A15.6020708@stroeder.com> Anil Jangity wrote: > > url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?')) > try: > print url > ldap_url = ldapurl.LDAPUrl(url) BTW: See also 2nd example on http://python-ldap.sourceforge.net/doc/python-ldap/ldapurl-example.html Ciao, Michael. From michael at stroeder.com Mon Feb 26 23:58:14 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 26 Feb 2007 23:58:14 +0100 Subject: python-ldap and asyncore In-Reply-To: <71fe4e760702220506s558c0bc6hdce96d0abb186028@mail.gmail.com> References: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> <71fe4e760702220506s558c0bc6hdce96d0abb186028@mail.gmail.com> Message-ID: <45E36606.5010408@stroeder.com> Alain Spineux wrote: > On 2/20/07, Hiroki Sakagami wrote: >> Hi, >> >> I'm trying to use python-ldap with asyncore event loop. Since >> asyncore's event source is a socket object, I can't use search() and >> result() style polling. Is it possible to access a socket object in >> the LDAPObject instance? > > http://www.openldap.org/lists/openldap-software/200102/msg00290.html > > hope this help One would have to patch Modules/options.c and Modules/constants.c for this to theoretically work. Ciao, Michael. From anilj at entic.net Tue Feb 27 00:27:01 2007 From: anilj at entic.net (Anil Jangity) Date: Mon, 26 Feb 2007 15:27:01 -0800 Subject: peculiar problem In-Reply-To: <45E18A15.6020708@stroeder.com> References: <45E18A15.6020708@stroeder.com> Message-ID: I notice this in other areas of my code as well. Here is a trace of a modify: *** ldap://host:389 - SimpleLDAPObject.modify_ext (('cn=Shilpa J, uid=anilj, ou=People, o=entic.net', [(0, 'mail', [u'shilpa.j at something.com'])], None, None),{}) Error - : ('expected a string in the list', u'shilpa.j at something.com') The problem is, it seems work on and off. When the modifications or searches are done without the unicode string, it works. But later when I try to do the same thing again for some reason it trys to do the LDAP operation using unicode lists: [u'abc'] Thats when it fails. Is it something else in my code that is causing it or is something else wrong in the python-ldap? I'll see if I can find more details/code. I was just wondering if you guys knew off the top of your heads... On 2/25/07, Michael Str?der wrote: > Anil Jangity wrote: > > > > url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?')) > > try: > > print url > > ldap_url = ldapurl.LDAPUrl(url) > > BTW: See also 2nd example on > > http://python-ldap.sourceforge.net/doc/python-ldap/ldapurl-example.html > > Ciao, Michael. > From michael at stroeder.com Tue Feb 27 00:54:48 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 27 Feb 2007 00:54:48 +0100 Subject: peculiar problem In-Reply-To: References: <45E18A15.6020708@stroeder.com> Message-ID: <45E37348.80502@stroeder.com> Anil Jangity wrote: > I notice this in other areas of my code as well. > > Here is a trace of a modify: > > *** ldap://host:389 - SimpleLDAPObject.modify_ext (('cn=Shilpa J, > uid=anilj, ou=People, o=entic.net', [(0, 'mail', > [u'shilpa.j at something.com'])], None, None),{}) > Error - : ('expected a string in the > list', u'shilpa.j at something.com') > > > The problem is, it seems work on and off. When the modifications or > searches are done without the unicode string, it works. But later > when I try to do the same thing again for some reason it trys to do > the LDAP operation using unicode lists: [u'abc'] > > Thats when it fails. You have to pass solely raw strings to python-ldap since the API does not handle Unicode strings automatically. u'shilpa.j at something.com'.encode('utf-8') Ciao, Michael. From sakagami at gmail.com Wed Feb 28 17:55:55 2007 From: sakagami at gmail.com (Hiroki Sakagami) Date: Thu, 1 Mar 2007 01:55:55 +0900 Subject: python-ldap and asyncore In-Reply-To: <45E36606.5010408@stroeder.com> References: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> <71fe4e760702220506s558c0bc6hdce96d0abb186028@mail.gmail.com> <45E36606.5010408@stroeder.com> Message-ID: <8389af8b0702280855q3f3d2912n5094abaa75b52d72@mail.gmail.com> Hi, Thank you for your reply. So, I can get the socket object by adding such a method manually. Is there any chance there will be support for LDAP_OPT_DESC in future python-ldap? -- Hiroki Sakagami On 2/27/07, Michael Str?der wrote: > Alain Spineux wrote: > > On 2/20/07, Hiroki Sakagami wrote: > >> Hi, > >> > >> I'm trying to use python-ldap with asyncore event loop. Since > >> asyncore's event source is a socket object, I can't use search() and > >> result() style polling. Is it possible to access a socket object in > >> the LDAPObject instance? > > > > http://www.openldap.org/lists/openldap-software/200102/msg00290.html > > > > hope this help > > One would have to patch Modules/options.c and Modules/constants.c for > this to theoretically work. > > Ciao, Michael. > From michael at stroeder.com Wed Feb 28 18:23:06 2007 From: michael at stroeder.com (=?UTF-8?B?Ik1pY2hhZWwgU3Ryw7ZkZXIi?=) Date: Wed, 28 Feb 2007 18:23:06 +0100 Subject: python-ldap and asyncore In-Reply-To: <8389af8b0702280855q3f3d2912n5094abaa75b52d72@mail.gmail.com> References: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> <71fe4e760702220506s558c0bc6hdce96d0abb186028@mail.gmail.com> <45E36606.5010408@stroeder.com> <8389af8b0702280855q3f3d2912n5094abaa75b52d72@mail.gmail.com> Message-ID: On 5:55:55 pm 2007-02-28 "Hiroki Sakagami" wrote: > > Thank you for your reply. So, I can get the socket object by adding > such a method manually. Is there any chance there will be support for > LDAP_OPT_DESC in future python-ldap? Feel free to submit a patch. Ciao, Michael. From michael at stroeder.com Thu Mar 1 09:17:29 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 01 Mar 2007 09:17:29 +0100 Subject: python-ldap and asyncore In-Reply-To: <8389af8b0702280855q3f3d2912n5094abaa75b52d72@mail.gmail.com> References: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> <71fe4e760702220506s558c0bc6hdce96d0abb186028@mail.gmail.com> <45E36606.5010408@stroeder.com> <8389af8b0702280855q3f3d2912n5094abaa75b52d72@mail.gmail.com> Message-ID: <45E68C19.7010908@stroeder.com> Hiroki Sakagami wrote: > > Thank you for your reply. So, I can get the socket object by adding > such a method manually. Is there any chance there will be support for > LDAP_OPT_DESC in future python-ldap? Not sure what you mean with "socket object". Let's read http://www.openldap.org/lists/openldap-software/200102/msg00290.html once again: "You can use ldap_get_option(ld, LDAP_OPT_DESC, &sd) to access the primary file descriptor associated with a session handle." This function of the OpenLDAP C SDK returns just the OS' file descriptor. I never worked with asyncore. Not sure what you need. Ciao, Michael. From sakagami at gmail.com Thu Mar 1 16:56:51 2007 From: sakagami at gmail.com (Hiroki Sakagami) Date: Fri, 2 Mar 2007 00:56:51 +0900 Subject: python-ldap and asyncore In-Reply-To: References: <8389af8b0702200824yc1f78fnfac7dae219be1815@mail.gmail.com> <71fe4e760702220506s558c0bc6hdce96d0abb186028@mail.gmail.com> <45E36606.5010408@stroeder.com> <8389af8b0702280855q3f3d2912n5094abaa75b52d72@mail.gmail.com> Message-ID: <8389af8b0703010756o7a836113kfaec00559291450f@mail.gmail.com> On 3/1/07, "Michael Str?der" wrote: > On 5:55:55 pm 2007-02-28 "Hiroki Sakagami" wrote: > > > > Thank you for your reply. So, I can get the socket object by adding > > such a method manually. Is there any chance there will be support for > > LDAP_OPT_DESC in future python-ldap? > > Feel free to submit a patch. OK, I'm going to try to implement it. -- Hiroki Sakagami From airween at gmail.com Fri Mar 9 16:45:49 2007 From: airween at gmail.com (=?ISO-8859-1?Q?Ervin_Heged=FCs?=) Date: Fri, 9 Mar 2007 16:45:49 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX Message-ID: Hello, here is an Ubuntu Server box (6.06) with python 2.4, python-ldap 2.0.4, and slapd 2.2.26 - all of these from Ubuntu package. Here is an application, what runs by crontab in every minutes. It looks a list, and if list was modified, it modifies LDAP tree. (List generated by a directory's items.) Early version of that app use to add an entry OBJECT.add() method, but it was not sync mode, and crontabs 1 minute was not enough to sync tree. So I changed to add_s(), and then my application adds entry sync correctly. But now, when original list modified, and app runs by crontab, I get this error: Traceback (most recent call last): File "/usr/local/checkftpdir/chkdir.py", line 43, in ? L.addEntry(d, base, '') File "/usr/local/checkftpdir/Ldapfunctions.py", line 61, in addEntry self.l.add_s(_dn, ldif) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 163, in add_s self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 399, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 405, in result2 return self._ldap_call(self._l.result2,msgid,all,timeout) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 94, in _ldap_call result = func(*args,**kwargs) ldap.INVALID_DN_SYNTAX: {'info': 'invalid DN', 'desc': 'Invalid DN syntax'} and entry added correctly to tree. BUT, when I run it interactive, I _don't_get_any_ error. del_s() method doesn't give any error, just add_s(). Any suggestion? Thank you: a. From michael at stroeder.com Fri Mar 9 20:16:38 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 09 Mar 2007 20:16:38 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: References: Message-ID: <45F1B296.8040100@stroeder.com> Ervin Heged?s wrote: > > File "/usr/local/checkftpdir/Ldapfunctions.py", line 61, in addEntry > self.l.add_s(_dn, ldif) > File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 163, in add_s > self.result(msgid,all=1,timeout=self.timeout) > File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line > 399, in result > res_type,res_data,res_msgid = self.result2(msgid,all,timeout) > File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line > 405, in result2 > return self._ldap_call(self._l.result2,msgid,all,timeout) > File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 94, > in _ldap_call result = func(*args,**kwargs) > ldap.INVALID_DN_SYNTAX: {'info': 'invalid DN', 'desc': 'Invalid DN syntax'} This is an error the server sends back. Probably you're generating a DN with invalid syntax. I'd recommend to set trace_level=2 with ldap.initialize() to see what the python-ldap API receives from your script. Ciao, Michael. From airween at gmail.com Fri Mar 9 21:21:59 2007 From: airween at gmail.com (=?ISO-8859-1?Q?Ervin_Heged=FCs?=) Date: Fri, 9 Mar 2007 21:21:59 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: <45F1B296.8040100@stroeder.com> References: <45F1B296.8040100@stroeder.com> Message-ID: Hello, > > File "/usr/local/checkftpdir/Ldapfunctions.py", line 61, in addEntry > > self.l.add_s(_dn, ldif) [...] > > File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 94, > > in _ldap_call result = func(*args,**kwargs) > > ldap.INVALID_DN_SYNTAX: {'info': 'invalid DN', 'desc': 'Invalid DN syntax'} > > This is an error the server sends back. Probably you're generating a DN > with invalid syntax. I'd recommend to set trace_level=2 with > ldap.initialize() to see what the python-ldap API receives from your script. I'm not sure about it - as I wrote when I run script from system shell (I mean: interactively), then script doesn't drop any exception. I try to print out the DN value, what I give to the function as first argument, and it looks like a normally DN, eg.: cn=airtest,ou=ftp,o=company,dc=domain,dc=com. There aren't any spaces, or other chars, what I miss then. By the way: I try to set up those trace_level, may be it will be more informative... thanks: a. From chaoseternal at gmail.com Sat Mar 10 05:33:28 2007 From: chaoseternal at gmail.com (Chaos Eternal) Date: Sat, 10 Mar 2007 12:33:28 +0800 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: References: <45F1B296.8040100@stroeder.com> Message-ID: <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> hello there, Since your script is run by cron every one minute, i wonder that do you have any lock mechanisms to prevent more than one instance of your script to start? some buggy or mis-configured ldapserver can not work properly when large amounts of write operations come simultaneously. What I suggest is carefully re-design your script. use some lock mechanisms and some queue technologies. On 3/10/07, Ervin Heged?s wrote: > Hello, > > > > File "/usr/local/checkftpdir/Ldapfunctions.py", line 61, in addEntry > > > self.l.add_s(_dn, ldif) > [...] > > > File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 94, > > > in _ldap_call result = func(*args,**kwargs) > > > ldap.INVALID_DN_SYNTAX: {'info': 'invalid DN', 'desc': 'Invalid DN syntax'} > > > > This is an error the server sends back. Probably you're generating a DN > > with invalid syntax. I'd recommend to set trace_level=2 with > > ldap.initialize() to see what the python-ldap API receives from your script. > > I'm not sure about it - as I wrote when I run script from system shell (I mean: > interactively), then script doesn't drop any exception. I try to print > out the DN > value, what I give to the function as first argument, and it looks > like a normally > DN, eg.: cn=airtest,ou=ftp,o=company,dc=domain,dc=com. > > There aren't any spaces, or other chars, what I miss then. > > By the way: I try to set up those trace_level, may be it will be more > informative... > > thanks: > > a. > > From airween at gmail.com Sat Mar 10 09:37:50 2007 From: airween at gmail.com (=?ISO-8859-1?Q?Ervin_Heged=FCs?=) Date: Sat, 10 Mar 2007 09:37:50 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> References: <45F1B296.8040100@stroeder.com> <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> Message-ID: Hello, > Since your script is run by cron every one minute, i wonder that do > you have any lock mechanisms to prevent more than one instance of your > script to start? It's very interesting theory... > some buggy or mis-configured ldapserver can not work > properly when large amounts of write operations come simultaneously. Hmmm... I think there is _no_ other thread (or process), what wants to write to database. > What I suggest is carefully re-design your script. use some lock > mechanisms and some queue technologies. I don't think so it any LDAP client requires this feature. It's like any SQL server needs to lock a table, when a client wants to insert a simple record. (Don't wrong me: I know, there are many cases need to lock a table, but IMHO that's for other cases) Handle the clients requests is the most common function of any kind of "database" servers - in this case the database word means any kind of structure-handle application. :) But this is a flame-way, sorry. Back to my problem: on that machine there is just one user, who gets access to LDAP db, and that user write to db _only_ when original list was modified. That's occurrence is 1-5 event per week...(!) Thanks: a. From chaoseternal at gmail.com Sun Mar 11 06:05:59 2007 From: chaoseternal at gmail.com (Chaos Eternal) Date: Sun, 11 Mar 2007 13:05:59 +0800 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: References: <45F1B296.8040100@stroeder.com> <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> Message-ID: <6456782e0703102105k6f48140x360ae2861bac381a@mail.gmail.com> Helo On 3/10/07, Ervin Heged?s wrote: > Hello, > > > Since your script is run by cron every one minute, i wonder that do > > you have any lock mechanisms to prevent more than one instance of your > > script to start? > It's very interesting theory... chaos at felucia:~$ ps afx|grep sleep 25170 ? Ss 0:00 | \_ sleep 300 25246 ? Ss 0:00 | \_ sleep 300 25324 ? Ss 0:00 | \_ sleep 300 25403 ? Ss 0:00 | \_ sleep 300 25486 ? Ss 0:00 \_ sleep 300 25530 pts/5 S+ 0:00 | \_ grep sleep chaos at felucia:~$ crontab -l # m h dom mon dow command * * * * * sleep 300 have i missed something? > > > some buggy or mis-configured ldapserver can not work > > properly when large amounts of write operations come simultaneously. > Hmmm... I think there is _no_ other thread (or process), what wants to > write to database. Still dont get it? > > > What I suggest is carefully re-design your script. use some lock > > mechanisms and some queue technologies. > > I don't think so it any LDAP client requires this feature. It's like any > SQL server needs to lock a table, when a client wants to insert a > simple record. > (Don't wrong me: I know, there are many cases need to lock a table, > but IMHO that's for other cases) > > Handle the clients requests is the most common function of any kind > of "database" servers - in this case the database word means any kind > of structure-handle application. :) But this is a flame-way, sorry. > > Back to my problem: on that machine there is just one user, who gets > access to LDAP db, and that user write to db _only_ when original list > was modified. That's occurrence is 1-5 event per week...(!) If the event only occures 1-5 time per-week, why you make your script run every minute? > > Thanks: > a. > > From michael at stroeder.com Sun Mar 11 11:17:33 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 11 Mar 2007 11:17:33 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: References: <45F1B296.8040100@stroeder.com> Message-ID: <45F3D73D.9080306@stroeder.com> Ervin Heged?s wrote: > > I'm not sure about it - as I wrote when I run script from system shell (I mean: > interactively), then script doesn't drop any exception. If your script behaves differently when invoked from system shell then their is another problem. > I try to print > out the DN > value, what I give to the function as first argument, and it looks > like a normally > DN, eg.: cn=airtest,ou=ftp,o=company,dc=domain,dc=com. ^^^ I guess the trailing dot is the end of the sentence and not part of your DN? > By the way: I try to set up those trace_level, may be it will be more > informative... I recommend this since you see then which values get really passed into python-ldap. Ciao, Michael. From michael at stroeder.com Sun Mar 11 11:19:25 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 11 Mar 2007 11:19:25 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> References: <45F1B296.8040100@stroeder.com> <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> Message-ID: <45F3D7AD.6070208@stroeder.com> Chaos Eternal wrote: > hello there, > Since your script is run by cron every one minute, i wonder that do > you have any lock mechanisms to prevent more than one instance of your > script to start? some buggy or mis-configured ldapserver can not work > properly when large amounts of write operations come simultaneously. Very unlikely. This would be a really brain-dead LDAP server. > What I suggest is carefully re-design your script. use some lock > mechanisms and some queue technologies. LDAP add and modify operations are atomic. The LDAP server takes care of database locking. And python-ldap takes care of locks for using a LDAP connection in several threads. Ciao, Michael. From michael at stroeder.com Sun Mar 11 11:23:03 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 11 Mar 2007 11:23:03 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: <6456782e0703102105k6f48140x360ae2861bac381a@mail.gmail.com> References: <45F1B296.8040100@stroeder.com> <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> <6456782e0703102105k6f48140x360ae2861bac381a@mail.gmail.com> Message-ID: <45F3D887.4080005@stroeder.com> Chaos Eternal wrote: >> >> Back to my problem: on that machine there is just one user, who gets >> access to LDAP db, and that user write to db _only_ when original list >> was modified. That's occurrence is 1-5 event per week...(!) > > If the event only occures 1-5 time per-week, why you make your script > run every minute? I guess he does not want to have a longer latency for passing the modifications to the LDAP server and there's no other possibility to trigger running the script event-based when the original list is actually updated. Ciao, Michael. From airween at gmail.com Sun Mar 11 20:55:06 2007 From: airween at gmail.com (=?ISO-8859-1?Q?Ervin_Heged=FCs?=) Date: Sun, 11 Mar 2007 20:55:06 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: <45F3D73D.9080306@stroeder.com> References: <45F1B296.8040100@stroeder.com> <45F3D73D.9080306@stroeder.com> Message-ID: Hello there, > If your script behaves differently when invoked from system shell then > their is another problem. I think that - but where could be that problem? > > DN, eg.: cn=airtest,ou=ftp,o=company,dc=domain,dc=com. > ^^^ > I guess the trailing dot is the end of the sentence and not part of your DN? No, that dot is the 'end of the sentence', not part of DN. > I recommend this since you see then which values get really passed into > python-ldap. thanks, I will try this... a. From airween at gmail.com Sun Mar 11 21:16:41 2007 From: airween at gmail.com (=?ISO-8859-1?Q?Ervin_Heged=FCs?=) Date: Sun, 11 Mar 2007 21:16:41 +0100 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: <6456782e0703102105k6f48140x360ae2861bac381a@mail.gmail.com> References: <45F1B296.8040100@stroeder.com> <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> <6456782e0703102105k6f48140x360ae2861bac381a@mail.gmail.com> Message-ID: Hello, > chaos at felucia:~$ ps afx|grep sleep > 25170 ? Ss 0:00 | \_ sleep 300 > 25246 ? Ss 0:00 | \_ sleep 300 > 25324 ? Ss 0:00 | \_ sleep 300 > 25403 ? Ss 0:00 | \_ sleep 300 > 25486 ? Ss 0:00 \_ sleep 300 > 25530 pts/5 S+ 0:00 | \_ grep sleep > chaos at felucia:~$ crontab -l > # m h dom mon dow command > * * * * * sleep 300 > > have i missed something? Nothing. Or rather yes. :) I didn't wrote, the run-time of script usually less than 1sec. Here is my output: # ps axf | grep chkdir.py 24859 pts/2 S+ 0:00 \_ grep chkdir.py > > Hmmm... I think there is _no_ other thread (or process), what wants to > > write to database. > > Still dont get it? no, I don't. > If the event only occures 1-5 time per-week, why you make your script > run every minute? Because event occurs randomly: sometime it occur monday morning, sometime friday evening - sometime it occurs in workhours, sometime out of workhours. This is not so simple.... Thank you: a. From chaoseternal at gmail.com Mon Mar 12 03:05:52 2007 From: chaoseternal at gmail.com (Chaos Eternal) Date: Mon, 12 Mar 2007 10:05:52 +0800 Subject: add_s: ldap.INVALID_DN_SYNTAX In-Reply-To: References: <45F1B296.8040100@stroeder.com> <6456782e0703092033t134d245ehc7cd430e7cdbae9b@mail.gmail.com> <6456782e0703102105k6f48140x360ae2861bac381a@mail.gmail.com> Message-ID: <6456782e0703111905o6f1a8a74w50da70c3c60058c5@mail.gmail.com> hi, Obviously , you didn't aware when your script didn't finish in one minute the cron would start another script doing the same job. As you have mentioned, 1 minute was not enough to sync tree. I think that is the core problem. So my suggestion is , when your script starts, aquire a lock, then do all the sync things, and release the lock before exit. Hope my suggestion can help. On 3/12/07, Ervin Heged?s wrote: > Hello, > > > chaos at felucia:~$ ps afx|grep sleep > > 25170 ? Ss 0:00 | \_ sleep 300 > > 25246 ? Ss 0:00 | \_ sleep 300 > > 25324 ? Ss 0:00 | \_ sleep 300 > > 25403 ? Ss 0:00 | \_ sleep 300 > > 25486 ? Ss 0:00 \_ sleep 300 > > 25530 pts/5 S+ 0:00 | \_ grep sleep > > chaos at felucia:~$ crontab -l > > # m h dom mon dow command > > * * * * * sleep 300 > > > > have i missed something? > Nothing. Or rather yes. :) > > I didn't wrote, the run-time of script usually less than 1sec. > > Here is my output: > # ps axf | grep chkdir.py > 24859 pts/2 S+ 0:00 \_ grep chkdir.py > > > > Hmmm... I think there is _no_ other thread (or process), what wants to > > > write to database. > > > > Still dont get it? > no, I don't. > > > If the event only occures 1-5 time per-week, why you make your script > > run every minute? > Because event occurs randomly: sometime it occur monday morning, > sometime friday evening - sometime it occurs in workhours, sometime > out of workhours. > > This is not so simple.... > > > Thank you: > > a. > > From michael at stroeder.com Wed Mar 14 05:54:15 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 14 Mar 2007 05:54:15 +0100 Subject: peculiar problem In-Reply-To: References: <45E18A15.6020708@stroeder.com> <45E37348.80502@stroeder.com> Message-ID: <45F77FF7.10406@stroeder.com> Anil, please keep replies to the python-ldap-dev list. Anil Jangity wrote: > > But, why couldn't python-ldap automatically encode as utf-8? Is it > because of performance issues? Each attribute has different syntax, e.g. 'jpegPhoto' etc. So you have to look at the schema to do the right thing. Or the application has prior knowledge like most people are implementing it. Strictly speaking in case of attribute 'mail' one would have to encode as 'ascii' since the LDAP syntax for this is IA5String and ASCII is the closest to this. Ciao, Michael. From garlandkr at gmail.com Mon Mar 19 19:21:47 2007 From: garlandkr at gmail.com (Garland, Ken R) Date: Mon, 19 Mar 2007 14:21:47 -0400 Subject: Error modlist.py in addModlist Message-ID: I've sliced together a script to add users to ldap, which works great. however, now i'm implementing it into a webapp and having some issues. -------------------- Spyce exception File: /home/kgarland/downloads/spyce-2.1/www/newadd.spy Message: AttributeError: 'str' object has no attribute 'keys' Stack: /usr/lib/python2.4/site-packages/ldap/modlist.py:34, in addModlist: for attrtype in entry.keys(): newadd.spy:19, in passcheck: mymodlist = ldap.modlist.addModlist(entry) -------------------- My code causing the issue: -------------------- def passcheck(self, api, passwd, firstname, lastname, vamcdrop): import string, sys, ldap, crack, hashlib, base64 try: crack.VeryFascistCheck(passwd) except ValueError, reason: print("Please use a different password, %s." % reason) else: l=ldap.initialize("ldaps://null") l.bind_s('cn=removed,dc=removed,dc=removed', 'removed') y = hashlib.sha1(passwd).digest() base64encode = base64.encodestring(y) userpass = string.rstrip(base64encode) uid = firstname.lower() + "." + lastname.lower() mydn = "uid=" + uid + ",ou=VA,dc=pharmacy,dc=com" entry = "{'uid': ['" + uid + "'], 'objectClass': ['top', 'inetOrgPerson'], 'userPassword': ['" + '{SHA}' + userpass + "'], 'vamc': ['" + vamcdrop + "'], 'sn': ['" + lastname + "'], 'givenName': ['" + firstname + "'], 'cn': ['" + firstname + " " + lastname + "']}" mymodlist = ldap.modlist.addModlist(entry) l.add_s(mydn, mymodlist) print "Adding the following information into LDAP:" print "
" print entry -------------------- Looks like modlist is not happy with the string being presented to it. Printing the entry variable gives the same results for both the webapp and commandline. Web: {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], 'givenName': ['null'], 'cn': ['null null']} Shell: {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], 'givenName': ['null'], 'cn': ['null null']} From aspineux at gmail.com Mon Mar 19 19:37:18 2007 From: aspineux at gmail.com (Alain Spineux) Date: Mon, 19 Mar 2007 19:37:18 +0100 Subject: Fwd: Error modlist.py in addModlist In-Reply-To: <71fe4e760703191135j35a29701x4973e0f740fa2e9a@mail.gmail.com> References: <71fe4e760703191135j35a29701x4973e0f740fa2e9a@mail.gmail.com> Message-ID: <71fe4e760703191137k1c01acaer5bd833f495e7b98a@mail.gmail.com> I didn't read your code, but I know ldap dont like python's unicode string. Convert any strings coming from your web interface into string, using str(). Hope this help On 3/19/07, Garland, Ken R wrote: > > I've sliced together a script to add users to ldap, which works great. > however, now i'm implementing it into a webapp and having some issues. > > -------------------- > Spyce exception > File: /home/kgarland/downloads/spyce- 2.1/www/newadd.spy > Message: > > AttributeError: 'str' object has no attribute 'keys' > > Stack: /usr/lib/python2.4/site-packages/ldap/modlist.py:34, in > addModlist: > > for attrtype in entry.keys (): > > newadd.spy:19, in passcheck: > mymodlist = ldap.modlist.addModlist(entry) > -------------------- > > My code causing the issue: > > -------------------- > def passcheck(self, api, passwd, firstname, lastname, vamcdrop): > import string, sys, ldap, crack, hashlib, base64 > try: > crack.VeryFascistCheck(passwd) > except ValueError, reason: > print("Please use a different password, %s." % reason) > else: > l=ldap.initialize("ldaps://null") > l.bind_s('cn=removed,dc=removed,dc=removed', 'removed') > y = hashlib.sha1(passwd).digest() > base64encode = base64.encodestring(y) > userpass = string.rstrip(base64encode) > uid = firstname.lower() + "." + lastname.lower() > mydn = "uid=" + uid + ",ou=VA,dc=pharmacy,dc=com" > entry = "{'uid': ['" + uid + "'], 'objectClass': > ['top', 'inetOrgPerson'], 'userPassword': ['" + '{SHA}' + userpass + > "'], 'vamc': ['" + vamcdrop + "'], 'sn': ['" + lastname + "'], > 'givenName': ['" + firstname + "'], 'cn': ['" + firstname + " " + > lastname + "']}" > mymodlist = ldap.modlist.addModlist(entry) > l.add_s(mydn, mymodlist) > print "Adding the following information into LDAP:" > print "
" > print entry > -------------------- > > Looks like modlist is not happy with the string being presented to it. > Printing the entry variable gives the same results for both the webapp > and commandline. > > Web: > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > 'givenName': ['null'], 'cn': ['null null']} > > Shell: > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > 'givenName': ['null'], 'cn': ['null null']} > > ------------------------------------------------------------------------- > 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 > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- -- Alain Spineux aspineux gmail com May the sources be with you -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From garlandkr at gmail.com Mon Mar 19 20:09:35 2007 From: garlandkr at gmail.com (Garland, Ken R) Date: Mon, 19 Mar 2007 15:09:35 -0400 Subject: Error modlist.py in addModlist In-Reply-To: <71fe4e760703191137k1c01acaer5bd833f495e7b98a@mail.gmail.com> References: <71fe4e760703191135j35a29701x4973e0f740fa2e9a@mail.gmail.com> <71fe4e760703191137k1c01acaer5bd833f495e7b98a@mail.gmail.com> Message-ID: well i get the error still. but i made a mistake earlier and it looks like my string is not a true dictionary and modlist is unhappy with it. The shell version of my script is a bit different and doesn't have this issue. Traceback (most recent call last): File "./ldapadd.py", line 23, in ? mymodlist = ldap.modlist.addModlist(newentry) File "/usr/lib/python2.4/site-packages/ldap/modlist.py", line 34, in addModlist for attrtype in entry.keys(): AttributeError: 'str' object has no attribute 'keys' Now I'll dive into converting it into a dictionary. Thanks, looks like the error is on my part. On 3/19/07, Alain Spineux wrote: > > I didn't read your code, but I know ldap dont like python's unicode string. > > Convert any strings coming from your web interface into string, using str(). > > Hope this help > > > > On 3/19/07, Garland, Ken R wrote: > > I've sliced together a script to add users to ldap, which works great. > > however, now i'm implementing it into a webapp and having some issues. > > > > -------------------- > > Spyce exception > > File: /home/kgarland/downloads/spyce- 2.1/www/newadd.spy > > Message: > > > > AttributeError: 'str' object has no attribute 'keys' > > > > Stack: > /usr/lib/python2.4/site-packages/ldap/modlist.py:34, > in addModlist: > > > > for attrtype in entry.keys (): > > > > newadd.spy:19, in passcheck: > > mymodlist = ldap.modlist.addModlist(entry) > > -------------------- > > > > My code causing the issue: > > > > -------------------- > > def passcheck(self, api, passwd, firstname, lastname, vamcdrop): > > import string, sys, ldap, crack, hashlib, base64 > > try: > > crack.VeryFascistCheck(passwd) > > except ValueError, reason: > > print("Please use a different password, %s." % reason) > > else: > > l=ldap.initialize("ldaps://null") > > > l.bind_s('cn=removed,dc=removed,dc=removed', 'removed') > > y = hashlib.sha1(passwd).digest() > > base64encode = base64.encodestring(y) > > userpass = string.rstrip(base64encode) > > uid = firstname.lower() + "." + lastname.lower() > > mydn = "uid=" + uid + ",ou=VA,dc=pharmacy,dc=com" > > entry = "{'uid': ['" + uid + "'], 'objectClass': > > ['top', 'inetOrgPerson'], 'userPassword': ['" + '{SHA}' + userpass + > > "'], 'vamc': ['" + vamcdrop + "'], 'sn': ['" + lastname + "'], > > 'givenName': ['" + firstname + "'], 'cn': ['" + firstname + " " + > > lastname + "']}" > > mymodlist = ldap.modlist.addModlist(entry) > > l.add_s(mydn, mymodlist) > > print "Adding the following information into LDAP:" > > print "
" > > print entry > > -------------------- > > > > Looks like modlist is not happy with the string being presented to it. > > Printing the entry variable gives the same results for both the webapp > > and commandline. > > > > Web: > > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > > 'givenName': ['null'], 'cn': ['null null']} > > > > Shell: > > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > > 'givenName': ['null'], 'cn': ['null null']} > > > > > From gwidion at mpc.com.br Mon Mar 19 22:38:12 2007 From: gwidion at mpc.com.br (Joao S. O. Bueno Calligaris) Date: Mon, 19 Mar 2007 18:38:12 -0300 Subject: Fwd: Error modlist.py in addModlist In-Reply-To: <71fe4e760703191137k1c01acaer5bd833f495e7b98a@mail.gmail.com> References: <71fe4e760703191135j35a29701x4973e0f740fa2e9a@mail.gmail.com> <71fe4e760703191137k1c01acaer5bd833f495e7b98a@mail.gmail.com> Message-ID: <200703191838.12107.gwidion@mpc.com.br> On Monday 19 March 2007 15:37, Alain Spineux wrote: > I didn't read your code, but I know ldap dont like python's unicode > string. > > Convert any strings coming from your web interface into string, > using str(). > better do your_unicode_string.encode("utf-8") - that way your application won't crash on non ASCII characters. > Hope this help > > On 3/19/07, Garland, Ken R wrote: > > I've sliced together a script to add users to ldap, which works > > great. however, now i'm implementing it into a webapp and having > > some issues. > > > > -------------------- > > Spyce exception > > File: /home/kgarland/downloads/spyce- 2.1/www/newadd.spy > > Message: > > > > AttributeError: 'str' object has no attribute 'keys' > > > > Stack: /usr/lib/python2.4/site-packages/ldap/modlist.py:34, in > > addModlist: > > > > for attrtype in entry.keys (): > > > > newadd.spy:19, in passcheck: > > mymodlist = ldap.modlist.addModlist(entry) > > -------------------- > > > > My code causing the issue: > > > > -------------------- > > def passcheck(self, api, passwd, firstname, lastname, vamcdrop): > > import string, sys, ldap, crack, hashlib, base64 > > try: > > crack.VeryFascistCheck(passwd) > > except ValueError, reason: > > print("Please use a different password, %s." % > > reason) else: > > l=ldap.initialize("ldaps://null") > > l.bind_s('cn=removed,dc=removed,dc=removed', > > 'removed') y = hashlib.sha1(passwd).digest() > > base64encode = base64.encodestring(y) > > userpass = string.rstrip(base64encode) > > uid = firstname.lower() + "." + lastname.lower() > > mydn = "uid=" + uid + ",ou=VA,dc=pharmacy,dc=com" > > entry = "{'uid': ['" + uid + "'], 'objectClass': > > ['top', 'inetOrgPerson'], 'userPassword': ['" + '{SHA}' + > > userpass + "'], 'vamc': ['" + vamcdrop + "'], 'sn': ['" + > > lastname + "'], 'givenName': ['" + firstname + "'], 'cn': ['" + > > firstname + " " + lastname + "']}" > > mymodlist = ldap.modlist.addModlist(entry) > > l.add_s(mydn, mymodlist) > > print "Adding the following information into > > LDAP:" print "
" > > print entry > > -------------------- > > > > Looks like modlist is not happy with the string being presented > > to it. Printing the entry variable gives the same results for > > both the webapp and commandline. > > > > Web: > > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > > 'givenName': ['null'], 'cn': ['null null']} > > > > Shell: > > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > > 'givenName': ['null'], 'cn': ['null null']} > > > > From garlandkr at gmail.com Tue Mar 20 00:48:44 2007 From: garlandkr at gmail.com (Garland, Ken R) Date: Mon, 19 Mar 2007 19:48:44 -0400 Subject: Fwd: Error modlist.py in addModlist In-Reply-To: <200703191838.12107.gwidion@mpc.com.br> References: <71fe4e760703191135j35a29701x4973e0f740fa2e9a@mail.gmail.com> <71fe4e760703191137k1c01acaer5bd833f495e7b98a@mail.gmail.com> <200703191838.12107.gwidion@mpc.com.br> Message-ID: thanks, i think i was getting by with my own tests but i'm sure users will crash it with error. i've added your suggestion for encoding. On 3/19/07, Joao S. O. Bueno Calligaris wrote: > On Monday 19 March 2007 15:37, Alain Spineux wrote: > > I didn't read your code, but I know ldap dont like python's unicode > > string. > > > > Convert any strings coming from your web interface into string, > > using str(). > > > > better do your_unicode_string.encode("utf-8") - that way your > application won't crash on non ASCII characters. > > > Hope this help > > > > On 3/19/07, Garland, Ken R wrote: > > > I've sliced together a script to add users to ldap, which works > > > great. however, now i'm implementing it into a webapp and having > > > some issues. > > > > > > -------------------- > > > Spyce exception > > > File: /home/kgarland/downloads/spyce- 2.1/www/newadd.spy > > > Message: > > > > > > AttributeError: 'str' object has no attribute 'keys' > > > > > > Stack: /usr/lib/python2.4/site-packages/ldap/modlist.py:34, in > > > addModlist: > > > > > > for attrtype in entry.keys (): > > > > > > newadd.spy:19, in passcheck: > > > mymodlist = ldap.modlist.addModlist(entry) > > > -------------------- > > > > > > My code causing the issue: > > > > > > -------------------- > > > def passcheck(self, api, passwd, firstname, lastname, vamcdrop): > > > import string, sys, ldap, crack, hashlib, base64 > > > try: > > > crack.VeryFascistCheck(passwd) > > > except ValueError, reason: > > > print("Please use a different password, %s." % > > > reason) else: > > > l=ldap.initialize("ldaps://null") > > > l.bind_s('cn=removed,dc=removed,dc=removed', > > > 'removed') y = hashlib.sha1(passwd).digest() > > > base64encode = base64.encodestring(y) > > > userpass = string.rstrip(base64encode) > > > uid = firstname.lower() + "." + lastname.lower() > > > mydn = "uid=" + uid + ",ou=VA,dc=pharmacy,dc=com" > > > entry = "{'uid': ['" + uid + "'], 'objectClass': > > > ['top', 'inetOrgPerson'], 'userPassword': ['" + '{SHA}' + > > > userpass + "'], 'vamc': ['" + vamcdrop + "'], 'sn': ['" + > > > lastname + "'], 'givenName': ['" + firstname + "'], 'cn': ['" + > > > firstname + " " + lastname + "']}" > > > mymodlist = ldap.modlist.addModlist(entry) > > > l.add_s(mydn, mymodlist) > > > print "Adding the following information into > > > LDAP:" print "
" > > > print entry > > > -------------------- > > > > > > Looks like modlist is not happy with the string being presented > > > to it. Printing the entry variable gives the same results for > > > both the webapp and commandline. > > > > > > Web: > > > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > > > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > > > 'givenName': ['null'], 'cn': ['null null']} > > > > > > Shell: > > > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > > > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > > > 'givenName': ['null'], 'cn': ['null null']} > > > > > > From anilj at entic.net Tue Mar 20 17:06:43 2007 From: anilj at entic.net (Anil Jangity) Date: Tue, 20 Mar 2007 10:06:43 -0600 Subject: another odd problem... with ldap restart Message-ID: If I restart the LDAP server, while connected to it using python-ldap, it doesn't seem to be throwing an exception at the right time. self.logger('*** about to do a search ***') result = g.ldap[customer][uid].search(base=suffix, scope="base", attr=["dn"]) self.logger('*** finished search ***') g.ldap is a wrapper method that just does this: try: self.logger('1') ldap_result_id = self.l.search(ldap_url.dn, ldap_url.scope, ldap_url.filterstr, ldap_url.attrs) self.logger('2') except ldap.LDAPError, e: self.logger("LDAP SEARCH failed: %s" % (e)) return False Once connected to the ldap server, I do stop-start ldap server. Then, I do two searches in order. The 2nd search throws an exception "Can't contact LDAP server". I am just wondering why it doesn't do it the first time? Mar 20 09:43:35 DEBUG 127.0.0.1 *** about to do a search *** Mar 20 09:43:35 INFO LDAP SEARCH: dn: uid=demo, ou=People, o=entic.net scope: 0 filter: (objectClass=top) Mar 20 09:43:35 INFO 1 Mar 20 09:43:35 INFO 2 Mar 20 09:43:36 DEBUG 127.0.0.1 *** about to do a search *** Mar 20 09:43:36 INFO LDAP SEARCH: dn: uid=demo, ou=People, o=entic.net scope: 0 filter: (objectClass=top) Mar 20 09:43:36 INFO 1 Mar 20 09:43:36 INFO LDAP SEARCH failed: {'info': '', 'desc': "Can't contact LDAP server"} Mar 20 09:43:36 DEBUG 127.0.0.1 *** finished search *** From aspineux at gmail.com Tue Mar 20 18:28:34 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 20 Mar 2007 18:28:34 +0100 Subject: another odd problem... with ldap restart In-Reply-To: References: Message-ID: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> You are working asynchronously ! add a ldap.result() into your try: except or use the synchronous ldap.search_s() method and you will get your error in the expected order. I you want to survive to ldap restart, use the ReconnectLDAPObject that do the job nicely. BUT this let a good QUESTION : If I start 10 asynchronous ldap requests when the server is down, how many exception will I get ? 1 or 10 ? easy to test :-) On 3/20/07, Anil Jangity wrote: > > If I restart the LDAP server, while connected to it using python-ldap, > it doesn't seem to be throwing an exception at the right time. > > self.logger('*** about to do a search ***') > result = g.ldap[customer][uid].search(base=suffix, scope="base", > attr=["dn"]) > self.logger('*** finished search ***') > > g.ldap is a wrapper method that just does this: > try: > self.logger('1') > ldap_result_id = self.l.search(ldap_url.dn, ldap_url.scope, > ldap_url.filterstr, ldap_url.attrs) > self.logger('2') > except ldap.LDAPError, e: > self.logger("LDAP SEARCH failed: %s" % (e)) > return False > > Once connected to the ldap server, I do stop-start ldap server. Then, > I do two searches in order. The 2nd search throws an exception "Can't > contact LDAP server". I am just wondering why it doesn't do it the > first time? > > Mar 20 09:43:35 DEBUG 127.0.0.1 *** about to do a search *** > Mar 20 09:43:35 INFO LDAP SEARCH: dn: uid=demo, ou=People, o=entic.net > scope: 0 filter: (objectClass=top) > Mar 20 09:43:35 INFO 1 > Mar 20 09:43:35 INFO 2 > Mar 20 09:43:36 DEBUG 127.0.0.1 *** about to do a search *** > Mar 20 09:43:36 INFO LDAP SEARCH: dn: uid=demo, ou=People, o=entic.net > scope: 0 filter: (objectClass=top) > Mar 20 09:43:36 INFO 1 > Mar 20 09:43:36 INFO LDAP SEARCH failed: {'info': '', 'desc': "Can't > contact LDAP server"} > Mar 20 09:43:36 DEBUG 127.0.0.1 *** finished search *** > > ------------------------------------------------------------------------- > 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 > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Mar 20 21:57:27 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Mar 2007 21:57:27 +0100 Subject: another odd problem... with ldap restart In-Reply-To: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> References: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> Message-ID: <46004AB7.3000102@stroeder.com> Alain Spineux wrote: > > I you want to survive to ldap restart, use the ReconnectLDAPObject that > do the job nicely. Note that there are various import fixes to ReconnectLDAPObject still waiting to be released. Ciao, Michael. From michael at stroeder.com Tue Mar 20 20:04:08 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Mar 2007 20:04:08 +0100 Subject: Error modlist.py in addModlist In-Reply-To: References: Message-ID: <46003028.5050408@stroeder.com> Garland, Ken R wrote: > entry = "{'uid': ['" + uid + "'], 'objectClass': > ['top', 'inetOrgPerson'], 'userPassword': ['" + '{SHA}' + userpass + > "'], 'vamc': ['" + vamcdrop + "'], 'sn': ['" + lastname + "'], > 'givenName': ['" + firstname + "'], 'cn': ['" + firstname + " " + > lastname + "']}" What made you think that you have to pass a string for parameter 'entry'? It MUST be a dictionary. As others noted all attribute values should be encoded to strings. This can either require .encode('utf-8') or .encode('ascii') according to the LDAP syntax defined for the various attributes. (One might argue that UTF-8 is a superset of ASCII but IMO it's better to catch syntax errors before sending anything to the server.) > {'uid': ['null.null'], 'objectClass': ['top', 'inetOrgPerson'], > 'userPassword': ['{SHA}null'], 'vamc': ['null'], 'sn': ['null'], > 'givenName': ['null'], 'cn': ['null null']} BTW: Setting pseudo-null values is bad practice when adding LDAP entries. You may run into interop issues with other LDAP-enabled applications later. Ciao, Michael. From anilj at entic.net Tue Mar 20 22:12:39 2007 From: anilj at entic.net (Anil Jangity) Date: Tue, 20 Mar 2007 15:12:39 -0600 Subject: another odd problem... with ldap restart In-Reply-To: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> References: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> Message-ID: Cool, that was the problem! Where is ReconnectLDAPObject documented? Don't think I've seen it before in the docs. On 3/20/07, Alain Spineux wrote: > You are working asynchronously ! > > add a ldap.result() into your try: except or use the synchronous > ldap.search_s() > method and you will get your error in the expected order. > > I you want to survive to ldap restart, use the ReconnectLDAPObject that do > the job nicely. > > BUT this let a good QUESTION : > > If I start 10 asynchronous ldap requests when the server is down, > how many exception will I get ? 1 or 10 ? easy to test :-) > > > > On 3/20/07, Anil Jangity wrote: > > > > If I restart the LDAP server, while connected to it using python-ldap, > > it doesn't seem to be throwing an exception at the right time. > > > > self.logger('*** about to do a search ***') > > result = g.ldap[customer][uid].search(base=suffix, > scope="base", attr=["dn"]) > > self.logger('*** finished search ***') > > > > g.ldap is a wrapper method that just does this: > > try: > > self.logger('1') > > ldap_result_id = self.l.search(ldap_url.dn, ldap_url.scope, > > ldap_url.filterstr, ldap_url.attrs) > > self.logger('2') > > except ldap.LDAPError, e: > > self.logger("LDAP SEARCH failed: %s" % (e)) > > return False > > > > Once connected to the ldap server, I do stop-start ldap server. Then, > > I do two searches in order. The 2nd search throws an exception "Can't > > contact LDAP server". I am just wondering why it doesn't do it the > > first time? > > > > Mar 20 09:43:35 DEBUG 127.0.0.1 *** about to do a search *** > > Mar 20 09:43:35 INFO LDAP SEARCH: dn: uid=demo, ou=People, o= entic.net > > scope: 0 filter: (objectClass=top) > > Mar 20 09:43:35 INFO 1 > > Mar 20 09:43:35 INFO 2 > > Mar 20 09:43:36 DEBUG 127.0.0.1 *** about to do a search *** > > Mar 20 09:43:36 INFO LDAP SEARCH: dn: uid=demo, ou=People, o=entic.net > > scope: 0 filter: (objectClass=top) > > Mar 20 09:43:36 INFO 1 > > Mar 20 09:43:36 INFO LDAP SEARCH failed: {'info': '', 'desc': "Can't > > contact LDAP server"} > > Mar 20 09:43:36 DEBUG 127.0.0.1 *** finished search *** > > > > > From aspineux at gmail.com Tue Mar 20 22:20:59 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 20 Mar 2007 22:20:59 +0100 Subject: another odd problem... with ldap restart In-Reply-To: <46004AB7.3000102@stroeder.com> References: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> <46004AB7.3000102@stroeder.com> Message-ID: <71fe4e760703201420t580cdfb1gece6ac26368f36d8@mail.gmail.com> Are you advising us about the use of ReconnectLDAPObject in production environment ? Can you tell us more about that ? Thx On 3/20/07, Michael Str?der wrote: > > Alain Spineux wrote: > > > > I you want to survive to ldap restart, use the ReconnectLDAPObject that > > do the job nicely. > > Note that there are various import fixes to ReconnectLDAPObject still > waiting to be released. > > 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 > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Mar 20 22:29:07 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Mar 2007 22:29:07 +0100 Subject: another odd problem... with ldap restart In-Reply-To: References: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> Message-ID: <46005223.8030301@stroeder.com> Anil Jangity wrote: > Where is ReconnectLDAPObject documented? In the source code. I've just implemented it for my own applications and considered it to be experimental. Ciao, Michael. From michael at stroeder.com Tue Mar 20 22:31:50 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Mar 2007 22:31:50 +0100 Subject: another odd problem... with ldap restart In-Reply-To: <71fe4e760703201420t580cdfb1gece6ac26368f36d8@mail.gmail.com> References: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> <46004AB7.3000102@stroeder.com> <71fe4e760703201420t580cdfb1gece6ac26368f36d8@mail.gmail.com> Message-ID: <460052C6.8020705@stroeder.com> Alain Spineux wrote: > > Are you advising us about the use of ReconnectLDAPObject in production > environment ? Alain, you were the one who started the thread "ReconnectLDAPObject doesn't reconnect after main failure". ;-) As I said: There are issues with ReconnectLDAPObject up to latest released 2.2.1. SourceForge seems very slooooowwwww at the moment....so I'm too tired to provide URLs. > Can you tell us more about that ? The fix committed back then wasn't released yet. You might want to grab patches from CVS. Ciao, Michael. From michael at stroeder.com Tue Mar 20 22:40:06 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 20 Mar 2007 22:40:06 +0100 Subject: another odd problem... with ldap restart In-Reply-To: <460052C6.8020705@stroeder.com> References: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> <46004AB7.3000102@stroeder.com> <71fe4e760703201420t580cdfb1gece6ac26368f36d8@mail.gmail.com> <460052C6.8020705@stroeder.com> Message-ID: <460054B6.5070206@stroeder.com> Michael Str?der wrote: > > The fix committed back then wasn't released yet. You might want to grab > patches from CVS. http://python-ldap.cvs.sourceforge.net/python-ldap/python-ldap/Lib/ldap/ldapobject.py?r1=1.94&r2=1.95 >From glancing over the CVS comments it seems unlikely that you can simply grab whole ldapobject.py file from HEAD. Ciao, Michael. From aspineux at gmail.com Tue Mar 20 23:26:14 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 20 Mar 2007 23:26:14 +0100 Subject: another odd problem... with ldap restart In-Reply-To: <460052C6.8020705@stroeder.com> References: <71fe4e760703201028k3974f42do6b2015ea7d3abf95@mail.gmail.com> <46004AB7.3000102@stroeder.com> <71fe4e760703201420t580cdfb1gece6ac26368f36d8@mail.gmail.com> <460052C6.8020705@stroeder.com> Message-ID: <71fe4e760703201526o7339b315wdc8bffd0d0a2b790@mail.gmail.com> I remember, of course ! And I was thinking it was stable after applying the patch. But leaved behind that you didn't released any new version since :-) On 3/20/07, Michael Str?der wrote: > > Alain Spineux wrote: > > > > Are you advising us about the use of ReconnectLDAPObject in production > > environment ? > > Alain, you were the one who started the thread > "ReconnectLDAPObject doesn't reconnect after main failure". ;-) > > As I said: There are issues with ReconnectLDAPObject up to latest > released 2.2.1. SourceForge seems very slooooowwwww at the moment....so > I'm too tired to provide URLs. > > > Can you tell us more about that ? > > The fix committed back then wasn't released yet. You might want to grab > patches from CVS. > > Ciao, Michael. > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From aspineux at gmail.com Thu Mar 22 16:02:41 2007 From: aspineux at gmail.com (Alain Spineux) Date: Thu, 22 Mar 2007 16:02:41 +0100 Subject: Any volunteers for SF#1657848? In-Reply-To: <46002F89.7050703@stroeder.com> References: <46002F89.7050703@stroeder.com> Message-ID: <71fe4e760703220802l55035ecak3fcbeefc2a86318a@mail.gmail.com> I'll take a look this weekend and help if I can On 3/20/07, Michael Str?der wrote: > > HI! > > I'd like to release python-ldap 2.3 within the next weeks. For this > release I'd like to get rid of using deprecated OpenLDAP C SDK functions. > > Since my C skills are limited I'd appreciate if somebody could take over > implementing a new C function l_ldap_str2dn(). I've collected my > thoughts in the SF tracker item SF#1657848 (see current content below). > > Ciao, Michael. > > -- > Michael Str?der > E-Mail: michael at stroeder.com > http://www.stroeder.com > > -------- Original Message -------- > Subject: [ python-ldap-Bugs-1657848 ] ldap_value_free() deprecated > Date: Sun, 18 Mar 2007 04:49:49 -0700 > From: SourceForge.net > To: noreply at sourceforge.net > > Bugs item #1657848, was opened at 2007-02-12 11:16 > Message generated for change (Comment added) made by stroeder > You can respond by visiting: > > https://sourceforge.net/tracker/?func=detail&atid=102072&aid=1657848&group_id=2072 > > Please note that this message will contain a full copy of the comment > thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: None > Priority: 8 > Private: No > Submitted By: Michael Str?der (stroeder) > Assigned to: Nobody/Anonymous (nobody) > Summary: ldap_value_free() deprecated > > Initial Comment: > Current ldap.h lists ldap_value_free() as deprecated. > ldap_values_free_len() shall be used instead. > > ---------------------------------------------------------------------- > > >Comment By: Michael Str?der (stroeder) > Date: 2007-03-18 12:49 > > Message: > Logged In: YES > user_id=64920 > Originator: YES > > Hmm, since Python strings are similar to struct berval probably OpenLDAP's > function ldap_bv2dn() should be used instead ldap_str2dn() within > l_ldap_str2dn(). > > ---------------------------------------------------------------------- > > Comment By: Michael Str?der (stroeder) > Date: 2007-03-18 11:52 > > Message: > Logged In: YES > user_id=64920 > Originator: YES > > It seems ldap_value_free() is solely used in l_ldap_explode_dn() and > ldap_explode_rdn(). These functions in turn use OpenLDAP's functions > ldap_explode_dn() and ldap_explode_rdn() which are also marked as > deprecated. > > So the best thing is for upcoming python-ldap 2.3 > 1. to add a new function l_ldap_str2dn() to functions.c, > 2. add a new Python wrapper function str2dn() to Lib/ldap/functions.py, > 3. to remove l_ldap_explode_dn() and ldap_explode_rdn() from functions.c > and > 4. modify pure Python wrapper function explode_dn() and explode_rdn() in > ldap.functions to use the new Python function ldap.functions.str2dn() for > preserving backward compability. > > This might change the behaviour of ldap.explode_dn() to return hex-escaped > chars for NON-ASCII chars. This is odd anyway so personally I don't care. > > ---------------------------------------------------------------------- > > You can respond by visiting: > > https://sourceforge.net/tracker/?func=detail&atid=102072&aid=1657848&group_id=2072 > > > > > ------------------------------------------------------------------------- > 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 > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Mar 22 20:48:40 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 22 Mar 2007 20:48:40 +0100 Subject: Any volunteers for SF#1657848? In-Reply-To: <46029D07.5080505@adaptive-enterprises.com.au> References: <46002F89.7050703@stroeder.com> <71fe4e760703220802l55035ecak3fcbeefc2a86318a@mail.gmail.com> <46029D07.5080505@adaptive-enterprises.com.au> Message-ID: <4602DD98.8010807@stroeder.com> David Leonard wrote: > here's my hackery so far.. doesn't seem to work completely though... David, glad to here from you! Even more glad to receive some code for python-ldap! > this is how I test: > $ python setup.py build > $ PYTHONPATH=build/lib.openbsd-4.0-i386-2.3/ python -c 'import _ldap; > print _ldap.dn2str(_ldap.str2dn("a=b,c=d;e=f"))' 1. Do we really need to expose OpenLDAP constants LDAP_DN_* etc. you introduced in constants.c at the python-ldap's API? I'd rather vote to through out some already existing constants since they are not needed for Python applications. For the ease of maintenance I'd like to keep the C part under Modules/ as sparse as possible. 2. The new functions: >>> import _ldap >>> _ldap.str2dn('cn=Michael Str?der,o=Blurb\, Co.') [[('cn', 'Michael Str\xc3\xb6der', 4)], [('o', 'Blurb, Co.', 1)]] What are the numbers? Some flags in an integer? Further trails with dn2str(): >>> print _ldap.dn2str([[('cn', 'Michael Str\xc3\xb6der', 4)], [('o', 'Blurb, Co.', 1)]]) Modules/functions.c:160 Traceback (most recent call last): File "", line 1, in TypeError: function takes exactly 1 argument (3 given) >>> print _ldap.dn2str([[('cn', 'Michael Str\xc3\xb6der')], [('o', 'Blurb, Co.')]]) Modules/functions.c:160 Traceback (most recent call last): File "", line 1, in TypeError: function takes exactly 1 argument (2 given) >>> print _ldap.dn2str([[('cn=Michael Str\xc3\xb6der')], [('o=Blurb, Co.')]]) Modules/functions.c:160 Traceback (most recent call last): File "", line 1, in SystemError: new style getargs format but argument is not a tuple >>> print _ldap.dn2str([['cn=Michael Str\xc3\xb6der'], ['o=Blurb, Co.']]) Modules/functions.c:160 Traceback (most recent call last): File "", line 1, in SystemError: new style getargs format but argument is not a tuple >>> print _ldap.dn2str(['cn=Michael Str\xc3\xb6der','o=Blurb, Co.']) Traceback (most recent call last): File "", line 1, in TypeError: ("expected seq of seq of '2+'-seq", ['cn=Michael Str\xc3\xb6der', 'o=Blurb, Co.']) >>> ??????? > ps - my mails to the dev list don't seem to be getting through .. i'll > have to look at that :) I had this also (see below). Maybe my provider fixed it... : host mail.sourceforge.net[66.35.250.206] said: 550-Callback setup failed while verifying 550-Called: 81.169.145.100 550-Sent: MAIL FROM:<> 550-Response: 503 5.1.8 Postmaster not allowed 550-The initial connection, or a HELO or MAIL FROM:<> command was 550-rejected. Refusing MAIL FROM:<> does not help fight spam, disregards 550-RFC requirements, and stops you from receiving standard bounce 550-messages. This host does not accept mail from domains whose servers 550-refuse bounces. 550 Sender verify failed (in reply to RCPT TO command) Ciao, Michael. From michael at stroeder.com Thu Mar 22 21:16:23 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 22 Mar 2007 21:16:23 +0100 Subject: Any volunteers for SF#1657848? In-Reply-To: <4602DD98.8010807@stroeder.com> References: <46002F89.7050703@stroeder.com> <71fe4e760703220802l55035ecak3fcbeefc2a86318a@mail.gmail.com> <46029D07.5080505@adaptive-enterprises.com.au> <4602DD98.8010807@stroeder.com> Message-ID: <4602E417.4040609@stroeder.com> Michael Str?der wrote: > Further trails with dn2str(): Frankly we don't need l_ldap_dn2str() at all. We can easily write efficient pure Python code for it with '='.join() etc. Well, ldap.dn.escape_dn_chars() could need a C part for performance. Ciao, Michael. From d at adaptive-enterprises.com.au Thu Mar 22 14:39:02 2007 From: d at adaptive-enterprises.com.au (David Leonard) Date: Thu, 22 Mar 2007 23:39:02 +1000 Subject: Any volunteers for SF#1657848? In-Reply-To: <46002F89.7050703@stroeder.com> References: <46002F89.7050703@stroeder.com> Message-ID: <460286F6.5060407@adaptive-enterprises.com.au> Michael Str?der wrote: > HI! > > I'd like to release python-ldap 2.3 within the next weeks. For this > release I'd like to get rid of using deprecated OpenLDAP C SDK functions. > > Since my C skills are limited I'd appreciate if somebody could take over > implementing a new C function l_ldap_str2dn(). I've collected my > thoughts in the SF tracker item SF#1657848 (see current content below). > > Ciao, Michael. > > yeah, I'll have a go. From michael at stroeder.com Thu Mar 22 22:44:32 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 22 Mar 2007 22:44:32 +0100 Subject: Any volunteers for SF#1657848? In-Reply-To: <4602F4F2.8060806@adaptive-enterprises.com.au> References: <46002F89.7050703@stroeder.com> <71fe4e760703220802l55035ecak3fcbeefc2a86318a@mail.gmail.com> <46029D07.5080505@adaptive-enterprises.com.au> <4602DD98.8010807@stroeder.com> <4602E417.4040609@stroeder.com> <4602F4F2.8060806@adaptive-enterprises.com.au> Message-ID: <4602F8C0.5050305@stroeder.com> David, hope you don't mind that I'm Cc:-ing the list. David Leonard wrote: > > Mmm as LDAPDN doesn't seem to be used in any other part of the C API, At Python level I don't care about LDAPDN at all. > Maybe just move the explode_* impl out into python code.. That's what I'm currently doing. Other issues: $ python -c "import _ldap;print _ldap.str2dn('')" Segmentation fault $ python -c "import _ldap;print _ldap.str2dn('c=')" [[('c', None, 1)]] ^^^^ IMHO this should be ''. Ciao, Michael. From michael at stroeder.com Thu Mar 22 23:07:42 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 22 Mar 2007 23:07:42 +0100 Subject: Any volunteers for SF#1657848? In-Reply-To: <4602F8C0.5050305@stroeder.com> References: <46002F89.7050703@stroeder.com> <71fe4e760703220802l55035ecak3fcbeefc2a86318a@mail.gmail.com> <46029D07.5080505@adaptive-enterprises.com.au> <4602DD98.8010807@stroeder.com> <4602E417.4040609@stroeder.com> <4602F4F2.8060806@adaptive-enterprises.com.au> <4602F8C0.5050305@stroeder.com> Message-ID: <4602FE2E.3060803@stroeder.com> David, I've committed various changes related to this. Everybody please test. Despite the corner-cases listed before ldap.explode_dn() and ldap.explode_rdn() should work nearly as before. Ciao, Michael. From michael at stroeder.com Fri Mar 23 00:17:43 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Mar 2007 00:17:43 +0100 Subject: Any volunteers for SF#1657848? In-Reply-To: <4602E417.4040609@stroeder.com> References: <46002F89.7050703@stroeder.com> <71fe4e760703220802l55035ecak3fcbeefc2a86318a@mail.gmail.com> <46029D07.5080505@adaptive-enterprises.com.au> <4602DD98.8010807@stroeder.com> <4602E417.4040609@stroeder.com> Message-ID: <46030E97.6050307@stroeder.com> Michael Str?der wrote: > > Frankly we don't need l_ldap_dn2str() at all. We can easily write > efficient pure Python code for it with '='.join() etc. See pure Python implementation ldap.dn.dn2str() in HEAD. Well, this function name is somewhat misleading but let's stick to OpenLDAP's naming convention here. Ciao, Michael. From michael at stroeder.com Fri Mar 23 00:31:42 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Mar 2007 00:31:42 +0100 Subject: Preparing python-ldap 2.3 In-Reply-To: <4577740E.4030205@stroeder.com> References: <4577740E.4030205@stroeder.com> Message-ID: <460311DE.9020400@stroeder.com> HI! Thanks to David we made good progress getting current HEAD code updated to reflect changes in OpenLDAP's C SDK. I'd like to release 2.3 soon since there are some important improvements in HEAD but not yet released. Therefore testing of HEAD is needed! Please provide feedback ideally on the mailing list. Thanks. Ciao, Michael. Current CHANGES: From ajcblyth at glam.ac.uk Fri Mar 23 12:17:20 2007 From: ajcblyth at glam.ac.uk (Blyth A J C (AT)) Date: Fri, 23 Mar 2007 11:17:20 -0000 Subject: Python 2.5 Message-ID: <0BA7EE4D4646E0409D458D347C508B7802164CFA@MAILSERV1.uni.glam.ac.uk> Is there a version of LDAP that works with Python 2.5? Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri Mar 23 12:31:44 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 23 Mar 2007 12:31:44 +0100 Subject: Python 2.5 In-Reply-To: <0BA7EE4D4646E0409D458D347C508B7802164CFA@MAILSERV1.uni.glam.ac.uk> References: <0BA7EE4D4646E0409D458D347C508B7802164CFA@MAILSERV1.uni.glam.ac.uk> Message-ID: <4603BAA0.3000103@stroeder.com> Blyth A J C (AT) wrote: > > Is there a version of LDAP that works with Python 2.5? Current CHANGES from CVS HEAD says it all (see relevant excerpts below). 2.3.0 is yet to be released. Testing especially on exotic platforms is appreciated. Ciao, Michael. From aspineux at gmail.com Mon Mar 26 14:30:20 2007 From: aspineux at gmail.com (Alain Spineux) Date: Mon, 26 Mar 2007 14:30:20 +0200 Subject: Preparing python-ldap 2.3 In-Reply-To: <460311DE.9020400@stroeder.com> References: <4577740E.4030205@stroeder.com> <460311DE.9020400@stroeder.com> Message-ID: <71fe4e760703260530p50c237d5me691347436db7442@mail.gmail.com> I get this error # gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fPIC -DHAVE_LIBLDAP_R -DHAVE_SASL -DHAVE_TLS -DLDAPMODULE_VERSION=2.3 -IModules -I/usr/local/openldap-2.3/include -I/usr/include/sasl -I/usr/include/python2.4 -c Modules/functions.c -o build/temp.linux-i686-2.4 /Modules/functions.o Modules/functions.c:143: error: 'l_ldap_dn2str' undeclared here (not in a function) regarding # grep -ir dn2str . .... ./Lib/ldap/dn.py:def dn2str(dn): ./Modules/functions.c: { "dn2str", (PyCFunction)l_ldap_dn2str, METH_VARARGS }, I removed the dn2str definition from ./Modules/functions.c and now it works BR On 3/23/07, Michael Str?der wrote: > > HI! > > Thanks to David we made good progress getting current HEAD code updated > to reflect changes in OpenLDAP's C SDK. > > I'd like to release 2.3 soon since there are some important improvements > in HEAD but not yet released. Therefore testing of HEAD is needed! > > Please provide feedback ideally on the mailing list. Thanks. > > Ciao, Michael. > > Current CHANGES: > > ---------------------------------------------------------------- > Released 2.3.0 2007-03-xx > > Changes since 2.2.1: > > * OpenLDAP 2.3+ required now to build. > * Added support for Cancel operation ext. op. if supported > in OpenLDAP API of the libs used for the build. > > Modules/ > * Removed deprecated code for setting options by name > * Added l_ldap_cancel() > * Some modifications related to PEP 353 for > Python 2.5 on 64-bit platforms (see SF#1467529) > * Added new function l_ldap_str2dn(), removed functions > l_ldap_explode_dn() and l_ldap_explode_rdn() (see SF#1657848) > > Lib/ > * Added method ldapobject.LDAPObject.cancel() > * ldap.schema.subentry.urlfetch() now can do non-anonymous > simple bind if the LDAP URL provided contains extensions > 'bindname' and 'X-BINDPW'. (see SF#1589206) > * ldap.filter.escape_filter_chars() has new a key-word argument > escape_mode now which defines which chars to be escaped > (see SF#1193271). > * Various important fixes to ldapobject.ReconnectLDAPObject > * Moved all DN-related functions to sub-module ldap.dn, > import them in ldap.functions for backward compability > * ldap.dn.explode_dn() and ldap.dn.explode_rdn() use the new > wrapper function ldap.dn.str2dn() (related to SF#1657848) > * changetype issue partially fixed (see SF#1683746) > > ------------------------------------------------------------------------- > 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 > Python-LDAP-dev at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev > -- -- Alain Spineux aspineux gmail com May the sources be with you -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Mar 26 20:37:41 2007 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 26 Mar 2007 20:37:41 +0200 Subject: Preparing python-ldap 2.3 In-Reply-To: <71fe4e760703260530p50c237d5me691347436db7442@mail.gmail.com> References: <4577740E.4030205@stroeder.com> <460311DE.9020400@stroeder.com> <71fe4e760703260530p50c237d5me691347436db7442@mail.gmail.com> Message-ID: <460812F5.7070706@stroeder.com> Alain Spineux wrote: > > I removed the dn2str definition from ./Modules/functions.c and now it works Thanks committed it. Ciao, Michael. From michael at stroeder.com Tue Mar 20 20:01:29 2007 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Tue, 20 Mar 2007 20:01:29 +0100 Subject: Any volunteers for SF#1657848? Message-ID: <46002F89.7050703@stroeder.com> HI! I'd like to release python-ldap 2.3 within the next weeks. For this release I'd like to get rid of using deprecated OpenLDAP C SDK functions. Since my C skills are limited I'd appreciate if somebody could take over implementing a new C function l_ldap_str2dn(). I've collected my thoughts in the SF tracker item SF#1657848 (see current content below). Ciao, Michael. -- Michael Str?der E-Mail: michael at stroeder.com http://www.stroeder.com -------- Original Message -------- Subject: [ python-ldap-Bugs-1657848 ] ldap_value_free() deprecated Date: Sun, 18 Mar 2007 04:49:49 -0700 From: SourceForge.net To: noreply at sourceforge.net Bugs item #1657848, was opened at 2007-02-12 11:16 Message generated for change (Comment added) made by stroeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102072&aid=1657848&group_id=2072 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 8 Private: No Submitted By: Michael Str?der (stroeder) Assigned to: Nobody/Anonymous (nobody) Summary: ldap_value_free() deprecated Initial Comment: Current ldap.h lists ldap_value_free() as deprecated. ldap_values_free_len() shall be used instead. From aspineux at gmail.com Tue Mar 27 13:55:33 2007 From: aspineux at gmail.com (Alain Spineux) Date: Tue, 27 Mar 2007 13:55:33 +0200 Subject: Preparing python-ldap 2.3 In-Reply-To: <460812F5.7070706@stroeder.com> References: <4577740E.4030205@stroeder.com> <460311DE.9020400@stroeder.com> <71fe4e760703260530p50c237d5me691347436db7442@mail.gmail.com> <460812F5.7070706@stroeder.com> Message-ID: <71fe4e760703270455y79627c52kfeebd47c5d96a2fd@mail.gmail.com> It works for me BR On 3/26/07, Michael Str?der wrote: > Alain Spineux wrote: > > > > I removed the dn2str definition from ./Modules/functions.c and now it works > > Thanks committed it. > > Ciao, Michael. > -- -- Alain Spineux aspineux gmail com May the sources be with you