PDA

View Full Version : NEW ERROR: RewriteEngine not allowed here


gkovacs
17th April 2009, 16:44
I have a couple of Joomla sites that have been using a .htaccess based URL rewrite, running under ISPConfig 3. Recently these sites stopped working if the following .htaccess file is in place:

RewriteEngine On
DirectoryIndex index.php
RewriteBase /

RewriteCond %{REQUEST_URI} ^(/component/option,com) [NC,OR]
RewriteCond %{REQUEST_URI} (/|\.htm|\.php|\.html|/[^.]*)$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php

The site throws an Internal Server Error, and puts this in the error.log:
.../web/.htaccess: RewriteEngine not allowed here

The same thing happens if I put this .htaccess file in an empty folder and try to open it in a browser.

I've updated ISPConfig to 3.0.1 a couple of days ago, but nothing has been changed since, and this error only started to happen today.
What could have gone wrong?

gkovacs
18th April 2009, 13:20
Since yesterday, more sites using mod_rewrite in a .htaccess have stopped working.

I have nailed down the problem. If this is present in a site's vhost file, mod_rewrite stops working:


<Directory /var/www/XXX.hu/web>
Options FollowSymLinks
AllowOverride Indexes AuthConfig Limit
Order allow,deny
Allow from all
</Directory>


If I manually change it to


<Directory /var/www/XXX.hu/web>
Options All
AllowOverride All
Order allow,deny
Allow from all
</Directory>


then it works. However, ISPConfig restores the previous state at any modification I do, so there is currently no way to leave these sites in a working state.

falko
18th April 2009, 15:18
You can try to add your custom directives to the Apache Directives field on the Options tab of that web site in ISPConfig.

gkovacs
18th April 2009, 15:58
I can try, but it will surely not work. If I add these two lines in the options, Apache fails to restart and rejects this config:

root@ispconfig:/var/clients/clientXXX/XXX.hu/web# /etc/init.d/apache2 reload
Syntax error on line 45 of /etc/apache2/sites-enabled/XXX.hu.vhost:
AllowOverride not allowed here
...fail!

So I'm not sure what I'm supposed to add.

But more importantly, do you have any idea why the latest ISPConfig fux up the vhosts files so no one is able to use mod_rewrite anymore?

falko
19th April 2009, 16:03
You must add this inside <Directory></Directory> directives.

mgibson
19th April 2009, 19:52
Falko,

I'm also having similar issues to gkovacs.

Falko, in your response to "You can try to add your custom directives to the Apache Directives field on the Options tab of that web site in ISPConfig. "

Is there a way to add these in as default so we dont have to add custom directives. If so, which file do we need to edit?

Kind Regards,

Mark.

falko
20th April 2009, 12:00
Is there a way to add these in as default so we dont have to add custom directives. If so, which file do we need to edit?

No, that's not possible.

mgibson
20th April 2009, 12:20
Not possible at all? Or can be possible with a bit of work? :)

I'm sure alot of ispconfig3 users would appreciate this feature when running CMS such as Drupal or Joomla.

ISPConfig3 has to be writing the directives into the vhost somewhere...

Regards,

Mark.

gkovacs
20th April 2009, 13:09
No, that's not possible.

You still didn't answer my question about how and why ISPConfig has changed regarding this matter. It seems to me that ISPConfig did allow mod_rewrite running out of the box, but since the latest update it does not.

