Repository: test-kitchen/test-kitchen

Issue #382: Wrap mkdir in sudo() for init_command of chef_base provisioner?
Created: 2014-03-12T03:17:33Z
In this method, rm is wrapped by sudo() but mkdir is not:
def init_command
  dirs = %w{cookbooks data data_bags environments roles clients}.
    map { |dir| File.join(config[:root_path], dir) }.join(" ")
  "#{sudo('rm')} -rf #{dirs} ; mkdir -p #{config[:root_path]}"
end
(See also: https://github.com/test-kitchen/test-kitchen/blob/master/lib/kitchen/provisioner/chef_base.rb#L113)
Setting the provisioner root_path to something like /var/cache/kitchen fails because the directory cannot be created:
mkdir: cannot create directory ‘/var/cache/kitchen’: Permission denied
>>>>>> Converge failed on instance <default-fedora-19>.
>>>>>> Please see .kitchen/logs/default-fedora-19.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: SSH exited (1) for command: [sudo -E rm -rf /var/cache/kitchen/cookbooks /var/cache/kitchen/data /var/cache/kitchen/data_bags /var/cache/kitchen/environments /var/cache/kitchen/roles /var/cache/kitchen/clients ; mkdir -p /var/cache/kitchen]
>>>>>> ----------------------

Duplicate issue #444: shell-provisioner: lots of trouble with a noexec /tmp, failing workaround.
Created: 2014-05-21T06:28:47Z
Hi.
Induced by _pingu's requests in freenode/#kitchenci, I had a look at the shell provisioner when /tmp is mounted noexec.  (Guessing that this is the case with SUSE Enterprise Linux.)
Reproducing the issue with Ubuntu is possible, running
sudo mount -t tmpfs -o noexec tmpfs /tmp
in a Ubuntu VM leads to:
~/tmp$ kitchen converge ubuntu
-----> Starting Kitchen (v1.2.1)
-----> Converging <default-ubuntu-1204>...
       Preparing files for transfer
       Preparing script
       bootstrap.sh not found so Kitchen will run a stubbed script. Is this intended?
       Transfering files to <default-ubuntu-1204>
>>>>>> Converge failed on instance <default-ubuntu-1204>.
>>>>>> Please see .kitchen/logs/default-ubuntu-1204.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: SSH exited (1) for command: [sudo -E /tmp/kitchen/bootstrap.sh]
>>>>>> ----------------------
The obvious change however, changing the root_path of the provisioner:
provisioner:
  name: shell
  root_path: /opt/kitchen

fails, too, because of a bug here, missing " around what sudo is meant to execute:
~/tmp$ kitchen converge ubuntu
-----> Starting Kitchen (v1.2.1)
-----> Converging <default-ubuntu-1204>...
       Preparing files for transfer
       Preparing script
       bootstrap.sh not found so Kitchen will run a stubbed script. Is this intended?
mkdir: cannot create directory `/opt/kitchen': Permission denied
>>>>>> Converge failed on instance <default-ubuntu-1204>.
>>>>>> Please see .kitchen/logs/default-ubuntu-1204.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: SSH exited (1) for command: [sudo -E rm -rf /opt/kitchen/data ; mkdir -p /opt/kitchen]
>>>>>> ----------------------
That said, I wonder how we can remedy the noexec issue properly.  I don't know of any platform-independent way (reading /proc? parsing mount(8)?) to check and warn the user.  A robust approach would be to use the proper interpreter, i.e. run "sudo -E sh /tmp/kitchen/bootstrap.sh", but then this should be a configurable setting, allowing for using Python, Ruby, your-favorite-outlandish-shell...
TL;DR: There's a bug in the shell-provisioners init_command ;)

Closing comment (2014-05-21T06:32:37Z): Just realised the init_command mkdir-in-sudo bug is already reported in #382, so this only adds that the shell-provisioner is also affected.  (Maybe move that, once fixed, to base.rb?)
By the way, a quick and dirty workaround is to pick a root_path that lies in the home of your login user, such as (on ubuntu) /home/ubuntu/kitchen...