The Substantially Similar Weblog

My server’s mailman (or postfix) installation is mysteriously rejecting mail from one Yahoo! mail user. I don’t get it:

 Hi. This is the qmail-send program at yahoo.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : 72.1.169.10 does not like recipient. Remote host said: 550 : Recipient address rejected: undeliverable address: unknown user: "[list name]" Giving up on 72.1.169.10. 

72.1.169.10 is, in fact, the IP address of my server. [list name] is (in the real version) the real live name of the list. The list seems to work for everyone else. And it’s certainly not true that I, or my server, doesn’t like this recipient (or sender).

Aside from this anomalous behavior, it’s also funny that Yahoo! provides plain old unfiltered qmail bounce messages to its users. Wouldn’t you think a fully matured webmail service like Yahoo! would, by this point, have somewhat customized their mail error reporting messages? In fact, wouldn’t you think they would want to hide the fact that the use qmail at all, if only for security purposes? Couldn’t they hire an intern to write a few replacement error messages? Maybe I’m missing something.

A propos, I discovered this nice piece from McSweeney’s, entitled YAHOO’S MAILER-DAEMON AUTOMATED REPLY FOR FAILED E-MAIL DELIVERY IS GETTING A LITTLE TOO INTIMATE.

Update 5/30/06: Figured it out. Oddly, Yahoo! was looking up the CNAME DNS record for the domain name and replacing that in the mail header. While the original email went to e.g., listname@lists.mydomain.com, the message as delivered was addressed to listname@servername.mydomain.com. Because only lists.mydomain.com processed email for lists, the message bounced. The solution was to change lists.mydomain.com from being a CNAME entry to its own A entry with the IP address specified directly. That fixed the problem. I’ve never seen any other mail service work this way — gmail certainly doesn’t.

As a result of the Verizon v710 Bluetooth Class Action Lawsuit Settlement, I just got the LG VX9800, aka “LG the V.” It’s actually not as mediocre as I thought—more on that later. In keeping with my tradition of posting solutions to problems that are not easily found on google (an omnibus entry I plan to separate out into separate entries some day), I’m posting this tip about getting on to Verizon’s high speed (“3G”) network from Linux over a Bluetooth connection.

I was able to get on with no problem with my old phone — the v710. I was surprised when wvdial kept failing with the new phone. The key, it turns out, was adding the following to /etc/ppp/options:

 -chap -mschap -mschap-v2 

(I’m not even sure all of those are necessary, since -mschap and -mschap-v2 are not documented, but they can’t hurt.)

Here’s the whole process:

