While I keep my home directory in SCM (initially CVS, then SVN, now GIT) and that directory is replicated across Linux, Windows, and Mac OS X systems, a big reason for changing from svn to git is to give people more access to my open-source projects.

Periodically, I'd have my CVS and SVN repositories available on a public web server. But, that typically required some effort of mine to mirror a public copy from my private repository. Using a distributed SCM like git, there is no additional effort needed to make a public copy of my respository. But, a bigger win over just making a public respository available is allow users to have their own local respository. While I appreciate the patches (bug fixes and improvments) users email to me, there are some cases where I feel the patch has limited value and don't incorporate it into my upstream respository. With a distributed SCM, users can maintain their own local patches while being able to merge changes that I make to the project's canonical repository. Though, I do hope users to continue to send patches that would be useful to a project's user base. As an added benefit, git has much improvement mechanisms for users to do so.

For my private use, the distributed repository system is not a big win. However, git has much improved branching over subversion which will help when I want to make a local branch for experimental changes.

To convert from my single private respository to a useful public git repository, I've separated my open-source projects into discrete git repositories. The histories of the git repositories on some projects go back to 2002. Unfortunately, I was not able to migrate my tags from subversion to git because git-svnimport got confused about the odd tagging/commits from the cvs2svn tool I used when I migrated from CVS to SVN. If checking out a particular old version is important, one can refer to the dates in the project's debian/changelog file to find the commit matching that release. At some point, I may write an automatic tool to retag the version numbers on the projects.

The public git repositories can be browsed at http://git.b9.com/gitweb. I'm modifing my Lisp web site creation tool so it will automatically add the git repository to each project's website. For now, the typical URI to clone a git repository would in the form of git://git.b9.com/<project>.git. I expect users of my projects will find the new, much deeper access to my open-source projects empowering.

The set of commands to clone the current set of open-source repositories are:
git clone git://git.b9.com/cl-base64.git
git clone git://git.b9.com/cl-modlisp.git
git clone git://git.b9.com/cl-photo.git
git clone git://git.b9.com/cl-readline.git
git clone git://git.b9.com/cl-rss.git
git clone git://git.b9.com/clsql.git
git clone git://git.b9.com/cluck.git
git clone git://git.b9.com/ctsim.git
git clone git://git.b9.com/getopt.git
git clone git://git.b9.com/hyperobject.git
git clone git://git.b9.com/irc-logger.git
git clone git://git.b9.com/kmrcl.git
git clone git://git.b9.com/lml.git
git clone git://git.b9.com/lml2.git
git clone git://git.b9.com/md5.git
git clone git://git.b9.com/pipes.git
git clone git://git.b9.com/postoffice.git
git clone git://git.b9.com/ptester.git
git clone git://git.b9.com/pubmed.git
git clone git://git.b9.com/puri.git
git clone git://git.b9.com/reversi.git
git clone git://git.b9.com/rlc.git
git clone git://git.b9.com/rt.git
git clone git://git.b9.com/uffi.git
git clone git://git.b9.com/umlisp.git
git clone git://git.b9.com/umlisp-orf.git
git clone git://git.b9.com/vcs-tree.git
git clone git://git.b9.com/wdq2wav.git
git clone git://git.b9.com/wol.git
git clone git://git.b9.com/xlunit.git
git clone git://git.b9.com/xmlutils.git
git clone git://git.b9.com/xptest.git

The library is called cluck (Common Lisp μcontroller ClocK calculator) and is available at http://files.b9.com/cluck. Its initial functions include:

• displaying range of frequencies and periods for 8, 16, and 32-bit timers values for a given clock speed
• displaying prescaler, compare values, and error percentage for a desired millisecond interrupt period
• displaying UART divisors and error percentage for common serial port speeds

The gallery is at http://kevin.hypershots.com/gallery/000190ss

Also, special thanks to Christophe Rhodes, frequent contributor to SBCL's MOP, for his excellent suggestion in response to a question for improving CLSQL's MOP internals: CLSQL object definitions use custom slot types. For example, a CLSQL slot may have :type (varchar 10) specified which gets translated to a lisp type of (or null string). Rather than parsing and then re-storing the type atrribute of a slot in compute-effective-slot-definiton, Christophe suggested performing the type parsing in initialize-instance :around of the CLSQL direct-slot-definition object. Then, the real type attribute is stored in the both the direct and effective slot definition from the beginning.This is more AMOP complaint since AMOP doesn't specify that one may change the type attribute of a slot. This is clearly seen since CLSQL no longer needs to modify OpenMCL's ccl:type-predicate slot attribute after the type was changed in compute-effective-slot-definition.

• SBCL Win32
• OpenMCL AMD64
• CLISP Win32, Cygwin, Linux i386, Linux AMD64

Special thanks for the CLISP support to CMUCL for its LOOP's packge to allow the CLSQL loop extensions and to CFFI-UFFI-COMPAT for its CLISP support.

After a moderate search and trying a number of candidates, I settled on Console Password Manger (CPM) written by Harry Brueckner. It's close to an ideal match to my needs: it's console-based, had an emphasis on security and uses my existing GPG key for encryption. The program is maintained and I've had no issues while using the last three beta versions of the program. Thanks, Harry for the very good tool. Recommended.

