vagrant user may need vagrant group

[mattieb]

Trying to use rsync-style shared folder support, I get this:

==> default: Rsyncing folder: /Users/matt/src/brewdo/ => /vagrant
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

find '/vagrant' '(' ! -user vagrant -or ! -group vagrant ')' -print0 | xargs -0 -r chown vagrant:vagrant

Stdout from the command:



Stderr from the command:

xargs: illegal option -- r
usage: xargs [-0opt] [-E eofstr] [-I replstr [-R replacements]] [-J replstr]
             [-L number] [-n number [-x]] [-P maxprocs] [-s size]
             [utility [argument ...]]
find: -group: vagrant: no such group

The -r option for xargs requires some extra work on Vagrant's end, but I think the vagrant group is something that can be done in prepare_iso (Vagrant boxes for other OSes have this.) Unfortunately, I'm not sure where to start looking for this.

Note: I am using the prerelease Packer with SATA ISO support for VirtualBox (hashicorp/packer#1200) and the small work that I've done adding that support to the Packer template (https://github.com/zigg/osx-vm-templates/commit/e9dd4034ae8ac4a13aed8cb54267458b7fa23b3a) but I expect this behaves similarly under VMware. The Vagrantfile required to trigger this looks like this:

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "osx109"
  config.vm.synced_folder ".", "/vagrant", type: "rsync"
end

[timsutton]

Very cool. I had looked a few months ago at what would be needed for VBox support and didn't have the time or Go chops to add the SATA interface support for the optical device. I see you even saw my template gist with the testing VBox builder 😸

Adding a vagrant group would make the most sense in the vagrant.sh script I would think as it's specifically Vagrant-related, so it could always be omitted for someone not using Vagrant. This would be trivial to add, which I'd be happy to when I have time to test it in a few days back at work.

It's also convenient that I recently simplified the partitioning step for the built ISO, because prior to that it used a mechanism that was failing due to the way that OS X saw the exposed disk from VirtualBox compared to when using VMware.

[mattieb]

Yep, the small merge/tweak work of mine started with your gist, and I suspected you'd done some work regarding the removable disk thing since I didn't actually run into that second issue. (Actually, I originally started hacking on the Bento VMware template and ended up with something similar, but when I saw you'd already started I went there instead—this looks to have been a good decision 😄)

I had looked at vagrant.sh, but thought that might not actually be the right place since it didn't actually seem to create the user account. Something with vagrant.plist and PlistBuddy? This is unfamiliar territory for me (the only user automation I've ever done revolved around dscl…)

Just because I'm on a roll I may look into it anyway and see, but if I don't, I'll be happy to let you take the reins later…

[timsutton]

The partitioning change I added recently is definitely simpler, though perhaps too simple, as it always assumes the disk to partition is disk0, most likely the first SATA disk. Anyway, it is definitely possible to make it smarter if need be, but if it works for the common case and for VBox as well, then I guess we're good for now.

As for where to create the group, while it is more logical to create it along with the user, it's also more work to do it on the unbooted image, and also adds another plist resource (with the same name: vagrant.plist no less) to manage in prepare_iso, because this would need to be copied over.

Either way it's not a big deal, but I'm more in favor of keeping prepare_iso pared down to only the bare essentials needed to get Packer able to connect to it to do the rest of the provisioning, since it's a long enough pile of shell as it is. I think all that would be required is a dscl create and the setting of a GID, and I guess to make the vagrant user a member of the group with dseditgroup. Feel free to try it if you'd like, I can look it over soon or otherwise add them myself.

Thanks for your work on this!

[mattieb]

Turned out to be pretty dead easy with your guidance, thanks!

There is still the xargs -r problem, but I think that's something I have to work on Vagrant with. In the meantime, rsyncing is working, just not setting ownership properly.

[mattieb]

For the record, here's the last piece of the puzzle to fix Vagrant. hashicorp/vagrant#3902

[timsutton]

Awesome. In the meantime today I'd also done the equivalent with dscl and tested that a new machine builds ok. I didn't have time to test an actual vagrant up and importing the box, but will tomorrow. So I hadn't even had time to run into the cargos issue but now we know that will be in the next version of Vagrant thanks to you. And using dseditgroup is probably the better way to go here anyway, so the system can itself determine the GID.

I also prefer what you did (as did @fnichol I believe) in using user vars for the iso path and checksum as they will be always different and could be passed in via a wrapper script, and this way you share them between builders too.

Curious, have you tested synced folders in Vbox using NFS?

[mattieb]

Just did now and it worked.

But it took a little Vagrant-related doing to get it going, because on my branch I've been attempting to supply a Vagrantfile in the box that defaults to rsync for the virtualbox provider… and I ended up overriding the nfs version of same in my local Vagrantfile. So I may have to back that one out.

The Vagrantfile trick worked for OpenBSD, but that's an OS with no guest additions period. I may not be able to selectively do this…

[timsutton]

This looks good. I'm able to have Packer build the whole VM and with the xargs change in Vagrant's rsync cap, use the rsync sync'ed folder mechanism.

The default Vagrantfile is a good point, though, since the default of using Vbox's shared folders system won't work. NFS works for me, though it requires additional network config in the Vagrantfile. I don't have a preference either way - it's useful enough to just have the information about the lack of shared folder support readily available in the Vagrantfile so that the warning output from Vagrant isn't a surprise.

The only other thing I have to note is that when I tested this at home on a slow 2010 Mac Mini (Core 2 Duo) the --cpuidset option caused the VM to halt with an error on boot. On my Ivy Bridge iMac at work this doesn't happen, however, so there is some point where this option seems necessary, at least in the current version of Vbox. Not sure how to best handle this. It doesn't look like Packer yet has support for comments. (ie. hashicorp/packer#283)

[mattieb]

Re --cpuidset, guess that's going to have to come out, too, then. AFAICT it's required for Haswell but nothing prior, and you've discovered it only works on Ivy Bridge forward.

I don't really want to create multiple templates (especially as they'll be largely similar) but it seems the most user-friendly way would be to go ahead and do a virtualbox-haswell.json, virtualbox-all.json, vmware.json, etc.

[timsutton]

I'm not sure it only works on Ivy Bridge forward, it's just that I didn't test anything between my Ivy Bridge workstation and whatever Core2 generation is in the 2010 Mini.

Until there is some supported way to add comments to the templates, another option could be simply to document the issue in a caveats section in the README, which I'd be happy to do. This would be generally useful as a to document the details of the template which currently aren't.

I have access to other generations of iMacs for testing - if I can identify that the option works on other Core i5/i7 boxes then we could probably safely leave it in the template.

Curious, how did you identify the option requirement in the first place?

[timsutton]

Just to add, I also don't really want to create multiple templates for a one or two-line change. Maybe at some point it may be necessary, but it's easier to track one file for now, I think.

[mattieb]

This venerable page about running OS X in VirtualBox used to note that Haswell hosts would fail to boot Mavericks, but was updated at some point recently with the --cpuidset option. I haven't actually managed to try it on my wife's Haswell iMac yet though.

I wish there was a better way to do the templates, but that's JSON for you. 😑 Couple ideas, but none of them are very clean or easy…

I won't have any more time to work on this today or tomorrow most likely, so feel free to run with my virtualbox branch if you wish.

[timsutton]

Sounds good. I'll merge this one right now and when I've a bit more time to update the main docs I'll merge your template update, with notes about the minimum required Packer and Vagrant versions.

[timsutton]

FYI I split the templates just for the time being until 0.6.1 is released (which should include your fix, assuming it will be merged). As I expected, there has been confusion about the 0.6.1 requirement and I hadn't considered that it prevents using the vmware-iso builder as well.

f106563

[mattieb]

Hi @timsutton, thanks for letting me know. I am watching this repo though so don't feel like you have to go out of your way in the future :)