python-ldap-dev — discussion among developers

Re: Error message when running python-ldap under Zope and Suse

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

Jens Vagelpohl wrote:
>> But SuSE also ships with Zope (not sure which version).
>> I guess it works with the Python 2.1 SuSE RPM package.
> 
> i don't think his zope install is a suse package, or it is an older 
> package.

I guess so either.

Ciao, Michael.

Re: Error message when running python-ldap under Zope and Suse

[Jens V. <je...@zo...>]

> But SuSE also ships with Zope (not sure which version).
> I guess it works with the Python 2.1 SuSE RPM package.

i don't think his zope install is a suse package, or it is an older 
package. zope 2.3.x does not officially support python 2.x, only 1.5.2. 
besides, i doubt they would stick a second python binary into the zope 
package. that sounds awfully stupid to me... but who knows.

i tend to avoid packaged stuff unless it is for generic software packages 
that i know will only be used in the bone stock configuration. relying on 
packages is good for newbies to a degree, but when you get 
incompatibilities you're usually *really* screwed.

jens

Re: Error message when running python-ldap under Zope and Suse

[Jens V. <je...@zo...>]

i assume the problem is trying to mix things that cannot be mixed using=20=

the packages provided by suse.

from what i can deduct sude comes with python2.1 and if python-ldap is a=20=

suse package i assume it is compiled for this specific python2.1. =
however,
  the zope he has only runs on 1.5.2. so he cannot achieve the desired =
goal=20
using only prepackaged stuff.

jens


On Friday, April 19, 2002, at 09:10 , Michael Str=F6der wrote:

> Josef Meile wrote:
>> You mean if there is a file called python and nothing else in the =
folder
>> Zope2.x.x/bin?
>> If so, then I have a binary version, so I'll have to install the =
source.
>>  By
>> the way, where should I compile the source? I guess I've to install =
the
>> version 1.5.2 as well.
>
> You should probably try to install all the packages from the SuSE =
Linux.=20
> Don't start mixing without really knowing what to do!
>
> AFAIK SuSE 7.3 comes with Python 2.1, (outdated) python-ldap =
1.10alpha3=20
> and Zope.
>
> Ciao, Michael.
>

Re: Error message when running python-ldap under Zope and Suse

[Josef M. <jm...@ho...>]

> if there is a python binary anywhere underneath the zope directory then
you
> most likely have a binary distribution, which presents problems for
newbies
> trying to install additional python modules.

You mean if there is a file called python and nothing else in the folder
Zope2.x.x/bin?
If so, then I have a binary version, so I'll have to install the source. By
the way, where should I compile the source? I guess I've to install the
version 1.5.2 as well.

Thanks,
Josef.

Re: Error message when running python-ldap under Zope and Suse

[Jens V. <je...@zo...>]

>> is your zope a binary version or the source version?
> Actually, I don't know it because it was installed when I started with it.
> How can I now it?

if there is a python binary anywhere underneath the zope directory then you 
most likely have a binary distribution, which presents problems for newbies 
trying to install additional python modules.

>
>> apart from that you cannot expect python 1.5 (which is what your zope is
>> running on) to find and use things in the python path of a python 2.1
>> installation.
> I know it, but there isn't a suse version on the python-ldap's sourceforge
> page. So,
> where should I get it? Or can I perhaps change the python version?

zope 2.3.x runs on python 1.5.2. you will have to get the python-ldap 
1.10alpha3 source and build it i suppose.

>
>> P.S.: never trust RPM packages for addons like this because they are
> always
>> packaged with a lot of assumptions, like what python to use and where
>> things are installed.
> Which one should I download?

get the source

jens

Re: Error message when running python-ldap under Zope and Suse

[Josef M. <jm...@ho...>]

> is your zope a binary version or the source version?
Actually, I don't know it because it was installed when I started with it.
How can I now it?

> apart from that you cannot expect python 1.5 (which is what your zope is
> running on) to find and use things in the python path of a python 2.1
> installation.
I know it, but there isn't a suse version on the python-ldap's sourceforge
page. So,
where should I get it? Or can I perhaps change the python version?

> P.S.: never trust RPM packages for addons like this because they are
always
> packaged with a lot of assumptions, like what python to use and where
> things are installed.
Which one should I download?

Thanks for your reply,
Josef.

Re: Error message when running python-ldap under Zope and Suse

[Jens V. <je...@zo...>]

is your zope a binary version or the source version?

apart from that you cannot expect python 1.5 (which is what your zope is 
running on) to find and use things in the python path of a python 2.1 
installation.

jens

P.S.: never trust RPM packages for addons like this because they are always 
packaged with a lot of assumptions, like what python to use and where 
things are installed.

On Thursday, April 18, 2002, at 05:38 , Josef Meile wrote:

