[ More Info ]

[/network/web/blogging/blosxom] permanent link

I was able to access webpages that were not blog postings. When I checked the site's error log file, I saw many entries similar to the following indicating that others were experiencing the same problem when accessing the site:

[Tue Mar 22 11:43:12.276013 2016] [cgi:error] [pid 24979] [client 136.243.36.80:
52035] AH01215: Magic number checking on storable file failed at /usr/lib64/perl
5/vendor_perl/Storable.pm line 381, <DATA> line 32, at /home/jdoe/public_html/su
pport/blog/plugins/calendar line 322.

I use a Blosxom calendar plugin, so I checked line 322 in the calendar plugin file and found the following code:

    if (!Storable->can('lock_retrieve')) {
        debug(1, "cache disabled, Storable::lock_retrieve not available");
        $use_caching = 0;
        return 0;
    }
    $cache = (-r $cachefile ? Storable::lock_retrieve($cachefile) : undef);

The line starting with "$cache" is line 322. I checked the cache file for the plugin which is under the plugins/state directory for the blog software and saw it was zero bytes in length.

# ls -al /home/jdoe/public_html/support/blog/plugins/state/.calendar.cache
-rw-r--r--. 1 apache apache 0 Mar 22 11:42 /home/jdoe/public_html/support/blog/plugins/state/.calendar.cache

So I deleted the file; it will be recreated automatically when the blog is accessed after it is deleted.

# rm /home/jdoe/public_html/support/blog/plugins/state/.calendar.cache
rm: remove regular empty file ‘/home/jdoe/public_html/support/blog/plugins/state/.calendar.cache’? y

Deletion of the .calendar.cache file fixed the problem. When I refreshed the page in my browser for a blog posting from years ago I had been attempting to view I could then see it and access other blog postings as well. I also saw the file had been recreated.

# ls -al /home/jdoe/public_html/support/blog/plugins/state/.calendar.cache
-rw-r--r--. 1 apache apache 94578 Mar 22 21:54 /home/jdoe/public_html/support/blog/plugins/state/.calendar.cache

[/network/web/blogging/blosxom] permanent link

[ More Info ]

[/network/web/blogging/blosxom] permanent link

http://support.moonpoint.com/blog/blosxom/2014/03//RS=%5EADAZpNNfKrcEOr1DFixlJAHJ_euLow-/2014/03/04/2014/03/2014/03/01/

They had "RS=" and "euLow-" followed by repetitions of the year and month in the URL. I knew that the links had been appearng normally, so I suspected the problem was caused when I posted an entry this morning. Sometimes when I've worked on something previously, but not yet posted it, I will change the time on the file associated with the entry to point to the date and time I worked on it or when I edit an entry I may set its time stamp to the original date and time after I've finished editing it. I had done that this morning, so I suspected there was a problem with the calendar's cache file, .calendar.cache, which is located in the Blosxom plugins state directory, plugins/state. The file can be deleted; it will be recreated automatically when the Blosxom blog is viewed again. I deleted the file and refreshed the page in the browser with which I was viewing the site and all of the links for the calendar then appeared normally.

[/network/web/blogging/blosxom] permanent link

5.10.83.52 - - [12/Mar/2014:00:32:23 -0400] "GET /blog/blosxom/<a%20href=/<a%20h ref=/<a%20href=/2008/05/01/2008/03/2008/05/05/network/email/clients/outlook/2008 /10/network/email/sendmail/2008/07/network/email/clients/outlook/2008/05/25/2008 /12/2008/05/18/2008/05/03/index.html?advanced_search=1 HTTP/1.1" 200 12080 "-" " Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://ahrefs.com/robot/)"

They seem to be getting erroneous URLs reflecting a directory structure related to dates that doesn't exist on the system. The URLs appear to be related to the find plugin, since its search option includes code for "advanced_search=1", so I've edited the Perl code for that plugin to include rel="nofollow" at the end of the URL generated for the advanced search capability.

The orignal code was:

<a href="$blosxom::url/$path_withflavour?advanced_search=1">Advanced Search</a>

The line is now:

