| Author | Post |
|---|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 583 |
|
Posted: Thu Feb 23rd, 2006 06:49 pm |
|
As of version 6.11.060223 There is a simpler way to create child installations running shared library files from a parent installation.
First, create a parent installation and get it running. Create a domain license for that installation using your Developer KEY on the Site Parameters tab of the Admin Control Panel.
On child installations create /editwrx/library/data folder and populate that folder with the same files as in the parent installation's /editwrx/library/data folder.
Change the /editwrx/library/data/users/txt to contain only
admin=start
so that the user of the child installation can begin by logging in as admin with the word "start" for their password.
Do not change the $DOMAIN_LICENSE in /editwrx/library/data/config.txt file. The child installation will use the parent installation's domain license and there is no need to generate a separate license for the child installation.
Install a wrx.cgi on the child installation. The $child variable must read $child=1; The variables
$url_to_library = "url_to_library_in_parent_domain";
$url_to_ikons = "url_to_ikons_in_parent_domain";
$path_to_library = "path_to_library_in_parent_domain";
in the sub parent subroutine must be changed to contain the full urls and full path to folders in the parent domain.
This change from previous parent/child setup allows you to create a skeleton system for installing child installations at the time the child domain is created. The change is that the child installation can now validate using the domain license from the parent installation allowing the parent installation's license to be embedded in the config.txt of the skeleton set of files.
The parent domain must be readable by scripts from other domains. On most Unix/Apache servers this requirement will mean that the domain's entrance folder (public_html, httpdocs, whatever) will need 0755 permissions. If you have sensitive files in the parent domain that should not be read by scripts from other domains, give those sensitive files only 0600 permissions.
Last edited on Sun Feb 26th, 2006 10:38 pm by Keith |
astro254
Member
| Joined: | Thu Mar 2nd, 2006 |
| Location: | |
| Posts: | 4 |
|
Posted: Fri Mar 3rd, 2006 11:09 pm |
|
Will this work if the parent is really one of the children?:
top domain is /xxx.org
within it are
xxx.org
web1.xxx.org
web2.xxx.org
I can install in the top level xxx.org, but cannot run wrx.cgi there, because /xxx.org points to /xxx.org/xxx.org; that is, to the sub-domain.
Can I install in xxx.org/xxx.org and then use your instructions for the other children and point to the first child?
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 583 |
|
Posted: Fri Mar 3rd, 2006 11:52 pm |
|
I hope so. The problem is that nested domain servers can produce weird environment variables. There are no standards for using Apache's nested configuration so everybody tends to invent their own environment variables.
Create a cgi script named env.cgi and run it in each nested domain. The contents of the script should be:
#!/usr/bin/perl --
open(X,">x.txt");
print X "X";
print "Content-type: text/html\n\n";
for (sort keys %ENV) {
print "<br><tt>$_=$ENV{$_}</tt>\n";
}
Look for a true DOCUMENT_ROOT variable. By "true" I mean that it's path needs to be the real physical path to the domain's directory that home page is in.
Look for a true SCRIPT_NAME. The path for that needs to be the path from the domain's DOCUMENT_ROOT to env.cgi. The path must begin with a slash.
Look for a correct HTTP_HOST, it should contain only your domain name (www . myDomain . com)
If all that checks out, then see if env.cgi created the "x.txt" file and if so if it contains "X". If env.cgi did not create x.txt, change open(X,">x.txt"); to open(X,">../x.txt"); and run env.cgi again and look for x.txt one directory up from env.cgi. If neither run created x.txt or failed to write to it, then all of your domains are running under the same user instead of under the owner of each domain and you can not run EditWrx on your server (and should not run ANY content management system at all on the server). Remember to "refresh" your FTP client's view of the directory to see if the x.txt file was created.
If you've gotten that far OK, then do a full installation in one of the domains and make sure it works, that's the parent. Then try creating a child running off of it. The main problem you may encounter is giving a permissioned path to the parent that the child can read. Remember, each child is a different Unix user and the path to the parent installation must have "read" permissions for "other" Unix users.
|
Martin
Member
| Joined: | Tue Jun 14th, 2005 |
| Location: | |
| Posts: | 66 |
|
Posted: Tue Jul 4th, 2006 05:00 pm |
|
Just a quick question that has been on my mind for years now.
What's the point of creating child domains?
What's the advantage over just setting up editwrx completely?
Martin
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 583 |
|
Posted: Wed Jul 5th, 2006 04:48 pm |
|
Martin
There is only one advantage to using child domains. Back on version 5 we did not have the automatic update feature, so a single installation made sense, update one updated all. The only advantage for version 6 is if the owner has customized parts of EditWrx and needs to tweak some code after an update.
A single version also give the owner the illusion that their client can not steal the installation (move the domain and install it on another server). A single installation makes that difficult, but it is certainly doable. All the domain owner needs to do is download a shareware version from editwrx.com and use the $DOMAIN_LICENSE in config.txt to relicense on the new installation. Or they can pull all of the files from the parent library folder, though they would need to write a Perl or PHP script to do it.
|
Martin
Member
| Joined: | Tue Jun 14th, 2005 |
| Location: | |
| Posts: | 66 |
|
Posted: Wed Jul 5th, 2006 05:38 pm |
|
Thanks for the reply Keith!
Martin
|
Current time is 05:57 pm | |
|
