I am currently using Interworx on my server and I am having difficulty in getting mod_suphp setup. It loads (or I think it does) but the scripts are not being interpreted at all. I just get back the contents of the file. I’ve tried to install 0.6.2 from source and 0.5.2 from the rpm binary for centos 4.x. I’m going to try the 0.6.0 srpm but I don’t expect it to work any better.
I used the following commandline to install 0.6.1 from source.
At the moment it is actually uninstalled and I am making another attempt on working with mod_php but I would like to have mod_suphp installed and working for when I add other people to the server.
Oh and this same exact issue came up after I installed the suphp 0.6.0 SRPM on updates.interworx.com.
It all built fine but doesn’t seem to work at all.
I commented out the entire contents of php.conf when I was trying to run mod_suphp which follows here.
#
# PHP is an HTML-embedded scripting language which attempts to make it
# easy for developers to write dynamically generated webpages.
#
LoadModule php4_module modules/libphp4.so
#
# Cause the PHP interpreter to handle files with a .php extension.
#
AddType application/x-httpd-php .php
#
# Add index.php to the list of files that will be served as directory
# indexes.
#
DirectoryIndex index.php
Finally. I got it to work. I was using the IfModule brackets but thinking that they may be causing an issue I just commented out the mod_php specific directives and removed all the IfModule brackets from the configs then restarted apache. Now it works perfectly. Thanks for your help!
Now then how can I make it so that future accounts that are created use these settings instead of setting up mod_php (which isn’t even being loaded anymore imo).
Unfortunately, right now, there isn’t a way to automate the addition of these directives. New accounts will have to be modified manually, as they are created.
You could put some of the suPHP directives in the vhost conf, but directives that are specific to the account can not be put in the vhost-base.conf file. For example, the following two lines:
I looked at the code that does the vhost-base.conf translation, and it turns out we do actually allow more variables to be dynamically replaced. Here a few of the more useful variables
<<IP_ADDR>> - ip address of the siteworx account
<<UNIQNAME>> - username of siteworx account
<<WEBROOT>> - webroot of account ( /home/username/domain.com/html )
<<PACKROOT>> - package root of account (/home/username)
<<DOMAIN>> - domain
So, you’d want to make your vhost-base.conf look like this:
<VirtualHost <<IP_ADDR>>:<<PORT>>>
<<SUEXEC>>
DocumentRoot <<WEBROOT>>
ServerName <<DOMAIN>>
ServerAlias <<ALIASES>>
ServerAdmin webmaster@<<DOMAIN>>
# subdomain logic
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_HOST} !^www\.<<ESCDOMAIN>> [NC]
RewriteCond %{HTTP_HOST} !^<<ESCDOMAIN>> [NC]
RewriteCond %{HTTP_HOST} ^([A-Z0-9a-z-]+)\.<<ESCDOMAIN>> [NC]
RewriteCond %{DOCUMENT_ROOT}/%1 -d
RewriteRule ^(.+) %{HTTP_HOST}/$1 [C]
RewriteRule ^([0-9A-Za-z-]+)\.<<ESCDOMAIN>>/?(.*)$ %{DOCUMENT_ROOT}/$1/$2 [L]
# end subdomain logic
ErrorLog <<ERRORLOG>>
CustomLog <<XFERLOG>> combined
AddType application/x-httpd-php .php
AddHandler x-httpd-php .php
suPHP_Engine on
suPHP_UserGroup <<UNIQNAME>> <<UNIQNAME>>
suPHP_ConfigPath <<PACKROOT>>
php_admin_flag engine off
php_admin_flag engine On
# cgi: <<CGISTATUS>> don't edit between this and the "end cgi" comment below
<Directory <<WEBROOT>>>
suPHP_AddHandler x-httpd-php .php
<<CGI1>>
</Directory>
<<CGI2>>
# end cgi
</VirtualHost>
That should work. Also, note that “suPHP_ConfigPath” can be set to pretty much any path, as this is the path to where the php.ini resides. So you could set it to:
instead of setting it to <<PACKROOT>> like I did above. I would just strongly urge you to not set the config path to a public accessible location (like <<WEBROOT>>), otherwise people may be able to read your php.ini file.
No pbm Socheat. One time Chris gave me few others variables but I didn’t know there were all these ones
DOC DOC is need !!!
If All these configs could be set in the control panel it could be great. You like an admin/setup which allow to define/rewrite some entries in the iworx.ini and could be set other kind of things like :
define the vhost-conf
define the look of suspend web page
define the contents of mail alert
etc…
My pbm now is every time there is a majour release I lost my vhost-conf file :
If you could externalise this or define it contents in DataBase and front admin in the panel it would allow to always have the same custom config/setup
instead of setting it to <<PACKROOT>> like I did above. I would just strongly urge you to not set the config path to a public accessible location (like <<WEBROOT>>), otherwise people may be able to read your php.ini file.
the php.ini is not in /etc/php.ini ?? or is it suPHP which create or need a php.ini for every accounts ?
arff so the creation process of a new account with the use of suPHP can’t be fully automate as you’ll always have to copy/create a php.ini file somewhere
If All these configs could be set in the control panel it could be great. You like an admin/setup which allow to define/rewrite some entries in the iworx.ini and could be set other kind of things like :
define the vhost-conf
define the look of suspend web page
define the contents of mail alert
etc…
My pbm now is every time there is a majour release I lost my vhost-conf file :
If you could externalise this or define it contents in DataBase and front admin in the panel it would allow to always have the same custom config/setup
I’m sure this is coming eventually but we’ll have to see how high it ends up on the list of priorities of the devs. In the mantime I’d suggest just keeping copies of your vhost.conf as vhost-conf-custom and/or keep a local copy.
Actually I don’t believe that suPHP_ConfigPath has to be defined in the conf files at all. I think if it is left undefined then php will look at the compiled in path which happens to be /etc/php.ini anyways. suPHP_ConfigPath can be setup in a users htaccess file so if you wanted to you could make the user aware of it and they can manage their own file. It is an interesting thing though because then they can manage multiple php.ini files for various parts of their site.
To effectively do that idea though you need to build a version of php that has most of its modules as shared so they can be loaded dynamically (like how apache is now). The php that is setup with interworx has nearly all of its modules compiled in.
Just to be sure to understand well, as I didn’t read the suPHP doc and I’m not a user of this, with suPHP, PHP is running as CGI or suPHP might use the Apache PHP module ?
I ask this because I was thinking about a solution we may do.
The solution would be to compile a new PHP5 version and propose to our user to use both php4 and php5 on the same box. Php4 will be used as an Apache module and PHP5 will be used as CGI with the use of suPHP
It should be possible, no ?
is some of you already configure this ? or configure on the same box a PHP4 as module and a PHP5 as CGI ?
Any howto ? web pointer ?
Could we use the iworx php5 srpm to have a base and be able to change the way it is compiled ?
suPHP 0.6.0 has been released.
For this release suPHP has been completely rewritten. This in an (incomplete) list of only the most important changes:
Complete code rewritten now using C++ instead of C
Automake based build system
suPHP is now reading its runtime configuration from a file
Apache 1.3 module completely rewritten - now all modes are supported with Apache 1.3, too Support for concurrent use of different PHP version (e.g. 3, 4, 5)
Which is exactly what I was looking for
I thought run php4 as module and php5 as CGI but if suPHP can run both !!!
Seems interesting, but wouldn’t you still have to run one of the PHPs as a module and one as a CGI wether or not you use suPHP for both?
Or does suPHP actually provide a gateway between apache and PHP where there is NO PHP4 mod and PHP5 mod in apache, just the suPHP mod which then independant of apache uses PHP4 or PHP5???
When i get some more time Im gonna look into it or maybe I’ll just wait and see what you find out
edit
Found this, looks outdated, but maybe the right .idea.
Requests to files ending with .php, .php3, .php4 or .phtml should be handled by PHP4 CGI (this can be easily changed). Create a /etc/apache2/modules.d/php4-cgi.conf, which will be included by httpd.conf automatically:
Requests to files ending with .php5 should be handled by PHP5 CGI (this can be easily changed). Create a /etc/apache2/modules.d/php5-cgi.conf, which will be included by httpd.conf automatically:
