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.

I add a VirtualHost section for the website in the httpd.conf file similar to the following:

<VirtualHost *:80>
    ServerName example.com
    ServerAdmin webmaster@example.com
    ServerAlias www.example.com
    DocumentRoot /home/jdoe/public_html/mysite
    ScriptAlias /blog/ "/home/jdoe/public_html/mysite/blog/"
    ErrorLog "|/usr/sbin/rotatelogs -l /home/jdoe/public_html/mysite/logs/%Y/error.log.%Y.%m.%d 86400"
    CustomLog "|/usr/sbin/rotatelogs -l /home/jdoe/public_html/mysite/logs/%Y/transfer.log.%Y.%m.%d 86400" combined
</VirtualHost>

The ServerName line is the fully qualified domain name (FQDN) for the site and the ServerAlias line allows the site to be accessed with an "alias", e.g., www.example.com in addition to example.com. Of course, you must have configured the relevant Domain Name System (DNS) servers to point both example.com and www.example.com to the same IP address for the site.

The ServerAdmin line is where you can designate the email address to which email related to the site can be sent. The DocumentRoot line points to the directory that will serve as the top-level directory for the website.

The ErrorLog and CustomLog directives provide the location and name for the log that will contain Apache's error messages related to the site and the log that contains entries recording access to the site's pages. I use rotatelogs located in the /usr/sbin directory to rotate the logs at midnight each night. The %Y, %m, and %d represent the current year in four digit form, e.g. 2016, the current month in two-digit form, e.g., 02, and day in two digit form, e.g. 19. The "combined" parameter for the customlog results in additional information being recorded for each access to a web page - see the "Combined Log Format" section of Log Files.

The line where I made an error was the ScriptAlias line. Since blosxom uses a Perl script named blosxom, the directory where that script is located needs to be designated as one from which scripts can be executed, e.g., if I have the blosxom Perl script in /home/jdoe/public_html/mysite/blog and I want to access the blog from http://www.example.com/blog/blosxom, I would use the following ScriptAlias directive:

ScriptAlias /blog/ "/home/jdoe/public_html/mysite/blog/"

In this case, I renamed the mysite directory, which is the name for the web site in my case from something else, but forgot to update the ScriptAlias line in the VirtualHosts section when I did so. When I corrected the problem, I no longer saw a script not found or unable to stat errors in the Apache error log file for the site when I attempted to access the blog. Instead, I saw the error 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@example.com to inform them of the time this error occurred, and the actions you performed just before this error.

Checking the Apache error log file, I found the following entries related to the problem:

[Fri Feb 19 19:33:38.092121 2016] [cgi:error] [pid 3635] [client 10.11.8.2:2617] AH01215: Can't locate CGI.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /home/jdoe/public_html/mysite/blog/blosxom line 92.
[Fri Feb 19 19:33:38.092266 2016] [cgi:error] [pid 3635] [client 10.11.8.2:2617] AH01215: BEGIN failed--compilation aborted at /home/jdoe/public_html/mysite/blog/blosxom line 92.

From past experience with the "Can't locate CGI.pn in @INC" error message - see CGI.pm missing from CentOS system - I knew I needed to install the CGI.pm Perl module, though first I installed CPAN.pm since that module was missing, also, as I found from the following command:

# perl -e shell -MCPAN Can't locate CPAN.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .). BEGIN failed--compilation aborted.

Since the system was running CentOS 7 with yum as the package manager, I installed perl-CPAN with yum install perl-CPAN. Instead of installing the CGI.pm module as I had in the prior instance when I encountered the error message, I used yum install perl-CGI this time, though. I still received the error message, though, even after I restarted the Apache web server with apachectl restart. An RPM query showed the software was installed.

# rpm -qi perl-CGI
Name        : perl-CGI
Version     : 3.63
Release     : 4.el7
Architecture: noarch
Install Date: Fri 19 Feb 2016 10:28:32 PM UTC
Group       : Development/Libraries
Size        : 716590
License     : (GPL+ or Artistic) and Artistic 2.0
Signature   : RSA/SHA256, Fri 04 Jul 2014 04:15:15 AM UTC, Key ID 24c6a8a7f4a80eb5
Source RPM  : perl-CGI-3.63-4.el7.src.rpm
Build Date  : Mon 09 Jun 2014 07:31:20 PM UTC
Build Host  : worker1.bsys.centos.org
Relocations : (not relocatable)
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Vendor      : CentOS
URL         : http://search.cpan.org/dist/CGI
Summary     : Handle Common Gateway Interface requests and responses
Description :
CGI.pm is a stable, complete and mature solution for processing and preparing
HTTP requests and responses. Major features including processing form
submissions, file uploads, reading and writing cookies, query string
generation and manipulation, and processing and preparing HTTP headers. Some
HTML generation utilities are included as well.

