tips & tricks

Plant my key

4

Here’s a neat little script that I developed at “the oven place”. It “plants” my SSH key on a remote machine, so I can get in later without entering a password.

#!/bin/sh
user_at_machine=$1
# plant my SSH key on the target machine
cat $HOME/.ssh/id_rsa.pub | \
   ssh $user_at_machine \
      "if [ ! -d .ssh ] ; then mkdir -m 700 .ssh ; fi ; \
      cat >> .ssh/authorized_keys"

All of the action takes place in one single line (which I broke up here so it would wrap OK). It takes your public key from the machine you’re on, and it pipes it into an SSH session, which you’ll have to type your password into. On the remote machine, it creates a .ssh directory if it needs to, and then it appends your public key to an authorized_keys file.

The next time you log in to that remote machine, you will not need to enter your password.

Counting down with ‘pv’

0

Here’s a neat tool.

Ever start some long task, and wonder how much longer it has to go? There’s a small utility called pv (short for “pipe viewer”) that counts time and bytes through a pipe, and it shows a nice progress bar.

Here’s how I used it to watch a very large file being compressed (note the use of the most excellent lzma compression utility.

$ pv < winxp.vdi | lzma > winxp.vdi.lzma
1.79GB 0:21:50 [1.49MB/s] [===>          ] 10% ETA 3:11:02

Note that if I had used a different pipe notation, pv would not have been able to read the input file size, and therefore it could not make estimates of remaining time. So instead, it shows you the “Knight Rider” scanning eye for progress.

$ cat winxp.vdi | pv | lzma > winxp.vdi.lzma
5.48MB 0:00:04 [1.27MB/s] [  <=>         ]

Nice tool. Thanks, Andrew!

Save that thought…

1

At work, our build process can produce thousands of lines of code, and sometimes the important bits can slide off of the terminal’s scrollback buffer.

So I created an alias that logs all output of the shell. It’s nothing fancy… it’s just a call to script with an argument to put the time and date in the filename. But it goes a step further, actually exec-ing the script command, so you do not have to exit twice when you’re done (once to exit the script, and once to exit the original shell).

alias log='exec script "/home/alan/logs/terminal-$(date +%Y%m%d-%H%M%S)-$$.log"'

Still, this requires you to think about logging before you start your work.

Since I normally launch my shell windows from a Gnome application launcher icon, I decided to modify that launcher so that EVERYTHING is logged.

On Gnome, right-click on the panel at the top and select “+ Add to panel…”. Then select “application launcher” and pick out the gnome-terminal from the menus. You’ll have a little terminal icon on the top Gnome panel.

Right-click on that terminal icon and select “properties”. It should say “gnome-terminal”. Change it to the following:

sh -c "exec gnome-terminal -x script $HOME/logs/terminal-$(date +%%Y%%m%%d-%%H%%M%%S)-$$.log"

The double-percents are so the launcher will not interpret them.

Now, when you click on that application launcher icon, a new terminal window will open, and all output to that terminal will be logged.

Firefox: invalid or unsupported form of compression

0

Occasionally, I have been seeing the following error in Firefox (v3.0.11).

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

It occurs frequently when I am using a SOCKS proxy. One web site which happens to exhibit the problem more than others is Bruce Schneier’s blog.

The work-around that seems to work for me is to do a “Tools / Clear Private Data…” and select Cache, Cookies and Offline Website Data.

There’s a lively discussion on the Mozilla support forum, but no one seems to know what the source of the problem is.

Two heads are better than one

0

At work, I got a new PC with two monitors, and I have really enjoyed having the extra screen real estate.

When I worked from home this week, I decided that I needed to try hooking an external monitor to my HP laptop. I was happy that, unlike the last time I tried this a few years ago, it “Just Worked” ™ without any special calesthenics on my part.

I wondered why Gnome decided to put the panels (the bars at the top and the bottom) on the external monitor instead of on the laptop display. To me, it seemed more natural to have the “start” menu (actually, the “Applications, Places, System” tri-menu) on the external display instead of right in front of me.

It turns out that this is really easy to fix. Gnome has this configuration tool that is roughly equivalent to the Windows registry… yuck. You can access it using either gconf-editor or gconftool-2. Inside that deep mine of settings, there is one jewel that tells where the panels should go. So I wrote a quick script to move the panels from one monitor to the other and back.

#!/bin/bash

m=$1
if [[ ( ! -z "$m" ) && ( ( $m -eq 1 ) || ( $m -eq 0 ) ) ]]
then
   menu="/apps/panel/toplevels"
   panels=$(gconftool-2 --dump $menu | \
      grep '<key>.*/monitor</key>' | \
      sed -e 's/^.*<key>//g' -e 's/</key>.*$//g')
   for p in $panels
   do
      gconftool-2 --set "$menu/$p" --type integer "$m"
   done
else
   echo "usage --> $0 [ 0 | 1 ]"
   echo "moves gnome panels to monitor 0 (VGA) or 1 (LCD)"
fi
exit 0

The Quick Lounge

0

In my line of work, I occasionally have the luxury of working from home. When that happens, I prefer to run all of my applications on my desktop PC at the office, and I use “NX” to connect remotely. Specifically, I use the NoMachine NX server on my Ubuntu PC at work (although I am considering trying the open source “freenx” server), and at home I use the “qtnx” client on my laptop, which also runs Ubuntu.

This works pretty well, except my desktop environment does not like the stress of changing resolutions back and forth. It seems that the “panels” in Gnome get confused about where to place the different applets and widgets, since at one time it may have a lot of room, and at another time it may be more cramped.

I got tired of scooting my quick-launch icons around one-by-one, and so I was looking for a container where I could keep them together and move them around as a group. I tried the “drawer” applet, which is available in Ubuntu by default, but that was not quite right. I don’t want to open and close the drawer every time I launch something… I just want the icons to always be there in a group.

I found an applet called “quick-lounge-applet” which really fits the bill. One wonders whether the author meant to say “quick launch”, but perhaps had a poor grasp of English. Either way, this little applet does a great job of keeping my quick-launch icons together in a group, and it can be moved around easily.

After installing the applet (using the normal apt-get install quick-lounge-applet, I found that it was not listed in the “+ Add to panel…” menu. Apparently, Gnome needs to be prodded before it recognises newly-installed applets. There is a simple work-around. Simply re-start the service that keeps track of that stuff: killall bonobo-activation-server. The service will re-start, and there will be a new entry in the “+ Add to panel…” menu called “Launchers List”.

Now, if you’ll excuse me, I am in a hurry. I have some quick lounging to do.

ssh + netcat

1

At work, I need to access some blade servers that are on a private network. The only way to get into these machines is to shell into a lab box first, and then shell into a blade.

alan@desktop:~$ ssh root@labaccess
Last login: Tue Feb 17 10:13:52 2009 from desktop
[root@labaccess ~]# ssh root@blade3
root@blade3's password:-******
Last login: Tue Feb 17 10:14:03 2009 from labaccess
[root@blade3 ~]#

A while back, I picked up this little nugget from the TriLUG mailing list (thanks to Magnus Hedemark). There is a way to make this intermediate hop automatically. Simply add the following to $HOME/.ssh/config:

Host blade3 blade5 blade10
    ProxyCommand ssh root@labaccess "nc %h %p" 2>/dev/null

Now, when I try to ssh directly from my desktop to one of the blades, it first establishes an SSH session to the labaccess machine, and then netcat’s all of my original SSH traffic directly to the target blade.

This process will ask you for 0, 1 or 2 passwords, depending on whether your public key (from desktop) is in the $HOME/.ssh/authorized_keys files on the labaccess and bladeX machines. Since I have my public key on all of the machines, this is what I see now:

alan@desktop:~$ ssh root@blade3
Last login: Tue Feb 17 10:17:21 2009 from labaccess
[root@blade3 ~]#

This also means that I can scp files directly from my desktop to the blades, without having to dump them on the labaccess machine.

By the way, this trick provides an EXCELLENT reason to consider re-flashing your home router with Tomato firmware, which has ssh and netcat built-in.

Host homepc1 homepc2
    ProxyCommand ssh root@router "nc %h %p" 2>/dev/null

USB on VirtualBox (non-OSE)

0

I spent most of Sunday trying to get a USB device to work under Windows XP, running inside of VirtualBox OSE on an Ubuntu host. I found lots of how-to’s, mostly involving permissions on /dev/bus/usb and /proc/bus/usb, and also comments about /etc/fstab. However, the part that was not inherently obvious was that VirtualBox OSE (the “Open Source Edition”) does not support USB. However, the non-OSE version does.

Again, VirtualBox OSE does not support USB.

So I downloaded the non-OSE version (actually, on Ubuntu, you can simply add a line to your apt sources file and use the normal apt tools to install it). Within minutes, my USB devices showed up. From what I understand, you do still need to make sure to mount /dev/bus/usb.

root@kimono:~$ grep vbox /etc/group
vboxusers:x:125:alan
root@kimono:~$ grep usb /etc/fstab
none  /proc/bus/usb  usbfs  devgid=125,devmode=664 0 0
root@kimono:~$ mount | grep usb
none on /proc/bus/usb type usbfs (rw,devgid=125,devmode=666)
root@kimono:~$
Go to Top