Comment exécuter des commandes en tant que root dans le hook git post-reception

J'ai récemment mis en place un dépôt git distant sur un serveur pour une application web fonctionnant en tant que service Upstart. Je souhaite utiliser le hook post-réception pour déclencher les actions requises pour mettre à jour le code d'application et arrêter puis redémarrer le service upstart. Voici mon fichier repo.git / hooks / post-receive:

#!/bin/bash
export GIT_WORK_TREE=/var/www/current/myapp/
echo "Checking out new files and restarting app"
echo $USER
git checkout -f
sudo /sbin/stop myapp-service
sudo /sbin/start myapp-service

Sur la base des informations que j'ai lues ici: askUbuntu.com , la façon d'obtenir les commandes upstart à exécuter en tant que root est d'éditer mon fichier visudo. Voici l'extrait pertinent:

%sudo   ALL=(ALL:ALL) ALL
admin   ALL=(ALL:ALL) NOPASSWD: /sbin/start myapp-service /sbin/stop myapp-service

Mais quand je pousse sur la télécommande, j'obtiens une sortie comme:

$ git commit -am "test" && git push prod master
[master 59ffccd] test
 1 file changed, 1 insertion(+), 1 deletion(-)
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 544 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
remote: Checking out new files on production and restarting app
remote: admin
remote: 
remote: sudo: no tty present and no askpass program specified
remote: Sorry, try again.

J'ai vérifié que l'utilisateur correct exécute le script de post-réception (admin, comme indiqué ci-dessus).

Quelqu'un peut-il m'aider à arrêter puis à démarrer le travail Upstart dans un script de hook git post-receive? Les scripts javascript Python, PHP ou node.js seraient également acceptables s'ils pouvaient exécuter la commande upstart plus facilement que bash (je suis un débutant bash)

J'ai regardé dans mon journal d'authentification et voici ce que j'ai:

Apr 24 19:35:21 myhost01 sudo: pam_unix(sudo:auth): auth could not identify password for [admin]
Apr 24 19:35:21 myhost01 sudo: pam_unix(sudo:auth): conversation failed
Apr 24 19:35:21 myhost01 sudo: pam_unix(sudo:auth): auth could not identify password for [admin]
Apr 24 19:35:21 myhost01 sudo: pam_unix(sudo:auth): conversation failed
Apr 24 19:35:21 myhost01 sudo: pam_unix(sudo:auth): auth could not identify password for [admin]
Apr 24 19:35:21 myhost01 sudo:    admin : 3 incorrect password attempts ; TTY=unknown ; PWD=/home/admin/myapp.git ; USER=root ; COMMAND=/s$
Apr 24 19:35:21 myhost01 sudo: unable to execute /usr/sbin/sendmail: No such file or directory
Apr 24 19:35:21  myhost01 sudo: pam_unix(sudo:auth): conversation failed

Vous devez séparer les commandes de votre fichier sudoers à l'aide de virgules. En ce moment, vous autorisez une seule commande: /sbin/start myapp-service /sbin/stop myapp-service.

Vous devez écrire admin ALL=(ALL:ALL) NOPASSWD: /sbin/start myapp-service, /sbin/stop myapp-service.

Ok, je l'ai compris. J'ai dû créer un script séparé contenant uniquement les commandes que je voulais exécuter en tant que root.

#!/bin/bash
sudo /sbin/stop myapp-service
sudo /sbin/start myapp-service

Ensuite, dans mon script post-réception:

#!/bin/bash
export GIT_WORK_TREE=/var/www/current/myapp/
set -x
echo "Checking out new files on production and restarting app"
echo $USER
git checkout -f
sudo /home/admin/restart-myapp

Et enfin dans mon visudo:

%sudo   ALL=(ALL:ALL) ALL
admin   ALL=(ALL) NOPASSWD: /home/admin/restart-myapp

J'espère que ceci aide quelqu'un d'autre

J'ai un fichier /etc/sudoers.d/root_groupqui contient juste la ligne %root ALL=(ALL) NOPASSWD: ALLet j'ajoute des comptes à la racine du groupe pour leur permettre d'utiliser sudosans mot de passe.

Je suis sûr qu'il y a des implications de sécurité pour les autorisations de fichiers qui ne considéraient pas les comptes d'utilisateurs comme étant dans le groupe "root", mais si vous êtes inquiet, un groupe différent peut être utilisé. %my_new_group ALL=(ALL) NOPASSWD: ALLModifiez simplement la ligne en et ajoutez les comptes pertinents à my_new_group.