Accessing the RHDS console from multiple servers.

[Richard J Harper]

I have just set up A multi-mastered Red Hat Directory Server (8.0) environment and I've hit a bit of a problem ...

Should it be possible to access the console gui from more than one server? i.e:

host1# /usr/bin/redhat-idm-console -a https://localhost:9830

or

host1# /usr/bin/redhat-idm-console -a https://host2:9830

or

host2# /usr/bin/redhat-idm-console -a https://host1:9830

etc.

... otherwise it would seem that if one host is lost, then all access to the gui would be lost.

(I currently have two masters, one 11v1 and one 11v3)

[Steven E. Protter]

Shalom,

If there is an X windows based GUI.

ssh -X hostname command_line

This will give you the gui remotely.

I've worked with this product and that does work.

You could create a floating IP address that follows the active master server around and hit https://floatingip:9830

You could probably use Service Guard to manage to floating IP.

SEP

[Richard J Harper]

This is the first time I have done anything with RHDS, so please forgive my ignorance.

I cannot see anything in the docs to say whether the gui should only run on one server or if it should be accessable on any of the masters. If I try to access the console locally on my second master, the session appears to hang and has to be killed. Is this by design and the console can only reside on one server (if so, can it be 'failed over' to another server), or is my current configuration a bit screwy?

cheers,

Richard

[Weltman, Ulf]

Unless I've missed some detail about your configuration, it is is common usage. Yes, the administration console can be run on any host in your topology where you have it installed, and then point it to any administration server in your topology. In fact, the depot contains fileset RedHatDirSvr.gui which you can install if you wanted to have a host that will only be used to administer the directory server on other hosts.

As to the console hanging on one of your hosts, I'm not sure. We've seen some issues when the use of SSL is mismatched, i.e. using a http:// URL against an administration server that has SSL configured. Also, if you have something like ipfilter enabled and blocking (without rejecting) the administration server port, that could appear as a hang.

You can test whether the administration server is responding by using a regular web browser. Point it to the administration URL, e.g. http://host1:9830
You should see a short page with links to the administration express, etc.

Depending on how far the administration console gets before it freezes, you may also find something relevant in debug logging by using the "-D" option, like this:
/opt/dirsrv/bin/redhat-idm-console -D

[Richard J Harper]

I'll clarify the configuration ...

I am setting up RHDS as a test prior to rolling it out across the company. The current isolated environment consists of three servers (two 11v1 and one 11v3) connected through a switch, there is no DNS, just host files.

host1 is an 11v3 server and is a master server. I can only open the console by running "/opt/dirsrv/bin/redhat-idm-console -a https://localhost:9830" on this host

host2 is an 11v1 server and and has multi-master replication of userroot and netscape root with host1. If I run opt/dirsrv/bin/redhat-idm-console -D -a https://host1:9830 then I see the following:

