Using a Message Broker to Send Audit Messages

One thing I've been working on on the side is a little project that uses a message broker to send and receive "auditing" events. Just briefly, the idea is that any piece of software might want to emit audit messages to log certain events that have occurred so that those events are captured for future reporting purposes. This project (call it rhq-audit for now) can provide a message broker if you need one, along with a high-level API that can be used to both emit and process these audit messages. For example, maybe you want your sales application to record each attempted login by a remote client, or maybe you want to record each sales order that has been submitted. Using the rhq-audit API, audit messages can be fired off on the message bus for later consumption by an rhq-audit consumer whose job it will be to store the audit record in a persistence store that can be used by reporting tools when audit reports need to be generated.

RHQ-Audit doesn't provide any reporting tools, but does provide a compact API that allows you to emit and store audit messages. You can persist your audit messages to a simple log file (see LoggerConsumer) or to a relationship database (see DataSourceConsumer), or to any custom backend (you would just need to implement your own BasicMessageListener and have the AuditRecordProcessor use it as its listener).

I talk a bit more detail on this type of thing in my previous blog on starting out with ActiveMQ. The code now in the rhq-audit repo is a bit different, but the concepts are still the same.

I separated out the message broker stuff (along with a generic and extensible consumer/producer API) into rhq-msg. rhq-audit extends rhq-msg to handle audit events. But the idea is rhq-msg can be used to provide a message bus along with an API for any type of messaging app you want to build.

In addition to the API, an embedded broker that you can use to embed in your VM or run standalone, and an extensible test API, there is also a custom Wildfly module extension that can be used to easily deploy a message broker inside your application server via Maven. See my previous blog on how to install that Wildfly extension via a mvn plugin.

To build and run the tests for rhq-audit and rhq-msg, all you need to do is run "mvn install" from the top level root directory.

Using the new Maven Wildfly Extension plugin to deploy module extensions

Libor is putting together a nice maven plugin to help you deploy your custom Wildfly module extensions to an existing Wildfly or EAP installation.

I decided to integrate it with my rhq-msg-broker-wf-extension project (I talked about my prototype of the rhq-msg work here). What this now allows us to do is deploy a message broker directly in an existing Wildfly or EAP installation via a simple mvn command line.

I won't repeat all of Libor's instructions - just go to his blog I linked above for the full details of how to integrate his mvn plugin in your mvn project - but in short all I had to do was create a snippet of .xml which includes the configuration I want to deploy in the Wildfly or EAP instance's standalone.xml (which includes the subsystem and the socket-binding) and then in the pom just define some settings for the plugin to let it know where to put my extension code and that XML configuration.

In the pom.xml, I have this to define the mvn plugin configuration - notice I allow the user to tell us where the app server is installed via a system property "org.rhq.msg.broker.wildfly.home":

        <plugin>
            <groupId>org.jboss.plugins</groupId>
            <artifactId>wildfly-extension-maven-plugin</artifactId>
            <configuration>
                <moduleZip>${project.build.directory}/${project.build.finalName}-module.zip</moduleZip>
                <jbossHome>${org.rhq.msg.broker.wildfly.home}</jbossHome>
                <modulesHome>modules/system/layers/base</modulesHome>
                <serverConfig>standalone/configuration/standalone.xml</serverConfig>
                <subsystem>${basedir}/src/main/scripts/standalone-subsystem.xml</subsystem>
                <profiles>
                    <profile>default</profile>
                </profiles>
                <socketBinding>${basedir}/src/main/scripts/socket-binding.xml</socketBinding>
                <socketBindingGroups>
                    <socketBindingGroup>standard-sockets</socketBindingGroup>
                </socketBindingGroups>
            </configuration>
        </plugin>

To publish the rhq-msg-broker-wf-extension custom module extension to an already-installed EAP instance, simply run this command (this sets the system property to point to a EAP install directory, and it uses the goal "wildfly-extension:deploy" which tells the mvn plugin to deploy the extension to that EAP installation):

mvn -Dorg.rhq.msg.broker.wildfly.home=/opt/jboss-eap-6.3 wildfly-extension:deploy

At this point, the standalone.xml will have been modified to include the custom module extension's subsystem configuration and the module code will have been copied to the EAP modules directory. At this point, once the app server is started, the module extension will be deployed and running.

Starting an ActiveMQ Project with Maven and Eclipse

