Is there a programmatic way to get the version of the locally installed Vagrant without using the terminal commands? (ie. Not parsing the answer from the output of `vagrant -v`)
As Vagrant is no longer served as RubyGem now (from v1.1), you'll need a new gem called vagrant-wrapper.
It's a Ruby wrapper around New Vagrant installations. You can control vagrant with it from Ruby.
For version this:
require 'vagrant-wrapper'
VagrantWrapper.new.vagrant_version
Related
I am having a problem after I installed vagrant on Windows Linux Subsytem.
I know that vagrant is installed because I checked vagrant -v.
Vagrant 2.2.7
But every command I give from vagrant it executes the same error.
/opt/vagrant/embedded/gems/2.2.7/gems/vagrant-2.2.7/lib/vagrant/util/which.rb:37: warning: Insecure world writable dir /home/tiedmud/.rvm/gems/ruby-2.5.1 in PATH, mode 040777
/opt/vagrant/embedded/gems/2.2.7/gems/vagrant-2.2.7/lib/vagrant/environment.rb:1059:in `chmod': Operation not permitted # chmod_internal - /mnt/c/Users/ricar/.vagrant.d/insecure_private_key (Errno::EPERM)
from /opt/vagrant/embedded/gems/2.2.7/gems/vagrant-2.2.7/lib/vagrant/environment.rb:1059:in `chmod'
from /opt/vagrant/embedded/gems/2.2.7/gems/vagrant-2.2.7/lib/vagrant/environment.rb:1059:in `copy_insecure_private_key'
from /opt/vagrant/embedded/gems/2.2.7/gems/vagrant-2.2.7/lib/vagrant/environment.rb:166:in `initialize'
from /opt/vagrant/embedded/gems/2.2.7/gems/vagrant-2.2.7/bin/vagrant:154:in `new'
from /opt/vagrant/embedded/gems/2.2.7/gems/vagrant-2.2.7/bin/vagrant:154:in `<main>'
Can someone help me?
I think you upgraded Vagrant from 1.0 to higher version.Please remove old version and reinstall.
RubyGemmethod is gone.
Installing Vagrant
Installing Vagrant is extremely easy. Head over to the Vagrant downloads page and get the appropriate installer or package for your platform. Install the package using standard procedures for your operating system.
The installer will automatically add vagrant to your system path so that it is available in terminals. If it is not found, please try logging out and logging back in to your system (this is particularly necessary sometimes for Windows).
`Looking for the gem install? Vagrant 1.0.x had the option to be installed as a RubyGem. This installation method is no longer supported. If you have an old version of Vagrant installed via Rubygems, please remove it prior to installing newer versions of Vagrant.
Use this login as root on safe mode
I have a running puppet server and want to do following steps on the puppet agent:
download rbenv from git server to /usr/local/rbenv (success)
download ruby-build from git server (success)
create file rbenv.sh in /etc/profile.d, so that on every login then rbenv-environment ist loaded (success)
install a specific ruby version using an exec-resource with rbenv install (success)
activate the specific ruby version using an exec-resource with rbenv global (fail for current login)
install a specific ruby gem (failed because of ruby version dependency)
The problem is, rbenv started from an exec-resource in puppet switches the ruby version in a subshell, and stores that information somewhere. The ruby version for the current shell, where I startet puppet agent --test is not changed. After logging out and in again, the puppet run is successful, because the environment is successfully loaded again.
So my question is: Is there a possibility to run the package provider in a new subshell? Or do I have to use another exec running gem install?
So my question is: Is there a possibility to run the package provider in a new subshell? Or do I have to use another exec running gem install?
No. Providers run in the host Ruby instance. They may launch external commands, including shells, but they themselves are not run that way.
Furthermore, you said,
After logging out and in again, the puppet run is successful, because
the environment is successfully loaded again.
If it really requires logging out and back in to make the rbenv reconfiguration active (which is unclear), then running the provider in a subshell wouldn't be effective anyway. Neither would running gem install via an Exec, unless that Exec also expressly activated the desired Ruby environment.
If you are using Puppet to swap out the system's default Ruby, out from under itself, then you need to be prepared for inconsistent behavior. You may be able to work around it by employing an appropriate Exec to perform the gem installation.
I had this same problem and wrestled for a solution. I wanted my servers to provision successfully from scratch so running provision twice wasn't going to cut it.
I fixed this by adding a symlink to the shim'ed gem. Puppet looks for the gem provider there.
This worked for me...
include rbenv
rbenv::plugin {'rbenv/ruby-build':}
-> rbenv::build { '2.5.3':
global => true,
}
-> file { '/usr/bin/gem':
ensure => link,
target => '/usr/local/rbenv/shims/gem',
}
-> package {'passenger':
ensure => '6.0.1',
provider => gem,
}
Our organization has not upgraded to Chef 13 or 14, so we have to pin all our cookbooks to version 12. This means pinning to chef-dk version 1.6.11.
I'm spinning a centos7 vm in Vagrant with a cookbook and have set the version, but it will only install the Latest of chefdk, which results in the machine getting Chef 14. I've added a dependency in metadata.rb of chef_version ~> 12, so the provision fails, as Chef 14 is installed but the cookbook demands 12.
I should mention that the VM is for cookbook dev, so i want the right version of chef on it.
What am i missing to get the right version installed?
Thanks.
recipes/default.rb:
node.default['chef_dk']['version'] = '1.6.11'
node.default['chef_dk']['global_shell_init'] = true
include_recipe 'chef-dk'
metadata.rb:
depends 'chef-dk'
chef_version '~> 12.0'
berksfile:
cookbook 'chef-dk'
The part that is failing is the "outer" Chef, the thing running the recipe, not the ChefDK install (it never gets that far). We don't generally recommend using Chef to install ChefDK because installing both the chef-client and ChefDK installers on the same machine can lead to confusion as there are overlapping command line tools. I would provision the dev VM using a simpler system, probably a bash script or similar. We also do provide chef/chefdk Docker images on Hub for this kind of thing. (also we don't recommend doing cookbook development inside a VM at all, but I would guess that ship has sailed for you)
I am using the trusty64 vagrant box and I provision it using puppet.
I just noticed today that ruby and chef are installed and I don't use either of them for my VM work.
Do I need them there for Vagrant to do its magic?
Can I remove them after my VM is provisioned or will vagrant halt and vagrant up stop working?
so to the question
Do I Need Ruby and Chef On My Vagrant Box
Its mainly up to you.
no, more seriously:
Ruby comes install with Linux distro, generally some older version but its a fact that it is delivered (as python, perl ...) so you should leave it. It is not doing any harm and some other tools (including chef and puppet) relies on Ruby to be installed so if you provision with puppet you must leave ruby
Vagrant does not rely on ruby to be installed on the guest to do its magic, its mainly issuing ssh script command to do the update on network/hostname ...
trustry64 box is an official box from hashicorp (the company behind vagrant) and vagrant does support out of the box chef and puppet provisioning those tools are installed. Again they don't make any harm even if you're not using it.
The thing is that your box will have ruby and chef installed and whenever you boot a new VM from this box, it will contain ruby and chef, I think you will spend more time cleaning the booted VM at the end of the day, specially if you have to destroy/rebuild the VM.
If you want a minimalist box that contains only the thing you need, you can look at packer - packer is a tool to automate the creation of vagrant box, so you can really control what is install from the iso file of the OS to the libraries and 3rd party tools.
Vagrant does rely on ruby installed in the box if you are using chef or puppet provisioner. chef/puppet runs happen inside the guest box which vagrant orchestrates using ssh.
You can remove chef when you will use chef provisioner,vagrant will download and install it again but you would need ruby for puppet.
See puppet install dependency here
Running the otherwise working command:
jekyll serve --watch
inside Vagrant is not leading to regeneration of the files unless I restart the jekyll server. I am editing on Windows. Is this a problem with Jekyll running inside Vagrant or is there some configuration that I need to do to make this work? I even tried using foreman with the following Procfile configuration but with the same result
web: jekyll serve --watch
It's implemented in the latest pre release (jekyll 2.0.0.alpha.3 by the time of writing).
You should use --force_polling option to get benefit of it.
Try running the jekyll server like this:
jekyll serve --watch --force_polling
My guess, based on nothing more than my own experience of this issue is that you are running your jekyll site in the /vagrant folder which vagrant maps/syncs back to the host os.
These mapped or synchronised folders are using some kind of crazy filesystem driver (basically a type of network share) and the file watch features don't work on them.
This SO question shows the same symptom.
(You will see what I mean of you run your jekyll site outside `/vagrant' like in the home folder. Make a change (using nano) and you will see the Regeneration triggering)
What provider are you using? I was able to get it to work on Windows 8 using Virtual Box as a provider and Ubuntu 12.04 as a guest OS. I had to use version 1.2.1 and not the latest version however.
When I use the latest Jekyll version (1.4.2), watch does not work as expected (it doesn't notice the file change and does not rebuild). It does work when I edit them on the guest OS though (it does notice the file change and will rebuild).
Version 1.2.1 works regardless of where the files are edited from (Guest OS or Host OS).
To revert back to version 1.2.1 I ran the following commands:
gem uninstall jekyll
gem install jekyll -v 1.2.1
Note: The jekyll site is running from the vagrant directory
In vagrant, just add --force_polling, then jekyll will watch almost all files except "_config.yml"
jekyll serve --force_polling
When you change the other files except for "_config.yml", you will see the regeneration.
But if you are changing "_config.yml" it will not trigger the regeneration.
Are you excepting the regeneration when you are changing "_config.yml"?
My guess (without knowing the details) is that you need to be running headless, as in:
jekyll serve -w --detach
as mentioned in the jekyll documentation. If it's not that, then describe the issue in more detail, as I asked about in the comment. Also, are you using any type of provisioner in Vagrant, e.g. shell, chef, ansible, etc.?