Thankfully, the TexLive installation is quite modular, and it’s relatively straight forward to install new environments and packages. Through trial and error, I’ve discovered the missing packages required to use glossaries are: glossary, glossaries, xfor and etoolbox.

Firstly, we need to find the location to install local tex packages

[max@dolphin ~] $ kpsewhich -expand-var "\$TEXMFLOCAL"
/usr/local/share/texmf

Now that we know where to install the packages, we can download and install them. The following redacted typescript will download and extract the packages to the appropriate local location and rebuild the LaTeX package map.

[max@dolphin ~] $ wget http://mirror.ctan.org/macros/latex/contrib/glossary.zip -P /tmp/
[max@dolphin ~] $ wget http://mirrors.ctan.org/install/macros/latex/contrib/glossaries.tds.zip -P /tmp/
[max@dolphin ~] $ wget http://mirrors.ctan.org/install/macros/latex/contrib/xfor.tds.zip -P /tmp/
[max@dolphin ~] $ wget http://mirrors.ctan.org/install/macros/latex/contrib/etoolbox.tds.zip -P /tmp/
[max@dolphin ~] $ sudo unzip /tmp/glossaries.tds.zip -d /usr/local/share/texmf
[max@dolphin ~] $ sudo unzip /tmp/xfor.tds.zip -d /usr/local/share/texmf
[max@dolphin ~] $ sudo unzip /tmp/etoolbox.tds.zip -d /usr/local/share/texmf
[max@dolphin ~] $ sudo mkdir -p /usr/local/share/texmf/tex/latex/{contrib,html}
[max@dolphin ~] $ cd /tmp/
[max@dolphin ~] $ unzip glossary.zip && cd glossary
[max@dolphin glossary] $ latex glossary.ins
[max@dolphin glossary] $ sudo cp glossary.sty /usr/local/share/texmf/tex/latex/contrib/
[max@dolphin glossary] $ sudo cp glossary.perl /usr/local/share/texmf/tex/latex/html/
[max@dolphin glossary] $ cd /usr/local/share/texmf/
[max@dolphin glossary] $ sudo texhash

Install SSMTP

sudo apt-get install ssmtp

Edit configuration in /etc/ssmtp/ssmtp.conf

# Backup the original first
sudo cp /etc/ssmtp/ssmtp.conf /etc/ssmtp/ssmtp.conf.out
# Truncate the file and add the following
mailhub=smtp.gmail.com:587
hostname=ssmtp_user@domain.com
root=ssmtp_user@domain.com
AuthUser=ssmtp_user@domain.com
AuthPass=
UseSTARTTLS=yes
UseTLS=yes
FromLineOverride=yes

Edit revaliases map in /etc/ssmtp/revaliases.conf

# Add a line for each local user who should be able to send email
root:smtp_user@domain.com:smtp.gmail.com:587
max:smtp_user@domain.com:smtp.gmail.com:587

Send Email!
You should now be able to send email, e.g. from the shell using

echo "Testing" | mail -s "Test Email" someone@example.com

I work predominantly with Linux and use Virtual Box as my V12n application of choice.  Later versions of Virtual Box support VPC’s VHD disk image format.  This means it’s possible to run these VPC images under VirtualBox, but it involves downloading and extracting files from the win32 executables; downloading drivers for the ethernet adapter and other time consuming steps that I’d rather not repeat every time my IE VM expires.  I’m a programmer, therefore I’m lazy and don’t like doing things more than once; I’d rather script something to do it for me.  In keeping with this virtue, I’ve written msie2vbox to automate this stuff for me.  It’s on Github with a GPLv3 license.  There’s some outstanding todo items but it does the job for me, and I thought it might be of use to others.

I’m often jumping on and off of a number of different servers where I use a variety of programs such as Gnu Screen and Vim.  If I tweak ~/.vimrc for example, I have to remember to copy the changed file to all of the other servers I use, which is a pain.  I could request that home directories be auto-mounted using autofs, but this solution is something I can implement myself in isolation without effecting any other users.  The idea is to store configuration files in SVN so that when I make a change on one server, I can push that change to SVN and pull the change down to any other server I happen to be on.  The approach I’m taking here is to have a local working copy in my home directory, and to have configuration files symlinked into that working copy.  This could be made more flexible by having different configurations stored in a separate branch and switching branches depending on your needs.

I’m sure there are better ways to do this, such as having the entire home directory in subversion, and automatically updated on login.  Perhaps you could use SVN externals to provide a modular approach to managing your configuration.  The great thing about SVN, and more generally Linux is that there are plenty of different ways to achieve your goal.

Before I go on, I’ve made a few assumptions based on my server configuration – Ubuntu 10.04 with Apache 2.2.14 and Subversion already installed.  The first thing we need to do is enable SVN over HTTP.

sudo apt-get install libapache2-svn

Once installed, we need to configure the module in /etc/apache2/mods-enabled/dav_svn.conf

DAV svn
SVNParentPath /var/lib/svn
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user

This configuration will allow you to refer to your repositories via e.g. http://example.com/svn, where the actual location of your repositories on the filesystem is /var/lib/svn.  We’re also using basic authentication here, so we’ll need to add a valid user.

sudo htpasswd -c /etc/apache2/dav_svn.passwd username

Next, we need to create our SVN directory and create a first repository

sudo mkdir -p /var/lib/svn
sudo svnadmin create /var/lib/svn/homedir
sudo chown -R :www-data /var/lib/svn
sudo chmod 700 /var/lib/svn
sudo chmod -R 755 /var/lib/svn/homedir

Now, on a server that has a good baseline set of configuration files, we can check out a working copy

svn co http://example.com/svn/homedir .

Add some configuration files

cp ~/.bashrc ~/.vimrc ~/.vimrc ~/homedir
cd ~/homedir
svn st | awk '/\?/ {print $2}' | xargs svn add
svn commit -m "Initial Commit"

We can now symlink our files to those in the working copy

ln -sf ~/homedir/.bashrc ~/.bashrc
ln -sf ~/homedir/.vimrc ~/.vimrc
ln -sf ~/homedir/.screenrc ~/.screenrc

If we do this on all the servers we use, we can make a change in one place, commit it to SVN, and then update our working copy somewhere else to get the most up-to-date version of the files.  As I said before, I’m sure this can be enhanced and tweaked to be more efficient, but this serves my needs for now.

Strace showed that subversion reads from /dev/random as part of the commit, and that’s where the problem seemed to be happening.  After doing some research, I discovered that /dev/random generates random numbers using the so-called entropy pool.  This entropy pool is just random bits of noise generated from things such as mouse movements, time between keystrokes and so on.  For whatever reason, on the client server, this entropy pool was empty!  Using /dev/random is cryptographically more random than using /dev/urandom; and /dev/random blocks when the entropy pool is empty, whereas /dev/urandom is non-blocking.  Moving /dev/random to /dev/random.old and linking /dev/urandom to /dev/random solved the problem.  There may be a better solution to this, and depending on your cryptographic requirements it might be better to find an alternative, but this did the trick for me.  One svn commit later and all was well.