11–20 of 47 posts
Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my dream development workflow. Edit: I got so excited I even forgot to thank Mitchell for all the hard work. Vagrant completely changed my (work) life. Thank you a thousand times, Mitchell!
Just the other day I was telling a friend of mine how having the ability to share my Vagrant dev environment was the only missing from what I would consider my dream development workflow. Edit: I got so excited I even forgot to thank Mitchell for all the hard work. Vagrant completely changed my (work) life. Thank you a thousand times, Mitchell!
I install ngrok[1] on my vm's to show off what I've been working on temporarily or to see how things look on iOS. [1] https://ngrok.com/
Another benefit Vagrant Share has that I haven't seen yet in any other localhost tunneling solution is that it shares _every_ port (if you want), not just a single port, and gives the other person an IP to access the machine as if it were on the LAN. This is super nice if you want to expose anything like Redis, SSH, etc. You just "vagrant share" and, again, you're done.
Also, many localhost tunneling solutions don't support UDP. We fully support UDP connections in addition to TCP.
The big win, though, technology aside, is how if you use Vagrant, this just becomes another part of your Vagrant workflow that _just works_. You don't have to worry about installing anything, and of course it'll work with any sort of guest machine running on any provider.
Feature request for the Mac OS Vagrant port: please don't copy your executable into /usr/bin when running the installer (and that seems to be the only reason the installer exists at all — it would be better distributed just as a .zip containing the Vagrant directory; I can take it from there). /usr/bin is for system-provided executables, not for applications. I understand the wish to provide an easily-accessible comm…
An alternate approach: Mac has some way to hook into shell profile loading so we should be able to inject a script somewhere that amends the PATH. This turns out to be a little crazy on Mac for some reason I don't remember, but should be possible.
Surprisingly, things are better here for Windows: Windows has an API call to both set environmental variables AND send messages to applications to refresh their environmental variables! So, Windows people have somewhat nice things.
Anyways, I'd love to improve this. The installer generators are open source, would be happy for any contributions: https://github.com/mitchellh/vagrant-installers
Feature request for the Mac OS Vagrant port: please don't copy your executable into /usr/bin when running the installer (and that seems to be the only reason the installer exists at all — it would be better distributed just as a .zip containing the Vagrant directory; I can take it from there). /usr/bin is for system-provided executables, not for applications. I understand the wish to provide an easily-accessible comm…
We used to do that, but we received SO MANY complaints that it wasn't instantly available on the PATH, that we symlinked into /usr/bin. An alternate approach: Mac has some way to hook into shell profile loading so we should be able to inject a script somewhere that amends the PATH. This turns out to be a little crazy on Mac for some reason I don't remember, but should be possible. Surprisingly, things are better here…
It works for Mactex without fucking with the system folders.
It looks like the SSH option sends the encrypted private-key to anyone who asks (via the "vagrant connect --ssh" command)... so they could do an offline brute-force attack. Thus, even though there's some public-key encryption being used, this is ultimately less secure than even allowing remote logins with just a password (because you can't observe and throttle failed attempts). Even with the keypairs being regenerate…
Yes, you're right. But this is assuming a lot of things which are still really hard: * The person would've had to retrieved the private key before. This private key is only ephemerally written to disk to `ssh` and is deleted after, otherwise being stored in memory only a brief period of time. Additionally, when it is sent down over the network, it is done so over a TLS connection. So this means they would've had to s…
The unpredictable share-name likely adds the most important short-term barrier – essentially an extra random passphrase that's not offline-brute-forceable – especially if your server is logging/throttling scans of the share-name space.
Do I understand correctly that the 'share' command doesn't exit until the session ends? If so, it might be nice to report all the connections/attempts at each session end, so checking another log at a remote console isn't required to notice an anomaly.
The security may be fine for typical uses, I just wanted to help people understand that the password chosen is potentially leaked (in encrypted form) to third-parties... so shouldn't be something too weak/common/widely-reused.
Earlier quoted context omitted.
The idea is that you could have a remote coworker or a QA use your dev server to test things, review UI, etc.
So they can only get their job done if they are in the same timezone or if you don't happen to reboot your laptop? Those don't seem like great use cases. Plus if you are at the point of QA/PM review of what you've done, the code has already been checked into source control. They could just as easily spin up their own VM with the Vagrantfile.
I used Vagrant for CI builds for a while, and I would have liked the ability to automatically share an internal url to the environment so that when coworkers submitted code that broke the build, they would have a single link to follow to get access to the particular environment on the particular server that serviced their job.
Some vagrant envs are also somewhat complex to set up - I could use this for teaching people how to use things like this: https://github.com/stackforge/puppet_openstack_builder
If my above assumption is true, would a Vagrant Share Enteprise be in the works/future, similar to Github Enterprise?
Thanks for the awesome tools HashiCorp!
Earlier quoted context omitted.
The idea is that you could have a remote coworker or a QA use your dev server to test things, review UI, etc.
So they can only get their job done if they are in the same timezone or if you don't happen to reboot your laptop? Those don't seem like great use cases. Plus if you are at the point of QA/PM review of what you've done, the code has already been checked into source control. They could just as easily spin up their own VM with the Vagrantfile.