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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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 *>* https://admin.fedoraproject.org/mailman/listinfo/389-users https://admin.fedoraproject.org/mailman/listinfo/389-users *
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.
On 04/10/2014 02:24 PM, Herb Burnswell wrote:
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 />/ https://admin.fedoraproject.org/mailman/listinfo/389-users /
--
Dustin Rice UNIX System Administrator - CIS Portland State University =====================================
On Thu, Apr 10, 2014 at 1:17 PM, Herb Burnswell <herbert.burnswell@gmail.com mailto:herbert.burnswell@gmail.com> 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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 *>* https://admin.fedoraproject.org/mailman/listinfo/389-users https://admin.fedoraproject.org/mailman/listinfo/389-users*
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@gmail.com
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=CompanyAIn the 389 1.2.6 Directory server console, Configuration tab, I have:
Data -
- dc=hq,dc=example,dc=com - userRoot - o=netscaproot - NetscapRootSo, 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 *>* https://admin.fedoraproject.org/mailman/listinfo/389-users https://admin.fedoraproject.org/mailman/listinfo/389-users*
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@gmail.com
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@gmail.com> 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=CompanyAIn the 389 1.2.6 Directory server console, Configuration tab, I have:
Data -
- dc=hq,dc=example,dc=com - userRoot - o=netscaproot - NetscapRootSo, 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 *>* https://admin.fedoraproject.org/mailman/listinfo/389-users https://admin.fedoraproject.org/mailman/listinfo/389-users*
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 Apr 14, 2014, at 18:32, Herb Burnswell herbert.burnswell@gmail.com 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@gmail.com 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@gmail.com 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 - NetscapRootSo, 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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@gmail.com
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@gmail.com> 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@gmail.com> 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=CompanyAIn the 389 1.2.6 Directory server console, Configuration tab, I have:
Data -
- dc=hq,dc=example,dc=com - userRoot - o=netscaproot - NetscapRootSo, 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 *>* https://admin.fedoraproject.org/mailman/listinfo/389-users https://admin.fedoraproject.org/mailman/listinfo/389-users*
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@gmail.com wrote:
Michael - Thank you for your reply.
You are correct, I just did the update to version 1.2.11.15.
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…
Why are you going to 1.2.6 and not 1.2.11 which is the current maint release?
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@gmail.com 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@gmail.com 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@gmail.com 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 - NetscapRootSo, 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 15/04/14 08:32, Herb Burnswell 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?
The easiest way to do this is to filter the ldif file through an editor such as sed.
$ sed 's/o=CompanyA/ou=CompanyA,dn=hq,dn=example,dn=com/' <export.ldif
import.ldif
There may be some subtleties, but this should work.
cheers
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@gmail.com mailto:herbert.burnswell@gmail.com> 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@gmail.com mailto:herbert.burnswell@gmail.com> 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 />/ https://admin.fedoraproject.org/mailman/listinfo/389-users/
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
- -- Dr Robin Garner Technology Services Southern Cross University P: +61 2 6620 3281 M: +61 418 619 500 http://cs.anu.edu.au/people/robin.garner/
389-users@lists.fedoraproject.org
-
Dustin Rice -
Herb Burnswell -
Michael Gettes -
Michael R. Gettes -
Robin Garner