Server Error - Scripts not executing

[Squeeb]

I too am having the EXACT problems you are having.

Looking through the server logs I just get the same error:

[Mon Nov 30 15:33:51 2009] [error] [client] Can't open perl script "\r": No such file or directory
[Mon Nov 30 15:33:51 2009] [error] [client] Premature end of script headers: nq000001.pl
[Mon Nov 30 15:33:52 2009] [error] [client] Can't open perl script "\r": No such file or directory
[Mon Nov 30 15:33:52 2009] [error] [client] Premature end of script headers: nq000001.pl
[Mon Nov 30 15:33:52 2009] [error] [client] Can't open perl script "\r": No such file or directory
[Mon Nov 30 15:33:52 2009] [error] [client] Premature end of script headers: nq000001.pl
[Mon Nov 30 15:33:52 2009] [error] [client] Can't open perl script "\r": No such file or directory
[Mon Nov 30 15:33:52 2009] [error] [client] Premature end of script headers: nq000001.pl
[Mon Nov 30 15:33:52 2009] [error] [client] Can't open perl script "\r": No such file or directory
[Mon Nov 30 15:33:52 2009] [error] [client] Premature end of script headers: nq000001.pl
[Mon Nov 30 15:35:07 2009] [error] [client] Can't open perl script "\r": No such file or directory
[Mon Nov 30 15:35:07 2009] [error] [client] Premature end of script headers: nq000001.pl

I cannot find what's calling "\r" or why it's even calling "\r" in the first time.

If anyone has any information on why this is happening, I would be grateful for any feedback.

I've followed the instructions carefully, It's NOT helpful that the "View Response" button is grayed out.

At first I thought it may have been the transparent proxy server we're running here, so I let all HTTP traffic pass direct through our corporate router but this made no difference.

[pinbrook]

If anyone has any information on why this is happening, I would be grateful for any feedback.

who is the host?
have you run network setup
what are you network settings
has it ever worked
what are permissions on cgi-bin

[Squeeb]

The host is my own Linux server.
I have run the network setup unsuccessfully with this error in the server log at the end:

30 15:48:38 2009] [error] [client x.x.x.x] (2)No such file or directory: exec of '/var/www/vhosts/sl/store/cgi-bin/cp000001.pl' failed
[Mon Nov 30 15:48:38 2009] [error] [client x.x.x.x] Premature end of script headers: cp000001.pl


These are the network settings:

HTTPPROXYMODE 0
HTTPPROXYADDRESS
HTTPPROXYPORT 80
HTTPPROXYUSER
HTTPPROXYPASSWORD
FTPPROXYMODE 0
FTPPROXYADDRESS
FTPPROXYPORT 21
FTPPROXYUSER
FTPPROXYPASSWORD
SCRIPTID 1
SCRIPTEXT .pl
SMTPHOST 127.0.0.1
WEBSITEURL http://foo/
IGNOREPASSIVEERRORS true
USERELATIVECGIURLS false
PATHTOPERL /usr/bin/perl
USEENHANCEFTP true
FTPCLIENTTIMEOUT 15000
FTPRETRYDELAY 3000
FTPKEEPALIVEINTERVAL 30000
FTPSILENT false
FTPMAXRETRIES 3
FTPCONNECTTIMEOUT 25000
SMTPAUTHREQUIRED false
SMTPUSERNAME
SMTPPASSWORD
COMPRESSIONPACKETSIZE 1024
COMPRESSEDUPLOAD true
CATALOGURL http://foo/acatalog/
ONLINESTOREFOLDERNAME acatalog
CGIBINURL http://foo/cgi-bin/
PATHFROMCGITOCATALOG /var/www/vhosts/sl/store/public_html/acatalog/
CODEBASE ./
FTPHOST foo
FTPUSERNAME sl
FTPPASSWORD pass
PATHTOCGIBIN /var/www/vhosts/sl/store/cgi-bin/
USEPASSIVEFTP false
FTPPATHFROMCGITOCATALOG /var/www/vhosts/sl/store/public_html/acatalog/

It's never worked.

Permissions on cgi-bin are correct:

drwxr-xr-x 2 sl root 4096 2009-11-30 15:46 cgi-bin
drwxr-xr-x 3 sl root 4096 2009-11-30 15:25 public_html

[Squeeb]

Just for more information, other perl scripts executed by apache are running fine on the same host.

[Squeeb]

I've figured out the problem but can find no solution.

What appears to be happening is that Actinic is uploading DOS line feeds at the end of the perl scripts.

Thus:

# ./cp000001.pl
-bash: ./cp000001.pl: /usr/bin/perl^M: bad interpreter: No such file or directory

..

however, after running dos2unix on the file, the file will execute:

# dos2unix cp000001.pl
# ./cp000001.pl
Content-type: text/plain
Content-length: 9
Date: Mon, 30 Nov 2009 16:14:18 GMT


Of course, every time I click test, the file is re-uploaded and the script fails to execute.

Catch22 error anyone? I'm calling bug!

[pinbrook]

Have you searched the forum? I am pretty sure this has come up before

dos2unix would be a good keyword

[Squeeb]

Ok,

The "workaround" is:

Ignore the test and click OK anyway,

Click "Publish to Web" .. at the point where it fails log in to ssh if you can and run the command:

# dos2unix * && chown YOURUNIXUSER *

In the cgi-bin..

Press "Try again" .. and it APPEARS to work.

Hope this helps someone.

A cool feature to add in the future would be a "run command after upload" function on the FTP stuff.

[Mike Hughes]

I think this might be down to the files being transferred as binary rather than ascii.

See: http://community.actinic.com/showthread.php?t=45155

Mike

[Hendrik]

4) check the permissions on both of these cgi-bin = 755 acatalog = 777

I have just moved to a dedicated server (Linux box hosted by Easynet) and yesterday the guy who built the server switched the acatalog permissions to 775 because he felt there were security issues. This meant that whenever someone added an item to the cart they simply got a server error. (Things had been working up to that point!)

We switched the permissions on the acatalog folder back to 777, but this did not fix the problem. However different files within the acatalog folder had a variety of permissions attached to them. We have fixed the problem by giving every single file within the acatalog folder 777 permissions. However I wonder if we have lowered our guard more than strictly necessary?

Is there a definitive guide somewhere to the permissions needed by the files INSIDE the acatalog folder?

Hendrik

[pinbrook]

easiest way to resolve this is a web refresh from help menu, this should reset all permissions.

[Squeeb]

I would really rather not enable ASCII upload on vsftpd.

For the sake of completeness, I quote from the well written paragraph found inside vsftpd.conf:

# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.

[Owen Drumm]

easiest way to resolve this is a web refresh from help menu, this should reset all permissions.

I tried this but it didn't work for me.

[Mike Hughes]

I would really rather not enable ASCII upload on vsftpd.

That's fine. Now you know the problem though.

Mike

[NormanRouxel]

I would really rather not enable ASCII upload on vsftpd

Surely only a problem if you're letting world+dog log in to your FTP server.