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