?

Log in

No account? Create an account
"Siamese twins" monitors - Alex Belits
abelits
abelits
"Siamese twins" monitors

We all know about dual (and multiple) head setups -- install a board that supports multiple screens, or just multiple boards, or both, connect monitors, configure X to either run Xinerama or just multiple screens (or run Ultramon if you use Windows), and you have multiple screens, that share mouse and keyboard, allowing you to move the pointer around them, more or less following their physical layout.

From that point opinions are split -- some people prefer Xinerama-like configuration where all monitors form a large screen (so a window can be simply dragged between them), some keep screens separate. There is however a situation that often happens to sysadmins -- they get a lot of equipment but it's all underpowered, and the numbers of computers remains equal to the number of monitors. The obvious solution is to just attach all video cards and monitors to the fastest computer, and from there use remote X and ssh to talk to everything else. If the "main" desktop is fast enough, everything is great, however usually this is not the case, and latency+network traffic increase make this configuration rather suboptimal.

Another solution is to simply have all computers separate, and use separate keyboards and mice for them. This would be great if not the need to keep all keyboards somewhere on the desk, plus leave enough space near each of them for the mouse (or use multiple trackballs) -- the whole setup is cumbersome even with two boxes on the average desk. To save space, one can use a KVM switch without the "V" part, however having to turn the knob every time you switch between computers is annoying, and on top of that many sysadmins, myself included, hate KVM switches with a passion, and don't want to see them anywhere close to their desk on principle.

Faced with this problem, I have decided to keep "heads" where they originally were, yet build a setup where I can do everything from a single keyboard and mouse. The program to do this magic behind the scenes is already known, it's x2x, however something still has to run it when the user still has no control over a computer without a keyboard. And it would be reasonable to expect that on multiple computers joined in this setup the user may login, logout and reboot them at different times, losing the connection between them. And last but not least, there is always a matter of security -- the times when people did not think twice before typing xhost + passed long ago.

After few hours of messing with two desktops, I have ended up with the following:

ssh-x2x-master:
#!/bin/sh
if [ "$DISPLAY" = "" ]
 then
 echo "X forwarding is not active"
 exit
 fi
displayfrom=$1
location=$2
if [ "$displayfrom" = "" ]
 then
 displayfrom=:0
 fi
if [ "$location" = "" ]
 then
 location=-east
 fi
echo $DISPLAY > $HOME/.ssh-x2x-display
x2x -from $displayfrom -to $DISPLAY $location
kill -1 $PPID


ssh-x2x-slave:
#!/bin/sh
remotedisplay=$3
if [ "$3" = "" ]
 then
 remotedisplay=$DISPLAY
 fi

if [ "$DISPLAY" = "" ]
 then
 echo "X is not running"
 exit
 fi
location=$2
if [ "$1" = "" ]
 then
 echo "No hostname"
 exit
 fi
if [ "$location" = "" ]
 then
 location=-east
 fi
(
  while xset q 
  do
   ssh -n -X $1 ssh-x2x-master $remotedisplay $location
   sleep 10
  done
) > /dev/null 2>&1 &


ssh-x2x-clean:
#!/bin/sh
rm $HOME/.ssh-x2x-display
killall x2x


ssh-x2x-run:
#!/bin/sh
DISPLAY="`cat $HOME/.ssh-x2x-display`" exec $* &

The scripts are placed into some directory in the </tt>$PATH</tt> on both "master" and "slave" computers. The user who uses this configuration places his own ssh public key on the "slave" computer into his $HOME/.ssh/authorized_keys on "master", thus allowing "slave" to run x2x on "master" when "slave"'s display is ready (yes, in this case "slave" and "master" have their roles reversed).

