Re: [Puppet Users] Austin Puppet User's meetup

[Wolf Noble]

I'd enjoy coming to this. Please keep me posted as things develop.

Thanks Dan!

MobileMail

On Feb 7, 2012, at 7:05 PM, "Dan Bode" 
mailto:d...@puppetlabs.com>> wrote:

Hi Austin Puppet Users,

I will be in the area in a few weeks and I would like to try to get some of the 
local users together to talk Puppet and have a few beers.

Curious about how much interest there would be for an event on the 23rd of 
February (location tbd).

regards,

Dan Bode

--
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to 
puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Mac users: Textbucket scripts for puppet types

[Wolf Noble]

Hi Gang,

If you're a mac user and haven't heard of text bucket, but find yourself typing 
the same things semi-often.. you might want to check it out.
http://bassetsoftware.com/b.cgi/textbucket/index

I started using it about 9 months ago when someone showed me klypper on linux 
and I went searching for something similar… Anyways, where was I?

oh yeah right:
I've cobbled together some ruby scripts to help make creating the 10 core 
puppet types a little easier..

cron
exec
file
group
host
mount
package
service
tidy
user

you can find them here, along with a stub text bucket storedata file:
 https://github.com/wolfspyre/textbucket-puppet

the storedata file lives in ~/Library/Application Support/Text_Bucket/storedata

the application reads the file at load time, and saves it blindly when you quit 
the program, so make sure that if you play with the file you do so when the 
program isn't running, lest your changes be lost.


I'll continue to hack on them as I get time/need and post updates to github. 
They're FAR from perfect (or even good?) right now. There are plenty of 
formatting issues. I'd be willing to bet there's even a few typos or incorrect 
attributes listed. I finished the user script last night and so I figured I'd 
share sooner than later in case it makes someone else's life easier.


W




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] mixing source & content (templates) in concat::fragment

[Wolf Noble]

I've been using this, which works pretty well for a template selector:

  file { "foo":
content => inline_template(
  file(
"/literal/path/to/template/on/puppetmaster/$hostname.erb",
"/literal/path/to/template/on/puppetmaster/$devicename.erb",
"/literal/path/to/template/on/puppetmaster/$clientname.erb",
"/literal/path/to/template/on/puppetmaster/motd.erb"
  )),
  ...
}

On May 2, 2012, at 8:00 PM, Tim Mooney wrote:

>
> All-
>
> We're using puppet 2.7.11.
>
> Our custom firewall module currently builds the RHEL
> /etc/sysconfig/iptables (and ip6tables) from multiple fragments using
> concat::fragment.
>
> The base part of the firewall is constructed like this:
>
> class firewall {
>  include concat::setup
>
>  $firewall_config  = '/etc/sysconfig/iptables'
>
>  concat::fragment { "firewall-base":
>target => "$firewall_config",
>source => [
>  "puppet:///modules/firewall/firewall-base.$fqdn",
>  "puppet:///modules/firewall/firewall-base"
>],
>order => '01',
>  }
>
>  concat::fragment {"firewall-end":
>target  => "$firewall_config",
>content => "COMMIT\n",
>order   => '99',
>  }
> }
>
>
> As you can see, we use source to look for a per-box custom firewall base
> first, and then fall back to a stock firewall-base file fragment.
>
> I want to modify this config so that the fall-back fragment comes from
> a template, rather than a file fragment.  The problem is that it appears
> I can't do this:
>
>  concat::fragment { "firewall-base":
>target => "$firewall_config",
>source => [
>  "puppet:///modules/firewall/firewall-base.$fqdn",
>  template('firewall/firewall-base.erb'),
>],
>order => '01',
>  }
>
> When I try that, I get:
>
> $sudo puppet agent --test --noop
> info: Retrieving plugin
> info: Loading facts in /var/lib/puppet/lib/facter/ipmi_product.rb
> info: Loading facts in /var/lib/puppet/lib/facter/biosversion.rb
> info: Loading facts in /var/lib/puppet/lib/facter/net_info.rb
> info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> info: Loading facts in /var/lib/puppet/lib/facter/net_location.rb
> info: Loading facts in /var/lib/puppet/lib/facter/pacemaker.rb
> info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> info: Caching catalog for host.nodak.edu
> err: Failed to apply catalog: Parameter source failed: Could not understand 
> source #
>
>
> and then it spits out the file template.
>
> Is there an easy way to mix, in one fragment, a source and a template,
> as I'm trying to do?
>
> It occurs to me that I could just "pretend" that all of our per-host
> firewall-base.$fqdn files are instead templates, even if there's no
> actual templating going on, and use something like:
>
>  concat::fragment { "firewall-base":
>target => "$firewall_config",
>content => [
>  template("firewall/firewall-base.$fqdn.erb"),
>  template('firewall/firewall-base.erb'),
>],
>order => '01',
>  }
>
> But that seems kind of hackish.  Can anyone suggest a more elegant method,
> or some syntax that I'm missing?
>
> Thanks,
>
> Tim
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure  701-231-1076 (Voice)
> Room 242-J6, IACC Building 701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>

Wolf Noble
Senior UNIX Systems administrator
Datapipe Managed IT Services
Tel: 201.792.1918 x2910






This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] how best to combine business data (Hiera) and machine data (Facts)

[Wolf Noble]

Hi Luke,

Would adding fqdn to the bottom of your hierarchy give you the ability to 
override the values on the outliers that you can't automagically set while 
retaining elegance in your class? Or am I missing something?



Wolf Noble
Datapipe Managed IT Services



On May 11, 2012, at 12:45 PM, Jeff wrote:

I have a similar issue with Hiera when decisions depend on more than facts 
alone... thus exluded from the hierarchy.

In example,  the hostname can tell a node is a database server (fact: role) but 
only a custom group will tell it should run Oracle 10g or 11g (product) and the 
proper sysctl to apply specifically.  I can't build a fact about something that 
ain't installed yet and I don't want a local file to define group membership 
(giving up control).   The node to group membership has to be in a CMDB 
somewhere.

So far I think using an ENC with Hiera at the same time is the solution to 
cover all cases unless you guys know of a better way.

jean

On Friday, 11 May 2012 13:19:33 UTC-4, Gary Larizza wrote:
I see (and I saw your post on create_resources - I tested it out and also 
noticed that inheritance didn't work as expected for me either).  My initial 
thought would be to try and break down the individual sysctl entries as 
individual resources that could be declared with a defined type (as Aaron 
mentioned) - then you can use hiera to declare them with create_resources() AS 
WELL as individually declaring additional resources.



On Fri, May 11, 2012 at 9:47 AM, Luke Bigum 
mailto:luke.bi...@lmax.com>> wrote:
Hi Gary,

Not quite... Let me go into more detail.

I'm trying to handle sysctl "perfectly" which is probably my real problem. 
Hiera's ability to merge hashes together makes it perfect for arriving at one 
set of sysctl options for a server based on "business logic" (my hierarchy).  
For Hiera data on 'someserver' below which has 'some_role', calling hiera_hash 
in a Puppet manifest will give me IP forwarding set and rp_filter set, which is 
what I want:

- some_role.json 
{
   "sysctl" : {
  "net.ipv4.ip_forward" : {
 "comment" : "Controls IP packet forwarding",
 "value" : "1"
  }
}

- common.json --
{
   "sysctl" : {
  "net.ipv4.ip_forward" : {
 "comment" : "Controls IP packet forwarding",
 "value" : "0"
  },
  "net.ipv4.conf.default.rp_filter" : {
 "comment" : "Controls source route verification",
 "value" : "1"
  }
  ...
  ...
}
-

Where it becomes difficult is trying to then incorporate pure Fact data to 
influence or modify these decisions.

Lets say that I actually get back 20 keys of sysctl data, one of those is 
'vm.swappiness'. Most of my nodes have a value of '10', but lets say 
hypothetically that I have a small set of nodes that require a different value 
because of the amount of RAM available in the machine (a decision needs to be 
made based on hardware, not business logic). This is purely a Fact. Introducing 
another level of hierarchy for Fact 'memorytotal' is a bit silly in this case.

The sysctl class looks roughly like this:

--- sysctl.pp --
class sysctl {
  $sysctl_hash = hiera_hash('sysctl')
  create_resources('sysctl', $sysctl_hash)
}
--

I love that simplicity, however it's difficult to introduce edge cases that 
modify the data retrieved from Hiera based on Facts. Class inheritance won't 
work because create_resources() seems to insert into the catalog in an 
uninheritable way - bug report or fixable with Ruby DSL perhaps? Filling this 
class full of "if ($fact) modify hash" to munge the data pulled from Hiera 
seems dirty too.

There may be no elegant solution and as you say, 80-90% may have to do.

-Luke


On 11/05/12 16:53, Gary Larizza wrote:
I see this with people looking to move to the hierarchical system that Hiera 
brings.  It essentially boils down to "How do I do this without having a ton of 
hierarchy levels?".  Usually we tend to recommend using the hierarchy to hit 
the 80% mark for the data you need in your modules.  Anything that's 
module-specific-data should then be broken out to a data.pp or params.pp file 
with conditional logic there.  I tend to ask people: "Is this something others 
are going to hit when they try to use the module too?", as in - "Are there path 
differences between operating systems?", or "Are there important changes to the 
data between RHEL 5 and 6?".  If the answer to these is yes, then I tend to 
favor putting that da

[Puppet Users] erb logic with a hiera value

[Wolf Noble]

so I've set a  hiera key, and trying to display some different data in motd 
depending on if the value of said key is true or false… it gets set 
accordingly.. but my motd template doesn't seem to be properly reacting when 
the value of it changes..

it's as if the variable never matches "true"
not sure what I'm doing wrong here…. I SUSPECT 'true' isn't being perceived as 
such somehow…

Can anyone spot what I'm missing?



bash-3.2$ cat /etc/puppetlabs/puppet/modules/core/manifests/values.pp
#
# core::values
# a class for namespaceing variables not specifically linked to any other 
module.
class core::values {
   $foostatus = hiera('core_values_foo')
}



bash-3.2$ cat hieradata/(extraneous tree pruned)/Prod/common.yaml
core_values_foo: - true



bash-3.2$ cat hieradata//common.yaml
core_values_foo: - false


bash-3.2$ cat core/motd/templates/motd.erb
<% foostatus = scope.lookupvar('core::values::foostatus') -%>
## Configuration Notice ##--
The configuration of <%= hostname -%> is managed by Puppet.
### QuickStats from last puppetrun
  RAM: <%= memorysize -%> ::
  <%= lsbdistdescription %>
  Kernel: <%= kernelrelease %>
  Internal IP: <%= ipaddress %>
###
<% if foostatus  == "true"  -%>
 |   foo is true  |
 `'
<% else -%>
 |   foo is not true   |
 `'
<% end-%>
<%= foostatus %>
bash-3.2$



[root@bookworm ~]# cat /etc/motd
## Configuration Notice ##--
The configuration of bookworm is managed by Puppet.
### QuickStats from last puppetrun
  RAM: 512.18 MB ::
  CentOS release 5.8 (Final)
  Kernel: 2.6.18-308.4.1.el5xen
  Internal IP: 123.123.123.123
###
 |   foo is not true   |
 `'
true



if I remove the entry which is setting it to true in 
hieradata/(pruned)Prod/common.yaml:

[root@bookworm ~]# cat /etc/motd
## Configuration Notice ##--
The configuration of bookworm is managed by Puppet.
### QuickStats from last puppetrun
  RAM: 512.18 MB ::
  CentOS release 5.8 (Final)
  Kernel: 2.6.18-308.4.1.el5xen
  Internal IP: 123.123.123.123
###
 |   foo is not true|
 `'
false







This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] erb logic with a hiera value

[Wolf Noble]

Thanks Gary,

I knew it was something simple.

Appreciate the help


<% if foostatus  == "true"  -%>

This is the problem - you're trying to compare a boolean value of true to a 
string value of 'true'.  Just do something like:

<% if foostatus -%>

That should work for you :)



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] "Best" way to relate keys, or stuff multiple values into a single key in hiera?

[Wolf Noble]

So… I'm coming across a situation where I foresee myself having a collection of 
related k/v pairs in hiera. I want to create a thing… lets say a yumrepo for 
example's sake, but this same idea translates to  a vhost, a web app 
configuration , a virtual domain, etc.

lets assume a hierarchy of:

  - %{region}/%{dc}/%{env}/%{function}/%{fqdn}
  - %{region}/%{dc}/%{env}/%{function}/common
  - %{region}/%{dc}/%{env}/common
  - %{region}/%{dc}/common
  - %{region}/common

in the us-east region common yaml file, should I create the following two repos 
values:

repo_descr: eastcoast-pub
repo_baseurl: http://myfoo.com/eastcoastgoodtimes
repo_gpgkey: http://myfoo.com/eastcoastgoodtimes/key
repo_gpgcheck: 1
repo_enabled: 1
repo_enablegroups: 0

repo_descr: eastcoast-internal
repo_baseurl: http://myfoo.com/eastcoast
repo_gpgkey: http://myfoo.com/eastcoast/key
repo_gpgcheck: 1
repo_enabled: 1
repo_enablegroups: 0


in the foo DC common file I have a repo for that datacenter:

repo_descr: foo
repo_baseurl: http://myfoo.com/goodtimes
repo_gpgkey: http://myfoo.com/goodtimes/key
repo_gpgcheck: 1
repo_enabled: 1
repo_enablegroups: 0



in the 'qa' env common yaml file

repo_descr: fooqarepo
repo_baseurl: http://myfoo.com/qa_crispybacon/goodtimes
repo_gpgkey: http://myfoo.com/qa_crispybacon/goodtimes/key
repo_gpgcheck: 1
repo_enabled: 1
repo_enablegroups: 0



in the webservers function common yaml file, I have another repo:

repo_descr: webservers
repo_baseurl: http://myfoo.com/bacon/goodtimes
repo_gpgkey: http://myfoo.com/bacon/goodtimes/key
repo_gpgcheck: 1
repo_enabled: 1
repo_enablegroups: 0






so I want all the qa web servers in the foo DC in the east coast to have all 
five of those repo files defined.. except for web02, of course, because he's 
special… looking at it this way makes my head hurt. I don't see a good way to 
actualize these repos onto a node, or exclude them from a unique snowflake if 
necessary, which sort-of defeats the purpose of hiera altogether.

Do I not create them as separate keys, but as a single 'repo' array, and in my 
manifest use a template to iterate through the array and associate the values 
contained within  the array with values needed for the addition of a repo?

What have people found works "best"?







This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: "Best" way to relate keys, or stuff multiple values into a single key in hiera?

[Wolf Noble]

Hi John,

Thanks a bunch. This seems incredibly sensible.

If I'm understanding your suggestion properly, I interpret the best thing to do 
as something like:


mymodule::repos {
$region_repos = hiera('region_repos' , '' )
$dc_repos = hiera('dc_repos' , '' )

  if $region_repos {
create_resources('yumrepo', $region_repos))
  }
  if $dc_repos {
create_resources('yumrepo', $dc_repos))
  }
#...
}

and then I could override them like

us-east/foo/qa/webservers/web02.qa.myfoo.com.yaml

region_repos: ""
dc_repos:
  foodc_qa_repo: {
descr: foodc-qa,
baseurl: http://myfoo.com/foodc-repo,
gpgkey: http://myfoo.com/foodcrepo/key,
gpgcheck: 1,
enabled: 1,
enablegroups: 0
}


with the known caveat that I'd have to explicitly redeclare the entire hash at 
the most relevant tier if I wanted to change any element of the hash already 
defined.


Did I miss anything?


On Jun 12, 2012, at 5:18 PM, jcbollinger wrote:

