Hi,
I am trying to import an ldiff file while I created using slapcat on another server. Now when I try to use slapadd to import the ldiff file to my new server, I am getting an error for a last line in the ldiff file i.e. could not parse entry line:1333... The entry on that line is something about "Timestamp" . Previously during the trial I did get the could not parse entry but I figured out that those were because of the whitespaces(emptylines) in the ldiff file, so I removed all of those, but now its is the last line which is not getting parsed by slapadd. I tried having one white space (one empty line) after the last line and with no empty line and ending the file at the last line, but to no avail.
Can any one please point me to the right direction??
Thanks & Regards Naufal
Naufal Sheikh wrote:
Hi,
I am trying to import an ldiff file while I created using slapcat on another server. Now when I try to use slapadd to import the ldiff file to my new server, I am getting an error for a last line in the ldiff file i.e. could not parse entry line:1333... The entry on that line is something about "Timestamp" . Previously during the trial I did get the could not parse entry but I figured out that those were because of the whitespaces(emptylines) in the ldiff file, so I removed all of those, but now its is the last line which is not getting parsed by slapadd. I tried having one white space (one empty line) after the last line and with no empty line and ending the file at the last line, but to no avail.
Can any one please point me to the right direction??
Thanks & Regards Naufal
What was the *exact* error message?
Gavin,
Sorry for late reply, got stuck. Following is the error message I am getting.
slapadd: could not parse entry (line=1344465)
line 134465 is the last line in the ldiff file and it says:
modifyTimestamp: 20070927152001Z
On 10/11/07, Gavin Henry ghenry@suretecsystems.com wrote:
Naufal Sheikh wrote:
Hi,
I am trying to import an ldiff file while I created using slapcat on another server. Now when I try to use slapadd to import the ldiff file to my new server, I am getting an error for a last line in the ldiff file i.e. could not parse entry line:1333... The entry on that line is something about "Timestamp" . Previously during the trial I did get the could not parse entry but I figured out that those were because of the whitespaces(emptylines) in the ldiff file, so I removed all of those, but now its is the last line which is not getting parsed by slapadd. I tried having one white space (one empty line) after the last line and with no empty line and ending the file at the last line, but to no avail.
Can any one please point me to the right direction??
Thanks & Regards Naufal
What was the *exact* error message?
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry@suretecsystems.com
Open Source. Open Solutions(tm).
Naufal Sheikh wrote:
Gavin,
Sorry for late reply, got stuck. Following is the error message I am getting.
slapadd: could not parse entry (line=1344465)
line 134465 is the last line in the ldiff file and it says:
modifyTimestamp: 20070927152001Z
slapadd up to OpenLDAP 2.3 misleadingly reports the last line of an entry for parse errors occurring anywhere within that entry. Please post the whole entry.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
I am sorry I did not get you. You want me to post the whole ldiff file or the output of slapadd using the debug switch. Below is the last line of slapadd output when run with debug switch.
str2entry: entry -1 has multiple DNs "o=trac" and "cn=Administrators,o=trac" slapadd: could not parse entry (line=1344465).
Tha last enttry of ldiff file is :
#id=0000b263 dn: uid=larry4372,o=trac subscribedate: 2007-09-27 11:20 sn: Stern uid: larry4372 tracfedquota: 20000 mail: lmstern@verizon.net lastModifiedTime: 2007-09-27 11:20 maxqueries: 20 affiliation: lawyer clientorg: lawyer sitemaxusers: 1 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: tracperson telephoneNumber: 212-925-6863 termsagree: 1 lastModifiedBy: larry4372 middlename:: IA== cn: Lawrence Stern userPassword:: Nzg5OQ== regsite: WEB postalAddress: $$$ givenName: Lawrence clearpassword: 7899 mailPreferenceOption: 1 regdate: 2007-09-27 11:20 structuralObjectClass: tracperson entryUUID: dc5ec5a6-0158-102c-976b-9052d08550b0 creatorsName: cn=nsadmin createTimestamp: 20070927152001Z entryCSN: 20070927152001Z#000001#00#000000 modifiersName: cn=nsadmin modifyTimestamp: 20070927152001Z
Regards
On 10/12/07, Pierangelo Masarati ando@sys-net.it wrote:
Naufal Sheikh wrote:
Gavin,
Sorry for late reply, got stuck. Following is the error message I am
getting.
slapadd: could not parse entry (line=1344465)
line 134465 is the last line in the ldiff file and it says:
modifyTimestamp: 20070927152001Z
slapadd up to OpenLDAP 2.3 misleadingly reports the last line of an entry for parse errors occurring anywhere within that entry. Please post the whole entry.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Naufal Sheikh wrote:
I am sorry I did not get you. You want me to post the whole ldiff file or the output of slapadd using the debug switch. Below is the last line of slapadd output when run with debug switch.
I meant: only the entry that ends at the line reported in the error message issued by slapadd.
str2entry: entry -1 has multiple DNs "o=trac" and "cn=Administrators,o=trac" slapadd: could not parse entry (line=1344465).
Sounds odd. You didn't report what version of OpenLDAP software you're using; assuming a recent 2.3, it seems that two consecutive entries are not separated by a blank line, thus resulting in "dn:" appearing twice...
Tha last enttry of ldiff file is :
#id=0000b263 dn: uid=larry4372,o=trac subscribedate: 2007-09-27 11:20 sn: Stern uid: larry4372 tracfedquota: 20000 mail: lmstern@verizon.net lastModifiedTime: 2007-09-27 11:20 maxqueries: 20 affiliation: lawyer clientorg: lawyer sitemaxusers: 1 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: tracperson telephoneNumber: 212-925-6863 termsagree: 1 lastModifiedBy: larry4372 middlename:: IA== cn: Lawrence Stern userPassword:: Nzg5OQ== regsite: WEB postalAddress: $$$ givenName: Lawrence clearpassword: 7899 mailPreferenceOption: 1 regdate: 2007-09-27 11:20 structuralObjectClass: tracperson entryUUID: dc5ec5a6-0158-102c-976b-9052d08550b0 creatorsName: cn=nsadmin createTimestamp: 20070927152001Z entryCSN: 20070927152001Z#000001#00#000000 modifiersName: cn=nsadmin modifyTimestamp: 20070927152001Z
... but the entry above has neither of the two DNs reported by the error message. Assuming your naming context is "o=trac" and your LDIF starts with the suffix entry "o=trac" and the second entry is "cn=Administrators,o=trac", I suspect your file has no blanks at all separating entries (or slapadd for any reason misinterprets them; e.g. '\r\n'?), and the error is reported at line 1344465 but it actually occurs much earlier. Of course, assuming the crystal ball I just borrowed from Raphael works...
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=1313) slapadd shutdown: initiated ====> bdb_cache_release_all slapadd shutdown: freeing system resources.
Regards
On 10/12/07, Pierangelo Masarati ando@sys-net.it wrote:
Naufal Sheikh wrote:
I am sorry I did not get you. You want me to post the whole ldiff file or the output of slapadd using the debug switch. Below is the last line of slapadd output when run with debug switch.
I meant: only the entry that ends at the line reported in the error message issued by slapadd.
str2entry: entry -1 has multiple DNs "o=trac" and
"cn=Administrators,o=trac"
slapadd: could not parse entry (line=1344465).
Sounds odd. You didn't report what version of OpenLDAP software you're using; assuming a recent 2.3, it seems that two consecutive entries are not separated by a blank line, thus resulting in "dn:" appearing twice...
Tha last enttry of ldiff file is :
#id=0000b263 dn: uid=larry4372,o=trac subscribedate: 2007-09-27 11:20 sn: Stern uid: larry4372 tracfedquota: 20000 mail: lmstern@verizon.net lastModifiedTime: 2007-09-27 11:20 maxqueries: 20 affiliation: lawyer clientorg: lawyer sitemaxusers: 1 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: tracperson telephoneNumber: 212-925-6863 termsagree: 1 lastModifiedBy: larry4372 middlename:: IA== cn: Lawrence Stern userPassword:: Nzg5OQ== regsite: WEB postalAddress: $$$ givenName: Lawrence clearpassword: 7899 mailPreferenceOption: 1 regdate: 2007-09-27 11:20 structuralObjectClass: tracperson entryUUID: dc5ec5a6-0158-102c-976b-9052d08550b0 creatorsName: cn=nsadmin createTimestamp: 20070927152001Z entryCSN: 20070927152001Z#000001#00#000000 modifiersName: cn=nsadmin modifyTimestamp: 20070927152001Z
... but the entry above has neither of the two DNs reported by the error message. Assuming your naming context is "o=trac" and your LDIF starts with the suffix entry "o=trac" and the second entry is "cn=Administrators,o=trac", I suspect your file has no blanks at all separating entries (or slapadd for any reason misinterprets them; e.g. '\r\n'?), and the error is reported at line 1344465 but it actually occurs much earlier. Of course, assuming the crystal ball I just borrowed from Raphael works...
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
"Naufal Sheikh" naufalzamir@gmail.com writes:
Ok I tried again running the slapadd with the original ldap file with -d and here it goes:
[...]
str2entry: invalid value for attribute objectClass (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=1313) slapadd shutdown: initiated ====> bdb_cache_release_all slapadd shutdown: freeing system resources.
What is the description of object class tracperson? It seems that the object class type definition has no OID, probabely only a descriptive name.
-Dieter
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 1.3.6.1.4.1.1466.115.121.1.38) 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.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
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 1.3.6.1.4.1.1466.115.12 1.1.15) 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!!!
Naufal
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 1.3.6.1.4.1.1466.115.121.1.38) 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.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati skrev, on 12-10-2007 19:15:
[...}
str2entry: entry -1 has multiple DNs "o=trac" and "cn=Administrators,o=trac" slapadd: could not parse entry (line=1344465).
Sounds odd. You didn't report what version of OpenLDAP software you're using; assuming a recent 2.3, it seems that two consecutive entries are not separated by a blank line, thus resulting in "dn:" appearing twice...
Chappy has already reported he deleted all blank lines in his ldif file. Go figure ...
--Tonni
Naufal Sheikh skrev, on 12-10-2007 19:02:
Sorry for late reply, got stuck. Following is the error message I am
getting.
slapadd: could not parse entry (line=1344465)
line 134465 is the last line in the ldiff file and it says:
modifyTimestamp: 20070927152001Z
slapadd up to OpenLDAP 2.3 misleadingly reports the last line of an entry for parse errors occurring anywhere within that entry. Please post the whole entry.
You have to go back to your original post: "The entry on that line is something about "Timestamp" . Previously during the trial I did get the could not parse entry but I figured out that those were because of the whitespaces(emptylines) in the ldiff file, so I removed all of those" and undo that.
"whitespaces(emptylines)" between each record in an ldif file are necessary, otherwise you have a useless ldif file. Your problem is with ACLs. The rootdn should be doing this modify.
--Tonni
Tony Earnshaw wrote:
Naufal Sheikh skrev, on 12-10-2007 19:02:
Sorry for late reply, got stuck. Following is the error message I am
getting.
slapadd: could not parse entry (line=1344465)
line 134465 is the last line in the ldiff file and it says:
modifyTimestamp: 20070927152001Z
slapadd up to OpenLDAP 2.3 misleadingly reports the last line of an entry for parse errors occurring anywhere within that entry. Please post the whole entry.
You have to go back to your original post: "The entry on that line is something about "Timestamp" . Previously during the trial I did get the could not parse entry but I figured out that those were because of the whitespaces(emptylines) in the ldiff file, so I removed all of those" and undo that.
"whitespaces(emptylines)" between each record in an ldif file are necessary, otherwise you have a useless ldif file. Your problem is with ACLs. The rootdn should be doing this modify.
Yes, I initially missed that point, but later we clarified it, and I think he restored them. In fact, he's now getting a different error. It seems that he's facing with the Well Known Migrating From SunOne/iPlanet/whatever to OpenLDAP (WKMFSO, (C)) problem. I can tell my awk scripts for this purpose are becoming way and way refined, and I'm happy about that because it means more and more people are migrating ;).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org