Reconfigure Apache after failed php-update

I've tried to use a manuall upgrade to php 5.4 using Debian squeeze. After not achieving what I wanted I moved back to php 5.3.

Now the webserver does not seem to honor the linux user and group - if a webuser (the linux user) tries to write into a cache folder (within a webfolder) I get a "not writable" exception. Setting the cache folder to 777 (just for testing purposes) worked.

How can I reconfigure apache / php to (re)honor ispconfigs security policy on web-folder owners?

Any help is welcome.

Edit:
If I change the owner of the cache folder to www-data it works fine.

 

Thanks for your fast reply.

Yep - I will do that, thanks for the link.

But how can I get the server back on track or where shall I start? Do you have a hint here? This is a production environment and reinstallation is not an option.

I know I've been stupid - but somehow I've to pick up the pieces...

 

During the installation of ispconfig there is a section where services are configured. Would a reconfiguration of Apache help in this case? What is happening during the reconfiguration process? Would it make sense to dig out those steps from the update / installation routine and run them manually?

 

Thanks for your reply.

So would the approach rather be to apt-get --purge remove around and reinstall the php packages?

PHP as actually running and the pages are displayed correctly but the web-folder user resp. the owner of the webfolder is not honored. So I've the feeling that something is wrong with the apache configuration or am I misled here?

 

Thanks again for your reply.

I reinstalled around a bit with no success. So purging would be the next step I guess. A good guess for the packages that should be reinstalled and/or purged is probably the installation guide (perfect server).

So you think that a reconfiguration of apache from the ispconfig setup won't be the solution here?

 

I've tried to --reinstall and purge the packages but the problem remains. I've als ran the new ISPConfig update which also did not fix the problem. Would the next step be to purge the apache?

Run commands:

Code:

apt-get --purge remove php5-suhosin libapache2-mod-php5 php5-cli php5-cgi php5-mysql php5-mcrypt php5-imap php5-gd php5-curl php5-imagick php5-sybase php5-common php-pear php5 php-auth apache2-suexec phpmyadmin libapache2-mod-fcgid apache2-suexec

apt-get install php5-suhosin libapache2-mod-php5 php5-cli php5-cgi php5-mysql php5-mcrypt php5-imap php5-gd php5-curl php5-imagick php5-sybase php5-common php-pear php5 php-auth apache2-suexec phpmyadmin libapache2-mod-fcgid apache2-suexec

 

Have you checked suexec is still enabled?

Code:

a2enmod suexec
service apache2 restart

 

Hey - thanks for your reply.

Jep - I've checked that. It's already enabled.

So do you think it has something to do with the suexec module?

 

Have you tried setting the php mode of the web to modphp and then back to fastcgi (or suphp or whatever you used)?
Double check the checkbox "SuExec" is enabled for the web, too.

 

Thanks for your reply.

Sadly it's not just one web but around a hundred. But yes I've tried that (after your remark) with no success.

 

Could you try creating an info.php in one of those webs with

PHP:

<?php
phpinfo();
?>

There you can check which php mode is used in the web and what modules are enabled.

 

(Partial) output of phpinfo():

Code:

[B]Hostname:Port	<affected.domain>:0[/B]
[B]User/Group	www-data(33)/33[/B]

Virtual Server	Yes

Server Root	/etc/apache2

Loaded Modules:	core mod_log_config mod_logio prefork http_core mod_so mod_actions mod_alias mod_auth_basic mod_auth_digest mod_authn_file mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cgi mod_dav mod_dav_fs mod_dav_svn mod_authz_svn mod_deflate mod_dir mod_env mod_expires mod_fcgid mod_headers mod_include mod_mime mod_evasive20 mod_negotiation mod_perl mod_php5 mod_proxy mod_proxy_http mod_python mod_reqtimeout mod_rewrite mod_ruby mod_setenvif mod_ssl mod_status mod_suexec

I was wondering about two things:
1. Port 0? Shouldn't that be port 80?
2. User/Group: Shouldn't this be clientXY:webXX?

The mode can be seen within the value Server API right?
This says: Server API Apache 2.0 Handler

Are those settings correct?

 

