500 Internal Server Error when trying to run a cgi script

[MaRiOs]

Hello ppl,
I need some more automatic things to put in plesk so I said I must begin learning perl to write my own scripts.

I made a very easy one that just prints 2 words and i uploades to the cgi-bin area...
(its the first time Im using the cgi-bin).

so when i try to run the script i get :

500 Internal Server Error ....
the link is :
http://www.mariosmaravelias.info/cgi-bin/test.cgi

what am I doing wrong?

 

[jamesyeeoc]

Could you post this script?

Have you checked your log files?

/var/log/messages

/home/httpd/vhosts/mariosmaravelias.info/statistics/logs/access_log
/home/httpd/vhosts/mariosmaravelias.info/statistics/logs/error_log

 

[MaRiOs]

#!/usr/bin/perl
$name="Hello World";
print $name;


i cantbe more simple than that

 

[jamesyeeoc]

And what about your log files, any errors or messages relating to this problem??

You should be seeing 'Premature end of script headers: test.cgi' in your error_log file

Common solutions to this are:

1) Copy psa-suexec to suexec:

cp /usr/sbin/psa-suexec /usr/sbin/suexec

2) Permissions:

chmod -R 755 /home/httpd/vhosts/yourdomain.com/cgi-bin

3) Ownership:

chown -R ftpusername : psacln /home/httpd/vhosts/yourdomain.com/cgi-bin

(without the spaces around the colon : )
4) File is ASCII: If you uploaded the file using FTP, it may have been uploaded in binary mode instead of ASCII, reupload it as ASCII.

Then restart apache:

service httpd restart

In some cases, a whole server restart is necessary, not just apache restart.

These have solved the same problem for countless others here on the forum.

 

[MaRiOs]

Ok I did these :

1)cp: `/usr/sbin/psa-suexec' and `/usr/sbin/suexec' are the same file

2)Done

3)Done

4) i didnt upload it , I loged in ssh and i made the file with nano editor.

5) ok i will try to restart it.

about the error log files i dont see anythin about the script..

the only error i see is :

