1.0 now failing because of .composer config in the wrong spot

[neerolyte]

This only seems to happen with one VM I use, but it only started with a recent upgrade of the cachier plugin.

The output is:

==> centos5: Configuring cache buckets...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mkdir -p `dirname /.composer/cache`

Stdout from the command:

Stderr from the command:

mkdir: cannot create directory `/.composer': Permission denied

Can be induced with this Vagrantfile:

Vagrant.configure(2) do |config|
  config.vm.box = "centos5-matrix-64-lyte"
  config.vm.box_url = "http://lyte.id.au/vagrant/centos5-matrix-64-lyte.box"
end

[fgrehm]

You might have upgraded from a pre 0.8.0 version when we changed the composer bucket to use $HOME/.composer/cache because of GH-89

Please shutdown the VM, remove the cache directory on your host and try again to check if it works. If it doesn't please LMK!

[neerolyte]

You're at least partially right, I upgraded one that was doing it from 0.7.2 and if I do a fresh install on a spare machine the same VM does boot with cachier 1.0.0.

However on the first machine I spotted this on upgrading to 1.0.0 again, removing the cache dir (rm -rf ~/.vagrant.d/cache), doing a destroy (vagrant destroy -f) and a then an up again still resulted in the same error.

I've even removed everything from ~/.vagrant.d, restored just ~/.vagrant.d/Vagrantfile (I don't think anything in it is problematic, but thought I'd include "just in case"):

Vagrant::configure('2') do |config|
        if Vagrant.has_plugin?("vagrant-proxyconf")
                config.proxy.http     = "http://10.0.2.2:8123/"
                config.proxy.https    = "http://10.0.2.2:8123/"
                config.proxy.no_proxy = "localhost,127.0.0.1"
        end

        if Vagrant.has_plugin?("vagrant-cachier")
                # Configure cached packages to be shared between instances of the same base box.
                config.cache.scope = :box
        end

        if Vagrant.has_plugin?('vagrant-vbguest')
                # set auto_update to false, if you do NOT want to check the correct 
                # additions version when booting this machine
                # projects can override this themselves
                config.vbguest.auto_update = false
        end
end

and reinstalled the 3 plugins we're using (cachier, vbguest and proxyconf) and still get the same error.

Any other ideas where this might be getting caught up?

[fgrehm]

Not sure if you tried but you might want to uninstall other plugins apart from vagrant-cachier to ensure it is not some weird conflict.

If that still doesn't work, could you please gist the output of running vagrant up --debug from scratch so we can try understanding what's going on? Thanks in advance

[neerolyte]

Ok so I managed to induce it on the fresh install machine (only has cachier 1.0.0 and the two defaults, login 1.0.1 and share 1.1.1) just by adding the config.cache.scope = :box section - so turns out it's not actually a conflict with another plugin, but actually something to do with the scope.

The gist from vagrant up --debug is up at https://gist.github.com/anonymous/62ee5ad90c0c6dd476aa

I can't yet tell where it's going wrong from that (it looks like it's calling the same mkdir a number of times?).

[neerolyte]

As a side issue: I noticed in some of the doco you can enable specific caches with something like config.cache.enable :composer - would it be reasonable to have something similar to blacklist ones we don't want running (e.g config.cache.disable :composer)?

AFAICT at the moment it's only possible to turn the whole cache off (config.cache.disable!).

[fgrehm]

Weird, it works fine for me using the lxc provider and the following vagrantfile

Vagrant.configure("2") do |config|
  config.vm.box = "fgrehm/trusty64-lxc"
  config.vm.provision :shell, inline: 'apt-get update && apt-get install php5 -y'
end

Maybe you've got some provisioning code that is somehow messing things up? I can't test with the VBox provider right now but if you can reproduce the issue with an equivalent Vagrantfile I can try to do some more digging.

Regarding the disable config, there's an issue for that (GH-115) but it is something I personally don't have a need at the moment, so if you are able to put up a PR I'd be more than happy to have a look into it :-)

[neerolyte]

The Vagrantfile that produces it is still just:

Vagrant.configure(2) do |config|
  config.vm.box = "centos5-matrix-64-lyte"
  config.vm.box_url = "http://lyte.id.au/vagrant/centos5-matrix-64-lyte.box"
end

so no provisioning code to speak of.

It only happens with the centos5 VM, not any SL6 or debian ones we use - I'm hesitant to try rebuilding the CentOS one to resolve it (not sure if it'd even help as I still don't know what specifically is tripping it up) however as it's just getting used for a couple of projects that have to support legacy installs and I'm hoping I can simply stop using it soonish.

I'll try having a look at GH-115 as that'd be good enough for my use case.

[fgrehm]

Ok, so I built a CentOS vagrant-lxc base box just to give it a try and I didn't experience that behavior =/ I'll try your box when I have a chance.

[neerolyte]

Hmm, always seem to get PRs wrong - either way #124 resolves the issue I was hitting. Basically the difference in that area seems to be on a working VM I get something like /home/vagrant\n, but on the centos5 VM (whether it's a CentOS 5 specific issue or just my dodgy VM :) ) I get two runs through the buffer loop with the first one containing /home/vagrant\n and the second just containing \n.

Not sure concatenating it all is the perfect solution, but it seemed more reasonable than assuming the first pass or second pass would always contain the desired output.

[fgrehm]

Thanks for the PR, I'll try to get it in over the week :-)