1. Why did this change happen? (Just out of curiosity, I'm interested)

2. Why don't you (I presume you are a developer) acknowledge this change? (This seems to affect a lot of people, and will affect a lot more as soon as they modify their config and ISPConfig overwrites their vhost files, so we deserve a clarification)

3. Is it REALLY impossible to add a checkbox to the site config that allows mod_rewrite to run as it did before?

Mogi
20th April 2009, 13:28
No, that's not possible.

You have to be kidding.

ISPConfig has arbitrarily removed the ability to use rewrites?

Seriously?

Have you never heard of WordPress??

Dozens and dozens (and it will be hundreds soon enough) of WP blogs are going from working perfectly to 500 server error, just because you decided to *remove*the*ability*to*use*rewrites*??

*What* were you *thinking*?

Y'know, for the first time ever, I'm now lost for words.

The boxes are not yours that you can arbitrarily decide who can and who can't use rewrite in .htaccess.

When will this be fixed? I'm sick of being screamed at by WP users with broken sites.

gkovacs
20th April 2009, 13:43
You have to be kidding.

ISPConfig has arbitrarily removed the ability to use rewrites?

Seriously?


Chill dude. Let's wait for an answer, don't jump to conclusions.

Mogi
20th April 2009, 13:59
Chill dude. Let's wait for an answer, don't jump to conclusions.

Your right of course.

It's just that it is more than a little beyond my comprehension how or why such talented (and highly experienced) devs as these could have made a change of such epic proportions. I know next to nothing about code but even I would easily have forseen that change bringing sites down wholesale, which is exactly what it has done.

Bizarre.

Anyhow, just have to wait and see what they say.

mgibson
20th April 2009, 20:16
To be honest I agree with Mogi, rewrites is a *must* feature.
It would be a shame if it didnt have this function and as good as it is, users will stop using ispconfig3.

Falko help us out here :)

till
20th April 2009, 20:30
You can enable this in your vhost template if you want. So this is not a missing feature nor feature thing at all. To enable rewrites, you will have to alllow to allow overriding of file info which on the other hand enables your customers to widen their access restrictions on the server. As a software provider we will have to release a safe system as everyone will complian otherwise. If you dont need a secure system or it does not matter for you if users are able to get additional features without being activated in the site settings by putting them in a .htaccess file, feel free to give your users thiese permissions. Thats why ispconfig uses templates for config files, so everyone can customize the safe default settiongs to its needs.

mgibson
20th April 2009, 20:36
Hi Till, thanks for the response.

We can edit the vhost file manually with our directive AllowOverride All but.... when we come to ispconfig3 and configure a new site, it resets all the directives back to how they were originally hence all working wordpress, joomla or drupal sites getting an Error 500.

gkovacs is trying to say that this never used to happen. Since the latest update, it messes with rewrites.

gkovacs
20th April 2009, 20:36
Till, there is no problem with you guys releasing a safe software environment. Everyone here is grateful for ISPConfig, it's a great piece of software.

The problem lies in the fact that it seems you CHANGED the behaviour of ISPConfig silently in the last update, and many of our sites simply STOPPED working. And there is no easy workaround. Most of my clients right now are hosted without mod_rewrite, with Google Adwords turned off. I'm getting phonecalls around the clock.

In the previous version mod_rewrite worked out of the box, now it doesn't. There was no warning, I don't remember seeing it in the release notes, heck you guys aren't even acknowledging the change here, now.

Why should this be kept secret? Thousands of sites will fail in the coming weeks if people keep updating their systems. Hundreds of people will try to look for advice everywhere. Are you sure you guys are handling this in the best possible way?

till
20th April 2009, 20:43
The problem lies in the fact that it seems you CHANGED the behaviour of ISPConfig silently in the last update, and many of our sites simply STOPPED working. And there is no easy workaround. Most of my clients right now are hosted without mod_rewrite, with Goodle Adwords turned off. I'm getting phonecalls around the clock.

Nothing has been changed silently. You should read the release notes and the comments on fixed bugs as the behaviour has been chenged to fix a bug.

till
20th April 2009, 20:45
Hi Till, thanks for the response.

We can edit the vhost file manually with our directive AllowOverride All but.... when we come to ispconfig3 and configure a new site, it resets all the directives back to how they were originally hence all working wordpress, joomla or drupal sites getting an Error 500.

gkovacs is trying to say that this never used to happen. Since the latest update, it messes with rewrites.

Please read my post more closely. I told you to change the vhost template file and not the vhost file!

Mogi
20th April 2009, 21:07
You can enable this in your vhost template if you want. So this is not a missing feature nor feature thing at all.