However, the is one non-Allegro specific optimization that has caused a number of people some trouble: that the library expects input strings to be simple strings rather than generalized lisp strings. That has caused at least 3 people to mention the issue to me. I pondered the best solution for a bit. Likely, the optimum result would be to write a macro that emits generic functions specialized to both simple and generalized strings. However, I took a simpler route: I removed the simple-string specific optimiztions (such as using schar rather than char). I expect the reduction of trouble for library users outweighs the run-time overhead.

A few bug fixes including accomodating a change in the function of SBCL's shink-vector, and PURI 1.4 is now available.

While I found the disk speed acceptable using the encrypted filesystem, I did note that it was subjectively slower than using an unencrypted filesystem. This time, I used the bonnie++ disk benchmark to test the new disk.

Raw disk benchmark

       ------Sequential Output------ --Sequential Input- --Random-
        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
  Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
    4G 30299  98 47348  13 20552   6 29947  91 44758   5 137.3   0
       ------Sequential Create------ --------Random Create--------
        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
     16  3545  21 +++++ +++  3863  42  3350  20 +++++ +++   867   6

Encrypted disk benchmark

       ------Sequential Output------ --Sequential Input- --Random-
        -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
   Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
     4G 18861  60 40812   9 10534   2 18530  58 30641   4 143.6   0
       ------Sequential Create------ --------Random Create--------
        -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
  files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
     16  3150  87 +++++ +++  3510  92  2919  86 +++++ +++   900  35

While there is an overhead using the encrypted file system (which is likely magnified by using a 4-year old CPU, a 2GHz Pentium 4-M), the overall speed with the 7200rpm drive is acceptable and will be a boost compared to the old 5400rpm drive.

While my notebook previously ran Debian Sarge, I thought I'd try something slightly different, the Debian offshoot Ubuntu Breezy. I found a few issues that had to be resolved to use the encrypted filesystems.

• Patching /usr/sbin/mkinitrd
  mkinitrd had the wrong devmapper library version. I had to change line 385 from /lib/libdevmapper.so.1.00 to /lib/libdevmapper.so.1.01.
• Add modules to /etc/mkinitrd/modules
  I added aes_i586, dm_crypt, and dm_mod to /etc/mkinitrd/modules.
• Modifying /etc/lvm/lvm.conf
  I use an encrypted physicial LVM partition to host my logical volumes. That way, I only have to encrypt the LVM physical partition. Subsequently when booting and decrypting the filesystem, I only have to give once the key to the physical volume and all of the logical volumes created in that partition will be decrypted. This requires some editing of lvm.conf to recognize the encrypted physical volume. I named the LVM physicial volume pv and then added /dev/mapper/pv to the filter specification in the devices section. Also, LVM has to be notified of the device mapper type, so the line types=["device-mapper",16] must be added to the devices section.
• Change the startup script order
  The script order in /etc/rcS.d/ needs to be changed so that cryptdisks is executed before lvm. This is required so that the lvm script will have access to the unencrypted physicial volume. This is simply done by renaming S28cryptdisks to S25cryptdisks which places it before the lvm script S26lvm.

After those bits of additional configuration, the encrypted root filesystem and encrypted LVM physical volume is working very well. Additionally, I'm using an encrypted swap partition, but there was no additional configuration required beyond what I previously described.

Recapping the history, one of my domains has been under a persistant SMTP dictionary attack for over a year. I get 3-10 emails a second with guessed destination email address. Sendmail on the primary MX host is rather efficient at rejecting these so the only real effect is my 200MB of email logs a day. However, spammers often target the backup MX host since they usually have less spam filtering. Last year, the attack took down my backup MX host. The backup host will kindly accept a message for any username in the appropriate domain. Then, it will try to deliver them to the primary MX host. If the primary MX host rejects the username as invalid, the backup MX host tries to send a reject message back to the sender. The breaks down when the sender is a spam zombie that is not running a SMTP server. The backup MX host queues the reject message while it attemps redelivery for a number of days. My backup MX host has 500,000 reject messages in its queue before the load average become too great.

A great piece of software fixes this problem. SnertSoft's no-cost milter-ahead sendmail filter handles this sort of attack very well. The author is very responsive. I found only one issue with the software: it wouldn't compile or run on AMD64 platforms [typical issue of the C long type varying between 32 and 64-bit platforms]. In just a few hours, the author updated his code and milter-ahead is now running very well on my Debian AMD64 servers.

milter-ahead runs on a gateway or backup mail server and checks the RCPT during the SMTP connection with the a designated MX host. If that "look-ahead" host is down, milter-ahead will accept any email, which is the right thing to due. If the designated host is up, then milter-ahead can do one of several things. But, it's primary use is to query the designated host and verify that the receipient address is valid. If it is not, then the milter rejects the RCPT and avoids queueing the message. If the receipient is valid, then milter-ahead allows the backup MX host to accept the message for forwarding.

Now that my backup MX host won't be queueing email for invalid email addresses, I've brought that system back online. If you're running a gateway or backup mail server, you'll likely find milter-ahead a useful tool.