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)
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.
2013/3/11 Denis GERMAIN <dt.germ...@gmail.com>
> Hi,
>
> I'd like to discover a feature that I always know existed for a while (the
> very begining if I'm not mistaken ;-) ) but never had the opportunity to
> put to use : the realms.
>
> I'm working for a french company which is composed of multiple sub
> entities that are more or less autonomous. The infrastructure/softwares I
> provide to those semi autonomous entities do not want to share data with
> the other ones. I'd like to propose a monitoring solution for both the
> technical and decision teams for these entities. Ideally It would be
> acheived by a centralised Shinken and subrealms, but there seem to be
> limitations...
>
> 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 ;-)
>
> 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).
>
> Regards
>
>
> ------------------------------------------------------------------------------
> 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
