12 posts / 0 new
Last post
#1 Tue, 12/11/2012 - 00:48
allhen

Upgrade 3.97

Hi, after upgrade my VPS with Virtulamin 3.96 to Virtualmin 3.97 Debian 6.0 were displayed 2 warnings in top about FollowSymLinks.

I did click both for fix, and now all sites can't be visited.

I see in log this .htaccess: Option FollowSymLinks not allowed here

Any help?

Thanks

Tue, 12/11/2012 - 04:02
helpmin

This option has been disabled for security resasons.

But does it work again if you replace that with SymLinksIfOwnerMatch?

Tue, 12/11/2012 - 04:06
allhen

Adding SymLinksIfOwnerMatch, doesn't work.

Disabling

Option FollowSymLinks

allow enter site (Magento) but with this disabled Fooman Speedster doesn't work !!

Tue, 12/11/2012 - 04:31
helpmin

Just to clarify, don't add it. replace FollowSymLinks with SymLinksIfOwnerMatch.

Sun, 12/16/2012 - 09:55
John_B

I have found this change breaks sites on newly created domains but did not break existing sites. Why?

Where Virtualmin is used only by the single sysadmin, is this really necessary?

It is a royal PITA because every time an automated site software update overwrites the .htaccess with one which includes FollowSymLinks (as the Drupal one does), the websites on virtualhosts created since the Virtualmin update break. Websites on domains created before the update are not breaking when .htaccess includes +FollowSymLinks. I am not yet sure why. This will certainly start to raise protests from Drupal newbies, who often have a lot of trouble getting a Drupal install working (reference drupal.org installation forum), even without this additional step to consider.

Hence, running # drush up and forgetting to hack Drupal's .htaccess is safe on my old Drupal sites, but will break my newer Drupal sites. When I find the way to turn off this feature for new domains (mercifully it is not afflicting existing domains) I will, unless given a compelling reason not to. A quick indication of how to change this behaviour would be welcome.

It would be useful to include a warning flag in the Virtualmin interface that a default Drupal installation will not work on a new virtualhost without modification of both .htaccess in document root, and additionally any .htaccess in sub-directories such as sites/default/files (where there is by default a .htaccess including FollowSymLinks). This is going to be a major source of incompatibility between Virtualmin and Drupal for less experienced Drupallers.

Sun, 12/16/2012 - 09:55
allhen

My solution was Edit directives for each virtual server created :

In

Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch

for this :

Options -Indexes +IncludesNOEXEC +FollowSymLinks
allow from all
AllowOverride All

and in just write this allow from all

Sun, 12/16/2012 - 09:57
allhen

My solution was Edit directives for each virtual server created :

In Directory /home/XXXXXXXXXX/public_html

Options -Indexes +IncludesNOEXEC +SymLinksifOwnerMatch
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch

for this :

Options -Indexes +IncludesNOEXEC +FollowSymLinks
allow from all
AllowOverride All

and in Directory /home/XXXXXXXXXX/cgi-bin just write this

allow from all
Sun, 12/16/2012 - 10:00
John_B

Thanks, I should have spotted that. Actually just 'AllowOverride All' is enough to get it working again.

Being a Drupal guy I still find it annoying that Virtualmin is no longer compatible with Drupal out of the box.

Sun, 12/16/2012 - 10:09
helpmin

That seup allows any user on your system to read the contents of files that belong to other users (via php, via shell etc). I you only have one site, then that probably wouldn't be an issue :-)

Sun, 12/16/2012 - 10:39
allhen

@helpmin, for me or for @John_B??

if is for me, is my VPS with 7 domains and only me have access

Thu, 01/10/2013 - 15:31
drori

i've tackled with exactly the same issue here, a new virtualmin environment (from scratch, not an update).
The website(s) are copied from another server.

inside my htaccess i had:

...
</FilesMatch>

Options -Indexes
Options FollowSymLinks
...

So according to the tip aove, i deleted that, and instead, changed it to:

...
</FilesMatch>
Options -Indexes +IncludesNOEXEC +FollowSymLinks
allow from all
AllowOverride All
...

But then Apache didn't like "allowoverride" here:
/home/xxxxxx/public_html/.htaccess: AllowOverride not allowed here

So I commented that out, and checked the xxxx.conf file, where I found:
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All Options=ExecCGI,Includes,IncludesNOEXEC,Indexes,MultiViews,SymLinksIfOwnerMatch

So I removed the restrictions, and now it's allowing from all:
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch +ExecCGI
allow from all
AllowOverride All

But nope:
FollowSymLinks or SymLinksIfOwnerMatch is off which implies that RewriteRule directive is forbidden

Hey - i thought that SymLinksIfOwnerMatch was supposed to set on (with this line in the htaccess:
Options -Indexes +IncludesNOEXEC +SymLinksIfOwnerMatch

So i'm utterly confused.
I'm not an Apache guru.

How can allow everything and get started until I figure out permissions issue?
As with the original person who asked, my system is 100% under my control, and each website has different owner & group, so i'm a bit less worried about this ATM.

Thu, 01/10/2013 - 15:47 (Reply to #11)
drori

I solved this case, but i don't understand or remember how exactly

I edited the file:

/home/xxxxxx/public_html/sites/default/files/.htaccess
commented out #Options None and un-commented Options +FollowSymLinks, this way:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None       
Options +FollowSymLinks     
 
now ALL files are up.
 
i'm not sure if and how much my files are secure, and even less how to repeat the fix.
Topic locked