> Hi,
> I'm just trying to install python-ldap on suse 7.3, Zope 2.3.3 and Python
> 1.5.2
> I also installed the LDAPUserManager 1.3 and the LDAPLoginAdapter 1.6.
>
> I followed all the instruccions:
> 1- Download and install the binary from suse 7.3 ->
> python-ldap-1.10alpha3-182.i386.rpm (I took it from ftp.suse.com)
>
> 2- Set the LD_LIBRARY_PATH where my liblber.so.2 and libldap.so.2 are:
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib
> export LD_LIBRARY_PATH
>
> 3- Set the PYTHONPATH where the python-ldap module is:
> PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages/python-ldap:/usr/
> lib
> /python2.1/site-packages
> export PYTHONPATH
>
> Here I also tried:
> PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages/python-ldap
> export PYTHONPATH
>
> and:
> PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages
> export PYTHONPATH
>
> But then I got one error more.
>
> These are the errors:
>
> ------
> 2002-04-18T21:18:23 ERROR(200) Zope Couldn't import
> Products.LDAPLoginAdapter
> Traceback (innermost last):
>   File /usr/local/Zope-2.3.0/lib/python/OFS/Application.py, line 528, in
> import_
> products
>     (Object: string)
>   File /usr/local/Zope/lib/python/Products/LDAPLoginAdapter/__init__.py,
> line 13
> , in ?
>   File
> /usr/local/Zope/lib/python/Products/LDAPLoginAdapter/LDAPLoginAdapter.py,
>  line 23, in ?
>   File /usr/local/Zope/lib/python/Products/LDAPLoginAdapter/LDAPShared.py,
> line
> 19, in ?
>   File /usr/lib/python2.1/site-packages/python-ldap/ldap.py, line 2, in ?
> ImportError: /usr/lib/python2.1/site-packages/_ldapmodule.so: undefined
> symbol:
> PyObject_Init
>
>
> ------
> 2002-04-18T21:18:23 ERROR(200) Zope Couldn't import 
> Products.LDAPUserManager
> Traceback (innermost last):
>   File /usr/local/Zope-2.3.0/lib/python/OFS/Application.py, line 528, in
> import_
> products
>     (Object: string)
>   File /usr/local/Zope/lib/python/Products/LDAPUserManager/__init__.py, 
> line
> 13,
>  in ?
>   File
> /usr/local/Zope/lib/python/Products/LDAPUserManager/LDAPUserManager.py, l
> ine 16, in ?
>   File /usr/local/Zope/lib/python/Products/LDAPUserManager/LDAPShared.py,
> line 2
> 3, in ?
> AttributeError: SCOPE_BASE
>
>
> ------
> 2002-04-18T21:18:38 INFO(0) ZServer HTTP server started at Thu Apr 18
> 23:18:38 2
> 002
>         Hostname: localhost
>         Port: 80
> ------
> 2002-04-18T21:18:38 INFO(0) ZServer FTP server started at Thu Apr 18
> 23:18:38 20
> 02
>         Hostname: localhost
>         Port: 8021
> ------
> 2002-04-18T21:18:38 INFO(0) ZServer PCGI Server started at Thu Apr 18
> 23:18:38 2
> 002
>         Unix socket: /usr/local/Zope-2.3.0/var/pcgi.soc
>
>
> Does anybody know the mistake?
>
> Thanks in advanced,
> Josef.
>
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Error message when running python-ldap under Zope and Suse

[Josef M. <jm...@ho...>]

Hi,
I'm just trying to install python-ldap on suse 7.3, Zope 2.3.3 and Python
1.5.2
I also installed the LDAPUserManager 1.3 and the LDAPLoginAdapter 1.6.

I followed all the instruccions:
1- Download and install the binary from suse 7.3 ->
python-ldap-1.10alpha3-182.i386.rpm (I took it from ftp.suse.com)

2- Set the LD_LIBRARY_PATH where my liblber.so.2 and libldap.so.2 are:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib
export LD_LIBRARY_PATH

3- Set the PYTHONPATH where the python-ldap module is:
PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages/python-ldap:/usr/lib
/python2.1/site-packages
export PYTHONPATH

 Here I also tried:
PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages/python-ldap
export PYTHONPATH

 and:
PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages
export PYTHONPATH

 But then I got one error more.

These are the errors:

------
2002-04-18T21:18:23 ERROR(200) Zope Couldn't import
Products.LDAPLoginAdapter
Traceback (innermost last):
  File /usr/local/Zope-2.3.0/lib/python/OFS/Application.py, line 528, in
import_
products
    (Object: string)
  File /usr/local/Zope/lib/python/Products/LDAPLoginAdapter/__init__.py,
line 13
, in ?
  File
/usr/local/Zope/lib/python/Products/LDAPLoginAdapter/LDAPLoginAdapter.py,
 line 23, in ?
  File /usr/local/Zope/lib/python/Products/LDAPLoginAdapter/LDAPShared.py,
line
19, in ?
  File /usr/lib/python2.1/site-packages/python-ldap/ldap.py, line 2, in ?
ImportError: /usr/lib/python2.1/site-packages/_ldapmodule.so: undefined
symbol:
PyObject_Init


------
2002-04-18T21:18:23 ERROR(200) Zope Couldn't import Products.LDAPUserManager
Traceback (innermost last):
  File /usr/local/Zope-2.3.0/lib/python/OFS/Application.py, line 528, in
import_
products
    (Object: string)
  File /usr/local/Zope/lib/python/Products/LDAPUserManager/__init__.py, line
13,
 in ?
  File
/usr/local/Zope/lib/python/Products/LDAPUserManager/LDAPUserManager.py, l
ine 16, in ?
  File /usr/local/Zope/lib/python/Products/LDAPUserManager/LDAPShared.py,
line 2
3, in ?
AttributeError: SCOPE_BASE


------
2002-04-18T21:18:38 INFO(0) ZServer HTTP server started at Thu Apr 18
23:18:38 2
002
        Hostname: localhost
        Port: 80
------
2002-04-18T21:18:38 INFO(0) ZServer FTP server started at Thu Apr 18
23:18:38 20
02
        Hostname: localhost
        Port: 8021
------
2002-04-18T21:18:38 INFO(0) ZServer PCGI Server started at Thu Apr 18
23:18:38 2
002
        Unix socket: /usr/local/Zope-2.3.0/var/pcgi.soc


Does anybody know the mistake?

Thanks in advanced,
Josef.

Error message when running python-ldap under Zope and Suse

[Josef M. <me...@im...>]

Hi,
I'm just trying to install python-ldap on suse 7.3, Zope 2.3.3 and Python
1.5.2
I also installed the LDAPUserManager 1.3 and the LDAPLoginAdapter 1.6.

I followed all the instruccions:
1- Download and install the binary from suse 7.3 ->
python-ldap-1.10alpha3-182.i386.rpm (I took it from ftp.suse.com)

2- Set the LD_LIBRARY_PATH where my liblber.so.2 and libldap.so.2 are:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib
export LD_LIBRARY_PATH

3- Set the PYTHONPATH where the python-ldap module is:
PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages/python-ldap:/usr/lib
/python2.1/site-packages
export PYTHONPATH

Here I also tried:
PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages/python-ldap
export PYTHONPATH

and:
PYTHONPATH=$PYTHONPATH:/usr/lib/python2.1/site-packages
export PYTHONPATH

But then I got one error more.

These are the errors:

------
2002-04-18T21:18:23 ERROR(200) Zope Couldn't import
Products.LDAPLoginAdapter
Traceback (innermost last):
  File /usr/local/Zope-2.3.0/lib/python/OFS/Application.py, line 528, in
import_
products
    (Object: string)
  File /usr/local/Zope/lib/python/Products/LDAPLoginAdapter/__init__.py,
line 13
, in ?
  File
/usr/local/Zope/lib/python/Products/LDAPLoginAdapter/LDAPLoginAdapter.py,
 line 23, in ?
  File /usr/local/Zope/lib/python/Products/LDAPLoginAdapter/LDAPShared.py,
line
19, in ?
  File /usr/lib/python2.1/site-packages/python-ldap/ldap.py, line 2, in ?
ImportError: /usr/lib/python2.1/site-packages/_ldapmodule.so: undefined
symbol:
PyObject_Init


------
2002-04-18T21:18:23 ERROR(200) Zope Couldn't import Products.LDAPUserManager
Traceback (innermost last):
  File /usr/local/Zope-2.3.0/lib/python/OFS/Application.py, line 528, in
import_
products
    (Object: string)
  File /usr/local/Zope/lib/python/Products/LDAPUserManager/__init__.py, line
13,
 in ?
  File
/usr/local/Zope/lib/python/Products/LDAPUserManager/LDAPUserManager.py, l
ine 16, in ?
  File /usr/local/Zope/lib/python/Products/LDAPUserManager/LDAPShared.py,
line 2
3, in ?
AttributeError: SCOPE_BASE


------
2002-04-18T21:18:38 INFO(0) ZServer HTTP server started at Thu Apr 18
23:18:38 2
002
        Hostname: localhost
        Port: 80
------
2002-04-18T21:18:38 INFO(0) ZServer FTP server started at Thu Apr 18
23:18:38 20
02
        Hostname: localhost
        Port: 8021
------
2002-04-18T21:18:38 INFO(0) ZServer PCGI Server started at Thu Apr 18
23:18:38 2
002
        Unix socket: /usr/local/Zope-2.3.0/var/pcgi.soc


Does anybody know the mistake?

Thanks in advanced,
Josef.

Re: Schema support

[Hans A. <Han...@Ph...>]

On Dienstag, 16. April 2002 07:59, Michael Ströder wrote:
> I tried your attachments. But to me it seems that there is lacking
> something. The build went fine but the functions do not appear in
> extension module _ldap.

Sorry, ashes on my head...
I forgot to apped the patch for Modules/ldapmodule.c (which calls
LDAPinit_schema()) -- see below.

> Please re-send most recent version of your schema support and SASL
> patches.

Ok, here we go. The "grand unified patch" against cvs.

