[Date Prev][Date Next] [Chronological] [Thread] [Top]
FW: Netscape DS 4.1 LDIF into OpenLDAP 2.0.11

To: "'openldap-software@OpenLDAP.org'" <openldap-software@OpenLDAP.org>
Subject: FW: Netscape DS 4.1 LDIF into OpenLDAP 2.0.11
From: "Doyon, Jean-Francois" <Jean-Francois.Doyon@CCRS.NRCan.gc.ca>
Date: Fri, 27 Jul 2001 14:15:47 -0400
The mystery continues!

I've checked hex dumps of my ldif file, and ONLY "\n"'s appear in the file,
nothing else. So I guess weird or different codes isn't the problem.

I also tried generating the ldiff using "ldapsearch" instead of the Netscape
Console, but, bloody hell, same problem.

Some people have mentionned the "oc" I have in the DN ... It is defined in
my own schema file.

Here is the definition for the attribute:

attributetype ( oc-oid NAME 'oc' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE )

The problem here is that oc allways equals "OTHER" and nothing else, so why
would one work and not the other? It was defined in the Netscape DS 4.1
config file as:

attribute oc                   oc-oid               cis
single

Help!!!!!!!!

J.F.

> ----------
> From: 	Doyon,
> Jean-Francois[SMTP:Jean-Francois.Doyon@CCRS.NRCan.gc.ca]
> Sent: 	Thursday, July 26, 2001 11:20 AM
> To: 	'openldap-software@OpenLDAP.org'
> Subject: 	FW: Netscape DS 4.1 LDIF into OpenLDAP 2.0.11
> 
> Hello again!
> 
> Well I'm still having no luck.  I tried using dos2unix on the ldif, that
> didn't help.  So I tried dumping the ldif on a UNIX and then moving to a
> UNIX, still the exact same problem.  I tried manually adding/removing
> blank
> lines and line returns (Backspace, enter) and so on using both vim and
> pico,
> and that didn't chane anything either ...
> 
> I tried moving the "dn:" line to a different place within the block, but
> that didn't help either, I got the same error (with the SAME line number
> ??).
> 
> I tried doing a unix2dos on it (Then nothing worked!) and then convert it
> back with dos2unix, same problem.
> 
> Does anybody know a Linux text editor that has a "reveal codes" kind of
> concept in it so I can try and hunt down bad \n's or \r's or something?
> Anybody have any other idea?  I'm completely confused :(
> Seems it shouldn't be this hard, that's why there's a standard for LDIF
> files!
> 
> How about other tools that could help me? I tried getting ldapdiff but it
> wouldn't compile on my system.
> 
> Thanks again!
> J.F.
> 
> > ----------
> > From: 	Doyon,
> > Jean-Francois[SMTP:Jean-Francois.Doyon@CCRS.NRCan.gc.ca]
> > Sent: 	Wednesday, July 25, 2001 4:58 PM
> > To: 	'openldap-software@OpenLDAP.org'
> > Subject: 	Netscape DS 4.1 LDIF into OpenLDAP 2.0.11
> > 
> > Hello,
> > 
> > I am investigating the possibility of migrating from Netscape Directory
> > Server 4.1 to OpenLDAP.  This first thing I did was to try and migrate
> the
> > data itself, by exporting to an LDIF file and then trying to "slapadd"
> it
> > into the OpenLDAP server.
> > 
> > It seems however that the slapadd does NOT like the LDIF I'm feeding it.
> > I
> > did edit the ldif some to remove the "aci" lines (Which slapadd choked
> on,
> > eventhough I compiled using --with-aci, but I don't need them anymore
> > anyways), and a couple of unused OU's, but that's about it.
> > 
> > I get the following error when running "slapadd -f
> > /usr/local/etc/openldap/slapd.conf -l cgdi.ldif -v -d 1":
> > 
> > ...
> > <= index_entry_add( 297, "uid=RMike,oc=OTHER,c=CA,ou=Users,o=CGDI" )
> > success
> > => dn2id_add( "UID=RMIKE,OC=OTHER,C=CA,OU=USERS,O=CGDI", 297 )
> > => ldbm_cache_open( "/usr/local/var/openldap-ldbm/dn2id.dbb", 7, 600 )
> > <= ldbm_cache_open (cache 3)
> > <= dn2id_add 0
> > added: "uid=RMike,oc=OTHER,c=CA,ou=Users,o=CGDI" (00000129)
> > => str2entry
> > str2entry: invalid value for syntax 1.3.6.1.4.1.1466.115.121.1.12
> > slapadd: could not parse entry (line=91)
> > => ldbm_cache_open( "/usr/local/var/openldap-ldbm/nextid.dbb", 7, 600 )
> > <= ldbm_cache_open (cache 1)
> > slapadd shutdown: initiated
> > ldbm backend syncing
> > ...
> > 
> > Line 91 is the blank line before the "uid=JDoyon" entry (Right after the
> > uid=RMike entry, which works fine) ... If I delete that entry, it'll go
> > by,
> > and choke on some other entry further down. I can't seem to pick out
> what
> > it's choking on though.  It complains about the syntax of the DN, but
> they
> > look pretty straightforward and simple to me!
> > 
> > I am using some custom defined attributetypes and objectsclasses, as you
> > will note below, but I as of yet have no reason to suspect a schema
> > definition problem.
> > 
> > Anyone? Any help would be greatly appreciated! Thanks!
> > 
> > Jean-François Doyon
> > Internet Service Development and Systems Support
> > GeoAccess Division
> > Canadian Center for Remote Sensing
> > Natural Resources Canada
> > http://atlas.gc.ca
> > Phone: (613) 992-4902
> > Fax: (613) 947-2410
> > 
> > 
> > Here's the top of the LDIF file (With sensitive data removed):
> > 
> > dn: o=CGDI
> > objectclass: top
> > objectclass: organization
> > o: CGDI
> > 
> > dn: ou=Groups, o=CGDI
> > objectclass: top
> > objectclass: organizationalunit
> > ou: Groups
> > 
> > dn: ou=People, o=CGDI
> > objectclass: top
> > objectclass: organizationalunit
> > ou: People
> > 
> > dn: ou=Special Users,o=CGDI
> > objectclass: top
> > objectclass: organizationalUnit
> > ou: Special Users
> > description: Special Administrative Accounts
> > 
> > dn: ou=Users,o=CGDI
> > ou: Users
> > objectclass: top
> > objectclass: organizationalunit
> > 
> > dn: c=CA,ou=Users,o=CGDI
> > c: CA
> > objectclass: top
> > objectclass: country
> > 
> > dn: oc=OTHER,c=CA,ou=Users,o=CGDI
> > oc: OTHER
> > objectclass: top
> > objectclass: organizationalclass
> > 
> > dn: uid=RMike,oc=OTHER,c=CA,ou=Users,o=CGDI
> > cgdijunkmail: YES
> > authenticationlevel: EMAIL
> > title: Executive
> > cgdiregistersecret: <removed> 
> > cgdiemail: SimpleNTclient-YES
> > mail: <removed>
> > objectclass: top
> > objectclass: person
> > objectclass: organizationalPerson
> > objectclass: inetorgperson
> > objectclass: cgdiuser
> > cn: Robson Mike
> > uid: RMike
> > cgdiregfrom: SimpleNTclient
> > st: ON
> > givenname: Robson
> > sn: Mike
> > userpassword: <removed>
> > cgdilastlogin: 19991220
> > l: Ottawa
> > cgdilanguage: en
> > businesscategory: Geomatics
> > cgdiauthno: 3
> > 
> > dn: uid=JDoyon,oc=OTHER,c=CA,ou=Users,o=CGDI
> > authenticationlevel: EMAIL
> > cgdiregistersecret: <removed>
> > cgdiemail: Secret-YES
> > cgdiemail: Atlas-NO
> > cgdiemail: GeoGratis-NO
> > cgdiemail: CCAD-NO   
> > objectclass: top
> > objectclass: person
> > objectclass: organizationalPerson
> > objectclass: inetorgperson
> > objectclass: cgdiuser
> > uid: JDoyon
> > cgdiregfrom: Atlas
> > cgdilanguage: en 
> > userpassword: <removed>
> > cn: Jean-Francois Doyon
> > sn: Doyon
> > cgdijunkmail: NO
> > businesscategory: Government - Federal
> > givenname: Jean-Francois
> > mail: <removed>
> > seealso: http://www.nrcan.gc.ca
> > telephonenumber: <removed>
> > facsimiletelephonenumber: <removed>
> > st: ON
> > cgdilastlogin: 20010716
> > cgdiauthno: 75
> > 
> > dn: uid=bmcleod,oc=OTHER,c=CA,ou=Users,o=CGDI
> > cgdijunkmail: NO
> > authenticationlevel: EMAIL
> > cgdiregistersecret: <removed>
> > cgdiemail: GeoGratis-NO
> > mail: <removed>
> > objectclass: top
> > objectclass: person
> > objectclass: organizationalPerson
> > objectclass: inetorgperson
> > objectclass: cgdiuser
> > cn: brian mcleod   
> > uid: bmcleod
> > cgdiregfrom: GeoGratis
> > st: ON
> > givenname: brian
> > sn: mcleod
> > userpassword: <removed>
> > cgdilastlogin: 20000124
> > cgdilanguage: en 
> > businesscategory: Government - Federal
> > cgdiauthno: 1
> > 
> > Jean-François Doyon
> > Internet Service Development and Systems Support
> > GeoAccess Division
> > Canadian Center for Remote Sensing
> > Natural Resources Canada
> > http://atlas.gc.ca
> > Phone: (613) 992-4902
> > Fax: (613) 947-2410
> > 
>
Prev by Date: Re: Keeping track of lastModifiedTime and lastModifiedBy
Next by Date: Re: Keeping track of lastModifiedTime and lastModifiedBy
Index(es):
- Chronological
- Thread