I'm currently researching and prototyping a new subproject under the RHQ umbrella that will be a subsystem that can perform the emission and storage of audit messages (we're tentatively calling it "rhq-audit").

I decided to start the prototype with ActiveMQ. But one problem I had was I could not find a "starter" project that used ActiveMQ. I was looking for something with basic, skeleton Maven poms and Eclipse project files and some stub code that I could take and begin fleshing out to build a prototype. So I decided to publish my basic prototype to fill that void. If you are looking to start an ActiveMQ project, or just want to play with ActiveMQ and want a simple project to experiment with, then this might be a good starting point for you. This is specifically using ActiveMQ 5.10.

The code is in Github located at https://github.com/jmazzitelli/activemq-start

Once you clone it, you can run "mvn install" to compile everything and run the unit tests. Each maven module has an associated Eclipse project and can be directly imported into Eclipse as-is. If you have the Eclipse M2E plugin, these can be imported using that Eclipse Maven integration.

Here's a quick overview of the Maven modules and a quick description of some of the major parts of the code:

• /pom.xml
• This is the root Maven module's pom. The name of this parent module is rhq-audit-parent and is the container for all child modules. This root pom.xml file contains the dependency information for the project (e.g. dependency versions and the repositories where they can be found) and identifies the child modules that are built for the entire project.
• rhq-audit-common
• This Maven module contains some core code that is to be shared across all other modules in the project. The main purpose of this module is to provide code that is shared between consumer and producer (specifically, the message types that will flow from sender to receiver).
• AuditRecord.java is the main message type the prototype project plans to have its producers emit and its consumers listen for. It provides JSON encoding and decoding so it can be sent and received as JSON strings.
• AuditRecordProcessor.java is an abstract superclass that will wrap producers and consumers. This provides basic functionality such as connecting to an ActiveMQ broker and creating JMS sessions and destinations.
• rhq-audit-broker
• This provides the ability to start an ActiveMQ broker. It has a main() method to allow you to run it on the command line, as well as the ability to instantiate it in your own Java code or unit tests.
• EmbeddedBroker.java is the class that provides the functionality to embed an ActiveMQ broker in your JVM. It can be configured using either an ActiveMQ .properties configuration file or an ActiveMQ .xml configuration file.
• rhq-audit-test-common
• The thinking with this module is that there is probably going to be common test code that is going to be needed between producer and consumer. This module is to support this. The intent is for other Maven modules in this project to list this module as a dependency with a scope of "test". For example, some common code will be needed to start a broker in unit tests - including this module as a test dependency will give unit tests that common code.
• TCPEmbeddedBrokerWrapper.java provides a simple ActiveMQ broker configured very simply and will use a free TCP port to listen to. Tests can have their consumers and producers communicate with this broker.
• VMEmbeddedBrokerWrapper.java provides a simple ActiveMQ that is only for intra-VM messaging. It too is very simply configured and is useful, again, for unit or integration tests that need a broker for message processing.
• EmbeddedBrokerTest.java exercises the above test brokers by using a test consumer and producer (which are also available for use by other Maven modules since they are also part of the common code provided by this rhq-audit-test-common module).
• rhq-audit-producer
• This provides the producer-side functionality of the project. The intent here is to flesh out the API further. This will become rhq-audit's producer API.
• AuditRecordProducer.java provides a simple API that allows a caller to connect the producer to the broker and send messages. The caller need not worry about working with the JMS API as that is taken care of under the covers.
• rhq-audit-consumer
• This provides the consumer-side functionality of the project. The intent here is to flesh out the client-side API further. This will become the rhq-audit's consumer API.
• AuditRecordConsumer.java provides a simple API that allows a caller to connect the consumer to the broker and attach listeners so they can process incoming messages.
• AuditRecordListener.java provides the abstract listener class that is to be extended in order to process received audit records. The idea here is that subclasses can process audit records in different ways - perhaps one can store the audit records in a backend data store, and another can log the audit messages in rsyslog.
• AuditRecordConsumerTest.java provides a simple end-to-end unit test that uses the embedded broker to pass messages between a producer and consumer.

Taking a look at AuditRecordConsumerTest shows how this initial prototype can be tested and shows how audit records can be sent and received through an ActiveMQ broker:

1. Create and start the embedded broker:

VMEmbeddedBrokerWrapper broker = new VMEmbeddedBrokerWrapper();
broker.start();
String brokerURL = broker.getBrokerURL();

