payload extraction can nuke /tmp permissions

[bmoyles]

Not sure if you want to consider this a bug or if it's simply worth calling out in documentation, but if the payload tarball is created as a non-root user using something like "tar -C build/ -czf payload.tgz ." the resultant tarball will have a ./ entry with the same permissions as that local build/ directory. When the provisioning plugin extracts the payload with "tar -C /tmp -xf payload.tgz", /tmp's permissions get nuked. I put some guards in our cookbooks to deal with that there, but you may want to either call that out in docs or have tar ignore permissions when extracting so everything ends up owned by root...

[kvick]

It might be worth considering making the payload dir configurable (e.g. /opt/chef/cookbooks) I prefer that the cookbooks live somewhere less volatile than /tmp (it may be useful to have the cookbooks for a future run or analysis). I currently have a jenkins job that produces a deb from the berkshelf package output that sticks all them under /var/chef/cookbooks, solo.rb, node-base.json and a python script that fires the chef run/install.

[bmoyles]

That seems reasonable. I actually like the cookbooks in /tmp myself as I like that they're gone on next boot (I'm only using aminator for our base images right now, and I don't necessarily want those cookbooks lingering) but something configurable is not a bad option. Permissions probably still need to be dealt with to be safe (today was a fun firedrill day :))

[bunjiboys]

I think it makes a lot of sense having a command line argument that you can use to specify output folder. Thats also a very easy fix for this. We should however also make sure that gets documented, so people are aware when they build their payloads, to either handle it after the fact, or create the payload without the . folder