Parenting Hack: Disabling the auto-flushing toilet

If you are a parent of small children like myself you can probably relate to a situation that I commonly find myself in. I take our 4 year old girl to the public restroom because, well, she's gotta go. And when we get there we see that the toilet is one of those auto-flushing models, you know, with a light sensor that can tell when an adult has sat down and stood back up and hence flushes automatically. I put emphasis on adult because as you may know this doesn't always work so well with a child, especially squirmy ones. Inevitably, the toilet flushes too soon, and these tend to not be wimpy flushers either. The flushing action can remind one of Charlton Heston as Moses in the Ten Commandments parting the Red Sea. And children find this very disturbing, obviously.

Well, on a recent trip to the "facilities", I came up with a simple hack to get around this problem. Simply take a piece of toilet paper (paper towel would probably work well too) and drape it over the light sensor. The child can then safely use the toilet. After the child has dismounted and everyone is ready for a flushing of biblical proportions, remove the toilet paper from the light sensor, which will activate the flushing, and drop it into the toilet.

Happy parenting!

Evaluating Grid Portal Security Paper, Review

I just finished reading a paper titled Evaluating Grid Portal Security, by David Del Vecchio, Victor Hazelwood and Marty Humphrey. In it they evaluate GridSphere, OGCE and Clarens against a standard set of security metrics. The conclusion is that there is plenty of "room for improvement". I found their recommendation section at the end particularly helpful. It got me to thinking about things we can do in the projects I work with to make grid portals more secure, and here I try to capture my thoughts.

First, I think in the PURSe/PURSe Portlets project, we should provide a way to configure the strength of the password required when a user creates a new registration, and we should provide a secure setting of this by default out of the box. I created a bug report to track this.

Second, I think one of the most difficult challenges for grid portals is in the area of creating, managing and processing auditing logs. But the authors do provide a simple criterion, that all grid credential accesses be written to auditing logs. However, is this sufficient? It would seem that one would need to audit also all grid services requests (e.g., GRAM and GridFTP calls). Then there is the problem of how to audit the auditing logs. Perhaps there are general purpose tools to make this more feasible. Nevertheless, we are seeing in TeraGrid a strong requirement for this functionality, so we need to come up with a solution.

For the LEAD Portal that I work on, this is complicated by the fact that we do not have the user's grid credentials at the portal level, nor do we make calls to grid services from the portal. Ours is a more distributed architecture, with services communicating asynchronously via a publish/subscribe notification broker. So what we need is an auditing notification topic that all LEAD services could write to as a kind of auditing log. A special auditing listener could be set up to listen to this topic and persist the messages to a file or database.

Upgrading MySQL 3.23 to 5.0

I recently had to upgrade a crufty old MySQL database on one of our Solaris machines (rainier) from 3.23 to 5.0. Here's the process I came up with. This is all in the MySQL documentation, but you have to hunt here and there for it, and what is outlined below allows you to do, or at least, test the upgrade while the original server is still running.

Preparation

Downloaded and installed latest 4.0, 4.1, and 5.0 into a directory.

Copied data directory into /usr/local/mysql-data.

Upgrade from 3.23 to 4.0

Started 4.0 pointing at this data directory, on port 3307.

Edit /usr/local/mysql-data/my.cnf to use port 3307 and socket file /tmp/mysql2.sock

cd mysql-4.0
export PATH=$PWD/bin:$PATH
mysqld_safe --defaults-file=/usr/local/mysql-data/my.cnf --user=emysql --datadir=/usr/local/mysql-data --basedir=$PWD --pid-file=/usr/local/mysql-data/rainier.pid

Check the databases:

mysqlcheck --all-databases -u root -p -h rainier -P 3307

mysql_fix_privilege_tables --user=root --socket=/tmp/mysql2.sock --password=xxxxxx

Lots of warnings and errors, but supposedly this is okay.

Didn't need to upgrade ISAM to MyISAM storage engine.

mysqladmin -u root -P 3307 -p -h rainier shutdown

Upgrading from 4.0 to 4.1.

cd ../mysql-4.1

export PATH=$PWD/bin:$PATH
mysqld_safe --defaults-file=/usr/local/mysql-data/my.cnf --user=emysql --datadir=/usr/local/mysql-data --basedir=$PWD --pid-file=/usr/local/mysql-data/rainier.pid

Check the databases:

mysqlcheck --all-databases -u root -p -h rainier -P 3307

mysql_fix_privilege_tables --user=root --socket=/tmp/mysql2.sock --password=xxxxxx --basedir=$PWD

mysqladmin -u root -P 3307 -p -h rainier shutdown

Upgrading from 4.1 to 5.0


cd ../mysql-5.0

export PATH=$PWD/bin:$PATH
mysqld_safe --defaults-file=/usr/local/mysql-data/my.cnf --user=emysql --datadir=/usr/local/mysql-data --basedir=$PWD --pid-file=/usr/local/mysql-data/rainier.pid

mysql_upgrade didn't seem to work, but I think that's because I had run it in an earlier attempt to upgrade from 3.23 to 5.0. So I did the individual steps:
mysql_fix_privilege_tables --user=root --socket=/tmp/mysql2.sock --password=xxxxxxxxx --basedir=$PWD
mysqlcheck --check-upgrade --all-databases --auto-repair -u root -p -h rainier -P 3307

I ran upgrade again, anyways, this time with the force option
mysql_upgrade -p -S /tmp/mysql2.sock --datadir=/usr/local/mysql-data --basedir=$PWD -u root --force


Additional notes:

Setting up the mysql init script. I set the datadir and the basedir, and then I added a --defaults-extra-file=$datadir/my.cnf to the line that invokes mysqld_safe.