8000 VBox guest additions by steeve · Pull Request #284 · boot2docker/boot2docker · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Jan 1, 2021. It is now read-only.

VBox guest additions #284

Closed
wants to merge 1 commit into from
Closed

VBox guest additions #284

wants to merge 1 commit into from

Conversation

steeve
Copy link
Contributor
@steeve steeve commented Mar 14, 2014

This is a PR in response to #282.
It adds ~400kb to the unpacked system.
Please discuss wether vboxsf are a good option of not in #282, not here.

Add a shared folder to the VM:

$ boot2docker stop
$ VBoxManage sharedfolder add boot2docker-vm -name home -hostpath $HOME

Now mount the folder inside the VM:

$ boot2docker up
$ boot2docker ssh "sudo modprobe vboxsf && mkdir -p $HOME && sudo mount -t vboxsf home $HOME"

You can now run docker -v transparently as long as the volume is inside $HOME.

A test ISO based on 0.7 is at https://dl.dropboxusercontent.com/u/12014139/boot2docker.iso

@shlomifruchter
Copy link

Is there a workaround for now? How can I manually install the vbox guest additions on the boot2docker image?

@steeve
Copy link
Contributor Author
steeve commented Mar 17, 2014

The best and easiest way is to build the image yourself from the Dockerfile

This was referenced Mar 17, 2014
Closed
Closed
@aheissenberger
Copy link
Contributor

👍 @steeve you are a hero!

now it will be very easy to access e.g. IP of VM and other stuff thru the GuestProperty API

On the Host the properties are accessed through VBoxManage command with the following qualifiers:
guestproperty get <vmname>|<uuid> <property> [-verbose]
guestproperty set <vmname>|<uuid> <property> [<value> [-flags <flags>]] 
guestproperty enumerate <vmname>|<uuid> [-patterns <patterns>]

and on the Guest with the corresponding VBoxControl commands

guestproperty get <property> [-verbose]
guestproperty set <property> [<value> [-flags <flags>]] 
guestproperty enumerate [-patterns <patterns>]

