[389-users] Clarification on admin server and console

Gerrard Geldenhuis Gerrard.Geldenhuis at betfair.com
Mon Aug 16 12:44:59 UTC 2010


>> I understand that on a (physical/virtual) server there can be multiple
>> directory server instances but only one admin server instance.
>> However, what I'm wondering is whether it is possible for an instance
>> of the admin server to manage directory servers on different boxes.
>> For example, could I have one admin server per location - where a
>> location houses X physical servers each running a DS instance (a mix
>> of read-only consumers and read-write suppliers)? This brings obvious
>> benefits as regards easier backup and a single point of
>> administration, but also becomes a bit of a single point of failure.
>>
>There must be an admin server on the physical machine that hosts the
>directory server.  Some of the admin server tasks are CGI based e.g.
>certificate management, log viewing, server stop/start/restart.  These
>cannot be done remotely.

There is still some haziness in my mind about the admin server...

I setup a server called master01 using setup-ds-admin.pl and then setup another physical server called master02 also using setup-ds-admin.pl. The only difference was that I "registered" master02 with master01. The effect is that when I run 389-console from the command line logging into either master01 or master02 I get both master01 and master02 listed in the directory tree. Each one has a server group with an admin server and directory server listed. However the admin server for master02 points to master01 by default when looking at the settings.

I have a configured client that authenticates against master02 and then fails over to master01. If I shutdown master01(shutdown -h now) and restart master02 I am still able to authenticate from the client server or at least get results for getent passwd.

master02 does not have a netscaperoot so that seems shared if you register master02 with master01. 

Now for my question, I have read above that you have said that we must have an admin server on each physical server. I believe we have... I can do a service dirsrv-admin start/stop/restart  on master02. 
* So what does the "registration" during installation actually do?
* I registering one physical server to another physical server a bad idea as I described above.
* What is the reliance of master02 on master01. I did notice that I can't start the 389-console at all if master01.dirsrv service is not running.

We plan to have quite a number of servers and it would be nice to have a "centralized control panel" where you can easily access all servers and select servers from a drop down box when setting up replication agreements. Thus what I have experimented with above is basically trying to achieve this control panel but I would like to be sure that it is done correctly. The other concern is that we don't want to introduce a central point of failure for the convenience of having a centralized control panel.

>>
>>
>>
>> If not, is it necessary/standard to run an admin server per physical
>> server, and then group them in the console by having them all share a
>> single configuration server (as specified in setup-ds-admin.pl)?
>> Although again this creates a single POF, at least with administration
>> - or have I got the wrong end of the stick entirely?
>>
>>
>>
>> One more point: the Console and Admin Server documentation has
>> diagrams which reference "external programs"; what kind of things does
>> this refer to? Is there a typical use case?
>>
>I'm not sure (can you provide a URL?) but the "external programs" are
>probably the aforementioned CGI programs.


http://www.redhat.com/docs/manuals/dir-server/8.2/console/html/chap-Console_Guide-Introducing_Red_Hat_Console_and_Administration_Server.html 
Figure 1.2 was what Jonathan referred to.

Best Regards

________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from 
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________



More information about the 389-users mailing list