Thank goodness for forums!
Just installed a new copy of CS-Cart (2.0.12) in a new environment running Linux and PHP as CGI.
I followed the instructions here and changed all the files in the following directories from 777 to 755 (These are the folders that the installation specifically suggests setting 777):
/images/
/catalog/
/skins/
/var/
But I was still having trouble, so I did a little playing with permissions. I found that the 2 main files, index.php and admin.php, were set at 666. I changed them to 644 and it started working again!
Just thought I’d share this tip in case someone has the same problem.
bofco - that sorted my installation problem - thanks!
Let me try … good luck to me.
[quote]
For ANYTHING listed above (except for DSO), you cannot set any of your files or folders to permission ‘777’ as doing so will kill your site and cause Error 500 pages, the very title subject of this thread – thus the comment!
[/quote]
Hmm… I run all my clients under fast_cgi and have never had a problem with 777 permissions on directories. While I think this is hitting a tack with a hammer, I haven’t seen it cause an issue.
The helpdesk always tries to take the easiest way out by recommending to remove all security permissions on the files. I don’t recommend this approach but I can understand that they deal with many different sites hosted by man different providers. Hence the recommendation should address general permissions problems (which if investigated, usually are more about ownerships than permissions).
Just two cents…
[quote name=‘jbenitos’]Thanks for the ideas…
I’ve asked the client to try adding 4 products again via the clone method, and bang it breaks again. Basically after he adds the 4 products and trys to view them on the site, the page that contains the products becomes very slow and then just shows an error.
[/QUOTE]
Are you getting a true 500 error (I.e. you get a page from cs-cart that says 500 near the top) or are you getting an Apache “Server Misconfiguration Error”?
The latter is usually caused by a timeout where Apache is expecting PHP to respond within a certain period of time but it isn’t. Hence Apache thinks it’s dead and kills it.
[quote name=‘jbenitos’]Thanks for your reply. I understand this but it seems like bad code.
Any number that is allowed to be entered into that box should work. Surely there could be some sort of data validation that sets a limit?.
I work with software at work, and in my code I would never allow the user to input something that could break the program. Hmmm[/QUOTE]
The value of the number is directly related to the size of the field in the DB. For product quantity (amount) it is defined as ‘mediumint(8)’ which is 8 bytes. I’ll leave the calculation of the maximum amount to you. But it is a signed number so the top bit indicates positive/negative.
[quote]
But I was still having trouble, so I did a little playing with permissions. I found that the 2 main files, index.php and admin.php, were set at 666. I changed them to 644 and it started working again!
[/quote]
Shouldn’t make any difference as long as the file can be read by PHP (whatever php method you are using). Most Apache/PHP installations today run as the “owner” of the site and an appropriate group. If running CGI then the group will probably be ‘apache’. If not, it will probably be the same as the owner of the site (but depends on how the provider sets things up). You might want to look at the ownerships of the files. If running fast_cgi, then the owner/group should be the same as the root directory of your store.
My guess: If it’s 506 it’s mod_security related and the way the regex is calculated upon links. Sure fire way to know that it’s broke is that you cannot add banners to blocks.
I am getting a 500 Internal Server Error message : The server encountered an internal error or misconfiguration and was unable to complete your request.
I am getting this on my development site (which is on a subdirectory of my live site), but my live site is funtioning normally! The folders which I can see (I haven’t gone down through all the subdirectories) are set at 755, and the files at 655.
I don’t think this is a problem with the server, as the main site is ok, does anyone have any suggestions please?
Files should be 644.
Try 644, if you are using suPHP, use 600
Sorry my mistake, I meant they are 644. How do I tell if I am using suPHP?
mikee, disregard that advice above. 600 permissions have nothing to do with the PHP environment and will not work on many servers. If you want to try that setting to improve security then apply it to a single file (index.php) and load it in a web browser to see if it throws errors before applying it to all php files. If no error then you can safely apply 600 perms to the other php files
You can check your PHP environment using a phpinfo script and looking at the Server API section. If that states CGI or CGI/FastCGI then you are running in a suPHP environment. If it states Apache/Apache2 or similar then it is DSO (mod_PHP).
My server is Apache 2.0, so I guess that means it is DSO. What do you think I should change my folder & file permissions to, if this is the reason I can’t get it to work?
With DSO your permissions could be as CS-Cart suggests
[QUOTE]
chmod 666 config.local.php (644 after installing recommended)
chmod -R 777 images
chmod -R 777 skins
chmod -R 777 var[/QUOTE]
Note the -R means recursive (any files/directories below that level as well)
I said ‘could’ above because that is not optimal for security.
Technically these directories should be set to 777 and files to 666 but 777 on everything will work although is less secure.
The .htaccess files in these subdirectories should not be writable so 644 is best for those.
Thanks, will try to get these changed.