<a href="$blosxom::url/$path_withflavour?advanced_search=1" rel="nofollow">Advanced Search</a>

Adding rel="nofollow" to a URL tells search engines, such as Google's search engine not to follow any link that includes the nofollow parameter.

The following meta tag can be included in the head section of the HTML code for a page to tell search engines not to follow any links on a page.

<meta name="robots" content="nofollow">

But there may be instances, such as this case for me, where a webpage designer wants only some links on a page not to be followed to their destination by search engines.

The attribute can also be added to individual links if you don't want to vouch for the content of the page to which the link points. E.g., adding it to links placed in comments by those commenting on a page will allow visitors to go to the linked page, but search engines that adhere to the nofollow parameter won't use the link to increase their ranking of the page to which the link points, which may discourage some comment spammers.

The rel="nofollow" option for links was developed as a way to combat link spam. In January 2005, Google, Yahoo! and MSN announced that they would support use of the "nofollow" tag as a way to deter link spam. Microsoft's MSN Spaces and Google's Blogger blogging services joined the effort to utilize the tag to discourage link spamming At that time a number of blog software providers, including Six Apart, WordPress, Blosxom, and blojsom, also joined the effort by supporting use of the tag.

References:

1. Use rel="nofollow" for specific links
   Google Webmaster Tools
2. Wipedia ponders joining search engines in fight against spam
   By: Michael Snow
   Date: January 24, 2005

[/network/web/blogging/blosxom] permanent link

The plugin has been contributing a lot of entries in the site's error log that appear to be related to normal behavior for the plugin. I've been ignoring them, since the plugin has been working fine and the entries seem to be more informatonal in nature than reflective of a problem with the plugin. E.g., I see a lot of entries similar to the following:

[Sun Mar 09 23:59:19 2014] [error] [client 10.0.90.23] calendar debug 1: start() called, enabled
[Sun Mar 09 23:59:20 2014] [error] [client 10.0.90.23] calendar debug 1: filter() called
[Sun Mar 09 23:59:20 2014] [error] [client 10.0.90.23] calendar debug 1: Using cached state
[Sun Mar 09 23:59:20 2014] [error] [client 10.0.90.23] calendar debug 1: head() called
[Sun Mar 09 23:59:20 2014] [error] [client 10.0.90.23] calendar debug 1: head() done, length($month_calendar, $year_calendar, $calendar) = 3947 1212 5229

I finally decided I should stop the production of those entries, though, so I could more readily see log entries that are significant. So I looked at the Perl code for the plugin. On line 30, I see the following:

$debug_level    = 1 unless defined $debug_level;

The debug surboutine is on lines 49 through 56 and is as follows:

sub debug {
    my ($level, @msg) = @_;

    if ($debug_level >= $level) {
        print STDERR "$package debug $level: @msg\n";
    }
    1;
}

On line 517, I see the following comment.

C<$debug_level> can be set to a value between 0 and 5; 0 will output
no debug information, while 5 will be very verbose.  The default is 1,
and should be changed after you've verified the plugin is working
correctly.

Since the plugin has been working for a long time and I don't need to see the debugging information, I set the value for debug_level on line 30 to zero instead of one.

$debug_level    = 0 unless defined $debug_level;

That has stopped the insertion of the calendar plugin entries in the Apache error log file with no effect on the calendar's functionality.

[/network/web/blogging/blosxom] permanent link

Line 210, Column 10: ID "MAIN" already defined

<div id="main">

An "id" is a unique identifier. Each time this attribute is used in a document it must have a different value. If you are using this attribute as a hook for style sheets it may be more appropriate to use classes (which group elements) than id (which are used to identify exactly one element).

I still got those errors when checking blog entries with the new version, but decided that I should deal with the problem at last. I found that the problem was within the story.html file I was using for Blosxom. I hadn't changed that file when I upgraded Blosxom. The file had the following contents:

<div id="main">
<a name="$fn"><b>$title</b></a>
<br>
<br>
$body
<p>
[<a href="$url$path">$path</a>]
<a href="$url/$yr/$mo_num/$da#$fn">permanent link</a>
</p>
</div>

