I'm running OS X 10.7 Lion. Today I'm working on some database-heavy code that also creates lots of watchdog entries. So I decided to turn off Drupal's database logging and turn on syslog.

I created a file for the log entries to go into:

sudo touch /var/log/drupal.log


I added one line to /etc/syslog.conf to tell OS X to put messages coming to the local3 logging facility into the new file.

local3.* /var/log/drupal.log


I rebooted. If I had a neckbeard I would have used launchctl instead.

Then I enabled syslog module on Drupal's module administration screen, went to Administration / Configuration / Development / Logging and errors and set the Syslog facility to LOG_LOCAL3.

And I turned off the database logging module.

Now I can happily watch incoming watchdog entries in a terminal with

tail -f /var/log/drupal.log


UPDATE: OS X 10.8 Mountain Lion and OS X 10.9 Mavericks are slightly different:

1. Just like above, create the log file with

sudo touch /var/log/drupal.log


2. Instead of adding a line to /etc/syslog.conf, add the following line to /etc/asl.conf:

# Drupal logging
? [= Facility local3] file /var/log/drupal.log


3. Restart logging with

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist


On RHEL6, the following packages are installed when you do

yum groupinstall "Web Server"


on a RHEL6 minimal install:

===================================================================================
Package Arch Version
===================================================================================
Installing:
crypto-utils x86_64 2.4.1-24.2.el6
httpd x86_64 2.2.15-15.el6_2.1
httpd-manual noarch 2.2.15-15.el6_2.1
mod_perl x86_64 2.0.4-10.el6
mod_ssl x86_64 1:2.2.15-15.el6_2
mod_wsgi x86_64 3.2-1.el6
webalizer x86_64 2.21_02-3.3.el6
Installing for dependencies:
apr x86_64 1.3.9-5.el6_2
apr-util x86_64 1.3.9-3.el6_0.1
apr-util-ldap x86_64 1.3.9-3.el6_0.1
fontconfig x86_64 2.8.0-3.el6
freetype x86_64 2.3.11-6.el6_2.9
gd x86_64 2.0.35-10.el6
httpd-tools x86_64 2.2.15-15.el6_2.1
libX11 x86_64 1.3-2.el6
libX11-common noarch 1.3-2.el6
libXau x86_64 1.0.5-1.el6
libXpm x86_64 3.5.8-2.el6
libjpeg x86_64 6b-46.el6
libpng x86_64 2:1.2.49-1.el6_2
libxcb x86_64 1.5-1.el6
mailcap noarch 2.1.31-2.el6
perl x86_64 4:5.10.1-127.el6
perl-BSD-Resource x86_64 1.29.03-3.el6
perl-ExtUtils-MakeMaker x86_64 6.55-127.el6
perl-ExtUtils-ParseXS x86_64 1:2.2003.0-127.el
perl-Module-Pluggable x86_64 1:3.90-127.el6
perl-Newt x86_64 1.08-26.el6
perl-Pod-Escapes x86_64 1:1.04-127.el6
perl-Pod-Simple x86_64 1:3.13-127.el6
perl-Test-Harness x86_64 3.17-127.el6
perl-devel x86_64 4:5.10.1-127.el6
perl-libs x86_64 4:5.10.1-127.el6
perl-version x86_64 3:0.77-127.el6


I don't use webalizer, httpd-manual, mod_wsgi or mod_perl for standard installs (mostly Drupal), so the following is a more minimal version of the above:

yum install mod_ssl httpd


That results in far fewer packages:

===============================================================================
Package Arch Version
===============================================================================
Installing:
httpd x86_64 2.2.15-15.el6_2.1
mod_ssl x86_64 1:2.2.15-15.el6_2.1
Installing for dependencies:
apr x86_64 1.3.9-5.el6_2
apr-util x86_64 1.3.9-3.el6_0.1
apr-util-ldap x86_64 1.3.9-3.el6_0.1
httpd-tools x86_64 2.2.15-15.el6_2.1
mailcap noarch 2.1.31-2.el6


Perhaps you'll remember me staring in disbelief when Dell placed a heatsink directly behind the PCIe slot in the OptiPlex 990 (apparently it's also the case in the 980).

You'll be happy to know that the motherboard layout has changed with the OptiPlex 9010.

Instead of being unable to seat your GeForce GTX560 card (for example) because of a heatsink, you'll simply need to unplug all of your SATA devices, since the SATA ports are behind the 16x PCIe slot.

But John, I hear you saying, why not use the other slot, the one near the edge of the case? It's a 16x slot, isn't it? Well, according to the spec sheet it's actually a "full height PCIE x16 (wired x4)." Thud.

I was setting up a hypervisor for RHEV running a full RHEL6 install instead of RHEV-H, and I wanted to tune it for better hypervisorness.

So I thought, Hey! I'll install tuned, since I am all excited about tuned after viewing the slides from Mark Wagner's Achieving Top Network Performance (PDF) at the 2012 Red Hat Summit. I was particularly excited about slide 12 entitled "Teaser 3 - latency."

Not to mention that the tuned virtual-host profile is the recommended profile for RHEV hosts.

Anyway, I went ahead and installed tuned and applied the virtual-host profile:

# yum -y install tuned
...
# tuned-adm profile virtual-host
Switching to profile 'virtual-host'
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf: [ OK ]
Calling '/etc/ktune.d/tunedadm.sh start': can't rename /etc/mtab.tmp to /etc/mtab: Permission denied
can't rename /etc/mtab.tmp to /etc/mtab: Permission denied


Er...what? Permission denied for root to rename?

It's probably SELinux. It's always SELinux. Sure enough:

# ls -laZ /etc/mtab
-rw-r--r--. root root system_u:object_r:system_conf_t:s0 /etc/mtab
# restorecon /etc/mtab
# ls -laZ /etc/mtab
-rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 /etc/mtab


Now it works fine:

# tuned-adm profile virtual-host
Reverting to saved sysctl settings: [ OK ]
Calling '/etc/ktune.d/tunedadm.sh stop': [ OK ]
Stopping tuned: [ OK ]
Switching to profile 'virtual-host'
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf: [ OK ]
Calling '/etc/ktune.d/tunedadm.sh start': [ OK ]
Applying sysctl settings from /etc/sysctl.conf
Starting tuned: [ OK ]

An observation: each time you apply a tuned profile (for example, going back to the default and then to a non-default again), tuned-adm may append options to /etc/mtab. For example, we start with the following line in /etc/mtab:

/dev/mapper/[UUID] /rhev/data-center/mnt/blockSD/[UUID] ext3 rw,barrier 0 0


After doing

# tuned-adm profile virtual-host
# tuned-adm profile default
# tuned-adm profile virtual-host

the line in /etc/mtab looks like this:

/dev/mapper/[UUID] /rhev/data-center/mnt/blockSD/[UUID] ext3 rw,barrier,nobarrier,barrier,nobarrier 0 0


This was a bit confusing, but since mount and umount maintain /etc/mtab I assume they know what they're doing. Interestingly, after a reboot, /proc/mounts says:

/dev/mapper/[UUID] /rhev/data-center/mnt/blockSD/[UUID] ext3 rw,seclabel,relatime,errors=continue,barrier=1,data=ordered 0 0


That makes me sleep a little better, given the dire warnings about running ext3 without barrier=1.