1. Establish a Bluetooth connection with the phone.
   • Make the phone “discoverable” — go into Bluetooth Options and set it to be visible to all devices
   • hcitool scan to find the phone’s Bluetooth ID (henceforth ##:##:##:##:##:##)
   • hcitool cc ##:##:##:##:##:##
   • hcitool auth ##:##:##:##:##:##
2. Add a stanza to /etc/bluetooth/rfcomm.conf:
   

    rfcomm { bind yes; device ##:##:##:##:##:##; channel 8; } 

3. Add a stanza to /etc/wvdial.conf:
   

    [Dialer Defaults] Modem = /dev/rfcomm0 Carrier Check = No Baud = 115200 Init1 = ATZ Init2 = AT$QCMDR=3 Phone = #777 Username = [Your Verizon 10 Digit Phone Number]@vzw3g.com Password = vzw 

4. As dicussed above, add to /etc/ppp/options:
   

    -chap -mschap -mschap-v2 

You’ll of course have to deal with permissions issues (on /dev/rfcomm0), have the packages installed (bluetooth, wvdial, ppp), etc., but that sort of information is available elsewhere.

It should be obvious that this method costs you airtime. But in my experience Verizon imposes no other charges. I get about 16 kilobytes/second out here in Vermont, which isn’t bad compared to dial-up.

Finally, I haven’t nailed this down yet, but in some situations (maybe where you are outside EV-DO range), you may need to do the following:

• Open the phone
• Press OK – 0 – 000000
• Press 3, Network Select
• Press 1, Mode Preference
• Select 1X only.

(Remember to change it back to Digital Only Hybrid when done)

Finally, there is already an excellent page describing how to use the VX9800 (“LG the V”) on Linux. I would not want to displace its PageRank.

It’s been a while since I announced a release of randomplay, my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period.

This new version features the much sought ‘back a song’ keybinding. It also announces the “random weight” preference of the current song as it plays.

In an effort to put an end to the endless time sink of hardware problems on the small cooperative ISP I run, I’ve decided to outsource the responsibility of actually taking care of hardware and move most of the operations to a virtual private server. Part of our hosting is actually already on a VPS, but the service there has been lackluster: sometimes disk space is mysteriously unavailable; we don’t always get the promised amount of memory; throughput is slower than we’d like; customer support usually gives us cryptic responses about what was wrong and how they fixed it after a few hours; etc.. (Not to give them too bad a name, but the provider here was SPRY.)

We decided to find a new provider. Lots of people had good things to say about RIMU Hosting, and after just a day it’s becoming clear to me that they are an excellent provider. Tech support (even before we signed up) was incredibly responsive; the packages of virtual servers or dedicated hardware seem like an excellent value; and my first impression is that there is none of the VPS flakiness that seemed to permeate our prior provider. It looks and feels like a real machine: top provides an accurate task list that reflects the memory we really have, dmesg gives realistic kernel-like output, etc.

In such a short period of time, I can’t genuinely claim that RIMU Rules, but I will say that they rule so far. They also have a Debian developer discount, as well as a discount for hosting multiple machines with them.

A couple of weeks, I blogged about trying to create some babysitting coop software and “doing it right.” Despite knowing that I’d benefit from the discipline imposed by Python, I ended up coding it in perl and staying in my comfort zone. Still, it’s a lot less screwy than past things I’ve done.

It’s definitely not ready for prime time—barely tested at all; probably buggy; not feature complete; and not nearly secure enough. But I thought I’d announce it so it can start entering search engine indices. The past blog entry is already a #2 google result for babysitting coop software. (Apparently there is very little competition in this niche).

So. Announcing BabyOp: Software for Babysitting Coops.

I’m coding a new CGI application, tentatively entitled BabyOp. It is software to run a babysitting coop; I suppose it is a species of “social software.” The idea is to be able to track hours credits, schedule babysitting times, centralize contact information and other details about babysitting requirements.

I considered using something like Zope or Drupal for the application, but I’ve never liked developing exclusively through a web-interface and found myself having to do a fair bit of “actual” coding to get the results I wanted. I realize there is a command-line interface for Zope, but it’s really pretty limited. I had some plans a couple of years ago when I designed my wedding site in Zope to extend it to be more useful, but sadly never got around to it.

So I’m back in my comfort zone, perl. I’ve written a fair amount of unmanageable perl code, however, CoopOrder probably being a shining example (it was also my first perl program). I’ve certainly improved since then, and the fact that I’ve received several patches from others for randomplay suggests that my coding style is getting to a half-decent point.

I’d really like to get it right this time, though. One thing I’ve learned over the years is always to look for a module to do what you want before setting out to do it yourself, since chances are the module writer is a better coder than you (or at least, than me!). To that end, I’m using CGI::Application, HTML::Template, and DBIx::Abstract, among others. I’m also trying to keep things really granular and avoiding long subroutines. Certainly taking the HTML out of the perl code helps with that. I’m amazed at how often my code now just “works” on the first try, similar to esr’s story about his first look at Python (“Brace yourself: this code only took me about ninety minutes to write—and it worked correctly the first time I ran it.”)

I’m trying to figure out if it would be sensible to make this application more fully object oriented. Growing up in the ’70s and ’80s and having done a lot of database programming, I’ve always been unfortunately pathologically declarative. (My first major package was in Clipper—I was 13 years old). I find it a lot easier to modify a pre-existing object oriented package than to design my own.

But then again, does it really make sense to attempt an object-oriented design where there is really only one important “object” — in this case, the babysitting unit?

I know I said I was swamped until December, but there’s always a few minutes to release a new version of a package, right? It’s kind of like dessert—there’s always room.

I’ve released randomplay 0.49.

The new version adds a keystroke to pause playing and a keystroke to display the available keystrokes, and the ability to configure UTF-8 display of tags on or off.

I’ve also improved the documentation and filled in the sample rc file to give all available options.

By the way, Clint Adams, I would be happy to add Audioscrobbler support. Unfortunately, there is not yet any Net::AudioScrobbler perl module. I contacted the guy who is working on it and he said it’s not yet fit for public consumption, but will let me know when it is.

Get the latest version of randomplay as a tarball (v0.60, released 10/15/06).

Randomplay is a command-line based shuffle music player that remembers songs between sessions.Randomplay plays your music collection (or execute any arbitrary commands on any arbitrary filetypes) in random order, remembering songs played across sessions. It also has many features to make command-line music playing more convenient, including recursive regexp searching for tracks and the ability to specify a certain number of tracks, bytes, or minutes to play. Randomplay will also generate a list of music files to be loaded onto a portable music player device. It includes a ‘random weighting’ feature, so your favorite songs are more likely to come up in the random shuffle.Randomplay is a convenient tool for the user who does everything in an xterm window or console and is constantly devising complex find/grep/sed command lines to play just the right set of songs.

Following are some example invocations of randomplay to give a general sense of its flexibility; see the manpage for more complete information:

Play all ogg files in dir1 and dir2 under your home directory, and dir3 under the base directory specified in ~/.randomplayrc, which have not been played for 15 days in random order with 5 seconds between songs:

randomplay --days=15 --pause=5 --player ogg=ogg123 ~/dir1 ~/dir2 =dir3

Play all ogg, wav, and mp3 files under the current directory (or base directory, if specified in .randomplayrc file) which have not been played for 10 days in alphabetical order, switch the ‘skip to next song’ keystroke to ‘G’ or ‘g’ and ‘quit’ to ‘q’ or ‘c’:

randomplay --norandom --key next=Gg --key quit=qc

Play all files under the current directory with the strings “frisell” and “bill” in the filename, in any order, (saves having to hunt down a file in a hierarchy), ignore whether the file has been played recently, but stop playing after 15 minutes:

 randomplay --regexp 'frisell bill' -0 --maxtime=15m

Display 100M worth of music files, randomly sorted, without recording the history of tracks, using the default music directory (or the current directory if not specified):

randomplay --maxsize=100M --noremember --names-only

Play the last 10 songs played over again:

randomplay --last=10

Play songs test.ogg, test2.ogg, test3.ogg, and all files in musicdir in random order without weighting preferred songs:

randomplay --noweight test.ogg test2.ogg test3.ogg musicdir

Copy 128M of songs into a Neuros Audio Player, using positron:

positron add `randomplay --names-only --maxsize=128M`

Pick a random jpeg or png file that has not been displayed in the last week from the ‘images’ directory and display it with ImageMagick ‘display’ command:

randomplay --player jpg=display --player gif=display --days 7 ~/images

randomplay is listed on freshmeat.net.

You can download randomplay as a Debian package, or get it directly from the Debian archive.

You can take a look at randomplay, the main script, with nice highlighting, also see the changelog.

I’ve released randomplay 0.48. randomplay is my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period.

The new version fixes a bug that prevented randomplay from advancing to the next track when the player subprocess itself spawned a child process (e.g., with ‘play’ which spawns ‘sox’). I use a bit of a hack to kill the child task and it’s children, but the standard way of doing this in perl—kill HUP => -$$ doesn’t seem to work when randomplay is called from a shell script and the child process’ output is redirected to null. Here’s the code in question (with the fix to kill children and grandchildren recursively):

 # KillAll recursively kills the request process ID and all of its children/grandchildren/etc. # This is a bit of a hack--there should be a better way to do this, but I haven't found one. # Normally, kill HUP => -$$ should do the job, except this doesn't work when randomplay itself # is called from a shell script and all output from child processes is redirected to null. # This subroutine assumes that shelling out to ps is going to work, which may not be totally # safe--at the very least, it reduces the portability of the script. # Any suggestions for a better way to do this are welcome. sub KillAll { my $pid = shift; local $SIG{HUP} = 'IGNORE'; # don't want to kill ourselves here--shouldn't happen, but just in case. if (open PS, "ps -o pid,ppid |") { eof PS; # Force ps to run now. Otherwise it would run at the first read operation. kill HUP => $pid; foreach my $line () { KillAll($1) if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($2 eq $pid)); } close PS; } else { # if we can't read the process table, just try killing the child process group kill HUP => -$$; } } 

Thanks to Christopher Zimmermann for the patch to kill children recursively.

The latest version of salonify allows the web user to download each entire photo album as a ZIP file; also has better error/sanity checking and reorganized documentation.

• tarball
• Sample Gallery