>
>
> On Tuesday, June 12, 2012 1:48:09 PM UTC-5, Wolf Noble wrote:
> So… I'm coming across a situation where I foresee myself having a collection 
> of related k/v pairs in hiera. I want to create a thing… lets say a yumrepo 
> for example's sake, but this same idea translates to  a vhost, a web app 
> configuration , a virtual domain, etc.
>
> lets assume a hierarchy of:
>
>   - %{region}/%{dc}/%{env}/%{function}/%{fqdn}
>   - %{region}/%{dc}/%{env}/%{function}/common
>   - %{region}/%{dc}/%{env}/common
>   - %{region}/%{dc}/common
>   - %{region}/common
>
> in the us-east region common yaml file, should I create the following two 
> repos values:
>
> repo_descr: eastcoast-pub
> repo_baseurl: http://myfoo.com/eastcoastgoodtimes
> repo_gpgkey: http://myfoo.com/eastcoastgoodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
> repo_descr: eastcoast-internal
> repo_baseurl: http://myfoo.com/eastcoast
> repo_gpgkey: http://myfoo.com/eastcoast/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
> in the foo DC common file I have a repo for that datacenter:
>
> repo_descr: foo
> repo_baseurl: http://myfoo.com/goodtimes
> repo_gpgkey: http://myfoo.com/goodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
>
> in the 'qa' env common yaml file
>
> repo_descr: fooqarepo
> repo_baseurl: http://myfoo.com/qa_crispybacon/goodtimes
> repo_gpgkey: http://myfoo.com/qa_crispybacon/goodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
>
> in the webservers function common yaml file, I have another repo:
>
> repo_descr: webservers
> repo_baseurl: http://myfoo.com/bacon/goodtimes
> repo_gpgkey: http://myfoo.com/bacon/goodtimes/key
> repo_gpgcheck: 1
> repo_enabled: 1
> repo_enablegroups: 0
>
>
>
>
>
>
> so I want all the qa web servers in the foo DC in the east coast to have all 
> five of those repo files defined.. except for web02, of course, because he's 
> special… looking at it this way makes my head hurt. I don't see a good way to 
> actualize these repos onto a node, or exclude them from a unique snowflake if 
> necessary, which sort-of defeats the purpose of hiera altogether.
>
> Do I not create them as separate keys, but as a single 'repo' array, and in 
> my manifest use a template to iterate through the array and associate the 
> values contained within  the array with values needed for the addition of a 
> repo?
>
> What have people found works "best"?
>
> For complex data you need to put some structure in your YAML and process it 
> accordingly in your manifests.  In particular, in this case it would be to 
> your advantage to use hiera's (and YAML's) support for arrays and / or hashes 
> as values.  For example:
>
> in us-east/common.yaml:
> ==
> region_repos:
>   eastcoast_pub_repo: {
>   descr: eastcoast-pub,
>   baseurl: http://myfoo.com/eastcoastgoodtimes,
>   gpgkey: http://myfoo.com/eastcoastgoodtimes/key,
>   gpgcheck: 1,
>   enabled: 1,
>   enablegroups: 0
> },
>   eastcoast_internal_repo: {
>   descr: eastcoast-internal,
>   baseurl: http://myfoo.com/eastcoast,
>   gpgkey: http://myfoo.com/eastcoast/key,
>   gpgcheck: 1,
>   enabled: 1,
>   enablegroups: 0
> }
> ==
>
> That's a hash of hashes, associated with the key "region_repos".  You could 
> use that in your manifests like so:
>
> mymodule::repos {
> create_resources('yumrepo', hiera('region_repos'))
> # perhaps also create_resources('yumrepo&

Re: [Puppet Users] Hiera - can't convert Array into String error

[Wolf Noble]

I had some issues with using boolean logic with data being fed to me by hiera. 
I went for a slightly hacky option of:

might help you, might be a BadIdea(™)

(untested)


class foo::params{
bool_to_be_tempname = hiera('some_TorF_key_as_a_string')
  case bool_to_be_tempname {
[tT][rR][uU][eE]: {
  bool_to_be = true
}
default: {
  bool_to_be = false
}
  }
}


On Jun 13, 2012, at 7:40 AM, Michael Knox wrote:

> Hi,
> I've been moving from extlookup to hiera, and it's generally gone fairly 
> smoothly, but I've run into a problem with one of our defines ...
>
> I get this error:
> err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> can't convert Array into String at ...
>
> The define uses an exec to install Perl CPAN modules and sets log output 
> based on a hiera lookup.
>  exec{"cpan_load_${title}":
>   < cut …>
>logoutput   => hiera('cpan_logoutput'),
>  }
>
> If I remove that line, everything runs through fine.
>
> The yaml for hiera:
> ---
> cpan_logoutput: true
>
> Any ideas on what could be triggering this error?
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: "Best" way to relate keys, or stuff multiple values into a single key in hiera?

[Wolf Noble]

Awesome!

I wonder about one other thing though,  Is create_resources likely to balk if 
there are values in the hash that are irrelevant for the resource type being 
fed?

ie: if I have a region_repos hash that has both yum values, and apt values… 
(assuming that a debian sibling to the yumrepo type comes along at some point 
in the future) and feed them both via the same key, is that likely going to 
cause me pain? or should the key be geared more to one or the other, i.e.:

region_yumrepo:
  foo_repo: {
..
  }

region_aptsource
  foo_aptsource: {
…
  }

just trying to think about where the pointy/sharp parts of this might be.


On Jun 13, 2012, at 8:24 AM, jcbollinger wrote:

>
>
> On Tuesday, June 12, 2012 5:51:06 PM UTC-5, Wolf Noble wrote:
> Hi John,
>
> Thanks a bunch. This seems incredibly sensible.
>
> If I'm understanding your suggestion properly, I interpret the best thing to 
> do as something like:
>
>
> mymodule::repos {
> $region_repos = hiera('region_repos' , '' )
> $dc_repos = hiera('dc_repos' , '' )
>
>   if $region_repos {
> create_resources('yumrepo', $region_repos))
>   }
>   if $dc_repos {
> create_resources('yumrepo', $dc_repos))
>   }
> #...
> }
>
> and then I could override them like
>
> us-east/foo/qa/webservers/web02.qa.myfoo.com.yaml
>
> region_repos: ""
> dc_repos:
>   foodc_qa_repo: {
> descr: foodc-qa,
> baseurl: http://myfoo.com/foodc-repo,
> gpgkey: http://myfoo.com/foodcrepo/key,
> gpgcheck: 1,
> enabled: 1,
> enablegroups: 0
> }
>
>
> with the known caveat that I'd have to explicitly redeclare the entire hash 
> at the most relevant tier if I wanted to change any element of the hash 
> already defined.
>
>
> Did I miss anything?
>
> I don't see any obvious errors or omissions.  In particular, you are correct 
> that overriding repos declared at a lower level will involve declaring an 
> entirely new hash (of hashes) at the appropriate higher level.  That's one of 
> the costs attending complex data.  All in all, it looks nicely fleshed out.
>
>
> John
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/puppet-users/-/Ts3RcypLci0J.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Conditional with variable from facter

[Wolf Noble]

Hi Jakov,

the two semicolons locate these variables as  being in top-scope/variables 
outside of any specific module.

otherwise it might be $modulename::variable

Does that help at all?

W

On Jun 18, 2012, at 8:25 AM, Jakov Sosic wrote:

> Hi.
>
> I have the following facts available:
>
> # facter | grep oper
> operatingsystem => CentOS
> operatingsystemrelease => 6.2
>
> Now, if I wish to use conditionals on these facts, I have to do it like
> this:
>
> case $operatingsystem {}
> case $::operatingsystemrelease {}
>
>
> I'm puzzled as to why can't I just use $operatingsystemrelease, and what
> do these two semicolons mean?
>
>
> Thank you.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Conditional with variable from facter

[Wolf Noble]

D'oh

On Jun 18, 2012, at 11:26 AM, Martin Alfke wrote:

> Hi,
>
> On 18.06.2012, at 17:14, Wolf Noble wrote:
>
>> Hi Jakov,
>>
>> the two semicolons locate these variables as  being in top-scope/variables 
>> outside of any specific module.
>
> please note that these are colons (:) no semicolons(;).

I will not respond to lists before coffee
I will not respond to lists before coffee
I will not respond to lists before coffee
...



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?

[Wolf Noble]

… Now that I'm excessively caffeinated (I'm not actually sure if that's better, 
or worse, than my previous state, but)…


On Jun 18, 2012, at 12:47 PM, Jo Rhett wrote:

> On Jun 18, 2012, at 12:55 AM, Felix Frank wrote:
>> this thread is starting to confuse me, I am no longer sure what you're
>> suggesting, precisely.
>>
>> a) Make it possible to nullify notifications under certain circumstances.
>> b) Make it possible to ignore file owner/mode for files that exist already.
>>
>> While (b) is rather tasteless to me (as is the whole "replace"
>> parameter), it is certainly well in line of what's possible today, so I
>> wouldn't object too much.
>> (a) is a nightmare I hope you're not invested in.
>
> Well, a in the service of b -- but as a general point, I think that every 
> notify/subscribe should be tune-able as to which things changing will cause 
> the action to take place.



Not to continue this thread longer than it needs to go, but wouldn't your 
suggested paradigm permit you to bite yourself in the following scenario:
  - change the ownership or mode of a file to the point that the required 
application could no longer access the file
  - exclude this change from notifying or triggering the application that the 
permissions or ownership of its' config file have changed.
  This change will go unnoticed until:
 o Some random point in time in the future wherein the service "should" 
restart according to the method you propose.
 o Some part of the application needs to re-read it's configuration file
 o The server reboots

Suddenly things don't work. You don't have a smoking gun for the culprit change 
as that "clean" deployment happened [hours,days,weeks] ago with some other 
"unrelated" change by some other team that this service was set to ignore.

That really seems, to me at least, like a huge bag of pain to drag around 
waiting to pull out simply because it's tuesday.
… I never could get the hang of tuesdays.

Just my $.02, but if a file's ownership shouldn't change,  and it belongs to a 
specific module, and there becomes a reason to change that ownership, without 
impacting existing modules, does it make sense to create a different module, 
and manage the dissimilar needs via that route?

That would at least let you know you're attempting to utilize two incompatible 
resources before doing so







This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] can we avoid notify/subscribe firing on a mode change?

[Wolf Noble]

On Jun 18, 2012, at 6:04 PM, Jo Rhett wrote:

> On Jun 18, 2012, at 1:57 PM, Wolf Noble wrote:
>>> Well, a in the service of b -- but as a general point, I think that every 
>>> notify/subscribe should be tune-able as to which things changing will cause 
>>> the action to take place.
>>
>> Not to continue this thread longer than it needs to go, but wouldn't your 
>> suggested paradigm permit you to bite yourself in the following scenario:
>>  - change the ownership or mode of a file to the point that the required 
>> application could no longer access the file
>>  - exclude this change from notifying or triggering the application that the 
>> permissions or ownership of its' config file have changed.
>>  This change will go unnoticed until:
>> o Some random point in time in the future wherein the service "should" 
>> restart according to the method you propose.
>> o Some part of the application needs to re-read it's configuration file
>> o The server reboots
>> Suddenly things don't work. You don't have a smoking gun for the culprit 
>> change as that "clean" deployment happened [hours,days,weeks] ago with some 
>> other "unrelated" change by some other team that this service was set to 
>> ignore.
>
> I do believe I can shoot myself in the foot a dozen different ways that 
> puppet does allow me to do:
>* break the configuration in the change
>* fail to restart the service
>* break some other dependancy
> …etc
>
> The short version is this is nowhere close to the easiest way to bag the 
> service or host. I can do it dozens of ways with puppet today.  It's my job 
> to write the policy well, and test it well, and test all its dependencies.  
> Puppet can't save me from myself.
> What would be really nice is if I can, writing my policy carefully, achieve 
> more granularity, more control. Saying that I shouldn't have finer-grained 
> control because I could bag the service makes no sense, unless this was 
> opening some new vector in which to do so.  It isn't.

No, it's not the easiest way to break your environment. but it is a direct line 
to future obfuscated breakage, red herrings, and new and exciting ways to waste 
lots of engineers' time trying to suss out what in the the last N changes broke 
$package.

Not taking that into account will arguably lead one to making bad design 
choices.  Aren't we supposed to be lazy and try to NOT shoot ourselves in the 
foot unexpectedly?

>> Just my $.02, but if a file's ownership shouldn't change,  and it belongs to 
>> a specific module, and there becomes a reason to change that ownership, 
>> without impacting existing modules, does it make sense to create a different 
>> module, and manage the dissimilar needs via that route?
>
> Same software, same management functions, same configs… just a different 
> permissions change on new installations. Should I really duplicate the entire 
> module, and manage all changes in both places?  And forever try to manage 
> which host should be in which generation?


There's many ways of doing this…  A case statement tied to a version number, or 
some other fact will get you this..
Aren't you pretty clearly stating that this old generation IS different than 
the next generation? How is puppet supposed to KNOW the difference between the 
two?

I've yet to see a satisfactory implementation of 'do what I mean, not what I 
say'.. but then again, I think that's why we're driving the computers and not 
the other way around…
oof. My laptop's out of battery… have to go plug it in…Hey… Wait a minute..




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] hiera questions

[Wolf Noble]

This thought crossed our minds as well.

I created the following feature request awhile back:

https://projects.puppetlabs.com/issues/13934#change-60706

the intent behind which is "if this fact is flagged as immutable, and it 
changes, something is drastically wrong… (don't)? do something"


until something along those lines is implemented, however, the following works 
reasonably well:


the client/puppet master communication is wrapped around the base layer of 
trust of the ssl cert's CN.

if you use that name to perform a lookup against an accessory lookup table 
before feeding hiera, this will accommodate most environments 'bootstrappy' 
needs… i.e.:

certname: fooweb.product1.somesite.com
  role: webserver
  tier: qa
  environment: product1
  etc…


your lookup table is outside of the client's control, so it cannot change these 
pieces of information. It also can not easily change it's certname…

this provides a reasonable amount of security, and flexibility… I'd prefer to 
set a handful of facts that I know are 'correct' at system install time and not 
perform extra puppet master work at manifest compilation time, but that's just 
me.

W


On Jul 2, 2012, at 2:57 PM, Jan Ivar Beddari wrote:

On 02. juli 2012 17:26, Darryl Wisneski wrote:
modules I can use hiera to call up my hash and create ruby/puppet
functions to do the server host location and functional logic based
on the default facter facts of hostname and operatingsystem reported
by the server host themselves.  All the configuration remains in
hiera and the module manifests remain puppet business logic.

Comments?

Off list as I'm too lazy to write in length and explain it all ;-)

Do you care that the node (i.e root on the server) is able to say anything at 
all about its role and location? If you place a fact on the system that says 
what it is it could lie.

What I'm getting at is security.

I've designed my own hiera setup so that I don't use ANY host-derived facts, at 
all. The only thing I can be (relatively) sure of on the puppetmaster is that 
clientcert is what it says it is.

In a multi-tenant scenario (or easier even, in a scenario where all your 
servers have a common root password) where would you place your source of truth?

Don't know if you see this or care but still fired this off.


best,
Jan Ivar Beddari
Linux/Mac architect University of Bergen, Norway



--
http://www.uib.no/personer/Jan.Ivar.Beddari


--
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.





This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Multiple template fallbacks

[Wolf Noble]

Here's what I've been doing, fwiw:

file { 'nsswitch.conf':
  path => '/etc/nsswitch.conf',
  content => inline_template(
file(
  
"/etc/puppet/modules/dist/ldapclient/templates/etc/nsswitch.conf.$hostname.erb",
  
"/etc/puppet/modules/dist/ldapclient/templates/etc/nsswitch.conf.$deviceid.erb",
  
"/etc/puppet/modules/dist/ldapclient/templates/etc/nsswitch.conf.$clientid.erb",
  "/etc/puppet/modules/dist/ldapclient/templates/etc/nsswitch.conf.erb")),
  ensure => file,
  owner => root, group => 0, mode => 0644;
}


not sure about the elegance or lack thereof, contained within, but it seems to 
work until there's a "better way"(™) to do it

W
On Sep 1, 2011, at 9:09 AM, Nigel Kersten wrote:



On Wed, Aug 31, 2011 at 10:48 PM, Sam Morrison 
mailto:sorri...@gmail.com>> wrote:
Hi,

In a file resource I want to be able to specify multiple template contents. If 
the 1st template doesn't exist use the 2nd listed and so on. Much like how the 
source attribute works.
Basically this:

  file { "/tmp/somefile.txt":
ensure  => present,
content => [
   template("somefile-$fqdn.erb"),
   template("somefile.erb"),
   ]
mode=> 644,
owner   => root,
group   => root,
}

Which doesn't work. Is there a way to do this in puppet?

Unfortunately the template and file functions treat multiple values 
differently. File uses them for fallbacks, Template concats the .erb files 
together.

This is something we'd quite like to fix, and the solution is probably going to 
involve a separate concatenation function, but changing how template works is 
somewhat problematic for backwards compatibility. Perhaps an 'erb' function 
that behaves like 'template' is a better solution...


http://projects.puppetlabs.com/issues/5158





Thanks,
Sam


--
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/mVbZoOdhVp8J.
To post to this group, send email to 
puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



--
Nigel Kersten
Product Manager, Puppet Labs

Join us for PuppetConf

Sept 22/23 Portland, Oregon, USA.



--
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to 
puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further 
information on confidentiality and the risks of non-secure electronic 
communication. If you cannot access these links, please notify us by reply 
message and we will send the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] LDAP Authentication and puppet?

[Wolf Noble]

Hi Peter,

we used a different method here for linux hosts.
We put the groups we want to grant access to in /etc/security/access.conf ; ala:

[root@---]# egrep -v ^# /etc/security/access.conf

- : ALL EXCEPT root admin pci_sysadmin pci_devadmin : ALL

and then just add users to the group which permits access to the machines in 
question via ldap.

[root@---]# id wnoble
uid=(wnoble) gid=(pci_sysadmin) 
groups=77(puppet),(pci_sysadmin),9998(sysadmin)

that was the cleanest way I found to do it, but ymmv


W
On Dec 12, 2011, at 2:24 PM, Peter Berghold wrote:

> Having a brain storm this morning I had a thought.  This can be dangerous at 
> times.
>
> I have an infrastructure where I am moving user authentication to be LDAP 
> based. Further I am working out how to create host groups in LDAP such that I 
> can group which user can log into what hosts.  For instance I have
>
> $users = ['tom','dick','jaine','harry','sally']
>
> apple_host_users = ['tom','jane','sally']
>
> bannana_host_users=['dick','harry']
> etc.
>
> Only instead of puppet arrays I'd be doing this in LDAP.
>
> Has anybody managed to come up with a class or define that would query an 
> LDAP server for a hostgroup and create the home directories and apply a 
> skeleton to those directories based on the users in the host group?
>
> I'm thinking this is probably going to have to be a custom fact...
>
>
> --
> Peter L. Berghold
> Owner, Shark River Technical Solutions LLC
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.






This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further 
information on confidentiality and the risks of non-secure electronic 
communication. If you cannot access these links, please notify us by reply 
message and we will send the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Blocking or gating service restarts?

[Wolf Noble]

just a thought; what if you made a fact for number of apache workers currently 
serving something, and base the service restart off of that.

Might not be the best option; might not even work, but it makes more sense to 
me to have the service restart dependent on a local fact than be dependent on 
something external to the server

On Jan 6, 2012, at 3:52 PM, simonmcc wrote:

> inside puppet is it possible to block or stall a service restart until
> some external component clears the restart?
>
> for example, I want to make sure a node is bled down on the load-
> balancer before allowing the restart to happen.
>
> a post restart feature of re-enabling in the load-balancer would also
> be really useful :-)
>
> Simon.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/about-us-legal-email-disclaimer.htm for further 
information on confidentiality and the risks of non-secure electronic 
communication. If you cannot access these links, please notify us by reply 
message and we will send the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] create multiple resources from an array of things.

[Wolf Noble]

Hi gang,

I feel like I'm missing something fundamental here…
I've got the following:

class snmp::rhel::rh5enable {
  $collector = ['10.0.0.1', '10.0.0.2']
  define add_snmp_hosts_allow ($ip) {
exec { "hosts_allow_$ip":
  command => "/bin/echo \"snmpd : $ip : ALLOW\" >>/etc/hosts.allow",
  unless  => "/bin/grep -c \"snmpd : $ip : ALLOW\" /etc/hosts.allow",
}
  }
  notify { "COLLECTOR IS SET TO ${collector}": }
  add_snmp_hosts_allow{$collector: ip=> $collector,}
}

yet I get borked, as :

err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Duplicate declaration: Exec[hosts_allow_10..0.0.110.0.0.2] is already declared 
in file /etc/puppetlabs/puppet/modules/core/snmp/manifests/rhel/rh5enable.pp at 
line 4; cannot redeclare at 
/etc/puppetlabs/puppet/modules/core/snmp/manifests/rhel/rh5enable.pp:4 on node 
centos


how do I go about doing this "correctly" ?







This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] create multiple resources from an array of things.

[Wolf Noble]

Hi Eric,

No, this class is not being called anywhere else.

What I think is going on is that I have an array of two strings, but somehow 
the defined type is getting a concatenated string which contains both values of 
the array instead of treating each element of the array  as an individual.

The end goal here is to have an array of each ip address that needs to have an 
entry in /etc/hosts.allow, and have a defined type which is fed those IPs and 
verifies the presence of/creates the entries as needed.

is there a better direction to approach this than I'm employing?




On Jul 8, 2012, at 1:46 PM, Eric Shamow wrote:

> Wolf,
>
> Are you calling that parameterized class multiple places?
>
> This sounds like a situation where what you want may be a defined type but in 
> fact you are using a parameterized class. You can include paramaterized 
> classes multiple times using "include" but not using parameters.
>
> -Eric
>
> --
>
> Eric Shamow
> Professional Services
> http://puppetlabs.com/
> (c)631.871.6441
>
>
> On Sunday, July 8, 2012 at 2:00 PM, Wolf Noble wrote:
>
>> Hi gang,
>>
>> I feel like I'm missing something fundamental here…
>> I've got the following:
>>
>> class snmp::rhel::rh5enable {
>> $collector = ['10.0.0.1', '10.0.0.2']
>> define add_snmp_hosts_allow ($ip) {
>> exec { "hosts_allow_$ip":
>> command => "/bin/echo \"snmpd : $ip : ALLOW\" >>/etc/hosts.allow",
>> unless => "/bin/grep -c \"snmpd : $ip : ALLOW\" /etc/hosts.allow",
>> }
>> }
>> notify { "COLLECTOR IS SET TO ${collector}": }
>> add_snmp_hosts_allow{$collector: ip=> $collector,}
>> }
>>
>> yet I get borked, as :
>>
>> err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
>> Duplicate declaration: Exec[hosts_allow_10..0.0.110.0.0.2] is already 
>> declared in file 
>> /etc/puppetlabs/puppet/modules/core/snmp/manifests/rhel/rh5enable.pp at line 
>> 4; cannot redeclare at 
>> /etc/puppetlabs/puppet/modules/core/snmp/manifests/rhel/rh5enable.pp:4 on 
>> node centos
>>
>>
>> how do I go about doing this "correctly" ?
>>
>>
>>
>>
>>
>> 
>>
>> This message may contain confidential or privileged information. If you are 
>> not the intended recipient, please advise us immediately and delete this 
>> message. See http://www.datapipe.com/legal/email_disclaimer/ for further 
>> information on confidentiality and the risks of non-secure electronic 
>> communication. If you cannot access these links, please notify us by reply 
>> message and we will send the contents to you.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com 
>> (mailto:puppet-users@googlegroups.com).
>> To unsubscribe from this group, send email to 
>> puppet-users+unsubscr...@googlegroups.com 
>> (mailto:puppet-users+unsubscr...@googlegroups.com).
>> For more options, visit this group at 
>> http://groups.google.com/group/puppet-users?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] create multiple resources from an array of things.

[Wolf Noble]

I figured out what I was doing wrong.

I wasn't (maybe I'm still not? :) ) properly  taking advantage of the freebie 
parameter 'title' of defined types. This now seems to behave like I had hoped 
it would:


class snap::rhel::rh5enable {
  #...
  $collector = ['10.0.0.1','10.0.0.2']
  #…
  define add_snmp_hosts_allow () {
exec { "hosts_allow_$title":
  command => "/bin/echo \"snmpd : $title : ALLOW\" >>/etc/hosts.allow",
  unless  => "/bin/grep -c \"snmpd : $title : ALLOW\" /etc/hosts.allow",
}
  }#end define
  #...
  notify { "COLLECTOR IS SET TO ${collector}": }
  add_snmp_hosts_allow{$collector:}
  #...
}


notice: 
/Stage[main]/Snmp::Rhel::Rh5enable/Snmp::Rhel::Rh5enable::Add_snmp_hosts_allow[10.0.0.2]/Exec[hosts_allow_10.0.0.2]/returns:
 executed successfully
notice: COLLECTOR IS SET TO 10.0.0.110.0.0.2
notice: /Stage[main]/Snmp::Rhel::Rh5enable/Notify[COLLECTOR IS SET TO 
10.0.0.110.0.0.2]/message: defined 'message' as 'COLLECTOR IS SET TO 
10.0.0.110.0.0.2'
notice: 
/Stage[main]/Snmp::Rhel::Rh5enable/Snmp::Rhel::Rh5enable::Add_snmp_hosts_allow[10.0.0.1]/Exec[hosts_allow_10.0.0.1]/returns:
 executed successfully
notice: Finished catalog run in 6.76 seconds


On Jul 8, 2012, at 2:38 PM, Wolf Noble wrote:

> Hi Eric,
>
> No, this class is not being called anywhere else.
>
> What I think is going on is that I have an array of two strings, but somehow 
> the defined type is getting a concatenated string which contains both values 
> of the array instead of treating each element of the array  as an individual.
>
> The end goal here is to have an array of each ip address that needs to have 
> an entry in /etc/hosts.allow, and have a defined type which is fed those IPs 
> and verifies the presence of/creates the entries as needed.
>
> is there a better direction to approach this than I'm employing?
>
>
>
>
> On Jul 8, 2012, at 1:46 PM, Eric Shamow wrote:
>
>> Wolf,
>>
>> Are you calling that parameterized class multiple places?
>>
>> This sounds like a situation where what you want may be a defined type but 
>> in fact you are using a parameterized class. You can include paramaterized 
>> classes multiple times using "include" but not using parameters.
>>
>> -Eric
>>
>> --
>>
>> Eric Shamow
>> Professional Services
>> http://puppetlabs.com/
>> (c)631.871.6441
>>
>>
>> On Sunday, July 8, 2012 at 2:00 PM, Wolf Noble wrote:
>>
>>> Hi gang,
>>>
>>> I feel like I'm missing something fundamental here…
>>> I've got the following:
>>>
>>> class snmp::rhel::rh5enable {
>>> $collector = ['10.0.0.1', '10.0.0.2']
>>> define add_snmp_hosts_allow ($ip) {
>>> exec { "hosts_allow_$ip":
>>> command => "/bin/echo \"snmpd : $ip : ALLOW\" >>/etc/hosts.allow",
>>> unless => "/bin/grep -c \"snmpd : $ip : ALLOW\" /etc/hosts.allow",
>>> }
>>> }
>>> notify { "COLLECTOR IS SET TO ${collector}": }
>>> add_snmp_hosts_allow{$collector: ip=> $collector,}
>>> }
>>>
>>> yet I get borked, as :
>>>
>>> err: Could not retrieve catalog from remote server: Error 400 on SERVER: 
>>> Duplicate declaration: Exec[hosts_allow_10..0.0.110.0.0.2] is already 
>>> declared in file 
>>> /etc/puppetlabs/puppet/modules/core/snmp/manifests/rhel/rh5enable.pp at 
>>> line 4; cannot redeclare at 
>>> /etc/puppetlabs/puppet/modules/core/snmp/manifests/rhel/rh5enable.pp:4 on 
>>> node centos
>>>
>>>
>>> how do I go about doing this "correctly" ?
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> This message may contain confidential or privileged information. If you are 
>>> not the intended recipient, please advise us immediately and delete this 
>>> message. See http://www.datapipe.com/legal/email_disclaimer/ for further 
>>> information on confidentiality and the risks of non-secure electronic 
>>> communication. If you cannot access these links, please notify us by reply 
>>> message and we will send the contents to you.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-users@googlegroups.com 
>>> (mailto:puppet-users@googlegroups.com).
>>>

Re: [Puppet Users] Modify Facter Value

[Wolf Noble]

I'm doing something similar in one environment… I've come to realize this 
method contains less awesome than I'd anticipated.

What I'd suggest doing, is changing the file deployed to the client into a 
template that's deployed via puppet..
have that template set the content correctly for the machine in question when 
it's deployed.
The HOW you go about doing that varies greatly depending on your environment…

This way you're not trying to override facts, which is generally an adventure 
in undergoodness.

my $.02

On Jul 31, 2012, at 3:38 PM, rjl  wrote:

> Hi all,
> I have a custom facts script that is distributed to all of my puppet clients. 
> This first thing this script does is read a file on the client to determine 
> the 'type' of server that it is. Later in the script, I would like to change 
> the value based on some additional information. I don't seem to be able to 
> modify the value of a fact once it has been set. For example
>
> Facter.add("server_type") do
>   setcode do
>  "apache_web_server"
>   end
> end
>
> # Later I may want to change the value.
>
> if Facter.value("http_server") = "false"
># Change value of "server_type" here. I have tried many different 
> approaches but none work.
> end
>
> Any advice would be greatly appreciated.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/puppet-users/-/AXcBrQsr4YsJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Hiera relationships

[Wolf Noble]

I was asleep, and woke up thinking about a way to define a relationship between 
the hiera parameters of multiple modules such that conflicts could be avoided...

The thought process was that if I set one value, say, the service enablement 
parameter for snmp to 'stopped' in my tripwire module, that value could 
conflict with the service parameter of the snmp module.. Which references a 
completely unrelated hiera parameter


I thought about just using the same value for both, but that could be confusing 
for sharing modules, as the pseudo-scope of hiera parameters ie:

$modulename_parametername: foo

snmp_snmp_enable: enable
tripwire_snmp_enable: stopped

Would no longer be the rule, which, while I suppose there is no rule, (is 
there?) this made the most sense to me, so I ran with it.

I thought, sleepily: if there was some way for me to say there could be a 
conflict which could be clearly stated in the hiera values, I think it might 
make for easier module sharing/blending

'if this other parameter (bacon_crispness) exists and has the value of  [ 
crispy,burnt,raw ] that conflicts with me (breakfast_enjoyment) if the value is 
true.'

This could be furthered to override a stated value via a relationship :
Breakfast_enjoyment: true  <~ unless (bacon_crispness) is [ crispy,burnt,raw ]

Or to confine another parameter's values:
Breakfast_enjoyment: true ~> bacon_crispness: [ undef,chewy,thick,absent ]



Is there any merit to this idea?

In speaking with people who have tastyzombiebrains™ there was a concern that 
this breaks the 'data only' model of hiera.. so perhaps the dependency logic 
should live in the hiera function in puppet? or not at all… dunno..

Maybe I should have just gone back to bed?



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] how to resolve hostnames to IP addresses in templates

[Wolf Noble]

if you're using hiera, why not something like:


foo_data_webfarm_http_servers:
  foo1.example.com: {
ip: '1.2.3.4',
port: '80',
  }
  foo2.example.com: {
ip: '2.3.4.5',
port: '80',
  }
foo_data_webfarm_https_servers:
  foo1.example.com: {
ip: '1.2.3.4',
port: '443',
  }
  foo2.example.com: {
ip: '2.3.4.5',
port: '443',
  }

class foo::data {
  include foo::params
file { 'foo.conf':
  path   => '/etc/foo.conf',
  ensure  => 'file',
  content  => template(foo_conf.erb),
  mode => '0555',
}

class foo::params {
  $webfarm_http_servers   = hiera('foo_data_webfarm_http_servers', '')
  $webfarm_https_servers = hiera('foo_data_webfarm_https_servers', '')
}


foo_conf.erb
<% http_servers = scope.lookupvar('foo::params::webfarm_http_servers')
   https_servers = scope.lookupvar('foo::params::webfarm_https_servers')
-%>
#
# http servers
<% http_servers.each_pair do |key, hash| -%>
#<%=key%>
IPADDR= <%=hash['ip'] %>
PORT=  <%=hash['port'] %>
<% end%>
#
# https servers
<% https_servers.each_pair do |key, hash| -%>
#<%=key%>
IPADDR= <%=hash['ip'] %>
PORT=  <%=hash['port'] %>
<% end%>

<% end%>



On Aug 9, 2012, at 3:38 PM, Tim Mooney 
 wrote:

>
> Environment: puppet 2.7.14 on both master and all clients.  We're also
> using puppetlabs-stdlib and hiera, if that matters.
>
> I know this is really more of a ruby/erb question, but I've been searching
> for a couple hours and haven't turned up anything relatively close to what
> I'm trying to do, and I'm hoping someone here has had to do this and can
> provide a suggestion for how to proceed.
>
> I'm generating a configuration file from a template.  The configuration
> file will need to have IP addresses in it, but I would like to be able to
> use either hostnames or IP adresses in the puppet config.  This means
> that I need to be able to resolve the hostnames and turn them into IP
> addresses, probably in the template itself.
>
> Basically, given something like this in puppet:
>
> class foo::data {
>
>  $webfarm = {
>http_servers => hiera('webfarm_http_servers', [
>  {
>host => 'foo1.example.com',
>port => '80',
> },
>  {
>host => 'foo2.example.com',
>port => '80',
> },
>  {
>host => 'foo3.example.com',
>port => '80',
> },
>]),
>https_servers => hiera('webfarm_https_servers', [
>  {
>host => 'foo1.example.com',
>port => '443',
> },
>  {
>host => 'foo22.example.com',
>port => '443',
> },
>  {
>host => 'foo99.example.com',
>port => '443',
> },
>]),
>  }
> }
>
> I need my template to iterate over the http_servers and https_servers
> arrays and resolve the values for the host key for each element.
>
> Anyone have an example of how to do this in a template?
>
> Thanks,
>
> Tim
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure  701-231-1076 (Voice)
> Room 242-J6, IACC Building 701-231-8541 (Fax)
> North Dakota State University, Fargo, ND 58105-5164
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] how to resolve hostnames to IP addresses in templates

[Wolf Noble]

On Aug 9, 2012, at 5:42 PM, Tim Mooney 
 wrote:

> In regard to: Re: [Puppet Users] how to resolve hostnames to IP addresses...:
>
>> if you're using hiera, why not something like:

[…]
heh yeah,

okay, so, well, uh... I didn't say it was a GOOD idea ;)

> Thanks for the fully-formed example Wolf.  John's subsequent response
> was spot-on as to why I would like to avoid duplicating the IPs in the
> data structure.  They won't change frequently, but at the same time,
> I really don't want to have to manually duplicate and sync information
> that's stored in our DNS.

I didn't know if they were already being defined somewhere else similarly, and 
thought if there was already a hash defining them in some way, you could just 
tack the ip in and call it a day.

>
> I do have one follow-on question regarding your example, though.
>
> Did you choose foo_data_webfarm_http_servers as the "top level" hiera
> name for any particular reason, such as how hiera is going to work in
> puppet 3 with parameterized classes?

I have no real knowledge of how that's going to work; I have been namespacing 
things based on what I felt made things very clear for people looking at the 
hiera values, and the templates.

afaik there's no significant penalty for longish names, but it makes it a bit 
easier for me to ingest when looking through a gaggle of hiera parameters.

>
> I must admit that while I find hiera fantastic, I've really struggled
> with how our complex data should be organized in hiera.  I'm looking
> forward to the hiera examples that Kelsey Hightower mentioned a couple
> weeks ago on the list, but seeing examples like this in the interim is
> really helpful and appreciated.

for what it's worth, happy to help…

this gave me another idea, however which I'll create a new thread on rather 
than hijack this one

>
> Tim
>
>> On Aug 9, 2012, at 3:38 PM, Tim Mooney 
>> wrote:
>>
>>>
>>> Environment: puppet 2.7.14 on both master and all clients.  We're also
>>> using puppetlabs-stdlib and hiera, if that matters.
>>>
>>> I know this is really more of a ruby/erb question, but I've been searching
>>> for a couple hours and haven't turned up anything relatively close to what
>>> I'm trying to do, and I'm hoping someone here has had to do this and can
>>> provide a suggestion for how to proceed.
>>>
>>> I'm generating a configuration file from a template.  The configuration
>>> file will need to have IP addresses in it, but I would like to be able to
>>> use either hostnames or IP adresses in the puppet config.  This means
>>> that I need to be able to resolve the hostnames and turn them into IP
>>> addresses, probably in the template itself.
>>>
>>> Basically, given something like this in puppet:
>>>
>>> class foo::data {
>>>
>>> $webfarm = {
>>>   http_servers => hiera('webfarm_http_servers', [
>>> {
>>>   host => 'foo1.example.com',
>>>   port => '80',
>>>},
>>> {
>>>   host => 'foo2.example.com',
>>>   port => '80',
>>>},
>>> {
>>>   host => 'foo3.example.com',
>>>   port => '80',
>>>},
>>>   ]),
>>>   https_servers => hiera('webfarm_https_servers', [
>>> {
>>>   host => 'foo1.example.com',
>>>   port => '443',
>>>},
>>> {
>>>   host => 'foo22.example.com',
>>>   port => '443',
>>>},
>>> {
>>>   host => 'foo99.example.com',
>>>   port => '443',
>>>},
>>>   ]),
>>> }
>>> }
>>>
>>> I need my template to iterate over the http_servers and https_servers
>>> arrays and resolve the values for the host key for each element.
>>>
>>> Anyone have an example of how to do this in a template?
>>>
>>> Thanks,
>>>
>>> Tim
>>> --
>>> Tim Mooney tim.moo...@ndsu.edu
>>> Enterprise Computing & Infrastructure  701-231-1076 (Voice)
>>> Room 242-J6, IACC Building 701-231-8541 (Fax)
>>> North Dakota State University, Fargo, ND 58105-5164
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-users@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> puppet-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/puppet-users?hl=en.
>>>
>>
>>
>> 
>>
>> This message may contain confidential or privileged information. If you are 
>> not the intended recipient, please advise us immediately and delete this 
>> message. See http://www.datapipe.com/legal/email_disclaimer/ for further 
>> information on confidentiality and the risks of non-secure electronic 
>> communication. If you cannot access these links, please notify us by reply 
>> message and we will send the contents to you.
>>
>>
>
> --
> Tim Mooney tim.moo...@ndsu.edu
> Enterprise Computing & Infrastructure  701-231-

Re: [Puppet Users] Hiera relationships

[Wolf Noble]

On Aug 9, 2012, at 5:15 PM, Dan White 
 wrote:

> Wow.
>
> My next reaction is, "Are you sure you woke up ?"  But then I am a known and 
> convicted joker and a registered paronomasiac [1].

Nope ;)


> In an effort to make a serious response:
>
> I feel you may be using the wrong tool for the job.

quite possibly… I actually came up with this as a straw man example of a way to 
say 'this other module's hiera values may constrain or conflict with mine'

> If, as in your example, snmp and tripwire are interrelated, that should be 
> handled by your class/resource definitions.

*nod* I get that. I was thinking that having the ability to constrain 
possibilities of parameters or define conflicts in the hiera function of a 
module might make the 'shipping a module with hiera parameters to the forge for 
community use at large' easier.

I have absolutely no attachment to the idea; if people thought the idea was a 
good one, great! I done helped a bit!
but if not... well… I DID say I was asleep.

> How would you solve this problem in a version of puppet before hiera ?

Therein lies the problem, I think.
The issues of divergently sourced module cohabitation is a complicated one.

now with hiera, I was thinking having consistent, module-scoped namespacing 
would be a good thing, but then this scenario presented itself to my 
dreamspaced mind and I didn't really see a great way  around it.

> If one module wants a service running and another wants it stopped, there 
> needs to be something like a common parameter or decision point over both 
> modules to prevent a conflict.
>
> Does that make any sense or do I need to wake myself up to try for a better 
> answer ?

Totally agree.. I don't know that there's a better answer than that. I just 
wasn't convinced that there's not, either.
>
> I am honestly trying to help out, but your statement of the problem is a bit 
> confuzzled [2].
>
> (1) http://en.wiktionary.org/wiki/paronomasiac
> (2) http://en.wiktionary.org/wiki/confuzzle
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere in 
> the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> - Wolf Noble  wrote:



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] hiera peers

[Wolf Noble]

I wonder…
Would there be a benefit in the notion of 'peer values' in hiera?
Currently hiera_array will collect all the possible values for $thing defined 
all the way up the hierarchy…
This js awesome.
But there's no way to find out the values of $thing for other nodes at the same 
level in the hierarchy…

is this another 'I should have gone back to bed' thought? or would this be 
useful to people?




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Hiera to hash

[Wolf Noble]

I accomplished something similar awhile back.

While I've not spent much time looking at your particular problem, I think 
this'll help point you in the direction of what you need…



