[Puppet Users] Is there a way to publish a module via the Forge API?

[Amos Shapira]

Hello,

I didn't find a way to upload a module to the Forge using the Forge API. Is 
this possible?

I find it a bit weird that a tool which advocates "infrastructure as code" 
doesn't cater for options to script module uploads.

Am I missing something?

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/8cbb7e19-dbf8-4f06-9a52-76ebb5c24287%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Announce: Puppet Agent 1.5.0, Puppet Server 2.4.0

[Eric Sorenson]

On May 19, 2016, at 5:54 PM, Eric Sorenson > wrote:
> 
>   * Puppet 4.5.0 - Also primarily a bugfix release, with improvements in the 
> type system and a few hotly awaited fixes for systemd and the DNF package 
> manager. The release notes mention new functions (including a function named 
> "new") that need

... to be added to the type reference on the website, but for now you can check 
out the inline docs at:
 https://github.com/puppetlabs/puppet/tree/master/lib/puppet/functions 


(WHUPS! Thanks Rob Nelson for pointing out my half-baked sentence.)

Eric Sorenson - eric.soren...@puppet.com  - 
freenode #puppet: eric0
puppet platform // coffee // techno // bicycles

-- 
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/3FE92236-E9CE-45CD-B7EB-0094A55BBBD2%40puppet.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announce: Puppet Agent 1.5.0, Puppet Server 2.4.0

[Eric Sorenson]

I'm excited to announce a new batch of backwards-compatible feature releases 
for the Puppet Agent and Server.  There's a lot to take in here, so check out 
the release notes and take the code for a test-drive before you yell out 
"YOLO!" and upgrade all of production.

Puppet Server 2.4.0 - A slew of bugfixes and an enhancement to the 
trapperkeeper auth.conf implementation that allows you to use certificate 
extensions in your auth.conf rules. So for example you can assign your trusted 
management nodes a certificate that contains new authorization extensions 
indicating they ought to have higher privilege, then match those extensions in 
the rules that permit cert management or catalog request commands, avoiding the 
need to keep a list of privileged hostnames in your auth.conf.
Check out the full release notes here: 
https://docs.puppet.com/puppetserver/latest/release_notes.html 


Puppet Agent 1.5.0 - All-in-one Agent package contains updated component 
versions, including a new feature release of Puppet.
  * Ruby 2.1.9 update
  * Puppet 4.5.0 - Also primarily a bugfix release, with improvements in the 
type system and a few hotly awaited fixes for systemd and the DNF package 
manager. The release notes mention new functions (including a function named 
"new") that needs
  * Facter 3.1.7 - Bugfixes for GCE and one particularly nasty recursion / 
fork-bomb that could happen if facter was invoked from inside a fact (I know...)
  * Hiera 3.2.0 - There's a backwards-compatible change that moves the default 
location of hiera.yaml out of the 'codedir' and back into 'config'. Read up on 
the backstory at HI-490 or on the puppet-dev thread[1], but the tl;dr is that 
we realized having this file (whose contents are frequently managed by puppet) 
inside the code dir (which is managed by r10k) was a mistake, and this change 
unwinds that, hopefully without introducing any additional badness. 
Release notes for each of these are linked from the main puppet-agent note: 
https://docs.puppet.com/puppet/4.5/reference/release_notes_agent.html 


Special community shout-out to Matthew Gyurgyik (whose name I admit i 
copy-pasted from JIRA) for working through the systemd issues! 

Eric Sorenson - eric.soren...@puppet.com  - 
freenode #puppet: eric0
puppet platform // coffee // techno // bicycles

[1]: https://groups.google.com/d/topic/puppet-dev/NQBK0vdp2E0/discussion 


-- 
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/5F9C86BD-A678-44B2-91CC-C371F17F912E%40puppet.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] the issues with thias/fooacl: filesystem ACL

[Ken Lareau]

On Thu, May 19, 2016 at 5:04 PM, Sans  wrote:

Hi there,
>
> Is anyone using thias/fooacl
>  module? I use it for
> WordPress, to give www-data read access to wp-config.php and few other
> files. Every time puppet runs, the file becomes unreadable:
>
> # file: wp-config.php
> # owner: root
> # group: root
> user::r--
> user:www-data:r--   #effective:---
> group::---
> mask::---
> other::---
>
> eventually breaking the whole site. Any idea why that's happening? And/or
> how can I fix that? Really appreciate any help on this.
>
>
If the file changes, fooacl on its own won't notice the change and won't
reset the ACLs.  You need to notify the class to ensure it does catch
this.  We have something like this for ours that we put after the fooacl
resource:

File[] ~> Class['::fooacl']

Hopefully this helps.

-- 
Ken Lareau

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

[Puppet Users] the issues with thias/fooacl: filesystem ACL

[Sans]

Hi there,

Is anyone using thias/fooacl  
module? I use it for WordPress, to give www-data read access to wp-config.php 
and few other files. Every time puppet runs, the file becomes unreadable: 

# file: wp-config.php
# owner: root
# group: root
user::r--
user:www-data:r--   #effective:---
group::---
mask::---
other::---

eventually breaking the whole site. Any idea why that's happening? And/or 
how can I fix that? Really appreciate any help on this.

-San

-- 
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/baa51382-f4a7-42b5-ad76-e5365178b0be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[Peter Huene]

On Thu, May 19, 2016 at 2:52 PM, David Karr 
wrote:

> On Thursday, May 19, 2016 at 2:36:53 PM UTC-7, Peter Huene wrote:
>
>>
>> On Thu, May 19, 2016 at 2:23 PM, David Karr 
>> wrote:
>>
>>> On Thursday, May 19, 2016 at 2:16:17 PM UTC-7, Peter Huene wrote:

 Hi David:

 On Thu, May 19, 2016 at 1:57 PM, David Karr 
 wrote:

> I'm stepping through "Learning Puppet 4", and I ran into an error
> following steps in the book, and I want to understand what went wrong
> before I report it.
>
> The section in question is "Using Puppet EPP Templates" in chapter 13.
>
> I'll work backwards from the error I'm getting, showing the relevant
> files afterwards.  Here is what I see when I apply the manifest:
> [vagrant@client puppet]$ sudo puppet apply --environment test
> manifests/
> Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/
> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf
> .epp:3:21
> Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/
> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf
> .epp:7:7
> Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code
> /environments/test/modules/puppet/templates/puppet.conf.epp:10:18
> Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/
> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf
> .epp:14:7
> Notice: Compiled catalog for client.example.com in environment test in
> 0.04 seconds
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
> content: content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to
> '{md5}0f89a3d91b54aec8463b4a250a493f36'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
> owner: owner changed 'vagrant' to 'root'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
> group: group changed 'vagrant' to 'wheel'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
> mode: mode changed '0664' to '0644'
> Notice: Applied catalog in 0.06 seconds
> [vagrant@client puppet]$
>
>
 Based on the warnings, it looks like the "puppet" class hasn't been
 declared.  Did you `include puppet` somewhere or otherwise classify the
 node to include the "puppet" class?

