I have four Web development systems, two with Windows 10 and two with Ubuntu Linux and have set up Alias folders on three without a problem but am currently traveling and having trouble with the fourth. It is running Ubuntu with Apache2. A sample of one of the VirtualHost entries is below.
<VirtualHost devsite.dev:80>
DocumentRoot /var/www/html/devsite.dev
ServerName devsite.dev
Alias /common/ /var/www/html/devsite.dev/common/
<Directory "/var/www/html/devsite.dev">
AllowOverride None
Options FollowSymLinks Indexes
Require all granted
</Directory>
Options FollowSymLinks
</VirtualHost>
The above does not work so what did I miss? All site folders including the common folder are in /var/www/html/ and I must have missed something as the alias is not working. In other words, each site has its own sitename.dev folder so http://devsite.dev/ pulls up the site but there is no physical folder within the site folder for http://devsite.dev/common/ to work so needs an Alias. Not sure if trailing slashes are needed or not and can't recall what my other systems have but either way it doesn't seem matter here.
When I say it doesn't work, I mean that the aliased folder does not show up in the PC's file manager as it does on all my other systems and the site cannot find it using the browser in order to load files from it as I showed above in the sample URLs.
Perhaps I was not too clear that common is not within /var/www/html/devsite.dev. Instead it is at /var/www/html/common and it does require an Alias to work. Also, there is already a DocumentRoot /var/www/html line in the Apache 000-default.conf file.
I was under the mistaken impression that the Alias path was telling the system where the alias should appear but I was obviously wrong so here's the answer for others to see. Still not sure of the trailing slashes but, as it is working with them, I'll leave them in.
<VirtualHost devsite.dev:80>
DocumentRoot /var/www/html/devsite.dev
ServerName devsite.dev
Alias /common/ /var/www/html/common/
<Directory "/var/www/html/devsite.dev">
AllowOverride None
Options FollowSymLinks Indexes
Require all granted
</Directory>
Options FollowSymLinks
</VirtualHost>
Related
I have old solution based on Drupal 7 and the new one based on Drupal 8. Both of them provide APIs for their mobile apps. (URLs can be easy distinguished) In order to maintain smooth migration for users I want to keep old solution working as it is and serve new version of API behind it, it has obvious difference in pattern like /oauth/token, /api/v1/, /api/v2/.
I have tried the different ways of configuring apache with I different results, but not exactly what I need. I tried:
Configuring virtual hosts together with Alias;
Changing DocumentRoot to /var/www (where I have docroot with and docroot-new)
Configuring the .htaccess different ways
<VirtualHost *:80>
ServerName ${APACHE_SERVERNAME}
ServerAlias test.*
DocumentRoot /var/www/docroot/
#this is example with phpinfo, works well
Alias "/info.php" "/var/www/docroot-new/"
#Just to simplify I'm trying to serve only one API endpoint from
new solution
Alias /api/v1/mobile-ui/ "/var/www/docroot-new/"
#And auth endpoint
Alias "/oauth/token/" "/var/www/docroot-new/"
</VirtualHost>
<Directory "/var/www/docroot/">
DirectoryIndex index.php
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
<Directory "/var/www/docroot-new/">
DirectoryIndex index.php
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>
In this case the old solution is served well, but the new one can't be handled appropriately.
If I change DocumentRoot to /var/www/ , then both of them will work well, but obviously with a dir name in url. I guess .htaccess can help me here, but I'm not an expert and can't find the solution.
I also switch-on addition logging for apache and able to check details like matching for mod_rewrite (actually not very helpful for me)
so, I find the solution by myself. It's even better than previous thoughts. Just proxying queries.
ProxyPassMatch "/api(.*)" "http://new-solution.local/api$1"
ProxyPassReverse "/api(.*)" "http://new-solution.local/api$1"
ProxyPass "/oauth/token" "http://new-solution.local/oauth/token"
ProxyPassReverse "/oauth/token" "http://new-solution.local/oauth/token"
Hope it will help someone to solve similar problem.
I'm working on a Debian 7 server which I did a dist upgrade on so it is Debian 8 now.
The only thing I am having trouble with is the apache2 which got updated from 2.2 to 2.4. the problem that is that now it shows me an empty "Index of /" although there are a lot of files in the specified folders.
vHost Conf:
<VirtualHost *:80>
ServerAdmin some#email
ServerName some.server
ServerAlias some.server
DocumentRoot "/data/apt/public_html"
<Directory "/data/apt/public_html">
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Require all granted
</Directory>
</VirtualHost>
How can I get it working again?
mixing 2.2 and 2.4 access directives is not recommended. Look at http://httpd.apache.org/docs/current/upgrading.html. You will see that they never mix Order allow,deny with Require all granted. So remove your Order line.
Mixing old and new directives
Mixing old directives like Order, Allow or Deny with new ones like
Require is technically possible but discouraged. mod_access_compat was
created to support configurations containing only old directives to
facilitate the 2.4 upgrade. Please check the examples below to get a
better idea about issues that might arise.
Also, you do not specify a DocumentIndex file so Apache does not know which file it should return a client when he asks for http://some.server/.
Let's assume the default page is index.html, add this in your VirtualHost:
DocumentIndex index.html
Note 1: ServerAlias has the same value as ServerName, and is therefore not required.
Note 2: you should setup access and error log files for this VirtualHost. It might not be useful if you have only 1 VirtualHost, but you will thank me if you have a large site (with multiple VH later).
Just a simple question but I can't seem to find an answer.
I want to have Wampserver hosting a site (I am aware of the security implications of home hosting, don't worry), and I want to stop people accessing the index of folders and viewing all the files. For example, I want mysite/images not to be browsable, but I'd like for the files to be accessible, for example, mysite/images/image1.jpg.
My current virtual host for said website:
<VirtualHost *:25567>
DocumentRoot "C:\Users\Tom\OFFICIAL_WEBSERVERwamp\www\25567"
<Directory "C:\Users\Tom\OFFICIAL_WEBSERVERwamp\www\25567">
AllowOverride All
Require all granted
Options Indexes FollowSymLinks
</Directory>
</VirtualHost>
I can't get Apache's configuration to return the correct page, if there is a hyphen in the ServerName. I found a page here titled, "Dashes not allowed in virtual host entry?", but it was dealing with hyphens in the DocumentRoot, not with ServerName. In any case, it did not solve my problem, and I've been unable to find any other references to this problem.
I'm setting up multiple virtual hosts (VH) on a recently acquired Ubuntu 12.04 server, running Apache. Ubuntu's configuration for this is organized so that you have folders for sites-available and sites-enabled. A separate file, placed in sites-availabe is used for each individual VH. Enabling the VH is just a matter of making a symlink from the file in the sites-available folder to the sites-enabled folder, and restarting Apache.
I have several working VHs already. It's an easy recipe, since it's just a matter of copying a working file to a new filename, and changing a few variables.
All of my correctly-working entries do NOT have any hyphen in the ServerName, or ServerAlias. The one entry which does have a hyphen, does not work. Instead of returning the proper page, Apache returns the host's base page (which tells me DNS is fine).
I've tried enclosing ServerName and ServerAlias in quotes, with and without. No change.
Lots of domains use hyphens, I can't be the only one with this problem. Has anyone found a workaround? Here's my config:
<VirtualHost *:80>
ServerAdmin webmaster#localhost
ServerName datacore-inc.com
ServerAlias www.datacore-inc.com
DocumentRoot /home/web/datacore/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /home/web/datacore/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
I had the same issue and thought the problem came from the hyphen character in the ServerName. But actually I had declared the VirtualHost twice. I've removed one of them and that resolved the problem.
Yesterday, I had a fistful of sites running locally with no problem. Today, nothing opens and I have a log full of this:
Symbolic link not allowed or link target not accessible: /var/www
I have no idea what I did (I didn't open/change my httpd.conf file in any way), but clearly it was something bad. I run virtual hosts and the root directories are located in ~/Developer/www. In order to share the config files across multiple Macs with different home directories, I've created a symlink, /var/www which points to ~/Developer/www.
All of the virtualhost config files point their DocumentRoot to /var/www/project_directory and its own root directory has the FollowSymLinks option:
<VirtualHost *:80>
ServerName localhost
ServerAlias localhost.local localhost.dev
DocumentRoot /var/www/_localhost
<Directory /var/www/_localhost>
Options FollowSymLinks Indexes
AllowOverride None
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
My main httpd.conf file, similarly, has the FollowSymLinks option enabled for /:
<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
</Directory>
Any idea what I could have done to stop Apache from understanding symlinks or, better yet, what I can do to get it back on track?
Thanks.
UPDATE:
I should add that all of the directories in the "stack" are executable by all users and that this is the native Apache install on OS X Lion.
I guess I made an assumption that I shouldn't have. I had verified every relevant permission except the one that evidently mattered. Apache didn't have execute permissions on my top level home directory. I checked, re-checked and triple checked everything under that, but having never changed anything in that directory itself, I just didn't anticipate it being the issue.