Buenas,
Os cuento mi problemática: en mi empresa disponemos de un servidor de integración continua (Jenkins) que además es el encargado de desplegar las aplicaciones de manera automática en producción.
Para realizar el deploy Jenkins se apoya en Phing (gemelo de Ant en PHP para los que no lo conozcan) utilizando para ello un script implementado por nosotros mismos que básicamente hace un rsync del código del proyecto (incluídos vendors) al servidor de producción.
La conexión al servidor de producción y el despliegue se realizan mediante un usuario tecnico distinto del usuario que ejecuta nginx, la cuestión es que tras el deploy ejecutamos el comando cache:clear sobre el servidor de producción y este arroja un error diciendo que no puede escribir en el directorio de caché.
Dado que no nos sirve ninguna de las otras opciones, para tratar de solucionar el problema hemos seteado umask(0000); en los ficheros app.php y app/console. La cuestión es que cuando se empiezan a generar los archivos de caché estos no se generan con permisos 777 sino que lo hacen con 666 (-rw-rw-rw-) y el problema de los permisos se repite en cada deploy teniendo que entrar a borrar manualmente el contenido de estos directorios.
¿Alguna idea de qué está pasando y qué puedo hacer para solucionarlo?
Gracias de antemano.
Un saludo
Respuestas
Lo primero que hay que tener en cuenta es que la instrucción umask() de PHP en realidad lo único que hace es restar un valor respecto al valor global del umask en el sistema. Así que umask(0000); está restando 0, por lo que en realidad es lo mismo que decir: utiliza el umask global.
El valor del umask de tu usuario lo puedes descubrir directamente ejecutando el comando umask. En mi caso por ejemplo me sale esto:
$ umask 0022
Para configurarlo, edita el archivo /etc/bashrc o /etc/profile y pon el valor que quieras:
# /etc/bashrc umask 000
En cualquier caso, y aunque no se si es posible en vuestro caso, la única manera recomendada de solucionar el tema de los permisos de Symfony es utilizar el mismo usuario en la consola y en el servidor web. Esto es por ejemplo lo que hacen los programadores de SensioLabs (la empresa que está detrás de Symfony), tanto en sus entornos locales de desarrollo como en producción.
Así que si abrís el archivo de configuración de nginx y cambiáis el usuario para que sea el mismo que el que ejecuta los comandos en la consola, habréis acabado con el problema de los permisos para siempre.
@javiereguiluz
Una vez más, muchísimas gracias por tu ayuda Javier, la verdad es que estaba un poco equivocado en cuanto al comportamiento de la función umask de php, y lo que me comentas respecto a la manera solucionar de una vez por todas el problema con los permisos también me es de gran utilidad.
Un saludo.
@beni0888
Hola de nuevo Javier,
pese a seguir las instrucciones que me has dado seguimos teniendo problemas con el deploy... La cuestión es que en nuestro servidor de despliegue tenemos montada una infraestructura con Docker (supongo que lo conocerás, es un sistema de virtualización basado en contenedores ligeros), en dicho servidor tenemos un contenedor con el servidor web que monta en "/var/www/myProject" el directorio "/home/tecnico/myProject" del servidor físico. La cuestión es que al hacer el deploy nosotros lanzamos el comando de symfony "cache:clear" sobre el servidor físico del siguiente modo:
/home/tecnico/myProject/app/console cache:clear -e prod --no-debug"
Y dicho comando arroja el siguiente error:
[RuntimeException]
Unable to write in the "/var/www/myProjec/app/cache/prod" directory
Según se puede ver, el comando falla porque no puede escribir en el directorio en cuestión, lo cuál es lógico ya que dicho directorio no existe en el servidor físico, sólo existe dentro del contenedor. La cuestión es, ¿por qué el comando cache:clear está intentando escribir en este directorio del contenedor si yo lo estoy lanzando desde el servidor físico?
@beni0888
¿Es posible que el error tenga algo que ver con este error reportado en el repositorio de Composer?
@javiereguiluz
Pues la verdad es que no sé si tendrá algo que ver con el error que comentas, es muy extraño porque el error lo daba al lanzar el comando "cache:clear" habiendo ya generados archivos de cache creados por el servidor web, pero tras borrar el contenido de la cache manualmente y volver a lanzar el comando este se ejecutaba correctamente sin errores.
@beni0888