unable - Symfony2 Capifony deploy setfacl Operación no permitida en el directorio de caché

symfony2 filesystem

Question

Estoy implementando mi aplicación web Symfony2 en un servidor web Apache, en una máquina Ubuntu, alojada en AWS, utilizando el despliegue de múltiples etapas de Capifony.

Tengo un usuario configurado

set :user, "ubuntu"

Y el directorio de escritura para el caché se configuró como tal

set :writable_dirs, ["app/cache"]
set :webserver_user, "www-data"
set :use_set_permissions, true
set :permission_method, :acl

Todo se despliega bien aparte de cuando se ejecuta

executing "setfacl -R -m u:ubuntu:rwx -m u:www-data:rwx /var/www/releases/20140310012814/app/cache"

Recibo múltiples errores de Operación no permitidos, como

setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: Operation not permitted

Parece que el usuario, supuestamente ''www-data'', no puede establecer permisos en los archivos creados por ''ubuntu''. Sin embargo, he ejecutado lo siguiente en el servidor desde el directorio / var / www / current, pero no estoy completamente seguro de lo que hacen:

sudo setfacl -R -m u:www-data:rwX -m u:`whoami`:rwX app/cache
sudo setfacl -dR -m u:www-data:rwx -m u:`whoami`:rwx app/cache

Aquí hay alguna información de acl

getfacl app/cache
# file: app/cache
# owner: ubuntu
# group: ubuntu
user::rwx
user:www-data:rwx
user:ubuntu:rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:user:www-data:rwx
default:user:ubuntu:rwx
default:group::rwx
default:mask::rwx
default:other::rwx

He echado un vistazo a un problema similar aquí ¿Debería ejecutar algo similar? como:

sudo sh -c ''setfacl -R -m u:ubuntu:rwX -m u:www-data:rwX /var/www/current/app/cache''

Gracias

Answer 1

Capifony tiene una entrada de libro de cocina que explica cómo configurar automáticamente los permisos adecuados . Básicamente lo que necesitas es esto:

set :writable_dirs, ["app/cache", "app/logs"]
set :webserver_user, "www-data"
set :permission_method, :acl
set :use_set_permissions, true

:use_sudo no necesita ser true siempre que los :writable_dirs sean propiedad de :user .

El problema

setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: operación no permitida

Este mensaje indica que el directorio de caché no está vacío cuando se ejecuta la tarea ( setfacl opera en prod/classes.php en ese directorio), que no es propiedad de :user ( setfacl no está permitido).

El hecho de que el archivo no sea propiedad de :user es bastante normal porque el servidor web creará una gran cantidad de archivos de caché, que los hacen propiedad de :webserver_user .

Lo extraño aquí es que el directorio de caché no está vacío. Normalmente, una nueva versión debe tener un directorio de caché vacío. Una causa común para esto es que el directorio de caché está compartido, lo que significa que lo ha agregado a :shared_children . Si es así, elimínelo. El directorio de caché no debe ser compartido.

Si este no es el caso, intente averiguar por qué el directorio de caché no está vacío cuando se setfacl tarea setfacl . Quizás otras tareas se estén ejecutando pronto.

Escribir niños compartidos

¿Qué sucede si realmente desea que un directorio compartido pueda escribirse para el servidor web? Esto es realmente muy común, piense en un directorio de media o uploads que deba compartirse.

Los permisos deben establecerse en el directorio compartido real, no en el enlace simbólico en el directorio de publicación. Capifony se ocupa de esto, siempre que la misma frase en :writable_dirs también esté en :shared_children .

# this will work:
set :shared_children, ["web/uploads"]
set :writable_dirs, ["web/uploads"]
# this will also work:
set :web_path, "web" # is default
set :shared_children, [web_path + "/uploads"]
set :writable_dirs, ["web/uploads"]
# this will not:
set :web_path, "web" # is default
set :shared_children, [web_path + "/uploads"]
set :writable_dirs, ["web/uploads/"] # trailing /

Compruebe si el directorio mencionado en el error es el directorio compartido real (no el enlace simbólico).

El propietario del directorio compartido debe ser el usuario que ejecutará el comando setfacl . En otras palabras, debe ser :user . Cuando haya cambiado el valor de :user , o haya tenido :use_sudo habilitado en el pasado, esto podría causar problemas. Compruebe si los directorios (tal como están establecidos en :writable_dirs ) son propiedad de :user .

Capifony realizará una comprobación si los permisos ya están establecidos. Si es así, no intentará hacerlo de nuevo. Esto se hace con el siguiente comando:

getfacl --absolute-names --tabular #{dir} | grep #{webserver_user}.*rwx | wc -l"

Intente ejecutar este comando manualmente (reemplace #{dir} y #{webserver_user} con los valores reales) para ver el resultado. Si no produce ningún resultado, Capifony supone que los permisos aún no se han establecido e intentará hacerlo.

En ese caso, compruebe manualmente los permisos con getfacl . Si son incorrectos, configúrelos manualmente (de nuevo, reemplace #{user} , #{webserver_user} y #{dir} ) usando "the power of root":

sudo setfacl -R -m u:#{user}:rwX -m u:#{webserver_user}:rwX #{dir}
sudo setfacl -dR -m u:#{user}:rwx -m u:#{webserver_user}:rwx #{dir}

Luego, ejecute Capifony nuevamente. Si todo está bien, ¡debería tener éxito esta vez!

Answer 2

Ha ejecutado sudo setfacl en el directorio actual, pero está recibiendo los errores en las carpetas de versiones únicas. De todos modos, www-data debe ser el propietario correcto de la carpeta de caché, ¡es el usuario principal de ese directorio, al final!

En nuestro script de implementación, usamos esto:

set :permission_method, :acl
set :writable_dirs, ["app/cache"]
set :webserver_user, "www-data"
set :use_set_permissions, false
set :use_sudo, false

Creo que esta es la solución correcta.