host2# console -D -a https://host1:9830
Red-Hat-Management-Console/1.1.0 B2008.248.043
CommManager> New CommRecord (https://host1:9830/admin-serv/authenticate)

And the session just hangs until it is killed. This also happens if IP addresses are used or if I attempt to start the the console on the localhost
connected through a switch, there is no DNS, just host files and nslookup returns the correct information.

[Weltman, Ulf]

One detail that is unusual about your configuration is that you're replicating the NetscapeRoot backend. When you ran setup-ds-admin.pl on each host, what did you answer to the question "Do you want to register this software with an existing configuration directory server"?

Regarding the hang, does it not even show you the splash screen or the login dialog (with User ID, Password, and Admin URL fields)?

Also, which version of Java (/opt/java1.5/jre/bin/java -version) are you using on the troubled host?

[Richard J Harper]

Hi,

I tried to add a configuration server whilst running setup-ds-admin.pl, but this caused the admin server to be unstartable ... if such a word exists. I got the following error from the script:

Updating admpw . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Updating the configuration for the httpd engine . . .
Starting admin server . . .
output: /opt/dirsrv/sbin/start-ds-admin[76]: 2905 Memory fault(coredump)
Could not start the admin server. Error: 35584
Failed to create and configure the admin server
Exiting . . .


The same error and coredump where generated if I then tried to start the admin server from the command line.

The hang happens after the login details have been entered, so the splash screen and X11 stuff is ok.

I believe the JRE version is 1.50.11

[Weltman, Ulf]

Regarding the admin server crash, can you verify that Apache is not using old NSPR libraries, and the version is not B.2.0.59.00? Please reference:
http://docs.hp.com/en/J4258-90068/ch02s01.html#v1036344

Regarding the hang, are you using SSL between config DS and admin server? Check /etc/opt/dirsrv/admin-serv/adm.conf, if the "ldapurl" directive is using a "ldaps://" prefix, then you are using SSL. If so, please edit the file and change it to "ldap://" and the trailing port to your plain (e.g. 389) LDAP port. SSL between admin server and config DS will result in the admin console freezeing at the "Initializing" phase of logging in. The fix for this is planned for the next release.

The lack of SSL between config DS and admin server is a security concern when the config DS and admin server are on separate hosts, that is, if you responded YES to the "Do you want to register this software with an existing configuration directory server" question during set up. Therefore I would suggest reinstalling, if needed, and responding NO so that you will have a config DS instance on each host. You will not be able to replicate the NetscapeRoot backend easily with this configuration; instead, I would suggest that you run db2bak on the NetscapeRoot backend after you've configured your instances.

[Richard J Harper]

The NSPR fix was applied and the Apache version is B.2.0.58.00, I have been through the document that you linked to.

My masters here are insistent that all communications are over SSL, so anywhere it can be enabled, it is.

I have replicated NetscapeRoot, is this not the correct way of getting round this problem? Does db2bak do something different?

[Weltman, Ulf]

No, I suggested db2bak so that you have a back up, which you wouldn't have if you didn't replicate NetscapeRoot. I'm not sure what problem you're trying to solve by replicating NetscapeRoot. The o=NetscapeRoot data can be remote, that is what you accomplish by answering YES to "Do you want to register this software with an existing configuration directory server" during setup. If you say NO, then a NetscapeRoot backend will be created in the instance you're creating on the local host, and that instance becomes a "configuration directory server" for itself and any other instances created on the local host.

Does your policy require SSL to be used even for local communication, e.g. to localhost:389? Have you had opportunity to verify whether the bug I mentioned is the problem by following the second paragraph in my previous post?

[Richard J Harper]

The bug you mentioned is evident, I could answer 'yes' to the the question without ssl and it would work, but it fails in the way you suggest if ssl is used.

Forgive me if I am reading your response incorrectly, but isn't replication of o=NetscapeRoot the best solution? This maintains consistancy between seperate config directories and provides resilience if I was to lose a host.

As you may have gathered, I am new new to this directory server stuff, so if I am talking rubbish, please feel free to tell me,

cheers,

Richard

[Weltman, Ulf · Accepted solution]

I've pinpointed the problem with the administration console freezing on "Initializing" phase when administration server uses SSL with its configuration DS. To work around the problem you will need to modify a value in the o=NetscapeRoot tree.
Example (replace host, domain and ports with your own):
# /opt/dirsrv/bin/ldapmodify -h localhost -p 389 -D "cn=directory manager" -w -
Enter bind password:
dn: cn=UserDirectory, ou=Global Preferences, ou=example.com, o=NetscapeRoot
changetype: modify
replace: nsDirectoryURL
nsDirectoryURL: ldaps://host.example.com:636/dc=example, dc=com
^D^D

Restart the administration server and reconnect with the console.

For your reference, I've filed defect QXCR1000928721 targeted at our next release.

Regarding replicating NetscapeRoot, this is fine, it's just uncommon and wasn't documented until release 8.0 because it's not complete - there is no automatic failover to another replica if the primary is down. To fail over manually you have to edit the ldapurl parameter in adm.conf and the pass through authentication plugin's configuration entry under cn=config (or edit dse.ldif) in each directory server instance to switch to another replica.