If you run a lot of terminal tabs or scripts that all need to make OpenSSH connections to the same server, you can speed them all up with multiplexing: making the first one act as the master and letting the others share its TCP connection to the server.

If you don’t already have a config file in the .ssh directory in your home directory, create it with permissions 600: readable and writeable only by you.

Then add these lines:

Host *
   ControlMaster auto
   ControlPath ~/.ssh/master-%r@%h:%p

ControlMaster auto tells ssh to try to start a master if none is running, or to use an existing master otherwise.

ControlPath is the location of a socket for the ssh process to communicate among themselves. The %r, %h and %p are replaced with your user name, the host to which you’re connecting and the port number - only ssh sessions from the same user to the same host on the same port can or should share a TCP connection, so each group of multiplexed ssh process needs a separate socket.

To make sure it worked, start one ssh session and keep it running. Then, in another window, open another connection with the -v option:

~ ssh -v example.com echo "hi"

And, instead of the long verbose messages of a normal ssh session, you’ll see a few lines, ending with:

debug1: auto-mux: Trying existing master
hi

Pretty fast. If you have to connect to an old ssh implementation that doesn’t support multiplexed connections, you can make a separate Host section:

Host antique.example.com
   ControlMaster no

For more info, see man ssh and man ssh_config.

If you need to transfer an entire filesystem from one machine to another, for example, when you get a new computer, do the following steps.

1) Boot both PCs with any Linux live CD (for example, Knoppix), and make sure they can access each other via the network.

2) On the source machine, mount the partition containing the filesystem to be copied, and start the transfer using netcat and tar:

cd /mnt/sda1
tar -czpsf - . | pv -b | nc -l 3333

3) On the destination machine, mount the partition to receive the filesystem, and start the process:

cd /mnt/sda1
nc 192.168.10.101 3333 | pv -b | tar -xzpsf -

The nc (netcat) command is used for any kind of TCP connections between two hosts. The pv (progress viewer) command is used to display the progress of the transfer. tar is used to archive the files on the source machine and un-archive them on the destination.

Have you ever needed to display information or get information from the user from within one of your scripts? There is a slick little utility for Gnome systems called ‘zenity‘ that will do the trick. (zenity for gnome, kdialog for KDE, xmessage for other windows managers) Here is a link to a site that has some zenity examples for you to try.

We have introduce how to make use of GUI dialog box in Using GUI dialog box, where we give an example of how zenity create a question dialog box. Besides question dialog box, zenity can create more than that, such as calendar, entry, error, info, file selection, list, notification, progress, warning, scale and text info. In this tutorial, we would like to illustrate how to create every single zenity dialog by examples.

A complete zenity dialog examples 1 » Linux by Examples.

Here are some non IT related tips. I can’t vouch for the validity of any of these - your mileage may vary.

Read more »

Here is a great article from Linux Journal.

If you have multiple computers on your desktop there are a number of scenarios for using them:

* The brute force way: get a big desk and a swivel chair and spin back and forth between keyboards/mice
* Use VNC or rdesktop to control secondary computers from your primary computer. The main problem with this is that you lose all the screen real estate on your secondary computers and end up with their desktops showing in a window on your primary computer.
* Get a KVM to allow you to switch one keyboard/mouse between multiple computers.
The normal usage of a KVM is to switch your monitor as well as your keyboard and mouse, but that’s not required. KVM’s often seem like a great solution for many peripheral sharing problems, but they’re a bit of a hit-or-miss. They often have switching problems, system boot problems, video quality problems, and if you use multiple monitors a KVM to switch multiple monitors between systems gets pretty expensive.
* Use x2x, the solution we’ll examine here, to share the keyboard and mouse between systems.

There are two ways to run x2x on Linux, the easiest is to use ssh with X forwarding enabled and ssh from the primary system to the secondary system and run x2x on the secondary system:

primary $ ssh -X secondary x2x -east -to :0

The -X option tells ssh to enable X forwarding. The “x2x …” tells ssh to run x2x on the remote system (secondary) rather than running the shell. The “-east” option tells x2x where one system is relative to the other: to the east or west (-west).

The primary system is the system whose keyboard and mouse you are actually using. The secondary system is the one that is going to share the primary system’s keyboard and mouse.

