One of the nice things that happens when I’m writing my articles is that while researching the content, I come across a blog post or other site that has picked up one of my articles and added it to some catalogue or other.

Here’s an example I just found: Intute Science, Engineering and Technology – Full record details for Managing a grid, part 1 : network and infrastructure.

A more detailed look shows it’s not the only article they have of mine in their catalog (see this search). There are lots of useful articles here if you are still interested in grid tech and want some more background information.

We’ve got a lot of queries recently on the MySQL docs team address about the documentation (particularly man pages) for MySQL on Debian/Ubuntu.

The source of the original problem was reported as a Debian bug. The assumption from the reading of the license in this instance is that you are not allowed to distribute MySQL documentation unless you’ve asked first, and that the documentation is not released under the GPL license.

The original license was misunderstood in this respect.

In fact, the license as originally quoted in that bug does allow you to provide the documentation if you are providing the MySQL software.

In addition, regardless of how you interpret the license, all of our documentation, including installable man pages, has been available on http://dev.mysql.com/doc. You can find online HTML, offline HTML, PDF, CHM and the man pages for all of our reference manuals (on a version by version basis), along with the main HTML/PDF formats for all of the remaining documentation.

We have never tried to limit the availability of the documentation (that’s why we provide it in so many formats).

However, as soon as this issue was reported on to us by the folks at Debian we agreed with our legal department to put the man pages under a GPL license. This affects only the man pages, but gets round the misunderstanding above by allowing the man pages to be distributed under the same GPL license as the software.

Why did we only change our man page license?

MySQL documentation is updated and released very often, in fact as often
as ten times per day. Allowing anyone to create static copies of an
arbitrary documentation release would lead to many outdated copies on
the ‘Net. This is bad for users doing Google searches for MySQL
documentation, and bad for us (we’ve seen complaints about “our” 5.0.0
Manual being badly outdated when MySQL 5.1.20 was out). We appreciate
anyone mirroring the MySQL Dev Zone which contains all MySQL
documentation.

So where does that leave the man pages in Debian/Ubuntu?

I’m pleased to say that the new 5.0.51-1 package for MySQL that has gone into the latest Debian release (actually, in December). That means that MySQL and the corresponding man pages should appear already in the latest Debian “unstable” branch, and the next major Debian release should include everything you need.

Thanks to Christian Hammers (Debian) and Norbert Tretkowski (Ubuntu) for their help on getting this all sorted!

Just recently I seem to have noticed an increased number of mysterious crashes and terminations of applications. This is generally on brand new systems that I’m setting up, or on existing systems where I’m setting up a new or duplicate account.

Initially everything is fine, but then all of a sudden as I start syncing over my files, shell profile and so on applications will stop working. I’ve experienced it in MySQL, and more recently when starting up Gnome on Solaris 10 9/07.

Sometimes the problem is obvious, other times it takes me a while to realize what is happening and causing the problem. But in all cases it’s the same problem - my TMPDIR environment variable points to a directory that doesn't exist. That's because for historical reasons (mostly related to HP-UX, bad permissions and global tmp directories) I've always set TMPDIR to a directory within my home directory. It's just a one of those things I've had in my bash profile for as long as I can remember. Probably 12 years or more at least.

This can be counterproductive on some systems - on Solaris for example the main /tmp directory is actually mounted on the swap space, which means that RAM will be used if it’s available, which can make a big difference during compilation.

But any setting is counterproductive if you point to a directory that doesn’t exist and then have an application that tries to create a temporary file, fails, and then never prints out a useful trace of why it had a problem (yes, I mean you Gnome!).

I’ve just reset my TMPDIR in .bash_vars to read:

case $OSTYPE in
(solaris*) export set TMPDIR=/tmp/mc;mkdir -m 0700 -p $TMPDIR
;;
(*) export set TMPDIR=~/tmp;mkdir -m 0700 -p $TMPDIR
;;
esac

Now I explicitly create a directory in a suitable location during startup, so I shouldn’t experience those crashes anymore.

I’ve been investigating some recent issues with installations of MySQL on Mac OS X and the Perl DBD::mysql module for accessing MySQL from within Perl through DBI.

The problem exists only with binary distributions of MySQL and is related to the installation location of the libraries for the MySQL client that DBD::mysql uses.

By default these are installed into /usr/local/mysql/lib, but the dynamic libraries are configured to be located within /usr/local/mysql/lib/mysql.

It’s possible for DBD::mysql to build and link correctly, but trying to use the library will fail because it can’t find the library in the latter directory, even though it linked to the library in the former location. To get round this, the easiest method is to create a link within the directory that points to the parent. For example:

$ cd /usr/local/mysql/lib
$ ln -s . mysql

