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 pam_access.so
The following rules allow
root from a local connection and deny all but users in the
-:ALL EXCEPT ssh:ALL
With this in place, managing SSH access is a matter of tweaking the
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 http://archive.ubuntu.com karmic-updates/main libpam0g 1.1.0-2ubuntu1.1
404 Not Found [IP: 188.8.131.52 80]
You can update
/etc/apt/sources.list to use the URL
http://old-releases.ubuntu.com/ubuntu/ instead of
http://archive.ubuntu.com/ubuntu/ and get to those packages.
Note, old versions of Ubuntu no longer receive security updates, so upgrading is the best way to go.
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
I fixed this by, first, adding
/usr/local/bin/vim as an alternative for
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
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 https://vim.googlecode.com/hg/ ~/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.
At work we have a couple of directories that are organized as two-deep hash buckets, totaling 65536 directories . 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;
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.
 the base directory has 256 directories 00 – ff, which each have 256 00 – ff directories in them. 256^2 = 65536 directories.
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.
- logging in as
- Stopping GDM (service gdm stop)
cp /root/xorg.conf.new /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:
Viewport 0 0
service gdm start
The screen resolution should be full again. Remember the screen resolution will not be dynamic anymore, but that was already jacked.