
|
View Full Version : FormMail CGI's stoped working - POST not working?!?
jucebro 11-20-2001, 07:08 PM This is strange. A site that was working fine, cgi's and all, all of a sudden stopped working. I'm not sure when the last time it worked was, but I know it did not too long ago (month or 2).
What is happening is when I submit to the formmail.pl, I get an "internal server error".
The permissions on the formmail.pl are 755. Owner is the sites admin, group is siteXX. I have tried it on 2 diffrent sites on the same server, same error. I have tried both formmail version 1.6 and 1.9.
here is the errors from the http/error log:
handler "cgi-wrapper" not found for: /home/sites/site31/web/cgi-bin/FormMail.pl
malformed header from script. Bad header=emailaddress@listed_as_recipient_in_form.com... No : /usr/cgiwrap/cgiwrap
If I use 'www.thedomain.com' in the @referers array, FormMail gives me a "Invalid @referers" error. Anything else in the @referers results in the "Internal server error"
The server is a RAQ3 with all the latest patches.
Does anybody know what might be causing this error?
(yes, cgi's are enabled)
cactus 11-21-2001, 02:14 PM Try changing the formmail.pl to another name and upload it again in ascii mode(chmod 755) and try it again. Some server due to security reasons may have disabled the script (formail.pl) maybe due to someone using the script at your server's bandwidth expense. Also change the script name in your Form to call the script again.
If I use 'www.thedomain.com' in the @referers array, FormMail gives me a "Invalid @referers" error. Anything else in the @referers results in the "Internal server error"
Usually @referers only need the domain.com without the www. It's to protect unauthorised ppl using the script but maybe someone may have used some utilities to gain access and using the script.
Another possibility is the path to Perl may have changed. If you want to know where it's installed and also other modules installed on your Host's server and where it's installed for example Perl, sendmail.etc .... Install the perldiver.cgi script in your cgi-bin and call the script via browser to have a complete details of your Host's server specs and paths if you don't have shell (Telnet) access or your Host have disabled it.
The url to download the script:
http://www.scriptsolutions.com/programs/free/perldiver/
INSTALLATION INSTRUCTIONS
To install and run PerlDiver v1.1:
1) If /usr/bin/perl is your path to perl, nothing need to be done to the perldiver.cgi file itself. If your path to perl is not /usr/bin/perl, change the first line of perldiver.cgi to your path to perl. Simply upload perldiver.cgi into your cgi-bin, or other executable directory in ASCII format. If you don't know your path to perl, and have telnet access, telnet to your account and type:
whereis perl
There, you will see a list of locations the server looks in (and finds) the perl executable, separated by spaces. Pick one, and type it in the first line of perldiver.cgi.
2) Upload perldiver.cgi in ASCII format to your cgi-bin or other executable directory.
3) Change permissions on the file to 755 (NOTE: some web servers may require permissions of 775 or higher for the program to run. If in doubt, check with your server administrator.
3) Run the program in your browser.
Hope this helps
jucebro 11-21-2001, 02:36 PM Thanks for the reply.
I forgot to mention I'm the system admin for the server. I've used the same script that works on another Raq 3. transfered through ASCII and tar'ed then transfered them through Binary. neither way worked.
maybe the version of perl did get changed, I'll look into that possibality.
What I don't get, is why are those error showing up in the httpd/error log? If I go directly to the script, the script will execute and show that it IS working. The only time it fails is when information is posted to it from an HTML form.
cactus 11-21-2001, 02:43 PM If you are the system administrar of the server, then create an account and upload the perldiver.cgi It's a great little program as it tells you everything you want to know including your server's apache modules installed on your server and its path.
cactus 11-21-2001, 02:53 PM The only time it fails is when information is posted to it from an HTML form.
Most probably the perl complier installed on the server is unable to find your script or the path to Perl that your script is looking for may have changed.
cactus 11-21-2001, 03:07 PM I forgot to mentioned, please test on some other perl/cgi script to pinpoint the problem in case your perl complier is not functioning or corrupt. If other scripts worked on the server, then it may be the path to perl that is giving the error.
Please post your findings if you can as I am also interested to know and as it will help me and others should we encounter such a problem in the future :D
jucebro 11-21-2001, 06:46 PM Ok, now I'm getting confused. I tried to run the perldiver.cgi on the server, but it gives me a CGI-Wrap, bla, bla, bla error. I even tried adding the /.../perl-- line, but same error. here is the error from the httpd/error log:
handler "cgi-wrapper" not found for: /home/sites/site31/web/be/perldiver.cgi
I added frommail.pl to the same directory, and it works fine (shows the banner) when I call it directly. But this error appears even if the banner shows up ok:
handler "cgi-wrapper" not found for: /home/sites/site31/web/be/frommail.pl
I read in another post that there is a bug that cause apache running on a cobalt to produce this error even when everything is ok, but now I'm stuck woundering what h3II is going on.
The path to perl is still the same. When logged in as eather root, or an admin for the site, a /usr/bin/perl --version spits back:
This is perl, version 5.005_03 built for i386-linux
I put another simple script that just outputs some text, and it worked fine as a .cgi and a .pl. Here is the script for recrence:
#!/usr/bin/perl
use CGI qw(header);
print header( -STATUS => "200 OK");
#print "Content-type: text/html\n\n";
print "test test\n\n";
cactus 11-21-2001, 10:43 PM Sorry, it's beyond me and I can't think of anything that's causing the error and would suggest getting your server provider tech support to help you.
Good luck
jucebro 11-23-2001, 01:06 PM Thanks for the help anyhow. At least I've scrached out a couple possiabilites.
Powerlord 11-26-2001, 05:24 AM Did you try running your simple script from the webserver, or just from the command line?
It almost sounds like the program cgi-wrapper, which runs by default when you attempt to run perl scripts from the webserver (as a URL) is missing. What cgi-wrapper does is change the effective user that is running the script... instead of running as nobody, it would run as the sites admin (in your example).
You can probably make it stop trying to run cgi-wrapper by editing the Apache configuration files, but a better idea might be to find out why cgi-wrapper disappeared.
jucebro 11-26-2001, 07:50 PM I tried it through the webserver. I tried adding a .htaccess file with this:
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
...but I still get the same error. I was hopeing it would override the cgiwrap problem.
One correction from above, perldiver.cgi DOSE work. I had it in binary the first time I tried to execuite it :dunce:
jucebro 12-04-2001, 01:44 PM This is weird. now the exact same thing is happening on another server thats a RaQ4. Are there any known issues with cgiwrap on cobalts?
jucebro 12-04-2001, 06:12 PM Well, I feal stupid. I guess if your 'recipient' is not a valid e-mail address, you get a bad Header error:blush:
jahsh 12-04-2001, 07:26 PM that'll do it;)
cactus 12-04-2001, 09:42 PM Hehe, glad you solved the problem. Well one more Formmail tip for the records, just in case if I get stuck it will make my work easier. Cheers!
|