Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I just recently set up a remote git repo on a server for a web app running as an Upstart service. I'd like to use the post-receive hook to trigger actions that are required to update the application code and stop then restart the upstart service. This is my repo.git/hooks/post-receive file:

#!/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

Based on the info I read here: askUbuntu.com, the way to get the upstart commands to execute as root is to edit my visudo file. Here is the relevant snippet:

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

But when I git push to the remote, I get output like:

$ 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.

I've checked that the correct user is executing the post-receive script (admin, as echoed above).

Can someone help me stop and then start the Upstart job in a git post-receive hook script? Python, PHP, or node.js javascript scripts would also be acceptable if they would be able to exec the upstart command more easily than bash (I'm a bash newbie)

I looked in my auth log and this is what I have:

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
share|improve this question
    
The colon looks wrong after NOPASSWD. Also, have you checked the logs? "/var/log/auth.log" –  Elliott Frisch Apr 25 '14 at 0:19

3 Answers 3

up vote 2 down vote accepted

You need to separate the commands in your sudoers file using commas. Right now, you're authorizing a single command: /sbin/start myapp-service /sbin/stop myapp-service.

You need to write admin ALL=(ALL:ALL) NOPASSWD: /sbin/start myapp-service, /sbin/stop myapp-service.

share|improve this answer
    
Thanks for the tip. I'll try this later today. If it works, I'll accept your answer, rather than my own above. –  djheru Apr 25 '14 at 15:19
    
Thanks that worked. I think I'm still going to go with the separate script route instead of authorizing multiple commands. –  djheru Apr 25 '14 at 23:08

Ok,I figured it out. I had to create a separate script containing only the commands I wanted to run as root.

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

Then, in my post-receive script do:

#!/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

And finally in my visudo:

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

Hope this helps someone else

share|improve this answer
    
I'm sure I'll find this useful someday –  jbo5112 Apr 25 '14 at 1:53

I have a file in /etc/sudoers.d/root_group that just has the line %root ALL=(ALL) NOPASSWD: ALL, and I add accounts to the group root to allow them to use sudo without a password.

I'm sure there are security implications for file permissions that didn't consider user accounts being in the group "root", but if you're concerned, a different group can be used. Just change the line to %my_new_group ALL=(ALL) NOPASSWD: ALL and add the relevant accounts to my_new_group.

share|improve this answer
    
Thank you, but I'm trying to set it up so the only commands that can be run without a password are the upstart stop and start calls in the script. –  djheru Apr 25 '14 at 1:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.