Re: LDAP import

Michael Gettes <gettes@xxxxxxxxx> · Tue, 15 Apr 2014 13:15:00 -0400

no, you could get rid of 7.1.  if you read the deployment docs, you should look at it from the perspective of running one 389 server as o=Company configured to chain to another 389 server where the real data is in ou=Company,dc=hq,blah,blah
if all this is too much for you, then you may want to stay away from it or hire a consultant to assist.

/mrg

On Apr 15, 2014, at 1:11 PM, Herb Burnswell <herbert.burnswell@xxxxxxxxx> wrote:

Michael - Thank you for your reply.

1. You are correct, I just did the update to version 1.2.11.15.

2.  Regarding chaining, I read though a bit about it but wanted to confirm.  Does the original instance (7.1 in my case) need to continue to be up and running for chaining to work?  I ask because I need to decommission the servers that are currently running the 7.1 DS instance.

I appreciate the help,

Herb

Michael R. Gettes:
I have 2 questions for you…

1.  Why are you going to 1.2.6 and not 1.2.11 which is the current maint release?

2.  Have you looked into Chaining?  It would appear to me it would be a better fit to have a new
tree and chain the old tree into the new tree.  The admin guide has all the info and the deployment
guide also discusses various strategies.

/mrg

On Mon, Apr 14, 2014 at 3:32 PM, Herb Burnswell <herbert.burnswell@xxxxxxxxx> wrote:

I just wanted to bump this inquiry.

Is this a unique issue?  Is there a way to export/import below the:

o=CompanyA
ou=CompanyA,dn=hq,dn=example,dn=com

Level to avoid the inconsistency?

Please let me know if I'm thinking about this incorrectly...

TIA,

Herb

On Thu, Apr 10, 2014 at 6:06 PM, Herb Burnswell <herbert.burnswell@xxxxxxxxx> wrote:

To add to this:
I have gone into the DS 7.1 Directory Server Console on the Configuration tab and drilled down to:

Data -
     - o=CompanyA
          -CompanyA = right click, export database

This creates the ldif file that looks like exactly what I need but the import into the new 389 1.2.6 fails with:

ldapmodify -a -D "cn=Administrators" -W -f /tmp/companyA.ldif -p 389 -h localhost

Enter LDAP Password: 
adding new entry "o=CompanyA"
ldap_add: No such object (32)

Which makes sense.

Again, any assistance is greatly appreciated.

Herb

On Thu, Apr 10, 2014 at 5:51 PM, Herb Burnswell <herbert.burnswell@xxxxxxxxx> wrote:

Thanks again for the reply Dustin.  I think I'm a little over my head here.  I have cleared out all the previous data from ou=CompanyA,dn=hq,dn=example,dn=com by going into the Directory Server console, selecting the 'Directory' tab and deleting and re-adding CompanyA under hq folder.  I can connect to it via LDAPadmin, but as you can imagine, no data.

Here's my confusion, the old LDAP implementation from which I need to import the data is Fedora DS 7.1 and the new LDAP implementation is 389 1.2.6.  So, the old one is much older and is has a different 'structure'.  

In 7.1 in the Directory server console, Configuration tab, I have:
Data -
     - o=NetscapeRoot
          - NetscapRoot
     - o=CompanyA
          - o=CompanyA
In the 389 1.2.6 Directory server console, Configuration tab, I have:
Data -

     - dc=hq,dc=example,dc=com
          - userRoot
     - o=netscaproot
          - NetscapRoot
So, in DS 7.1 the top level is o=CompanyA
In 389 1.2.6 the top level is ou=CompanyA,dn=hq,dn=example,dn=com
The new 'top level' is what I'd like it to be but I need everything underneath these 'top levels' to be identical.  My question is how can I import the DS 7.1 o=CompanyA into the 389 1.2.6 ou=CompanyA,dn=hq,dn=example,dn=com?

Hopefully I have not completely confused the situation here.  I greatly appreciate any suggestions on how to get this working properly.

TIA,
Herb

Dustin Rice:
The better way would be using a tool on the OS that's like db2ldif 
(pretty sure most netscape LDAP deriviatives come with these).

When you do a ldapsearch like that the server won't send along some 
fields (password being one of them). If you run the db2ldif it'll spit 
out an ldif file then you should be able to import it with something 
like ldif2db or just an ldapadd.

Herb:

Dustin thanks for the reply.
I would need everything in:
o=companyA dc=hq,dc=example,dc=com
Everything appears to be imported as needed except the password issue.  If I reset the passwords in the new implementation it's fine but that won't work with 100's of users.

Is this:
ldapsearch -b "o=companyA" -D "dc=hq,dc=example,dc=com" -h original_system > output.ldif

an acceptable way of exporting everything including passwords for users or is there a better way?
Thanks again,

Herb 

Dustin Rice:
Well, schema would be like, the list of fields whereas it looks like you 
might be doing a dump/load of users/groups?

On 04/10/2014 01:17 PM, Herb Burnswell wrote:
> All,
>
> I'm attempting to import an LDAP schema (is that the correct term?) 
> from one LDAP implementation to another and it appears that I may be 
> doing it incorrectly.  I created a ldif file for import as:
>
> ldapsearch -b "o=companyA" -D "dc=hq,dc=example,dc=com" -h 
> original_system > output.ldif
>
> I then used the GUI in the new LDAP implementation to import the ldif 
> file.  Everything seemed to work find as I have the entire tree but 
> there appears to be a problem with passwords.
>
> Am I missing the passwords for users with this export to ldif file? 
>  What is the proper procedure to import all information from a schema 
> (is that the correct term?) to import into a new LDAP implementation?
>
> Thanks in advance for any assistance,
>
> Herb
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users