RHEL5

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):

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:

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.

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:

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:

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.

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:

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.)

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:

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

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

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