Preferred method for installing JBoss EAP 6

Latest response

We are currently working on a migration from Glassfish on Solaris to JBoss EAP 6 on RHEL, and are trying to decide on how we will be installing the EAP software on the servers we're going to be setting up.  We are trying to decide if we should use the RPM or jar installation method, and I was wondering if I could get some advice on which method to use.

Here are some details about our environment:

  • OS: RHEL 6.4 on x86_64 VMWare VMs
    • Patch management: local Spacewalk (Satellite) server
    • Configuration management: Puppet Enterprise
  • JBoss: EAP 6
    • JVM: OpenJDK 1.7
    • JBoss Management: JBoss ON 3.1 (we have the license for this, and plan to deploy EAP 6 in standalone mode, using JON for management)
    • Web Server: JBoss EWS
  • Load balancing: F5 BigIP

This is an entirely new installation and new OS for us, so we are not limited right now by any past decisions regarding OS or JBoss management.  We're planning to deploy the latest versions of all of the components.  Ideally, if we got a request for a new developer VM or needed another server in the cluster, I'd like to be able to script it to create the VM, have Puppet install JBoss, JON, and the other components, and then have JON apply the appropriate base configuration for that instance.

I did find this article in the Knowledge Base, but as it is 2 years old, and presumably regarding EAP 5, I didn't know what has changed since them.

"JBoss EAP - Installation Options compared"


Any advice would be appreciated.  Thanks!


Hi Brian,

I have a nearly identical setup to you, we are using Puppet to install and configure all the components. Puppet was already in use by our Linux team for config management.

My JBoss Puppet class:

  • Installs the required RPM packages
  • Pushes standard base configuration, customised with Puppet templates for host, IP, etc.
  • Installs SSL certificates
  • Sets file/directory permissions
  • Installs and configures the JON agent
  • Setups adminstrator users and groups and appropriate sudo access
  • Installs as a service
  • And finally starts the services

My JBoss EWS Puppet class:

  • Installs EWS and pushes base configuration, certs, etc
  • Setups adminstrator users and groups and appropriate sudo access
  • Installs as a service
  • And finally starts the services

Previously we had JAR/ZIP based installations with shell scripts to install, this was far more cumbersome. Puppet can fully automate the installation.


Thanks!  Glad to hear we're going down the right path.  Are any of those manifests posted on the Puppet community website?  It'd be great to not have to reinvent the wheel.  I'm new to Puppet, too, so this has been a learning experience all around. :)

Thanks for sharing this info, David!

Hi Brian,

I built the manifest myself. I was also new to Puppet. It was basically a combination of the following types:

package- To install the yum packages

For example, this installs standalone only:


package {

"jbossas-bundles": ensure => latest;

"jbossas-core": ensure => latest;

"jbossas-hornetq-native": ensure => latest;

"jbossas-jbossweb-native": ensure => latest;

"jbossas-modules-eap": ensure => latest;

"jbossas-product-eap": ensure => latest;

"jbossas-standalone": ensure => latest;



file- To copy the files in place (using templates in some cases)


file { "eap-config":

path    => "/etc/jbossas/standalone/standalone.xml",

owner   => jboss,

group   => jboss,

mode    => 660,

content => template("jboss/eap/standalone/standalone.xml");


service- to install the service.


service { "jbossas":

ensure => running,


Hey, David !
Did you ever put your module on GitHub or PuppetForge ?

I'd say that there are both definite advantages and disadvantages to using the RPMs, and which ones is best depends a lot on your environment and how you administer things.


The EAP 6 RPMs make things a lot easier in terms of installation because you can use all the tools that know how to deal with RPMs, such as Puppet or kickstart, and upgrading is simpler because you can use yum to do it, especially for security errata. You don't need to write scripts or learn new ways of handling the installation.


Most of the down sides come from being forced to do things the way RHN/RPMs want to do it. You cannot install multiple version of JBoss in parallel, which may not be an issue if you spin up a new VM per instance, but can be for some people. It is also difficult to install non-current versions, since you either need to manually specify the versions of several hundred packages or use Satellite with a date cutoff on a custom cloned channel to hide any packages from newer releases.

I just happened to run across this discussion and felt compelled to add my 2 cents.  I love RPM & YUM, but I've experienced contention between using them to install & update JBoss EAP versus how some in the JBoss Community operate.

I hope nobody takes this the wrong way, but my experience has been that many JBoss developers (both internal to our company and those employed by Red Hat) tend to be a little more `loosey-goosey` about where things go and what they should be modifying.  The JBoss RPMs put things where many RHEL system administrators would expect them:  config files under /etc, content & libraries under /var, etcetera.  The developers then complain about not knowing where something is.  They are use to zip file installs that just plop it all down under one directory.

JBoss RPMs `assume` there are certain files that won't be modified and thus are safe to replace when updated.  The RPM maintainers haven't met some of our JBoss developers!  :-)  We sysadmins did a "yum update" on one of the RPM-installed JBoss 5 EAP servers and it broke their application.  We're still investigating what the developers did that effectively keeps us from applying all but the most surgical of JBoss updates to their servers.

The latest RPM vs. zip file contention was brought about with our installation of JBoss Operations Network (JON).  JON has the ability to update its JBoss servers, but only if they have been installed via zip file.  This limitation comes from the fact that the JON agents have to run as the same user as the JBoss daemon, and that account cannot alter the RPM DB.  Obviously Red Hat could give the JON agent some kind of sudo-type privilege to run the rpm or yum commands, but how does one limit it to just the JBoss packages and not all the other packages?  I'm assuming that is why Red Hat did not take that route.

By the way, JON must be installed via zip file; there are no RPMs for it.

As extremely useful as RPM & YUM are, we are no longer using them for our JBoss installations.  I look forward to the future, hoping Red Hat better improves RPM support and addresses any concerns the JBoss community has over it.

Yes, Bernie that was one of the major issues with EAP 5's RPMs, that internal details were mixed up with end-user configuration.


That is vastly improved in EAP 6 where the internal details are not exposed in a jumble of files, and everything is either a JBoss-owned file which you should never need to touch, or a end-user file which will not be touched on upgrades.

File locations are not a YUM/RPM issue: it's adherence to an actual standard for locations.

Yes: there's a standard. It's good, and when people follow the standard, locations are where everyone expects them to be. This is what you wanted, right?

If you're not following the standard, and others are, you will not be looking in the proper locations for things, and you will become sad until you are enlightened. You will rail at the arbitrary and unhappy location for things, and you will wish that the others could change their tools to use your arbitrary locations.