Fix vagrant.sh hanging when executing dseditgroup.

[asimpletune]

Related to issue #31

So, VPN issues are present but not the cause of this. The root cause has to do with the dseditgroup command when called on some environments. Passing in the -q flag disables interactive verification, thus preventing the script from hanging.

[timsutton]

Wow. Good to know the fix! Did you ever get to compare different environments in order to figure out what the real cause of dseditgroup hanging? I'm surprised that since we're adding group membership from a known starting place that it would cause a prompt (?). I wonder if it could have something to do with the user that's being added?

[timsutton]

One other point - if you added the 'exit' to the end of the script.. does that mean that those commands with the -q added are now silently failing in your environment?

It may also be entirely possible that we don't need to be creating a group just for the user. This logic goes way back to when I first wrote these definitions for VeeWee, and may well no longer be needed.

[timsutton]

Looked again, I see that the group is there due to the default behaviour when using rsync as a synced folder mechanism (see #13).

[asimpletune]

Hey Tim, sorry about the delayed reply. I'll try to answer in order:

I didn't get very far in comparing environments. Until the change that I submitted, it was failing on my work environment, but it passes on my local (with or without my proposed change). I don't really know what would be different about my work environment to make it do that, other than we use a custom OS X image.

That's a good point about the exit. I believe that would be the case but haven't tested.

It's great that you tracked down the origins of needing the group, perhaps that gives some clues why it would fail on a custom OS X image (like the one I have for work) and succeeds on stock image (my personal machine)?

[timsutton]

So by 'custom OS X image', is this one that defines a user other than vagrant?

Since those dseditgroup statements were added only for the use case of Vagrant and rsync anyway, I should actually make them run only in case $USERNAME is vagrant. (That should probably actually be the case for the entire script and move the computer/hostname bits to another script, but that's outside the scope of this anyway).

[asimpletune]

So by 'custom OS X image', is this one that defines a user other than vagrant?

No, I meant custom OS X image for bare metal provided by IT. There could be other differences between the two environments, but that was kind of a general starting point for me. I don't know enough about what is done to our enterprise images to really pinpoint the main differences.

Regardless though, I think it's probably best that the non-interactive flag -q is set anyway.

edit: at least until you do the refactor that you were discussing.