[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: lCould not parse line... slapadd

Hello everyone,

Well I have been able to resolve the main issue. I had spelled "inlcude schemafile" instead of include. Donno why the slapd started despite of wrong speeling. I found this script slaptest which told me the issue when I ran it. 

This time when I ran slapadsd it ran perfecty for a wrong time showing me that it is adding the entries in verbose mode till it again gave me an error :

str2entry: invalid value for attribute clientorg (syntax
slapadd: could not parse entry (line=99365)

Below is the corrsponding entry in ldiff file:

dn: uid=tmseeb,o=trac
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: tracperson
cn: Trow Seeb
uid: tmseeb
userPassword:: e1NIQX14ZGI5b2ZHajZLaTJXVG8wR3J6QTg1bE16ekE9
clearpassword: cristin
givenName: Trow
middlename: Milford
sn: Seeb
clientorg: No real organization
affiliation: community
mailPreferenceOption: 0
l: Podunk
st: NY
postalCode: 12345
regsite: FBI
regdate: 05AUG97:23:43:15
regip: usr10-39.dial.roc.frontiernet.net
structuralObjectClass: tracperson
entryUUID: 532fc900-74d8-102a-86eb-90f8caf384a9
creatorsName: cn=nsadmin
modifiersName: cn=nsadmin
createTimestamp: 20060511012215Z
modifyTimestamp: 20060511012215Z
entryCSN: 20060511012215Z#000003#00#000000

I have checked other entries with clientorg, and some have the name of the organization while some have sort of hash. Now the slapadd has passed many entries with clientorg defined, wots the problem with this?

Pierangelo thanks, your explanantion about tracperson being odd pointed me to the right direction!!!


On 10/13/07, Pierangelo Masarati <ando@sys-net.it> wrote:
 Naufal Sheikh wrote:
> Ok I tried again running the slapadd with the original ldap file with
> -d and here it goes:
> # id=00000008
> dn: uid=djdaley,o=trac
> objectClass: top
> objectClass: person 
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: tracperson
> cn: Douglas Daley
> uid: djdaley
> userPassword:: e1NIQX1UVnZKa1FVbDgxM1ltMEE4WjQ4Yk8veFZmM0E9 
> clearpassword: 2915
> givenName: Douglas
> middlename: J
> sn: Daley
> clientorg: SUNY ESF
> affiliation: educator
> l: Syracuse
> st: NY
> postalCode: 13210
> regsite: IRS 
> regdate: 25MAR97:13:28:40
> regip: athena.esf.edu
> mailPreferenceOption: 2
> modifiersName: cn=nsadmin
> modifyTimestamp: 20000320195137Z
> structuralObjectClass: tracperson 
> entryUUI>>> dnPrettyNormal: <uid=nsadmin,o=trac>
> <<< dnPrettyNormal: <uid=nsadmin,o=trac>, <uid=nsadmin,o=trac>
> str2entry: invalid value for attribute objectClass (syntax 
> slapadd: could not parse entry (line=1313)
> slapadd shutdown: initiated
> ====> bdb_cache_release_all
> slapadd shutdown: freeing system resources.

There's an invalid value of the objectClass attribute; assuming you
loaded the standard schema files distributed with OpenLDAP (in this
case, core.schema and inetorgperson.schema); the only unusual value is 
"tracperson".  I infer it is a custom class; is it defined anywhere in
your slapd.conf(5)?  If it's not, you need to define it according to
slapd.conf(5) (and Section 4.1.1 of RFC4512).  The same is needed for 
all opbjectClasses and attributes used in your LDIF that are not already
defined in the standard schema.  One way to proceed consists in:

- getting the schema from the DSA you got the LDIF from (e.g. ldapsearch 
the subschemaSubentry for objectClasses attributetypes);

- sanitize it (namely: remove those definitions that are already present
in OpenLDAP, and modify the remaining to make sure they comply with
specifications; in many cases I've seen implementations with incorrect 
matching rules, or missing OIDs, or invalid inheritance chains, and
things like that)

- load it into your slapd.conf(5)

It sounds like a pain (and it is) but it will eventually pay back in
terms of data consistency. 


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it