As a follow-up to my post on getting rid of the X-Authentication-Warning error when using phpList on FreeBSD, here’s how to do the same in Linux.

Open up /etc/mail/trusted-users in your favorite editor, and add both the user that your Apache is running under, as well as any usernames which are processing phpList queues and bounces via crontab. For example, your trusted-users file should look like this:
httpd
yourusername
Save & Exit. Restart sendmail with the following command:
/etc/init.d/sendmail restart
Now when you send mail with phpList, the headers won’t contain X-Authentication-Warnings.

One security drawback that you should be aware of: Any user on your system can now use PHP to send email with “forged” headers. You basically just gave everyone on your system “Trusted User” status to Sendmail, so be sure that you trust your users before actually doing this!

See how to do this on FreeBSD

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

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.

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.

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.