4938 Posts in 16594 Topics by 1490 members
|Go to End|
6 October 2010 at 8:04am
I'm working on a SilverStripe installation on a Linux dedicated server.
http access works fine; https throws [User Error] Uncaught Zend_Cache_Exception: cache_dir is not writable
Any ideas on why we're having this problem?
During the testing phase we're using a self-signed certificate.
6 October 2010 at 12:21pm
Changing the cache permissions to 777 makes it possible to log in using https. However, other work -- uploading photos to assets, for example -- cannot be done because the assets folder is not writable for https. I don't want to make assets 777.
Can anyone point me to documentation that explains how to set up SilverStripe on a Linux server so that the admin interface works under https?
I'm working on a dedicated server with WHM and cPanel, so I'm pretty much free to configure this in any way I need.
I openly admit to being ignorant of the SSL environment requirements. However, it is supposed to be possible to set up under SilverStripe and I'd like to know how to do it.
Any help would be greatly appreciated.
7 October 2010 at 12:37am
I suggest you do the following:
1. Create a folder called silverstripe-cache into where you installed SilverStripe
2. Give the newly created folder web user write permissions (chown www-data silverstripe-cache for example)
3. Give the assets folder web user write permissions and all files inside (chown www-data -R assets)
All cached files SS generates for the site will now reside in silverstripe-cache instead of the system temp folder. This makes it easier to manage, and should fix your problem as it will use this folder consistently.
7 October 2010 at 12:07pm
I'm working with John on this, and we did exactly that. It worked for the most part, but when we tried to upload a file in the Files & Images section (via https), it seemed to not want to heed our cache folder selection, and tried to read/write to the systems '/tmp' folder.
I got an error on:
It looks to me like it is trying to access the /tmp folder, which I imagine is where PHP puts files that get uploaded via a standard file upload.
We haven't run into this on other hosts, so we're not sure if this is a SilverStripe issue, or not. It seems to work (no error) when we're not in https. One thought we had was that the host might be running as a different user when in https mode. It may be using the /tmp folder when we're not in https, and simply be working.
Do you know where I can override the /tmp directory for uploads? That might be a work-around that would get us where we need to be.
7 October 2010 at 1:50pm Last edited: 7 October 2010 1:52pm
I think the problem you're having is that uploads don't use this folder because PHP uses it's system temporary folder for uploads.
This also applies to where sessions are stored by PHP as well. We'll need to override these to use the SilverStripe defined temp path instead.
Add these two lines to the top of mysite/_config.php:
Now it should be using the "silverstripe-cache" folder for session, uploads and SilverStripe caches! This keeps it tidier, because all of the temporary files are stored in the same place.
9 October 2010 at 9:13am
Thanks Sean! That was a great idea.
Unfortunately it didn't work.
I tried adding that to mysite/_config.php like this:
global $project, $database;
$project = 'mysite';
$database = 'SS';
In our _ss_environment.php we are defining the cache dir as well.
# Cache Dir
I also tried adding your lines to our _ss_environment.php file, after we defined the TEMP_FOLDER, like this:
The error I am seeing is:
[Warning] Unknown: open(/tmp/silverstripe-cache-home-stripe-public_html/sess_58f46e4a101d50f45488dd4831bc6512, O_RDWR) failed: Permission denied (13)
Seems not to be heeding our instructions.
Again, this only happens when we are using https. It all works fine for http.
Any other thoughts?
Thanks for your help so far!!!
9 October 2010 at 9:51am Last edited: 9 October 2010 9:54am
The following is not necessary if silverstripe-cache exists in the project code (as Core.php works this out for you):
It's a bit puzzling that you can't get the sessions to store elsewhere.
|Go to Top|