Limiting SSH access to certain users

There are multiple ways to limit SSH access to a machine. The one I’ve found most straight forward is to use PAM access rules. First, edit /etc/pam.d/sshd and uncomment the line:

account required

Next, edit /etc/security/access.conf

The following rules allow root from a local connection and deny all but users in the SSH group.


With this in place, managing SSH access is a matter of tweaking the ssh group.


Accessing end-of-life’d Ubuntu packages

Sometimes it’s necessary to keep a server running an end-of-life’d version of Ubuntu breathing just a bit longer. Because Canonical removes old packages from, apt-get install will spew out messages like:

Err karmic-updates/main libpam0g 1.1.0-2ubuntu1.1
404 Not Found [IP: 80]

You can update /etc/apt/sources.list to use the URL instead of and get to those packages.

Note, old versions of Ubuntu no longer receive security updates, so upgrading is the best way to go.

Using the Debian alternatives system

On Debian-based systems like Ubuntu it is possible for common programs to have multiple versions. The alternatives system is a way to manage what version is used when a command is run.

Vi, for example, can have multiple versions, and even variants such as vim, installed. Recently I custom-compiled vim in order to get CommandT working and realized that it broke if I ever ran vi instead of vim.

I fixed this by, first, adding /usr/local/bin/vim as an alternative for vi:

sudo update-alternatives --install /usr/bin/vi vi /usr/local/bin/vim 1

And subsequently set it as the alternative running the command:

sudo update-alternatives --config /usr/bin/vi


CommandT on Ubuntu 11.04 & 11.10

Vim has a pretty awesome fuzzy search plugin, named after the TextMate shortcut, CommandT. Installing it is fairly straight forward, but it crashes pretty bad on Ubuntu. After some reading I found out it is because Ubuntu ships a version of vim with flaky Ruby support.

In order to recompile I installed the following packages:

sudo aptitude install python-dev ruby-dev mercurial ncurses-dev liblua5.1-0-dev lua5.1

I then followed Kresimir Bojcic’s instructions on building from the HG repo and ended up with vim in /usr/local:

hg clone ~/vim 
cd ~/vim
hg update -C v7-3-154
./configure --with-features=huge  --disable-largefile \
            --enable-perlinterp   --enable-pythoninterp \
            --enable-rubyinterp   --enable-gui=gtk2 \
sudo make install

With a new vim installed I followed the *command-t-installation* instructions and so far it has been stable.

Update 2012-01-16: After installing 11.10 I found that vim doesn’t have ruby support at all. Following the instructions above worked like a charm.

Hash buckets, rsync, and xargs magic

At work we have a couple of directories that are organized as two-deep hash buckets, totaling 65536 directories [1]. This creates a ton of directories and traversing this, e.g. find . -type f, takes ages. This structure also causes rsync to take up a lot of memory.

One way to solve this is to work on a single directory at a time instead of all 256 directories (each containing 256 directories of their own). For example, this will run rsync once per directory which dramatically decreases rsync‘s work load and works pretty well:

for i in *; do rsync -a $i server:/path/to/dest/$i; done;

With xargs the serial process above can be parallelized. The following will continually process 8 directories until all 256 have been copied over:

ls | xargs -n 1 -P 8 -I% rsync -a % server:/path/to/dest/%

I tried with 32, 16, then 8 parallel processes. In my case a -P value more than 10 will cause xargs to explode trying to create that many rsync processes. I haven’t figured out why, but it really doesn’t matter. With 8 running in parallel, the disk and network should be pretty well saturated anyway.

[1] the base directory has 256 directories 00 – ff, which each have 256 00 – ff directories in them. 256^2 = 65536 directories.

OS X + VirtualBox + Ubuntu 10.10 = Flaky Resolution

I’ve been using a VirtualBox VM running Ubuntu 10.10 quite a bit recently. After getting the base system up and running I installed version 4.0.4 of the guest additions. The guest additions handle VirtualBox shared folders, the clipboard, and screen resolution.

I want to use the VM in full screen; i.e. it looks like I’m running Ubuntu on my MacBook Pro. I’ve been having the hardest time with the screen resolution. One minute it appears to be working, and then all of a sudden the screen resolution gets “off” and it no longer fills the screen. Since having a dynamically resizable screen isn’t a priority at the moment, I figure out how to “hard code” the full resolution I want.

Ubuntu 10.10 no longer has /etc/X11/xorg.conf. Instead if Xorg doesn’t have this configuration file, it automatically figures things out while it’s running. That’s great, but at least in VirtualBox it apparently doesn’t get the screen resolution right (I’m guessing the blame falls on VirtualBox for not properly relaying the screen resolution to the guest OS). In any case, the first thing to do is actually get an xorg.conf file. This can be done by:

  • logging out of the GUI
  • dropping into a console (e.g. ctrl+alt+F1)
  • logging in as root
  • Stopping GDM (service gdm stop)
  • Run X -configure
  • cp /root/ /etc/X11/xorg.conf
  • Now that the configuration file is in place, find the Display section and add the resolution mode you’re interested in; in my case, my screen res is 1680×1050:

    SubSection "Display"
    Viewport 0 0
    Depth 24
    modes "1680x1050_60.00"

    Finally, service gdm start

    The screen resolution should be full again. Remember the screen resolution will not be dynamic anymore, but that was already jacked.