Let me preface this post with a note that I have read all old posts regarding 500 errors and have installed Links 2.0 on another server successfully. I have also been using DBMan for some time and have successfully performed almost every mod that exists.

I just purchased my own server and installed Linux, Apache and Ensim's WEBppliance virtual hosting administrator.

I tried to directly transfer my heavily modified Links 2.0 from the old server, but when I go to the admin page I just get a plain old 500 Server Error page.

SO, next I installed a fresh (and unmodified) version of Links 2.0, carefully doublechecking all permissions and file locations. Same thing.

So I triplechecked my locations and permissions:
/home/virtual/drag/home/httpd/cgi-bin....

Same result.

Next I tried setting "Use IIS headers?" to "1", as that worked for another person, but had no effect here.

Then I tried changing the location of links.cfg in admin.cgi to the absolute path... no effect.

I would really like to get this up ASAP, but I am at a loss. I checked the server log and all it says is:
"[Sun Jun 10 21:49:52 2001] [error] [client 4.35.205.181] Premature end of script headers: /home/virtual/drag/home/httpd/cgi-bin/shopguide/admin/admin.cgi"

Any ideas?

| www.meltedmonitor.com |

Are you sure that the CHMOD values are set correctly? That can normally cause the problem. Remember, folders need to be CHMODed to 777. Lots of people forget that they do in fact need to be CHMODed.

Andy

webmaster@ace-installer.com
http://www.ace-installer.com

Actually the problem is more likely to be a different path to perl on the new server.

Installations:http://www.wiredon.net/gt/
Favicon:http://www.wiredon.net/favicon/

No, the path to perl is the same as on the old server and yes, I chmod'd every single folder that has to do with Links to 777.

I'm wondering if the Ensim WEBppliance software that runs the virtual hosting could be messing things up. I have DBMman running in the new server, as well as some other scripts. It is just Links that refuses to cooperate.

A very interesting sidenote, when I installed probe.pl (a small script that just lists out import perl information) I got the same error message when the script was chmod'd to 777. When i chmod'd it to 755 it worked fine. On my old server it would work either way!

All of my .cgi scripts in Links are set at 755, but maybe it has something to do with permissions. I have all my permissions set as specified in the readme file, though.

Hmmmmmm.

| www.meltedmonitor.com |

After some more research I have discovered that suEXEC is running on my server. I'm not sure what it is exactly, but it is a security function of some type. More info is here:

http://httpd.apache.org/docs/suexec.html

| www.meltedmonitor.com |

I would highly suggest removing your FTP access information. Anyone can go into your server and start messing with things.

Do you REALLY trust 10,000+ users in this forum???

Regards,

Eliot Lee

Sounds smart... now I'm trying to disable suEXEC, maybe that will solve the problem.

| www.meltedmonitor.com |

I found the error logs for suEXEC, they led me to the fact that nothing will run if I have a directory chmod'd to 777.

Now I wonder if I'll be able to make Links run without 777 dirs.

PROBLEM SOLVED

| www.meltedmonitor.com |

You can try using 766, which will make the directory world-wide writable...

Regards,

Eliot Lee

766 failed still, but when I tried 755 everything appeared to work correctly. Thanks guys!

| www.meltedmonitor.com |

I'm assuming that you are able to get the add.cgi to work also? I've been having similar problems since moving to a new server with a CGI Wrapper. I managed to finally get everything working, except I continue to get a 500 error when I try to run add.cgi. Just wondered if you ran into that also?

Actyally I'm using Links in a non-public way, so add.cgi isn't used. Sorry.

| www.meltedmonitor.com |