Hello till,

Does ISPConfig 2 allow rewrites? If it does, are you planning to disable that in the next release/update?

Seriously, if you are, you may as well stop developing both of these tools right now, as fantastic (truly, they are fantastic) as they are, or rather were.

Just the single thing of breaking all of these thousands of WordPress sites, let alone all of the other scripts using rewrites, is enough to make ISPConfig a thing of the past in a very, very short space of time.

Just speaking for myself, even if you do reverse your decision on this rewrites thing (and I think you are going to have zero choice but find a way to fix this) how do we now know that something equally crazy won't be sprung on us in some other future update?

I think that you have made a really huge error here, and I don't think that you are helping by not dealing with this properly now either.

I mean, is that it? Your reaction to this is; 'it's not a missing feature'?

It sure is to hundreds of site owners, and it sure is going to be for hundreds and hundreds more in a short while, too.

till
20th April 2009, 21:18
We might enable this again in ispconfig 3 if it causes so many problems. And yes, it is not feature issue as this is a configuration questions which can be handled easily and individually by every administrator in his setup. ISPConfig uses templates for config files so that every admin can have its own and specific set of templates, this also enables administartors to use different security settings etc. which do not have to be the same then the ones we deliver with ispconfig. Your post shows that you are not aware what the exact issue is. The override option default has been changed because users requested this and not because I requested this. So your complain is that we have fixed a security issue due to user requests and you did not know it because you did not had read the release notes. So if it is populer demand we will turn it on again.

till
20th April 2009, 21:28
So, here the way to change the defaults, its really easy and I had posted this last week already but here for refernce again the step:

Edit the file:

/usr/local/ispconfig/server/conf/vhost.conf.master

and replace all lines (the lin exists 4 times in the file):

AllowOverride Indexes AuthConfig Limit

with:

AllowOverride Indexes AuthConfig Limit FileInfo

---
Update:fixed typo in path.

Mogi
20th April 2009, 21:48
The override option default has been changed because users requested this and not because I requested this. So your complain is that we have fixed a security issue due to user requests and you did not know it because you did not had read the release notes. So if it is populer demand we will turn it on again.

Hey till, thanks for the reply.

I figured that it would not be a decision a dev would make, I just think that your way of handling it was back to front (which is entirely your prerogative, obviously) - instead of disabling rewrite it might have been better to offer an option to disable it. As it is there are no options at all other than to renable one site at a time retroactively, which is no option in real life.

Anyhow, what is done is done. I appreciate the slight security risks of rewrite and understand your concerns as to not having problems from users who might suffer because it is there.

From this end of things, though, things look very different.

To satisfy both the pro and anti rewrite brigades, why not reenable it globally and then have some way of disabling it afterwards (i.e. locking the sites that need it down with it enabled on all of them in one click). Then afterwards make some option to enable it, as you and the antis want, on a per *new* site basis. The enabling per site option would have to be sticky though.

All non-trivial to do, I'm sure, but as ISPConfig 3 shows, you're in it for the long haul. So that kind of setup (options per site and global/ rewrites on or off/ all sticky) as non trivial as it might be for you to code into the script would pay didident in the long term.

Just my take on it.

Whatever you decide, I for one would really like to see it reenabled just for the immediate future anyway, if only to calm things down!

Also would like to say, despite all of the above and this present problem we are having, that ISPConfig 3 is excellent. Just the ultra-effective installation script is outstanding, let alone what the main script does once it starts work. Can't imagine the work that has gone into getting it this far, and kudos to you for that.

But just for now, please bring back the rewrites, before I and a lot of others get driven insane by broken sites. :)

Mogi
20th April 2009, 22:08
So, here the way to change the defaults, its really easy and I had posted this last week already but here for refernce again the step:

Edit the file:

/usr/local/ispconfig/server/conf/vhsot.conf.master

and replace all lines (the lin exists 4 times in the file):

AllowOverride Indexes AuthConfig Limit

with:

AllowOverride Indexes AuthConfig Limit FileInfo

