Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to pass extra options do Docker? #332

Open
chlohr opened this issue Jan 19, 2025 · 5 comments
Open

How to pass extra options do Docker? #332

chlohr opened this issue Jan 19, 2025 · 5 comments
Assignees

Comments

@chlohr
Copy link

chlohr commented Jan 19, 2025

Related Bug

Hi,
Is there some way to pass extra options (or volumes) to Docker?
(I would have been interested in mounting /tmp/.X11-unix/X0 ;-) )

Best regards

Feature Description

Offering some ways for a GUI would be a plus.

Solution

No response

Alternative Solutions

No response

Additional Context

No response

@tcaiazzi
Copy link
Member

Dear @chlohr,

Thank you for opening this issue!

Currently, directly passing extra options to Docker is not supported. However, we are actively exploring the possibility of adding support for mounting additional volumes on devices in the upcoming releases.

Could you please share more details about your specific use case?

This will help us understand your requirements better and potentially find a suitable solution using the currently available features.

Thanks!

@chlohr
Copy link
Author

chlohr commented Jan 23, 2025

Hello,
My goal is to use X11 applications ;-)

The simplest and lightest way to do this is to share the unix socket /tmp/.X11-unix/X0 from the user's session on the host machine towards the containers.
(bind mount of the socket file)

Of course, there are then a few details to adjust ('export DISPLAY=:0' in containers, and 'xhost +SI:localuser:$USER' on the host).
But sharing the unix socket does the job.

This is why I would be interested in ways to pass such extra mounting option to docker.

For now, my workaround is to put this unix socket in the /shared/ folder (with symlink to /tmp/.X11-unix/X0), and having a forwarding process in the host
('socat UNIX-LISTEN:./shared/X0,unlink-early,fork UNIX-CONNECT:/tmp/.X11-unix/X0')

Another alternative is to do X11 via TCP ('export DISPLAY=172.17.0.1:0'), and a forwarder
('socat TCP-LISTEN:6000,fork,bind=172.17.0.1 UNIX-CONNECT:/tmp/.X11-unix/X$0').
But this requires a linked network interface on the nodes, which complicates network configuration on the nodes and disturbs my teaching objectives.

A final alternative is to ssh -X from the host, which requires finding the binded IP addresses of the nodes.

But all these alternatives are complicated. I'd rather just share the X11 unix socket as mentioned at the beginning.

Regards

@jcondor98
Copy link

Btw such feature would likely solve #329 straightforwardly.

@tcaiazzi
Copy link
Member

tcaiazzi commented Jan 28, 2025

Dear all,

We will try to implement the feature in the next release 🚀

I'm super interested in your use case @chlohr… Do you have any example to share? 😇

@chlohr
Copy link
Author

chlohr commented Jan 29, 2025

Hello,

Being able to pass additional options to docker will certainly enable us to experiment with many additional use cases. That's great.

As mentionned above, my wish is to run some usual X11 applications in the container.
(Not only wireshark, but also firefox thunderbird driftnet zenmap etc.)

For this, doing a bind mount of the unix socket for X11 (/tmp/.X11-unix/X0) is sufficient.
(With a limitation: this can't work with Docker Desktop)

For now, my fall-back solution is to do a plain-old (but robust) X11 TCP forwarding from guest to the host, via the bridged interface offered by docker.
Guests just do an 'export DISPLAY=127.17.0.1:0' (or similar), and the host open a listen TCP socket on port 6000 and forward it to its own DISPLAY (socat is fine for that).
(Bellow is a piece of shell script to do this.)
The downside is that the additional bridged interface pollutes the lab's network configuration and can be troublemaker for students.

A more innovative solution might be to transmit X11 connections via a vsock between each guest and the host.
Unfortunately, at the moment, docker isn't very friendly with vsocks ;-)

#!/bin/bash


echo -n "Get docker bridge gateway... "
GW=$(docker network inspect bridge | jq -r '.[0].IPAM.Config[0].Gateway')
echo "$GW"

echo
echo -n "Start an x11 forwarder... "

XHOSTNAME="${DISPLAY%%:*}"
TMP="${DISPLAY##*:}"
DISPLAYNUMBER="${TMP%%.*}"

if [ -n "$DISPLAYNUMBER" ] ; then

  if [ -n "$XHOSTNAME" ] ; then
    DEST="TCP:$XHOSTNAME:$((6000 + DISPLAYNUMBER))"
  else
    DEST="UNIX-CONNECT:/tmp/.X11-unix/X$DISPLAYNUMBER"
  fi

  for ((N=0; N<50; N++)); do 
    INUSE=$(ss -tnl "sport = :$((6000 + N))" | tail +2)
    if [ -z "$INUSE" ]
      then break
    fi
  done
  
  socat "TCP-LISTEN:$((6000 + N)),bind=$GW,fork" "$DEST" &
  echo $! > ./x11_forward.pid
  
  echo "export DISPLAY=$GW:$N" > ./shared/.x11.sh
  echo -n > ./shared/.Xauthority
  xauth -f ./shared/.Xauthority add "$GW:$N" $(xauth list $DISPLAY | head -1 | tr -s ' ' | cut -d ' ' -f 2-)
  echo "done"

else
  echo "Error: no DISPLAY"
fi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants