I try to only deploy fail2ban Apache jails if apache is actually installed. I have a fact for that that works.
# fail2ban
$jails = [
'ssh', 'ssh-ddos',
'pam-generic'
] + if $f2b_enable_apache { ['apache-auth', 'apache-badbots', 'apache-multiport', 'apache-noscript', 'apache-overflows'] }
notify{"Enable apache jails: ${f2b_enable_apache}":}
notify{"Jails: ${jails}":}
class { 'fail2ban':
package_ensure => 'latest',
jails => $jails
}
When I run it though, then I get the follwing output
Without apache:
Puppet : Enable apache jails: false
Puppet : Jails: [ssh, ssh-ddos, pam-generic, apache-auth, apache-badbots, apache-multiport, apache-noscript, apache-overflows]
With apache:
Puppet : Enable apache jails: true
Puppet : Jails: [ssh, ssh-ddos, pam-generic, apache-auth, apache-badbots, apache-multiport, apache-noscript, apache-overflows]
What am I doing wrong? Why is it in both cases appended? Is there a better way to achieve this that is extensible?
I would likely use a selector expression for this:
$jails = $f2b_enable_apache ? {
true => ['ssh', 'ssh-ddos', 'pam-generic', 'apache-auth', 'apache-badbots', 'apache-multiport', 'apache-noscript', 'apache-overflows'],
false => ['ssh', 'ssh-ddos', 'pam-generic'],
}
There are indeed algorithms for using Array[String] concatenation here, but they become messy due to Puppet DSL enforcing the immutability of variables. This uses one variable, one conditional expression, and no lambda iterator functions.
Related
I have a basic puppet install using this tutorial https://www.digitalocean.com/community/tutorials/how-to-install-puppet-4-on-ubuntu-16-04
When I run /opt/puppetlabs/bin/puppet agent --test on my node I get
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Error while evaluating a Resource Statement. Could not find declared class firewall at /etc/puppetlabs/code/environments/production/manifests/site.pp:7:1 on node mark-inspiron.
On my node:
/opt/puppetlabs/bin/puppet module list
returns
/etc/puppetlabs/code/environment/production/modules
----- puppetlabs-firewall (v1.9.0)
On my puppet master at /etc/puppetlabs/code/environments/production/manifests/site.pp:
file {'/tmp/it_works.txt': # resource type file and filename
ensure => present, # make sure it exists
mode => '0644', # file permissions
content => "It works on ${ipaddress_eth0}!\n", # Print the eth0 IP fact
}
class { 'firewall': }
resources { 'firewall':
purge => true,
}
firewall { "051 asterisk-set-rate-limit-register":
string => "REGISTER sip:",
string_algo => "bm",
dport => '5060',
proto => 'udp',
recent => 'set',
rname => 'VOIPREGISTER',
rsource => 'true';
}
firewall { "052 asterisk-drop-rate-limit-register":
string => "REGISTER sip:",
string_algo => "bm",
dport => '5060',
proto => 'udp',
action => 'drop',
recent => 'update',
rseconds => '600',
rhitcount => '5',
rname => 'VOIPREGISTER',
rsource => true,
rttl => true;
}
The file part works but not firewall.
You need to install the modules on your master in a master setup with Puppet. They need to be somewhere in your modulepath. You can either place it in the modules directory within your $codedir (normally /etc/puppetlabs/code/modules) or in your directory environment modules directory (likely /etc/puppetlabs/code/environments/production/modules in your case since your cited site.pp is there). If you defined additional module paths in your environment.conf, then you can also place the modules there.
You can install/deploy them with a variety of methods, such as librarian-puppet, r10k, or code-manager (in Enterprise). However, the easiest method for you would be puppet module install puppetlabs-firewall on the master. Your Puppet catalog will then find the firewall class during compilation.
On a side note, that:
resources { 'firewall':
purge => true,
}
will remove any changes to associated firewall configurations (as defined by Puppet's knowledge of the system firewall configuration according to the module's definition of what the resource manages) that are not managed by Puppet. This is nice for eliminating local changes that people make, but it can also have interesting side effects, so be careful.
I'm new to puppet. I know that cassandra is missing from yum so I figured a puppet recipe would download and install it, but it seems like locp/cassandra is just trying to install it from yum. The recipe is supposed to work, but I don't see anything on https://github.com/locp/cassandra as to why it's not working for me or any thing I need to set up before it should work.
I used librarian-puppet to install the modules in puppet/modules.
Error
==> default: Notice: /Stage[main]/Cassandra/File[/var/lib/cassandra/data]: Dependency Package[dsc22] has failures: true
Vagrantfile
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = "puphpet/centos65-x64"
config.vm.provision "puppet" do |p|
p.module_path = "puppet/modules"
p.manifests_path = "puppet/manifests"
p.manifest_file = "site.pp"
end
end
puppet/manifests/site.pp
class { 'cassandra':
cluster_name => 'foobar',
listen_address => "${::ipaddress}",
}
puppet/Puppetfile
forge 'https://forgeapi.puppetlabs.com'
mod "locp/cassandra"
You could also use the cassandra::datastax_repo class. To incorporate that into the answer provided by #Frédéric-Henri, one could do the following:
class { 'cassandra::datastax_repo': } ->
class { 'cassandra':
cluster_name => 'foobar',
listen_address => "${::ipaddress}"
}
Thats probably because the repo is not configured (see here)
Add the following to your site.pp and make sure to add a require on it in your cassandra class
class repo {
yumrepo { "datastax":
descr => "DataStax Repo for Apache Cassandra",
baseurl => "http://rpm.datastax.com/community",
gpgcheck => "0",
enabled => "1";
}
}
class { 'cassandra':
cluster_name => 'foobar',
listen_address => "${::ipaddress}",
require => Yumrepo["datastax"],
}
include repo
include cassandra
I am using elastic search 1.7.1 and when i am trying to use script_score or script_fields it is showing the error ScriptException[scripts of type inline], operation [search] and lang [groovy] is disabled can anyone please tell me how can i remove this error. my code is given below
function_score: {
query: {
query_string: {
query: shop_search,
fields: [ 'shop_name']
}
},
functions: [
{
script_score: {
script: "_score * doc['location'].value"
}
}
]
}
Add script.engine.groovy.inline.search: on to elasticsearch.yml configuration file and restart the node.
adding script.groovy.sandbox.enabled: true to .yml works for me
For ES Version 2.x+
script.inline: on
script.indexed: on
Add
script.engine.groovy.inline.aggs: on
script.engine.groovy.inline.update: on
to elasticsearch.yml
and restart
For those with ES 2.x+
script.inline: true
script.indexed: true
Make sure you prefix the lines with a space!
Which is better for Puppet 3.7 or newer ?
1- Hiera with Yaml definition as
ubuntu.yaml:
---
classes:
- google-chrome
- xcode
2- Base node definition as
node.pp:
node "ubuntu" {
include google-chrome
include xcode
}
I think you misunderstand purpose of using hiera. According to documentation:
Hiera is a key/value lookup tool for configuration data, built to make Puppet better and let you set node-specific data without repeating yourself.
Hiera gives you a versatile way to deliver configuration parameters. So in my opinion "2- Base node definition", with hiera as configuration provider is proper way of using puppet with hiera.
E.g: instead of definig:
node node1 {
class { 'some_class_1' :
param_1 => value1,
param_2 => value2,
}
class { 'some_class_2' :
param_1 => value3,
param_2 => value4,
}
}
node node2 {
class { 'some_class_1' :
param_1 => value11,
param_2 => value22,
}
class { 'some_class_2' :
param_1 => value33,
param_2 => value44,
}
}
Use hiera as configuration provider. In puppet define only:
node some_regexp { #or just provide node names
include some_class_1
include some_class_2
}
than define proper hiera files:
node1.yaml
some_class_1::param_1: value1
some_class_1::param_2: value2
some_class_2::param_1: value3
some_class_2::param_2: value4
node2.yaml
some_class_1::param_1: value11
some_class_1::param_2: value22
some_class_2::param_1: value33
some_class_2::param_2: value44
With the logstash 1.2.1 one can now have conditional to do various stuff. Even the earlier version's conf file can get complicated if one is managing many log files and implement metric extraction.
After looking at this comprehensive example, I really wondered my self, how can I detect any breakages in this configuration?
Any ideas.
For a syntax check, there is --configtest:
java -jar logstash.jar agent --configtest --config <yourconfigfile>
To test the logic of the configuration you can write rspec tests. This is an example rspec file to test a haproxy log filter:
require "test_utils"
describe "haproxy logs" do
extend LogStash::RSpec
config <<-CONFIG
filter {
grok {
type => "haproxy"
add_tag => [ "HTTP_REQUEST" ]
pattern => "%{HAPROXYHTTP}"
}
date {
type => 'haproxy'
match => [ 'accept_date', 'dd/MMM/yyyy:HH:mm:ss.SSS' ]
}
}
CONFIG
sample({'#message' => '<150>Oct 8 08:46:47 syslog.host.net haproxy[13262]: 10.0.1.2:44799 [08/Oct/2013:08:46:44.256] frontend-name backend-name/server.host.net 0/0/0/1/2 404 1147 - - ---- 0/0/0/0/0 0/0 {client.host.net||||Apache-HttpClient/4.1.2 (java 1. 5)} {text/html;charset=utf-8|||} "GET /app/status HTTP/1.1"',
'#source_host' => '127.0.0.1',
'#type' => 'haproxy',
'#source' => 'tcp://127.0.0.1:60207/',
}) do
insist { subject["#fields"]["backend_name"] } == [ "backend-name" ]
insist { subject["#fields"]["http_request"] } == [ "/app/status" ]
insist { subject["tags"].include?("HTTP_REQUEST") }
insist { subject["#timestamp"] } == "2013-10-08T06:46:44.256Z"
reject { subject["#timestamp"] } == "2013-10-08T06:46:47Z"
end
end
This will, based on a given filter configuration, run input samples and test if the expected output is produced.
To run the test, save the test as haproxy_spec.rb and run `logstash rspec:
java -jar logstash.jar rspec haproxy_spec.rb
There are lots of spec examples in the Logstash source repository.
since logstash has been upgraded and now the command will be something like (give the folder)
/opt/logstash/bin/logstash agent --configtest -f /etc/logstash/logstash-indexer/conf.d
If you see some warning, but the error message is mixed together, and you didn't know which one have issue. You have to check its file one by one