|
>We have also designed
a new script that you can use to test the install to try and find
obvious problems with the install.
install_test.cgi
Just download this script
and then just upload it to your store folder and set the permissions
to 755 and run it from your browser. The file has a .txt extension
so that you can download it so you will also need to change that
to .cgi.
Permissions:
99% of the time if you are getting an error when trying to run
agora.cgi or manager.cgi it is because you have the permissions
wrong or you are not running scripts under your hosting account user ID! By default, the CPanel, web install, and the telnet/SSH installation methods with extract the files with the permissions you need. So if you installed you store in of these ways, you my need to look at installing the wrappers. go to the wrappers sections of the Install guide, online manual or security page for more information. On CPanel installs, usually the wrapper is installed/operating and/or the store will run under your user ID automatically without the wrappers, so skip this section.
It is impossible
to tell you exactly what all the permissions should be, because
they will vary on every server depending on how the server is
configured. The main thing that you need to know is "Do scripts
on your server run under your user id, or do they run under a
generic id like 'nobody'"?
If scripts
on your server run as nobody they you have to have much looser
permissions on the files.
Here are just
some basic permissions rules that should help in this case (but we recommend that you switch hosting first before using these type of settings):
- If the
file is a script (.cgi) then the permissions need to be 755
- If you
have a file or folder that needs to be written to then the permissions
should be 766
- All other
files are usually 744
Depending
on the server configuration you may have to also set your .pl
files to 755
So both commerce.cgi
and manager.cgi need to be set to 755, and possibly
also all the .pl files that are in the /store/library/ folder.
In the admin_files
folder, data_files folder, shopping_carts folder
and the log_files folder you have configuration files that
need to be written to by the manager, or commerce.cgi so all these
files and the folders need to be set to 766. On some servers
I have had to set the shopping_carts folder to 777
so that the carts can be deleted.
Also the /protected/files/
folder usually works best when set to 777.
This brings
up another good point... I have seen a lot of people say just
to set everything to 777 to get it working. That is fine in some
cases, just make sure that you go back and then adjust the permissions
back down and test it after each file to get the permissions as
low as you can with the cart still functioning properly. If you
leave the permissions at 777 you are just opening your self up
for trouble and the files/folders will not be secure.
Also I have
ran into several server that will not function if you have a file
or folder set to 777, so keep this in mind.
Here is an
article that was recently posted in another mailing list that explains
this very well:
|
Most of
our webservers are compiled with Apache's suexec support.
This means that all CGI scripts are automatically run as your
own user ID without any kind of changes or modifications to
your scripts.
Suexec
has many security features built-in, which can cause problems
for the unaware, however. Many commonly available CGI scripts
recommend setting various files and directories to world-writable
permissions (777). Your scripts will not work if the CGI script
itself has 777 permissions, or the
directory it resides in. You may have other problems as well
if files that it must write to have world-writable permissions.
Finally, all files and directories must be owned by yourself,
not nobody.
Most scripts
will instruct you to set various write permissions in their
install instructions--you do not need to do this. Setting
any file, whether executable or data, to a world-writable
state is very dangerous and should
be avoided at all costs.
Also,
when scripts are run under your userid, it will not take into
account your various environment variables, so umask settings
for default file permissions will probably not work. There
is a simple fix to this, however.
If the script in question is a perl script, add the following
somewhere near the beginning of your script:
umask
022;
|
Troubleshooting Errors:
Often times the error
that you get from the browser is just a generic 500 error, and that
basically just tells you that the script is broke. Basically it is useless....
error.log:
The very first
thing that you should do is check the error.log file
that is located in the "log_files" folder. This may not
always work depending on what the problem is, but sometimes if
there is a problem it will log the problem in the error.log and
you may be able to see what the problem is.
Telnet/SSH:
If you
have telnet or SSH access to your server the first thing you can try
is logging in and running the script from the command line. Just
cd to your store folder and then type in 'perl agora.cgi'.
This should give you a better error message then just a 500...
In some cases you will find that at this point the script runs
just fine from the command line but it will not work from the
browser.
If this is
the case then you probably have a permissions problem with a file.
Usually this is caused by the fact that script on your server
run under a generic user id such as "nobody", but when you login
from telnet (or SSH) the script is running under your user id. In this
case running it from telnet or SSH will not help you at all.
Set Cart to Test Mode:
This handy tool will send diagnostic to the screen when navigating thru the script. To set this, log into the store manager (manager.cgi). - click on program settings link.
- click on the free form logic manager button.
- In the top box add this line:
- then try out the cart
This assumes you can run the cart and the store manager.
make sure to delete this command immediately when you are finished or your cart will will show information you do not wish others to see and will also expose you to cross scripting vulnerability attacks.
Testing Cart IDs:
This handy tool will send diagnostic to the screen when navigating thru the script. To set this, log into the store manager (manager.cgi). - click on program settings link.
- click on the free form logic manager button.
- In the top box add this line:
- $sc_debug_track_cartid = 'yes';
- then try out the cart
This assumes you can run the cart and the store manager. this will allow you to track the cart ID as you navigate. Not that some portions should stay the same as you navigate from page to page. Do not be alarmed that part of it changes. This is normal. make sure to delete this command immediately when you are finished or your cart will not take orders.
A great Troubleshooting Script:
This great script can be a lifesaver. This script will basically let you run your script just like you
were running it from the command line of the server and should
give you a easy to understand message of what the problem is.
AdminPro:
Since this script runs from the browser it will also run as "nobody" in this case and return
an error message that will probably let you know exactly were
the problem it.
Click Here to Get AdminPro Now!
This is one of the tools that everyone who is working with CGI script should
always have handy.
NOTE: make sure you delete this file from your server after you
are done solving the problem, or put it in a password (.htaccess) protected folder
because it is a powerful script and you would not want someone
else to find it on your server.
Other Options for Help:
If after all that you are still not able to figure out what the problem is then there
are two great resources on this site to get help.
Yahoo Forum - Mailing List / Message Board:
The forun has been running for years and if packed with thousands of posts that you can search through to find the answers to your questions. If you cannot find the answer then just post your question in the forum. Other forum members do their best to answer as many of the questions as they can.
Pro Membership:
Probably even a better option is to sign up for our Pro Membership. Pro membership offers a members only bbs, a pro members forum at Yahoo, extra files for pro members only as well as other goodies to help you. Lifetime Pro Members enjoy access to live chat areas for real time interaction with us and other pro members. There are currently at the time of this article over 400 Pro Members and membership is growing every day. Many of these people have been using AgoraCart for years, and they are more than willing to help answer questions that you may have. We also try to answer more indepth and more frequently in the Pro member support mediums
Contact an Authorized Solutions Provider:
If after all that, or you just don't want to take the time you can always contact one of the ASPPs regarding professional store installaions/upgrades, store/website design, custom programming options, new hosting, or paid tech support options.
|
