I am new to CHEF provisioning. These are steps, I am following to spin-up VMs on Vagrant.
Step 1: Cloned the Git code (https://github.com/chef/chef-provisioning.git)
Step 2: gem install chef-provisioning chef-provisioning-vagrant
Step 3: export CHEF_DRIVER=vagrant
Step 4: export VAGRANT_DEFAULT_PROVIDER=virtualbox
Step 5: chef-client -z vagrant_linux.rb simple.rb
I am not able to figure out the error.
Error executing action converge on resource 'machine[Makeitpossible]'
STDERR:The HGFS kernel module was not found on the running virtual machine.
This must be installed for shared folders to work properly. Please
install the VMware tools within the guest and try again. Note that
the VMware tools installation will succeed even if HGFS fails
to properly install. Carefully read the output of the VMware tools
installation to verify the HGFS kernel modules were installed properly.
vagrant_linux.rb:
require 'chef/provisioning/vagrant_driver'
vagrant_box 'sles11sp3.box' do
url 'https://jenkins-hzn.eng.vmware.com/tools/vagrant/sles11sp3.box'
end
with_driver 'vagrant'
with_machine_options :vagrant_options => {
'vm.box' => 'sles11sp3.box'
}
Simple.rb
require 'chef/provisioning'
machine 'Makeitpossible' do
tag 'itsa_me'
converge true
end
Related
I have vagrant : Vagrant 1.7.4, and a devbox cookbook, when I do vagrant up is showing me a compile error :
Recipe Compile Error in /var/chef/cache/cookbooks/couchbase/libraries/helper.rb cannot load such file -- chef/rest .
With same setup, same cookbook is working for all other machines.
full logs : https://s3-eu-west-1.amazonaws.com/uploads-eu.hipchat.com/102620/3335846/qsb5ZamnZGZ7Rdf/log.txt
Can some help?
Thank you
Check if you're using the Chef 13 pre release that went up today. If so, that file is indeed removed and the cookbook needs to be updated. The official Chef 13 release will be on Monday and it will take some time for even a reasonable number of cookbooks to port to it.
From the docs it seems like using Serverspec to verify that packages are installed should be pretty straight-forward, but I'm having some interesting problems with vim and ag (the_silver_searcher).
I am using Test Kitchen with the kitchen-vagrant plugin and have two platforms: ubuntu-1404 and centos-72. All of my specs pass for Ubuntu, and two of them fail for Centos: vim and ag.
vim
The Chef code that handles this installation is super simple:
package "vim"
And here is the spec:
describe "Vim" do
describe package("vim") do
it { should be_installed }
end
end
Again, very straight-forward. However, it fails on my Centos build with this error:
2) Vim Package "vim" should be installed
Failure/Error: it { should be_installed }
expected Package "vim" to be installed
/bin/sh -c rpm\ -q\ vim
package vim is not installed
Yet if I login to the server, it most definitely is installed:
▶ kitchen login all-centos-72
Last login: Sat Jul 2 17:53:30 2016 from 10.0.2.2
[vagrant#all-centos-72 ~]$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jun 10 2014 06:55:55)
[vagrant#all-centos-72 ~]$ which vim
/usr/bin/vim
[vagrant#all-centos-72 ~]$ sudo yum install -y vim
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: distro.ibiblio.org
* extras: mirror.us.leaseweb.net
* updates: mirror.eboundhost.com
Package 2:vim-enhanced-7.4.160-1.el7.x86_64 already installed and latest version
Nothing to do
ag
ag is more complicated in that the installation requires building from source on Centos whereas on Ubuntu it's available with apt-get. Here is the relevant part of the recipe:
bash "install Development Tools" do
code "yum -y groupinstall \"Development Tools\""
end
package %w(pcre-devel xz-devel)
target_dir = File.join("/", "usr", "local", "the_silver_searcher")
git "clone the ag repo" do
repo "https://github.com/ggreer/the_silver_searcher/"
revision "master"
destination target_dir
end
bash "install ag" do
not_if system("hash ag")
cwd target_dir
code <<-EOF
./build.sh
make install
EOF
end
And here is the spec:
describe "The Silver Searcher" do
if host_inventory["platform"] == "ubuntu"
describe package("silversearcher-ag") do
it { should be_installed }
end
else
describe package("the_silver_searcher") do
it { should be_installed }
end
end
end
The Centos failure:
1) The Silver Searcher Package "the_silver_searcher" should be installed
Failure/Error: it { should be_installed }
expected Package "the_silver_searcher" to be installed
/bin/sh -c rpm\ -q\ the_silver_searcher
package the_silver_searcher is not installed
Likewise, if I log into the Centos VM I can use ag:
[vagrant#all-centos-72 ~]$ ag --version
ag version 0.32.0
[vagrant#all-centos-72 ~]$ which ag
/usr/local/bin/ag
These commands also work if I switch to root user.
I've tried to cheat the system by writing my specs in different ways for the Centos platform:
describe command("ag") do
its(:stderr) { should match /Usage: ag/ }
end
The above also doesn't work, even though typing ag when logged in (exit status 1) does produce that usage content. My last attempt was:
describe file("/usr/local/bin/ag") do
it { should exist }
end
This works but feels super hacky and like it shouldn't be necessary.
Anyone have recommendations here? Is there something I'm missing/doing wrong with these packages? I initially thought that the ag problem was only because it was installed from source rather than a package manager, but vim was installed with a package manager and still has the same problem as ag.
The answer to the question has two parts, one dealing with the way Serverspec works and the other with how various Linux distributions handle packages.
1) Serverspec users shouldn't assume any behavior that isn't literally implied by the name of the package resource. Applications that are installed by any means other than the system's package manager will not be picked up and their successful installation should be tested by other means. This could include, as in the question, testing for the existence of a binary file.
2) When the developer has installed an application with a package manager, he/she must be aware that package managers on different Linux distributions sometimes (often?) have different names for the same package. A classic example of this is apache2 on Debian systems vs. httpd on RedHat systems. In the specific case mentioned in the question, vim is recognized on CentOS as vim-enhanced even though yum accepts vim as the name when installing it (thanks to #matt-schuchard for pointing out that they are linked).
Also wanted to credit #Karen B for helping me reach these conclusions in the comments to the question.
You aren't installing ag via a package so it's not a "hack" for that to not work.
So I have a vagrant / puppet setup for my project* and am running Ubuntu 14.04 on it. It just broke, without changing anything. puppet module install puppetlabs-apt inside the VM fails with the following lines:
Error: Could not execute operation for 'puppetlabs/apt'
The server being queried was https://forge.puppetlabs.com
The HTTP response we received was '302 Found'
Check the author and module names are correct.
I'm using this module for quite some time and it seems like it just stopped working for no reason. Any advice appreciated.
-- Edit: answer question
running it with --debug doesn't help much I guess
Notice: Preparing to install into /home/vagrant/.puppet/modules ...
Notice: Created target directory /home/vagrant/.puppet/modules
Notice: Downloading from https://forge.puppetlabs.com ...
Error: Could not execute operation for 'puppetlabs/apt'
The server being queried was https://forge.puppetlabs.com
The HTTP response we received was '302 Found'
Check the author and module names are correct.
*Link: https://github.com/dwalldorf/owTracker
vagrant up / vagrant ssh and puppet module install puppetlabs-apt
This should be fixed. You can check FORGE-327 for more information
https://forge.puppetlabs.com/puppetlabs/apt redirect to https://forge.puppet.com/puppetlabs/apt
you can force it to use the correct forge by appending --module_repository https://forge.puppet.com/ so it will become
puppet module install puppetlabs-apt --module_repository https://forge.puppet.com/
not sure exactly why it wants to download from https://forge.puppetlabs.com at first place, you could check your puppet.conf
I have a vagrant and virtual box configuration and I tried installing postfix using puphet but I can't proceed because I always encounter this error when I run vagrant up or vagrant provision
Info: Loading facts in /etc/puppet/modules/rabbitmq/lib/facter/rabbitmq_erlang_cookie.rb
Warning: Could not retrieve fact fqdn
Error: The postfix module does not support the Debian family of operating systems. on node teaser-site-mgr
Error: The postfix module does not support the Debian family of operating systems. on node teaser-site-mgr
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
FACTER_ssh_username='vagrant' puppet apply --verbose --hiera_config /vagrant/puphpet/puppet/hiera.yaml --parser future --manifestdir /tmp/vagrant-puppet/manifests --detailed-exitcodes /tmp/vagrant-puppet/manifests/manifest.pp || [ $? -eq 2 ]
Stdout from the command:
and in my manifest.pp
class {'postfix':
remove_sendmail => false,
myorigin => undef,
relayhost => undef,
relayhost_port => undef,
}
I also added this mod in Puppetfile
mod 'postfix', :git => 'https://github.com/Aethylred/puppet-postfix'
Please help anyone m(_ _)m
#felix-frank --parser future is def. required by PuPHPet. Please don't remove this.
#inferno, the issue is you're trying to use this puppet-postfix module in a Debian OS, when it clearly states it does not support Debian.
Might I suggest https://github.com/example42/puppet-postfix ?
It seems that the error(s) I encountered is also somehow my fault.
Its because the puppet version now in my vagrant is 3.5.x (i created the config months ago) and i didn't noticed that the puphpet.com config has been also updated
and also the required puppet version is just 3.4.x
So when I run vagrant provision, the puppet version is updated to latest version which is 3.5.x (because of outdated puphpet config) thats why I always encounter the error (and sometimes syntax error)
im just wondering why puppet version 3.0 to 3.5 is now unsupported (but still puphpet.com is using it for vagrant) http://docs.puppetlabs.com/release_notes/
But anyways, thank you very much for your help guys :) I won't notice my mistake without all of your help m(_ _)m
I'm trying to create a development environment using Vagrant which depends on certain applications running inside of Docker containers.
The required environment is Ubuntu 12.04 LTS, which maps out to be the precise64 box in Vagrant. The problem is ensuring the following:
The Saucy LTS kernel is installed.
The Saucy LTS kernel is running.
I'm trying to provision the box using Puppet and I can't figure out a way to ensure that the following commands are executed:
apt-get install linux-image-generic-lts-saucy linux-headers-generic-lts-saucy
reboot
I'll obviously need to reboot the box for it to load and run the new kernel.
Is there a way I can define these items as dependencies in Puppet?
I'm looking to do something like this:
package { "lxc-docker":
/* ... */
requires => Package["lts-kernel-saucy"]
}
Any ideas on how I can accomplish this?
If apt-get is the package manager puppet is using, then you can try the following :
# Create an array of package names that need to be installed
$mypack = [ "linux-image-generic-lts-saucy", "linux-header-generic-lts-saucy", "lts-kernel-saucy" ]
# Install all the packages
package { $mypack :
ensure => installed,
}
# Install other package that depends on the packages above :
package { "lxc-docker" :
ensure => installed,
requires => Package[$mypack],
}
# Create an `exec` that will reboot the machine if a new package is installed
# `refreshonly` sits there waiting for something new to happen
exec { "reboot_machine" :
command => "shutdown -r now",
path => "/bin:/usr/sbin:/sbin:/usr/local/sbin",
subscribe => Package ["lxc-docker"],
refreshonly => true,
}
The best and easiest solution here is to use a Vagrant box which supports Docker by running the right kernel.