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
Related
OS : 'CentOS 6.5
'
ElasticSearch version : '2.3.0'
Master's puppet version: '3.8.7'
Client's puppet version : '3.7.4'
Base module version before upgrade : '0.10.2'
Base module version after upgrade : '5.1.0'
Error: could not retrieve catalog from remote server: Error 400 on
SERVER: invalid parameter elasticsearch_package_name on
Elasticsearch_plugin[license] at
/etc/puppet/environments/production/modules/elasticsearch/manifests/plugin.pp:169
on node bla-test01.dom'
Hi,
This error started after we upgraded our Elasticsearch's base (Official from puppet forge) module from version '0.10.2' to '5.1.0'. Our puppet module of elasticsearch worked just fine before the upgrade.
Since the upgrade this error occurred whenever puppet ran on our nodes.
After we saw this case we tried to restart our puppetserver service. Since the restart, the error occurs once every 3-4 runs of puppet and we have no idea why.
Looking at the elastic/elasticsearch module which is the one you seem to be using i can see that the elastic_plugin custom type did not have the elasticsearch_package_name parameter in version 0.11.0 however the 5.1.0 version does. This looks to me that you may have updated the module on the system but have not restarted the puppet server so it still has the 0.11.0 custom type/provider ruby files loaded.
Restart the puppet master server and see if that fixes the issue
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 am unable to run
ansible-playbook openshift-ansible/playbooks/byo/config.yml
as I get various errors depending on the verison of ansible used. On various 1.9.x versions, the error is
ERROR: fail is not a legal parameter in an Ansible task or handler
and on 2.0.0:
ERROR! 'vars_files' is not a valid attribute for a PlaybookInclude
The error appears to have been in '/home/ansible/openshift-ansible/playbooks/byo/openshift-cluster/config.yml': line 2, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
---
- include: ../../common/openshift-cluster/config.yml
^ here
I have seen this error reported on github, with the 1.9 solution supposedly addressed by moving to 2.0, and the 2.0 error mentioned as being fixed with a 1.9 downgrade, but cannot find a set up in which it actually does work and would appreciate some tip as this seems like one of those steps that should go easily.
This is on RHEL 7 with docker version:
[root#mtl-vm374 ansible]# docker --version
Docker version 1.8.2-el7.centos, build a01dc02/1.8.2
Thanks in advance!
After trying a few 1.9.4 Ansible versions, I finally found an install that works:
http://dl.fedoraproject.org/pub/epel/7/x86_64/a/ansible1.9-1.9.4-2.el7.noarch.rpm
--John
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.