search

xforty / drush-deploy

Drupal deploy tool based on Capistrano and Drush
https://github.com/xforty/drush-deploy/wiki
Other
35 stars 4 forks source link

ACL problems in Drupal #10

Open medlefsen opened 12 years ago

medlefsen commented 12 years ago

Right now we have code that, if it can, sets up file system acls on the files directory so apache can write to it.

This was done because file system ACLs are by far the easiest way to deal with the complex permissions issues that come up (no more chmod 777 or group + umask ). However two things have come up:

  1. We need to set the mask in addition to the user permissions. This just means add m::rwx to the acls we apply.

  2. Bigger issue is that Drupal has bugs that prevent it from doing certain things if it only has ACL access to the directories.

    This was first discussed in this issue http://drupal.org/node/1333390 but was then merged into http://drupal.org/node/944582 which also provides a patch which is going into drupal 8 but can be applied to drupal 7. Code needs to be added to drush deploy to detect if the drupal version supports ACLs and has some kind of fallback otherwise.

dkingofpa commented 11 years ago

Would this resolve issues with removing older releases during deploy:cleanup? Currently, I have to keep running chmod -R u+w [oldest_release] so I don't get permission errors and the whole deployment fails.

dkingofpa commented 11 years ago

I keep getting burned by this issue on projects. Is there a better workaround than the one described above? Why can't we just chmod -R u+w the release right before we run rm -rf?

dkingofpa commented 11 years ago

This is what I'm seeing:

  * 2012-12-19 21:28:52 executing `deploy:cleanup'
 ** keeping 5 of 6 deployed releases
  * executing "rm -rf /home/user/example.com/releases/20121217171354"
    servers: ["example.com"]
    [user@example.com] executing command
*** [err :: user@example.com] rm:
*** [err :: user@example.com] cannot remove `/home/user/example.com/releases/20121217171354/sites/default/default.settings.php'
*** [err :: user@example.com] : Permission denied
*** [err :: user@example.com] 
*** [err :: user@example.com] rm:
*** [err :: user@example.com] cannot remove `/home/user/example.com/releases/20121217171354/sites/default/files'
*** [err :: user@example.com] : Permission denied
*** [err :: user@example.com] 
*** [err :: user@example.com] rm:
*** [err :: user@example.com] cannot remove `/home/user/example.com/releases/20121217171354/sites/default/settings.php'
*** [err :: user@example.com] : Permission denied
*** [err :: user@example.com] 
*** [err :: user@example.com] rm:
*** [err :: user@example.com] cannot remove `/home/user/example.com/releases/20121217171354/sites/default/local.settings.php'
*** [err :: user@example.com] : Permission denied
*** [err :: user@example.com] 
    command finished in 1723ms
pearcec commented 11 years ago

@dkingofpa I think this issue is a separate issue. The ACLs is something Matt uses to ease the pain of having user deployment and webserver write access. Seems like the ACLs doesn't play nice with Drupal in general. We don't experience this issue at the moment because we are typically using drush-deploy in a control-panel environment using FastCGI which means the server is running as the user we are deploying with. I opened a new issue. #14