This was referenced Mar 26, 2014
Closed
Closed
cameronmaske added a commit to cameronmaske/docker-osx that referenced this pull request Mar 26, 2014
@cameronmaske
Replace Ubuntu VM with boot2docker.
a8db1e9 
Setup HOME directory mounting using this [workaround](boot2docker/boot2docker#284).
Uses an forked boot2docker shell script (based on boot2docker/boot2docker#93) but fast forward to the latest master to allow a fixed ip address for guest and host (aka localdocker).
Removed Vagrant, VM is managed by VirtualBox alone.
@cameronmaske cameronmaske mentioned this pull request Mar 26, 2014
Open
@aanand aanand mentioned this pull request Mar 27, 2014
Closed
@lightsofapollo
Copy link

For me this is the only thing that makes me keep around my custom docker environment (vagrant basically) -v is required for happy docker usage :)

@steeve
Copy link
Contributor Author
steeve commented Mar 28, 2014

Can we merge this already guys ?

@nsfmc
Copy link
nsfmc commented Mar 29, 2014

sorry if this is super reductive, but i was playing around with this and noticed that the hardcoded guest-additions are likely to be incompatible with most folks' virtualbox installs. does it make sense to

but they both add a time-overhead over just downloading a 'working' boot2docker image, but it seems like there would almost certainly be compatibility issues between guest-addition versions (which seem to change every week or so).

also i could be totally missing something. let me know if i'm approaching this in a naive way, i'm mostly trying to simplify an install of docker among a group of computers in a super heterogenous environment and this point jumped out at me. thanks for any feedback.

@steeve
Copy link
Contributor Author
steeve commented Mar 30, 2014

Well, boot2docker has an amazing feature, which makes most of your concerns go away imho: the OS is read only.
That means that when you need to update, your restart the OS with a new version of it.

Obviously the guest additions evolve rapidly, but VBox versions don't get released that often. And when they do we take a good look at them.
Thankfully VBox guest additions are backward compatible, so we don't screw existing installs.

The thing is, boot2docker strives to Just WorkTM, and to provide the best experience for folks without doing anything (it's a goal 😃). Plus the added weight/complexity to the image is negligible, as we already have some VM (QEMU/VMware/VBox) detection mechanism going on to force dockerd to listen on 0.0.0.0 (which is a no-no on baremetal).

That said, I should probably update the PR with the newly released VBox.

@tianon
Copy link
Contributor
tianon commented Mar 30, 2014

I'm still -1 on this change in general, as it further reduces the agnosticism of boot2docker and encourages what is a fairly destructive and confusing pattern. The problem of bind mounts not working from a remote Docker client is one that's general to all instances of a Docker daemon that listens non-locally, so I firmly believe the "proper" solution to this needs to (and indeed will, given time) come from the Docker side.

Just my 2¢.

@aheissenberger aheissenberger mentioned this pull request Apr 1, 2014
Closed
@aidanhs
Copy link
aidanhs commented Apr 2, 2014

@tianon has this been raised as a Docker issue then?

@tianon
Copy link
Contributor
tianon commented Apr 2, 2014

Absolutely, this is being discussed in moby/moby#4023.

@dduportal dduportal mentioned this pull request Apr 9, 2014
Closed
@hunterloftis
8000 Copy link

+1

@iwootten
Copy link

Sorry to step in, but I've run these commands using the 0.7 boot2docker image linked to along with the 0.7 boot2docker script and I just get (on the final step):

"modprobe: module vboxsf not found in modules.dep"

I understand this has something to do with having the VBAdditions available, but I'm unable to figure out how to install this or enable it.

NB. I've also built using the Dockerfile in the commit (which seems successful), but leads to the same problem. I'm building on a Mac and some poking around seems to suggest VBAdditions isn't available for OSX. Can anyone suggest a solution until this is merged?

@steeve
Copy link
Contributor Author
steeve commented Apr 15, 2014

I think you may not be booting from the right ISO file—
Steeve Morin

On Mon, Apr 14, 2014 at 9:44 AM, Ian Wootten notifications@github.com
wrote:

Sorry to step in, but I've run these commands using the 0.7 boot2docker image linked to along with the 0.7 boot2docker script and I just get (on the final step):
"modprobe: module vboxsf not found in modules.dep"
I understand this has something to do with having the VBAdditions available, but I'm unable to figure out how to install this or enable it.

NB. I've also built using the Dockerfile in the commit (which seems successful), but leads to the same problem. I'm building on a Mac and some poking around seems to suggest VBAdditions isn't available for the mac. Can anyone suggest a solution?

Reply to this email directly or view it on GitHub:
#284 (comment)

@bjaglin
Copy link
Contributor
bjaglin commented Apr 15, 2014

For those willing to automate to the maximum this workaround and are fine with maintaining a custom image, I recommend adding $VBM sharedfolder add $VM_NAME -name home -hostpath /Users at the end of the init function in the boot2docker script, and registering modprobe vboxsf && mkdir -p /Users && mount -t vboxsf home /Users in some init.d script within the rootfs. This way, mounting volumes under /Users will work transparently, without any need for manual steps.

(Note that this is simply a slight variation of what's suggested in the issue description, removing the need to resolve $HOME on the VBox host)

@TheBigBear
Copy link

What are the steps required to build a 'custom' iso like the one posted above under 'steeve's first comment:
[quote]
steeve said:
A test ISO based on 0.7 is at https://dl.dropboxusercontent.com/u/12014139/boot2docker.iso
[/quote]

Can this somehow be done 'scripted', or automated to the maximum, as bjaglin called it above, by using a Dockerfile somehow?

@bjaglin
Copy link
Contributor
bjaglin commented Apr 15, 2014

@TheBigBear producing a custom iso is a fairly documented and simple process: https://github.com/boot2docker/boot2docker/blob/master/doc/BUILD.md

$ sudo docker build -t boot2docker/boot2docker:base base/
$ sudo docker build -t boot2docker/boot2docker-rootfs rootfs/
$ sudo docker rm build-boot2docker
# you will need more than 2GB memory for the next step
$ sudo docker run --privileged --name build-boot2docker boot2docker/boot2docker-rootfs
$ sudo docker cp build-boot2docker:/boot2docker.iso .

@TheBigBear
Copy link

Thanks bjaglin that is great and very helpful.
So seeing that there is a lot more documentation out there than I was aware off and just to make sure I don't try to re-invent the wheel. ;-)
What I was hoping to do was to build a tcz extension pkg that contains the virtual box guest additions kernel modules to allow folder sharing (maybe I should plan to also include the others?) And then include this optional tcz kernel module extension pkg in the 'optional' pkgs dir on the iso and then have a Dockerfile that loads these guest extensions from the tcz extension pkg at boot time when I use my boot2docker client on my mac to boot off the boot2docker+optional_vbox_fs_extension.iso
This way the additional vbox flles only get into ram IF I chose to install this optional kernel modules tcz pkg.
Would any of this make sense? If not why not?

@SvenDowideit
Copy link
Contributor

fundamentally, we are working towards not doing sharing this using vbox specific extensions. instead, the solution will come from either docker itself, or using a network shared volume container - see https://github.com/SvenDowideit/dockerfiles/blob/master/samba/Dockerfile for what I use to share my boot2docker tools with my Windows desktop.

bind-mounting a directory that is actually located remotely to the docker daemon is both risky and slow, whereas using network shared volume containers matches much more closely what you would do in deployment.

@tunix
Copy link
tunix commented Apr 16, 2014

I'm a Mac user and really hoping an easy way of using docker with it. My development heavily relies on Virtualbox VM's and I want to convert it to docker containers. I can't make use of docker just because of this sharing folders issue. Is there a plan to solve this in near releases?

@mattes
Copy link
Contributor
mattes commented Apr 16, 2014

Same here. @tunix Using https://github.com/noplay/docker-osx in the meanwhile works out for me.

@TheBigBear
Copy link

OK, I am too new to docker to really know or understand how this all works together , just yet. But I have seen enough (mainly Mac) people's posts, and I am also one of them, that would like (even if it's temporary) a virtual box shared file integration.
How would I, basically combine the basic isos rebuild script from the instructions at
https://github.com/boot2docker/boot2docker/blob/master/doc/BUILD.md
with the vbox additons Dockerfile from:
https://gist.github.com/nsfmc/9862241#file-dockerfile-tmpl
and of course also the finale customisations that bjaglin mentions here
#284 (comment)
or can it even be done in one single Dockerfile?

The main question I have on this I think is how do I work a single Dockerfile so I can have the combination of these two manual lines:

$ sudo docker build -t boot2docker/boot2docker:base base/
$ sudo docker build -t boot2docker/boot2docker-rootfs rootfs/

I believe that once I understand how to do that, I think I can then "merge" all those pieces and instructions together into one final Dockerfile. (hopefully)

Thanks for a quick sample Dockerfile that achives the above two manual steps with a single Dockerfile?

@aanand
Copy link
Contributor
aanand commented Aug 4, 2014

OK, posted a comment there.

@nathanleclaire
Copy link
Contributor

To be clear: sharing your home directory with the virtual machine does not mean arbitrary images have access to anything in your home directory. They have access to what you choose to give them access to in your home directory, in the same way that running Docker on Linux works.

Sure, but that doesn't stop users from accidentally allowing this with a docker run -v $HOME:/free_secrets command concealed in a run.shscript, or copy-pasted from the Internet by users who aren't familiar with the CLI, etc.

I'll move discussion over to the other issue.

@wavded
Copy link
wavded commented Aug 5, 2014

Pardon my ignorance but if Docker running on Linux directly allows you to share whatever (what I understand from @bfirsh comment above) and therefore is OK running nasty run.sh scripts, why is this boot2docker's problem? Isn't it more a security issue with Docker itself that should be addressed there and not here?

@SvenDowideit
Copy link
Contributor

@steeve no, you are not going to merge this. b2d 1.3.0 will solve it properly, and we do not have time to test all the problems it will cause before 1.2.0 is released.

see boot2docker/boot2docker-cli#202 for the plan.

@SvenDowideit
Copy link
Contributor

one particularly scary user-story I told the other day, is when someone installs b2d on their family computer to try out some SW that can be run using it, then days later is finished, and forgets all about it. for the next 5 years, b2d is running (for some auto-start at boot time reason), and therefore is not updated to fix what we missed - then someone else clicks a link in an email that gets around a tls impl issue and hands the magically run container the docker socket

  • yay.

boot2docker is already a tool that can be used by non-developers - and there will be more all the time.

@1mentat
Copy link
1mentat commented Aug 5, 2014

You cannot protect people who are willing to copy and paste from the
internet. It is outside the info sec concerns of any project.
On Aug 4, 2014 7:16 PM, "Sven Dowideit" notifications@github.com wrote:

one particularly scary user-story I told the other day, is when someone
installs b2d on their family computer to try out some SW that can be run
using it, then days later is finished, and forgets all about it. for the
next 5 years, b2d is running (for some auto-start at boot time reason), and
therefore is not updated to fix what we missed - then someone else clicks a
link in an email that gets around a tls impl issue and hands the magically
run container the docker socket

  • yay.

—
Reply to this email directly or view it on GitHub
#284 (comment)
.

@mitar
Copy link
mitar commented Aug 5, 2014

@SvenDowideit, in any computer security discussion, the first thing is to define a threat model. Because, will boot2docker protect users against NSA as well?

@nathanleclaire
Copy link
Contributor

Pardon my ignorance but if Docker running on Linux directly allows you to share whatever (what I understand from @bfirsh comment above) and therefore is OK running nasty run.sh scripts, why is this boot2docker's problem? Isn't it more a security issue with Docker itself that should be addressed there and not here?

@wavded Well, this is why Sven says he runs boot2docker when working with Docker in Linux as well. It provides an additional layer of security should something wonky happen. Additionally on Linux you have to deliberately add the user to the docker group to run without sudo, on Mac/Windows a lot of this kind of thing is abstracted away from users, thus making them less aware of the risks.

You cannot protect people who are willing to copy and paste from the internet. It is outside the info sec concerns of any project.

@1mentat Sure you can. This is why Facebook attempts to mitigate attacks made by tricking people into copy-pasting malicious JavaScript into their URL bar. Just because someone will always fall for tricks doesn't mean you shouldn't even try. Even people who know better copy-paste commands and code from the Internet from time to time. Not to mention that's not the only attack surface, there are a huge variety of attacks and if a Docker exploit comes out tomorrow we're all going to be very glad we have a VM sitting between Docker and our "real" computer.

in any computer security discussion, the first thing is to define a threat model. Because, will boot2docker protect users against NSA as well?

If only.

Keep in mind everyone that most likely the solution implemented will allow you to share your home directory if you want to, but it won't do that by default. Being vulnerable should be "opt-in" not "opt-out".

@steeve
Copy link
Contributor Author
steeve commented Aug 5, 2014

@SvenDowideit alright, closing then.

@steeve steeve closed this Aug 5, 2014
@hrldcpr
Copy link
hrldcpr commented Aug 5, 2014

Just so other people don't have to scroll around to find it, here is the new issue:

boot2docker/boot2docker-cli#202

@bfirsh
Copy link
Contributor
bfirsh commented Aug 5, 2014

I'm pretty sure we're going to need this if we do some kind of directory sharing as described in boot2docker/boot2docker-cli#202.

@mitar
Copy link
mitar commented Aug 5, 2014

Keep in mind everyone that most likely the solution implemented will allow you to share your home directory if you want to, but it won't do that by default. Being vulnerable should be "opt-in" not "opt-out".

Vulnerable to whom and for what? Again, what is a threat model?

@tianon tianon mentioned this pull request Sep 11, 2014
Merged
@bfirsh
Copy link
Contributor
bfirsh commented Sep 11, 2014

This has now been reopened as #534. (Just so you all get a notification!)

@gansbrest
Copy link

VirtualBox Guest Additions are unusable/slow for project with lots of small files ( tested with 17K files ). Is it just me?

I created Hodor github.com/gansbrest/hodor to streamline dev workflow for Mac and Linux. Let me know what you guys think.

@dduportal
Copy link
Contributor

@gansbrest : http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines
Yes

@alex-zige
Copy link

@gansbrest @dduportal Yeah. You are not alone. Had the same problem. :(

@vmaatta vmaatta mentioned this pull request Oct 22, 2014
Open
@jmreicha
Copy link

@gansbrest @dduportal is there a workaround for the VBox guest addition horrible performance issue? I haven't looked at hodor yet.

@gansbrest
Copy link

@jmreicha hodor! ))

@tianon tianon deleted the vboxsf branch December 16, 2014 18:10
@nathan-zhu
Copy link

hi, any news for this, i'm use docker1.7 but still have same problem. please help.

@thaJeztah
Copy link

@nathan-zhu no single solution yet. The performance issue isn't related to Docker itself, just the VBox guest additions. You can find some alternative approaches in the discussion above though, that might help in your situation.

However, the Docker 1.7 "experimental build" offers "Volume Drivers" (see https://github.com/docker/docker/blob/master/experimental/plugins_volume.md), which could potentially open up some possibilities (for example, see moby/moby#13420 (comment))

@mattes
Copy link
Contributor
mattes commented Jun 30, 2015

@nathan-zhu Check out https://github.com/synack/docker-rsync. It's pretty experimental though.

@gansbrest
Copy link

@nathan-zhu I guess I still have to recommend Hodor (https://github.com/gansbrest/hodor) for now for fast bidirectional sync through Unison.

@ehernandez-xk
Copy link

Hi,
What is the status of this? because I have the problem with the following configuration:

Windows 7
I have a custom boot2docker form 1.11.1 version
VirtualBox 5.0.16
Vagrant 1.8.5

Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attemped was:

set -e
mount -t vboxsf -o uid=`id -u docker`,gid=`getent group docker | cut -d: -f3` b5
973a5087 /var/lib/docker/docker_1472079332_51007
mount -t vboxsf -o uid=`id -u docker`,gid=`id -g docker` b5973a5087 /var/lib/doc
ker/docker_1472079332_51007

The error output from the command was:

mount: mounting b5973a5087 on /var/lib/docker/docker_1472079332_51007 failed: Pr
otocol error

Do you have an example to use it on windows? I'm using Vagrant and docker as a provider.

@ehernandez-xk
Copy link

When I run mountmanually I get this message.

-sh: getent: not found
gid= requires an argument (i.e. gid==<arg>)
mount: mounting vagrant on /vagrant failed: Protocol error

@dduportal
Copy link
Contributor

Hello @ehernandez-xk !
This is due to a regression in Vagrant, from 1.8.5 until 1.8.5 included:

For now, I strongly recommend you to stay on Vagrant 1.8.1 and VirtualBox 5.0.x line, since Vagrant support of VBox 5.1.x landed on... vagrant 1.8.2...

@ehernandez-xk
Copy link

Thank you @dduportal

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0