Menu
▾
▴
python-ldap-dev
|
From: <mi...@st...> - 2002-07-27 20:47:42
|
HI!
ldap.schema.str2objectclass() fails when parsing the following
string (from Netscape DS 4.16SP1 sub schema sub entry):
"( 2.5.6.1 NAME 'alias' DESC 'Standard ObjectClass' SUP 'top' MUST
( objectclass $ aliasedObjectName ) MAY ( aci ) )"
This schema string does not look unusual to me but...
>>> ldap.schema.str2objectclass("( 2.5.6.1 NAME 'alias' DESC
'Standard ObjectClass' SUP 'top' MUST ( objectclass $
aliasedObjectName ) MAY ( aci ) )")
Error: 6: MUST ( objectclass $ aliasedObjectName ) MAY ( aci )
)Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.2/site-packages/ldap/schema.py", line
43, in str2objectclass
return
ldap.functions._ldap_function_call(_ldap.str2objectclass,schema_element_str)
File "/usr/lib/python2.2/site-packages/ldap/__init__.py", line
56, in _ldap_function_call
result = apply(func,args,kwargs)
SystemError: NULL result without error in PyObject_Call
>>>
Well, I'd like to see some better error reporting with the help of
exceptions. Anyway, there is a debug output text "Error: 6: .."
produced. Don't know whether by the OpenLDAP libs or some code in
Modules/schema.c.
Hans, before I ask on the OpenLDAP list what this error means can
you please review your code and test with the string above? Make
sure to bring your CVS working tree in sync!
Ciao, Michael.
|
|
From: Jacek K. <ja...@bn...> - 2002-07-28 09:07:04
|
On Sat, Jul 27, 2002 at 10:38:35PM +0200, Michael Str=F6der wrote:
> Well, I'd like to see some better error reporting with the help of=20
> exceptions. Anyway, there is a debug output text "Error: 6: .."=20
> produced. Don't know whether by the OpenLDAP libs or some code in=20
> Modules/schema.c.
Here is a fragment of Modules/schema.c:
o =3D ldap_str2objectclass( oc_string, &ret, &errp, flag);
if (ret) {
printf("Error: %d: %s", ret, errp);
/* XXX Do error handling... */
return NULL;
}
It seems ldap_str2objectclass() fails, but no proper python-way error
hadnling is done. The fix should be easy (just replace=20
/* XXX Do error handling... */ with exception object initialization).
Unfortunately I am not able to do it now (lack of time) :-(
Greets,
Jacek
|
|
From: David L. <dav...@it...> - 2002-07-28 11:41:47
|
On Sun, 28 Jul 2002, Jacek Konieczny typed thusly:
> On Sat, Jul 27, 2002 at 10:38:35PM +0200, Michael Str=F6der wrote:
> It seems ldap_str2objectclass() fails, but no proper python-way error
> hadnling is done. The fix should be easy (just replace
> /* XXX Do error handling... */ with exception object initialization).
> Unfortunately I am not able to do it now (lack of time) :-(
is ret important?
is a subclassed error the right thing to do?
Index: schema.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/python-ldap/python-ldap/Modules/schema.c,v
retrieving revision 1.2
diff -u -r1.2 schema.c
--- schema.c=094 May 2002 18:14:48 -0000=091.2
+++ schema.c=0928 Jul 2002 11:39:00 -0000
@@ -8,6 +8,8 @@
#include "schema.h"
#include "ldap_schema.h"
+static PyObject *SchemaError;
+
/*
This utility function takes a null delimited C array of (null
delimited) C strings, creates its python equivalent and returns a
@@ -91,8 +93,7 @@
=09return NULL;
o =3D ldap_str2objectclass( oc_string, &ret, &errp, flag);
if (ret) {
- printf("Error: %d: %s", ret, errp);
- /* XXX Do error handling... */
+ PyErr_SetString(SchemaError, errp);
return NULL;
}
@@ -139,8 +140,7 @@
return NULL;
a =3D ldap_str2attributetype( at_string, &ret, &errp, flag);
if (ret) {
- printf("Error: %d: %s", ret, errp);
- /* XXX Do error handling... */
+ PyErr_SetString(SchemaError, errp);
return NULL;
}
@@ -208,8 +208,7 @@
return NULL;
s =3D ldap_str2syntax(syn_string, &ret, &errp, flag);
if (ret) {
- printf("Error: %d: %s", ret, errp);
- /* XXX Do error handling... */
+ PyErr_SetString(SchemaError, errp);
return NULL;
}
py_ret =3D PyList_New(4);
@@ -243,8 +242,7 @@
return NULL;
m =3D ldap_str2matchingrule(mr_string, &ret, &errp, flag);
if (ret) {
- printf("Error: %d: %s", ret, errp);
- /* XXX Do error handling... */
+ PyErr_SetString(SchemaError, errp);
return NULL;
}
py_ret =3D PyList_New(6);
@@ -285,5 +283,8 @@
void
LDAPinit_schema( PyObject* d ) {
+ SchemaError =3D PyErr_NewException("ldap.SchemaError",
+=09LDAPexception_class, NULL);
+ PyDict_SetItemString(d, "SchemaError", SchemaError);
LDAPadd_methods( d, methods );
}
--=20
David Leonard Dav...@it...
Dept of Inf. Tech. and Elec. Engg _ Ph:+61 404 844 850
The University of Queensland |+| http://www.itee.uq.edu.au/~leonard/
QLD 4072 AUSTRALIA ~` '~ B73CD65FBEF4C089B79A8EBADF1A932F13E=
A0FC8
|
|
From: <mi...@st...> - 2002-07-30 13:48:41
|
David Leonard wrote: > is ret important? Yes, I think so. > is a subclassed error the right thing to do? Frankly I'd prefer to check the numerical error code in ldap.schema.str2objectclass() and the other wrapper functions and raise Python-declared exceptions instead of create the exception instances in Modules/schema.c. This is much easier to maintain (at least for me) and the schema exception class can be sub-classed etc. Ciao, Michael. |
|
From: <mi...@st...> - 2002-07-30 20:23:09
|
Michael Str=F6der wrote:
> Frankly I'd prefer to check the numerical error code in=20
> ldap.schema.str2objectclass() and the other wrapper functions and raise=
=20
> Python-declared exceptions instead of create the exception instances in=
=20
> Modules/schema.c.
How about this approach assuming _ldap.str2objectclass() only=20
returns a error code as integer in case of an error?
------------------------- snip -------------------------
class SchemaError(Exception): pass
class SCHERR_OUTOFMEM(SchemaError): pass
class SCHERR_UNEXPTOKEN(SchemaError): pass
class SCHERR_NOLEFTPAREN(SchemaError): pass
class SCHERR_NORIGHTPAREN(SchemaError): pass
class SCHERR_NODIGIT(SchemaError): pass
class SCHERR_BADNAME(SchemaError): pass
class SCHERR_BADDESC(SchemaError): pass
class SCHERR_BADSUP(SchemaError): pass
class SCHERR_DUPOPT(SchemaError): pass
class SCHERR_EMPTY(SchemaError): pass
ERRCODE2SCHERR =3D {
1:SCHERR_OUTOFMEM
2:SCHERR_UNEXPTOKEN
3:SCHERR_NOLEFTPAREN
4:SCHERR_NORIGHTPAREN
5:SCHERR_NODIGIT
6:SCHERR_BADNAME
7:SCHERR_BADDESC
8:SCHERR_BADSUP
9:SCHERR_DUPOPT
10:SCHERR_EMPTY
}
# Wrapper functions to serialize calls into OpenLDAP libs with
# a module-wide thread lock
def str2objectclass(schema_element_str,schema_allow=3D0):
r =3D ldap.functions._ldap_function_call(
_ldap.str2objectclass,schema_element_str,schema_allow
)
if type(res)=3D=3Dtype(0):
raise ERRCODE2SCHERR.get(r,SchemaError)(
r,schema_element_str
)
else:
assert type(res)=3D=3Dtype(())
return r
------------------------- snip -------------------------
Ciao, Michael.
|
|
From: Hans A. <Han...@Ph...> - 2002-07-31 14:23:40
|
On Dienstag, 30. Juli 2002 22:20, Michael Ströder wrote: > Michael Ströder wrote: > > Frankly I'd prefer to check the numerical error code in > > ldap.schema.str2objectclass() and the other wrapper functions and > > raise Python-declared exceptions instead of create the exception > > instances in Modules/schema.c. > > How about this approach assuming _ldap.str2objectclass() only > returns a error code as integer in case of an error? [...] This a really easy approach to the problem. Should I commit that patch? Hans -- Han...@Ph... |
|
From: <mi...@st...> - 2002-07-31 14:47:40
|
Hans Aschauer wrote: > On Dienstag, 30. Juli 2002 22:20, Michael Str=F6der wrote: >=20 >>Michael Str=F6der wrote: >> >>>Frankly I'd prefer to check the numerical error code in >>>ldap.schema.str2objectclass() and the other wrapper functions and >>>raise Python-declared exceptions instead of create the exception >>>instances in Modules/schema.c. >> >>How about this approach assuming _ldap.str2objectclass() only >>returns a error code as integer in case of an error? >=20 >=20 > [...] >=20 > This a really easy approach to the problem. Should I commit that patch?= Yes! Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-08-01 09:09:23
|
On Mittwoch, 31. Juli 2002 16:46, Michael Ströder wrote: > Hans Aschauer wrote: > > This a really easy approach to the problem. Should I commit that > > patch? > > Yes! Done. Including the patch for schema.py. It works for me, but, as always, please test it! Hans -- Han...@Ph... |
|
From: <mi...@st...> - 2002-08-01 09:41:47
|
Hans Aschauer wrote: > On Mittwoch, 31. Juli 2002 16:46, Michael Str=F6der wrote: >=20 >>Hans Aschauer wrote: >> >>>This a really easy approach to the problem. Should I commit that >>>patch? >> >>Yes! >=20 > Done. Including the patch for schema.py. It works for me, but, as=20 > always, please test it! Seems to work. The assertion assert res in ERRCODE2SCHERR.keys() is not necessary since we use ERRCODE2SCHERR.get(res,SchemaError)=20 to use the base-class in case of unknown error code. I expect the=20 OpenLDAP project to add new error codes without us keeping up with=20 it. ;-) Ciao, Michael. |
|
From: <mi...@st...> - 2002-08-02 14:23:33
|
Dear list members, please review the schema API in Lib/ldap/schema.py. There's also a demo script Demo/schema.py. I've tested it with OpenLDAP 2.0.x and 2.1.x, an Innosoft server and some Siemens Dir/X servers I found. It still chokes on Netscape/iPlanet/Sun Directory Servers etc. with non-numeric "OID" but now with a nice exception. Up to now I only addressed the issues with finding the mandantory and optional attribute types to a given list of object classes. It's still far away from being a complete schema support. Please comment! Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-08-07 19:50:52
|
i'm trying to run the Demo/schema.py script and steppping through it =
with=20
pdb there's an oddity i see, which prevents the script from running=20
successfully:
- ldapobject.py line 548 (in method search_subschemasubentry) a search =
is=20
done on the passed-in DN to retrieve the value for the attribute=20
"subschemaSubentry". the search is successful and returns...
[('dc=3Dvts,dc=3Dzope,dc=3Dcom', {'subschemaSubentry': =
['cn=3DSubschema']})]
- in line 555 there is the following call:
e =3D ldap.cidict.cidict(r[0][1]) (r is the result shown above)
- at this point "e" has the following value:
{'subschemasubentry': ['cn=3DSubschema']} (notice: "subschemasubentry" =
is=20
all lowercase now)
- now the problem is in line 556 in the call...
search_subschemasubentry_dn =3D e.get('subschemaSubentry', [None])[] =20
(notice: it expects camelcase again...)
... at this point the result is None and the script dies a little later.
jens
On Friday, August 2, 2002, at 10:23 , Michael Str=F6der wrote:
> Dear list members,
>
> please review the schema API in Lib/ldap/schema.py. There's also a =
demo=20
> script Demo/schema.py.
>
> I've tested it with OpenLDAP 2.0.x and 2.1.x, an Innosoft server and =
some=20
> Siemens Dir/X servers I found. It still chokes on Netscape/iPlanet/Sun=20=
> Directory Servers etc. with non-numeric "OID" but now with a nice=20
> exception.
>
> Up to now I only addressed the issues with finding the mandantory and=20=
> optional attribute types to a given list of object classes. It's still=20=
> far away from being a complete schema support.
>
> Please comment!
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
|
|
From: <mi...@st...> - 2002-08-07 20:04:26
|
Jens Vagelpohl wrote:
> i'm trying to run the Demo/schema.py script and steppping through it
> with pdb there's an oddity i see, which prevents the script from running
> successfully:
>
> - ldapobject.py line 548 (in method search_subschemasubentry) a search
> is done on the passed-in DN to retrieve the value for the attribute
> "subschemaSubentry". the search is successful and returns...
>
> [('dc=vts,dc=zope,dc=com', {'subschemaSubentry': ['cn=Subschema']})]
>
> - in line 555 there is the following call:
>
> e = ldap.cidict.cidict(r[0][1]) (r is the result shown above)
>
> - at this point "e" has the following value:
>
> {'subschemasubentry': ['cn=Subschema']} (notice: "subschemasubentry" is
> all lowercase now)
>
> - now the problem is in line 556 in the call...
>
> search_subschemasubentry_dn = e.get('subschemaSubentry', [None])[]
Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim
that there is no bug. But I can't see a problem.
> ... at this point the result is None and the script dies a little later.
"Dies a little later" is a little bit unspecific. Can you please
provide the traceback and mention which LDAP server you're using
for testing?
Ciao, Michael.
|
|
From: Jens V. <je...@zo...> - 2002-08-07 21:14:47
|
here's the traceback:: [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py=20 ldap://waldorf.zope.com/dc=3Dvts,dc=3Dzope,dc=3Dcom Time elapsed search sub schema sub entry: 0.018 Traceback (most recent call last): File "schema.py", line 29, in ? subschemasubentry_entry =3D l.read_subschemasubentry_s( File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", = line=20 584, in read_subschemasubentry_s attrs File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", = line=20 422, in search_s return = self.search_st(base,scope,filterstr,attrlist,attrsonly,timeout=3D -1) File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", = line=20 425, in search_st msgid =3D self.search(base,scope,filterstr,attrlist,attrsonly) File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", = line=20 419, in search return=20 self._ldap_call(self._l.search,base,scope,filterstr,attrlist,attrsonly) File "/usr/local/lib/python2.1/site-packages/ldap/ldapobject.py", = line=20 95, in _ldap_call result =3D apply(func,args,kwargs) TypeError: argument 1 must be string, not None [dhcp182:src/python-ldap-HEAD/Demo] jens% the "error" is that this call on ldapobject.py line 557 "e =3D=20 ldap.cidict.cidict(r[0][1])" all of a sudden lowercases the key=20 "subschemaSubentry" from the original search result. so when the code=20 tries to determine the value of that key, and asks for the *camelcased*=20= version, it will get None back: "e.get('subschemaSubentry',[None])[0]"=20= because "e" only has a key "subschemasubentry". if "e" contains the=20 original camelcased key then the script continues successfully. jens On Wednesday, August 7, 2002, at 04:03 , Michael Str=F6der wrote: > Jens Vagelpohl wrote: >> i'm trying to run the Demo/schema.py script and steppping through it=20= >> with pdb there's an oddity i see, which prevents the script from = running=20 >> successfully: >> - ldapobject.py line 548 (in method search_subschemasubentry) a = search=20 >> is done on the passed-in DN to retrieve the value for the attribute=20= >> "subschemaSubentry". the search is successful and returns... >> [('dc=3Dvts,dc=3Dzope,dc=3Dcom', {'subschemaSubentry': = ['cn=3DSubschema']})] >> - in line 555 there is the following call: >> e =3D ldap.cidict.cidict(r[0][1]) (r is the result shown above) >> - at this point "e" has the following value: >> {'subschemasubentry': ['cn=3DSubschema']} (notice: = "subschemasubentry" is=20 >> all lowercase now) >> - now the problem is in line 556 in the call... >> search_subschemasubentry_dn =3D e.get('subschemaSubentry', [None])[] > > Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim = that=20 > there is no bug. But I can't see a problem. > >> ... at this point the result is None and the script dies a little = later. > > "Dies a little later" is a little bit unspecific. Can you please = provide=20 > the traceback and mention which LDAP server you're using for testing? > > Ciao, Michael. > |
|
From: <mi...@st...> - 2002-08-08 07:47:36
|
Jens Vagelpohl wrote: > > [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py > ldap://waldorf.zope.com/dc=vts,dc=zope,dc=com Does the entry dc=vts,dc=zope,dc=com exist? What LDAP server is running on waldorf.zope.com:389? Any niftly access control in place? Not sure how to handle ldap.NO_SUCH_OBJECT during first search in search_subschemasubentry_s(). I've checked in a version yesterday 2002/08/07 20:25:26 which handles that (and some weird servers returning ldap.UNDEFINED_TYPE) slightly different. > [dhcp182:src/python-ldap-HEAD/Demo] jens% python2.1 schema.py > ldap://waldorf.zope.com/dc=vts,dc=zope,dc=com > Time elapsed search sub schema sub entry: 0.018 > Traceback (most recent call last): > File "schema.py", line 29, in ? > subschemasubentry_entry = l.read_subschemasubentry_s( > [..] > TypeError: argument 1 must be string, not None Well, off course here the Demo script is flawed... ;-) l.read_subschemasubentry_s() should not be called if the result was None (=> sync CVS). Ciao, Michael. |
|
From: Jens V. <je...@zo...> - 2002-08-07 21:22:07
|
the problem is in the cidict class. when you call "get" then the method=20=
"get" on UserDict gets called - which has no lowercasing of the name you=20=
ask for.
jens
On Wednesday, August 7, 2002, at 04:03 , Michael Str=F6der wrote:
> Jens Vagelpohl wrote:
>> i'm trying to run the Demo/schema.py script and steppping through it=20=
>> with pdb there's an oddity i see, which prevents the script from =
running=20
>> successfully:
>> - ldapobject.py line 548 (in method search_subschemasubentry) a =
search=20
>> is done on the passed-in DN to retrieve the value for the attribute=20=
>> "subschemaSubentry". the search is successful and returns...
>> [('dc=3Dvts,dc=3Dzope,dc=3Dcom', {'subschemaSubentry': =
['cn=3DSubschema']})]
>> - in line 555 there is the following call:
>> e =3D ldap.cidict.cidict(r[0][1]) (r is the result shown above)
>> - at this point "e" has the following value:
>> {'subschemasubentry': ['cn=3DSubschema']} (notice: =
"subschemasubentry" is=20
>> all lowercase now)
>> - now the problem is in line 556 in the call...
>> search_subschemasubentry_dn =3D e.get('subschemaSubentry', [None])[]
>
> Yes, no problem since ldap.cidict.cidict is used. I wouldn't claim =
that=20
> there is no bug. But I can't see a problem.
>
>> ... at this point the result is None and the script dies a little =
later.
>
> "Dies a little later" is a little bit unspecific. Can you please =
provide=20
> the traceback and mention which LDAP server you're using for testing?
>
> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
|
|
From: <mi...@st...> - 2002-08-08 07:28:40
|
Jens Vagelpohl wrote:
> the problem is in the cidict class. when you call "get" then the method
> "get" on UserDict gets called - which has no lowercasing of the name you
> ask for.
Nothing wrong with that.
See UserDict.py:
def get(self, key, failobj=None):
if not self.has_key(key):
return failobj
return self[key]
Method UserDict.get() calls self.__getitem__(). I've added two
test cases to ldap.cidict as proof that this works correctly.
Ciao, Michael.
|
|
From: Hans A. <Han...@Ph...> - 2002-07-29 12:10:44
|
On Samstag, 27. Juli 2002 22:38, Michael Ströder wrote: > HI! > > ldap.schema.str2objectclass() fails when parsing the following > string (from Netscape DS 4.16SP1 sub schema sub entry): > > "( 2.5.6.1 NAME 'alias' DESC 'Standard ObjectClass' SUP 'top' MUST > ( objectclass $ aliasedObjectName ) MAY ( aci ) )" > > This schema string does not look unusual to me but... But it does to me. The "SUP 'top'" should be "SUP top" (as far as I understand RFC 2252, Chapter 4: the argument of sup is oids, which does not include the quotes...). Just tried it, and it worked. One way to solve this problem (if netscape DS always returns such 'wrong' sub schema sub entries) would be to expose the flags argument of the C function to the python API, which allows to be more liberal in parsing the strings. The flags are defined in ldap_schema.h: #define LDAP_SCHEMA_ALLOW_NONE 0x00 /* Strict parsing */ #define LDAP_SCHEMA_ALLOW_NO_OID 0x01 /* Allow missing oid */ #define LDAP_SCHEMA_ALLOW_QUOTED 0x02 /* Allow bogus extra quotes */ #define LDAP_SCHEMA_ALLOW_DESCR 0x04 /* Allow descr instead of OID */ #define LDAP_SCHEMA_ALLOW_DESCR_PREFIX 0x08 /* Allow descr as OID prefix */ #define LDAP_SCHEMA_ALLOW_OID_MACRO 0x10 /* Allow OID macros in slapd */ #define LDAP_SCHEMA_ALLOW_ALL 0x1f /* Be very liberal in parsing */ At present, the flags are set to 0x00... [incomplete and 'bad' python error] > Well, I'd like to see some better error reporting with the help of > exceptions. Anyway, there is a debug output text "Error: 6: .." > produced. Don't know whether by the OpenLDAP libs or some code in > Modules/schema.c. Sorry that I still have not implemented correct error handling... The return codes are (again from ldap_schema.h): /* Codes for parsing errors */ #define LDAP_SCHERR_OUTOFMEM 1 #define LDAP_SCHERR_UNEXPTOKEN 2 #define LDAP_SCHERR_NOLEFTPAREN 3 #define LDAP_SCHERR_NORIGHTPAREN 4 #define LDAP_SCHERR_NODIGIT 5 #define LDAP_SCHERR_BADNAME 6 #define LDAP_SCHERR_BADDESC 7 #define LDAP_SCHERR_BADSUP 8 #define LDAP_SCHERR_DUPOPT 9 #define LDAP_SCHERR_EMPTY 10 > Hans, before I ask on the OpenLDAP list what this error means can > you please review your code and test with the string above? Make > sure to bring your CVS working tree in sync! Ok, I can try to fix things along the lines of David's patch (but including the error code). It will however take me at least one week. Hans -- Han...@Ph... |
|
From: <mi...@st...> - 2002-07-29 12:36:47
|
Hans Aschauer wrote: > > One way to solve this problem (if netscape DS always returns such > 'wrong' sub schema sub entries) would be to expose the flags argument > of the C function to the python API, which allows to be more liberal in > parsing the strings. We definitely need this! > Ok, I can try to fix things along the lines of David's patch (but > including the error code). It will however take me at least one week. Go for it. Ciao, Michael. |
|
From: <mi...@st...> - 2002-07-29 16:47:38
|
Michael Str=F6der wrote: > Hans Aschauer wrote: >=20 >> One way to solve this problem (if netscape DS always returns such=20 >> 'wrong' sub schema sub entries) would be to expose the flags argument = >> of the C function to the python API, which allows to be more liberal=20 >> in parsing the strings. >=20 > We definitely need this! I changed the API to pass around this flags integer. I did other=20 changes. Please bring your CVS working tree in sync. Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-07-30 07:13:27
|
On Montag, 29. Juli 2002 18:46, Michael Ströder wrote: > I changed the API to pass around this flags integer. I did other > changes. I made changes to schema.c and schema.py in order to actually pass the flag to the C functions: >>> a = "( 2.5.6.1 NAME 'alias' DESC 'Standard ObjectClass' SUP 'top' MUST ( objectclass $ aliasedObjectName ) MAY ( aci ) )" >>> ldap.schema.str2objectclass(a,15) ['2.5.6.1', ['alias'], 'Standard ObjectClass', 0, ['top'], 1, ['objectclass', 'aliasedObjectName'], ['aci'], []] >>> ldap.schema.str2objectclass(a) Error: 6: MUST ( objectclass $ aliasedObjectName ) MAY ( aci ) )Traceback (most recent call last): [...] Seems to work. Please test. Hans -- Han...@Ph... |
|
From: <mi...@st...> - 2002-07-30 09:44:02
|
Hans Aschauer wrote: > On Montag, 29. Juli 2002 18:46, Michael Str=F6der wrote: >=20 > I made changes to schema.c and schema.py in order to actually pass the = > flag to the C functions: > [...] > Seems to work. Please test. Thanks. It gets further but still chokes with schema of Netscape=20 DS 4.16SP1 on some object classes although called with=20 schema_allow=3D31. Can you point me to where are the error codes described in OpenLDAP? You can check yourself by invoking recently checked in Demo/schema.py: $ python Demo/schema.py ldap://memberdir.netscape.com/ memberdir.netscape.com is a iPlanet-Directory/5.0 B2001.109.0903. Feel free to use web2ldap's [ConnInfo] feature to find out more=20 about demo servers mentioned there. It also does not work with www.nldap.com (Novell eDirectory 8.7). $ python Demo/schema.py ldap://www.nldap.com/ *** Schema from 'cn=3Dschema' Error: 5: ( smssmdrclass-oid NAME 'sMSSMDRClass' DESC 'Standard=20 ObjectClass' SUP resource STRUCTURAL MAY ( status $ Version $=20 sAPName $ sMSRegisteredService $ sMSProtocolAddress ) X-NDS_NAME=20 'SMS SMDR Class' X-NDS_NOT_CONTAINER '1' )Traceback (most recent=20 call last): File "Demo/schema.py", line 27, in ? schema =3D=20 ldap.schema.subSchema(subschemasubentry_entry,schema_allow=3D31) File "/usr/lib/python2.2/site-packages/ldap/schema.py", line=20 154, in __init__ se =3D SCHEMA_CLASS_MAPPING[attr_type](attr_value,schema_allow) File "/usr/lib/python2.2/site-packages/ldap/schema.py", line=20 47, in __init__ ( File "/usr/lib/python2.2/site-packages/ldap/schema.py", line=20 20, in str2objectclass return=20 ldap.functions._ldap_function_call(_ldap.str2objectclass,schema_element_s= tr,schema_allow) File "/usr/lib/python2.2/site-packages/ldap/__init__.py", line=20 56, in _ldap_function_call result =3D apply(func,args,kwargs) SystemError: NULL result without error in PyObject_Call Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-07-30 10:13:52
|
On Dienstag, 30. Juli 2002 11:42, Michael Ströder wrote: > Can you point me to where are the error codes described in OpenLDAP? In ldap_schema.h: ---------------------------------------------- /* Codes for parsing errors */ #define LDAP_SCHERR_OUTOFMEM 1 #define LDAP_SCHERR_UNEXPTOKEN 2 #define LDAP_SCHERR_NOLEFTPAREN 3 #define LDAP_SCHERR_NORIGHTPAREN 4 #define LDAP_SCHERR_NODIGIT 5 #define LDAP_SCHERR_BADNAME 6 #define LDAP_SCHERR_BADDESC 7 #define LDAP_SCHERR_BADSUP 8 #define LDAP_SCHERR_DUPOPT 9 #define LDAP_SCHERR_EMPTY 10 ---------------------------------------------- > You can check yourself by invoking recently checked in > Demo/schema.py: > > $ python Demo/schema.py ldap://memberdir.netscape.com/ The problem is that they do not provide OID's where there must be OID's: objectClasses: ( inetsubscriber-oid NAME 'inetSubscriber' SUP top AUXILIARY MAY ( inetSubscriberAccountId $ inetSubscriberChallenge $ inetSubscriberResponse ) X-ORIGIN 'Nortel subscriber interoperability') In this case, the offending item is "inetsubscriber-oid", which is expected to be a numeric OID. In this case, the openldap schema parser is not liberal enough to allow such a string. There's not much that we can do in this case (except for writing our own parser, or filing a "bug" report, and hoping the best...) Of course, if we already had better error handling, we could also use some heuristics after an exception is caught ;-) Hans -- Han...@Ph... |
|
From: <mi...@st...> - 2002-07-30 12:01:05
|
Hans Aschauer wrote: > On Dienstag, 30. Juli 2002 11:42, Michael Str=F6der wrote: >=20 >>You can check yourself by invoking recently checked in >>Demo/schema.py: >> >>$ python Demo/schema.py ldap://memberdir.netscape.com/ >=20 > The problem is that they do not provide OID's where there must be OID's= : > objectClasses: ( inetsubscriber-oid Yes, that's what i suspected too. But I thought one of #define LDAP_SCHEMA_ALLOW_DESCR 0x04 /* Allow descr instead of OID */ #define LDAP_SCHEMA_ALLOW_DESCR_PREFIX 0x08 /* Allow descr as OID prefix */ #define LDAP_SCHEMA_ALLOW_OID_MACRO 0x10 /* Allow OID macros in slapd */ would do the trick. > There's not much that we=20 > can do in this case (except for writing our own parser, Jacek already has a pure-Python parser in his curses-based LDAP=20 client... > or filing a=20 > "bug" report, and hoping the best...) I suspect that Kurt will not accept that but I will try to file an=20 issue report anyway. > Of course, if we already had better error handling, we could also use=20 > some heuristics after an exception is caught ;-) No. Ciao, Michael. |
|
From: <mi...@st...> - 2002-07-30 22:38:48
|
Hans Aschauer wrote: > On Dienstag, 30. Juli 2002 11:42, Michael Str=F6der wrote: >=20 > The problem is that they do not provide OID's where there must be OID's= : It should be accepted with schema_allow=3D31. See discussion for issue filed in OpenLDAP's ITS: http://www.OpenLDAP.org/its/index.cgi?findid=3D1996 Please cross-check that the client library ALLOW flags are=20 "properly enabled". Ciao, Michael. |
|
From: Hans A. <Han...@Ph...> - 2002-07-31 07:51:49
|
On Mittwoch, 31. Juli 2002 00:37, Michael Ströder wrote: > It should be accepted with schema_allow=31. > > See discussion for issue filed in OpenLDAP's ITS: > > http://www.OpenLDAP.org/its/index.cgi?findid=1996 > > Please cross-check that the client library ALLOW flags are > "properly enabled". I did some printf - debugging, and I think it is a real openldap bug: >>> ldap.schema.str2objectclass(b,31) Error: 5: ( nsHost-oid NAME 'nsHost' DESC 'iPlanet defined objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'iPlanet' ). flag = 31 ^^^^^^^^^ The "flag = 31" is printf'ed by the C wrapper code, using the same variable that is passed to the openldap - function. This is a small C test code in order to exclude errors from the python side (maybe you could post it to the ITS): ---------------------------------------------------------------------- #include "ldap_schema.h" char *oclass = "( nsHost-oid NAME 'nsHost' DESC 'iPlanet defined objectclass' SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'iPlanet' )"; const char *errp; int ret = 0; int main(){ ldap_str2objectclass(oclass, &ret, &errp, LDAP_SCHEMA_ALLOW_ALL); if (ret) printf ("Error: %d: %s\n", ret, errp); } ---------------------------------------------------------------------- compile it with 'gcc schema_test.c -lldap -o schema_test' and have fun ;-) Hans -- Han...@Ph... |
Thanks for helping keep SourceForge clean.
X