Announcement

Collapse
No announcement yet.

scripts not executing on server

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    scripts not executing on server

    Hi - we have changed our hosting provider but are
    encountering difficulties when trying to upload and test network settings;

    "The test script failed to execute on the web 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, and the CGI-BIN URL. This error
    could also occur if your web site is out of disk space or your web server is
    not configured to accept POSTs to CGI scripts."

    we have checked the error log on server and this is example of error:
    No such file or directory: exec of '/home/sites/orderseuro.bmj.com/cgi-bin/cp000002.pl' failed
    Premature end of script headers: cp000002.pl

    Systems administrator has reexamined config settings and maintains the server (linux) is correctly configured for running Perl CGI scripts.

    Looking at the cgi-bin folder within the orderseuro site I can see a number of files in format - **.000002.pl; and **.000002.pm so some files have
    successfully uploaded. A number of files have uploaded to /web/acatalog also.

    Systems admin wonders whether the problem relates to coding inconsistencies created by uploading files from a Windows desktop machine to a Linux server?

    we found information at http://encodable.com/internal_server_error/ which supported this and recommended changing the FTP client to use either ASCII or BINARY transfer mode before transferring the CGI script."

    Problem is I'm not sure where to change these settings. There's ftp options within Advanced Network Setup but no option to change transfer mode. I have an ftp client on my desktop but I don't think this is used by Actinic - or is it? That might be a red herring.

    I have attached network settings and error log from ftp server following recent attempt to upload files.

    any advice gratefully received. Have logged with Actinic Support but so far no resolution.

    we are using Actinic v 8.5.3.
    Attached Files

    #2
    Who are the hosts and if approved successful actinic hosts, have you tried the network settings off the forum for them. Not all hosts work with actnic, hopefully you have chosen one that does. IME, do not waste any time on anything else until you get the network test to pass. Passing the network test is always key, despite what techno babble you will be provided with. Try the wizard also.

    99% of actinic users Linux, your problem is 99% sure to be your hosts or your network settings. Paste them into your post, more people will take a look and also notice there is a specific forum for these problems.

    Comment


      #3
      network settings

      Hi - these are network settings. We use uk2.net as hosts and I am waiting on a reply from them as to compatibility with Actinic. Do you know where network settings for uk2.net are on the Forum? I've searched forum for uk2.net but can't find them. Might Actinic support have them?

      HTTPPROXYMODE 0
      HTTPPROXYADDRESS
      HTTPPROXYPORT 80
      HTTPPROXYUSER
      HTTPPROXYPASSWORD
      FTPPROXYMODE 0
      FTPPROXYADDRESS
      FTPPROXYPORT 21
      FTPPROXYUSER
      FTPPROXYPASSWORD
      SCRIPTID 2
      SCRIPTEXT .pl
      SMTPHOST localhost
      WEBSITEURL http://orderseuro.bmj.com/
      IGNOREPASSIVEERRORS true
      USERELATIVECGIURLS false
      PATHTOPERL /usr/bin/perl
      USEENHANCEFTP true
      FTPCLIENTTIMEOUT 15000
      FTPRETRYDELAY 3000
      FTPSILENT false
      FTPMAXRETRIES 3
      FTPCONNECTTIMEOUT 25000
      SMTPAUTHREQUIRED false
      SMTPUSERNAME
      SMTPPASSWORD
      CATALOGURL http://orderseuro.bmj.com/acatalog/
      CGIBINURL http://orderseuro.bmj.com/cgi-bin/
      PATHFROMCGITOCATALOG ../web/acatalog/
      CODEBASE ./
      FTPHOST orderseuro.bmj.com
      FTPUSERNAME ********
      FTPPASSWORD ********
      PATHTOCGIBIN /cgi-bin/
      USEPASSIVEFTP false
      FTPPATHFROMCGITOCATALOG /web/acatalog/

      cheers

      Comment


        #4
        Matt, i feel your will be waiting at least 24hours for a response from them, they have 24/7 support when they get around to answering.

        Besting to do is not use your main ftp login. Go to your control panel and create a new ftp account that just has access to your web root. Im not sure who they use, it could be public_html as the directory to your web root.

        then change your settings file these bits

        PATHFROMCGITOCATALOG ../web/acatalog/
        FTPPATHFROMCGITOCATALOG /web/acatalog/

        to this

        PATHFROMCGITOCATALOG ../acatalog/
        FTPPATHFROMCGITOCATALOG

        you might find these settings work without creating an ftp account. Unfortunately its a case of trial and error.

        Comment


          #5
          Darren - thanks for the suggestion. Our sys admin says that the ftp accounts we're using do have access to web root. I have tried changing the paths as you suggest without success.

          We are able to run a test Perl script successfully within the cgi-bin which suggests that the web server has been configured successfully to run Perl. I have logged this with Actinic Support and am waiting on feedback from them.

          The sys admin guy wonders whether this issue is related to the CGI PC to linux transfer issues as detailed below:

          http://johnbokma.com/mexit/2007/01/0...i-program.html

          An excerpt from the web server error log is reproduced below in case this sheds any light:

          [Tue Oct 14 04:01:11 2008] [error] [client 64.246.161.30] File does not exist: /home/sites/orderseuro.bmj.com/web/robots.txt, referer: http://www.whois.sc/
          [Tue Oct 14 05:01:37 2008] [error] [client 208.36.144.8] File does not exist: /home/sites/orderseuro.bmj.com/web/robots.txt
          [Tue Oct 14 07:40:13 2008] [error] [client 74.6.22.164] File does not exist: /home/sites/orderseuro.bmj.com/web/robots.txt
          [Tue Oct 14 07:40:14 2008] [error] [client 74.6.22.164] (2)No such file or directory: exec of '/home/sites/orderseuro.bmj.com/cgi-bin/mf000002.pl' failed
          [Tue Oct 14 07:40:14 2008] [error] [client 74.6.22.164] Premature end of script headers: mf000002.pl
          [Tue Oct 14 07:41:03 2008] [error] [client 74.6.22.164] (2)No such file or directory: exec of '/home/sites/orderseuro.bmj.com/cgi-bin/mf000002.pl' failed
          [Tue Oct 14 07:41:03 2008] [error] [client 74.6.22.164] Premature end of script headers: mf000002.pl
          [Tue Oct 14 07:41:51 2008] [error] [client 74.6.22.164] (2)No such file or directory: exec of '/home/sites/orderseuro.bmj.com/cgi-bin/mf000002.pl' failed
          [Tue Oct 14 07:41:51 2008] [error] [client 74.6.22.164] Premature end of script headers: mf000002.pl
          [Tue Oct 14 09:42:15 2008] [error] [client 208.36.144.10] File does not exist: /home/sites/orderseuro.bmj.com/web/robots.txt
          [Tue Oct 14 10:04:25 2008] [error] [client 66.249.71.40] File does not exist: /home/sites/orderseuro.bmj.com/web/robots.txt
          [Tue Oct 14 12:40:39 2008] [error] [client 193.22.89.2] (2)No such file or directory: exec of '/home/sites/orderseuro.bmj.com/cgi-bin/cp000002.pl' failed
          [Tue Oct 14 12:40:39 2008] [error] [client 193.22.89.2] Premature end of script headers: cp000002.pl
          [Tue Oct 14 12:43:08 2008] [error] [client 193.22.89.2] (2)No such file or directory: exec of '/home/sites/orderseuro.bmj.com/cgi-bin/nq000002.pl' failed
          [Tue Oct 14 12:43:08 2008] [error] [client 193.22.89.2] Premature end of script headers: nq000002.pl

          Comment


            #6
            you should put www before your URLs - this won't help your cgi issue but will upload to www.domain rather then domain. people tend to put www in URLs

            Comment


              #7
              Hi Matt,

              If you would like me to take a look at your server then please email me your ftp details so I can see if I can figure out what the problem is.
              ********************
              Tracey
              SellerDeck

              Comment


                #8
                problem resolved (well almost!)

                the answer to this lies here:

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

                By default, Redhat Linux servers do not have ASCII uploads enabled - only BINARY. This means that the scripts are corrupted as they are uploaded as Actinic requires script files to be uploaded in ASCII.

                To workaround this you have to enable ASCII transfers on the server. If you are a server administrator then do the following (if you are not a server administrator, then you will need to tell your web host to do the following).

                Open the vsftpd.conf file. This may exist twice on the server, so edit the files in the following locations:

                /etc/vsftpd/vsftpd.conf
                /etc/vsftpd.conf

                Within it, locate the line

                ascii_upload_enable=YES

                And uncomment it by removing the hash '#' from the beginning of the line.

                Then you need to restart the xinetd service (and also the vsftpd service) and Actinic should upload correctly.


                having taken the action outlined above I can now successfully upload files via ftp. The side-effect is that the currency signs are no longer displaying correctly - see http://orderseuro.bmj.com/acatalog/B...rnational.html - which may be related to the change in code from BINARY to ASCII. Any ideas on this would be welcome.

                thanks to all for their help.
                Last edited by KB2; 23-Mar-2010, 10:20 AM. Reason: Updating kb links

                Comment


                  #9
                  Hi,

                  The side-effect is that the currency signs are no longer displaying correctly
                  Try this kb article for that one.
                  Last edited by KB2; 23-Mar-2010, 10:18 AM. Reason: Updating kb links
                  ********************
                  Tracey
                  SellerDeck

                  Comment


                    #10
                    resolved

                    great - thanks for your help, option 3 in this article worked for me!

                    Comment

                    Working...
                    X