[389-users] Clarification on admin server and console

[Jonathan Boulle]

I've been trawling through the documentation trying to get a better understanding of "best practices" for use of the console and admin server in an environment with a large number of directory servers.  In the perfect scenario, we would like to be able to manage the entire estate (multiple locations) using one instance of the console; or perhaps one console per location. Unfortunately I'm not finding it straightforward.

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.

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?

Thanks
Jonathan

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

________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20100812/7143d6ac/attachment.html>