Replaced the original mod_suphp.so in the package with the customized version.

Adjusted several directives in the package control file:

Changed package name

Added dependency apache2-prefork-dev

Added conflict libapache2-mod-suphp

Adjusted Installed-Size

Added an additional README.

Updated the md5 values.

Created the package.

I now have a package that installs with dpkg -i. Doing so with libapache2-mod-suphp already installed or without apache2-prefork-dev (or any of the other dependencies like suphp-common) available, aborts the installation with an appropriate message. In the latter case, apt-get -f install is enough to have the missing packages installed.

On the surface everything seems o.k. The only problem is that my php websites don't work. They all show the familiar "500 error - Internal Server Error!". Adding the neccessary Apache Directives for a site, makes it appear again.

Can anyone assist me in troubleshooting this problem? I have far too little experience to do that all by myself. Ofcourse the package will be made available to the ISPConfig community as soon all the problems have been solved.

At least one thing is quite strange: there is no suPHP log file. My /etc/suphp/suphp.conf reads: logfile=/var/log/suphp/suphp.log and loglevel=info. The /var/log/suphp directory is there, but it's empty. So it appears that the mod_suphp module is never activated.

When you install suphp, you should disable mod_php first. Then make sure that you enabled mod_suphp with the "a2enmod" command. When you get a 500 error, look in the error log of the website where you got the error and post the error message.

Because Hans' howto first disables mod_php but in the end of the article enables it again to support suPHP incompatible applications (which is what I need too), I thought it wouldn't be neccessary to disable it in the first place, so I didn't. Also I expected the Debian package to enable mod_suphp automagically when installing the package, so I didn't do that either.

I did a fresh installation and this time I first disabled mod_php. After installing the package, I explicitly tried to enable mod_suphp, but got the message: 'This module is already enabled!'. So once again all looks well. Unfortunately it still doesn't work. A simple phpinfo script results in the 500 error (the file permissions of the script are 644).

I can't find any related error messages in the apache the log files. I also still don't have a suphp log file. When you say 'the error log of the website', which log file do you mean exactly?

Thanks Hans (and Till). Inspecting the log file did the trick (I didn't know it existed until now ) because it showed that mod_suphp was looking in the wrong place for the suphp executable. By default mod_suphp looks in /usr/sbin. However, on Debian suphp is installed in directory /usr/lib/suphp by default. Adding the extra option '--sbindir=/usr/lib/suphp' to the configure command of Hans' howto, solved that problem.

So it finally appears to work. I didn't do any intensive testing yet, but my phpinfo script and Roundcube site show regular web pages instead of an annoying 500 error.

There are still some minor issues to deal with though. An important one is the /etc/suphp/suphp.conf file. This file is part of the Debian suphp-common packge, but it differs from the one Hans uses in his howto and that's the one that appears to work fine with ISPConfig, so I would like to include it in the custom mod_suphp package. However, when I do that, I get an error message and installation of my package aborts. Unfortunately I didn't write down the exact message, but it had something to do with the fact that you can not just overwrite a configuration file that originally came with another package. I don't know how to solve that, so I hope someone can give me a few pointers how it should be done in a proper manner. Can you be of any assistance there as well Till?

Once I solved the last few issues, I'll post my custom package in the forum and maybe even write a small howto on how to use it. It will probably be sort of a short version of Hans' howto

At this moment I can't spare the time to set up my own package repository, but if anyone already has one and would like to offer this package from that repository, I would like that very much. Installing the package with aptitude from a repository is much more user friendly than using dpkg because it takes care of all the dependencies.

Package: obix-ispconfig-libapache2-mod-suphp
Version: 0.6.2-1
Section: web
Priority: optional
Architecture: i386
Depends: libc6 (>= 2.3.6-6), suphp-common (= 0.6.2-1), apache2.2-common, apache2
-prefork-dev
Conflicts: libapache2-mod-suphp
Installed-Size: 120
Maintainer: Pieter-Jan de Vries ([email protected])
Source: suphp
Description: Apache2 module to run php scripts with the owner permissions
With the use of the suphp setuid root binary (from suphp-common package),
this Apache2 module change the uid of the process executing the PHP
interpreter to the owner of the php script.
This package is a modified version of the the stable Debian package with
the same version number, to make it work effortless with ISPConfig
(see usr/share/doc/libapache2-mod-suphp/README.obix).​

Thanks Falko. I guessed that much but I don't know the proper way to solve it. Because my custom package is nothing more than a customised Debian libapache2-mod-suphp package, it needs to depend on exactly the same packages as the original Debian package. suphp-common is one of them.

I assume there is a standard way to handel such a situation, but thusfar I haven't been able to figure out what it is. Obviously I could just make a custom package of suphp-common with a modified /etc/suphp/suphp.conf, but I think there must be a cleaner way to handle these kind of situations.

After a bit of extra digging, I found a way to resolve this issue. Adding the "Replaces: suphp-common" directive to the package control file, makes dpkg overwrite the existing /etc/suphp/suphp.conf file without complaining.

So here it is, a customized libapache2-mod-suphp package (see attachment), modified to work with ISPConfig. You apply it as follows:

backup /etc/apache2/vhosts/Vhosts_ispconfig.conf

if you don't need the regular php5 module anymore:

a2dismod php5

remove all php_admin entries from /etc/apache2/vhosts/Vhosts_ispconfig.conf

make a small modification to one of your websites to force ISPConfig to write a new /etc/apache2/vhosts/Vhosts_ispconfig.conf file

This package has been tested on a server running Debian Etch, ISPConfig 2.2.14, PHP 5.2.0-8 and Apache 2.2.3. I assume if you edit /etc/suphp/suphp.php and change x-httpd-php=php:/usr/bin/php5-cgi into x-httpd-php=php:/usr/bin/php-cgi it will work with either php4 or php5 but I haven't tested that myself.

Beware!!! I'm not an experienced Debian developer and and this is my first package which hasn't been extensively tested yet, nor has the resulting suphp installation. Usage is at your own risk but any feed back and suggestions for improvements are very much appreciated.

I am considering installing suPHP on my Debian server, but since I had some issues before when I had suPHP installed on an OpenSuse system, I am a little reluctant to do so (especially since I am by no means an expert on administration yet).

So my question is: supposed I encounter problems when suPHP is running, how easy is it to remove it and restore the previous configuration alltogether? If you have the time, I would really appreaciate if you could explain how a deinstallation of your package could be performed.

As I explained, I'm not an experienced Debian developer. I am also not an experienced administrator. I tried to keep the package as standard as possible though and by using the original Debian libapache2-mod-suphp package as a starting point, I think I may have succeeded. As a result, uninstalling should be as straigth forward as: dpkg --remove (or --purge) obix-ispconfig-libapache2-mod-suphp_0.6.2-1_i386. The command dpkg --help will give you more information.

Ok, I made my own Debian package by using your package as a basis and replacing the mod_suphp - file with one I compiled on my system.

Then I followed the steps mentioned in one of your previous posts. The installation of my package seemed to work flawless, however, suPHP wasn't running obviously... whenever I tried to access a PHP-page, it was simply offered as a download by the server.

Also, the Vhosts_ispconfig.conf file did not show any new entries mentioning suPHP.

I am a little lost now, since I followed every single step of the instruction... Any idea what might be wrong?

Update: Tried it yet again. The Vhosts_ispconfig.conf now features the suPHP-Entries. However, when I know try to open a PHP website, I get an Internal Server Error (500).