Regarding the timeout issue, I had the exact same problem with my console. It turned out
to be a reverse DNS lookup failure for the remote console url I was using. I corrected DNS
and all was good (using host entries does not work either). If you want to narrow it down,
try connecting to the console on the local server (localhost) at your console port and see
if it's fast or not. Don't forget to check your firewalls also. Sorry I can't
help on your other questions...
-----Original Message-----
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Gerrard Geldenhuis
Sent: Friday, November 19, 2010 6:04 AM
To: 'General discussion list for the 389 Directory server project.'
Subject: Re: [389-users] Problems with accessing console
Importance: Low
From: 389-users-bounces(a)lists.fedoraproject.org
[mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Gerrard Geldenhuis
Sent: 19 November 2010 11:34
To: General discussion list for the 389 Directory server project.
(389-users(a)lists.fedoraproject.org)
Subject: [389-users] Problems with accessing console
Hi
I have a bit of a problem with a few 389 servers I recently build...
Firstly how I got there:
I added 4 additional servers to our infrastructure, the servers had 389 installed and
configured but as a separate set of 4 servers completely stand >alone. I removed
everything with remove-ds-admin -f -y before I added the 4 servers to our main
infrastructure.
We use a shared (multimaster netscapedb setup), setup in the following way:
Enable changelog on new server ( aka master-new)
Create netscapedb root suffix
enable master replica for netscape db
iniatiate db from another master (aka master01)
run register-ds-admin.pl on master-new
The problem is that I am not able to access the admin console.
If I run the console from master01 and try to access the admin console on master-new, it
takes a very long time to load and when I then try and >view anything in the
configuration tab I get timeouts. I can open the directory server for master-new remotely
so that seems to be working fine.
My questions:
It seems remove-ds-admin.pl does not cleanly remove any previously set admin settings for
the admin server, would you agree or is it expected >to not remove admin server
settings.
How can I fix this, comparing /etc/dirsrv/admin-serv/local.conf to another working server
brings up loads and loads of differences. My first >thought is to fix this file. I
compared to different working servers and they seem similar enough for me to attempt this.
I am just not sure if this >would have other effects not yet known. Is this a recommend
course of action?
My other option is to start again, but I don't know how to delete a server cleanly
from netscapedb if I use a shared MM netscapedb database. Is >there a recommended way
to do this?
Regards
Some more information, if I try to access the Adminstration server locally from master-new
I get the following error message:
Failed to install a localcopy of 389-admin-1.1.jar or one of its supporting files.
Now before you shout package differences, that was one of the first things I checked and
they are exactly the same on all servers old and new.
I have tried to fix the config but I still get the same errors.
If I try to access the admin server from another console run from master01 then I
don't get the above missing package error but I do get a the following:
URL:
HTTP response timeout
So there is probably a missing string for the URL in the netscapedb... any ideas where it
would be?
Regards
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
This electronic message transmission contains information from Black Hills Corporation,
its affiliate or subsidiary, which may be confidential or privileged. The information is
intended to be for the use of the individual or entity named above. If you are not the
intended recipient, be aware the disclosure, copying, distribution or use of the contents
of this information is prohibited. If you received this electronic transmission in error,
please reply to sender immediately; then delete this message without copying it or further
reading.