Setting up GS on pagodabox.com

[samrocksc]

Anyone had any luck with this? I have been playing with Boxfile configurations for two days now. What non data/admin files need to be consider read/write? If I can get this to work I can move both of my business sites over to a way cheaper and git deployable host.

I had no problem deploying on github pages, but this Boxfile bit is a bit of a different beast.

[shawn_a]

Before explaining all the possible configurations, please note that our infrastructure uses Apache. We recognize and read .htaccess files where much of your app's configuration takes place.

Why is a boxfile needed ?
What doesn't work ?

[samrocksc]

This is my first time deploying GS not off of FTP. I'm trying out a new host. In essence with ftp I could chmod my files to make them writeable. A Boxfile would be needed in this situation to make writeable directories.

Here is the documentation on the Boxfile: http://help.pagodabox.com/customer/porta...les/175475

Here is what I would normally chmod, so I'm just adding them as writeable on the Boxfile instead:

web1:
name: GetSimple
shared_writable_dirs:
- /backup
- /data
- /admin
- /theme

I would remove /admin after install so it could auto remove install, and setup files respectively. However I get 404'd when I go to try to /admin/install.php manually.

When I visit the target root of the file I get this:
Warning: include(admin/inc/common.php): failed to open stream: No such file or directory in /var/www/index.php on line 34 Warning: include(): Failed opening 'admin/inc/common.php' for inclusion (include_path='.:/usr/lib/php-5.3.8/php') in /var/www/index.php on line 34 Fatal error: Call to undefined function exec_action() in /var/www/index.php on line 37

I tried including a default version of PHP into the Boxfile.


This is my first time using a Boxfile or YAML, it's new to me. Perhaps someone has some experience? I'll gladly return a nice user friendly pagodabox.com guide if I can get an answer.

[shawn_a]

I thought you only needed a boxfile if you needed shared write across apps.

Sounds like your includes are failing.
Also install is in root not admin

[samrocksc]

I thought you only needed a boxfile if you needed shared write across apps.

Sounds like your includes are failing.
Also install is in root not admin

I had just cloned the repo from github and uploaded. /admin/install.php is the file that should automatically be running correct? I'll try to download it when I get home.

When I change file permissions locally and push it, it gives me 404's on anything in admin, and include problems on index.php. I tried it on another repo(I have 2 sites running GS I'm trying to switch to pagoda with) and got the same result.

[samrocksc]

I went and downloaded straight from the site instead of cloning from git, and I still get the same thing changed the htaccess to read/write, and i'm still getting this error

Unable to continue: Unable to write the configuration file. CHMOD 755 or 777 the /data, /backups folders & sub-folders and retry.

[shawn_a]

Well that sounds a little better, than include errors.

Ill have to try this pagodabox thing out, looks very neat.

[shawn_a]

Because your app code on Pagoda Box is in a read-only environment, it doesn’t accommodate running install scripts. The suggested workflow is to run install scripts locally, then push the results up to Pagoda.

That being said, it seem you do need to move a full site, and have a boxfile with write configs

[samrocksc]

Yeah, I have been playing with the Boxfile, I can get it for the most part to run, but it's hit or miss for what resource in the CMS is getting pulled. According to what I look at for the most part data, themes, backups, admin all need to be included into the Boxfile. It's almost like the Boxfile doesn't set everything recursively.

They are an awesome host, and probably the best I've found yet that uses git for deployment. All of their pre-packaged CMS systems are all sql based....

[shawn_a]

I couldn't get it working at all.
Ill try to clone their repo and see about pushing to it instead of pulling my repo.

And yes I do not think its recursive, it doesn't really say shit.

[samrocksc]

I am contacting their support. I'll switch 5 sites over to them if I can get GSCMS to work. I need some proof of concept though before I spend money on them ;0).

I'm pushing http://www.loficoffee.com right now to see. http://loficoffee.pagodabox.com. If we can figure out the Boxfile config we might be able to get them to put GS in their app cafe , then I would be a happy man for life.

[shawn_a]

