Eric R. Thern ————–=[ thern dot org ]=————–

26Nov/070

FreeBSD Plesk 8 – installing php5 as CGI alongside php4

If you have ever needed php5 to run along side php4, you can always compile php5 as a CGI, and let php4 remain as an apache module.

Here we've compiled php5 from FreeBSD's ports, and have installed it as a CGI so that specific vhosts will run on this new php5. The installation was done on a Plesk 8 box running FreeBSD 6.x.


Compiling PHP5 (installation from FreeBSD Ports)

1) Update port tree using portsnap (use `portsnap extract` instead of update if this is the first time you've used portsnap). Or use classic rsync techniques.

portsnap fetch; portsnap update

2) Configure php5 and install:

cd /usr/ports/lang/php5
make config; make install

In the config, the basics should already be selected, make sure you have not selected php5 as an apache module, and keep debugging turned off unless you require this.

3) Compile the php5 extensions.

cd /usr/ports/lang/php5-extensions
make config; make install

In the config, make sure you have selected the extensions that you require. For my purposes, I've selected: BZ2, CTYPE, CURL, DOM, EXIF, FILTER, GD, GETTEXT, HASH, ICONV, IMAP, JSON, MCRYPT, MHASH,MYSQL, NCURSES, PCRE, PDO, PDO_SQLITE, POSIX, SESSION, SIMPLEXML, SOAP, SPL, SQLITE, TOKENIZER, XML, XMLREADER, XMLRPC, XMLWRITER, XSL, ZLIB.

4) Create the directory for your installation of php, and make sure it is owned by the proper user (the siteowner) so that suexec will be happy running binaries in this directory:

mkdir /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi
chown siteowner:psacln /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi

5) Copy the new php-cgi over to this directory (we're naming the php-cgi binary 'php') and make sure to set the ownership to the siteowner, so that suexec can run this binary.

cp /usr/local/bin/php-cgi /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi/php
chown siteowner:psacln /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi/php

6) Move the recommended configuration file to the real configuration file location, edit if necessary:

mv /usr/local/etc/php.ini-recommended /usr/local/etc/php.ini

Now we add the vhost configuration and apache bits:


Add the following to your /usr/local/psa/home/vhosts/yoursite.com/conf/vhost.conf (change "yoursite.com" to your domain name or host)


ScriptAlias /php5-cgi /usr/local/psa/home/vhosts/yoursite.com/httpdocs/php5-cgi
Action application/x-httpd-php5-custom "/php5-cgi/php"

AddType application/x-httpd-php5-custom .php
AddType application/x-httpd-php5-custom .php5

Run the reconfiguration utility and restart apache:


/usr/local/psa/admin/sbin/my_apci_rst
/usr/local/psa/rc.d/httpd restart

Test out the page with a phpinfo.php script, you can create one easily from the command line, go into the httpdocs directory and run this:


echo "<?php
phpinfo();
?> " > phpinfo.php

From a browser, go to yoursite.com/phpinfo.php and see if you have the new php you just installed showing up. If you do, you have succeeded. If not, or if there are any errors, here are a few things to try:

Troubleshooting

Check the local site error_log:

/usr/local/psa/home/vhosts/yoursite.com/statistics/logs/error_log

Check the suexec log:

/usr/local/psa/apache/logs/suexec_log

Try running php from the command line:

/usr/local/bin/php -v

If you see any errors on the command line, this will result in the binary not working from Apache.

One error I ran into was this:


/usr/local/bin/php --version
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20060613/xsl.so' - Shared object "libgpg-error.so.3" not found, required by "libexslt.so.8" in Unknown on line 0
PHP 5.2.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 26 2007 03:33:26)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

This was caused by some ports being older versions. To solve this, you must make sure that the libgpg-error and related ports are up to date, and then recompile the php5-xsl port:

recompile (from packages -P) libgpg-error and related ports:

portupgrade -rf libgpg-error-\* -P

Recompile xsl related ports, I may be recompiling too many, but this worked for me:

cd /usr/ports/textproc/libxslt
make clean; make deinstall; make install
cd /usr/ports/textproc/php5-xsl
make clean; make deinstall; make install
cd /usr/ports/textproc/php5-xml
make clean; make deinstall; make install

This solved the shared library problem, and allowed php5 to work. You shouldn't have to recompile php after this, since this only impacts the shared libraries.

Double check your /usr/local/etc/php/extensions.ini to make sure that you have all the libraries installed that you require.

VN:F [1.8.4_1055]
Rating: 0 (from 0 votes)
21Nov/070

Updating Spamassassin on FreeBSD and Plesk

Updating Spamassassin on Plesk and FreeBSD is quite simple without breaking things since the Spamassassin on Plesk is pretty standard.

System: FreeBSD 6.x
Plesk Version: 8.0.x

May work with other versions.

The stock plesk Spamassassin is a 3.1.x variant, which gets pretty old pretty quick. You can upgrade this via the ports by passing a few variables to 'make install' to make sure that you

1) Back up /usr/psa/spamassassin so you have a backup in case something goes wrong:


tar -czf /usr/psa/spamassassin-backup.tar.gz /usr/psa/spamassassin

