Friday, September 27, 2013

Desktop setup

My previous post spoke about using Synergy as a software-based KVM. But to really see how useful it is, lets see how it fits into the bigger picture. This is my desktop at the moment:


Both the laptop and the desktop are connected to the big screen - one via VGA, the other via DVI.  I use the one mouse and keyboard to control both environments, using Synergy.  Most of the time, Ubuntu is on the big screen. However, if I need to use the big screen for Windows as an extended desktop, I can quickly switch the screen from the VGA to the DVI input. 

I keep files in sync between Windows and Linux using Unison. This is a two way sync, allowing both the environments to see my latest file changes. Between the MacBook Pro and Linux I use BitTorrent Sync, which is a private Dropbox replacement. I also setup TimeMachine on the MBP to backup to an external HDD plugged into Linux

This is pretty much an almost exact copy of the desktop setup I used about 4 years ago. I dont know how long I will be using this setup though - I might soon switch to using a Mac. Maybe one day when I grow up, perhaps I can get a 27'' iMac, which one of the guys here uses:

Wednesday, September 18, 2013

Synergy - software/network based KVM


Synergy is a application that allows you to share one mouse and keyboard with other PCs, similar to a KVM switch.  Typically a person will have a laptop and one or more desktops at his desk - so instead of keeping a separate keyboard/mouse for each, you can just use one to control all of them.


How Synergy works.


I use synergy running on my laptop (Windows 7) to control my desktop (Ubuntu 13.04) - all with the built-in mouse an keyboard on the laptop.

They launch at startup. However on Ubuntu, I created an entry in Startup Applications. However, this will only launch once the user is logged in. To launch Synergy earlier, you can use this recipe (I have not tested it yet).


Synergy requires an X server. That means a server must be running and synergy must be authorized to connect to that server. It's best to have the display manager start synergy. You'll need the necessary (probably root) permission to modify the display manager configuration files. If you don't have that permission you can start synergy after logging in via the .xsession file.
Typically, you need to edit three script files. The first file will start synergy before a user logs in, the second will kill that copy of synergy, and the third will start it again after the user logs in.
The contents of the scripts varies greatly between systems so there's no one definite place where you should insert your edits. However, these scripts often exit before reaching the bottom so put the edits near the top of the script.
The location and names of these files depend on the operating system and display manager you're using. A good guess for the location is /etc/X11. If you use kdm then try looking in /etc/kde3 or/usr/kde/version/share/config. Typical file names are:
    xdm  kdm  gdm
1xdm/Xsetupkdm/Xsetupgdm/Init/Default (*)
2xdm/Xstartupkdm/Xstartupgdm/PostLogin/Default (*)
3xdm/Xsessionkdm/Xsessiongdm/Sessions/Default (*, **)
*) The Default file is used if no other suitable file is found. gdm will try displayname (e.g. :0) and hostname (e.g. somehost), in that order, before and instead of Default.
**) gdm may use gdm/Xsessionxdm/Xsession or dm/Xsession if gdm/Sessions/Default doesn't exist.
For a synergy client, add the following to the first file: /usr/bin/killall synergyc sleep 1 /usr/bin/synergyc [<options>] synergy-server-hostname Of course, the path to synergyc depends on where you installed it so adjust as necessary.
Add to the second file: /usr/bin/killall synergyc sleep 1
And to the third file: /usr/bin/killall synergyc sleep 1 /usr/bin/synergyc [<options>] synergy-server-hostname Note that <options> must not include -f or --no-daemon or the script will never exit and you won't be able to log in.
The changes are the same for the synergy server except replace synergyc with synergys and use the appropriate synergys command line options. Note that the first script is run as root so synergys will look for the configuration file in root's home directory then in /etc. Make sure it exists in one of those places or use the --config config-pathname option to specify its location.
Note that some display managers (xdm and kdm, but not gdm) grab the keyboard and do not release it until the user logs in for security reasons. This prevents a synergy server from sharing the mouse and keyboard until the user logs in. It doesn't prevent a synergy client from synthesizing mouse and keyboard input, though.
If you're configuring synergy to start only after you log in then edit your .xsession file. Add just what you would add to the third file above.

Monday, September 16, 2013

Remote SSH sessions: screen

This is one of the most usefull things I have come across: when working via SSH/telnet on remote hosts, you can get disconnected for any reason: timeouts, connection drops, etc. You may have been in the middle of running a script, and now you won't know if the script finished. You can use 'screen' to overcome and simply reconnect where you left of. 

This link says it better:

Even tho this is not a direct answer to your question, it is highly related to the problem you have. Instead of trying to keep the connection alive (all connections eventually die) you can use terminal multiplexors, like screen and tmux that keep the session alive in the background even if your terminal gets disconnected.
Essentially when you login in to the SSH server you immediately run screen which will create and attach a new session:
$ screen
Then you go ahead and do your work with the shell as you would normally do. Now if the connection gets dropped, when you can get back online and reconnect to the server over SSH, you get a list the current sessions with:
$ screen -ls
To reattach to a session:
$ screen -r <session>
where <session> is the PID or a session name. You will be reconnected to your session and you can continue from where you left off!
You can even detach the session and reconnect from home to pick up from the exact point where you left off. To detach the session you use C-a followed by C-d (thats Control + A and then Control + D).
There is simple online tutorial as well.
Using screen and tmux on remote servers is considered a best practice and is highly recommended. Some people go as far as to have screen as their default login shell, so when they connect they immediately start a new screen session.

Now if you dont want to have to remember to  screen when you login to a remote box, you can automate it with these scripts:

I'm still playing around with it to see if it works for me.