RHEL5

Solution to Invalid command 'PubcookieAppID'

When setting up Pubcookie, you may encounter an "Internal Server Error" in your browser and the following error in /var/log/httpd/ssl_error_log (or wherever you're keeping your SSL error log):

[alert] [client] /var/www/html/foo/bar/baz/.htaccess: Invalid command 'PubcookieAppID', perhaps misspelled or defined by a module not included in the server configuration

This might be a headscratcher for a while, since you've probably been working hard to make sure that your Pubcookie configuration is nice and tidy and your .htaccess file is set up with PubcookieAppID, like this:

AuthType NetID
PubcookieAppID fribble
require valid-user

In fact, Apache is telling you exactly what you need to know: it can't make sense of the PubcookieAppID directive because the module that interprets that directive is not loading and thus is "not included in the server configuration."

To solve this, make sure that a line like this is actually somewhere in your configuration, normally somewhere like /etc/httpd/conf.d/pubcookie.conf:

LoadModule pubcookie_module modules/mod_pubcookie.so

In my case, I had commented it out while getting SSL to work. Duh.

Red Hat Enterprise Linux 5 on Dell OptiPlex 990 Initial Impressions

I received a Dell OptiPlex 990 and installed RHEL5 on it. Some preliminary observations:

  • I wanted a RAID 1, so I reached for a trusty 3ware 8006-2LP, which is a 64-bit-capable SATA RAID PCI card that I typically run in a 32-bit PCI slot. But the OptiPlex 990 has placed a heatsink directly behind the PCI slot. The card can't physically fit in the slot because the heatsink is in the way. That led to my next adventure.

  • I've tried several times over the years to run software RAID on OptiPlex systems both with FreeBSD and Linux. Everything would set up fine but under load the computer would reboot and rebuild. I suspect that the SATA controllers on the motherboard were to blame. But I thought hey, this whole Sandy Bridge thing might have improved things -- let's try again. So I put in the Red Hat installer. That led to my next adventure.
  • The onboard Sandy Bridge video is not compatible with the installer. After X tries to start the result is a black screen. Not too surprising, really. Fortunately the installer offers a handy VNC option which worked fine.
  • I created two RAID partitions, mirrored them, and assigned the /boot mountpoint to the mirror. Then I created a large LVM volume group and created logical volumes for the rest of my mountpoints. A brief summary of operations:
Create RAID partition of 100MB on /dev/sda
Create RAID partition of 100MB on /dev/sdb
Create RAID device on /dev/md0 using the above two partitions in RAID1. Mount point is /boot.

Create RAID partition of 80G on /dev/sda2
Create RAID partition of 80G on /dev/sdb2
Create RAID device on /dev/md1 of type LVM physical volume

Click LVM button and create logical volumes for swap, /var/log, and /. Results:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol01
                       65G  2.3G   59G   4% /
/dev/mapper/VolGroup00-LogVol02
                      9.5G  152M  8.9G   2% /var/log
/dev/md0               99M   13M   82M  14% /boot
tmpfs                 902M     0  902M   0% /dev/shm

Now on to test whether the onboard SATA controllers would fall down. I ran two simultaneous instances of bonnie++, one in /var/bonnie and one in /var/log/bonnie (separate logical volumes, if you've been paying attention and haven't fallen asleep yet). No rebooting. I was impressed.

My final observation: the onboard NIC is an Intel 82579LM which does not seem to have an onboard TCP offload engine. Though the 82577LM does in this matrix so I'm not sure. Let's see what ethtool has to say:

# ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off
generic-receive-offload: off

Update 2011-06-15: The 990 is definitely noisier than the 980 or the 7xx series due to fan placement and lack of hooded airflow internally. Also, with RHEL6 and BIOS A03 the OptiPlex 990 will shut down but will hang when restarted. In order for it to reboot cleanly it is necessary to add reboot=pci to the kernel options in /etc/grub.conf.

Nonparsing Apache Log Messages Solved

I set up a new Red Hat Enterprise Linux 5 webserver but the nightly emails from logwatch were complaining about logs not being parsed correctly:

--------------------- httpd Begin ------------------------

This is a listing of log lines that were not parsed correctly.
Perhaps the variable $LogFormat in file conf/services/http.conf
is not correct?

(Only the first ten are printed; there were a total of 188)
   "1.2.3.4 - - [30/Mar/2011:01:49:18 -0500] "GET /foo/bar/modules/node/node.css HTTP/1.1" 200 678 "https://www.example.edu/foo/bar/baz"
   ...

I looked in /etc/logwatch/conf/services but there was no httpd.conf in there. In fact, there was nothing there, so the speculation by logwatch as to what the problem was was appreciated but not helpful.

Looking more carefully at the log entries, it became apparent that they were all from referrers that were requests over SSL. When I pored over the logging configuration for the virtual hosts on this box, I discovered that the CustomLog directive for the host listening on 443 was very slightly different than the default host; yet they were writing to the same log file.

Making the two CustomLog directives identical fixed the problem. (I also changed the configuration so that https requests were written to a separate file.)

Topic: 

Logrotate configuration file for Apache Solr on RHEL5

I'm running Solr using Jetty and logging to /var/log/solr.log.

This log is growing so I added a logrotate entry at /etc/logrotate.d/solr as follows:

# Logrotate file for /var/log/solr.log
/var/log/solr.log {
   rotate 5
   compress
   size 10M
   weekly
   postrotate
     /sbin/service solr restart
   endscript
}

Since this is a new file, the SELinux security context is off for /etc/logrotate.d/solr:

# ls -lZ /etc/logrotate.d
-rw-r--r--  root root system_u:object_r:etc_t          acpid
-rw-r--r--  root root system_u:object_r:etc_t          conman
-rw-r--r--  root root system_u:object_r:etc_t          cups
-rw-r--r--  root root system_u:object_r:etc_t          mgetty
-rw-r--r--  root root system_u:object_r:etc_t          ppp
-rw-r--r--  root root system_u:object_r:etc_t          psacct
-rw-r--r--  root root system_u:object_r:etc_t          rpm
-rw-r--r--  root root system_u:object_r:etc_t          setroubleshoot
-rw-r--r--  root root root:object_r:etc_t              solr
...

That can be fixed by telling SELinux to relabel the solr file using the correct context for /etc/logrotate.d/:

# chcon --reference=/etc/logrotate.d solr
[root@plpt300 logrotate.d]# ls -lZ
-rw-r--r--  root root system_u:object_r:etc_t          acpid
-rw-r--r--  root root system_u:object_r:etc_t          conman
-rw-r--r--  root root system_u:object_r:etc_t          cups
-rw-r--r--  root root system_u:object_r:etc_t          mgetty
-rw-r--r--  root root system_u:object_r:etc_t          ppp
-rw-r--r--  root root system_u:object_r:etc_t          psacct
-rw-r--r--  root root system_u:object_r:etc_t          rpm
-rw-r--r--  root root system_u:object_r:etc_t          setroubleshoot
-rw-r--r--  root root system_u:object_r:etc_t          solr
...

The new config file can be checked using the debug flag for logrotate, e.g.:

# logrotate --debug /etc/logrotate.d/solr
reading config file /etc/logrotate.d/solr
reading config info for /var/log/solr.log

Handling 1 logs

rotating pattern: /var/log/solr.log  weekly (5 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/solr.log
  log does not need rotating
not running postrotate script, since no logs were rotated

Pages

Subscribe to RSS - RHEL5