Re: STRONG_AUTH_REQUIRED

2007-12-12 Thread Fernando Ribeiro
Hi James,

 The problem was fixed using ldap.VERSION with ldap.VERSION3:

  self.conn.set_option(ldap.VERSION, ldap.VERSION3)

Thanks

Att,
-- 
-
- Fernando Ribeiro
- +55-61-8438-5806
-
Firthunands: firthu means peace, nands means daring.
"Those who do anything to maintain the peace!"
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: [ANNOUNCE] python-ad

2007-12-12 Thread David Leonard

Geert Jansen wrote:

Michael Ströder wrote:

  

Well, setting an env var is not really a good choice when running within
a multi-threaded web application... :-/
  



yet another reason to avoid threads? :)



I was thinking how one could solve the problem of per-thread credentials
in python-ldap (or python-ad).. I think it can be done with the keyring
credential cache code that is in recent MIT Kerberos distributions.
Per-thread keyrings exist so if you set $KRB5CCNAME to
"KEYRING:thread:default" then you should be able to use per-thread
credentials.
  


[A per-thread getenv() would be similarly interesting. I'm thinking like 
how errno was bodged as a macro.]


Recapping the (interesting) problem: Michael wanted to pick out the 
delegated creds from an SPNEGO auth'd request, convey them down to the 
SASL GSSAPI auth underneath an LDAP bind. And have it all work inside a 
threaded web server.
If the request handler is a python script, then you would get a separate 
python process for each request, and setenving KRB5CCNAME to a temporary 
cred cache file for the delegated ticket is straightforward. I know, 
because I've done this. But let's say you want to be interesting and use 
mod_python and have python-ldap code and sasl-gssapi running inside the 
web server's thread. In this case, you might arrange for the spnego auth 
to export the krb5 in-memory cred cache via an apache request note. 
However, when it comes time to prepare the SASL GSSAPI environment, you 
get stuck because there seems to be no way to communicate to the krb5 
mechanism under sasl which cred cache to use for auth.. This is because 
GSSAPI functions don't take context handles: it assumes global state for 
mechanisms. Even doing the "KEYRING" trick above seems dubious to me 
because the gss mechanisms might be squirreling away credential context 
in global storage. If I recall correctly, some krb5 implementations of 
gss are thread-clever, and might see different defaults per thread, so 
they might work.


I think it would just be easier to avoid threads when using GSSAPI. 
(Perhaps gss-v3 may be thread friendly?)







--
David Leonard   [EMAIL PROTECTED]
   Ph:+61 404 844 850

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: [ANNOUNCE] python-ad

2007-12-12 Thread Michael Ströder
David Leonard wrote:
>   Geert Jansen wrote:
>> Michael Ströder wrote:
>>> Well, setting an env var is not really a good choice when running within
>>> a multi-threaded web application... :-/
> 
> yet another reason to avoid threads? :)

The multi-threaded approach gives me the possibility to use persistent 
LDAP connections. This is much faster.

> Recapping the (interesting) problem: Michael wanted to pick out the 
> delegated creds from an SPNEGO auth'd request, convey them down to the 
> SASL GSSAPI auth underneath an LDAP bind. And have it all work inside a 
> threaded web server.

Exactly. ;-)

> If the request handler is a python script, then you would get a separate 
> python process for each request, and setenving KRB5CCNAME to a temporary 
> cred cache file for the delegated ticket is straightforward.

This would be easy, but that's not how web2ldap works.

> I know, 
> because I've done this. But let's say you want to be interesting and use 
> mod_python and have python-ldap code and sasl-gssapi running inside the 
> web server's thread. In this case, you might arrange for the spnego auth 
> to export the krb5 in-memory cred cache via an apache request note. 

I'd rather prefer to even extract the SPNEGO from the HTTP header within 
my web app since I don't need a Kerberos module for Apache then. And 
web2ldap runs also as a stand-alone server which is pretty handy in many 
situations.

> However, when it comes time to prepare the SASL GSSAPI environment, you 
> get stuck because there seems to be no way to communicate to the krb5 
> mechanism under sasl which cred cache to use for auth.

Yupp. I already talked to Howard Chu about whether it's possible to 
change the OpenLDAP API (sasl_interactive_bind()) in this regard.

> I think it would just be easier to avoid threads when using GSSAPI. 

