RHQ Group Definitions (dynagroup) Enhancement

The RHQ Project supports Group Definitions, also known as DynaGroups, to let users automatically generate resource groups given a powerful expression language.  For example, if I'm managing a bunch of JBoss AS7 Servers I may want to automatically group them so I can process them together.  Instead of creating and populating a  resource group manually, I could also just create a Group Definition like: 

resource.type.plugin = JBossAS7
resource.type.name = JBossAS7 Standalone Server

Moreover I could even have it automatically recalculate the group membership at some interval to my liking. Here is a link for a complete rundown on Group Definitions.  

This blog is to point out a nifty new feature for limiting generated group membership by providing one or more narrowing groups.  We've added the 'memberof' expression to the group definition language.

Let's say you're managing a bunch of machines and you've got them split up between two teams.  You've already imported your platforms into RHQ and created a couple of groups (either manually or with dynagroups) such that you have Platform Group A and Platform Group B, and your two teams are assigned views of these two groups appropriately (RHQ provides a robust Role Based Security Model). As a note, these are recursive groups, meaning they implicitly include all of the resources for that platform.

Now let's say a few team members are devoted to your AS server management and require heightened permissions for the servers they manage, say deployment permissions.  I create a new role with the desired permissions and assign the users. What I need is to easily create a group of the servers that they can see, and assign it to the role in order to tie together the users, the permissions and the server resources. I can do that by using the same Group Definition above, but with one more expression:

resource.type.plugin = JBossAS7
resource.type.name = JBossAS7 Standalone Server

memberof = Platform Group A

The groups generated are now guaranteed to be limited to only those servers that are in Platform Group A. Put another way, the results are narrowed by Platforms Group A. It is valid to supply multiple 'memberof' expressions in one group definition.  In this case the resulting dynagroups will be limited to resources in the union of narrowing groups. This feature can play a big role in role-based security in RHQ, but has other uses as well.  Use it any time it would be helpful to generate proper subsets of existing groups.

Enjoy!

Store your RHQ Agent Preferences in a File

The RHQ Project stores its agent configuration using Java Preferences, which is a great way to store things in a platform-independent way without having to worry about it.  But, sometimes it's nice to have a little more control over things, especially on Windows where the native implementation uses the registry.  Some RHQ users have requested being able to store the agent configuration in a configurable file, so that they can just wipe an agent directory and not leave any configuration litter somewhere on the machine.

I recently pushed this feature to our master git branch and it should show up in RHQ 4.7.  But you can try it now if you roll your own builds.

All you need to do is start your agent with two system properties set:


java.util.prefs.PreferencesFactory=org.rhq.core.util.preferences.FilePreferencesFactory 
rhq.preferences.file=


This can be done conveniently by setting them in rhq-agent-env.sh|bat:

set RHQ_AGENT_JAVA_OPTS=-Djava.util.prefs.PreferencesFactory=org.rhq.core.util.preferences.FilePreferencesFactory -Drhq.preferences.file=

You can omit the rhq.preferences.file property and it will default to user.home/.fileprefs but you probably don't want to use the default.  A more likely approach would be to set it to something like:

 -Drhq.preferences.file=$RHQ_AGENT_HOME/conf/agent-prefs.properties

By doing that you'll be storing it under the agent's root, and therefore if you delete the entire agent you'll also get rid of the prefs.

Note that this works easily for new agents.  For existing agents that want to switch to this approach, it will be somewhat like starting with the --fullcleanconfig option.  This means you'll need to re-enter the setup questions and also specify the existing security token via -Drhq.agent.security-token=.  If you want to see your existing configuration settings before making a switch you  can use the '> config list' agent prompt command (either interactively or via the RHQ Agent's operation).