Finally got a webserver running with PHP and suPHP. This took me a lot longer then I expected and reminded me of the old days of reading complicated documentation along with crazy errors. In the end, I did get everything working. As usual the following is what I did from an instructional point of view. This was done using FreeBSD 7.2, so things might be slightly different depending on the distribution being used.

To get Apache go here:

http://httpd.apache.org/

For PHP, go here:

http://www.php.net/

And to get suPHP go here:

http://www.suphp.org

As a bit of explanation, Apache is a free web-server that powers a lot of the Internet. PHP is a nice scripting language that can be used to do a lot. It can interface with MySQL, hence why I spend time getting that configured. Also, I do believe some of the addons I plan on working with will require both PHP and MySQL. The last is suPHP which is for securing the PHP scripts. It does this by making the scripts run as the user trying to run them. For the most part, I probably could have avoiding using suPHP since I may only run a few personal websites, but I was curious about it and it does seem to add another layer of security.

One of the bigger problems I had concerned compiling suPHP. It kept saying that it couldn’t find apxs, even though the suPHP configure command asks for the path to apxs. In the end installing Perl resolved that issue.

So the first two things that should be done is install the following from the FreeBSD Ports collection:

- libxml2
- Perl 5.x or later

I had to log off and then log back in after installing Perl to get suPHP to compile right, but I’m not sure if that is what really resolved my problem.

Create a new user and group called apache by doing the following:

pw groupadd apache
pw useradd apache -c “Apache Server” -d /dev/null -g apache -s /sbin/nologin

The first piece of software I installed was Apache and used the following configure options:

./configure –prefix=/usr/local/apache22 \
–with-perl \
–enable-so \
–enable-cache \
–enable-disk-cache \
–enable-rewrite \
–enable-usertrack

Do a make and make install. You can install Apache anywhere, I just chose apache22 to remind myself roughly what version I had.

The next piece is PHP and I used the following configure options:

./configure \
–prefix=/usr/local/php \
–with-mysql=/usr/local/mysql \
–with-config-file-path=/etc \
–enable-cgi \
–enable-force-cgi-redirect \
–enable-mbstring \
–without-sqlite \
–with-mysql-sock=/tmp/mysql

Then do a make, make test and make install.

The last step is suPHP and these are the configure options I used:

./configure –prefix=/usr/local \
–with-apache-user=apache \
–with-apr=/usr/local/apache22/bin \
–with-logfile=/var/log/suphp.log \
–with-apxs=/usr/local/apache22/bin/apxs \
–with-min-uid=500 \
–with-min-gid=500

Do a make and make install. With luck everything should have configured.

Here is the configuration that is placed in my /usr/local/apache22/conf directory:

http://projectesxi.wordpress.com/files/2009/12/httpdconf.pdf

For the PHP.ini file, I just copied the “php.ini-production” version from the src directory to the /etc directory. I may come back later and edit the file, but for now it is working.

For the suphp.conf file, I used the following and placed it into the /etc directory:

http://projectesxi.wordpress.com/files/2009/12/suphp_conf.pdf

With any luck running this command should get your Apache server going:

/usr/local/apache22/bin/apachectl start

With luck if you go to your server IP address you should get a page.

The permissions to your public_html should be “701″. The rest of the permissions in the public_html should be 604. I did have an issue serving up my images directory so I had to set that directory permission to 701.

The only other thing I did was create a start-up script and add it to /usr/local/etc/rc.d with the following contents:

#!/bin/sh
/usr/local/apache22/bin/apachectl start

If you run into any problems, then /usr/local/apache22/logs are your friend.

• DSO — Provides PHP through libphp4.so or libphp5.so (aka, mod_php). This option is usually the fastest way to execute PHP requests; however, this option uses the system user called “nobody” to serve all PHP requests. It is also important to note that if you wish to use both versions of PHP via DSO, you must apply the concurrent DSO patch at build time.
• suPHP — Provides PHP through mod_suphp. Using this option is probably the most flexible way of serving PHP requests and is generally very secure. Under this option, PHP scripts will be executed by the user who owns the VirtualHost serving the request.
• FCGI — This option serves PHP through mod_fcgid. This is a fast way of serving PHP requests but will most likely require that you tweak php.conf. You can enable suEXEC to execute PHP scripts under the user who owns the VirtualHost that is serving the request or, if suEXEC is disabled, PHP will be served by the system user “nobody.”
  • Important: This method is only recommended for advanced administrators who understand how to tune the performance of mod_fcgid. UserDir requests will not function correctly with the basic mod_fcgid setup.
• CGI — This option provides PHP through mod_cgi or mod_cgid. Using this option, you can enable suEXEC so that PHP scripts will be executed as the user who owns the VirtualHost that is serving the request. If suEXEC is disabled, the system user “nobody” will execute PHP scripts. UserDir requests will not function properly with the setup provided by cPanel.
  • This option is only intended as a fallback for when DSO or suPHP is not available. Serving PHP as CGI is not especially fast or secure, even if suEXEC is enabled.

After installing suPHP and before changing the PHP handler from your default one to suPHP, there are a few configuration options that need to be checked.

1) Check if the suPHP module is correctly loaded in the Apache configuration file.

# LoadModule suphp_module libexec/mod_suphp.so

2) Run the below scripts to double check the server settings:

# /scripts/postsuexecinstall

# /scripts/chownpublichtmls

3) Lets check the permissions now.

If there are files with either 777 or 666 permission inside the document root, you are most likely to get Internal Server Errors.

find /home/*/public_html/ -perm 777 -exec ls {} \;
find /home/*/public_html/ -perm 777 -exec ls {} \;

Set 755 and 644 respectively, for the files that gets listed in the above command.

4) Check the CGI scripts as well

# /scripts/fixsuexeccgiscripts

5) Last but not the least, make sure that there are no php_flags in the domain’s .htaccess file.

# grep -iRl php /home/*/public_html/.htaccess

If you want to use php flags for the domains, create a custom php.ini file and place it in the domain’s web root.

Com o Php em modo suPHP basta criar um arquivo php.ini na árvore de diretório do cliente com o seguinte teor:

register_globals = On