tmatilai / vagrant-proxyconf

Vagrant plugin that configures the virtual machine to use proxies
MIT License
531 stars 74 forks source link

Provisioning of docker fails #180

Closed jub77 closed 5 years ago

jub77 commented 5 years ago

Provisioning of docker fails:

System: Win7 Virtualbox: 6.0 Vagrant: 2.2.2

boxes: centos/7, ubuntu/bionic64

When the unlink is commented out, the provisioning is done correctly.

==> default: Configuring proxy for Docker...
C:/Users/-----/.vagrant.d/gems/2.4.4/gems/vagrant-proxyconf-2.0.0/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:93:in `unlink': Permission denied @ unlink_internal - /tmp/vagrant-proxyconf-docker-config.json (Errno::EACCES)
        from C:/Users/-----/.vagrant.d/gems/2.4.4/gems/vagrant-proxyconf-2.0.0/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:93:in `update_docker_client_config'
        from C:/Users/-----/.vagrant.d/gems/2.4.4/gems/vagrant-proxyconf-2.0.0/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:22:in `configure_machine'
        from C:/Users/-----/.vagrant.d/gems/2.4.4/gems/vagrant-proxyconf-2.0.0/lib/vagrant-proxyconf/action/base.rb:28:in `call'
        from D:/programs/Vagrant/embedded/gems/2.2.2/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Users/-----/.vagrant.d/gems/2.4.4/gems/vagrant-proxyconf-2.0.0/lib/vagrant-proxyconf/action/base.rb:31:in `call'
        from D:/programs/Vagrant/embedded/gems/2.2.2/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:34:in `call'
        from C:/Users/-----/.vagrant.d/gems/2.4.4/gems/vagrant-proxyconf-2.0.0/lib/vagrant-proxyconf/action/base.rb:31:in `call'
        from D:/programs/Vagrant/embedded/gems/2.2.2/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:34:in `call'
        from D:/programs/Vagrant/embedded/gems/2.2.2/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
        from D:/programs/Vagrant/embedded/gems/2.2.2/gems/vagrant-2.2.2/lib/vagrant/action/warden.rb:34:in `call'
        from D:/programs/Vagrant/embedded/gems/2.2.2/gems/vagrant-2.2.2/lib/vagrant/action/builder.rb:116:in `call'
        from D:/programs/Vagrant/embedded/gems/2.2.2/gems/vagrant-2.2.2/lib/vagrant/action/runner.rb:66:in `block in run'
tmatilai commented 5 years ago

Hi! Could you please check what are the file permissions of that /tmp/vagrant-proxyconf-docker-config.json file?

tmatilai commented 5 years ago

That said. The temporary file should really be made using Tempfile. Pull requests welcome. =)

brunowego commented 5 years ago

@jub77 I am running a shell script following this configurations:

export http_proxy=http://your-proxy https_proxy=http://your-proxy no_proxy=localhost,127.0.0.1
sudo mkdir -p /etc/sysconfig
cat /etc/sysconfig/docker
sudo tee -a /etc/sysconfig/docker << EOF
HTTP_PROXY=$http_proxy
HTTPS_PROXY=$https_proxy
NO_PROXY=$no_proxy
http_proxy=$http_proxy
https_proxy=$https_proxy
no_proxy=$no_proxy
EOF
sudo mkdir -p /etc/systemd/system/docker.service.d
cat /etc/systemd/system/docker.service.d/http-proxy.conf
sudo sh -c 'echo -e "[Service]\nEnvironmentFile=-/etc/sysconfig/docker" >> /etc/systemd/system/docker.service.d/http-proxy.conf'
sudo systemctl daemon-reload
sudo systemctl show --property EnvironmentFiles docker
sudo systemctl restart docker
jub77 commented 5 years ago

I did check the permissions (at first I had to find the temp directory which is suprisingly d:/tmp, how the vagrant came up with this one is a mystery for me) and that seems not to be the problem. It seems that the upload comm.upload(@docker_client_config_path, @docker_client_config_path) somehow locks that file and prevents the deletion.

codylane commented 5 years ago

Hmmm, that is odd behavior and I appreciate you taking the time to report the issue. I thought I had spent a lot of time testing out the docker integrations but I must have missed a few small edge cases.

What version of docker are you using? I'm wondering if the edge case is happening because I don't have a windows box to run tests on and I wonder if windows is perhaps munging the permissions on the before the upload happens. I'll try and spend some time in the next few days to determine what the root cause is.

In the meantime, can you please provide the Vagrantfile and any provisioning scripts that you are using?

I'd like to make sure I can reproduce this issue locally.

jub77 commented 5 years ago

Installed docker version is 18.09.1, but it's not relevant in my opinion. The problem is probably in vagrant upload implementation for windows. The vagrant file is simple:

Vagrant.configure("2") do |config|
  config.vm.box = "centos/7"
  config.vm.provision "docker"
  config.proxy.http     = "http://10.0.2.2:3128"
  config.proxy.https    = "http://10.0.2.2:3128"
  config.proxy.no_proxy = "localhost,127.0.0.1"
end

And then vagrant up and vagrant provision.

I did try to add code to the part of the plugin which deals with docker to upload and delete of a file which I have prepared beforehand in the directory with vagrant file.

@machine.communicate.tap do |comm|
  comm.upload("test.txt", "/tmp/test.txt")
...

File.delete("test.txt") if File.exists?("test.txt")

And I have received the same error:

/.vagrant.d/gems/2.4.4/gems/vagrant-proxyconf-2.0.0/lib/vagrant-proxyconf/action/configure_docker_proxy.rb:96:in `delete': Permission denied @ unlink_internal - test.txt (Errno::EACCES)

