3.97 Problems with Drupal sites

4 posts / 0 new
Last post
#1 Fri, 12/14/2012 - 13:27
Adam

3.97 Problems with Drupal sites

Like many others, we've been having a nightmare since 3.96/7 with Ubuntu 12.4 on AWS.

When updating to 3.96, most of our sites 30+ CMS sites (WP/Drupal/Magento) & phpMyAdmin had problems.

We solved most of these problems by rolling back via a server backup, and selecting to not fix the domains at update.

We've now had to (for different reasons) move our domains onto a fresh install of 3.97 and create the virtual servers via a virtualmin backup. Upon re-creating them, the WordPress sites work but the majority of our sites on Drupal don't. The only way to prevent a 500 error is to comment out 'Options +FollowSymLinks' in the standard Drupal .htaccess file. Even then we seem to have problems with the sites such as 500 errors on stylesheets, etc.

If you create a new virtual server on fresh install of 3.97 and install Drupal, it doesn't work by default. You have to edit the .htaccess file to access the site, then if you turn on caching the site's JS and CSS fails with 500 errors. This is a pretty big problem...

Can anyone help and explain how to change the settings for a new virtual server creation in 3.97, that will undo what has been added by these updates please? We can't be fixing this on a per-domain basis and I'm sure we're not the only people having this problem.

Thanks

Fri, 12/14/2012 - 14:56
andreychek

Howdy,

When you receive 500 errors when accessing the CSS and JS for that site, what is showing up in the Apache error logs in $HOME/logs/error_log?

One thing is that, rather than commenting out the "FollowSymLinks" in your .htaccess, you may want to instead change that to use "SymLinksIfOwnerMatch".

But if that doesn't help, let us know what errors you're seeing in the logs, and we can offer some input on how to correct them.

The reason for the config change is that there's a rather large security problem without that change.

Whenever you see "+FollowSymlinks", you should instead read that as "+CanSeeAnyUsersFileOnTheServer" :-)

We highly recommend against doing anything that would allow the use of FollowSymlinks in a .htaccess file.

However, after knowing the severity of the security issue, if you really want to continue using that anyhow, let us know, as there is indeed a way to tell Virtualmin to ignore the security issue.

I wouldn't recommend that though :-)

-Eric

Fri, 12/14/2012 - 16:28
Adam

Hi Eric,

Thanks for your comments.

After digging around a bit further with this, it seems that just changing 'FollowSymLinks' to 'SymLinksIfOwnerMatch' in the root .htaccess file didn't fix it completely. A .htaccess file at /sites/default/files also needed changing too; hence why changing the root one initially granted access to the site, but there were issues with files/css caching!

This seems to have been discussed a bit over a drupal.org already. You can see one of the conversations here:

http://drupal.org/node/1269780

... there's even a Virtualmin mention at the end!

I think we can live with changing this in the two .htaccess files going forward.

Thanks for your help and I hope this helps other stuck on this.

Adam

Fri, 12/14/2012 - 18:34
andreychek

That's quite helpful, thanks for letting us know how you fixed it, and for providing the link to that Drupal page!

-Eric

Topic locked