<snip> "Multisite" means multiple sites installed on a single codebase. You have to have a base installation and that is where the VirtualHost will point. ? Nancy </snip>
Thank you Nancy The fault was not the base installation but the way I named the test multi site. example.com did not work, apparently because there is a web page on a domain called example.com but example1.ab and example2.xy did work well as a multi site on my home pc. It is a bit misleading in the Drupal.org tutorial which uses example.com in a number of places as examples for multi site installation.
So now it works on my home Fedora 16 box but I have no luck getting it to work on the ISP's remote centos shared server where I cannot access nor change httpd.conf, and /etc/hosts does not exist. Increasingly I find it a pity that apache has to be altered when the redirection and access could instead be through /sites.php which in this case seems to have no effect, or I am not understanding the instructions.
That sites.php in the /sites folder seems correct but Drupal seems to ignore it no matter what I put on the last line as per instructions. Whatever! It seems that http.conf and /etc/hosts has to be altered and I cannot find out how in cpanel or ssh on a shared server.
I wonder how others in similar situations have achieved multi sites on shared server? thanks Roger
On 12/19/12 5:12 PM, Roger wrote:
<snip> "Multisite" means multiple sites installed on a single codebase. You have to have a base installation and that is where the VirtualHost will point. ? Nancy </snip>
Thank you Nancy The fault was not the base installation but the way I named the test multi site. example.com did not work, apparently because there is a web page on a domain called example.com but example1.ab and example2.xy did work well as a multi site on my home pc. It is a bit misleading in the Drupal.org tutorial which uses example.com in a number of places as examples for multi site installation.
So now it works on my home Fedora 16 box but I have no luck getting it to work on the ISP's remote centos shared server where I cannot access nor change httpd.conf, and /etc/hosts does not exist. Increasingly I find it a pity that apache has to be altered when the redirection and access could instead be through /sites.php which in this case seems to have no effect, or I am not understanding the instructions.
That sites.php in the /sites folder seems correct but Drupal seems to ignore it no matter what I put on the last line as per instructions. Whatever! It seems that http.conf and /etc/hosts has to be altered and I cannot find out how in cpanel or ssh on a shared server.
I wonder how others in similar situations have achieved multi sites on shared server? thanks Roger
If you named the multi-site example.com, then you need to reference the site as http://example.com/ and you need to make sure that your system is set-up to resolve example.com to that machine and that document root.
By RFC, example.tld for almost all top level domains (I seem to remember that there are a very few old domain exceptions) is defined to not be used and free for documentation examples. If you are getting the notice that this domain is an example domain, then your problem is that you never told your machine to resolve example.com to be your machine, and perhaps the other domains somehow are routed that way (maybe due to .com being a real tld, while I am not familiar with a .ab or a .xy tld).
It is normally expected that when you implement the example, you will change the various example domains into real domains. For example, normally on a shared server, you will have a control panel that somehow lets you map where you want the document root for all of your registered domains and sub-domains, and since YOU don't "own" example.com, they control panel isn't going to let you tell it were to find the document root for that directory. For example, if drupal.org was implemented as a multisite (I don't know one way or the other), you might find under the sites directory directories like
/sites/drupal.org /sites/api.drupal.org
It really doesn't sound like you understand how this all is working. Your shared server probably does have an /etc/hosts (there are a few standard definitions, like localhost, that are placed there in most systems) but it is not something that an customer would be given access to change, because it could cause immeasurable problems to let someone do so, same with making arbitrary changes to httpd.conf. You also shouldn't need to make changes to these for anything that is proper to run on a shared server. One key limitation is that you MUST use domains that you own, and that the machine knows you own. One way to understand why is to think what would happen otherwise. Lets say they did allow you to tell it to serve pages for example.com from your document root. Since you share the server with other people, they should be able to do the same thing. The machine then runs into the problem that when it gets a request for a page from example.com, how is it to determine which customers version to use? This problem is why you are only allowed to direct document roots for domains that you own, and not things like example.com.
If you are actually trying to make your shared server have a domain "example.com", then this is the first issue to fix, you need to replace the example.com with a domain that you own and have registered your use of with that server.