Using ODBC with bind

I ran into this last week, and the Google was failing me, so here's the reason why you sometimes get "Required token $zone$ not found." when debugging why bind won't start with ODBC. The answer is: because the DLZ documentation is slightly wrong. It delimits "zone" and "record" with % instead of $. That is, the directions show:

{select zone from dns_records where zone = '%zone%'}

But really, it should be:

{select zone from dns_records where zone = '$zone$'}

There you go. That's where that error comes from. Now hopefully the next person who hits this will be able to find an actual useful answer when they search for the error.

Sharing a shell and monitoring the other party

Recently, I had a reason to allow someone else to use a shell on a machine for which I'm the admin, but I wanted a way to track what they're doing. You might think the history command is just fine for this, but it's possible to clear the history, and I wouldn't want that. Screen to the rescue!

I ssh'd into the machine and created a new user for my visitor. Then I switched to that user. Once logged in, I ran screen -L, which logs the shell (both input and output) to ~user/screelog.0). Then I called up the user, gave them the IP address, username, and password. They logged in, and I told them to run screen -ls to see a list of open screen sessions. The output looks like this:

There is a screen on:
 2119.pts-0.marlyn (09/01/2010 06:32:03 PM) (Attached)
1 Socket in /var/run/screen/S-maco.

The next step was for them to type screen -x 2119.pts-0.marlyn Once they did this, we could each see what the other saw in our SSH session, and it was all logged. Great! I could keep track of what they were doing as they were doing it and review the logs later for a double check.

It's not a VCS though. If you know what directory they'll be operating in, you might want to run bzr init ; bzr add ; bzr commit -m "starting point" first, so you can later run bzr diff | less to see what files changed and keep a record of what changed, since while it might all seem perfectly logical while it's happening, recalling the exact changes won't be easy. The point of watching can be to catch them in the act if they try to do something that violates your security policy or to be given a demonstration.

EDIT: After a question in comments about how you keep them from opening another non-screen'd connection, my friend Peter suggested adding screen -xR to the user's ~/.bash_profile, so it forcibly connects to the screen session. Thanks, Peter!

Where did my favourite package go?

Did you upgrade to Lucid and find that some package you like is no longer available? There are a number of binary packages that were removed in Lucid as a cleanup of the archive, though for the most part the source packages are still in there. Most of these were removed because the source package was no longer buildable—meaning patches could not be applied to fix bugs since the patched source would not compile (unless, of course, the patch fixed that build issue). Some were removed because Python 2.5 was removed. To find out what happened to the package you're looking for, try this:

apt-cache showsrc $PACKAGE

This'll tell you the name of the source package (on the "Package: " line). Then go to http://launchpad.net/ubuntu/+source/SRCPKG/+publishinghistory for a full listing of all versions of the package in Ubuntu. If you click the triangle on the left, it'll unfold revealing changelog info for that published version. For example, Sage Math's publishing history shows that it was deleted for the depends-on-Python2.5 reason.

And there's today's lesson on how to find data in Launchpad.