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, 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 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. 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
Blosxom Calendar Plugin Bug
I use Blosxom for my blog and
the Blosxom Calendar Plugin to add a calendar to the blog. I
installed version 0.6i of the plugin on August 30, 2004. Today, I noticed that
if I click on the path link at the bottom of an entry where the path has
a directory as part of the path with a name beginning with a number, clicking
on that link generates the internal server error shown below.
Server error!
-
The server encountered an internal error and was
unable to complete your request.
-
Error message:
Premature end of script headers: blosxom
-
If you think this is a server error, please contact
the webmaster
Error 500
When I looked in the site's error log, I found the following.
[Mon Jul 25 19:18:21 2005] [error] [client 162.83.13.120] Cannot handle date (0, 0, 0, 1, 11, 2800) at /support/blog/plugins/calendar line 214, referer: http://support.moonpoint.com/blog/blosxom/index.html?find=Dell&plugin=find&path=
When I checked line 214 in the calendar plugin I saw the following.
$monthstart = timelocal(0,0,0,1,$month-1,$year-1900);
The problem appears to be triggered whenever there is a directory with
the directory name starting with a number in part of the path. I had a
directory with /pc/hardware/dell/4700 as part of the path. I renamed the
4700 directory to d4700 and the problem went away. I changed it to 4700d
and the problem reoccurred. I changed it to 3800 and the problem remained.
Since I didn't have time to carefully examine the code in the calendar
plugin, I finally just changed the directory to dimension_4700 and left
it at that.
I thought there might be a later version of the plug-in at the
developer's website, but the 0.6i version is the one still posted there.
[/network/web/blogging/blosxom]
permanent link
Blosxom Calendar Plugin
A plugin to add a calendar to a
Blosxom blog is available from
Mt. Molelog or from
here.
When I first installed the plugin, I received an "Error 500" error from
my blog's webpage with the error message "Premature
end of script headers: blosxom.cgi". The webpage loaded correctly once
I changed the ownership of the state directory, which lies
beneath the plugins directory. I used the following commands
to change the user and group for the directory:
chown apache state
chgrp apache state
I used apache as the owner and group, since my web server runs Apache
webserver software. I could also have used chmod 777 to
make the directory world writable, but that would be much less secure,
since anyone else on the system could then have write access to the
directory.
[/network/web/blogging/blosxom]
permanent link
