Who’s the JBOSS? Rapid Jboss 4.2.3GA AS server installs on CentOS 5

by lesliebuna on January 1, 2012 | One comment

We have just completed the first part of this sprint – creating an automated jboss server installation based on Jboss 4.2.3GA and CentOS 5.

This one went relatively smoothly thanks to following resources:

Craig Andrews’ Install JBoss 4.2 on Centos/RHEL 5 Blog Post,
The JPackage Project,
R.I. Pienaars Puppet-Concat module and,
Rob Myers [JPackage-discuss] /usr/bin/rebuild-security-providers is needed by package java-1.4.2-gcj-compat fix

Once out of the gate we started with the meatcloud approach and installed everything by hand to find out what the ins and outs were and identify any possible gotcha’s. Straight off the bat we found that there was a problem installing the jboss application server on CentOS/RHEL5 using the JPackage repository due to a rebuild-security-providers dependency, after practicing a bit of google-fu I found Craig Andrews post that pointed us to the following RPM Spec file from Rob Myers JPackage discussion post:

Name:           jpackage-utils-compat-el5
Version:        0.0.1
Release:        1%{?dist}%{?repo}
Epoch:          0
Summary:        Compatibility For RHEL5 and JPackage
License:        GPL
URL:            http://rmyers.fedorapeople.org/jpackage-utils-compat-el5
Group:          Utilities
BuildRoot:      %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
 
BuildArch:      noarch
Requires:       /bin/bash
 
%description
Compatibility for JPackage Utils between RHEL5 and the JPackage Project.
 
%prep
# no setup
 
%build
# no building
 
%install
rm -rf $RPM_BUILD_ROOT
 
install -dm 755 ${RPM_BUILD_ROOT}%{_bindir}
install -dm 755 ${RPM_BUILD_ROOT}%{_sysconfdir}/java/security
install -dm 755 ${RPM_BUILD_ROOT}%{_sysconfdir}/java/security/security.d
 
pushd ${RPM_BUILD_ROOT}%{_bindir}
 
cat > rebuild-security-providers << EOF
 
#!/bin/bash
# Rebuild the list of security providers in classpath.security
 
secfiles="/usr/lib/security/classpath.security /usr/lib64/security/classpath.security"
 
for secfile in \$secfiles; do
  # check if this classpath.security file exists
  [ -f "\$secfile" ] || continue
 
  sed -i '/^security\.provider\./d' "\$secfile"
 
  count=0
  for provider in \$(ls /etc/java/security/security.d)
  do
    count=\$((count + 1))
    echo "security.provider.\${count}=\${provider#*-}" >> "\$secfile"
  done
done
EOF

 
popd
 
%clean
rm -rf $RPM_BUILD_ROOT
 
%files
%defattr(-,root,root,-)
%{_bindir}/rebuild-security-providers
%{_sysconfdir}/java/security
%{_sysconfdir}/java/security/security.d
 
%changelog

* Thu Jul  3 2008 Rob Myers <rob.myers at gtri.gatech.edu> - 0:0.0.1-1%{?dist}%{?repo}
- initial release

After vetting what the specfile actually did (Always do this!) and deeming it safe to use we rolled our RPM from it and placed it into our cobbler repository and did a “yum install jbossas”. The default Jpackage installation of Jboss is configured to only listen on localhost for security purposes but we wanted to expose it to our network for testing so we set the JBOSS_IP variable to 0.0.0.0 in the /etc/sysconfig/jbossas file and restarted the jbossas service to make it accessible remotely. It’s all good, just a simple “chkconfig jbossas on” and we are done, a sample jboss server ready to go, now the fun part, automating to whole deployment process from scratch. Breaking out my puppet toolkit, we went about writing a module that would install jbossas, configure it, get it running and set it to autostart on reboot. We also wanted to add some configurability to allow me to change the settings in /etc/sysconfig/jbossas e.g. setting the JBOSS_IP or JAVA_OPTS variables.

# Class: jboss
#
# This class manages the jboss application server
#
# Parameters:
#   None
#
#
# Actions:
#   Install the jboss application server
#
# Requires:
#   - Package[]
#   - R.I. Pienaar's puppet-concat module
#
# Sample Usage:
#
 
class jboss::install {
    $packagelist = ["jpackage-utils-compat-el5","jbossas","jbossweb2"]
    package{ $packagelist:
        ensure  => latest,
        require => Class["repository::uncommonsense","repository::jpackage::generic","repository::jpackage::el5"],
    }
}
 
class jboss::config {
    File{
        require => Class["jboss::install"],
        notify  => Class["jboss::service"],
        owner   => "root",
        group   => "root",
        mode    => 644
    }
}
 
class jboss::service {
    service{["jbossas","jbossweb2"]:
        ensure  => running,
        enable  => true,
        require => Class["jboss::config"],
    }
}
 
class jboss {
    include jboss::install,
            jboss::service,
            jboss::config
 
    include concat::setup
 
