From: W. Trevor King <wking@drexel.edu>
Date: Wed, 18 May 2011 15:57:44 +0000 (-0400)
Subject: Add mxconns post and package reference.
X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=73cb21837c5054f3640aa3d3b8a99af79f94a645;p=blog.git

Add mxconns post and package reference.
---

diff --git a/posts/Gentoo_overlay.mdwn b/posts/Gentoo_overlay.mdwn
index 1d89053..1c549a3 100644
--- a/posts/Gentoo_overlay.mdwn
+++ b/posts/Gentoo_overlay.mdwn
@@ -28,7 +28,8 @@ personal `layman.xml`).  The overlay is a fairly strange mix:
 - dev-util/be
   ([Gentoo 303867](http://bugs.gentoo.org/303867))
 - media-gfx/metacam
-  ([Gentoo 65200](http://bugs.gentoo.org/65200))
+  ([Gentoo 65200](http://bugs.gentoo.org/65200), but I suggest you use
+  `media-gfx/exif` if you don't need `metacam`'s special decoding)
 - media-sound/abcmidi
   ([Gentoo 76017](http://bugs.gentoo.org/76017),
    also in the [Sunrise overlay][])
@@ -52,6 +53,8 @@ personal `layman.xml`).  The overlay is a fairly strange mix:
   (my [[sawsim]] force spectroscopy simulator)
 - virtual/thesis-tools
   (useful dependencies for compiling a [[thesis]])
+- x11-misc/mxconns
+  ([[mxconns]])
 
 For those that aren't yet familiar with layman and overlays, install
 layman with:
diff --git a/posts/mxconns.mdwn b/posts/mxconns.mdwn
new file mode 100644
index 0000000..e4813ec
--- /dev/null
+++ b/posts/mxconns.mdwn
@@ -0,0 +1,88 @@
+[[!meta  title="mxconns"]]
+
+[Lionel Cons][LC]'s [mxconns][] is an X Windows monitor and proxy.
+The author suggests you use it to enhance the security of your X
+server by monitoring for connection attempts and dangerous requests
+(e.g. keylogging).
+
+I ran into it while trying to get X forwarding working with my
+[[cluster|Abax]].  Ususally if you [[SSH]] into a remote computer and
+want to run X applications, you use `ssh -Y` to forward your X
+connection to the remote host, and everything works as expected.
+However, I could not figure out how to expose the forwarded server so
+it could except connections from other nodes in the cluster.  For
+example, if a job I had running on `n1` wanted to talk to my X server
+(e.g. via [[MPE]]), it would need to connect to `n0`:
+
+    home <--(ssh -Y)----> n0 <--(???)----> n
+
+`mxconns` fills the gap by providing a proxy between the local socket
+provided by `ssh -Y` and a new publicly exposed X socket available to
+`n*`:
+
+    home <--(ssh -Y)----> n0 <--(mxconns)----> n1
+
+`mxconns` needs a configuration file telling it to trust all the
+computers on the cluster, which should look something like:
+
+    n0$ cat ~/.mxconns 
+    192.168.2.*     allow
+
+After you've set that up, a full connection will look like
+
+  home$ ssh -Y n0
+  n0$ export DISPLAY=`mxconns -config ~/.mxconns -fork -hunt -verbose`
+  n0$ echo $DISPLAY
+  n0.*.edu:5
+
+after which you can do things like
+
+  n0$ ssh n1
+  n1$ export DISPLAY=n0:5 xeyes
+
+You can explicitly kill `mxconns` when you're done:
+
+  n0$ killall mxconns
+
+or just wait and it will die naturally when you close your initial X
+connection to `n0`.
+
+Packaging
+---------
+
+`mxconns` is enough of a niche app that it's not widely packaged at
+the moment.  However, building and installing it is really easy, and
+is well explained in the `README` file.  I've added an ebuild to my
+[[Gentoo overlay]] if you're running Gentoo.
+
+Messy details
+-------------
+
+`ssh -Y` sets up an X proxy on `n0` on 127.0.0.1:6010 and sets my
+`DISPLAY` to `localhost:10.0`:
+
+    n0$ netstat -an | grep 6010
+    tcp     0    0    127.0.0.1:6010    0.0.0.0:*    LISTEN
+    tcp6    0    0    ::1:6010          :::*         LISTEN
+
+However, I *want* the X proxy to bind to `eth0` (192.168.2.100) not
+localhost (127.0.0.1), so other nodes can connect.  If you're using
+[OpenSSH][]'s `sshd` on `n0`, you can set `X11UseLocalhost no` in your
+`sshd_config`.  However, this binds the `ssh -Y` X connection to the
+wildcard address, exposing it to the world through eth1 (which is bad)
+as well as to the cluster through eth0 (which is good).
+
+X authentication is handled with cookies, and getting cookie detection
+working in `mxconns` turned out to be a key part of patching `mxconns`
+to work in this situation.  The `ssh -Y` connection stores its X
+authority cookie under `hostname/unix:dpynum`:
+
+    n0$ xauth list
+    n0/unix:10  MIT-MAGIC-COOKIE-1  ...
+
+as described under the `DISPLAY NAMES` section of [xauth(1)][xauth].
+
+[LC]: http://cons.web.cern.ch/cons/
+[mxconns]: http://mxconns.web.cern.ch/mxconns/
+[OpenSSH]: http://www.openssh.com/
+[xauth]: http://www.x.org/archive/X11R6.8.1/doc/xauth.1.html#sect5