Re: [Puppet Users] Question about setting master-less server

[Hubert Lubaczewski]

Hi,
I checked the repo, but I don't understand what you wrote in the README. 
What is the purpose of these ssh keys? Why are you, in the run_puppet 
script, copying config to some place versioned by git commit, and run 
puppet from there, instead of just keeping /etc/puppet as git repo?

Basically - it is likely that your scripts solve problems that I am not 
aware of, yet, but then, would greatly appreciate more information what it 
is for - I can read what it does, but why?

depesz

On Thursday, March 12, 2015 at 3:38:21 AM UTC+1, Charles Yeomans wrote:
>
> > On Mar 11, 2015, at 8:32 PM, Hubert Lubaczewski  > wrote: 
> > 
> > Hi, 
> > 
> > I'm trying to learn puppet by using it on a test machine I have. Figured 
> that for single server, it makes sense to use master-less mode. 
> > 
> > So, my question is like this. To set it up, I figured that: 
> > 1. /etc/puppet would be clone of some repo 
> > 2. in /etc/puppet/manifests/site.pp, I would add vcsrepo{} that would 
> make sure that puppet will update itself on each run 
> > 3. I'll add a cronjob to periodically run "puppet apply 
> /etc/puppet/manifests/site.pp" 
> > 
> > Optionally, I would run "git pull" before actual puppet apply, so that 
> puppet will run on already updated repo. 
> > 
> > Does it make sense? Am I missing something? I know it's pretty basic, 
> but in one place I had to write quite a lot of manifests/modules for 
> puppet, and finally decided to setup whole machine, on my own, using 
> puppet. 
> > 
> > Thanks for any help/guidance, 
> > 
> > depesz 
> > 
>
>
> I've used masterless puppet setups for several years. 
>
> My current starter template for puppet projects is at  
> https://github.com/declaresub/git-puppet-bootstrap .  It may be useful 
> for what you want to do. It is intended for use with VMs; I've tested it 
> with Ubuntu 12.04 and Debian Wheezy on Linode and Vagrant VMs.   
>
> I have a simple puppet module for postgresql if you need one too :) 
>
> Charles 
>
>

-- 
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/85ee6161-3430-4d60-8efc-6cbe66032508%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: why doesn't 'Package <| provider == "apt" |>' work for me?

[Amos Shapira]

On Thursday, 12 March 2015 00:39:53 UTC+11, jcbollinger wrote:
>
>
>
> On Tuesday, March 10, 2015 at 10:30:48 PM UTC-5, Amos Shapira wrote:
>>
>> Hi,
>>
>> I'm running into the common issue of having to force an "apt-get update" 
>> before installing packages (in my case - because the base EC2 AMI is old 
>> and I need it to pick newer package versions).
>>
>> I ended up doing the usual:
>>
>>  exec { 'apt-get update':
>>path => '/usr/bin/',
>>  }
>>  ->
>>  Package <| |>
>>
>>
>
> If you are using PuppetLabs's Apt module, then I think setting the 
> 'always_apt_update => true' on class 'apt' and declaring
>
> Class['Apt'] -> Package <| |>
>
>
> should take care of it for you.  That module's 'apt::update' class is not 
> really suited to be public, given the way the module uses it.
>
>
Thanks. I'm aware of the "always_apt_update" option but am worried that it 
means that puppet will force an "apt-get update" every time it runs (every 
30 minutes).  We will eventually move away from puppet agents to immutable 
images but until then I'm worried that this could stir up a lot of load on 
our EC2 instances which we wouldn't want.

Perhaps I should reconsider this option.
 

>  
>
>> (I can't use "apt::update" because it creates dependency cycles) and it 
>> works.
>>
>> But what baffles me is that I really only need "apt-get update" to 
>> execute before "apt" packages get installed, like this:
>>
>> Package <| provider = "apt" |>
>>
>> But this doesn't trigger the "apt-get update".
>>
>> Just as an example, I also have a Gem-provider related exec which works 
>> as expected:
>>
>>   exec { 'Add Ruby Gems repo mirror':
>> command => 'gem source --config-file /etc/gemrc -a 
>> http://production.cf.rubygems.org/',
>> unless  => 'gem source --config-file /etc/gemrc | fgrep -xq 
>> http://production.cf.rubygems.org/',
>> path=> '/usr/bin:/bin',
>>   }
>>   ->
>>   Package<| provider == 'gem' |>
>>
>> So why doesn't it work for the "apt" provider?
>>
>>
>  
> Resource collectors operate during catalog building.  Their selection 
> predicates can see only parameter and property values *explicitly* 
> declared in your manifests.  It does not know what values will be effective 
> at catalog application time for any other parameters.  In particular, it 
> does not know what provider will be selected during catalog application 
> unless one is specified in the manifest, which is not usual when the 
> system's default provider is expected. 
>

> To the best of my knowledge, the "gem" provider is not the default for any 
> system, so you get it only when you specifically ask for it.  That's why 
> you can reliably select gem Packages by provider.  'Apt' is normally the 
> default Package provider on systems that support it at all.  Your selection 
> predicate will not match Package resources that rely 'apt' being selected 
> by default.
>

Thanks for the explanation. That makes sense. Mystery answered :) 
 

>
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5b4569a1-b6c5-4d48-8942-70f26e1523ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Question about setting master-less server

[Charles Yeomans]

> On Mar 11, 2015, at 8:32 PM, Hubert Lubaczewski  wrote:
> 
> Hi,
> 
> I'm trying to learn puppet by using it on a test machine I have. Figured that 
> for single server, it makes sense to use master-less mode.
> 
> So, my question is like this. To set it up, I figured that:
> 1. /etc/puppet would be clone of some repo
> 2. in /etc/puppet/manifests/site.pp, I would add vcsrepo{} that would make 
> sure that puppet will update itself on each run
> 3. I'll add a cronjob to periodically run "puppet apply 
> /etc/puppet/manifests/site.pp"
> 
> Optionally, I would run "git pull" before actual puppet apply, so that puppet 
> will run on already updated repo.
> 
> Does it make sense? Am I missing something? I know it's pretty basic, but in 
> one place I had to write quite a lot of manifests/modules for puppet, and 
> finally decided to setup whole machine, on my own, using puppet.
> 
> Thanks for any help/guidance,
> 
> depesz
> 


I've used masterless puppet setups for several years. 

My current starter template for puppet projects is at  
https://github.com/declaresub/git-puppet-bootstrap .  It may be useful for what 
you want to do. It is intended for use with VMs; I've tested it with Ubuntu 
12.04 and Debian Wheezy on Linode and Vagrant VMs.  

I have a simple puppet module for postgresql if you need one too :)

Charles

-- 
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/600A56EB-E62D-479F-8A52-5E81691A54DC%40dakim.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Bostjan Skufca]

On Wednesday, 11 March 2015 23:31:38 UTC+1, Luke Bigum wrote:
>
>
>
> On Wednesday, March 11, 2015 at 4:35:36 PM UTC, Bostjan Skufca wrote:
>>
>>
>>
>>> Something like this seems like I'm telling a module *how* to look up my 
>>> own data, rather than passing the right data to the module:
>>>
>>>
>>> class resolv (
>>>   $dns_servers_key_name = 'dns_servers',
>>>   $dns_servers_key_merge = false,
>>> ) {
>>>   if ($dns_servers_key_merge) {
>>> $dns_servers = hiera_array($dns_servers_key_name)
>>>   } else {
>>> $dns_servers = hiera($dns_servers_key_name)
>>>   }
>>> }
>>>
>>> class { 'resolv': dns_servers_key_merge => true }
>>>
>>>
>>> I'd also have to code it to selectively use Hiera or not (some people 
>>> don't) and that would get even worse.  The second example of module design 
>>> may be super awesomely flexible in terms of how I can structure my Hiera 
>>> data, but it doesn't fit the direction the community is moving in terms of 
>>> module design.
>>>
>>
>>
>> This is almost what I am looking for. I have an alternate approach: what 
>> if merging vs nonmerging is decided based on hiera key?
>>
>>
>
> That is my approach, that class would do an implicit Hiera lookup for 
> those class parameters, I just illustrated the point with a resource-like 
> declaration as an example. While the above method would work, I don't think 
> I've made my point about not putting this personalised logic in the 
> "resolv" module itself. The above example is not so good. Gary Larizza 
> explains it very well here if you haven't seen it (
> https://www.youtube.com/watch?v=v9LB-NX4_KQ). That video should answer 
> your questions in your second reply to me too, BTW.
>

Tnx for the pointer, I will watch it soon.

 

> The above code example is a bad idea for these reasons:
>
> - the resolv module is tightly coupled to the data, it's in control of how 
> it should look up data, rather than just be *given* data
> - you won't be able to replace that resolv module with the super awesome 
> puppetlabs_resolv module because of your custom way of handling data
> - it makes a *very* bad assumption that everyone uses Hiera, it is not 
> compatible for people who use ENCs that supply all class parameters for 
> example
> - there's a higher barrier to entry on understanding the module, some 
> people would have to read the body of the resolv module code to figure out 
> what's going on (or there would be a long README)
> - it's more complicated to test because the range of data it can take is 
> more complicated
>

Agreed.

 

> Now expand on my first example:
>
> 
> class puppetlabs_resolv($dns_servers) {
>   file { '/etc/resolv.conf': content => template(...) }
> }
>
> class profile::dns_base {
>   #lookup my DNS data from Hiera
>   $hiera_dns_server_array = hiera_array('dns::server')
>   #and add a global DNS server I have
>   $common_dns_server = '127.0.0.1'
>   class { 'puppetlabs_resolv':
> dns_servers => [ $hiera_dns_server_array, $common_dns_server ]
>   }
> }
>
> class profile::dns_special {
>#don't do a hiera lookup, DNS here is special
>$special_dns = '10.1.1.1'
>class { 'puppetlabs_resolv':
> dns_servers => [ $special_dns ]
>   }
> }
>
> node dc1 { include profile::dns }
> node dc1_special { include profile::dns_special }
> 
>
> The puppetlabs_resolv module I downloaded from GitHub does one thing well, 
> resolv.conf, in a simple and easily understood manner, and it comes with 
> Rspec tests, so I don't have to reinvent the wheel.
>
> All of my business logic about how I get IP addresses into that resolv 
> module is in my profile::dns* classes. These are *my* profile classes, I 
> can do whatever crazy Hiera lookups and string manipulation I want/need to 
> get the data into a format that puppetlabs_resolv takes. In other words my 
> profiles are the "glue" between my data and the "building block" 
> puppetlabs_resolv module. At any time I can replace puppetlabs_resolv with 
> lukebigum_resolv (which is obviously better) with a few tweaks to my 
> profiles. If I replace my data backend or get rid of Hiera entirely, my 
> profile might have to be adjusted but I don't have to stop using that 
> awesome lukebigum_resolv I downloaded.
>

This introduces another layer into the system, but it makes sense. 
Especially if you rely on third-party modules.

 

> Why the use of a second profile, profile::dns_special? It takes complexity 
> out of Hiera. I don't need a complicated Hierarchy when I've got profiles, 
> and I rarely need inheritance at all. I've got my "tpl_%{::domain}" which 
> is where my profile::dns looks up data from, and anything that's special is 
> actually a different implementation of how I usually do DNS, so it gets 
> it's own profile, hence profile::dns_special. It is better to handle these 
> exceptions in Puppet code because it's an *actual* language, rather than 
> trying to model something complex into Hiera which is just a key-v

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Luke Bigum]

- Original Message -
> From: "Christopher Wood" 
> >Puppet in fact provides three functions functions for lookups: there is
> >also hiera_hash().
> > 
> >In any case, you are quite right.  Which sort of lookup is intended is
> >an
> >attribute of the data -- part of the definition of each key -- but it is
> >not represented in or alongside the data.  Each user of the data somehow
> >has to know.  That could be tolerated, inconvenient as it is, except
> >that
> >it is incompatible with automated data binding.  This is an issue that
> >has
> >been recognized and acknowledged, though I'm uncertain whether it is
> >actively being addressed.
> 
> Could you possibly expound on the "Each user of the data somehow has to know"
> part? I'm having trouble with the notion that people would use puppet
> manifests and hiera data without knowing what's in them.

I can't speak for John but I think I get his meaning, but if I don't, here's my 
own opinion ;-)

If a user of a module is reading that module's documentation and parameters, it 
seems a bit nasty to assume they user must also go read the Puppet module code 
in great detail to find out what type of Hiera call is being used.  Passing 
data to the module should be simply defined, eg: "this parameter takes an 
array" or "this parameter is a comma separated string".  For a module to assume 
that it can or should attempt to do some sort of deep merging seems overly 
complicated and it shifts the focus away from the user providing the right data 
to a well written module. Rather than have "classname::merge => true" I would 
advocate something like this which puts the user in complete control of the 
data reaching it's modules in a correct and easily testable manner:


class 'profile::dns' {
  #lookup my DNS data
  $hiera_dns_server_array = hiera_array('dns::server')
  $common_dns_server = '127.0.0.1'
  
  class { 'resolv':
dns_servers => [ $hiera_dns_server_array, $common_dns_server ]
}


Something like this seems like I'm telling a module *how* to look up my own 
data, rather than passing the right data to the module:


class resolv (
  $dns_servers_key_name = 'dns_servers',
  $dns_servers_key_merge = false,
) {
  if ($dns_servers_key_merge) {
$dns_servers = hiera_array($dns_servers_key_name)
  } else {
$dns_servers = hiera($dns_servers_key_name)
  }
}

class { 'resolv': dns_servers_key_merge => true }


I'd also have to code it to selectively use Hiera or not (some people don't) 
and that would get even worse.  The second example of module design may be 
super awesomely flexible in terms of how I can structure my Hiera data, but it 
doesn't fit the direction the community is moving in terms of module design.

-Luke
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

---
#1 Fastest Growing Tech Company in UK - Sunday Times Tech Track 100 (2014)

Awards
2015 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2014 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Infrastructure/Technology Initiative - WSL Institutional Trading 
Awards
2013 #15 Fastest Growing Tech Company in UK - Sunday Times Tech Track 100
2013 Best Overall Testing Project - The European Software Testing Awards
2013 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2013 Best FX Trading Platform - ECN/MTF - WSL Institutional Trading Awards
2013 Best Executing Venue - Forex Magnates Awards
2011 Best Trading System - Financial Sector Technology Awards
2011 Innovative Programming Framework - Oracle Duke's Choice Awards
---

FX and CFDs are leveraged products that can result in
losses exceeding your deposit. They are not suitable
for everyone so please ensure you fully understand
the risks involved.

This message and its attachments are confidential,
may not be disclosed or used by any person other
than the addressee and are intended only for the
named recipient(s). This message is not intended for
any recipient(s) who based on their nationality,
place of business, domicile or for any other
reason, is/are subject to local laws or regulations
which prohibit the provision of such products and
services. This message is subject to the terms at
http://www.lmax.com/pdf/general-disclaimers.pdf
however if you cannot access these, please notify
us by replying to this email and we will send you
the terms. If you are not the intended recipient,
please notify the sender immediately and delete any
copies of this message.

LMAX Exchange is the trading name of LMAX Limited. LMAX
Limited operates a multilateral trading facility. LMAX
Limited is authorised and regulated by the Financial
Conduct Authority (firm registration number 509778)
and is a company registered in England and Wales
(number 6505809).

LMAX Hong Kong Limited is a wholly-owned subsidiary
of LMAX Limited. LMAX Hong Kong i

[Puppet Users] Question about setting master-less server

[Hubert Lubaczewski]

Hi,

I'm trying to learn puppet by using it on a test machine I have. Figured 
that for single server, it makes sense to use master-less mode.

So, my question is like this. To set it up, I figured that:
1. /etc/puppet would be clone of some repo
2. in /etc/puppet/manifests/site.pp, I would add vcsrepo{} that would make 
sure that puppet will update itself on each run
3. I'll add a cronjob to periodically run "puppet apply 
/etc/puppet/manifests/site.pp"

Optionally, I would run "git pull" before actual puppet apply, so that 
puppet will run on already updated repo.

Does it make sense? Am I missing something? I know it's pretty basic, but 
in one place I had to write quite a lot of manifests/modules for puppet, 
and finally decided to setup whole machine, on my own, using puppet.

Thanks for any help/guidance,

depesz

-- 
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/b6da6bf0-9152-472b-b54f-85c0cf87b7d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppetlabs-mysql and Percona

[Anthony Martinet]

Hi there,

I have the same issue here.
Still digging on how to make this work, so far when using package_name => 
'percona-xtradb-cluster-server-5.5' I have an error.
Next step for me is digging into the autogenerated my.cnf ...

Any feedback would be appreciated :)

Anthony

Le mardi 9 décembre 2014 13:54:23 UTC+1, Jochen Haeberle a écrit :
>
> Hi,
>
> the module puppetlabs-mysql on the forge is tagged with percona, but I 
> don't see a way to have the module install a Percona-Server. The module has 
> providers for MySQL and MariaDB, but not Percona.
>
> I tried working with puppetlabs-mysql, installing Percona with a 
> package-resource ending with Percona-Server and MySQL beeing constantly 
> installed and deinstalled.
>
> What does everybody else use to manage a Percona-Server?
>
>
> Thanks in advance
>
> Jochen
>

-- 
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/749886e6-377b-4b37-85c3-86f5e678642b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet as patch management

[Alfredo De Luca]

Agree.
Thanks
On 12/03/2015 12:26 AM, "Alessandro Franceschi"  wrote:

> I agree with what you wrote.
> Puppet is not the best tool to execute one-shot operations like patching
> or deploying of applications.
> It's good at maintaining the state of the resources of our systems, so you
> can use it to configure what you need to manage the patching or the
> deployment of a system's package or an application (apt/yum config files,
> deploy scripts, ssh keys, sudo permissions... ), but not to trigger the
> operation itself.
>
> my2c
> al
>
> On Wednesday, March 11, 2015 at 12:37:26 PM UTC+1, Alfredo De Luca wrote:
>>
>> Hi all.
>> I am configuring Puppet in our environment for configuration
>> management. Also I am using Hiera and it's so great so far.
>> Now managers are asking if we can use it as patch mgmt tool. I said
>> Puppet it's not but it can help with patch/pkg distribution which I
>> think it could be very good.
>> Do you agree on that?
>> Any more info/thoughts would be appreciated.
>>
>> Regards
>>
>>
>> --
>> Alfredo
>>
>  --
> 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/c6307d1b-fa76-4b97-a46d-ed50a0c24bcc%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/CAAWpFTFaiBP4i5-td2M0-eTwVGYZ8oDY0QNiGKbngiS%3DSohbHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Luke Bigum]

On Wednesday, March 11, 2015 at 4:35:36 PM UTC, Bostjan Skufca wrote:
>
>
>
>> Something like this seems like I'm telling a module *how* to look up my 
>> own data, rather than passing the right data to the module:
>>
>>
>> class resolv (
>>   $dns_servers_key_name = 'dns_servers',
>>   $dns_servers_key_merge = false,
>> ) {
>>   if ($dns_servers_key_merge) {
>> $dns_servers = hiera_array($dns_servers_key_name)
>>   } else {
>> $dns_servers = hiera($dns_servers_key_name)
>>   }
>> }
>>
>> class { 'resolv': dns_servers_key_merge => true }
>>
>>
>> I'd also have to code it to selectively use Hiera or not (some people 
>> don't) and that would get even worse.  The second example of module design 
>> may be super awesomely flexible in terms of how I can structure my Hiera 
>> data, but it doesn't fit the direction the community is moving in terms of 
>> module design.
>>
>
>
> This is almost what I am looking for. I have an alternate approach: what 
> if merging vs nonmerging is decided based on hiera key?
>
>

That is my approach, that class would do an implicit Hiera lookup for those 
class parameters, I just illustrated the point with a resource-like 
declaration as an example. While the above method would work, I don't think 
I've made my point about not putting this personalised logic in the 
"resolv" module itself. The above example is not so good. Gary Larizza 
explains it very well here if you haven't seen it 
(https://www.youtube.com/watch?v=v9LB-NX4_KQ). That video should answer 
your questions in your second reply to me too, BTW.

The above code example is a bad idea for these reasons:

- the resolv module is tightly coupled to the data, it's in control of how 
it should look up data, rather than just be *given* data
- you won't be able to replace that resolv module with the super awesome 
puppetlabs_resolv module because of your custom way of handling data
- it makes a *very* bad assumption that everyone uses Hiera, it is not 
compatible for people who use ENCs that supply all class parameters for 
example
- there's a higher barrier to entry on understanding the module, some 
people would have to read the body of the resolv module code to figure out 
what's going on (or there would be a long README)
- it's more complicated to test because the range of data it can take is 
more complicated

Now expand on my first example:


class puppetlabs_resolv($dns_servers) {
  file { '/etc/resolv.conf': content => template(...) }
}

class profile::dns_base {
  #lookup my DNS data from Hiera
  $hiera_dns_server_array = hiera_array('dns::server')
  #and add a global DNS server I have
  $common_dns_server = '127.0.0.1'
  class { 'puppetlabs_resolv':
dns_servers => [ $hiera_dns_server_array, $common_dns_server ]
  }
}

class profile::dns_special {
   #don't do a hiera lookup, DNS here is special
   $special_dns = '10.1.1.1'
   class { 'puppetlabs_resolv':
dns_servers => [ $special_dns ]
  }
}

node dc1 { include profile::dns }
node dc1_special { include profile::dns_special }


The puppetlabs_resolv module I downloaded from GitHub does one thing well, 
resolv.conf, in a simple and easily understood manner, and it comes with 
Rspec tests, so I don't have to reinvent the wheel.

All of my business logic about how I get IP addresses into that resolv 
module is in my profile::dns* classes. These are *my* profile classes, I 
can do whatever crazy Hiera lookups and string manipulation I want/need to 
get the data into a format that puppetlabs_resolv takes. In other words my 
profiles are the "glue" between my data and the "building block" 
puppetlabs_resolv module. At any time I can replace puppetlabs_resolv with 
lukebigum_resolv (which is obviously better) with a few tweaks to my 
profiles. If I replace my data backend or get rid of Hiera entirely, my 
profile might have to be adjusted but I don't have to stop using that 
awesome lukebigum_resolv I downloaded.

Why the use of a second profile, profile::dns_special? It takes complexity 
out of Hiera. I don't need a complicated Hierarchy when I've got profiles, 
and I rarely need inheritance at all. I've got my "tpl_%{::domain}" which 
is where my profile::dns looks up data from, and anything that's special is 
actually a different implementation of how I usually do DNS, so it gets 
it's own profile, hence profile::dns_special. It is better to handle these 
exceptions in Puppet code because it's an *actual* language, rather than 
trying to model something complex into Hiera which is just a key-value 
store.

Your Hiera example where you have tpl_dc1.yaml and tpl_dc1-special.yaml is 
going to bite you. Your joke about mimicking node inheritance functionality 
in Hiera worries me a little, because it reminds me of some of my 
colleagues. Just because it can be modelled in Hiera, doesn't mean it 
should be. To give you an example, at my work place we can build an entire 
platform where each node's Hiera file looks li

[Puppet Users] Failures on file_metadata, catalog, etc.

[Forrest]

We have a Puppet config that stores files outside of modules, along with 
appropriate auth.conf entries to support this.For the most part, it has 
just worked and I haven't felt any need to muddle with it - so I was 
surprised to find a bevy of these errors in the logs:

Mar 11 18:24:51 central puppet-agent[10505]: 
(/Stage[main]/Resolv-conf-prod/File[/etc/resolv.conf]) Could not evaluate: 
Could not retrieve file metadata for puppet:///files/etc/resolv.conf.prod: 
Error 403 on SERVER: Forbidden request: central(10.101.0.9) access to 
/file_metadata/files/etc/resolv.conf.prod [find] at : 128

( hundreds of those, including /catalog )

the auth.conf entry for file_metadata says:

path ~ ^/file_(metadata|content)/etc/
auth yes
allow /^(.+\.)?ourdomain.com$/
allow_ip 127.0.0.0/8
allow_ip 10.0.0.0/8


That pretty much covers all.   

Puppet is now at 3.7.4 and it's running under Passenger, which it has been 
for a long time.

I'm trying to figure out what's changed so I can fix this; hopefully 
without having to spend time writing modules that I will never use.



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/592e2ac6-f714-4312-af53-ea082377610a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: hiera-eyaml - masterless puppet

[Jeff Adams]

We're using a couple of techniques:

We bake them into our system images, and for ad-hoc we have a Rundeck
job that can push the keys onto a host.

Haven't had to rotate the keys yet, but I presume that we'd either use
the ad-hoc technique, or re-spin the system image and re-deploy the
hosts. Since we're moving towards ephemeral/immutable hosts, this works
for us.

Hope that helps.

- Jeff

On 03/11/2015 03:05 PM, Heinz Kalkhoff wrote:

Jeff,

I realize you may not want to share the details, but can you share your
strategy on management of the private keys in a masterless setup?

Thanks for the reply.

Heinz

On Wednesday, March 11, 2015 at 9:43:02 AM UTC-4, jeff Adams wrote:

We're using eyaml in our masterless setup as well. We've got our
hiera.yaml in /etc/puppet, so we don't need to specify the
--hiera_config with puppet apply.

True that distributing the private key(s) was an interesting issue
to solve.

-  Jeff

On 03/11/2015 08:30 AM, Alessandro Franceschi wrote:
 > Sure you can,
 > you have to pass the --hiera_config parameter to the puppet apply
 > command (pointing to your hiera.yaml) and you will need the
private key
 > used to encrypt keys on every node (this is maybe the only issue
with
 > hiera-eyaml in masterless mode).
 > al
 >
 > On Tuesday, March 10, 2015 at 10:37:30 PM UTC+1, Heinz Kalkhoff
wrote:
 >
 > Is it possible to use hiera-eyaml with a masterless puppet setup
 > (e.g. puppet apply)?  I want to verify before going down this
path
 > as I have been unable to find examples using puppet
masterless and
 > hiera-eyaml.
 >
 > --
 > 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...@googlegroups.com 
 > .
 > To view this discussion on the web visit
 >

https://groups.google.com/d/msgid/puppet-users/f888b737-7789-4e4b-a72c-1b655a130c87%40googlegroups.com



 >

>.

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



This message and any attached files contain confidential information
and is intended only for the individual named. If you are not the
named addressee you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately by e-mail if you have
received this e-mail by mistake and delete this e-mail from your
system. E-mail transmission cannot be guaranteed to be secure or
without error as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail
transmission. If verification is required please request a hard-copy
version.

--
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/00971302-01db-475f-945e-9c08763b6b46%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.




This message and any attached files contain confidential information and is 
intended only for the individual named. If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. E-mail transmission cannot be guaranteed 
to be secure or without error as information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or contain viruses. The sender 
therefore does not accept liability for any errors or omissions in the contents 
of this message, which arise as a result of e-mail transmission. If 
verification is required please request a hard-copy version.

--
You received this message because you are subscribed to the Goog

Re: [Puppet Users] Re: hiera-eyaml - masterless puppet

[Heinz Kalkhoff]

Jeff,

I realize you may not want to share the details, but can you share your 
strategy on management of the private keys in a masterless setup?

Thanks for the reply.

Heinz

On Wednesday, March 11, 2015 at 9:43:02 AM UTC-4, jeff Adams wrote:
>
> We're using eyaml in our masterless setup as well. We've got our 
> hiera.yaml in /etc/puppet, so we don't need to specify the 
> --hiera_config with puppet apply. 
>
> True that distributing the private key(s) was an interesting issue to 
> solve. 
>
> -  Jeff 
>
> On 03/11/2015 08:30 AM, Alessandro Franceschi wrote: 
> > Sure you can, 
> > you have to pass the --hiera_config parameter to the puppet apply 
> > command (pointing to your hiera.yaml) and you will need the private key 
> > used to encrypt keys on every node (this is maybe the only issue with 
> > hiera-eyaml in masterless mode). 
> > al 
> > 
> > On Tuesday, March 10, 2015 at 10:37:30 PM UTC+1, Heinz Kalkhoff wrote: 
> > 
> > Is it possible to use hiera-eyaml with a masterless puppet setup 
> > (e.g. puppet apply)?  I want to verify before going down this path 
> > as I have been unable to find examples using puppet masterless and 
> > hiera-eyaml. 
> > 
> > -- 
> > 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...@googlegroups.com  
> > . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/f888b737-7789-4e4b-a72c-1b655a130c87%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/puppet-users/f888b737-7789-4e4b-a72c-1b655a130c87%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>  
>
> This message and any attached files contain confidential information and 
> is intended only for the individual named. If you are not the named 
> addressee you should not disseminate, distribute or copy this e-mail. 
> Please notify the sender immediately by e-mail if you have received this 
> e-mail by mistake and delete this e-mail from your system. E-mail 
> transmission cannot be guaranteed to be secure or without error as 
> information could be intercepted, corrupted, lost, destroyed, arrive late 
> or incomplete, or contain viruses. The sender therefore does not accept 
> liability for any errors or omissions in the contents of this message, 
> which arise as a result of e-mail transmission. If verification is required 
> please request a hard-copy version. 
>

-- 
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/00971302-01db-475f-945e-9c08763b6b46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Bostjan Skufca]

On Wednesday, 11 March 2015 15:59:12 UTC+1, Luke Bigum wrote:
>
>
> The second example of module design may be super awesomely flexible in 
> terms of how I can structure my Hiera data, but it doesn't fit the 
> direction the community is moving in terms of module design.
>

What do you mean by this? I am curious about what you think where the 
community is moving to? Are modules getting dumbed down? :)


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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f50f91fd-5f50-43be-8af9-4108ecf9bf9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Bostjan Skufca]

On Wednesday, 11 March 2015 15:59:12 UTC+1, Luke Bigum wrote:
>
>
> On Wednesday, March 11, 2015 at 1:57:00 PM UTC, Christopher Wood wrote:
>>
>>
>> Could you possibly expound on the "Each user of the data somehow has to 
>> know" part? I'm having trouble with the notion that people would use puppet 
>> manifests and hiera data without knowing what's in them. 
>>
>>
>>
> I can't speak for John but I think I get his meaning, but if I don't, 
> here's my own opinion ;-)
>
> If a user of a module is reading that module's documentation and 
> parameters, it seems a bit nasty to assume they user must also go read the 
> Puppet module code in great detail to find out what type of Hiera call is 
> being used.  Passing data to the module should be simply defined, eg: "this 
> parameter takes an array" or "this parameter is a comma separated string". 
>  For a module to assume that it can or should attempt to do some sort of 
> deep merging seems overly complicated and it shifts the focus away from the 
> user providing the right data to a well written module.
>

Spot on, I believe.



Rather than have "classname::merge => true" I would advocate something like 
> this which puts the user in complete control of the data reaching it's 
> modules in a correct and easily testable manner:
>
>
> class 'profile::dns' {
>   #lookup my DNS data
>   $hiera_dns_server_array = hiera_array('dns::server')
>   $common_dns_server = '127.0.0.1'
>   
>   class { 'resolv':
> dns_servers => [ $hiera_dns_server_array, $common_dns_server ]
> }
>
>
> Something like this seems like I'm telling a module *how* to look up my 
> own data, rather than passing the right data to the module:
>
>
> class resolv (
>   $dns_servers_key_name = 'dns_servers',
>   $dns_servers_key_merge = false,
> ) {
>   if ($dns_servers_key_merge) {
> $dns_servers = hiera_array($dns_servers_key_name)
>   } else {
> $dns_servers = hiera($dns_servers_key_name)
>   }
> }
>
> class { 'resolv': dns_servers_key_merge => true }
>
>
> I'd also have to code it to selectively use Hiera or not (some people 
> don't) and that would get even worse.  The second example of module design 
> may be super awesomely flexible in terms of how I can structure my Hiera 
> data, but it doesn't fit the direction the community is moving in terms of 
> module design.
>


This is almost what I am looking for. I have an alternate approach: what if 
merging vs nonmerging is decided based on hiera key?

class resolv (
  $dns_servers_key_name = 'dns_servers',
) {
  if (hiera('dns_servers_key_merge')) {# <--- hiera is 
responsible for merging decision
$dns_servers = hiera_array($dns_servers_key_name)
  } else {
$dns_servers = hiera($dns_servers_key_name)
  }
}


Though I can forsee the problem in this case:
- layer 1 data, merge value has no effect here
- layer 2 data, merge true<--- correct, data from layer 1 and layer 2 
is merged
- layer 3 data, merge false   <--- if we stop here, only data from layer 3 
is used
- layer 4 data, merge true <--- this would cause merging of data from 
all layers

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d2bd3ad8-d807-4543-823b-985bb0ce8179%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Bostjan Skufca]

On Wednesday, 11 March 2015 14:57:00 UTC+1, Christopher Wood wrote:
>
> (Replying to two people in one email, hum.) 
>
> I rather take your point, but isn't the requirement for different data 
> handling just another data item? Is any code unaware of the underlying data 
> structure? Even if you have a single type of data (plain string-like 
> variables) your code is implicitly aware that it can treat them as that 
> type. 
>

Yes, certain dependency always exists, that can not be denied. But it 
should lean towards minimum amount of coupling.

But if we venture a peek into programming languages, for example towards 
functions that return arrays, which best matches our current discussion.

function callee ()
{
   ...
   return $arrayOfData;
}

function caller ()
{
   $newDataArray = callee();
}


The caller() gets very messy, if it is its responsibility to figure out if 
returned array from callee() is either:
- an array of keys and values
- an array of arrays of keys and values


This is what I am talking about - if callee just returns array of arrays it 
is not behaving very nicely :)
And this is exactly what hiera does.

If I think about this a little further, this is what hiera backends do. 
hiera*() functions on the other hand does a bit poor job at abstracting 
provider internal data, or does a good and simple job alright sacrificing 
some flexibility we had with class inheritance.


Anyhow, it seems writing custom backend providers is the way out.


 

> I'm not really sure there's a way to automagically distinguish 
>
> "this is an array, do not retrieve its contents from all levels" 
> "this is an array, do retrieve its contents from all levels" 
>
> while still preserving our sanity.
>

Agreed. But if you use hiera with multiple scopes (common, dc, row, rack, 
node), each layer usually knows if data from parent scope should be merged 
with, or replaced.

Again, maybe it is just that default hiera backends do not allow for such 
flexibility. It should not be hard to switch that to custom provider, whose 
data model actually allows for such flexibility.


(I've had some nasty run-ins with merging lookups and have decided they're 
> mostly not for me, maybe the smarter people on this list are having better 
> results.) 
>

Care to elaborate a bit, especially how did you overcome them (define all 
data for each node)?


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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a3b26c59-beb9-4dc1-a669-e253858d602a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetdb console and docs

[Wyatt Alt]

Hey James,

The MQ depth is labeled "Command Queue depth" in the dashboard. I just
updated the docs to make that connection explicit, so your link should be
updated shortly.

That page isn't intended to document the dashboard specifically, so not all
the fields are described. We don't really document the dashboard in a
centralized place, but I like the idea and I made this ticket to create one
https://tickets.puppetlabs.com/browse/PDB-1285

Catalog Duplication specifically is dupes / (dupes + new), where dupes and
new are both counters that are respectively incremented when a catalog is
stored with the same content as one that has already been stored, and when
a catalog is stored with original content.

Both counters start at zero at startup and only apply relative to catalogs
processed since startup.

Wyatt

On Wed, Mar 11, 2015 at 4:17 AM, James Green 
wrote:

> The documentation at
> https://docs.puppetlabs.com/puppetdb/latest/maintain_and_tune.html talks
> about checking the MQ depth.
>
> I'm not seeing such a thing on our dashboard but plenty of others not
> documented such as Catalogue Duplication.
>
> Am I looking at outdated documentation?
>
> James
>
>  --
> 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/CAMH6%2BaxTxqy5yC7AX%2BstW0379khse0dAXBAf3UqbKv0QtOB27A%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/CAJDiH3EeMpCKgoCZ1qxM55p3v%3De1-W5b%2B0%3D8oF2OU9z4yN74VQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Luke Bigum]

On Wednesday, March 11, 2015 at 1:57:00 PM UTC, Christopher Wood wrote:
>
>
> >Puppet in fact provides three functions functions for lookups: there 
> is 
> >also hiera_hash(). 
> > 
> >In any case, you are quite right.  Which sort of lookup is intended 
> is an 
> >attribute of the data -- part of the definition of each key -- but it 
> is 
> >not represented in or alongside the data.  Each user of the data 
> somehow 
> >has to know.  That could be tolerated, inconvenient as it is, except 
> that 
> >it is incompatible with automated data binding.  This is an issue 
> that has 
> >been recognized and acknowledged, though I'm uncertain whether it is 
> >actively being addressed.  
>
> Could you possibly expound on the "Each user of the data somehow has to 
> know" part? I'm having trouble with the notion that people would use puppet 
> manifests and hiera data without knowing what's in them. 
>
>
>
I can't speak for John but I think I get his meaning, but if I don't, 
here's my own opinion ;-)

If a user of a module is reading that module's documentation and 
parameters, it seems a bit nasty to assume they user must also go read the 
Puppet module code in great detail to find out what type of Hiera call is 
being used.  Passing data to the module should be simply defined, eg: "this 
parameter takes an array" or "this parameter is a comma separated string". 
 For a module to assume that it can or should attempt to do some sort of 
deep merging seems overly complicated and it shifts the focus away from the 
user providing the right data to a well written module. Rather than have 
"classname::merge => true" I would advocate something like this which puts 
the user in complete control of the data reaching it's modules in a correct 
and easily testable manner:


class 'profile::dns' {
  #lookup my DNS data
  $hiera_dns_server_array = hiera_array('dns::server')
  $common_dns_server = '127.0.0.1'
  
  class { 'resolv':
dns_servers => [ $hiera_dns_server_array, $common_dns_server ]
}


Something like this seems like I'm telling a module *how* to look up my own 
data, rather than passing the right data to the module:


class resolv (
  $dns_servers_key_name = 'dns_servers',
  $dns_servers_key_merge = false,
) {
  if ($dns_servers_key_merge) {
$dns_servers = hiera_array($dns_servers_key_name)
  } else {
$dns_servers = hiera($dns_servers_key_name)
  }
}

class { 'resolv': dns_servers_key_merge => true }


I'd also have to code it to selectively use Hiera or not (some people 
don't) and that would get even worse.  The second example of module design 
may be super awesomely flexible in terms of how I can structure my Hiera 
data, but it doesn't fit the direction the community is moving in terms of 
module design.

To answer Bostjan's original example, you have 3 "profiles" of syslog: one 
base, one dc1 and one dc1_special, and you assign those profiles to 
whatever node needs them.

-Luke 

-- 
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/f3db0374-7555-402a-affd-3c162de2a4cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Can a type/provider be written to use Python libraries ?

[Dan White]

Looking at developing a type/provider for RHSM.
Python API libraries exist, but not Ruby.
I found the RubyPython gem, but the idea of an imbeded Python interpreter seems 
a bit scary.

Anyone been down this road or am I trailblazing again ?

“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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ae8aada6-acc7-4160-baba-8bdee0f7fa9a%40me.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[Christopher Wood]

(Replying to two people in one email, hum.)

On Wed, Mar 11, 2015 at 06:01:39AM -0700, jcbollinger wrote:
>On Tuesday, March 10, 2015 at 9:59:41 PM UTC-5, Bostjan Skufca wrote:
> 
>  On Monday, 9 March 2015 14:45:38 UTC+1, Christopher Wood wrote:
> 
>On Sun, Mar 08, 2015 at 11:55:03AM -0700, Bostjan Skufca wrote:
>>    With hiera:
>>    - How would you go about when certain nodes need data merged from
>all
>>    scopes, but other nodes need data from just the last scope?
> 
>I've usually had a "classname::merge: true" key in hiera, controlling
>whether I use hiera() or hiera_hash() to obtain the data I need.
> 
>  And this hits the nail on the spot, even if unknowingly:)
>  The problem I am seeing here and which I am only now being able to
>  articulate, is the clash of two contradictory elements:
>  1. Puppet development is pushed towards decoupling code (manifest) from
>  data, a noble goal
>  2. Puppet provides two functions, hiera() and hiera_array(), and the
>  very existence of more than one function to retrieve data destroys the
>  notion, that code should be unaware of underlying data storage details.

I rather take your point, but isn't the requirement for different data handling 
just another data item? Is any code unaware of the underlying data structure? 
Even if you have a single type of data (plain string-like variables) your code 
is implicitly aware that it can treat them as that type.

I'm not really sure there's a way to automagically distinguish

"this is an array, do not retrieve its contents from all levels"
"this is an array, do retrieve its contents from all levels"

while still preserving our sanity.

(I've had some nasty run-ins with merging lookups and have decided they're 
mostly not for me, maybe the smarter people on this list are having better 
results.)
 
>Puppet in fact provides three functions functions for lookups: there is
>also hiera_hash().
> 
>In any case, you are quite right.  Which sort of lookup is intended is an
>attribute of the data -- part of the definition of each key -- but it is
>not represented in or alongside the data.  Each user of the data somehow
>has to know.  That could be tolerated, inconvenient as it is, except that
>it is incompatible with automated data binding.  This is an issue that has
>been recognized and acknowledged, though I'm uncertain whether it is
>actively being addressed. 

Could you possibly expound on the "Each user of the data somehow has to know" 
part? I'm having trouble with the notion that people would use puppet manifests 
and hiera data without knowing what's in them.

>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 [1]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/24d78255-435a-480a-94be-128a0e760c45%40googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:puppet-users+unsubscr...@googlegroups.com
>2. 
> https://groups.google.com/d/msgid/puppet-users/24d78255-435a-480a-94be-128a0e760c45%40googlegroups.com?utm_medium=email&utm_source=footer
>3. 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/20150311135651.GA841%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: hiera-eyaml - masterless puppet

[Jeff Adams]

We're using eyaml in our masterless setup as well. We've got our
hiera.yaml in /etc/puppet, so we don't need to specify the
--hiera_config with puppet apply.

True that distributing the private key(s) was an interesting issue to solve.

-  Jeff

On 03/11/2015 08:30 AM, Alessandro Franceschi wrote:

Sure you can,
you have to pass the --hiera_config parameter to the puppet apply
command (pointing to your hiera.yaml) and you will need the private key
used to encrypt keys on every node (this is maybe the only issue with
hiera-eyaml in masterless mode).
al

On Tuesday, March 10, 2015 at 10:37:30 PM UTC+1, Heinz Kalkhoff wrote:

Is it possible to use hiera-eyaml with a masterless puppet setup
(e.g. puppet apply)?  I want to verify before going down this path
as I have been unable to find examples using puppet masterless and
hiera-eyaml.

--
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/f888b737-7789-4e4b-a72c-1b655a130c87%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.




This message and any attached files contain confidential information and is 
intended only for the individual named. If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. E-mail transmission cannot be guaranteed 
to be secure or without error as information could be intercepted, corrupted, 
lost, destroyed, arrive late or incomplete, or contain viruses. The sender 
therefore does not accept liability for any errors or omissions in the contents 
of this message, which arise as a result of e-mail transmission. If 
verification is required please request a hard-copy version.

--
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/5500465F.10308%40bancvue.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: why doesn't 'Package <| provider == "apt" |>' work for me?

[jcbollinger]

On Tuesday, March 10, 2015 at 10:30:48 PM UTC-5, Amos Shapira wrote:
>
> Hi,
>
> I'm running into the common issue of having to force an "apt-get update" 
> before installing packages (in my case - because the base EC2 AMI is old 
> and I need it to pick newer package versions).
>
> I ended up doing the usual:
>
>  exec { 'apt-get update':
>path => '/usr/bin/',
>  }
>  ->
>  Package <| |>
>
>

If you are using PuppetLabs's Apt module, then I think setting the 
'always_apt_update => true' on class 'apt' and declaring

Class['Apt'] -> Package <| |>


should take care of it for you.  That module's 'apt::update' class is not 
really suited to be public, given the way the module uses it.

 

> (I can't use "apt::update" because it creates dependency cycles) and it 
> works.
>
> But what baffles me is that I really only need "apt-get update" to execute 
> before "apt" packages get installed, like this:
>
> Package <| provider = "apt" |>
>
> But this doesn't trigger the "apt-get update".
>
> Just as an example, I also have a Gem-provider related exec which works as 
> expected:
>
>   exec { 'Add Ruby Gems repo mirror':
> command => 'gem source --config-file /etc/gemrc -a 
> http://production.cf.rubygems.org/',
> unless  => 'gem source --config-file /etc/gemrc | fgrep -xq 
> http://production.cf.rubygems.org/',
> path=> '/usr/bin:/bin',
>   }
>   ->
>   Package<| provider == 'gem' |>
>
> So why doesn't it work for the "apt" provider?
>
>
 
Resource collectors operate during catalog building.  Their selection 
predicates can see only parameter and property values *explicitly* declared 
in your manifests.  It does not know what values will be effective at 
catalog application time for any other parameters.  In particular, it does 
not know what provider will be selected during catalog application unless 
one is specified in the manifest, which is not usual when the system's 
default provider is expected.

To the best of my knowledge, the "gem" provider is not the default for any 
system, so you get it only when you specifically ask for it.  That's why 
you can reliably select gem Packages by provider.  'Apt' is normally the 
default Package provider on systems that support it at all.  Your selection 
predicate will not match Package resources that rely 'apt' being selected 
by default.


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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3db8500f-db7f-4343-9054-a6abcd5209ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: hiera-eyaml - masterless puppet

[Alessandro Franceschi]

Sure you can, 
you have to pass the --hiera_config parameter to the puppet apply command 
(pointing to your hiera.yaml) and you will need the private key used to 
encrypt keys on every node (this is maybe the only issue with hiera-eyaml 
in masterless mode).
al

On Tuesday, March 10, 2015 at 10:37:30 PM UTC+1, Heinz Kalkhoff wrote:
>
> Is it possible to use hiera-eyaml with a masterless puppet setup (e.g. 
> puppet apply)?  I want to verify before going down this path as I have been 
> unable to find examples using puppet masterless and hiera-eyaml.
>
>

-- 
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/f888b737-7789-4e4b-a72c-1b655a130c87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet as patch management

[Alessandro Franceschi]

I agree with what you wrote.
Puppet is not the best tool to execute one-shot operations like patching or 
deploying of applications.
It's good at maintaining the state of the resources of our systems, so you 
can use it to configure what you need to manage the patching or the 
deployment of a system's package or an application (apt/yum config files, 
deploy scripts, ssh keys, sudo permissions... ), but not to trigger the 
operation itself.

my2c
al

On Wednesday, March 11, 2015 at 12:37:26 PM UTC+1, Alfredo De Luca wrote:
>
> Hi all. 
> I am configuring Puppet in our environment for configuration 
> management. Also I am using Hiera and it's so great so far. 
> Now managers are asking if we can use it as patch mgmt tool. I said 
> Puppet it's not but it can help with patch/pkg distribution which I 
> think it could be very good. 
> Do you agree on that? 
> Any more info/thoughts would be appreciated. 
>
> Regards 
>
>
> -- 
> Alfredo 
>

-- 
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/c6307d1b-fa76-4b97-a46d-ed50a0c24bcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Node key merging/overloading - node inheritance vs hiera

[jcbollinger]

On Tuesday, March 10, 2015 at 9:59:41 PM UTC-5, Bostjan Skufca wrote:
>
>
>
> On Monday, 9 March 2015 14:45:38 UTC+1, Christopher Wood wrote:
>>
>> On Sun, Mar 08, 2015 at 11:55:03AM -0700, Bostjan Skufca wrote: 
>> >With hiera: 
>> >- How would you go about when certain nodes need data merged from 
>> all 
>> >scopes, but other nodes need data from just the last scope? 
>>
>> I've usually had a "classname::merge: true" key in hiera, controlling 
>> whether I use hiera() or hiera_hash() to obtain the data I need. 
>>
>
> And this hits the nail on the spot, even if unknowingly:)
>
> The problem I am seeing here and which I am only now being able to 
> articulate, is the clash of two contradictory elements:
> 1. Puppet development is pushed towards decoupling code (manifest) from 
> data, a noble goal
> 2. Puppet provides two functions, hiera() and hiera_array(), and the very 
> existence of more than one function to retrieve data destroys the notion, 
> that code should be unaware of underlying data storage details.
>
>

Puppet in fact provides *three* functions functions for lookups: there is 
also hiera_hash().

In any case, you are quite right.  Which sort of lookup is intended is an 
attribute of the data -- part of the definition of each key -- but it is 
not represented in or alongside the data.  Each user of the data somehow 
has to know.  That could be tolerated, inconvenient as it is, except that 
it is incompatible with automated data binding.  This is an issue that has 
been recognized and acknowledged, though I'm uncertain whether it is 
actively being addressed.  
 

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/24d78255-435a-480a-94be-128a0e760c45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] trunc number in manifest

[Jonathan Gazeley]

I would recommend using the `floor` function from puppetlabs/stdlib

https://forge.puppetlabs.com/puppetlabs/stdlib

Thanks,
Jonathan


On 10/03/15 09:27, MaryG wrote:

Hi,
I get this value from fact:
 $shmmax = <<$facts['memorysize_mb']*1024*1024)/2

I want to trunc since I get a float 963211427.84. I want to cut 
decimal numer and get  963211427.

How can I do it?
--
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/feb8e41a-21c8-4a8e-a81b-0b571593c086%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/55002CDC.5040403%40bristol.ac.uk.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet as patch management

[Alfredo De Luca]

Hi all.
I am configuring Puppet in our environment for configuration
management. Also I am using Hiera and it's so great so far.
Now managers are asking if we can use it as patch mgmt tool. I said
Puppet it's not but it can help with patch/pkg distribution which I
think it could be very good.
Do you agree on that?
Any more info/thoughts would be appreciated.

Regards


-- 
Alfredo

-- 
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/CAAWpFTEwQRsARPuV1V4BOkvU3%2B0iBnryP_PS4QE6k8UbWxfP4w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppetdb console and docs

[James Green]

The documentation at
https://docs.puppetlabs.com/puppetdb/latest/maintain_and_tune.html talks
about checking the MQ depth.

I'm not seeing such a thing on our dashboard but plenty of others not
documented such as Catalogue Duplication.

Am I looking at outdated documentation?

James

-- 
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/CAMH6%2BaxTxqy5yC7AX%2BstW0379khse0dAXBAf3UqbKv0QtOB27A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Could not retrieve file metadata ... end of file reached

[James Green]

Hi,

Sorry for the delayed response.

In our case we are using Passenger.

On 5 March 2015 at 15:24, Henrik Lindberg 
wrote:

> On 2015-05-03 12:02, James Green wrote:
>
>> We occasionally have an agent fail because of this. I'm told by others
>> running the agents more frequently that it appears to be at random and
>> not on anything particularly large.
>>
>>
> If you are using webrick then it is most likely a concurrency problem
> (more than one agent calling in at the same time). Webrick is not
> recommended for production use because of this.
>
> - henrik
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
> --
> 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/md9sfc%24r1e%241%40ger.gmane.org.
>
> 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/CAMH6%2Bays%2B5UYx4Lk51R0ZXrJNL6bCWtnTjGOPCyKprUr5F6Ygg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Error in provisioning with puppet

[Ash26]

I am trying to build a Win 2008 R1 SP2 baked AMI using packer and puppet.

My builder works fine and creates the AMI with puppet installed.

Now in my provisioner I have a very simple puppet script and it is 
executing when I do a puppet apply on the instance.

But inside packer it is failing with the below error. The  json file was 
validated successfully by packer.

amazon-windows-ebs: Provisioning with Puppet...
amazon-windows-ebs: Creating Puppet staging directory...
amazon-windows-ebs: The syntax of the command is incorrect.

This is my provisioner

"provisioners":[{
  "type": "puppet-masterless",
  "manifest_file": 
"C:\\Users\\xyz\\Downloads\\packer_0.7.5_windows_386\\site.pp"
}]

Please provide pointers.

-- 
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/0732c5b0-1f9a-4827-8981-fb744f41126d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.