Netscraps

A windsurfing, CSS-grudging, IE-hating, web-developing, gigantic-machine-puzzling blog

Tag: apache

Plesk Apache 404 error: File does not exist: /var/www/vhosts/default/htdocs/

You’ve no doubt discovered massive amounts of 404 errors in your main Apache error log that go something like:

File does not exist: /var/www/vhosts/default/htdocs/....

The requests may appear to be legitimate requests for page on the the primary virtualhost, but are returning 404 errors. Or, they may be crap requests to /var/www/vhosts/default/htdocs/phpMyAdmin etc made by script kiddies looking for vulnerabilities. Sound familiar?

Chances are you have SSL disabled for the domain in Plesk, & these requests to vhosts/default/htdocs/ are from HTTPS requests.

Plesk handles this use case in the most asinine way possible.

Since you have SSL disabled for your virtualhost, Plesk doesn’t route HTTPS requests to any virtualhost. Instead, it’s using the default host settings in /etc/httpd/conf/plesk.conf.d which can be something like:

<VirtualHost your_ip_here:7081 127.0.0.1:7081>
    ServerName "default-your_underscored_ip_here"
    DocumentRoot "/var/www/vhosts/default/htdocs"
    ....
</VirtualHost>

Little-known (to me) Plesk fact: For SSL requests, Apache listens to port 7081 when it’s running behind nginx, per /etc/httpd/conf.d/ssl.conf

How do you know this is going on? Enable servername & port logging in access_log so you can tell exactly what these requests are coming in as. To set that up, in /etc/httpd/conf/httpd.conf look for where your main access_log is defined, like:

 CustomLog logs/access_log combined

Then look for a LogFormat line that defines the log format nickname “combined”:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Add %v %V %p in there — right after %t is a good spot. Doing this adds the servername in two flavors, & the port of the original request. The servername helps you to determine which section of your Apache config is getting used, if you aren’t sure. The port shows the original — not mapped — port of the request. HTTPS starts out as a port 443 request so you’ll see that in the access log, not port 7081.

Restart Apache, either through Plesk, or apachectl restart. Then go tail -f access_log  to watch the log with that additional data.

How do you fix how Plesk handles these SSL requests? In Plesk…

  • In Hosting Settings for your domain, check the box to enable (…yep) SSL.
  • In the Apache & nginx settings for your domain, under “Additional directives for HTTPS “, add this RewriteRule to redirect HTTPS requests to HTTP:
RewriteEngine On
RewriteRule .* http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

That’s the best way I know how to fix this, anyway.

Any other suggestions? Normally you could set up a “black hole” entry, but I’m not sure how to overwrite the default Apache server settings, since server.conf is auto-generated by Plesk.

I’m off to bang some rocks together.

Apache httpd.conf changes ignored in Windows 7

VirtualStore in Windows 7 causes problems

Feature? Hack? Or hugely misguided mistake?

Imagine this: You are a web developer. You buy a brand new computer running Windows 7. You install Apache using all the default installation options. You fire up your browser to see Apache’s “It works!” test page …so it does, Apache. Awesome.

You edit httpd.conf to point to your latest web project, restart Apache, refresh the browser. Which still shows It works! … not your project. Hmm. No startup errors in the Apache error.log …. you close & reopen httpd.conf & your changes still look good. Apache still shows It works! In a mad rage you delete all settings in httpd.conf & bang out some undocumented 4-letter profanity settings guaranteed to throw Apache startup errors. Restart Apache. It works! No, Apache, it doesn’t!! What the fuck.

WTF is happening is a little-known feature, hack, & extremely bad idea from Microsoft in Windows 7 (and some other versions) called VirtualStore. VirtualStore should have been called VirtualStoreYourFilesElsewhereAndNotTellYou, because that’s what is occurring.

When you saved your edited httpd.conf file, Windows 7 secretly saved it in (deep breath) …

/Users/[Your User Name]/AppData/Local/VirtualStore/Program Files/Apache Software Foundation/Apache2.2/conf/httpd.conf

… and a hidden link gets created within your Program Files folders to the VirtualStore copy. Normally this works okay with legacy Windows programs, but apparently with Apache running as a service, it doesn’t pick up the VirtualStore link.

The upshot is while you continue madly editing your VirtualStore’d httpd.conf, Apache continues reading the original, which you are secretly being prevented from editing. How are you supposed to know what’s going on? Take a look …

Awful VirtualStore Warning

Microsoft's alert that VirtualStore files exist

Yea. One little icon in the action bar. Not at all noticeable.

(Microsoft should consider using my patented red oval).

No indication of which files are “Compatibility Files”.

And apparently, the linked file system doesn’t work consistently. What a stupid feature. It’s a hack, really, trying to blindly protect an operating system infamous for core-level security flaws.

How about a simple warning that the VirtualStore hack was occurring? Or ditch VirtualStore & display a UAC-style dialog, “Program X wants to write to Program Files, cancel or allow?” Even cancel or allow would be an improvement.

run as Administrator

Don't forget this minor detail.

What triggered VirtualStore in the first place? Way back when you fired up your text editor, you needed to run it in Administrator mode. Only then does it have the ability to save files directly under the protected Program Files folder structure without VirtualStore links.

How to fix the VirtualStore mess — First, move your Apache config file(s) out of the VirtualStore folder structure. Then delete the Virtualstore/Apache Software Foundation/ folder. That removes the “Compatibility Files” links from the real directory. Then you can run your text editor in Administrator mode & redo your Apache config edits.

Or even better: right-click on the folder that contains the files you want to edit, click Properties, Security tab & give Full Access privileges to your Windows user.

Notepad (& possibly Wordpad) won’t trigger VirtualStore — instead they’ll simply throw a “permission denied” error until you switch to Administrator mode. Most third-party editors like Komodo Edit will silently generate the VirtualStore’d copies until you run them in Administrator mode.

You can see which of your applications are being VirtualStore’d by opening Task manager, Processes tab, View menu, “Select Columns…”, check Virtualization. Back at the task list, any process with “Enabled” in the column means you’re in for some VirtualStore fuckedupedness.

Best part: VirtualStore isn’t just for files — any program attempting to write to the registry under the HKEY_LOCAL_MACHINE\Software branch will be VirtualStore-slapped over to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software

Hope this helps someone! As someone commented on another blog, “I really hate how Microsoft surprises you with their new retarded ways of keeping us safe from ourselves.” Amen to that.

If you have Windows 7 Professional, Ultimate, or Enterprise editions, you can disable VirtualStore completely through the Local Policy Editor. This may prevent some legacy programs from running, however.

For more, see VirtualStore is horrible. How do you disable it in Windows 7.

Powered by WordPress & Theme by Anders Norén