Now, if you move the mouse on the primary system over to the edge where the secondary system is the mouse pointer should move from the primary screen to the secondary screen and from now on any mouse movement should be passed to the secondary system and anything you type on the keyboard should be sent to the secondary system. If this doesn’t work try moving the mouse to the other side of the screen, if that works then restart the command using “-west” rather than “-east”.

The other method of running x2x on a Linux system is to run it directly on the primary system and tell it to connect to the X server on the secondary system:

primary $ x2x -to secondary:0.0 -east

The reason this is not the easy method is that you also need to enable remote X access on the secondary system using xhost:

secondary $ xhost primary

and you also need to open TCP port 6000 on both systems. The easiest way of doing this is going to depend on your distro.

The main advantage of the second method is that copy/paste will now work between systems.

Getting x2x to work on a Windoze system takes a bit more work, mostly because first you have to install Cygwin. Although, if you’re a Linux fan you should already have it installed, it’s the only way to make Windoze bearable. When you’re installing Cygwin make sure x2x is selected in the list of available packages.

Using x2x with Cygwin has a couple of restrictions/problems:

* You can’t use the ssh connection method.
* You have to use the Windoze system as the primary system (i.e. you have to use the keyboard and mouse on the Windoze system).
* If you have multiple displays on your Windoze system you’ll probably experience mouse problems when you return the mouse from a secondary display. The only workaround is to move the mouse very very slowly when you’re about to move off a secondary display onto the primary display.

When using x2x on Windoze run the following command from a shell prompt:

windoze $ x2x -fromwin -to secondary:0.0 -east

Generally speaking x2x works very well both on Linux and on Windoze. Every once in a while you may get a bit of mouse flakiness when you move a window on a secondary display. Also once in a while, when using the shift key you may get the unshifted character on the secondary system if you type too fast. But in most instances you won’t notice any difference between typing/mousing on the primary system and on the secondary system.

p.s. If you have a problem where you get a “>” when you type “< " you need to find a newer version of x2x. This is long-standing bug that was recently fixed.

Links are commonly used to point from one filesystem location to another. They also have a more surprising use: to make a program that does several things, deciding what to do by checking the name it was called with. Here’s an example: a single program in /usr/bin that sets, shows, and removes at jobs:

$ ls -l at*
-rwsr-sr-x 1 ... at
lrwxrwxrwx 1 ... atq -> at
lrwxrwxrwx 1 ... atrm -> at

These are simple to write as shell scripts. The script simply needs to test its name:

myname=${0##*/}  # Program name without path
case "$myname" in
at) ... ;;
atq) ... ;;
atrm) ... ;;
*) echo "$0 ERROR: ..." 1>&2; exit 1 ;;
esac

Back in the good old days, there was an operating system that didn’t seem to think NAME and name were different. The result was that sometimes when you transfered files from a floppy disk (remember them?) created on that Dumb Old System, you would clutter your directory with uppercase filenames. As us UNIX old-timers learned a nifty trick to get directory names to sort before filenames in the output of the ls command (namely, start directory names with an uppercase letter), having filenames with uppercase letters was irritating.
After using the mv command all too many times and typing things like mv FILE.TXT file.txt, I wrote this script. I was thinking I could put a new coat of paint on it but, in reality, it does the job and is easy to understand. (The line numbers are there, of course, just for reference.)

.
    1   #!/bin/sh
    2   # lowerit
    3   # convert all file names in the current directory to lower case
    4   # only operates on plain files--does not change the name of directories
    5   # will ask for verification before overwriting an existing file
    6   for x in `ls`
    7     do
    8     if [ ! -f $x ]; then
    9       continue
   10       fi
   11     lc=`echo $x  | tr '[A-Z]' '[a-z]'`
   12     if [ $lc != $x ]; then
   13       mv -i $x $lc
   14     fi
   15     done

Line 6 starts a loop (which ends with line 15). The ls command returns a list of filenames which are sequentially assigned to the shell variable x. The if test (lines 8 through 10) checks to see if the current filename is that of a plain file. If not, the remainder of the statements in the current loop iteration are skipped.

If line 11 is to be executed we know that we have an ordinary file. Using tr we convert the filename to lowercase and assign the new name to the shell variable lc. Line 12 then checks to see if the lowercase version of the name differs from the original. If it does, line 13 is executed to change the name of the original file to the new lowercase name. The -i option causes the mv to prompt for confirmation if executing the command would overwrite an existing filename.