class mymodule::params{
$collector= hiera('mymodule_collector','')
}

class mymodule::config{
 $collector   = $mymodule::params::collector
 $ipstring= inline_template("<% collector.each_pair do |key, hash| 
%><%=hash['ip']%>,<%end%>")
 $ips = split ($ipstring,',')
}

define mymodule::add_hosts_allow () {
  exec { "hosts_allow_$title":
command => "/bin/echo \"myservice : $title : ALLOW\" >>/etc/hosts.allow",
unless  => "/bin/grep -c \"myservice : $title : ALLOW\" /etc/hosts.allow",
  } #end exec
}


On Aug 21, 2012, at 11:00 PM, Douglas Garstang  wrote:

> I know I did this once before but can't find docs on how to do it again.
>
> I have this in a yaml file:
>
> pvdisks:
>ec2_pvdisks_m1.small:
>disks: /dev/xvdb1
>enabled: yes
>
> Loading it with hiera.
>
> Manifest has:
>
>$testkey = hiera('pvdisks')
>notice ("TESTKEY=$testkey[ec2_pvdisks_m1.small]")
>
> This is printing
> TESTKEY=ec2_pvdisks_m1.smalldisks/dev/xvdb1enabledtrue['ec2_pvdisks_m1.small']
>
> which obviously is the data picked into a string.
>
> Doug.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Best way to bail from facter script without using confine in Facter.add ?

[Wolf Noble]

why not check to see if the binary which you're using to talk to the raid hw 
exists.. if so, execute and provide facts, if not, do nothing..
That's how it's being done in the hpacucli fact I've been using.


On Aug 23, 2012, at 11:26 AM, Nigel Kersten 
 wrote:

> On Thu, Aug 23, 2012 at 7:17 AM, ZJE  wrote:
>>
>> On Wednesday, August 22, 2012 1:56:49 PM UTC-5, Nigel Kersten wrote:
>>>
>>> On Wed, Aug 22, 2012 at 11:13 AM, ZJE  wrote:
 The slowdown comes from the command that I run before any Facter.add
 statements. It takes roughly 1.5 seconds to run and I would need to run
 it
 roughly 64 times if I had it in each Facter.add. Many facts are
 generated by
 a loop that contains a Facter.add, so I feel like some sort of exception
 would make things easier.  I'd like to avoid using a "giant if
 statement" if
 possible (there are roughly 100 lines of code that would be
 encapsulated).
 One of the main issues I have is that there are two different checks
 that
 happen in different parts of the code. I recognize that some may
 consider
 adding more if-statements as increased readability, but I feel like the
 added indentation for large chunks of code causes confusion for readers
 (especially when looking at loops).

 Thanks so much for your reply!
>>>
>>> You should be able to do something like this, which worked for the
>>> quick test I did, but I haven't extensively tested it.
>>>
>>> arr = ["one", "two", "three", "four"]
>>>
>>> if true then
>>>  # exit due to conditions for not running on this host
>>>  exit
>>> else
>>>  # run the command you'd run and store in an instance variable
>>> end
>>>
>>> arr.each do |e|
>>>  Facter.add("tester_#{e}") do
>>>setcode do
>>>  "bleah"
>>>end
>>>  end
>>> end
>>
>>
>>
>> Hi Nigel,
>>
>> Thanks again for your reply. Currently, I'm using "exit" - but I think this
>> causes the entire facter run to stop prematurely. If my script ends up being
>> the first custom fact run, facter actually outputs nothing. Could there be a
>> different problem?
>>
>> For example, if FACTERLIB=/opt/facter/facts and my custom fact looks like
>> this:
>> ---
>> cat /opt/facter/facts/bailfact.rb
>> #!/usr/bin/ruby
>> Facter.debug "In bailfact!"
>> exit
>> ---
>>
>> I get:
>> ---
>> [root@testhost ~]# facter -d
>> Relative directory ./facter removed from search path.
>> Not an EC2 host
>> in bail fact!
>> ---
>>
>> and nothing else.
>>
>> If it helps, I'm using facter 2.0.0rc4
>>
>> Thanks!
>
> heh. That makes sense :)
>
> You're going to need to surround it all in a conditional then as far
> as I can see.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Problem with hiera arrays not obeying the hierachy

[Wolf Noble]

I believe hiera_array() collects and provides an array of all the relevant 
elements up the entirety of the tree. To collect only the most relevant data 
just use hiera()



On Sep 3, 2012, at 10:21 AM, Josh 
 wrote:

> Versions: puppet 2.7.18, hiera 0.3.0
>
> I have encountered a problem that is completely counter intuitive to how I 
> thought hiera was meant to work. I have three levels in my hierarchy in the 
> following order:
> - .yaml   (specific to the host)
> - .yaml   (we have multiple sites, this is info specific to the 
> site)
> - common.yaml   (applies to everything)
>
> I noticed this problem while working round a DNS problem, needless to say I 
> had the following (ip addresses changes to protect the innocent) in the 
> .yaml:
>
> dns_servers:
>   - '1.1.1.1'
>   - '2.2.2.2'
>
> I wanted a specific host to use different DNS so in the .yaml I added:
>
> dns_servers:
>   - '3.3.3.3'
>
> Now, when I do a hiera_array('dns_servers') I would expect that the original 
> array (1.1.1.1 and 2.2.2.2) would be overwritten with a single value 
> (3.3.3.3)...
>
> As it turned out is concatenated the two arrays together, giving me (1.1.1.1 
> and 2.2.2.2 and 3.3.3.3). Non-plussed I added another entry to the 
> common.yaml (4.4.4.4) and lo and behold it added that in as well giving me  
> (1.1.1.1 and 2.2.2.2 and 3.3.3.3 and 4.4.4.4).
>
> I really did assume from the documentation that the hierarchy would be obeyed 
> and both .yaml and common.yaml would be ignored ... or have I 
> misunderstood how the system works?
>
> Thanks
> Josh
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/puppet-users/-/e-jCVgKPe6AJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] install vmware tools through puppet

[Wolf Noble]

I've just added a fact to github which on vmware hosts running linux runs 
dmidecode and matches known bios address/ esx version to realize an ESX version 
fact.

this information generated from 
http://virtwo.blogspot.com/2010/10/which-esx-version-am-i-running-on.html

in limited testing on an esx 4.1 host, and a non esx host, it seems to not 
create a fact unless it's a vmware host, and seems to properly set the version, 
and fail to vmware-unknown if I change the 4.1 match

you can find it here

https://github.com/wolfspyre/vmware_puppetfact


feel free to let me know if something is incorrect, or could be done in a more 
elegant fashion.

W

On Sep 24, 2012, at 4:45 PM, Elias Abacioglu 
 wrote:

> I think that you can specify vmware version with a variable or something for 
> the razors edge module..
>
> Otherwise I can soon try to publish my vmware tools module.. Though it's not 
> written as nice as razorsedge
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] updating puppetlabs-firewall forge module to line up with whats in the github repo?

[Wolf Noble]

Hi there!

Is there a timeline on when the puppetlabs-firewall forge module will be 
updated (not necessarily to 1.0) ? the github version has the firewallchain 
type (as well as other nifty) that the forge version seems to be lacking, but 
it's not clear from my perusing that the two are different.  They both appear 
to be the same version superficially*…. The github version points to the forge 
version for documentation, so I sillily grabbed the forge version, then noticed 
that it was missing stuff I was expecting to be there. My expectation could be 
the problem here, but I didn't think it would hurt to ask.

W



*to be fair, I didn't look that hard. I could just be blind, and missed 
something sooper obvious.





This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] [facter] ESX/vSphere version detection without vmware tools

[Wolf Noble]

Hi Keiran,

I wrote this and posted it to the list awhile ago:

https://github.com/wolfspyre/vmware_puppetfact

