Manejo de shared/tmp en un proyecto de Ruby on Rails cuando el usuario de implementación es diferente al usuario de ejecución

ruby-on-rails permissions

Question

Tengo dos usuarios en mi servidor, un servidor virtual Ubuntu 12.04 que administro yo mismo:

• projectx se usa para implementar la aplicación y es el usuario / grupo para la mayoría de los archivos en / var / www / projectx
• projectx_rails y se usa para ejecutar la aplicación Rails. De esta forma, la aplicación de raíles en ejecución no tiene acceso para modificar el código fuente.

Algunos directorios, como public / uploads, están configurados para pertenecer a projectx_rails: projectx_rails, de modo que la aplicación Rails pueda escribir los archivos cargados.

Mi problema viene al directorio tmp. Este directorio se encuentra en / var / www / projectx / shared y está vinculado a cada versión en la forma usual de manejar las publicaciones. El problema es que algunos archivos creados durante la implementación no se pueden escribir en la aplicación de raíles en ejecución y los archivos creados por la aplicación Rails no se pueden escribir en el proceso de implementación.

¿Hay alguna manera de manejar esto? Tener todos los archivos que pertenecen a projectx_rails: projectx_rails y ser de grupo de escritura sería suficiente, pero no estoy seguro de cómo desencadenar esto.

Estoy usando: Capistrano 3, Rails 3.2, Ruby 2.1.2, Unicorn 4.8.3, nginx.

Answer 1

¿Se puede usar ACL para archivos compartidos? Lo único que habilita el soporte de ACL en fstab.

setfacl -m d:u:projectx:rwx,u:projectx:rwx,/
d:u:projectx_rails:rwx,u:projectx_rails:rwx /var/www/projectx/shared/tmp

Answer 2

1) asegurar que tanto projectx como projectx_rails son miembros del grupo projectx 2) agregar esto para implementar:

task :change_tmp_pems do
run "chmod -Rf 775 #{shared_path}/tmp"
end
after "deploy:started", :change_tmp_pems

the -f fallará / saltará silenciosamente cualquier archivo al que no tenga acceso, por lo que no será un problema.

4 líneas de código, bastante breve. No hable con chown ya que requiere sudo normalmente y es innecesario.

Answer 3

Bueno, esta es mi teoría. Obviamente es difícil probarlo por mi cuenta, así que considéralo una conjetura.

Primero: crea un grupo al que pertenezcan ambos usuarios. Como projectx_shared .

Segundo: haga de este grupo el propietario del grupo del directorio tmp :

chown projectx_rails:projectx_shared tmp

Tercero: configure el bit setgid en este directorio:

chmod g+s tmp

Ahora, el propietario del grupo de los archivos agregados a tmp debe establecerse en projectx_shared automáticamente. Creo que esto se aplicará también a las tareas capistrano.

Supongo que cuando implemente, los archivos ya obtienen los permisos rw-rw-r-- automáticamente. De lo contrario, deberá configurar su UMASK a 002 en su, por ejemplo, .bashrc también.

Déjame saber si funciona...

Answer 4

Mi solución actual es tener esta tarea:

namespace :deploy do
desc "Fix permissions"
task :fix_permissions do
on roles(:app) do
execute "sudo chown -R projectx_rails:projectx_rails #{shared_path}/tmp"
execute "sudo chmod ug+rwX,o+rw #{shared_path}/tmp"
end
end
end

y ejecutarlo tanto al principio como al final de mi implementación:

after "deploy:started", "deploy:fix_permissions"
before "deploy:restart", "deploy:fix_permissions"

y para que funcione, tuve que agregar esto a mis sudoers:

projectx ALL=NOPASSWD: /bin/chown -R projectx_rails/:projectx_rails /var/www/projectx/shared/tmp
projectx ALL=NOPASSWD: /bin/chmod ug+rwX/,o+rw /var/www/projectx/shared/tmp

lo que me hace bastante incómodo

Answer 5

Puede ejecutar comandos en la máquina remota a través de capistrano. Podría ejecutar un cambio de propietario de directorio después, digamos, de vincular simbólicamente la aplicación.

En su archivo deploy.rb , agregue una devolución de llamada:

after ''deploy:create_symlink'' do
run "chown -R projectx_rails:projectx_rails #{current_release}/tmp"
end