capistrano
Feature: git:wrapper user when uploading git-ssh.sh
This is related to #154, #191, and probably others.
I'm trying to run all of the commands as a different user than the one I connect with, and it works in general with the following:
SSHKit.config.command_map = Hash.new do |hash, command|
hash[command] = "sudo -u deployuser #{command}"
end
But the git:wrapper task does an upload of git-ssh.sh file, which ends up with my user as the owner, not deployuser. The last line of the task then fails because it tries to run chmod on this file as deployuser.
Is there a way to control the permissions on upload? I'm not too familiar with this part of capistrano and the purpose of the git:wrapper/how it works, so maybe trying to play with the permissions on that file isnt the solution, but any kind of workaround or general guidance would be appreciated.
No sorry if the core things don't work for you, don't load them, and rather load replacement. That is a heavy hammer, so you might look at overwriting the git:wrapper task - http://blog.jayfields.com/2008/02/rake-task-overwriting.html
Follow up question.. I was able to work around the git:wrapper task, but run into some further issues.
The SSHKit.config.command_map as I am using it above gives us access to just the command portion, so just "chmod" or "mkdir". Is there anyway to get/modify the rest of the line?
I run into a problem when it tries to pipe git archive to tar for extracting. The "git" portion is run as deployuser, but the tar is not and hits a permission denied.
sudo -u deployuser git archive master | tar -x -C .....
This actually just the way linux works, and suggested workarounds include running the entire command in a shell as the user you want.
On a related note, is there a reason that the 'default shell' option from version 2 was dropped?
On a related note, is there a reason that the 'default shell' option from version 2 was dropped?
It widens the door to too many operating modes, interactive, non-interactive, tty, no-tty two or more levels deep, it's just unnecessary for the 90th percentile case. That, coupled with too much poorly written and misleading information on the internet about how to "Fix" things that aren't broken with regard to shells/ptys, etc
Indeed however we might consider whether (I'd love a patch) we could use the command map inline, something like:
"sudo -u deployuser git archive master | #{CommandMap.lookup(:tar)} -x -C ..... "
Just incase anyone sees this. I tried this and modified the capistrano git.rb:
"| #{SSHKit::config.command_map[:tar]} -x -f - -C"
Which worked, however I then ran into another issue with the command:
sudo -u deployuser echo "ead0885" >> REVISION
Which looses the sudo as the output is redirected. I can't see a solution to this without modifying the capistrano set_current_revision task.
I apologize, I'm a little behind in responding here. Thanks @threesquared for testing those cases. It seems like in general, using the command map inline works. If I understand correctly, are we proposing an enhancement here to go back and have any existing Capistrano tasks make use of the inline syntax where applicable?
This also does still leave me with my original issue, with the >> REVISION, but this seems like less of a Capistrano issue and more of a UNIX command line issue, which I am by no means an expert of. I'm not entirely sure how one would go about modifying that set_current_revision task to not use >> to redirect output.
@mtamhankar1 if you're still interested in this issue, please report back, otherwise the issue will be closed soon. It's possible to workaround the >> REVISION problem using echo abcdefg | sudo [-u someuser] -a REVISION, this coupled with setting sudo in the CommandMap might work.