>>>
>>> The only file in the "manifests" directory is "init.pp", which is this:
>>> class puppet(
>>>   # input parameters and default values for the class
>>>   $version = 'latest',
>>>   $status  = 'running',
>>>   $enabled = true,
>>>   $server  = 'puppet.example.com',
>>>   $common_loglevel = 'warning',
>>>   $agent_loglevel  = undef,
>>>   $apply_loglevel  = undef,
>>> ) {
>>>
>>>   # echo the input provided
>>>   notice("Install the $version version of Puppet, ensure it's $status,
>>> and set boot time start $enabled.")
>>>
>>>   # install puppet-agent
>>>   package { 'puppet-agent':
>>> ensure => 'latest',
>>> notify => Service['puppet'],
>>>   }
>>>
>>>   # manage the puppet service
>>>   service { 'puppet':
>>> ensure => 'running',
>>> enable => true,
>>> subscribe => Package['puppet-agent'],
>>>   }
>>> }
>>>
>>> class puppet::agent {
>>> }
>>>
>>> file { '/etc/puppetlabs/puppet/puppet.conf':
>>>   ensure => file,
>>>   owner => 'root',
>>>   group => 'wheel',
>>>   mode  => '0644',
>>> #  source => 'puppet:///modules/puppet/puppet.conf',
>>>   content => epp('puppet/puppet.conf.epp'),
>>> }
>>>
>>>
>> Without including the puppet class, the evaluation of the epp function
>> here will result in those "unknown variable" warnings and they will
>> evaluate to undef (or cause an error in more recent versions of Puppet with
>> strict variable checking enabled).
>>
>
> Ok, so it appears that if I add "include puppet" right after the body of
> the "puppet" class, it processes the template without undefined variable
> references.  That just seems odd.  Is that really what I need to do?
>

There are two parts to using a class in Puppet: defining the class and
declaring the class.

Defining a class is what you were originally doing (i.e. "class puppet(...)
{ ... }"); this lets Puppet's compiler know that there is a class named
"puppet" so that it can later be declared, usually based on some
conditional logic specific to the node's role.

Declaring a class (one possible way is by calling the "include" function)
causes the compiler to evaluate the class' parameters into its scope
(something your EPP was relying on) and evaluates the class' body, in this
case adding the package and service resources to the resource catalog.
Typically class declaration is performed through a node classifier, Hiera
data, or node definition statements in your site.pp.

I'm not the best explainer, so perhaps the docs can be of more help:

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[David Karr]

On Thursday, May 19, 2016 at 2:36:53 PM UTC-7, Peter Huene wrote:
>
>
> On Thu, May 19, 2016 at 2:23 PM, David Karr  > wrote:
>
>> On Thursday, May 19, 2016 at 2:16:17 PM UTC-7, Peter Huene wrote:
>>>
>>> Hi David:
>>>
>>> On Thu, May 19, 2016 at 1:57 PM, David Karr  
>>> wrote:
>>>
 I'm stepping through "Learning Puppet 4", and I ran into an error 
 following steps in the book, and I want to understand what went wrong 
 before I report it.

 The section in question is "Using Puppet EPP Templates" in chapter 13.

 I'll work backwards from the error I'm getting, showing the relevant 
 files afterwards.  Here is what I see when I apply the manifest:
 [vagrant@client puppet]$ sudo puppet apply --environment test manifests
 /
 Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/
 puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf.
 epp:3:21
 Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/puppetlabs
 /code/environments/test/modules/puppet/templates/puppet.conf.epp:7:7
 Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code/
 environments/test/modules/puppet/templates/puppet.conf.epp:10:18
 Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/puppetlabs
 /code/environments/test/modules/puppet/templates/puppet.conf.epp:14:7
 Notice: Compiled catalog for client.example.com in environment test in 
 0.04 seconds
 Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
 content: content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to 
 '{md5}0f89a3d91b54aec8463b4a250a493f36'
 Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
 owner: owner changed 'vagrant' to 'root'
 Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
 group: group changed 'vagrant' to 'wheel'
 Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/mode
 : mode changed '0664' to '0644'
 Notice: Applied catalog in 0.06 seconds
 [vagrant@client puppet]$ 


>>> Based on the warnings, it looks like the "puppet" class hasn't been 
>>> declared.  Did you `include puppet` somewhere or otherwise classify the 
>>> node to include the "puppet" class? 
>>>
>>
>> The only file in the "manifests" directory is "init.pp", which is this:
>> class puppet(
>>   # input parameters and default values for the class
>>   $version = 'latest',
>>   $status  = 'running',
>>   $enabled = true,
>>   $server  = 'puppet.example.com',
>>   $common_loglevel = 'warning',
>>   $agent_loglevel  = undef,
>>   $apply_loglevel  = undef,
>> ) {
>>
>>   # echo the input provided
>>   notice("Install the $version version of Puppet, ensure it's $status, 
>> and set boot time start $enabled.")
>>
>>   # install puppet-agent
>>   package { 'puppet-agent':
>> ensure => 'latest',
>> notify => Service['puppet'],
>>   }
>>
>>   # manage the puppet service
>>   service { 'puppet':
>> ensure => 'running',
>> enable => true,
>> subscribe => Package['puppet-agent'],
>>   }
>> }
>>
>> class puppet::agent {
>> }
>>
>> file { '/etc/puppetlabs/puppet/puppet.conf':
>>   ensure => file,
>>   owner => 'root',
>>   group => 'wheel',
>>   mode  => '0644',
>> #  source => 'puppet:///modules/puppet/puppet.conf',
>>   content => epp('puppet/puppet.conf.epp'),
>> }
>>
>>
> Without including the puppet class, the evaluation of the epp function 
> here will result in those "unknown variable" warnings and they will 
> evaluate to undef (or cause an error in more recent versions of Puppet with 
> strict variable checking enabled). 
>

Ok, so it appears that if I add "include puppet" right after the body of 
the "puppet" class, it processes the template without undefined variable 
references.  That just seems odd.  Is that really what I need to do?
 

>  
>
>>  
>>
>>>  
>>>
 The template in question, right from the book, is this:

 # Generated by Puppet EPP template processor
 [master]
 log_level = <%= $::puppet::common_loglevel %>

 # This is used by "puppet agent"
 [agent]
 <% if $puppet::agent_loglevel != undef { -%>
 log_level = <%= $::puppet::agent_loglevel %>
 <% } -%>
 server = <%= $::puppet::server %>

 # This is used for "puppet apply"
 [user]
 <% if $puppet::apply_loglevel != undef { -%>
 log_level = <%= $::puppet::apply_loglevel %>
 <% } -%>


 Likely the most important piece to see now is the part of the "init.pp" 
 manifest that declares the parameters being referenced here:

 class puppet(
   $version = 'latest',
   $status  = 'running',
   $enabled = true,
   


 *$server  = 'puppet.example.com ',  
 $common_loglevel = 'warning',  

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[Peter Huene]

On Thu, May 19, 2016 at 2:23 PM, David Karr 
wrote:

> On Thursday, May 19, 2016 at 2:16:17 PM UTC-7, Peter Huene wrote:
>>
>> Hi David:
>>
>> On Thu, May 19, 2016 at 1:57 PM, David Karr 
>> wrote:
>>
>>> I'm stepping through "Learning Puppet 4", and I ran into an error
>>> following steps in the book, and I want to understand what went wrong
>>> before I report it.
>>>
>>> The section in question is "Using Puppet EPP Templates" in chapter 13.
>>>
>>> I'll work backwards from the error I'm getting, showing the relevant
>>> files afterwards.  Here is what I see when I apply the manifest:
>>> [vagrant@client puppet]$ sudo puppet apply --environment test manifests/
>>> Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/
>>> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf.
>>> epp:3:21
>>> Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/puppetlabs/
>>> code/environments/test/modules/puppet/templates/puppet.conf.epp:7:7
>>> Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code/
>>> environments/test/modules/puppet/templates/puppet.conf.epp:10:18
>>> Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/puppetlabs/
>>> code/environments/test/modules/puppet/templates/puppet.conf.epp:14:7
>>> Notice: Compiled catalog for client.example.com in environment test in
>>> 0.04 seconds
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
>>> content: content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to
>>> '{md5}0f89a3d91b54aec8463b4a250a493f36'
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/owner
>>> : owner changed 'vagrant' to 'root'
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/group
>>> : group changed 'vagrant' to 'wheel'
>>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/mode:
>>> mode changed '0664' to '0644'
>>> Notice: Applied catalog in 0.06 seconds
>>> [vagrant@client puppet]$
>>>
>>>
>> Based on the warnings, it looks like the "puppet" class hasn't been
>> declared.  Did you `include puppet` somewhere or otherwise classify the
>> node to include the "puppet" class?
>>
>
> The only file in the "manifests" directory is "init.pp", which is this:
> class puppet(
>   # input parameters and default values for the class
>   $version = 'latest',
>   $status  = 'running',
>   $enabled = true,
>   $server  = 'puppet.example.com',
>   $common_loglevel = 'warning',
>   $agent_loglevel  = undef,
>   $apply_loglevel  = undef,
> ) {
>
>   # echo the input provided
>   notice("Install the $version version of Puppet, ensure it's $status,
> and set boot time start $enabled.")
>
>   # install puppet-agent
>   package { 'puppet-agent':
> ensure => 'latest',
> notify => Service['puppet'],
>   }
>
>   # manage the puppet service
>   service { 'puppet':
> ensure => 'running',
> enable => true,
> subscribe => Package['puppet-agent'],
>   }
> }
>
> class puppet::agent {
> }
>
> file { '/etc/puppetlabs/puppet/puppet.conf':
>   ensure => file,
>   owner => 'root',
>   group => 'wheel',
>   mode  => '0644',
> #  source => 'puppet:///modules/puppet/puppet.conf',
>   content => epp('puppet/puppet.conf.epp'),
> }
>
>
Without including the puppet class, the evaluation of the epp function here
will result in those "unknown variable" warnings and they will evaluate to
undef (or cause an error in more recent versions of Puppet with strict
variable checking enabled).


>
>
>>
>>
>>> The template in question, right from the book, is this:
>>>
>>> # Generated by Puppet EPP template processor
>>> [master]
>>> log_level = <%= $::puppet::common_loglevel %>
>>>
>>> # This is used by "puppet agent"
>>> [agent]
>>> <% if $puppet::agent_loglevel != undef { -%>
>>> log_level = <%= $::puppet::agent_loglevel %>
>>> <% } -%>
>>> server = <%= $::puppet::server %>
>>>
>>> # This is used for "puppet apply"
>>> [user]
>>> <% if $puppet::apply_loglevel != undef { -%>
>>> log_level = <%= $::puppet::apply_loglevel %>
>>> <% } -%>
>>>
>>>
>>> Likely the most important piece to see now is the part of the "init.pp"
>>> manifest that declares the parameters being referenced here:
>>>
>>> class puppet(
>>>   $version = 'latest',
>>>   $status  = 'running',
>>>   $enabled = true,
>>>
>>>
>>>
>>> *$server  = 'puppet.example.com ',  
>>> $common_loglevel = 'warning',  $agent_loglevel  = undef,  $apply_loglevel  
>>> = undef,*
>>> ) {
>>>
>>>
>>> I imagine the syntax of the variable references in the EPP file have to
>>> be slightly different, but I have no idea what it should be.
>>>
>>
>> The EPP is fine; the code inside an EPP <% %> is expected to be valid
>> Puppet code.
>>
>>
>>>
>>> I also find it curious that the error messages print the name of the
>>> variable differently for different messages, sometimes prefixed with "::"

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[David Karr]

On Thursday, May 19, 2016 at 2:16:17 PM UTC-7, Peter Huene wrote:
>
> Hi David:
>
> On Thu, May 19, 2016 at 1:57 PM, David Karr  > wrote:
>
>> I'm stepping through "Learning Puppet 4", and I ran into an error 
>> following steps in the book, and I want to understand what went wrong 
>> before I report it.
>>
>> The section in question is "Using Puppet EPP Templates" in chapter 13.
>>
>> I'll work backwards from the error I'm getting, showing the relevant 
>> files afterwards.  Here is what I see when I apply the manifest:
>> [vagrant@client puppet]$ sudo puppet apply --environment test manifests/
>> Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/
>> puppetlabs/code/environments/test/modules/puppet/templates/puppet.conf.
>> epp:3:21
>> Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/puppetlabs/
>> code/environments/test/modules/puppet/templates/puppet.conf.epp:7:7
>> Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code/
>> environments/test/modules/puppet/templates/puppet.conf.epp:10:18
>> Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/puppetlabs/
>> code/environments/test/modules/puppet/templates/puppet.conf.epp:14:7
>> Notice: Compiled catalog for client.example.com in environment test in 
>> 0.04 seconds
>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/
>> content: content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to 
>> '{md5}0f89a3d91b54aec8463b4a250a493f36'
>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/owner: 
>> owner changed 'vagrant' to 'root'
>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/group: 
>> group changed 'vagrant' to 'wheel'
>> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/mode: 
>> mode changed '0664' to '0644'
>> Notice: Applied catalog in 0.06 seconds
>> [vagrant@client puppet]$ 
>>
>>
> Based on the warnings, it looks like the "puppet" class hasn't been 
> declared.  Did you `include puppet` somewhere or otherwise classify the 
> node to include the "puppet" class? 
>

The only file in the "manifests" directory is "init.pp", which is this:
class puppet(
  # input parameters and default values for the class
  $version = 'latest',
  $status  = 'running',
  $enabled = true,
  $server  = 'puppet.example.com',
  $common_loglevel = 'warning',
  $agent_loglevel  = undef,
  $apply_loglevel  = undef,
) {

  # echo the input provided
  notice("Install the $version version of Puppet, ensure it's $status, and 
set boot time start $enabled.")

  # install puppet-agent
  package { 'puppet-agent':
ensure => 'latest',
notify => Service['puppet'],
  }

  # manage the puppet service
  service { 'puppet':
ensure => 'running',
enable => true,
subscribe => Package['puppet-agent'],
  }
}

class puppet::agent {
}

file { '/etc/puppetlabs/puppet/puppet.conf':
  ensure => file,
  owner => 'root',
  group => 'wheel',
  mode  => '0644',
#  source => 'puppet:///modules/puppet/puppet.conf',
  content => epp('puppet/puppet.conf.epp'),
}

 

>  
>
>> The template in question, right from the book, is this:
>>
>> # Generated by Puppet EPP template processor
>> [master]
>> log_level = <%= $::puppet::common_loglevel %>
>>
>> # This is used by "puppet agent"
>> [agent]
>> <% if $puppet::agent_loglevel != undef { -%>
>> log_level = <%= $::puppet::agent_loglevel %>
>> <% } -%>
>> server = <%= $::puppet::server %>
>>
>> # This is used for "puppet apply"
>> [user]
>> <% if $puppet::apply_loglevel != undef { -%>
>> log_level = <%= $::puppet::apply_loglevel %>
>> <% } -%>
>>
>>
>> Likely the most important piece to see now is the part of the "init.pp" 
>> manifest that declares the parameters being referenced here:
>>
>> class puppet(
>>   $version = 'latest',
>>   $status  = 'running',
>>   $enabled = true,
>>   
>>
>>
>> *$server  = 'puppet.example.com ',  
>> $common_loglevel = 'warning',  $agent_loglevel  = undef,  $apply_loglevel  = 
>> undef,*
>> ) {
>>
>>
>> I imagine the syntax of the variable references in the EPP file have to 
>> be slightly different, but I have no idea what it should be.
>>
>
> The EPP is fine; the code inside an EPP <% %> is expected to be valid 
> Puppet code.
>  
>
>>
>> I also find it curious that the error messages print the name of the 
>> variable differently for different messages, sometimes prefixed with "::" 
>> and sometimes not.  Any background that would explain that?
>>
>
> When a variable name has a leading "::" it forces a lookup in the 
> top-scope.  An example where it would be needed is when you have a 
> top-scoped variable and a local variable of the same name; a leading "::" 
> would ensure that the top-scope variable is used and not the local variable.
>

Perhaps I wasn't clear.  All the variable references in the template use 
the same syntax, using the "$::puppet" 

Re: [Puppet Users] Error with EPP template from "Learning Puppet 4"

[Peter Huene]

Hi David:

On Thu, May 19, 2016 at 1:57 PM, David Karr 
wrote:

> I'm stepping through "Learning Puppet 4", and I ran into an error
> following steps in the book, and I want to understand what went wrong
> before I report it.
>
> The section in question is "Using Puppet EPP Templates" in chapter 13.
>
> I'll work backwards from the error I'm getting, showing the relevant files
> afterwards.  Here is what I see when I apply the manifest:
> [vagrant@client puppet]$ sudo puppet apply --environment test manifests/
> Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/puppetlabs
> /code/environments/test/modules/puppet/templates/puppet.conf.epp:3:21
> Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/puppetlabs/
> code/environments/test/modules/puppet/templates/puppet.conf.epp:7:7
> Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code/
> environments/test/modules/puppet/templates/puppet.conf.epp:10:18
> Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/puppetlabs/
> code/environments/test/modules/puppet/templates/puppet.conf.epp:14:7
> Notice: Compiled catalog for client.example.com in environment test in
> 0.04 seconds
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/content
> : content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to
> '{md5}0f89a3d91b54aec8463b4a250a493f36'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/owner:
> owner changed 'vagrant' to 'root'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/group:
> group changed 'vagrant' to 'wheel'
> Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/mode:
> mode changed '0664' to '0644'
> Notice: Applied catalog in 0.06 seconds
> [vagrant@client puppet]$
>
>
Based on the warnings, it looks like the "puppet" class hasn't been
declared.  Did you `include puppet` somewhere or otherwise classify the
node to include the "puppet" class?


> The template in question, right from the book, is this:
>
> # Generated by Puppet EPP template processor
> [master]
> log_level = <%= $::puppet::common_loglevel %>
>
> # This is used by "puppet agent"
> [agent]
> <% if $puppet::agent_loglevel != undef { -%>
> log_level = <%= $::puppet::agent_loglevel %>
> <% } -%>
> server = <%= $::puppet::server %>
>
> # This is used for "puppet apply"
> [user]
> <% if $puppet::apply_loglevel != undef { -%>
> log_level = <%= $::puppet::apply_loglevel %>
> <% } -%>
>
>
> Likely the most important piece to see now is the part of the "init.pp"
> manifest that declares the parameters being referenced here:
>
> class puppet(
>   $version = 'latest',
>   $status  = 'running',
>   $enabled = true,
>
>
>
> *$server  = 'puppet.example.com ',  
> $common_loglevel = 'warning',  $agent_loglevel  = undef,  $apply_loglevel  = 
> undef,*
> ) {
>
>
> I imagine the syntax of the variable references in the EPP file have to be
> slightly different, but I have no idea what it should be.
>

The EPP is fine; the code inside an EPP <% %> is expected to be valid
Puppet code.


>
> I also find it curious that the error messages print the name of the
> variable differently for different messages, sometimes prefixed with "::"
> and sometimes not.  Any background that would explain that?
>

When a variable name has a leading "::" it forces a lookup in the
top-scope.  An example where it would be needed is when you have a
top-scoped variable and a local variable of the same name; a leading "::"
would ensure that the top-scope variable is used and not the local variable.

For what it's worth, here's what a warning from a prototype Puppet compiler
I'm working on looks like when evaluating your example (hopefully it's a
bit more clear):

Warning: :3:21: could not look up variable $::puppet::common_loglevel
because class 'puppet' has not been declared.
  log_level = <%= $::puppet::common_loglevel %>
  ^~
 ...

Note: the filename is "" because I stuck your EPP source in an
"inline_epp" call rather than a file.


> --
> 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/01a83a7f-c3f2-4ca6-83d9-df09bec41527%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 

[Puppet Users] Error with EPP template from "Learning Puppet 4"

[David Karr]

I'm stepping through "Learning Puppet 4", and I ran into an error following 
steps in the book, and I want to understand what went wrong before I report 
it.

The section in question is "Using Puppet EPP Templates" in chapter 13.

I'll work backwards from the error I'm getting, showing the relevant files 
afterwards.  Here is what I see when I apply the manifest:
[vagrant@client puppet]$ sudo puppet apply --environment test manifests/
Warning: Unknown variable: '::puppet::common_loglevel'. at /etc/puppetlabs/
code/environments/test/modules/puppet/templates/puppet.conf.epp:3:21
Warning: Unknown variable: 'puppet::agent_loglevel'. at /etc/puppetlabs/code
/environments/test/modules/puppet/templates/puppet.conf.epp:7:7
Warning: Unknown variable: '::puppet::server'. at /etc/puppetlabs/code/
environments/test/modules/puppet/templates/puppet.conf.epp:10:18
Warning: Unknown variable: 'puppet::apply_loglevel'. at /etc/puppetlabs/code
/environments/test/modules/puppet/templates/puppet.conf.epp:14:7
Notice: Compiled catalog for client.example.com in environment test in 0.04 
seconds
Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/content: 
content changed '{md5}a72aadac19feefd06f10fb6b8f90c5f4' to 
'{md5}0f89a3d91b54aec8463b4a250a493f36'
Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/owner: 
owner changed 'vagrant' to 'root'
Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/group: 
group changed 'vagrant' to 'wheel'
Notice: /Stage[main]/Main/File[/etc/puppetlabs/puppet/puppet.conf]/mode: 
mode changed '0664' to '0644'
Notice: Applied catalog in 0.06 seconds
[vagrant@client puppet]$ 

The template in question, right from the book, is this:

# Generated by Puppet EPP template processor
[master]
log_level = <%= $::puppet::common_loglevel %>

# This is used by "puppet agent"
[agent]
<% if $puppet::agent_loglevel != undef { -%>
log_level = <%= $::puppet::agent_loglevel %>
<% } -%>
server = <%= $::puppet::server %>

# This is used for "puppet apply"
[user]
<% if $puppet::apply_loglevel != undef { -%>
log_level = <%= $::puppet::apply_loglevel %>
<% } -%>


Likely the most important piece to see now is the part of the "init.pp" 
manifest that declares the parameters being referenced here:

class puppet(
  $version = 'latest',
  $status  = 'running',
  $enabled = true,
  


*$server  = 'puppet.example.com',  $common_loglevel = 'warning',  
$agent_loglevel  = undef,  $apply_loglevel  = undef,*
) {


I imagine the syntax of the variable references in the EPP file have to be 
slightly different, but I have no idea what it should be.

I also find it curious that the error messages print the name of the 
variable differently for different messages, sometimes prefixed with "::" 
and sometimes not.  Any background that would explain that?

-- 
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/01a83a7f-c3f2-4ca6-83d9-df09bec41527%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announce: PuppetDB 4.1.0 is now available

[Ryan Senior]

PuppetDB 4.1.0 - May 19, 2016
===

PuppetDB 4.1.0 is a backward-compatible feature release that adds packages
for Ubuntu Xenial - 16.04, Ubuntu Wily - 15.10, adds preliminary support
for HUP signal handling, and improves the speed of removing old reports,
and of expiring or purging nodes.

PuppetDB 4.1.0 Downloads


Available in native package format as part of Puppet Collection 1
(PC1). More information on the PC1 repositories is available here:
https://bit.ly/1MpEieG

Binary tarball: https://downloads.puppetlabs.com/puppetdb/

Source: https://github.com/puppetlabs/puppetdb

Please report feedback via the Puppet Labs tickets site, using an
affected PuppetDB version of 4.1.0:
https://tickets.puppetlabs.com/browse/PDB

Documentation: https://docs.puppetlabs.com/puppetdb/4.1/

Puppet module: https://forge.puppetlabs.com/puppetlabs/puppetdb

PuppetDB 4.1.0 Release Notes


Please consult the release notes here:
https://docs.puppetlabs.com/puppetdb/4.1/release_notes.html

Contributors

Andrew Roetker, Karel Brezina, Ken Barber, François Lafont, Melissa Stone,
Nick Lewis, Rob Browning, Ryan Senior, Steve Axthelm, Wyatt Alt

-- 
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/CAGDMwd3pSh6RGYju6sekY%3DZ_AEo%2BfiT2aX1Jg-wy4Zgv%2Bz7LoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Logrotate module broken, string 'undef' now treated as undef

[Daniel Urist]

Here's some code to try:

  $var1 = undef
  $var2 = "undef"
  $var3 = 'undef'
  $var4 = "'undef'"
  $var5 = '"undef"'
  notify { "VAR1: ${var1} VAR2: ${var2} VAR3: ${var3} VAR4: ${var4} VAR5:
${var5}": }

When run, this results in:

  Notice: VAR1:  VAR2:  VAR3:  VAR4: 'undef' VAR5: "undef"

On Thu, May 19, 2016 at 8:30 AM, Daniel Urist  wrote:

> puppetserver: 2.3.2-1puppetlabs1
> puppet client: 3.8.5-2~bpo8+1
>
> Both server and clients are running Debian 8 (jessie); the puppet client
> is from the Debian backports repo.
>
> On Wed, May 18, 2016 at 3:40 PM, Matthaus Owens 
> wrote:
>
>> Daniel,
>> Which version of Puppet are you seeing this on?
>>
>> On Wed, May 18, 2016 at 2:33 PM, Daniel Urist  wrote:
>>
>>> I have been using the yo61 logrotate module from puppetforge (
>>> https://forge.puppet.com/yo61/logrotate), which seems to be the most
>>> popular, but it recently stopped working, with many errors about undefined
>>> parameters.
>>>
>>> The issue seems to be the use of the string 'undef' as a default value;
>>> for example:
>>>
>>> define logrotate::rule(
 $create_owner   = 'undef',

>>>
>>> Later on in the code, there are comparisons against the actual string
>>> 'undef'; for example:
>>>
>>>
>>>   if ($create_owner != 'undef') and ($create_mode == 'undef') {
 fail("Logrotate::Rule[${name}]: create_owner requires create_mode")
}
>>>
>>>
>>> Regardless of whether this is best practice, these comparisons are now
>>> failing, apparently because the string 'undef' is now treated as the value
>>> undef. I've confirmed this by printing the string with notify (prints
>>> nothing when it's 'undef'), and changing it to something else, which does
>>> print.
>>>
>>> I'm not sure exactly when this changed or if it's intended behavior or a
>>> bug, but it does seem odd that now apparently 'undef' === undef
>>>
>>> --
>>> 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/CAEo6%3DKYjAx286r9NNvKtGU3PscrAZ77H5_HXc9CXO1LLa552sg%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/CACD%3DwAcwR0OdVsPguNNzzeqZ_LUHMoLhAyhTJP56bAZDc0J6Jw%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/CAEo6%3DKZ-Ayz5pz%3Djs-EdO8%2BbkP7seQjKNBL-NSKjCnFzdhSavQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to control who can add/update permissions in sudoers

[Rob Nelson]

This is probably something that should be addressed via code management or
audits, rather than via puppet. It can't really know e intentions, so if
someone wants to exec 'rm -fR' it will gleefully let it happen. It's on you
to trust your developers and have a pipeline to test things. Canary nodes
that can be audited may be a good idea here.

On Thursday, May 19, 2016, Alex Scoble  wrote:

> Problem is that if you don't have a way of limiting where sudo entries can
> be made, someone can create a new module and grant themselves full sudo
> rights there for a large number of systems. When in a large enterprise such
> as ours, there are modules that are created and maintained by teams outside
> of the main teams that maintain the bulk of the puppet code.
>
> I think one possibility we are looking in to is using Teamcity (could also
> be done with Jenkins) to check that sudo calls aren't made outside of our
> protected sudo module.
>
> --
> 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/5198fce0-fb84-42fe-bc8e-b6c2b48141d3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.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/CAC76iT8ogdZZ1iP5ebLRkjOeGDZU0-FUn12%2Bu1f1n-h0JLTerA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet 4 environments git feedback?

[Rob Nelson]

We use a cron job in addition to git hooks. The hooks work 99% of the time,
and the cron job handles the occasional miss because the network burped.
They're very complimentary.

On Thursday, May 19, 2016, Christopher Wood 
wrote:

> On Thu, May 19, 2016 at 11:39:30AM -0400, Rob Nelson wrote:
> >Doug,
> >
> >If all your git repositories are local filestores, that's probably a
> >pretty reasonable workflow. However, most people use some form of
> >dedicated service as their git origins, that reside external to the
> local
> >systems - GitHub, Bit Bucket, Git Lab, etc. If you are using one of
> those
> >systems, or you can migrate to it, you can then improve your code
> flow by
> >using pull requests to review changes and merge them into the branch
> at
> >the upstream. These services would also be able to fire a web hook, an
> >event sent to your puppet master as an http/https payload, that can
> >trigger r10k to deploy the updated code.
>
> Our inter-datacenter connectivity tends to skip a beat whenever there's a
> DDOS. It's old skule but a cron job gives us some easy resilience here.
>
> [root@puppetmaster6 ~]# crontab -l | grep r10k
> # Puppet Name: r10k deploy
> * * * * * /usr/bin/lockrun --lockfile=/var/run/r10k-deploy --
> /opt/puppetlabs/puppet/bin/r10k deploy environment --puppetfile >/dev/null
> 2>&1
>
> Also when I set this up there were issues setting up plain git hooks with
> the gitlab instance we were originally using, using a cron job saved weeks
> of inter-team ticket discussion judging by other hook tickets.
>
> >That might sound complicated, but I promise you, it's not. It's just
> using
> >some peculiar terminology you're not familiar with. For learning git
> and
> >services like GitHub, there are countless tutorials out there; I
> recommend
> >[1]https://github.com/commitmas/12-days-of-commitmas. That will
> introduce
> >you to git, GitHub, Pull Requests (PRs), and code review processes. I
> >wrote an article on using r10k with a webhook at
> >[2]
> https://rnelson0.com/2015/05/03/configuring-an-r10k-webhook-on-your-puppet-master/
> ,
> >and I and others have tons of articles about using r10k. With this in
> >place, your process would be a little simpler:
> >
> >  git commit -am 'Something I want to push to test'
> >  git push origin test_change
> >  
> >
> >The webhook fires, r10k starts deploying code, and in a few seconds to
> >minutes, your test environment has been updated to incorporate those
> >changes. You'd then use PRs to promote code from test -> dev -> qa ->
> uat
> >-> production. This has other impacts to your workflow, of course,
> and you
> >may actually be able to remove a level of environments (feature -> qa
> ->
> >uat -> production). You could later add some continuous integration
> tests
> >to your code, that are automatically run by GitHub/GitLab/Jenkins/etc,
> >which could lead to removing the qa level as well. But that's down the
> >road a bit.
> >
> >There is a lot of room for improvement here as you have time to focus
> on
> >your pipeline.
> >Rob Nelson
> >[3]rnels...@gmail.com 
> >On Wed, May 18, 2016 at 9:02 PM, dkoleary
> ><[4]dkole...@olearycomputers.com > wrote:
> >
> >  Hey;
> >  To put this in perspective, I'm a sysadmin, not a developer.  While
> I've
> >  used git for a couple of years, until today, I could easily count
> the
> >  number of times I issued a 'git branch' command.
> >  I'm practicing setting up a new puppet 4 server and, after some
> >  research, I've got various environments under git management and
> have
> >  successfully 'promoted code' from test through production.  It's a
> wee
> >  bit tedious but I'm sure I could get used to it.
> >  What I'm hoping is to have someone more familiar the process verify
> I'm
> >  doing it somewhat close to right and/or make suggestions on an
> >  improvements.  I have heard of r10k; however, I'm one of those that
> has
> >  to know what's going on under the covers.  Up until now, r10k has
> been
> >  of of those 'developer' things.  Once I run through this a few
> times,
> >  *then* I'll start playing with r10k.
> >  So, bit of a build up.  Here's what I have:
> >  one git repo covering all puppet environments thusly::
> >  # git branch -r
> >origin/HEAD -> origin/master
> >origin/dev
> >origin/master
> >origin/prod
> >origin/qa
> >origin/test
> >origin/uat
> >  On a different system, one pulls the test system, develops code,
> >  commits, pushes, etc.  In the test environment, the admin pulls the
> >  updated work and tests
> >  # pwd
> >  /etc/puppetlabs/code/environments/test
> >  # git branch
> >  * test
> >  once the tests are complete, a 

Re: [Puppet Users] puppet 4 environments git feedback?

[Christopher Wood]

On Thu, May 19, 2016 at 11:39:30AM -0400, Rob Nelson wrote:
>Doug,
> 
>If all your git repositories are local filestores, that's probably a
>pretty reasonable workflow. However, most people use some form of
>dedicated service as their git origins, that reside external to the local
>systems - GitHub, Bit Bucket, Git Lab, etc. If you are using one of those
>systems, or you can migrate to it, you can then improve your code flow by
>using pull requests to review changes and merge them into the branch at
>the upstream. These services would also be able to fire a web hook, an
>event sent to your puppet master as an http/https payload, that can
>trigger r10k to deploy the updated code.

Our inter-datacenter connectivity tends to skip a beat whenever there's a DDOS. 
It's old skule but a cron job gives us some easy resilience here.

[root@puppetmaster6 ~]# crontab -l | grep r10k
# Puppet Name: r10k deploy
* * * * * /usr/bin/lockrun --lockfile=/var/run/r10k-deploy -- 
/opt/puppetlabs/puppet/bin/r10k deploy environment --puppetfile >/dev/null 2>&1

Also when I set this up there were issues setting up plain git hooks with the 
gitlab instance we were originally using, using a cron job saved weeks of 
inter-team ticket discussion judging by other hook tickets.

>That might sound complicated, but I promise you, it's not. It's just using
>some peculiar terminology you're not familiar with. For learning git and
>services like GitHub, there are countless tutorials out there; I recommend
>[1]https://github.com/commitmas/12-days-of-commitmas. That will introduce
>you to git, GitHub, Pull Requests (PRs), and code review processes. I
>wrote an article on using r10k with a webhook at
>
> [2]https://rnelson0.com/2015/05/03/configuring-an-r10k-webhook-on-your-puppet-master/,
>and I and others have tons of articles about using r10k. With this in
>place, your process would be a little simpler:
> 
>  git commit -am 'Something I want to push to test'
>  git push origin test_change
>  
> 
>The webhook fires, r10k starts deploying code, and in a few seconds to
>minutes, your test environment has been updated to incorporate those
>changes. You'd then use PRs to promote code from test -> dev -> qa -> uat
>-> production. This has other impacts to your workflow, of course, and you
>may actually be able to remove a level of environments (feature -> qa ->
>uat -> production). You could later add some continuous integration tests
>to your code, that are automatically run by GitHub/GitLab/Jenkins/etc,
>which could lead to removing the qa level as well. But that's down the
>road a bit.
> 
>There is a lot of room for improvement here as you have time to focus on
>your pipeline.
>Rob Nelson
>[3]rnels...@gmail.com
>On Wed, May 18, 2016 at 9:02 PM, dkoleary
><[4]dkole...@olearycomputers.com> wrote:
> 
>  Hey;
>  To put this in perspective, I'm a sysadmin, not a developer.  While I've
>  used git for a couple of years, until today, I could easily count the
>  number of times I issued a 'git branch' command.
>  I'm practicing setting up a new puppet 4 server and, after some
>  research, I've got various environments under git management and have
>  successfully 'promoted code' from test through production.  It's a wee
>  bit tedious but I'm sure I could get used to it.
>  What I'm hoping is to have someone more familiar the process verify I'm
>  doing it somewhat close to right and/or make suggestions on an
>  improvements.  I have heard of r10k; however, I'm one of those that has
>  to know what's going on under the covers.  Up until now, r10k has been
>  of of those 'developer' things.  Once I run through this a few times,
>  *then* I'll start playing with r10k.
>  So, bit of a build up.  Here's what I have:
>  one git repo covering all puppet environments thusly::
>  # git branch -r
>    origin/HEAD -> origin/master
>    origin/dev
>    origin/master
>    origin/prod
>    origin/qa
>    origin/test
>    origin/uat
>  On a different system, one pulls the test system, develops code,
>  commits, pushes, etc.  In the test environment, the admin pulls the
>  updated work and tests
>  # pwd
>  /etc/puppetlabs/code/environments/test
>  # git branch
>  * test
>  once the tests are complete, a responsible admin accesses the dev
>  environment and executes:
>  git checkout test 
>  git pull # if necessary
>  git checkout dev
>  git merge test
>  Process iterates through the environments to prod.  
>  # git log --oneline
>  e298de7 prod.rst: mved from uat
>  07f3ab1 uat: merged from qa
>  a20a85c qa: mved from dev
>  2f644f2 dev: renamed from test
>  c8c067b test: added
>  a432124 puppet production environment initial check in
>  

Re: [Puppet Users] Re: How to control who can add/update permissions in sudoers

[Alex Scoble]

Problem is that if you don't have a way of limiting where sudo entries can 
be made, someone can create a new module and grant themselves full sudo 
rights there for a large number of systems. When in a large enterprise such 
as ours, there are modules that are created and maintained by teams outside 
of the main teams that maintain the bulk of the puppet code.

I think one possibility we are looking in to is using Teamcity (could also 
be done with Jenkins) to check that sudo calls aren't made outside of our 
protected sudo module.

-- 
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/5198fce0-fb84-42fe-bc8e-b6c2b48141d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet 4 environments git feedback?

[Rob Nelson]

Doug,

If all your git repositories are local filestores, that's probably a pretty
reasonable workflow. However, most people use some form of dedicated
service as their git origins, that reside external to the local systems -
GitHub, Bit Bucket, Git Lab, etc. If you are using one of those systems, or
you can migrate to it, you can then improve your code flow by using pull
requests to review changes and merge them into the branch at the upstream.
These services would also be able to fire a web hook, an event sent to your
puppet master as an http/https payload, that can trigger r10k to deploy the
updated code.

That might sound complicated, but I promise you, it's not. It's just using
some peculiar terminology you're not familiar with. For learning git and
services like GitHub, there are countless tutorials out there; I recommend
https://github.com/commitmas/12-days-of-commitmas. That will introduce you
to git, GitHub, Pull Requests (PRs), and code review processes. I wrote an
article on using r10k with a webhook at
https://rnelson0.com/2015/05/03/configuring-an-r10k-webhook-on-your-puppet-master/,
and I and others have tons of articles about using r10k. With this in
place, your process would be a little simpler:

  git commit -am 'Something I want to push to test'
  git push origin test_change
  

The webhook fires, r10k starts deploying code, and in a few seconds to
minutes, your test environment has been updated to incorporate those
changes. You'd then use PRs to promote code from test -> dev -> qa -> uat
-> production. This has other impacts to your workflow, of course, and you
may actually be able to remove a level of environments (feature -> qa ->
uat -> production). You could later add some continuous integration tests
to your code, that are automatically run by GitHub/GitLab/Jenkins/etc,
which could lead to removing the qa level as well. But that's down the road
a bit.

There is a lot of room for improvement here as you have time to focus on
your pipeline.



Rob Nelson
rnels...@gmail.com

On Wed, May 18, 2016 at 9:02 PM, dkoleary 
wrote:

> Hey;
>
> To put this in perspective, I'm a sysadmin, not a developer.  While I've
> used git for a couple of years, until today, I could easily count the
> number of times I issued a 'git branch' command.
>
> I'm practicing setting up a new puppet 4 server and, after some research,
> I've got various environments under git management and have successfully
> 'promoted code' from test through production.  It's a wee bit tedious but
> I'm sure I could get used to it.
>
> What I'm hoping is to have someone more familiar the process verify I'm
> doing it somewhat close to right and/or make suggestions on an
> improvements.  I have heard of r10k; however, I'm one of those that has to
> know what's going on under the covers.  Up until now, r10k has been of of
> those 'developer' things.  Once I run through this a few times, *then* I'll
> start playing with r10k.
>
> So, bit of a build up.  Here's what I have:
>
> one git repo covering all puppet environments thusly::
>
> # git branch -r
>   origin/HEAD -> origin/master
>   origin/dev
>   origin/master
>   origin/prod
>   origin/qa
>   origin/test
>   origin/uat
>
> On a different system, one pulls the test system, develops code, commits,
> pushes, etc.  In the test environment, the admin pulls the updated work and
> tests
>
> # pwd
> /etc/puppetlabs/code/environments/test
> # git branch
> * test
>
> once the tests are complete, a responsible admin accesses the dev
> environment and executes:
>
> git checkout test
> git pull # if necessary
> git checkout dev
> git merge test
>
> Process iterates through the environments to prod.
>
> # git log --oneline
> e298de7 prod.rst: mved from uat
> 07f3ab1 uat: merged from qa
> a20a85c qa: mved from dev
> 2f644f2 dev: renamed from test
> c8c067b test: added
> a432124 puppet production environment initial check in
>
> Thanks for any hints/tips/suggestion.
>
> Doug O'Leary
>
> --
> 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/729cd1f2-2828-4d46-b008-2e0033fed34d%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/CAC76iT_LczDuGm1kdJ-bmm11sM2ib%2BNbaHSvqqUOc34jj5C%2BTQ%40mail.gmail.com.
For more 

Re: [Puppet Users] Re: How to control who can add/update permissions in sudoers

[Rob Nelson]

I was coming in here to say the same thing John said. Your sudoers
definition is going to be a combination of code (include sudo; sudo::conf
{'whatever':}) and data (the sudo::conf attributes). That data can be
embedded in your code, or come from a hiera/lookup backend. Both of those
should be in some form of revision control with proper review policies and
permissions. This ensures that only the correct people can submit/merge
changes, and that all merged code is reviewed before it makes it to
production.

I recommend Gary's blog post
http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/
starting with the section "Just put it in the control repo" (lots of other
good articles on the site as well). It describes some of the workflow
impacts of a consolidated repo, and how that might be a positive or
negative toward control of your data. As I read the recommendations, there
are certainly valid reasons to keep some things out of the control repo,
but only if you explicitly need to. It's up to you to determine if you need
to, or if your code review and gating processes are sufficient.


Rob Nelson
rnels...@gmail.com

On Thu, May 19, 2016 at 9:06 AM, jcbollinger 
wrote:

>
>
> On Wednesday, May 18, 2016 at 7:05:48 PM UTC-5, Alex Scoble wrote:
>>
>> Hi all,
>>
>> We're currently on PE 3.8.4.
>>
>> We need to be able to manage sudoers permissions with Puppet, but control
>> things so sudoers permissions can only be granted within a specific module.
>>
>> So permissions could be included via 'include foo::bar' from anywhere,
>> but the actual sudoers permissions used by the include could only be set
>> within the specific module that has access tightly controlled.
>>
>> The goal is to prevent someone from injecting a new sudoers rule in to a
>> module/manifest outside of our control.
>>
>
>
> I don't think there is any reliable way to do what you ask from within
> Puppet.  You may be able to achieve it by completely protecting the sudo
> configuration from Puppet via mandatory access controls (SELinux) or a
> similar mechanism, but then Puppet cannot manage it at all.  Perhaps that's
> ok, but it seems rather pointless: if you do not trust your own manifests,
> then you are in a world of hurt.
>
> There are innumerable things that an assailant wanting to breach your
> security could do with the ability to influence nodes' catalogs, and
> closing down just a single avenue -- if that were even possible -- misses
> the forest for the trees.  Anyone who can inject a single File or Exec
> resource into a node's catalog can very likely take control of that node if
> they so desire.  Therefore, I recommend procedural safeguards: control
> access to all your manifests, perform code reviews for all changes, etc..
>
>
> 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/f6dbf98e-03d8-40f2-92a1-a1807ffc2441%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/CAC76iT_rXohGO9aFGeT7HGVeyS1cquW%2Bg4K6b99rnUT6Gddjmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Logrotate module broken, string 'undef' now treated as undef

[Daniel Urist]

puppetserver: 2.3.2-1puppetlabs1
puppet client: 3.8.5-2~bpo8+1

Both server and clients are running Debian 8 (jessie); the puppet client is
from the Debian backports repo.

On Wed, May 18, 2016 at 3:40 PM, Matthaus Owens  wrote:

> Daniel,
> Which version of Puppet are you seeing this on?
>
> On Wed, May 18, 2016 at 2:33 PM, Daniel Urist  wrote:
>
>> I have been using the yo61 logrotate module from puppetforge (
>> https://forge.puppet.com/yo61/logrotate), which seems to be the most
>> popular, but it recently stopped working, with many errors about undefined
>> parameters.
>>
>> The issue seems to be the use of the string 'undef' as a default value;
>> for example:
>>
>> define logrotate::rule(
>>> $create_owner   = 'undef',
>>>
>>
>> Later on in the code, there are comparisons against the actual string
>> 'undef'; for example:
>>
>>
>>   if ($create_owner != 'undef') and ($create_mode == 'undef') {
>>> fail("Logrotate::Rule[${name}]: create_owner requires create_mode")
>>>}
>>
>>
>> Regardless of whether this is best practice, these comparisons are now
>> failing, apparently because the string 'undef' is now treated as the value
>> undef. I've confirmed this by printing the string with notify (prints
>> nothing when it's 'undef'), and changing it to something else, which does
>> print.
>>
>> I'm not sure exactly when this changed or if it's intended behavior or a
>> bug, but it does seem odd that now apparently 'undef' === undef
>>
>> --
>> 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/CAEo6%3DKYjAx286r9NNvKtGU3PscrAZ77H5_HXc9CXO1LLa552sg%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/CACD%3DwAcwR0OdVsPguNNzzeqZ_LUHMoLhAyhTJP56bAZDc0J6Jw%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/CAEo6%3DKa5FpwNDBXfnEACFUD0_%3Dm2efTJEnCiheN7sNhnxxEEVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to control who can add/update permissions in sudoers

[jcbollinger]

On Wednesday, May 18, 2016 at 7:05:48 PM UTC-5, Alex Scoble wrote:
>
> Hi all,
>
> We're currently on PE 3.8.4.
>
> We need to be able to manage sudoers permissions with Puppet, but control 
> things so sudoers permissions can only be granted within a specific module.
>
> So permissions could be included via 'include foo::bar' from anywhere, but 
> the actual sudoers permissions used by the include could only be set within 
> the specific module that has access tightly controlled.
>
> The goal is to prevent someone from injecting a new sudoers rule in to a 
> module/manifest outside of our control.
>


I don't think there is any reliable way to do what you ask from within 
Puppet.  You may be able to achieve it by completely protecting the sudo 
configuration from Puppet via mandatory access controls (SELinux) or a 
similar mechanism, but then Puppet cannot manage it at all.  Perhaps that's 
ok, but it seems rather pointless: if you do not trust your own manifests, 
then you are in a world of hurt.

There are innumerable things that an assailant wanting to breach your 
security could do with the ability to influence nodes' catalogs, and 
closing down just a single avenue -- if that were even possible -- misses 
the forest for the trees.  Anyone who can inject a single File or Exec 
resource into a node's catalog can very likely take control of that node if 
they so desire.  Therefore, I recommend procedural safeguards: control 
access to all your manifests, perform code reviews for all changes, etc..


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/f6dbf98e-03d8-40f2-92a1-a1807ffc2441%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] How to control who can add/update permissions in sudoers

[Thomas Müller]

Look for assert_private in puppetlabs-stdlib module. Maybe its what you are 
looking for.

Thomas

-- 
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/a7c6f739-8090-471e-a43c-d764fd2cb426%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Message from application: cannot load such file — puppet/util/command_line (LoadError)

[Lowe Schmidt]

First off. As of Puppet 4 is the server part written in Clojure and runs on
the JVM, the parts that are still Ruby are also ran on the JVM with JRuby.

Secondly is the package an all in one package, so no third party or system
ruby should be running.

You should not need Apache or Passenger, just go to the root of the puppet
installation (i believe it is /opt/puppet/ by default) and run
./bin/puppetserver and you should be set.

--
Lowe Schmidt | +46 723 867 157

On 18 May 2016 at 13:39, San  wrote:

> Hi,
>
>
> I have configured puppet with passenger (using -
> https://docs.puppet.com/guides/passenger.html AND
> http://www.olindata.com/blog/2014/09/setup-puppet-master-passenger-and-apache-centos
>  ).
>
>
> [root@a-puppet-03 ~]# puppet --version
>
> 4.4.2
>
> [root@a-puppet-03 ~]# ruby --version
>
> ruby 2.1.8p440 (2015-12-16 revision 53160) [x86_64-linux]
>
> [root@a-puppet-03 ~]# passenger --version
>
> Phusion Passenger 5.0.28
>
> [root@a-puppet-03 ~]# cat /etc/centos-release
>
> CentOS release 6.7 (Final)
>
> [root@a-puppet-03 ~]#
>
>
> Things are fine till the last step, when puppet agent is run, there are
> lots of error. Mainly LoadError.
>
>
> puppet agent -t
>
>
> [ 2016-05-18 04:06:41.8270 19959/7f95efba2700
> age/Cor/Con/CheckoutSession.cpp:285 ]: [Client 1-100] Cannot checkout
> session because a spawning error occurred. The identifier of the error is
> ba45fc42. Please see earlier logs for details about the error.
>
> App 25759 stdout:
>
> App 25759 stdout:
>
> [ 2016-05-18 04:06:42.2164 19959/7f95ee7a0700
> age/Cor/App/Implementation.cpp:304 ]: Could not spawn process for
> application /usr/share/puppet/rack/puppetmasterd: An error occurred while
> starting up the preloader.
>
>   Error ID: d1069d73
>
>   Error details saved to: /tmp/passenger-error-SqIO1Z.html
>
>   *Message from application: cannot load such file --
> puppet/util/command_line (LoadError)*
>
>   /usr/local/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
> `require'
>
>   /usr/local/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in
> `require'
>
>   *config.ru:41:in `block in *'
>
>   /usr/local/lib/ruby/gems/2.1.0/gems/rack-1.6.4/lib/rack/builder.rb:55:in
> `instance_eval'
>
>   /usr/local/lib/ruby/gems/2.1.0/gems/rack-1.6.4/lib/rack/builder.rb:55:in
> `initialize'
>
>   config.ru:1:in `new'
>
>   config.ru:1:in `'
>
>
> /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.28/src/helper-scripts/rack-preloader.rb:110:in
> `eval'
>
>
> /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.28/src/helper-scripts/rack-preloader.rb:110:in
> `preload_app'
>
>
> /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.28/src/helper-scripts/rack-preloader.rb:156:in
> `'
>
>
> /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.28/src/helper-scripts/rack-preloader.rb:30:in
> `'
>
>
> /usr/local/lib/ruby/gems/2.1.0/gems/passenger-5.0.28/src/helper-scripts/rack-preloader.rb:29:in
> `'
>
>
> Please can someone help.. thanks in advance..
>
> --
> 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/4adaf1f5-792e-4af8-acab-e945b19cd427%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/CAC-wWcR%3DqFvJ47q1qa1tzs64zOSH8VQgXVj_4E2NM1XgcQKWFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.