From michael at stroeder.com Sat Jan 10 18:15:11 2009 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Sat, 10 Jan 2009 18:15:11 +0100 Subject: Thoughts on python-ldap 3.0 In-Reply-To: <61722e190901090144r187c06e3tc32e6540779fd679@mail.gmail.com> References: <49144FB9.5080505@stroeder.com> <49147A76.6000809@stroeder.com> <61722e190901090144r187c06e3tc32e6540779fd679@mail.gmail.com> Message-ID: <4968D79F.1070402@stroeder.com> Please, stay on the mailing list. Olivier Sessink wrote: > Sorry for this very late reaction. > > What would be great is to have a higher-level ldap objects to > manipulate entries: > ldapconnection = new blabla() > ldapobjects = ldapconnection.search('uid=xyz') > if (ldapobjects[0]['sn'] == 'yourname'): > ldapobjects[0]['sn'] = 'my name' > ldapobjects[0].commit() Something like this could be easily implemented on top of the current python-ldap API but this won't be the basic API for doing such things. Glad you used dictionary keys in your example though. Ciao, Michael. From lgp171188 at gmail.com Thu Jan 15 10:35:21 2009 From: lgp171188 at gmail.com (Guruprasad) Date: Thu, 15 Jan 2009 15:05:21 +0530 Subject: How to change the password of a LDAP entry as LDAP administrator Message-ID: <496F0359.20001@gmail.com> Hi all, I am new to this Python-LDAP API and am currently learning and working on it. I, the LDAP admin, want to set the password of a LDAP user after binding as the admin user. I came across passwd_s() method which can be used to change the user password, but requires the old password too. As an admin, I should be able to reset the LDAP passwords of users whose current passwords I do not know. Is there a way to do this? Thanks in advance. Regards, Guruprasad -------------- next part -------------- A non-text attachment was scrubbed... Name: lgp171188.vcf Type: text/x-vcard Size: 145 bytes Desc: not available URL: From lgp171188 at gmail.com Thu Jan 15 10:51:25 2009 From: lgp171188 at gmail.com (Guruprasad) Date: Thu, 15 Jan 2009 15:21:25 +0530 Subject: How to change the password of a LDAP entry as LDAP administrator In-Reply-To: <496F0359.20001@gmail.com> References: <496F0359.20001@gmail.com> Message-ID: <496F071D.5080102@gmail.com> Guruprasad wrote: > Hi all, > I am new to this Python-LDAP API and am currently learning and working > on it. I, the LDAP admin, want to set the password of a LDAP user after > binding as the admin user. I came across passwd_s() method which can be > used to change the user password, but requires the old password too. As > an admin, I should be able to reset the LDAP passwords of users whose > current passwords I do not know. Is there a way to do this? > > Thanks in advance. > > Regards, > Guruprasad I figured it out. When I bind as LDAP admin and want to change the password of another DN, I just have to give oldpasswd=None. For example: ldapobj.passwd_s("DN to delete",None,"newpassword") Thank you. Regards, Guruprasad -------------- next part -------------- A non-text attachment was scrubbed... Name: lgp171188.vcf Type: text/x-vcard Size: 145 bytes Desc: not available URL: From michael at stroeder.com Thu Jan 15 11:38:24 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 15 Jan 2009 11:38:24 +0100 Subject: How to change the password of a LDAP entry as LDAP administrator In-Reply-To: <496F071D.5080102@gmail.com> References: <496F0359.20001@gmail.com> <496F071D.5080102@gmail.com> Message-ID: <496F1220.20509@stroeder.com> Guruprasad wrote: > Guruprasad wrote: >> Hi all, >> I am new to this Python-LDAP API and am currently learning and working >> on it. I, the LDAP admin, want to set the password of a LDAP user >> after binding as the admin user. I came across passwd_s() method which >> can be used to change the user password, but requires the old password >> too. As an admin, I should be able to reset the LDAP passwords of >> users whose current passwords I do not know. Is there a way to do this? >> >> Thanks in advance. >> > I figured it out. When I bind as LDAP admin and want to change the > password of another DN, I just have to give oldpasswd=None. For example: > > ldapobj.passwd_s("DN to delete",None,"newpassword") Yupp. That's exactly the solution. Which LDAP server is that? Mote that the Password Modify Extended Operation is sometimes slightly differently implemented in various LDAP servers. I came across one vendor who does not allow the use of this extended operation for an admin setting another user's password. So if your LDAP client is supposed to work with any LDAP server you have to do some interop testing. Ciao, Michael. From solomon_antoine at emc.com Mon Jan 26 23:05:36 2009 From: solomon_antoine at emc.com (solomon_antoine at emc.com) Date: Mon, 26 Jan 2009 17:05:36 -0500 Subject: No subject Message-ID: <90BCBCF398FF14448502FD294B6EBA7C70D2A1@CORPUSMX100A.corp.emc.com> Hello all, I wanted to know if any of you were successful in getting python-ldap installed on solaris 10. if so could you point me to any instructions that you might have? Best regards, Antoine From michael at stroeder.com Tue Jan 27 02:10:05 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 27 Jan 2009 02:10:05 +0100 Subject: In-Reply-To: <90BCBCF398FF14448502FD294B6EBA7C70D2A1@CORPUSMX100A.corp.emc.com> References: <90BCBCF398FF14448502FD294B6EBA7C70D2A1@CORPUSMX100A.corp.emc.com> Message-ID: <497E5EED.9090801@stroeder.com> solomon_antoine at emc.com wrote: > > I wanted to know if any of you were successful in getting python-ldap > installed on solaris 10. if so could you point me to any instructions > that you might have? I've installed it with the usual platform-independent method: http://python-ldap.sourceforge.net/doc/html/installing.html Don't know whether there are acceptable pre-built Solaris 10 packages. You could check out the usual repositories. Ciao, Michael. From solomon_antoine at emc.com Tue Jan 27 03:51:50 2009 From: solomon_antoine at emc.com (solomon_antoine at emc.com) Date: Mon, 26 Jan 2009 21:51:50 -0500 Subject: References: <90BCBCF398FF14448502FD294B6EBA7C70D2A1@CORPUSMX100A.corp.emc.com> <497E5EED.9090801@stroeder.com> Message-ID: <90BCBCF398FF14448502FD294B6EBA7C43DB83@CORPUSMX100A.corp.emc.com> Michael, thanks for the info. I will try to use this site below. regards, Antoine -----Original Message----- From: Michael Str?der [mailto:michael at stroeder.com] Sent: Mon 1/26/2009 8:10 PM To: Solomon, Antoine; python-ldap-dev at lists.sourceforge.net Subject: Re: solomon_antoine at emc.com wrote: > > I wanted to know if any of you were successful in getting python-ldap > installed on solaris 10. if so could you point me to any instructions > that you might have? I've installed it with the usual platform-independent method: http://python-ldap.sourceforge.net/doc/html/installing.html Don't know whether there are acceptable pre-built Solaris 10 packages. You could check out the usual repositories. Ciao, Michael. From solomon_antoine at emc.com Wed Jan 28 16:50:51 2009 From: solomon_antoine at emc.com (solomon_antoine at emc.com) Date: Wed, 28 Jan 2009 10:50:51 -0500 Subject: In-Reply-To: <497E5EED.9090801@stroeder.com> References: <90BCBCF398FF14448502FD294B6EBA7C70D2A1@CORPUSMX100A.corp.emc.com> <497E5EED.9090801@stroeder.com> Message-ID: <90BCBCF398FF14448502FD294B6EBA7C7794AF@CORPUSMX100A.corp.emc.com> Hello all, I tried using the platform install and for some reason I get this error. ImportError: ld.so.1: python: fatal: libresolv.so.2: open failed: No such file or directory Also I ran ldd on the libresolve.so.2 libresolv.so.2 => /usr/lib/libresolv.so.2 libresolv.so.2 (SUNW_2.2.2) => (version not found) Any of you have a clue about this? Regards, Antoine -----Original Message----- From: Michael Str?der [mailto:michael at stroeder.com] Sent: Monday, January 26, 2009 8:10 PM To: Solomon, Antoine; python-ldap-dev at lists.sourceforge.net Subject: Re: solomon_antoine at emc.com wrote: > > I wanted to know if any of you were successful in getting python-ldap > installed on solaris 10. if so could you point me to any instructions > that you might have? I've installed it with the usual platform-independent method: http://python-ldap.sourceforge.net/doc/html/installing.html Don't know whether there are acceptable pre-built Solaris 10 packages. You could check out the usual repositories. Ciao, Michael. From michael at stroeder.com Wed Jan 28 16:55:35 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 28 Jan 2009 16:55:35 +0100 Subject: In-Reply-To: <90BCBCF398FF14448502FD294B6EBA7C7794AF@CORPUSMX100A.corp.emc.com> References: <90BCBCF398FF14448502FD294B6EBA7C70D2A1@CORPUSMX100A.corp.emc.com> <497E5EED.9090801@stroeder.com> <90BCBCF398FF14448502FD294B6EBA7C7794AF@CORPUSMX100A.corp.emc.com> Message-ID: <49807FF7.7070102@stroeder.com> solomon_antoine at emc.com wrote: > > I tried using the platform install and for some reason I get this error. > ImportError: ld.so.1: python: fatal: libresolv.so.2: open failed: No such file or directory > > Also I ran ldd on the libresolve.so.2 > libresolv.so.2 => /usr/lib/libresolv.so.2 > libresolv.so.2 (SUNW_2.2.2) => (version not found) That's probably item 9 in the FAQ: http://python-ldap.sourceforge.net/faq.shtml Ciao, Michael. From python-ldap at tk-webart.de Wed Jan 28 16:55:22 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Wed, 28 Jan 2009 16:55:22 +0100 Subject: Updated eggs for linux x86 and amd64 Message-ID: <20090128165522.61b11412@atalante.iwm-kmrc.de> Hi folks, it's been a while since my last update, but today I built some eggs of python-ldap 2.3.5 for Linux i686 and x86_64 and Python versions 2.4 through 2.6. Windows and OS X versions will follow as soon as my respective development environments are up to date and running again. As usual, the eggs can be obtained from http://svn.kmrc.de/download/distribution They are built against OpenLDAP 2.3.43/OpenSSL 0.9.8j/Cyrus SASL 2.1.22 I'm still looking for a satisfactory solution to present an all-in-one package for Windows, containing all necessary dependencies (i.e. OpenLDAP, OpenSSL, Heimdal/MIT-Krb5, ...) Does anyone have a great idea on how to accomplish that (besides giving away a zip file that has to be manually unpacked to a proper location)? Best regards, Torsten -- Life is cheap, but the accessories can kill you. From python-ldap at tk-webart.de Thu Jan 29 09:17:17 2009 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Thu, 29 Jan 2009 09:17:17 +0100 Subject: Updated eggs for linux x86 and amd64 In-Reply-To: References: <20090128165522.61b11412@atalante.iwm-kmrc.de> Message-ID: <1863519300.20090129091717@tk-webart.de> On Thursday, January 29, 2009 at 03:44 Sidnei da Silva wrote: > >> Does anyone have a great idea on how to accomplish that (besides >> giving away a zip file that has to be manually unpacked to a proper >> location)? > The best way really would be to build it statically. I did manage to > do this *once*, but fail to remember how. I'm sure it is possible > though. Yes, that's definitely a good idea. I'll try to accomplish this. If I'm stuck somewhere, maybe we can explore your memory together? ;-) Best regards, Torsten -- Never make anything simple and efficient when a way can be found to make it complex and wonderful. - Murphy's Law No. 13 - From waldemar.osuch at gmail.com Thu Jan 29 20:43:24 2009 From: waldemar.osuch at gmail.com (Waldemar Osuch) Date: Thu, 29 Jan 2009 12:43:24 -0700 Subject: Updated eggs for linux x86 and amd64 In-Reply-To: <1863519300.20090129091717@tk-webart.de> References: <20090128165522.61b11412@atalante.iwm-kmrc.de> <1863519300.20090129091717@tk-webart.de> Message-ID: <6fae95540901291143o6a192de1ibb49018ed6988c6@mail.gmail.com> On Thu, Jan 29, 2009 at 1:17 AM, Torsten Kurbad wrote: > On Thursday, January 29, 2009 at 03:44 Sidnei da Silva wrote: > >> >>> Does anyone have a great idea on how to accomplish that (besides >>> giving away a zip file that has to be manually unpacked to a proper >>> location)? > >> The best way really would be to build it statically. I did manage to >> do this *once*, but fail to remember how. I'm sure it is possible >> though. > > Yes, that's definitely a good idea. I'll try to accomplish this. If I'm > stuck somewhere, maybe we can explore your memory together? ;-) > FYI To force static build of the extensions I tweak source of distutils/cygwinccompiler.py After lineno 299 I have added: #TODO enable to force static build if False: shared_option = "-mdll -static" and change "False" into "True" whenever I build python-ldap. It seems to work. If you find a more elegant way of doing it please share. Waldemar Osuch http://www.osuch.org From sidnei at enfoldsystems.com Fri Jan 30 14:14:50 2009 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Fri, 30 Jan 2009 11:14:50 -0200 Subject: Updated eggs for linux x86 and amd64 In-Reply-To: <6fae95540901291143o6a192de1ibb49018ed6988c6@mail.gmail.com> References: <20090128165522.61b11412@atalante.iwm-kmrc.de> <1863519300.20090129091717@tk-webart.de> <6fae95540901291143o6a192de1ibb49018ed6988c6@mail.gmail.com> Message-ID: On Thu, Jan 29, 2009 at 5:43 PM, Waldemar Osuch wrote: > On Thu, Jan 29, 2009 at 1:17 AM, Torsten Kurbad > wrote: >> On Thursday, January 29, 2009 at 03:44 Sidnei da Silva wrote: >>> The best way really would be to build it statically. I did manage to >>> do this *once*, but fail to remember how. I'm sure it is possible >>> though. >> >> Yes, that's definitely a good idea. I'll try to accomplish this. If I'm >> stuck somewhere, maybe we can explore your memory together? ;-) >> > > To force static build of the extensions I tweak source of > distutils/cygwinccompiler.py > After lineno 299 I have added: > > #TODO enable to force static build > if False: > shared_option = "-mdll -static" > > and change "False" into "True" whenever I build python-ldap. > It seems to work. > > If you find a more elegant way of doing it please share. Yes, that rings a bell. I think I managed to pass those flags manually without hacking the distutils source, but that's exactly what needs to be done. Thanks for refreshing my memory! -- Sidnei da Silva From michael at stroeder.com Fri Jan 30 14:31:21 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 30 Jan 2009 14:31:21 +0100 Subject: Updated eggs for linux x86 and amd64 In-Reply-To: References: <20090128165522.61b11412@atalante.iwm-kmrc.de> <1863519300.20090129091717@tk-webart.de> <6fae95540901291143o6a192de1ibb49018ed6988c6@mail.gmail.com> Message-ID: <49830129.1070900@stroeder.com> Sidnei da Silva wrote: > On Thu, Jan 29, 2009 at 5:43 PM, Waldemar Osuch > wrote: >> On Thu, Jan 29, 2009 at 1:17 AM, Torsten Kurbad >> wrote: >>> On Thursday, January 29, 2009 at 03:44 Sidnei da Silva wrote: >>>> The best way really would be to build it statically. I did manage to >>>> do this *once*, but fail to remember how. I'm sure it is possible >>>> though. >>> Yes, that's definitely a good idea. I'll try to accomplish this. If I'm >>> stuck somewhere, maybe we can explore your memory together? ;-) >>> >> To force static build of the extensions I tweak source of >> distutils/cygwinccompiler.py >> After lineno 299 I have added: >> >> #TODO enable to force static build >> if False: >> shared_option = "-mdll -static" >> >> and change "False" into "True" whenever I build python-ldap. >> It seems to work. >> >> If you find a more elegant way of doing it please share. > > Yes, that rings a bell. I think I managed to pass those flags manually > without hacking the distutils source, but that's exactly what needs to > be done. Feel free to post a patch to setup.py / setup.cfg which does that. Ciao, Michael. From melander at dfn-cert.de Mon Feb 16 11:28:28 2009 From: melander at dfn-cert.de (Fredrik Melander) Date: Mon, 16 Feb 2009 11:28:28 +0100 Subject: Distinguished name problem Message-ID: <49993FCC.4050804@dfn-cert.de> Hello, list! I'm sure I'm overlooking something fairly obvious her, and I'm hoping that somebody here can point me in the right direction. We have a small ldap-server running here and I've now been given the honor of writing a small Python program to interact with it. >From the command line (ldapsearch) I've got no problem becoming whatever I want. The python-ldap module on the other hand gives me *almost* anything I want. The only thing that I seem to not be able to get is the DN. The documentation makes a somewhat cryptic reference to a function called ldap_get_dn(). It's mentioned only once and not further explained. Trial and error, excessive googling, book flipping etc. unfortunately didn't get me any further either. Bear with me if this is a stupid question. I, as a programmer, have very limited ldap-experience (in fact, this is the first time I'm having anything to do with it), and my ldap guru here has little programming experience, so we're kind of stuck at the moment. Any suggestions very welcome! Thanks in advance. Regards, Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5927 bytes Desc: S/MIME Cryptographic Signature URL: From michael at stroeder.com Mon Feb 16 11:56:07 2009 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 16 Feb 2009 11:56:07 +0100 Subject: Distinguished name problem In-Reply-To: <49993FCC.4050804@dfn-cert.de> References: <49993FCC.4050804@dfn-cert.de> Message-ID: <49994647.7010806@stroeder.com> Fredrik Melander wrote: > From the command line (ldapsearch) I've got no problem becoming whatever > I want. The python-ldap module on the other hand gives me *almost* > anything I want. The only thing that I seem to not be able to get is the > DN. The 2-tuples returned by ldap_search_s() etc. are (dn,entry) where entry is the dictionary {attrtype:[attrvalues]} and dn is simply a binary string containing the entry's distinguished name. See also: http://python-ldap.sourceforge.net/doc/html/ldap.html#example > The documentation makes a somewhat cryptic reference to a function > called ldap_get_dn(). Which documentation? ldap_get_dn() is part of the underlying libldap and you don't have to mess with that yourself. Ciao, Michael. From michael at stroeder.com Mon Feb 16 15:07:28 2009 From: michael at stroeder.com (=?ISO-8859-15?Q?Michael_Str=F6der?=) Date: Mon, 16 Feb 2009 15:07:28 +0100 Subject: Distinguished name problem In-Reply-To: <49996EBE.4030409@dfn-cert.de> References: <49993FCC.4050804@dfn-cert.de> <49994647.7010806@stroeder.com> <49996EBE.4030409@dfn-cert.de> Message-ID: <49997320.9010002@stroeder.com> Fredrik Melander wrote: > first of all - I noticed (a bit too late) that this actually is the > developer-list (although a user-list doesn't seem to exist). I want to > take the opportunity to thank you for taking time to answer my trivial > questions in spite of this. Much appreciated! There's only one low-traffic mailing list python-ldap-dev and therefore also beginner questions are welcome there. Keep posting questions there. >> Which documentation? ldap_get_dn() is part of the underlying libldap and >> you don't have to mess with that yourself. >> > Well, I was referring to the the downloadable pdf at Sourceforge > (version 2.3.2) which contains this statement: > "The DN in /dn /is extracted using the underlying ldap_get_dn() > function, which may raise an exception if the DN is malformed." > Although admittedly the use of the word "underlying" kind of hinted > that I wouldn't have to touch this myself, I got a bit confused by > this... Hmm, I tried to fix the wording a little bit. Not sure whether that helps avoiding confusion though. Ciao, Michael. From Joel.Heenan at Optiver.com.au Tue Mar 3 05:05:13 2009 From: Joel.Heenan at Optiver.com.au (Joel Heenan) Date: Tue, 3 Mar 2009 15:05:13 +1100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl Message-ID: I'm trying to use SimplePagedResultsControl so I can pull some data out of Active Directory that has a Server-Limit set. I got most of my code from this guide http://www.novell.com/coolsolutions/tip/18274.html When I try and run it I get this dump: """ SimplePagedResultsControl(1.2.840.113556.1.4.319,True,(10, '')) Traceback (most recent call last): File "./test_ldap_brakeit.py", line 29, in ? msgid = l.search_ext(base, ldap.SCOPE_SUBTREE, 'objectclass=user', serverctrls=[lc]) File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 468, in search_ext EncodeControlTuples(serverctrls), File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 93, in EncodeControlTuples result = [ File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 45, in getEncodedTuple return (self.controlType,self.criticality,self.encodeControlValue(self.controlValue)) File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 78, in encodeControlValue return _ldap.encode_page_control(size,cookie) ldap.ENCODING_ERROR """ Server is RHEL5.2 , not too sure about the Active Directory I think it is running on Windows Server 2003. Here is the code: #!/usr/bin/python # import ldap,ldap.async,pprint from ldap.controls import SimplePagedResultsControl server = 'xxxx.com' ldap_version = 3 base = 'dc=example,dc=com' binddn = '' bindpw = '' userbase = '' port = 3268 page_size = 10 l = ldap.open(server,port) l.protocol_version = ldap_version l.simple_bind_s(binddn, bindpw) ldap.set_option(ldap.OPT_REFERRALS, 0) lc = SimplePagedResultsControl( ldap.LDAP_CONTROL_PAGE_OID, True, (page_size,'') ) print lc msgid = l.search_ext(base, ldap.SCOPE_SUBTREE, 'objectclass=user', serverctrls=[lc]) pages = 0 while True: pages += 1 print "Getting page %d" % (pages,) rtype,rdata,rmsgid,serverctrls = l.result3(msgid) print "%d results" % len(rdata) pctrls = [ c for c in serverctrls if c.controlType == ldap.LDAP_CONTROL_PAGE_OID ] if pctrls: est, cookie = pctrls[0].controlValue if cookie: lc.controlValue = (page_size,cookie) msgid = l.search_ext(base, ldap.SCOPE_SUBTREE, 'objectclass=user', serverctrls=[lc]) else: break else: print "Warning: Server ignores RFC 2696 control" Joel Heenan ________________________________ Information contained in this communication (including any attachments) is confidential and may be privileged or subject to copyright. If you have received this communication in error you are not authorised to use the information in any way and Optiver requests that you notify the sender by return email, destroy all copies and delete the information from your system. Optiver does not represent, warrant or guarantee that this communication is free from computer viruses or other defects or that the integrity of this communication has been maintained. Any views expressed in this communication are those of the individual sender. Optiver does not accept liability for any loss or damage caused directly or indirectly by this communication or its use. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue Mar 3 14:01:10 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 03 Mar 2009 14:01:10 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: References: Message-ID: <49AD2A16.9050205@stroeder.com> Joel Heenan wrote: > > I'm trying to use SimplePagedResultsControl so I can pull some data out > of Active Directory that has a Server-Limit set. I got most of my code > from this guide http://www.novell.com/coolsolutions/tip/18274.html Since I posted this code I think it works. ;-) > File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 78, > in encodeControlValue > > return _ldap.encode_page_control(size,cookie) > > ldap.ENCODING_ERROR It seems you're running on a 64-bit platform. I did never test python-ldap on such a system. Which version of python-ldap is it? Did you compile it yourself? Which versions of OpenLDAP libs are used? > Server is RHEL5.2 Hmm, isn't this quite old? I'd guess old versions of python-ldap and OpenLDAP are shipped with this release. Ciao, Michael. From Joel.Heenan at Optiver.com.au Wed Mar 4 01:31:02 2009 From: Joel.Heenan at Optiver.com.au (Joel Heenan) Date: Wed, 4 Mar 2009 11:31:02 +1100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49AD2A16.9050205@stroeder.com> References: <49AD2A16.9050205@stroeder.com> Message-ID: Hi Michael, Comments inline: > Michael Str?der wrote: > Joel Heenan wrote: > > > File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line > 78, > > in encodeControlValue > > > > return _ldap.encode_page_control(size,cookie) > > > > ldap.ENCODING_ERROR > > It seems you're running on a 64-bit platform. I did never test > python-ldap on such a system. Which version of python-ldap is it? Did > you compile it yourself? Which versions of OpenLDAP libs are used? > I am using 64-bit RPM's compiled by RedHat for RHEL5.2 . The 32-bit variants are installed I'll see if I can work out how to force it to use them. Here are the versions involved, but be aware RedHat versions include backporting so it can be difficult to say exactly what is included: openldap-2.3.27-8.el5_1.3 openldap-devel-2.3.27-8.el5_1.3 python-ldap-2.2.0-2.1 > > Server is RHEL5.2 > > Hmm, isn't this quite old? I'd guess old versions of python-ldap and > OpenLDAP are shipped with this release. Err RHEL5.2 is the latest stable I believe. RHEL5.3 may have been released. Not to be confused with RedHat 5.2 which is of course ancient :-) Joel Information contained in this communication (including any attachments) is confidential and may be privileged or subject to copyright. If you have received this communication in error you are not authorised to use the information in any way and Optiver requests that you notify the sender by return email, destroy all copies and delete the information from your system. Optiver does not represent, warrant or guarantee that this communication is free from computer viruses or other defects or that the integrity of this communication has been maintained. Any views expressed in this communication are those of the individual sender. Optiver does not accept liability for any loss or damage caused directly or indirectly by this communication or its use. Please consider the environment before printing this email. From michael at stroeder.com Wed Mar 4 02:50:54 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 04 Mar 2009 02:50:54 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: References: <49AD2A16.9050205@stroeder.com> Message-ID: <49ADDE7E.6080402@stroeder.com> Joel Heenan wrote: > Hi Michael, > > Comments inline: > >> Michael Str?der wrote: >> Joel Heenan wrote: >> >>> File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line >> 78, >>> in encodeControlValue >>> >>> return _ldap.encode_page_control(size,cookie) >>> >>> ldap.ENCODING_ERROR >> It seems you're running on a 64-bit platform. I did never test >> python-ldap on such a system. Which version of python-ldap is it? Did >> you compile it yourself? Which versions of OpenLDAP libs are used? > > I am using 64-bit RPM's compiled by RedHat for RHEL5.2 . The 32-bit > variants are installed I'll see if I can work out how to force it to > use them. > > Here are the versions involved, but be aware RedHat versions include > backporting so it can be difficult to say exactly what is included: > > openldap-2.3.27-8.el5_1.3 > openldap-devel-2.3.27-8.el5_1.3 > python-ldap-2.2.0-2.1 These releases are old: OpenLDAP 2.3.27 was released 2006-08-19 python-ldap 2.2.0 was released 2006-04-10 There have been numerous bug fixes to both packages since then. While I don't have a 64-bit box myself there were several related fixes contributed and tested by others. So I suggest to build recent releases of both from source and test with that. >>> Server is RHEL5.2 >> Hmm, isn't this quite old? I'd guess old versions of python-ldap and >> OpenLDAP are shipped with this release. > > Err RHEL5.2 is the latest stable I believe. Whatever stable means to Red Hat for these particular packages. Sorry, if you insist on using these ancient versions I have to point you to Red Hat's support. Ciao, Michael. From raj at csub.edu Wed Mar 4 07:53:29 2009 From: raj at csub.edu (Russell Jackson) Date: Tue, 03 Mar 2009 22:53:29 -0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49AD2A16.9050205@stroeder.com> References: <49AD2A16.9050205@stroeder.com> Message-ID: <49AE2569.5080605@csub.edu> Michael Str?der wrote: > It seems you're running on a 64-bit platform. I did never test > python-ldap on such a system. Which version of python-ldap is it? Did > you compile it yourself? Which versions of OpenLDAP libs are used? > Just as a data point, I've been running python-ldap (from ports) on FreeBSD-amd64 since 6.x without issue. -- Russell A. Jackson Network Analyst California State University, Bakersfield Q: What do they call the alphabet in Arkansas? A: The impossible dream. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From pyldap.20.dlobue at neverbox.com Thu Mar 5 13:01:36 2009 From: pyldap.20.dlobue at neverbox.com (pyldap.20.dlobue at neverbox.com) Date: Thu, 5 Mar 2009 04:01:36 -0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <93de24940903050342i3dedd1bcg9f9c9157fb84ca24@mail.gmail.com> References: <93de24940903050342i3dedd1bcg9f9c9157fb84ca24@mail.gmail.com> Message-ID: <93de24940903050401q45d39c1ale781aa4fd59fb4da@mail.gmail.com> Michael, I've run into the same problem as Joel on basically an identical setup - CentOS 5.2, openldap 2.3.27-8.el5_2.4, python 2.4.3-21.el5, python-ldap 2.2.0-2.1. This of course being on a 64 bit release of CentOS. I did as you suggested and updated openldap to 2.4.12-1, and python-ldap to 2.3.5-1, but I still received the exact same error. Because you mentioned that you had never tested python-ldap on a 64 bit machine, I duplicated my setup in a VirtualBox VM only using a i686 release of CentOS rather than x64. I ran my python program using the old versions of software ( openldap 2.3.27-8.el5_2.4, python 2.4.3-21.el5, python-ldap 2.2.0-2) and it ran without any problems whatsoever. Any suggestions on how to fix this? Let me know if you need any other info. Dominic ----------------------------- Joel Heenan wrote: > Hi Michael, > > Comments inline: > >> Michael Str?der wrote: >> Joel Heenan wrote: >> >>> File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line >> 78, >>> in encodeControlValue >>> >>> return _ldap.encode_page_control(size,cookie) >>> >>> ldap.ENCODING_ERROR >> It seems you're running on a 64-bit platform. I did never test >> python-ldap on such a system. Which version of python-ldap is it? Did >> you compile it yourself? Which versions of OpenLDAP libs are used? > > I am using 64-bit RPM's compiled by RedHat for RHEL5.2 . The 32-bit > variants are installed I'll see if I can work out how to force it to > use them. > > Here are the versions involved, but be aware RedHat versions include > backporting so it can be difficult to say exactly what is included: > > openldap-2.3.27-8.el5_1.3 > openldap-devel-2.3.27-8.el5_1.3 > python-ldap-2.2.0-2.1 These releases are old: OpenLDAP 2.3.27 was released 2006-08-19 python-ldap 2.2.0 was released 2006-04-10 There have been numerous bug fixes to both packages since then. While I don't have a 64-bit box myself there were several related fixes contributed and tested by others. So I suggest to build recent releases of both from source and test with that. >>> Server is RHEL5.2 >> Hmm, isn't this quite old? I'd guess old versions of python-ldap and >> OpenLDAP are shipped with this release. > > Err RHEL5.2 is the latest stable I believe. Whatever stable means to Red Hat for these particular packages. Sorry, if you insist on using these ancient versions I have to point you to Red Hat's support. Ciao, Michael. From michael at stroeder.com Thu Mar 5 15:22:23 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 05 Mar 2009 15:22:23 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <93de24940903050401q45d39c1ale781aa4fd59fb4da@mail.gmail.com> References: <93de24940903050342i3dedd1bcg9f9c9157fb84ca24@mail.gmail.com> <93de24940903050401q45d39c1ale781aa4fd59fb4da@mail.gmail.com> Message-ID: <49AFE01F.8020600@stroeder.com> pyldap.20.dlobue at neverbox.com wrote: > > I've run into the same problem as Joel on basically an identical setup > - CentOS 5.2, openldap 2.3.27-8.el5_2.4, python 2.4.3-21.el5, > python-ldap 2.2.0-2.1. This of course being on a 64 bit release of > CentOS. > > I did as you suggested and updated openldap to 2.4.12-1, and > python-ldap to 2.3.5-1, but I still received the exact same error. The problem with using binary packages is that I never know whether patches were applied by the distributor and which build parameters were used. Also note there's python-ldap with some minor build fixes and OpenLDAP 2.4.15 with numerous fixes to libldap. OpenLDAP developers will likely not give support with this issue if the problem cannot be reproduced with recent code. > Because you mentioned that you had never tested python-ldap on a 64 > bit machine, I duplicated my setup in a VirtualBox VM only using a > i686 release of CentOS rather than x64. > > I ran my python program using the old versions of software ( openldap > 2.3.27-8.el5_2.4, python 2.4.3-21.el5, python-ldap 2.2.0-2) and it ran > without any problems whatsoever. Thanks for testing this. > Any suggestions on how to fix this? At the moment I have no idea how to proceed. I'd suggest to build from source. Not sure about compiler woes on that platform. E.g. try turning off optimization (with option -O0) when building from source. Ciao, Michael. From pyldap.20.dlobue at neverbox.com Fri Mar 6 13:53:12 2009 From: pyldap.20.dlobue at neverbox.com (pyldap.20.dlobue at neverbox.com) Date: Fri, 6 Mar 2009 04:53:12 -0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl (pyldap: message 1 of 20) In-Reply-To: <49AFE01F.8020600@stroeder.com> References: <93de24940903050342i3dedd1bcg9f9c9157fb84ca24@mail.gmail.com> <93de24940903050401q45d39c1ale781aa4fd59fb4da@mail.gmail.com> <49AFE01F.8020600@stroeder.com> Message-ID: <93de24940903060453g730d1bc2q52f11934e971be14@mail.gmail.com> Michael, I will try as you suggested and will compile the current versions of openldap, python-ldap, cyrus-sasl, and openssl without any patches and default options. I'll let you know how that turns out. To respond to your point that you don't know what build options are used, or what patches applied to binary distributions, here is what the spec files I used to build openldap and python-ldap contained: python-ldap only had one patch applied to it. I'll paste the patch below, but the patch isn't the problem. I recompiled the python-ldap RPM without any of the patches and ran into the same encoding error. The packages was configured and built using the following two commands: setup.py build setup.py install --skip-build --root $RPM_BUILD_ROOT ($RPM_BUILD_ROOT being /var/tmp/python-ldap-2.3.5-root ) python-ldap-2.2.0-dirs.patch: --- python-ldap-2.3.5/setup.cfg.dirs 2008-07-06 11:04:13.000000000 -0400 +++ python-ldap-2.3.5/setup.cfg 2008-09-03 13:45:20.000000000 -0400 @@ -2,8 +2,7 @@ extra_objects = extra_compile_args = libs = ldap_r lber sasl2 ssl crypto -library_dirs = /usr/local/openldap-2.3/lib -include_dirs = /usr/local/openldap-2.3/include /usr/include/sasl +include_dirs = /usr/include/sasl OpenLDAP was built with considerably more patches and the build process is extremely involved. The following flags are used in building: CFLAGS=" -D_REENTRANT -fPIC -D_GNU_SOURCE" The OpenLDAP package RPM builds its own version of BerkeleyDB which it builds like so: configure -C \ --with-pic \ --disable-static \ --enable-shared \ --with-uniquename=_openldap_slapd_46 \ --prefix=${dbdir} \ --includedir=${dbdir}/include \ --libdir=${dbdir}/%{_lib}${subdir:+/${subdir}} make %{_smp_mflags} libdb_base=libslapd_db libso_base=libslapd_db make install libdb_base=libslapd_db libso_base=libslapd_db strip="false" OpenLDAP is configured and made with the following flags: configure \ --with-threads=posix \ --enable-local --enable-rlookups \ --with-tls \ --with-cyrus-sasl \ --enable-wrappers \ --enable-passwd \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --enable-lmpasswd \ --enable-modules \ --disable-sql \ --libexecdir=%{_libdir} \ $@ make %{_smp_mflags} LIBTOOL="$libtool" The openldap clients are build using: build \ --disable-slapd \ --enable-shared \ --enable-dynamic \ --enable-static \ --without-kerberos \ --with-pic If there's any information you need to figure out what's going, let me know and I'll be happy to grab it for you. Dominic On Thu, Mar 5, 2009 at 6:22 AM, Michael Str?der - michael at stroeder.com <+pyldap+dlobue+63e3ab027f.michael#stroeder.com at spamgourmet.com> wrote: > pyldap.20.dlobue at neverbox.com wrote: >> >> I've run into the same problem as Joel on basically an identical setup >> - CentOS 5.2, openldap 2.3.27-8.el5_2.4, python 2.4.3-21.el5, >> python-ldap 2.2.0-2.1. This of course being on a 64 bit release of >> CentOS. >> >> I did as you suggested and updated openldap to 2.4.12-1, and >> python-ldap to 2.3.5-1, but I still received the exact same error. > > The problem with using binary packages is that I never know whether > patches were applied by the distributor and which build parameters were > used. > > Also note there's python-ldap with some minor build fixes and OpenLDAP > 2.4.15 with numerous fixes to libldap. OpenLDAP developers will likely > not give support with this issue if the problem cannot be reproduced > with recent code. > >> Because you mentioned that you had never tested python-ldap on a 64 >> bit machine, I duplicated my setup in a VirtualBox VM only using a >> i686 release of CentOS rather than x64. >> >> I ran my python program using the old versions of software ( openldap >> 2.3.27-8.el5_2.4, python 2.4.3-21.el5, python-ldap 2.2.0-2) and it ran >> without any problems whatsoever. > > Thanks for testing this. > >> Any suggestions on how to fix this? > > At the moment I have no idea how to proceed. I'd suggest to build from > source. Not sure about compiler woes on that platform. E.g. try turning > off optimization (with option -O0) when building from source. > > Ciao, Michael. > From janfrode at tanso.net Sun Mar 8 00:44:43 2009 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Sun, 8 Mar 2009 00:44:43 +0100 Subject: change password for user Message-ID: I have a script that tries to sync a userdatabase with plaintext username/password in mysql, to a Centos Directory Server. Currently I've been pushing the passwords into the directory by first creating the SSHA1 hash in python and store '{SSHA}' + encode-string in the password field. But, it occurred to me that I'm not fully sure what I'm doing when creating the SSHA1 hash, so it would be nice to have the directory server do the hashing instead. I've found the method: passwd_s(user, oldpw, newpw, [serverctrls=None, [clientctrls=None]]) but are there any way to use that when I don't know the plaintext 'oldpw' ? -jf From michael at stroeder.com Mon Mar 9 01:08:45 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 09 Mar 2009 01:08:45 +0100 Subject: change password for user In-Reply-To: References: Message-ID: <49B45E0D.5070402@stroeder.com> Jan-Frode Myklebust wrote: > I have a script that tries to sync a userdatabase with > plaintext username/password in mysql, to a Centos Directory > Server. Currently I've been pushing the passwords into the > directory by first creating the SSHA1 hash in python and > store '{SSHA}' + encode-string in the password field. > > But, it occurred to me that I'm not fully sure what I'm doing > when creating the SSHA1 hash, If the password is usable afterwards there's nothing wrong with client-side password hashing. The salt should be at least 4 bytes long. > so it would be nice to have > the directory server do the hashing instead. I've found the > method: > > passwd_s(user, oldpw, newpw, [serverctrls=None, [clientctrls=None]]) > > but are there any way to use that when I don't know the plaintext > 'oldpw' ? Simply use None for oldpw. Ciao, Michael. From zhbmaillistonly at gmail.com Mon Mar 9 02:51:09 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Mon, 09 Mar 2009 09:51:09 +0800 Subject: change password for user In-Reply-To: <49B45E0D.5070402@stroeder.com> References: <49B45E0D.5070402@stroeder.com> Message-ID: <49B4760D.4030000@gmail.com> Michael Str?der wrote: >> so it would be nice to have >> the directory server do the hashing instead. I've found the >> method: >> >> passwd_s(user, oldpw, newpw, [serverctrls=None, [clientctrls=None]]) >> >> but are there any way to use that when I don't know the plaintext >> 'oldpw' ? >> > > Simply use None for oldpw. How can i specfy hash mechanism in passwd_s()? like SSHA, MD5. It seems use default setting of ldap server (password-hash in openldap slapd.conf), right? -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Mon Mar 9 10:27:12 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 09 Mar 2009 10:27:12 +0100 Subject: change password for user In-Reply-To: <49B4760D.4030000@gmail.com> References: <49B45E0D.5070402@stroeder.com> <49B4760D.4030000@gmail.com> Message-ID: <49B4E0F0.4040307@stroeder.com> Zhang Huangbin wrote: > Michael Str?der wrote: >>> so it would be nice to have >>> the directory server do the hashing instead. I've found the >>> method: >>> >>> passwd_s(user, oldpw, newpw, [serverctrls=None, [clientctrls=None]]) >>> >>> but are there any way to use that when I don't know the plaintext >>> 'oldpw' ? >>> >> >> Simply use None for oldpw. > > How can i specfy hash mechanism in passwd_s()? like SSHA, MD5. You don't. That's completely configured at the server's side. > It seems use default setting of ldap server (password-hash in openldap > slapd.conf), Yes. Other LDAP servers might have a different configuration. Also some servers set other password attributes as well (e.g. the smbk5pwd overlay for OpenLDAP sets Samba password attributes and the Kerberos keys for a heimdal KDC). Ciao, Michael. From zhbmaillistonly at gmail.com Mon Mar 9 10:41:57 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Mon, 09 Mar 2009 17:41:57 +0800 Subject: change password for user In-Reply-To: <49B4E0F0.4040307@stroeder.com> References: <49B45E0D.5070402@stroeder.com> <49B4760D.4030000@gmail.com> <49B4E0F0.4040307@stroeder.com> Message-ID: <49B4E465.3030902@gmail.com> Michael Str?der wrote: > Yes. Other LDAP servers might have a different configuration. Also some > servers set other password attributes as well (e.g. the smbk5pwd overlay > for OpenLDAP sets Samba password attributes and the Kerberos keys for a > heimdal KDC). > > Ciao, Michael. > > Thanks Michael. :) How can i set DEFAULT password-hash in slapd.conf? such as MD5 or whatever. -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From janfrode at tanso.net Mon Mar 9 12:04:55 2009 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Mon, 9 Mar 2009 12:04:55 +0100 Subject: change password for user References: <49B45E0D.5070402@stroeder.com> Message-ID: On 2009-03-09, Michael Str?der wrote: > > > > But, it occurred to me that I'm not fully sure what I'm doing > > when creating the SSHA1 hash, > > If the password is usable afterwards there's nothing wrong with > client-side password hashing. The salt should be at least 4 bytes long. Still, I'm uncertain how f.ex. character encodings will/should be handled, so it seems safer to let the directory server handle both the hashing and verification. > > Simply use None for oldpw. > It didn't like None: Traceback (most recent call last): File "./update-ldap-from-atmail.py", line 166, in ? con.passwd_s( dn, None, mailpassword ) File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 330, in passwd_s msgid = self.passwd(user,oldpw,newpw,serverctrls,clientctrls) File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 327, in passwd return self._ldap_call(self._l.passwd,user,oldpw,newpw,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls)) File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 94, in _ldap_call result = func(*args,**kwargs) TypeError: argument 2 must be string or read-only buffer, not None but "" seems to work (after I set up SSL to get around the ldap.CONFIDENTIALITY_REQUIRED). Thanks! -jf From michael at stroeder.com Mon Mar 9 11:37:50 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 09 Mar 2009 11:37:50 +0100 Subject: change password for user In-Reply-To: <49B4E465.3030902@gmail.com> References: <49B45E0D.5070402@stroeder.com> <49B4760D.4030000@gmail.com> <49B4E0F0.4040307@stroeder.com> <49B4E465.3030902@gmail.com> Message-ID: <49B4F17E.3040600@stroeder.com> Zhang Huangbin wrote: > Michael Str?der wrote: >> Yes. Other LDAP servers might have a different configuration. Also some >> servers set other password attributes as well (e.g. the smbk5pwd overlay >> for OpenLDAP sets Samba password attributes and the Kerberos keys for a >> heimdal KDC). > > How can i set DEFAULT password-hash in slapd.conf? such as MD5 or whatever. That's more a question for the openldap-software mailing list. Since you already found the password-hash parameter you could simply use it: password-hash {SSHA} Ciao, Michael. From michael at stroeder.com Mon Mar 9 12:27:37 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 09 Mar 2009 12:27:37 +0100 Subject: change password for user In-Reply-To: References: <49B45E0D.5070402@stroeder.com> Message-ID: <49B4FD29.7040702@stroeder.com> Jan-Frode Myklebust wrote: > On 2009-03-09, Michael Str?der wrote: >>> But, it occurred to me that I'm not fully sure what I'm doing >>> when creating the SSHA1 hash, >> If the password is usable afterwards there's nothing wrong with >> client-side password hashing. The salt should be at least 4 bytes long. > > Still, I'm uncertain how f.ex. character encodings will/should be > handled, so it seems safer to let the directory server handle both the > hashing and verification. For LDAPv3 you should pass UTF-8 to the python-ldap functions/methods or before hashing the password. (In theory one has to use SASLprep before the UTF-8 encoding but in most cases this is the same). Ciao, Michael. From zhbmaillistonly at gmail.com Sun Mar 15 11:51:12 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Sun, 15 Mar 2009 18:51:12 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl Message-ID: <49BCDDA0.5010009@gmail.com> I had the same error here while run Demo/page_control.py: ---- Traceback (most recent call last): File "1.py", line 23, in ? serverctrls=[lc] File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/ldapobject.py", line 501, in search_ext_s msgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/ldapobject.py", line 495, in search_ext EncodeControlTuples(serverctrls), File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 110, in EncodeControlTuples result = [ File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 45, in getEncodedTuple return (self.controlType,self.criticality,self.encodeControlValue(self.controlValue)) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 78, in encodeControlValue return _ldap.encode_page_control(size,cookie) ldap.ENCODING_ERROR ---- My env: OS: RHEL 5.3, x86_64 Python: 2.4.3-24.el5 (shipped within RHEL 5.3) python-ldap: 2.3.6 (installed from source tarball) OpenLDAP: 2.3.43-3.el5 (shipped within RHEL 5.3) How can i solve it? -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From zhbmaillistonly at gmail.com Sun Mar 15 14:43:01 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Sun, 15 Mar 2009 21:43:01 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BCDDA0.5010009@gmail.com> References: <49BCDDA0.5010009@gmail.com> Message-ID: <49BD05E5.9040101@gmail.com> Strange, the same code (Demo/page_control.py) works in: - OS: CentOS 5.2, *i386* - Python: 2.4.3-21.el5 (shipped within CentOS) - python-ldap: 2.3.6 (installed from source tarball) - OpenLDAP: 2.3.27-8.el5_2.4 -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From zhbmaillistonly at gmail.com Sun Mar 15 15:11:45 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Sun, 15 Mar 2009 22:11:45 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BD05E5.9040101@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BD05E5.9040101@gmail.com> Message-ID: <49BD0CA1.9040407@gmail.com> Zhang Huangbin wrote: > Strange, the same code (Demo/page_control.py) works in: > > - OS: CentOS 5.2, *i386* > - Python: 2.4.3-21.el5 (shipped within CentOS) > - python-ldap: 2.3.6 (installed from source tarball) > - OpenLDAP: 2.3.27-8.el5_2.4 > How can i help developers fix this possible bug? Please feel free to contact me if you need more information. Thanks very much. :P -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Mon Mar 16 12:28:26 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Mar 2009 12:28:26 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BD0CA1.9040407@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BD05E5.9040101@gmail.com> <49BD0CA1.9040407@gmail.com> Message-ID: <49BE37DA.7070506@stroeder.com> Zhang Huangbin wrote: > Zhang Huangbin wrote: >> Strange, the same code (Demo/page_control.py) works in: >> >> - OS: CentOS 5.2, *i386* >> - Python: 2.4.3-21.el5 (shipped within CentOS) >> - python-ldap: 2.3.6 (installed from source tarball) >> - OpenLDAP: 2.3.27-8.el5_2.4 >> > How can i help developers fix this possible bug? Please feel free to > contact me if you need more information. The problem is that I don't have 64-bit Linux hardware to test myself. And a bug could be in OpenLDAP client libs, Python or python-ldap itself. The OpenLDAP and Python versions mentioned above are indeed quite old. Also I don't know what the distributor CentOS or Red Hat is exactly doing when builing the packages. Dominic tested with a more recent version of the OpenLDAP client libs (2.4.12) but still with pre-installed python 2.4.3-21.el5. Hmm... Ciao, Michael. From michael at stroeder.com Mon Mar 16 12:36:16 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Mar 2009 12:36:16 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BCDDA0.5010009@gmail.com> References: <49BCDDA0.5010009@gmail.com> Message-ID: <49BE39B0.60506@stroeder.com> Zhang Huangbin wrote: > I had the same error here while run Demo/page_control.py: To all of the people experiencing problems: Could you please run Demo/page_control.py after applying the attached patch (which enables debug logging). To preclude problems in the 64-bit build of OpenLDAP client libs you could also try paged-search with the command-line tool ldapsearch which essentially uses the same control encoding/decoding functions in libldap. Ciao, Michael. Index: Demo/page_control.py =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Demo/page_control.py,v retrieving revision 1.4 diff -u -r1.4 page_control.py --- Demo/page_control.py 8 Dec 2006 12:38:39 -0000 1.4 +++ Demo/page_control.py 16 Mar 2009 11:33:41 -0000 @@ -6,8 +6,9 @@ import ldap from ldap.controls import SimplePagedResultsControl +ldap.set_option(ldap.OPT_DEBUG_LEVEL,255) ldap.set_option(ldap.OPT_REFERRALS, 0) -l = ldap.initialize(url) +l = ldap.initialize(url,trace_level=2) l.protocol_version = 3 l.simple_bind_s("", "") From zhbmaillistonly at gmail.com Mon Mar 16 13:02:03 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Mon, 16 Mar 2009 20:02:03 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE39B0.60506@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> Message-ID: <49BE3FBB.7080200@gmail.com> Michael Str?der wrote: > To all of the people experiencing problems: > Could you please run Demo/page_control.py after applying the attached > patch (which enables debug logging). > > Index: Demo/page_control.py > =================================================================== > RCS file: /cvsroot/python-ldap/python-ldap/Demo/page_control.py,v > retrieving revision 1.4 > diff -u -r1.4 page_control.py > --- Demo/page_control.py 8 Dec 2006 12:38:39 -0000 1.4 > +++ Demo/page_control.py 16 Mar 2009 11:33:41 -0000 > @@ -6,8 +6,9 @@ > import ldap > from ldap.controls import SimplePagedResultsControl > > +ldap.set_option(ldap.OPT_DEBUG_LEVEL,255) > ldap.set_option(ldap.OPT_REFERRALS, 0) > -l = ldap.initialize(url) > +l = ldap.initialize(url,trace_level=2) > l.protocol_version = 3 > l.simple_bind_s("", "") > > Thanks Michael. :) Here is output msg: ---- $ python page_control.py ldap_create ldap_url_parse_ext(ldap://r6:389/) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.simple_bind (('cn=Manager,dc=iredmail,dc=org', 'passwd', None, None),{}) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP r6:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.122.6:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request => result: 1 *** ldap://r6:389/ - SimpleLDAPObject.result3 ((1, 1, -1),{}) ldap_result ld 0x1671b300 msgid 1 ldap_chkResponseList ld 0x1671b300 msgid 1 all 1 ldap_chkResponseList returns ld 0x1671b300 NULL wait4msg ld 0x1671b300 msgid 1 (infinite timeout) wait4msg continue ld 0x1671b300 msgid 1 all 1 ** ld 0x1671b300 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Mon Mar 16 20:00:35 2009 ** ld 0x1671b300 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x1671b300 Response Queue: Empty ldap_chkResponseList ld 0x1671b300 msgid 1 all 1 ldap_chkResponseList returns ld 0x1671b300 NULL ldap_int_select read1msg: ld 0x1671b300 msgid 1 all 1 read1msg: ld 0x1671b300 msgid 1 message type bind read1msg: ld 0x1671b300 0 new referrals read1msg: mark request completed, ld 0x1671b300 msgid 1 request done: ld 0x1671b300 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ldap_msgfree => result: (97, [], 1, []) Traceback (most recent call last): File "page_control.py", line 24, in ? serverctrls=[lc] File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 468, in search_ext EncodeControlTuples(serverctrls), File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 93, in EncodeControlTuples result = [ File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 45, in getEncodedTuple return (self.controlType,self.criticality,self.encodeControlValue(self.controlValue)) File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 78, in encodeControlValue return _ldap.encode_page_control(size,cookie) ldap.ENCODING_ERROR ldap_free_connection 1 1 ldap_send_unbind ldap_free_connection: actually freed ---- -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Mon Mar 16 13:13:33 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Mar 2009 13:13:33 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE3FBB.7080200@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> Message-ID: <49BE426D.9010802@stroeder.com> Zhang Huangbin wrote: > Michael Str?der wrote: >> To all of the people experiencing problems: >> Could you please run Demo/page_control.py after applying the attached >> patch (which enables debug logging). > > Here is output msg: So this seems to boil down to that the following commands (lines wrapped) would fail at your site instead of returning the encoded control tuple: >>> import ldap >>> from ldap.controls import SimplePagedResultsControl >>> SimplePagedResultsControl(ldap.LDAP_CONTROL_PAGE_OID,True,(10,'')).getEncodedTuple() ('1.2.840.113556.1.4.319', True, '0\x05\x02\x01\n\x04\x00') Ciao, Michael. From zhbmaillistonly at gmail.com Mon Mar 16 13:23:36 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Mon, 16 Mar 2009 20:23:36 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE426D.9010802@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> Message-ID: <49BE44C8.2090105@gmail.com> Michael Str?der wrote: > So this seems to boil down to that the following commands (lines > wrapped) would fail at your site instead of returning the encoded > control tuple: > > >>>> import ldap >>>> from ldap.controls import SimplePagedResultsControl >>>> >>>> > SimplePagedResultsControl(ldap.LDAP_CONTROL_PAGE_OID,True,(10,'')).getEncodedTuple() > ('1.2.840.113556.1.4.319', True, '0\x05\x02\x01\n\x04\x00') > Thanks Michael. :) You are right, here is the output: ---- # python Python 2.4.3 (#1, Sep 17 2008, 16:07:08) [GCC 4.1.2 20071124 (Red Hat 4.1.2-41)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ldap >>> ldap.__version__ '2.3.6' >>> from ldap.controls import SimplePagedResultsControl >>> SimplePagedResultsControl(ldap.LDAP_CONTROL_PAGE_OID,True,(10,'')).getEncodedTuple() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 45, in getEncodedTuple return (self.controlType,self.criticality,self.encodeControlValue(self.controlValue)) File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 78, in encodeControlValue return _ldap.encode_page_control(size,cookie) ldap.ENCODING_ERROR ---- What's the problem? How can i solve it? Thanks very much. :) -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Mon Mar 16 13:48:35 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Mar 2009 13:48:35 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE426D.9010802@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> Message-ID: <49BE4AA3.1060609@stroeder.com> Michael Str?der wrote: > Zhang Huangbin wrote: >> Michael Str?der wrote: >>> To all of the people experiencing problems: >>> Could you please run Demo/page_control.py after applying the attached >>> patch (which enables debug logging). >> Here is output msg: > > So this seems to boil down to that the following commands (lines > wrapped) would fail at your site instead of returning the encoded > control tuple: > >>>> import ldap >>>> from ldap.controls import SimplePagedResultsControl >>>> > SimplePagedResultsControl(ldap.LDAP_CONTROL_PAGE_OID,True,(10,'')).getEncodedTuple() > ('1.2.840.113556.1.4.319', True, '0\x05\x02\x01\n\x04\x00') Could somebody with more knowledge of C programming please review function encode_rfc2696() in Modules/ldapcontrol.c? The following var declaration could be problematic on 64-bit systems: unsigned long size; Another issue could be in decode_rfc2696() (which is not yet reached if encode_rfc2696() fails): unsigned long count; Ciao, Michael. From zhbmaillistonly at gmail.com Mon Mar 16 14:31:06 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Mon, 16 Mar 2009 21:31:06 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE4AA3.1060609@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> Message-ID: <49BE549A.6060202@gmail.com> Michael Str?der wrote: > Could somebody with more knowledge of C programming please review > function encode_rfc2696() in Modules/ldapcontrol.c? > > The following var declaration could be problematic on 64-bit systems: > > unsigned long size; > > Another issue could be in decode_rfc2696() (which is not yet reached if > encode_rfc2696() fails): > > unsigned long count; I asked friend and he suggests me change them to: unsigned long size; => unsigned int size; unsigned long count; => unsigned int count; Re-compile and install, but it raises the same error. -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Mon Mar 16 14:33:26 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Mar 2009 14:33:26 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE549A.6060202@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> Message-ID: <49BE5526.4070405@stroeder.com> Zhang Huangbin wrote: > Michael Str?der wrote: >> Could somebody with more knowledge of C programming please review >> function encode_rfc2696() in Modules/ldapcontrol.c? >> >> The following var declaration could be problematic on 64-bit systems: >> >> unsigned long size; >> >> Another issue could be in decode_rfc2696() (which is not yet reached if >> encode_rfc2696() fails): >> >> unsigned long count; > > I asked friend and he suggests me change them to: > > unsigned long size; => unsigned int size; > unsigned long count; => unsigned int count; > > Re-compile and install, but it raises the same error. I guess both is platform-dependent and hence the error. Do you see any compiler warnings during build of python-ldap? Can you please send the output? Ciao, Michael. From michael at stroeder.com Mon Mar 16 15:55:25 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Mar 2009 15:55:25 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE549A.6060202@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> Message-ID: <49BE685D.1060600@stroeder.com> Zhang Huangbin wrote: > Michael Str?der wrote: >> Could somebody with more knowledge of C programming please review >> function encode_rfc2696() in Modules/ldapcontrol.c? >> >> The following var declaration could be problematic on 64-bit systems: >> >> unsigned long size; Thanks to Zhang Huangbin for giving me access to his machine for testing. So I could track it down. It seems to work with the patch below which I committed to CVS HEAD. Ciao, Michael. Index: Modules/ldapcontrol.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/ldapcontrol.c,v retrieving revision 1.9 diff -u -r1.9 ldapcontrol.c --- Modules/ldapcontrol.c 20 Mar 2008 12:24:56 -0000 1.9 +++ Modules/ldapcontrol.c 16 Mar 2009 14:48:49 -0000 @@ -241,13 +241,15 @@ PyObject *res = 0; BerElement *ber = 0; struct berval cookie, *ctrl_val; + Py_ssize_t cookie_len; unsigned long size; ber_tag_t tag; if (!PyArg_ParseTuple(args, "is#:encode_page_control", &size, - &cookie.bv_val, &cookie.bv_len)) { + &cookie.bv_val, &cookie_len)) { goto endlbl; } + cookie.bv_len = (ber_len_t) cookie_len; if (!(ber = ber_alloc_t(LBER_USE_DER))) { LDAPerr(LDAP_NO_MEMORY); From zhbmaillistonly at gmail.com Mon Mar 16 16:39:51 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Mon, 16 Mar 2009 23:39:51 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE685D.1060600@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> Message-ID: <49BE72C7.2080702@gmail.com> Michael Str?der wrote: > Thanks to Zhang Huangbin for giving me access to his machine for testing. > So I could track it down. It seems to work with the patch below which I > committed to CVS HEAD. Hi, Michael. Thanks for your quick response and hard work :) But i got new error (ldap.NO_MEMORY) here: ---- $ python 1.py ldap_create ldap_url_parse_ext(ldap://r6:389/) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.simple_bind (('cn=Manager,dc=iredmail,dc=org', 'passwd', None, None),{}) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP r6:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.122.6:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request => result: 1 *** ldap://r6:389/ - SimpleLDAPObject.result3 ((1, 1, -1),{}) ldap_result ld 0xd271300 msgid 1 ldap_chkResponseList ld 0xd271300 msgid 1 all 1 ldap_chkResponseList returns ld 0xd271300 NULL wait4msg ld 0xd271300 msgid 1 (infinite timeout) wait4msg continue ld 0xd271300 msgid 1 all 1 ** ld 0xd271300 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Mon Mar 16 23:38:48 2009 ** ld 0xd271300 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0xd271300 Response Queue: Empty ldap_chkResponseList ld 0xd271300 msgid 1 all 1 ldap_chkResponseList returns ld 0xd271300 NULL ldap_int_select read1msg: ld 0xd271300 msgid 1 all 1 read1msg: ld 0xd271300 msgid 1 message type bind read1msg: ld 0xd271300 0 new referrals read1msg: mark request completed, ld 0xd271300 msgid 1 request done: ld 0xd271300 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ldap_msgfree => result: (97, [], 1, []) *** ldap://r6:389/ - SimpleLDAPObject.search_ext (('o=domains,dc=iredmail,dc=org', 2, '(objectClass=mailUser)', None, 0, [('1.2.840.113556.1.4.319', True, '0\x05\x02\x01\n\x04\x00')], None, -1, 0),{}) ldap_search_ext put_filter: "(objectClass=mailUser)" put_filter: simple put_simple_filter: "objectClass=mailUser" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request => result: 2 Getting page 1 *** ldap://r6:389/ - SimpleLDAPObject.result3 ((2, 1, -1),{}) ldap_result ld 0xd271300 msgid 2 ldap_chkResponseList ld 0xd271300 msgid 2 all 1 ldap_chkResponseList returns ld 0xd271300 NULL wait4msg ld 0xd271300 msgid 2 (infinite timeout) wait4msg continue ld 0xd271300 msgid 2 all 1 ** ld 0xd271300 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Mon Mar 16 23:38:48 2009 ** ld 0xd271300 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xd271300 Response Queue: Empty ldap_chkResponseList ld 0xd271300 msgid 2 all 1 ldap_chkResponseList returns ld 0xd271300 NULL ldap_int_select read1msg: ld 0xd271300 msgid 2 all 1 read1msg: ld 0xd271300 msgid 2 message type search-entry wait4msg continue ld 0xd271300 msgid 2 all 1 ** ld 0xd271300 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Mon Mar 16 23:38:48 2009 ** ld 0xd271300 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xd271300 Response Queue: * msgid 2, type 100 ldap_chkResponseList ld 0xd271300 msgid 2 all 1 ldap_chkResponseList returns ld 0xd271300 NULL ldap_int_select read1msg: ld 0xd271300 msgid 2 all 1 read1msg: ld 0xd271300 msgid 2 message type search-result read1msg: ld 0xd271300 0 new referrals read1msg: mark request completed, ld 0xd271300 msgid 2 request done: ld 0xd271300 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 adding response ld 0xd271300 msgid 2 type 101: ldap_parse_result ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_msgfree => result: (101, [('mail=www at a.cn,ou=Users,domainName=a.cn,o=domains,dc=iredmail,dc=org', {'cn': ['www'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}Tq418bNZd6AOvYCGwlnUyQ=='], 'accountStatus': ['active'], 'sn': ['www'], 'homeDirectory': ['/home/vmail'], 'mail': ['www at a.cn'], 'mailMessageStore': ['a.cn/w/ww/www/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['www']})], 2, [('1.2.840.113556.1.4.319', 0, '0\x05\x02\x01\x00\x04\x00')]) Traceback (most recent call last): File "1.py", line 31, in ? rtype, rdata, rmsgid, serverctrls = l.result3(msgid) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/ldapobject.py", line 443, in result3 decoded_serverctrls = DecodeControlTuples(serverctrls) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 122, in DecodeControlTuples return [ File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 74, in __init__ LDAPControl.__init__(self,ldap.LDAP_CONTROL_PAGE_OID,criticality,controlValue,encodedControlValue) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 33, in __init__ self.controlValue = controlValue or self.decodeControlValue(encodedControlValue) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 81, in decodeControlValue size,cookie = _ldap.decode_page_control(encodedValue) ldap.NO_MEMORY ldap_free_connection 1 1 ldap_send_unbind ldap_free_connection: actually freed ---- -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Mon Mar 16 18:30:43 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 16 Mar 2009 18:30:43 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE72C7.2080702@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> <49BE72C7.2080702@gmail.com> Message-ID: <49BE8CC3.9000701@stroeder.com> Zhang Huangbin wrote: > Michael Str?der wrote: >> Thanks to Zhang Huangbin for giving me access to his machine for testing. >> So I could track it down. It seems to work with the patch below which I >> committed to CVS HEAD. > > Hi, Michael. Thanks for your quick response and hard work :) > > But i got new error (ldap.NO_MEMORY) here: This patch seems to work (already installed at your site ;-). Ciao, Michael. Index: Modules/ldapcontrol.c =================================================================== RCS file: /cvsroot/python-ldap/python-ldap/Modules/ldapcontrol.c,v retrieving revision 1.10 diff -u -r1.10 ldapcontrol.c --- Modules/ldapcontrol.c 16 Mar 2009 14:54:55 -0000 1.10 +++ Modules/ldapcontrol.c 16 Mar 2009 17:29:04 -0000 @@ -300,11 +300,13 @@ ber_tag_t tag; struct berval *cookiep; unsigned long count; + Py_ssize_t ldctl_value_len; if (!PyArg_ParseTuple(args, "s#:decode_page_control", &ldctl_value.bv_val, &ldctl_value.bv_len)) { goto endlbl; } + ldctl_value.bv_len = (ber_len_t) ldctl_value_len; if (!(ber = ber_init(&ldctl_value))) { LDAPerr(LDAP_NO_MEMORY); From zhbmaillistonly at gmail.com Mon Mar 16 19:23:48 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Tue, 17 Mar 2009 02:23:48 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE8CC3.9000701@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> <49BE72C7.2080702@gmail.com> <49BE8CC3.9000701@stroeder.com> Message-ID: <49BE9934.4090906@gmail.com> Michael Str?der wrote: > This patch seems to work (already installed at your site ;-). > Ciao, Michael. > > Index: Modules/ldapcontrol.c > =================================================================== > RCS file: /cvsroot/python-ldap/python-ldap/Modules/ldapcontrol.c,v > retrieving revision 1.10 > diff -u -r1.10 ldapcontrol.c > --- Modules/ldapcontrol.c 16 Mar 2009 14:54:55 -0000 1.10 > +++ Modules/ldapcontrol.c 16 Mar 2009 17:29:04 -0000 > @@ -300,11 +300,13 @@ > ber_tag_t tag; > struct berval *cookiep; > unsigned long count; > + Py_ssize_t ldctl_value_len; > > if (!PyArg_ParseTuple(args, "s#:decode_page_control", > &ldctl_value.bv_val, &ldctl_value.bv_len)) { > goto endlbl; > } > + ldctl_value.bv_len = (ber_len_t) ldctl_value_len; > > if (!(ber = ber_init(&ldctl_value))) { > LDAPerr(LDAP_NO_MEMORY); > > > So great, it works now. Big thanks, Michael. :) -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From zhbmaillistonly at gmail.com Mon Mar 16 19:36:32 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Tue, 17 Mar 2009 02:36:32 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE8CC3.9000701@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> <49BE72C7.2080702@gmail.com> <49BE8CC3.9000701@stroeder.com> Message-ID: <49BE9C30.8090304@gmail.com> Michael Str?der wrote: > This patch seems to work (already installed at your site ;-). > > Ciao, Michael. > > Index: Modules/ldapcontrol.c > =================================================================== > RCS file: /cvsroot/python-ldap/python-ldap/Modules/ldapcontrol.c,v > retrieving revision 1.10 > diff -u -r1.10 ldapcontrol.c > --- Modules/ldapcontrol.c 16 Mar 2009 14:54:55 -0000 1.10 > +++ Modules/ldapcontrol.c 16 Mar 2009 17:29:04 -0000 > @@ -300,11 +300,13 @@ > ber_tag_t tag; > struct berval *cookiep; > unsigned long count; > + Py_ssize_t ldctl_value_len; > > if (!PyArg_ParseTuple(args, "s#:decode_page_control", > &ldctl_value.bv_val, &ldctl_value.bv_len)) { > goto endlbl; > } > + ldctl_value.bv_len = (ber_len_t) ldctl_value_len; > > if (!(ber = ber_init(&ldctl_value))) { > LDAPerr(LDAP_NO_MEMORY); > > > hi, Michael. I found another problem. Below code works: >>> import ldap >>> from ldap.controls import SimplePagedResultsControl >>> SimplePagedResultsControl(ldap.LDAP_CONTROL_PAGE_OID,True,(10,'')).getEncodedTuple() ('1.2.840.113556.1.4.319', True, '0\x05\x02\x01\n\x04\x00') >>> But Demo/page_control.py doesn't work, it raises ldap.NO_MEMORY sometimes, and 'Segmentation fault' too. ---- # python 1.py ldap_create ldap_url_parse_ext(ldap://r6:389/) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.simple_bind (('cn=Manager,dc=iredmail,dc=org', 'passwd', None, None),{}) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP r6:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.122.6:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request => result: 1 *** ldap://r6:389/ - SimpleLDAPObject.result3 ((1, 1, -1),{}) ldap_result ld 0xb1cd7d0 msgid 1 ldap_chkResponseList ld 0xb1cd7d0 msgid 1 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL wait4msg ld 0xb1cd7d0 msgid 1 (infinite timeout) wait4msg continue ld 0xb1cd7d0 msgid 1 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: Empty ldap_chkResponseList ld 0xb1cd7d0 msgid 1 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 1 all 1 read1msg: ld 0xb1cd7d0 msgid 1 message type bind read1msg: ld 0xb1cd7d0 0 new referrals read1msg: mark request completed, ld 0xb1cd7d0 msgid 1 request done: ld 0xb1cd7d0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ldap_msgfree => result: (97, [], 1, []) *** ldap://r6:389/ - SimpleLDAPObject.search_ext (('domainName=b.cn,o=domains,dc=iredmail,dc=org', 2, '(objectClass=mailUser)', None, 0, [('1.2.840.113556.1.4.319', True, '0\x05\x02\x01\n\x04\x00')], None, -1, 0),{}) ldap_search_ext put_filter: "(objectClass=mailUser)" put_filter: simple put_simple_filter: "objectClass=mailUser" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request => result: 2 Getting page 1 *** ldap://r6:389/ - SimpleLDAPObject.result3 ((2, 1, -1),{}) ldap_result ld 0xb1cd7d0 msgid 2 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL wait4msg ld 0xb1cd7d0 msgid 2 (infinite timeout) wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: Empty ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-entry adding response ld 0xb1cd7d0 msgid 2 type 100: wait4msg continue ld 0xb1cd7d0 msgid 2 all 1 ** ld 0xb1cd7d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:34:51 2009 ** ld 0xb1cd7d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0xb1cd7d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0xb1cd7d0 msgid 2 all 1 ldap_chkResponseList returns ld 0xb1cd7d0 NULL ldap_int_select read1msg: ld 0xb1cd7d0 msgid 2 all 1 read1msg: ld 0xb1cd7d0 msgid 2 message type search-result read1msg: ld 0xb1cd7d0 0 new referrals read1msg: mark request completed, ld 0xb1cd7d0 msgid 2 request done: ld 0xb1cd7d0 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 adding response ld 0xb1cd7d0 msgid 2 type 101: ldap_parse_result ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_msgfree => result: (101, [('mail=1 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['1'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}xMpCOKC5I4INzFCab3WEmw=='], 'accountStatus': ['active'], 'sn': ['1'], 'homeDirectory': ['/home/vmail'], 'mail': ['1 at b.cn'], 'mailMessageStore': ['b.cn/1/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['1']}), ('mail=2 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['2'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}yB5yjZ1ML2NvBn+JzBSGLA=='], 'accountStatus': ['active'], 'sn': ['2'], 'homeDirectory': ['/home/vmail'], 'mail': ['2 at b.cn'], 'mailMessageStore': ['b.cn/2/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['2']}), ('mail=3 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['3'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}7MvIfktc4v4oMI/Z8qe68w=='], 'accountStatus': ['active'], 'sn': ['3'], 'homeDirectory': ['/home/vmail'], 'mail': ['3 at b.cn'], 'mailMessageStore': ['b.cn/3/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['3']}), ('mail=4 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['4'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}qH/2eaLz5x2RgaZ7dUISLA=='], 'accountStatus': ['active'], 'sn': ['4'], 'homeDirectory': ['/home/vmail'], 'mail': ['4 at b.cn'], 'mailMessageStore': ['b.cn/4/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['4']}), ('mail=5 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['5'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}5No7f7vOI0XXdysGdKMY1Q=='], 'accountStatus': ['active'], 'sn': ['5'], 'homeDirectory': ['/home/vmail'], 'mail': ['5 at b.cn'], 'mailMessageStore': ['b.cn/5/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['5']}), ('mail=6 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['6'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}FnkJHFqID69vteYIfrGy3A=='], 'accountStatus': ['active'], 'sn': ['6'], 'homeDirectory': ['/home/vmail'], 'mail': ['6 at b.cn'], 'mailMessageStore': ['b.cn/6/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['6']}), ('mail=7 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['7'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}jxTkX87qFnpaNt7dS+olQw=='], 'accountStatus': ['active'], 'sn': ['7'], 'homeDirectory': ['/home/vmail'], 'mail': ['7 at b.cn'], 'mailMessageStore': ['b.cn/7/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['7']}), ('mail=8 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['8'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}yfD4lfuYq5FZ9R/QKX4jbQ=='], 'accountStatus': ['active'], 'sn': ['8'], 'homeDirectory': ['/home/vmail'], 'mail': ['8 at b.cn'], 'mailMessageStore': ['b.cn/8/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['8']}), ('mail=9 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['9'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}RcSMzi4tf73qGvxRx8atJg=='], 'accountStatus': ['active'], 'sn': ['9'], 'homeDirectory': ['/home/vmail'], 'mail': ['9 at b.cn'], 'mailMessageStore': ['b.cn/9/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['9']}), ('mail=10 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['10'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}09lEaAKkQll1XTjm0WPoIA=='], 'accountStatus': ['active'], 'sn': ['10'], 'homeDirectory': ['/home/vmail'], 'mail': ['10 at b.cn'], 'mailMessageStore': ['b.cn/10/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['10']})], 2, [('1.2.840.113556.1.4.319', 0, '0\r\x02\x01\x00\x04\x08.\x02\x00\x00\x00\x00\x00\x00')]) Traceback (most recent call last): File "1.py", line 32, in ? rtype, rdata, rmsgid, serverctrls = l.result3(msgid) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/ldapobject.py", line 443, in result3 decoded_serverctrls = DecodeControlTuples(serverctrls) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 122, in DecodeControlTuples return [ File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 74, in __init__ LDAPControl.__init__(self,ldap.LDAP_CONTROL_PAGE_OID,criticality,controlValue,encodedControlValue) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 33, in __init__ self.controlValue = controlValue or self.decodeControlValue(encodedControlValue) File "/usr/lib64/python2.4/site-packages/python_ldap-2.3.6-py2.4-linux-x86_64.egg/ldap/controls.py", line 81, in decodeControlValue size,cookie = _ldap.decode_page_control(encodedValue) ldap.NO_MEMORY ldap_free_connection 1 1 ldap_send_unbind ldap_free_connection: actually freed ---- ---- # python 1.py ldap_create ldap_url_parse_ext(ldap://r6:389/) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.set_option ((17, 3),{}) *** ldap://r6:389/ - SimpleLDAPObject.simple_bind (('cn=Manager,dc=iredmail,dc=org', 'passwd', None, None),{}) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP r6:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.122.6:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request => result: 1 *** ldap://r6:389/ - SimpleLDAPObject.result3 ((1, 1, -1),{}) ldap_result ld 0x11df67d0 msgid 1 ldap_chkResponseList ld 0x11df67d0 msgid 1 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL wait4msg ld 0x11df67d0 msgid 1 (infinite timeout) wait4msg continue ld 0x11df67d0 msgid 1 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: Empty ldap_chkResponseList ld 0x11df67d0 msgid 1 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 1 all 1 read1msg: ld 0x11df67d0 msgid 1 message type bind read1msg: ld 0x11df67d0 0 new referrals read1msg: mark request completed, ld 0x11df67d0 msgid 1 request done: ld 0x11df67d0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ldap_msgfree => result: (97, [], 1, []) *** ldap://r6:389/ - SimpleLDAPObject.search_ext (('domainName=b.cn,o=domains,dc=iredmail,dc=org', 2, '(objectClass=mailUser)', None, 0, [('1.2.840.113556.1.4.319', True, '0\x05\x02\x01\n\x04\x00')], None, -1, 0),{}) ldap_search_ext put_filter: "(objectClass=mailUser)" put_filter: simple put_simple_filter: "objectClass=mailUser" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request => result: 2 Getting page 1 *** ldap://r6:389/ - SimpleLDAPObject.result3 ((2, 1, -1),{}) ldap_result ld 0x11df67d0 msgid 2 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL wait4msg ld 0x11df67d0 msgid 2 (infinite timeout) wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: Empty ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-entry adding response ld 0x11df67d0 msgid 2 type 100: wait4msg continue ld 0x11df67d0 msgid 2 all 1 ** ld 0x11df67d0 Connections: * host: r6 port: 389 (default) refcnt: 2 status: Connected last used: Tue Mar 17 02:35:36 2009 ** ld 0x11df67d0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 0x11df67d0 Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 ldap_chkResponseList ld 0x11df67d0 msgid 2 all 1 ldap_chkResponseList returns ld 0x11df67d0 NULL ldap_int_select read1msg: ld 0x11df67d0 msgid 2 all 1 read1msg: ld 0x11df67d0 msgid 2 message type search-result read1msg: ld 0x11df67d0 0 new referrals read1msg: mark request completed, ld 0x11df67d0 msgid 2 request done: ld 0x11df67d0 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 adding response ld 0x11df67d0 msgid 2 type 101: ldap_parse_result ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_dn ldap_first_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_get_values_len ldap_next_attribute ldap_msgfree => result: (101, [('mail=1 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['1'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}xMpCOKC5I4INzFCab3WEmw=='], 'accountStatus': ['active'], 'sn': ['1'], 'homeDirectory': ['/home/vmail'], 'mail': ['1 at b.cn'], 'mailMessageStore': ['b.cn/1/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['1']}), ('mail=2 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['2'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}yB5yjZ1ML2NvBn+JzBSGLA=='], 'accountStatus': ['active'], 'sn': ['2'], 'homeDirectory': ['/home/vmail'], 'mail': ['2 at b.cn'], 'mailMessageStore': ['b.cn/2/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['2']}), ('mail=3 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['3'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}7MvIfktc4v4oMI/Z8qe68w=='], 'accountStatus': ['active'], 'sn': ['3'], 'homeDirectory': ['/home/vmail'], 'mail': ['3 at b.cn'], 'mailMessageStore': ['b.cn/3/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['3']}), ('mail=4 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['4'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}qH/2eaLz5x2RgaZ7dUISLA=='], 'accountStatus': ['active'], 'sn': ['4'], 'homeDirectory': ['/home/vmail'], 'mail': ['4 at b.cn'], 'mailMessageStore': ['b.cn/4/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['4']}), ('mail=5 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['5'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}5No7f7vOI0XXdysGdKMY1Q=='], 'accountStatus': ['active'], 'sn': ['5'], 'homeDirectory': ['/home/vmail'], 'mail': ['5 at b.cn'], 'mailMessageStore': ['b.cn/5/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['5']}), ('mail=6 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['6'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}FnkJHFqID69vteYIfrGy3A=='], 'accountStatus': ['active'], 'sn': ['6'], 'homeDirectory': ['/home/vmail'], 'mail': ['6 at b.cn'], 'mailMessageStore': ['b.cn/6/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['6']}), ('mail=7 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['7'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}jxTkX87qFnpaNt7dS+olQw=='], 'accountStatus': ['active'], 'sn': ['7'], 'homeDirectory': ['/home/vmail'], 'mail': ['7 at b.cn'], 'mailMessageStore': ['b.cn/7/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['7']}), ('mail=8 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['8'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}yfD4lfuYq5FZ9R/QKX4jbQ=='], 'accountStatus': ['active'], 'sn': ['8'], 'homeDirectory': ['/home/vmail'], 'mail': ['8 at b.cn'], 'mailMessageStore': ['b.cn/8/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['8']}), ('mail=9 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['9'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}RcSMzi4tf73qGvxRx8atJg=='], 'accountStatus': ['active'], 'sn': ['9'], 'homeDirectory': ['/home/vmail'], 'mail': ['9 at b.cn'], 'mailMessageStore': ['b.cn/9/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['9']}), ('mail=10 at b.cn,ou=Users,domainName=b.cn,o=domains,dc=iredmail,dc=org', {'cn': ['10'], 'mailQuota': ['104857600'], 'objectClass': ['inetOrgPerson', 'mailUser', 'top'], 'userPassword': ['{MD5}09lEaAKkQll1XTjm0WPoIA=='], 'accountStatus': ['active'], 'sn': ['10'], 'homeDirectory': ['/home/vmail'], 'mail': ['10 at b.cn'], 'mailMessageStore': ['b.cn/10/'], 'enabledService': ['mail', 'imap', 'pop3', 'smtp', 'deliver'], 'uid': ['10']})], 2, [('1.2.840.113556.1.4.319', 0, '0\r\x02\x01\x00\x04\x08.\x02\x00\x00\x00\x00\x00\x00')]) Segmentation fault ---- -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From zhbmaillistonly at gmail.com Tue Mar 17 04:23:42 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Tue, 17 Mar 2009 11:23:42 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BE8CC3.9000701@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> <49BE72C7.2080702@gmail.com> <49BE8CC3.9000701@stroeder.com> Message-ID: <49BF17BE.7090001@gmail.com> Michael Str?der wrote: > This patch seems to work (already installed at your site ;-). > > Ciao, Michael. > > Index: Modules/ldapcontrol.c > =================================================================== > RCS file: /cvsroot/python-ldap/python-ldap/Modules/ldapcontrol.c,v > retrieving revision 1.10 > diff -u -r1.10 ldapcontrol.c > --- Modules/ldapcontrol.c 16 Mar 2009 14:54:55 -0000 1.10 > +++ Modules/ldapcontrol.c 16 Mar 2009 17:29:04 -0000 > @@ -300,11 +300,13 @@ > ber_tag_t tag; > struct berval *cookiep; > unsigned long count; > + Py_ssize_t ldctl_value_len; > > if (!PyArg_ParseTuple(args, "s#:decode_page_control", > &ldctl_value.bv_val, &ldctl_value.bv_len)) { > goto endlbl; > } > + ldctl_value.bv_len = (ber_len_t) ldctl_value_len; > > if (!(ber = ber_init(&ldctl_value))) { > LDAPerr(LDAP_NO_MEMORY); > > Hi, Michael. Something strange. The server your tested is CentOS 5.2 x86_64, and it works with your patched version. But on RHEL 5.3 x86_64, it raises ldap.NO_MEMORY error: ---- # python 1.py Getting page 1 Traceback (most recent call last): File "1.py", line 30, in ? rtype, rdata, rmsgid, serverctrls = l.result3(msgid) File "/usr/lib64/python2.4/site-packages/ldap/ldapobject.py", line 443, in result3 decoded_serverctrls = DecodeControlTuples(serverctrls) File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 122, in DecodeControlTuples return [ File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 74, in __init__ LDAPControl.__init__(self,ldap.LDAP_CONTROL_PAGE_OID,criticality,controlValue,encodedControlValue) File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 33, in __init__ self.controlValue = controlValue or self.decodeControlValue(encodedControlValue) File "/usr/lib64/python2.4/site-packages/ldap/controls.py", line 81, in decodeControlValue size,cookie = _ldap.decode_page_control(encodedValue) ldap.NO_MEMORY ---- But i don't have a public RHEL 5.3 x86_64 server. :( -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Tue Mar 17 13:38:14 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 17 Mar 2009 13:38:14 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BF17BE.7090001@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> <49BE72C7.2080702@gmail.com> <49BE8CC3.9000701@stroeder.com> <49BF17BE.7090001@gmail.com> Message-ID: <49BF99B6.8060704@stroeder.com> Zhang Huangbin wrote: > Michael Str?der wrote: >> This patch seems to work (already installed at your site ;-). >> > Something strange. > > The server your tested is CentOS 5.2 x86_64, and it works with your > patched version. > > But on RHEL 5.3 x86_64, it raises ldap.NO_MEMORY error: Are you sure that the new version really was installed and gets used? I'm asking since I also made a mistake regarding this during testing. You might wanna check with python -v which modules get loaded and check the file timestamp of the _ldap.so file. Ciao, Michael. From michael at stroeder.com Wed Mar 18 07:02:38 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 18 Mar 2009 07:02:38 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49BF99B6.8060704@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> <49BE72C7.2080702@gmail.com> <49BE8CC3.9000701@stroeder.com> <49BF17BE.7090001@gmail.com> <49BF99B6.8060704@stroeder.com> Message-ID: <49C08E7E.5060103@stroeder.com> Michael Str?der wrote: > Zhang Huangbin wrote: >> Michael Str?der wrote: >>> This patch seems to work (already installed at your site ;-). >>> >> Something strange. >> >> The server your tested is CentOS 5.2 x86_64, and it works with your >> patched version. >> >> But on RHEL 5.3 x86_64, it raises ldap.NO_MEMORY error: > > Are you sure that the new version really was installed and gets used? Aargh! My fault. Thanks David. Modules/ldapcontrol.c in CVS HEAD should work now. Ciao, Michael. http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/ldapcontrol.c From zhbmaillistonly at gmail.com Wed Mar 18 07:31:11 2009 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Wed, 18 Mar 2009 14:31:11 +0800 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49C08E7E.5060103@stroeder.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49BE426D.9010802@stroeder.com> <49BE4AA3.1060609@stroeder.com> <49BE549A.6060202@gmail.com> <49BE685D.1060600@stroeder.com> <49BE72C7.2080702@gmail.com> <49BE8CC3.9000701@stroeder.com> <49BF17BE.7090001@gmail.com> <49BF99B6.8060704@stroeder.com> <49C08E7E.5060103@stroeder.com> Message-ID: <49C0952F.3010808@gmail.com> Michael Str?der wrote: > Aargh! My fault. Thanks David. > Modules/ldapcontrol.c in CVS HEAD should work now. Tested and it *WORKS* now, Thanks David & Michael. :) -- Best regards. Zhang Huangbin - Open Source Mail Server Solution for RHEL/CentOS 5.x: http://code.google.com/p/iredmail/ From michael at stroeder.com Wed Mar 18 09:21:33 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 18 Mar 2009 09:21:33 +0100 Subject: ldap.ENCODING_ERROR when trying to use SimplePageResultsControl In-Reply-To: <49C09608.1000505@gmail.com> References: <49BCDDA0.5010009@gmail.com> <49BE39B0.60506@stroeder.com> <49BE3FBB.7080200@gmail.com> <49C09608.1000505@gmail.com> Message-ID: <49C0AF0D.7080308@stroeder.com> Zhang Huangbin wrote: > > A personal question: Cc: to the list since this could be of general interest. > when will you release a new version? It would be no big deal to release a new version tonight if it's important for your project to use a released version with a definite version number you can reference in your docs. I'd like others who reported the problem to confirm that it works for them now. Ciao, Michael. From unix.gurus at gmail.com Fri Mar 20 20:14:11 2009 From: unix.gurus at gmail.com (Sean Burford) Date: Fri, 20 Mar 2009 12:14:11 -0700 Subject: Segfault in LDAPerror() when errnum is out of bounds Message-ID: Hi, When LDAPError receives an errnum from ldap_get_option(l, LDAP_OPT_ERROR_NUMBER, &errnum) that is out of bounds it causes a segfault. I have attached a script that triggers it and patch that fixes it. The test script requires an ldap URI and a BaseDN on the command line. The ldap server can be OpenLDAP 2.3 or 2.4 and the BaseDN should be configured with a syncprov overlay and have syncprov-reloadhint TRUE. eg: /tmp/ldap-segfault.py ldap://ldap.example.com dc=example,dc=com After patching _ldap.so we get a valid Exception: Traceback (most recent call last): File "/tmp/ldap-segfault.py", line 39, in ? rtype, rdata, rmsgid, serverctrls = conn.result3(all=1, timeout=60) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 438, in result3 rtype, rdata, rmsgid, serverctrls = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 97, in _ldap_call result = func(*args,**kwargs) ldap.LDAPError: {'info': 'sync cookie is stale', 'desc': 'Content Sync Refresh Required'} -- Thanks, Sean Burford -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: python-ldap-2.3.1-error.patch Type: text/x-diff Size: 969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap-segfault.py Type: text/x-python Size: 1197 bytes Desc: not available URL: From michael at stroeder.com Fri Mar 20 21:38:53 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Mar 2009 21:38:53 +0100 Subject: Segfault in LDAPerror() when errnum is out of bounds In-Reply-To: References: Message-ID: <49C3FEDD.3050908@stroeder.com> Sean, many thanks for digging through this. Does that mean your issues with syncrepl controls and l_ldap_result3() are fixed? Any particular reason why you're using python-ldap 2.3.1 which is almost two years old? Sean Burford wrote: > When LDAPError receives an errnum from ldap_get_option(l, > LDAP_OPT_ERROR_NUMBER, &errnum) that is out of bounds it causes a > segfault. I have attached a script that triggers it and patch that > fixes it. So after applying your patch I get this generic LDAPError exception below. This is definitely more robust. ldap.LDAPError: {'info': 'sync cookie is stale', 'desc': 'Content Sync Refresh Required'} Anyway I'd see some benefit adding also the syncrepl error codes to let the application catch specific exceptions. Unfortunately errobjects in Modules/errors.c is a simple array. Bumping up LDAP_ERROR_MAX to LDAP_SYNC_REFRESH_REQUIRED would be pretty naively waste a lot of space. Ciao, Michael. From unix.gurus at gmail.com Fri Mar 20 22:00:41 2009 From: unix.gurus at gmail.com (Sean Burford) Date: Fri, 20 Mar 2009 14:00:41 -0700 Subject: Segfault in LDAPerror() when errnum is out of bounds In-Reply-To: <49C3FEDD.3050908@stroeder.com> References: <49C3FEDD.3050908@stroeder.com> Message-ID: Hi, 2009/3/20 Michael Str?der > many thanks for digging through this. Does that mean your issues with > syncrepl controls and l_ldap_result3() are fixed? Yeah. There are still mysteries, but RefreshOnly works well enough for now. I'm wondering why controls are stripped from search results (it would be nice to get the control that says whether a syncrepl result is an add/modify or delete for example). Is this just a side effect of optimisation of the usual code path? Any particular reason why you're using python-ldap 2.3.1 which is almost > two years old? It came with my distro. > Sean Burford wrote: > > When LDAPError receives an errnum from ldap_get_option(l, > > LDAP_OPT_ERROR_NUMBER, &errnum) that is out of bounds it causes a > > segfault. I have attached a script that triggers it and patch that > > fixes it. > > So after applying your patch I get this generic LDAPError exception > below. This is definitely more robust. Glad to help. -- Thanks, Sean Burford -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri Mar 20 22:24:38 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 20 Mar 2009 22:24:38 +0100 Subject: Segfault in LDAPerror() when errnum is out of bounds In-Reply-To: References: <49C3FEDD.3050908@stroeder.com> Message-ID: <49C40996.6050002@stroeder.com> Sean Burford wrote: > > 2009/3/20 Michael Str?der > > > many thanks for digging through this. Does that mean your issues with > syncrepl controls and l_ldap_result3() are fixed? > > Yeah. There are still mysteries, but RefreshOnly works well enough for now. > > I'm wondering why controls are stripped from search results (it would be > nice to get the control that says whether a syncrepl result is an > add/modify or delete for example). Is this just a side effect of > optimisation of the usual code path? I did not write that code. It' still mystery to me especially since I don't like programming C. Maybe David could enlighten us. When support for LDAPv3 controls was added I already had some doubts... > Any particular reason why you're using python-ldap 2.3.1 which is almost > two years old? > > > It came with my distro. Please upgrade, especially when providing patches. There have been numerous fixes since then: http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/CHANGES?revision=1.183&view=markup Your patch and a couple of other minor changes are now in CVS HEAD. There should be no compability issues between 2.3.1 and a recent python-ldap release. Ciao, Michael. From unix.gurus at gmail.com Fri Mar 27 03:31:52 2009 From: unix.gurus at gmail.com (Sean Burford) Date: Thu, 26 Mar 2009 19:31:52 -0700 Subject: Segfault in LDAPerror() when errnum is out of bounds In-Reply-To: <49C40996.6050002@stroeder.com> References: <49C3FEDD.3050908@stroeder.com> <49C40996.6050002@stroeder.com> Message-ID: 2009/3/20 Michael Str?der > Your patch and a couple of other minor changes are now in CVS HEAD. errors.c still looks the same, has the patch been submitted? http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/errors.c?view=markup -- Thanks, Sean Burford -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Fri Mar 27 10:42:10 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 27 Mar 2009 10:42:10 +0100 Subject: Segfault in LDAPerror() when errnum is out of bounds In-Reply-To: References: <49C3FEDD.3050908@stroeder.com> <49C40996.6050002@stroeder.com> Message-ID: <49CC9F72.9080408@stroeder.com> Sean Burford wrote: > 2009/3/20 Michael Str?der > > > Your patch and a couple of other minor changes are now in CVS HEAD. > > errors.c still looks the same, has the patch been submitted? Oops. Yes, forgot to committ it. Done now. http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/errors.c?r1=1.19&r2=1.20 Ciao, Michael. From unix.gurus at gmail.com Tue Mar 17 22:25:38 2009 From: unix.gurus at gmail.com (Sean Burford) Date: Tue, 17 Mar 2009 14:25:38 -0700 Subject: Python ldap and syncrepl controls Message-ID: Hi, I've been working on implementing an RFC 4533 syncrepl consumer using python-ldap. I can't work out why I can't get the SyncDoneControl that is returned with the LDAP_RES_SEARCH_RESULT through python-ldap. The SyncDoneControl contains the cookie that is needed for stateful/minimal syncrepl refresh only, so losing that control makes the code a lot less useful. It looks like SyncStateControl is never returned to the Python code because Modules/LDAPObject.c l_ldap_result3() calls LDAPmessage_to_python() for LDAP_RES_SEARCH_ENTRY. LDAPmessage_to_python() discards controls in the result. I can live with this. I'm mystified as to why Modules/LDAPObject.c l_ldap_result3() doesn't return the SyncDoneControl with the LDAP_RES_SEARCH_RESULT. I've waded through the source and I'm pretty sure that nothing is deliberately filtering out the control. Here we can see that the control is in the result when l_ldap_result3() calls ldap_parse_result(): Breakpoint 2, ldap_parse_result (ld=0x783710, r=0x730830, errcodep=0x7fff5d8582c4, matcheddnp=0x0, errmsgp=0x0, referralsp=0x7fff5d8582a8, serverctrls=0x7fff5d8582a0, freeit=0) at error.c:261 (gdb) p *r->lm_ber $6 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 121, ber_len = 81, ber_usertag = 0, ber_buf = 0x7e3d60 "\002\001\001yL\200\0301.3.6.1.4.1.4203.1.9.1.4\2010?.\004,csn=20090317201420Z#000000#00#000000,rid=000", ber_ptr = 0x7e3d63 "yL\200\0301.3.6.1.4.1.4203.1.9.1.4\2010?.\004,csn=20090317201420Z#000000#00#000000,rid=000", ber_end = 0x7e3db1 "", ber_sos = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} (gdb) p *serverctrls $7 = (LDAPControl **) 0x0 Here is my sample code: class SyncRequestControl(ldap.controls.LDAPControl): # The Sync Request Control is an LDAP Control [RFC4511] where the # controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the # controlValue, an OCTET STRING, contains a BER-encoded # syncRequestValue. The criticality field is either TRUE or FALSE. # syncRequestValue ::= SEQUENCE { # mode ENUMERATED { # -- 0 unused # refreshOnly (1), # -- 2 reserved # refreshAndPersist (3) # }, # cookie syncCookie OPTIONAL, # reloadHint BOOLEAN DEFAULT FALSE # } # The Sync Request Control is only applicable to the SearchRequest Message. controlType='1.3.6.1.4.1.4203.1.9.1.1' def __init__(self, controlType='1.3.6.1.4.1.4203.1.9.1.1', criticality=False, controlValue=None, encodedControlValue=None): ldap.controls.LDAPControl.__init__(self, self.controlType, criticality, controlValue, encodedControlValue) def encodeControlValue(self, value): # 30 31 Sequence tag (len=0x31) # 0a 01 01 Enumerated (len=0x01) value 0x01 (RefreshOnly) # 04 2C Octet String (len=0x2C) value 'csn=...,rid=000' # 63 73 6e 3d 32 30 30 39 30 33 31 36 31 39 35 35 # 30 39 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 # 30 30 30 30 2c 72 69 64 3d 30 30 30 mode, cookie, reload_hint = value # Enumerated (len=0x01) value 0x01 (RefreshOnly) result_content = struct.pack('BBB', 0x0A, 0x01, mode) # Octet String (optional) if cookie: result_content += struct.pack('BB', 0x04, len(cookie)) result_content += cookie # Boolean (optional) if reload_hint: result_content += struct.pack('BBB', 0x01, 0x01, 0xFF) # Sequence tag result_header = struct.pack('BB', 0x30, len(result_content)) return result_header + result_content ldap.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3) ldap.set_option(ldap.OPT_REFERRALS, 0) conn = ldap.initialize(host) sync_req_ctrl=SyncRequestControl(criticality=True, controlValue=(3, cookie, True)) op_id = conn.search_ext(base, ldap.SCOPE_ONELEVEL, attrlist=('dn',), serverctrls=(sync_req_ctrl,), ) # ldap.controls.knownLDAPControls[SyncStateControl.controlType] = SyncStateControl # ldap.controls.knownLDAPControls[SyncDoneControl.controlType] = SyncDoneControl #rtype, rdata, rmsgid, decoded_serverctrl = conn.result3(all=0, timeout=60) rtype, rdata, rmsgid, serverctrls = conn._ldap_call(conn._l.result3,_ldap.RES_ANY,0,60) while rtype: print 'rtype=%s' % rtype print 'rdata=%s' % rdata print 'rmsgid=%s' % rmsgid print 'serverctrls=%s' % serverctrls print '' # rtype, rdata, rmsgid, decoded_serverctrl = conn.result3(all=0, timeout=10) rtype, rdata, rmsgid, serverctrls = conn._ldap_call(conn._l.result3,_ldap.RES_ANY,0,10) -- Thanks, Sean Burford -------------- next part -------------- An HTML attachment was scrubbed... URL: From unix.gurus at gmail.com Tue Mar 17 23:53:15 2009 From: unix.gurus at gmail.com (Sean Burford) Date: Tue, 17 Mar 2009 15:53:15 -0700 Subject: Python ldap and syncrepl controls In-Reply-To: References: Message-ID: Hi, If I switch the control from RefreshPersist(3) to RefreshOnly(1) I get an LDAP_RES_SEARCH_RESULT instead of LDAP_RES_INTERMEDIATE carrying the SyncDoneControl. Strangely enough, the LDAP_RES_SEARCH_RESULT makes it back to my code with an intact control: rtype=101 rdata=[] rmsgid=1 serverctrls=[('1.3.6.1.4.1.4203.1.9.1.3', 0, '01\x04,csn=20090317224602Z#000000#00#000000,rid=000\x01\x01\xff')] So the problem is that the control is lost if it is attached to an LDAP_RES_INTERMEDIATE, but it is not lost when it is attached to an LDAP_RES_SEARCH_RESULT. -- Thanks, Sean Burford -------------- next part -------------- An HTML attachment was scrubbed... URL: