From michael at stroeder.com Sat Jan 9 15:49:41 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 09 Jan 2010 15:49:41 +0100 Subject: Multiple Email Values In-Reply-To: <20091230152231.GW20638@ZenIV.linux.org.uk> References: <1260269333.1816.4.camel@localhost> <4B2B43C7.3050907@stroeder.com> <4B3B586F.9030205@gmx.de> <20091230152231.GW20638@ZenIV.linux.org.uk> Message-ID: <4B489785.9090208@stroeder.com> Chris Dukes wrote: > On Wed, Dec 30, 2009 at 02:41:03PM +0100, Christoph Holtermann wrote: >> I use LDAP for storing my contacts. I keep thinking about the >> simple case of people having multiple email. One case >> would be to have an attribute "mail" another one "mozillaSecond >> Email". On the other hand I know that it >> is possible to store multiple values in the corresponding LDAP- >> attribute. but i wonder how it could be possible to also store >> an additional information about these email. > > If you're caring from an MTA perspective... > Postfix's LDAP maps suggest a 'maildrop' attribute for calculating actual > delivery. 'maildrop' has a different semantics. > And now a suggestion so you can spend an afternoon seeing what it > breaks... > Well, atleast in my LDAP schemas the mail attribute has syntax > 1.3.6.1.4.1.1466.115.121.1.15 > > And looking at 6.10 of RFC2252 > http://tools.ietf.org/html/rfc2252 > > You can put any unicode string there you want to such > as > Christoph Holtermann Obsolete This is IMO bad advice since MUAs expect only the raw e-mail address in attribute 'mail' (see section 2.16 in RFC 4524) which also contains some other interesting notes. Ciao, Michael. From dave.x.kirby at gmail.com Sun Jan 17 17:24:41 2010 From: dave.x.kirby at gmail.com (Dave Kirby) Date: Sun, 17 Jan 2010 16:24:41 +0000 Subject: =?UTF-8?Q?How_get_get_more_search_results_than_the_server=E2=80=99s_?= =?UTF-8?Q?sizelimit=3F?= Message-ID: <596657641001170824r7cb4846fv604c02fecbb35ea3@mail.gmail.com> Hi, I am trying to search for all groups on a server, but there are more than the server sizelimit results, so the search fails to get them all. My understanding is that the only way to get round this is to use a paged search control with the search, but according to the python-ldap docs controls are not supported for the search functions even though they are for other functions. Is there a way in python-ldap to get all the results from a search query, or am I shafted? From michael at stroeder.com Mon Jan 18 13:51:55 2010 From: michael at stroeder.com (=?windows-1252?Q?Michael_Str=F6der?=) Date: Mon, 18 Jan 2010 13:51:55 +0100 Subject: =?windows-1252?Q?Re=3A_How_get_get_more_search_resul?= =?windows-1252?Q?ts_than_the_server=92s_sizelimit=3F?= In-Reply-To: <596657641001170824r7cb4846fv604c02fecbb35ea3@mail.gmail.com> References: <596657641001170824r7cb4846fv604c02fecbb35ea3@mail.gmail.com> Message-ID: <4B54596B.3090708@stroeder.com> Dave Kirby wrote: > Hi, I am trying to search for all groups on a server, but there are > more than the server sizelimit results, so the search fails to get > them all. > > My understanding is that the only way to get round this is to use a > paged search control with the search, Which LDAP server product? With MS Active Directory using the simple paged results control helps to circumvent the search result limit. But this won't work with other LDAP servers like OpenLDAP which always enforces the configured search result limit. > but according to the python-ldap > docs controls are not supported for the search functions even though > they are for other functions. Which version of python-ldap and docs are you referring to? An example for simple paged results is shipped in the source distribution. See this file: Demo/page_control.py > Is there a way in python-ldap to get all the results from a search > query, or am I shafted? In general the server determines what "all the results" means. ;-) Ciao, Michael. From michael at stroeder.com Mon Jan 18 17:25:36 2010 From: michael at stroeder.com (=?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?=) Date: Mon, 18 Jan 2010 17:25:36 +0100 Subject: How get get more search results than the =?UTF-8?B?c2VydmVy4oCZ?= =?UTF-8?B?cyBzaXplbGltaXQ/?= In-Reply-To: <596657641001180618w515ccee7o5078ee5e720b20a5@mail.gmail.com> References: <596657641001170824r7cb4846fv604c02fecbb35ea3@mail.gmail.com> <4B54596B.3090708@stroeder.com> <596657641001180618w515ccee7o5078ee5e720b20a5@mail.gmail.com> Message-ID: <4B548B80.5030201@stroeder.com> Dave Kirby wrote: > 2010/1/18 Michael Str?der : > Dave Kirby wrote: > [snip] >>> but according to the python-ldap >>> docs controls are not supported for the search functions even though >>> they are for other functions. >> >> Which version of python-ldap and docs are you referring to? >> > > I was referring to the docs online at > http://www.python-ldap.org/doc/html/ldap.html#ldapobject-class and the > latest version in CVS at > http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Doc/ldap.rst?revision=1.11&view=markup. > > They both say under the LDAPPObject.search_xxx functions: > > * serverctrls* not implemented yet. > * clientctrls* not implemented yet. Sorry, this is clearly outdated. Will correct it soon. Ciao, Michael. From michael at stroeder.com Sun Jan 31 15:58:09 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 31 Jan 2010 15:58:09 +0100 Subject: How can i add a booleanMatch type attribute In-Reply-To: References: Message-ID: <4B659A81.5060908@stroeder.com> Zhang Huangbin wrote: > How can i add a booleanMatch type attribute with py-ldap? Simply like any other attribute provided your attribute value is TRUE or FALSE. > Refer to python-ldap-2.3.10/Demo/ldapcontrols.py, i use below code to add new attribute: > > ---- > l = ldap.initialize('ldap://localhost:389',trace_level=2) > l.add_ext_s(dn, modlist, serverctrls=[ BooleanControl('1.3.6.1.4.1.4203.1.10.1',1,1) ],) ??? Here you are using the Subentries control with an LDAP AddRequest. AFAIK this control (which is not an attribute) is only applicable to SearchRequests (see RFC 3672). What made you write this code? > ---- > > But i got this error message: > ---- > => result: 2 > *** ldap://127.0.0.1:389/ - SimpleLDAPObject.result3 ((2, 1, -1),{}) > => LDAPError - UNAVAILABLE_CRITICAL_EXTENSION: {'info': 'critical extension is not recognized', 'desc': 'Critical extension is unavailable'} > ---- The server does not support this control for processing this request. Well, that looks correct to me. > I use amavisd-new attribute: > ---- > attributetype ( 1.3.6.1.4.1.15312.2.2.1.19 > NAME 'amavisLocal' > DESC 'Is user considered local' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE ) > ---- I don't see any need to use a LDAPv3 extended control to simply populate this attribute (once it's added to the schema). Ciao, Michael. From zhbmaillistonly at gmail.com Sat Jan 30 14:14:37 2010 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Sat, 30 Jan 2010 21:14:37 +0800 Subject: How can i add a booleanMatch type attribute Message-ID: Hi, all. How can i add a booleanMatch type attribute with py-ldap? Refer to python-ldap-2.3.10/Demo/ldapcontrols.py, i use below code to add new attribute: ---- l = ldap.initialize('ldap://localhost:389',trace_level=2) l.add_ext_s(dn, modlist, serverctrls=[ BooleanControl('1.3.6.1.4.1.4203.1.10.1',1,1) ],) ---- But i got this error message: ---- => result: 2 *** ldap://127.0.0.1:389/ - SimpleLDAPObject.result3 ((2, 1, -1),{}) => LDAPError - UNAVAILABLE_CRITICAL_EXTENSION: {'info': 'critical extension is not recognized', 'desc': 'Critical extension is unavailable'} ---- I use amavisd-new attribute: ---- attributetype ( 1.3.6.1.4.1.15312.2.2.1.19 NAME 'amavisLocal' DESC 'Is user considered local' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) ---- -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu, FreeBSD: http://www.iredmail.org/ From awilliam at opengroupware.us Fri Jan 29 17:15:00 2010 From: awilliam at opengroupware.us (Adam Tauno Williams) Date: Fri, 29 Jan 2010 11:15:00 -0500 Subject: DSML writer Message-ID: <1264781700.6660.24.camel@linux-m3mt> I noticed that python-ldap contains some DSML support; only the XML produced is invalid [I believe this is caused by its attempt to create 'pretty' output]. Unable to use the DSML support in python-ldap I wrote my own DSML writer. License is MIT/X11. This is only meant as an FYI in case someone wants to update the DSML support in Python-LDAP. -- OpenGroupware developer: awilliam at whitemice.org From michael at stroeder.com Sun Jan 31 19:10:43 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sun, 31 Jan 2010 19:10:43 +0100 Subject: DSML writer In-Reply-To: <1264781700.6660.24.camel@linux-m3mt> References: <1264781700.6660.24.camel@linux-m3mt> Message-ID: <4B65C7A3.3070702@stroeder.com> Adam Tauno Williams wrote: > I noticed that python-ldap contains some DSML support; only the XML > produced is invalid [I believe this is caused by its attempt to create > 'pretty' output]. Could you please point me to the details which parts of the XML produced are invalid. Ciao, Michael. From zhbmaillistonly at gmail.com Mon Feb 1 06:03:31 2010 From: zhbmaillistonly at gmail.com (Zhang Huangbin) Date: Mon, 1 Feb 2010 13:03:31 +0800 Subject: How can i add a booleanMatch type attribute In-Reply-To: <4B659A81.5060908@stroeder.com> References: <4B659A81.5060908@stroeder.com> Message-ID: On Jan 31, 2010, at 10:58 PM, Michael Str?der wrote: > Zhang Huangbin wrote: >> How can i add a booleanMatch type attribute with py-ldap? > > Simply like any other attribute provided your attribute value is TRUE or FALSE. Successed with modlist: ('amavisLocal', ['TRUE']), Thanks :) -- Best Regards. Zhang Huangbin - Open Source Mail Server Solution for Red Hat(R) Enterprise Linux, CentOS, Debian, Ubuntu, FreeBSD: http://www.iredmail.org/ From michael at stroeder.com Tue Feb 2 00:41:03 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Feb 2010 00:41:03 +0100 Subject: ldaps and Active Directory In-Reply-To: <4B66FC56.1050506@swarthmore.edu> References: <4B66FC56.1050506@swarthmore.edu> Message-ID: <4B67668F.9010404@stroeder.com> Patrick A. Treptau wrote: > I am pulling my hair out trying to connect via ldaps to one of our AD > controllers. > > host = "ldaps://ad_host:636" You should always use the fully-qualified which is in the CN of the server certificate's subject DN. > #openssl s_client -CAfile path/to/cert.crt -connect ad_host:636 returns > a successful connection With -verify? Ciao, Michael. From ptrepta1 at swarthmore.edu Mon Feb 1 17:07:50 2010 From: ptrepta1 at swarthmore.edu (Patrick A. Treptau) Date: Mon, 01 Feb 2010 11:07:50 -0500 Subject: ldaps and Active Directory Message-ID: <4B66FC56.1050506@swarthmore.edu> I am pulling my hair out trying to connect via ldaps to one of our AD controllers. Everything works just fine with ldap:389, but as soon as I try to use ldaps:636, I get this: ldap.SERVER_DOWN: {'info': '(unknown error code)', 'desc': "Can't contact LDAP server"} My code is exactly as in "Demo/initialize.py": import sys import ldap ldap.set_option(ldap.OPT_REFERRALS, 0) ldap.set_option(ldap.OPT_DEBUG_LEVEL,0) ldapmodule_trace_level = 1 ldapmodule_trace_file = sys.stderr host = "ldaps://ad_host:636" con = ldap.initialize(host,trace_level=ldapmodule_trace_level,trace_file=ldapmodule_trace_file) con.set_option(ldap.OPT_PROTOCOL_VERSION, 3) con.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,ldap.OPT_X_TLS_DEMAND) con.set_option(ldap.OPT_X_TLS_CACERTFILE, 'path/to/cert.crt') con.set_option(ldap.OPT_DEBUG_LEVEL, 255) con.bind_s(full_dn, pass) #openssl s_client -CAfile path/to/cert.crt -connect ad_host:636 returns a successful connection and I am also able to connect with other ldap clients (jxplorer) with SSL and the same CA cert. What am I missing? Thank you, Patrick From buesching at univention.de Fri Jan 8 09:39:40 2010 From: buesching at univention.de (Andreas =?utf-8?q?B=C3=BCsching?=) Date: Fri, 8 Jan 2010 09:39:40 +0100 Subject: start_tls = 2 is ignored with LDAP URIs starting with LDAP:// Message-ID: <201001080939.43196.buesching@univention.de> Hi, I've found a strange behaviour of python-ldap when working with TLS encrypted connections. I'm not sure if this is a problem of the python bindings or of libldap or in my head ;-) In my first scenario I was trying to set up a TLS encrypted connection with a specific CA certificate that was set in the ldap.conf file (TLS_CACERT). >>> import ldap >>> l = ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention.test:389', who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem') >>> l.started_tls 0 In that case the connection is not encrypted. When I replace LDAP:// with ldap:// in the URI the connection is encrypted. >>> l = ldap.ldapobject.SmartLDAPObject(uri='ldap://qamaster.windom2008.univention.test:389', who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem') >>> l.started_tls 1 It look likes a TLS connection is not set up if the URI starts with LDAP:// In the second scenario I've tried to set up a TLS encrypted connection with a CA certificate that was not set in the ldap.conf file. >>> l = ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389', who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', start_tls=2, tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem') ... ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': 'Connect error'} It seems that the argument tls_cacertfile is ignored, because if I set the CA certificate file with the set_option function the connection works and is encrypted. ldap.set_option( ldap.OPT_X_TLS_CACERTFILE, '/etc/univention/connector/ad/ad_cert_20091221_153053.pem' ) l = ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389', who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', start_tls=2 ) >>> l.started_tls 1 software versions: python 2.4.6 libldap 2.4.15 python-ldap 2.3.5 Is there any mistake in my reasoning or is this a known behaviour? best regards Andreas -- Andreas B?sching Open Source Software Engineer Univention GmbH Linux for your business Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 Fax : +49 421 22232-99 http://www.univention.de Gesch?ftsf?hrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From buesching at univention.de Wed Feb 3 08:36:37 2010 From: buesching at univention.de (Andreas =?utf-8?q?B=C3=BCsching?=) Date: Wed, 3 Feb 2010 08:36:37 +0100 Subject: start_tls = 2 is ignored with LDAP URIs starting with LDAP:// In-Reply-To: <201001080939.43196.buesching@univention.de> References: <201001080939.43196.buesching@univention.de> Message-ID: <201002030836.41605.buesching@univention.de> Hi, Has anyone an idea? thanx in advance Andreas Am Freitag 08 Januar 2010 09:39:40 schrieb Andreas B?sching: > I've found a strange behaviour of python-ldap when working with TLS > encrypted connections. I'm not sure if this is a problem of the python > bindings or of libldap or in my head ;-) > > In my first scenario I was trying to set up a TLS encrypted connection with > a specific CA certificate that was set in the ldap.conf file (TLS_CACERT). > > >>> import ldap > >>> l = > > ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention. >test:389', > who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred=' >univention', start_tls=2, > tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem') > > >>> l.started_tls > > 0 > > In that case the connection is not encrypted. When I replace LDAP:// with > ldap:// in the URI the connection is encrypted. > > >>> l = > > ldap.ldapobject.SmartLDAPObject(uri='ldap://qamaster.windom2008.univention. >test:389', > who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred=' >univention', start_tls=2, > tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem') > > >>> l.started_tls > > 1 > > It look likes a TLS connection is not set up if the URI starts with LDAP:// > > In the second scenario I've tried to set up a TLS encrypted connection with > a CA certificate that was not set in the ldap.conf file. > > >>> l = > > ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univ >ention.test:389', > who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='u >nivention', start_tls=2, > tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem') > ... > ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed', 'desc': 'Connect error'} > > It seems that the argument tls_cacertfile is ignored, because if I set the > CA certificate file with the set_option function the connection works and > is encrypted. > > ldap.set_option( > ldap.OPT_X_TLS_CACERTFILE, > '/etc/univention/connector/ad/ad_cert_20091221_153053.pem' ) l = > ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univ >ention.test:389', > who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='u >nivention', start_tls=2 ) > > >>> l.started_tls > > 1 > > software versions: > > python 2.4.6 > libldap 2.4.15 > python-ldap 2.3.5 > > Is there any mistake in my reasoning or is this a known behaviour? > > best regards > Andreas -- Andreas B?sching Open Source Software Engineer Univention GmbH Linux for your business Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 Fax : +49 421 22232-99 http://www.univention.de Gesch?ftsf?hrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 **** Besuchen Sie uns auf der KOMCOM NORD in Hannover vom 9.-10.02.2010 in der Eilenriedehalle, Stand H 03 **** -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From michael at stroeder.com Thu Feb 4 20:42:29 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 04 Feb 2010 20:42:29 +0100 Subject: start_tls = 2 is ignored with LDAP URIs starting with LDAP:// In-Reply-To: <201001080939.43196.buesching@univention.de> References: <201001080939.43196.buesching@univention.de> Message-ID: <4B6B2325.7090706@stroeder.com> Andreas, sorry for my late reply. I'm quite busy at the moment. Andreas B?sching wrote: > I've found a strange behaviour of python-ldap when working with TLS encrypted > connections. I'm not sure if this is a problem of the python bindings or of > libldap or in my head ;-) > > In my first scenario I was trying to set up a TLS encrypted connection with a > specific CA certificate that was set in the ldap.conf file (TLS_CACERT). > >>>> import ldap >>>> l = > ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention.test:389', > who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', > start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem') >>>> l.started_tls > 0 > > In that case the connection is not encrypted. When I replace LDAP:// with > ldap:// in the URI the connection is encrypted. Well, that's because of the stupid handling in SmartLDAPObject.__init__(). Line 900 should check the lower-cased uri: if start_tls>0 and uri[:5].lower()=='ldap:': Well, SmartLDAPObject is not well tested nor documented and should probably be removed anyway... > In the second scenario I've tried to set up a TLS encrypted connection with a > CA certificate that was not set in the ldap.conf file. > >>>> l = > ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389', > who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', > start_tls=2, > tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem') > ... > ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed', 'desc': 'Connect error'} Well, tls_cacertfile is simply not used in SmartLDAPObject.__init__(). The reason is that OpenLDAP libs 2.3 were not able to set connection-specific SSL options. It should work with OpenLDAP 2.4 under some circumstances but I never got it working. => please either don't use SmartLDAPObject or contribute fixes for it Personally I'd vote for removing it. Ciao, Michael. From michael at stroeder.com Fri Feb 5 13:34:32 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 05 Feb 2010 13:34:32 +0100 Subject: ldap.ldapobject.SmartLDAPObject removed In-Reply-To: <4B6B2325.7090706@stroeder.com> References: <201001080939.43196.buesching@univention.de> <4B6B2325.7090706@stroeder.com> Message-ID: <4B6C1058.9000704@stroeder.com> Michael Str?der wrote: > Well, SmartLDAPObject is not well tested nor documented and should probably be > removed anyway... > [..] > Well, tls_cacertfile is simply not used in SmartLDAPObject.__init__(). The > reason is that OpenLDAP libs 2.3 were not able to set connection-specific SSL > options. It should work with OpenLDAP 2.4 under some circumstances but I never > got it working. > > => please either don't use SmartLDAPObject or contribute fixes for it > Personally I'd vote for removing it. In CVS HEAD I've removed the untested and undocumented wrapper class ldap.ldapobject.SmartLDAPObject completely. Upcoming release 2.3.11 will not contain it anymore. It never worked robustly like intended and it's not worth the effort to fix it. Ciao, Michael. From michael at stroeder.com Fri Feb 5 13:54:22 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 05 Feb 2010 13:54:22 +0100 Subject: Anyone using LDAPObject.manage_dsa_it()? Message-ID: <4B6C14FE.7000301@stroeder.com> HI! For some time there has been a warning in the docs about LDAPObject.manage_dsa_it() soon vanishing from python-ldap once full support for LDAPv3 controls is implemented. Since we have that for quite some time now this inherently broken method should be removed. Anyone still using it? If yes, then raise your voice now or I'll remove it from upcoming python-ldap 2.3.11. Ciao, Michael. From buesching at univention.de Mon Feb 8 12:05:21 2010 From: buesching at univention.de (Andreas =?iso-8859-1?q?B=FCsching?=) Date: Mon, 8 Feb 2010 12:05:21 +0100 Subject: ldap.ldapobject.SmartLDAPObject removed In-Reply-To: <4B6C1058.9000704@stroeder.com> References: <201001080939.43196.buesching@univention.de> <4B6B2325.7090706@stroeder.com> <4B6C1058.9000704@stroeder.com> Message-ID: <201002081205.26485.buesching@univention.de> Hi Michael, Am Freitag 05 Februar 2010 13:34:32 schrieb Michael Str?der: > Michael Str?der wrote: > > Well, SmartLDAPObject is not well tested nor documented and should > > probably be removed anyway... > > [..] > > Well, tls_cacertfile is simply not used in SmartLDAPObject.__init__(). > > The reason is that OpenLDAP libs 2.3 were not able to set > > connection-specific SSL options. It should work with OpenLDAP 2.4 under > > some circumstances but I never got it working. > > > > => please either don't use SmartLDAPObject or contribute fixes for it > > Personally I'd vote for removing it. > > In CVS HEAD I've removed the untested and undocumented wrapper class > ldap.ldapobject.SmartLDAPObject completely. Upcoming release 2.3.11 will > not contain it anymore. It never worked robustly like intended and it's not > worth the effort to fix it. Thanx for the information. We will replace in SmartLDAPObject in one of our next releases of the software. best regards Andreas -- Andreas B?sching Open Source Software Engineer Univention GmbH Linux for your business Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 Fax : +49 421 22232-99 http://www.univention.de Gesch?ftsf?hrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 **** Besuchen Sie uns auf der KOMCOM NORD in Hannover vom 9.-10.02.2010 in der Eilenriedehalle, Stand H 03 **** -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From michael at stroeder.com Fri Feb 26 09:57:40 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Feb 2010 09:57:40 +0100 Subject: Anyone using LDAPObject.manage_dsa_it()? In-Reply-To: <4B6C14FE.7000301@stroeder.com> References: <4B6C14FE.7000301@stroeder.com> Message-ID: <4B878D04.2060201@stroeder.com> Michael Str?der wrote: > For some time there has been a warning in the docs about > LDAPObject.manage_dsa_it() soon vanishing from python-ldap once full support > for LDAPv3 controls is implemented. Since we have that for quite some time now > this inherently broken method should be removed. > > Anyone still using it? If yes, then raise your voice now or I'll remove it > from upcoming python-ldap 2.3.11. No answer so far. => I removed it in CVS HEAD and will release it like this in 2.3.11. Ciao, Michael. From michael at stroeder.com Fri Feb 26 10:33:38 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Feb 2010 10:33:38 +0100 Subject: ANN: python-ldap-2.3.11 Message-ID: <4B879572.3070900@stroeder.com> Find a new release of python-ldap: http://www.python-ldap.org/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). Ciao, Michael. -- Michael Str?der E-Mail: michael at stroeder.com http://www.stroeder.com From tobias.schmidt.1 at ub.hu-berlin.de Fri Feb 26 13:41:23 2010 From: tobias.schmidt.1 at ub.hu-berlin.de (Tobias Schmidt) Date: Fri, 26 Feb 2010 13:41:23 +0100 Subject: python_ldap 2.3.11 broken on pypi Message-ID: <4B87C173.8070000@ub.hu-berlin.de> Hi, could it be that the latest release of python_ldap (2.3.11) is broken on pypi? It didn't work inside my buildout and I could not open the archive after downloading it manually. Error message: gzip: stdin: unexpected end of file tar: Child returned status 1 tar: Error exit delayed from previous errors Best regards Tobias From michael at stroeder.com Fri Feb 26 15:27:52 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 26 Feb 2010 15:27:52 +0100 Subject: python_ldap 2.3.11 broken on pypi In-Reply-To: <4B87C173.8070000@ub.hu-berlin.de> References: <4B87C173.8070000@ub.hu-berlin.de> Message-ID: <4B87DA68.6050209@stroeder.com> Tobias Schmidt wrote: > could it be that the latest release of python_ldap (2.3.11) is broken on > pypi? It didn't work inside my buildout and I could not open the archive > after downloading it manually. > > Error message: > > gzip: stdin: unexpected end of file > tar: Child returned status 1 > tar: Error exit delayed from previous errors Should be fixed now. Thanks for your quick report. Ciao, Michael. From michael at stroeder.com Sat Feb 27 11:18:53 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Sat, 27 Feb 2010 11:18:53 +0100 Subject: Docs updated for 2.3.11 Message-ID: <4B88F18D.3060606@stroeder.com> HI! Slightly updated python-ldap docs are now available on: http://www.python-ldap.org/docs.shtml Ciao, Michael. From michael at stroeder.com Tue Mar 2 11:59:36 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 02 Mar 2010 11:59:36 +0100 Subject: Question: Mac OS 10.6 and Python 2.6 In-Reply-To: <20100302104613.1dde534b@robbenbabyle.tk-webart.de> References: <20100302104613.1dde534b@robbenbabyle.tk-webart.de> Message-ID: <4B8CEF98.1000106@stroeder.com> Torsten Kurbad wrote: > Exactly What kind of problem are you encountering while trying to > build on 10.6? Note that recent release 2.3.11 contains fixes for backward-compability to build with OpenLDAP 2.3 libs. You probably need that when building for Mac OS X. Ciao, Michael. From jtcody at gmail.com Tue Mar 2 00:10:21 2010 From: jtcody at gmail.com (John Cody) Date: Mon, 1 Mar 2010 17:10:21 -0600 Subject: Question: Mac OS 10.6 and Python 2.6 Message-ID: I was wondering if anyone has been successful building packages for python-ldap for Mac OS X 10.6 and Python 2.6. Thanks, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From python-ldap at tk-webart.de Tue Mar 2 10:46:13 2010 From: python-ldap at tk-webart.de (Torsten Kurbad) Date: Tue, 2 Mar 2010 10:46:13 +0100 Subject: Question: Mac OS 10.6 and Python 2.6 In-Reply-To: References: Message-ID: <20100302104613.1dde534b@robbenbabyle.tk-webart.de> Hi John, > I was wondering if anyone has been successful building > packages for python-ldap for Mac OS X 10.6 and Python 2.6. a bit outdated, but you might have a look at http://svn.iwm-kmrc.de/download/distribution/contrib/python_ldap-2.3.9-py2.6-macosx-10.3-fat.egg This .egg was built on OS X 10.5 and should work on any version (and platform) from 10.3 through 10.6. Exactly What kind of problem are you encountering while trying to build on 10.6? Did you install the latest XCode? Did you change the include- and library-paths in python-ldap's setup.cfg according to your setup? Best regards, Torsten -- The scene is dull. Tell him to put more life into his dying. -Samuel Goldwyn From jtcody at gmail.com Tue Mar 2 18:41:14 2010 From: jtcody at gmail.com (John Cody) Date: Tue, 2 Mar 2010 11:41:14 -0600 Subject: Question: Mac OS 10.6 and Python 2.6 Message-ID: I've got the 2.3.11 release of python-ldap, latest version of XCode, and Python 2.6.2 installed. I run: $ sudo python setup.py build and I get the following output. extra_compile_args: extra_objects: include_dirs: /usr/include /usr/include/sasl library_dirs: /usr/lib libs: ldap_r lber sasl2 ssl crypto running build running build_py file Lib/ldap.py (for module ldap) not found file Lib/ldap/schema.py (for module ldap.schema) not found creating build/lib.macosx-10.3-fat-2.6 copying Lib/ldapurl.py -> build/lib.macosx-10.3-fat-2.6 copying Lib/ldif.py -> build/lib.macosx-10.3-fat-2.6 copying Lib/dsml.py -> build/lib.macosx-10.3-fat-2.6 creating build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/__init__.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/async.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/controls.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/cidict.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/dn.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/filter.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/functions.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/ldapobject.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/modlist.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/resiter.py -> build/lib.macosx-10.3-fat-2.6/ldap copying Lib/ldap/sasl.py -> build/lib.macosx-10.3-fat-2.6/ldap creating build/lib.macosx-10.3-fat-2.6/ldap/schema copying Lib/ldap/schema/__init__.py -> build/lib.macosx-10.3-fat-2.6/ldap/schema copying Lib/ldap/schema/models.py -> build/lib.macosx-10.3-fat-2.6/ldap/schema copying Lib/ldap/schema/subentry.py -> build/lib.macosx-10.3-fat-2.6/ldap/schema copying Lib/ldap/schema/tokenizer.py -> build/lib.macosx-10.3-fat-2.6/ldap/schema file Lib/ldap.py (for module ldap) not found file Lib/ldap/schema.py (for module ldap.schema) not found running egg_info writing requirements to Lib/python_ldap.egg-info/requires.txt writing Lib/python_ldap.egg-info/PKG-INFO writing top-level names to Lib/python_ldap.egg-info/top_level.txt writing dependency_links to Lib/python_ldap.egg-info/dependency_links.txt file Lib/ldap.py (for module ldap) not found file Lib/ldap/schema.py (for module ldap.schema) not found reading manifest file 'Lib/python_ldap.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no files found matching 'Makefile' warning: no files found matching 'Modules/LICENSE' writing manifest file 'Lib/python_ldap.egg-info/SOURCES.txt' running build_ext building '_ldap' extension creating build/temp.macosx-10.3-fat-2.6 creating build/temp.macosx-10.3-fat-2.6/Modules gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -DHAVE_LIBLDAP_R -DHAVE_SASL -DHAVE_TLS -DLDAPMODULE_VERSION=2.3.11 -IModules -I/usr/include -I/usr/include/sasl -I/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c Modules/LDAPObject.c -o build/temp.macosx-10.3-fat-2.6/Modules/LDAPObject.o In file included from /usr/include/math.h:26, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyport.h:235, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:58, from Modules/common.h:10, from Modules/LDAPObject.c:4: /usr/include/architecture/ppc/math.h:666: warning: conflicting types for built-in function ?scalb? In file included from /usr/include/stdarg.h:4, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/unicodeobject.h:4, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:85, from Modules/common.h:10, from Modules/LDAPObject.c:4: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory In file included from /usr/include/architecture/i386/math.h:626, from /usr/include/math.h:28, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyport.h:235, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:58, from Modules/common.h:10, from Modules/LDAPObject.c:4: /usr/include/AvailabilityMacros.h:108:14: warning: #warning Building for Intel with Mac OS X Deployment Target < 10.4 is invalid. In file included from /usr/include/stdarg.h:4, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/unicodeobject.h:4, from /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:85, from Modules/common.h:10, from Modules/LDAPObject.c:4: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory lipo: can't figure out the architecture type of: /var/tmp//cc5IXFBh.out error: command 'gcc' failed with exit status 1 Any help you can give me would be great. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgollmer at tcnetworks.com Thu Mar 4 20:17:16 2010 From: bgollmer at tcnetworks.com (Ben Gollmer) Date: Thu, 4 Mar 2010 13:17:16 -0600 Subject: Question: Mac OS 10.6 and Python 2.6 In-Reply-To: References: Message-ID: <699C5627-D060-46FE-9B7A-4FDFEE0E4778@tcnetworks.com> On Mar 2, 2010, at 11:41 AM, John Cody wrote: > I've got the 2.3.11 release of python-ldap, latest version of XCode, and Python 2.6.2 installed. > > I run: $ sudo python setup.py build > and I get the following output. > /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory This is a known problem when using a non-Apple supplied Python install: http://bugs.python.org/issue6957 The bug has more details, but the basic workaround is to install the 10.4 SDK (it's an optional package when installing Xcode) and using GCC 4.0 instead of the default 4.2. -- Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2429 bytes Desc: not available URL: From dave.x.kirby at gmail.com Mon Jan 18 15:18:56 2010 From: dave.x.kirby at gmail.com (Dave Kirby) Date: Mon, 18 Jan 2010 14:18:56 +0000 Subject: =?UTF-8?Q?Re=3A_How_get_get_more_search_results_than_the_server?= =?UTF-8?Q?=E2=80=99s_sizelimit=3F?= In-Reply-To: <4B54596B.3090708@stroeder.com> References: <596657641001170824r7cb4846fv604c02fecbb35ea3@mail.gmail.com> <4B54596B.3090708@stroeder.com> Message-ID: <596657641001180618w515ccee7o5078ee5e720b20a5@mail.gmail.com> 2010/1/18 Michael Str?der : Dave Kirby wrote: [snip] >> but according to the python-ldap >> docs controls are not supported for the search functions even though >> they are for other functions. > > Which version of python-ldap and docs are you referring to? > I was referring to the docs online at http://www.python-ldap.org/doc/html/ldap.html#ldapobject-class and the latest version in CVS at http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Doc/ldap.rst?revision=1.11&view=markup. They both say under the LDAPPObject.search_xxx functions: * serverctrls* not implemented yet. * clientctrls* not implemented yet. So I assumed that controls were not implemented for the search functions. I guess the docs need updating. Thanks for the response - I now have enough information to do what I want. Regards, Dave From michael at stroeder.com Thu Mar 4 22:40:39 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 04 Mar 2010 22:40:39 +0100 Subject: Contributing Mac OS X packages to PyPI In-Reply-To: References: Message-ID: <4B9028D7.3010700@stroeder.com> Ben Gollmer wrote: > I have built universal binary packages for Python-LDAP 2.3.10 on both > Mac OS X 10.5 (Python 2.5) and 10.6 (Python 2.6). Is it possible to add > these to the PyPI page, to go along with the Windows installers? They > can be very useful for users that don't have Xcode / gcc installed. Sorry, for answering that late. Do you have a PyPI account? I'd appreciate to see the builds there. Ciao, Michael. From bgollmer at tcnetworks.com Fri Mar 5 01:15:42 2010 From: bgollmer at tcnetworks.com (Ben Gollmer) Date: Thu, 4 Mar 2010 18:15:42 -0600 Subject: Contributing Mac OS X packages to PyPI In-Reply-To: <4B9028D7.3010700@stroeder.com> References: <4B9028D7.3010700@stroeder.com> Message-ID: On Mar 4, 2010, at 3:40 PM, Michael Str?der wrote: > Ben Gollmer wrote: >> I have built universal binary packages for Python-LDAP 2.3.10 on both >> Mac OS X 10.5 (Python 2.5) and 10.6 (Python 2.6). Is it possible to add >> these to the PyPI page, to go along with the Windows installers? They >> can be very useful for users that don't have Xcode / gcc installed. > > Sorry, for answering that late. Do you have a PyPI account? I'd appreciate to > see the builds there. I do - I'm jatoben. I'd be happy to either upload the builds directly, or send them to you to do so. -- Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2429 bytes Desc: not available URL: From requate at univention.de Fri Mar 12 13:57:13 2010 From: requate at univention.de (Arvid Requate) Date: Fri, 12 Mar 2010 13:57:13 +0100 Subject: ldap.DECODING_ERROR in ldap.dn.str2dn with python2.4 on amd64 Message-ID: <201003121357.13779.requate@univention.de> Hello, we had a problem with ldap.dn.str2dn showing instable behavior and throwing ldap.DECODING_ERROR in python2.4 Debian Lenny (amd64). It seems that using PyArg_ParseTuple with format string "z#" and saving the length of the string directly into the berval member bv_len does not store a correct value, which in turn causes the problem in ldap_bv2dn. It seems that str2dn is the only location in python-ldap (2.3.5) where this technique is used, and the problems seems to affect only amd64 and might be caused by a leak in the PyArg_ParseTuple routine of python2.4. The attached patch solved the problem for us. Cheers, Arvid -- Arvid Requate Open Source Software Engineer Univention GmbH Linux for your business Mary-Somerville-Str.1 28359 Bremen Tel. : +49 421 22232-0 Fax : +49 421 22232-99 requate at univention.de http://www.univention.de Gesch?ftsf?hrer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876 -------------- next part -------------- A non-text attachment was scrubbed... Name: str2dn_DECODING_ERROR.patch Type: text/x-diff Size: 1619 bytes Desc: not available URL: From michael at stroeder.com Fri Mar 12 16:15:59 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 12 Mar 2010 16:15:59 +0100 Subject: ldap.DECODING_ERROR in ldap.dn.str2dn with python2.4 on amd64 In-Reply-To: <201003121357.13779.requate@univention.de> References: <201003121357.13779.requate@univention.de> Message-ID: <4B9A5AAF.5040803@stroeder.com> Arvid Requate wrote: > we had a problem with ldap.dn.str2dn showing instable behavior and throwing > ldap.DECODING_ERROR in python2.4 Debian Lenny (amd64). > It seems that using PyArg_ParseTuple with format string "z#" and saving the > length of the string directly into the berval member bv_len does not store a > correct value, which in turn causes the problem in ldap_bv2dn. It seems that > str2dn is the only location in python-ldap (2.3.5) where this technique is > used, and the problems seems to affect only amd64 and might be caused by a > leak in the PyArg_ParseTuple routine of python2.4. I think it is fixed since release 2.3.7. You should encourage the Debian maintainer to provide an updated package. See CVS: http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Modules/functions.c?r1=1.21&r2=1.22 Revision 1.22 Tue Apr 7 16:45:57 2009 UTC (11 months ago) by stroeder Branch: MAIN CVS Tags: PYLDAP_REL_2_3_7 Fixed functions.c not to raise ldap.ENCODING_ERROR in function l_ldap_str2dn() on 64-bit systems (see SF#2725356) Ciao, Michael. From michael at stroeder.com Fri Mar 12 16:17:25 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Fri, 12 Mar 2010 16:17:25 +0100 Subject: edirectory question In-Reply-To: References: <4B99C238.9090502@dewhirst.com.au> Message-ID: <4B9A5B05.6080707@stroeder.com> Yeargan, Yancey wrote: > > Your question is really about Novell eDirectory, not the Python LDAP module; That's definitely related to Novell eDirectory. I vaguely remember that some eDirectory allowed searching with an empty search root. Not sure but worth a short test. Ciao, Michael. From miked at dewhirst.com.au Fri Mar 12 05:25:28 2010 From: miked at dewhirst.com.au (Mike Dewhirst) Date: Fri, 12 Mar 2010 15:25:28 +1100 Subject: edirectory question Message-ID: <4B99C238.9090502@dewhirst.com.au> Hi all - I couldn't find my answer in your archives so I joined the list. Thanks for being here. Background I'm new to most of this but I managed to configure (for testing) a local Novell eDirectory 8.7 LDAP service to respond to a remote request for authentication. The client is a php website which requires auth and which was built by someone else. I provided the bind user and I can create my own local eDirectory users and successfully log them in to the website. The problem The website owner has a large tree of Novell servers whereas my test setup is a single server. We now wish to point the php website at the large tree so that vast numbers of employees can login using their Novell credentials. The problem is that the credentials are spread over a number of org/org units like this ... maintree central (o) binduser (cn) suburbs (o) footscray (ou) users (cn)s glenroy (ou) moreusers (cn) bayside (ou) ... and when I try to configure my own eDirectory in a similar structure, the binduser cannot find credentials outside its own container. I can solve the problem by creating an alias object named identically for the user in the other container but this is totally unwieldy from the viewpoint of the sheer numbers of users. It would be awful to do that if there was another way. Question Is there another way? Thanks Mike From yancey at unt.edu Fri Mar 12 06:32:46 2010 From: yancey at unt.edu (Yeargan, Yancey) Date: Thu, 11 Mar 2010 23:32:46 -0600 Subject: edirectory question In-Reply-To: <4B99C238.9090502@dewhirst.com.au> References: <4B99C238.9090502@dewhirst.com.au> Message-ID: Your question is really about Novell eDirectory, not the Python LDAP module; so I will provide a brief answer here and you may contact me directly for more eDirectory information. However, I would first make sure that the LDAP search base parameter is set to either "o=central" or "o=suburbs". To begin, you will not need an alias. The default eDirectory LDAP configuration allows anonymous LDAP binds, so a 'bind user' may not be strictly necessary either. If you do authenticate in order to perform a search for the user's account, eDirectory also defaults to every user being able to browse the structure of the tree. It should be possible to find a user account by the CN value (or 'sn' or 'givenName') simply using the default configuration and security permissions. If your search involves another attribute that is not publicly visible, then you may need to grant additional directory permissions to the 'bind user'. That's all I will say here. Feel free to contact me directly for more information about Novell eDirectory. Yancey On Mar 11, 2010, at 10:25 PM, Mike Dewhirst wrote: > Hi all - I couldn't find my answer in your archives so I joined the > list. Thanks for being here. > > Background > > I'm new to most of this but I managed to configure (for testing) a local > Novell eDirectory 8.7 LDAP service to respond to a remote request for > authentication. The client is a php website which requires auth and > which was built by someone else. I provided the bind user and I can > create my own local eDirectory users and successfully log them in to the > website. > > The problem > > The website owner has a large tree of Novell servers whereas my test > setup is a single server. We now wish to point the php website at the > large tree so that vast numbers of employees can login using their > Novell credentials. The problem is that the credentials are spread over > a number of org/org units like this ... > > maintree > central (o) > binduser (cn) > suburbs (o) > footscray (ou) > users (cn)s > glenroy (ou) > moreusers (cn) > bayside (ou) > > ... and when I try to configure my own eDirectory in a similar > structure, the binduser cannot find credentials outside its own container. > > I can solve the problem by creating an alias object named identically > for the user in the other container but this is totally unwieldy from > the viewpoint of the sheer numbers of users. It would be awful to do > that if there was another way. > > Question > > Is there another way? > > Thanks > > Mike > > From jtcody at gmail.com Fri Mar 5 14:52:57 2010 From: jtcody at gmail.com (John Cody) Date: Fri, 5 Mar 2010 07:52:57 -0600 Subject: Question: Mac OS 10.6 and Python 2.6 In-Reply-To: <699C5627-D060-46FE-9B7A-4FDFEE0E4778@tcnetworks.com> References: <699C5627-D060-46FE-9B7A-4FDFEE0E4778@tcnetworks.com> Message-ID: > > > > This is a known problem when using a non-Apple supplied Python install: > > http://bugs.python.org/issue6957 > > The bug has more details, but the basic workaround is to install the 10.4 > SDK (it's an optional package when installing Xcode) and using GCC 4.0 > instead of the default 4.2. > > -- > Ben > > I had tried downloading the 10.4 SDK and setting GCC to 4.0, since that is what worked for building other python packages, but it didn't seem to work for this. In the setup.cfg file I put in this parameter: extra_compile_args = -isysroot /Developer/SDKs/MacOSX10.6.sdk and that seemed to do the trick. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From miked at dewhirst.com.au Sat Mar 13 00:02:08 2010 From: miked at dewhirst.com.au (Mike Dewhirst) Date: Sat, 13 Mar 2010 10:02:08 +1100 Subject: edirectory question In-Reply-To: <4B9A5B05.6080707@stroeder.com> References: <4B99C238.9090502@dewhirst.com.au> <4B9A5B05.6080707@stroeder.com> Message-ID: <4B9AC7F0.3030303@dewhirst.com.au> Thanks all - much appreciated Mike On 13/03/2010 2:17am, Michael Str?der wrote: > Yeargan, Yancey wrote: >> >> Your question is really about Novell eDirectory, not the Python LDAP module; > > That's definitely related to Novell eDirectory. > > I vaguely remember that some eDirectory allowed searching with an empty search > root. Not sure but worth a short test. > > Ciao, Michael. > > From patatetom at gmail.com Wed Mar 17 11:22:34 2010 From: patatetom at gmail.com (Pascal) Date: Wed, 17 Mar 2010 11:22:34 +0100 Subject: python-ldap and kerberos Message-ID: Hi everybody, I'm on an M$AD and I'm trying python-ldap from a LINUX host with Python 2.6.4. All is ok, I can search_s after a bind_s. The problem is the plain text password (wireshark)... LDAPs is not not avaible and I can't play with certificats... Kerberos is nativelly available on M$AD and is ok on the LINUX host (heimdal ~ kinit ok and klist ok)... I search (Google) and try for ldap.sasl.gssapi but it is always ko :-( Can anybody help me ? Thanks From michael at stroeder.com Thu Mar 25 20:27:05 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 25 Mar 2010 20:27:05 +0100 Subject: python-ldap and kerberos In-Reply-To: References: Message-ID: <4BABB909.9050501@stroeder.com> Pascal, it seems you're not described to the python-ldap-dev list so your posting was delayed in the list maintainer's queue... Pascal wrote: > I'm on an M$AD and I'm trying python-ldap from a LINUX host with Python 2.6.4. > All is ok, I can search_s after a bind_s. > The problem is the plain text password (wireshark)... > LDAPs is not not avaible and I can't play with certificats... > Kerberos is nativelly available on M$AD and is ok on the LINUX host > (heimdal ~ kinit ok and klist ok)... > I search (Google) and try for ldap.sasl.gssapi but it is always ko :-( > Can anybody help me ? Well, it simply works for me. If klist shows a service ticket everything should be fine. Most times issues are because of mis-configuration (principal names, enc-types etc.). Ciao, Michael. From alberto at pexego.es Mon Mar 29 20:03:45 2010 From: alberto at pexego.es (Alberto Luengo Cabanillas (Pexego)) Date: Mon, 29 Mar 2010 20:03:45 +0200 Subject: [SPAM] Re: CONNECTING FROM A SERVERS POOL In-Reply-To: References: <4BB0BC06.9010205@pexego.es> Message-ID: <4BB0EB81.4020608@pexego.es> Yeargan, Yancey wrote: > > I think it is as simple as using multiple URL values separated with > spaces. For example: > > ldap.initalize("url1 url2 url3") > > The underlying LDAP code will automatically try each URL until one > succeeds or they all fail. > > Yancey > Hi Yeargan. Thanks for the quick reply but that's not exactly the problem we're facing. The point that if you initialize url1, url2 and url3, with url1 down, the followup queries will be against url2. That's a correct behaviour, but if while you're keeping up that connection, this url2 server goes down, you'll get an exception, instead of trying to reconnect to next available server (url1 or url3), supposing, of course, that they have an equivalent structure. So, when this happens, we're initializing another LDAPObject with remaining URIs this way: new_object = ldap.functions._ldap_function_call(_ldap.initialize,string_uris) self = new_object (or self._l = new_object?) , but this still fails, any suggestion? Greetings. > > On Mar 29, 2010, at 9:41 AM, Alberto Luengo Cabanillas (Pexego) wrote: > >> Hi all! Me and a workmate are currently working in an approach of >> connecting to different LDAP servers (each one is a replica of >> another) because of fault tolerancy purposes. >> So, first thing we did was modifying the *__init__* method of >> SimpleLDAPObject class (ldapobject.py file) adding a new attribute >> "pool" which contains the list of servers passed as param in >> *initialize* method as a string. So, attribute .*_l *changes to: >> self._l = >> ldap.functions._ldap_function_call(_ldap.initialize,self._pool[0]) >> >> Then, in *_ldap_call *we introduced a /while/ loop surrounding all >> code with a boolean condition set to False. When *"func"* call fails >> raising a "SERVER_DOWN" exception, we remove URI from pool and create >> a new ReconnectLDAPObject instance with self._l attribute pointing to >> next LDAP URI in pool. >> >> The problem we're actually facing is that when *func *calls raises a >> SERVER_DOWN exception (with, for example, a *search_s* operation) the >> code behaviour is correct when URI is wrong, but when LDAP URI is >> right the func calls stills raises an exception...Is this because of >> what is explained in the beginning of ReconnectLDAPObject class (that >> synchronous methods like search_s() automatically tries to reconnect >> when LDAP server is down)?. >> >> Are we pointing in the right direction? >> >> Thanks a lot in advance. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yancey at unt.edu Mon Mar 29 20:19:15 2010 From: yancey at unt.edu (Yeargan, Yancey) Date: Mon, 29 Mar 2010 13:19:15 -0500 Subject: [SPAM] Re: CONNECTING FROM A SERVERS POOL In-Reply-To: <4BB0EB81.4020608@pexego.es> References: <4BB0BC06.9010205@pexego.es> <4BB0EB81.4020608@pexego.es> Message-ID: <684F4483-5953-44A9-8C2A-0F7E99E40672@unt.edu> Hmm.. I do not know enough about the SimpleLDAPObject code. Perhaps a python-ldap developer can provide more information (but I think they will recommend that you not use SimpleLDAPObject). Assigning to self may not work as you expect. I do not think you will be able to replace the SimpleLDAPObject inside an exception handler. Creating a new LDAP connection using the same URIs as the original is valid logic, but your code will need to keep track of the state of pending LDAP requests and whether they have completed successfully, perhaps storing the requests in some sort of local database. The LDAP API itself does not provide for this sort of complex behavior. The level of redundancy you seek is not easy. Yancey On Mar 29, 2010, at 1:03 PM, Alberto Luengo Cabanillas (Pexego) wrote: Yeargan, Yancey wrote: I think it is as simple as using multiple URL values separated with spaces. For example: ldap.initalize("url1 url2 url3") The underlying LDAP code will automatically try each URL until one succeeds or they all fail. Yancey Hi Yeargan. Thanks for the quick reply but that's not exactly the problem we're facing. The point that if you initialize url1, url2 and url3, with url1 down, the followup queries will be against url2. That's a correct behaviour, but if while you're keeping up that connection, this url2 server goes down, you'll get an exception, instead of trying to reconnect to next available server (url1 or url3), supposing, of course, that they have an equivalent structure. So, when this happens, we're initializing another LDAPObject with remaining URIs this way: new_object = ldap.functions._ldap_function_call(_ldap.initialize,string_uris) self = new_object (or self._l = new_object?) , but this still fails, any suggestion? Greetings. On Mar 29, 2010, at 9:41 AM, Alberto Luengo Cabanillas (Pexego) wrote: Hi all! Me and a workmate are currently working in an approach of connecting to different LDAP servers (each one is a replica of another) because of fault tolerancy purposes. So, first thing we did was modifying the __init__ method of SimpleLDAPObject class (ldapobject.py file) adding a new attribute "pool" which contains the list of servers passed as param in initialize method as a string. So, attribute ._l changes to: self._l = ldap.functions._ldap_function_call(_ldap.initialize,self._pool[0]) Then, in _ldap_call we introduced a while loop surrounding all code with a boolean condition set to False. When "func" call fails raising a "SERVER_DOWN" exception, we remove URI from pool and create a new ReconnectLDAPObject instance with self._l attribute pointing to next LDAP URI in pool. The problem we're actually facing is that when func calls raises a SERVER_DOWN exception (with, for example, a search_s operation) the code behaviour is correct when URI is wrong, but when LDAP URI is right the func calls stills raises an exception...Is this because of what is explained in the beginning of ReconnectLDAPObject class (that synchronous methods like search_s() automatically tries to reconnect when LDAP server is down)?. Are we pointing in the right direction? Thanks a lot in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Mon Mar 29 21:45:07 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Mar 2010 21:45:07 +0200 Subject: [SPAM] Re: CONNECTING FROM A SERVERS POOL In-Reply-To: <684F4483-5953-44A9-8C2A-0F7E99E40672@unt.edu> References: <4BB0BC06.9010205@pexego.es> <4BB0EB81.4020608@pexego.es> <684F4483-5953-44A9-8C2A-0F7E99E40672@unt.edu> Message-ID: <4BB10343.3050708@stroeder.com> HI! For simple synchronous operations there is ldap.ldapobject.ReconnectLDAPObject which does automatic re-connect when ldap.SERVER_DOWN is raised within a *operation_s() method (synchronous operations). You could use that as a starting point to implement connecting to another server in a pool with a failover strategy which fits your needs (sometimes depends on network topology). BTW: You don't have to call ldap.functions._ldap_function_call() yourself. Ciao, Michael. Yeargan, Yancey wrote: > > Hmm.. I do not know enough about the SimpleLDAPObject code. Perhaps a > python-ldap developer can provide more information (but I think they > will recommend that you not use SimpleLDAPObject). Assigning to self may > not work as you expect. I do not think you will be able to replace > the SimpleLDAPObject inside an exception handler. > > Creating a new LDAP connection using the same URIs as the original is > valid logic, but your code will need to keep track of the state of > pending LDAP requests and whether they have completed successfully, > perhaps storing the requests in some sort of local database. The LDAP > API itself does not provide for this sort of complex behavior. The level > of redundancy you seek is not easy. > > Yancey > > > On Mar 29, 2010, at 1:03 PM, Alberto Luengo Cabanillas (Pexego) wrote: > >> Yeargan, Yancey wrote: >>> >>> I think it is as simple as using multiple URL values separated with >>> spaces. For example: >>> >>> ldap.initalize("url1 url2 url3") >>> >>> The underlying LDAP code will automatically try each URL until one >>> succeeds or they all fail. >>> >>> Yancey >>> >> Hi Yeargan. Thanks for the quick reply but that's not exactly the >> problem we're facing. The point that if you initialize url1, url2 and >> url3, with url1 down, the followup queries will be against url2. >> That's a correct behaviour, but if while you're keeping up that >> connection, this url2 server goes down, you'll get an exception, >> instead of trying to reconnect to next available server (url1 or >> url3), supposing, of course, that they have an equivalent structure. >> So, when this happens, we're initializing another LDAPObject with >> remaining URIs this way: >> >> new_object = >> ldap.functions._ldap_function_call(_ldap.initialize,string_uris) >> >> self = new_object (or self._l = new_object?) >> >> , but this still fails, any suggestion? >> >> Greetings. >> >>> >>> On Mar 29, 2010, at 9:41 AM, Alberto Luengo Cabanillas (Pexego) wrote: >>> >>>> Hi all! Me and a workmate are currently working in an approach of >>>> connecting to different LDAP servers (each one is a replica of >>>> another) because of fault tolerancy purposes. >>>> So, first thing we did was modifying the *__init__* method of >>>> SimpleLDAPObject class (ldapobject.py file) adding a new attribute >>>> "pool" which contains the list of servers passed as param in >>>> *initialize* method as a string. So, attribute .*_l *changes to: >>>> self._l = >>>> ldap.functions._ldap_function_call(_ldap.initialize,self._pool[0]) >>>> >>>> Then, in *_ldap_call *we introduced a /while/ loop surrounding all >>>> code with a boolean condition set to False. When *"func"* call fails >>>> raising a "SERVER_DOWN" exception, we remove URI from pool and >>>> create a new ReconnectLDAPObject instance with self._l attribute >>>> pointing to next LDAP URI in pool. >>>> >>>> The problem we're actually facing is that when *func *calls raises a >>>> SERVER_DOWN exception (with, for example, a *search_s* operation) >>>> the code behaviour is correct when URI is wrong, but when LDAP URI >>>> is right the func calls stills raises an exception...Is this because >>>> of what is explained in the beginning of ReconnectLDAPObject class >>>> (that synchronous methods like search_s() automatically tries to >>>> reconnect when LDAP server is down)?. >>>> >>>> Are we pointing in the right direction? >>>> >>>> Thanks a lot in advance. >>>> >>> >> > > > > From jwm at horde.net Tue Mar 23 19:11:13 2010 From: jwm at horde.net (John Morrissey) Date: Tue, 23 Mar 2010 14:11:13 -0400 Subject: ldif.py won't parse with 'python -tt' Message-ID: <20100323181113.GA23872@boost.horde.net> ldif.py won't parse with the python option '-tt', which enforces consistent whitespace. It's a simple fix of replacing the handful of tabs with spaces. john --- ldif.py.orig 2010-03-23 13:50:19.000000000 -0400 +++ ldif.py 2010-03-23 13:50:43.000000000 -0400 @@ -355,20 +355,20 @@ if attr_type=='dn': # attr type and value pair was DN of LDIF record if dn!=None: - raise ValueError, 'Two lines starting with dn: in one record.' + raise ValueError, 'Two lines starting with dn: in one record.' if not is_dn(attr_value): - raise ValueError, 'No valid string-representation of distinguished name %s.' % (repr(attr_value)) + raise ValueError, 'No valid string-representation of distinguished name %s.' % (repr(attr_value)) dn = attr_value elif attr_type=='version' and dn is None: version = 1 elif attr_type=='changetype': # attr type and value pair was DN of LDIF record if dn is None: - raise ValueError, 'Read changetype: before getting valid dn: line.' + raise ValueError, 'Read changetype: before getting valid dn: line.' if changetype!=None: - raise ValueError, 'Two lines starting with changetype: in one record.' + raise ValueError, 'Two lines starting with changetype: in one record.' if not valid_changetype_dict.has_key(attr_value): - raise ValueError, 'changetype value %s is invalid.' % (repr(attr_value)) + raise ValueError, 'changetype value %s is invalid.' % (repr(attr_value)) changetype = attr_value elif attr_value!=None and \ not self._ignored_attr_types.has_key(attr_type.lower()): -- John Morrissey _o /\ ---- __o jwm at horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__ From michael at stroeder.com Mon Mar 29 22:06:27 2010 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 29 Mar 2010 22:06:27 +0200 Subject: ldif.py won't parse with 'python -tt' In-Reply-To: <20100323181113.GA23872@boost.horde.net> References: <20100323181113.GA23872@boost.horde.net> Message-ID: <4BB10843.5070001@stroeder.com> John Morrissey wrote: > ldif.py won't parse with the python option '-tt', which enforces consistent > whitespace. It's a simple fix of replacing the handful of tabs with spaces. Thanks for reporting that. Should be fixed in HEAD now. Ciao, Michael.