0

on a fresh debian 9.2 install with isp3config this is something that works on my fresh debian 8 VM's without problems

after my first sudoers command in my git post-receive script

GIT post-receive
/bin/systemctl stop test.service

all following sudo cmds do this:

GIT post-receive
/bin/systemctl start test.service
remote: sudo: no tty present and no askpass program specified

my relevant config files:

sudoers.d/testsudos
git ALL = NOPASSWD: /bin/systemctl stop test.service, /bin/systemctl start test.service
git ALL = NOPASSWD: /bin/systemctl status -l test.service


/var/log/auth.log
Nov 30 00:03:20 server systemd-logind[491]: New session 6291 of user git.
Nov 30 00:03:20 server systemd: pam_unix(systemd-user:session): session      opened for user git by (uid=0)
Nov 30 00:03:21 server sudo:      git : TTY=unknown ; PWD=/home/git/test.git ; USER=root ; COMMAND=/bin/systemctl st$
Nov 30 00:03:21 server sudo: pam_unix(sudo:session): session opened for   user root by (uid=0)
Nov 30 00:03:21 server sudo: pam_unix(sudo:session): session closed for user root
Nov 30 00:03:38 server sudo:      git : TTY=unknown ; PWD=/home/git/test.git/test ; USER=root ; COMMAND=/bin/systemc$
Nov 30 00:03:38 server sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 30 00:03:38 server sudo: pam_unix(sudo:session): session closed for user root
Nov 30 00:03:38 server sudo: pam_unix(sudo:auth): conversation failed
Nov 30 00:03:38 server sudo: pam_unix(sudo:auth): auth could not identify password for [git]
Nov 30 00:03:38 server sudo:      git : command not allowed ; TTY=unknown ; PWD=/home/git/test.git/test ; USER=root $
Nov 30 00:03:38 server sudo: pam_unix(sudo:auth): conversation failed
Nov 30 00:03:38 server sudo: pam_unix(sudo:auth): auth could not identify password for [git]
Nov 30 00:03:38 server sudo:      git : command not allowed ; TTY=unknown ; PWD=/home/git/test.git/test ; USER=root $
Nov 30 00:03:43 server sudo: pam_unix(sudo:auth): conversation failed
Georg T
  • 1
  • 2
  • I'd say the problem is that the command `/bin/systemctl start test.service` does not match any entry in the sudo config for the `git` user which would have `NOPASSWD` modifier specified. The behaviour of `sudo` is implemented in such a way that it would ask for the password even if it actually *knows* there's no valid command it could have executed (supposedly that's a measure against figuring out the list of supported commands via brute-forcing). And to ask for a password, `sudo` needs a real terminal to interact with the user. – kostix Nov 30 '17 at 07:13
  • By the way, I'd say questions of this kind are better suited for https://superuser.com or https://serverfault.com as they are not too much about Git usage but are rather about configuring servers. – kostix Nov 30 '17 at 07:20

1 Answers1

0

At least i got my service to restart again...

So it turns out:

1 sudoers line for those commands is needed

It stops working after the 1st illegal command

my systemctl status still does not work with a "no tty present"

how do i get the information back to my git_bash?

Georg T
  • 1
  • 2
  • Oh, I see you've figured this out yourself ;-) Well, it supposedly *should* work—in the `githooks(7)` (run `git help hooks`) manual we see this passage in the description of the `post-receive` entry: "Both standard output and standard error output are forwarded to git send-pack on the other end, so you can simply echo messages for the user."; so whatever was output to either of the standard output streams of the hook script should have been forwarded to the Git process handling your `git push`. – kostix Nov 30 '17 at 07:16
  • Wasn't you redirecting the output of `sudo` calls in your hook script by any chance? If yes, try using `tee` to both save the output and let it be handled by Git at the same time (you can start with [this](https://stackoverflow.com/a/692407/720999)). – kostix Nov 30 '17 at 07:18