👍 This is definitely the way to go in my opinion - much simpler than doing port-forwarding. I'm going to have a go at porting the /etc/hosts thing over from docker-osx.

OK, have a look at https://github.com/aanand/boot2docker/compare/hostonly

I also rebased onto the current master, but there was a conflict in the first commit and I don't fully understand it, so you might want to have a quick look at d5d7db7 to see if anything broke.

OK, I think I fixed the rebase. Sorry for the noise.

Thanks ! 👍

@steeve, @bfirsh, @aanand what do you think about this ?

The main difficulty is about having a dedicated VirtualBox interface, since the user can use boot2docker alongside other typical virtual machines

A big part of the commits is dedicated to handling this and also the reboot issue
It may remain some bugs, but I think we should merge it in master and begin to use it

To paint a bikeshed, I wonder if boot2docker as the hostname might be easier to comprehend. One less thing to understand.

My thoughts are.

1. Go with a really unique IP.
2. If it's taken, throw an error and ask them to override it with a command line option or ENV variable.

I guess the main points of ease of use is getting an entry into their hosts file and into their $DOCKER_HOST env variable.

@aheissenberger in the osacript thing, I get where you're coming from, but when I tried it, it pops up a pretty weird dialog asking for your password, which for me at least was a little bit unexpected coming from a command line install. I expect to enter my password for sudo, but the popup almost looked a little virusey.

When you mount an nfs share with vagrant, it asks you for your sudo password.

Perhaps we can make the assumption that as a developer they'll have admin rights, or try to detect this first?

@eugeneware I always use a user on OSX without admin rights (= no sudo) and my boot2docker script tests if the user has access to sudo and will only use the oascript on OSX if there is no other way to get access to sudo. a developer with admin rights (= access to sudo) will not see any kind of popup:
https://github.com/aheissenberger/boot2docker/blob/master/boot2docker#L527

The way I implemented the host only interface you will allway get a unique IP and I will reuse any existing vbox interface as long it complies to my requirements. to enjure that that I know the IP I will add an magic update of the IP to the local /etc/hosts file.

@aheissenberger strange, because when I used the nfs mapping script I definitely got a popup, and I have Admin rights. Maybe that script doesn't check?

Not a big deal in any way, just some feedback.

@eugeneware can you do a sudo -v and post me your output?

@eugeneware fixed it - have not tested it with an admin user - should work now without the popup for you

Thanks @aheissenberger! You rock!

finished my hostonly interface implemetation which also includes now setting /etc/hosts and ~/.bash_profile

Any news regarding this? :)

the replacement project (https://github.com/boot2docker/boot2docker-cli has a second hostonly network interface added - and work is ongoing to add more control. so yes, but over there :)

Closing, as this is working in boot2docker-cli.

For those curious about how it works in boot2docker-cli (which I installed with Boot2Docker.app) you need to expose the port as normal (using -P or p 127.0.0.0:$HOST_PORT:$CONTAINER_PORT), then you can access the port via the boot2docker vm ip, which is usually 192.168.59.103 (you should see the IP when you first run boot2docker up).

boot2docker/boot2docker-cli#164

boot2docker-cli that been a solution to this now deprecated... I think issue is active again

The solution today would be to do it via docker-machine, directly in VirtualBox, etc. There's nothing in boot2docker itself we can change to help here, as the OS bits are functional.