/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:
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:
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:
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:
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.