Into whatever script runs after login on a "master" (in my case it's .gnomerc) a single line is added:


ssh-x2x-clean

This allows the "master" to remove all "stale" connections that may remain at the time of login.

On the "slave" the same line looks like:
ssh-x2x-slave userid@masterhost -east

or even:


ssh-x2x-slave userid@masterhost -east xdisplay-on-master

if $DISPLAY on "master" is not the same as on "slave", what may be the case if either of them uses remote X server.

Now, the only thing left is to log in the user on the "slave" machine and give him the local X server. While there are easier solutions, I have just configured gdm to login me on that computer, and re-login me on logout after 10 seconds of inactivity (what means, the keyboard is not attached). That lets me restart the session without losing control of the "skave" computer, and allows me to issue a halt or reboot from the Gnome logout menu, that then gdm performs for me.

Since this configuration keeps X forwarding for x2x, it's possibly to "piggyback" another application on it, running it on "master" and displaying on "slave" -- this is what ssh-x2x-run and $HOME/.ssh-x2x-display files are for. I use that to run CADs -- say, 3D one locally, 2D remotely.

The security of this setup is obviously lower than of two separate boxes -- whatever is running on the "slave" can run things on "master", and whatever has access to X on the "master", has the same access to X on the "slave". This is kinda the point of "siamese twins" metaphor in the first place. Another possible problem is that if someone attaches a keyboard or mouse directly to the "slave" computer, and they are not separately disabled, he can get access to the automatically-logged-in user's session. However this is firmly in the realm of physical security, what often is not a problem.

Right now I run two such forwarding configurations on my desktops at work -- "master" runs X servers for itself, and remote for a rack-mountable box, "slave" runs ssh-x2x-slave for both of them. So I can use Ctrl-Alt-Fn to switch the "master" screen between local and remote, however regardless of which screen is active, moving mouse east passes pointer and keyboard to the "slave"'s local screen.</i> Update: Oh, wow, I had ssh-x2x-slave truncated for three years in this entry. Fixed.

Tags: , ,

9 comments or Leave a comment
Comments
suvorow_ From: suvorow_ Date: March 29th, 2005 10:48 am (UTC) (Link)

Ой, какие люди! И без охраны!

забавно, что ты по-английски ПИШЕШЬ с русским акцентом :) А ведь давно пишешь.
abelits From: abelits Date: March 29th, 2005 10:55 am (UTC) (Link)

Re: Ой, какие люди! И без охраны!

Видимо, неисправимо.
suvorow_ From: suvorow_ Date: March 29th, 2005 11:03 am (UTC) (Link)

Re: Ой, какие люди! И без охраны!

ты извини, я на тебя подписываться не буду, тяжело читать ленту, когда её разбивают англоязычные сообщения. Но заходить буду, и ты заходи - я "под замок" не пишу.
sprainedsoul From: sprainedsoul Date: April 13th, 2005 02:19 am (UTC) (Link)

what about...

Synergy...haven't tried it, but it was recommended in SH/SC on SA

http://synergy2.sourceforge.net/index.html
abelits From: abelits Date: April 13th, 2005 04:45 am (UTC) (Link)

Re: what about...

I'll try it -- however from its description it looks like it uses a host-based security, and even with localshot and ssh it gives full access to everything that runs on the same host and connects to the local server. And someone still has to restart ssh sessions.

x2x uses X protocol, so access to it is limited by X security, and ssh merely transfers cookies and associated permissions between users and hosts. This is a much cleaner solution because it does not break the security model or gives access to something that is not always supposed to be the same user. Obviously, the main shortcoming is that it's limited to X11-based systems, however it would be much better if synergy simply reimplemented cookies (or, better, some other kind of temporary key) on systems that don't support them, and did not make assumptions about localhost being "secure".
dottedmag From: dottedmag Date: April 18th, 2005 01:39 pm (UTC) (Link)

Re: what about...

А еще у нее проблемы с клавиатурой.

Кстати, я сейчас являюсь maintaner'ом x2x. любые предложения приветствуются и заносятся в BTS :)
dottedmag From: dottedmag Date: April 18th, 2005 01:40 pm (UTC) (Link)

Re: what about...

Имеется в виду - с русской клавиатурой, да еще и правый альт вроде как глотает.
dottedmag From: dottedmag Date: April 18th, 2005 01:41 pm (UTC) (Link)
Есть желание поместить эти скрипты в contrib/ к x2x. Можно ли это сделать?
abelits From: abelits Date: April 19th, 2005 02:51 am (UTC) (Link)
Конечно.
9 comments or Leave a comment