Unwrap your LVM partition

Today I ran out of disk space on my root partition. Since I still had some disk space left my hard disk I booted up GParted Live-CD to start resizing. Unfortunately this is not possible with a LVM partition (which is default on Fedora). Personally I think this is a bit of a bummer.

Although LVM only has a very small overhead with remapping requests to the right sector, I would rather have an ext partition on my laptop. It serves little purpose to split up mount points over a lot of logical volumes (don't want/need live volume management).

Since the physical volume contains only one volume group with only one logical volume I thought let's unwrap the ext3 filesystem hidden in there.

Note: make backups first and verify them, because this procedure hacks a new partition offset.

Because LVM is only a remapping of requests to the right sector, the data itself is on a regular ext3 filesystem. If your logical volume is splattered across multiple extents the ext3 is no longer continuous, abort at this point. For multiple logical volumes, all with 1 extent, the procedure could work as long as everything fits in a msdos partition table.

With the assumption of just 1 logical volume and 1 extent it's easy to find the start of the ext3 filesystem by doing: pvs -o+pe_start. This will show a column '1st PE'. That's where your ext3 filesystem is. For me it said '192.00K', with a block size of 512 bytes this would put the offset at 384 blocks.

Now go into fdisk and enter the expert menu. You now have the option to change the beginning of data on the lvm partition. Add the offset to the block number and change the partition type to Linux. After saving the partition you'll have a working ext3 partition instead of lvm.

Don't hide the key under a rock

This project is about a little critique I have on the mini guide for Maven password encryption.

http://maven.apache.org/guides/mini/guide-encryption.html

The guide under-states the security ramification of these measures. Which I think should be explicitly stated for a reader to attain the desired effect.

The article should stress that the 'encrypted' master password must be stored on a removable drive to attain a secure environment.

Why do I put encrypted within quotes? Because fact of the matter is that the master password is not encrypted, but simply encoded.

   @Test
   public void test1() throws Exception
   {
      String master = "{WR51wo2sI1QHlQM0MhI7AULqJXRZvtoppQsqdg74p08=}";

      DefaultPlexusCipher cipher = new DefaultPlexusCipher();

      String result = cipher.decryptDecorated(master, "settings.security");
      assertEquals("Doh!", result);
   }

This means that putting the master password in .m2/settings-security.xml would make your server password perfectly readable again.

   @Test
   public void test2() throws Exception
   {
      String master = "Doh!";
      String pwd = "{fB3b7bF6RKUHOTcOH790i8jm4C4fIBM4BZ5UvXSTODk=}";

      DefaultPlexusCipher cipher = new DefaultPlexusCipher();

      String result = cipher.decryptDecorated(pwd, master);
      assertEquals("Eeek!", result);
   }

So without introducing an external factor (like an USB key) the mechanism is just as secure as your plain password in .m2/settings.xml.

To try this out on your own passwords, simply clone
git://github.com/wolfc/plexus-cipher-test.git [1], mvn assembly:assembly and do:

$ java -jar target/jboss-plexus-cipher-test-full.jar {WR51wo2sI1QHlQM0MhI7AULqJXRZvtoppQsqdg74p08=}
$ java -jar target/jboss-plexus-cipher-test-full.jar {fB3b7bF6RKUHOTcOH790i8jm4C4fIBM4BZ5UvXSTODk=} Doh\!

In short: take the rock with you (in which case you don't need the rock anyway ;-) ).

[1] http://github.com/wolfc/plexus-cipher-test

E.T. phone home

Using some extra facilities it should be possible to call EJBs deployed on JBoss 4 from JBoss 5 (or calling 5 from 6, and even calling WebSphere from JBoss). The end result should be:

InitialContext ctx = new InitialContext();
GreeterRemote bean = (GreeterRemote) ctx.lookup("java:externalContext/Greeter");
String result = bean.sayHi("testPositive");

Now the first step should be to be able to have complete isolation of the outgoing calls, so that any existing class in the application server doesn’t collide with any client class.

// we want the client classes of the receiving application server
URL clientUrl = new URL(jbossHomeDir.toURI().toURL(), "client/jbossall-client.jar");
// don't set a parent, so we run in complete isolation.
URLClassLoader urlCl = new URLClassLoader(urls, null);
// since we're running in isolation my own interface needs to be added.
ClassLoader cl = new AluniteClassLoader(urlCl, ClassLoader.getSystemClassLoader());
ClassLoader previous = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(cl);
try
{
   InitialContext ctx = new InitialContext();
   GreeterRemote bean = (GreeterRemote) ctx.lookup("Greeter");
   String result = bean.sayHi("testPositive");
   assertEquals("Hi testPositive", result);
}
finally
{
   Thread.currentThread().setContextClassLoader(previous);
}

The most important bit is the AluniteClassLoader which has no parent class loader and delegates to the given class loaders in turn. Thus can the above code work out.

As Jaikiran correctly pointed out, the current bean proxy needs to be called within the correct context class loader. So we would also need a specialized external context which return wrappers to allow setting the thread context class loader at the right moment.

Lastly it needs code to correctly setup and install the external context in the local JNDI.

The code so far can be found here.

Visualizing code changes

Visualizing data can be an effective way to spot things that are usually hidden behind the scenes.

In that respect I like to visualize code in different ways and with Gource we have one way to visualize code changes. So using 'Animating JBoss projects with Gource' as a guide I made the following video:



Although it's a beautiful video, I fail to find any data points in it that might be useful.

But maybe after you've seen the video you can spot some?