Idea: Dynamic group- definition
Aiello, Steve (GE, Corporate, consultant)
steve.aiello at ge.com
Tue Feb 27 16:29:10 CET 2007
I had a thought today about easing administration and restricting write
access to the bb-hosts file. They are just thoughts, and not sure to the
difficulty of implementation.
Problem Statement:
1. I want to limit write access to the hobbit bb-hosts file. I do not
want every person that can do a client install requiring write access to
the file. If the bb-hosts file is corrupted/mistyped/etc, the entire
server is affected. Thus I would like to refine accountability to a
select few. But I also do not want to impeded the client installs with
process/red tape.
2. Be able to define a group/group-compress/group-only/etc to a
classname definition. so this grouping will automatically update it's
members. Basically a dynamic group definition.
So a scenario of performing client installs would be:
1. apply OS tar of client software on server. This tar would have a
class definition of NEWCLIENT.
2. configure bb-hosts to have a page of unallocated/new client installs.
basically a NEWCLIENT bucket.
3. configure alert rules to not send any alerts for the class definition
of NEWCLIENT.
4. every week a bb-host admin would look into the NEWCLIENT bucket, and
create the appropriate bb-hosts entry.
Dynamic Class defined group buckets could be useful for other processes
too.
More information about the Xymon
mailing list