Server Error - Scripts not executing

[Owen Drumm]

Decided to redo a site using Business Plus 9.0.5. Not an upgrade as have been using the same version previously and all worked fine. I am getting the following error.

Actinic received a server error from the web server. The CGI scripts are not executing properly on the server. The error could be caused by several things. Check:
- the 'Path to the Perl shell'
- the 'CGI script extension'
- the 'Path to CGI-BIN'
- the 'CGI-BIN URL.
- the amount of web space left on your server
- if your server is configured to accept POSTs to CGI scripts
- the permissions on the server:

On Linux/Unix based servers the permissions should be:
cgi-bin (755) – drwxr-xr-x
Online Store Folder (777) – drwxrwxrwx
On Windows based servers (need to be checked with the hosting company):
IIS
cgi-bin = read/execute
Online Store Folder = read/write/execute
NTFS
cgi-bin = Catalog's FTP account needs 'Change' permissions on the directory
Online Store Folder = Catalog's FTP account needs 'Change' permissions on the directory AND the IUSR_<servername> account needs to have 'Change' permissions on the directory

Run Web | Configure Web Site Details... to review your web site configuration.

I have done a network test and everything tests fine. Checked permissions on cgi-bin 755 and acatalog 777.

I decided to completely delete everything on the site and starting from scratch but that doesnt work either. I tried changing the script id but that failed as well.

I have deleted cat, fil and perl files and done a purge and refresh but still no joy.

Lastly but not least I have been searching the forum since last night for a solution to no avail.

[peblaco]

Could you post the network settings? (minus passwords) and are you hosting it or which company is hosting it?

[Owen Drumm]

Here are the network settings. It is on a VPS server hosted by Ntt Europe

HTTPPROXYMODE 0
HTTPPROXYADDRESS
HTTPPROXYPORT 80
HTTPPROXYUSER
HTTPPROXYPASSWORD
FTPPROXYMODE 0
FTPPROXYADDRESS
FTPPROXYPORT 21
FTPPROXYUSER
FTPPROXYPASSWORD
SCRIPTID 1
SCRIPTEXT .pl
SMTPHOST supplement-warehouse.veriovps.co.uk
WEBSITEURL http://www.fitness-focus.co.uk/
IGNOREPASSIVEERRORS true
USERELATIVECGIURLS false
PATHTOPERL /usr/bin/perl
USEENHANCEFTP true
FTPCLIENTTIMEOUT 15000
FTPRETRYDELAY 3000
FTPSILENT true
FTPMAXRETRIES 3
FTPCONNECTTIMEOUT 25000
SMTPAUTHREQUIRED false
SMTPUSERNAME
SMTPPASSWORD
COMPRESSIONPACKETSIZE 1024
COMPRESSEDUPLOAD false
CATALOGURL http://www.fitness-focus.co.uk/acatalog/
ONLINESTOREFOLDERNAME acatalog
CGIBINURL http://www.fitness-focus.co.uk/cgi-bin/
PATHFROMCGITOCATALOG ../fitness-focus.co.uk/acatalog/
CODEBASE ./
FTPHOST fitness-focus.co.uk
FTPUSERNAME
FTPPASSWORD
PATHTOCGIBIN /www/cgi-bin/
USEPASSIVEFTP true
FTPPATHFROMCGITOCATALOG /www/fitness-focus.co.uk/acatalog/

[Rich Brady]

Path to cgi-bin, doesn't look right to me. Try "/cgi-bin"

[Owen Drumm]

Path to cgi-bin is correct

[peblaco]

Online script gives Internal server error with "More information about this error may be available in the server error log."

Have you checked the server error logs?.

[Owen Drumm]

Got the following on error log.

