Chef::Provider::Git with user attribute queries /root/.conf/git/config

I traced it down. As soon as ENV['HOME'] = '/home/user' is set in mixlib-shellout, the error disappears. At the moment no such environment variable is set and it seems that the git application in Fedora 18 can't handle it and looks in the /root path.

The question is now how to fix this. It would be possible to check in mixin/shell_out.rb (pseudocode):

if userattribute set
  if not HOME env set
     get HOME env from system and add it to the command_args
  fi
end

Else this could just be handled for the git resource in resource/scm.rb in a similar way.

It's unclear to me how to handle it for non-Unix systems.

I tried to fix it here:

https://github.com/smaftoul/chef/commit/02216b301f0826dc2bbb6844656085abf2df5fa7

No idea if we can have a workaround with modifying the application cookbook or passing correctly environments in the git resource (I'm using it through the application resource).

My fix uses node[:etc][:passwd][@new_resource.user] , if this user is created during the chef run, the attribute won't be available, you need to reload ohai. This is I think another bug in the chef user provider.

A branch url is easier than a commit url:
https://github.com/smaftoul/chef/commits/patch-1

Samuel Maftoul points out in a commit message that git v1.8.0 appears to raise a new error if there is a ~/.gitconfig file that it cannot read. Did anything else change on your system other than upgrading to Chef 11 Volker, e.g. did you upgrade your entire system or just Chef 11?

It seems that relying on node[:etc] is going to find at least a few edge cases where people don't have that populated for one reason or another. Perhaps they want the users .gitconfig loaded, perhaps they don't care, but it would work for them if we weren't fooling around looking for data that isn't there on them.

File.expand_path seems a bit more reliable, but doesn't appear to work for windows:

$ ruby -v
ruby 1.8.7 (2012-02-08 patchlevel 358) [x86_64-linux]
$ irb
irb(main):001:0> File.expand_path("~btm/")
=> "/home/btm"

C:\Users\btm>whoami
win-vq19br1ifrd\btm

C:\Users\btm>irb
irb(main):001:0> File.expand_path("~btm")
ArgumentError: can't find user btm
        from (irb):1:in `expand_path'
        from (irb):1
        from C:/opscode/chef/embedded/bin/irb:12:in `<main>'

So we need to find a cross-platform way, or at least an additional windows friendly way, to get that information.

IMHO, the real problem here is that HOME is set to root's HOME while we specify a user.
We can reproduce a somewhat similar situation outside of chef in pure git:

$ HOME="/root" git clone git@github.com:opscode/chef
Cloning into 'chef'...
fatal: unable to access '/root/.config/git/config': Permission denied
$ HOME="" git clone git@github.com:opscode/chef
Cloning into 'chef'...
The authenticity of host 'github.com (204.232.175.90)' can't be established.
...

Bryan McLellan [Chef] you say 'if there is a ~/.gitconfig file that it cannot read', to be precise, if it's in an unreadable directory, the same message is here, even if the file doesn't exist.

Would the proper solution be unsetting HOME or setting it to an empty value ?

Experiencing the same issue, unsetting HOME works properly, Ubuntu 13.04, does not do this on my fresh 12.10 install.

Seeing the same error with Ubuntu 11.10 - chef-client 10.18 - git version 1.8.2.2

I have this issue on Ubuntu 13.04 with chef-client 11.4.4

I encountered it trying the community rbenv cookbook, which tries to git clone as the rbenv user.

* git[/opt/rbenv] action sync[2013-06-01T13:25:28+01:00] INFO: Processing git[/opt/rbenv] action sync (rbenv::default line 44)
[2013-06-01T13:25:28+01:00] DEBUG: git[/opt/rbenv] finding current git revision
[2013-06-01T13:25:28+01:00] DEBUG: git[/opt/rbenv] resolving remote reference

================================================================================
Error executing action `sync` on resource 'git[/opt/rbenv]'
================================================================================


Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '128'
---- Begin output of git ls-remote git://github.com/sstephenson/rbenv.git master ----
STDOUT:
STDERR: fatal: unable to access '/root/.config/git/config': Permission denied
---- End output of git ls-remote git://github.com/sstephenson/rbenv.git master ----
Ran git ls-remote git://github.com/sstephenson/rbenv.git master returned 128


Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/rbenv/recipes/default.rb

 44: git node[:rbenv][:root] do
 45:   repository node[:rbenv][:git_repository]
 46:   reference node[:rbenv][:git_revision]
 47:   user "rbenv"
 48:   group "rbenv"
 49:   action :sync
 50:
 51:   notifies :create, "template[/etc/profile.d/rbenv.sh]", :immediately
 52: end
 53:



Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/rbenv/recipes/default.rb:44:in `from_file'

git("/opt/rbenv") do
  provider Chef::Provider::Git
  action [:sync]
  retries 0
  retry_delay 2
  destination "/opt/rbenv"
  revision "master"
  remote "origin"
  cookbook_name "rbenv"
  recipe_name "default"
  repository "git://github.com/sstephenson/rbenv.git"
  user "rbenv"
  group "rbenv"
end



[2013-06-01T13:25:28+01:00] INFO: Running queued delayed notifications before re-raising exception
[2013-06-01T13:25:28+01:00] DEBUG: Re-raising exception: Mixlib::ShellOut::ShellCommandFailed - git[/opt/rbenv] (rbenv::default line 44) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '128'
---- Begin output of git ls-remote git://github.com/sstephenson/rbenv.git master ----
STDOUT:
STDERR: fatal: unable to access '/root/.config/git/config': Permission denied

This is biting me too, and hacking to set HOME hasn't helped for me.

It looks like git 1.8.4 will loosen the dependence on a readable HOME, though. https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.4.txt#L104-L106

For what it's worth, I tried building git from source (@b5c26758) and the error is now a warning.

I solved this by doing something gross before any git calls:

directory '/root' do
  mode 0755
end

Although I dislike this solution, my servers never have anything in the /root dir nor do I ever use the root user.

This is still a bug, but at least this is a workaround.

this is ridiculous ... opscode already forces users to make their /root 0755 ... dear god. please fix this trivial issue!

Same issue here. Ubuntu 13.04 and chef 11.4.4

I have the same problem with Chef 11.4.4 and Gentoo... I wonder if there is at least some kind of workaround...

https://github.com/zentoo/mixlib-shellout/commit/5a4cc1122f551f3aa186369fa79cd1ea2573816a

Samuel Maftoul, HOME is not set to root's HOME by Chef, it is not set at all. shell_out does not start a login shell (CHEF-2288), it just runs a command.

This bug is in git, not Chef, but we may have to deal with git's bug. Other tools have run into the same issue, like Redmine.

4698c8feb in git resolves this bug and explains the situation well. Similarly, shell_out shouldn't make assumptions about what you might want your variables to be set to and cannot set those variables in such a way you can't change them. Git tag reports that commit was included in Git 1.8.3.1. The bug was introduced in 96b9e0e31 and released first in Git 1.8.1.1. I would suspect some distributions aren't going to get an update.

The solution presented to use Etc won't work. As previously noted, it isn't portable, and I wonder if there are cases where it would report something that we don't want, and then need a way to override it. Ignoring that case, I imagine the solution would be to implement a feature in mixlib-shellout to provide a login shell, and then have the git resource use that option when --user is set.

Benedikt Böhm I'm not completely convinced we want to set environment variables by default anytime a user is passed, but I guess it's okay. 5a4cc1122f should not set HOME or USER if they've been passed to the environment hash. user can be a name or a uid, so that should be handled. Since uid is right there, it's probably easiest to call getpwuid against the uid rather than add logic to determine if user is a name or uid. Finally, there should be unit tests.

I had this error again while provisioning a ubuntu 13.04 VM:
---- Begin output of git ls-remote git://github.com/sstephenson/rbenv.git v0.4.0 ----
STDOUT:
STDERR: fatal: unable to access '/root/.config/git/config': Permission denied
---- End output of git ls-remote git://github.com/sstephenson/rbenv.git v0.4.0 ----
Ran git ls-remote git://github.com/sstephenson/rbenv.git v0.4.0 returned 128

I did install the patched mix-shellout from zentoo mentioned by Bryn. Afterwards everything worked as expected. The error was gone.

I hope this gets resolved soon.

Bryan McLellan [Chef] I know that this i not a proper fix for the problem. it just mitigates it until mixlib-shellout has proper login shell handling ... it would be really nice to implement that. until then people may use the workaround if they want to.

Bryan McLellan [Chef] you say that HOME isn't set all.
I don't know what happens, but as you see in comment-34804, having no HOME set works, having an unreadable HOME set breaks git for those versions.
Maybe I come up with HOME set, because I launch chef from within a shell where HOME is set, than, the (deploy|git|application) resource sets its user, but HOME remains here.
Do you confirm, the fact that in my case the HOME is set is due to the fact I'm launching chef from an interactive shell where HOME is set ?

I'm wrong. According to Daniel DeLeo, shellout inherits environment variables from the parent shell. So whatever HOME is set to when chef-client is run, should also be set when shellout runs something.

irb(main):001:0> require 'rubygems'
=> true
irb(main):004:0> require 'mixlib/shellout'
=> true
irb(main):017:0> foo = Mixlib::ShellOut.new("echo $HOME")
=> <Mixlib::ShellOut#69905889980380: command: 'echo $HOME' process_status: nil stdout: '' stderr: '' child_pid: nil environment: {"LC_ALL"=>"C"} timeout: 600 user:  group:  working_dir:  >
irb(main):018:0> foo.run_command
=> <Mixlib::ShellOut#69905889980380: command: 'echo $HOME' process_status: #<Process::Status: pid=27869,exited(0)> stdout: '/home/btm' stderr: '' child_pid: 27869 environment: {"LC_ALL"=>"C"} timeout: 600 user:  group:  working_dir:  >
irb(main):019:0> foo.stdout
=> "/home/btm\n"

My above comments to Benedikt Böhm regarding 5a4cc1122f are probably the path forward for us.

Just hit this brick wall as well. None of these work-arounds seem feasible for production. Can we please get something like 5a4cc1122f in so this ugly problem goes away?

Here is one workaround that doesn't require opening up the root dir and works for chef-solo:

class Chef::Provider::MyGit < Chef::Provider::Git
  alias :run_options_old :run_options
  def run_options(run_opts={})
    ret = run_options_old(run_opts)
    ret[:environment] = {} unless ret[:environment]
    ret[:environment]['HOME'] = '/home/foo'
    ret
  end
end

git 'foo' do
  # ...
  provider Chef::Provider::MyGit
end

my workaround

1. install apt cookbook
2. add the following:

apt_repository "git-core" do
  uri "http://ppa.launchpad.net/git-core/ppa/ubuntu"
  distribution node['lsb']['codename']
  components ["main"]
  keyserver "keyserver.ubuntu.com"
  key "E1DF1F24"
end
package 'git'

Got bit by this HOME environment variable bug in many recipes in sprout using vagrant + chef-solo. I feel like this is a larger issue and probably should be fixed in mixlib-shellout.

I can confirm the workaround with custom git provider works for me. I can add my perspective as a new user and as mentioned by James Cuzella, whenever I use user "bla", I assumed that I will get the user's PATH, HOME, etc., instead oftentimes I end up setting those manually, e.g. on a bash script:

environment("HOME" => user_home)

and then in the actual script I manually set the path to something that already is on the user's path.

I also often set the value of HOME when I specify a user or owner on a resource.
I also feel that if we specify a user, there is no reason we inherit a HOME value for the login shell we ran chef-client from. There is also some good reasons to set the value to the correct one depending on the user running the command, lot of programs are failing with home not set correctly.

Fix available here: https://github.com/opscode/chef/pull/1108

Fix seems appropriate. We would like to know what the use case is for falling back to /home/user if Etc.getpwnam fails, if there is one.

We'll pull out the rescue after merge.

I used this as a workaround.

old_home = ENV['HOME']

ruby_block "clear_home for CHEF-3940" do
  block do
    ENV['HOME'] = Etc.getpwnam("USERNAMEYOUWANT").dir
  end
  not_if {`git --version`.split[2].to_f <= 1.7}
end

git "/src/somerepo" do
  repo "git://github.com/YOU/REPO.git"
  revision "master"
  user "USERYOUWANT"
  group "GROUPYOUWANT"
end

ruby_block "reset_home" do
  block do
    ENV['HOME'] = old_home
  end
  not_if {`git --version`.split[2].to_f <= 1.7}
  subscribes :create, "git[/src/somerepo]", :immediately
end

I can confirm this bug on Ubuntu 13.04 and 13.10. The workaround from Joshua works, but it still really annoying.

Merged with PR #1149 to contributions.

I saw the issue with RHEL 5.9, and just wanted to confirm that JTimberman's workaround worked for me.