Okay, so this is the point.
Your webs run in apache mod_php and not in fastcgi/fpm/cgi etc.
So it always runs with www-data (you cannot change this with mod_php).
The question is: Why do your webs run with mod_php? From your posts I read you set it to something else in website settings.
Could you post the vhost file of one of the non-working webs?

 

It seems to me that the entire server is running a wrong php mode - or am I wrong here? However - here is the vhost fiel of one of the affected webs.

Code:

<Directory /var/www/<affected domain>>
		AllowOverride None
				Order Deny,Allow
		Deny from all
		</Directory>

<VirtualHost *:80>
		DocumentRoot /var/www/clients/client31/web179/web

		ServerName <affected domain>
		ServerAdmin webmaster@<affected domain>

		ErrorLog /var/log/ispconfig/httpd/<affected domain>/error.log

		Alias /error/ "/var/www/<affected domain>/web/error/"
		ErrorDocument 400 /error/400.html
		ErrorDocument 401 /error/401.html
		ErrorDocument 403 /error/403.html
		ErrorDocument 404 /error/404.html
		ErrorDocument 405 /error/405.html
		ErrorDocument 500 /error/500.html
		ErrorDocument 502 /error/502.html
		ErrorDocument 503 /error/503.html

		<IfModule mod_ssl.c>
		</IfModule>

		<Directory /var/www/<affected domain>/web>
				Options +FollowSymLinks
				AllowOverride All
								Order allow,deny
				Allow from all
						</Directory>
		<Directory /var/www/clients/client31/web179/web>
				Options +FollowSymLinks
				AllowOverride All
								Order allow,deny
				Allow from all
						</Directory>




		# suexec enabled
		<IfModule mod_suexec.c>
			SuexecUserGroup web179 client31
		</IfModule>
		# Clear PHP settings of this website
		<FilesMatch ".+\.ph(p[345]?|t|tml)$">
				SetHandler None
		</FilesMatch>
		# suphp enabled
		<Directory /var/www/clients/client31/web179/web>
		<IfModule mod_suphp.c>
			suPHP_Engine on
			# suPHP_UserGroup web179 client31
	suPHP_ConfigPath /var/www/conf/web179
			<FilesMatch "\.php[345]?$">
				SetHandler x-httpd-suphp
			</FilesMatch>
			suPHP_AddHandler x-httpd-suphp
		</IfModule>
		</Directory>


		# add support for apache mpm_itk
		<IfModule mpm_itk_module>
			AssignUserId web179 client31
		</IfModule>

		<IfModule mod_dav_fs.c>
		# Do not execute PHP files in webdav directory
			<Directory /var/www/clients/client31/web179/webdav>
				<ifModule mod_security2.c>
					SecRuleRemoveById 960015
					SecRuleRemoveById 960032
				</ifModule>
				<FilesMatch "\.ph(p3?|tml)$">
					SetHandler None
				</FilesMatch>
			</Directory>
			DavLockDB /var/www/clients/client31/web179/tmp/DavLock
			# DO NOT REMOVE THE COMMENTS!
			# IF YOU REMOVE THEM, WEBDAV WILL NOT WORK ANYMORE!
      # WEBDAV BEGIN
			# WEBDAV END
		</IfModule>

</VirtualHost>

 

Okay. So you are using suphp.
Have you tried fastCGI mode?
Have you checked suphp module is active?
a2enmod suphp

 

Well... ok obviously suPHP was not installed so that's why it kept falling back to modPHP. But it seems suPHP is not configured correctly - entry from a suPHP enabled site:

Code:

[Sat Apr 26 17:05:07 2014] [error] [client **] SecurityException in Application.cpp:496: Handler not found in configuration
[Sat Apr 26 17:05:07 2014] [error] [client **] Caused by KeyNotFoundException in Configuration.cpp:234: Handler "x-httpd-suphp" not found
[Sat Apr 26 17:05:07 2014] [error] [client **] Premature end of script headers: index.php

I found some posts adding a file handler manually to vhost files but that can't be the solution. How can I solve that?

Edit:
Found a post.

I had to add in /etc/suphp/suphp.conf:

[handlers]
;Handler for php-scripts
application/x-httpd-suphp="php:/usr/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi="execute:!self"
x-httpd-suphp="php:/usr/bin/php-cgi"

Thanks a lot for your help!