Proxying with Docker

When using docker under a corporate proxy, it can be cumbersome to have a working networking in all containers. You often end up being blocked by specific network access which does not seem to be properly forwarded to the proper proxy. For example when using apt.

Classic way of doing

There is a documented way of using a proxy, by adding command-line switches to your docker deamon. However, it does not seem to work everytime and could require exporting additional settings to your in-container applications (in my experience though).

Why not using docker

Nicolas pointed me an image he created to help with the setup of a corporate proxy. It uses redsocks under the hood that listen to the docker socket and automatically add the glue to do the forwarding through the proxy.

Easy proxying in docker is just one command away ! (fill in the blank of your proxy ip and port)

docker run \
       --restart=always \
       --privileged=true \
       --net=host \
       -d ncarlier/redsocks \

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…