HOW TO: Hosting multiple websites

Anyways, WhoCares?, for the directory image problem I think you should add

Alias /images/ /frontview/ui/resource/images/
<Directory /images>                  
  Options MultiViews                 
  AllowOverride None                
  Order allow,deny                       
  Allow from all                         
</Directory>

to /etc/frontview/apache/DefAlias.conf in your repo.

The snippet above is wrong on so many levels ;) Generally it looks like PHP isn't working for you.
Going to to have a detailled look later.

-Stefan

WhoCares? wrote:
The snippet above is wrong on so many levels ;) Generally it looks like PHP isn't working for you. Going to to have a detailled look later. -Stefan

Stefan,

Thanks a bunch. I created a new thread titled Help set up PHP CGI Environment please where I have posted my updated configuration files.

It seems that in the chaos of it all I found the code Alias /images/ /frontview/ui/resource/images/ ...etc... in /etc/frontview/apache/DefAlias.conf then added that very same code a second time to the same file. So now I realize my suggesting, after some sleep, makes no sense as you would just be re-adding the alias to the same file (DefAlias.conf) that it's already in. I made that suggestion because I was misled into thinking that adding that bit of code to DefAlias.conf solved the directory image problem due to a new discovery: just running the restart command doesn't really refresh everything like it should. Instead you have to restart the entire NAS to see it all refreshed for sure. That's why my problem went from the file being downloaded to permission errors for .php files... So lesson learned: restart the whole NAS after a change AND clear your browser cache or else you won't see the true effects of your changes...

So yeah, that means my /images/ Alias suggestion wasn't wrong on any level because that code is already in AliasDef.conf! However I would now modify that suggestion to put the Alias /images/ /frontview/ui/resource/images/ ...etc... code inside the <VirtualHost *:80> definition in *.vhost which is probably wrong on some level..? But I can confirm that this (after restarting the NAS) does fix the images in the directory listing.

Joel

Instead of restarting your ReadyNAS I guess clearing your browser's cache after restarting just Apache would do the trick equally well. Will have a look at the other thread you mentioned.

-Stefan

WhoCares? wrote:
Instead of restarting your ReadyNAS I guess clearing your browser's cache after restarting just Apache would do the trick equally well. Will have a look at the other thread you mentioned. -Stefan

No this is my point: I had made the same assumption as you but after numerous tests I found that running the command

apache-ssl -f /etc/frontview/apache/httpd.conf -k restart

and clearing the browser cache does NOT result in the same results as restarting the NAS entirely and then clearing the browser cache.

leoj3n wrote:
No this is my point: I had made the same assumption as you but after numerous tests I found that running the command apache-ssl -f /etc/frontview/apache/httpd.conf -k restart and clearing the browser cache does NOT result in the same results as restarting the NAS entirely and then clearing the browser cache.

From a technical point of view there's no difference between these two methods. Anyway, that's a moot discussion because even if we get to agree on something here it won't solve your problem ;)

-Stefan

Agreed, I just wanted to make clear what is and isn't working for me incase it affects our discussion or helps anyone else who may have similar issues and find this thread in the future. As far as adding the /images/ Alias to *.vhost: what is your stance on that? Would that end up intercepting any /images/ directory in a non-directory-listing scenario? (i.e: if you put an /images/ folder in the site dir and linked to an image in there from index.html like <img src='images/mycoolimage.png' />)

Would you mind testing a directory-listing scenario and let me know if directory images display correctly for you using your apache-configs?

leoj3n wrote:
As far as adding the /images/ Alias to *.vhost: what is your stance on that? Would that end up intercepting any /images/ directory in a non-directory-listing scenario? (i.e: if you put an /images/ folder in the site dir and linked to an image in there from index.html like <img src='images/mycoolimage.png' />)

As with most config settings for Apache the answer is: "It depends." ;)
To make that a bit more clearer, we first have to look at what the 'Alias' command does and how it works. The basic function of the 'Alias' command is to tell Apache, where to look for files that are requested from a specific path. So, if we are to have something like

Alias /images/ /foo/

in the Apache configs, and then a request for 'www.some.url/images/test.gif' comes in, Apache would try to fetch the file '/foo/test.gif' from the local file system. So basically, Alias maps a location from the request to a location on the physical drive. That said, there are (at least) two different places where you can have an 'Alias' definition: The server config, which would create a global alias, and the VHost config, which creates an Alias only known within a virtual host. Now, *all* global Aliases are known within virtual hosts as well. And since Netgear's original configuration contains a global 'Alias /images/ ...' statement, you can add aliases to virtual hosts or even have a real images directory there until you're blue in the face - Apache will still always try to fetch images from the location named in the first and global 'Alias' statement. That's also why you're seeing the error saying 'Alias will never match ...' in your config. Which in turn brings me to the conclusion that you either used an old version of my configs or only parts of those, for one major change my configs bring is that there aren't *any* global Alias statements anymore. (Well, at least there shouldn't be any). So, it would be interesting to learn which config you used for your ReadyNAS.

-Stefan

I used git to pull the repo off Gitorious so I assume that means I used the newest version of your config. I guess the problem may be that I created a /sites/ directory in which I put all my *.vhost files for my sites. I added

Include /etc/frontview/apache/sites/*.vhost

at the end of /etc/frontview/apache/httpd.conf to pull in those vhost configs. I'll try moving them to /etc/frontview/apache/addons/... By the way I think I am already blue in the face. :rofl:

Changing from /sites/ to /addons/ was fruitless. However I tried going to http://2011cc.otzo.com/index.php which gives the output:

Your server is running PHP version 5.2.0-8+etch16 but WordPress 3.4.1 requires at least 5.2.4.

However if you don't go directly to the index.php file you still get the permissions thing: http://2011cc.otzo.com/