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

`vagrant` user may need `vagrant` group #13

Merged
merged 1 commit into from May 28, 2014

Conversation

Projects
None yet
2 participants
@zigg
Contributor

zigg commented May 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton May 25, 2014

Owner

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.

Owner

timsutton commented May 25, 2014

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.

@zigg

This comment has been minimized.

Show comment
Hide comment
@zigg

zigg May 25, 2014

Contributor

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…

Contributor

zigg commented May 25, 2014

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

This comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton May 25, 2014

Owner

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!

Owner

timsutton commented May 25, 2014

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!

@zigg

This comment has been minimized.

Show comment
Hide comment
@zigg

zigg May 25, 2014

Contributor

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.

Contributor

zigg commented May 25, 2014

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.

@zigg

This comment has been minimized.

Show comment
Hide comment
@zigg

zigg May 25, 2014

Contributor

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

Contributor

zigg commented May 25, 2014

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

@timsutton

This comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton May 26, 2014

Owner

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?

Owner

timsutton commented May 26, 2014

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?

@zigg

This comment has been minimized.

Show comment
Hide comment
@zigg

zigg May 26, 2014

Contributor

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…

Contributor

zigg commented May 26, 2014

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 comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton May 26, 2014

Owner

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)

Owner

timsutton commented May 26, 2014

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)

@zigg

This comment has been minimized.

Show comment
Hide comment
@zigg

zigg May 26, 2014

Contributor

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.

Contributor

zigg commented May 26, 2014

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

This comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton May 27, 2014

Owner

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?

Owner

timsutton commented May 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton May 27, 2014

Owner

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.

Owner

timsutton commented May 27, 2014

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.

@zigg

This comment has been minimized.

Show comment
Hide comment
@zigg

zigg May 27, 2014

Contributor

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.

Contributor

zigg commented May 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton May 28, 2014

Owner

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.

Owner

timsutton commented May 28, 2014

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 added a commit that referenced this pull request May 28, 2014

Merge pull request #13 from zigg/fix/vagrant-group
`vagrant` user may need `vagrant` group

@timsutton timsutton merged commit df2dfbd into timsutton:master May 28, 2014

@zigg zigg deleted the zigg:fix/vagrant-group branch May 28, 2014

@timsutton

This comment has been minimized.

Show comment
Hide comment
@timsutton

timsutton Jun 2, 2014

Owner

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

Owner

timsutton commented Jun 2, 2014

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

@zigg

This comment has been minimized.

Show comment
Hide comment
@zigg

zigg Jun 4, 2014

Contributor

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 :)

Contributor

zigg commented Jun 4, 2014

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 :)

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