Wikipedia defines Web Access Management as:
Authentication Management
Policy-based Authorizations
Audit & Reporting Services
Single sign-on Convenience

I’ve had previous experience in this space using CA’s Siteminder product but this time I want to experience some “open” alternatives where the information on the use and configuration of the product isn’t as limited and the costs aren’t as great.

Initially I thought I’d have a look at JOSSO (Java Open Single Sign On)

Installing Josso

Enter “osgi:list | grep Atricore” to confirm the services are started and running.

Browse to http://jossohost:8081/atricore-console/ default login is admin:admin

I was working on a project that ran a java jar file e.g. java -cp application.jar and I initially wrote a simple initscript to stop and start it.Unfortunately it would not daemonize cleanly and dump tons of “useful” info and debug data to the console, eventually it got to the point where I only felt comfortable starting it in using screen.

I finally got time to revisit the situation and look at Tanuki’s Java Service Wrapper software, unfortunately it was incompatible with the project I was working on (and by incompatible I mean it was going to cost me lots and lots of license fees).

Enter YAJSW – Yet Another Java Service Wrapper (http://yajsw.sourceforge.net/):

“YAJSW is a java centric implementation of the java service wrapper by tanuki (JSW).
It aims at being mostly configuration compliant with the original. It should therefore be easy to switch from JSW to YAJSW.”

And it only took me minutes to get working:

• Download yajsw from Sourceforge
• unzip to your application’s working directory
• Run the java application and go to $applicationdir/yajsw/bat
• Change the mode to all the shell scripts e.g. chmod a+x *.sh
• Run ./genConfig.sh $java_app_pid
• Edit $applicationdir/yajsw/conf/wrapper.conf and customise it to your needs
• Run ./runConsole.sh to check if the application is running correctly.
• If you want to install the service run ./installService.sh this will create the required initscripts and place them into /etc/init.d/ and /etc/rc.d/runlevel directories.
• You can then choose to either run the startService or stopService shell scripts or use the newly created one in /etc/init.d.

More detailed configuration can be found on their main site and this one is definitely a keeper for my java deployment toolkit.

I’m beginning to see what Ken Barber (@ken_barber) was hinting at when he told me at the last EU Devops Days conference that configuring linux firewalls was just tip of the iceberg, I can now see the path of it being used to configure Cisco and Juniper based firewalls eventually.

To get the puppet-firewall module working for me out of the box I had to add the following to my site.pp

After that I configured a base firewall module e.g.

Top Marks for this module!

http://github.com/puppetlabs/puppetlabs-firewall

Unfortunately, I was having an issues, that after a set amount of time the MySQL nodes would stop accepting connections.

After a bit of failed googling I visited the #haproxy irc chat on Freenode and a couple of helpful fellows called @vr and @meineerde pointed me to this section of the HAProxy configuration guide:

  …It was reported that it can generate lockout if check is too frequent and/or if there is not enough traffic. In fact, you need in this case to check MySQL “max_connect_errors” value as if a connection is established successfully within fewer than MySQL “max_connect_errors” attempts after a previous connection was interrupted, the error count for the host is cleared to zero. If HAProxy’s server get blocked, the “FLUSH HOSTS” statement is the only way to unblock it.

I had already set the max_connect_errors in my.cnf file to be 1000 but I guess that was no way enough. After looking around the net a bit looking for inspiration I’ve decided to set it to:

In order to create a WordPress server I need 4 main components:

A Server with an Operating System installed
A MySQL database
A HTTP Web Daemon and
The WordPress application itself.
So like a good boy scout I set off about installing a WordPress on a centos box by hand and I found some most excellent instructions here by Andrew at Adlibre.

I hit my first problem, the WordPress package from EPEL for RHEL/CentOS 5 is quite old, it’s 2.8 while the version of WordPress with all the new hotness is 3.0.

Hmm ”old busted” or “new hotness” (not to say the 2.8 is either old or busted but you get what I mean). I decided I’d roll with the new hotness and then I hit another dilemma I couldn’t find a RPM for RHEL/CentOS 5, so should I just roll out the tar ball or create a package for it?

This is currently a hot topic in the Devops community and when I went to Devops Hamburg back in October one of the more popular open space sessions was “packaging vs. non-packaging, when and what?” and the main output was it “depends”.

However I wanted a zero touch and fully automated deployment so I investigated both methods and weighted them up:

Scenario 1 – Installation of Tar ball

Download WordPress tar ball to the server file system
Untar the package and install it to the correct location
Track the installation and ensure that it is valid (correctly installed, all checksums in place (Thanks AndrewH!)) also be able to cleanly handle upgrades.

Scenario 2 – Installation RPM

Package WordPress RPM
Yum install WordPress

I quickly came to the conclusion that the packaging case won over when I imagined the amount of puppet code I’d have to churn out to do scenario #1 and make it robust versus just using what I believed was the right tool for the job i.e. RPM and keeping it as simple as possible.

OK now I have my newly packaged WordPress 3.0 rpm and life is good, everything else I need is already packaged and can be easily installed using yum, a few minutes later I have a fully functioning WordPress server.

Now for the fun part, how do a fully automate the creation of a WordPress server end to end.

Firstly I created a custom kickstart profile on my cobbler server to install a minimal Just Enough Operating System (JeOS) base build (faster to install and patch with the minimum security attack surface) with some additional post install stuff to bootstrap puppet.

For the MySQL installation and configuration I wanted something a little more robust since I believed I could make a lot of use out of a good MySQL puppet module. I found it quite ironic that I stumbled across a problem that I had previously answered on server fault that being how do you find a top notch MySQL module:

There were quite a few out there and after a fair bit of back and forth I settled on the Camp to Camp boys’ MySQL puppet module, it is very functional and quite compact in the amount of supporting modules that are needed to make it function:

There were quite a few out there and after a fair bit of back and forth I settled on the Camp to Camp boys’ MySQL puppet module, it is very functional and quite compact in the amount of supporting modules that are needed to make it function:

puppet-mysql
puppet-augeas
puppet-common

You’ll need to have the plugin sync enabled in your puppet.conf for this to work because it copies some custom facts and plugins to the client in order to create the databases.

Onto the final stretch I need to install WordPress so I whipped up the following puppet module to install WordPress.

I used the following entry in my nodes.pp file to pull it all together

Ok so I now have a fully functional WordPress Server in about 5 minutes. This is just a basic setup but it demonstrates what can be done without too much effort and if I wanted to take this further in the future, I would create an erb template for the wp-config.php so that the database settings are populated by puppet using the existing username, password and database name variables.

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:

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.

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

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

And finally the code to call it:

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.

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:

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

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

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

Remove the HWADDR setting in the /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.

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

Save the file and create a new fstab file

Paste in the following data and edit as necessary

Now you can create myvirtualbox lxc container by typing in

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

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

To see and interact with the console.

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.

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.