I've written a small custom REST service that runs via a python3 wsgi app under gunicorn, and is managed on the system via an upstart init script. (The host is ubuntu 14.04.1). The service is a git post-commit hook, which I'll call
git-hook here for simplicity.
The service is deployed via a jenkins pipeline, and the deploy job does a stop/update/start sequence, as the account
release, to update the files and restart the service.
The problem is that when the jenkins job gets to the step where it runs
sudo service stop git-hook
it appears to fail at that step and the deploy is aborted. This is what the job is supposed to do if a command fails, but it's not 100% visible what exactly the failure was, only that something went wrong while trying to run that step.
Here's what I know:
The service works
- The service itself runs 100% correctly and as expected, provided I execute the init commands interactively with a (non-root) admin account, which has basically full sudo permissions. Specifically, the command is
sudo /usr/sbin/service git-hook start|stop
The service won't start or stop as the
- The 'release' account has been given limited sudo access to run the same start|stop commands for this service, but when I try either one interactively as the
releaseaccount, it always fails with the message
git-hook: unrecognized service
The sudo rule appears to work (at least as far as the 'sudo' functionality is concerned)
- When running the start|stop as any user, the system logs the sudo command, but doesn't give any indication that it has failed (though functionally it always fails for the
- When I instead run a sudo command that
releasedoes not have access for, it does correctly fail to a password prompt, and sudo logs that the command is not allowed.
- The sudoer file is syntactically valid, checked with
- The same sudoer file has other rules for this user, and those work fine, so I at least know it's loading correctly.
Permissions seem correct
- The 'release' account owns all the hook service application files, as it needs full write to deploy new code
www-datauser also has equivalent read/write perms via membership in a common group that owns the application files. This is because the actual wsgi application runs as the
Here is the sudoers rule, implemented as a separate file in
Host_Alias TOOLS = tools??.*.ourdomain.com Cmnd_Alias RELEASE_GITHOOK_SERVICE =\ /usr/sbin/service git-hook stop,\ /usr/sbin/service git-hook start release TOOLS = NOPASSWD:\ RELEASE_GITHOOK_SERVICE
And here is the upstart init file,
/etc/init/git-hook.conf, which has has perms:
-rw-r--r-- and ownership
description "git-hook service" start on (filesystem) stop on runlevel  respawn setuid www-data setgid deploy env APPHOME="/var/www/git_hook" env GUNICORN="/var/www/git_hook/venv/bin/gunicorn" env HOSTNAME="0.0.0.0" env PORT="5000" script chdir $APPHOME exec $GUNICORN --workers 4 --bind $HOSTNAME:$PORT hook:app end script
So the question is, why does the init command work fine under one account and not under the other? It would seem to have some connection to the more restrictive sudo rules, however it appears the sudo call actually is successful, so maybe something it calls is what fails. Is there some other, implied command that
/usr/sbin/service runs that I also need a rule for? Or some other access permission I'm missing?