phpList with crontab: USER environment variable is not defined

When trying to automate processing of the mail queue and/or bounces in phpList, I came across the following error when calling the phplist command line script from a crontab:
Error: USER environment variable is not defined, cannot do access check. Please make sure USER is defined.
This happens because when a crontab executes, the $USER variable is not set. We must set it in our script. So open up the phplist file and add the following:
USER=youusername
export USER

The entire file should now look like this:
CONFIG=/path/to/phplist/config/config.php
export CONFIGUSER=yourusername
export USER/path/to/php /home/yourusername/path/to/phplist/admin/index.php $*

Note that you also must set the $commandline_users variable in your config/config.php:
$commandline_users = array("yourusername");
With all of that in place, you can automate your queue and bounce processing with a crontab like this (adjust your paths accordingly):
# Suppress crontab emails
MAILTO=""
# Process phplist queue daily, every half hour
0,30 * * * * /home/yourusername/phplist -pprocessqueue
# Process phplist bounces once a day, 5am
0 5 * * * /home/yourusername/phplist -pprocessbounces

Apache with SSL: “dftables: error while loading shared libraries”

While updating OpenSSL & Apache on a Linux machine (2.4.7-10smp), I came across an error when running ‘make‘ for Apache:
/usr/local/src/httpd-2.0.55/srclib/apr/libtool --silent --mode=link gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -I/usr/local/src/httpd-2.0.55/srclib/apr/include -I/usr/local/src/httpd-2.0.55/srclib/apr-util/include -I. -I/usr/local/src/httpd-2.0.55/os/unix -I/usr/local/src/httpd-2.0.55/server/mpm/prefork -I/usr/local/src/httpd-2.0.55/modules/http -I/usr/local/src/httpd-2.0.55/modules/filters -I/usr/local/src/httpd-2.0.55/modules/proxy -I/usr/local/src/httpd-2.0.55/include -I/usr/local/src/httpd-2.0.55/modules/generators -I/usr/local/ssl/include/openssl -I/usr/local/ssl/include -I/usr/local/src/httpd-2.0.55/modules/dav/main -export-dynamic -L/usr/local/ssl/lib -o dftables -L/usr/local/ssl/lib dftables.lo -lssl -lcrypto
./dftables > /usr/local/src/httpd-2.0.55/srclib/pcre/chartables.c
./dftables: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory
make[3]: *** [/usr/local/src/httpd-2.0.55/srclib/pcre/chartables.c] Error 127
make[3]: Leaving directory `/usr/local/src/httpd-2.0.55/srclib/pcre'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/httpd-2.0.55/srclib/pcre'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/httpd-2.0.55/srclib'
make: *** [all-recursive] Error 1

I figured this was because of an inconsistency between the two versions of OpenSSL I had on my system. The system came with the SSL libraries installed in /usr/lib, which I had updated as symlinks to my newly & manually installed directory /usr/local/ssl/lib. That wasn’t enough. Apache (dftables specifically) needs to know where the new libraries are, so we must tell it where to look. Do this by adding our new lib dir to /etc/ld.so.conf. Open it up in your favorite editor and add the following line:
/usr/local/ssl/lib
Save & Exit, then run:
/sbin/ldconfig
Now re-run make in your Apache dir and everything should go smoothly. Note that you may want to run make distclean first just to be sure you start with a clean slate.

Apache: Forcing SSL using mod_rewrite and .htaccess

If you want to force all connections to your Apache web server to use SSL (https), you can do so with a simple .htaccess file inside the directory you want to protect:
# Force SSL connections
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Make sure you get all the proper spacing in there, or else it won’t work! I spent quite a bit of time pulling my hair out trying to get this to work, only to find out I was missing a space somewhere.

Apache & mod_gzip: No rule to make target `libgzip.’

I was upgrading an Apache install from 1.3.33 to 1.3.34 last night, including the gzip module using: --activate-module=src/modules/gzip/mod_gzip.o, and during the make process I received the following error:
rm -f libgzip.a
ar cr libgzip.a mod_gzip.o mod_gzip_compress.o mod_gzip_debug.o
ranlib libgzip.a
make[4]: *** No rule to make target `libgzip.', needed by `lib'. Stop.
make[3]: *** [all] Error 1
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/usr/local/src/apache_1.3.34/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/usr/local/src/apache_1.3.34'
make: *** [build] Error 2

It turns out that there’s an entry in mod_gzip’s Makefile.tmpl file that confuses my system. The very first line of src/modules/gzip/Makefile.tmpl uses a variable named LIBEXT that’s not defined on my system, so it fails. It’s an easy fix, open up src/modules/gzip/Makefile.tmpl for editing and find:
LIB=libgzip.$(LIBEXT)
And replace with:
LIB=libgzip.a
Save & Exit, run make clean; make; make install in the Apache src dir and you should be good to go.

FreeBSD: SSH logins hang after install of openssh-portable