there's been some suggestion that the source I used as a basis for this fact is 
slightly inaccurate, however I don't have a suite of esx servers to test on.. 
(it's on my list)

feel free to inform me of changes that are required, and I'll happily make them.


W

On Oct 31, 2012, at 1:26 PM, Keiran Sweet 
 wrote:

> Hi Everyone,
> I'm looking for a way to identify (if possible) the ESX/vSphere version that 
> a particular VMWare guest server is running on without the use of vmware 
> tools related commands, such as vmware-checkvm, which does seem to do the 
> trick from what I can gather.
>
> [root@server ~]# vmware-checkvm -h
> VM's hw version is 4
> VMware software version 6 (good)
> [root@server ~]#
>
> The reason behind this is that we have brought online a new site that uses 
> ESX5, and I'd like new VM's to be able to self classify what ESX specific 
> packages and services to install and manage without any admin intervention, 
> ie, Do I install the ESX4 tools, or the ESX5 ones.
>
> I have had a bit of a poke around to see if this is possible, but have so far 
> come up empty handed, and feel it may not be possible in a way that I can 
> roll it into a custom fact, so i may have to go down the route of pushing 
> some new values into our ENC that define the version of ESX in use at each 
> particular site, which isnt perfect, but will also do the job.
>
> Has anyone ever had to deal with this chicken/egg situation ?
> And if so, did you find a solution ?
>
> Thanks in advance,
>
> K
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/puppet-users/-/0-kAK--l5IcJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Best way to manage routing entries

[Wolf Noble]

Hello all,

Is anyone managing custom static routes via puppet? if so, how?

I'm wondering if there's a better cross-platform way of adding routes than a 
custom init script that defines the routes that need to be associated with each 
interface…

or maybe someone with extra tasty brains (zombies will like them even more) has 
a defined type that can already do the fu necessary for debian/rhel flavors of 
routing, and I just haven't found it yet...

Thoughts?








This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Poll for thoughts on hierifying modules and OS default differences

[Wolf Noble]

Hello lovelies,

Our team is deliberating a few different options for the hierification of our 
modules; and wanted to poll the collective genius before making our decision.

As we all know, there are certain attributes of a package which are, by 
default, consistent on an OS... say, the name of a package.

class foobar {
include foobar::params
  $package = $foobar::params::package
  Package {$package:
ensure => installed
  }
}

class foobar::params {
case $osfamily:
  redhat: {
$package = 'foobar'
  }
  debian: {
$package = 'foobard'
  }
  default: {
fail
  }
}


well, we want to be able to overide those defaults with hiera:

class foobar {
include foobar::params
  $package = $foobar::params::package
  Package {$package:
ensure => installed
  }
}

class foobar::params {
case $osfamily:
  redhat: {
$package = hiera('foobar_package','foobar')
  }
  debian: {
$package = hiera('foobar_package','foobard')
  }
  default: {
fail
  }
}


which is great, except now the package name is wrong by default on debian 
boxes...

now sure, I can argue that my hierarchy should have places to logically 
separate out and override those 'inconvenient' defaults, ie for an environment 
that uses debian...

one of our engineers suggested the following paradigm:


class foobar {
include foobar::params
  $package = $foobar::params::package
  Package {$package:
ensure => installed
  }
}

class foobar::params {
case $osfamily:
  redhat: {
$package = hiera('foobar_os_rhel_package','foobar')
  }
  debian: {
$package = hiera('foobar_os_deb_package','foobard')
  }
  default: {
fail
  }
}

which makes our topmost hierarchy (which is not segregated by OS, because the 
relevant hierarchies doen't split very cleanly at the OS level.) a little more 
bloated:

foobar_os_deb_package: 'foobard'
foobar_os_rhel_package: 'foobar'


but makes for less overriding and additions for "default" setups...


to be honest, I'm not sure which idea (or what other as yet unthought of idea) 
has the most merit, and I'd love to hear your thoughts on the matter before we 
get too much further


Thanks so much in advance


Wolf Noble



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Poll for thoughts on hierifying modules and OS default differences

[Wolf Noble]

Hi Gary,


I know what you mean, and agree for modules destined to be released to the wild.
unfortunately, we have a diverse enough environment that even the defaults 
occasionally need to be overridden; hence the hierification.
(I've got all that logic wrapped into a case statement based on if the global 
parameter hiera_enabled is true or false, with sane-ish defaults when hiera 
isn't enabled)


On Dec 7, 2012, at 12:35 PM, Gary Larizza 
 wrote:

> I tend to take the stance that things in modules that AREN'T specific to your 
> company (i.e. things that could help others - like names of packages on other 
> OS platforms, config file paths, etc) should be kept in the Module and not 
> locked up in Hiera data (that way, both people using and NOT using Hiera can 
> benefit from them).  I HAVE in the past put that data in Hiera, but have also 
> find that it can bloat the hierarchy.  I'm curious as to what others think, 
> as this is my opinion and not necessarily 'best practice'.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Hiera hashes and arrays in ERB templates

[Wolf Noble]

not sure if this is the "best" way to do this, but, taking from a different 
module I have:


hiera yaml:

snmp_filesystems:
  root: {
mountpoint:  '/',
threshold:   '10%'
  }
snmp_collector:
  test: {
ip:'1.2.3.4',
group: 'readonly',
community: 'somecommunity'
  }

class:

class snmp::params(
filesystems = hiera(snmp_filesystems, undef),
collector = hiera(snmp_collector, undef)
{
#…
}

template:

<%
  collector = scope.lookupvar('snmp::params::collector')
  filesystems = scope.lookupvar('snmp::params::filesystems')
-%>

<% collector.each_pair do |key, hash| -%>
group  <%=hash['group']-%>  v2c  <%=key%>
<%end-%>

# Filesystem monitoring enabled
<% filesystems.each_pair do |key, hash| -%>
# <%=key%>
disk <%=hash['mountpoint']-%>  <%=hash['threshold']%>
<%end-%>




does that help at all?


Wolf Noble
UNIX Team Lead
Datapipe Managed IT Services
1.201.792.4847 (international) x2910
1.888.749.5821 (toll free) x2910




On Jan 4, 2013, at 9:37 AM, llowder  wrote:

>
>
> On Friday, January 4, 2013 9:11:28 AM UTC-6, Andy Taylor wrote:
> Hi,
>
> I'm trying to build a module for haproxy which fetches all the configuration 
> data from Hiera to populate the haproxy config file. I've run into a number 
> of issues though when I try to use hashes. Ideally, I want to use something 
> like this:
>
> haproxy_listeners :
>  "cluster1" :
>   ip : '192.168.0.2'
>   port : '80'
>   servers :
>"server1" :
> ip : '192.168.0.3'
> port : '8080'
>
> So a hash of clusters with each cluster containing a nested hash of servers. 
> Is this possible with Hiera/ERB? It's easy enough to iterate over the first 
> hash, but I can't work out how to extract the contents of the nested hash. Or 
> I might just be approaching this in entirely the wrong way... Any help would 
> be much appreciated.
>
>
> I haven't used the function myself, but this looks like it would be a good 
> case for a define + create_resources(), which I think is part of stdlib. You 
> might need to restructure the hashes slightly, but I think that will be the 
> best approach.
>
>
> Thanks,
>
> Andy
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/puppet-users/-/DPkuzR8Q8soJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Thoughts on roles/profiles class paradigm

[Wolf Noble]

Hi Gang,

My colleagues and I are contemplating refactoring our modules to take advantage 
of the "roles/profiles" paradigm suggested by Craig Dunn in his blog post found 
here:
http://www.craigdunn.org/2012/05/239/

Before we jump feet-first into adopting this paradigm, I thought it a good idea 
to reach out and see what everyone else thinks about this.

We're currently struggling with some problems that this paradigm seems to solve 
quite nicely; but I'm not convinced it's the best abstraction / organization 
paradigm out there.

If you've not read it, I think It's worth the few minutes it takes to read.  
Thanks Craig, for writing it.






This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] ssh::auth and other ways of managing ssh keys

[Wolf Noble]

This is actually a module I would love to see CURATED by PL, as I believe it is 
a great real-world example to demonstrate the current recommendations from 
which many people can learn.

The focus is pretty tight, however it could make a lot of people's lives easier.
Many community members(1)(2)(3) (and I'm sure there are more) have mentioned 
that they've taken the time to improve on the existing module available on the 
(out of date) wiki(4) for their own needs. With some guidance and direction 
those improvements could be merged into a practical and useful example of some 
of the more intricate parts of puppet.

There are a lot of modules out there which have found interesting and creative 
ways to get from point A to point B. That doesn't mean that these are good 
examples to follow.
I'm not asserting that there is always only ONE "right" way to do (something)… 
however there ARE several ways that are certainly NOT the right way, and 
discerning the difference is not always easy.
I have been under the impression that puppetlabs modules are as close to living 
reference material as it gets. I'd like to see more examples out there, as I 
think community modules will show a real increase in both quality, and code 
similarity with a stronger authoritative reference base.

In other words, with a little effort on puppetlabs' part, this could have the 
benefit of
- Really increasing the immediately available sexy that puppet can accomplish 
out of the box
- Further the community's proverbial fishing skill
- Increasing the efficiency of module creation, as there will be more 'trusted' 
examples to start from
- Theoretically, more of the community's modules would become increasingly 
compatable as there is a greater pool of reference material to evolve from. 
This could serve to improve the average quality of modules available.. ergo 
moar win.

Thoughts?
(1) https://github.com/boklm/puppet-sshkeys
(2) https://github.com/vurbia/puppet-sshauth
(3) https://github.com/ashleygould/puppet-sshauth
(4)http://projects.puppetlabs.com/projects/1/wiki/Module_Ssh_Auth_Patterns#detailed-usage

On Jan 15, 2013, at 8:56 AM, nicolas vigier  wrote:

> On Mon, 14 Jan 2013, Ashley Gould wrote:
>
>>
>> I've created a puppet-sshauth repo on github:
>> https://github.com/ashleygould/puppet-sshauth
>>
>> I would very much like to work with others on perfecting this
>> module.  Management of keypairs is really useful.  2 improvements I
>> imagine are using hiera as the keystore and adding ablity to install
>> the same pubkey into multiple user accounts on a single node.
>
> Hello,
>
> I also reworked the ssh::auth module :
> https://github.com/boklm/puppet-sshkeys
>
> The main changes in this version are :
> - allow installing the same pubkey into multipe user accounts
> - allow installing multiple key pairs or pubkeys into one account
> - remove use of exported resources, for simplification
> - renaming resources to create_key, set_client_key_pair and
>   set_authorized_keys instead of key, client, server because I think
>   that's easier to understand
>
> It's not using hiera but it looks like a good idea for an improvement.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Security considerations for basing decisions on facts

[Wolf Noble]

On Jan 22, 2013, at 3:04 PM, jcbollinger  wrote:

>
>
> On Tuesday, January 22, 2013 7:08:09 AM UTC-6, Boyan Tabakov wrote:
> Hello,
>
> Let's consider the scenario when a client node in a puppet environment
> gets compromised.
>
> In case some of the puppet modules make decisions based on agent facts,
> these modules are potentially exposed to abuse from the malicious puppet
> agent.
>
> For example, if a class has:
>
> if $some_fact == 'some value' {
> # deploy some configuration
> }
>
> then the compromised node could send falsified value of that fact to
> obtain configuration that potentially contains secrets (private keys,
> passwords, etc) that was meant only for other nodes.
>
> AFAIK, the only authenticated piece of information that a puppet agent
> passes to the puppetmaster server is the name of the node, as specified
> in the SSL certificate for the agent. However, the value of $fqdn, as
> seen in a manifest / class on the puppetmaster seems to be based on the
> agent-supplied fact 'fqdn'.
>
> Having said that, then can the value of $hostname be trusted to come
> from the identity in the agent's SSL certificate? What are best
> practices for ensuring that a compromised agent can't access
> configuration meant for different nodes?
>
> Are an ENC or external data sources (Hiera) designed to provide trusted
> puppetmaster-side metadata for nodes? Is that the way to go?
>
>
>
> You are correct that that only the identity of the client node is 
> authenticated by Puppet, and even that only insomuch as the client can be 
> relied upon to protect its SSL certificate.  The $hostname fact cannot be 
> relied upon to convey that information, as it doesn't in any sense need to be 
> the same thing; you're looking for $certname.  It is, however, $certname (not 
> $hostname) by which a node block is selected and/or an ENC queried, so 
> Puppet's architectural foundation is secure in that regard.
>
> You are also right that a compromised client can, in principle, falsify the 
> fact values presented to the master in an attempt to make it divulge secret 
> information.  Whether the master might actually divulge anything is a 
> function of the manifests with which site administration has configured it.  
> In other words, that's a question of how Puppet is used, not of the 
> fundamental security of Puppet itself.
>
> To the extent that you want to record server-side node data, I think hiera is 
> the way to go.  I prefer that to encoding data in an ENC or in your 
> manifests, but those are some of the other options.  All of those are secure 
> to the extent that the master itself is secure, though I wouldn't say that 
> any of them were designed specifically as a secure alternative to node facts.
>
>
> John
>
Several months ago I created a feature request which basically requested the 
ability to flag certain facts as 'should never change' and have the ability to 
trigger different behaviors in on the master if $node delivers its facts with 
those items different…

https://projects.puppetlabs.com/issues/13934


if a node reports memory changed, you might want to send an email (IE: a dimm 
failed, the box panic'ed and rebooted, and now has less memory). This could be 
done with other methods and tools, this feature doesn't need to be implemented 
to facilitate that (nor is it necessarily the best tool for the job), but if a 
node reports that it's fqdn, or  '$proprietary_fact' is now different, you may 
want the master to full-stop on catalog compilation and flag the node as 
problematic and notify you, as someone may be doing something nasty.

you can also use an enc and base lookups off of $certname, as you can trust 
that you signed that cert at some point in time (assuming you don't have auto 
signing enabled) and so that should be trusted as legitimate.
if you have auto-signing enabled though, this could give someone a path into 
nefariousness.

W



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] puppet + openscap / hardening

[Wolf Noble]

Hi All,

I noticed that a few years back, someone from Puppet Labs (well Reductive Labs 
at that time) reached out to the openscap list in an attempt to collaborate on 
puppet modules:
https://www.redhat.com/archives/open-scap-list/2010-March/msg0.html

it seems like the aqueduct project is/was working on a similar 'harden through 
puppet modules' approach: https://fedorahosted.org/aqueduct/  but their site 
seems to have not been updated much in the past 10 months.

Is anyone currently working with either of these, or something else in 
combination with puppet modules? I've seen a github module or two, but nothing 
seems particularly current..









This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Best practice to share variable values among nodes

[Wolf Noble]

On Jan 30, 2013, at 4:52 AM, Sylvain Mougenot 
 wrote:

> Hello, I'm new to puppet using a puppet-master. And I couldn't figure out 
> what's the best practice I need.
>
> My context :
> - puppet-master with a puppet dashboard is setup and running
> - few modules are ready and fully fonctionnal (tested using vagrant and 
> "puppet apply")
> - there are some nodes in different "zone" (such as dev, QA, preprod, prod, 
> ...)
>
> In fact,
> I've some shared resources in a zone :
> - SQL data-base
> - Mail server
> - ...
> And my apps are running in several nodes (for the same zone) :
> - one node as the front-end role
> - another as the back-office role
> - 
> So I'd like to setup the configuration variables in one place (by zone) and 
> reuse it among nodes in the same zone.
> (Obviously, every node as some specific configurations)
>
> My question is :
> - How can I share some variable svalues among nodes (like those in the same 
> zone for exemple)?
>
> What to do ?
> - I tryed to put the zone specific variables in a dedicated configuration 
> file andimport it in the relevant nodes. But this didn't worked telling me 
> that I redefined variable (as soon as I've several zones)
> - Should I create a template node by zone with thoses common varaibles?
> - Is there any other way to do?
>
>
> Sample files are below:
>
> Sample class :
> class p2es::plateforme_stockage(
> $env  ='integration',
> $yumrepo_host ='10.10.25.5',
> $version  =undef,
> $ensure   =undef,
> $rwpwd="admin",
> $ropwd="reader",
> $probepwd ="probe",
> $bddhost  ="10.10.25.23",
> $bddlogin ="l_ps",
> $bddpwd   ="l_ps",
> $mailhost ="smtp.XXX.fr",
> $mailto   ="dev-p...@xxx.fr",
> $mailfrom ="dev-p...@xxx.fr"){
>
> # Repo YUM
> class{ p2es::repo:
>   env  => $env,
>   yumrepo_host => $yumrepo_host
> }
> 
>
> Sample node :
> node /^.*ps.*preprod.*$/ inherits base {
>
>   # Partie de la conf mutualisée
>   import '../configuration/p2es_ps_conf_preprod'
>
>   # indiquer l'environnement cible
> $env= 'preprod'
>
> # Le soft
> class{ p2es::plateforme_stockage:
> env   => $env,
> yumrepo_host  => $YUM_REPO_HOST,
> version   => $PS_VERSION,
> ropwd   => $JMX_RO_PWD,
> rwpwd   => $JMX_RW_PWD,
> probepwd=> $PSI_PROBE_PWD,
> bddhost => $BDD_HOST,
> bddlogin=> $BDD_LOGIN,
> bddpwd  => $BDD_PWD,
> mailhost=> $MAIL_HOST,
> mailto  => $MAIL_TO,
> mailfrom=> $MAIL_FROM
> }
> }
>
> Sample configuration :
>   $YUM_REPO_HOST="10.10.25.5"
>   $DATASRC_HOST="10.10.25.23"
>   $DATASRC_LOGIN="l_pe"
>   $DATASRC_PASSWORD="l_pe"
>   $MONGODB_HOST="10.10.25.23"
>   $MONGODB_LOGIN=""
>   $MONGODB_PASSWORD=""
>   $PS_HOST="10.10.25.39"
>   $PS_LOGIN="admin"
>   $PS_PASSWORD="adminspassword"
>   $CAS_VALIDATE_URL=""
>   $CAS_LOGIN_URL="adminspassword"
>   $CAS_LOGOUT_URL="adminspassword"
>   $SECURITY_WS_URL=""
> ...
>
> Thank you for your help
>
Hi Sylvain,



Check out hiera. It contains loads of awesome, and should allow you to feed the 
nodes relevant variables for each zone.

http://projects.puppetlabs.com/projects/hiera
https://github.com/puppetlabs/hiera


HTH

W




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Migration with Puppet -- A way to profile machines for module creation?

[Wolf Noble]

On Jan 30, 2013, at 2:56 PM, Jason Cochard 
 wrote:

> Hello all,
>
> We are in the process of moving our data center from one city to another city 
> (far away).  This won't be a physical move -- we are simply bringing up 
> equivalent machines in the new location and then configuring them to match.  
> Great job for puppet, right?
>
> My question is, other than manually going through a machine to find all 
> applications, versions, config files, services, etc., does anyone know of a 
> tool that does a good job of gathering that information.  The idea would be 
> to build puppet modules based off of that.
>
> I'd like to avoid:
> rpm -qa >> installed packages.txt
>
> There is definitely an opportunity to discuss each machine with a subject 
> matter expert, which will be a primary step, but I'd like to come to that 
> discussion with some information that we can filter through.
>
>
> Many thanks,
> Jason


Hi Jason,


I've not used it (yet) but a tool I was researching for just this need today 
can be found here: https://github.com/devstructure/blueprint

I suspect there are others on the list who have used this tool and could 
provide you with some feedback on it…



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Certificate nightmares

[Wolf Noble]

Did you try removing the cert from a node and seeing if that changes the 
behavior? you removed the certs from the master, but the node still thinks it 
has a valid cert maybe?




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Problems getting rspec testing working in OSX?

[Wolf Noble]

Hey Gang,

Running into a weird error when trying to follow puppetlabs' blog:
https://puppetlabs.com/blog/the-next-generation-of-puppet-module-testing/

I'm running 10.8.2, using default ruby, in an attempt to make my home env a 
little more sane, (ran into weird rbenv issues at work, which I won't go into 
here)

The google tells me not a whole lot.  Appreciate any help anyone can offer. I 
had the same error before I installed puppet from gems, suspected that 
installing the gem might help, but no; no change:

http://pastie.org/private/b34pv87osbefarl77j5m5g

kiera:apache loiosh$ gem list


*** LOCAL GEMS ***



diff-lcs (1.2.1)
facter (1.6.17)
metaclass (0.0.1)
mocha (0.13.2)
puppet (2.7.20)
puppet-lint (0.3.2, 0.1.13)
puppet-module (0.3.4)
puppetlabs_spec_helper (0.4.1)
rake (10.0.3)
rspec (2.13.0)
rspec-core (2.13.0)
rspec-expectations (2.13.0)
rspec-mocks (2.13.0)
rspec-puppet (0.1.6)


kiera:apache loiosh$ pwd
/etc/puppet/modules/apache

kiera:apache loiosh$ rake spec
HEAD is now at 9a06f11 Merge branch '4.x'
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -S rspec 
spec/classes/apache_spec.rb --color
FF.F


Failures:



1) apache On a Debian OS with no package name specified


Failure/Error: should contain_package('httpd').with( { 'name' => 'apache2' } )
 NoMethodError:


undefined method `contain_package' for 
#


# ./spec/classes/apache_spec.rb:13



2) apache On a RedHat OS with no package name specified


Failure/Error: should contain_package('httpd').with( { 'name' => 'httpd' } )
 NoMethodError:


undefined method `contain_package' for 
#


# ./spec/classes/apache_spec.rb:26



3) apache With a package name specified


Failure/Error: should contain_package('httpd').with( { 'name' => 'apache' } )
 NoMethodError:


undefined method `contain_package' for 
#


# ./spec/classes/apache_spec.rb:51


Finished in 0.00107 seconds
4 examples, 3 failures


Failed examples:


rspec ./spec/classes/apache_spec.rb:12 # apache On a Debian OS with no package 
name specified
rspec ./spec/classes/apache_spec.rb:25 # apache On a RedHat OS with no package 
name specified
rspec ./spec/classes/apache_spec.rb:50 # apache With a package name specified
rake aborted!
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -S rspec 
spec/classes/apache_spec.rb --color failed
/Library/Ruby/Gems/1.8/gems/rspec-core-2.13.0/lib/rspec/core/rake_task.rb:156:in
 `run_task'
/Library/Ruby/Gems/1.8/gems/rspec-core-2.13.0/lib/rspec/core/rake_task.rb:124:in
 `initialize'
/Library/Ruby/Gems/1.8/gems/rspec-core-2.13.0/lib/rspec/core/rake_task.rb:122:in
 `send'
/Library/Ruby/Gems/1.8/gems/rspec-core-2.13.0/lib/rspec/core/rake_task.rb:122:in
 `initialize'
/Library/Ruby/Gems/1.8/gems/puppetlabs_spec_helper-0.4.1/lib/puppetlabs_spec_helper/rake_tasks.rb:102
Tasks: TOP => spec_standalone
(See full trace by running task with --trace)
kiera:apache loiosh$



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] LSB Fact resolution in the absence of -lsb package

[Wolf Noble]

Hi there,

in house, we rely on the lsb facts:
lsbdistcodename, lsbdistdescription, lsbdistid, lsbdistrelease, and 
lsbmajdistrelease

all of which are essentially derived from the 
/etc/${distro-specific-release-file} and don't _really_ need the lsb packages 
(and the associated bloat) installed.

I'd like to come up with a good way to allow these facts to exist while 
streamlining our systems.
I see a few different approaches, and thought Id ask for community input on the 
best solution before just picking a direction and running with it.


1) some idea I've not thought up. (I'm sure there's a few of them)



2) distribute a script to derive this info. /opt/puppet/bin/lsb_release_lite or 
something, and in the absence of lsb_release (the binary that facter turns to 
to generate this information) facter asks this script.

PRO: Minimal changes to existing facts.
PRO: Adds "robustness" while keeping the os-specific code out of the facts.

CON: Another script to maintain in puppet.
CON: can't override what lsb_release provides on edge OSes with funky lsb vaues

2A) distribute as part of PE/Puppet:
  PRO: More immediately available sexy.
  CON: More stuff distributed as part of PE/Puppet.

2B) distribute as supplementary module on forge:
 PRO: Outside of puppet.  / product distance / resisting scope creep.
 CON: Lack of visibility/awareness/immediately available sexy.



3) adjust the facts to derive the data in the absence of the binary.

PRO: Additional "robustness".

CON: moar bugs in facter! more complicated facts which could slow execution 
time (minimally) if not written properly.
CON: can't override what lsb_release provides on edge OSes with funky lsb vaues



4) distribute additional facts (negatively weighted) to provide this 
information in the absence of the binary.

PRO: Everything is derived from facts, as opposed to an external script.
PRO: Have a means to override funky edge OSes if desired.

CON: The worst parts of 3, with additional confusion.

4A )  distribute them in facter core
  PRO: More immediately available sexy..
  CON: Where does 'core' end?

4B) distribute as forge module
  PRO: not part of core.
  CON: not part of core.


thoughts?



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: LSB Fact resolution in the absence of -lsb package

[Wolf Noble]

Hi John,

Thanks for taking the time to respond :) Replies inline.

On Mar 20, 2013, at 8:01 AM, jcbollinger 
 wrote:

> On Tuesday, March 19, 2013 2:27:22 PM UTC-5, Wolf Noble wrote:
> Hi there,
>
> in house, we rely on the lsb facts:
> lsbdistcodename, lsbdistdescription, lsbdistid, lsbdistrelease, and 
> lsbmajdistrelease
>
> all of which are essentially derived from the 
> /etc/${distro-specific-release-file} and don't _really_ need the lsb packages 
> (and the associated bloat) installed.
>
>
> Well, that's a matter of interpretation.  The lsb packages typically ensure 
> that the system has all the pieces required for compliance with the LSB 
> specifications, and the facts describe details of the compliance, such as 
> which version of LSB the system complies with.  If your systems are not, in 
> fact, fully LSB-compliant, then it is of questionable wisdom to suggest 
> otherwise to Puppet.

the lsbrelease fact certainly lists what parts of the LSB spec and additional 
lsb modules the node is compliant with. I am not suggesting altering the output 
of that.

The remainder of the facts seem to consistently correlate with pieces from the 
distro specific release file. I've not found a node which does not (although 
one may exist).
Looking at the lsb_release script, I see it referencing /etc/lsb-release and 
/etc/[distro]-release and returning what it finds.
This enhancement didn't seem too far out of line with what's going on behind 
the scenes in the first place.



> I'd like to come up with a good way to allow these facts to exist while 
> streamlining our systems.
> I see a few different approaches, and thought Id ask for community input on 
> the best solution before just picking a direction and running with it.
>
>
> If you do not want to require your systems to be fully LSB-compliant, then 
> your Puppet manifests should not rely on LSB-associated facts.  If, on the 
> other hand, you need to rely on LSB facts, then you should ensure your 
> systems LSB-compliant.  Certainly if you rely on third-party modules that in 
> turn require LSB-associated facts for correct operation then you have to 
> assume that your nodes must be LSB-compliant.

Well, the motivation behind this is easy collaboration. All my modules really 
care about is lsbmajdistrelease and lsbdistid/osfamily/operatingsystem.
Stepping back a bit though, the underlying question is what's the best way to 
determine what major version of the OS is running.

lsbmajdistrelease is currently part of core, and one could expect it to exist 
on any (linux) node that has puppet installed, unlike a custom site-specific 
fact which would work fine for us, but not so well collaboratively.

Expanding the listed lsb facts' functionality to provide the information that 
can be derived in the absence of the lsb_release script doesn't seem like an 
overstep to me, but I'm happy to concede that there may be a better direction 
to go. I'd be equally satisfied (maybe even slightly happier) if 
operatingsystemmajrelease was added to current facter to accompany 
operatingsystemrelease.

I felt that suggestion might be met with greater resistance, and then there's 
the same problem that depending on osfamily can bring for earlier versions, 
although that problem is becoming less and less of a concern.


I don't want to resort to a regex every time I looked to see what major version 
of $os I'm on. That doesn't seem the most efficient way to go.
I want to remove the requirement for the lsb packages, as that is meeting with 
some understandable resistance.

I'm not opposed to refactoring to include a not-yet-existent 
operatingsystemmajrelease fact. I want to solve this in a fashion that is … 
least likely to bite me or someone else later. :)

Do you still feel expanding lsbdistcodename lsbdistdescription lsbdistid 
lsbdistrelease and lsbmajdistrelease (and not touching lsbrelease) is more 
likely to lead to problems?

What would you suggest as an alternative?


>
> John
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure el

Re: [Puppet Users] How to make sure my common module executes before all other ones

[Wolf Noble]

Hi Chris,

Take a look at run stages
http://docs.puppetlabs.com/guides/language_guide.html#stages
They make it a little easier to perform some coarse ordering.

additionally, you can use PuppetLabs stdlib module and take advantage of the 
anchor pattern sparingly.
Here's a good example of its use:
https://github.com/adrienthebo/puppetlabs-mrepo/blob/master/manifests/init.pp

Hope that helps!

W


On Mar 20, 2013, at 5:04 PM, Chris Handy 
 wrote:

> I am running puppet 3.1.1 and have a site.pp which roughly looks like this
>
> site.pp:
> node basenode {
>   include common
> }
>
> node 'server1' inherits basenode {
>   include role::appserver
> }
> node 'server2' inherits basenode {
>   include role::webserver
> }
>
> And my common module includes lots of different types of classes for creating 
> base directories, adding in users/groups, setting up LDAP, mcollective, etc.. 
>  So my issue is how to make sure that the common module runs before the roles 
> listed in my node definitions.  I know that I could write out
>
> node 'server1' inherits basenode {
>   class{'common': } ->
>   class{'role::appserver': }
> }
> node 'server2' inherits basenode {
>   class{'common': } ->
>   class{'role::webserver': }
> }
>
> but I am trying to think of a better way to do this.  Thoughts?
>
> Thanks,
> Chris
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Rake tests for hiera

[Wolf Noble]

What we've been doing here is trying to make all our hiera calls as class 
parameter default values. This allows us to set param values in the unit tests, 
thus bypassing hiera.

This has required some refactoring, but it has the advantage of being a simpler 
test collection to implement.

Does this paradigm not work for you?

On Mar 27, 2013, at 7:13 AM, Nikola Petrov  wrote:

> +1
>
> Last time I tried writing tests, I just gave up because we started using
> hiera
>
> --
> Nikola
>
> On Fri, Mar 22, 2013 at 06:26:09PM +0100, Maarten Thibaut (mthibaut) wrote:
>> Hi,
>>
>> I'm having a hard time figuring out how to make rake spec tests work 
>> correctly with hiera and puppet 3. Should I just give up for now until the 
>> various gems work with puppet 3?
>>
>> --
>> maarten
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>




This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: How do I automagically remove old versions of jar files?

[Wolf Noble]

On Apr 25, 2013, at 9:47 AM, jcbollinger 
 wrote:

> On Wednesday, April 24, 2013 4:24:08 PM UTC-5, Larry Fast wrote:
> I keep running into the following upgrade pattern.
>
> Previous Puppet run declared:
>  file { "my_jar.1.2.3.jar": ... }
>
> New puppet run declares:
>  file {"my_jar.2.4.6.jar": ... }
>
> But the new puppet run doesn't delete the older versions of this jar file.
>
> Is there a standard puppet pattern for removing older versions of jars 
> without explicitly naming each version?
>
> The overall pattern is...
>
>declare resource file {  "my_jar.1.2.3.jar": }
>ensure absent for all older versions of my_jar
>ensure => "1.2.3"  (imaginary code since version is specified in the name)
>only restart service if my_jar.nnn.jar  has changed
>
>
>
> You need to be able to identify the files to remove somehow.  If you don't 
> want to list them individually, then the most automated way to do it would be 
> to manage the directory in which they reside, and use the 'purge' parameter 
> for the directory.  That does require that all the wanted contents of the 
> directory be managed, but you should be able to arrange that one way or 
> another.  For example, if there are unmanaged files that you want to keep, 
> then you could move the managed jar file(s) to a for-purpose, managed 
> subdirectory, and symlink the correct one to its original location.
>
> Alternatively, you can probably come up with an Exec that removes (only) the 
> unwanted files.  That's less in the Puppet spirit, but probably quicker and 
> easier to write (yet maybe also more prone to bugs).
>
>
> John


John's suggestion is definitely the cleanest.

Some shops have a regularly scheduled deployment of a new jar with updated 
content, and like to keep the last version around.
If that is close to your paradigm,  you could also do this with a cron job to 
purge any jar files older than ((2x(deployment delta))+~7 ) days. This would 
give you the ability to keep the current+last in case you need to rollback at 
some point in time.






This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] rspec-puppet testing with puppet $::settings

[Wolf Noble]

Hi Simon,
On Apr 29, 2013, at 7:45 PM, Simon Piette 
 wrote:

> Hi all,
> 
> Any solution for testing variables that depends on settings will be welcome.
>
> Thanks,

I sent this last night from another account, but it didn't seem to go through:




What I've done elsewhere is to make a parameter for, in your case, vardir:


(untested, but close)

Class foo($vardir = $::settings::vardir){
file { "${vardir}/files":
  ensure => directory
}
}


Then in
spec/classes/foo_main_spec.rb:
require 'spec_helper'
require 'puppetlabs_spec_helper/module_spec_helper'
vartest = Puppet.settings[:vardir]
describe 'foo', :type => :class do
  #...
  #Then you can assign vartest as a class parameter to your tests.
end





Hope that helps.

W



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] rspec-puppet testing with puppet $::settings

[Wolf Noble]

Hi Simon,



On Apr 29, 2013, at 23:35, "Simon Piette"  wrote:

> Hi all,
> 
> Any solution for testing variables that depends on settings will be welcome


What I've done elsewhere is to make a parameter for, in your case, vardir:


(untested, but close)

Class foo($vardir = $::settings::vardir){
file { "${vardir}/files":
  ensure => directory
}
}


Then in 
spec/classes/foo_main_spec.rb:
require 'spec_helper'
require 'puppetlabs_spec_helper/module_spec_helper'
vartest = Puppet.settings[:vardir]
describe 'foo', :type => :class do
  #...
  #Then you can assign vartest as a class parameter to your tests.
end

W


=MobileMail=
Please excuse brevity or spelling errors


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] rspec-puppet testing with puppet $::settings

[Wolf Noble]

Hi Simon,

On Tue, Apr 30, 2013 at 12:08 PM, Simon Piette wrote:

> Hi Wolfe,
>
> On Tue, Apr 30, 2013 at 12:05 PM, Wolf Noble  wrote:
>
>> Hi Simon,
>> On Apr 29, 2013, at 7:45 PM, Simon Piette 
>>  wrote:
>>
>> What I've done elsewhere is to make a parameter for, in your case, vardir:
>>
>>
>> (untested, but close)
>>
>> Class foo($vardir = $::settings::vardir){
>> file { "${vardir}/files":
>>   ensure => directory
>> }
>> }
>>
>>
>> Then in
>> spec/classes/foo_main_spec.rb:
>> require 'spec_helper'
>> require 'puppetlabs_spec_helper/module_spec_helper'
>> vartest = Puppet.settings[:vardir]
>> describe 'foo', :type => :class do
>>   #...
>>   #Then you can assign vartest as a class parameter to your tests.
>> end
>>
>>
>>
>>
> That's what I did for this module:
>
> https://github.com/spiette/puppet-selinux/blob/master/manifests/params.pp
>
> But under other circumstances, (a puppet module) I can't do this, I have
> to use the $::settings variable.
>
> Thanks,
>
> Simon
>
>

I suspect what's going on here, is the class you're testing doesn't have
the ability to override the $::settings::vardir variable.
I've found that if I make the relevant variable a parameter to the class in
question, I can override it in the tests in question.

It may be possible to set a different class's parameter to a value from a
test, but I've not found a way.

This has resulted in me making whatever variables I need to override
parameters to the class I'm testing. I'd be curious to hear how others have
accomplished this.

Would you mind showing us the module you're talking about where you were
having problems with this approach? Perhaps the list can offer some input
on other ways to accomplish your needs.

CAVEAT: The statement that I've not seen a better way doesn't mean there
isn't one.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Feedback on module pattern?

[Wolf Noble]

Hi Ken,

I'm happy to give my $.02, FWIW.

I've found immense benefit from the overall paradigm described in Craig
Dunn's blog post here:
http://www.craigdunn.org/2012/05/239/

That paradigm, combined with modules which have all of their variables
placed as module::variable_name parameters which default to
module::params::variable_name allows for much flexibility:

- easy unit test creation. (avoiding trying to get hiera to work with unit
tests made this incredibly attractive to us)

- clear delineation between 'do-stuff' modules and 'implementation of the
do-stuff module in my environment' profiles.

This makes the 'do-stuff' modules more re-usable and generally communally
consumable, as there are as few as possible environment-specific bits in
the 'do-stuff' modules.

Depending on the environment, this can also serve as a line in the sand as
to which modules can be shared with the world and which contain secret
sauce.


This also has the added benefit of creating tiers of complication.
You can allow your more junior people to orchestrate role modules onto
servers, and provision servers.
You can have your intermediate admins write, or improve profile modules.
A select few can work on your do-stuff modules and help fill out other
needs as they arise.

This, again, is just my $.02. I'm sure there are many others whose opinions
are equally as interesting and may contain more relevant suggestions for
your specific implementation.





On Mon, May 6, 2013 at 8:22 PM, Dan White  wrote:

> This looks great.
> Some constructive criticism:
>
> I think “defaults" and “settings” are redundant.
> Use one.
> I kind of like the term “params”, but they all do the same thing.
>
> On May 6, 2013, at 1:25 PM, Ken Coar wrote:
>
> I've been having to write (and modify) a lot of modules lately, and I've
> so far moved to the following pattern.  I'd appreciate comments and
> feedback about my approach, particularly in light of the changes to name
> scoping (all my modules are currently deployed under 2.7).
>
>
>1. mod::defaults (defaults.pp)
>   - does *not* inherit from anywhere
>   - 'include mod::settings'
>   - references module variables with $mod::settings::varname
>2. mod::base (base.pp)
>   - 'inherits mod::defaults'
>   - 'include mod'
>   - 'include mod::settings'
>   - any other things which apply to all classes in the module
>   3. mod::settings (settings.pp)
>   - does *not* inherit from anywhere
>   - has responsibility for resolving and normalising any global or
>   mod() class variables into sane values
>   4. mod (init.pp)
>   - 'inherits mod::defaults'
>   - 'include mod::settings'
>   - imports all $mod::settings:: definitions into the $mod
>   namespace
>   - if it's a multi-function module (*i.e.*, classes may be
>   selectively called out for use), this is all it does.
>   - if it's a single-purpose module, the rest of its work can go here
>   -- or in other classes it includes
>5. all other classes
>   1. 'inherits mod::defaults'
>   2. 'include mod::base'
>   3. does whatever else it's suppposed to do.
>
> The ideas I'm working from are to abstract all the parameter selectors and
> such into one class, resource declaration defaults into another, and the
> module top-level namespace and every-class-needs-this stuff into a third.
> Does this make sense, or is it completely lame?  Or are there better
> patterns (that don't require hiera nor puppetdb) I should consider?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Preparing to install Puppet Dashboard on RHEL 5 with newer MySQL

[Wolf Noble]

Hi Dan,

I've a script here that grabs the mysql 5.5 / 5.6 packages and turns them
into a yumrepo for easier consumption:
https://github.com/wolfspyre/MySQL_Createrepo

it's not perfect, but imho better than grabbing the RPMs manually form
Oracle.



On Wed, May 15, 2013 at 3:24 PM, Dan White  wrote:

> One more thing:
>
> Silly me :P
>
> MySQL-client also to be able to work with the database locally
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> - Original Message -
> From: "Dan White" 
> To: "Puppet Users Mailing List" 
> Sent: Wednesday, May 15, 2013 4:20:48 PM
> Subject: [Puppet Users] Preparing to install Puppet Dashboard on RHEL 5
> with newer MySQL
>
> When I discovered that I could use the PuppetLabs RPM's to install Puppet
> Dashboard on my RHEL 5 Puppet Master, I decided to take the plunge.
>
> The "newest" Red Hat supplied rpm is mysql-server-5.0.95-5.el5_9
>
> We have been using a customized 5.5.x, built from source.
> I wanted to see if I could use RPM's to do this.
>
> I got the latest 5.5.x RPM's from
> http://dev.mysql.com/downloads/mysql/5.5.html
>
> Long story short:  installed the MySQL-server and MySQL-shared-compat
> RPM's and then "yum install puppet-dashboard" did not complain.
>
> Thought I'd share this little How-To with the community.
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] module namespace?

[Wolf Noble]

Hi Matt,

What I've seen done before is to use ${modulename}x for 'wrapper' modules
that give you the ability to stay current with the
forge/release/externally-owned module, but still maintain the necessary
site-spectific-shim code to extend the functionality of the original module
in the ways you desire.

We use the class 'mysqlx' as a place for a few defined types, and as a
namespacing entry point to hiera, which allows us to have  mysqlx::v5,
mysqlx::v55, and  mysqlx::v56 classes which all take the same parameters
that the puppetlabs-mysql class does. These namespacing classes can take
care of loading sane version-specific defaults from hiera for $version of
mysql, and subsequently feeding them to the puppetlabs-mysql module.

I've found this to work reasonably well thus far. Hope that helps.


On Mon, May 20, 2013 at 3:34 AM, Nikola Petrov  wrote:

> Well we had that problem in the past. I now name my modules with a
> prefix for the company first letter so if I was working for puppetlabs
> then I would name the module pmysql. The thing is that most of the time
> I want convenient "wrappers" for the mysql module provided by puppetlabs
> or some third party. This also ensures that if they change the interface
> I have stable defines/classes.
>
> The other way arround this is to put all those things in a single module
> named "site" or "custom" for example.
>
> --
> Nikola
>
> On Thu, May 16, 2013 at 05:10:44PM -0500, Matt Zagrabelny wrote:
> > Greetings,
> >
> > When writing modules are people namespacing them to avoid collisions
> > with puppetlabs' modules?
> >
> > I wrote some (very simple) modules:
> >
> > mysql
> > postgresql
> >
> > that now have namespace conflicts when I am trying to install the
> > puppetlabs modules of the same name.
> >
> > Is there a best practice or style guide that people follow when
> > namespacing their in-house modules?
> >
> > For instance:
> >
> > site::umn::duluth::postgresql
> >
> > ??
> >
> > Thanks for any hints or feedback!
> >
> > -mz
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to puppet-users+unsubscr...@googlegroups.com.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Two resources managing the same file?

[Wolf Noble]

It seems to me that you will be relinquishing puppet's ability to maintain the 
content of the file by doing this. If that's acceptable, use the replace 
parameter to only have puppet maintain the initial config and allow the file to 
be changed outside puppet moving forward. If that's not acceptable, then the 
location from which the template values are derived must be updated in 
lock-step with the changes you make externally to puppet. This may be possible 
programmatically depending on your scenario, but it feels like the wrong 
direction to go to me.

I might approach this with a wrapper class that has awareness of resource A and 
resource B, and feeds them both the proper parameters to satiate their needs 
when cohabitating.

Alternatively, I might stub out a conf.d style config directory and provide to 
resource B a handle into resource A's config file through an included config 
file owned by resource B.




=MobileMail=
Please excuse brevity or spelling errors

On May 20, 2013, at 11:39, Schofield  wrote:

> Given a configuration file that is initially managed by a template in File 
> resource A .  Resource B interacts with a middleware product through its 
> published admin API which causes changes within File resource A.  Is there 
> anyway, through custom provider code for resource B to tell resource A that 
> its changes affect the configuration file so that when the state of resource 
> A is checked it accounts for the changes made by B?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppet pull code from svn

[Wolf Noble]

Hi Dominic,

take a look at the vcsrepo module:

http://forge.puppetlabs.com/puppetlabs/vcsrepo

this should likely get you everything you need.



On Mon, May 20, 2013 at 2:45 PM, DJames  wrote:

> How can i setup puppet  to pull code from A current SVN server?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppet agent errors for non included module.

[Wolf Noble]

Hi JJ,

I've seen this happen when class dependencies are placed outside the
specific class' scope, ie:

# default.pp
#
#
Anchor['my_prereq::end'] -> Class['default']
class{ 'default':
  notice 'default'
}

I've only seen this occur with anchors, but it's entirely possible it
happens with other resources too..


I've seen a node which uses class my_prereq, and class default run, and
then another node run with neither of those classes in it's catalog, but
the error about the unsatisfied relationship still displayed…

I've not seen any other instances of this occur, but there may be other
reasons for it to happen.
HTH.

W



On Wed, Jun 12, 2013 at 3:52 PM, Jeremiah Jester
wrote:

> Does anyone know why i would get a module error for my 'base' module that
> I'm not even including for a node?  I'm explicitly NOT include the 'base',
> yet puppet-client-t2 still errors when i pull it in. Snips from both are
> below. Any ideas why this would happen?
>
> Thanks,
> JJ
>
> 
>
> site.pp file
>
> [root@puppet-master-t1 puppet]# cat manifests/site.pp
> node 'puppet-client-t1' {
> include base
> include base::firewall
> }
> node 'puppet-client-t2' {
> include monitoring
> }
>
> puppet agent run on client...
>
> jjest@puppet-client-t2 puppet]$ su -c "puppet agent -t"
> Password:
> Info: Retrieving plugin
> Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> Info: Loading facts in
> /var/lib/puppet/lib/facter/iptables_persistent_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/ip6tables_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb
> *Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find data item rsfw_rules in any Hiera data file and no
> default supplied at /etc/puppet/modules/base/manifests/firewall.pp:1 on
> node puppet-client-t2.mcis.washington.edu*
> *Warning: Not using cache on failed catalog*
> *Error: Could not retrieve catalog; skipping run*
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] The handy Grail of Modules Standards

[Wolf Noble]

I'd like to say I really like the intent behind this.

Yes, a name is important. So is continuity. I believe the underlying goal is to 
provide a collection of reference material. Once the skeleton of this material 
is generally agreed upon, it can be used as guidelines to the community for how 
to implement a common set of functionality with performance, and the greatest 
quantity of interoperability in mind. 

How is this a bad thing?

The demonstrated example shows plenty of well thought out functionality. How 
might we better implement these functional knobs and levers?

Lets go beyond the fact that the only reason we call knobs, switches, and 
levers what we do is that communally we agreed that this long-ish thing 
protruding from this surface over here should be called a lever, that this 
definitive state toggle be called a switch, and this round, grabbable twisty 
thing here should be called a knob. Names are important, but not just because 
they're names, they're icons of functionality. 

Consistently referring to a lever as a lever provides more intuitive context, 
but doesn't change how it operates. Does it do the same thing if you call it a 
widget? Sure! Does it help with the goal of communally establishing conventions 
of grounding and interoperability? Not so much.

So, on the one hand, no, this conversation is not purely about naming 
conventions. On the other, I don't think that's the point to focus on.

I can absolutely see the value in a few sets of versioned "interoperability 
reference" modules, which provide one a good working model of how to provide 
specific bits of functionality in as flexible a manner as necessary.

There are several different good module paradigms out there. I feel that 
fragmentation of design and implementation hinders the community more than a 
little bit. It confuses it, at the very least.

I do not believe a 'one-size-fits-all' paradigm would do us all that much good 
here either. You'd likely always be one side or the other of too much 
scaffolding for simple modules, and not enough flexibility for complicated ones.

I believe this means a few levels of module complexity would need to be 
modeled. Then the transitions between those states would be more 
straightforward. Someone could expand the functionality of your module with 
greater ease and consistency.

I would love to see other examples which provide similar levels of implemented 
functionality.

(... (:(: and then the bikeshedding and performance holy wars can really get 
going :):) ...)

What other good ways are there to easily write unit tests to validate the 
different behaviors of a module without parameters? 
Facts?
Limited scope/functionality subclasses?


This is a very exciting subject of conversation. I am thankful to everyone 
participating in it for their thoughts and contributions.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppet agent errors for non included module.

[Wolf Noble]

It is incorrect to make that relationship declaration (via the chain
> operator) if there are any nodes that do not declare the specified anchor,
> because top-level declarations in *any* manifest file apply to all
> nodes.  It is poor practice to make declarations at top level like that
> other than class and defined-type definitions, however, except sometimes in
> site.pp and manifests 'import'ed by it.  When they appear in other places,
> Puppet may or may not see them during any given catalog run, but you must
> not assume that Puppet will fail to see them under any given circumstances.
>

I absolutely agree. I was not recommending this as something to do, merely
stating that I've seen the exhibited behavior in that circumstance.



>
> Thus, manifest files that are intended to be autoloaded should contain
> exactly one thing at top-level: the definition of the class or defined type
> that is the autoloading target.
>
>
> On the other hand, I would be surprised if a top-level dependency
> declaration caused a referenced class to be declared when it otherwise was
> not declared.  That's not an issue in the example because a declaration of
> the class involved occurs in the same manifest, at the same level as the
> chain, so the class (but not necessarily the anchor) will always be
> declared if the relationship is declared.  That could point to the actual
> problem, though: there may somewhere be just such a top-level declaration
> of class 'base::firewall'.  Otherwise, it must be that class 'monitoring'
> declares class 'base::firewall', either directly or indirectly.
>

I have actually seen an error arise on a node with the cause being an
ordering declaration occurring in a non-included class file, but outside
the scope of that class. I suspect it may be a bug, however I've only
encountered it while utilizing this antipattern.


>
> John
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] most current method of configuring cisco (and force10?) devices

[Wolf Noble]

Hey Gang,

I've been asked to explore the landscape of network device management via
puppet.

in particular, I'm looking to support cisco, and force10 switches.

I know about the network device system, I'm wondering if that's the way to
go for both cisco and force10, or if there's a better way for one or both?

I've seen the Juniper netdev module, but haven't the gear to play with it.

I'm continuing my research, but figured it wouldn't hurt to concurrently
ask the herd for input.


Thanks in advance!
W

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: How to make a package dependant on a class for the repository.

[Wolf Noble]

Hi Stack,

here's an example:
https://github.com/wolfspyre/puppet-mysqlx/blob/master/manifests/v55.pp

in this class I create a pair of bookend anchors, and then shove a yumrepo,
and a file resource between them.


Your other classes/resources can then declare a relationship to the end
anchor to establish the relationship.

some gotchas:

- Make sure to include the class declaring the anchor into the class which
has the dependency.
- Remember that you've just permanently established a relationship between
these two classes. This is important to know, and can take you in a
direction that leads to complications down the road.

- It is common to have specific software classes depend on your base-type
'i set up my package repositories, and some other core things that will
happen most everywhere' resources. The caveat here is that modules you
share with the world will NOT have that base class, and as such may have
dependency issues.

- Use the anchor pattern as sparingly as possible. Consider having to use
it like having to resort to an exec. It is occasionally the right tool for
the job, but not usually.

Hope that helps.




On Wed, Jun 26, 2013 at 7:38 PM, Stack Kororā  wrote:

> Thank you very much Joe. I think this exactly the path that I need but I
> am having trouble with it.
>
> As I said, I have multiple systems that this repo class watches over.
> Thus, for one of several instances, I have things like:
>
> if $osfamily == 'RedHat' {
> class {'repos::epel': }
> }
>
> The sub-class epel.pp file configures the EPEL repository for the RHEL,
> Scientific, CentOS, Fedora, ect. However, trying to anchor that caused a
> bunch of odd errors (it is entirely possible I didn't do it right).
>
> I also have the main configuration in a large case statement that manages
> the main configuration in sub-classes for all operating systems (thus only
> some sub-classes are ever called). This too is causing me some issues.
>
> I think it is because I don't fully understand how the anchor is supposed
> to work and the examples listed are a bit simplistic with both a require
> and a notify. But what if I need it to require only if it matches certain
> parameters?
>
> I poked around in a few other modules seeing if I could find more
> examples, but came up empty.
>
> Does anyone know where I can view more examples/code for some guidance?
>
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Is it possible to pass extra flags to Puppet via rspec?`

[Wolf Noble]

Hi Amos,

Here's what I've done:

in spec/spec_helper.rb:

Puppet.settings[:confdir] = "spec/fixtures"

then in the class I was working on, I made a parameter:


class foo(
  $puppetdir = $settings::confdir
  ){
…
}


then in that class's spec test:

require 'spec_helper'
require 'puppetlabs_spec_helper/module_spec_helper'
foo = Puppet.settings[:confdir]

describe 'foo', :type => :class do

let (:params) do { 'puppetdir' => foo } end


…


it stands to reason that a similar method could be employed to feed your
function, but I'm not certain.






On Wed, Jun 26, 2013 at 9:23 PM, Amos Shapira wrote:

> Hello,
>
> I'm writing my first puppet function rspec test and am having a problem
> which I don't see how to solve.
>
> The function (and the test) involve access to files through the File
> Server. In order for the function (and the test) to work I need to pass
> "--fileserverconf=fileserver.conf" parameter to Puppet.
>
> So far I haven't found a way to do that.
>
> If I understand the rspec-puppet source at
> https://github.com/rodjek/rspec-puppet/blob/master/lib/rspec-puppet.rbcorrectly
>  then the list of parameters I can pass is limited to the ones
> mentioned in lines 16-22. Am I right?
>
> Does anyone know how can I pass other parameters, or otherwise affect
> Puppet's configuration to set this value?
>
> Thanks,
>
> --Amos
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Using Puppet for downgrading Varnish (circular dependency)

[Wolf Noble]

Hi Stefan,

I've run into similar issues before… I don't have module code handy, but
what I ended up doing was creating an exec which performed something
similar to:

exec{'nuke_pesky_pkg':
  command => 'rpm -e $package; touch /etc/package.removed',
  creates => '/etc/package.removed'
}

which I run before the package declaration..

I imagine others might have better suggestions?





On Fri, Jun 28, 2013 at 9:11 AM, Stefan Pommerening  wrote:

> Hi all,
>
> I am trying to use puppet (2.7.18) for downgrading varnish cache on Centos
> Linux (6.3).
>
> Unfortunately there are two varnish RPMs (which seem to have circular
> dependencies):
>
> varnish-3.0.4-1.el6.x86_64
> varnish-libs-3.0.4-1.el6.x86_64
>
> When using "ensure" for downgrading I get a bunch of errors:
>
> err: /Stage[main]/Varnish/Package[varnish-libs]/ensure: change from
> 3.0.4-1.el6 to 3.0.3-1.el6 failed: Could not update: Execution of
> '/usr/bin/yum -d 0 -e 0 -y downgrade varnish-libs-3.0.3-1.el6' returned 1:
> Error: Package: varnish-3.0.4-1.el6.x86_64 (@varnish-3.0)
>Requires: varnish-libs = 3.0.4-1.el6
>Removing: varnish-libs-3.0.4-1.el6.x86_64 (@varnish-3.0)
>varnish-libs = 3.0.4-1.el6
>Downgraded By: varnish-libs-3.0.3-1.el6.x86_64 (varnish-3.0)
>varnish-libs = 3.0.3-1.el6
>Available: varnish-libs-2.1.5-1.el6.i686 (EPEL-RHEL)
>varnish-libs = 2.1.5-1.el6
>Available: varnish-libs-3.0.3-0.rc1.el6.x86_64 (varnish-3.0)
>varnish-libs = 3.0.3-0.rc1.el6
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
>  at
> /etc/puppet/environments/development/modules/varnish/manifests/init.pp:8
> err: /Stage[main]/Varnish/Package[varnish]/ensure: change from 3.0.4-1.el6
> to 3.0.3-1.el6 failed: Could not update: Execution of '/usr/bin/yum -d 0 -e
> 0 -y downgrade varnish-3.0.3-1.el6' returned 1: Error: Package:
> varnish-3.0.3-1.el6.x86_64 (varnish-3.0)
>Requires: varnish-libs = 3.0.3-1.el6
>Installed: varnish-libs-3.0.4-1.el6.x86_64 (@varnish-3.0)
>varnish-libs = 3.0.4-1.el6
>Available: varnish-libs-2.1.5-1.el6.i686 (EPEL-RHEL)
>varnish-libs = 2.1.5-1.el6
>Available: varnish-libs-3.0.3-0.rc1.el6.x86_64 (varnish-3.0)
>varnish-libs = 3.0.3-0.rc1.el6
>Available: varnish-libs-3.0.3-1.el6.x86_64 (varnish-3.0)
>varnish-libs = 3.0.3-1.el6
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
>  at
> /etc/puppet/environments/development/modules/varnish/manifests/init.pp:8
>
> Whatever I try I do not succeed. My goal is to have a rock-solid puppet
> manifest for switching between varnish versions in development environments
> without having to reinstall the whole VM.
>
> Using yum to downgrade both packages at the same time (and being able to
> resolve circular dependencies) succeeds:
>
> /usr/bin/yum -d 0 -e 0 -y downgrade varnish-libs-3.0.3-1.el6
> varnish-3.0.3-1.el6
>
> Any idea how I can solve this?
>
> Kind regards,
>   Stefan
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] scope for templates that is called from a class that includes the class that calls the template.

[Wolf Noble]

Hi Daniel,


What I've done in the past is:

Foo.erb
<% foobar = scope.lookupvar('::somefact')
  othervar   = scope.lookupvar('class::variable')
lastvar = scope.lookupvar('myclass::myvar')
fqdn = scope.lookupvar('::fqdn')
-%>
#this file generated automatically by puppet for <%=fqdn%>
#manual changes will be reverted


<% if foobar -%>
Foo = <%=foobar%>
<%end-%>
...  ...


Not sure if there's a better way, but I'm inter the impression (correct me if 
I'm wrong here?) that scope.lookupvar will do the right thing as often as is 
possible.

HtH!

Wolf
MobileMail

> On Jul 1, 2013, at 19:07, Daniel Jung  wrote:
> 
> hi,
> 
> trying to understand the scope for templates -- after reading 
> http://docs.puppetlabs.com/guides/templating.html, got a question about the 
> following,
> 
> 
> class test::foo {
> 
>  file {
>
> 
> 
>content => template ("footemplate.erb"), 
>  }
> 
> }
> 
> 
> class test::foo2 {
>   $var = blah, 
>   class {'test::foo' : 
>   } 
> }
> 
> so the question is if footemplate.erb uses variable $var as @var, is there a 
> need for me to pass it as a argument within class {'test::foo': var => $var ? 
>   My interpretation of templating.html is that all the variables that are in 
> scope of the called class would be passed/available in the template hence i 
> would need to pass it as an argument. 
> 
> Can anyone shed some lights on this?
> 
> Thanks 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet Razor doesn't recognize Scientific Linux?

[Wolf Noble]

It seems like the match is 'Scientific' not 'Scientific Linux' but I'm nowhere 
near a computer to check

MobileMail

> On Jul 10, 2013, at 19:36, Stefan Lasiewski  wrote:
> 
> I am using Scientific Linux 6.4. Scientific Linux is a derivative of Red Hat 
> Enterprise Linux, similar to CentOS.
> 
> I am following the instructions at 
> http://forge.puppetlabs.com/puppetlabs/razor to install Puppet Razor on my 
> new Puppet Master node. The instructions say:
> 
> Installation
> 
> Install puppetlabs-razor module and dependencies into module_path:
> 
>  $ puppet module install puppetlabs-razor
> Preparing to install into /etc/puppet/modules ...
> Downloading from http://forge.puppetlabs.com ...
> Installing -- do not interrupt ...
> /etc/puppet/modules
> ...
>  
> Puppet apply, apply test manifests:
> 
> puppet apply razor/tests/init.pp 
> 
> However, when I try this I get an error:
> 
> root@sl6:/etc/puppet/modules # puppet apply razor/tests/init.pp
> Class nodejs does not support Scientific at 
> /etc/puppet/modules/nodejs/manifests/params.pp:55 on node sl6.example.org
> 
> I thought that the actual cause of this error was line 26 in 
> /etc/puppet/modules/nodejs/manifests/params.pp , which includes RHEL, CentOS 
> & Oracle Enterprise Linux, but not Scientific Linux:
> 
> class nodejs::params {
> 
>   case $::operatingsystem {
>   ...
>   ...
> 
> 'RedHat', 'CentOS', 'OEL', 'OracleLinux': {
>   $majdistrelease = $::lsbmajdistrelease ? {
> ''  => regsubst($::operatingsystemrelease,'^(\d+)\.(\d+)','\1'),
> 
> 
> I tried to fix this by modifying line 26 to include strings for Scientific 
> Linux:
> 
> #'RedHat', 'CentOS', 'OEL', 'OracleLinux': {
> 'RedHat', 'CentOS', 'OEL', 'OracleLinux', 'Scientific Linux', 
> 'Scientific': {
>   $majdistrelease = $::lsbmajdistrelease ? {
> ''  => regsubst($::operatingsystemrelease,'^(\d+)\.(\d+)','\1'),
> 
> But I get the same error:
> 
> root@sl6:/etc/puppet/modules # puppet apply razor/tests/init.pp
> Class nodejs does not support Scientific at 
> /etc/puppet/modules/nodejs/manifests/init.pp:59 on node sl6.example.org
> 
> 
> Any ideas how to get Razor to recognize Scientific Linux?
> 
> -= Stefan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: How do I set global noop?

[Wolf Noble]

Hi Sam,

it somewhat depends on your requirements, but if you have a window during
which changes are not permitted, end of story, what about a cronjob to set
it to false at a particular time?

or in the same run that you set noop to true, require an exec which creates
an at job to re-enable at a specific time?

you could go full tilt maverick, and have a cron job which does a curl to a
known server asking if the value should be true/false and use sed to change
the value, and then wake puppet from its nap.

you're essentially removing the ability for puppet to do anything so you'll
have to use some other tool to let puppet out of it's cage.


I'm sure others have additional (likely better) suggestions..

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Need input on how to run a file with list of commands

[Wolf Noble]

Glad to hear you got it worked out!

You might have good luck with this module for controlling network interfaces
https://github.com/adrienthebo/puppet-network


=MobileMail=
Please excuse brevity or spelling errors

> On Sep 15, 2013, at 22:31, Mani Devarajan  wrote:
> 
> All,
>  Adding /bin/bash helped fix the issue. Thanks all.
> 
> command => "/bin/bash $intconfigfile",
> 
> Thanks,
> Mani
>> On Sunday, September 15, 2013 4:55:08 PM UTC-7, Mani Devarajan wrote:
>> Hello, 
>>  I am downloading a file from puppet master which has list of ifconfig 
>> command and run it using exec command on client. But it fails "change from 
>> notrun to 0 failed: intconfig returned 1 instead of one of [0] at". Any 
>> suggestion on how to overcome this error. Thanks in advance.
>> 
>> File content:
>> ifconfig eth3 up
>> exit 0
>> 
>> Puppet code:
>> file { $intconfigfile:
>> owner => "root",
>> group => "root",
>> mode => "777",
>> source => "puppet:///files/$intfilename",
>>   }
>> 
>>   exec {"config_uplink":
>> command => $intconfigfile,
>> require => File[$intconfigfile]
>>   }
>> 
>> Error:
>> err: returns: change from notrun to 0 failed: intconfig returned 1 instead 
>> of one of [0] at
>> 
>> Thanks,
>> Mani
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] 3.3.0 bug? Could not prefetch package provider/UTF-8

[Wolf Noble]

When I ran into this, what bit me was funky characters hiding in comments
in the manifests.


On Tue, Sep 17, 2013 at 3:42 PM, Robin Lee Powell <
rlpow...@digitalkingdom.org> wrote:

>
> As of upgrading master and clients to 3.3.0, some of my servers are
> saying:
>
> Error: Could not prefetch package provider 'yum': invalid byte sequence in
> UTF-8
> Error: Could not prefetch package provider 'rpm': invalid byte sequence in
> UTF-8
>
> I can't tell whether this actually stops them from *doing* anything
> or not, but I don't think so.
>
> I have tried various things with LANG and LC_ALL to no effect.
>
> Ideas?
>
> -Robin
>
> --
> http://intelligence.org/ :  Our last, best hope for a fantastic future.
> .i ko na cpedu lo nu stidi vau loi jbopre .i danfu lu na go'i li'u .e
> lu go'i li'u .i ji'a go'i lu na'e go'i li'u .e lu go'i na'i li'u .e
> lu no'e go'i li'u .e lu to'e go'i li'u .e lu lo mamta be do cu sofybakni
> li'u
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet 3.2.2: Could not find declared class

[Wolf Noble]

Hi Sergey,

I've noticed behavior similar to then when resource ordering is specified
outside of a class; something like this:

#foo class
#
#
Class['prereq'] -> Class['foo']
class foo() {
  #some stuff here
}

since that dependency isn't occurring INSIDE the boundary of Class['foo'],
 there can be weirdness.

I'm not certain that's what's going on for you, but I have seen that same
behavior in those instances.

HTH

W



On Thu, Sep 26, 2013 at 11:31 AM, Sergey Arlashin <
sergeyarl.maill...@gmail.com> wrote:

> Hi!
> Every now and then I get the following error message in logs on one
> particular host on my network:
>
> "Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError:
> Could not find declared class cachier at /etc/puppet/manifests/nodes.pp:285
> on node hostname1.site"
>
> The next run the error disappears. In a couple of days I see the same
> message with one difference - it says that it cannot find another class. So
> the class name can vary. Host name is the same every time.
>
> Do you know what can cause an error like this ?
>
> --
> Best regards,
> Sergey Arlashin
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] tidy negative match

[Wolf Noble]

Hi Sebastian,

A potentially better way to do it might be to set purge => true on the
/etc/yum.repos.d directory, and specifically manage every file/repo in
there via puppet. This should insure that there are no repos present that
puppet didn't create

HTH

w



On Thu, Sep 26, 2013 at 1:28 PM, Sebastian Juarez wrote:

> Hy!
>
> I'm trying to conf tidy in one of my yum class, the objective is to erase
> old repos from "/etc/yum.repos.d".
>
> This is what i try without success:
>
> tidy {'/etc/yum.repos.d':
> recurse => true,
> matches != [ "oldrepo.repo" ]
> }
>
> Error:
> Could not retrieve catalog from remote server: Error 400 on SERVER: Could
> not parse for environment production: Syntax error at '!='; expected '}'
> at...
>
> I'm attempting to erase all files in the directory, but not those listed.
>
> It's possible to do this?
>
>
> Thanks.-
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet 3.2.2: Could not find declared class

[Wolf Noble]

On Thu, Sep 26, 2013 at 5:21 PM, jcbollinger wrote:

>
>
> On Thursday, September 26, 2013 3:11:24 PM UTC-5, Wolf Noble wrote:
>>
>> Hi Sergey,
>>
>> I've noticed behavior similar to then when resource ordering is specified
>> outside of a class; something like this:
>>
>> #foo class
>> #
>> #
>> Class['prereq'] -> Class['foo']
>> class foo() {
>>   #some stuff here
>> }
>>
>> since that dependency isn't occurring INSIDE the boundary of
>> Class['foo'],  there can be weirdness.
>>
>> I'm not certain that's what's going on for you, but I have seen that same
>> behavior in those instances.
>>
>>
>
> I have trouble believing that an error arising from such a cause would
> randomly appear and disappear as Sergey describes his doing.  Something
> must be changing on the master between runs.
>
> With that said, there have been a few similar issues reported in the past;
> generally they seem to be triggered by manifest files being edited, and
> often they are resolved by restarting the master.  If Sergey's master is
> running under Passenger then he may be getting new masters starting
> frequently enough to explain the problem disappearing.  I can't immediately
> explain why the problem seems pinned to one node, but perhaps this will
> serve as a clue.
>
>
> John
>

What I've seen is that a dependency derived from catalog/nodeA, when NOT
inside a class, can be inconsistently "inherited" by catalog/nodeB if
catalog compilation is occurring at the same time, or soon after A.

I'm not sure if this still occurs >3.x

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Force Fact within manifest

[Wolf Noble]

Hi Paul,

Here's a diagram showing how the puppet run process flows:
http://www.aosabook.org/images/puppet/TimingDiagram.png

as you can see, facter is run exactly once, before the catalog is created.

facter is not invoked again until the next run. I suppose you could have
your sshkey resource notify the puppet service, which would subsequently
trigger another run.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Sync data between various PuppetDB instances

[Wolf Noble]

I'd be interested in accomplishing a similar thing. I want to have a
central reporting puppetdb which I can (outside of puppet) query for
multisite information without tying isolated environments together via a
single postgres db, or using multi-master replication.

my needs do not involve making each puppet site aware of each other's data,
but it would be nice to have one db which has all the data for my digging
pleasure.

from my understanding this is not currently supported.

I was thinking something could be done to ask puppetdb at site A (what
updates have you had in the past N minutes/ since the last time I checked
in with you/ since timestamp(N)), and then iterate through the collected
data and feed it into a reporting puppetdb instance, however I've not gone
beyond thinking about it.





On Thu, Oct 10, 2013 at 7:12 AM, Pablo Fernandez wrote:

> Thanks Ken,
>
> I took a look at the Command API and seems to be quite interesting, but
> it triggers a few more questions.
>
> As a reminder (also for others), what I wanted to do was to add exported
> resources from Node_A (managed by PuppetMaster_A that has its own
> PuppetDB_A) into a different PuppetDB_B, where Node_A is unknown, in
> order for other Nodes_B (managed by PuppetMaster_B) be aware and
> possibly realize those exported resources.
>
> Taking a look the Commands API seem to capabilities to change a whole
> catalog, or facts. Do they need to be existing catalogs, or could I add
> new ones?
> I am thinking: If I want to add Node_A's exported resource(s) to
> PuppetDB_B, I could "artificially" add its whole catalog to
> PuppetDB_B... but the Command API is "replace catalog", no "add
> catalog". Would it be rejected? How does the first catalog of a node get
> introduced into the DB? And moreover, how do I query a whole catalog?
>
> Another possibility would be to include the resource inside an existing
> Node_B catalog on the PuppetDB_B (after all, exported resources don't
> really mater what node do they belong, as long as they have the right
> attributes, right?), but the Catalog wire format seems to require the
> whole set of resources, so, if I define the resources of Node_B with
> some exported resources from Node_A, I believe I would lose the original
> Node_B's resources. The only possibility would be to query Node_B full
> catalog, and *add also* those resources from Node_A before sending them
> to the DB... and this seems to me like a bit dirty :)
>
> Am I missing anything? Or is there another way to implemen what I need
> with Puppet 3.2?
>
> Thanks again,
> BR/Pablo
>
>
> On 10/10/2013 09:16 AM, Ken Barber wrote:
> >>> Is there a mechanism to pull and push some exported resources from one
> >>> PuppetDB to another? I guess this could be done with the API, but has
> >>> anybody tried it, or will it work at all?
> > Not provided by us, yet. We've had a lot of discussions internally
> > about this kind of thing. How about you outline your requirements in
> > the form of a feature request here:
> >
> > http://projects.puppetlabs.com/projects/puppetdb/issues
> >
> >> Did anybody try to push data to a PuppetDB by hand? The API does not
> >> seem to have the PUT or POST methods.
> > The client obviously pushes uses POST :-). The documentation for the
> > mechanism is here:
> >
> > http://docs.puppetlabs.com/puppetdb/1.5/api/commands.html
> >
> > ken.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] exporting custom facts to puppet agents

[Wolf Noble]

Hi Santanu,

custom facts should always do their work inside a setcode block.
http://docs.puppetlabs.com/guides/custom_facts.html

That has nothing to do with the issue at hand, however.

If you need the file to exist before puppet's first run, have your
provisioning system lay it down. Otherwise, you'll have the situation
you're describing where your first puppet run's job is to set the stage for
the rest of your runs.

hth

W





On Sun, Oct 13, 2013 at 6:30 AM, Sans  wrote:

> To solve my "copying file" issue, I can certainly have a file{} type like
> this:
>
> file { 'running_oss':
>> name=> '/home/admin/OSs.txt',
>> mode=> '0644',
>> content => file('/home/admin/OSs.txt');
>> }
>>
>
> to copy the file from the Master to the agent, but as "Retrieving plugin" 
> stuff
> happens way before anything else, the file is not copied prior to the
> custom fact. So, I need to run puppet twice to get the custom fact working
> on a freshly installed agent.
>
> -San
>
>
>
>
> On Sunday, October 13, 2013 11:39:22 AM UTC+1, Sans wrote:
>>
>> .well, unless I'm missing something here.
>>
>> -Santanu
>>
>>
>>
>> On Sunday, October 13, 2013 11:37:19 AM UTC+1, Sans wrote:
>>>
>>> Hi Martin,
>>>
>>> That doesn't actually work: I thought exactly the same in the beginning
>>> and already have the pluginsync enabled. I think, the reason being, the
>>> fact (am_running_oss.rb) file itself reads a text file and the file should
>>> be local. When it runs on the agent, the file (inFile =
>>> "/home/admin/OSs.txt")is there for the .rb file to read it, hence the
>>> fact returns 'undefined'as well.
>>>
>>> -San
>>>
>>>
>>>
>>>
>>>
>>> On Sunday, October 13, 2013 11:18:46 AM UTC+1, Martin Alfke wrote:

 Hi,

 On 13.10.2013, at 10:57, Sans  wrote:

 > [...]

 > The file is on the PuppetMaster. Hence the custom fact
 'am_running_oss' is not available or empty when it runs on the agent. What
 are the options I have to make the custom facts(s) available on every
 single puppet agent? Thanks in advance. Cheers!!
 >

 You have to put the fact inside the lib/facter directory of a module
 and you have to enable pluginsync on all nodes puppet.conf.
 http://docs.puppetlabs.com/**guides/plugins_in_modules.html

 hth,

 Martin



  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] most straight-forward way to verify catalog compilation of several node types?

[Wolf Noble]

Hi All,

I am going to be doing a large bit of module refactoring, without an
existing suite of tests; and I wanted to convince a master inside of
vagrant on my dev laptop  to compile a catalog against a collection of node
names to try to catch breaking changes more expediently and less impact
fully to everyone else than deploying to our test environment..

all my nodes are essentially the same. What's the most elegant way of
providing the master vm with an artificial set of facts and certname and
validating a successful catalog compilation before proceeding?

I know this is just one facet of validating non-breakage, but I think it's
likely to be my sweet spot between local validation and a small canary
environment.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] PuppetDB performance tests

[Wolf Noble]

I would LOVE it if this (or some other tool) would be capable of sending
puppetdb pushes to a back-of-house / reporting puppetdb instance
asynchronously... this seems like a nifty feature.. course, being able to
list multiple puppetdb instances in /etc/puppet/puppetdb.conf might be just
as nice for this too.


On Thu, Oct 24, 2013 at 10:11 AM, Ken Barber  wrote:

> So the closest and best thing I have now is this:
>
> https://github.com/kbarber/dark-loader-proxy
>
> But its very alpha and probably full of bugs. The principle is simple,
> it sits in front of your main traffic like a normal proxy, and
> forwards traffic to both a master PuppetDB, and a 'dark' set of
> PuppetDB instances.
>
> Now as far as responses, it only cares about the responses from the
> 'master' PuppetDB ignoring any dark instances responses (basically it
> drops them). But it could be adapted to compare responses for example.
>
> It adds overhead because the downstream multi-plexed requests are not
> threaded, read the README.md file for more details. I would like to
> find the time to make this more performant and able to be used in a
> production like environment but for now this is only recommended in
> test, or for short periods of time in production.
>
> ken.
>
> On Thu, Oct 24, 2013 at 1:56 PM, ak0ska  wrote:
> > Hello,
> >
> > I was wondering if it's possible to experiment with different PuppetDB
> > setups, and see how different setups perform when hooked on a different
> > database, run on different hardware, or some other configuration is
> changed.
> > It would be good to know whether a certain change is going to be
> beneficial,
> > or not, without having to point the production masters to an experimental
> > setup. Is there any way I could simulate some load, similar to the
> traffic
> > on the live setup? Or better yet, to duplicate/clone/mirror the live
> traffic
> > somehow (even with another tool), without interfering with the live
> > communication between the production PuppetDB and the masters?
> >
> > Suggestions are welcome! :)
> > Thanks,
> > ak0ska
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to puppet-users+unsubscr...@googlegroups.com.
> > To post to this group, send email to puppet-users@googlegroups.com.
> > Visit this group at http://groups.google.com/group/puppet-users.
> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Error 4000 on SERVER: Could not find class

[Wolf Noble]

at the very least, I'd alter the process you use to copy the new modules
dir into something like $puppetconfigdir/modules_MMDDYYSTUFF and then doing
2 mv's:
 mv modulepathdir modulepathdir.old
mv modules_MMDDYYSTUFF modulepathdir
and then puppet should be good, you can start the rm -rf on module path.old

that way at least you're minimizing the number of iops that must occur
between when you've gotten the old modules out of the way and you've gotten
the new modules into place,

Normally, when I do deployments I restart the puppet master gracefully,
(apache/nginx/whathaveyou) to make sure that files aren't cached, although
the only problems I've actually encountered here involve having a
vagrantized puppetmaster .having issues with apache+sendfile


On Mon, Mar 24, 2014 at 2:19 PM, John Pyeatt wrote:

> We are periodically seeing the error
>
> *Could not retrieve catalog from remote server: Error 400 on SERVER: Could
> not find class webadminserver*
>
>
> In our puppet agent logs even though the module/webadminserver files are
> there.
>
> But I'm wondering if there is a timing/file refresh issue involved.
>
> When we push new code out to our puppetmaster we perform the following
> steps:
> 1) copy the new code to a temporary location on the puppetmaster
> 2) rm -rf   the modules directory the puppetmaster uses
> 3) cp -r from the temporary location into the modules directory
>
> Sometimes when the puppet agent's next run we will see the error described
> above. I'm wondering if the puppetmaster is not refreshing its inode values
> between the time of the rm/cp combination and a puppet agent's attempt to
> pull down the new code.
>
> Has anyone ever seen this? Does my hypothesis make sense? Does anyone have
> a better way to deploy the code to puppetmaster remotely without an outage?
>
> --
> John Pyeatt
> Singlewire Software, LLC
> www.singlewire.com
> --
> 608.661.1184
> john.pye...@singlewire.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAEisTL%3DNPpgU%3DrbagtmeJAv-JFXzndHULnB6G7p13Qki7BmEAw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC1UU3eys8jd0P-6YzeA8O6mFHJS30Ze%3D1sp1nbUDvHTu67Oxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Profiling catalog compilation

[Wolf Noble]

Hey guys,

I wrote a post on how to profile your puppet catalog compilations (3.4+) to 
find resource hogs

Hope this helps someone

http://www.wolfspyre.com/2014/05/profiling-puppet-catalog-compilations/

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1BC4D944-B31F-4FBC-8376-BA52FBE95B8C%40wolfspyre.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Profiling catalog compilation

[Wolf Noble]

indeed.

I'd strongly encourage y'all to move to 3.5+ there's a bunch of really
nifty stuff that's been added... not to mention it's incredibly more
performant.

Say Hi to Seb for me, and pass along my contact info.


W


On Wed, May 21, 2014 at 12:13 AM, William Leese  wrote:

> Great stuff, thanks for this. Would be nice to get this kind of
> troubleshooting in the official docs somewhere.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/0e014a92-d52c-4bcc-a5ca-f4b79a2cf138%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC1UU3eNPPM5xEEAbxQj7%3DHQaFyeK5c%2B%2BLgXW3Db-Frn4BZpBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] rspec - Unable to find class ::logstash

[Wolf Noble]

Hi Brian,

I've found having my spec test print out a catalog is a good way to build out a 
suite of tests


context 'when the do_stuff param has the value of hell_yeah' do
  let (:facts) {{'osfamily' => 'RainbowOS }}
  let (:params) {{'do_stuff' => 'hell_yeah'}}
  It 'print a catalog for spec building' do
   p subject.resources
  end
end
context 'when the do_stuff param has the value of nope' do
  let (:facts) {{'osfamily' => 'RainbowOS }}
  let (:params) {{'do_stuff' => 'nope'}}
  It 'print a catalog for spec building' do
   p subject.resources
  end
end

Then I do some simple formatting on the subsequently generated catalogs in 
sublime text and review all the resources. With just a few tweaks it's pretty 
easy to grab the resources you actually care about from the catalog as rspec 
sees it.


HTH
-W
Sent from my iPad

> On Jun 4, 2014, at 1:30 PM, Brian Wilkins  wrote:
> 
> I am trying to write unit tests of my puppet modules. In my 
> profiles::logstash::install, I disambiguate the call to 
> /etc/puppet/modules/logstash by using ::logstash in my class definition like 
> so:
> 
> class profiles::logstash::install() {
>   $ensure = $profiles::logstash::enable ? {true => present, default => absent}
>   $status = $profiles::logstash::start ? {true => enabled, default => 
> disabled}
> 
>   class { '::logstash':
> ensure  => $ensure,
> status  => $status,
> version => $profiles::logstash::version
>   }
> }
> 
> However, when I run my spec file:
> 
> require 'spec_helper'
> 
> describe "profiles::logstash" do
>   it { should contain_class("::logstash") }
>   it { should contain_class("profiles::logstash::install") }
>   it { should contain_class("profiles::logstash::config") }
> end
> 
> I get the errors:
> 
> 1) profiles::logstash
>  Failure/Error: it { should contain_class("::logstash") }
>  Puppet::Error:
>Puppet::Parser::AST::Resource failed with error ArgumentError: Could 
> not find declared class ::logstash at 
> /etc/puppet/modules/profiles/spec/fixtures/modules/profiles/manifests/logstash/install.pp:10
>  on node els4167.els.dev
>  # ./spec/classes/logstash_spec.rb:4
> 
>   2) profiles::logstash
>  Failure/Error: it { should contain_class("profiles::logstash::install") }
>  Puppet::Error:
>Puppet::Parser::AST::Resource failed with error ArgumentError: Could 
> not find declared class ::logstash at 
> /etc/puppet/modules/profiles/spec/fixtures/modules/profiles/manifests/logstash/install.pp:10
>  on node els4167.els.dev
>  # ./spec/classes/logstash_spec.rb:5
> 
>   3) profiles::logstash
>  Failure/Error: it { should contain_class("profiles::logstash::config") }
>  Puppet::Error:
>Puppet::Parser::AST::Resource failed with error ArgumentError: Could 
> not find declared class ::logstash at 
> /etc/puppet/modules/profiles/spec/fixtures/modules/profiles/manifests/logstash/install.pp:10
>  on node els4167.els.dev
>  # ./spec/classes/logstash_spec.rb:6
> 
> How do I get rspec to find my class /etc/puppet/modules/logstash and get it 
> to reference ::logstash as a disambiguation?
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/a47b6fdb-519a-453c-92ec-40787c7d2470%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/BAD12348-3208-4763-B20D-70FD1C721B8B%40wolfspyre.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] 3.6 directory environments, r10k, and hieradata