[Mon Jul 25 12:29:05 2005] [warn] RSA server certificate CommonName (CN) `plesk' does NOT match server name!?
[Mon Jul 25 12:29:05 2005] [notice] Apache/2.0.46 (Red Hat) configured -- resuming normal operations

 

[ylikone]

Ok, I had the same problem and finally got my cgi scripts to work.

Here are the things I had to do:

1. make sure script is in the virtual domains cgi-bin dir (not inside httpdocs)

2. chown your-vhost-ftp-account-namesacln *.cgi

3. chmod 755 *.cgi (has to be exactly 755, not 777 or anything else)

4. make sure you have allow cgi enabled in plesk control panel for this virtual host

5. make sure the first line of the script is #!/usr/bin/perl (with no CR character at the end, which gets put there if this script is transfered from a windows text editor... should be fine if you created the file locally via vi, joe, nano or pico)

6. make sure you have proper http header being sent out... using a line like the following
print "Content-type: text/html\n\n";
as the first thing that gets sent out.


I've dealt with many perl script on non-plesk servers before and find that plesk is configured to be really picky on cgi when it comes to permissions, ownership, and sending out the mime type header.

 

[tbannister]

Originally posted by MaRiOs
#!/usr/bin/perl
$name="Hello World";
print $name;


i cantbe more simple than that

Unfortunately, that is too simple. Most likely you're getting a server 500 error because you didn't send the http headers first.

Add the line:
print "Content-type: text/html\n\n"

before
print $name;

 

[MaRiOs]

ylikone :

1.yes

2.yes

3.allready

4.they are enabled.

5.yes

6.done

I even restared apache,

now the script looks like :

#!/usr/bin/perl

$name="Hello World";
print "Content-type: text/html\n\n"
print $name;

but still running http://www.mariosmaravelias.info/cgi-bin/test.cgi

gets 500

 

[MaRiOs]

ok i added an ; in the line : print "Content-type: text/html\n\n"

and now it works

 

[Jllynch]

Unfortunately that didn't do it for us. We have other clients on the same box that have no problems with the same scripts, just this one for some reason. I tried everything suggested above...

 

[jamesyeeoc]

Please make sure you chmod 755 the actual directory cgi-bin, not just the files *.cgi

chmod 755 /home/httpd/vhosts/domain.tld/cgi-bin

Also make sure the ownership of the cgi-bin directory is ftpusername : psacln (or psaserv)

I have run across situations where the chmod 755 cgi-bin did not occur properly, but no error came back. Then I re-issued the command and used 'ls -al' to verify and then all went ok with the .cgi files.

(I hate strange happenings)

 

[phoenixisp]

I was updating to 7.5.4 and ran into a couple of minor problems and ironed them out - but now I don't have a psa-exec file. Is there a way, other than uninstall psa and reinstall, to get my hands on a new psa-suexec?

 

[phatPhrog]

7.5.4r

This is interesting. I have recently updted 7.5.3 to 7.5.4 and my cgi stopped working.

Following the instructions given here I find I don't have a /usr/sbin/psa-suexec.

These are what we have on the server

/usr/sbin/suexec
/usr/lib/httpd/modules/mod_suexec.so
/usr/local/psa/suexec/psa-suexec

 

[phoenixisp]

Here's the fix that worked for me, it actually created the psa-suexec file. Then copy the contents to suexec. Good luck:

The following is based on a RedHat 9 box, if you are on a different OS, there will be a bit of a difference. When posting it's always a good idea to provide some information like OS, current version of Plesk, etc.

CD to the directory where the base Plesk rpm is. It should be in a directory named psa/PSA_7.5.4/rpm_RedHat_9/base. Then run:

#rpm -Uvh --force psa-7.5.4-rh9.build75050824.12.i586.rpm

 

[phatPhrog]

Sorry. We have a 7.5.4 FC2.

So the following should set me on the right path?

psa stop

rpm -Uvh --force psa-7.5.4-fc2.build75050824.12.i586.rpm

psa start

Thanks for responding so fast, too. Really appreciated.

 

[phoenixisp]

Yep, should work just fine.

 

[phatPhrog]

That didn't work for me. Will keep looking.

Had some failed dependencies due to our upgraded apps, but suexec and psa-suexec still have the same timestamps as before running the rpm.


base]# rpm -Uvh --force psa-7.5.4-fc2.build75050824.12.i586.rpm
error: Failed dependencies:
perl(Mail::SpamAssassin) is needed by (installed) psa-spamassassin-7.5.4-fc2.build75050824.12
perl(Mail::SpamAssassin::ArchiveIterator) is needed by (installed) psa-spamassassin-7.5.4-fc2.build75050824.12
perl(Mail::SpamAssassin::Message) is needed by (installed) psa-spamassassin-7.5.4-fc2.build75050824.12
perl(Mail::SpamAssassin:erMsgLearner) is needed by (installed) psa-spamassassin-7.5.4-fc2.build75050824.12
spamassassin >= 2.60 is needed by (installed) psa-spamassassin-7.5.4-fc2.build75050824.12
base]# /etc/init.d/psa start
Starting psa-spamassassin service: [ OK ]
Processing config directory: /usr/local/psa/admin/conf/httpsd.*.include
/usr/local/psa/admin/bin/httpsdctl start: httpd started
Starting Plesk: [ OK ]

Thanks again.

 

[phoenixisp]

Try rpm -e psa-spamassassin - then install Plesk again. You can always come back and install psa-spamassassin.

 

[jamesyeeoc]

Not that I personally recommend doing this, but if you are going to force it, then you should also tell rpm to ignore deps:

rpm -Uvh --force --nodeps psa-7.5.4-fc2.build75050824.12.i586.rpm

Forcing the PSA upgrade install is not something I would ever do or recommend to anyone. Under some limited circumstances it may solve things, but in this case, I would expect the end result to still be flawed. It may give you the suexec file, but it sounds like something else went wrong during the initial upgrade.

 

[phatPhrog]

Unsuccessful

First, I'd like to say that is an exercise I'd rather not perform on a production server "ever" again. It was, however, a learning experience; nonetheless.

After removing psa-spamassassin, running the 7.5.4 rpm, there is still no /usr/bin/psa-suexec. The same two are still there with original timestamps.

/usr/sbin/suexec
/usr/local/psa/suexec/psa-suexec

There is obviously something about FC2 and suexec that I need to do further research on.

Aside from that, I had to re-run updater, of course to bring the server back up-to-date but all works as great as it did before.

The cgi thing is important, but not so important I'll do that again.

Again, Thank you for your help. If I find the resolution to this, I'll post here in case anyone else has the same problem.