[hobbit] Idea: Dynamic group- definition
Hubbard, Greg L
greg.hubbard at eds.com
Tue Feb 27 23:25:39 CET 2007
Won't an "include" be subject to the same issues regarding stability,
etc, or did Henrik make it smart enough to discard bad includes?
GLH
-----Original Message-----
From: Gary Ciampa [mailto:Gary.Ciampa at sas.com]
Sent: Tuesday, February 27, 2007 4:20 PM
To: hobbit at hswn.dk
Subject: RE: [hobbit] Idea: Dynamic group- definition
Steve,
Would the "include" file support in bb-hosts be suitable for this type
of policy. You could configure an include for each client class, with
unique permissions associated with the include(s).
The bb-hosts admin would simply add the include file to bb-hosts at the
appropriate time. Non-admin folks would still able to make user changes
to the included file, which would be picked up dynamically as well.
Gary
-----Original Message-----
From: Aiello, Steve (GE, Corporate, consultant)
[mailto:steve.aiello at ge.com]
Sent: Tuesday, February 27, 2007 10:29 AM
To: hobbit at hswn.dk
Subject: [hobbit] Idea: Dynamic group- definition
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.
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe at hswn.dk
More information about the Xymon
mailing list