Since that was specifying that a <div id="main"> be used for each blog entry, whenever I would check a Blosxom blog page with multiple entries, at least one of the error messages would be reported by the W3C Markup Validation Service, since "id=main" should appear only once within a webpage since it should specify a style in CSS for a single, unique element on a page. If there were 10 entries on a page, then I would see 9 such error messages reported.

So I changed "id=main" to "class=main", since unlike "id", the class selector is used to specify a style for a group of elements on a page - see The id and class Selectors for an explanation of the two elements.

In the style.css file I specified for the blog in the head.html file for Blosxom, I inserted the following line just to have something there that I could alter later if I wanted to format entries differently. There hadn't been an element for "main" there previously.

div.main {text-align:left;}

In the head section of the head.html file, I had the following line to bring in the stylesheet I use for the blog.

<link rel="stylesheet" href="/css/style.css" type="text/css">

[/network/web/blogging/blosxom] permanent link

Blosxom is available from SourceForge at blosxom :: the zen of blogging. Upgrading from the 2.0 version to the 2.1.2 version was very easy. I made a backup copy of the existing blosxom script in case anything went wrong. I then unzipped and untarred the gunzip blosxom-2.1.2.tar.gz file I downloaded.

gunzip blosxom-2.1.2.tar.gz
tar -xvf blosxom-2.1.2.tar

The only file I needed was the blosxom one, which I edited to set the configurable variables, which are at the top of the file, to those I had for the 2.0 version. I also set the plugins directory variable, plugin_dir, in the Plugins (Optional) section of the file, which is after the Configurable variables section, since I'm using a calendar plugin for Blosxom. I then copied the new blosxom file over top the old one and then verified that the blog was still working as it had been.

When I checked the latest blog entry with the W3C Markup Validation Service, which allows one to verify that a webpage is coded correctly in HTML, I saw the warning below:

Character Encoding mismatch!

The character encoding specified in the HTTP header (utf-8) is different from the value in the <meta> element (iso-8859-1). I will use the value from the HTTP header (utf-8) for this validation.

The issue was reported as a warning rather than an error and shouldn't effect the display of entries in anyone's browser, but I thought I should fix it. I found the following line in the head.html file for Blosxom.

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

I replaced it with the following line:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Since I didn't change head.html as part of the upgrade, that issue has likely always been there; I don't know why I never noticed it before when checking blog entries with the W3C Markup Validation Service.

The upgrade didn't eliminate the error messages in the Apacehe server log file, but at least I am now at the current version of Blosxom.

[/network/web/blogging/blosxom] permanent link

[Mon Jul 28 08:57:25 2008] [error] [client 216.246.77.172] calendar debug 1: filter() called
[Mon Jul 28 08:57:25 2008] [error] [client 216.246.77.172] File is not a perl storable at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_retrieve.al) line 380, <DATA> line 32, at /home/jsmith/www/blog/plugins/calendar line 322
[Mon Jul 28 08:57:25 2008] [error] [client 216.246.77.172] Premature end of script headers: blosxom
[Mon Jul 28 08:58:22 2008] [error] [client 66.249.71.193] calendar debug 1: start() called, enabled
[Mon Jul 28 08:58:23 2008] [error] [client 66.249.71.193] calendar debug 1: filter() called
[Mon Jul 28 08:58:23 2008] [error] [client 66.249.71.193] File is not a perl storable at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/_retrieve.al) line 380, <DATA> line 32, at /home/jsmith/www/blog/plugins/calendar line 322

The blog uses a Blosxom Calendar plugin.

I remembered having problems when I moved the blog from a 32-bit Linux system to a 64-bit system (see Blosxom Calendar Plugin on 64-bit System). I found the problem was similar and I was able to resolve it by deleting the .calendar.cache file from the Blosxom plugins state directory, plugins/state.

Once the blog was accessible again, I checked the state directory with ls -al again and saw the .calendar.cache file had been recreated.

[/network/web/blogging/blosxom] permanent link

