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
On 12/22/12 1:22 AM, Roger wrote:
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
Every site on the internet should have a domain name for people to get to. (It is possible to access a site via just its IP address/port number, but this isn't done often, and doesn't work for shared servers), so to do any testing on a shared server you need a domain name that you "own".
When you sign up for server space, the hosting provider will give you a "default domain name" to access the server, normally a specific subdomain, something like u12345.example.com, where example.com will one of the domain names the host provider uses for their hosting. In addition you can register other domain names and connect them to the server.
The use of the example.com domain names in these examples is largely to avoid the problem of people copying them exactly, then testing them out and hitting some real servers with strange requests. It is expected (and usually spelled out) that you need to replace the example domains with your real domain.
Either you local machine has been set up to map unknown domains to localhost, or (based on some of your comments) the instructions included steps to modify your host file to tell your machine where to find these domains (as localhost). The key is that somehow you need to establish a mapping from domain name to server (either via the global DNS system for registered domains, or via the hosts file on your machine for unregistered domains for testing purposes, and then tell the server where to go to serve request for that domain.
As far as having a multi-site system or a couple of independent installs, I would suggest that it may be better to have separate installs. One issue with a multi-site install is that Drupal's built in update tools are not setup for it. For a single install, a module update can be done solely inside Drupal, and it will take the site off-line, update the module, and you can run the database update. This is NOT automated for a multi-site install. You will need to manually take off-line the other sites, and manually run the database update afterwords, and then manually put them back online. There are more advanced tools (like Drush) which can help with this, put it does require someone to understand a lot more about how the system works.
On Sat, Dec 22, 2012 at 10:02 AM, Richard Damon wrote:
Every site on the internet should have a domain name for people to get to. (It is possible to access a site via just its IP address/port number, but this isn't done often, and doesn't work for shared servers), so to do any testing on a shared server you need a domain name that you "own".
I really dislike misinformation and the only reason I'm responding to this issue. You do not need "a domain name that you "own"". You will need to map the IP for the server to a domain name but it doesn't need to be registered in a DNS. You map the IP to a domain name via the client hosts file. On a *nix system that would be /etc/hosts. On Windows it would be %SYSTEMROOT%\system32\drivers\etc\hosts. I typically use a fictitious host name of ``local.test'' with the name of the real site prepended such as example.local.test. I enter the following in my client hosts file for my dev/test site.
127.0.0.1 example.local.test example
Replace 127.0.0.1 with the appropriate IP address for your server. Doing this allows you to develop and test a site before putting it on line.
-
Earnie Boyd -
Richard Damon -
Roger