That should fix the problem whether you run the commands before the DBD::mysql build or after it.

Sorry about the ‘Testing’ posts - I’ve been trying about the new Sun Weblog Publisher extension for StarOffice and I seem to have discovered a bug that is affecting what you can post.

Sun are working on the issue right now to determine the problem.

I’m switching off the need to register just to leave a comment.

Mostly this is because I tend to get a lot of direct emails and reply back to people, but a l;ot of that info would be useful to everybody. If I can get you to comment, rather than use the contact form for those type of queries, we might be able to help more people!

If it works here, I’ll do it on all blogs.

I mentioned the problem with setting up the stack on a new Solaris box yesterday and then realized this morning that I’d already added Brian Aker’s blog posting on the same issues to my queue (Solaris, HOW-TO, It works… Really…).

Brian mentions pkg-get, the download solution from Blastwave which I neglected to mention yesterday. It certainly makes the downloading and installation easier, but its’s far from comprehensive and some of the stuff is out of date.

To be honest I find that I install the stuff from Sun Freeware to get me going, then spend time recompiling everything myself by hand, for the plain and simple reason that I then know it is up to date and/or working or both. This is particularly the case for Perl, which often needs an update of the entire perl binary to get the updated versions of some CPAN modules.

Ultimately, though, it sucks.

There’s a great post on Coding Horror about Configuring the Stack.

Basically the gripe is with the complexity of installing the typical developer stack, in this case on Windows, using Visual Studio. My VS setup isn’t vastly different to the one Jeff mentions, and I have similar issues with the other stacks I use.

I’ve just set up the Ultra3 mobile workstation again for building MySQL and other stuff on, and it took about 30 packages (from Sun Freeware) just to get the basics like gcc, binutils, gdb, flex, bison and the rest set up. It took the best part of a day to get everything downloaded, installed, and configured. I haven’t even started on modules for Perl yet.

The Eclipse stack is no better. On Windows you’ll need the JDK of your choice, plus Eclipse. Then you’ll have to update Eclipse. Then add in the plugins and modules you want. Even though some of that is automated (and, annoyingly some of it is not although it could be), it generally takes me a few hours to get stuff installed.

Admittedly on my Linux boxes it’s easier - I use Gentoo and copy around a suitable make.conf with everything I need in it, so I need only run emerge, but that can still take a day or so to get everything compiled.

Although I’m sure we can all think of easier ways to create the base systems - I use Parallels for example and copy VM folders to create new environments for development - even the updating can take a considerable amount of time.

I suggest the new killer app is one that makes the whole process easier.

OK, so once again it’s been incredibly quiet round here.

Why?

Well I’ve moved house again I say that like I move house regularly, but in fact it’s almost three years since the last time we moved house. This time we haven’t moved very far, just a few hundred yards, but it’s to a a bigger house and, more importantly for us, to one that we have purchased instead of the renting we did when we moved up from the south coast in 2004.

Unfortunately that has completely mucked up my blogging schedule and nearly all of my articles and other work. It’s not just the hassle of the move itself (which started in late June), but it’s the distractions of having boxes to empty and possessions to move around. I have, for example, books stacked up on the shelves, but there are in sort of order, and more than half of the shelves are empty.

Anyway, look out for me to get back into the blogging soon I’ve already started on Computerworld, and last week I tried to catch up on the waiting articles and tutorials that had recently been published by posting a number of articles on MCslp.com.

One of the steps I find myself doing a lot is distributing round an ssh key so that I can login and use different machines automatically. To help in that process I created a small function in my bash profile script (acutally for me it’s in .bash_aliases):

function setremotekey
{
OLDDIR=`pwd`
if [ -z "$1" ]
then
echo Need user@host info
fi
cd $HOME
if [ -e "./.ssh/id_rsa.pub" ]
then
cat ./.ssh/id_rsa.pub |ssh $1 'mkdir -p -m 0700 .ssh && cat >> .ssh/authorized_keys'
else
ssh-keygen -t rsa
cat ./.ssh/id_rsa.pub |ssh $1 'mkdir -p -m 0700 .ssh && cat >> .ssh/authorized_keys'
fi
cd $OLDDIR
}

To use, whenever I want to copy my public key to a remote machine I just have to specify the login and machine:

$ setremotekey mc@narcissus

Then type in my password once, and the the function does the rest.

How? Well it checks to make sure I’ve entered a user/host (or actually just a string of some kind). Then, if I haven’t created a public key before (which I might not have on a new machine), I run the ssh-keygen to create it. Once the key is in place, I output the key text and then use ssh to pipe append that to the remote authorized_keys file, creating the directory along the way if it doesn’t exist.

Short and sweet, but saves me a lot of time.