Thank very much indeed, till.

till
20th April 2009, 22:14
I added this to the bugtracker. I posted above the information on how to enable and keep this setting in your configuration.

The security problem is not the rewrite engine itself (even if wrong rewrite rules may cause different problems too), so what we did is not disabling rewrite in the first line, the problem is that the rewrite engine is coupled to the FileInfo option and fileinfo allows also to enable scripting in websites were scripting is disallowed by e.g. adding AddType.... statements or filters to a .htaccess file.

For more information, take a look here what fileinfo enables:

http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride

(as a personal side note, the apache documentation does not even mention that mod_rewrite depends on fileinfo)

There is no real solution for this so I will enable overriding of FileInfo again by default and write a note in the documentation that this will impose the risk that poeple with websites without scripting rights can enable them theirself by .htaccess file if the default configuration is not changed. Later version it might be an option to add a field in the site settings to set the override options individually per site.

mgibson
20th April 2009, 22:29
So, here the way to change the defaults, its really easy and I had posted this last week already but here for refernce again the step:

Edit the file:

/usr/local/ispconfig/server/conf/vhost.conf.master

and replace all lines (the lin exists 4 times in the file):

AllowOverride Indexes AuthConfig Limit

with:

AllowOverride Indexes AuthConfig Limit FileInfo

---
Update:fixed typo in path.

Thank you very much, was told in an earlier post that this couldnt be done when I asked where the default file was....

No, that's not possible.
__________________
Falko

wink wink ;)

davestyle
23rd April 2009, 20:43
So, here the way to change the defaults, its really easy and I had posted this last week already but here for refernce again the step:

Edit the file:

/usr/local/ispconfig/server/conf/vhost.conf.master

and replace all lines (the lin exists 4 times in the file):

AllowOverride Indexes AuthConfig Limit

with:

AllowOverride Indexes AuthConfig Limit FileInfo

---
Update:fixed typo in path.


Thanking you very much. I'm all for the checkbox approach to allowing mod_rewrite :)

Ovidiu
2nd May 2009, 21:52
so the safest solution is the one posted in reply #21, right? http://www.howtoforge.com/forums/showpost.php?p=183193&postcount=21

no other chance to enable only mod_rewrite and nothing else?

I guess that is a shortcoming of apache2 then. will alter my masterfiles then.

btw. if I change this file /usr/local/ispconfig/server/conf/vhost.conf.master and then go, make a small change in a website and save it will this vhost.conf.master be automatically applied? to the site I jsut saved?

till
2nd May 2009, 21:56
no other chance to enable only mod_rewrite and nothing else?

No, at least I'am not aware of another solution.

I guess that is a shortcoming of apache2 then. will alter my masterfiles then.

yes.

btw. if I change this file /usr/local/ispconfig/server/conf/vhost.conf.master and then go, make a small change in a website and save it will this vhost.conf.master be automatically applied? to the site I jsut saved?

yes.

Ovidiu
31st May 2009, 23:09
don't understand this. I changed what was psoted above by till, still if one of my wordpress sites tris to use mod rewrite, I get a 403 error:

Forbidden

You don't have permission to access /wp-admin/options-permalink.php on this server.
Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny3 with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g Server at klub-kamikaze.com Port 80
and if I check the vhost file:

<Directory /var/www/clients/client1/web15/web>
Options FollowSymLinks
AllowOverride Indexes AuthConfig Limit FileInfo
Order allow,deny
Allow from all
</Directory>

I even added these directives into the apache directives field within ispcfg3 so what am I doing wrong here? all other wordpress sites are fine after the hack described above by till, even without me adding the directives manually... the only difference I can think of is that meanwhile I have upgraded from (within the last week)

mgibson
1st June 2009, 09:32
Hi Tenaka,

Those apache directives didnt work for me either...
In the vhost.conf.master, change the lines to:

Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All

There should be 4 places in vhost.conf.master where you do this. It worked for me on joomla, magento and wordpress.

