I forget what tiny problems I was having with vagrant from the repo (I can try to reproduce that, if nobody else had that issue) that pushed me to look for solutions. But, I ended up on their website about 6-8 weeks ago and they insist that users use their binary and nothing from a repo or ruby gem (I silently assumed that’s what everyone was doing, after reading how much they insist on it), which worked alright (few warnings, no errors) until about a week ago, when it seemed to play tug-of-war with my rubygems. It was easily solved (all hail the repo, simply just dpkg --install vagrant’s .deb and let apt/synaptic handle system packages masked vagrant).
I’m sure this approach is okay, but does vagrant need to be in the repo? Is it working just fine for others? I personally kind of use it more like temporary image, because of it’s limited networking features. So, for example, I’ll use a vagrant if I just need the instance to test something or basically for anything less than a week. If I need a long-term machine, I build a full on image. I know that’s just a personal approach, but I was wondering if anyone else was seeing this.
And quick, for the users using the binary from HashiCorp again, do not go messing with your repo. If you run into stack to deep or whatever the ruby circular gem problem was, in relation to vagrant, it’s quickly fixed by just installing the .deb ontop of itself. It doesn’t mess with any running instances and the issue is open for them, hopefully they’ll close it sooner than later. (I didn’t file the issue with them, plenty of debian rolling already have)
My build there was always latest packages from repo (vagrant, virtualbox, puppet? I don’t recall grabbing puppet, but I know it may be related and it’s installed). Historically, I always had access to VMWare licenses, so I come from that kind of background and I’m not big on Oracle, so I’m fairly new to virtualbox itself. The only change I’ve made is masking the repo’s vagrant and using their binary .deb … it seems to break any time I see a bunch of ruby patches come through the repo, then I reinstall it and then apt wants me to autoremove a bunch of ruby libraries or downgrade vagrant, which I don’t do, I just mask vagrant.
I feel like they’re not playing well with gems, since their departure from that method of installation. However, I did not use it back then.
Honestly, it may come down to me just sucking at ruby and ruby environments. I’m still not sure rbenv or rmv or whatever and default to the repo. I’ve had less than fun times trying to follow either rbenv’s approach or the other one’s and these days, I just keep as much to the repo and try to laugh it off as like a whole python virtualenv thing. Trying to keep everything in userland, and outside of global.
They only important part or ruby for me is metasploit for ease during client demonstrations and things like that. I honestly am partial to python for my own approach towards interpreters, and maybe that’s lazy or not (I did also cling to perl for too long, maybe it’s time to re-educate myself again). And now, more recently, with vagrant. But, I don’t really need it for anything else, I hardly use the tools that rely on it (whatweb is fast, sure, but I’m not trying to “hack the planet”), the list goes on of useful tools in ruby, I’m not trying to bash them, but I generally stick to my comfort zone for all the obvious reasons. Plus, python is buried in a bunch of good stuff (package management for distros, etc…).
Just kind of asking, because I can tame pip/python and I’m not all that familiar with ruby… other than “getting it”, but again, my attempts to follow “best practices” (lol, okay, I’ll drink) for ruby environments usually end up in some kind of mess eventually. Particularly now with Vagrant (and that may be because I tend to prioritize msf, I will seek and destroy any errors msf runs into with no mercy to other packages’ dependence, as that’s what client’s see, however my virtual lab is just as important to my further growth and keeping up with the times, particularly my temporary images).
If the official stance is go back to the repo because we’re rolling, I can do that and if I run back into the issue I was having again, see if it’s financially feasible to thumb through it with someone and resolve it.