Yii does not work with cloudcontrol - clouds - ideas?

I recently tried to setup a Yii application at cloudcontrol.com and basically the problem that I am having is that cloudcontrol is a read-only system. Save for a tmp directory Yii cannot write to the system, which is needed for the runtime and assets directories. How can I overcome this? Is it possible to write to a mongodb instance instead to those directories?

It makes me think that for Yii to be cloud-ready some sort of workaround should be possible to use something like mongodb or something like that to store files created at run time. Any ideas?

Many thanks :)

i first time here about read only cloud :blink:

This is not yii problem…

You can turn off all things that work with runtime…

errors logging… set state to memory, etc.

Thanks David.

So basically every single call to mkdir(); every single call to file_put_contents (or fopen … fwrite … etc.) is not needed for the framework to work. Is this correct?

The function setRuntimePath($path) { … } on line 264 under framework/base/CApplication.php of Yii version 1.1.8 makes the whole application die if the directory runtime is not writable under the protected folder of the application.

Do you mind telling me or pointing me into the docs part that talks about turning both the runtime directory off all together and the assets directory off for all write purposes?

Many thanks.

–Ilan

If you look closer to your stack trace, you see, that the setRuntimePath originated from a CFileLogRoute::init(). So you seem to have configured such a log route in your main.php. Try to disable this first and try again.

Are you sure it’s not a matter of file permissions ?

Hi, I had a similar problem that I partly resolved.

True cloudControl has a readonly file system for scalability. So, Yii cannot write to the runtime and assests folders though you can change the ‘runtimePath’ and ‘assestManager’ ‘baseURL’ to point to the tmp directory served by $_SERVER[“TMPDIR”].

Note this will only eliminate the exception you had earlier, the images tied to widgets will not show and any jquery functions also tied to the widgets will cease working.

I found a workaround on my local web server (WAMP) but I couldn’t deploy it on cloudControl. I mapped the assests URL to the file system directory supplied by $_SERVER[“TMPDIR”] by adding the following line to the Apache httpd.conf file.

Alias /assets "path/to/tmp/dir"

The config file (ccconfig.xaml) on cloudControl only allows a limited number of parameters to be configured and setting up an alias is not one of them. According to the cloudControl support staff setting an alias via the config file maybe a future enhancement, they suggested symlink, as a workaround.

And, that’s where I got stuck. Anyone with suggestions?

Thanks.

I ran in the exact same problem with cloudcontrol.com and I’m in the process of resolving this. The most obvious and probably best solution is to use MongoDB where possible and Amazon S3 for any public assets.

I’m currently using the directmongosuite extension which includes components for saving sessions, cache and logs in a MongoDB database. For assets, there is a fresh extension, s3assetmanager, to manage them on Amazon S3, but I did not use it yet.

Note also that you could use the MongoDB GridFS for saving files in the database.

Is there any other functionality that require filesystem access?

I just started looking into Yii as a potential framework a day or two ago and after watching some instructional videos on youtube,

I discovered the cloudcontrol host and the subsequent errors from trying to use Yii with their service. I don’t know enough about this stuff to evaluate the potential security issues or any other unknown unknowns….

for runtime dir not writeable error, locate line below in framework/base/CApplication.php

$this->setRuntimePath($this->getBasePath().DIRECTORY_SEPARATOR.‘runtime’);

change to

$this->setRuntimePath($_SERVER["TMPDIR"]);

for assets dir not writeable error, locate line below in framework/web/CAssetManager.php

$this->setBasePath(dirname($request->getScriptFile()).DIRECTORY_SEPARATOR.self::DEFAULT_BASEPATH);

change to

$this->setBasePath($_SERVER["TMPDIR"]);

This stopped all errors after initial installation… and as I said - I’m not sure if this is even an good idea…. :)