Closed fnordfish closed 10 years ago
One way or another, I bumped into this bug in Vagrant 1.3.3 while testing my changes. Make sure you use Vagrant 1.3.4 to test this.
No reaction after 11 days. Is there anyone listening on the other side? :-)
Sorry! We're listening, but kind of busy right now.
Your PR looks pretty good to me -- @skade, any objections?
On 14.10.2013, at 13:15, Ringo De Smet notifications@github.com wrote:
No reaction after 11 days. Is there anyone listening on the other side? :-)
— Reply to this email directly or view it on GitHub.
It looks like this change unfortunately makes it impossible to install the resolver if no graphical environment is available (i.e. over SSH). In my case, I'm running a VM in VMware running OS X, and I want to use vagrant-dns
inside that virtual machine to allow it to resolve another VM that it runs nested inside.
I've developed a simple test case for anybody who wants to reproduce it:
ssh localhost
, accepting the host key, then entering your password when prompted.vagrant-dns --install
.This results in the following error:
0:138: execution error: The administrator user name or password was incorrect. (-60007)
In my case, I have allowed passwordless sudo on the OSX virtual machine. So ideally I'd just run the command with sudo (so sudo vagrant dns --install
). Maybe you could add a check -- if the command is running as root, don't bother with the osascript stuff to ask for credentials? I'm happy to deal with the fallout from using sudo
(permissions issues mainly, so I'll manually set the permissions after it runs).
@bradfeehan accepted as issue #26
Creating the resolvers symlink (
/etc/resolver/tld
) to our temp file (~/vagrant.d/tmp/dns/resolver/tld
) requires root permissions. Prior vagrant-dns 0.4.0 you needed to run the installation process usingsudo
or alike. As a ancillary side effect, this also created some files in your user space with root permission, which made those files inaccessible when running as "normal user".The solution merged into from pull request #12 uses backticks to spawn a "sudo" process when needed. This certainly gets the job done, but isn't quite elegant and also makes a lot of assumptions of how your user land is configured.
However, I can't think of any really good solution at the moment.