[Wolf Noble]

Hi Guys,


I have a few questions about 3.6 directory environments, which we're
looking to adopt.

Currently the most pressing surrounds the integration of r10k and hiera…

I believe I want to store hieradata inside the r10k repos, so that each
r10k repo (I'm planning on using these to segregate different internal
product stacks so that product owners can put sensitive data in their own
hiera hierarchy, without the members of other products having access to the
sensitive data)

It seems that if I want some tiers of my hierarchy to be accessible to all,
the only path open to me is to have a hierarchy inside each r10k repo, and
symlink the branches of that hierarchy to relevant locations inside the
global hierarchy.

While I suspect this _will work_ it doesn't quite sound like the most
elegant solution.

Does anyone have any input on a more elegant way that they'd be willing to
share?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC1UU3eAPaMPsM3XF9kdwwXb%2BD5cH8mG2ZxHKCakv4rS0NCj-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Apt: Execute sources before builddep

[Wolf Noble]

Hi David,

I've seen a setup that has an exec which fires apt-get update. This exec
has refreshonly => true. All Apt::Source resources are instantiated via a
profile class kicking off create_resources. All Apt::Source resources
notify the apt-get update exec.

I think something similar to that should give you the ability to have a
class/package require the apt-get update exec, and achieve the behavior you
desire.