NOTE: when you upgrade ispconfig3, it wipes these settings out so you will either make a backup of your vhost.conf.master, or put them in again and restart apache2.

till
1st June 2009, 10:08
I hope that you dont have any clients on your server as you now completely opened up your server for manipulations by your clients.

mgibson
1st June 2009, 10:21
only in their directory structures, which they should have full access to anyway ;) many clients are happy as their sites are working as should.

tenaka, this setting is up to you. I have had no issues with it.

till
1st June 2009, 10:24
only in their directory structures, which they should have full access to anyway many clients are happy as their sites are working as should.

No. As this setting allows also the inclusion of other script interpreters and run bash cgi acripts to break out of their directorys and enable all kind of php functions etc.

Ovidiu
1st June 2009, 10:43
Ok, back to my question:

I did what till suggested above, edited the masterfile with:

AllowOverride Indexes AuthConfig Limit FileInfo

and it worked for the last couple of weeks for all wordpress isntallations. Then I upgraded ispcfg3 and yesterday I installed a new wordpress isntallation which is now acting weird, giving those 403 forbidden errrors, so I checked its vhost fiel and it seems ok, see my last psot.

what could have gone wrong here?

till
1st June 2009, 10:46
1) Which version number does ISPConfig show in the interface?
2) Which allow override options are set in the newly created vhost.

Ovidiu
1st June 2009, 10:54
1. Powered by ISPConfig 3.0.1.2
2. the vhost contains the following:

<Directory /var/www/mydomain>
AllowOverride None
Order Deny, Allow
Deny from All
</Directory>
then comes the actual Virtualhost directive aka
<VirtualHost *.80>
...
...
<Directory /var/www/mydomain/web>
Options FollowSymlinks
Allowoverride Indexes, AuthConfig Limit Fileinfo
Order allow, deny
Allow from all
</Directory>

should be working, right?

btw. there might be spelling msitakes above, as I couldn't cut and paste, I had to write it manually...

till
1st June 2009, 11:02
1) Then you dont have the latest version installed. Please install the latest update again and run this command before you do the update:

rm -f /tmp/ISPConfig*

to remove all old copies of installation files in the /tmp directory.

2) The vhost ino looks fine. But there are two places withe the allowoverride, make sure that both look like this.

Ovidiu
1st June 2009, 11:28
1. done. says: 3.0.1.3
2. there are two places, one /var/www/mydomain the other one /var/web/client/... and both look the same as above...

stil, if I enable mod_rewrite in this vhost by inserting a mod_rewrite directive into an .htaccess file, I get 403 errors, forbidden.

till
2nd June 2009, 10:45
Please compare the vhost file with a working vhost file from another site and also compare the .htaccess file from this vhost with a .htaccess file from a working installation on the same server.

mgibson
2nd June 2009, 16:12
No. As this setting allows also the inclusion of other script interpreters and run bash cgi acripts to break out of their directorys and enable all kind of php functions etc.

then the tutorial should be updated here - http://www.howtoforge.com/magento-e-commerce-solution-debian-etch

step 7.1

<Directory /var/www/magento/>
AllowOverride All
</Directory>

are you saying users who have been following this tutorial are vulnerable?

till
3rd June 2009, 08:58
This tutorial is for a private server and not ispconfig or for a hosting enviroment. As long as you are the only user, then AllowOverride all is fine.

Ovidiu
4th June 2009, 18:15
Please compare the vhost file with a working vhost file from another site and also compare the .htaccess file from this vhost with a .htaccess file from a working installation on the same server.

ok, here is the .htaccess from a not-working site:

# preventing hotlinking
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(.*)?domain1.com(/)?.*$ [NC]
RewriteRule .*.(gif|jpe?g|png|bmp)$ [F,NC]

Redirect 301 /category/blog http://domain1.com/

# BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

# END WPSuperCache

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

here is a .htaccess from a working site:

# preventing hotlinking
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(.*)?domain2.com(/)?.*$ [NC]
RewriteRule .*.(gif|jpe?g|png|bmp)$ [F,NC]

