Deploying Symfony2 apps with magephp and file system acls

Releases still seem to be the most frightening point in the chain of development events towards finishing a release. I recently had a discussion with a coworker about the best way to deploy a php app, specifically the rights management on the server. We are using magephp for our deployments, which does the same thing as capistrano back in the days, but is way cooler, because it's written in php and installable via composer.

Based on the discussion, here is my attempt so solve all problems and bring peace to the world:

Our deployment root should be e.g. /srv/www. In this directory, we have eventually a domain dir (which is the reversed DNS name, like com.xenji, but in all cases an application dir, which matches the subdomain it is hosted on (like blog). In this application dir we have the default mage release folder structure: current (a symlink), releases and our own addition "shared". We've borrowed this from capistrano, as we needed something to put the logs and shared config files into.

The final structure looks like this:

lrwxrwxrwx   deployer nobody current -> releases/20140305105721
drwxr-xr-x  deployer nobody releases
drwxr-xr-x   nobody   nobody shared

So far, great. We have a structure everybody can remember, all cool. But wait! Nobody? Deployer? Shared is only writable for the server process? Let's peek into the folders:

The releases folder looks quite normal:

drwxr-xr-x 9 deployer nobody 4.0K May  1 16:15 20140501141458
drwxr-xr-x 9 deployer nobody 4.0K May  1 16:30 20140501142942

The shared folder look a bit different in terms of rights.

$> ls -lah shared/app/
drwxr-xr-x  3 nobody nobody 4.0K May  1 10:03 .
drwxr-xr-x  3 nobody nobody 4.0K May  1 10:03 ..
drwxrwxr-x+ 2 nobody nobody 4.0K May  1 10:03 logs

The logs folder is linked into the release folder right before the commands for that release start (generate caches, etc). You might have noticed the plus sign on the right of the folders permission bits. This is the indicator for "There are additional ACLs". You can fetch them with:

$> getfacl logs
# file: logs
# owner: nobody
# group: nobody
user::rwx
user:deployer:rwx
group::r-x
mask::rwx
other::r-x

The group nobody does not have any rights on that folder, but only the deployer user has (in addition to the webserver) the permission to write the logs folder. The same thing is on the app/cache folder. This solves the conflict between the delpoy user and the webserver user.
The application folder looks like this: 

...
-rw-r--r--  1 deployer nobody  90K Apr  7 15:28 bootstrap.php.cache
drwxrwxr-x+ 3 deployer nobody 4.0K May  1 16:30 cache
-rw-r--r--  1 deployer nobody 1.8K Feb  7 18:08 check.php
drwxr-xr-x  3 deployer nobody 4.0K May  1 16:30 config
-rwxr-xr-x  1 deployer nobody  867 Feb  7 18:08 console
-rw-r--r--  1 deployer nobody   13 Feb  7 18:08 .htaccess
lrwxrwxrwx  1 deployer nobody   49 May  1 16:30 logs -> /srv/www/some/path/shared/app/logs
...

The original author of Magallanes seems to have stopped the active development on the project, so we've added plenty of features to our fork of Magallanes, check it out on github: https://github.com/freshcells/Magallanes. You will find the ACL task, a new deployment strategy via remote cache (similar to the one you might know from capistrano) and more.