Today, while trying to get Mail::SPF::Query to build cleanly, I ran into a wonderful error that caused the test harness to bomb out. Google got me nowhere, the phrasing (This account is currently not available) was way too generic to get any useful hits on.
The build environment is a CentOS 4.2 installation, updated via yum. Nothing special. The only caveat is that I was doing the build of Mail::SPF::Query via rpmbuild as root. Yes, I know, bad move - but it did show up an interesting glitch:
# make test
PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e” “test_harness(0, ‘blib/lib’, ‘blib/arch’)” t/*.t
t/00_all….NOK 9# Test 9 got: “This account is currently not available.: 192.0.2.1 is neither permitted nor denied by domain of 06.spf1-test.mailzone.com” (t/00_all.t at line 109 fail #8)
# Expected: “192.0.2.1 is neither permitted nor denied by domain of 06.spf1-test.mailzone.com”
The ‘account is currently not available’ message is the one that’s too generic, and it throws the test right off. The result did contain the correct string that the test wanted, but the test is a hard match, not a soft match. The source code for the SPF module didn’t have the ‘not available’ message, nor did the DNS query results (tethereal capture to make sure). This meant it had to be coming from deeper down the stack of modules - the only question was where?
The source code for Query.pm states on line 1082:
$newval = $query->{myhostname} if (lc $field eq 'r');
So now I knew it was myhostname that was messing up.
Grep resulted in:
284: $query->{myhostname} = Sys::Hostname::Long::hostname_long();
So, off to Sys::Hostname::Long to see how it gets the hostname. A quick debug flag later, and I had
Sys::Hostname::Long - Last Dispatch method = exec_hostname_fqdn
Ah hah. Checking that routine:
if ($< == 0) {
$tmp = `su nobody -c "hostname --fqdn"`;
} else {
$tmp = `hostname --fqdn`;
}
And therein lies the source of the error message. The ‘nobody’ account is disabled by default in CentOS 4.2, and my building the SPF module as root triggered the logic. Solution? Fix my build environment to build as a non-root user.
So, Mail::SPF::Query built successfully, and I moved on to HTML::Tree.
t/tag-rendering.....NOK 7# Failed test (t/tag-rendering.t at line 24)
# '<img alt="A few bottles of Chech'tluth later..." border="0" height="540" src="damian-conway-in-a-dress.jpg" width="100" />
# '
# doesn't match '(?-xism: alt="A few bottles of Chech'tluth later..." )'
This one is deep inside HTML::Element, so a hunting I shall go.
Comment by cricalix — January 26, 2006 @ 11:53
The Element.pm code calls HTML::Entities to encode things - and I think that someone didn’t notice (possibly) a change in HTML::Entities:
The default set of characters to encode are control chars, high-bit chars, and the “<”, “&”,”>”, and “"” characters.
There’s no mention in there of the ‘ (') character. Looking through the HTML::Element code, I don’t even see a call for encode_entities_numeric, which is the only encoding form that can even generate the #39 format.
It turns out the fix is to edit the test file tag-rendering.t. Line 17 contains
my $html = $img->as_HTML();
Making it
my $html = $img->as_HTML("<>&'\"");
fixes the test, and the test passes. This probably means some other stuff needs fixing elsewhere, but I’ll find it when it breaks. I hope.
Comment by cricalix — January 26, 2006 @ 12:27