:-(

Ciao, Michael.

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: STRONG_AUTH_REQUIRED

2007-12-12 Thread Fernando Ribeiro
Hi Michael,

On Dec 12, 2007 12:00 PM, Michael Ströder <[EMAIL PROTECTED]> wrote:

>
> Strange, since ldap.VERSION3 is the default explicitly set when creating
> a LDAPObject instance. Unless you formerly set this to ldap.VERSION2
> before in your code it's unlikely that this was the solution.
>

 Really strange.
 Don't was set ldap.VERSION2 in my code.
 I'm using python-ldap 2.3

Att,
Fernando Ribeiro


-- 
-
- Fernando Ribeiro - SysAdmin
- +55-61-8438-5806
-
Firthunands: firthu means peace, nands means daring.
"Those who do anything to maintain the peace!"
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: STRONG_AUTH_REQUIRED

2007-12-12 Thread Michael Ströder
Fernando Ribeiro wrote:
> 
>  The problem was fixed using ldap.VERSION with ldap.VERSION3:
> 
>   self.conn.set_option(ldap.VERSION, ldap.VERSION3)

Strange, since ldap.VERSION3 is the default explicitly set when creating 
a LDAPObject instance. Unless you formerly set this to ldap.VERSION2 
before in your code it's unlikely that this was the solution.

Ciao, Michael.

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


undefined symbol: ber_pvt_opt_on

2007-12-12 Thread Robert Escorcio
After installing python-ldap 2.3 on Ubuntu (with openldap 2-3.39), I am
getting the following error when importing ldap from a python program

  ImportError: /usr/lib/python2.4/site-packages/_ldap.so: undefined symbol:
ber_pvt_opt_on

I have seen reports on the web that this is because I did not link _ldap.so
with -llber, but that cannot be so because I see the following when I run

  python setup.py install

gcc -pthread -shared build/temp.linux-x86_64- 2.4/Modules/LDAPObject.o
build/temp.linux-x86_64-2.4/Modules/ldapcontrol.o build/temp.linux-x86_64-
2.4/Modules/common.o build/temp.linux-x86_64-2.4/Modules/constants.o
build/temp.linux-x86_64-2.4/Modules/errors.o build/temp.linux-x86_64-
2.4/Modules/functions.o
build/temp.linux-x86_64-2.4/Modules/schema.o
build/temp.linux-x86_64-2.4/Modules/ldapmodule.o
build/temp.linux-x86_64-2.4/Modules/message.o
build/temp.linux-x86_64-2.4/Modules/version.o
build/temp.linux-x86_64- 2.4/Modules/options.o -L/usr/local/openldap-2.3/lib
-Wl,-R/usr/local/openldap-2.3/lib -lldap -llber -lresolv -o
build/lib.linux-x86_64-2.4/_ldap.so


Can anyone advise me on what is the problem?
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: undefined symbol: ber_pvt_opt_on

2007-12-12 Thread Michael Ströder
Robert Escorcio wrote:
> After installing python-ldap 2.3 on Ubuntu (with openldap 2-3.39), I am 
> getting the following error when importing ldap from a python program
> 
>   ImportError: /usr/lib/python2.4/site
> -packages/_ldap.so: undefined symbol: ber_pvt_opt_on
> 
> I have seen reports on the web that this is because I did not link 
> _ldap.so with -llber,

Maybe something's wrong with run-time linking?

> but that cannot be so because I see the following 
> when I run
> 
>   python setup.py install
> 
> -Wl,-R/usr/local/openldap-2.3/lib -lldap -llber -lresolv -o 
> build/lib.linux-x86_64-2.4/_ldap.so

Seems to be ok at first glance. But how about asking the Ubuntu 
maintainer first?

Or could you please try to build yourself from a 2.3.1 source 
distribution and provide setup.cfg if it fails? Generally I don't trust 
package maintainers of Linux distribution anymore. Some of them (e.g. 
Debian) has a very large patch set.

Also I note that you're on a 64-bit platform. Maybe there's something 
wrong with the tool chain on that platform?

Ciao, Michael.


-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: undefined symbol: ber_pvt_opt_on

2007-12-12 Thread Robert Escorcio
Where can I get 2.3.1?  Looked for it on

  ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release

but the closest I could find was

  ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.3.10.tgz

Googled for it and only found


http://www.google.com/search?source=ig&hl=en&rlz=&q=openldap-2.3.1&btnG=Google+Search

I'll check 2.3.4 because its the earliest version I can find and 2.3.10 on
the off chance that this is what you meant.

2007/12/12 Michael Ströder <[EMAIL PROTECTED]>:

> Robert Escorcio wrote:
> > After installing python-ldap 2.3 on Ubuntu (with openldap 2-3.39), I am
> > getting the following error when importing ldap from a python program
> >
> >   ImportError: /usr/lib/python2.4/site
> > -packages/_ldap.so: undefined symbol: ber_pvt_opt_on
> >
> > I have seen reports on the web that this is because I did not link
> > _ldap.so with -llber,
>
> Maybe something's wrong with run-time linking?
>
> > but that cannot be so because I see the following
> > when I run
> >
> >   python setup.py install
> >
> > -Wl,-R/usr/local/openldap-2.3/lib -lldap -llber -lresolv -o
> > build/lib.linux-x86_64-2.4/_ldap.so
>
> Seems to be ok at first glance. But how about asking the Ubuntu
> maintainer first?
>
> Or could you please try to build yourself from a 2.3.1 source
> distribution and provide setup.cfg if it fails? Generally I don't trust
> package maintainers of Linux distribution anymore. Some of them (e.g.
> Debian) has a very large patch set.
>
> Also I note that you're on a 64-bit platform. Maybe there's something
> wrong with the tool chain on that platform?
>
> Ciao, Michael.
>
>


-- 
Robert Escorcio
Google Inc
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: undefined symbol: ber_pvt_opt_on

2007-12-12 Thread Michael Ströder
Robert Escorcio wrote:
> Where can I get 2.3.1?

I meant the source distribution of python-ldap 2.3.1:

http://sourceforge.net/project/showfiles.php?group_id=2072

> I'll check 2.3.4 because its the earliest version I can find and 2.3.10 
> on the off chance that this is what you meant.

I'm not talking about OpenLDAP libs. You need at least 2.3.something for 
building python-ldap 2.3.1.

Ciao, Michael.

-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Python-LDAP-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/python-ldap-dev


Re: undefined symbol: ber_pvt_opt_on

2007-12-12 Thread Robert Escorcio
2007/12/12 Michael Ströder <[EMAIL PROTECTED]>:

> Robert Escorcio wrote:
> > Where can I get 2.3.1?
>
> I meant the source distribution of python-ldap 2.3.1:
>
> http://sourceforge.net/project/showfiles.php?group_id=2072
>

Oh.  Sorry.  Right.  I was using 2.3.1 of python ldap.  When I try to import
ldap I get

  File "/usr/lib/python2.4/site-packages/ldap/__init__.py", line 23, in ?
from _ldap import *
ImportError: /usr/lib/python2.4/site-packages/_ldap.so: undefined symbol:
ber_pvt_opt_on

The build and install seem to work fine (see below for details)

I'll try building on a clean install of fedora.  Maybe its just my OS build
that is messed up.

Thanks for your help!
Robert

PS  Details:


[EMAIL PROTECTED]:~/installs/python-ldap-2.3.1# python setup.py build
extra_compile_args:
extra_objects:
include_dirs: /usr/include/sasl
library_dirs: /usr/lib/sasl2
libs: ldap lber
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
creating build/lib.linux-i686-2.4
copying Lib/ldapurl.py -> build/lib.linux-i686-2.4
copying Lib/ldif.py -> build/lib.linux-i686-2.4
copying Lib/dsml.py -> build/lib.linux-i686-2.4
creating build/lib.linux-i686-2.4/ldap
copying Lib/ldap/__init__.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/async.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/controls.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/cidict.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/dn.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/filter.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/functions.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/ldapobject.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/modlist.py -> build/lib.linux-i686-2.4/ldap
copying Lib/ldap/sasl.py -> build/lib.linux-i686-2.4/ldap
creating build/lib.linux-i686-2.4/ldap/schema
copying Lib/ldap/schema/__init__.py -> build/lib.linux-i686-2.4/ldap/schema
copying Lib/ldap/schema/models.py -> build/lib.linux-i686-2.4/ldap/schema
copying Lib/ldap/schema/subentry.py -> build/lib.linux-i686-2.4/ldap/schema
copying Lib/ldap/schema/tokenizer.py -> build/lib.linux-i686-2.4/ldap/schema
file Lib/ldap.py (for module ldap) not found
file Lib/ldap/schema.py (for module ldap.schema) not found
running build_ext
building '_ldap' extension
creating build/temp.linux-i686-2.4
creating build/temp.linux-i686-2.4/Modules
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/LDAPObject.c -o build/temp.linux-
i686-2.4/Modules/LDAPObject.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/ldapcontrol.c -o build/temp.linux-
i686-2.4/Modules/ldapcontrol.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/common.c -o build/temp.linux-i686-2.4
/Modules/common.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/constants.c -o build/temp.linux-i686-2.4
/Modules/constants.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/errors.c -o build/temp.linux-i686-2.4
/Modules/errors.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/functions.c -o build/temp.linux-i686-2.4
/Modules/functions.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/schema.c -o build/temp.linux-i686-2.4
/Modules/schema.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/ldapmodule.c -o build/temp.linux-
i686-2.4/Modules/ldapmodule.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/message.c -o build/temp.linux-i686-2.4
/Modules/message.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/version.c -o build/temp.linux-i686-2.4
/Modules/version.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DLDAPMODULE_VERSION=2.3.1 -IModules -I/usr/include/sasl
-I/usr/include/python2.4 -c Modules/options.c -o build/temp.linux-i