On Sat, Jul 5, 2014 at 9:22 PM, David Mohl  wrote:

> Hello,
>
> I am scratching my head on this one. For a project, I need to compile a
> package from source that depends on a apt source package. Since I am
> managing package sources with puppet, I need apt-get builddep to be
> executed *after* sources have been added.
>
> All my sources are managed inside the class 'sources' through apt::source.
> However, when I require that class for builddep, I am falling into a huge
> dependency cycle: (Anchor[apt::source::puppetlabs] =>
> Apt::Source[puppetlabs] => Class[Sources] => Apt::Builddep[something] =>
> Exec[apt-builddep-something] => Exec[apt_update] => Class[Apt::Update] =>
> Anchor[apt::source::puppetlabs])
>
> When I omit the requirement, puppet executes builddep before the sources
> have been added and the command fails.
>
> After a lot of debugging, trying and reading through the apt source, I
> came to the conclusion that this is a problem inside apt. I am out of
> ideas.
> Does anyone here have a idea for this problem or should I start patching
> apt?
>
> (Related serverfault:
> http://serverfault.com/questions/610356/puppet-class-node-dependencies)
>
>
> Cheers,
> David
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/d22156cf-87e9-4ff1-951f-e6e6038aeb21%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC1UU3fKfmU%2Bv-KM6v9mZS5_hpaqrrBNXFYWQ1OYLOPcjdbLiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Custom Facts

[Wolf Noble]

Hi Steve,

All custom facts are delivered to all nodes within a puppetmaster's 
control. IOW, having a module that has a custom fact will deploy that 
fact to every node, regardless of if that node uses, or is aware of the 
fact, or module in question.


It is generally expected that the fact author will ensure that the 
behavior of a dormant custom fact is as close to a noop as possible.





Steve Harp 
February 3, 2015 at 10:45 AM
Hi Guys,

I've created some custom facts in /etc/puppet/MODULE_NAME/lib/facter/. 
 When I run puppet I'm having facts that aren't even defined in a 
module being called by the node deployed to the agent.  This is 
causing the facts to fail on the agent.


For instance, if I have the following custom fact files:

/etc/puppet/modules/abc/lib/facter/abc.rb

/etc/puppet/modules/xyz/lib/facter/xyz.rb


When I define a node calling only module abc, it also delivers the 
fact file defined under module xyz.  On the agent, I end up with 
abc.rb AND xyz.rb.


Am I doing something wrong or is this normal?

Thanks.

--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to puppet-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/00d60c9a-5c35-4a85-a552-9505be073f28%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/54D1011E.8060809%40wolfspyre.com.
For more options, visit https://groups.google.com/d/optout.