Oscar A. Valdez wrote: > El vie, 02-02-2007 a las 13:27 -0800, Noriko Hosoi escribi?: > >> Oscar A. Valdez wrote: >> >>> The backup was created and restored with db2bak. Would this imply that >>> the backup contained the Admin Server's ou=duraflex.com.sv" and that it >>> was imported into a Directory Server with "ou=duraflex"? >>> >>> >>> >> That's most likely what happened to your server... >> >> >>> Again, as I said, I'm willing to try changing the Admin Server over to >>> "ou=duraflex". I'll appreciate your pointers on how to do it. >>> >>> >>> >> Well, I'd try the following, but since we haven't tested it, we don't >> know how it ends up... >> 1. shutdown the admin server and console >> 2. go to your <server_root>/admin-serv/config >> 3. replace "ou=duraflex.com.sv" with "ou=duraflex" in all the files in >> the directory >> 4. restart the admin server, then console >> 5. login on the console >> >> Hope it goes fine... >> > > I think it went in the right direction. After logging in, I got two > ou's in the console's default view: "duraflex.com.sv" and "duraflex". I > deleted the first one. The second one can be expanded to show the server > "pendragon", which in turn can be expanded to show an "Administration > Server" and a "Directory Server". However, when I click the first, it > tries but fails to download and install server component admserv10.jar, > and when I click the second, it tries but fails to install server > component ds10.jar. > > In addition, the admin-serv error log has lines like this: > > [crit] populate_tasks_from_server(): Unable to search > [cn=admin-serv-pendragon, cn=Fedora Administration Server, cn=Server > Group, cn=pendragon.duraflex.com.sv, ou=duraflex, o=NetscapeRoot] for > LDAPConnection [pendragon.duraflex.com.sv:389] > > Hmm, that does not sound right... How about resuming the admin-serv/config files and changing the Directory Server side? 1. shutdown the admin server and console 2. go to your <server_root>/admin-serv/config 3. replace back to "ou=duraflex.com.sv" in all the files in the directory 4. go to your config directory server instance dir: <server_root>/slapd-<id> 5. export DIT under o=netscaperoot: $ db2ldif -n NetscapeRoot ldiffile: <server_root>/slapd-<id>/ldif/<date_time>.ldif [...] - export NetscapeRoot: Processed 103 entries (100%). 6. edit the <date_time>.ldif file: replace "ou=duraflex" with "ou=duraflex.com.sv" The word may be split across two lines. Please be careful if you substitute the word automatically. 7. stop the directory server: stop-slapd 8. import the <date_time>.ldif file: ldif2db -n NetscapeRoot -i <server_root>/slapd-<id>/ldif/<date_time>.ldif 9. restart the directory server: start-slapd 10. restart the admin server, then console 11. login on the console If this does not work, you'd better re-install the server and import your data to the new server. 1. on the current directory server, export the data into ldif files. go to your <server_root>/slapd-<id>; run "db2ldif -n <backend>" for each backend (e.g., userRoot) EXCEPT NetscapeRoot 2. install new FDS 3. go to the <new_server_root>/slapd-<id> 4. stop the directory server 5. import the ldif files from the current directory server repeat "ldif2db -n <backend> -i <server_root>/slapd-<id>/<date_time>.ldif" for each <date_time>.ldif file exported in (1). 6. start the directory server Thanks, --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070205/3f2cbbba/attachment.bin
