On 20/12/12 23:00, support-request@drupal.org wrote:
If you named the multi-site example.com, then you need to reference the site ashttp://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.
-- Richard Damon
Thanks Richard, you are correct, I don't understand exactly what is going on but am learning.
You mention that we must own the domains and this is a problem as she wants to use the shared server to host 3 or 4 other sites for teachers who will have their own domain names, not yet established.
It seems that one way is for each to have their own share on the server which means she will have to manage several drupal installs on different servers, something I wanted to avoid because each is a very simple requirement easily handled by a fairly basic drupal and a few modules.
The other option offered by the ISP is to have the separate drupal installs on her share then have the domains as Add Ons. I'm not familiar with this - seems I must learn.
Have no interest in example.com it is just mentioned in the drupal tutorials. I tried it and it doesn't work, no matter what I have in /hosts or /httpd.conf
As for .ab and .xy these are my invention for practising on my home pc, I found the home pc it doesn't care what the domain is called as long as it has a name a dot and an extension of 2 or 3 letters, Drupal and apache don't care.
Regards Roger