009] [error] [client 88.109.230.222] attempt to invoke directory as script: /home/fitness/www/cgi-bin
[Tue Nov 17 13:40:35 2009] [error] [client 86.137.83.92] File does not exist: /home/fitness/www/fitness-focus.co.uk/favicon.ico
[Tue Nov 17 13:42:34 2009] [error] [client 88.109.230.222] Premature end of script headers: /home/fitness/www/cgi-bin/ca000001.pl
[Tue Nov 17 13:42:53 2009] [error] [client 88.109.230.222] Premature end of script headers: /home/fitness/www/cgi-bin/ca000001.pl
[Tue Nov 17 13:45:47 2009] [error] [client 86.167.217.162] Premature end of script headers: /home/fitness/www/cgi-bin/nq000001.pl
[Tue Nov 17 13:45:47 2009] [error] [client 86.167.217.162] Premature end of script headers: /home/fitness/www/cgi-bin/nq000001.pl
[Tue Nov 17 13:45:50 2009] [error] [client 86.167.217.162] Premature end of script headers: /home/fitness/www/cgi-bin/nq000001.pl
[Tue Nov 17 13:52:11 2009] [error] [client 217.205.250.130] Premature end of script headers: /home/fitness/www/cgi-bin/ss000001.pl

[Mike Hughes]

PATHTOCGIBIN /www/cgi-bin/

Path to cgi-bin, doesn't look right to me. Try "/cgi-bin"

Path to cgi-bin is correct

In which case this bit is wrong:

FTPPATHFROMCGITOCATALOG /www/fitness-focus.co.uk/acatalog/

Why not delete it and leave blank unless otherwise advised?

Mike

PS. Most servers are set up with the cgi-bin directory in the root directory of the website. This allows multiple sites to each have their own cgi-bin to prevent problems. Any reason you're not doing it this way?

[Owen Drumm]

That makes no difference. Still comes up with the same problem

[Rich Brady]

Any reason you're not doing it this way?

Why are you so certain the Path to cgi is correct?

[Owen Drumm]

Why are you so certain the Path to cgi is correct?

It was correct before when the site was functioning perfectly. Also I Configure web site details.

[Rich Brady]

Okay, did you type the network settings in or did you export and import the old ones?

[Mike Hughes]

So, the network test runs and passes OK which implies that the network settings, permissions and default upload format are all OK. Have you ftp'd into the site and checked that all the files are sitting in the right directories? and no duplicate directories?

Did you get the test email? Just checking as the smtp server (and email address? ) are off-domain.

The only other thing I can think of is to check the amount of webspace you have. This will give the same error if you don't have any space left.

Other than that I'm out of ideas.

Mike

[Owen Drumm]

There is ample disk space. I exported and imported the network settings. I checked that everything is in place on the site via ftp.

[Rich Brady]

The only other thing I can think off is that coincidentally your hosts have changed something. Have you spoken with them?

[Owen Drumm]

The hosts haven't changed anything. There are another couple of Actinic sites on this VPS server that are working perfectly well by the way.

[guccij]

It's probably time to call Support ...

[Owen Drumm]

I have raised a ticket with Actinic

[Owen Drumm]

Still no joy on this one. The last point I got to was when doing network settings getting a can connect to http server.

Orders are on the site but cant download them as when we try to download Actinic just hangs.

[Owen Drumm]

Another thing I have noticed is that when we switch to other sites and download after download we get an unspecified error dialog box come up.

[Owen Drumm]

I have now tried doing a network setup for all the sites and a screenshot of the error message I am getting for all of them is attached.

They are not all on the same server by the way and I have pinged them from my PC and they are fine.

[Darren B]

do you have a firewall blocking it, or has you ip address been blocked by your host for to many incorrect login attemps, this block is likely to be local to the ip address your connecting to

oh and have you changed the script id and done a full refresh, Actinic sometimes needs a kick up the arse to upload scripts. If they are corrupt on the server you need to delete them and force a new upload

[Owen Drumm]

do you have a firewall blocking it, or has you ip address been blocked by your host for to many incorrect login attemps, this block is likely to be local to the ip address your connecting to

oh and have you changed the script id and done a full refresh, Actinic sometimes needs a kick up the arse to upload scripts. If they are corrupt on the server you need to delete them and force a new upload

I tried with the firewall turned off a few times with no joy. I can't see any reason why my host would block my ip address.

Whilst I changed the script id on one site I didn't on the other sites.

[Owen Drumm]