The following files have beed added and do not appear in the patch.
BTW: is there a way to include them using 'cvs diff'?

Demo/sasl_bind.py
Lib/ldap/sasl.py     (new sasl module)
Lib/ldap/schema.py   (the schema module)
Modules/schema.c
Modules/schema.h

__Opps__ I just saw that you have already applied the schema patches to
CVS. The missing part in the C part is the following patch:

Index: Modules/ldapmodule.c
===================================================================
RCS file: /cvsroot/python-ldap/python-ldap/Modules/ldapmodule.c,v
retrieving revision 1.3
diff -r1.3 ldapmodule.c
11a12

> #include "schema.h"

46a48

>       LDAPinit_schema(d);

The attached patch is a context sensitive diff in order to minimize the
confusion of patches which are applied twice ;-)

If you prefere a tar-ball of my sources, let me know. Maybe it is then
easier to merge our trees (hint, hint :-).

Hans

--
Han...@Ph...

-------------------------------------------------------


-- 
Han...@Ph...

Re: Schema support

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

Hans Aschauer wrote:
> I have finished a first version of schema support for python-ldap. 

I tried your attachments. But to me it seems that there is lacking 
something. The build went fine but the functions do not appear in extension 
module _ldap.

Maybe you also modified functions.c?

Please re-send most recent version of your schema support and SASL patches.

Ciao, Michael.

Re: Error importing LDAP module

[Jens V. <je...@zo...>]

build python-ldap with the exact binary that is in zope. i assume you are 
using some binary distribution.

<python_binary_in_zope_tree> setup.py build
<python_binary_in_zope_tree> setup.py install

that should do it.

jens

P.S.: a lot of peoples' problems could be solved if they used the source 
install of zope, which is very easy to install and build. then you can use 
any python module that is installed into your machine's python library path 
because your machine's python is used.


On Friday, April 12, 2002, at 12:23 , Sharma, Gopesh (NCI) wrote:

