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:
- 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.
- 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:
- apply OS tar of client software on server. This tar would have a class definition of NEWCLIENT.
- configure bb-hosts to have a page of unallocated/new client installs. basically a NEWCLIENT bucket.
- configure alert rules to not send any alerts for the class definition of NEWCLIENT.
- 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