The previous two posts on building the eBrainPool Linux Container have outlined the following strategies and problems associated with them : Design 1. Bridging the network interface on host Design 2. Unique network bridge for container Both the above strategies have the deficiency that they require complex root level changes to the configuration of the host system. This is undesirable since it could have serious repercussions to the user working on the host system. Our solution has to be as simple and as elegant as can be and require minimum changes to the current setup. Root access should only be required to setup the application and create the container. Root level configuration changes to the current setup are a no and requirement of having root privileges during running is also not acceptable. The strategy I am about to describe next hopefully addresses these concerns and as of this moment I believe it to be the most elegant of all solutions presented thus far.
Design 3. Port forwarding into container
The key elements in this design are as follows :
- As before each host has it's own container. The container shares the key directories of the host (read-only bind mounted) and therefore the same applications on the host can be run within the container.
- The host has a unique bridge for the container. Therefore both the host and container are on their own independent networks - for e.g. as shown above Host 1 - IP 192.168.0.106 and Container 1 - 192.168.56.101.
- The eBrainPool client runs on the host and unlike the previous designs where it too was running inside the container but was X forwarded to the host.
- This allows for the clients to be able to see each other via Avahi without changing the host's avahi configuration and putting it in reflector mode so that it can broadcast Avahi messages from the client inside the container.
- Using ssh's local port forwarding mechanism to establish dynamic port forwarding to the container.
This last point above is what makes this entire solution so elegant imho.
Design 2 needed a persistent port forwarding rule to be set on the host computer. Clients across the network don't have direct access to the container on a particular host since the container is on it's own private network. Port forwarding would allow for the client to talk to the other hosts on the same network and this communication to be forwarded to the respective containers. A persistent port forwarding rule is however an undesirable change to the configuration of the host.
In this strategy, once an eBrainPool client receives a request to launch an application from the current host and the user accepts, the ssh client on the host communicates with the ssh server in the container and sets up local port forwarding. For e.g.
ssh -g -L 4321:192.168.56.101:22 192.168.56.101Now any communication on port 4321 of the host will automatically get forwarded to the ssh server on the host. The host that sent the request (Host 2) is then notified that the request has been accepted and is passed along the port no. on which further communication should be carried forward. Host 2 then calls on it's ssh client to communicate with port 4321 on Host 1 i.e.
ssh -p 4321 ebp@192.168.0.106 -X [application]Port 4321 on Host 1 (192.168.0.106) is automatically forwarded to Container 1 (192.168.56.101) and therefore this ssh client ends up establishing a connection with the ssh server in the container and X forwarding an application from within the container.
No need of a static persistent rule for port forwarding. No need for major changes to configuration on the host.
Simple. Clean. Effective :) As of this moment I plan to move ahead and implement the container using the above design. Any refinements will be done as we encounter problems and feedback....stay tuned :)