> Hello All:
>
> I am getting error while using 'import ldap' command.
>
> *************************************************************************
> *
>
> [root@tsdev2 bin]# ./python
> Python 2.1.2 (#1, Jan 25 2002, 13:17:56)
> [GCC 2.7.2.3] on linux2
> Type "copyright", "credits" or "license" for more information.
>>>> import ldap
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/local/ZopePark/lib/python2.1/ldap.py", line 2, in ?
>     from _ldap import __version__
> ImportError: No module named _ldap
>>>>
>
> *************************************************************************
> *
> I am running Python2.1.2 from within Zope Framework. If I use python2.2 it
> works fine.
>
> Is there any Pythons 2.1.2 patch available so that I can install in Zope?
> ?
>
> Please advise.
> Thanks,
> Gopesh
>
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

Error importing LDAP module

[Sharma, G. (NCI) <sha...@ma...>]

Hello All:

I am getting error while using 'import ldap' command. 

**************************************************************************

[root@tsdev2 bin]# ./python
Python 2.1.2 (#1, Jan 25 2002, 13:17:56) 
[GCC 2.7.2.3] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import ldap
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/ZopePark/lib/python2.1/ldap.py", line 2, in ?
    from _ldap import __version__
ImportError: No module named _ldap
>>> 

**************************************************************************
I am running Python2.1.2 from within Zope Framework. If I use python2.2 it
works fine.

Is there any Pythons 2.1.2 patch available so that I can install in Zope?? 

Please advise.
Thanks,
Gopesh  

Re: non-ascii handling

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

Jens Vagelpohl wrote:
> in handling these various kinds of strings (both UTF-8 encoded unicode 
> and latin-1 encoded unicode for web browser consumption) i always end up 
> running into trouble at some point because in some situations strings 
> get encoded more than once.

Especially when implementing web applications you have to take great care to 
define the charset used. Use <form accept-charset="utf-8" ..> or similar to 
also define the charset of the form input data. (This does not prevent e.g. 
StarOffice from sending ISO-8859-1 data.)

Also set the charset of the output in the HTTP header *and* the <head> section.

> does anyone know of a quick and fast test to 
> determine whether a string is already encoded in a certain encoding? my 
> knowledge of regular expressions (which i assume it would take for that) 
> is extremely limited at best.

Hmm, in some situations a try: unicode() except UnicodeError: might help. 
But I do not recommend such a solution (although sometimes used in web2ldap) 
and you have to apply specific knowledge about the character sets/encodings.

 From my personal experience it's much work to make an application 
Unicode-aware. But you should try to clean up your application design. It's 
worth the effort.

Ciao, Michael.

Re: non-ascii handling

[Jens V. <je...@zo...>]

michael,

thanks for the answer, that helped a bit.

in handling these various kinds of strings (both UTF-8 encoded unicode =
and=20
latin-1 encoded unicode for web browser consumption) i always end up=20
running into trouble at some point because in some situations strings =
get=20
encoded more than once. does anyone know of a quick and fast test to=20
determine whether a string is already encoded in a certain encoding? my=20=

knowledge of regular expressions (which i assume it would take for that) =
is=20
extremely limited at best.

jens


On Wednesday, April 10, 2002, at 01:17 , Michael Str=F6der wrote:

> Jens,
>
> Sorry for answering that late.
>
> Jens Vagelpohl wrote:
>> i have a product that uses python-ldap and i'm trying to make sure=20
>> everything works when non-ascii characters are used in a DN. from =
what i=20
>> have been reading about OpenLDAP it either wants pure ASCII passed to =
it=20
>> (for search terms, DNs etc) or UTF-8-encoded unicode strings.
>
> Depends on the attribute. BTW: ASCII is a real subset of UTF-8. Or =
better=20
> said: The character entities encoded in ASCII are mapped to the very =
same=20
> encoding in UTF-8.
>
>> my question is: does python-ldap do any automatic string conversions?
>
> No! And I refused a patch which does. It cannot be done without =
applying=20
> knowledge about the schema (syntax of an attribute). Review the =
archives.
>
>> i get search results just fine using a non-ascii search term when i =
do=20
>> not convert the term myself and hand it to ldap.search_s, but i never =
get=20
>> results if i convert the string by myself and then hand it to the=20
>> search_s method.
>
> If you have a Unicode object with a LDAP search filter than you have =
to=20
> encode that before calling method search_s().
>
> Example (valid on my Linux console with ISO-8859-1):
>
> filter =3D unicode('cn=3D*Str=F6der*','iso-8859-1')
> l.search_s(search_root,ldap.SCOPE_SUB,filter.encode('utf-8'))
>
> Note that filter is a Unicode object created by passing a string and =
the=20
> known character set to the unicode() function.
>
> Ciao, Michael.
>

Re: non-ascii handling

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

Jens,

Sorry for answering that late.

Jens Vagelpohl wrote:
> i have a product that uses python-ldap and i'm trying to make sure=20
> everything works when non-ascii characters are used in a DN. from what =
i=20
> have been reading about OpenLDAP it either wants pure ASCII passed to i=
t=20
> (for search terms, DNs etc) or UTF-8-encoded unicode strings.

Depends on the attribute. BTW: ASCII is a real subset of UTF-8. Or better=
=20
said: The character entities encoded in ASCII are mapped to the very same=
=20
encoding in UTF-8.

> my question is: does python-ldap do any automatic string conversions?

No! And I refused a patch which does. It cannot be done without applying =

knowledge about the schema (syntax of an attribute). Review the archives.=


> i=20
> get search results just fine using a non-ascii search term when i do no=
t=20
> convert the term myself and hand it to ldap.search_s, but i never get=20
> results if i convert the string by myself and then hand it to the=20
> search_s method.

If you have a Unicode object with a LDAP search filter than you have to=20
encode that before calling method search_s().

Example (valid on my Linux console with ISO-8859-1):

filter =3D unicode('cn=3D*Str=F6der*','iso-8859-1')
l.search_s(search_root,ldap.SCOPE_SUB,filter.encode('utf-8'))

Note that filter is a Unicode object created by passing a string and the =

known character set to the unicode() function.

Ciao, Michael.

Re: userPassword

[<de...@il...>]

On Wed, 3 Apr 2002, Hans Aschauer wrote:

> import crypt
> passwd = 'mysecret'
> salt = "xy"
> userPassword = '{crypt}' + crypt.crypt(passwd,salt)
> 
> And that's it. userPassword could then be used with the add() method of 
> the ldap object. 

Thanks for the example code. I guess I was a little confused about where 
the encryption took place. So now I understand that if I want to add an 
encrypted password in ldap I would do the encryption myself, prefixing the 
encrypted password with the encryption type (ie '{SHA}'). Then I add the 
password as a value of userPassword.

-- 
---
Dennis Sacks
de...@il...
"An idiot with a computer is a faster, better idiot." - Rick Julius

non-ascii handling

[Jens V. <je...@zo...>]

i have a product that uses python-ldap and i'm trying to make sure 
everything works when non-ascii characters are used in a DN. from what i 
have been reading about OpenLDAP it either wants pure ASCII passed to it 
(for search terms, DNs etc) or UTF-8-encoded unicode strings.

my question is: does python-ldap do any automatic string conversions? i 
get search results just fine using a non-ascii search term when i do not 
convert the term myself and hand it to ldap.search_s, but i never get 
results if i convert the string by myself and then hand it to the search_s 
method.

i'm trying to find out whether i am doing the wrong thing converting any 
and all non-ascii myself in my product before sending it over the line to 
the LDAP server using python-ldap.

jens

Re: Schema support

[Hans A. <Han...@Ph...>]

On Thursday, 4. April 2002 23:51, Michael Ströder wrote:


> Hmm, BTW it does not clarify how a client should deal with a
> multi-valued subschemaSubentry attribute. Should schemas be used
> exclusive-or or joined. That's another interesting topic to be
> discussed in IETF ldap-bis WG.

As I understand it, this issue has been addressed in 
draft-ietf-ldapbis-protocol-02.txt:

"""
B.8 Section 3.4 
    
   - Reworded text surrounding subschemaSubentry to reflect that it is 
     a single-valued attribute that holds the schema for the root DSE. 
     Also noted that if the server masters entries that use differing 
     schema, each entry's subschemaSubentry attribute must be 
     interrogated. This may change as further fine-tuning is done to 
     the data model. 
"""


[...]

> So my conclusion is that an application should first try to query
> operational attribute subschemaSubentry for a particular entry and
> fall-back to the subschemaSubentry attribute in the root DSE to find
> out the location of sub schema sub entry in the DIT. Puh...

According to the draft, we should probably query the root DSE only if 
we are interested in the schema controlling the root DSE itself (which 
most applications are not, as I think). On the other hand, the RFC text 
is somwhat misleading (especially where it is changed by the draft), 
and I don't know how implementors of server software interpreted the 
text... 

Anyway, back to the python specific things :-)

* If we implement per-entry schema information, caching is mandatory. 
  And it can be easily done, since we we can create a mapping 
  "subschema-entry RDN" => "schema information" (by doing it this way 
  we would not need nested trees, and for servers which have only one 
  subschema entry, one saves a lot of memory).

  To be specific, for my OpenLDAP installation, this mapping would look 
  like {'cn=Subschema': <class ldap.schema.rootDSESchema at xyz>} --- 
  only one entry. Of course, the name of the class 
  ldap.schema.rootDSESchema has to be changed... How about "schema"?

* How should this cache be accessed? Logically, it belongs to the ldap 
  connection (or to the ldap server, but there is not such python 
  class, is it?). However, I don't know if it is too high-level to make 
  it an attribute of the LDAPObject class.


So long,

Hans


-- 
Han...@Ph...

Re: Schema support

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

Hans Aschauer wrote:
> 
> Ok, I went back to RFC 2251. That's how I understand it (please correct 
> me when I'm wrong):
> 
> Sec. 3.4: 
> We can query the RootDSE for the subschemaSubentry attribute, which 
> tells us which "subschema entries (or subentries) [are] known by this 
> server":
> 
> [aschauer@pygar]$ldapsearch -LLL -x -b "" -s base "(objectclass=*)" \
> 	subschemaSubentry
> dn:
> subschemaSubentry: cn=Subschema

Hmm, BTW it does not clarify how a client should deal with a multi-valued 
subschemaSubentry attribute. Should schemas be used exclusive-or or joined. 
That's another interesting topic to be discussed in IETF ldap-bis WG.

> So, as far as I understand it, we should first query the rootDSE for 
> the subschema (sub)entries, and use the results as search bases for 
> querying the schema information. 

Take also a look at section 3.2.1.:

--------------- snip -----------------
3.2.1. Attributes of Entries

[..]
    Entries MAY contain, among others, the following operational
    attributes, defined in [5]. These attributes are maintained
    automatically by the server and are not modifiable by clients:
[..]
    - subschemaSubentry:  the Distinguished Name of the subschema entry
      (or subentry) which controls the schema for this entry.

--------------- snip -----------------

So my conclusion is that an application should first try to query 
operational attribute subschemaSubentry for a particular entry and fall-back 
to the subschemaSubentry attribute in the root DSE to find out the location 
of sub schema sub entry in the DIT. Puh...

I guess I will start a discussion about that on the ldap-bis list.

Ciao, Michael.

Re: Schema support

[Hans A. <Han...@Ph...>]

On Wednesday, 3. April 2002 20:48, Michael Ströder wrote:
> Hans Aschauer wrote:
> > On Wednesday, 3. April 2002 16:37, you wrote:

[about doing clever things in climbing down trees]

> I'm pretty sure there are situations where tree climbing does not
> work. Don't try to be clever. Most times it does not work out. Anyway
> we should review RFC 2251, section 3.2.2 for that more closely.

Ok, I went back to RFC 2251. That's how I understand it (please correct 
me when I'm wrong):

Sec. 3.4: 
We can query the RootDSE for the subschemaSubentry attribute, which 
tells us which "subschema entries (or subentries) [are] known by this 
server":

[aschauer@pygar]$ldapsearch -LLL -x -b "" -s base "(objectclass=*)" \
	subschemaSubentry
dn:
subschemaSubentry: cn=Subschema

Sec. 3.2.2: The result conforms to this section: "cn: this attribute 
MUST be used to form the RDN of the subschema entry". 

One thing I missed up to now: "Clients MUST only retrieve attributes 
from a subschema entry by requesting a base object search of the entry, 
where the search filter is '(objectClass=subschema)'" (up to now I used 
'(objectClass=*)').

