MoonPoint Support Logo

 


Shop Amazon Warehouse Deals - Deep Discounts on Open-box and Used ProductsAmazon Warehouse Deals



Advanced Search
April
Sun Mon Tue Wed Thu Fri Sat
 
25 26 27
28 29 30        
2019
Months
AprMay Jun
Jul Aug Sep
Oct Nov Dec


Fri, Apr 22, 2016 10:24 pm

Blosxom calendar plugin cache file causing internal server error

This morning, when I attempted to access an old blog posting to see how I had resolved a problem in the past that I was experiencing again, I saw a page displaying an "Internal Server Error" message. The page also noted "More information about this error may be available in the server error log. When I checked the Apache error log for the site, I noticed references to the problem being linked to line 322 in the calendar plugin code for the Blosxom blogging software I use on the site. I found the issue was related to the the calendar plug-in's cache file being only zero bytes in length. When I deleted the cache file it was automatically recreated, which resolved the problem. I experienced the same problem a month ago on March 22.

[ More Info ]

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

Tue, Mar 22, 2016 11:27 pm

Blosxom - Magic number checking on storable file failed

When I attempted to access blog postings on this site where I use Blosxom for the blog, I saw the message below:

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at webmaster@moonpoint.com to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

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

Fri, Feb 19, 2016 10:19 pm

Using blosxom as a blog for a website

When I set up another website on a Linux host to use Blosxom, a Perl-based blogging system, I encountered a few problems initially. I've been using Blosxom for this site for twelve years now - I posted the first entry Identifying a Motherboard from the Award BIOS String to the site on February 22, 2004. It appealed to me because it was simple to set up and use. Posts are just text files you can create in any text editor. But it has been a long time since I set up a site using Blosxom and, though it is fairly straight-forward to set up and configure, I had a couple of issues to address after installing blosxom, one of which was just due to a misconfiguration I made in Apache's /httpd/conf/httpd.conf file.

[ More Info ]

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

Fri, Mar 28, 2014 10:12 pm

Problem with Blosxom calendar cache

I use the Calendar Plugin for Blosxom on this site. When I checked the site with the Xenu Link Sleuth tool, which reveals broken links, today I found it reporting errors for urls with "//" in the directory path in the URL. It took me a few minutes to realize that the errors were due to the calendar displayed for the blog that points to prior entries. When I looked at the URLs for various days on this month's calendar, I saw that the links were all appearing similar to the following one:

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

Wed, Mar 12, 2014 11:40 pm

Adding "rel=nofollow" to Blosxom advanced search option for find plugin

I've noticed in the logs for the blog that search engines are trying to access pages with "?advanced_search=1" in the URL. E.g., I've seen a lot of entries similar to the following:

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

Mon, Mar 10, 2014 10:29 pm

Debug output for calendar plugin for Blosxom

I've been using Blosxom for this blog and version 0+6i of the calendar plugin for Blosxom written by Todd Larason whose website seems to no longer be extant, though it is available through the Internet Archive's WayBack Machine here. The last time the Internet Archive archived the site was on March 25, 2010. The plugin can be downloaded from this site at Calendar Plugin for Blosxom.

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

Mon, Oct 07, 2013 8:46 pm

Main Id element in Blosxom's story.html

I upgraded Blosxom today from version 2.0 to 2.1.2. I normally validate the HTML code in webpages and blog entries I've created with the W3C Markup Validation Service, which is a free service provided by the World Wide Web Consortium (W3C) for verifying that HTML code in a file you upload to the service, or at a URL you request be checked by the service, is correct. I've always gotten errors similar to the one below when I've checked blog entries, but have never taken the time to figure out how to fix the problem, which I thought was in the Blosxom Perl code.

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

Mon, Oct 07, 2013 7:40 pm

Blosxom upgrade

Today while checking the server's Apache error log file, I noticed error messages that appeared to be related to Blosxom, which I've been using for this blog, which runs on a Linux server, for almost 9 years now. I found the error messages had been occurring since at least the beginning of the year and they may have been occurring for a much longer period. When I checked on the error messages, I found a February 3, 2013 posting at [Blosxom] server error where someone reported similar error messages, I found someone responding here that the messages could be due to the absence of the XML::Parser Perl module. The responder mentioned that the module is reqiured by the atomfeed plugin, which I don't use. His message also referenced the categories plugin, which I don't have, either. But I thought I would check on whether the XML::Parser module was present on the system. It wasn't, so I installed it, but that didn't stop the error messages from occurring in the Apache server's log file. I then noticed that Blosxom was not up-to-date. I had version 2.0 on the system while the current version is 2.1.2.

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, 2008 7:32 pm

Blosxom Not Working After Reboot on 64-bit System

A Linux server on which a Blosxom blog was running lost power due to a power outage. When power was restored and I rebooted the server, I found that the website hosting the blog was functioning ok, but attempting to access the blog itself returned only a blank webpage. Checking the error log for the site, I saw error messages such as the following:
[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, 2008 10:18 pm

Blosxom Calendar Plugin on 64-bit System

I found that the Calendar plugin for Blosxom stopped working when I moved my blog from a 32-bit Redhat Linux system to a 64-bit CentOS Linux system. Nothing would appear within the blog. When I checked the error log for the website, I saw the following:
[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

Once You Know, You Newegg AliExpress by Alibaba.com

Shop Amazon Local - Subscribe to Deals in Your Neighborhood

Valid HTML 4.01 Transitional

Privacy Policy   Contact

Blosxom logo