CGI.pm performs very well in in a vanilla CGI.pm environment and also comes
with built-in support for mod_perl and mod_perl2 as well as FastCGI.

When I checked the Apache error log for the site again, I saw different error entries this time:

[Fri Feb 19 22:32:02.806970 2016] [cgi:error] [pid 3635] [client 10.11.8.2:2212] AH01215: can't write into /home/jdoe/public_html/mysite/blog/plugins/state/.calendar.cache: Permission denied at /home/jdoe/public_html/mysite/blog/plugins/calendar line 349.
[Fri Feb 19 22:32:02.810426 2016] [cgi:error] [pid 3635] [client 10.11.8.2:2212] End of script output before headers: blosxom
[Fri Feb 19 22:32:18.963641 2016] [cgi:error] [pid 4952] [client 10.11.8.2:2217] AH01215: can't write into /home/jdoe/public_html/mysite/blog/plugins/state/.calendar.cache: Permission denied at /home/jdoe/public_html/mysite/blog/plugins/calendar line 349.
[Fri Feb 19 22:32:18.967157 2016] [cgi:error] [pid 4952] [client 10.11.8.2:2217] End of script output before headers: blosxom

I could see that the issue was related to the calendar plugin I was using. I saw in the comments I had for that plugin that I needed to "Unzip the file and install the extracted zip file in your Blosxom plugins directory. Make sure it's world-readable, which you can set on a Unix or Linux system by the command chmod 744 calendar." I checked the file permissions on both the plugins directory and the calendar file; the directory had permissions 744, which the note indicated was needed, and the calendar file had 644 permissions, i.e., both had read permission for "others".

[jdoe@localhost blog]$ ls -ld plugins
drwxr-xr-x 3 jdoe jdoe 4096 Dec 24 03:56 plugins
[jdoe@localhost blog]$ ls -l plugins/calendar
-rw-r--r-- 1 jdoe jdoe 21738 Mar 11  2014 plugins/calendar
[jdoe@localhost blog]$

Looking at the error message again, I realized that the issue was with plugins/state/.calendar.cache. Checking the permissions on that file on the system where the error was occurring, I saw the following:

[jdoe@localhost blog]$ ls -ld plugins
drwxr-xr-x 3 jdoe jdoe 4096 Dec 24 03:56 plugins
[jdoe@localhost blog]$ ls -l plugins/calendar
-rw-r--r-- 1 jdoe jdoe 21738 Mar 11  2014 plugins/calendar
[jdoe@localhost blog]$ ls -al plugins/state
total 3528
drwxr-xr-x 2 jdoe jdoe    4096 Dec 24 04:00 .
drwxr-xr-x 3 jdoe jdoe    4096 Dec 24 03:56 ..
-rw-r--r-- 1 jdoe jdoe 3558696 Feb  6 23:35 .calendar.cache
-rw-rw-rw- 1 jdoe jdoe   41891 Feb  3 18:55 queries

For comparison, I looked at the permissions on this system and saw that the owner and group for the state directory was the apache account and that apache was also the owner and group for all files within the directory:

[jdoe@localhost blog]$ ls -ld plugins
drwxr-xr-x. 3 jdoe jdoe 44 Dec 23 22:56 plugins
[jdoe@localhost blog]$ ls -al plugins/state
total 6388
drwxr-xr-x. 2 apache apache      42 Dec 23 23:00 .
drwxr-xr-x. 3 jdoe    jdoe         44 Dec 23 22:56 ..
-rw-r--r--. 1 apache apache 6493335 Feb 19 17:52 .calendar.cache
-rw-rw-rw-. 1 apache apache   41935 Feb 13 18:28 queries

From the root account, I changed the permissions on the state directory and the files within it.

# chown -R apache /home/jdoe/public_html/mysite/blog/plugins/state
# chgrp -R apache /home/jdoe/public_html/mysite/blog/plugins/state
#

When I tried accessing the blog in a browser again, this time I was able to successfully access the blog.

 

TechRabbit ad 300x250 newegg.com

Justdeals Daily Electronics Deals1x1 px