I have read everyone elses post about not being able to install. Taking all the current advice and spending a few hours with my hosting services tech support I still get the ole access forbidden [403]. I have checked and rechecked and even had tech support check the file db.cgi is 755 or rwxr-xr-x. I have the first line set at #!/usr/local/bin/perl like my site says to and the basic script states and I have tried my path as follows which was confirmed by my host service and seems to work to view the other scripts like default.cfg http://server101.hypermart.net/horsesearchplus/cgi-bin/dbman but I still get the 403 error. I know some one will post saying just turn your chair around 360 degrees and all will be fine but man this has got me stumped. I know it is something simple which is probably why I have not seen it. Please help me!!!

Maybe this will help, I am trying to access the file thru the path in my browser of http://www.horsesearchplus.com/cgi-bin/dbman/db.cgi and this gives me the 403 error but I mistyped the path just now and actually ask for a file that did not exist and it said the same 403 error. I had asked for default.cgi Could this be some basic issue with cgi on my hosting servor? If I ask for ...../fred.cfg it returns file not found 404 but asking for fred.cgi is says access denied. Am I on to something here or just wasting key strokes?

Ok I found a post in another newsgroup that told me to change my .htaccess file to Options +ExecCGI -indexes # which was Options None and now I can execute the script but now I get a 500 error and it says it is fatal. So with so little time left before I croak (fatal error here) I at least think I making progress. Hope this little episode helps someone. Does anyone have any ideas why the 500 error would occur?

What is the url you have setup in your .cfg file for:

$db_dir_url =

What does the Hypermart error log say?

500 errors are usually due to one of two things (or both), at least when you're first setting up the script. Either your path to Perl is incorrect, or you have uploaded the db.cgi script in binary mode.

Try uploading the db.cgi script again, this time being *absolutely certain* that it's in ASCII mode. And recheck your path to Perl.


JPD
http://www.jpdeni.com/dbman/

error log says no erros

this is the url in my .cfg file ----> http://www.horsesearchplus.com/cgi-bin/dbman

i even removed front page extensions thinking they may have me messed up

This #!/usr/local/bin/perl is the path in the db.cgi file and this is what hypermart says to use.
This is the $db_script_path = "."; way the other other path statement looks in db.cgi.

I went and resent the whole script again but still get that servor error 500 with no error logs.
I double checked and for every file I uploaded the cuteftp file log says opening ascii transfer mode so it was uploading using ascii.

$db_dir_url = "http://www.horsesearchplus.com/cgi-bin/dbman"; is the path in my .cfg file.

could there be anything in the .htaccess which would limit these scripts from working

it looks like this
# -FrontPage-

Options +ExecCGI -indexes #

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>
AuthName www.horsesearchplus.com
AuthUserFile /data1/hypermart.net/horsesearchplus/_vti_pvt/service.pwd
AuthGroupFile /data1/hypermart.net/horsesearchplus/_vti_pvt/service.grp

Here is another idea or observation. If I ask for anyfile beyond the .../cgi-bin directory I get that 500 servor error. Even if the file does not exist. I also get the 500 error when I try to view the readme.txt in that directory for example http://www.horsesearchplus.com/cgi-bin/dbman/readme.txt also gives me a 500 internal servor error. And I can see and view the readme file from cuteftp.

dazed and corfused
greg

Well I figured it out. Anything put into the cgi-bin directory drew a 500 series error so I made a different directory calling it cgidbman at the same level the old cgi-bin directory was and loaded the scripts in there. All is fine now. Talked to tech support and they coul dnot even get their test scripts to work in the cgi-bin diectory but it worked fine in my alternate cgi directory. No one knows why it is like this but I wonder if anyone else has ever had this problem.

Could be that your old cgi-bin directory was not set to 755 (drwxr-xr-x).

Regards,

Eliot Lee

Nope, checked it many a time and it was set to 755. This one had me stumped.