When the upload of test file is removed, then the delete is performed without a problem.

codylane commented 5 years ago

Thank you for the detailed info, i'm going to see if I can reproduce this and or come up with a clever way to fix this today. Please bare with me and I would love to have you test this before I close out this issue.

Thanks again for reporting and providing a clear explanation of the problem you are seeing.

codylane commented 5 years ago

Installed docker version is 18.09.1, but it's not relevant in my opinion. The problem is probably in vagrant upload implementation for windows. The vagrant file is simple:

Vagrant.configure("2") do |config|
  config.vm.box = "centos/7"
  config.vm.provision "docker"
  config.proxy.http     = "http://10.0.2.2:3128"
  config.proxy.https    = "http://10.0.2.2:3128"
  config.proxy.no_proxy = "localhost,127.0.0.1"
end

I'm having a hard time trying to grasp your Vagrantfile that you posted above. You've got a typo in the line config.vm.provision "docker" which doesn't do anything. Next, you are using config.vm.box = "centos/7" which doesn't make sense how you are using docker. If you want to use the docker provider you need to use the correct docker provider syntax.

https://www.vagrantup.com/docs/docker/basics.html

jub77 commented 5 years ago

The config.vm.docker "docker" without the code block installs the docker to the vm without any additional action to be done. The only downside for the setup is that there has to be run vagrant provision after vagrant up because the installation of docker is done after the proxy configured - therefore the second provisioning.

codylane commented 5 years ago

I'm making a guess here because I am not sure how you have docker installed on your windows machine but I assume you are using 'docker-toolbox' intead of 'docker-desktop'? The reason I ask is there are pitfalls for using one or the other and some of which cannot be controlled by this plugin. I would assume since windows has a different permissions scheme, it is contributing to the behavior you are seeing since you are trying to use a linux based container. I would assume running a Linux docker container from a windows machine would cause permissions issues because a container shares the host settings and is not truly a linux environment.

I don't have a way to easily confirm this however. I also have no easy way to test this plugin on a windows based host. If you have time and want to contribute to this plugin, we will accept pull requests.

That said, I contributed a new integration #182 to use the Tempfile approach instead of hard coding paths. It's not released yet because I'd like to have @tmatilai do a code review when he has time.

codylane commented 5 years ago

2.0.1 has been released. Please re-open if this is still an issue.