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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/389-users