Let's try it:

[aschauer@pygar]$ldapsearch -LLL -x -b "cn=Subschema" -s base \
	"(objectclass=subschema)" objectclasses | less

Works!

So, as far as I understand it, we should first query the rootDSE for 
the subschema (sub)entries, and use the results as search bases for 
querying the schema information. 

> BTW: There could be also these attributes in sub schema sub entry:
> matchingRuleUse, dITStructureRules, dITContentRules and nameForms.
> I know OpenLDAP 2 server does not implement any of these. Does the
> schema parser in OpenLDAP 2 libs handle any of these?

Nope. I just looked at the source, and the parsers seem to be kind of 
hard-coded. No generic BNF parser. But then, that's exactly how I would 
write such a parser ;-)

So long,

Hans

-- 
Han...@Ph...

Re: Schema support

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

Hans Aschauer wrote:
> On Wednesday, 3. April 2002 16:37, you wrote:
> 
>>Hans Aschauer wrote:
> 
>> > * The class rootDSESchema (looking for a better name...), which
>> > takes an initialize()'d and simple_bind_s()'ed ldap object.
>>
>> [..] simply let the
>>application pass in a instance of ldap.LDAPObject and solely do the
>>search_s() calls within your class.
> 
> Ooops, that was exactly what I meant. Just pass an initialized and boud 
> ldap object.

