Multi Hop

It is often required that, for security reason, you have to hop through a SSH gateway to access other machines. While this is perfectly fine and simple to do, it is often cumbersome to open a new session. However, with a small script you can speed up your access to machines even with such a restriction in place.

Classical way of hop’ing

Let’s say our gateway is named gateway and our target host myAppHost the classical way of doing it would be :

ssh gateway
you@gateway $ hostname
you@gateway $ ssh myAppHost
you@myAppHost $ hostname

Faster way of hop’ing

A quicker way of doing this is to specify the ssh command directly, there is one thing to tell ssh though: allocating a TTY even if it does not seem to be connected to one. In fact, the command supplied to ssh is not supposed to be interactive, that is why you need to give this hint to SSH :

ssh -t gateway ssh myAppHost
you@myAppHost $ hostname

Script this !

The script is really simple, and only consists in the following

ssh -t gateway ssh $1

Save this in your path and give it the run permission then you are all set (mine is named gssh). All you have to do to connect is now a simple gssh myAppHost

Maven testing

One of the bothering thing being a contractor is that you often happen to work on a project with a skip tests flag set on all developers computer.

One of the thing I tend to do when on such project is enabling tests and trying to fix as much as possible (often the fixes are easy to do).

Multi module testing

By design, surefire plugin make the build fail if there is a test failure. While this is ok in single module, when working with multi-module project it can be nice to run all tests on all modules regardless of the failures happening in some modules.

Maven is a great tool and allows such a behavior very easily, it allows two command line switches for that :

  • --fail-at-end : will fail the build at the end if there is test failures
  • --fail-never : will never fail the build, even if there is test failures

Flags behavior differences

There is one thing to understand when using the --fail-at-end flag, it will fail the build at end for a module with test failure but it will also prevents building of dependent modules.

With a small example it become obvious. Let’s say that we have a multi project containing the following :

  • core : containing model objects and services
  • web : containing web views for browser access
  • javafx : containing desktop application classes

It is straightforward to see that web and javafx modules will depends on the core module.


If using the --fail-at-end flag, a test failure in the core module will prevent building the web and javafx module completely : you will not be able to track tests failure before fixing the ones from core (at least on a single build command).


If using the --fail-never flag, a test failure in the core module will be reported but the build and tests of the web and javafx modules will be built and their respective tests errors will also be reported.

Tired of typing

If you find that typing --fail-at-end is too long, remember yourself it short alias : -fae.

The same is also available for the --fail-never flag with : -fn.

Switching keymap

As some of you might know, I am now using a Typematrix 2030 on a daily basis. When I switched to this great keyboard I also adopted a new layout on it : Colemak.

However, to be able to pair with others not using a Colemak mapping, I did not set the default mapping to Colemak but I instead use an udev rule to set the input method to Colemak only for the Typematrix.

Write a keymap switch script

Thanks to @BitardMichael tips and existing scripts I ended up with the following script saved in /usr/local/bin/set_typematrix_colemak_mapping

One of the tricky part was having a way of executing the script only when the keyboard is ready, without blocking udev’s job (or the keyboard is not yet visible by the X system). The workaround I found was scheduling the execution of the job with the simple at command.

Tell udev to run the script on keyboard detection

The process is really easy, all you need to do is to add the following to a new file : /lib/udev/rules.d/85-typematrix.rules

Adapting it to your use case

If you are using another keyboard than a Typematrix you will need to adapt the udev rule with the proper Vendor / Product IDs (you can grab them with lsusb). For the xinput part, you will need to adjust the grep to match your hardware.

Of course the same goes for your layout : colemak / dvorak / bépo …

Arquillian testing

Arquillian testing is very convenient to get a full environment deployed on an application server and test quickly. However sometimes we need to debug what’s inside.

Launch Maven in Debug mode

One way of doing it can be launching Maven in debug mode with the mvnDebug command instead of the classical mvn. It will open a JPDA debugger on port 8000 by default, you then just need to connect to it with your preferred IDE. But, if there is forked processes, you won’t be able to debug inside them.

Launch Failsafe Integration Tests in Debug mode

When using Arquillian, there is a high probability that Arquillian is running in a forked process (with embedded containers).

There is an easy way to tell maven-failsafe-plugin to wait for a debugger when starting : use the -Dmaven.failsafe.debug property.

You can even specify the options as you would in $JAVA_OPTS to change ports / wait…


A few days ago, I finally decided to upgrade the installed Linux on my dedicated box hosted at OVH. As with every task you tend to postpone until it is too late, it failed miserably, Murphy’s law I am looking at you right now !

During the install process, the machine hanged (I am not sure whether the machine is faulty or not, it seems to shut down under heavy load). Fortunately for me, OVH is kind enough to send a tech resets the machine, and if it does not ping when booted, the tech reboots the machine in rescue mode.

Rescue mode

The rescue mode is a lightweight Linux booted on the machine so you can run fsckand other commands to rescue your filesystem (you can even scp files to backup before a reinstall for example.

My problem was simple, I needed to allow dpkg to finish its job in order for me to get a working machine. Then I think of the good old powerful chroot command and I remembered how powerful Unixes are !

Mounting filesystems

As you should know, chroot is a command allowing to change the root of a file system, litterally jailing it into a directory (popular things of today like pico containers like Docker are improved versions of chroot).

The partition layout of my machine is the following :

  • sda1 contains the root filesystem
  • sda2 contains home directories

I issued the following commands to “jail” the rescue mode into my machine :

$ mount /dev/sda1 /mnt
$ mount /dev/sda2 /mnt/home
$ mount -o bind /proc /mnt/proc
$ mount -o bind /dev /mnt/dev
$ mount -o bind /dev/pts /mnt/dev/pts
$ mount -o bind /sys /mnt/sys 
$ chroot /mnt/

From then, I was on my machine, with my files and so on, so I have been able to run dpkg to finish the install :

$ dpkg --configure --a

Finally, dpkg sent me back to a working prompt and I have been able to reboot the machine (do not forget to change boot disk in OVH manager to hd or netboot to prevent rebooting in rescue mode).