¿Por qué EC2 no está extrayendo actualizaciones de bitbucket / github a través del enlace post-recepción?

Antes de moverme a EC2, enviaría commits a un repository bitbucket y un gancho post-recepción los pasaría al server: después de una confirmación, se llama a la URL http://mywebsite.com/update.php , donde update.php es:

<?php `git pull`; ?> 

Eso solía funcionar como un encanto. Sin embargo, no está funcionando en EC2 y no estoy seguro de por qué.

Intenté lo siguiente:

  1. sudo chmod +x update.php Esto debería hacer que update.php sea ejecutable.

  2. Cambió update.php a

     <?php `sudo git pull`; ?> 
  3. Cambió update.php a

     <?php `sudo -s`; `git pull`; ?> 
  4. Cambió update.php a

     <?php `sudo -s git pull`; ?> 

Creo que tiene algo que ver con los permissions, porque cuando estoy en mi instancia a través de ssh, puedo ejecutar "git pull" como ec2-user. Además, "git pull" funciona cuando soy el usuario root.

¿Cómo puedo hacer que funcione? Creo que fue algo relacionado con los permissions.

Actualizar

Hice algunos problemas (gracias por las sugerencias @ cyberx86) y encontré lo siguiente:

Pude ejecutar el enganche de la actualización en la línea de command ejecutando php update.php y funcionó por qué era root, pero no cuando era ec2-user. El logging de error mostró

error: no se puede abrir .git / FETCH_HEAD: Permiso denegado

así que ejecuté el command chmod -R 777 .git como el usuario raíz.

Ahora puedo extraer actualizaciones a través de git pull y php update.php en la command-line, pero no funciona cuando lo hago a través del enlace posterior a la recepción o cuando apunto mi browser a url / update.php. El logging de error muestra

La verificación de la key de host falló. ^ M
fatal: el extremo remoto colgó inesperadamente

Creo que esto significa que el usuario que ejecuta el command cuando se accede a él a través de un browser no tiene configurada una key ssh, por lo que parece que el command de shell se está ejecutando, pero el repository remoto no permite que el usuario lo extraiga.

Según el consejo de @ cyberx86, revisé a los usuarios en / etc / passwd y mientras no haya usuario de PHP, hay un usuario llamado apache: apache:x:48:48:Apache:/var/www:/sbin/nologin y luego ejecuté sudo -u apache php -q update.php y recibí el siguiente post

No se pudo crear el directory '/var/www/.ssh'.

La autenticidad del server 'bitbucket.org (207.223.240.181)' no puede ser establecida.

La huella dactilar de la llave RSA se ha REDACTADO

¿Estás seguro de que quieres continuar conectando (sí / no)? sí

Error al agregar el host a la list de hosts conocidos (/var/www/.ssh/known_hosts).

Permiso denegado (publickey).

fatal: el extremo remoto colgó inesperadamente

Por lo tanto, parece que se trata de configurar una key ssh para el usuario (presumiblemente apache) que ejecuta el script de shell a través del browser.

  1. Los files PHP normalmente no necesitan ser ejecutables para ejecutarse
  2. Intente ejecutar su script PHP directamente (en lugar de simplemente ejecutar git pull ); lo que es más importante, intente ejecutar su script PHP mientras el usuario PHP se ejecuta como (posiblemente www-data , apache , etc., poco probable que sea ec2-user ) algo así como (como raíz): sudo -u php_user php -q /path/to/update.php .
  3. Aumente la verbosidad de su error_reporting y display_errors ; también verifique sus files de logging.
  4. Finalmente, sudo (lo que tienes en tu script) solo funciona si está configurado en sudoers, lo que probablemente no sea para el usuario de php.

El usuario php se está ejecutando como será:

  1. En httpd.conf de Apache (directivas de User , Group )
  2. En su configuration de VirtualHost (por ejemplo, si usa suExec, busque la directiva SuexecUserGroup )
  3. En su configuration para su grupo PHP-FPM (/etc/php-fpm.d/) si usa php-fpm como su administrador de process php (las directivas de user y group para el set).

En lugar de cambiar los permissions (es decir, chmod ), debe cambiar la propiedad ( chown ) de los files para que coincida con la de su usuario php. Los files PHP generalmente deben tener 644 permissions y directorys 755 permissions. 777 debe evitarse para cualquier cosa que no sea una testing (o, a veces, un directory temporal): si arregla la propiedad, no necesitará permissions tan laxos.

Finalmente, parece haber dos problemas: 1. que no tiene una configuration de key para que su usuario de php se conecte al server de git y 2. que no tiene una copy de la key del server de git (es decir, para autenticar) que te estás conectando al server correcto).

Para get la key que le permitirá iniciar session en el server de git (no estoy familiarizado con Bitbucket), supongo que será necesario uno de los siguientes (solo uno, no todos):

  • Ya tiene una key SSH (para el usuario root) que puede poner a disposition de su usuario de PHP
  • Generará una nueva key en el server para el usuario de PHP y la cargará en bitbucket
  • Generará una nueva key en bitbucket y la downloadá a su server, agregándola a las keys de su usuario de PHP.

Para get la key del server de Git debe ser más simple:

  1. Cree el directory /var/www/.ssh con la propiedad y los permissions correctos (para que php pueda escribir en él).
  2. Prueba SSH desde el server al git repo (o ejecuta git clone ; es posible que git pull también funcione) como usuario de php, y acepta la key que proporciona el server git.

Supongo que hiciste algo similar a lo anterior cuando inicialmente configuraste tu server para usar bitbucket (si no, mira la documentation )

(Publicado en nombre de OP)

Resuelto. Esto es lo que hice. Para solucionar problemas, agregué

 echo `whoami`; 

actualizar.php y cuando lo ejecuté a través del browser, mostró el nombre de usuario (no era el usuario apache, era otro usuario el que estaba configurado en el file hosts virtual). También noté que en /etc/passwd ese nombre de usuario como acceso a / bin / bash (a diferencia del usuario apache, que está restringido a / sbin / nologin), pero el acceso de ese nombre de usuario al shell está limitado en el file sudoers. Ese file contenía !SHELL al final de los derechos de sudo para el usuario, así que lo eliminé usando visudo y ahora funciona.

Encontré algunas publicaciones en Stack Overflow y Server Fault que están relacionadas: una , dos y tres .

Usé una versión simplificada del método en el tercer enlace, pero utilicé un command de shell en lugar de señalar un script de shell.

Estoy un poco preocupado por si he dejado algún agujero de security debido a todo el violín que he estado haciendo con los permissions de file y /etc/sudoers pero en este punto estoy contento de que funcione. Idealmente, me gustaría get el command para ejecutar sin sudo porque parece que eso sería más seguro, pero es probable que sea una de esas cosas que uno nunca hace una vez que uno encuentra una solución lo suficientemente buena para el problema .