CGI Scripts and permissions.
Would anyone know what would cause some cgi scripts to just stop working on one of our servers.
Some scripts such as Perlbill are fine and kept going, but other simple scripts which had been working for months have just stopped working, is there anything in the recent upgrades which might have caused this problem?
any info would be a great help.
thankyou.
For the scripts that do not work, are the permissions set to 777? If so, try changing them to 755. Might be the problem.
Try to log in via SSH and run the scripts via the command line. It may give you insight as to why the scripts are not working.
Also check /usr/local/apache/logs/error_logs when attempting to run the script - Apache will write some errors there.
Fire extinguisher extraordinare
-------------------------------
Brandon
FastServers.Net NOC Admin
Thankyou for the reply.
errors we are getting are,
bad headers
and user unknown errors, it seems that the server is treating users email addresses as unknown, we have checked hosts.allow and localdomains and other files and they are all listed.
here is a log entry
[Tue Mar 11 21:13:49 2003] [error] [client 203.45.133.145] malformed header from script. Bad header=info@ourclient.com... User unkno: /home/ourclient/public_html/cgi-bin/form/eforms.pl
from my research it seems that the email/sendmail issue is causing this, if the form cannot verify the email user address or does not accept it this causes the form to return errors, we have updated cpanel and other scripts, did /scripts/easyapache 4 and nothing has changed.
thankyou.
Last edited by hostcp3; 03-11-2003 at 10:22 PM.
I am having the same problem with my host (DayanaHost) after the latest upgrade to cPanel. My installation of Movable Type suddenly stopped working. All the cgi scripts in cgi-bin directory used for Movable Type generate premature end of script header error:
Premature end of script headers: /home/sforrest/public_html/cgi-bin/mt.cgi
If anyone has any thoughts on this, I'd love to hear it.
-Scott
Scott
Cpanel support looked at this for us and it turned out to be our fault.
We had sendmail trying to run over the top of exim, all sendmail is there for is a link to exim so that forms and other such cgi scripts can send off an email using the /sendmail link.
Removing sendmail and reinstalling exim is what was done to fix the issue for us, but your problem could be different so I don't advise you doing this until you talk to support.
I'm getting this error, and I've tried everything. I deleted the script and checked and double checked to make sure I was uploading in ASCII mode. I ran the /scripts/fixsuexeccgiscripts, and I've tried running the file from ssh (it works there). It worked fine on my old server (alabanz*)...
Any other ideas?
I checked out
/usr/local/apache/logs/suexec_log and I had the following error:
error: target uid/gid (32007/32007) mismatch with directory (32007/677) or program (32007/32007) or trusted user (0/10)
Don't know if this helps but a thread at WHT ,
http://www.webhostingtalk.com/showth...hreadid=125233
here some info
upload cgi files in binary mode first, then change to ascii mode and upload it again. Chmod 755.
its where the ftp is set to DefaultTransferMode is set to binary instead of ascii.
hope this helps some.
Dang! I was really hoping that would be it, but it wasn't. Still no luck.Originally posted by hostcp3
Don't know if this helps but a thread at WHT ,
http://www.webhostingtalk.com/showth...hreadid=125233
here some info
upload cgi files in binary mode first, then change to ascii mode and upload it again. Chmod 755.
its where the ftp is set to DefaultTransferMode is set to binary instead of ascii.
hope this helps some.
Sorry
I will keep my eyes open for you, the permissions are funny things I have found, sometimes running too high a permission and it stops the script from working, running 777 is not the best solution and actually can stop a script from working in a cgi-bin, try using such permissions as 600 , 660 and a few others to see if that helps,
do
a ls - l
in the dir the files are in to check the actuall permissions, sorry haven't been much help its a nightmare with this situation as customers scripts which r
un elsewhere stop working on your server for no reason.
another thing is we were running a program for testing purposes and it is cgi and it would not run when the httpd.conf file had the
User username
Group username
in it, when the above were deleted the script ran, with those in the file the script kept showing 500 errors.
much to know.
Thanks, hostcp3. I tried all the permissions, and I even tried deleting user username group username, but that ended up breaking apache, so I had to put it back (by the way, mine is user nobody and group nobody--is that a problem?).
Quote
"Thanks, hostcp3. I tried all the permissions, and I even tried deleting user username group username, but that ended up breaking apache, so I had to put it back (by the way, mine is user nobody and group nobody--is that a problem?).
"
sorry that user setting was for the particular domain not the the general setting for apache httpd.conf
Removing those for just the particluar domain your working on shouldn't break apache.
by the way what is the script?
We saw this on a box that was NOT originally using suexec. The build enabled suexec and all cgi stopped working. I entered WHM and disabled suexec again and all went back to normal.
Ha, ha. Silly me.Originally posted by hostcp3
Quote
"Thanks, hostcp3. I tried all the permissions, and I even tried deleting user username group username, but that ended up breaking apache, so I had to put it back (by the way, mine is user nobody and group nobody--is that a problem?).
"
sorry that user setting was for the particular domain not the the general setting for apache httpd.conf
Removing those for just the particluar domain your working on shouldn't break apache.
by the way what is the script?
The script is Tip of the Moment from
http://www.cgi-factory.com/software/
I have tried disabling suexec to no avail. I wouldn't want that to be the solution, anyway.
LinkBack URL
About LinkBacks
Reply With Quote