    concat{"/etc/sysconfig/jbossas":
        notify => Service["jbossas"],
    }
 
    concat::fragment{"jboss_sysconfig_header":
       target  => "/etc/sysconfig/jbossas",
       content => template("jboss/jbossas.erb"),
       order   => 01,
    }
}
 
class jboss::disable {
    include jboss::install
 
}
 
define jboss::setting($value) {
    concat::fragment{"jboss_${name}":
       target => "/etc/sysconfig/jbossas",
       content => "${name} = ${value}\n",
    }
}

We used a slightly modified version of the stock /etc/sysconfig/jbossas file as the template.

# This file was created and transferred by puppet
# Do not edit manually!
#
# Service-specific configuration file for jbossas services
# This will be sourced by the SysV service script after the global
# configuration file /etc/jbossas/jbossas.conf, thus allowing values
# to be overridden on a per-service way
#
# NEVER change the init script itself:
# To change values for all services make your changes in
# /etc/jbossas/jbossas.conf
# To change values for a specific service, change it here
# To create a new service, create a link from /etc/init.d/<you new service> to
# /etc/init.d/jbossas (do not copy the init script) and make a copy of the
# /etc/sysconfig/jbossas file to /etc/sysconfig/<you new service> and change
# the property values so the two services won't conflict
# Register the new service in the system as usual (see chkconfig and similars)
#
# To change a setting, uncomment the line and set the value for what you want
# The values in the comments are the default values, shown here for convenience
#
#JAVA_HOME=/usr/lib/jvm/java-1.5.0
#
##define where jboss is - this is the directory containing directories log, bin, conf etc
#JBOSS_HOME="/var/lib/jbossas"
#
##make sure java is on your path
#JAVAPTH="/usr/lib/jvm/java/bin"
#
##define the classpath for the shutdown class
##JBOSSCP=
#
 
##define jboss configuration to start
#JBOSSCONF="production"
#
##define the script to use to start jboss
##JBOSSSH="$JBOSS_HOME/bin/run.sh -c $JBOSSCONF"
#
##define what will be done with the console log
#JBOSS_CONSOLE="$JBOSS_HOME/server/$JBOSSCONF/log/console.log"
#
##define the user under which jboss will run, or use RUNASIS to run as the current user
#JBOSSUS="jboss"
#
##define the group under which jboss will run
#JBOSSGR="jboss"
#
##define the jgroups UDP group (multicast address) for clustering
#JBOSS_UDP_GROUP="228.1.2.3"
#
#define the Http Session Replication UDP port (multicast)
#JBOSS_UDP_PORT_WP="45577"
#
#define the UDP port for JBoss clustering (multicast)
#JBOSS_UDP_PORT_HA="45566"
#
#define the UDP port for the ejb3 entity cache cluster (multicast)
#JBOSS_UDP_PORT_EJB3="43333"
#
#define the UDP port for ejb3 sfsb cache cluster (multicast)
#JBOSS_UDP_PORT_EJB3SFSB="45551"
#
 
##define the timeout period for starting the server
#JBOSS_START_TIMEOUT="150"
#
##define the timeout period for stopping the server
#JBOSS_STOP_TIMEOUT="60"
#
##define the ip to which the server should bind to
#JBOSS_IP=127.0.0.1

And here are the yum repo definitions required to setup jpackage repos:

class repository::jpackage::generic {
    yumrepo { jpackage-generic:
        name           => "jpackage-generic",
        descr          => "JPackage (free) Generic",
        mirrorlist     => "http://www.jpackage.org/mirrorlist.php?dist=generic&type=free&release=5.0",
        failovermethod => "priority",
        gpgcheck       => "1",
        gpgkey         => "http://www.jpackage.org/jpackage.asc",
        enabled        => "1",
        }
}

class repository::jpackage::el5 {
    yumrepo { jpackage-redhat-el-5:
        name           => "jpackage-redhat-el-5.0",
        descr          => "JPackage (free) for Red Hat Enterprise Linux - \$releasever",
        mirrorlist     => "http://www.jpackage.org/mirrorlist.php?dist=redhat-el-\$releasever&type=free&release=5.0",
        failovermethod => "priority",
        gpgcheck       => "1",
        gpgkey         => "http://www.jpackage.org/jpackage.asc",
        enabled        => "1",
        }
}

And finally the code to call it:

node testvm-jboss {
        include repository::uncommonsense
        include repository::jpackage::generic
        include repository::jpackage::el5
        include jboss
        jboss::setting{"JBOSS_IP": value => "0.0.0.0" }

}

You can use a similar kickstart that we used in one of our previous posts to kick it off and viola! “Look Ma no hands!” – A working jboss server in less than 5 minutes.

One comment

I read your last lines related to puppet.
Can you help me configuring how puppet be configured for JBOSS deployment and configuration.

by decci on August 23, 2012 at 11:33 am. Reply #

Leave your comment

Required.

Required. Not published.

If you have one.