Just changed the script id again from 1 to 10 and did a site refresh and got the usual

Actinic received a server error from the web server. The CGI scripts are not executing properly on the server. The error could be caused by several things. Check:
- the 'Path to the Perl shell'
- the 'CGI script extension'
- the 'Path to CGI-BIN'
- the 'CGI-BIN URL.
- the amount of web space left on your server
- if your server is configured to accept POSTs to CGI scripts
- the permissions on the server:

On Linux/Unix based servers the permissions should be:
cgi-bin (755) – drwxr-xr-x
Online Store Folder (777) – drwxrwxrwx
On Windows based servers (need to be checked with the hosting company):
IIS
cgi-bin = read/execute
Online Store Folder = read/write/execute
NTFS
cgi-bin = Catalog's FTP account needs 'Change' permissions on the directory
Online Store Folder = Catalog's FTP account needs 'Change' permissions on the directory AND the IUSR_<servername> account needs to have 'Change' permissions on the directory

Run Web | Configure Web Site Details... to review your web site configuration.

[Owen Drumm]

Just found this in the knowledge base (http://community.actinic.com/showthread.php?t=45215)

As I have BT Broadband I will see if it does anything.

[Owen Drumm]

That is no use.

Am now getting You do not have write permissions to the cgi-bin directory "/www/cgi-bin/" or it does not exist. when I do a network test. I have checked and the cgi-bin is 755

[guccij]

Does it pass the network test with the settings you have now? - Ah, I see it doesn't. In which case, why not reconfigure the network settings.

[Darren B]

Owen when someone suggest something you come back with no or they would not, the advice you are being given is from experienced users but you give the impression you want help but not prepared to try everythign suggested?

Somethings to do

1) set up a new ftp login on your server that only has access to the site in question - i mean access to the www part only, you url not server root access
2) Now change you network settings and remove all the ftp paths refering to www and the like wise - you do not need access to the server root, doing this helps eliminate incorrect directory problems
3) check that your cgi-bin is under your url - you should have two folders cgi-bin and acatalog
4) check the permissions on both of these cgi-bin = 755 acatalog = 777
5) try uploading with a dial up connection, these plenty of 0845 dial up numbers on the internet you can use to test it out

I mentioned your host blocking your ip as alot of servers use automatic blocking to prevent hacking and dos attacks. This kick in when the wrong password or username is entered too many times

You firewall was not just your pc but also you router, are you also using third party software - zone alarm, mcafee e.t.c

[guccij]

The hosts haven't changed anything.
Are you sure? If so, what's this about on this thread (http://community.actinic.com/showthread.php?t=45629)?
Can anyone recommend a host in the UK that can offer a reliable platform for Actinic sites as I am having a few problems with my current hosts
You never did come back with an answer to Darren's latest suggestions. It would be nice if you could bring yourself to say thank you for the efforts made to help you instead of saying stuff like "that's no use" or "that makes no difference." This is a community, and people give their time and experience for free.

[Duncan Rounding]

I have raised a ticket with Actinic

Did you follow this up with Actinic?

[Mike Hughes]

I think he's given up on the hosts. See http://community.actinic.com/showthread.php?t=45629

This is fair enough. I'd probably do the same as there are so many hosts that will work fine it's just not worth the while struggling to get it working.

Mike

[Owen Drumm]

I have given up on the hosts and also the response to my ticket to support is below. My plain speaking seems to have people thinking that their suggestions were not appreciated. This is not the case, sometimes the emphasis on the written word does not stand out as much as the spoken word.

I'd tested your snapshot and setting my end and both worked fine, so I
imported your settings into a default site and uploaded it in test mode, all
went through fine except right at the end I got an error about permissions
on the scripts. I uploaded some test scripts to the server and they worked
fine as well you can view them through
http://www.fitness-focus.co.uk/cgi-bin/willow.pl and
http://www.fitness-focus.co.uk/cgi-bin/hello.pl . So I'm not too sure why it
fails at the end, can you pass this on to your hosts and see if they can
feed any light on it. Please have a chat with them because we and default
site fails whilst be uploaded.

[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.