radeksimko / vagrant-osx

Vagrant setup for Mac OS X

Vagrant setup for OSX

Vagrant environment for testing and experiments inside OSX running via VMWare.

Prerequisites

1. Download a fresh copy of OSX installer from AppStore.
2. Create a Vagrant OSX box via timsutton/osx-vm-templates

• Use --only=vmware-iso to only use VMWare builder
• Increase the disk size (default is 20480 MB) as installing large packages from Homebrew and elsewhere may take up 20GB pretty quickly
• Remove Parallels and Chef scripts as we won't need these

3. Place the result box in the root of this repo as mac-osx-10-10-vmware.box
4. Install Homebrew (which implies having XCode CLI Tools installed)
5. Install Brewcask brew install caskroom/cask/brew-cask
6. Install other tools: brew install --cask vagrant vmware-fusion
7. Install Vagrant VMWare plugin: vagrant plugin install vagrant-vmware-fusion and add license vagrant plugin license vagrant-vmware-fusion license.lic

Caveats

Boxen & synced folders

Boxen uses file-locking to ensure it's only running once. This doesn't work with the default VMWare file-sync mechanism.

This is why we use NFS, but that has a different caveat - each time you run vagrant [up|reload], Vagrant will try to modify /etc/exports on your host machine, which will by default require your sudo password.

A workaround could be allowing write for all admins on that system & restarting nfsd without password:

# This is due to pesky sed - see https://github.com/mitchellh/vagrant/pull/5259
sudo chown root:admin /etc
sudo chmod g+w /etc

sudo chown root:admin /etc/exports
sudo chmod g+w /etc/exports

echo "%admin ALL=(root) NOPASSWD: /sbin/nfsd" >> /etc/sudoers

while having Vagrant 1.7.0+ installed.

Testing environments

Just pure OSX

Just a pure OSX with no extra mountpoints/provisioners, works out of the box.

vagrant up base

Boxen

Expects ./our-boxen directory in the root, Vagrant will mount it & install accordingly.

Available ENV variables:

• GH_TOKEN - Github token for Boxen
• UNLOCK_BOXEN (empty or 1) - whether to unlock boxen (sometimes necessary when you kill the instance in mid-flight)
• NO_PULL (empty or 1) - whether to pull down latest version of mounted our-boxen or not

vagrant up boxen

Dotfiles

TODO

Homebrew (Cask)

This will install latest Homebrew + Brewcask, turn Brewcask into DEV mode and mount any directories named as homebrew-* as taps into the VM.

vagrant up brew

Usage

vagrant ssh brew
brew install vagrant/homebrew-mytap/package-name

vagrant-osx's Issues

Support Virtualbox

As discussed in boxen/our-boxen#364 (comment)

Boxen: Allow provisioning of uncommitted changes

Have a look if boxen has any option how to force it to not ask

Would you like to run Boxen anyway, without the latest updates? [y/N]

and/or automatically answer y.

==> boxen: --> Skipping auto-update, because you've got uncommitted changes:
==> boxen:
==> boxen:  M manifests/site.pp
==> boxen:
==> boxen: Since you've got some uncommitted changes to those files, I'm
==> boxen: going to take the safe road and not automatically update anything.
==> boxen: If you're actively working on some Boxen, maybe you'd like to
==> boxen: switch to a branch, rather than working on master? This way I'll
==> boxen: know that you're trying something new, and won't do things like
==> boxen: automatically update, or submit issues, while you're making
==> boxen: changes. It makes everyone's life a bit easier ❤
==> boxen:
==> boxen: Now, if you *weren't* expecting any changes, here's how to get
==> boxen: back on the golden path:
==> boxen:
==> boxen:   cd /opt/boxen/repo
==> boxen:   git reset --hard origin/master
==> boxen:   boxen
==> boxen:
==> boxen: For more info on how the simple git-based updates work, have a gander at
==> boxen: https://github.com/boxen/our-boxen/blob/master/docs/updates.md
==> boxen:
==> boxen: Would you like to run Boxen anyway, without the latest updates? [y/N]
==> boxen:

Refactor all boxen arguments into one host ENV variable

There's currently a few ENV variables that affect boxen:
https://github.com/radeksimko/vagrant-osx/blob/master/Vagrantfile#L33-35

As this list would only grow and more importantly limit users in what they can change on boxen run, this should be replaced with one variable, e.g. BOXEN_ARGS and have the current set as default.

GH_TOKEN should be probably still kept separately as not many users may want to duplicate all default args just because they want to set the token (which is likely to be a common use-case).

Support older versions of OS X

Make define hosts based on OSX versions, so that user can run any version for any use-case.

vagrant up \
  [boxen-10|boxen-9|boxen-8 | base-10|base-9|base-8 | ...]

eventually use codenames?

vagrant up \
  [boxen-yosemite|boxen-mavericks|boxen-mountain-lion | base-yosemite|base-mavericks|base-mountain-lion | ...]

HyperV support?

Hiya, thank you for publishing Vagrant boxes for macOS!

Would it be possible to offer HyperV provided boxes as well? Unfortunately, Docker in Windows relies on HyperV these days, and HyperV is unable to run concurrently with the VirtualBox hypervisor. In other words, developers working with Windows hosts must choose to boot with either HyperV enabled to run Docker, or else HyperV disabled to run VirtualBox and Vagrant. But if the macOS Vagrant boxes were integrated with the HyperV provider, then Windows users would be able to hack on Docker and Vagrant projects at the same time, without having to constantly reboot. What do you think?

Boxen: Allow provisioning with SSH-based repository URLs

If you use [email protected]:org_name/our-boxen as a default URL for upstream remote, vagrant will show following error:

==> boxen: --> Preparing to auto-update...
==> boxen: Host key verification failed.
==> boxen: fatal: Could not read from remote repository.
==> boxen:
==> boxen: Please make sure you have the correct access rights
==> boxen: and the repository exists.
==> boxen: --> Skipping auto-update, because running `git fetch` failed
==> boxen:
==> boxen: Well that's disappointing! Are you having network trouble? Is github.com
==> boxen: under attack? Given the potential for all sorts of boxen-y things failing
==> boxen: without the ability to pull from github, I'm going to abort for now.
==> boxen:
==> boxen: Check that you can hit github, see if there are any ongoing issues with
==> boxen: the site and/or your network, and try again ASAP!
==> boxen:
==> boxen: For more info on how the simple git-based updates work, have a gander at
==> boxen: https://github.com/boxen/our-boxen/blob/master/docs/updates.md
==> boxen:
==> boxen: Would you like to run Boxen anyway, without the latest updates? [y/N]

Because it doesn't have any key to use when reaching github.com over SSH.

Maybe Vagrant has some kind of key host->guest forwarding feature or maybe we can just simply skip this check the same way as intended in #1 ?