2) Install the new spamassassin from ports. Please check the prefix, and rules directories to make sure these are good. You can check these by grepping for RULES_DIR on the original plesk /usr/psa/spamassassin/bin/spamassassin file, that will tell you what directories you will want to use.


cd /usr/ports/mail/p5-SpamAssassin

All one line:


make install PREFIX=/usr/local/psa/spamassassin DEF_RULES_DIR=/usr/local/psa/spamassassin/share/spamassassin LOCAL_RULES_DIR=/usr/local/psa/spamassassin/etc/mail/spamassassin

Make sure you run spamassassin --lint to make sure that the rules you have installed are all error free.


/usr/local/psa/spamassassin/bin/spamassassin --lint

Restart spamassassin using:


/usr/local/psa/rc.d/psa-spamassassin restart

It should come back online and work, check the logs to make sure that it has. Send a few emails to make sure your new spamassassin is processing correctly, if so, sit back and enjoy another small plesk victory.

VN:F [1.8.4_1055]
Rating: 0 (from 0 votes)
3Oct/070

Keeping servers and workstations on time using cron and ntpdate

I'm a fan of having all my computers report the same time, especially when I have to cross reference logs on different servers and require the times to all match up.

I've used rdate to update time in the past, but lately have been using ntpdate, which seems to be quite a bit better.

One of the easiest ways to keep a system up to date is to put ntpdate in a cron job, via root's crontab:

Add the following to crontab via `crontab -e`

1 2,10 * * * /usr/sbin/ntpdate {0,1,2,3}.pool.ntp.org >/dev/null 2>&1

Here I have the cron running at 2:01 and 10:01, quite randomly picked times to run it. I'd suggest once a day or twice a day, please change the time to whatever suits you best.

I've got ntpdate running off of any one of the pool.ntp.org servers. Using the {0,1,2,3}.pool.ntp.org here allows for this to expand using any one of those servers, 0.pool.ntp.org etc. By the very nature of the pool.ntp.org addresses, they already represent a large pool of servers, so you can just choose one that suits you best. The pool servers also include continent and country specific pools of servers to use.

If you require ntpdate to update a bit quicker, you can always tune the -t (timeout) and -p (samples) settings accordingly. A setting of -p 1 will just have ntpdate get a single sample from the server to use as the time. These shouldn't really be used typically, but are useful if you run into problems.

I had a system with a broken i8254 timer chip which caused the system to not keep correct time, and also have a major CPU slowdown. It was an odd problem to have, but a script in crontab to run ntpdate on different servers using only a single sample of -p 1 allowed the system to have the proper time (a very temporary band-aid solution).

-p samples

Specify the number of samples to be acquired from each server as
the integer samples, with values from 1 to 8 inclusive. The
default is 4.

-t timeout

Specify the maximum time waiting for a server response as the
value timeout, in seconds and fraction. The value is rounded to
a multiple of 0.2 seconds. The default is 1 second, a value
suitable for polling across a LAN.

For futher reading:
http://www.ntp.org/
NTP Pool timeserver lists:
http://support.ntp.org/bin/view/Servers/NTPPoolServers

VN:F [1.8.4_1055]
Rating: 0 (from 0 votes)
Tagged as: , , No Comments
4Apr/070

FreeBSD pkgdb.db error

What happens with FreeBSD pkg and ports ends up with a corrupted database?

This happens from time to time, here's how it was solved:

# pkgdb -F
---> Checking the package registry database
[Updating the pkgdb in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument; rebuild needed] [Rebuilding the pkgdb in /var/db/pkg ... /var/db/pkg/pkgdb.db: unexpected file type or format -- Invalid argument: Cannot update the pkgdb!]: Cannot update the pkgdb!]

To fix this, remove /var/db/pkgdb.db and then run:

pkgdb -aF

# pkgdb -aF
---> Checking the package registry database
[Rebuilding the pkgdb in /var/db/pkg ... - 40 packages found (-0 +40) ........................................ done]
Stale dependency: portaudit-0.5.11 -> pkg_install-devel-20040811 (ports-mgmt/pkg_install-devel):
[/usr/ports/INDEX-5.db: unexpected file type or format -- Invalid argument] [Updating the portsdb in /usr/ports ... - 16801 port entries found /usr/ports/INDEX-5.db: unexpected file type or format -- Invalid argument: Cannot update the portsdb! (/usr/ports/INDEX-5.db)]
database file error

Now we've got a ports db error, remove the /usr/ports/INDEX-5.db file, and run:

portsdb -F -u

# portsdb -F -u
Receiving /usr/ports/INDEX-5.bz2 (921511 bytes): 100%
921511 bytes transferred in 3.0 seconds (296.37 kBps)
done
[Updating the portsdb in /usr/ports ... - 16817 port entries found .........1000.........2000.........3000.........4000.........5000.........6000.........7000.........8000.........9000.........10000.........11000.........12000.........13000.........14000.........15000.........16000........ ..... done]

Now all should work. Optionally:

Check for lost dependencies within installed ports:

pkgdb -L

And can fix up dependencies with:

pkgdb -F

VN:F [1.8.4_1055]
Rating: 0 (from 0 votes)
Tagged as: , No Comments