You are here:  » Script file permissions


Script file permissions

Submitted by crounauer on Wed, 2019-12-04 19:34 in

Hi David,

What should the file permissions be for the files in the Scripts folder.

I.e. cron.php etc...

Also what should the Scripts folder be?

I'm having problems with cron and trying to eliminate things...

Thanks,
Simon

Submitted by support on Thu, 2019-12-05 08:53

Hi Simon,

The .php files don't require any special permissions as they are executed by the PHP binary for cron operations e.g.

/usr/bin/php cron.php

However, so that cron.php can locate the feeds folder this should be preceded by the chdir command to scripts folder;

chdir /home/example/htdocs/scripts;/usr/bin/php cron.php

That is the command line worked out as the Option 1 command from /admin/ > Setup > CRON.

If that's basically what you are using but it's not working, you could try redirecting the output to a log file as that might indicate the problem e.g.;

chdir /home/example/htdocs/scripts;/usr/bin/php cron.php > ../feeds/cron.log

After it has been scheduled to run, check cron.log in the feeds folder which should contain the output of the command and might indicate the problem...

Hope this helps!

Cheers,
David.
--
PriceTapestry.com

Submitted by crounauer on Thu, 2019-12-05 18:22

Hi David,

I had to change the feeds/ folder permission from 755 to 777 to allow the creation of the tmp file. That got 1 feed working.

This is the output from the log file

fetching aw_coopelectrical.csv
fetching aw_coopelectrical.csv...[ERROR - TRANSFER FAILED]
fetching aw_currys.csv
fetching aw_currys.csv...[ERROR - TRANSFER FAILED]
fetching aw_dunelm.csv
fetching aw_dunelm.csv...[ERROR - TRANSFER FAILED]
fetching aw_robertdyas.csv
fetching aw_robertdyas.csv...[ERROR - TRANSFER FAILED]
fetching pr_aocom.csv
fetching pr_aocom.csv...[OK]

If I caut and paste the URL's into my browser they download fine. Could it be a GZIP issue?

Thanks,
Simon

Submitted by support on Fri, 2019-12-06 10:20

Hi Simon,

Are your aw_ feeds working when you click Run from /admin/ > Setup > Automation Tool?

A recurring issue lately with servers that have been online for a long time (in many cases several years!) is not having the latest authority certificates to validate an https connection.

Note that Awin feeds at time of writing still work over http so you can simply change https to http in the feed URLs however you can also set CURL to bypass certificate verification for https connections. To do this, edit includes/automation.php and look for the following code at line 147:

    curl_setopt($ch,CURLOPT_HEADER,0);

...and REPLACE with:

    curl_setopt($ch,CURLOPT_HEADER,0);
    curl_setopt($ch,CURLOPT_SSL_VERIFYHOST,0);
    curl_setopt($ch,CURLOPT_SSL_VERIFYPEER,FALSE);

Cheers,
David.
--
PriceTapestry.com

Submitted by crounauer on Fri, 2019-12-06 10:25

Hi David,

Yes they work when run from /admin/ > Setup > Automation Tool?

I'll try the workaround and get back to you.

Thanks,
Simon

Submitted by crounauer on Fri, 2019-12-06 10:45

Hi David,

Thanks for that - Changing the feeds from https to http solved the problem.

Last night when I was busy trouble shooting it the "products" table in the database disappeared. I didn't think anything of it thinking I have accidently deleted it (although it's not straight forward to do that).

When i've run cron.php again now, it's deleted the "products_import" table. I didn't even have phpmysql open today when this happened.

This is from cron.log after I ran cron.php from cron.

{code saved}

The first 3 feeds processed okay.

Any thoughts?

Submitted by support on Fri, 2019-12-06 12:31

Hi Simon,

The cron process does delete the products table but only at the very end before products_import is renamed to products so there is the tiny possibility that a database issue occurred after the delete but before the rename however I have not come across that being an issue at all.

You can restore the products table using setup.php?installDB=1 (it doesn't delete any tables already created), and if you have any custom fields set-up in $config_fieldSet the following dbmodall.php script will re-create the fields without having to run the modification script for each field individually;

<?php
  
require("includes/common.php");
  
$config_databaseDebugMode FALSE;
  
$ignore = array("name","description","image_url","buy_url","price","category","brand");
  foreach(
$config_fieldSet as $field => $v)
  {
    if (
in_array($field,$ignore)) continue;
    
$sql "ALTER TABLE `".$config_databaseTablePrefix."feeds`
              ADD `field_"
.$field."` VARCHAR(255) NOT NULL";
    
database_queryModify($sql,$result);
    
$sql "ALTER TABLE `".$config_databaseTablePrefix."products`
              ADD `"
.$field."` VARCHAR(255) NOT NULL";
    
database_queryModify($sql,$result);
  }
  print 
"Done.";
?>

Cheers,
David.
--
PriceTapestry.com

Submitted by support on Fri, 2019-12-06 12:33

Hi again,

I just had another thought after posting the above - I am wondering if you might have ended up with 2 (or more) cron.php processes running, so as one finished it removed products_import resulting in the error above in your second instance...

Cheers,
David.
--
PriceTapestry.com

Submitted by crounauer on Fri, 2019-12-06 14:21

Hi David,
That will be exactly what it is. I may have had 2 cron processes overlapping.

Thanks Simon