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 \
       $PROXY_IP $PROXY_PORT

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
gateway.my.tld
you@gateway $ ssh myAppHost
you@myAppHost $ hostname
myAppHost.my.tld
   

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
myAppHost.my.tld
   

Script this !

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

#!/bin/sh
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.

fail-at-end

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).

fail-never

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 …