2013/3/12 nap <napar...@gmail.com>
> Hi,
>
> On Tue, Mar 12, 2013 at 8:22 AM, David GUENAULT
> <david.guena...@gmail.com>wrote:
>
>> First : Is it possible to grant user access to only certain realms? For
>> exemple, I'd like to affect user1 to "e1" realm, in which he can only see
>> items related to his realm, not those of "e2" when he logs into the WebUI.
>> I think it's not, as of today, but I'd like to be sure ;-)
>>
>> Yes if you put a broker in each "isolated" realm. The webui and
>> livestatus are borker module so this is the best way (imho)
>>
>
> The webui got a "not so strong" ACL mode. By default the user will see the
> object where he is as "contacts". But if he knows about another node, he
> can still goes to the full URI of it, and see information, the page is not
> blocked from now.
>
> Of course if you put one webui by sub-realm, there is no more problem, as
> the WebUI just not have the other realm information :)
>
>
>> Secondly, I created 2 subrealms under the main realm "All" (let's say
>> "e1" ans "e2"). Even though the wiki specifies "realm is: * at least a
>> scheduler *", I had expected that my only scheduler, being attached to the
>> "All" realm could be used for both subrealms as there are members, but it
>> doesn't seem possible. I get a config error on arbiter launch "The realm e1
>> have hosts but no scheduler!".
>> Did I miss something, or is it necessary to absolutly have one scheduler
>> for each sub realm ? I know it might seem silly if you think of the example
>> of realms in a global network like in the wiki, but this could avoid having
>> using different schedulers in a mutualised infrastructure for multiple
>> clients (in a single local network).
>>
>> here is an example from wiki pages that should help you :
>> http://www.shinken-monitoring.org/wiki/setup_distributed_shinken_with_realm?s[]=realm
>>
>> if it does not help you please send your shinken-specific.cfg with
>> obfuscated names and ip so we can help you point where the config is wrong.
>>
>> For the scheduler, the realms were done for "datacenter" load
> distribution first, not for UI separation views or things like that. You
> won't be able to share a same scheduler between realms. One exeption : one
> can be a spare, but when it will become active, it will refuse new
> configuration from another realm.
>
That's what I thought, seeing the errors I got and reading the wiki page.
Thanks for the confirmation. So I have another question, even though I
already tried too ;-) is it possible to run 2 scheduler on the same host
(with 2 different config files and 2 distinct ports) ?
Because if you can't, this means I need to build one server for each sub
scheduler. With virtual machine that is not really problematic in terms of
infrastructure but not really conveniant if you have many clients...
> One way, if you want to have :
> * each realm got only their views on their WebUI
> * you still got the full view on one WebUI
>
> is to put WebUI on each sub-schedulers, and got one global broker with a
> WebUI too until the multi-broker levels feature is done (will not be for
> the next release).
>
Thank you both, I'm going to use the multiple WebUI brokers "trick", it
will be more than enough for a start. I don't know what you mean by
"multi-broker levels feature" though
Denis
>
>
>
> Regards,
>
>
> Jean
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
