Re: [389-users] Clarification on admin server and console

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gerrard Geldenhuis wrote:
>>> 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.
>   
Right.  Unfortunately, the admin server/console do not failover 
automatically to another configuration directory server.  But see this - 
http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Managing_Replication-Replicating-ADS-for-Failover.html
> 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.
>   
Right.  Regular LDAP clients don't know anything about the admin 
server/console.
> master02 does not have a netscaperoot so that seems shared if you register master02 with master01. 
>   
It's "sort of" shared.
> 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?
>   
It allows you to see both servers at the same time in the console i.e. 
centralized administration.  Otherwise, if you set up every master to be 
its own configuration directory server, you have to connect the console 
to each master, and can only use the console to manage one server at a time.
> * I registering one physical server to another physical server a bad idea as I described above.
>   
I don't understand the question.
> * 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.
>   
Right.  See the link I posted above.
> 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.
>   
See the link I posted above.
>   
>>>
>>> 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.
>   
Yes, the external programs are the admin server CGI programs.
> Best 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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>   

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users


[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux