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
