Rich,
Migration completed, SSL enabled, console is working! I used the 25changefedorato389.pl as a guide. In NetscapeRoot.ldif: + converted all cn=Fedora to cn=389 + converted all fedora to 389 (this converted the jar files and nicknames).
Thank you for your help,
Craig Swanson
On 04/28/2010 10:09 AM, Rich Megginson wrote:
Craig Swanson wrote:
Rich,
Thanks for the prompt reply. Ok, I'll not assume that SSL is the problem.
My setup is: SSL is enabled in its original configuration on the source. updated autofs and mozilla ldif files. db2ldif to export the userRoot and NetscapeRoot databases. Modified just the source /opt/fedora-ds/admin-serv/config/adm.conf and local.conf to replace cn=Fedora with cn=389
The migration fails during migration of the Administration Server with: check_and_add_entry: Entry not found cn=Tasks, cn=admin-serv-punch, cn=389 Administration Server, cn=Server Group, cn=punch.midwest-tool.com, ou=midwest-tool.com, o=NetscapeRoot error No such object
I think the main problem is that migration does not convert Fedora to 389. That's why you get the errors like +++check_and_add_entry: Entry not found cn=389 Administration Server, cn=Server Group, cn=punch.midwest-tool.com, ou=midwest-tool.com, o=NetscapeRoot error No such object
Because the migrated NetscapeRoot.ldif file has cn=Fedora Administration Server
There is an upgrade scriptlet - /usr/share/dirsrv/updates-admin/25changefedorato389.pl - if you are a perl hacker, you could probably take that and use it to fix NetscapeRoot.ldif before starting migration.
If not, then your best bet is to dump the old NetscapeRoot to ldif and fix it manually - be sure to use db2ldif -U so that the LDIF lines won't be wrapped - if the lines are wrapped, it will make finding all occurrances of "Fedora" quite difficult if not impossible with something like sed/awk/perl.
I'll send the debug log directly to you.
Craig Swanson
389-users@lists.fedoraproject.org