# BEGIN WPSuperCache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{HTTP:Cookie} !^.*(wordpress|comment_author_|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html.gz [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{HTTP:Cookie} !^.*(wordpress|comment_author_|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{HTTP:Cookie} !^.*(wordpress|comment_author_|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html.gz.wip -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html.gz.wip [L]
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{QUERY_STRING} ^$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{HTTP:Cookie} !^.*(wordpress|comment_author_|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html.wip -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{SERVER_NAME}_%{SERVER_PORT}/$1/index.html.wip [L]
</IfModule>

# END WPSuperCache

# BEGIN WordPress
RewriteEngine On
RewriteBase /

#uploaded files
RewriteRule ^(.*/)?files/$ index.php [L]
RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*
RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]
RewriteRule ^(.*/)?sitemap.xml wp-content/sitemap.php [L]

#avatar rule
RewriteRule ^(.*/)?avatar/(.*) wp-content/avatar.php?file=$2 [L]

#RewriteRule ^wp-content/blogs.dir/(\d+)/themes/(.*) wp-content/blogs.dir/$1/themes/$2 [L]

#google sitemap verification
RewriteRule ^google(.*).html googleverifyfile.html

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule . - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

# add a trailing slash to /wp-admin
RewriteCond %{REQUEST_URI} ^.*/wp-admin$
RewriteRule ^(.+)$ /$1/ [R=301,L]

# END WordPress


there are some differences but the first one is wordpress the second one is wpmu, still its only redirect and rewrites.

Now a non working vhost file:
<Directory /var/www/domain1.com>
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>

<VirtualHost *:80>
DocumentRoot /var/www/clients/client1/web7/web
ServerName domain1.com
ServerAlias www.domain1.com
ServerAdmin webmaster@domain1.com
ErrorLog /var/log/ispconfig/httpd/domain1.com/error.log

<Directory /var/www/domain1.com/web>
Options FollowSymLinks
AllowOverride Indexes AuthConfig Limit FileInfo
Order allow,deny
Allow from all
</Directory>

<Directory /var/www/clients/client1/web7/web>
Options FollowSymLinks
AllowOverride Indexes AuthConfig Limit FileInfo
Order allow,deny
Allow from all
</Directory>

# suphp enabled
<Directory /var/www/clients/client1/web7/web>
suPHP_Engine on
# suPHP_UserGroup web7 client1
AddHandler x-httpd-suphp .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-suphp
</Directory>

</VirtualHost>


and here is a working vhost:
<Directory /var/www/domain2.com>
AllowOverride None
Order Deny,Allow
Deny from all
</Directory>

<VirtualHost *:80>
DocumentRoot /var/www/domain2.com/web
ServerName domain2.com
ServerAlias *.domain2.com
ServerAdmin webmaster@domain2.com
ErrorLog /var/log/ispconfig/httpd/domain2.com/error.log


<Directory /var/www/domain2.com/web>
Options FollowSymLinks
AllowOverride Indexes AuthConfig Limit FileInfo
Order allow,deny
Allow from all
</Directory>

<Directory /var/www/clients/client1/web9/web>
Options FollowSymLinks
AllowOverride Indexes AuthConfig Limit FileInfo
Order allow,deny
Allow from all
</Directory>

# suexec enabled
SuexecUserGroup web9 client1
# php as fast-cgi enabled
<Directory /var/www/domain2.com/web>
AddHandler fcgid-script .php .php3 .php4 .php5
FCGIWrapper /var/www/php-fcgi-scripts/web9/.php-fcgi-starter .php
Options +ExecCGI
AllowOverride all
Order allow,deny
Allow from all
</Directory>

</VirtualHost>

Ovidiu
9th June 2009, 14:00
I figured out my problem, had nothing to do with ispconfig after all.

it seems the wordpress built in updater, sets file permissions wrong. Must check what they are set to, but it breaks suPhp somehow.

If I use plugin central wordpress plugin for updating all seems fine :-)