New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VBox guest additions #284

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
@steeve
Contributor

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

This comment has been minimized.

shlomifruchter commented Mar 17, 2014

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

@steeve

This comment has been minimized.

Contributor

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

@aheissenberger

This comment has been minimized.

Contributor

aheissenberger commented Mar 21, 2014

👍 @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>]

cameronmaske added a commit to cameronmaske/docker-osx that referenced this pull request Mar 26, 2014

Replace Ubuntu VM with boot2docker.
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.

@aanand aanand referenced this pull request Mar 27, 2014

Closed

volumes not work #172

@lightsofapollo

This comment has been minimized.

lightsofapollo commented Mar 28, 2014

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

This comment has been minimized.

Contributor

steeve commented Mar 28, 2014

Can we merge this already guys ?

@nsfmc

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

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¢.

@aidanhs

This comment has been minimized.

aidanhs commented Apr 2, 2014

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

@tianon

This comment has been minimized.

Contributor

tianon commented Apr 2, 2014

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

@hunterloftis

This comment has been minimized.

hunterloftis commented Apr 12, 2014

+1

@iwootten

This comment has been minimized.

iwootten commented Apr 14, 2014

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

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

This comment has been minimized.

TheBigBear commented Apr 15, 2014

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

This comment has been minimized.

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

This comment has been minimized.

TheBigBear commented Apr 15, 2014

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

This comment has been minimized.

Contributor

SvenDowideit commented Apr 15, 2014

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

mattes commented Apr 16, 2014

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

@TheBigBear

This comment has been minimized.

TheBigBear commented Apr 16, 2014

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

This comment has been minimized.

Contributor

aanand commented Aug 4, 2014

@nathanleclaire

This comment has been minimized.

Contributor

nathanleclaire commented Aug 4, 2014

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

SvenDowideit commented Aug 5, 2014

@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

This comment has been minimized.

Contributor

SvenDowideit commented Aug 5, 2014

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

nathanleclaire 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?

@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

This comment has been minimized.

Contributor

steeve commented Aug 5, 2014

@SvenDowideit alright, closing then.

@steeve steeve closed this Aug 5, 2014

@hrldcpr

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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 referenced this pull request Sep 11, 2014

Merged

VirtualBox Guest Additions #534

@bfirsh

This comment has been minimized.

Contributor

bfirsh commented Sep 11, 2014

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

@gansbrest

This comment has been minimized.

gansbrest commented Oct 5, 2014

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

This comment has been minimized.

@alex-zige

This comment has been minimized.

alex-zige commented Oct 5, 2014

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

@jmreicha

This comment has been minimized.

jmreicha commented Oct 24, 2014

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

@gansbrest

This comment has been minimized.

gansbrest commented Oct 24, 2014

@jmreicha hodor! ))

@tianon tianon deleted the vboxsf branch Dec 16, 2014

@nathan-zhu

This comment has been minimized.

nathan-zhu commented Jun 30, 2015

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

@thaJeztah

This comment has been minimized.

thaJeztah commented Jun 30, 2015

@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

This comment has been minimized.

Contributor

mattes commented Jun 30, 2015

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

@gansbrest

This comment has been minimized.

gansbrest commented Jun 30, 2015

@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

This comment has been minimized.

ehernandez-xk commented Aug 25, 2016

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

This comment has been minimized.

ehernandez-xk commented Aug 25, 2016

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

This comment has been minimized.

Contributor

dduportal commented Aug 26, 2016

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

This comment has been minimized.

ehernandez-xk commented Aug 26, 2016

Thank you @dduportal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment