VMware Player 5.0 Network Editor (vmnetcfg.exe)

I recently had to integrate a pre-release version of a vendor’s appliance into my development environment. The appliance consisted of a set of VMware VMs that were essentially black boxes (limited/no admin access), and for whatever reason, they had static IP addresses defined in a subnet that was not supported out of the box by VMware. While the vendor VMs were able to communicate with each other, I couldn’t actually communicate with it via my development server (VirtualBox VM).

This wouldn’t necessarily be a big deal, but for whatever reason VMware Player 5.0 does not come pre-bundled with vmnetcfg.exe. I had to do the following to get everything working:

1. Download the latest version of VMware Workstation from here
2. Open a command prompt window
3. Go to the directory you downloaded VMware Workstation and enter: VMware-workstation-full-9.0.0-812388.exe /e .\vmware_extract where “vmware_extract” is the destination directory where you want to extract the contents of the installer.
4. Navigate to the extract folder and using your favorite file archive tool (I recommend 7-zip) open core.cab
5. Copy vmnetcfg.exe to the directory you installed VMware PLayer
6. Open vmnetcfg.exe

The vendor VMs were setup with NAT, which would map to the VMnet8 virtual network.

7. Select VMnet8
8. Change the Subnet IP address (in this case, I changed mine to 192.168.10.0 with a mask of 255.255.255.0
9. Click on DHCP Settings...

10. Make sure the IP addresses are within the start and end range – update as necessary
11. Click OK

At this point, if you click Apply, your VMs should now be able to connect out. The VMware virtual network is private so I’ll need to setup some port forwarding so that I can access the machine from my VirtualBox instance through the host.

12. Click on NAT Settings...

13. Click on Add
14. Fill in the appropriate information
15. Click OK
16. Click OK

Finished!

Extending RHEL Guest HDDs on VirtualBox

1. Shutdown (power off) the VM.
2. (Optional/Recommended) Backup your current hdd image.
3. From your host: VBoxManage modifyhd <hdd>.vdi --resize <size>
4. Verify your hdd image has been resized.
5. Startup your VM.
6. sudo cfdisk /dev/sda
7. Create a new logical partition (a restart may/will be necessary) – this created a /dev/sda5 for me
8. sudo pvcreate /dev/sda5
9. sudo vgextend <volume_group> /dev/sda5
10. sudo lvextend -L+<size>G /dev/<volume_group>/<root logical volume>
11. resize2fs /dev/<volume_group>/<root logical volume>
12. Now when you type df you should note the expanded size of your root partition

JBoss, Grails, and Logging

In short, as outlined here, logging in Grails applications doesn’t necessarily play well with different containers. The basic problem the Grails war process automatically generates a web.xml that included a Grails-specific log4j listener. The solution is to remove that listener so that logging can be deferred to the container.

The post linked tries to address this problem with JBoss 5, but the information there is slightly outdated (no longer works with Grails 2.0). Additionally, I think that the recommended approach – either modifying the web.xml manually or modifying a Grails provided script (_Events.groovy) – leaves something to be desired.

My approach was to create a plugin that can be included in any application I want to be deployed on JBoss. To cut to the chase, my JbossLoggingGrailsPlugin.groovy has the following:

def doWithWebDescriptor = { xml ->
  use(DOMCategory) {
    def listeners = xml.'listener'
    listeners.each {
      if(it.'listener-class'.text() == 'org.codehaus.groovy.grails.plugins.log4j.web.util.Log4jConfigListener') {
        xml.removeChild(it)
      }
    }
  }
}

It’s important to remember to “use(DOMCategory)” so that proper manipulation of the xml file can occur (specifically removing a node). With this plugin installed, my generated WAR files have a web.xml that is free from that pesky Log4j listener…

Grails 2.0, Resources Plugin, and JQuery UI

Grails 2.0 integrates with the resources plugin which should, theoretically, make managing resources easier. Let’s see how it works with the JQuery UI plugin (since the documentation is pretty useless)…

The JQuery UI plugin defaults to the ui-lightness theme, which, in all its orangey goodness, needed to be replaced. Using the resource plugin, I can override the theme by doing the following in my Config.groovy

grails.resources.modules = {
  overrides {
    'jquery-theme' {
      resource id:'theme',
      url:[dir: 'jquery-ui/themes/redmond',
      file:'jquery-ui-1.8.16.custom.css'], 
      attrs:[media:'screen, projection']
    }
		
    'jquery-ui' {
      resource id:'js', url:[dir:'js', file:"jquery-ui-1.8.16.custom.min.js"],
      nominify: true, disposition: 'head'
    }
  }
}

In the above code, I overrode the modules declared by the JQuery UI plugin and used a newer version of JQuery UI as well as changed my theme to redmond.

JBoss EAP 5+ and Remote JMX Invocation – now with more Grails!

I had previously posted about EAP and remote JMX here. I recently had to revisit this topic since I was trying to build a simple front-end with Grails that could access some back-end services deployed on EAP. Since the services were EJBs, I thought I’d just do this again, but there seems to be some classloading issues with the embedded tomcat container in Grails 2.0-rc3.

I really didn’t want to be saddled with JBoss dependencies in the front-end, so after some investigation, a more elegant (and recommended by JBoss) solution is..

In your EAP run.conf, make the following additions:

# JMX remote stuff
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=3099"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"

# Enable the jconsole agent locally
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
# Tell JBossAS to use the platform MBean server
JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
# Make the platform MBean server able to work with JBossAS MBeans
JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"

The above enables the remote JMX port as well as exposes the JBoss MBeans for querying/invocation. Next in my Grails app:

String serverURL = "service:jmx:rmi:///jndi/rmi://localhost:3099/jmxrmi"
String username = null
String password = null
HashMap env = new HashMap()

JMXServiceURL url = new JMXServiceURL(serverURL)
if(username != null && password != null) {
	String[] creds = new String[2]
	creds[0] = username
	creds[1] = password
	env.put(JMXConnector.CREDENTIALS, creds)
}
		
JMXConnector jmxc = JMXConnectorFactory.connect(url, env)
MBeanServerConnection server = jmxc.getMBeanServerConnection()

Now I have access to all my JBoss MBeans and I don’t require any additional dependencies in my vanilla Grails application.

The information above was gleaned from a number of articles listed here.

JBoss AS 7 and Artifactory

AS 7 is drastically different from previous versions of JBoss. Two quick points on getting Artifactory up and running on AS 7:

1. Instead of binding your server using -b 0.0.0.0 you should add <any-address/> to the public interface section of your config file.
2. If you’re getting the following exception Only one JAX-RS Application Class allowed..., you can get around this by removing jaxrs from your extensions and profile section.

Anyway, just thought I’d share as I migrate some stuff over to AS 7…

Grails 2.0.0.M1 first impressions

Decided to play around with Grails 2.0.0.M1 and JDK 1.7 this weekend and here some quick thoughts:

1. If you use STS, you’ll have to download STS 1.8.0.M1 in order to run Grails 2.0.0.M1. You WILL get a permgen exception in previous versions.
2. You need to run a separate reloading agent to monitor class changes in order to have hot deployment functional:

grails -agent console

3. Grails has switched to JQuery for its javascript provider.
4. Good luck trying to run Grails from command line on Windows if anything it relies on is in a directory with a space in it. Just saying.

Anyway, still playing around with everything, but I’ll be making a post later about using Spring Security to authenticate with Facebook Connect using OAuth2.0. Expect some discourse on filters, providers, and how much I hate Facebook’s attitude towards developers…

TortoiseSVN, plink, and non-standard ports

Quick notes about TortoiseSVN over svn+ssh:
1. Typing in your password a bajillion times is annoying. I definitely recommend setting up authorized keys.
2. For Windows, I run Pageant on startup. To load your specific key file automatically:

"C:\Program Files (x86)\PuTTY\pageant.exe" "C:\private.ppk"

3. TortoiseSVN doesn’t like connecting over ssh+svn using non-22 ports. Instead of the inflexible hack shown here, I prefer this hack. The bat script that worked for me:

@echo off
set HOST=%1
set PORT=%HOST:*:=%

IF %PORT%==%HOST% (
    set PORT=22
)

c:\\Progra~1\\TortoiseSVN\\bin\\TortoisePlink.exe -P %PORT% %HOST% %2 %3

It does leave some nasty blank command prompt windows open…

CentOS 6, Subversion, SVN+SSH

I had been meaning to setup our first redShoe server, and I finally got around to it this weekend. I dusted off the Dell T110, installed ESXi 4.1, and spun up two CentOS 6 VMs. From my previous posts, it’s pretty obvious that I’m a Windows guy, so I apologize in advance if my Linux abilities are subpar.

Initially, I tried to setup my subversion repo following this handy wiki guide. Unfortunately, due to the secretive nature (not really that exciting) of my code development, I wanted something a little more secure than SVN over http. These are the steps I took to get subversion to work for me over svn+ssh…

First, I installed subversion:

yum install subversion

After which, I created my subversion directory and repository. You can place the repo anywhere, but a good amount of people choose:

mkdir /var/svn/repos
svnadmin create /var/svn/repos/<repo_name>

It’s worthwhile to note that I had already setup a number of developers who have ssh access to the server. I went ahead and assigned them to the developers group and made sure I assigned that group to my repo directory while also giving the group proper access:

chown -R :developers /var/svn/repos
chmod -R 775 /var/svn/repos

I added a script which can be found here which basically sets a umask for svnserve allowing the files it creates to be accessible by the rest of your group. Create /var/svn/svnwrapper.sh:

#!/bin/sh

# set the umask so files are group-writable
umask 002

# call the 'real' svnserve, also passing in the default repo location
exec /usr/bin/svnserve -t -r /var/svn/repos

Create a symlink in /usr/local/bin:

ln -s /var/svn/svnwrapper.sh /usr/local/bin/svnserve
chmod 755 /var/svn/svnwrapper.sh

I went ahead and made sure that my firewall let port 22 through. Add the following in your /etc/sysconfigs/iptables:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

Restart your firewall so it picks up the changes:

service iptables restart

Start svnserve as a daemon (su first):

svnserve -d

At this point, your server is all setup and you should be able to connect with your favorite SVN client (I recommend TortoiseSVN).

As a final note, if you need to shutdown your svn server it’s best to

ps auxww | fgrep svnserve

and kill the process.