Sorry, misread your phrase.

>>BTW: Theoretically the sub schema sub entry can be different in each
>>part of the DIT.
> 
> You write of this possibility as a theoretical one. Do you know of any 
> ldap server that implements this?

No I don't know one. Hmm, I have to check database configuration in Netscape 
and iPlanet DS again. But applications have to be prepared for it.

> Maybe one should not automatically query the schema entries for every 
> branch of the DIT, but only at "important" branches.

Now the really exciting questions is how you distinguish the "important" 
branches. ;-)

IMHO efficient applications should request the DN of the sub schema sub 
entry by requesting attribute subschemaSubentry of current DN each and every 
time. If that points to a sub schema sub entry already parsed the cached 
schema instance can be used.

> If there exists no 
> schema description at the desired level of the tree, the closest one is 
> aquired (in Zopista speach) by climbing down the tree toward its root.

I'm pretty sure there are situations where tree climbing does not work. 
Don't try to be clever. Most times it does not work out. Anyway we should 
review RFC 2251, section 3.2.2 for that more closely.

BTW: There could be also these attributes in sub schema sub entry: 
matchingRuleUse, dITStructureRules, dITContentRules and nameForms.
I know OpenLDAP 2 server does not implement any of these. Does the schema 
parser in OpenLDAP 2 libs handle any of these?

Ciao, Michael.

Re: Schema support

[Hans A. <Han...@Ph...>]

On Wednesday, 3. April 2002 16:37, you wrote:
> Hans Aschauer wrote:


>  > (defined in ldap_schema.h). For thread safety, they simply use the
>  > _ldap_call() function (Michael, is this a good idea?).
>
> I don't know if it's good idea. But it was the best idea I came up
> with. So it's the right way to do it.

:-)

[...]

>  > * The class rootDSESchema (looking for a better name...), which
>  > takes an initialize()'d and simple_bind_s()'ed ldap object.
>
> You should not do initialize() and simple_bind_s() because it could
> be a waste of resource and the root DSE and/or schema could be
> subject of access control.  The application is responsible to make
> the connection and set up the right bind context => simply let the
> application pass in a instance of ldap.LDAPObject and solely do the
> search_s() calls within your class.

Ooops, that was exactly what I meant. Just pass an initialized and boud 
ldap object.

>   > The constructor
>  >   queries the rootDSE and fills the attributeTypes, objectClasses,
>  >   ldapSyntaxes, and matchingRules which are known by the ldap
>  > server into 8 dictionaries: for each of the four classes, there is
>  > one dictionary which takes the oid's as keys (these are those
>  > funny "1.2.3.4" things, which are supposed to be unique), and one
>  > dictionary takes the names as keys. The latter is necessary, since
>  > for example, in objectClasses, the allowed or required attributes
>  > are referred to by name rather than by oid.
>
> I'd like to have a single OID registry since OIDs are really unique.
> There are no collisions. Simply map the OID in string notation to the
> schema element instance with a single dictionary. The reverse mapping
> can also be done by a single dictionary. I don't think that people
> are using the same names for attribute types and object classes.

You are right, this will really simplify things... 

[...]

> BTW: Theoretically the sub schema sub entry can be different in each
> part of the DIT. Therefore an application has to query the
> subschemaSubentry attribute each time it uses the schema somewhere.
> Schema can be cached if the DN in subschemaSubentry attribute is the
> same. Maybe the OID registry could be a nested dictionary...

You write of this possibility as a theoretical one. Do you know of any 
ldap server that implements this? Hmm, if I think about it, this is 
really usful as soon as referrals are being used. Are there other 
real-world situations where you (or someone else) have seen this?

Maybe one should not automatically query the schema entries for every 
branch of the DIT, but only at "important" branches. If there exists no 
schema description at the desired level of the tree, the closest one is 
aquired (in Zopista speach) by climbing down the tree toward its root.

It would then be up to the application writer (or some clever logics) 
to determine which branch is considered important. 

