Test for ownership (`with`) fails incorrectly on lucid32 Vagrant box

[karmi]

On the lucid32 Vagrant box, the tests for the cookbook-elasticsearch are failing with:

test_0002_installs_elasticsearch_jar(recipe::elasticsearch::default::Installation) [/opt/vagrant_ruby/lib/ruby/gems/1.8/gems/minitest-chef-handler-0.6.0/lib/minitest-chef-handler/resources.rb:33]:
The file does not have the expected owner.
Expected: "elasticsearch"
  Actual: nil

However, when SSH-ing to the box, the file in question has correct user:

$ vagrant ssh lucid32

vagrant@lucid32:~$ ls -la /usr/local/elasticsearch-0.18.5/lib/elasticsearch-0.18.5.jar 
-rwxr-xr-x 1 elasticsearch elasticsearch 12193850 2011-11-29 11:01 /usr/local/elasticsearch-0.18.5/lib/elasticsearch-0.18.5.jar

The tests in question is here: https://github.com/karmi/cookbook-elasticsearch/blob/master/files/default/tests/minitest/installation_test.rb#L17-23

Reported first as karmi/cookbook-elasticsearch#22 and confirmed by @karmi.

Environment info:

Guest Additions Version: 4.1.16
VirtualBox Version: 4.1.18
Chef 0.10.10

[calavera]

Hi @karmi, thanks for reporting this.

I see that you're using Chef 0.10.10. Other user already reported a similar behavior where Chef set the file's owner to nil in that version, which made me change the resources logic a little bit. You can check the thread in #23.

Could you do me a favor and verify that the issue is not in Chef using a test case like the one that I suggest there?

https://github.com/calavera/minitest-chef-handler/issues/23#issuecomment-6536543

[nrw]

@calavera (I'm a user that reported this bug to karmi). Switching to chef 0.10.8 did result in tests passing.

[karmi]

Hi! Confirmed the file owner is returned as nil... I too was bitten by Chef 0.10.10, currently trying to run the provisioning on Chef 10.12 (as suggested in http://stackoverflow.com/questions/11325479/how-to-control-the-version-of-chef-that-vagrant-uses-to-provision-vms/11485516#11485516), but so far no luck.

[calavera]

cool, I'm closing this ticket then. I was wondering if I should add a warning or something similar when this happen, even though it's not an issue here.

[karmi]

@calavera It's clearly an underlying system fault, not passing the owner properly -- maybe print a warning when Chef 10.10 is detected :)

[karmi]

Just a note, tried it with the precise64 box, which has Chef 0.10.10 as well, and the whole run fails with another link related error...

DEBUG: NoMethodError: ruby_block[update-java-alternatives] (java::openjdk line 43) had an error: NoMethodError: undefined method `to_str' for nil:NilClass
/opt/vagrant_ruby/lib/ruby/1.8/fileutils.rb:1414:in `fu_each_src_dest0'
/opt/vagrant_ruby/lib/ruby/1.8/fileutils.rb:336:in `ln_s'
/opt/vagrant_ruby/lib/ruby/1.8/fileutils.rb:359:in `ln_sf'