| Project: | Domain Access |
| Version: | 6.x-2.0-rc6 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
On MacOS X 10.5.6 under MAMP Pro, first the crux of the issue, then some configuration details:
My primary is "tetsite", the subdomain is "francais.testsite"
Their document roots are different: testsite is at .... /htdoc/testsite and the sub at ...../htdoc2/francais.testsite
They are both declared to Domain Access and marked active on the UI, however DA does not appear to be working so I have been trying to find out why.
When I click on "edit" for "francais.testsite" on the Domain Access UI and go to that page, the following warning is written at the top:
http://francais.testsite:8888/testsite/ is not responding and may not be configured correctly at the server level. Server code 404 was returned.
QUESTION: Why would either of these sites be looking for the primary site at the sub-site's address?
I thought the answer to this question might help me locate my problem, but I am not familiar enough with DA to be able to answer it.
************ configuration info ***********
HOST FILE:
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
127.0.0.1 francais.testsite
127.0.0.1 testsite
***********************
I note the urls of the two sites on my machine:
http://localhost:8888/testsite/
http://francais.testsite:8888/
[establishment of sub-domains with MAMP PRo is automated. It seems (above) to have re-written the Mac's (/private/etc/host) host file correctly. Mamp has its own httpd.conf file (the Mac's goes untouched) where the virtual host info is set by a series of calls beginning with:
# MAMP virtual hosts
#
MAMP_Port_iteration_begin_MAMP
NameVirtualHost *:MAMP_Port_MAMP
.....and on, making it a lot less easy to verify.
********************* end of config info *************
Otherwise I have a line of thoroughly dumb questions that two confirmations would resolve.
1) The Domain Access module is installed in only one site which thereby becomes the primary site & it is this site's settings.php file, and only this site's settings.php file, that is appended with the extra "four lines of code".
2) Any sub-domain which DA manages is a complete & fully functioning site with its own independent settings.php file both intact and unchanged as well as its own set of modules serving the functions sought for on that sub-domain.
I suppose both of these statements to be true, but when you run into trouble and start questioning everything, the readme & install texts leave room for doubt, even though they show every sign of having been written with care (thank you for this, really, it's rare) and gone over extensively.
Thank you for your time and consideration.
Comments
#1
I think you have gotten a few things mixed up here. DA is a single Drupal installation.
Set the document root for both domains to be the same eg. /htdoc/testsite (I'm assuming this is the one where your primary domain Drupal install with DA is).
Regarding #2 - they are not separate sites with separate settings.php files. What you are describing here (eg. set of modules serving the functions sought for on that sub-domain) is not possible with DA at the moment.
#2
So I was making a very fundamental error. Thank you. I will try to do what you say.
And in the meantime,
While I still remember what led me to my misunderstanding, I am going to go back over the DA documentation and perhaps suggest a couple of short, simple edits that could help avoid such errors to beginners in domain, sub-domain configuration. Should I have any suggestions, is this support thread the appropriate place to do that?
#3
Any additional feedback/suggestions is indeed appreciated;)
#4
Thank you, I'll get something back here by early next week, Monday or Tuesday.
... running a little late on this promise but it's on the way
#5
After looking over the documents that accompany DA, I made a series of edits etc. It seems to me that the major cause of ambiguity is the following.
Generally, the establishment of subdomains demands two actions, adding additional instructions to the hosts file and to the httpd.conf file. The install file gives the example of how to re-write a hosts file on a local set up, but says nothing of the httpd.conf file, nor does it mention the question of document root explicitly as you did above.
It says:
"resolve to your Drupal installation" is vague to the non-expert & "IP" is ambiguous here.
It should be explicit that the subdomains all use the same document root as the domain.
If you agree with this, and it is technically correct, I will upload an edit containing this and other suggestions.
(It'll take a few days as I'm a bit overrun at the moment)
By the way, correcting the document root as per your instructions has DA up and running as expected here.
The system still throws some errors, eg:
//francais.testsite:8888/testsite/misc/favicon.ico (from log)
but I think this error comes from the way MAMP Pro sets up subdomains on a local host and will disappear when we move the test site to a server on the net to continue development as we will get out from under MAMP Pro at that time....maybe, maybe not/we'll see.
#6
I test on MAMP, and am really not qualified to give instructions on setting up the server, which is why the documentation is deliberately thin.
Patches to docs welcome.
All I did for MAMP, it seems is edit conf/apache/hpptd.conf to make MAMP listen on 80, 3000, and 8888:
#Listen 12.34.56.78:80Listen 80
Listen 8080
Listen 3000
Everything else I have handled by the hosts file on my Mac.
Since these kinds of environment variables can differ widely, I feel safer giving no instruction rather than overly generic instruction.
#7
This (80, 3000, and 8888) is interesting. I'm going to run a couple of tests on the httpd.conf config.
I fully understand the position you have taken in the DA doc.
Take a little time but hope to make things clearer while respecting system differences
(mostly, like the present doc, by not entering into them).
Need to run some tests, talk to a couple of people, and go through some external doc,
then get back with my suggestions. Back soon.
#8
I run both XAMPP on my Windows machine and Apache/PHP/MySQL without MAMP/XAMPP on OS X. Installing DA does not differ from installing Drupal normally in any way, the only difference is pointing additional domains to the default domain location.
It really comes down to:
1. editing your hosts file to make domain names available
2. modifying httpd.conf to set up your DocumentRoot and to point domain names to your Drupal install
#9
I am attaching a first edit (odt file /additions in color) of the the part of the install.txt where there are a lot of suggestions. My aim has been to clarify some things that may be less than obvious to people less well versed in specialist language and/or the DA and Drupal vocabulary. I hope it is not too cumbersome. I need some feedback to finalize as there continue to be points I am unclear on.
For example, the second sentence here, from the original:
NOTE: No matter how many domains resolve to the same IP, you only need one instance of Drupal's settings.php file. The sites folder should be named 'default' or named for your primary domain.
Please note: it's written "sites" folder, not "site's" folder
In which case, if you were to follow these instructions to the letter, given that the only "sites" folder is the one delivered in the Drupal install, you might change its name...and then nothing would work. If this is a typo and the intention was to indicate the "site's" folder, being I suppose the folder (directory) in which Drupal has been installed, one could name it default, but that strikes me as a dangerous suggestion to be made so simply and I think that it is better to just tell people to put their site name on it until they learn what else they could or might want to do. Or, are we referring to the or a sites folder which may or may not be present with a given computer system's install and where we are supposed to store our "sites". At which point, I don't know anymore. I went with "site's" and eliminated the "default" suggestion in my edit.
To return to the crux of the matter: establishing a set of "as simple as can be" while remaining generic install instructions for the DNS configuration, I am still not totally confident of my analysis and their results. So, I am putting my "meanderings" here (below) rather than in the attached install.edit where it all comes down to one sentence.
For someone unfamiliar with the vocabulary, like me, who is reading every line of explanation in the hopes of straining a single, true and clear directive out of them, the presentation in "2.2 Server Configuration" is much too open. This presentation is centered on the host file configuration simply because that is all the it shows:
- ken.test => 127.0.0.1
- one.ken.test => 127.0.0.1
- two.ken.test => 127.0.0.1
- three.ken.test => 127.0.0.1
It is too simple to combine this "visual" with the phrase "the DNS record of your server must accept multiple DNS entries pointing at a single IP address" and assume that the above is all the configuration that is necessary. After all, we see multiple configurations (Ken.test, one.ken.test, etc) and they all seem to "resolve" to 127.0.0.1 which is a single IP address.
However, for a name-based virtual host (and this is what we are dealing with here), "In order for Apache to function properly, it absolutely needs to have two pieces of information about each virtual host: the ServerName and at least one IP address that the server will bind and respond to." dixit the Apache docs. This happens in the httpd.conf file where each virtual host is named and bound to an IP address in individual < virtual host > "blocks".
What I found interesting in agentrickard's example above (#6) was that the virtual host blocks weren't there (he may have simply not mentioned them?). Usually, they should be or it won't work. In the context of a localhost, working from the 127.0.0.1 IP address as above for example, we should find something like the following in the "virtual host" section at the end of the httpd.conf file:
[ and this conjecture could be totally wrong, but ]
Listen 80
Listen 8080
Listen 3000
NameVirtualHost 127.0.0.1:80
<VirtualHost 127.0.0.1:80>
DocumentRoot Applications/MAMP/htdoc/primary
ServerName primary
</VirtualHost>
<VirtualHost 127.0.0.1:8080>
DocumentRoot Applications/MAMP/htdoc/primary
ServerName subdomain1.primary
</VirtualHost>
<VirtualHost 127.0.0.1:3000>
DocumentRoot Applications/MAMP/htdoc/primary
ServerName subdomain2.primary
</VirtualHost>
In this example, the DocumentRoot, as I mentioned earlier, is the same in each of the virtualHost blocks. The documentRoot directive sets the directory from which httpd will serve files. For DA there is one Drupal installation and it is this installation built on a single database that is serving the files. So, if it is indeed true that the virtual hosts use (resolve to) a single IP address (different ports or not), it is equally important that they are served from (resolve to?) a single document root. If this last statement is true, it should be mentioned in the install doc., which is what I did, provisionally.
I also added some statements that try to avoid some of the recurrent error-questions that I have seen for DA in the forums etc., like "I see all my content everywhere" or "DA renamed all my sites with the same name"
Anyway, use what is useful and throw out the rest...
#10
One could also use the following method in httpd.conf:
<VirtualHost *:80>DocumentRoot /path/to/drupal/install
ServerName ken.test
ServerAlias *.ken.test foo.test
</VirtualHost>
In this case any subdomain (*.ken.test) and another domain foo.test resolve to the same location.
I'm unable to open this attachment - any chance you could post it as a regular txt file?
#11
Note that this patch #427258: Clean up domain administration would remove the ability to user 'ken.test' as a domain. Opinions wanted.
#12
here's the txt file: you lose the color marking for the edits
#13
Re: Note that this patch #427258
It is a little hard, as usual, to read what is really happening behind the eagerness of the programmer.
It seems some code has been consolidated: almost always a good thing
But what is the TLD validation story about. Validate? In reference to what or who.
Are you policing people or helping them.
It's not because you can install a bathtub or a garbage disposal unit in your car that you would want to.
Or, to get a bit closer, would you install special seats to make people sit up straight...then what would the lowriders do..etc
Whose regex? Are you getting together with ICANN?
http://www.articlesnatch.com/blog/2007/05/01/icann-releases-domain-check...
Finally, what is the advantage of TLD validation for DA users? Is there any?
As for the problems for localhost setups: do you really want to tell people, who have enough trouble as it is, that they can "still" do a localhost setup, but they have to do it this special way, only using names constructed in the following manner. (And I tend to think almost everybody who is thinking of using DA runs it through their machine first)
Which gets us to: you can get in my car and sit in one of my special seats that makes you sit straight but only if you back into the car butt first. If you should put your leg in first, it will get cut off and you won't get a ride.
Is this the kind of system you are suggesting? I mean, I may have read it all wrong...but you did ask for "opinions"
#14
@vic_d -- that last comment belongs in the other issue, please. And you might reconsider your tone.
#15
sorry. It was not my intent to be antagonistic, but simply to drive home the position you may be putting users in, if indeed my characterization is correct...and it could be a misinterpretation. Most people agree that added features should enhance either performance or the user experience (which generally comes down to saving work or avoiding error for the user). There is barely enough information visible on this patch to know exactly what enhancements it brings.
Here you asked for opinions on one possible outcome, the elimination of the most common, generally used subdomain name structure from the localhost environment. If I understand correctly, this blockage is due to TLD validation, which is why I mentioned it, here where you asked for opinions. My examples were added to show graphically what position you put people in when you ask them to step through a lot of hoops, in this case above and beyond the already, for most people but especially novices, daunting configuration ordeal.
Domain Access is a very promising module. It seems to be attracting a lot of attention recently especially from people who are looking to function in more than one language. The DA team is right behind this working to facilitate i18n integration (though I believe that some people like myself came to DA to move away from i18n, but that is another discussion). To cut to the quick and stay on topic: what does the elimination of the most common name structure from localhost configuration facilitate? Is there a significant gain elsewhere? In short, is it worth it?
#16
THIS IS THE WRONG ISSUE FOR THAT COMMENT.
#17
Back to the documentation issue. The problem with docs, is that you have to account for questions like #429278: Sudomain and 404 Not Found as well.
So in reviewing the documentation changes, do they help that user?
#18
Documentation serves to orient the newly arrived and to brief them on common problems and solutions, what to do & what not to do. The majority of Drupal modules, including DA, are in constant development. Ideally, the documentation would follow that development, as necessary, through edits and updates, but generally development gains a significant lead.
People who read documentation will have varying levels of IT sophistication as well as varying levels of knowledge about Drupal but they all come for basic orientation. In most cases, documentation is originally written by the developers, who have high levels of sophistication in both the IT & Drupal departments. This very sophistication can lead them to lose sight of how little a new arrival may know. He may be unfamiliar with commonly used Drupal terms or may carry a conflicting definition learned while using some other application. Because of this possibility, as much as possible, the doc should be couched in common terms, that may or may not lead to explanations of vocabulary that has taken on meanings specific to the Drupal (and/or in this case DA) set up.
If this is true, we see at least two things that documentation should do:
Orient & reassure the newly arrived by making every effort to include them in rather than exclude them from the circle of knowledge.
Educate the newly arrived by opening the way to Drupal application vocabulary.
In so far as the above tasks are fulfilled, it is not because you don't answer one specific question that the documentation does not help that specific asker / user elsewhere. Put another way, documentation is not limited solely to technical presentation (even if it should pretend to be). It has broader repercussions.
As to your/this user's specific question:
"So in reviewing the documentation changes, do they help that user?"
You answered it here:
"It is impossible for me to account for all server configurations."
which overrides:
"The problem with docs, is that you have to account for questions like...[specific situation]
Obviously, there is some hesitation about what path to take. This hesitation is well reflected in the case of configuration presentation. You have said that the doc was intentionally "thin" and sought to avoid presenting an overly generic set up while, at the same time, it needs to be understood that presenting all specific configurations is beyond a docs scope.
In this case, the only way forward is to present a single configuration as an example while surrounding it with sufficient definition and warning as to let anyone know that the presentation is just one example of the basic things that need to get done. Your choice, the localhost set up, was, in my mind, the best choice for this because a large majority of people do a first try on their computer and because everything necessary to configuration is accessible to the user on his own computer, which is very often not the case for sites housed with a provider.
However, in the doc, the presentation was not complete and this can very easily lead to misinterpretation. My own edit sought to complete the presentation, but actually my example of the httpd.conf set up was still a little too specific. I erred on the other side of the specific/generic balance by using "XAMPP". Nonsie's formula for the document root (brilliant) solves this: < DocumentRoot /path/to/drupal/install >.
The module is in development. So is the doc. Neither is ever perfect but both are part of a process. I offered to help things along because my own skill set is pretty well attuned to doc problems, much more than programming problems.
You do need to decide one thing though and that is whether you wish to stand by this kind of statement,
"The module (and its documentation) assume that you have this level of control and expertise."
(which I see as more of an off the cuff characterization of the situation at that time than a watchword, hopefully),
or move towards a greater degree of accessibility through a conscious effort towards inclusion and education.
#19
Please understand that although we are marked as rc6, the module is stable and in high use. Both of the maintainers run active sites with it, so we need to be very careful about making changes.
As to documentation, I was not asking for a dissertation, just a thoughtful review of your own edits.
I will accept the above as the latter. It is often better if someone other than the author writes the documentation, since the author can be too close to the code to see the issues. I have been hoping that you will contribute to documentation, but you seem to prefer to argue, which is damaging to our progress.
Let me rephrase clearly:
Are there any changes you wish to make to the edit in #9?
If not, can you roll a proper patch?
#20
Understood.
There are some changes that should be made to the patch in #9 and I have one question I will run here, but only after a careful review.
Then I can roll it without any problem.
Back soon.
#21
I am also going to open an issue for tracking Handbook documentation.
Perhaps we should have handbook pages devoted to things like CPanel, Plesk, Windows, and Unix installations instead of (or at least in addition to) adding them to INSTALL.txt. See #432268: Handbook pages for Domain Access.
#22
If we can get succinct instructions back from people who have handled these situations, it could certainly be included.
Once we see the information we gather and review it, we can decide how to best organize it.
#23
/me laughs at 'succinct'
The problem is that the reports are usually way too thin.
#24
onward and upward
#25
Here is an updated version of the doc patch.
I have moved the < before installing > section to the top. It seemed logical to do so since it is a warning not to rush into things with instructions on how to go about them. The table of contents and numbering system will have to be rationalized when the patch goes in. I will do that once these questions are answered.
QUESTIONS
1) I suggest putting the < before installing > section at the top, just before < Contents > and after the main title & subtitle.
- - - QUESTION 1: Are there any objections or other suggestions re this move?
2) At the bottom of section 2. Installation, we find the following statements:
On installation, all existing nodes [content] on your site will be assigned to the default (primary) domain for your web site as well as to all subdomains. In order to change this behavior, see sections 2.4 through 2.6 of README.txt
However, Section 2.6 does not exist in the ReadMe where we find:
2.4 Setting DOMAIN_INSTALL_RULE
2.5 Setting DOMAIN_SITE_GRANT
3. Permissions
- - - QUESTION 2: what did 2.4, 2.5 & 2.6 originally stand for in the ReadMe?
NOTE: The ReadMe and the Install texts need to be rationalized between them, but the first order of business is to finish this patch.
3) In the present file, I have not applied line breaks to the paragraphs. Personally, I find it a more flexible and readable situation where the reader can adjust line length as he wishes without having his paragraph break up if he makes his window too small. However, the rest of the file does have line breaks. Either I re-format the rest of the Install.txt or I re-format this file. What do you think: line breaks or no line breaks? My vote is for the latter.
- - - QUESTION 3: Line breaks or no line breaks?
4) Please re-read the patch. Inform me of any errors, suggestions or worries.
- - - QUESTION 4: otherwise, ready to commit?
#26
I have been on a short vacation. It may take the rest of the week to review.
Thanks for the patch.
#27
Lucky you.
Re: line breaks
I just realized that it all depends on what editor a reader opens the text in.
If it were BBedit for example, the text would be off the page without line breaks.
So I guess that's that and line breaks become preferable...
#28
I have to commit the code, and I use BBEdit. I try to ensure that all .txt documentation uses hard line breaks and < 80 characters per line.
This is so I can be sure that the text displays correctly on all viewers. (It also makes the docs easier to read when browsing the CVS repository,)
#29
Understood
re-formatting patch to < 80 characters per line while awaiting reactions on other questions.
Have a nice weekend
#30
- re-formatted to spec
- questions 1, 2 & 4 above outstanding
- followed issue # http://drupal.org/node/442868 ...food for thought.
have a nice day.
#31
answering the following question, which is more precise than the "needs review" tag indicates, would allow me to move on.
Perhaps "3. Permissions" used to be 2.6. And it should read "see sections 2.4 through 3".
Otherwise, it should be "see sections 2.4 & 2.5"
Or, something has gone missing, which I doubt
if you could confirm which arrangement is the correct one I could rationalize the two files: install x README. And go on to something else.
Below: copy of full question:
2) At the bottom of section 2. Installation, we find the following statements:
On installation, all existing nodes [content] on your site will be assigned to the default (primary) domain for your web site as well as to all subdomains. In order to change this behavior, see sections 2.4 through 2.6 of README.txt
However, Section 2.6 does not exist in the ReadMe where we find:
2.4 Setting DOMAIN_INSTALL_RULE
2.5 Setting DOMAIN_SITE_GRANT
3. Permissions
- - - QUESTION 2: what did 2.4, 2.5 & 2.6 originally stand for in the ReadMe?
#32
In the D5 version it is:
2.4 Setting DOMAIN_INSTALL_RULE2.5 Setting DOMAIN_EDITOR_RULE
2.6 Setting DOMAIN_SITE_GRANT
DOMAIN_EDITOR_RULE was deprecated in the D6 release.
#33
good
#34
Note: include NO_AUTO_VALUE_ON_ZERO issue for MySQL in strict mode in #474460 in either README or handbook
#35
Incorporated. Thanks!
#36
Automatically closed -- issue fixed for 2 weeks with no activity.
#37
I am using Mac MAMP and can't get this to work. I did the above mentioned virtual host thing. Safari can't find subdomain.
here is what I added to httpd.conf
MAMP uses port 8888 as default. The listen directie is already included in this file.
NameVirtualHost 127.0.0.1:8888
DocumentRoot /Applications/MAMP/htdocs/hyperlocaltest
ServerName localhost
DocumentRoot /Applications/MAMP/htdocs/hyperlocaltest
ServerName site1.localhost
DocumentRoot /Applications/MAMP/htdocs/hyperlocaltest
ServerName site2.localhost
People have made reference to host file - what is it, where is it, what do I need to put there, if anything.
TIA
#38
You can find information on setting up virtual hosts and modifying hosts file here - http://www.sawmac.com/mamp/virtualhosts/index.php
#39
With all the (marvelously verbose) information on this thread, I'm hoping someone can point me in the right direction - it seems like the information I need might well be here in pieces, but I'm having a hard time figuring it out. So here goes...
I'm running MAMP Pro with a base port of 80 - this allows me to have SSL installed (for testing only) and for me to have many different sites available for client review while the computer is on. I have MAMP pointing to a "sandbox" folder where each site lives in its own folder, so I can point the client to an IP (e.g., http://xx.xxx.xx.xx/[site name]) and everything works great without me having to have made any changes to the http.conf or the hosts file.
Here's the deal: I'm now working on mobilizing some of the sites; the best method seems to be domain switching. So I need to set up a subdomain for each site - something like http://xxx.xx.xx.xx/mobile.[site name] or http://xxx.xx.xx.xx/[site name]/mobile - either would be fine.
When I set up Domain Tools, slashes aren't allowed, so I can't enter the actual site base URL. And using the mobile.[site name] naming convention seems not to work for either mobile.[site name] nor [site name]/mobile.
Am I barking up the wrong tree with this module? Am I missing something relatively simple? Any guidance greatly appreciated... thanks much and Happy Holidays to all!