I needed to upgrade my OpenSSL installation on FreeBSD without having to recompile everything (make installworld), and found out that you can do so by installing the openssh-portable port. You must force it to replace the base OpenSSL install, so you pass in the proper options:
cd /usr/ports/security/openssh-portable
make -DOPENSSH_OVERWRITE_BASE install

This went great, however, I could no longer log in remotely. It would prompt me for username and password then just hang until it timed out.

This happens because newer versions of sshd have “UsePrivilegeSeparation” (privsep) set to YES by default, so sshd will always try to verify the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address.

Because sshd is chrooted to /usr/local/empty, it is unable to read /etc/resolv.conf and fails any DNS lookups. This is why we are hanging! To fix it, I found some people suggesting to copy /etc/resolv.conf to /var/empty/etc/resolv.conf. I decided to try a symbolic link instead, but got the following error.
mkdir /var/empty/etc
mkdir: /var/empty/etc: Operation not permitted

This is probably caused by some flags or the schg bit on the dir, and I didn’t want to deal with it. Instead I decided to take the easy (even though probably unsafe) way out: disable privsep. Open up your /etc/ssh/ssd_config file and add the following:
UsePrivilegeSeparation no
Restart your sshd with /etc/rc.d/sshd restart and you should be good to go! I know it’s probably not a good idea to run with privsep off, but with it on, NOBODY could log into the server via ssh, including myself, and that’s no good. Hopefully OpenSSH and the FreeBSD ports people will find a way to make things work with privsep enabled in the near future.

Xdebug & phpize for PHP on FreeBSD

I ran into a few problems trying to install Xdebug into PHP on both FreeBSD 5.2 and FreeBSD 5.4. My research led me to this PHP bug thread and the proper solution. Here’s a quick summary to get you going with Xdebug:

Xdebug is installed via phpize, and phpize has some requirements:

  • autoconf: 2.13
  • automake: 1.4+
  • libtool: 1.4.x+ (except 1.4.2)
  • bison: 1.28 (preferred), 1.35, or 1.75
  • flex: 2.5.4

I was able to get mine up and running with the following versions:

  • autoconf: 2.59_2
  • automake: 1.9.5
  • libtool: 1.5.10_1
  • bison: 1.75_2
  • flex: 2.5.4

However, the ports packages for autoconf, automake, and libtool that come with FreeBSD are installed into non-standard locations, so phpize is unable to find them. This is easily fixed with symlinks (NOTE: symlinks will vary depending on which versions you have installed):
ln -s /usr/local/bin/aclocal19 /usr/local/bin/aclocal
ln -s /usr/local/bin/automake19 /usr/local/bin/automake
ln -s /usr/local/bin/autoconf259 /usr/local/bin/autoconf
ln -s /usr/local/bin/autoheader259 /usr/local/bin/autoheader
ln -s /usr/local/bin/libtool15 /usr/local/bin/libtool
ln -s /usr/local/bin/libtoolize15 /usr/local/bin/libtoolize
ln -s /usr/local/share/aclocal19/ /usr/local/share/aclocal
ln -s /usr/local/share/aclocal19/libtool15.m4 /usr/local/share/aclocal19/libtool.m4

Now, assuming you have all the correct versions installed and paths present, phpize should be able to find everything and Xdebug should install as expected:
# phpize
# ./configure --enable-xdebug
# make
# cp modules/xdebug.so /usr/local/lib/php/extensions

  • Add the following to php.ini:
    zend_extension="/usr/local/lib/php/extensions/xdebug.so"
  • Restart your webserver
  • Check the output of phpinfo() to make sure Xdebug is properly loaded

Bob Moog (1934 – 2005)

Bob Moog
ASHEVILLE, N.C. – August 21, 2005 – Bob died this afternoon at his home in Asheville, N.C. He was 71. Bob was diagnosed with brain cancer (glioblastoma multiforme or GBM) in late April 2005. He had received both radiation treatment and chemotherapy to help combat the disease. He is survived by his wife, Ileana, his five children, Laura Moog Lanier, Matthew Moog, Michelle Moog-Koussa, Renee Moog, and Miranda Richmond; and the mother of his children, Shirleigh Moog.

Bob was warm and outgoing. He enjoyed meeting people from all over the world. He especially appreciated what Ileana referred to as “the magical connection” between music-makers and their instruments.

No public memorial is planned. Fans and friends can direct their sympathies or remembrances to www.caringbridge.com/visit/bobmoog.

Bob’s family has established The Bob Moog Foundation dedicated to the Advancement of Electronic Music in his memory. Many of his longtime collaborators including musicians, engineers and educators have agreed to sit on its executive board including David Borden, Wendy Carlos, Joel Chadabpe, John Eaton, David Mash, and Rick Wakeman. For more information about the foundation, contact Matthew Moog at mattmoog@yahoo.com.

We’ll miss you Bob.