Framework Version: 3.1.5

I am having some issues with the flush procedure when alternating between flushing via the browser/URL (i.e. http://www.example.com/?flush=all) and flushing via the command line (i.e. php /var/www/html/example-www/framework/cli-script.php / flush=all)

To provide a bit of background, there are two servers involved (both managed by a third party) one for a staging environment (where I push my code and CMS users update the CMS) and one for the live externally visible website. A synchronisation process is carried out to copy the codebase and database from stage -> live and the CLI based flush is done as the last step of this process.

The problem is that on a number of occasions I have noticed behaviour that suggests that the CLI based flush is doing nothing at all i.e the live website has errors on certain pages which are resolved by me manually doing a flush=all via the URL.

I have been digging into the core code quite extensively to try and work out why this would be. I understand that a new sub-folder of silverstripe-cache/ is created for each 'user' which causes cache to be generated (as per the getTempFolderUsername() function in TempPath.php). From my testing regardless of wether I flush via the URL or CLI the 'user' is determined to be 'root' however, there are differences in the directories permissions, owner and group depending on which method I use:

Browser/URL Flush:
Dir = root
Perms = 755
Owner = apache
Group = apache

Command Line Flush:
Dir = root
Perms = 775
Owner = root
Group = root

This subfolder is created in the getTempFolder() function in TempPath.php but its permissions are never explicitly set.

I can see that there is some logic on the parent cache folder (silverstripe-cache) in the getTempParentFolder() function in TempPath.php to ensure that it has full read/write/execute permissions:

	// first, try finding a silverstripe-cache dir built off the base path
	$tempPath = $base . DIRECTORY_SEPARATOR . 'silverstripe-cache';
	if(@file_exists($tempPath)) {
		if((fileperms($tempPath) & 0777) != 0777) {
			@chmod($tempPath, 0777);
		}
		return $tempPath;
	}

However I have a couple of problems with this, 1) what is this portion of the if() condition meant to say/do

(fileperms($tempPath) & 0777)

and 2) from my testing this code doesnt work? I can set my silverstripe-cache/ directory perms to 555, do a dev/build, a flush=all and anything else yet the silverstripe-cache/ dir's permissions never change?

Either way I can see no logic to do the same 'permissions fixing' on any of the sub-folder e.g. silverstripe-cache/root/ or silverstripe-cache/apache/ etc and these are the directories which are getting all the cache files written to?

I have a couple of questions:

• Is this a bug
  
• are other people suffering the same issue
  
• Is there anyway I can force there to be 1 cache file which is used by all 'users' which would remove the issue?
  

Thanks in advance,

HARVS1789UK

Over 30 views but 0 responses :'-( Does nobody have a detailed understanding of the SS caching structure and why it needs different sets of cache files dependant on the current 'user'?

I’m not very familiar with this code and the reasons behind it, but I might be able to shed a little light.

(fileperms($tempPath) & 0777)

The single ampersand is a bitwise operator - the short answer is that it’s just checking whether permissions are 0777. There’s a little more info here if you’re interested: http://php.net/manual/en/function.fileperms.php

As for why the code doesn’t appear to work: my guess would be that the error suppression (“@”) before chmod() is suppressing an error - that SilverStripe can’t change the permissions of that directory.

I’d also guess that there’s no permission checking for the “user” directories because there doesn’t need to be - the user creates the directory, so it already has permission to read from/write to it.

You should be able to specify a path to use for the cache by defining the TEMP_FOLDER constant in your _ss_environment.php file:

define('TEMP_FOLDER', '/path/to/directory');

Hope this was of some use! Perhaps someone else can expand on some of your other questions.

Loz

Hi @kinglozzer,

Firstly, thanks very much for your reply, I had assumed that the fileperms() line must just be checking that the directory had RWX perms for owner, group and world but its good to have it confirmed.

It is also a good point about the @ for error suppression, I will try removing it (temporarily) and triggering the cache to be re-generated to see if it does indeed throw some meaningful errors.

Unfortunately, in my scenario at least, what you say about the 'user' directories is not strictly true:

"I’d also guess that there’s no permission checking for the “user” directories because there doesn’t need to be - the user creates the directory, so it already has permission to read from/write to it."

In my scenario regardless of wether this user folder is created by a URL flush (which I would expect to yield a result of 'apache') or CLI when logged in as root, the 'user' is always determined to be 'root', so I always end up with a folder called 'root'. However, regardless of the folder name, the owner, group and permission level of that directory do differ between the URL and CLI flush methods.

As you have said, if the 'user' folder has just been created by the current user, they will have read/write access to it, but there is also code which checks for its existence before creating it. So in my scenario the following happens:

• Start from scratch - Empty /silverstripe-cache/ directory
  
• Do a flush via the URL
  
• Current 'user' identified as 'root' by SS core code (incorrectly? Maybe this should be identified as 'apache'?)
  
• SS core code checks for existence of /silverstripe-cache/root/ (which doesn't exist)
  
• /silverstripe-cache/root/ directory created, with an owner/group of 'apache' and perms of 775
  
• Some period of time passes...
  
• Do a flush via the CLI (when logged in as root user)
  
• Current 'user' identified as 'root' by SS core code (correctly)
  
• SS core code checks for existence of /silverstripe-cache/root/ (which still exists but has owner/group of 'apache' and perms of 755 still!)
  
• /silverstripe-cache/root/ directory attempted to be written to by the 'root' user
  

It is this last step which I suspect is failing, as the root user wouldn't have permission to write to this directory would it?

Finally, I will double check the usage of

define('TEMP_FOLDER', '/path/to/directory');

but if memory serves I think that only allows you to specify the parent cache directory (i.e. /silverstripe-cache/) and regardless of what I set this to, the core code will still create sub-directories under this one such as 'root', 'apache' and 'unknown' etc

My next attempt at a fix will be to modify the automated CLI flush process to first give full permissions to the /silverstripe-cache/ directory and all of its sub-directories by running this before the flush:

sudo chmod -R 777 /var/www/sites/my-site/silverstripe-cache/

If that makes no difference then it would seem all of my assumptions about this being permissions related are incorrect and ill have to go back to the drawing board :-(