python-ldap-dev — discussion among developers

Re: ldap.open() SSL patch

[<ygo...@dc...>]

Michael Ströder <mi...@st...>:

> Yes, you're right. I would accept such a patch. ;-)
>
> At least it's documented:
>
> http://www.python-ldap.org/doc/html/ldap.html#ldap.open

I was using ldap.open because there are many code samples where it's  
still used, in the tubes.

The new patch is attached. I hope to contribute with bigger patches in  
future. :)

Thank you for the attention.

-- 
Ygor Mutti (http://icaju.com - @Mamutti)

Re: ldap.open() SSL patch

[Michael S. <mi...@st...>]

ygo...@dc... wrote:
> Michael Ströder <mi...@st...>:
> 
>> Using ldap.open() is deprecated for quite a while now. python-ldap
>> applications still using this function should be fixed.
> 
> In this case, I think ldap.open() must raise a DeprecationWarning. Don't
> you?

Yes, you're right. I would accept such a patch. ;-)

At least it's documented:

http://www.python-ldap.org/doc/html/ldap.html#ldap.open

Ciao, Michael.

Re: ldap.open() SSL patch

[<ygo...@dc...>]

Michael Ströder <mi...@st...>:

> Using ldap.open() is deprecated for quite a while now. python-ldap
> applications still using this function should be fixed.

In this case, I think ldap.open() must raise a DeprecationWarning. Don't you?

-- 
Ygor Mutti (http://icaju.com - @Mamutti)

Re: ldap.open() SSL patch

[Michael S. <mi...@st...>]

ygo...@dc... wrote:
> I'm a member of GrudeSL (Free Software Development Group) at UFBA  
> (Federal University of Bahia). We were trying to integrate our new  
> Django site authentication with the existing LDAP server, so we ran  
> for python-ldap and I can say it does its job very well (thank you  
> very much! :D).
> 
> But, we are unable to connect using ldap.open() because our server use  
> the non-standardized LDAP over SSL scheme "ldaps", along with LDAPv3.  
> Although it worked when we used ldap.initialize(). So I wrote a patch  
> [1] that fix this tiny little issue, while mantaining backward  
> compatibility.

Using ldap.open() is deprecated for quite a while now. python-ldap
applications still using this function should be fixed.

Frankly I fail to see the benefit of avoiding the use of ldap.initialize(). In
both cases you have to change the application (Django in your case) to make
proper use of either ldap.open(...,ssl=True) or
ldap.initialize('ldaps://...'). In the first case it won't work with unpatched
python-ldap.
=> I reject this patch.

Maybe I've overlooked something though.

(Hopefully this does not discourage to submit patches in the future though.)

> [1] - http://pastebin.com/HxtgRAzg

Feel free to submit patches as attachments to the mailing list next time.
Since then they get properly archived.

Ciao, Michael.

ldap.open() SSL patch

[<ygo...@dc...>]

Hi,

I'm a member of GrudeSL (Free Software Development Group) at UFBA  
(Federal University of Bahia). We were trying to integrate our new  
Django site authentication with the existing LDAP server, so we ran  
for python-ldap and I can say it does its job very well (thank you  
very much! :D).

But, we are unable to connect using ldap.open() because our server use  
the non-standardized LDAP over SSL scheme "ldaps", along with LDAPv3.  
Although it worked when we used ldap.initialize(). So I wrote a patch  
[1] that fix this tiny little issue, while mantaining backward  
compatibility.

I hope you find it useful.

[1] - http://pastebin.com/HxtgRAzg

Best regards,

-- 
Ygor Mutti (http://icaju.com - @Mamutti)

Re: ldif.py won't parse with 'python -tt'

[Michael S. <mi...@st...>]

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.

Re: [SPAM] Re: CONNECTING FROM A SERVERS POOL

[Michael S. <mi...@st...>]

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.
>>>> <ATT00001..c><ATT00002..c>
>>>
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> 
> 
> 
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


-- 
Michael Ströder                 Klauprechtstr. 11
Dipl.-Inform.                   D-76137 Karlsruhe, Germany
Tel.: +49 721 8304316           Mobil: +49 170 2391920
E-Mail: mi...@st...    http://www.stroeder.com

Re: [SPAM] Re: CONNECTING FROM A SERVERS POOL

[Yeargan, Y. <ya...@un...>]

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.
<ATT00001..c><ATT00002..c>

[SPAM] Re: CONNECTING FROM A SERVERS POOL

[Alberto L. C. (Pexego) <al...@pe...>]

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.
>> <ATT00001..c><ATT00002..c>
>

CONNECTING FROM A SERVERS POOL

[Alberto L. C. (Pexego) <al...@pe...>]

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.

Re: python-ldap and kerberos

[Michael S. <mi...@st...>]

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.

ldif.py won't parse with 'python -tt'

[John M. <jw...@ho...>]

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
jw...@ho...        _-< \_          /  \       ----  <  \,
www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__

python-ldap and kerberos

[Pascal <pat...@gm...>]

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

Re: edirectory question

[Mike D. <mi...@de...>]

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.
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>
>

Re: edirectory question

[Michael S. <mi...@st...>]

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.

Re: ldap.DECODING_ERROR in ldap.dn.str2dn with python2.4 on amd64

[Michael S. <mi...@st...>]

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.

ldap.DECODING_ERROR in ldap.dn.str2dn with python2.4 on amd64

[Arvid R. <re...@un...>]

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

re...@un...
http://www.univention.de

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876 

Re: edirectory question

[Yeargan, Y. <ya...@un...>]

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
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

edirectory question

[Mike D. <mi...@de...>]

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

Re: Question: Mac OS 10.6 and Python 2.6

[John C. <jt...@gm...>]

>
>
>
> 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

Re: Contributing Mac OS X packages to PyPI

[Ben G. <bgo...@tc...>]

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

Re: Contributing Mac OS X packages to PyPI

[Michael S. <mi...@st...>]

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.

Re: Question: Mac OS 10.6 and Python 2.6

[Ben G. <bgo...@tc...>]

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

Re: Question: Mac OS 10.6 and Python 2.6

[John C. <jt...@gm...>]

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

Re: Question: Mac OS 10.6 and Python 2.6

[Michael S. <mi...@st...>]

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.