[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] calendar debug 1:
start() called, enabled
[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] calendar debug 1:
filter() called
[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] Byte order is not
compatible at ../../lib/Storable.pm (autosplit into
../../lib/auto/Storable/_retrieve.al) line 331, <DATA> line 32, at
/home/jsmith/www/blosxom/plugins/calendar line 322
[Sat Apr 26 21:53:00 2008] [error] [client 192.168.0.44] Premature end of
script headers: blosxom

At [ic] HELP !FreeBSD 5.3 Box With newest version of perl storable problem , I saw the following:

You appear to have a perl configured to use 64 bit integers in its scalar
variables.  If you have existing data written with an earlier version of
Storable which this version of Storable refuses to load with a

   Byte order is not compatible

error, then please read the section "64 bit data in perl 5.6.0 and 5.6.1"
in the Storable documentation for instructions on how to read your data.

(You can find the documentation at the end of Storable.pm in POD format)

That revealed that the problem was linked to the fact that I am now using a 64-bit operating system.

I decided to see if an upgrade Storable module was available.

# cpan upgrade Storable

/usr/lib/perl5/5.8.8/CPAN/Config.pm initialized.


CPAN is the world-wide archive of perl resources. It consists of about
100 sites that all replicate the same contents all around the globe.
Many countries have at least one CPAN site already. The resources
found on CPAN are easily accessible with the CPAN.pm module. If you
want to use CPAN.pm, you have to configure it properly.

If you do not want to enter a dialog now, you can answer 'no' to this
question and I'll try to autoconfigure. (Note: you can revisit this
dialog anytime later by typing 'o conf init' at the cpan prompt.)

Are you ready for manual configuration? [yes]

I entered "no" to the prompt regarding whether I was ready for manual configuration, which resulted in the autoconfigure process proceeding.

I then checked Storable again.

# cpan Storable
CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
  Database was generated on Sat, 26 Apr 2008 17:29:46 GMT
Storable is up to date.

I checked the version of the module with perlmodver. The version was 2.18.

But the problem still remained. Taking a look at the code in the calendar plugin, I realized it was reading a file, .calendar.cache in the plugins/state directory. I had not noticed the file previously, because I had checked the directory's contents only with ls. I saw it with ls -a. The calendar plugin reads the contents of that file. I had copied the file from the old 32-bit system to the new 64-bit system when I copied the plugins directory and its subdirectores. When I deleted the .calendar.cache file from the state directory and then tried accessing the blog again, the calendar plugin recreated it, but this time it was in the proper 64-bit format that the Storable.pm module was expecting, so I was now able to view the blog with the calendar functionality now working.

Further information on the issue can be found near the end of the Storable.pm file (look in /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Storable.pm).

Perl 5.6.x introduced the ability to optional configure the perl interpreter to use C's C<long long> type to allow scalars to store 64 bit integers on 32 bit systems. However, due to the way the Perl configuration system generated the C configuration files on non-Windows platforms, and the way Storable generates its header, nothing in the Storable file header reflected whether the perl writing was using 32 or 64 bit integers, despite the fact that Storable was storing some data differently in the file. Hence Storable running on perl with 64 bit integers will read the header from a file written by a 32 bit perl, not realise that the data is actually in a subtly incompatible format, and then go horribly wrong (possibly crashing) if it encountered a stored integer. This is a design failure.

Storable has now been changed to write out and read in a file header with information about the size of integers. It's impossible to detect whether an old file being read in was written with 32 or 64 bit integers (they have the same header) so it's impossible to automatically switch to a correct backwards compatibility mode. Hence this Storable defaults to the new, correct behaviour.

What this means is that if you have data written by Storable 1.x running on perl 5.6.0 or 5.6.1 configured with 64 bit integers on Unix or Linux then by default this Storable will refuse to read it, giving the error I<Byte order is not compatible>. If you have such data then you you should set C<$Storable::interwork_56_64bit> to a true value to make this Storable read and write files with the old header. You should also migrate your data, or any older perl you are communicating with, to this current version of Storable.

If you don't have data written with specific configuration of perl described above, then you do not and should not do anything. Don't set the flag - not only will Storable on an identically configured perl refuse to load them, but Storable a differently configured perl will load them believing them to be correct for it, and then may well fail or crash part way through reading them.

[/network/web/blogging/blosxom] permanent link