| Author | Post |
|---|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Thu May 19th, 2005 07:39 pm |
|
This Topic is closed
Refer to 6.04 instructions
Version 6.03+ only
Step-by-step instructions for creating one installation on a server that can run child installations in other domains on the same server.
This configuration allows a child installation in one domain to use the code files in a parent installation on the same physical server. The child installation contains only the wrx.cgi and a set of data files that are unique to the domain that it is installed on.
Security
The concept requires a Perl script in a child domain to be able to read files in the parent installation in a different domain. On most Unix servers (Plesk in particular) it is a security violation for a script in one domain to read files in another domain. Look at the permissions on the domain's root folder. If it is 751 or 750 then a script outside of that domain is not allowed access to the domain. To make this kind of EditWrx multi-domain installation work you must change the permissions on the domain's root folder to 755. Doing so will allow a script from a different domain to read any file inside the domain.
If you have sensitive files in the domain that should not be readable by scripts in other domains you can do one of two things:
- Place the sensitive files in a folder inside of the domain and give that folder the same permissions as was originally set for the root folder.
- Create a fully qualified sub domain and place only the EditWrx installation in that sub domain. The sub domain will need to resolve for browser access and it must have it's own domain root folder (which will have the 755 permissions).
Parent Installation
Install EditWrx on the parent domain. Get that installation running properly. For 6.03+ installations no changes are necessary.
Child Installation
Create a child installation in another domain on the same server. On the child domain install only the files:
/editwrx/wrx.cgi
/editwrx/library/data/config.txt
/editwrx/library/data/users.txt
/editwrx/library/data/changelog.txt
/editwrx/library/data/sessions.txt
The wrx.cgi on the child installation needs to be a copy of the wrx.cgi on the parent. It uses the same paths and URLs as the parent wrx.cgi with only the following exception:
Open wrx.cgi. Edit the $url_to_editor to contain the full URL to wrx.cgi in the child domain. Edit the path for $path_to_data to contain the full server path to the editwrx/library/data folder on the child domain. Edit the path for $path_to_domain to contain the full server path to the web home folder of the child domain.
If you are using Apache, you may change the value for the $path_to_data and $path_to_domain to
$path_to_data = $ENV{'DOCUMENT_ROOT'}."/editwrx/library/data";
$path_to_domain = $ENV{'DOCUMENT_ROOT'};
and let the server resolve the path for the child domain.
- On config.txt you need to get and manually enter the domain license for the child domain. If you have a Developer KEY you can do that at http://editwrx.com/generate_license.html , if not, you will need to buy a Domain License at http://editwrx.com/purchase.html
- By default, the startup "admin" user's password in users.txt is "start". You can change the users.txt to include only admin=start to give the child domain a clean startup. When "admin" logs in with the "start" password the user will be prompted to create a different "admin" password.
Automatic Updates
Version 6.03+ automatically knows if the installation is a child installation. If it is a child installation all capability and options for doing automatic updates are voided. If it is the parent installation, automatic updates are available in Site Parameters and User Setups in the Admin Control Panel.
Last edited on Thu Jun 30th, 2005 05:05 pm by Keith |
Rob
Member
| Joined: | Wed May 25th, 2005 |
| Location: | |
| Posts: | 21 |
|
Posted: Tue May 31st, 2005 05:05 pm |
|
Can we discuss the pro's and con's of having one main installation of this great program vs. independent installations on each domain? In your opinion, what questions should be asked to determine which scenerio is best, for example, "How many domains will be using EditWrx?"
My main question is regarding the upgrade process: When updates to the script come out, will only the "parent" installation need to be upgraded, or will individual files on the "children" also need to be changed / upgraded?
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Wed Jun 1st, 2005 03:49 pm |
|
There are 2 main reasons for using a multi-domain installation. The main purpose answers the question about updates.
In a parent/child setup, only the parent gets updated. No files on a child installation get changed during an update. The files in /library/data are the only files that are uniqued to each installation and they are not updated. Therefore, when you update the parent all child installations are working from the same version. This makes it easier for you to deal with your client's questions because you know what version they are on.
The second reason for using a parent/child setup is that your client does not get access to the code files and therefore cannot easily move the installation to another server. File in the ini, htm, and lang folders are not accessed by a browser so you can put an .htaccess file in each of those folders with a files deny declaration to prevent your clients from opening the source code files in a browser.
|
tkmc
Member
| Joined: | Wed Jun 8th, 2005 |
| Location: | |
| Posts: | 20 |
|
Posted: Wed Jun 8th, 2005 08:19 pm |
|
| Is this not more insecure than a single domain installation? I would think that having the files world readable would be dangerous.
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Thu Jun 9th, 2005 02:02 am |
|
Is this not more insecure than a single domain installation? I would think that having the files world readable would be dangerous.
That would be true IF all of the files were kept on the sub domain. But they are not. The files in the /data folder remain on the child domain and have exactly the same protections as the same files on a single domain installation. The passwords (stored in Unix grade encrypted format) are in /data/users.txt.
The library files stored on the common sub domain for all children installations to read are entirely generic. In fact, it would be foolish for someone to build a script on the server to retrieve those "world-readable" files from the common sub domain - they can easily download them at editwrx.com neatly packaged in a zip file.
It is important to note, an actual editor should NOT be run from the common folders on a multi-domain installation. That is why we recommend creating a sub domain. That sub domain should contain ONLY the editwrx files and should not contain a working /data/users.txt or /data/config.txt or even a wrx.cgi. That common set of files should be a library only.
|
tkmc
Member
| Joined: | Wed Jun 8th, 2005 |
| Location: | |
| Posts: | 20 |
|
Posted: Thu Jun 9th, 2005 12:39 pm |
|
Thank you for the info. My only concern was that program files would be world readable and thus could be used to find and exploit security holes in the code. I suppose library files are OK though with the precautions listed above.
Thanks for the help.
|
tkmc
Member
| Joined: | Wed Jun 8th, 2005 |
| Location: | |
| Posts: | 20 |
|
Posted: Tue Jun 14th, 2005 03:02 pm |
|
| Should the $path_to_domain be changed to the domain of the child installation?
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Tue Jun 14th, 2005 04:44 pm |
|
Should the $path_to_domain be changed to the domain of the child installation?
Yes it should. The instructions above have been changed to include that instruction. Thanks for catching that oversight, tkmc!
|
tkmc
Member
| Joined: | Wed Jun 8th, 2005 |
| Location: | |
| Posts: | 20 |
|
Posted: Tue Jun 14th, 2005 07:59 pm |
|
I must be doing something wrong because I can't get it to work. I am getting a 500 Internal Server error.
I installed EditWrx on a subdomain on my site, "editwrx.mysite.com". I discovered that I had to change the ownership of the directories created. Got it working.
I then copied the files:
/editwrx/wrx.cgi
/editwrx/library/data/config.txt
/editwrx/library/data/users.txt
/editwrx/library/data/changelog.txt
/editwrx/library/data/sessions.txt
to "othersite.com". I presumed that I should also create the directories like above (editwrx, editwrx/library/data) for the files.
use lib '/home/tkmc/public_html/editwrx/library/mods';
$url_to_editor = 'http://editwrx.mysite.com/editwrx/wrx.cgi';
$url_to_library = 'http://editwrx.mysite.com/library';
$url_to_ikons = 'http://editwrx.mysite.com/ikons';
$path_to_library = '/home/tkmc/public_html/editwrx/library';
$path_to_domain = $ENV{'DOCUMENT_ROOT'};
$path_to_data = $ENV{'DOCUMENT_ROOT'}."/editwrx/library/data";
I am wondering if the "$url_to_editor" is wrong. I am also wondering what the diffrence is between "$url_to_library" and "$path_to_library". Should both "use lib" and "$path_to_library" be specified as urls?
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Wed Jun 15th, 2005 12:48 am |
|
I discovered that I had to change the ownership of the directories created.
If you had to do that, your server is crippled and you should uninstall editwrx until your server is fixed. On a securely configured server, all files in a domain (or subdomain) are owned by the the FTP user for that domain (or subdomain). Installer.cgi is therefore owned by that user and can only create files and folders owned by that user. If suExec was compiled properly it would be impossible for installer.cgi to have created files or folders with the wrong ownership.
I am wondering if the "$url_to_editor" is wrong
Yes it is. The editor is in your child domain (only the library/ikons is in the parent), therefore the $url_to_editor must point to the wrx.cgi in your child domain.
I am also wondering what the diffrence is between "$url_to_library" and "$path_to_library".
A URL is the address that a browser uses (http://something). A path is the physical path on the computer to the file, it is used by programs on the server to find a file for reading or writing to the file. The two may point to the same file, but a URL starts at the domain's entrance, a path starts at the server's root.
Should both "use lib" and "$path_to_library" be specified as urls
Why would they? Both require a path from the server's root, not a URL from the domain's root.
|
chefdackel
Member
| Joined: | Wed Jun 15th, 2005 |
| Location: | |
| Posts: | 2 |
|
Posted: Wed Jun 15th, 2005 05:00 pm |
|
I also get the 500 error on windows 2000/IIS5. I am not sure access to files in folders other than the actual domain foldertree is a security problem for IIS? Maybe someone solved this issue, any hints are welcome.
|
tkmc
Member
| Joined: | Wed Jun 8th, 2005 |
| Location: | |
| Posts: | 20 |
|
Posted: Wed Jun 15th, 2005 07:16 pm |
|
I had to change the permissions because I uploaded with root.
I was not thinking straight when I asked about the path/url thing. Brain had a core dump ... needed to reboot. ;-)
As for my problem I checked the logs and find the following:
Can't locate /home/tkmc/public_html/editwrx/library/routines.txt in @INC (@INC contains: /home/tkmc/public_html/editwrx/library/mods /usr/lib/perl5/5.8.4/i686-linux /usr/lib/perl5/5.8.4 /usr/lib/perl5/site_perl/5.8.4/i686-linux /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl .) at wrx.cgi line 35.
Lines 33-35 in the wrx.cgi file (I have not changed them):
$path_to_library =~ s!/$!!;
$routines = $path_to_library."/routines.txt";
require "$routines";
I have very little experience with perl so forgive me if my question is basic. What is line 33 for ($path_to_library =~ s!/$!!;)?
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Wed Jun 15th, 2005 08:29 pm |
|
Can't locate /home/tkmc/public_html/editwrx/library/routines.txt
Is there a file named routines.txt at that path?
1) If not, then you've got the wrong path in $path_to_library. Fix it so the path points to routines.txt in the parent domain.
2) If that is the correct path, then you have permissions problems. The wrx.cgi script in the child domain is owned by the FTP owner of the child domain and needs to read routines.txt which is owned by the FTP owner of the parent domain. Therefore, routines.txt must have world read permissions (0644) and all of the folders in the parent domain path to routines.txt must have world read permissions also (0754 or 0755).
What is line 33 for ($path_to_library =~ s!/$!!;)?
It removes any trailing / on that path in case one was added by mistake during editing.
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Thu Jun 16th, 2005 03:43 pm |
|
I also get the 500 error on windows 2000/IIS5
As far as I know, a multi-domain installation will not work on IIS server. The Windows permission system keep a script in a domain from reading any files outside of the domain path, so it can not read library files residing outside of it's own path. I don't think there is any way around this without opening major security issues for the server.
|
chefdackel
Member
| Joined: | Wed Jun 15th, 2005 |
| Location: | |
| Posts: | 2 |
|
Posted: Fri Jun 17th, 2005 10:57 am |
|
>>
I don't think there is any way around this without opening major security issues for the server
<<
One idea for better security of windows installations:
Restricting direct browser access f.e. to the library/data folder can be done in IIS configuration by restricting access to the only IP-address 127.0.0.1. Direct browser access to files in the library/data folder results in
HTTP 403.6 - Forbidden: IP address rejected
Internet Information Services
Access from within editwrx is not rejected. Any ideas for more security settings on a windows installation are welcome.
|
tkmc
Member
| Joined: | Wed Jun 8th, 2005 |
| Location: | |
| Posts: | 20 |
|
Posted: Mon Jun 27th, 2005 01:32 pm |
|
Is there a file named routines.txt at that path?
Yes
1) If not, then you've got the wrong path in $path_to_library. Fix it so the path points to routines.txt in the parent domain.
It is correct. You can see it in the variables that I posted.
2) If that is the correct path, then you have permissions problems. The wrx.cgi script in the child domain is owned by the FTP owner of the child domain and needs to read routines.txt which is owned by the FTP owner of the parent domain. Therefore, routines.txt must have world read permissions (0644) and all of the folders in the parent domain path to routines.txt must have world read permissions also (0754 or 0755).
I have set the owners of all the files to the owners of the domain that contains the files. The routines.txt file has 644 permissions and the domain root has 755 permissions.
Someone on another forum suggested that I may need to add a line into the httpd.conf file so that other domains can access this common path if you have open_basedir active. Could this be the problem?
|
Keith
Moderator
| Joined: | Fri Apr 8th, 2005 |
| Location: | |
| Posts: | 603 |
|
Posted: Mon Jun 27th, 2005 03:47 pm |
|
Someone on another forum suggested that I may need to add a line into the httpd.conf file so that other domains can access this common path if you have open_basedir active. Could this be the problem?
open_basedir is a PHP directive. It will have not effect on Perl at all.
It is possible that the user account folder (the folder containing the domain root) for the parent has a permission keeping the child script from entering the parent path tree. That folder's permissions need to be set at 0755.
Also make certain that /editwrx folder and all of the folders inside /editwrx on the parent have 0755 permissions.
Since files in the parent are owned by the parent user, and the script in the child is owned by the child user, all files and folders in the parent (and leading to the poarent) must have world read permissions.
|
tkmc
Member
| Joined: | Wed Jun 8th, 2005 |
| Location: | |
| Posts: | 20 |
|
Posted: Tue Jun 28th, 2005 01:26 pm |
|
| That was the problem ... part of it anyway. It brings me to the login screen now, but the text and graphics do not show up. For example the submit login button shows up but no text is on it. I'll look more into it in the next couple days.
|
Current time is 07:37 pm | |
|