Would something like this make sense?



-- 
Han...@Ph...

Re: Schema support

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

Hans Aschauer wrote:
 > I have finished a first version of schema support for python-ldap.

Great!

 > * Thread safe wrappers for the four C functions (str2xyz), which return
 >   lists of entries which correspond to the C data types (defined in
 >   ldap_schema.h). For thread safety, they simply use the _ldap_call()
 >   function (Michael, is this a good idea?).

I don't know if it's good idea. But it was the best idea I came up with. So
it's the right way to do it.

 > * Four simple classes (attributeType, objectClass, ldapSyntax,
 >   matchingRule). Their constructors take a string description
 >   of the schema, pass it to the wrapper functions and fill in the
 >   object attributes. See RFC2252 for details.

Ok.

 > * The class rootDSESchema (looking for a better name...), which takes
 >   an initialize()'d and simple_bind_s()'ed ldap object.

You should not do initialize() and simple_bind_s() because it could be a
waste of resource and the root DSE and/or schema could be subject of access
control.  The application is responsible to make the connection and set up
the right bind context => simply let the application pass in a instance of
ldap.LDAPObject and solely do the search_s() calls within your class.

  > The constructor
 >   queries the rootDSE and fills the attributeTypes, objectClasses,
 >   ldapSyntaxes, and matchingRules which are known by the ldap server
 >   into 8 dictionaries: for each of the four classes, there is one
 >   dictionary which takes the oid's as keys (these are those funny
 >   "1.2.3.4" things, which are supposed to be unique), and one
 >   dictionary takes the names as keys. The latter is necessary, since
 >   for example, in objectClasses, the allowed or required attributes are
 >   referred to by name rather than by oid.

I'd like to have a single OID registry since OIDs are really unique. There
are no collisions. Simply map the OID in string notation to the schema
element instance with a single dictionary. The reverse mapping can also be
done by a single dictionary. I don't think that people are using the same
names for attribute types and object classes.

 > there was some
 > try/error involved in the RootDSE search...

He, he.

BTW: Theoretically the sub schema sub entry can be different in each part of
   the DIT. Therefore an application has to query the subschemaSubentry
attribute each time it uses the schema somewhere. Schema can be cached if
the DN in subschemaSubentry attribute is the same. Maybe the OID registry
could be a nested dictionary...

Taken from web2ldap's module ldapsession (lines wrapped!):

    def getSubschemaEntryDN(self,dn):
      """Get DN of subschemaSubentry for dn"""
      # Search for DN of subschemaSubentry
      search_result = self.readEntry(dn,['subschemaSubentry'])
      if search_result:
        entry = search_result[0][1]
        return
entry.get('subschemaSubentry',entry.get('subschemaSubentry',[None]))[0]
      else:
        return None

Ciao, Michael.

Schema support

[Hans A. <Han...@Ph...>]

I have finished a first version of schema support for python-ldap. 
There are four simple wrapper for the functions str2objectclass(), 
str2attributetype(), str2matchingrule(), and str2syntax() in the _ldap 
module (and thus in the ldap module --- I guess it would be a good idea 
to del() them from the ldap module in the ldap/__init__.py file...). 
These functions should not be used directly, since they are (probably) 
not thread safe.

There exists a new module ldap.schema, which proviedes the following 
functions/classes:

* Thread safe wrappers for the four C functions (str2xyz), which return 
  lists of entries which correspond to the C data types (defined in 
  ldap_schema.h). For thread safety, they simply use the _ldap_call()
  function (Michael, is this a good idea?).

* Four simple classes (attributeType, objectClass, ldapSyntax,
  matchingRule). Their constructors take a string description
  of the schema, pass it to the wrapper functions and fill in the
  object attributes. See RFC2252 for details.

* The class rootDSESchema (looking for a better name...), which takes
  an initialize()'d and simple_bind_s()'ed ldap object. The constructor 
  queries the rootDSE and fills the attributeTypes, objectClasses,
  ldapSyntaxes, and matchingRules which are known by the ldap server
  into 8 dictionaries: for each of the four classes, there is one
  dictionary which takes the oid's as keys (these are those funny
  "1.2.3.4" things, which are supposed to be unique), and one
  dictionary takes the names as keys. The latter is necessary, since
  for example, in objectClasses, the allowed or required attributes are
  referred to by name rather than by oid. The names of the
  dictionaries are:

        objectClasses
        objectClassesByName
        attributeTypes
        attributeTypesByName
        ldapSyntaxes
        ldapSyntaxesByName
        matchingRules
        matchingRulesByName

I've attached four files (a patch for setup.py, and the newly created 
files Modules/schema.c, Modules/schema.h, Lib/ldap/schema.py). 

Any comments? Does the user interface make sense? Could someone please 
try it with a _server_ different from OpenLDAP 2? As long as untested, 
I would say that it is only compatible with OpenLDAP --- there was some 
try/error involved in the RootDSE search...

Hans

-- 
Han...@Ph...