Forum Moderators: phranque
The way we've worked for a good few years now (on the 1 machine) was simply with Apache's userdir wherein anyone who requested a page which matched [domainname.com...] served files which were located at /home/members/username/public_html. now, the main server isn't hosting the user files, it's on a second server, called homes.domainname.com, which works in the way I described above, with Apache's userdir mod, while also having a rewrite rule in place that redirects any request on the www server with a "/~" url to go to the homes server.
That's all working fine, but I just started playing around with serving wildcard sub-domains, so that every one of our members are able to access their web folder through username.domainname.com. Now, I've set the bind server up to point www.domainname.com to our www server and all other *.domainname.com to the homes server.
Unfortunately, though, it doesn't work how I'd like it to, instead of serving the files directly from there, it rewrites the URL to the way userdir expects it, homes.domainname.com/~username. what I'd actually like to do is have the server directly serve the files from both URLs, username.domainname.com and homes.domainname.com/~username.
My problem is that I don't know how to expand the userdir mod so that it catches and attempts to serve all URLs that aren't that catch all subdomains that aren't "homes", as well as any URLs that match homes.domainname.com/~*.
Anybody with an idea how I can do this?
This won't happen by itself, so you'll need to identify the 'agency' involved. Also, how do you know the URL is being rewritten -- are you seeing it in the access or error log, or is something invoking an external redirect (i.e. not an internal rewrite) such that the userdir-format URL is exposed to the client browser?
Jim
I don't get what you're saying by your second paragraph, sorry. Everything is currently working, but not how I'd like it to.
If you type [domainname.com...] into your browser, it get's rewritten to [homes.domainname.com...] and hosting the files at /homes/members/username/public_html on that server, which is what should be happening. If you type [username.domainname.com,...] it also gets redirected to [homes.domain.com...] and hosts the same files. It's being rewritten in the URL bar on my browser, and hosting the correct files, so I know it's all working correctly.
The second part is happening via a rewrite rule,
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{http_host} .
RewriteCond %{http_host} !^homes\.domainname.com [NC]
RewriteCond %{http_host} ^.*\.it-netsoc\.ie [NC]
RewriteCond %{http_host}%{request_uri} ^([^.]+)\.domainname\.com/(.*) [NC]
RewriteRule ^(.*) [homes.domainname.com...] [R=301,L,QSA]
</IfModule>
This does actually work fine, but I don't think this is an elegant solution, as if anyone references a root file from their site, it won't get there from the originally redirected page.
ie. You've a page "index.html" which links to an image via "/logo.jpg" and is stored in your /home/members/username/public_html folder. You'd think that would work from the url of
username.domainname.com/index.html, but it won't. That URL will be rewritten to
homes.domainname.com/~username/index.html and will then look for the image at "/logo.jpg", which will now be pointing to
homes.domainname.com/logo.jpg, which will probably cause a 404 error. If however the files were being served directly from that URL, username.domainname.com, like Apache does with the userdir mod, that problem wouldn't be there any more.
Dump mod_userdir and replace its current function with another mod_rewrite rule. In this way, you'll be able to determine both the scope and priority of userdir rewrites with respect to the subdomain rewrites by using code order and RewriteConds where needed. I suspect that this ambiguity is the root of your current problem.
You should be able to easily fix the 'root file access' problem with this approach.
Use internal rewrites where possible, saving redirects for use only in changing the domain or hostname when actually required, *and* to redirect all non-canonical hostnames and URLs to one single canonical URL when these are directly requested by a client -- e.g. if the client requests a subdomain- or userdir- related subdirectory of DocumentRoot, then redirect that request back to either the subdomain root or the /~userdir subdirectory as applicable.
In all cases, if a canonical URL is requested, the browser address bar must not change -- in other words, a canonical URL request should invoke only an internal rewrite to the correct server filespace. The result of all of this work is that there should be one and only one URL that can be used to access a specific resource ("page") and any and all variations of subdomain, domain, FQDN, port number, and userdir-subdirectory paths should invoke a single 301 redirect to the canonical URL for that resource, whether it be subdomain- or userdir- format.
I'd also suggest you back out all of the new subdomain-related code temporarily, until you get the mod_userdir replacement code and the related URL-canonicalization for userdirs thoroughly-tested and working; in order to maintain sanity, I think you'll need to 'divide and conquer' this problem.
Jim
You got me realising that I was trying to reinvent the wheel by trying to expand the userdir mod, instead of doing what I should have been, thinking outside the box. I've now implemented a variant of
[captain.at...]
and it's working absolutely perfectly, thank you very, very much.
