I successfully set up links 1.1 just how I wanted it. I have been trying to setup links 2.0 but cannot figure out a cgi error.
Links 2.0 using the site_html.pl that comes in the zip file works perfectly and I have no problems. When I try and modify site_html.pl to have it looking the same as my links 1.1, everything seems to work ok except I can't validate or delete any records.All I get in the admin screen after clicking the "Validate/Delete records button" is :

CGI ERROR
==========================================
Error Message : error in validate_records, unable to open db file: /usr/www/htdocs/abat/links/admin/data/links.db. Reason: Permission denied
Script Location : /blah/blah/blah/links/admin/admin.cgi
Perl Version : 5.004

---------------------------------------
This does not work even if I have links.db permissions set at 777
Is there a relationship between site_html.pl and validate_records?

Please help somebody

  
No relationship at all other than they use the same databases. site_html.pl is used by nph-build.cgi. The admin screens are controlled by admin.cgi and admin_html.pl. None of the information in site_html.pl is used by the admin scripts.

Try changing the permissions on the data directory to 777 and see if it helps.

[This message has been edited by Bobsie (edited March 21, 1999).]

No changing the permissions of the data directory has no effect. I have found that if I telnet in and change the permissions of the links.db file from 666 to 777 just before I validate any records it will work. But the next time I try to validate it brings up the cgi error. Also when the cgi error appears the validate.db data is cleared and the database counter is incremented, but no data is transfered to the database.

any more suggestions please?

Login via telnet and do a full directory listing (ls -l) of the admin and data directories. See what the permissions are before you attempt to build.

If you set the permissions, for example, on the data directory to 777 and for some reason, the permissions are otherwise, then I suspect it is a problem with your ISP and how they handle permissions, or something else (another script) is changeing the permissions to some default value. Do you by chance use a web-based file manager provided by your ISP or installed yourself?