I've loaded all the bdman files into my cgi directory, modified the default.cfg for the URL to the cgi directory, set the permissions, fired up the system, and failed.

I fumbled around until I got the debugger turned on, fired up the system again, got to the Login window, used the supplied default "admin/admin" userid/password, and got, and still have the message:

Error Message : unable to open auth file: ./auth/. Reason: ACL/SRL denies write access

I searched the forum, found that meant the auth directory didn't have correct permissions set, and misc suggestions I chmod it to 777. Well, I can't. The host (XO, formerly Concentric) has it's own cgi permission setter, with read/write being the best it gets. It will reject telenet chmods, suggesting I use the CGI Permissions System, which of course I have. I also called tech support at the host, they confirm the 'auth' directory (and the entire CGI directory for that matter) do indeed have read/write permissoins.

There is currently only one file in the auth directory, named index.html. Should there be more? That's all that came with the download from Gossamer, but I might have missed something in the readme file about authorization.

What now? Is there a simple answer? Usually at this point in installation it's a dumb error on this end, but I didn't find any nourishment in reading the other forum messages about how this eventually got solved. Lots of folks had the problem, but no solution made the messages.

Thanks in advance.

Wade

Search for 'concentric' it seems like most have just changed to a host provider that allows you to properly chmod your files. Do they even allow you to set 755 for the .cgi files?

The /auth directory does only contain an index.html file, but is used to hold the login information of registered users, so it must be 777.

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

If you're suggesting a host change, that's out of the question.

Since it's a shared host, they eliminate chmod, but have the moral equivalent in their site management menu. I'm assured it's read/write (which I can see from the site manager), is mounted properly, and will execute any script that tries to execute.

I also run a UBB bulletin board on the same host which requires 777 and works fine. It too has password protected users, so what's the difference?

This is the first script I've found that won't run there, which makes me suspect we're focussing on the wrong issue. My guess is something to do with the path, but am unable to figure it out quickly, as I need to.

Wade

Post your default.cfg as a text file, or stick it out on your website so somebody can take a look at it.

It could be a "path" issue, but probably not. It seems to me you'd get something like "file not found" or "no such file or directory" if it was the path that was wrong.

What ftp program do you use?

>>post default.cfg

Tough at the moment, as I've transited to the marina, am standing outdoors on the laptop, not in the 4 computer office.

However: Only change to default.cfg from it's birth state is the URL to the cgi directory, which is

http://mysite.com/cgi

Its the URL.

The unix path in the db.cgi file has NOT been edited, and remains "."

I use CuteFTP, and locked it to ACSII for the transfers.

On the topic of paths, for my shared host, one cannot get to the unix root directory, living instead in virtual space so that our cgi experiments can't clobber the neighbors.

there are three directories
/cgi
/logs
/web

all dbman files are in the /cgi directory, including the /auth subdirectory.
The /cgi director and /auth subdirectory have read/write and execute permissions

If I have the debugger off, and fire the script, I get a message "internal error, turn on the debugger, etc". Turning on the debugger gets "Internal Error, etc" followed by a dump of many varibles, but NO error message. Up pops the login screen, with verbage instruction use of admin/admin userid/password, etc. Using any of the pairs of userid/passwords gets the "access denied" message mentioned in the opening thread.

I'm basically at square 1.1

Wade

Look in the FAQ under the section "Troubleshooting" for a thread called "Default passwords don't work" and see if that will help with not being able to login. Encryption varies on different servers which is why it may not recognize your login.

Also install the snippet of code in a thread called "Debugging - How To Obtain Useful Error Messages" which may help you pinpoint any errors.

Unoffical DBMan FAQ

http://creativecomputingweb.com/dbman/index.shtml/

Lois:

>>Look under Troubleshooting <snip>

Thanks a bunch. Looks like two helpful hints, and I took the time to visit both Unofficial DB and your section of it.

There may be a delay between my picking up this message and taking any action, as I'm packing for 2 weeks in the Galapagos, 1 week landside and 1 week diving, and the whirlpool of getting working dive gear, UW cameras, strobes, etc has moved ahead of the "get the database working" project. Will return mid may and hit it again, as it's not going away. I'm on the traveling laptop, which doesn't have the script installed, or I'd play with it tonight.


Wade
http://www.wadespage.com

Wade,

I don't know if you found your answer. This post is rather old. Here's what I found when dealing with XO.



Installing CGI at xo.com

Web hosting provider www.xo.com is a large company which has recently acquired many smaller web hosts. Many customers are using xo.com.

xo.com has set up their systems is a very convoluted way. It is so bad that they are almost certain to change things someday, but so far they haven't. One very nice thing about xo.com is that they answer their phones quickly -- you can call them at 888.699.6398.

The following two items must be read for purposes of setting up CGI on xo.com.

All CGI scripts must be placed in the "/cgi/" folder.

If you are using the auto-installer, enter your values like so:
Your Website:
http://www.example.com/cgi/
FTP Path:
/cgi/

For xo.com, the Perl Path, Perl CGI Extension, and FTP Server will all be auto-detected correctly.

The install will appear to be successful. However, the scripts will not be able to write to any files. The error returned will be something like "permission denied - ACL/SRL denies write access".

To correct this, you will need to log in to the xo admin area. The auto-installer is not smart enough to do this for you.

Log in to admin.xo.com (will open in new window).

Click on the Standard Login link. Login using a username like "user@example.com" with the password they provided.

Once logged in, you should see the admin area. Choose "Control Panel" => "Manage Site" => "CGI Permissions".

If you don't see these options, it may be because xo.com recently acquired your web host and they have not ported things to their system. If so, you need to call them at 888.699.6398 and request a custom change to your permissions.

Choose "Create Zone" for the "/cgi" path.

Choose "Back". There will then be a list of your zones, starting with "Default CGI Permissions". Below that will be listed the "/cgi" zone, as a link. Follow the link.

Choose "can read and write files in this directory" for the "/cgi" and "/web" paths. Then submit the changes using the "Update Zone" button.

Then click "Back" and then click "Advanced Zone Options".

Mount directories "/web" and "/cgi" as "Read-Write".

Your CGI scripts will now be able to access the file system.

Please let me know whether these instructions are helpful to you, or whether they seem to no longer apply to the xo system.





Hope this helps.