Have you copied a working site yet?
I know the install script wont work at all I tried everything.

[shawn_a]

Got it working it works great, i get CSRF on everything, i gotta figure that out, probably related to the ip crap we haven't fixed yet.

There is a problem writing htacess in root as well as removing install files. Since you cannot grant write on root, although i have not tryed yet.

It appears it will not pick up github clone commits, only changed made to the pagoda git after the initial clone, might be a bug or something I am not understanding.

I have to finish up my boxfile with php modules and stuff.

[samrocksc]

Hey! Sent an email to their support to understand how the filesystem works, here is the reply:

> 1) .htaccess setup will not work?
Could you clarify a little more on how it will not work. If the cms is trying to edit the .htaccess in the runtime environment, it won’t work. Pagoda Box is a read-only environment (discussed mroe below). If you’re making changes to the .htaccess locally, then pushing those changes up to Pagoda Box, it may be a simple syntax error in the .htaccess.
> 2) Boxfile shared writeable is not Recursive?
Whenever you specify a directory as a shared writable directory, those permissions are recursive. You can modify that directory in any way you’d like. Be sure that in the Boxfile, it’s spelled “shared_writable_dirs” and not “shared_writeable_dirs” (no “e” in writable).
> 1) Is there a way to make shared writeable individual files?
There is a way to make a single file writable. It involves storing two versions of the file in your repo – one in it’s normal location and the other in a shared writable directory. You then use an after_build hook to symlink the two files.
Note, the Pagoda Box infrastructure is very different than traditional hosting. Apps consist of multiple instance that are spread across multiple servers. If each of these instance were able to write to their filesystems, they would write themselves out of sync, leading to some odd behavior for your app. Shared writeable directories are a centralized writable filesytem that is shared between all app instance. There are some caveats when using network filestorage. Really, shared writable directories are only meant for static assets like images and user uploads. We highly discourage ever storing any code in a shared writable directory for reasons below:

No Version Control or Emergency Rollbacks – Writable storage is not tracked by Git, so if any bugs are introduced through writable storage, there is no easy way to roll back to a previous, bug free version. You’ll have to manually edit the code.

Decreased Performance – Writable storage is housed on a storage cluster separate from your app’s components. While minimal, network latency does increase response times to files stored in writable storage. Running source code in your writable storage negates the performance optimizations built into the Pagoda Box infrastructure.

Code Caching + Writable Source Code = No Bueno – Opcode cachers like APC and eAccelerator are great for improving the performance of your app. But they do cause problems when multiple web or worker instances are running source code from shared writable directories. When code is cached on Pagoda Box, we assume the code is read-only (which it should be). Once a code cacher caches the file, it never reads it again. So, when an instance caches code, it’s cached until you redeploy. This can lead to odd behavior like code updates not being reflected in the live app or instances in the same app serving up different versions of the code.

Network File System Reliability – Shared writable directories are network file stores. If the network connection is interrupted in any way, source code stored in a shared writable directory will be temporarily inaccessible, potentially causing an error in your application. In some cases, these errors can only be fixed by restarting your web process or redeploying your app. Anything to which your app must have a constant connection should not be stored in writable storage. Pagoda Box takes every precaution to make sure network connections are always stable, but interruptions can happen.

It looks like the default install for GS would be kind of strange. I'm going to setup a Github repo for it, and start fiddling until I can do a clean install on pagodabox. Then people can just fork it if they want to install on it.

I for one think it would be rad to have an install option on their app cafe, so folks could easily use pagodabox for GS installs.

---

Anyways, I wasn't able to finish the above email, but here is what I can ascertain:

Whatever "single file" items we have that are not writeable, we need to create two copies of and then create hooks.

Do you have a github repo setup for what you are using? If you do I will fork, install and try out a couple things. I think there a couple single files in /admin that need to be writeable.

Thoughts?

[samrocksc]

I got to the point where I was getting CSRF while migrating my existing copy of an install over. I honestly think that is because my Boxfile didn't have the proper includes. The hard thing is figuring out which folders have writable content.