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?

My shell keeps quiting

So I was writing a little shell script to setup some environment variables and out of habit it became:

#!/bin/bash
set -e
export X=Y

First mistake: to take in environment variables from a script I need to include it, not execute it. But whatever and moved on. And did the inclusion.

All of a sudden whenever a command return an error my shell would terminate.

Yep, second mistake (very silly) by including I had set my shell options to exit on error.

Ah well, it brought a smile to face. ;-)

Maven parent snapshot

Another case where Maven just won't listen to me. This time I want to release an artifact which has a snapshot parent dependency.

  <parent>
    <groupId>org.jboss.jpa</groupId>
    <artifactId>jboss-jpa-build</artifactId>
    <relativePath>../build/pom.xml</relativePath>
    <version>1.0.1-SNAPSHOT</version>
  </parent>

So first of all, why have the snapshot?
Because I want to have continuous integration runs on my Hudson instance.

Now I want to change the snapshot during release to 1.0.1. This is slightly bending the previous requirement where I want CI to happen. The reason is that during the lifetime of this component jboss-jpa-build will continue to evolve, while this component might remain static. So after some time this component will have a dependency on a stale snapshot. (I really want to have [0,) or latest.integration, but that's another story.)

$ mvn -DdryRun=true release:prepare
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
WAGON_VERSION: 1.0-beta-2
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss Container Managed JPA Deployers
[INFO]    task-segment: [release:prepare] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: svn --non-interactive status
[INFO] Working directory: /tmp/deployers
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : enter
Resolve Project Dependency Snapshots.: 'org.jboss.jpa:jboss-jpa-build' set to release? (yes/no) yes: : enter
What is the next development version? (1.0.2-SNAPSHOT) 1.0.2-SNAPSHOT: : 1.0.1

What is the next development version? (1.0.2-SNAPSHOT) 1.0.2-SNAPSHOT: : 

Snif...
Okay, let it ride until the end by specifying the default versions. Now we can change release.properties to match what we want:

dependency.dependency.org.jboss.jpa\:jboss-jpa-build.development=1.0.1

And tell the release plugin to restart:

completedPhase=map-development-versions

Then execute

mvn -DdryRun=true release:prepare

again.

And come to the conclusion that we encounter a bug http://jira.codehaus.org/browse/MRELEASE-449.

Error writing workspace state file

Todays maven problem is a m2eclipse problem. Somehow I get 'Error writing workspace state file' which leaves me in a workspace which doesn't properly update anymore.

org.eclipse.core.runtime.CoreException: Could not read maven project
 at org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:190)
 at org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Contains: Cannot resolve pre-scanned extension artifact: org.apache.maven.wagon:wagon-scm: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6
org.apache.maven.extension.ExtensionScanningException: Cannot resolve pre-scanned extension artifact: org.apache.maven.wagon:wagon-scm: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6
 at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModelBuildForExtensions(DefaultBuildExtensionScanner.java:369)
 at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:187)
 at org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:120)
 at org.apache.maven.embedder.MavenEmbedder.readProject(MavenEmbedder.java:377)
 at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody0(MavenEmbedder.java:416)
 at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody1$advice(MavenEmbedder.java:304)
 at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:1)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$MavenProjectReader.execute(MavenProjectManagerImpl.java:1117)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.readProjectWithDependencies(MavenProjectManagerImpl.java:967)
 at org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:180)
 at org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.apache.maven.extension.ExtensionManagerException: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6
 at org.apache.maven.extension.DefaultExtensionManager.init$_aroundBody2(DefaultExtensionManager.java:352)
 at org.apache.maven.extension.DefaultExtensionManager.init$_aroundBody3$advice(DefaultExtensionManager.java:384)
 at org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:352)
 at org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:148)
 at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModelBuildForExtensions(DefaultBuildExtensionScanner.java:365)
 ... 15 more