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.

Virtual machine stacking Using LXC on top of ESX

by lesliebuna on January 1, 2012 | One comment

What is LXC?

From Dwight Schauer:
“Linux Containers (LXC) are an operating system-level virtualization method for running multiple isolated server installs (containers) on a single control host. LXC does not provide a virtual machine, but rather provides a virtual environment that has its own process and network space. It is similar to a chroot, but offers much more isolation.”

Creating Virtual Environments within Virtual Machines using Red Hat Enterprise 6 or Centos 6

Why would anyone ever want to do this? Well for a number of reasons:

1. You only have access to one virtual machine but want to create multiple isolated services.

2. Have a requirement for multiple Linux OS versions but don’t want to invest in a heavyweight virtualisation solution.

3. Creating virtual multilayer services to that you wish to be deployed as a single virtual machine, think about a virtual network of machines encapsulated in a single easily deployed package that would only expose a single IP address e.g. reverse proxy, tomcat java container, database, and internal virtual networks).

4. Creation of lightweight development environment.

It so works on KVM, Virtualbox as well as VMware Vsphere.

LXC Setup

LXC needs kernel namespaces which is fully supported in 2.6.26 kernels and above which are currently upstream of Red Hat Enterprise Linux 5 so I opted to go to RHEL6 so I wouldn’t have to roll and maintain my own kernel (CentOS 6 wasn’t out when I tried this but it should just work).
For Red Hat Enterprise Linux 6 you will also need the RHN Optional Channel enabled so you can get ruby-selinux.

So let proceed onto how to get, compile and install LXC:

$ wget http://downloads.sourceforge.net/project/lxc/lxc/lxc-0.7.3/lxc-0.7.3.tar.gz
$ rpmbuild -ta lxc-0.7.3.tar.gz
$ yum --nogpg install lxc-0.7.3-1.x86_64.rpm libvirt
$ mkdir /var/lib/lxc /usr/lib64/lxc/rootfs /etc/lxc /cgroup
$ cat >> /etc/fstab < none /cgroup cgroup defaults 0 0
EOF
$ mount /cgroup

If your using DHCP on your network you can easily setup network bridging by doing the following:

?
$ cat > /etc/sysconfig/network-scripts/ifcfg-br0 <> /etc/sysconfig/network-scripts/ifcfg-eth0 < BRIDGE=br0
EOF<strong>
</strong>$ service network restart


And voila! LXC is now configured and ready for use, now all you need to do is install a LXC container.
Hint: I typically create a dedicated LVM Volume Group and Logical Volume for each LXC container and mount them under /srv/lxc/ e.g. /src/lxc/myvirtualbox in order to prevent it spilling over into the hosts file system and impacting other services.
You need to already have or create a lxc template here’s a link on how you can create one based on Centos 5.

Here’s some additional stuff I do: Chroot into the template and disable Bluetooth

$ chkconfig bluetooth off

Delete the ssh *key and *.pub from /etc/ssh

$ for key in `ls /etc/ssh/* | grep -e key -e pub` ; do echo rm $key ; done

Remove the HWADDR setting in the /etc/sysconfig/network-scripts/ifcfg-eth0

$ sed -i 's/HWADDR.*$//g' /etc/sysconfig/network-scripts/ifcfg-eth0

Ensure that tty’s 1-4 are not commented out in /etc/inittab from each image before packaging the template up.

After that’s done and you have your template on your LXC host and are ready to deploy it.

cd /srv/lxc
mkdir myvirtualbox
tar zxvf /path/to/template/tar/gz/file
vi /etc/lxc/myvirtualbox.conf

Paste the following into the file (adjust as necessary):

lxc.utsname = myvirtualbox
lxc.tty = 4
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.mtu = 1500
lxc.network.ipv4 = 0.0.0.0/24
lxc.rootfs = /srv/lxc/myvirtualbox
lxc.mount = /etc/lxc/myvirtualbox.fstab
lxc.cgroup.devices.deny = a
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
# /dev/pts/*
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm

Save the file and create a new fstab file

Save the file and create a new fstab file

Paste in the following data and edit as necessary

none /srv/lxc/myvirtualbox/dev/pts devpts defaults   0 0
none /srv/lxc/myvirtualbox/proc    proc   defaults   0 0
none /srv/lxc/myvirtualbox/sys     sysfs  defaults   0 0
none /srv/lxc/myvirtualbox/dev/shm tmpfs  defaults   0 0

Now you can create myvirtualbox lxc container by typing in

$ lxc-create -f /etc/lxc/myvirtualbox.conf -n myvirtualbox

And fire it up and a console to go with it using screen:

$ screen -dmS init-myvirtualbox /usr/bin/lxc-start -n myvirtualbox
$ screen -dmS console-myvirtualbox /usr/bin/lxc-console -n myvirtualbox

You can now use the following command to see the init boot session

$ screen -r
init-myvirtualbox

To see and interact with the console.

$ screen -r console-
myvirtualbox

JBoss 5.1.0A RPM Spec

by lesliebuna on January 1, 2012 | Leave your comment

I know some of you out there are running JBoss 5.1.0 GA, so not to let you all feel left out, I’ve created an RPM Spec file to let you easily package and roll out your own 5.1.0 packages.

Name: jbossas5
Version: 5.1.0.GA
Release: 1
Group: Internet/WWW/Servers
Summary: JBoss Application Server
Vendor: Red Hat
URL: http://www.jboss.org/
BuildArch: noarch
License: LGPL
Source0: http://downloads.sourceforge.net/project/jboss/JBoss/JBoss- 5.0.1.GA/jboss-%{version}-jdk6.zip
Source1: %{name}.init
BuildRoot: %{_tmppath}/%{name}-%{version}-root
Requires: shadow-utils
Requires: java >= 1:1.6.0

%description

JBoss Application Server (or JBoss AS) is a free software/open-source
Java EE-based application server. An important distinction for this
class of software is that it not only implements a server that runs
on Java, but it actually implements the Java EE part of Java. Because
it is Java-based, the JBoss application server operates cross-platform:
usable on any operating system that supports Java.

JBoss AS was developed by JBoss, now a division of Red Hat.

%prep
%setup -n jboss-%{version}

%install
rm -rf %{buildroot}
install -d -m 755 %{buildroot}/opt/%{name}

cp -R . %{buildroot}/opt/%{name}
install -d -m 755 %{buildroot}%{_initrddir}
install -d -m 755 %{buildroot}%{_sysconfdir}/sysconfig
install -p -m 755 %{SOURCE1} %{buildroot}%{_initrddir}/%{name}
rm -rf %{buildroot}/opt/%{name}/server/*/deploy/ROOT.war

%clean
rm -rf %{buildroot}

%files
%defattr(-,jboss,jboss)
/opt/%{name}
%attr(0755,root,root) %{_initrddir}/%{name}

%pre
getent group jboss >/dev/null || groupadd -r jboss
getent passwd jboss >/dev/null || \
useradd -r -g jboss -d /opt/${name} -s /bin/bash -c "JBoss AS Daemon" jboss
exit 0

%changelog
* Mon Dec 6 2010 Martin Jackson 5.1.0.GA-1
- Initial creation

All you need to do is download the 5.1.0 JDK version of Jboss from Sourceforge, copy the jboss_init_redhat.sh from the bin directory of the zip file to your SOURCES directory.