3. Connect the producer and consumer to the test broker:

producer = new AuditRecordProducer(brokerURL);
consumer = new AuditRecordConsumer(brokerURL);

2. Prepare to listen for audit record messages:

consumer.listen(Subsystem.MISCELLANEOUS, listener);

3. Produce audit record messages:

producer.sendAuditRecord(auditRecord);

At this point, the messages are flowing and the test code will ensure that all the messages were received successfully and had the data expected.

A lot of the code in this prototype is generic enough to provide functionality for most messaging projects; but of course there are rhq-audit specific types such as AuditRecord involved. The idea is to now flesh out this generic prototype to further provide the requirements of the rhq-audit project. More on that will be discussed in the future. But for now, perhaps this could help others come up to speed quickly with an AcitveMQ project without having to start from scratch.

Completed Remote Agent Install

My previous blog post talked about work being done on implementing an enhancement request which asked for the ability to remotely install an RHQ Agent. That feature has been finished and checked into the master branch and will be in the next release.

I created a quick 11-minute demo showing the UI (which is slightly differently than what the prototype looked like) and demonstrates the install, start, stop, and uninstall capabilities of this new feature.

I can already think of at least two more enhancements that can be added to this in the future. One would be to support SSH keys rather than passwords (so you don't have to require passwords to make the remote SSH connection) and the other would be to allow the user to upload a custom rhq-agent-env.sh file so that file can be used to override the default agent environment (in other words, it would be used instead of the default rhq-agent-env.sh that comes with the agent distribution).

Remote Install of JON Agent

A new feature request has been added to JBoss Operations Network. JON users will now be able to install agents on remote boxes from the UI as long as the remote box is accessible via SSH.

All you need is the hostname of the machine you want to install the agent on, its SSH port that it's listening to (default is 22) and the credentials of the user who will install (and run) the JON agent.

You can install, start, and stop the JON agent from this UI mechanism. You can also use it to get the status of any JON agent that might be installed as well and even attempt to find if and where an agent may be installed on the remote box.

Here's a snapshot of the UI page after I just successfully remote installed a JON agent:

Availability Updates in RHQ GUI

In older versions, the RHQ GUI showed you the availability status of resources but if you were viewing the resource in the GUI, it did not update the icons unless you manually refreshed the screen.

In RHQ 4.9, this has changed. If you are currently viewing a resource and its availability status changes (say, it goes down, or it comes back up), the screen will quickly reflect the new availability status by changing the availabilty icon and by changing the tree node icons.

To see what I mean, take a look at this quick 3-minute demo to see the feature in action (view this in full-screen mode if you want to get a better look at the icons and tree node badges):

Fine-Grained Security Permissions In Bundle Provisioning

RHQ allows one to bundle up content and provision that bundle to remote machines managed by RHQ Agents. This is what we call the "Bundle" subsystem, the documentation actually titles it the "Provisioning" subsystem. I've blogged about it here and here if you want to read more about it.

RHQ 4.9 has just been released and with it comes a new feature in the Bundle subsystem. RHQ can now allow your admins to give users fine-grained security constraints around the Bundle subsystem.

In the older RHQ versions, it was an all-or-nothing prospect - a user either could do nothing with respect to bundles or could do everything.

Now, users can be granted certain permissions surrounding bundle functionality. For example, a user could be given the permission to create and delete bundles, but that user could be denied permission to deploy those bundles anywhere. A user could be restriced in such a way to allow him to deploy bundles only to a certain group of resources but not others.

Along with the new permissions, RHQ has now introduced the concept of "bundle groups." Now you can organize your bundles into separate groups, while providing security constraints around those bundles so only a select set of users can access, manipulate, and deploy bundles in certain bundle groups.

If you want all the gory details, you can read the wiki documentation on this new security model for bundles.

I put together a quick, 15-minute demo that illustrates this fine-grained security model. It demonstrates the use of the bundle permissions to implement a typical use-case that demarcates workflows to provision different applications to different environments:

Watch the demo to see how this can be done. The demo will illustrate how the user "HR Developer" will only be allowed to create bundles and put them in the "HR Applications" bundle group and the user "HR Deployer" will only be allowed to deploy those "HR Applications" bundles to the "HR Environment" resource group.

Again, read the wiki for more information. The RHQ 4.9 release notes also has information you'll want to read about this.