Re: [Puppet Users] Hiera Error 400 on SERVER: Could not find data item classes in any Hiera data file and no default supplied

[Rob Nelson]

Ugo,

In your last example you used 'agen1' instead of 'agent1'. Maybe it's just
a typo? Those are the best problems :) I also don't see where the 400 error
comes from, can you capture that somewhere?

An alternative solution - or maybe complementary - is to change line 11 to
say `hiera_include('classes', [])`, or add a default class that notifies
"Can't find a class!" This way, all runs complete, even if they don't
manage the device properly, which ensures that facts are at least collected.

I also recommend upgrading to the latest 3.x version now, and 4.x as soon
as you can, as SO MANY hiera bugs were fixed in 3.7/3.8 and then 4.3/4.4
that it's very likely that any bug you run into is already fixed by moving
past 3.6.2.


Rob Nelson
rnels...@gmail.com

On Tue, Apr 19, 2016 at 1:36 PM, Ugo Bellavance  wrote:

> Hi,
>
> I'm currently testing hiera and I can't make it work.  I get this
> error: Error 400 on SERVER: Could not find data item classes in any Hiera
> data file and no default supplied at /etc/puppet/manifests/site.pp:11 on
> node. I'm trying to do something like this:
> https://docs.puppet.com/hiera/3.0/complete_example.html (puppetlabs ntp
> module).
>
> Client: puppet 3.6.2
>
> On the master:
>
> puppet 3.6.2
>
> # puppet config print | grep hiera_
> hiera_config = /etc/puppet/hiera.yaml
>
> Contents of /etc/puppet/hiera.yaml
> ---
> :backends:
> #  - regex
>   - yaml
> :yaml:
>   :datadir: /var/lib/hiera
> #:regex:
> #  :datadir: /var/lib/hiera
> :hierarchy:
>   - "host/%{fqdn}"
>   - "domain/%{domain}"
>   - "env/%{::environment}"
>   - "os/%{operatingsystem}"
>   - "osfamily/%{osfamily}"
>   - "virtual/%{::virtual}"
>   - common
>
> Contents of /etc/puppet/manifests/site.pp
>
> import "nodes/*"
> import "os/*"
> import "packages/*"
> import "users/*"
> import "service-types/*"
>
> # Enable hiera
> hiera_include('classes')
>
> #filebitbucket { main: server => puppet }
> #File { backup => main }
>
> # The filebucket option allows for file backups to the server
> filebucket { main: server => 'puppet' }
>
> # Set global defaults - including backing up all files to the main
> filebucket and adds a global path
> File { backup => main }
>
> Contents of the hiera file for this host:
>
> # cat /var/lib/hiera/host/agent1.example.com.yaml
> ---
> classes: ntp
> ntp::restrict:
>   -
> ntp::autoupdate: false
> ntp::enable: true
> ntp::servers:
>   - 0.ca.pool.ntp.org
>   - 1.ca.pool.ntp.org
>   - 2.ca.pool.ntp.org
>   - 3.ca.pool.ntp.org
>
> Contents of the common file:
>
> # cat /var/lib/hiera/common.yaml
> ---
> ntp::autoupdate: true
> ntp::enable: true
> ntp::servers:
>   - ntp1.example
>   - ntp2.example.com
>
>
> When debugging on the master:
>
> # puppet master --debug --compile agent1.example.com | grep hiera | grep
> -v Cannot | grep -v Looking
> Warning: The use of 'import' is deprecated at
> /etc/puppet/manifests/site.pp:4. See
> http://links.puppetlabs.com/puppet-import-deprecation
>(at grammar.ra:610:in `block in _reduce_190')
> Debug: hiera(): Hiera YAML backend starting
> Debug: hiera(): Found classes in host/agent1.example.com
> Debug: hiera(): Found ntp::autoupdate in host/agent1.example.com
> Debug: hiera(): Found ntp::restrict in host/agent1.example.com
> Debug: hiera(): Found ntp::servers in host/agent1.example.com
> Warning: Variable access via 'search_domain' is deprecated. Use
> '@search_domain' instead.
> template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:5
>(at /etc/puppet/modules/resolv/templates/resolv.conf.erb:5:in `block in
> result')
> Warning: Variable access via 'dns_servers' is deprecated. Use
> '@dns_servers' instead.
> template[/etc/puppet/modules/resolv/templates/resolv.conf.erb]:7
>(at /etc/puppet/modules/resolv/templates/resolv.conf.erb:7:in `block in
> result')
>
> (I will eventually fix the warnings, I doubt they cause my hiera problem)
>
> hiera debugging on the master:
>
> # hiera ntp::servers clientcert=agen1.example.com --debug
> DEBUG: 2016-04-19 13:26:43 -0400: Hiera YAML backend starting
> DEBUG: 2016-04-19 13:26:43 -0400: Looking up ntp::servers in YAML backend
> DEBUG: 2016-04-19 13:26:43 -0400: Looking for data source common
> DEBUG: 2016-04-19 13:26:43 -0400: Found ntp::servers in common
> ["ntp1.example.com", "ntp2.example.com"]
>
> (should not find the information in common, 

Re: [Puppet Users] pdxcat-nrpe, hiera data in command

[Rob Nelson]

Can you link directly to the module you're using, on the forge or on github?


-- 

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

Re: [Puppet Users] pdxcat-nrpe, hiera data in command

[Rob Nelson]

You cannot automatically pass parameters to defines with hiera. But, if you
put the nrpe::commands in a profile, you can do APL that way. I.e.

class profile::something (
  $ntpserver,
) {
  nrpe::command {'check_ntp':
package_name  => 'nagios-plugins-ntp',
ensure  => present,
command => "check_ntp -H $ntpserver";
  }
}

In your hiera data, add this at the right tier:

profile::something::ntpserver: 127.0.0.1

You can have specific classes for each check, or a giant nrpe profile that
includes all the commands. Just make all the variables you want to pass to
nrpe::command instances parameters of the class, and hiera can do the heavy
lifting. That should give you the best of both worlds.

Rob Nelson
rnels...@gmail.com

On Thu, Apr 21, 2016 at 3:28 PM, Ugo Bellavance  wrote:

>
>
> On Thursday, April 21, 2016 at 3:25:35 PM UTC-4, Rob Nelson wrote:
>>
>> Can you link directly to the module you're using, on the forge or on
>> github?
>
>
> Sorry... https://github.com/pdxcat/puppet-module-nrpe or
> https://forge.puppet.com/pdxcat/nrpe
>
> --
> 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/5cc2f9ab-4341-4769-9d08-274bab779d42%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/5cc2f9ab-4341-4769-9d08-274bab779d42%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-ZOmnvyz%2BuD%2By7wNES6YcASbajSku2KjS3ZqY8CiBZfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] using multiple EXECs

[Rob Nelson]

Puppet does not know what happens in an Exec resource, so it has one foot
in and one foot outside of the graph and impairs puppet's ability to define
state consistently and enforce idempotency. Because of these, Execs are the
least desirable resource type. Think of them as a "break in case of
emergency" type resource. Only use them if no other resource will work.

Some alternatives might include:
* Repackage the RPMs to include appropriate post-install scripts, so there
is nothing to exec afterward
* Use the correct resource types to achieve the same goal. If the command
would modify some file, use a File resource to manage the file's
permissions, contents, etc. via puppet.
* If you have multiple commands to run and there is absolutely no way to
use other puppet resource types to obtain the same results, then create a
script that is pushed down as a Package or File resource, then Exec that
file. File+Exec is usually better than a bunch of individual Execs, for
both better modeling of state, and your sanity (esp when dealing with
escaped strings, any sort of logic between Execs, and to have a logical
view of what the Execs are doing).

Again, Execs should generally be your last resort. Find another way when
possible!


Rob Nelson
rnels...@gmail.com

On Fri, Apr 22, 2016 at 1:24 AM,  wrote:

> Hi all,
>
>  I am building this module which has rpm packages in it and execs commands.
> What is the best way to build this module.. does writing numerous execs is
> a good way to start with??
>
> Im finding my way to work with puppet ... any help is greatly
> appreciated!! :)
>
> Thank You
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/8d95be4c-d2bb-44c0-913e-5dc96cf0f033%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/8d95be4c-d2bb-44c0-913e-5dc96cf0f033%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9kvybZ036cbKe%2BXwYTPPf_CwZmg25X46qPFp-US_g8OQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] python on puppet

[Rob Nelson]

Bapi,

Searching the forge (https://forge.puppet.com) is my first stop. A search
on python or pip turn up a number of hits. There's an approved puppet
module that looks like it might be helpful:
https://forge.puppet.com/stankevich/python. Approved modules must meet some
standards so are generally more interesting than non-approved modules, but
you should always review modules to find which is the best fit for you now
and in the future.


Rob Nelson
rnels...@gmail.com

On Fri, Apr 22, 2016 at 2:04 PM,  wrote:

> Hi all,
>
> I am trying to manage python packages from puppet.I wanted to run the
> following commands *without using EXEC..*
>
> *After installing python-setuptools i tried to install pika using pip as
> provider .. but it did not work.*
>
> *What is the best way to puppetize this??*
>
> *Thank You*
> *Bapi*
>
>
>
>
>
>
>
> *sudo yum install python-setuptoolssudo easy-install pipsudo easy-install
> argparsesudo /usr/bin/pip install pika*
>
> --
> 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/ed850c4b-628e-4a66-bd83-bb3dbd93d68c%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/ed850c4b-628e-4a66-bd83-bb3dbd93d68c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT8KaMSw9ABBdx9StXtv_X%2BGRD8Z%3DLNBbfjmB5AK5Uhy%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] manage passwords on several systems

[Rob Nelson]

Filip, is there a reason you're managing the shadow file directly instead
of feeding the right strings into the user resource's password parameter?
https://docs.puppet.com/puppet/latest/reference/type.html#user-attribute-password.
That may obviate some of your issues.

Otherwise, can you show the code you're using?


Rob Nelson
rnels...@gmail.com

On Mon, Apr 25, 2016 at 2:36 PM, filip hosten 
wrote:

> Hi,
>
> I'm writing a manifest to distribute the puppet master's shadow passwords
> for selected users to the clients.
>
> If a user want to change the password (as it is 1month valid) on the
> puppet master, it should be distributed to the nodes with the next run.
>
>
> I'm using "generate" in combination with sudo to read out the /etc/shadow
> and store it in a puppet variable.
>
> But I get the error message that only alphanumeric, fileseparators and
> dashes are allowed in the result of the generate function.
>
> I gues the dollar sign, and other characters in the shadow hashes are the
> cause here.
>
> Any other method to read out the shadow hash and store it in a variable so
> that I can use it in setting the password for a user?
>
>
> thanks in advance.
>
> Filip Hosten.
>
> --
> 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/26234be5-4d8d-4caa-8c2f-9bab49bff006%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/26234be5-4d8d-4caa-8c2f-9bab49bff006%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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_DMUuAyfnPPf9htpxPq_XsQuDH5Q3zTRSGUN9z7kSUPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Setting var to undef does not override class or define defaults

[Rob Nelson]

Passing undef to a parameter doesn't unset it. It's the same as not passing
it. I do not believe there is a standard way to unset a parameter with a
default value. You can set it to '', 0, false, or another appropriate
"unset" value depending on how it is to be used, though.


Rob Nelson
rnels...@gmail.com

On Sat, Apr 23, 2016 at 3:46 PM, Erik Anderson  wrote:

> On Puppet 4.4.1
>
> I ran the following:
>
> class testingclass(
>   $cmd_path = 'PluginDir',
> ){
>   $message_ntfy = "cmd_path is set to: ${cmd_path} for ${name}"
>   notify { $message_ntfy: }
> }
>
>
> define testingdefine(
>   $cmd_path = 'PluginDir',
> ){
>   $message_ntfy = "cmd_path is set to: ${cmd_path} for ${name}"
>   notify { $message_ntfy: }
> }
>
>
> node default {
>
>
>   class {'testingclass':
> cmd_path => undef,
>   }
>
>
>  testingdefine { 'testingdefinedefaults': }
>  testingdefine { 'testingdefineundef':
>   cmd_path => undef,
>  }
> }
>
> I expect cmd_path to be set to undef for the class and testingdefineundef.
> Instead it looks like all three end up with the same value for cmd_path:
>
> erik.anderson@puppetmaster1:~$ sudo puppet apply test.pp
> Warning: Config file /etc/puppetlabs/code/hiera.yaml not found, using
> Hiera defaults
> Notice: Compiled catalog for sa-sand-puppetmaster1.sa.moneydesktop.com in
> environment production in 0.15 seconds
> Notice: cmd_path is set to: PluginDir for testingclass
> Notice: /Stage[main]/Testingclass/Notify[cmd_path is set to: PluginDir for
> testingclass]/message: defined 'message' as 'cmd_path is set to:
> PluginDir for testingclass'
> Notice: cmd_path is set to: PluginDir for testingdefinedefaults
> Notice: /Stage[main]/Main/Node[default]/Testingdefine[
> testingdefinedefaults]/Notify[cmd_path is set to: PluginDir for
> testingdefinedefaults]/message: defined 'message' as 'cmd_path is set to:
> PluginDir for testingdefinedefaults'
> Notice: cmd_path is set to: PluginDir for testingdefineundef
> Notice: /Stage[main]/Main/Node[default]/Testingdefine[testingdefineundef]/
> Notify[cmd_path is set to: PluginDir for testingdefineundef]/message:
> defined 'message' as 'cmd_path is set to: PluginDir for
> testingdefineundef'
> Notice: Applied catalog in 0.35 seconds
>
> Any ideas on why it is behaving this way and is it intentional?
>
> --
> 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/26d1f9c0-61b6-47d3-a7fc-350fee0f2035%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/26d1f9c0-61b6-47d3-a7fc-350fee0f2035%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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_dPzxLR_0AQ2veD9G3gy%3DxR4Ty9%2B_x4yMhZRTQ9tVqwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Way to pass "arguments" into a subclass?

[Rob Nelson]

This sounds like a great use case for an additional parameter on
ucdpuppet::kerberos::config, to allow a user to pass in a source location,
with a sane default, or to use an ERB template in conjunction with at least
one parameter to define the contents. The parameters could be defined in
hiera, so there's no special if case in your code, just various data fed in
based on your hierarchy.

On Thursday, April 28, 2016, Omen Wild  wrote:

> I am looking for a way to pass "arguments" through multiple includes into
> a subclass. Situation is like this:
>
> - Begin code -
> node 'a-file-server.ucdavis.edu' {
>   include physicsnode
> }
>
> class physicsnode {
>   include baseclass
>
>   include ucdpuppet::kerberos
> }
>
> class ucdpuppet::kerberos {
>   ...
>   include ucdpuppet::kerberos::config
>   ...
> }
>
> class ucdpuppet::kerberos::params inherits ucdpuppet::params {
>   case $::osfamily {
> 'Debian', 'RedHat' : {
>   $krb5_conf_path = '/etc/krb5.conf'
>   $krb5_keytab_path = '/etc/krb5.keytab'
> }
>   }
>   ...
> }
>
> class ucdpuppet::kerberos::config inherits ucdpuppet::kerberos::params {
>   file {$ucdpuppet::kerberos::params::krb5_conf_path :
>source => 'puppet:///modules/ucdpuppet/kerberos/krb5.conf'
>   }
> }
> - End code -
>
> The problem is that a-file-server.ucdavis.edu is a special snowflake
> and requires a different krb5.conf file. I could build that knowledge
> into ucdpuppet::kerberos::params based on the fqdn, but burying the
> info like that really bugs me. I would like some way to define that in
> the node definition and be able to pull that out in
> ucdpuppet::kerberos::config.
>
> Thanks,
>Omen
>
> --
> Omen Wild
> Systems Administrator
> Metro Cluster
>
> --
> 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/20160428200333.GA7428%40descolada.ucdavis.edu
> .
> 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/CAC76iT8CzHxu8u_FPmKaQAS2kts_BVAZgVTet-He4V0%2B6O2oaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PE missing referents for production modules

[Rob Nelson]

Doesthe module show up with 'puppet module list'? You may need to add
'--environment=production' and/or
'--modulepath=/etc/puppetlabs/code/environments/production/modules'.


Rob Nelson
rnels...@gmail.com

On Mon, May 2, 2016 at 4:54 PM, Matthew Pounsett <
matthew.pouns...@rightside.co> wrote:

>
> I'm setting up a test deployment of the latest PE.  I haven't run PE for a
> couple of years, and it looks like a few (perhaps a lot of) things have
> changed.
>
> I have a completely fresh install of
> puppet-enterprise-2016.1.1-el-7-x86_64 on Centos 7.  I've added a module as
> /etc/puppetlabs/code/environments/production/modules/vim, and run a restart
> of the PE service (systemctl reload-or-restart pe-puppetserver.service).
>
> However, when I try to add my new 'vim' class to the All Nodes group and
> Commit the change, I'm getting a (rather large) missing-referents error.
>
> I've double-checked that the module file declares the class properly, and
> that the perms should allow the server process to read the modules.  The
> docs  don't seem to mention any other steps I need to follow.  Clearly I'm
> missing something newly added to the process though.  Anyone have any
> 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/6959bfcd-ff48-47bb-aa37-c2a7d38d8f8b%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/6959bfcd-ff48-47bb-aa37-c2a7d38d8f8b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9FTOJ%2BFyGMOrOSFDrs97QD9oSZpV2ujh5vcefkQHuMKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Upgrading Puppet from 2.7 to 4

[Rob Nelson]

I have not done this, but I suspect a stairstep upgrade of 2.7 -> 3.0 ->
3.8 w/future parser -> 4.latest would be the easiest. You *might* be able
to skip to 3.8, technically, but I suspect your code would blow up in
strange ways that would be less obvious than the additional step.

Puppetconf 2015 talks that may be of specific interest to upgrades:
https://www.youtube.com/watch?v=LahcjL8UY-0&list=PLV86BgbREluUDlJW_jAqnWPj0THx7eXBA&index=12
https://www.youtube.com/watch?v=biqYDOJNTB4&index=14&list=PLV86BgbREluUDlJW_jAqnWPj0THx7eXBA
https://www.youtube.com/watch?v=D7rbUlNWOg4&list=PLV86BgbREluUDlJW_jAqnWPj0THx7eXBA&index=23

There are a ton of other talks about Puppet 4 in the playlist, though maybe
not dealing specifically with upgrades.

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

Re: [Puppet Users] Puppet fails to convert plist hash to binary after password changed on OS X agent

[Rob Nelson]

pted, 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.
>
> Brehm Preparatory School, Inc. | 950 S. Brehm Lane, Carbondale, IL 62901 |
> Phone: (618) 457-0371 | www.brehm.org
>
> --
> 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/218738bd-19af-41e1-9b1c-276d156d8625%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/218738bd-19af-41e1-9b1c-276d156d8625%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT_c32Gu6rh5n1opPHg-%2B24WD10rzFPb2J4KqNMghbDbtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] fixtures from Puppetfile in puppetlabs_spec_helper

[Rob Nelson]

That's unfortunately a complex task, though it doesn't look it immediately.
How are you defining things in your Puppetfile? Are you pulling from git's
master, a git tag or branch, or from the forge? Do you want your fixtures
to be using HEAD or the specific version in your Puppetfile? If the latter,
how can it correlate between forge versions and git branch/tags? I think
that complexity has held up anyone from writing a full featured rake task
to keep fixtures up to date, at least anything that I've seen advertised
publicly.

There are some tools to update the Puppetfile, though -
https://github.com/puppetlabs/r10k/blob/master/doc/updating-your-puppetfile.mkd.
I wrote the last one, generate-puppetfile, which can create a very naive
.fixtures.yml for you, assuming you want to test against HEAD. If you want
to do specific versions, you'll have to do something else. PRs accepted :)


Rob Nelson
rnels...@gmail.com

On Thu, May 12, 2016 at 7:39 AM, Rudy Gevaert 
wrote:

> Hi,
>
> Does anyone know a way to integrate rspec-puppet and more
> specific puppetlabs_spec_helper to get its fixtures from a Puppetfile?
>
> It's a PITA to each time update the fixtures file if you update your
> Puppetfile in your control repo. (Our context is that roles and profiles
> are located in our puppet control repo and we want to check against the
> versions of the modules defined in the Puppetfile)
>
> By default we don't run deploy modules with r10k on our local machine.
>
> 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/b8b49a24-e238-49e1-8571-0995ebf921c9%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/b8b49a24-e238-49e1-8571-0995ebf921c9%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9CfhAAxjai2%3Dz71Es7XdG-n2TO6daApwW%2B-SvMozJEuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet enterprise code manager issue

[Rob Nelson]

A hack might be to have a proxy in the network. I'm sure you could use
squid to transparent proxy for the master only and let everything else go
direct, or redirect port 80 from the master to a proxy semi-transparently
(no agent config but requires some packet inspection and retorting of
traffic).

On Thursday, May 12, 2016, Alex Dreyer  wrote:

> On Thursday, May 12, 2016 at 11:01:49 AM UTC-7, Robert Chen wrote:
>>
>> my environment needs http_proxy, https_proxy for modules. probably code
>> manager issue is an proxy issue
>>
>>
>> #  puppet-code deploy  lab -l debug --wait
>>
>> 2016-05-12 13:39:48.388674 DEBUG puppetlabs.puppet-code - Loaded global
>> configuration from /etc/puppetlabs/client-tools/puppet-code.conf
>>
>> 2016-05-12 13:39:48.39 DEBUG puppetlabs.puppet-code - Loaded user
>> configuration from /root/.puppetlabs/client-tools/puppet-code.conf
>>
>> Deploying environment: lab
>>
>> 2016-05-12 13:39:48.388961 INFO  puppetlabs.puppet-access - Finding token
>> at path /root/.puppetlabs/token
>>
>> 2016-05-12 13:39:48.390796 DEBUG puppetlabs.puppet-code - puppet-code
>> version is 0.1.0 (commit 9caf577c432f50830341215aab29dc490909981e)
>>
>> 2016-05-12 13:39:48.390879 DEBUG leatherman.curl:223 - requesting
>> https://aaa.bbb:8170/code-manager/v1/deploys
>> <https://lvappi00356.bns:8170/code-manager/v1/deploys>.
>>
>> 2016-05-12 13:39:48.395317 DEBUG leatherman.curl:463 - Trying
>> 10.254.12.72...
>>
>> 2016-05-12 13:39:48.398554 DEBUG leatherman.curl:463 - Connected to
>> gateway.bbb(10.254.12.72) port 8000 (#0)
>>
>> 2016-05-12 13:39:48.398610 DEBUG leatherman.curl:463 - Establish HTTP
>> proxy tunnel to lvappi00356.bbb:8170
>>
>> 2016-05-12 13:39:48.415798 DEBUG leatherman.curl:463 - Received HTTP code
>> 504 from proxy after CONNECT
>>
>> 2016-05-12 13:39:48.415885 DEBUG leatherman.curl:463 - Closing connection
>> 0
>>
>> Unhandled exception: Failure when receiving data from the peer
>>
>>
>>
>>
>>
>> I saw something under code-staging but no modules there:
>>
>> [root@lvappi00356 lab]# pwd
>>
>> /etc/puppetlabs/code-staging/environments/lab
>>
>> [root@lvappi00356 lab]# ls -l
>>
>> total 12
>>
>> drwxr-xr-x. 2 pe-puppet pe-puppet   37 May 12 12:01 manifests
>>
>> -rw-r--r--. 1 pe-puppet pe-puppet  218 May 12 12:01 metadata.json
>>
>> -rw-r--r--. 1 pe-puppet pe-puppet 1172 May 12 13:23 Puppetfile
>>
>> -rw-r--r--. 1 pe-puppet pe-puppet 1589 May 12 12:01 README.md
>>
>> drwxr-xr-x. 2 pe-puppet pe-puppet   20 May 12 12:01 tests
>>
>>
>>
>>
>>
>> I can git clone the modules:
>>
>>
>>
>> [root@lvappi00356 /]# git clone
>> https://github.com/puppetlabs/puppetlabs-dsc.git
>>
>> Cloning into 'puppetlabs-dsc'...
>>
>> remote: Counting objects: 13452, done.
>>
>> remote: Compressing objects: 100% (13/13), done.
>>
>> remote: Total 13452 (delta 1), reused 0 (delta 0), pack-reused 13438
>>
>> Receiving objects: 100% (13452/13452), 11.53 MiB | 3.84 MiB/s, done.
>>
>> Resolving deltas: 100% (8767/8767), done.
>>
>
> The puppet code command connects to code-manager in puppet-server over
> https. It looks like your proxy is getting in the way of that. Can you
> disable the proxy configuration in the shell you're running puppet code
> from? You may get better messages that way. You can also try tailing
>  '/var/log/puppetlabs/puppetserver/puppetserver.log' while you're deploying.
>
> Unfortunately, http proxies for git repos won't be supported until the
> next release of Puppet Enterprise. You could try mirroring modules
> internally or installing them from puppet forge which code-manager can use
> proxies to connect to in all releases. Otherwise you'll have to wait for
> the next Puppet Enterprise release to use code-manager.
>
> --
> 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/54b7c064-9dc5-49e0-8a55-6c2f191667dc%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/54b7c064-9dc5-49e0-8a55-6c2f191667dc%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-20YX0PUP_7rF4w03PicRbh0kR2-c3W9ZwzafExf_nkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Test coverage behaviour changed between 3.x/4.x

[Rob Nelson]

I don't believe so. I filed a similar report on how custom facts are
treated, #356. Sounds like similar behavior, maybe a similar cause?


Rob Nelson
rnels...@gmail.com

On Fri, May 13, 2016 at 9:40 AM, Matt Dainty 
wrote:

> I have an open bug report with the rspec-puppet project
> (https://github.com/rodjek/rspec-puppet/issues/316) whereby the coverage
> from
> testing custom functions in my modules are not cumulative but only include
> coverage from the last expectation which results in reports showing low
> percentages.
>
> Anyway, I've now noticed that if I use Puppet 4.x (4.4.2 in this case) to
> run
> the test suite then I get zero code coverage which I've tracked down to the
> fact that the custom functions are shown in the report to be located in
> `spec/fixtures/modules//lib/puppet/parser/functions/...` and the
> whole of `spec/` is normally filtered out of the coverage report to prevent
> the tests themselves and any Ruby code in dependent modules from
> contributing.
>
> If I go back to Puppet 3.x (3.8.7) then the custom functions are shown to
> be
> located in `lib/puppet/parser/functions/...` again as expected.
>
> I have a small test module that I used to demonstrate the original bug
> available here:
>
> https://github.com/bodgit/puppet-test
>
> Is this change in behaviour expected?
>
> Matt
>
> --
> 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/20160513134022.GC13102%40simulant.bodgit-n-scarper.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/CAC76iT8Hyg_PTzNq14EEx4u88qd6niJWhto9gAwrPq3UyygPfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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
> <https://groups.google.com/d/msgid/puppet-users/f6dbf98e-03d8-40f2-92a1-a1807ffc2441%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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] 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
> <https://groups.google.com/d/msgid/puppet-users/729cd1f2-2828-4d46-b008-2e0033fed34d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this 

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:
> &

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
> <https://groups.google.com/d/msgid/puppet-users/5198fce0-fb84-42fe-bc8e-b6c2b48141d3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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] Is there a way to publish a module via the Forge API?

[Rob Nelson]

I love blacksmith, it's great. It does require the forge password be known 
to the person running it, however.

You can "level up" your deployments to allow others with write access to 
your repo, but not the forge credentials, in a mature pipeline with Travis 
CI's automated deployments . 
Details on puppetforge deploys 
, and an example of a 
working .travis.yml 
 
(the secure string is generated by travis encrypt 
). This allows any 
contributor to create a tag (usually with the voxpupuli-release gem 
 and `rake 
travis_release`, but also by creating a tag on GitHub). Travis kicks off a 
build on the tag, and if the test specified in the deploy section goes 
green, your module is published to the forge. That might be overkill for a 
module maintained by one person, but it is pretty neat when you have a 
distributed team and can't/don't want to share the forge password with 
everyone.

I'm sure you could get the same thing working with other services than 
GitHub/Travis CI, those are just the pair I know.

On Friday, May 20, 2016 at 3:48:16 AM UTC-4, garethr wrote:
>
> Hi Amos 
>
> On 20 May 2016 at 05:51, Amos Shapira > 
> wrote: 
> > 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. 
> > 
>
> It is indeed possible. Better that possible, there is even have a 
> handy tool that provides a nice user interface for doing so. 
>
> https://github.com/voxpupuli/puppet-blacksmith 
>
> Blacksmith provides a number of useful commands for determining how 
> you want to go about releasing your modules. The simplest is to just 
> run: 
>
> rake module:release 
>
> The README has lots more details. 
>
> Gareth 
>
>
> > 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...@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. 
>
>
>
> -- 
> Gareth Rushgrove 
> @garethr 
>
> devopsweekly.com 
> morethanseven.net 
> garethrushgrove.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/1919e254-d7f5-4f50-a5b0-32b8c9df1259%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet server 4: hiera set up?

[Rob Nelson]

Doug,

You could add --trace to see where it's looking. I would also try tossing
something into common, which requires NO facts, to ensure base hiera
functionality before moving on to tiers dependent upon fact values.


Rob Nelson
rnels...@gmail.com

On Fri, May 20, 2016 at 3:11 PM, dkoleary 
wrote:

> Hey;
>
> Before dumping a bunch of data into hiera data files, I wanted to run a
> quick check to verify functionality.  This seems to be set up so I'm
> suspecting my test isn't valid.  Could someone take a peek and confirm for
> me?
>
> This is the set up:
>
> # h
> pm
>
> # puppet config print hiera_config
> /etc/puppetlabs/puppet/hiera.yaml
>
> # cat /etc/puppetlabs/puppet/hiera.yaml
> ---
> :backends:
>   - yaml
> :hierarchy:
>   - "hosts/%{facts.hostname}"
>   - "environments/%{facts.environment}"
>   - "host_env/%{facts.env}"
>   - "os/%{facts.osfamily}"
>   - common
> :yaml:
>   :datadir: /etc/puppetlabs/code/hieradata
>
> # facter hostname
> pm
>
> # cat /etc/puppetlabs/code/hieradata/hosts/pm
> ---
> puppet::status: 'running'
>
> but the tests aren't showing anything:
>
> # hiera puppet::status
> nil
> # puppet lookup puppet::status
>
> The hiera call makes sense because it doesn't have access to host fact, as
> I understand it.  The puppet lookup command should have worked, though,
> right?
>
> Any hints/tips/suggestions greatly appreciated.
>
> 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/d7754606-219a-49f3-9065-4f3bd52855b3%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/d7754606-219a-49f3-9065-4f3bd52855b3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9ezn_sqn65Kkb%2BR6DueVEu5Sj8KtAfdMWCHZH-TXcq7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet and SVN

[Rob Nelson]

If you have a choice, you should almost always look at git over svn (IMO).

On Sunday, May 22, 2016, Alex Samad  wrote:

> Ta
>
> I was at the last puppet (sydney ) users group. heard r10k mentioned a lot.
>
> Also I got the impression that git was more closely integrated with puppet.
>
> Should I be l looking at git ?
>
> A
>
>
> On 23 May 2016 at 10:40, Henrik Lindberg  > wrote:
> > On 22/05/16 12:41, Alex Samad wrote:
> >>
> >> Hi
> >>
> >> just starting out with puppet.
> >> I found
> >> this
> http://projects.puppetlabs.com/projects/1/wiki/Puppet_Version_Control
> >> old page
> >>
> >> talks about checking /etc/puppet into svn.
> >>
> >> But on my centos install I have /etc/puppetlabs/puppet
> >>
> >> do I add /etc/puppetlabs or /etc/puppetlabs/puppet to svn and if the
> >> later what about my codedir ?
> >>
> >
> > You probably want to use the project r10k to manage your
> > manifests/configurations that are stored in a source code control
> > repository.
> >
> > Here is the page that explains a bit about r10k and SVN:
> >
> https://github.com/puppetlabs/r10k/blob/master/doc/dynamic-environments/svn-environments.mkd
> >
> > There is also lots of material available on r10k itsef that is easy to
> find
> > if you google for it.
> >
> > Regards
> > - henrik
> >
> >> 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 
> >> <mailto:puppet-users+unsubscr...@googlegroups.com >.
> >> To view this discussion on the web visit
> >>
> >>
> https://groups.google.com/d/msgid/puppet-users/ee63fdad-2d0f-4914-b9ca-0dbdb5044dc3%40googlegroups.com
> >>
> >> <
> https://groups.google.com/d/msgid/puppet-users/ee63fdad-2d0f-4914-b9ca-0dbdb5044dc3%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> >
> > Visit my Blog "Puppet on the Edge"
> > http://puppet-on-the-edge.blogspot.se/
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/puppet-users/Q0ke0NzMRjY/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/ac7d5df1-1798-e7d2-0215-b05166dc7b71%40puppet.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/CAJ%2BQ1PVrqBsaznadB9z9wTAS6s%3DdEHMZZpwNAqtCtYES7OMCyg%40mail.gmail.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/CAC76iT8S7298UeaEJgOzR%2B7ABcs8Cy-GvvgN%2Bh%3D4xYuDgSd%2BZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet and SVN

[Rob Nelson]

 stored in a source code control
> >> >> repository.
> >> >>
> >> >> Here is the page that explains a bit about r10k and SVN:
> >> >>
> https://github.com/puppetlabs/r10k/blob/master/doc/dynamic-environment
> >> >> s/svn-environments.mkd
> >> >>
> >> >> There is also lots of material available on r10k itsef that is easy
> to
> >> >> find if you google for it.
> >> >>
> >> >> Regards
> >> >> - henrik
> >> >>
> >> >>> 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
> 
> >> >>> <mailto:puppet-users+unsubscr...@googlegroups.com >.
> >> >>> To view this discussion on the web visit
> >> >>>
> >> >>>
> https://groups.google.com/d/msgid/puppet-users/ee63fdad-2d0f-4914-b9c
> >> >>> a-0dbdb5044dc3%40googlegroups.com
> >> >>>
> >> >>> <
> https://groups.google.com/d/msgid/puppet-users/ee63fdad-2d0f-4914-b9ca-0dbdb5044dc3%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
> >> >>> For more options, visit https://groups.google.com/d/optout.
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Visit my Blog "Puppet on the Edge"
> >> >> http://puppet-on-the-edge.blogspot.se/
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to a topic in
> the
> >> >> Google Groups "Puppet Users" group.
> >> >> To unsubscribe from this topic, visit
> >> >>
> https://groups.google.com/d/topic/puppet-users/Q0ke0NzMRjY/unsubscribe.
> >> >> To unsubscribe from this group and all its topics, 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/ac7d5df1-1798-e7d2-0215-b05166dc7b71%40puppet.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/CAJ%2BQ1PVrqBsaznadB9z9wTAS6s%3DdEHMZZpwNAqtCtYES7OMCyg%40mail.gmail.com
> .
> >> > For more options, visit https://groups.google.com/d/optout.
> >> >
> >> > --
> >> > You received this message because you are subscribed to a topic in
> the Google Groups "Puppet Users" group.
> >> > To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/Q0ke0NzMRjY/unsubscribe.
> >> > To unsubscribe from this group and all its topics, 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/00ed01d1b48c%24c1c09560%244541c020%24%40gmail.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/CAJ%2BQ1PV7FEU9tahp-5hSRqRLH4FXSD4o%3DkhejmjJ%3DoKr9%3DU_1g%40mail.gmail.com
> .
> >> For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/Q0ke0NzMRjY/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/20160523211657.GA6621%40iniquitous.heresiarch.ca
> .
> > 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/CAJ%2BQ1PV3%2BTWUZMTvJFE_wBPM9m6eJsdLqSZKj0ZxxMFmqZgNWQ%40mail.gmail.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/CAC76iT-TgCx0KbgavCwjXO8Z-J6xpsCBVn5ntueWRUw3wjpWrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] What is the meaning of all these different version commands

[Rob Nelson]

`puppet --version` and `puppet agent --version` are effectively the same
and are testing the version of the puppet executable. This comes from a
puppet or puppet-agent package, depending on where you're getting it from.
The `puppetserver --version` is testing the puppetserver executable, which
is a Clojure JVM that runs the puppetmaster service. This is typically
provided by the package puppetserver.

When it is time to upgrade, you would likely upgrade both puppetserver and
puppet/puppet-agent. In rpm parlance I would run `rpm -qa | grep puppet` to
see what puppet-related packages are present, and then upgrade those. If
you can do something similar with apt, you can determine what the package
names are and then upgrade them.

For more details on upgrades, you can review
https://docs.puppet.com/puppet/4.5/reference/architecture.html. Always read
the release notes and upgrade directions all the way through before
beginning, as there are sometimes warnings and gotchas you need to be aware
of.


Rob Nelson
rnels...@gmail.com

On Mon, May 23, 2016 at 9:10 PM, Jim  wrote:

> root@jim-Ubuntu1504:/etc/puppetlabs/code/environments# puppet --version
> 4.4.1
> root@jim-Ubuntu1504:/etc/puppetlabs/code/environments# puppetserver
> --version
> puppetserver version: 2.3.1
> root@jim-Ubuntu1504:/etc/puppetlabs/code/environments# puppet agent
> --version
> 4.4.1
>
> Also If I want to upgrade my Ubuntu from 15.10 to 16.04 would the puppet
> server and agent would also get upgraded?
>
> Please advise.
>
>
> Thanks
> Jim
>
> --
> 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/a2fa46b5-ae79-4095-8662-efd1fea2c7b0%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/a2fa46b5-ae79-4095-8662-efd1fea2c7b0%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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_M0K4auQYUMZVAjO1c8ZaxLOvTvAikNwB570P0pEJOUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet and SVN

[Rob Nelson]

Yep! I do that with some profiles:
Base
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/base.pp
calls
linuxfw and its pre/post subclasses
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/linuxfw.pp

https://github.com/puppetinabox/controlrepo/tree/production/dist/profile/manifests/linuxfw
to
set up the genera rules all bodes have.
Component profiles like Apache allows port 80
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/apache.pp

The names of the firewall rule resources are sorted numerically, so you can
have multiple 100 rules in different profiles and it won't cause a problem
unless one of them is a deny, in which case you probably want to start the
name with 99 - or have unique rules across profiles, though that doesn't
scale very well.

On Wednesday, May 25, 2016, Alex Samad  wrote:

> Hi
>
> Thanks for all the input.
>
> What I have gathered
>
> Start with GIT from the beginning. Okay I can do that
>
> /etc/*puppetwhatever*/environments/{production|stage|etc}/ is good
>
> Look at using / implementing r10k
>
>
> Profiles / roles good.
>
> No need to reinvent modules - wasn't actually planning on that.
>
> From the puppet user group meeting I got that it is good to (example ntp)
>
> 1) reuse forge ntp module
> 2) wrap it up with $job defaults
> 3) use the new ntp profile
>
>
> Something i was looking at doing was managing the server firewall.
>
> I was going to produce some sort of a template with places in it where
> I can add dynamic content - depending on what apps where installed on
> the server.
>
>
> Example
> profile - ABC Firewall
> this would be basic
>
> allow related,connected
> allow ssh
> 
> reject anything not from company ip address
> 
> drop broadcast
> drop multicast
> allow zabbix monitoring
> log  with limit
> reject with limit
> drop
>
>
> so if I applied this profile to server A it would get the basic firewall.
>
> The next step is if I had profile "app A"
> if it had something like
> rules to add to from anywhere
> allow inbound port 80
> allow inbound port 443
>
> rules to add to only from local network
> allow inbound port 8080
>
>
> I would hope to get puppet to update the basic firewall with info from
> app A and other profiles.
>
>
> Is this possible ?
>
> A
>
> On 24 May 2016 at 11:22, Rob Nelson >
> wrote:
> > I wrote some articles on using Git with puppet and r10k. It's a little
> out
> > of date in the referenced versions of puppet and r10k, so check to make
> sure
> > you're using the modern file locations, but otherwise remains accurate.
> >
> https://rnelson0.com/2014/05/19/puppet-and-git-201-r10k-setup-installation/
> >
> > There's a link to a Git 100 series I wrote if you need assistance with
> Git
> > itself.
> >
> >
> > On Monday, May 23, 2016, Alex Samad >
> wrote:
> >>
> >> Hi
> >>
> >> Is it really that painful to retro fit git. or is the way you think
> >> about the DB that different ?
> >>
> >> Could you point a good starting point to read up on this ?
> >>
> >> Thanks
> >> Alex
> >>
> >> On 24 May 2016 at 07:16, Christopher Wood  >
> >> wrote:
> >> > On Mon, May 23, 2016 at 03:51:58PM +1000, Alex Samad wrote:
> >> >> How hard is it to retro fit SVN / GIT onto a puppet install.
> >> >>
> >> >> I am building from scratch, working through the doco.
> >> >>
> >> >> Was thinking once I have a friendly setup then I would look at
> putting
> >> >> that into SVN/GIT.
> >> >
> >> > Do yourself a huge favour, use git as the tool you use to construct
> the
> >> > setup. Use it from the start of the process, not just as what you put
> things
> >> > into when you're done.
> >> >
> >> >> Thoughts are
> >> >> install puppet
> >> >> install puppetDB
> >> >> install heira ??
> >> >>
> >> >> setup environments, currently thinking
> >> >> Prod - all prod env
> >> >> SIM - testing for prod
> >> >> INF - inf
> >> >> NON Prod - anything thats not above
> >> >> dev - testing
> >> >> alex - personal
> >> >>
> >> >> Then I was going to create a whole bundle of profiles break up into
> >> >>
> >> >> OS app
> >> >>

Re: [Puppet Users] Puppet and SVN

[Rob Nelson]

Yes, you can see the modules used in the Puppetfile.

That's a learning tool / reference architecture, suitable for a quick lab
setup. My personal and work setups are not public, though.

On Wednesday, May 25, 2016, Alex Samad  wrote:

> Hi
>
> Cool, so I presume the module firewall is from the forge
> https://github.com/puppetlabs/puppetlabs-firewall this one ?
>
> I notice you have your modules / code on github aren't you concerned
> about having it in a public place ?
>
> A
>
> On 26 May 2016 at 11:01, Rob Nelson >
> wrote:
> > Yep! I do that with some profiles:
> > Base
> >
> https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/base.pp
> > calls linuxfw and its pre/post subclasses
> >
> https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/linuxfw.pp
> >
> https://github.com/puppetinabox/controlrepo/tree/production/dist/profile/manifests/linuxfw
> > to set up the genera rules all bodes have.
> > Component profiles like Apache allows port 80
> >
> https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/apache.pp
> >
> > The names of the firewall rule resources are sorted numerically, so you
> can
> > have multiple 100 rules in different profiles and it won't cause a
> problem
> > unless one of them is a deny, in which case you probably want to start
> the
> > name with 99 - or have unique rules across profiles, though that doesn't
> > scale very well.
> >
> >
> > On Wednesday, May 25, 2016, Alex Samad >
> wrote:
> >>
> >> Hi
> >>
> >> Thanks for all the input.
> >>
> >> What I have gathered
> >>
> >> Start with GIT from the beginning. Okay I can do that
> >>
> >> /etc/*puppetwhatever*/environments/{production|stage|etc}/ is good
> >>
> >> Look at using / implementing r10k
> >>
> >>
> >> Profiles / roles good.
> >>
> >> No need to reinvent modules - wasn't actually planning on that.
> >>
> >> From the puppet user group meeting I got that it is good to (example
> ntp)
> >>
> >> 1) reuse forge ntp module
> >> 2) wrap it up with $job defaults
> >> 3) use the new ntp profile
> >>
> >>
> >> Something i was looking at doing was managing the server firewall.
> >>
> >> I was going to produce some sort of a template with places in it where
> >> I can add dynamic content - depending on what apps where installed on
> >> the server.
> >>
> >>
> >> Example
> >> profile - ABC Firewall
> >> this would be basic
> >>
> >> allow related,connected
> >> allow ssh
> >> 
> >> reject anything not from company ip address
> >> 
> >> drop broadcast
> >> drop multicast
> >> allow zabbix monitoring
> >> log  with limit
> >> reject with limit
> >> drop
> >>
> >>
> >> so if I applied this profile to server A it would get the basic
> firewall.
> >>
> >> The next step is if I had profile "app A"
> >> if it had something like
> >> rules to add to from anywhere
> >> allow inbound port 80
> >> allow inbound port 443
> >>
> >> rules to add to only from local network
> >> allow inbound port 8080
> >>
> >>
> >> I would hope to get puppet to update the basic firewall with info from
> >> app A and other profiles.
> >>
> >>
> >> Is this possible ?
> >>
> >> A
> >>
> >> On 24 May 2016 at 11:22, Rob Nelson >
> wrote:
> >> > I wrote some articles on using Git with puppet and r10k. It's a little
> >> > out
> >> > of date in the referenced versions of puppet and r10k, so check to
> make
> >> > sure
> >> > you're using the modern file locations, but otherwise remains
> accurate.
> >> >
> >> >
> https://rnelson0.com/2014/05/19/puppet-and-git-201-r10k-setup-installation/
> >> >
> >> > There's a link to a Git 100 series I wrote if you need assistance with
> >> > Git
> >> > itself.
> >> >
> >> >
> >> > On Monday, May 23, 2016, Alex Samad >
> wrote:
> >> >>
> >> >> Hi
> >> >>
> >> >> Is it really that painful to retro fit git. or is the way you think
> >> >> about th

Re: [Puppet Users] 3.8.5 Master with 3.7.2 Agents

[Rob Nelson]

IME you definitely won't have issues with 3.7.2 agents talking to a 3.8.5
master.

When you are ready to move to puppet 4, however, the upgrade docs say that
the agents should all hit 3.8 before you upgrade the master to 4.latest.
However, I skipped that step in my upgrade and 3.7.x agents talked fine
with 4.3.x (latest when I did this). I can't say if the docs are over
protective, or if I just missed all the cases where that breaks something.

On Friday, May 27, 2016, christg76  wrote:

> Hi, background here is that I want to use both Master and agents from the
> Debian repo. The Master runs on Jessie (3.8.5 from the backports), and some
> agents still on wheezy (3.7.2 from the backports).
> This is not a new install, but rather an intermediate upgrade to the last
> Puppet 3 version, before moving on to 4 and Puppet Server.
> Is anybody aware of issues with 3.8.5 Master and 3.7.2 Agents? Is there
> any reason why I should not be running this setup for a while? Cant see
> anything pressing from the release notes..
>
> Many Thanks,
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com
> 
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/a19fc9f0-8636-489e-bf8a-aaeec46040ab%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/a19fc9f0-8636-489e-bf8a-aaeec46040ab%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT_wOQ%2Bbt-T%3DZNEJbLQBA0DRcP21By9JLr9Kp6UDCc8ZUQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to deliberately cause modules to conflict?

[Rob Nelson]

You could test for the other class and fail, something like

if Defined(Class['dma'])
  Fail "you cannot use postfix with dma"

Typed from my phone, please check syntax and caps and such.

On Saturday, May 28, 2016, Dan Mahoney, System Admin 
wrote:

> Hey there.
>
> This is a weird question, but I guess I'll ask it anyway.
>
> Is there a way to say one of the following two things?
>
> 1) That you want a manifest to deliberately break when you try to include
> two different items?  For example, most of our machines run a very simple
> mailer called DMA (dragonfly mail agent), but some machines (which handle
> inbound mail) require full blown postfix.  I'd love for the manifest to
> simply refuse to operate.  Since there's no common files between them,
> right now if you try to install both, you'll just have a bunch of Augeas
> changes required for each MTA being made back and forth.
>
> 2) To say that if I've installed the "postfix" module, that it basically
> de-includes the "dma" class from the manifest?
>
> I realize I could in fact create an "mta" class which installs dma by
> default, but parameterize it such that postfix is another option.  Are
> there any other ways?
>
> -Dan
>
> --
>
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> ICQ: 13735144   AIM: LarpGM
> Site:  http://www.gushi.org
> ---
>
>

-- 

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

Re: [Puppet Users] Multiple resource bodies?

[Rob Nelson]

ential and may
> constitute privileged information. If you are not the intended recipient,
> you are hereby notified that any printing, copying, distribution or other
> use of this message is strictly prohibited. If you have received this email
> in error, please notify the sender immediately by return email, and delete
> it. Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com
> 
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/C2F62CDF5915D0458F0528664315BAE760A2217E%40MTL1EXC01.scqmtl.loto-quebec.com
> <https://groups.google.com/d/msgid/puppet-users/C2F62CDF5915D0458F0528664315BAE760A2217E%40MTL1EXC01.scqmtl.loto-quebec.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9zty389N%3DeZEsM18dn66%3DNgPyViFjsJYAUhoWvyzYPnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 4.5 and git & R10K

[Rob Nelson]

Which article were you reading? If you're looking at
https://rnelson0.com/2014/05/19/puppet-and-git-201-r10k-setup-installation/,
be aware that was written 2 years ago, and the location of files have moved
since then (I'll add a note shortly). You shouldn't actually need to manage
that file directly, anyway. Keep going to the 'Install r10k' section
header, where I use the forge module zack/r10k to configure and install
r10k via a .pp file (ex:
https://github.com/puppetinabox/controlrepo/blob/production/r10k_installation.pp).
As long as you use a recent version of that module, the r10k.yaml file will
be created in the correct location for you.


Rob Nelson
rnels...@gmail.com

On Tue, May 31, 2016 at 2:40 AM, Alex Samad  wrote:

> Hi
>
> New install, I am doing this on Centos 6.x
> I have installed the repo RPM
>
> I believe this is PC1 repo
>
>
> yum --disablerepo '*' --enablerepo puppetlabs-pc1 list | grep
> puppetlabs-pc1
> puppet-agent.x86_64  1.5.0-1.el6
>  @puppetlabs-pc1
> puppetdb.noarch  4.1.0-1.el6
>  @puppetlabs-pc1
> puppetdb-termini.noarch  4.1.0-1.el6
>  @puppetlabs-pc1
> puppetserver.noarch  2.4.0-1.el6
>  @puppetlabs-pc1
> puppet-client-tools.x86_64   1.0.0-1.el6
>  puppetlabs-pc1
> puppetdb-terminus.noarch 3-1.el6
>  puppetlabs-pc1
>
> I believe I have installed puppet , server , db and agent.
>
> But I can't find r10k
>
> rpm -qa | grep puppet
> puppetdb-4.1.0-1.el6.noarch
> puppet-agent-1.5.0-1.el6.x86_64
> puppetserver-2.4.0-1.el6.noarch
> puppetdb-termini-4.1.0-1.el6.noarch
> puppetlabs-release-pc1-1.0.0-2.el6.noarch
>
> I was following Rob's blog for puppet r10K + git and couldn't find
>  /etc/r10k.yaml
>
> so how do I install r10k :)
>
> --
> 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/672db58c-e03b-4e60-9003-0afce7b37af8%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/672db58c-e03b-4e60-9003-0afce7b37af8%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-52yxKe7uv-HBUQCARHwh%2B7vc8rJcaxGYmavOvyezJnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet and SVN

[Rob Nelson]

Alex, some of the later r10k articles have changed workflows, you may want
to read the whole series before implementing anything. I highly recommend
you check out Gary's Workflows Evolved article at
http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/.
The third link is to a reference controlrepo that Puppet suggests be used
as a basis for building your own controlrepo (
https://github.com/puppetlabs/control-repo). The controlrepo is what r10k
would be deploying.

You may also want to capture other items, mostly for bootstrapping, such as
.pp files to configure hiera and r10k. Whether you place those in your
controlrepo or another repo is up to you.


Rob Nelson
rnels...@gmail.com

On Tue, May 31, 2016 at 1:01 AM, Alex Samad  wrote:

> Hi
>
>
> Finally got some time to look at this
>
>
> On 24 May 2016 at 11:22, Rob Nelson  wrote:
> > I wrote some articles on using Git with puppet and r10k. It's a little
> out
> > of date in the referenced versions of puppet and r10k, so check to make
> sure
> > you're using the modern file locations, but otherwise remains accurate.
> >
> https://rnelson0.com/2014/05/19/puppet-and-git-201-r10k-setup-installation/
> >
> > There's a link to a Git 100 series I wrote if you need assistance with
> Git
> > itself.
>
>
> I notice in the previous installs of puppet every thing was under
> /etc/puppet  and you recommended putting that under git.
>
>
> I see with the latest version of puppet I have
>
> /etc/puppetlabs
> should I place that under git
>
> The only thing of concern there would be the ssl directory.
>
> or do i just add
> code/
> puppet/
> puppetserver/
>
>
> THanks
> Alex
>
> --
> 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/CAJ%2BQ1PUs%3Dr6a74VPQ9K0z40Uu_bHXAdfeJEYMph4JCJ%3DRcFLQw%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/CAC76iT9ANbHm59X_fLcsGYxERgFBBHC97bk2yQR9EvirFWtz0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet and SVN

[Rob Nelson]

It does not hide it, but it does automate some of the installation and
setup. You'll still need to live in Git, and should at least be familiar
with using r10k even if you set up a webhook and don't run it manually all
the time. It's what you use to rescue yourself when you mess up, as I can
attest to!

On Tuesday, May 31, 2016, Alex Samad  wrote:

> Thanks.  I did get onto the code control section which seems to
> suggest I should use it instead of git/r10k as it hids this away
> behind the scene !
>
>
>
> On 31 May 2016 at 22:36, Rob Nelson >
> wrote:
> > Alex, some of the later r10k articles have changed workflows, you may
> want
> > to read the whole series before implementing anything. I highly recommend
> > you check out Gary's Workflows Evolved article at
> >
> http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/
> .
> > The third link is to a reference controlrepo that Puppet suggests be
> used as
> > a basis for building your own controlrepo
> > (https://github.com/puppetlabs/control-repo). The controlrepo is what
> r10k
> > would be deploying.
> >
> > You may also want to capture other items, mostly for bootstrapping, such
> as
> > .pp files to configure hiera and r10k. Whether you place those in your
> > controlrepo or another repo is up to you.
> >
> >
> > Rob Nelson
> > rnels...@gmail.com 
> >
> > On Tue, May 31, 2016 at 1:01 AM, Alex Samad  > wrote:
> >>
> >> Hi
> >>
> >>
> >> Finally got some time to look at this
> >>
> >>
> >> On 24 May 2016 at 11:22, Rob Nelson >
> wrote:
> >> > I wrote some articles on using Git with puppet and r10k. It's a little
> >> > out
> >> > of date in the referenced versions of puppet and r10k, so check to
> make
> >> > sure
> >> > you're using the modern file locations, but otherwise remains
> accurate.
> >> >
> >> >
> https://rnelson0.com/2014/05/19/puppet-and-git-201-r10k-setup-installation/
> >> >
> >> > There's a link to a Git 100 series I wrote if you need assistance with
> >> > Git
> >> > itself.
> >>
> >>
> >> I notice in the previous installs of puppet every thing was under
> >> /etc/puppet  and you recommended putting that under git.
> >>
> >>
> >> I see with the latest version of puppet I have
> >>
> >> /etc/puppetlabs
> >> should I place that under git
> >>
> >> The only thing of concern there would be the ssl directory.
> >>
> >> or do i just add
> >> code/
> >> puppet/
> >> puppetserver/
> >>
> >>
> >> THanks
> >> Alex
> >>
> >> --
> >> 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/CAJ%2BQ1PUs%3Dr6a74VPQ9K0z40Uu_bHXAdfeJEYMph4JCJ%3DRcFLQw%40mail.gmail.com
> .
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/puppet-users/Q0ke0NzMRjY/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/CAC76iT9ANbHm59X_fLcsGYxERgFBBHC97bk2yQR9EvirFWtz0Q%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/CAJ%2BQ1PUr46gus%2Bipc8H%3DsOAC%2Bzh7NXHOqvDCudJnqhDK6O9jjw%40mail.gmail.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/CAC76iT9hqgajRpyMVwJ6AjvsDfTe4kLgR2SbnZA6%2BQGd%2B3f0pw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 4.5 and git & R10K

[Rob Nelson]

Just to be sure, code manager is PE only. It looks like you're using Puppet
Opensource instead.

On Tuesday, May 31, 2016, Alex Samad  wrote:

> Answer my own question (and for any one following on)
>
> going to use
> https://docs.puppet.com/pe/2016.1/cmgmt_managing_code.html
> https://docs.puppet.com/pe/2016.1/cmgmt_control_repo.html
>
> for the setup and then back to
>
> http://garylarizza.com/blog/2014/08/31/r10k-plus-directory-environments/
> https://rnelson0.com/2014/05/19/puppet-and-git-201-r10k-setup-installation/
>
>
>
>
>
> On 1 June 2016 at 10:56, Alex Samad >
> wrote:
> > Hi
> >
> > Lowe - okay - so I presume by that it doesn't come as a centos rpm ..
> > Rob - yes
> > Lee
> >
> >
> > So it looks like (more for my documentation )
> >
> > install the puppet repo into centos
> > install the puppet base components (DB, server, agent)
> >
> > Then I can install r10k via puppet ?
> >
> > i'm looking at this
> > https://docs.puppet.com/pe/2016.1/cmgmt_managing_code.html
> >
> > should I follow this to setup ?
> >
> >
> > "
> > If you are already using r10k to manage your Puppet code, we suggest
> > that you upgrade to Code Manager. Code Manager works in concert with
> > r10k, so when you switch to Code Manager, you no longer interact
> > directly with r10k.
> > "
> >
> >
> >
> >
> >
> > On 31 May 2016 at 16:58, Lee DaeHyung >
> wrote:
> >> Hi
> >>
> >> I think you could see this page first:
> https://forge.puppet.com/zack/r10k
> >> and this
> >>
> http://garylarizza.com/blog/2014/08/31/r10k-plus-directory-environments/
> >>
> >> These will guide you how to use it.
> >>
> >>
> >>
> >> 2016년 5월 31일 화요일 오후 3시 40분 49초 UTC+9, Alex Samad 님의 말:
> >>>
> >>> Hi
> >>>
> >>> New install, I am doing this on Centos 6.x
> >>> I have installed the repo RPM
> >>>
> >>> I believe this is PC1 repo
> >>>
> >>>
> >>> yum --disablerepo '*' --enablerepo puppetlabs-pc1 list | grep
> >>> puppetlabs-pc1
> >>> puppet-agent.x86_64  1.5.0-1.el6
> >>> @puppetlabs-pc1
> >>> puppetdb.noarch  4.1.0-1.el6
> >>> @puppetlabs-pc1
> >>> puppetdb-termini.noarch  4.1.0-1.el6
> >>> @puppetlabs-pc1
> >>> puppetserver.noarch  2.4.0-1.el6
> >>> @puppetlabs-pc1
> >>> puppet-client-tools.x86_64   1.0.0-1.el6
> >>> puppetlabs-pc1
> >>> puppetdb-terminus.noarch 3-1.el6
> >>> puppetlabs-pc1
> >>>
> >>> I believe I have installed puppet , server , db and agent.
> >>>
> >>> But I can't find r10k
> >>>
> >>> rpm -qa | grep puppet
> >>> puppetdb-4.1.0-1.el6.noarch
> >>> puppet-agent-1.5.0-1.el6.x86_64
> >>> puppetserver-2.4.0-1.el6.noarch
> >>> puppetdb-termini-4.1.0-1.el6.noarch
> >>> puppetlabs-release-pc1-1.0.0-2.el6.noarch
> >>>
> >>> I was following Rob's blog for puppet r10K + git and couldn't find
> >>> /etc/r10k.yaml
> >>>
> >>> so how do I install r10k :)
> >>>
> >> --
> >> You received this message because you are subscribed to a topic in the
> >> Google Groups "Puppet Users" group.
> >> To unsubscribe from this topic, visit
> >> https://groups.google.com/d/topic/puppet-users/836ysw94ya4/unsubscribe.
> >> To unsubscribe from this group and all its topics, 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/e3d27c2a-4604-4c0d-9f31-d17dba05ef17%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/CAJ%2BQ1PUihWLQK8dfL-JP7q3Shrxq8ow44hXjKuFxvn-10Jr2_Q%40mail.gmail.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/CAC76iT91EYN790ON9MGCf89sA7tTTEbMOG4gKUNi8ACeeKrPsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re-issuing agent certs from a newer Puppet Master

[Rob Nelson]

If you run `puppet agent -t [--server ]` and there is a mismatch, it
should provide directions to remedy the situation. In your case, wiping out
the ssldir on the client should suffice.


Rob Nelson
rnels...@gmail.com

On Wed, Jun 1, 2016 at 12:39 PM, warron.french 
wrote:

> Hello again,
> I have a a few Puppet Agents on to which I installed the puppet-agent
> software from my first Puppetmaster1, however, something happened and I had
> to rebuild that server - for labelling purposes I am (in this email)
> calling it Puppetmaster2.
>
> The puppet agents all have their certs signed by Puppetmaster1, but that
> server no longer exist and now I have Puppetmaster2 (still the same
> hostname actually).
>
>
> How do I associate the puppet-agent nodes with the newer Puppetmaster2
> server properly?
>
> Do I execute an: *rpm -e puppet-agent* on all of the nodes, and then
> re-run the *curl *command to properly re-install and generate a new
> certificate from the newer Puppetmaster2 (puppetmaster)?
>
> Do I just go onto each of the nodes and simply remove the ssl subdirectory
> and then re-run the: *puppet agent -t* command (which didn't seem fail,
> or show its certificate up on the Puppet Admin Console)?
>
>
> Thanks for the help,
>
> --
> Warron French
>
> --
> 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/CAJdJdQmKtCk%3DqeSoDxZVyBw%2BuaCVDzLg%2B%3D7-b58hobm0GUOZGQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAJdJdQmKtCk%3DqeSoDxZVyBw%2BuaCVDzLg%2B%3D7-b58hobm0GUOZGQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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_1CTMxht8Hs3pDOG_89a9kq9-Eg--oY33zipTb%2Bz_yqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trying to understand hiera and use in site.pp

[Rob Nelson]

Can you show what happens on a brand new CentOS 6 or 7 node when you run
`puppet agent -t`? It should work the way you expect, though the
service_enable and service_ensure settings match the default, so there
won't be that much different.

If it is working, but the output isn't clear on that, you could try running
puppet against it as is, then turn one of the service_* values to
false/stopped and you should see the state change. If it changes from
running to stopped, and back again if you revert the changes, you know
things are working. If not, it gets you closer to the issue.


Rob Nelson
rnels...@gmail.com

On Wed, Jun 1, 2016 at 12:00 PM, Courtney Campbell 
wrote:

> I just upgraded to puppet 3.8. Things I used to do in 3.7 like import and
> inherits no longer work. Anyway, I have been trying to figure out hiera.
> The docs on the site are great if you already know what you are doing.
> Anyway, I have environments setup. And have the hiera.yaml setup and
> working. Here is the hiera.yaml.
>
> ---
> :backends:
>   - yaml
> :yaml:
>   :datadir: "/etc/puppet/environments/%{::environment}/hieradata"
> :hierarchy:
>   - "nodes/%{::trusted.certname}"
>   - "%{::osfamily}/%{::operatingsystemmajrelease}"
>   - "virtual/%{::virtual}"
>   - "common"
>
>
> under my development einvironment I have
>
> RedHat/6.yaml
> RedHat/7.yaml
>
> 6.yaml has info for ntp and 7.yaml has info for chrony.
>
> 6.yaml
> ---
> ntp::restrict: 127.0.0.1
> ntp::service_enable: true
> ntp::service_ensure: running
> ntp::servers:
>   - ntp.server.com
>
> 7.yaml
> ---
> chrony::service_enable: true
> chrony::service_ensure: running
> chrony::servers:
>   - ntp.server.com
>
> That all looks fine and hiera test works.
> $ hiera ntp::service_enable ::environment=development ::osfamily=RedHat
> ::operatingsystemmajrelease=6
> true
>
> Now I am unsre how to make use of this in  my site.pp.
>
> I have this, but it is not working:
>
> if $operatingsystemmajrelease =~ '6' {
>include ntp
> }
> elsif $operatingsystemmajrelease == '7' {
>include chrony
> }
>
> It's setting the ntp.conf and chrony.conf files to the defaults. I really
> like puppet when it is working. But trying to figure this out is just
> pissing me off. I wish there was a doc that would hold my hand and just
> give exact examples on how to get this to work. It's not intuitive.
>
>
>
>
>
>
> --
> 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/62c54869-4f91-449f-bf31-3f720db862ab%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/62c54869-4f91-449f-bf31-3f720db862ab%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-QZLNN4S%3DdJk_nBYYvN9e7iYONO0W0mFPA7HtSS%2BHuxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trying to understand hiera and use in site.pp

[Rob Nelson]

"Works" in this case would mean that when you set ntp::service_enable:
false, on the next puppet run, the service would be disabled. If that's the
case, hiera is working and any errors are likely to do with typos or yaml
formatting issues with the other settings.


Rob Nelson
rnels...@gmail.com

On Wed, Jun 1, 2016 at 2:14 PM, Courtney Campbell  wrote:

> It does work, but it is not taking the setting in 6.yaml. It is setting
> the defaults.
>
> On Wednesday, June 1, 2016 at 11:58:26 AM UTC-5, Rob Nelson wrote:
>>
>> Can you show what happens on a brand new CentOS 6 or 7 node when you run
>> `puppet agent -t`? It should work the way you expect, though the
>> service_enable and service_ensure settings match the default, so there
>> won't be that much different.
>>
>> If it is working, but the output isn't clear on that, you could try
>> running puppet against it as is, then turn one of the service_* values to
>> false/stopped and you should see the state change. If it changes from
>> running to stopped, and back again if you revert the changes, you know
>> things are working. If not, it gets you closer to the issue.
>>
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>> On Wed, Jun 1, 2016 at 12:00 PM, Courtney Campbell 
>> wrote:
>>
>>> I just upgraded to puppet 3.8. Things I used to do in 3.7 like import
>>> and inherits no longer work. Anyway, I have been trying to figure out
>>> hiera. The docs on the site are great if you already know what you are
>>> doing. Anyway, I have environments setup. And have the hiera.yaml setup and
>>> working. Here is the hiera.yaml.
>>>
>>> ---
>>> :backends:
>>>   - yaml
>>> :yaml:
>>>   :datadir: "/etc/puppet/environments/%{::environment}/hieradata"
>>> :hierarchy:
>>>   - "nodes/%{::trusted.certname}"
>>>   - "%{::osfamily}/%{::operatingsystemmajrelease}"
>>>   - "virtual/%{::virtual}"
>>>   - "common"
>>>
>>>
>>> under my development einvironment I have
>>>
>>> RedHat/6.yaml
>>> RedHat/7.yaml
>>>
>>> 6.yaml has info for ntp and 7.yaml has info for chrony.
>>>
>>> 6.yaml
>>> ---
>>> ntp::restrict: 127.0.0.1
>>> ntp::service_enable: true
>>> ntp::service_ensure: running
>>> ntp::servers:
>>>   - ntp.server.com
>>>
>>> 7.yaml
>>> ---
>>> chrony::service_enable: true
>>> chrony::service_ensure: running
>>> chrony::servers:
>>>   - ntp.server.com
>>>
>>> That all looks fine and hiera test works.
>>> $ hiera ntp::service_enable ::environment=development ::osfamily=RedHat
>>> ::operatingsystemmajrelease=6
>>> true
>>>
>>> Now I am unsre how to make use of this in  my site.pp.
>>>
>>> I have this, but it is not working:
>>>
>>> if $operatingsystemmajrelease =~ '6' {
>>>include ntp
>>> }
>>> elsif $operatingsystemmajrelease == '7' {
>>>include chrony
>>> }
>>>
>>> It's setting the ntp.conf and chrony.conf files to the defaults. I
>>> really like puppet when it is working. But trying to figure this out is
>>> just pissing me off. I wish there was a doc that would hold my hand and
>>> just give exact examples on how to get this to work. It's not intuitive.
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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/62c54869-4f91-449f-bf31-3f720db862ab%40googlegroups.com
>>> <https://groups.google.com/d/msgid/puppet-users/62c54869-4f91-449f-bf31-3f720db862ab%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/51dbad04-15e6-4600-824b-814f5beb9e98%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/51dbad04-15e6-4600-824b-814f5beb9e98%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT85q4wHV_ofHF-%2BCfQosLJdtZ%3DvNFJ3iVX%2BZN0rQb-Ccg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to get modules recognized for use during classification

[Rob Nelson]

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/CAJdJdQkSAbQj1ChFkm3%3DEd7Car4LWvNojkM11XQwC-kpVTmxdg%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/puppet-users/CAJdJdQkSAbQj1ChFkm3%3DEd7Car4LWvNojkM11XQwC-kpVTmxdg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> 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/CAOsPUciQfxwvP_Qt17yzpowoVAMLMV0fyCZvm7tp8iVxo%3D6X8w%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/puppet-users/CAOsPUciQfxwvP_Qt17yzpowoVAMLMV0fyCZvm7tp8iVxo%3D6X8w%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/CAJdJdQkRpt8avZU98wdU5QpXeuNiBXz-e6jfcPTRQ3n8v51DQA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-users/CAJdJdQkRpt8avZU98wdU5QpXeuNiBXz-e6jfcPTRQ3n8v51DQA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/CAOsPUcj%3DS5k8nsE0C8-82s2oyPFRSdhRy87zVVZFQKBXpi%3DVww%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAOsPUcj%3DS5k8nsE0C8-82s2oyPFRSdhRy87zVVZFQKBXpi%3DVww%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT87ir4j5UZ5JsgTJLJM3fAGiTP6fHCA9p0%2Bce%3DMuLm6KQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] how to escape %{ in hiera

[Rob Nelson]

Literal works when there is only one literal percent sign; last I checked,
you cannot use it twice in the same value. You can use "%%{::}{::hostname}"
to return "%{::hostname}" - the middle "%{::}" returns nothing and splits
the first percent from the variable name at the end, preventing
interpolation there.

The use of the two semi colons was to avoid a scoping issue that cropped up
as a regression around the puppet 4.3 timeframe that "%%{}{::hostname}"
would run into. It is possible this has been fixed by now and the
naked semi colons in the braces are optional, but I have not tested this
with the latest version of puppet myself.

On Monday, June 6, 2016, Christopher Wood 
wrote:

> I ran into this too, use the literal function.
>
> $ grep -rh literal hieradata/
> testing::cwood1::param3: "%{literal('%')}{::hostname}"
> testing::cwood1::param3: "%{literal('%')}{::hostname}"
>
>
> https://docs.puppet.com/hiera/3.1/variables.html#the-literal-lookup-function
>
> On Mon, Jun 06, 2016 at 06:20:46AM -0700, Simon wrote:
> >Hi all
> >does anyone know how i can escape %{ in hiera without it trying to
> convert
> >to variable?
> >i want to add the following to configure a syslog filter for logstash
> >
> >match => { "message" =>
> >"<%{POSINT:syslog_pri}>%{SYSLOGTIMESTAMP:syslog_timestamp}
> >%{SYSLOGHOST:syslog_hostname}
> >%{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?:
> >%{GREEDYDATA:syslog_message}"}
> >
> >problem is it will try and convert to variables so only shows the
> >following on the server
> >
> >match => { "message" => "<>  (?:\[\])?: "}
> >
> >i have tried all the methods i can think of,  any help would be
> >appreciated.
> >
> >cheers
> >
> >S
> >
> >--
> >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/c1d3661a-ee9c-4460-bb13-be23b210ddb7%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/c1d3661a-ee9c-4460-bb13-be23b210ddb7%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/20160606134212.GA8045%40iniquitous.heresiarch.ca
> .
> 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/CAC76iT8Dr3535kH77c0S-11XB%2Bb%3DgY64XbXCgaeGo3y-XMiATg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Run Puppet Class only once

[Rob Nelson]

Puppet doesn't run a class, it applies a manifest. If you apply the
manifest once, either with `puppet apply somefile.pp` or `puppet agent -t`
without the agent running as a service, your catalog will be applied just
once. If you want to keep running puppet in the future, have your node
classifier return a different catalog without that class.

But, this kind of defeats the purpose of puppet. It has idempotency, so
whether you apply a catalog with that class once or a thousand times, your
results should always be the same. If it's not, you may be relying on Execs
too much over other resource types that are better suited to your needs.


Rob Nelson
rnels...@gmail.com

On Tue, Jun 7, 2016 at 4:21 AM, Christoph 
wrote:

> Hi there,
>
> I want to run a whole puppet class only once when provisioning a system
> for the first time.
>
> Unfortunately I do not find a way to do this.
>
> I know how to run commands once using onlyif or unless or creates, but
> what about running a whole class ?
>
> Thanks
>   Christoph
>
> --
> 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/81d340b3-3ea9-4c57-8603-e1d5ba03d860%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/81d340b3-3ea9-4c57-8603-e1d5ba03d860%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT8GbVZidX%3Dr7x4x32P4Q47-AyTNuRcQho%3DD0g_LRcimjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble creating a release RPM from puppetlabs/puppet source repo

[Rob Nelson]

I believe most reason for concern with AIO is that it installs a separate 
version of ruby, openssl, and other applications and libraries on your 
system. These need upgrading, just like your system apps/libs, and Puppet 
may both expose you to different vulnerabilities, since their versions are 
likely different from your system's, and they may not patch in a timely 
fashion. If you're on something like Arch Linux, probably a very sensible 
concern. As you are stuck using EL6 still, it's probably more sensible to 
use AIO than relying on end-of-support versions of everything from the 
system, particularly ruby 1.8.7. IMO, your security posture can only 
improve by using AIO, regardless of what your infosec ninnies say :)

On Wednesday, June 8, 2016 at 5:06:10 AM UTC-4, Matt Larson wrote:
>
> I did try installing via the PC1 (AIO) repo, and it worked ok for me at 
> home.  But like I said, can't do that at work.
>
> What is your main concern with AIO?  I don't wanna make a bad step here.   
> At first, AIO sounded scary to me... like some alternative to rpm/yum (in 
> case of rhel-based distros), but it's still the same packaging mechanism, 
> just dedicated repos per collective release, yes?
>
> Thanks for your input,
> Matt
>
> On Friday, June 3, 2016 at 6:10:01 PM UTC-4, jcbollinger wrote:
>>
>>
>>
>> On Friday, June 3, 2016 at 1:51:10 PM UTC-5, LinuxDan wrote:
>>>
>>> First Silly Question: Why ?
>>> What do you need to do that cannot be done with the RPM's from a 
>>> Puppetlabs repo ?
>>>
>>
>> If I were undertaking the exercise, it would be to avoid the AIO 
>> structure.  I may one day undertake that exercise, but until now I have 
>> instead just avoided upgrading to Puppet 4.
>>
>>
>> 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/48e9a21e-7cb9-4dc4-9bdb-e4192152edae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 4.5 and git & R10K

[Rob Nelson]

I do something similar with zack/r10k:

#r10k_installation.pp
Package {
  allow_virtual => true,
}

sshkey { 'github.com':
  type => 'ssh-rsa',
  key  => 
'B3NzaC1yc2EBIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==',
}

class { 'r10k':
  version   => '2.1.1',
  sources   => {
'puppet' => {
  'remote'  => 'g...@github.com:puppetinabox/controlrepo.git',
  'basedir' => $::settings::environmentpath,
  'prefix'  => false,
},
  },
  manage_modulepath => false
}

# bootstrap.sh snippets
mkdir -p /root/bootstrap/modules
puppet module install --modulepath=/root/bootstrap/modules zack/r10k
--version 3.2.0
puppet apply --modulepath=/root/bootstrap/modules r10k_installation.pp
r10k deploy environment -p

Since I don't know where the files move around from version to version, I
let zack/r10k worry about that for me :)


Rob Nelson
rnels...@gmail.com

On Wed, Jun 8, 2016 at 3:06 PM, Ben West  wrote:

> At least to answer the question of installing r10k tool for use with open
> source Puppetserver (or just puppet agent), I do this in a bootstrap script
> for my Puppetserver to install r10k from gem, and do the initial deployment
> of the control repo.  This for directory-based environments.
>
> # Install r10k gem and deploy control repo for this environment
> /opt/puppetlabs/puppet/bin/gem install r10k --no-ri --no-rdoc
> mkdir -p /etc/puppetlabs/r10k
> cat > /etc/puppetlabs/r10k/r10k.yaml < :cachedir: '/opt/puppetlabs/puppet/cache/r10k'
> :sources:
>   :controlrepo:
> remote: '${PUPPET_CONTROLREPO_URL}'
> basedir: '/etc/puppetlabs/code/environments'
> R10K
>
> rm -rf /etc/puppetlabs/code/environments/*
>
> /opt/puppetlabs/puppet/bin/r10k deploy environment -pv info
> ${PUPPET_ENVIRONMENT}
>
>
>
>
> On Thursday, June 2, 2016 at 2:33:31 PM UTC-5, Stefan Heijmans wrote:
>>
>> HI,
>>
>> Maybe you check the r10k workshop [1] which will do a complete
>> walkthrough of r10k or just watch their video [2] of it.
>>
>> [1] https://github.com/adrienthebo/r10k-workshop/blob/master/WORKSHOP.mkd
>> [2] https://www.youtube.com/watch?v=rQJbuqMCl9c
>>
>> Stefan
>>
>> On Thursday, June 2, 2016 at 2:32:46 AM UTC+2, Alex Samad wrote:
>>>
>>>
>>>
>>> But branches ??? I read I need to have a production branch ...
>>>
>> --
> 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/51cad53b-2969-41ee-9e39-e5030286792e%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/51cad53b-2969-41ee-9e39-e5030286792e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-oqSkbMyOaALueCUqepXCPbz5JjEe%3DeMCRm7G5%3DMbH%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble creating a release RPM from puppetlabs/puppet source repo

[Rob Nelson]

Eric

Sidebar question I've always had. There's the puppet gem that is commonly
used for rspec-puppet. Could that gem (plus its deps, facter, hiera, etc.)
suffice for some or all use cases?


Rob Nelson
rnels...@gmail.com

On Thu, Jun 9, 2016 at 3:55 PM, Eric Sorenson 
wrote:

> Matt, I would like to understand this better and help you adopt Puppet
> into your environment.
>
> This is not a rhetorical question, but it might sound like one: Do you
> rebuild your linux distribution from source RPMs? Because that is very
> similar to what the AIO Puppet agent bundle is: a mini distribution with
> the dependencies ending up in one artifact.
>
> People outside Puppet can (and have) successfully rebuilt AIO, and there
> are also sucessful packaging efforts that take JUST the Puppet 4 source and
> build a standalone RPM from it in the manner of the puppet 3 packages:
>
> puppet-4.2.1-3.fc24.src.rpm
> <http://fedora.osuosl.org/linux/releases/test/24_Beta/Everything/source/tree/Packages/p/puppet-4.2.1-3.fc24.src.rpm>
>
> But our recommendation is to use the all-in-one obviously; it's what's
> tested extensively and what ships in puppet enterprise.
>
> --eric
>
> On Wednesday, June 8, 2016 at 2:01:43 AM UTC-7, Matt Larson wrote:
>>
>> Sorry for not getting back soon, Dan.
>>
>> Good question.
>>
>> I work for a draconian company that only allows installing FOSS after our
>> infosec team has vetted the source code and then built from source; an
>> impossible hand-waving exercise, I know... but it is what it is.
>>
>> On Friday, June 3, 2016 at 2:51:10 PM UTC-4, LinuxDan wrote:
>>>
>>> First Silly Question: Why ?
>>> What do you need to do that cannot be done with the RPM's from a
>>> Puppetlabs repo ?
>>>
>>> Dan White | d_e_...@icloud.com
>>> 
>>> “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)
>>>
>>>
>>> On Jun 03, 2016, at 02:44 PM, Matt Larson  wrote:
>>>
>>>
>>> I'm trying to create an RPM from source on a stock RHEL6-based (CentOS6)
>>> instance, but I'm seeing errors.  I also posted in
>>> https://ask.puppet.com/question/26388/trouble-creating-a-release-rpm-from-puppetlabspuppet-source-repo/
>>>
>>> The output actually gets pretty far along, but stops at with this error:
>>> "install: cannot stat ext/redhat/puppet.conf: no such file or directory".
>>> If I fix that problem by manually editing the SPEC file, I just get more
>>> errors, so clearly there is no need to go down a rabbit hole since this
>>> must work for someone else, right?
>>>
>>> I'm also posted in
>>> https://ask.puppet.com/question/26388/trouble-creating-a-release-rpm-from-puppetlabspuppet-source-repo/
>>>
>>> Ideas?
>>>
>>> Thanks in Advance,
>>> Matt
>>>
>>>
>>> --
>>> 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/8d532582-be4b-4e58-813e-0e3519043a3f%40googlegroups.com
>>> <https://groups.google.com/d/msgid/puppet-users/8d532582-be4b-4e58-813e-0e3519043a3f%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/07f2aed4-eb2b-4d32-aebb-e05dd0377817%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/07f2aed4-eb2b-4d32-aebb-e05dd0377817%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT91z4-2E6pj4g7dpDUV5H2xpPa_86gv8G8Eeyz6ebEnpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue copying files if package exists

[Rob Nelson]

Your code only shows one package, $package, being created, but it does not
show where the value for $package is set. Either that var has the value
'postfix', or the postfix package is managed in another file. Regardless,
there is nothing showing where a package called $sshdPackage is managed
here, which is why the if block is never hit.

On Sunday, June 12, 2016, Helmut Schneider  wrote:

> Hi,
>
> I want to copy files if a package is installed. What works fine with
> the packages 'postfix', 'fail2ban' and 'apache2' does not with
> 'openssh-server.
>
> class fail2ban {
>   $postfixPackage = $::operatingsystem ? {
> /(?i:Ubuntu|Debian|Mint)/ => 'postfix',
> default   => 'undef',
>   }
>   $sshdPackage = $::operatingsystem ? {
> /(?i:Ubuntu|Debian|Mint)/ => 'openssh-server',
> default   => 'undef',
>   }
>
>   if ! defined (Package["$package"]) {
> package { "$package":
>   ensure => installed,
> }
>   }
>
>   if defined (Package["$postfixPackage"]) {
> file { "/etc/fail2ban/filter.d/postfix-amavis.local":
>   mode => "0644",
>   owner => 'root',
>   group => 'root',
>   source =>
> 'puppet:///modules/fail2ban/etc/fail2ban/filter.d/postfix-amavis.local',
> }
>   }
>   if defined (Package["$sshdPackage"]) {
> file { "/etc/fail2ban/filter.d/sshd-dos.local":
>   mode => "0644",
>   owner => 'root',
>   group => 'root',
>   source =>
> 'puppet:///modules/fail2ban/etc/fail2ban/filter.d/sshd-dos.local',
> }
>   }
> }
>
> $ rm /etc/fail2ban/filter.d/postfix-amavis.local
> /etc/fail2ban/filter.d/sshd-dos.local^C
> $ sudo rm /etc/fail2ban/filter.d/postfix-amavis.local
> /etc/fail2ban/filter.d/sshd-dos.local
> $ sudo puppet agent -t -d | grep -Ei
> '(postfix|openssh-server|postfix-amavis.local|sshd-dos.local)'
> [...]
> Debug: /Package[postfix]: Provider apt does not support features
> virtual_packages; not managing attribute allow_virtual
> Debug: /Package[openssh-server]: Provider apt does not support features
> virtual_packages; not managing attribute allow_virtual
> [...]
> Notice:
> /Stage[main]/Fail2ban/File[/etc/fail2ban/filter.d/postfix-amavis.local]/
> ensure: defined content as '{md5}c5def71abe5f682c2beb896fd5e30e10'
> Debug:
> /Stage[main]/Fail2ban/File[/etc/fail2ban/filter.d/postfix-amavis.local]:
> The container Class[Fail2ban] will propagate my refresh event
>
> So /etc/fail2ban/filter.d/sshd-dos.local is not copied. When
> uncommenting the if-clause 'if defined (Package["$sshdPackage"])' the
> file gets copied:
>
> $ sudo puppet agent -t -d | grep -i 'sshd-dos.local'
> Debug:
> /Stage[main]/Fail2ban/File[/etc/fail2ban/filter.d/sshd-dos.local]:
> Autorequiring File[/etc/fail2ban/filter.d/]
> Notice:
> /Stage[main]/Fail2ban/File[/etc/fail2ban/filter.d/sshd-dos.local]/ensure
> : defined content as '{md5}3d993678f322e5cb6335addaaa40512e'
> Debug:
> /Stage[main]/Fail2ban/File[/etc/fail2ban/filter.d/sshd-dos.local]: The
> container Class[Fail2ban] will propagate my refresh event
>
> Am I missing the obvious?
>
> $ puppet -V
> 3.8.7
> $ lsb_release -d
> Description:Ubuntu 14.04.4 LTS
>
> Thank you
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/xn0k75zp1zhqvbs000%40news.gmane.org
> .
> 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/CAC76iT_K38VC7NJA_%3D5znESXC1pM%2BsEWf4TeJ%2BZkWTOcyE1MfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue copying files if package exists

[Rob Nelson]

I think it's important to note that CMs like Puppet only manage what you
tell it to manage via your state description. "If openssh-server is
installed" doesn't fit that model well because it has a conditional state
based on a potentially unmanaged component. "I want to manage the package
openssh-server and the file sshd-dos.local" fits the state model, as does
"I do not want to manage the package openssh-server or the file
sshd-dos.local," and you can use roles or ENCs to determine whether to
apply the fictional class 'profile::ssh' below to a given node.

class profile::ssh {
  package {'openssh-server':
ensure => present,
  }
  file {'/path/to/sshd-dos.local':
ensure => file,
source => $somesource,
require => Package['openssh-server'],
  }
}

Modeling state can be tricky. It's pretty easy for a human to understand
conditionals like "If a package is installed, install a file," but for
state modeling, resources are best defined as either managed or unmanaged,
not somewhere in between. It's important to keep this in mind when modeling
state. You can always, of course, "beat" the computer and figure out a
workaround, but you're losing out on the strengths of the CM tool you have
chosen.


Rob Nelson
rnels...@gmail.com

On Mon, Jun 13, 2016 at 9:44 AM, Helmut Schneider  wrote:

> Craig Dunn wrote:
>
> > Given the above, what are you trying to achieve?  Are you trying to
> > manage the file resource after the package resource, or are you
> > saying you only want to manage the file if the package exists on the
> > target system?
>
> The latter. If openssh-server is installed, copy the file sshd-dos.local
>
> --
> 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/xn0k77es51fdoh1000%40news.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/CAC76iT8OjTGhwnWha6e0q1WiQay1XthKOKn%2BiVVHzDVE2FgdXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Removing unmanaged path /etc/puppetlabs/code/environments/ - r10k

[Rob Nelson]

r10k will deploy the modules listed in the Puppetfile into the modules
directory. If you need some local (to the controlrepo) modules that are not
deployed from the Puppetfile, the recommendation is to add them to a
directory called site, dist, or similar, and create a file called
environment.conf that says:

modulepath = site:modules:$basemodulepath

This allows the contents of the site directory (within the repo), modules
(populated by r10k) and the $basemodulepath (set via puppet.conf or
defaults, oftentimes unused) to all be valid module locations without r10k
or other automation stepping all over it.


Rob Nelson
rnels...@gmail.com

On Fri, Jun 17, 2016 at 4:56 PM, Ali  wrote:

>
> r10k deployment is failing, if  my repo paths has  "modules"  in it .   if
> I change modules to any other word or even module it works fine .  In order
> to correctly map environment on my puppet master I need r10k to map repo as
> /etc/puppetlabs/code/environments/production [branch name ] / modules/
> modulename .  Trying to figure out where is conflict any help will be
> appreciated .
>
> *repo server :*
>
> [gitcodereposerver coderepo]# ls -la
> total 16
> drwxr-x--- 4 root root 4096 Jun 17 16:35 .
> drwxr-x--- 7 root root 4096 Jun 15 15:43 ..
> drwxr-x--- 8 root root 4096 Jun 17 16:35 .git
> drwxr-x--- 3 root root 4096 Jun 17 16:35 modules
>
>
> gitcodereposerver coderepo]# git branch -v
>   development ad420ad test
> * production  ad420ad test
>
>
>
> *puppet master:*
>
>
>
> puppetmaster r10k]# cat r10k.yaml
> ---
> sources:
>   main:
> remote: 'root@gitcodereposerver:/home/pupp/coderepo'
> basedir: '/etc/puppetlabs/code/environments'
>
>
>  puppetmaster]#r10k deploy environment -pv
> INFO -> Deploying environment /etc/puppetlabs/code/environments/
> development
> INFO -> Environment development is now at
> a20646d68ed3259e3ae6eeda6c31dfca9f9ab9f0
> INFO -> Deploying environment /etc/puppetlabs/code/environments/
> production
> INFO -> Environment production is now at
> c73bcc40b41373d87908093035be58e60fc2ea29
> INFO -> Removing unmanaged path /etc/puppetlabs/code/environments/
> production/modules/compliance
>
>
> no compliance folder under modules  as shown below .
>
> puppetmaster environments]# ls
> development  production
> [ environments]# cd production/
> [ production]# ls
> modules
> [ production]# cd modules/
> [modules]# ls
>
>
>
> 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/f0b9c4e2-a90a-4b3e-ab75-094592e457d0%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/f0b9c4e2-a90a-4b3e-ab75-094592e457d0%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT8Ljh1dZmGdvSW3_NSMyu_5aKGm4KvR7M1CRDRh1D%3DB%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Newbie question re Hiera

[Rob Nelson]

Typically, you wouldn't actually classify or assign environment via hiera.
That's a value provided to the master during checkin, either as a CLI
argument or in puppet.conf. You could, of course, manage that file and
provide an environment value through hiera. But that would change the
environment used on next run, not the current run.

If you're in a master less environment, you could do some magic with hiera
cli/puppet lookup to find a value for the environment then call puppet
apply with that environment, but that seems a bit needlessly complex at
that point.

You would typically use hiera to classify the node and assign the classes
it receives, though. That would be done with hiera_include('some_key'),
where somekey is found in your hierarchy with the proper value.

On Tuesday, June 21, 2016, Alex Samad  wrote:

> Hi
>
> I have a greenfield install. Centos 6.x puppet opensource latest.
>  installed r10k.
>
> I have setup my git repo, used the control repo as a starting spot.
>
> now I am getting my head around hiera
>
> Looking at this https://docs.puppet.com/hiera/3.1/complete_example.html
>  I understand the way that works for each environment.
>
> But how do I use hiera to allocate nodes to environments ?
>
> for example can I classify by name regex, so all hosts with name
> ".*prod.*" is in production and ".*inf.*" into inf environment
> can I also classify by ip address ?
>
> --
> 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/8236b18c-2b1c-4733-a744-7dbeb281784c%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/8236b18c-2b1c-4733-a744-7dbeb281784c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT_Fy30T8fR_xWZvGCoXKaw%2BMqzXnzhWLV51zHmYvUR-dQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] external node classifier my setup

[Rob Nelson]

g is that you
> should
> > not identify Puppet's sense of "environment" with any external concept
> going
> > by the same name.  I maintain that nodes probably don't need to be
> > explicitly aware of the label of their operational environment, either,
> but
> > especially if you're exerting central control over Puppet environments,
> > there is no reason for nodes to care how Puppet labels those
> environments.
>
> so environments should only really align with puppets production code
> and none prod code. and by non prod code you are talking only about
> puppet module code ?
>
>
> >
> >
> > John
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/puppet-users/mZBLZQKZ0xM/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/df3051e0-c516-4e17-8835-9ebabb82ae5e%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/CAJ%2BQ1PXEBMSmqdeshY9N9Q%3DeQGhyD7g3cBSx3dt8nFA8ENzajA%40mail.gmail.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/CAC76iT-5rs8nQYQ7LXHfYUMZvGegG%3D3Os4FgPd%2BAKp7OaxDrWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] external node classifier my setup

[Rob Nelson]

On Friday, June 24, 2016, Alex Samad  wrote:

> The point i was trying to make was not the how. But that a group of
> nodes will have 1 config and another a different config.  It seems
> like environments would be the way to group that.
>

Alex,

Environment is a very overloaded term. In this case, 'environment' means 'a
discrete set of puppet code and data.' It has no direct relation to
'environment' meaning 'an operational status of a set of services' (or
however one might deceive the concepts of 'production' vs 'development' vs
…). It is important not to confuse those two, or any other use of the term
environment.

The reason there is no direct relationship between those two versions of
the term is because a node that is in the operational status of production
can switch between the production environment and any other environment of
your puppet code without affecting its operational status (whether it
should is a very different question!). You may also have two nodes that are
both production nodes that receive different values for e.g. their mail
relay.

This data is better separated via hiera, where you can say "all nodes in
the Sydney datacenter use mail relay A, and all those in Perth use mail
relay B." They don't have to be in separate puppet environments for that to
occur.

Environments are more often used in your code development workflow, where
environments map to your version control branches. You branch off of
development to a branch called feature_a. None of your actual nodes check
in against either of these environments, but your CI pipeline and your
developers test against these with vagrant or similar. You maybe even take
a canary node that normally uses the puppet environment production and have
it check in against the feature_a environment instead.  When the feature
works properly, you merge feature_a->development and delete the branch
feature_a, which deletes the environment feature_a.

You repeat this for a few features, and then you merge from
development->production. Now the code that was tested in CI is being used
by the operational production nodes, which are using the operational
environment as well. Then you go back to making more feature branches and
repeat.

Along the way, a given node may check into one puppet environment 99% of
the time, but nothing prevents the node from using a different puppet
environment, for testing or urgent fixes or for any other reason. The
puppet environment can be pretty fluid without changing the data and
configuration a given node receives much if at all.

I hope that's not too confusing. You did say you haven't managed a puppet
install yet, and I think if you set something up in vagrant or a lab, some
of the concepts would become clear a lot quicker than when we discuss them
in the abstract.


-- 

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

Re: [Puppet Users] Working with hiera and debugging

[Rob Nelson]

 > #Puppet Server Tuning
> >
> puppet_enterprise::master::puppetserver::jruby_max_requests_per_instance: 0
> >
> >
> >
> > cat
> > /etc/puppetlabs/code/environments/alex/site/profile/manifests/mypuppet.pp
> > class profile::mypuppet {
> >
> > package { 'puppet-agent' :
> > ensure => 'present',
> > }
> >
> > #include ::puppet_agent;
> >
> > }
> >
> >
> >
> > then i go to my test node
> >
> > # for testing ..
> > sudo /opt/puppetlabs/bin/puppet agent --noop --verbose -t
> > Notice: Local environment: 'production' doesn't match server specified
> node
> > environment 'alex', switching agent to 'alex'.
> > Info: Retrieving pluginfacts
> > Info: Retrieving plugin
> > Info: Loading facts
> > Info: Applying configuration version
> > 'ee80ea6b15178f517618992833a8bc3c7c378bd0'
> > Notice: Applied catalog in 0.04 seconds
> >
> > I don't see any mention of mypuppet ??
> >
> > Am i testing the system the right way ?
> > What am i doing wrong ?
> >
> > Thanks
> > Alex
> >
> >
> >
> >
> >
> >
> >
> > --
> > 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/a7bb4a4b-d61b-4db0-bdff-57030d75cb51%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "Puppet Users" group.
> > To unsubscribe from this topic, visit
> > https://groups.google.com/d/topic/puppet-users/OAtIhSwbyEs/unsubscribe.
> > To unsubscribe from this group and all its topics, 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/cb352a0f-20a3-c79c-ada2-fe717850ebff%40alter3d.ca
> .
> >
> > 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/CAJ%2BQ1PUt6kDMRVveYmZwcYHMmVySK0i05Fed%2BPkY2H-pTrmmTA%40mail.gmail.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/CAC76iT-p5jMTzF%2BDg0o%3DzES985ciOVUePtnraFwPM4_36BqDog%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] R10k Post Recieve Hook Git/Github

[Rob Nelson]

I've written some articles on r10k, including setting up a webhook -
https://rnelson0.com/2015/05/03/configuring-an-r10k-webhook-on-your-puppet-master/
It's from 2015 so you should probably use newer versions of zack/r10k and
the r10k gem but it's otherwise the same as what I'm using to this day.


Rob Nelson
rnels...@gmail.com

On Thu, Jun 30, 2016 at 1:50 PM, broncosd183  wrote:

> Hello,
>
> I am currently using the open source version of puppet and am looking to
> automate the deployment of environments whenever a change is pushed to the
> control repo (containing the Puppetfile, etc). I am interested in finding
> the simplest solution possible and have come across some solutions like
> reaktor, and other custom hooks, though I haven't gotten any fully
> functioning. Is anyone able to share their setup / potential steps towards
> implementing such a hook? I am only running a single master as well.
>
> --
> 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/dca083c5-fc00-4719-b862-31a91481966d%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/dca083c5-fc00-4719-b862-31a91481966d%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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_OAVi9UsnZbv9gp8nDwerVExCQq1w4NWxpcXO%2BqOqoQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Dependacies with Custom Types

[Rob Nelson]

I don't know the specifics of how it works, but the puppet/zabbix module
has a type that relies on the zabbixapi which it also provides. You may
want to review that module to see how the package and type are implemented
in detail.

On Monday, July 11, 2016,  wrote:

> Hi,
>
> I have created a custom type which uses the ipaddress rubygem in the
> validation function. However, this package is not part of my standard build
> and I can find no way of installing it from Puppet as the catalog
> compilation fails with "Could not autoload *type*".
>
> Is there anyway to manage this type of dependency within Puppet, or should
> I look to do it outside?
>
> Puppet version: 3.6
>
> Thanks,
>
> Alan
>
> --
> 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/845debad-5c81-41b8-b3c9-a1a1405ef3b5%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/845debad-5c81-41b8-b3c9-a1a1405ef3b5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-BqLZ5%2B%3DRJfoVzrJ%2BsY7P7Bj13j4MSkxRtt447jacFfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Custom facts are updated in the next execution of "puppet agent --test"

[Rob Nelson]

Amrit, since you are deploying it as a file resource, it has to be deployed
to the agent before it will be used. You could instead add the fact to your
module, where plugin sync will push it to the agent before it collects
facts, which means it is there on the first facts run. See
https://docs.puppet.com/facter/3.1/custom_facts.html#fact-locations

On Tuesday, July 12, 2016, Amrit Atmajit  wrote:

> Hi,
>
> I am using following code snippet in one of the init.pp file of puppet
> master to load the updated facts in "facts.yaml" available in
> "C:\marionette-collective\etc\" folder.
>
>
>
>   file { "c:/marionette-collective/etc/facts.yaml":
>
> loglevel => debug,
>
> content  => inline_template("<%= scope.to_hash.reject { |k,v| k.to_s
> =~ /(uptime_seconds|timestamp|free)/}.to_yaml %>"),
>
> require   => [ Exec['set_executionpolicy'], Exec['gencustomfacts'] ],
>
>   }
>
>
>
> But, the custom facts are getting updated in facts.yaml file on execution
> of next "puppet agent --test", not immediately.
>
> Am I missing something to update the facts.yaml for the custom facts on
> the immediate execution of "puppet agent --test" not on the next execution?
>
> Regards
> Amrit
>
> --
> 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/060a4391-03a0-4074-b322-72a7784fcab0%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/060a4391-03a0-4074-b322-72a7784fcab0%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT8%2BDHZ5zW%2BcY63yzvWfjys-9jvYa88WFrPq3Wgntt%3DycQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Dependacies with Custom Types

[Rob Nelson]

I second this motion, that was a great explanation. I'd love to see that
documented well and maybe in a git repo with a 'bad' and 'good' branch to
better examine the differences, if at all possible!


Rob Nelson
rnels...@gmail.com

On Wed, Jul 13, 2016 at 8:51 AM, jcbollinger 
wrote:

>
>
> On Wednesday, July 13, 2016 at 12:52:58 AM UTC-5, Josh Cooper wrote:
> [A clear and detailed explanation...]
>
> That was great, Josh.  Are the same instructions available somewhere among
> Puppet's online docs and tutorials?  If not, they should be.
>
> 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/774fe4a8-0aa4-4227-958a-b97e5e3afe75%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/774fe4a8-0aa4-4227-958a-b97e5e3afe75%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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_tAsp1DZ_SuY1drgiwMVLpaaVaEaLv8SMCtfEVpDBycw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] LDAP Service failed to start: Difference between interactive shell commands and puppet commands

[Rob Nelson]

My guess would be the umask is not what you expect, or maybe the first part
of `command 2` failed (use `&&`, as `;` will let the second part run if the
first failed). However, I would encourage you to look at using
puppet/archive or a deb or even file resources to push down what you need,
rather than execs, as you can see how fragile an difficult to debug they
can be.


Rob Nelson
rnels...@gmail.com

On Fri, Jul 15, 2016 at 6:20 AM, gogan  wrote:

> I want to replace some files from an archive.
>
>
> I'm running following commands successfull on the shell.
>
>
> tar -xf /root/ldap_etc.tar.gz -C /etc/
>
> chown -R root:root /etc/ldap/ ; chown -R openldap:openldap /etc/ldap/slapd.d/
>
> After doing this, i'm able to start and stop the corresponding service.
>
>
> Now in Puppet:
>
>
> exec { "command 1":
>   command => "bash --login -c 'tar -xf /root/ldap_etc.tar.gz -C /etc/'",
>   path => ['/bin', '/usr/bin'],
> }
>
> exec { "command 2":
>   command => "bash --login -c 'chown -R root:root /etc/ldap/ ; chown -R 
> openldap:openldap /etc/ldap/slapd.d/'",
>   path => ['/bin', '/usr/bin'],
> }
>
>
> The service is not able to start!
>
>
> All files are copied successfull and the rights are set right.
>
>
> I changed the command execution in the way to set user, cwd and so on
> without bash --login -c ... but there is no difference.
>
>
> I'm not understanding the difference between puppet and shell execution.
> Why i get an error?
>
>
> [23039]: @(#) $OpenLDAP: slapd  (Jan 16 2016 23:00:08) $
> root@chimera:/tmp/buildd/openldap-2.4.40+dfsg/debian/build/servers/slapd[23039]:
>  olcBackend: value #0:  failed init (mdb)![23039]: config error 
> processing olcBackend={0}mdb,cn=config:  failed init[23039]: 
> DIGEST-MD5 common mech free[23039]: slapd stopped.[23039]: 
> connections_destroy: nothing to destroy.[23035]: Starting OpenLDAP: slapd 
> failed!
> systemd[1]: slapd.service: control process exited, code=exited status=1
> systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight 
> Directory Access Protocol).
> systemd[1]: Unit slapd.service entered failed state.
>
> --
> 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/ac954073-8ebc-44c7-8b0d-d3fb3ce17c13%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/ac954073-8ebc-44c7-8b0d-d3fb3ce17c13%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT8%3DV%3Dv6NuhaH4BeoZNvsEN1YXfuM1DSWoGAWwrtsoB6rA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Changing parameters for default/global classes inside a role

[Rob Nelson]

Can you share some of your code? This is somewhat complicated to follow,
but probably simpler to view the code.

However, I believe that what you want is to add a parameter to the class
that includes profile_tuned, perhaps called $is_oracle. If the parameter is
false, include profile_tuned, if true, include profile_tuned_for_oracle.
Or, move that inside the class profile_tuned. You can then set
'profile_whatever::is_oracle: true' via hiera and everything will flow
properly.

How you do that in your hierarchy is up to you but a fact-based tier is a
good idea. Keep in mind that facts are distributed and reported to the
master BEFORE catalog compilation, so they shouldn't need a second run to
take effect - unless their value is dependent upon software that puppet
would install on its first run.

On Sunday, July 17, 2016, David Bell  wrote:

> Hello,
>
> Assume an open source Puppet deployment using the roles and profiles
> paradigm and Heira (
> https://puppet.com/presentations/designing-puppet-rolesprofiles-pattern)
>
> Lets say I have a role module called 'role_applicationX' which includes
> two profile modules - "profile_oracle_server" and "profile_tomcat".
>
> Now also assume that all my systems, via the external node classifier,
> loads a series of base profile modules, such as "tuned" (a Red Hat tool for
> managing kernel settings). In this list of base profile modules is
> "profile_tuned".
>
> The profile_tuned class defaults to a tuned system profile of 'virtual' if
> it finds that the system is virtual based on Facts.
>
> What I want to be able to do is inside the "profile_oracle_server" in some
> way signal or change "profile_tuned" to use the oracle tuned profile. You
> can't redefine classes using 'resource-like' syntax, so I can't just change
> parameters to "profile_tuned". Variables are actually constants, so a
> profile can't change an existing variable.
>
> Heira doesn't solve this problem, although I'm told that it should,
> because including profile_oracle_server cannot have any bearing on Heira.
> Heira is great at letting you change the functionality of classes/modules
> per-node, but I cannot find a way for 'role' modules to change what a
> profile module does, without every role having to define all of my base
> profiles. I'm told that an ENC should only ever set a 'role' for a node,
> and nothing else, and yet it seems pretty clear to me I also have to store
> configuration for a role in the node's heira configuration, so I have to
> change things in multiple places.
>
> What I'd like to do is assign a role to a node and that should alter the
> base configuration as needed.
>
> The only other option I can think of is a horrible "if not defined define
> the base profile module" hack where base profiles are only declared via
> resource-like syntax if a role doesn't define them (i.e. with specific
> parameters). I'm pretty sure Heira was created to avoid this, and yet it
> seems the only in-puppet-code option I can think of.
>
> Any help and advice would be much appreciated.
>
> Cheers,
>
> David Bell
> University of Southampton
>
> --
> 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/329bc309-4780-4a6c-9bd6-15b9f8b0827c%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/329bc309-4780-4a6c-9bd6-15b9f8b0827c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT8ZD%3Dvgo35%2BnZnV_PwA13STsY5m9GB9yFCfk-cxfMZGKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet module and Hiera variable access

[Rob Nelson]

You should investigate hiera automatic parameter lookup (
https://docs.puppet.com/hiera/latest/puppet.html#automatic-parameter-lookup).
You need to make `icinga2_ido_password` a parameter of your class and then
APL will "magically" populate that properly. Check out the article, which
gets into details of default values and whatnot as well.


Rob Nelson
rnels...@gmail.com

On Mon, Jul 18, 2016 at 2:54 PM, Tobias Köck  wrote:

> Hi,
>
> for testing Hiera a have written a common.yaml with
>
> qmonitoring::db::icinga2_ido_password: "mypwd34"
> qmonitoring::db::icinga2_webdb_password: "mypwd544"
>
> and I have a module named qmonitoring with a class named
>
> class qmonitoring::db {
>
> $new_var = $icinga2_ido_password,
>
> }
>
> where I try to automatically access the
>
> qmonitoring::db::icinga2_ido_password
>
> Hiera variable.
>
> With $icinga2_ido_password it doesn't work with hiera( ...) it works.
>
> How can I automatically access the Hiera variable in my class with the
> priority lookup without having to use hiera(...)?
>
> Greetings and thanks,
> Tobias
>
>
>
> --
> 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/486eacc6-36c2-da49-c958-def735f2f6cb%40gmail.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/CAC76iT9F_UG4B-Xfaj-YHK1Z8dzDFf5oZVXawgs_TpM%2BV%2BeaqA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera Lookups Fail with variables

[Rob Nelson]

It cannot find the files. Do they exist and are they readable to the user
you are running hiera/the puppet master service as?

On Monday, July 18, 2016, John Baird  wrote:

> Attempting to use hiera to hold all of my node-specific variables.  It has
> been some time since I have run a puppet server, but I know it's not THAT
> hard.  That being said, my modules run fine, but hiera is not looking them
> up correctly.  It appears that any lines that contain any variables in the
> hiera.yaml are ignore and are not searched.  Any assistance would be
> great!  I'm sure it's something small, but sooo confused...
>
>
> HIERA.YAML
> --
> ---
> :backends:
>   - yaml
> :yaml:
>   :datadir: "/opt/local/modules/hieradata"
> :hierarchy:
>   - '%{calling_module}/%{::hostname}'
>   - '%{calling_module}/common'
>   - common
>
>
> hiera -d 'dhcpd::package_name' environment=production
> DEBUG: 2016-07-18 20:48:38 -0400: Hiera YAML backend starting
> DEBUG: 2016-07-18 20:48:38 -0400: Looking up dhcpd::package_name in YAML
> backend
> DEBUG: 2016-07-18 20:48:38 -0400: Looking for data source common
> DEBUG: 2016-07-18 20:48:38 -0400: Cannot find datafile
> /opt/local/modules/hieradata/common.yaml, skipping
> nil
>
>
> ---
> :backends:
>   - yaml
> :yaml:
>   :datadir: "/opt/local/modules/hieradata"
> :hierarchy:
>   - '%{calling_module}/%{::hostname}'
>   - '%{calling_module}/common'
>   - common
>   - puppet_test
>
> hiera -d 'dhcpd::package_name' environment=production
> DEBUG: 2016-07-18 20:49:30 -0400: Hiera YAML backend starting
> DEBUG: 2016-07-18 20:49:30 -0400: Looking up dhcpd::package_name in YAML
> backend
> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source common
> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile
> /opt/local/modules/hieradata/common.yaml, skipping
> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source puppet_test
> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile
> /opt/local/modules/hieradata/puppet_test.yaml, skipping
> nil
>
> --
> 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/34a20f55-02a2-49c7-88d2-28885636dab2%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/34a20f55-02a2-49c7-88d2-28885636dab2%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-nj8LKObnHkU1CzCHkqALSOxk7yaE%2BeGhpzfOfL3ZtPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Hiera Lookups Fail with variables

[Rob Nelson]

That is correct, when those values are not found, hiera doesn't search
those tiers at all. The debug information could be more helpful about it,
though.


Rob Nelson
rnels...@gmail.com

On Tue, Jul 19, 2016 at 1:27 PM, Gavin Williams  wrote:

> John
>
> I'm pretty sure when you're running hiera on the command line, you need to
> 'provide' the fact values. See
> https://docs.puppet.com/hiera/3.2/command_line.html#fact-sources
>
> HTH
>
> Gav
>
>
> On Tuesday, 19 July 2016 18:14:55 UTC+1, John Baird wrote:
>>
>> All files should be readable as they are either 755 or 644.  Even if they
>> don't exist, hiera should still attempt to "Search" that path and show me
>> what directories it is searching when doing so with debug on.  Since it is
>> not showing the directories with variables, it, for some reason, is
>> skipping them alltogether.
>>
>> another example:
>>
>> ---
>> :backends:
>>   - yaml
>> :yaml:
>>   :datadir: "/opt/local/modules/hieradata"
>> :hierarchy:
>>   - common1/%{calling_class}
>>   - common2/%{calling_class}
>>   - common3
>>   - puppet_test
>>
>> hiera -d 'dhcpd::package_name' environment=production
>> DEBUG: 2016-07-19 13:12:49 -0400: Hiera YAML backend starting
>> DEBUG: 2016-07-19 13:12:49 -0400: Looking up dhcpd::package_name in YAML
>> backend
>> DEBUG: 2016-07-19 13:12:49 -0400: Looking for data source common3
>> DEBUG: 2016-07-19 13:12:49 -0400: Cannot find datafile
>> /opt/local/modules/hieradata/common3.yaml, skipping
>> DEBUG: 2016-07-19 13:12:49 -0400: Looking for data source puppet_test
>> DEBUG: 2016-07-19 13:12:49 -0400: Cannot find datafile
>> /opt/local/modules/hieradata/puppet_test.yaml, skipping
>> nil
>>
>> common1 and common2 are completely ignored.
>>
>> On Tuesday, July 19, 2016 at 5:48:59 AM UTC-5, Rob Nelson wrote:
>>>
>>> It cannot find the files. Do they exist and are they readable to the
>>> user you are running hiera/the puppet master service as?
>>>
>>> On Monday, July 18, 2016, John Baird  wrote:
>>>
>>>> Attempting to use hiera to hold all of my node-specific variables.  It
>>>> has been some time since I have run a puppet server, but I know it's not
>>>> THAT hard.  That being said, my modules run fine, but hiera is not looking
>>>> them up correctly.  It appears that any lines that contain any variables in
>>>> the hiera.yaml are ignore and are not searched.  Any assistance would be
>>>> great!  I'm sure it's something small, but sooo confused...
>>>>
>>>>
>>>> HIERA.YAML
>>>> --
>>>> ---
>>>> :backends:
>>>>   - yaml
>>>> :yaml:
>>>>   :datadir: "/opt/local/modules/hieradata"
>>>> :hierarchy:
>>>>   - '%{calling_module}/%{::hostname}'
>>>>   - '%{calling_module}/common'
>>>>   - common
>>>>
>>>>
>>>> hiera -d 'dhcpd::package_name' environment=production
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Hiera YAML backend starting
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Looking up dhcpd::package_name in
>>>> YAML backend
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Looking for data source common
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Cannot find datafile
>>>> /opt/local/modules/hieradata/common.yaml, skipping
>>>> nil
>>>>
>>>>
>>>> ---
>>>> :backends:
>>>>   - yaml
>>>> :yaml:
>>>>   :datadir: "/opt/local/modules/hieradata"
>>>> :hierarchy:
>>>>   - '%{calling_module}/%{::hostname}'
>>>>   - '%{calling_module}/common'
>>>>   - common
>>>>   - puppet_test
>>>>
>>>> hiera -d 'dhcpd::package_name' environment=production
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Hiera YAML backend starting
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking up dhcpd::package_name in
>>>> YAML backend
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source common
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile
>>>> /opt/local/modules/hieradata/common.yaml, skipping
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source puppet_test
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile
>>>>

Re: [Puppet Users] Hiera Lookups Fail with variables

[Rob Nelson]

If the value is nil, then it skips that tier entirely.

On Tuesday, July 19, 2016, John Baird  wrote:

> I was using calling_class as an example.  %{calling_module} used to work,
> but now does not.  Are you aware of what should be used instead?  Things
> like %{::hostname} do not work either.
>
> My other real concern is that when using something like
> "%{calling_module}/random_thing", there is no lookup for "/random_thing"
> when calling_module is not interpolated as I would expect it to since it
> should see it as a nil value.
>
> On Tuesday, July 19, 2016 at 4:59:50 PM UTC-5, Gavin Williams wrote:
>>
>> John
>>
>> Yes, the 'common1' and 'common2' tiers are being ignored because
>> 'calling_class' doesn't expand to anything when running on the command line.
>>
>> Try running
>> hiera -d 'dhcpd::package_name' environment=production calling_class=*x*
>> replacing x with the corresponding class_name you'd expect to be
>> resolving...
>>
>> Gav
>>
>> On Tuesday, 19 July 2016 22:29:41 UTC+1, John Baird wrote:
>>>
>>> If you look at the hiera debug output from the last reply I posted, it
>>> clearly shows that several folders with variables are not looked at when it
>>> should be.  Even if it doesn't find data in those folders, hiera should
>>> still explicitly show that it is TRYING to look there, but that doesn't
>>> happen.  It clearly is not searching where it should be, which is why
>>> everything is failing unless it's all hard-coded, which is obviously not
>>> ideal.
>>>
>>> On Tuesday, July 19, 2016 at 2:16:10 AM UTC-5, John Baird wrote:
>>>>
>>>> Attempting to use hiera to hold all of my node-specific variables.  It
>>>> has been some time since I have run a puppet server, but I know it's not
>>>> THAT hard.  That being said, my modules run fine, but hiera is not looking
>>>> them up correctly.  It appears that any lines that contain any variables in
>>>> the hiera.yaml are ignore and are not searched.  Any assistance would be
>>>> great!  I'm sure it's something small, but sooo confused...
>>>>
>>>>
>>>> HIERA.YAML
>>>> --
>>>> ---
>>>> :backends:
>>>>   - yaml
>>>> :yaml:
>>>>   :datadir: "/opt/local/modules/hieradata"
>>>> :hierarchy:
>>>>   - '%{calling_module}/%{::hostname}'
>>>>   - '%{calling_module}/common'
>>>>   - common
>>>>
>>>>
>>>> hiera -d 'dhcpd::package_name' environment=production
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Hiera YAML backend starting
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Looking up dhcpd::package_name in
>>>> YAML backend
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Looking for data source common
>>>> DEBUG: 2016-07-18 20:48:38 -0400: Cannot find datafile
>>>> /opt/local/modules/hieradata/common.yaml, skipping
>>>> nil
>>>>
>>>>
>>>> ---
>>>> :backends:
>>>>   - yaml
>>>> :yaml:
>>>>   :datadir: "/opt/local/modules/hieradata"
>>>> :hierarchy:
>>>>   - '%{calling_module}/%{::hostname}'
>>>>   - '%{calling_module}/common'
>>>>   - common
>>>>   - puppet_test
>>>>
>>>> hiera -d 'dhcpd::package_name' environment=production
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Hiera YAML backend starting
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking up dhcpd::package_name in
>>>> YAML backend
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source common
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile
>>>> /opt/local/modules/hieradata/common.yaml, skipping
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Looking for data source puppet_test
>>>> DEBUG: 2016-07-18 20:49:30 -0400: Cannot find datafile
>>>> /opt/local/modules/hieradata/puppet_test.yaml, skipping
>>>> nil
>>>>
>>> --
> 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/096a7c43-6461-4f69-a9ee-d683fb71edb9%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/096a7c43-6461-4f69-a9ee-d683fb71edb9%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9NX3P0H3mJZxSfkBEW_h1-Kw7HMWh6HXpYNm-%2BnfARFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Basic question

[Rob Nelson]

I am not intimately familiar with them, but I think the modules
puppet/archive or puppet/staging will do what you want.

On Wednesday, July 20, 2016, warron.french  wrote:

> Is it possible to extract a tarball using the puppet module, and then set
> the permission of all the directory after that?
>
> Would one select a provider and then provide the tarball filename as the
> argument somehow?
>
> \\Warron French from mobile
>
> --
> 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/CAJdJdQm8h_NaqqodD8-3%3D%2BA713EVrRYm%2Bh4B5MVpW36V35jyzQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAJdJdQm8h_NaqqodD8-3%3D%2BA713EVrRYm%2Bh4B5MVpW36V35jyzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9VKuN%3Da%2BrtyOsX%2Bm-DThws1Y8fjAPT92_05f43FUA6LA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Recommended/Suggested R10k Deployment Strategy

[Rob Nelson]

I don't do any central modules, but everything in an environment
modulepath. That way there's no confusion about what module may be loaded.
It also keeps the configuration as simple as can be, no environment is
special in any way.


Rob Nelson
rnels...@gmail.com

On Wed, Jul 27, 2016 at 10:06 AM, dsdwcal  wrote:

> So relatively recently we have deployed and set up R10k to manage our
> environments and modules. In terms of suggested practices, I am curios what
> others are currently doing to manage their production/dev environments. It
> seems logical to me to change the production puppetfile's moduledir to
> manage the /etc/puppet/modules directory, and have all other environments
> manage their own environments moduledirectory
> (/etc/puppet/environments/... That way the lookup hierarchy
> for modules will first look in the specific environment. If them module is
> not found, the production version of the module will be deployed. Is this
> recommended/ are there better ways of doing this?
>
> --
> 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/ea3009d7-09b9-4797-9087-3c012a0d9e49%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/ea3009d7-09b9-4797-9087-3c012a0d9e49%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9WXcW4biKUXZYgJAUtNnnSC9GeXR5K33YhhjRgJd7EYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet web server stops after being started

[Rob Nelson]

You can check the logs of the puppetserver startup. A common reason is that
VMs have less RAM than the process expects to be allocated. You can either
increase the RAM or adjust the puppetserver settings to use less RAM, with
impact to the performance of course. See
https://docs.puppet.com/puppetserver/latest/install_from_packages.html#system-requirements
if that seems a likely cause.


Rob Nelson
rnels...@gmail.com

On Fri, Jul 29, 2016 at 12:18 PM, 'Michael Wildey' via Puppet Users <
puppet-users@googlegroups.com> wrote:

> I installed an puppetserver just like ist is written in the manual
> https://docs.puppet.com/puppet/4.5/reference/index.html on Debian Jessie.
>
> My Problem is that as soon as I want to get a cert for an agent it says
> that the puppetserver doesn't listen on Port 8140.
> Now I found out that the web server stops immediately after being started,
> but I don't know why.
>
> Any help is welcome.
>
> --
> 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/93e0e0e8-2b10-48ea-82c3-40fa8ec86d91%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/93e0e0e8-2b10-48ea-82c3-40fa8ec86d91%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9dK4XvaxHhzpgD5Lo-Eax2Mj7EFyaxZpHfE9d%2BT2M3_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetserver custom mount Error 400

[Rob Nelson]

Chet,

It looks like you have followed the directions at
https://docs.puppet.com/puppet/4.5/reference/file_serving.html, but it's
unclear if you checked the permissions of the path to make sure the puppet
user can read it. Also, I am guessing that you need to restart
puppetserver, though the page doesn't say one way or the other.

On Saturday, August 6, 2016, chetr via Puppet Users <
puppet-users@googlegroups.com> wrote:

> Hello all, I'm trying to get a custom mount point working and have been
> chasing my tail -- hoping someone has some fresh ideas to lend or sees
> something obvious I missed here?
> Thank you!!
> -chet
> 
> puppetserver 4.5.3 from puppet-collections-rc1
>
>
> *# custom mount point & file we are using for testing:*
> /home/admin/ops/configs/production/service/file.conf
>
>
> *# fileserverconfig = /etc/puppetlabs/puppet/fileserver.conf*
> [service]
> path /home/admin/ops/configs/production/service
> allow *
>
> *# the manifest:*
> node testnode01 {
> file { '/etc/service/file.conf':
> ensure => present,
> source => "puppet:///service/file.conf",
> }
> }
>
> *# on testnode01 run:*
> 'puppet agent -t --noop'
>
> *#the output:*
> Info: Using configured environment 'production'
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Info: Applying configuration version '1470528025'
> Error: /Stage[main]/Main/Node[testnode01]/File[/etc/service/file.conf]:
> Could not evaluate: Could not retrieve file metadata for
> puppet:///service/file.conf: Error 400 on SERVER: Not authorized to call
> find on /file_metadata/service/file.conf with
> {:rest=>"service/file.conf", :links=>"manage", :checksum_type=>"md5",
> :source_permissions=>"ignore"}
>
> *# /etc/puppetlabs/puppet/puppet.conf:*
> [main]
>   dns_alt_names = puppet, puppet.test.domain
>   rest_authconfig = /etc/puppetlabs/puppetserver/conf.d/auth.conf
>   log_level = debug
> [master]
>   vardir = /opt/puppetlabs/server/data/puppetserver
>   logdir = /var/log/puppetlabs/puppetserver
>   rundir = /var/run/puppetlabs/puppetserver
>   pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
>   codedir = /etc/puppetlabs/code
>   dns_alt_names = puppet, puppet.test.domain
>
> *# extra 'puppet config print' info*
> config_file_name = puppet.conf
> config = /etc/puppetlabs/puppet/puppet.conf
> rest_authconfig = /etc/puppetlabs/puppetserver/conf.d/auth.conf
> fileserverconfig = /etc/puppetlabs/puppet/fileserver.conf
>
> *# other configs*
> #/etc/puppetlabs/puppetserver/conf.d/puppetserver.conf: *(default)
> +use-legacy-auth-conf: false*
> #/etc/puppetlabs/puppetserver/conf.d/auth.conf: *(default)*
>
>
> *# puppetserver.log:*
> 2016-08-07 00:34:23,478 DEBUG [qtp327710486-24] [p.r.core] Processing :get
> /puppet/v3/file_metadata/service/file.conf
> 2016-08-07 00:34:23,483 DEBUG [qtp327710486-24] [puppetserver] Puppet
> Evaluating match for Route /^\/puppet\//
> 2016-08-07 00:34:23,483 DEBUG [qtp327710486-24] [puppetserver] Puppet
> Evaluating match for Route /v3/
> 2016-08-07 00:34:23,484 DEBUG [qtp327710486-24] [puppetserver] Puppet
> Evaluating match for Route /^\/environments$/
> 2016-08-07 00:34:23,484 DEBUG [qtp327710486-24] [puppetserver] Puppet Did
> not match path ("/file_metadata/service/file.conf")
> 2016-08-07 00:34:23,484 DEBUG [qtp327710486-24] [puppetserver] Puppet
> Evaluating match for Route /\/environment\/[^\/]+$/
> 2016-08-07 00:34:23,485 DEBUG [qtp327710486-24] [puppetserver] Puppet Did
> not match path ("/file_metadata/service/file.conf")
> 2016-08-07 00:34:23,485 DEBUG [qtp327710486-24] [puppetserver] Puppet
> Evaluating match for Route /.*/
> 2016-08-07 00:34:23,485 DEBUG [qtp327710486-24] [puppetserver] Puppet
> Evicting cache entry for environment 'production'
> 2016-08-07 00:34:23,486 DEBUG [qtp327710486-24]
> [p.s.j.puppet-environments] Removing environment 'production' from registry
> 2016-08-07 00:34:23,488 DEBUG [qtp327710486-24]
> [p.s.j.puppet-environments] Registering environment 'production'
> 2016-08-07 00:34:23,488 DEBUG [qtp327710486-24] [puppetserver] Puppet
> Caching environment 'production' (ttl = 0 sec)
> 2016-08-07 00:34:23,501 ERROR [qtp327710486-24] [puppetserver] Puppet Not
> authorized to call find on /file_metadata/service/file.conf with
> {:rest=>"service/file.conf", :links=>"manage", :checksum_type=>"md5",
> :source_permissions=>"ignore"}
>
> --
> You received this message because you are subscribed to the Goog

Re: [Puppet Users] Re: Service entry for puppet agents not working

[Rob Nelson]

On Mon, Aug 8, 2016 at 11:09 AM, Bret Wortman  wrote:

> Yep, it's not finding the pidfile because the init script is looking in
> /var/run/puppet/agent.pid and the daemon is putting it at
> /var/lib/puppet/run/agent.pid. So for now I'm going to modify the init
> script wherever we are having this problem.


We saw this issue when we performed an upgrade and the puppet.conf file's
rundir was different than where the services file was looking for the .pid
file. The recommendation was to remove the rundir setting from puppet.conf,
as the default location was the same as what the service file expected,
rather than to hardcode it to the correct value, in case it changed in the
future.


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

Re: [Puppet Users] exec not working in manifest with powershell commmand

[Rob Nelson]

Can you share the logs from your puppet run showing the error(s) received?

Also, you may want to look at the module https://forge.puppet.com/puppet/iis,
which may either handle this already, or be a good example of code you can
build on if the feature is not present.


Rob Nelson
rnels...@gmail.com

On Tue, Aug 9, 2016 at 8:53 AM, David Yeo  wrote:

> All,
>
> I have a requirement for automating the setup of IIS through puppet
> enterprise, I have a manifest which is not fully executing a powershell
> command utilising 'exec' (see below)
>
>
>
>
> *exec { 'SetvirtualDirectoryDefaultsuserName':  command =>
> '$(Set-ItemProperty -Path "IIS:\Sites\MainWebSite" -Name
> virtualDirectoryDefaults.userName -Value domain\username)',  provider =>
> powershell, }*
>
> the powershell command works perfectly if run direct from a powershell
> console
>
> Where am I going wrong?
>
> 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/3923f695-665e-47ff-8029-b591ffb6dbc7%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/3923f695-665e-47ff-8029-b591ffb6dbc7%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-QV2gsNR_rVEp1U5Ev6ZPks36BcD2B7nX_GiJ96ocHBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Service entry for puppet agents not working

[Rob Nelson]

On Tue, Aug 9, 2016 at 8:51 AM, Bret Wortman  wrote:

> What I failed to mention before is that the failure scenario is that I'll
> get a "Could not evaluate: Could not retrieve file metadata for
> puppet:///modules/ourlib/pip.conf: end of file reached"
>

Maybe try adding something like "/usr/bin/ruby/usr/bin/puppet config print
modulepath > /root/puppet.debug" to cron and compare it with the results
you get when you run that interactively. It's possible that there's some
difference due to the cron environment, which I always find tricky to
debug, but I think it's best to determine if it's an issue at all before
banging your head against that wall. Just grasping at straws here,
admittedly.


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

Re: [Puppet Users] managing vmware-tools with puppet

[Rob Nelson]

This. open-vm-tools upgrades seamlessly if you upgrade your kernel, the
official tools do not. They are only recommended when open-vm-tools is not
available.https://kb.vmware.com/kb/2073803 under VMware Support Policy. I
mention this because the official tools will be present, but not synced
with the new kernel version, so won't be considered Running by vSphere,
even though the processes themselves are running in the Guest OS, which is
impossible to ascertain from inside the Guest OS. That's best discovered
through any one of the vSphere APIs (like PowerCLI) and then use other
tools/actions to remediate your findings, like VUM.


Rob Nelson
rnels...@gmail.com

On Thu, Aug 11, 2016 at 7:00 AM, Dan White  wrote:

> Did you know that VMWare encourages the use of the open-vm-tools ?
> You might want to reconsider.
>
> Dan White | d_e_wh...@icloud.com
> 
> “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)
>
>
> On Aug 11, 2016, at 01:21 AM, Alex Samad  wrote:
>
> HI
>
> Yes went to puppet forge first, but .. the vmtools module use the
> opensource vmtools package, which I could use, but we have decided to
> stick with the office install from vmware. and I don't see one of
> those anywhere.
>
> Thanks
>
> Alex
>
> On 11 August 2016 at 14:12, Nick Cammorato 
> wrote:
>
> So setting aside if this is a good idea or not, you can do this in a
>
> single exec resource. Look at
>
> https://docs.puppet.com/puppet/latest/reference/types/exec.html
>
>
> Pay particular attention to onlyif, refreshonly, unless, and creates.
>
> Used either alone or in concert with the file resource type
>
> (https://docs.puppet.com/puppet/4.6/reference/types/
> file.html#file-attribute-source),
>
> you can set up something roughly like:
>
> file { 'somepath/vmtools.tar.gz': source =>
>
> 'http://somesite/vmtools.tar.gz', notify => exec['vmtoolsinst'] } ->
>
> exec { 'vmtoolsinst': command => 'stuffs', refreshonly => true }
>
>
> which will download the file then run a command on it if it had to
>
> download the file. You could also chain execs ala:
>
> exec { 'curl -o somepath http://somesite/vmtoolsd': onlyif =>
>
> 'shell eval of vmware-toolbox-cmd -v output', notify => vmtoolsinst }
>
> exec { 'vmtoolsinst': command => 'stuffs', refreshonly => true }
>
>
> Now going beyond that, you could add in a custom fact to capture the
>
> value of vmware-toolbox-cmd. This would look something like:
>
> Facter.add('vmtools-toolbox-cmd') do
>
> setcode do
>
> Facter::Core::Execution.exec(' vmware-toolbox-cmd -v')
>
> end
>
> end
>
>
> You would then be able to do logic based off this fact.
>
>
> Really though, you should just use the forge - there's a puppet
>
> approved module for vmtools:
>
> https://forge.puppet.com/razorsedge/vmwaretools
>
>
> HTH,
>
> --Nick
>
>
> On Wed, Aug 10, 2016 at 11:45 PM, Alex Samad  wrote:
>
> Hi
>
>
> so I have a repo of vmware-tools.*.tgz files located at a website.
>
>
> how do I build a module to check
>
> 1) is vmware tool install - check does vmware-toolbox-cmd exist
>
> 2) is it the right version - check for current version is
> vmware-toolbox-cmd
>
> -v
>
>
> I want to add version number into my hiera DB. think i have worked out. but
>
> not sure how to do the client test.
>
>
> I am guessing (psydo code)
>
>
> if exist vmware-toolbox-cmd and if vmware-toolbox-cmd -v >= 
> wanted>
>
> then
>
> do nothing
>
> else
>
> wget file
>
> run vmware-install
>
> fi
>
>
>
>
> --
>
> 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/7e990f42-
> 22b6-4aff-8887-83768e086cb8%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
>
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
>
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/puppet-users/zjoK2eEPhDg/unsubscribe.
>
> To unsubscribe

Re: [Puppet Users] managing vmware-tools with puppet

[Rob Nelson]

Sorry for the confusion. Take 2 :)

Open VM tools: just work
Official VM tools: work after install, but sometimes not after an upgraded
kernel, and are difficult to identify and remediate.

Use the Open version, every time!

On Thursday, August 11, 2016, Dan White  wrote:

> Your response is confusing, Rob.
>
> The process I have been using lately is to uninstall the VMWare-provided
> tools completely, then install OVT.
> It shows up in vSphere
>
> Dan White | d_e_wh...@icloud.com 
> 
> 
> “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)
>
>
> On Aug 11, 2016, at 08:03 AM, Rob Nelson  > wrote:
>
> This. open-vm-tools upgrades seamlessly if you upgrade your kernel, the
> official tools do not. They are only recommended when open-vm-tools is not
> available.https://kb.vmware.com/kb/2073803 under VMware Support Policy. I
> mention this because the official tools will be present, but not synced
> with the new kernel version, so won't be considered Running by vSphere,
> even though the processes themselves are running in the Guest OS, which is
> impossible to ascertain from inside the Guest OS. That's best discovered
> through any one of the vSphere APIs (like PowerCLI) and then use other
> tools/actions to remediate your findings, like VUM.
>
>
> Rob Nelson
> rnels...@gmail.com 
>
> On Thu, Aug 11, 2016 at 7:00 AM, Dan White  > wrote:
>
>> Did you know that VMWare encourages the use of the open-vm-tools ?
>> You might want to reconsider.
>>
>> Dan White | d_e_wh...@icloud.com 
>> 
>> 
>> “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)
>>
>>
>> On Aug 11, 2016, at 01:21 AM, Alex Samad > > wrote:
>>
>> HI
>>
>> Yes went to puppet forge first, but .. the vmtools module use the
>> opensource vmtools package, which I could use, but we have decided to
>> stick with the office install from vmware. and I don't see one of
>> those anywhere.
>>
>> Thanks
>>
>> Alex
>>
>> On 11 August 2016 at 14:12, Nick Cammorato > > wrote:
>>
>> So setting aside if this is a good idea or not, you can do this in a
>>
>> single exec resource. Look at
>>
>> https://docs.puppet.com/puppet/latest/reference/types/exec.html
>>
>>
>> Pay particular attention to onlyif, refreshonly, unless, and creates.
>>
>> Used either alone or in concert with the file resource type
>>
>> (https://docs.puppet.com/puppet/4.6/reference/types/file.
>> html#file-attribute-source),
>>
>> you can set up something roughly like:
>>
>> file { 'somepath/vmtools.tar.gz': source =>
>>
>> 'http://somesite/vmtools.tar.gz', notify => exec['vmtoolsinst'] } ->
>>
>> exec { 'vmtoolsinst': command => 'stuffs', refreshonly => true }
>>
>>
>> which will download the file then run a command on it if it had to
>>
>> download the file. You could also chain execs ala:
>>
>> exec { 'curl -o somepath http://somesite/vmtoolsd': onlyif =>
>>
>> 'shell eval of vmware-toolbox-cmd -v output', notify => vmtoolsinst }
>>
>> exec { 'vmtoolsinst': command => 'stuffs', refreshonly => true }
>>
>>
>> Now going beyond that, you could add in a custom fact to capture the
>>
>> value of vmware-toolbox-cmd. This would look something like:
>>
>> Facter.add('vmtools-toolbox-cmd') do
>>
>> setcode do
>>
>> Facter::Core::Execution.exec(' vmware-toolbox-cmd -v')
>>
>> end
>>
>> end
>>
>>
>> You would then be able to do logic based off this fact.
>>
>>
>> Really though, you should just use the forge - there's a puppet
>>
>> approved module for vmtools:
>>
>> https://forge.puppet.com/razorsedge/vmwaretools
>>
>>
>> HTH,
>>
>> --Nick
>>
>>
>> On Wed, Aug 10, 2016 at 11:45 PM, Alex Samad > > wrote:
>>
>> Hi
>>
>>
>> so I have a repo of vmware-tools.*.tgz files located at a website.
>>
>>
>> how do I build a module to check
>>
>> 1) is vmware tool install - check does vmware-toolbox-cmd ex

Re: [Puppet Users] managing vmware-tools with puppet

[Rob Nelson]

There's nothing wrong with them being 3rd party, it's just cannot tell if
those are the latest version available for the guest OS.

On Thursday, August 11, 2016, Alex Samad  wrote:

> Hi
>
> Thanks, very interesting, I had recently been testing with them. But
> they show up in VC as 3rd party... I will check out the KB.
>
>
> Thanks
> Alex
>
> On 11 August 2016 at 22:03, Rob Nelson >
> wrote:
> > This. open-vm-tools upgrades seamlessly if you upgrade your kernel, the
> > official tools do not. They are only recommended when open-vm-tools is
> not
> > available.https://kb.vmware.com/kb/2073803 under VMware Support Policy.
> I
> > mention this because the official tools will be present, but not synced
> with
> > the new kernel version, so won't be considered Running by vSphere, even
> > though the processes themselves are running in the Guest OS, which is
> > impossible to ascertain from inside the Guest OS. That's best discovered
> > through any one of the vSphere APIs (like PowerCLI) and then use other
> > tools/actions to remediate your findings, like VUM.
> >
> >
> > Rob Nelson
> > rnels...@gmail.com 
> >
> > On Thu, Aug 11, 2016 at 7:00 AM, Dan White  > wrote:
> >>
> >> Did you know that VMWare encourages the use of the open-vm-tools ?
> >> You might want to reconsider.
> >>
> >> Dan White | d_e_wh...@icloud.com 
> >> 
> >> “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)
> >>
> >>
> >> On Aug 11, 2016, at 01:21 AM, Alex Samad  > wrote:
> >>
> >> HI
> >>
> >> Yes went to puppet forge first, but .. the vmtools module use the
> >> opensource vmtools package, which I could use, but we have decided to
> >> stick with the office install from vmware. and I don't see one of
> >> those anywhere.
> >>
> >> Thanks
> >>
> >> Alex
> >>
> >> On 11 August 2016 at 14:12, Nick Cammorato  >
> >> wrote:
> >>
> >> So setting aside if this is a good idea or not, you can do this in a
> >>
> >> single exec resource. Look at
> >>
> >> https://docs.puppet.com/puppet/latest/reference/types/exec.html
> >>
> >>
> >> Pay particular attention to onlyif, refreshonly, unless, and creates.
> >>
> >> Used either alone or in concert with the file resource type
> >>
> >>
> >> (https://docs.puppet.com/puppet/4.6/reference/types/
> file.html#file-attribute-source),
> >>
> >> you can set up something roughly like:
> >>
> >> file { 'somepath/vmtools.tar.gz': source =>
> >>
> >> 'http://somesite/vmtools.tar.gz', notify => exec['vmtoolsinst'] } ->
> >>
> >> exec { 'vmtoolsinst': command => 'stuffs', refreshonly => true }
> >>
> >>
> >> which will download the file then run a command on it if it had to
> >>
> >> download the file. You could also chain execs ala:
> >>
> >> exec { 'curl -o somepath http://somesite/vmtoolsd': onlyif =>
> >>
> >> 'shell eval of vmware-toolbox-cmd -v output', notify => vmtoolsinst }
> >>
> >> exec { 'vmtoolsinst': command => 'stuffs', refreshonly => true }
> >>
> >>
> >> Now going beyond that, you could add in a custom fact to capture the
> >>
> >> value of vmware-toolbox-cmd. This would look something like:
> >>
> >> Facter.add('vmtools-toolbox-cmd') do
> >>
> >> setcode do
> >>
> >> Facter::Core::Execution.exec(' vmware-toolbox-cmd -v')
> >>
> >> end
> >>
> >> end
> >>
> >>
> >> You would then be able to do logic based off this fact.
> >>
> >>
> >> Really though, you should just use the forge - there's a puppet
> >>
> >> approved module for vmtools:
> >>
> >> https://forge.puppet.com/razorsedge/vmwaretools
> >>
> >>
> >> HTH,
> >>
> >> --Nick
> >>
> >>
> >> On Wed, Aug 10, 2016 at 11:45 PM, Alex Samad  > wrote:
> >>
> >> Hi
> >>
> >>
> >> so I have a repo of vm

Re: [Puppet Users] module design: different module sections manipulating files in single directory

[Rob Nelson]

Doubt,

I agree with Dan, packaging is the answer. And before you say it - yes,
packaging sounds scary at first, but it doesn't have to be. Check out FPM -
https://github.com/jordansissel/fpm/wiki - to generate a package in the
correct format. You can very easily package static files that way, and use
file resources with `source => template(...)` for any dynamic files
required.

Hosting the files is pretty easy if you're using yum, as yumrepos are built
in. You can host them on a node with profile::yumrepo (
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/yumrepo.pp
and
https://github.com/puppetinabox/controlrepo/blob/production/hiera/puppet_role/yumrepo.yaml),
throw the rpms in /var/www/html/puppetrepo/el7, and then ensure your base
profile distributes that repo (
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/base.pp#L29-L38).
That code is dated and needs a little improvement (stop using
`create_resources()`!) but should get you started quickly. I'm sure there's
an equivalent for Apt.


Rob Nelson
rnels...@gmail.com

On Mon, Aug 15, 2016 at 4:19 PM, Dan Mahoney  wrote:

> On Mon, 15 Aug 2016, dkoleary wrote:
>
> Hey;
>> I suspected this was going to be a problem and, sure enough, it is.
>>
>> Here's the scenario:  puppet server 4.5:  I have ~ 1200 hosts on which I
>> want specific files in /root/bin on all hosts.  A reasonably large subset
>> of
>> those should have additional files in /root/bin as part of an home-grown
>> application management process.  To be clear, none of the files from the
>> 'all-host' group overlap with any of the files from the 'some-hosts'
>> group.
>>
>> The all-host group is easy enough::
>>
>>   file { '/root/bin':
>> ensure  => 'directory',
>> owner   => 'root',
>> group   => 'root',
>> mode=> '0700',
>> recurse => true,
>> source  => 'puppet:///modules/myroot/rootbin',
>> require => File['/root'],
>>   }
>>
>> So, that's worked for weeks now.  In my company's slow migration to puppet
>> management, I'm finally to the point of adding some custom application
>> related files to /root/bin.  On the surface, the some-hosts group is
>> pretty
>> easy too::
>>
>> file { 'webconfbin':
>>   ensure  => 'directory',
>>   path=> '/root/bin',
>>   owner   => 'root',
>>   group   => 'root',
>>   mode=> '0700',
>>   recurse => true,
>>   source  => 'puppet:///modules/myroot/webconf',
>> }
>>
>> As I suspected, that resulted in the bright red error message about
>> 'resource /root/bin already declared'.  The two options that I can think
>> of
>> aren't particularly appetizing:
>>
>> 1.  Add the files from some-hosts to all-hosts resulting in the app
>> management files being everywhere.  These files, themselves, don't
>> represent
>> a security issue, but it's not a very clean approach.
>>
>> 2.  Use individual file resources.  I could get away with that approach on
>> this one; but, when I run into a similar issue with dozens or 100s of
>> files,
>> I'd hate to be specifying all those file resources.
>>
>> Realizing I probably took a wrong turn in my initial design and figuring
>> someone else has to have had run into this problem before, I'm asking the
>> experts.  What's the right way to have a set of files on all hosts and a
>> different set of files on a subset of all hosts in the same directory?
>>
>
> I don't often comment on the puppet stuff, but yours made me need to chime
> in and say this:
>
> Recurse is an ugly, awful, terrible hack and should be deprecated.
>
> I don't say that with any knowledge of the way it evolved or what its
> future support status is, but if you look at it -- it's effectively an
> expansion macro that turns into dozens or hundreds of File[] resources (and
> interally -- can and MUST grow your manifest internally in-memory to that
> size).
>
> Judging by the fact that you're using a /bin directory to distribute
> things, which I assume are binaries, or scripts, the thing that makes sense
> here (especially with 1200 hosts) is to look in to using your OS's package
> manager to accomplish this task -- where you could, possibly, break out the
> installables by host-class.  (i.e. the files in yoursite-db.rp

Re: [Puppet Users] Can I include hieradata in my puppet repo?

[Rob Nelson]

Including hieradata in your controlrepo is a common practice recommended
now by Puppet. See
http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/
for an explanation of why and https://github.com/puppetlabs/control-repo
for an example layout.


Rob Nelson
rnels...@gmail.com

On Tue, Aug 16, 2016 at 2:28 AM, Pubudu Gunatilaka 
wrote:

> Hi,
>
> I am using hieradata with puppet modules. Can I include hieradata in my
> puppet module repository? I can use a .pmtignore file and
> exclude hieradata from bundling to the puppet module. What is the best
>  practise?
>
> Thank you!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/27101f30-4195-422e-9059-a7e86112a994%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/27101f30-4195-422e-9059-a7e86112a994%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-DgXdpOj_8afDnE4LgzVYQCMwt%2BHPMLZWKdaYuW9CBsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet control, Hiera data, puppetfile, and r10k and git merging woes

[Rob Nelson]

Mike, is there a reason that Puppetfile changes and hiera changes are being
made in sync, when they aren't tied to each other? Perhaps those Puppetfile
changes that are not ready to be merged should be in a branch called
'experimental' (or even a more-persistent-than-normal feature branch) and
only merged to 'dev' when it's time to start promoting the code. You've
probably already thought of that, but throwing it out there just in case.

On Thursday, August 18, 2016, Mike Sharpton  wrote:

> Thanks for your reply.  We based our initial design on shit Gary says.
> This may be our only option as you say, to have hiera data changes made to
> each static branch/puppet environment by hand and not merge.  We need the
> static branches for separation of Puppet environments.  Problem with this
> approach is humans will make errors between each branch sometimes or
> always.  The branches/environments will eventually become snow flakes over
> time as far as Hieradata.  Perhaps we can possibly merge them weekly to
> lower this risk.  Assuming no code changes are in flight, which there most
> likely always will be.  The search continues. Thanks again,
>
> Mike
>
>
>
> On Wednesday, August 17, 2016 at 3:52:31 PM UTC-5, Christopher Wood wrote:
>>
>> It sounds like these might help:
>>
>> https://puppet.com/blog/git-workflows-puppet-and-r10k
>>
>> http://garylarizza.com/blog/categories/r10k/
>>
>> Seems like you would benefit from having all teams work from branches of
>> current production and merge back, rather than maintaining a semi-permanent
>> dev branch shared by everybody. This is usually where I suggest that people
>> review commits and talk to each other and figure out what's good, but
>> sometimes that's like pulling teeth.
>>
>>
>>
>> On Wed, Aug 17, 2016 at 01:21:45PM -0700, Mike Sharpton wrote:
>> >Hey all,
>> >We are coming up on an issue in our environment in where we have
>> multiple
>> >Puppet environments that are backed by git branches in a puppet
>> control
>> >repo.  Our Hiera data is stored inside these branches and changed
>> >frequently by our Operations teams.  Of which we then have them
>> merge
>> >changes up the environment chain and r10k through our Puppet
>> environments.
>> > This is all fine.
>> >Ex, dev -> test -> production, hiera data changes are moved up and
>> tested
>> >each step of the way.
>> >When things aren't fine is when we are testing code in our dev or
>> test
>> >branch and we have changed the tags for modules/repos inside the
>> >Puppetfile of those branches that we don't want in production right
>> away
>> >(dev/test).  This code only applies to dev environment, on purpose.
>>
>> >Our operations team then comes along with their hiera changes and
>> merges
>> >the puppetfile module/repo changes up the chain along with the hiera
>> data.
>> > Effectively moving our Puppetfile changes up the chain when we
>> don't want
>> >to.  We have thought about splitting hiera data out our puppet
>> control
>> >module like it was before Puppet 4, but this leaves us no room to
>> test
>> >hiera data up our environment chain and also leaves us with some CI
>> work
>> >to make this feasible.  Having the hieradata in each environment is
>> too
>> >nice.  We also attempted to monkey with .gitignore, but this is not
>> meant
>> >to do what we are trying to do.  Don't merge Puppetfile unless I
>> want to.
>> >Has anyone ran into this and found a somewhat elegant solution?
>> > Everything we are coming up with is either not easy to manage, or
>> just
>> >doesn't make sense to do.  Perhaps we are missing something simple
>> and are
>> >over thinking things.  Thanks in advance.
>> >Mike
>> >
>> >--
>> >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...@googlegroups.com.
>> >To view this discussion on the web visit
>> >[2]https://groups.google.com/d/msgid/puppet-users/9d9e18a4-
>> a6e4-4d04-b0b3-377b848a8504%40googlegroups.com.
>> >    For more options, visit [3]https://groups.google.com/d/optout.
>> >
>>
>>

Re: [Puppet Users] Puppet control, Hiera data, puppetfile, and r10k and git merging woes

[Rob Nelson]

The term 'environment' is overloaded. In the context of puppet, I prefer to
think of it as "a set of puppet code/data representing a branch of the
controlrepo' (puppet environment), rather than 'an environment that nodes
run in' (dev/qa/prod/etc) (node environment). Since you can make the latter
part of your hiera hierarchy, the only puppet environment that needs to
live forever is 'production'. Inside it, the hieradata has ALL the data for
all of the node environments, so they actually all check into 'production'.
The hierarchy value for the node environment can be a custom fact,
calculated or a file on disk, so nodes can get the right node environment
data from the puppet environment 'production'.

:hierarchy:
  - "nodes/%{::trusted.certname}"
  - "node_env/%{node_env}"
  - "common"

By differenting the various uses of the overloaded term 'environment' a
bit, you can actually streamline your workflow quite a bit. Now all your
data is in one place. When you create a feature branch for testing, you can
then point the canary nodes to that branch (`puppet agent -t --environment
ticket1234`, or putting `environment = ticket1234` in puppet.conf). Whether
you're changing roles and profiles, hiera data, or the Puppetfile, it's
contained in that branch, but you can actually have production, dev, qa
nodes check into it and get the new results, so you aren't surprised when a
Puppetfile change in dev trickles up to prod and suddenly things blow up.
Of course, you need to have some canary nodes in each node environment (or
place a LOT of trust in --noop mode) to get there, but I think that's a
reasonable goal to work toward.



Aside: I know we have discussed workflows and the various types of
environments on this list quite a bit this Spring/Summer. Does anyone have
a good reference article for this already, or do we need to come up with
one? I think this is an important gap to fill.


Rob Nelson
rnels...@gmail.com

On Thu, Aug 18, 2016 at 12:07 PM, Mike Sharpton  wrote:

> The static branches are basically Puppet environments in which nodes are
> bound/pointed to them in their puppet.conf.  This way we can open CR's per
> set of nodes and move up the chain.  Also, I may have found another option
> on Gary's site.  We could r10k our hiera data and split it from our control
> repo.  More to come.  Thanks again for thoughts.
>
>
> On Thursday, August 18, 2016 at 10:00:01 AM UTC-5, Christopher Wood wrote:
>
>> I'm missing why you need static branches. I'm picturing something more
>> like:
>>
>> git checkout production
>> git checkout -b ticket1234
>> # make changes, commit, push, test, repeat
>> git merge production # catch up on any prod changes, retest
>> git tag ticket.1234
>> git checkout production
>> git merge ticket1234
>> git branch -d ticket1234
>>
>> That way everybody's changes are working pretty close to what production
>> is right now.
>>
>> The alternatives are curating your branches, periodically re-branching
>> from production, or just accepting the current state, as near as I can tell
>> off the cuff. If you want to maintain something it requires maintenance
>> work no matter the tool you pick.
>>
>>
>> On Thu, Aug 18, 2016 at 05:27:40AM -0700, Mike Sharpton wrote:
>> >Thanks for your reply.  We based our initial design on shit Gary
>> says.
>> > This may be our only option as you say, to have hiera data changes
>> made
>> >to each static branch/puppet environment by hand and not merge.  We
>> need
>> >the static branches for separation of Puppet environments.  Problem
>> with
>> >this approach is humans will make errors between each branch
>> sometimes or
>> >always.  The branches/environments will eventually become snow
>> flakes over
>> >time as far as Hieradata.  Perhaps we can possibly merge them weekly
>> to
>> >lower this risk.  Assuming no code changes are in flight, which
>> there most
>> >likely always will be.  The search continues. Thanks again,
>> >Mike
>> >
>> >On Wednesday, August 17, 2016 at 3:52:31 PM UTC-5, Christopher Wood
>> wrote:
>> >
>> >  It sounds like these might help:
>> >
>> >  [1]https://puppet.com/blog/git-workflows-puppet-and-r10k
>> >
>> >  [2]http://garylarizza.com/blog/categories/r10k/
>> >
>> >  Seems like you would benefit from having all teams work from
>> branches of
>> >  current production and merge back, rather than maintaining a
>> >  semi-

[Puppet Users] puppet-lint 2.0.1 is released

[Rob Nelson]

All,

I'm happy to announce that puppet-lint 2.0.1 has been released today.
Please checkout the changelog below for details. Please open a ticket on
the project if you discover any issues with it.

This is the second release of puppet-lint this year and we hope to keep the
pace up in the coming months. Thank you for all your contributions to it
over the years!

https://rubygems.org/gems/puppet-lint
https://github.com/rodjek/puppet-lint/blob/master/CHANGELOG.md

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

Re: [Puppet Users] Puppet control, Hiera data, puppetfile, and r10k and git merging woes

[Rob Nelson]

The number of branches you have has almost nothing to do with how fast your
nodes converge to a new desired state. If you want them to check in on
command, use mcollective or another orchestration engine to make that
happen.

On Thursday, August 18, 2016, Alex Samad  wrote:

> Hi
>
> I have recently gone through this problem.
>
> I had initial thought to you different branches for the different
> environments.
> say
> prod
> uat
> sim
> inf
> dev
>
> But was advised best to go with production and testing.
>
>
> so I have and I have used a grouping in my ENC to put machines into the
> above groups. But I am about ready to go back to more branches again.  Why
>
> I have setup my profiles
>
> my_ssh profile this handles all the general setup of ssh server and client
> - standard across all machines
>
>
> so my roles just include profile::my_ssh
>
> My issue with this is if I want to now role out a change to my ssh setup I
> can't isolate which box gets its, pot luck, wait long enough and they all
> get it.
>
> I am not sure its the best to go to each dev/uat machine and run puppet
> --environment  is the best solution plus my ENC sets the
> environment ..  don't want pesky dev guys change environments on me.
>
> I don't want to have to create a new profile and attach it to the roles I
> want to test on.
>
> So I am thinking ... multiple branches is sounding good.
>
> But im keen to see what comes out of this.
>
>
> On Friday, 19 August 2016 02:24:58 UTC+10, Rob Nelson wrote:
>>
>> The term 'environment' is overloaded. In the context of puppet, I prefer
>> to think of it as "a set of puppet code/data representing a branch of the
>> controlrepo' (puppet environment), rather than 'an environment that nodes
>> run in' (dev/qa/prod/etc) (node environment). Since you can make the latter
>> part of your hiera hierarchy, the only puppet environment that needs to
>> live forever is 'production'. Inside it, the hieradata has ALL the data for
>> all of the node environments, so they actually all check into 'production'.
>> The hierarchy value for the node environment can be a custom fact,
>> calculated or a file on disk, so nodes can get the right node environment
>> data from the puppet environment 'production'.
>>
>> :hierarchy:
>>   - "nodes/%{::trusted.certname}"
>>   - "node_env/%{node_env}"
>>   - "common"
>>
>> By differenting the various uses of the overloaded term 'environment' a
>> bit, you can actually streamline your workflow quite a bit. Now all your
>> data is in one place. When you create a feature branch for testing, you can
>> then point the canary nodes to that branch (`puppet agent -t --environment
>> ticket1234`, or putting `environment = ticket1234` in puppet.conf). Whether
>> you're changing roles and profiles, hiera data, or the Puppetfile, it's
>> contained in that branch, but you can actually have production, dev, qa
>> nodes check into it and get the new results, so you aren't surprised when a
>> Puppetfile change in dev trickles up to prod and suddenly things blow up.
>> Of course, you need to have some canary nodes in each node environment (or
>> place a LOT of trust in --noop mode) to get there, but I think that's a
>> reasonable goal to work toward.
>>
>>
>>
>> Aside: I know we have discussed workflows and the various types of
>> environments on this list quite a bit this Spring/Summer. Does anyone have
>> a good reference article for this already, or do we need to come up with
>> one? I think this is an important gap to fill.
>>
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>> On Thu, Aug 18, 2016 at 12:07 PM, Mike Sharpton 
>> wrote:
>>
>>> The static branches are basically Puppet environments in which nodes are
>>> bound/pointed to them in their puppet.conf.  This way we can open CR's per
>>> set of nodes and move up the chain.  Also, I may have found another option
>>> on Gary's site.  We could r10k our hiera data and split it from our control
>>> repo.  More to come.  Thanks again for thoughts.
>>>
>>>
>>> On Thursday, August 18, 2016 at 10:00:01 AM UTC-5, Christopher Wood
>>> wrote:
>>>
>>>> I'm missing why you need static branches. I'm picturing something more
>>>> like:
>>>>
>>>> git checkout production
>>>> git checkout -b ticket1234
>>>> # make changes, commit, push, test, repeat
>

Re: [Puppet Users] puppet-lint 2.0.1 is released

[Rob Nelson]

Ramin,

No worries, it's a legitimate complaint. Puppet-lint 2.0.2 was just
released which reverted that issue. We're back to the original problem in
#504 but it's not worse than it was in 2.0.0 at least.


Rob Nelson
rnels...@gmail.com

On Thu, Aug 18, 2016 at 9:56 PM, Ramin K  wrote:

> On 8/18/16 9:35 AM, Rob Nelson wrote:
>
>> All,
>>
>> I'm happy to announce that puppet-lint 2.0.1 has been released today.
>> Please checkout the changelog below for details. Please open a ticket on
>> the project if you discover any issues with it.
>>
>> This is the second release of puppet-lint this year and we hope to keep
>> the pace up in the coming months. Thank you for all your contributions
>> to it over the years!
>>
>> https://rubygems.org/gems/puppet-lint
>> https://github.com/rodjek/puppet-lint/blob/master/CHANGELOG.md
>>
>
> I hate to be that person, but if you use puppet-lint for pre/post commit
> hooks I'd recommend staying on 2.0.0 till https://github.com/rodjek/pupp
> et-lint/issues/504 is resolved.
>
> Ramin
>
> --
> 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/ms
> gid/puppet-users/7639d826-628f-7743-4141-f8b6dd15cdc1%40badapple.net.
> 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/CAC76iT9xYDnaC7e957KMusvWZKJNn09XVf3vjd6YLnhSgM98Sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet control, Hiera data, puppetfile, and r10k and git merging woes

[Rob Nelson]

I think there are so many ways to do A/B deployments that it's probably not
wise to codify that into your Puppet environments layout. Here's a few
examples of how:

* Use DNS/Load Balancer rules/etc to control which puppet masters different
agents connect to. Some of the masters have a different default
environment, to force some percentage of nodes to run against your feature
branch and receive the correct environment. After the feature is merged
into production, those masters default back to the `production` environment.
* Your ENC provides the puppet environment to check into, forcing some
percentage of nodes to receive the `feature` environment, and later to
return to the `production` environment.
* Use any orchestration solution (mcollective, ansible, vRO, etc) to
configure agents to check in against the `feature` environment, and later
to return to the `production` environment.
* Manually check in canary nodes against the `feature` environment, and
later to return to the `production` environment.

That's just a sampling of methods in no particular order (although I think
we can all agree that the manual option is the least appealing) but is by
no means comprehensive. However, all of these methods let you do A/B
testing between production and a specific feature branch, rather than
against a long lived and divergent branch than production which may have
numerous changes that cause interaction in unexpected ways, which certainly
tests a lot more but makes it more difficult for diagnosing where failures
come from. Having your feature branches diverge from `production`, your
single source of truth, greatly limits the number of variables in play at
any given time and streamlines your pipeline.

I would recommend a book on Continuous Integration and/or Continuous
Delivery as these are subjects far too deep and wide to properly cover here
in the detail they require.


Rob Nelson
rnels...@gmail.com

On Sun, Aug 21, 2016 at 11:20 PM, Alex Samad  wrote:

> On 21 August 2016 at 11:04, Chadwick Banning 
> wrote:
> > As Rob Nelson mentioned above, you can differentiate between operational
> > environments in Hiera as long as you have the appropriate facts
> available.
> >
> > If you differentiate Puppet environments and operational environments,
> then
> > it's easier to address staged rollouts in each appropriate context.
> Staged
> > rollouts of changes across *operational* environments may be done through
> > Hiera, and staged rollouts of Puppet code (usually common Puppet code
> that
> > cuts across operational environments) can be done through *Puppet*
> > environments.
> >
> > If your environment is simple enough...such as a single app with dev,
> > staging, and production operational environments, then equating a Puppet
> > environment to an operational environment is that much of an issue. For
> more
> > complex Puppet setups, equating them always creates issues IMHO.
>
>
> Okay I get it you have another branch in hiera lets say env as you have
> above.
>
> But they pull in the same profile class - lets say openssh.
>
> So lets say ssh come out with v3, you want to slowly roll out.
>
> Do you have a bit if then or case switch statement in your ssh profile
> class or do you create a new ssh class call ssh-v3 and then assign it
> to only the env you want to.
>
> seems like every time you want to make a change to a profile/class you
> need to create another one so you can control the roll out or you have
> a big if/then or switch case to do that for you.
>
> trying to persist with the 2 branches production and testing for now ..
>
> >
> > This topic is really interesting to me since I've run into it multiple
> > times, the last being very recent.
> >
> > On Saturday, August 20, 2016 at 6:39:03 PM UTC-4, Alex Samad wrote:
> >>
> >> On 20 August 2016 at 22:50, Chadwick Banning 
> wrote:
> >> > This is an issue I run into pretty regularly. If your Puppet
> >> > infrastructure
> >> > is even moderately complex, I'd recommend NOT equating a Puppet
> >> > environment
> >> > to an operational environment, operational environment being the
> groups
> >> > of
> >> > machines known as dev, qa, staging, etc.
> >>
> >> But how to you stage a roll out of an update.  If you want it to go to
> >> dev then uat then prod ... or through some logical steps.
> >>
> >> presuming you have a common profile used by all.
> >>
> >> >
> >> > For instance, in my infrastructure we have 50+ different operational
> >> > environments. If I equate each one of these to a Puppet environment,
> I'd
> >> > need 5

Re: [Puppet Users] Re: Puppet control, Hiera data, puppetfile, and r10k and git merging woes

[Rob Nelson]

For canaries, we have some 'dev' versions of services, i.e. 'wiki' and
'wikidev'. Because of that, we can both leave the 'dev' versions on a
feature branch if we need to (or disable puppet entirely when we're down in
the nitty gritty and don't want puppet to undo development efforts) AND
have a tier in hiera where we can provide different values to the regular
and dev versions. We mostly rely on the hiera tier for data because then
there's less manual or even orchestration effort to test on those nodes,
except when we want a run immediately.


Rob Nelson
rnels...@gmail.com

On Mon, Aug 22, 2016 at 12:49 PM, Chadwick Banning <
chadwickbann...@gmail.com> wrote:

> Another potential management approach I'm exploring...
>
> Because of the complexity of my current situation, where we have multiple
> independent internal apps and each one of these has a more-or-less unique
> set of operational environments, AND we have common Puppet code that
> applies across everything, I'm looking into spinning off each app team into
> their own module and using the Puppet 4 data-in-modules to allow them to
> manage their own data/hierarchy. I'd then use the controlrepo as the
> integration point for these internal modules as well as the container for
> the common Puppet code.
>
> I'm just now exploring this idea so I'm not ready to say whether it's a
> good idea or not!
>
> I like the idea of doing A/B testing on feature branches off of
> production. In my situation, I'd have to have a pretty robust and visible
> way to test and report success/fail before the security team buys into it.
> Especially if this was automated such that canarys are moved to feature
> environment, test is performed, and on success feature is merged and
> canarys are moved back to production environment.
>
> On Mon, Aug 22, 2016 at 12:30 PM, Rich Burroughs 
> wrote:
>
>> I've managed a lot of configs for apps our developers build. At times
>> when config changes were not backwards compatible I built in the equivalent
>> of feature flags. I added a Boolean param that controlled if it was on or
>> off, and built logic into the ERB/EPP template that used it. Then I could
>> control the rollout by setting the value for that param in Hiera.
>>
>> Not my favorite thing to do but it worked :) And of course the bad part
>> about feature flags is remembering to clean them up when the rollout is
>> done.
>>
>> I'm really enjoying this discussion. I haven't done A/B or canary nodes
>> with Puppet and I think some of this stuff is hard to figure out if you
>> haven't seen it work.
>>
>>
>> Rich
>>
>> On Mon, Aug 22, 2016 at 7:06 AM Rob Nelson  wrote:
>>
>>> I think there are so many ways to do A/B deployments that it's probably
>>> not wise to codify that into your Puppet environments layout. Here's a few
>>> examples of how:
>>>
>>> * Use DNS/Load Balancer rules/etc to control which puppet masters
>>> different agents connect to. Some of the masters have a different default
>>> environment, to force some percentage of nodes to run against your feature
>>> branch and receive the correct environment. After the feature is merged
>>> into production, those masters default back to the `production` environment.
>>> * Your ENC provides the puppet environment to check into, forcing some
>>> percentage of nodes to receive the `feature` environment, and later to
>>> return to the `production` environment.
>>> * Use any orchestration solution (mcollective, ansible, vRO, etc) to
>>> configure agents to check in against the `feature` environment, and later
>>> to return to the `production` environment.
>>> * Manually check in canary nodes against the `feature` environment, and
>>> later to return to the `production` environment.
>>>
>>> That's just a sampling of methods in no particular order (although I
>>> think we can all agree that the manual option is the least appealing) but
>>> is by no means comprehensive. However, all of these methods let you do A/B
>>> testing between production and a specific feature branch, rather than
>>> against a long lived and divergent branch than production which may have
>>> numerous changes that cause interaction in unexpected ways, which certainly
>>> tests a lot more but makes it more difficult for diagnosing where failures
>>> come from. Having your feature branches diverge from `production`, your
>>> single source of truth, greatly limits the number of variables in play at
>>

Re: [Puppet Users] How to handle predictable network interface names

[Rob Nelson]

Marc,

We use VMware's vSphere, which still results in "random" but predictable
interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc.
We've stuck with that because while it's somewhat painful (eth# is soo
much easier to comprehend), it's far less painful to memorize that than to
maintain some udev rules that may need tweaked across time. However, if we
were on bare metal, it might be worth disabling the rules to get the older
style back. That's probably still less optimal than customized names, but
it's well documented at least. For example, http://carminebufano.com/?p=108
or
http://amolkg.blogspot.in/2015/05/centos-7-change-network-interface-name.html
- though there are multiple ways to do it even then.


Rob Nelson
rnels...@gmail.com

On Wed, Aug 24, 2016 at 9:55 AM, Marc Haber 
wrote:

> Hi,
>
> I would like to discuss how to handle systemd's new feature of
> predictable network interface names. This is a rather hot topic in the
> team I'm currently working in, and I'd like to solicit your opinions
> about that.
>
> On systems with more than one interface, the canonical way to handle
> this issue in the past was "assume that eth0 is connected to network
> foo, eth1 is connected to network bar, and eth2 is connected to
> network baz" and to accept that things fail horribly if the order in
> which network interfaces are detected changes.
>
> While upstream's focus is as usual on desktop machines where Ethernet,
> USB and WWAN interfaces come and go multiple times a day (see
> upstream's reasoning in
> https://www.freedesktop.org/wiki/Software/systemd/
> PredictableNetworkInterfaceNames/),
> this seldomly happens in our happy server environment, which reduces
> the breakage potential to disruptive kernel updates or vendor firmware
> changes peddling with the order in which network interfaces are
> enumerated.
>
> This happens rather seldomly in my experience.
>
> I would, however, like to stay with the new scheme since I see its
> charms.
>
> But, how would I handle this in a puppetized environment?
>
> Currently, the code that is already, for example for a firewall
> assumes that eth0 is the external interface, eth1 the internal one and
> eth2 the perimeter networks.
>
> In the new setup, all those interfaces can have different names
> depending on different hardware being used. That means that the same
> puppet code cannot be used on one firewall instance running on Dell
> hardware and a second one running on HP hardware because BIOS indices
> and/or PCI paths will vary. If I used the MAC scheme, things are even
> worse since interface names will be different even on different pieces
> of otherwise identical hardware.
>
> Many of my team members thinkt hat one should simply turn of
> predictable network interface names altgether and so that our old code
> continues to work. I think that this would be a bad idea, but don't
> have any logical arguments other than my gut feeling.
>
> Generating udev rules to fix the network names (and assign names like
> ext1, int1, per1) already in postinst of the OS does not work since we
> don't know how the machine is going to be wired and even used.
>
> Any ideas? How do _you_ do this?
>
> Greetings
> Marc
>
> --
> 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>
> --
> 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/20160824135527.GP2471%40torres.zugschlus.de.
> 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/CAC76iT8YZCWeKDB%2BdPiTRxE80WTe2BrCL%3D1hJEFteZKJF-gHEw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to handle predictable network interface names

[Rob Nelson]

Just tell them you wanted to make sure you were satisfying the external pen
testing requirements of PCI ;)

On Wednesday, August 24, 2016, Luke Bigum  wrote:

>  if I gave out the module the Security team would throttle me for
> releasing what is part of a map of internal network architecture ;-)
>


-- 

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/CAC76iT-WXMQ64j5KYBo%2BCU7AAh%2BQYv3pUJ9i0%2B0JJ0PfhSZGRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How to handle predictable network interface names

[Rob Nelson]

We are provisioning everything with vmxnet3 drivers, only weird old OVAs
from vendors have non-vmxnet3, and we don't manage those with puppet. We
are cloning from template and getting the same results on different
vSphere/vCenter versions and instances. Not sure why they would come out
different since the "slot" ends up being the same on the virtual hardware.


Rob Nelson
rnels...@gmail.com

On Thu, Aug 25, 2016 at 8:30 AM, Marc Haber 
wrote:

> Hi Rob,
>
> On Wed, Aug 24, 2016 at 10:30:20AM -0400, Rob Nelson wrote:
> > We use VMware's vSphere, which still results in "random" but predictable
> > interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc.
>
> In my experience, the numbers are rather random, different on each VM.
>
> > We've stuck with that because while it's somewhat painful (eth# is
> soo
> > much easier to comprehend), it's far less painful to memorize that than
> to
> > maintain some udev rules that may need tweaked across time.
>
> having net.ifnames=0 looks easier than working with those eight-digit
> numbers.
>
> >  However, if we were on bare metal, it might be worth disabling the
> >  rules to get the older style back. That's probably still less optimal
> >  than customized names, but it's well documented at least. For
> >  example, http://carminebufano.com/?p=108 or
> >  http://amolkg.blogspot.in/2015/05/centos-7-change-
> network-interface-name.html
> >  - though there are multiple ways to do it even then.
>
> Yes, that's what I'd see as a last moment manoeuvre. My gut feeling
> says "bad idea, don't do that". I don't have any evidence-based
> arguments for that though.
>
> Greetings
> Marc
>
> --
> 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
>
> --
> 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/20160825123035.GZ2471%40torres.zugschlus.de.
> 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/CAC76iT9xdN_CQZO8h9jvQZKMtsqKG8%3DfrJy_evxb-%2B_8_32hLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] mysql package name

[Rob Nelson]

t; Thanks
> Suresh Rajagopal
> --
> 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+unsubscribe@ googlegroups.com
> 
> .
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/c66b04fb- 2591-47da-af56-8f7eda59f964% 40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/c66b04fb-2591-47da-af56-8f7eda59f964%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/ optout
> <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-wWcT%2BD0BgoAa238y2xgn3dV5XByTSewJT
> k5hGOx4cR2GuQg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAC-wWcT%2BD0BgoAa238y2xgn3dV5XByTSewJTk5hGOx4cR2GuQg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/1151442669.1567854.1472493607331%40mail.yahoo.com
> <https://groups.google.com/d/msgid/puppet-users/1151442669.1567854.1472493607331%40mail.yahoo.com?utm_medium=email&utm_source=footer>
> .
> 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/148610e9-6fb8-ba33-0348-5af4b6c0ed6f%40alter3d.ca
> <https://groups.google.com/d/msgid/puppet-users/148610e9-6fb8-ba33-0348-5af4b6c0ed6f%40alter3d.ca?utm_medium=email&utm_source=footer>
> .
> 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/1604279226.1539856.1472495405093%40mail.yahoo.com
> <https://groups.google.com/d/msgid/puppet-users/1604279226.1539856.1472495405093%40mail.yahoo.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT9c9CUoyABT27ax_cwmuuXEx3FAUWT%3DU9Z2w_hVkUmNVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] mysql package name

[Rob Nelson]

Yes, you can see where the mysql module from Puppet does that, starting on
this line:
https://github.com/puppetlabs/puppetlabs-mysql/blob/master/manifests/params.pp#L58


Rob Nelson
rnels...@gmail.com

On Mon, Aug 29, 2016 at 3:46 PM, Suresh Rajagopal 
wrote:

> Hi Rob,
>
> version is passed via hiera. params.pp has the logic to decide the package
> name based version. Is it a good practice to have this logic in params.pp ?
>
> Thanks
> Suresh
>
>
> ----------
> *From:* Rob Nelson 
> *To:* "puppet-users@googlegroups.com" 
> *Sent:* Monday, August 29, 2016 11:41 AM
> *Subject:* Re: [Puppet Users] mysql package name
>
> If you dig deeper into the forge module, I think you will find that
> defaults are set in manifests/params.pp and set in the main class as
> `$client_package_name = $mysql::params::client_package_name` or similar.
> However, they're still class params so they can be overridden by users,
> often via hiera.
>
> On Monday, August 29, 2016, Suresh Rajagopal  wrote:
>
> Hi Peter,
>
> Yes passing package name works. But i have to pass package name for all
> the components. Something like below. I am just trying to figure out a way
> to handle this better. variable version is the deciding factor for the
> package names. I can pass this vie hiera. Is below the only approach to
> handle package names? If yes where to place this code ? init.pp or
> params.pp ?
>
>   if $mysql_provider == 'mariadb' {
> $client_package_name = 'MariaDB-client'
> $server_package_name = 'MariaDB-server'
> $server_service_name = 'mysql'
> $devel_package_name  = 'MariaDB-devel'
> $shared_package_name = 'MariaDB-shared'
>   } else {
> $server_package_name = $version ? {
>   /^5\.0|\.1\./ => 'MySQL-server-community',
>   /^5.6\./  => 'MySQL-server',
>   /^5.7\./  => 'mysql-community-server',
>   default   => 'mysql-community-server'
> }
> $client_package_name = $version ? {
>   /^5\.0|\.1\./ => 'MySQL-client-community',
>   /^5.6\./  => 'MySQL-client',
>   /^5.7\./  => 'mysql-community-client',
>   default   => 'mysql-community-client'
>   }
> $devel_package_name = $version ? {
>   /^5\.0|\.1\./ => 'MySQL-devel-community',
>   /^5.6\./  => 'MySQL-devel',
>   /^5.7\./  => 'mysql-community-devel',
>   default   => 'mysql-community-devel'
>   }
> $shared_package_name = $version ? {
>   /^5\.0|\.1\./ => 'MySQL-shared-community',
>   /^5.6\./  => 'MySQL-shared',
>   /^5.7\./  => 'mysql-community-libs',
>   default   => 'mysql-community-libs'
>   }
> $compat_package_name = $version ? {
>   /^5\.0|\.1\./ => 'MySQL-shared-compat',
>   /^5.6\./  => 'MySQL-shared-compat',
>   /^5.7\./  => 'mysql-community-libs-compat',
>   default   => 'mysql-community-libs-compat'
>   }
> $server_service_name = $version ? {
>   /^5\.0|\.1\./ => 'mysql',
>   /^5.6\./  => 'mysql',
>   /^5.7\./  => 'mysqld',
>   default   => 'mysqld'
> }
>
>
>
>
> Thanks
> Suresh Rajagopal
>
> --
> *From:* Peter Kristolaitis 
> *To:* puppet-users@googlegroups.com
> *Sent:* Monday, August 29, 2016 11:03 AM
> *Subject:* Re: [Puppet Users] mysql package name
>
> There is a package_name parameter in the Forge module.  It's designed to
> allow you to install e.g. MariaDB instead of MySQL, but it would work fine
> for your use case as well.
>
>
> On 2016-08-29 02:00 PM, Suresh Rajagopal wrote:
>
> Hi Lowe,
>
> My concern is with package name. MySQL package name differs for each
> version. In the forge module, if you try installing with
> mysql::server(ensure=>5.6.31) it will fail if you don't pass package name
> as(MySQL-server) an argument.
>
>  5.0/5.1 ---> MySQL-server-community
>  5.6 > MySQL-server
>  5.7 --->mysql-community-server
>
> How to handle this logic ?
>
> Thanks
> Suresh Rajagopal
> --
> *From:* Lowe Schmidt 
> *To:* puppet-users@googlegroups.com
> *Sent:* Monday, August 29, 2016 7:

Re: [Puppet Users] roles/profiles in the state of the art

[Rob Nelson]

I would suggest against this. Each role should be atomic and independent.
If I change my role, and you were depending on the profiles it included,
you might be negatively affected.

However, it's about your workflow and if you have roles that are
profile-roll ups that rarely change, perhaps it fits your workflow well
enough to be reasonable.

On Wednesday, September 7, 2016, Albert Shih  wrote:

> Hi,
>
> I would like to know if it's « in the state of the art » to include inside
> a role another role.
>
> Or inside a role I should ONLY include profile.
>
> I've got a CMS running in one server. I've two other server one for the
> dev, on for the sandbox.
>
> So I got a role for the first CMS. For the other two server, because I'm
> lazzy guy I would like just include the role_first_CMS inside the dev and
> sandbox, because the only difference (beside data inside hiera) are we add
> some scripts for the synchro.
>
> Regards.
>
> JAS
> --
> Albert SHIH
> DIO bâtiment 15
> Observatoire de Paris
> 5 Place Jules Janssen
> 92195 Meudon Cedex
> France
> Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
> xmpp: j...@obspm.fr 
> Heure local/Local time:
> mer 7 sep 2016 16:31:50 CEST
>
> --
> 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/20160907143523.gfbu22cz37iyl4qw%40pcjas.obspm.fr.
> 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/CAC76iT8Gzji5LwyuAosrHn7rrGQwKSL8xWxO8Huw%2BnTCZWh3-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Rob Nelson]

I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you are
stair stepping or starting fresh), they mostly "just work". Throw them in a
module and poof, agents get them on the next run, and they're processed
before the catalog compilation of that run so they take effect immediately.
Learning Just Enough Ruby(TM) also should not make you too shy. A long time
ago, I wrote a sample custom fact that parses a hostname with a regex and
grabs a portion of the string (
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/lib/facter/puppet_role.rb)
- if you are comfortable with regex, you can probably pick up the minimal
ruby required to understand the rest of it. It wouldn't be too difficult to
add a system() call to rpm and check the return code.

All that said, perhaps instead of using a fact, you could use ordering
within your puppet manifest, to implement the PAM module first, THEN update
the config via template afterward. This could be as simple as this:

  package{'pam-additional-module':
ensure => present,
  } ->
  file{'pam-additional-module-config':
ensure => present,
path => /etc/pam.d/additional.conf,
contents => template('profile/pam/additional.conf.erb'),
  }

This would install the package 'pam-additional-module', then install a
configuration file for it based on an ERB template. Just an example you can
adapt. I hope that helps!


Rob Nelson
rnels...@gmail.com

On Tue, Sep 13, 2016 at 2:10 PM, HPUX_PUPPET  wrote:

> I am moving from Puppet 0.25 to Puppet 4.  In doing so I am re-writing a
> lot of the modules to work better than what I inherited.
>
> So my current issue I am trying to figure out is how to update PAM
> variables based on what external 3rd party authentication package we have
> installed on that server. The old method that had been employed was to use
> an exec to push a file with the correct settings.  I am trying to do it via
> a template.
>
> The problem I am having is that I need to check if the PAM module is
> installed before making the changes and revert them if it is removed. I
> know I can write a custom fact, but on the 0.25 version a custom fact
> required both puppet.conf edits and a bounce of the agent. I haven't tried
> on the later versions, but I remain gun shy,
>
> Ideally I would run an execute to check the module and only do the changes
> if the PAM module is in place. I haven't figured out how to do that yet
> with templates.
>
> Has anyone else figured out the least invasive way to do this. Aka no
> custom facts?
>
> Do I need to just knuckle down and learn enough Ruby to have it determine
> if the package is set and use one variable, if not the other?
>
> I am still new to Puppet coding in Puppet 4, well in general too, when
> getting into the weeds like this. I would assume there is a simple think
> like below. (Notes this is probably not correct puppet code, just a
> pseudocode example)
>
> if ( ! exec { check_package:
>   path => "/usr/bin:/bin:/sbin:/usr/sbin",
>   command => "rpm -q ",
>   } ) {
>  $extra_lines = [
>  'blah blak',
>  'blah',
>  ]
>}
>
> Think is I just don't have enough skill yet to make it work on my own yet,
> so I am reaching out to see if someone already figured this out as I keep
> hammering on it.
>
> 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/fd5cb2f3-8ab1-4c0e-8134-f8e5ec49c1ac%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/fd5cb2f3-8ab1-4c0e-8134-f8e5ec49c1ac%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-ONfsSvxegE75WTO8BLm%3D4jTTORF7k3Vr5UE3RW-foVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Rob Nelson]

Are there cases where a node might not have the package, ever? Or do you
just want to make sure it's done in the right order? If you did this:

  package{'some-pam-package':
ensure => present,
  }

...and the package was already installed, nothing would happen. However you
could then leverage that, as in the previous example, in ordering to make
sure the file shows up afterward.

You could put this in a profile that is only applied to certain
roles/nodes, or some other conditional (i.e. a param `$manage_pam` to a
profile where, when true, the example code is hit), to restrict which nodes
receive that in their catalog. This lets the 'package' type do its job
rather than writing more complicated code and conditional, and protects you
if somehow that package is uninstalled - puppet will enforce the desired
state and re-install the package and configuration.

Does that make sense?


Rob Nelson
rnels...@gmail.com

On Wed, Sep 14, 2016 at 9:32 AM, HPUX_PUPPET  wrote:

> Thanks Rob!
>
> I am sort of "starting fresh" so I have a lot of latitude here. The way it
> was done before was shoddy and required a lot of files, so I am trying to
> reduce them.
>
> I will go back to investigating a custom fact.  I have used them in the
> past, but the problem was more related to needing to manually go to each
> host to restart puppet so it would recognize that a fact had been added.
>
> Unfortunately installing PAM is less the issue as having customized lines
> that need to be added to the top of the files for servers using the 3rd
> party AD authentication for boxes where it is installed. As they had
> mandatory require lines, if the files are not there, we are locked out.
> Currently we a file param to create the needed files in temp on all boxes
> and then if the software was installed, we would switch files. Trying to
> keep it less kludgy so I was seeing if Puppet could use an RPM list from
> the host to check. A custom fact seems the best way to go here.
>
>
> On Tuesday, September 13, 2016 at 5:42:50 PM UTC-4, Rob Nelson wrote:
>>
>> I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you
>> are stair stepping or starting fresh), they mostly "just work". Throw them
>> in a module and poof, agents get them on the next run, and they're
>> processed before the catalog compilation of that run so they take effect
>> immediately. Learning Just Enough Ruby(TM) also should not make you too
>> shy. A long time ago, I wrote a sample custom fact that parses a hostname
>> with a regex and grabs a portion of the string (
>> https://github.com/puppetinabox/controlrepo/blob/production
>> /dist/profile/lib/facter/puppet_role.rb) - if you are comfortable with
>> regex, you can probably pick up the minimal ruby required to understand the
>> rest of it. It wouldn't be too difficult to add a system() call to rpm and
>> check the return code.
>>
>> All that said, perhaps instead of using a fact, you could use ordering
>> within your puppet manifest, to implement the PAM module first, THEN update
>> the config via template afterward. This could be as simple as this:
>>
>>   package{'pam-additional-module':
>> ensure => present,
>>   } ->
>>   file{'pam-additional-module-config':
>> ensure => present,
>>     path => /etc/pam.d/additional.conf,
>> contents => template('profile/pam/additional.conf.erb'),
>>   }
>>
>> This would install the package 'pam-additional-module', then install a
>> configuration file for it based on an ERB template. Just an example you can
>> adapt. I hope that helps!
>>
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>> On Tue, Sep 13, 2016 at 2:10 PM, HPUX_PUPPET  wrote:
>>
>>> I am moving from Puppet 0.25 to Puppet 4.  In doing so I am re-writing a
>>> lot of the modules to work better than what I inherited.
>>>
>>> So my current issue I am trying to figure out is how to update PAM
>>> variables based on what external 3rd party authentication package we have
>>> installed on that server. The old method that had been employed was to use
>>> an exec to push a file with the correct settings.  I am trying to do it via
>>> a template.
>>>
>>> The problem I am having is that I need to check if the PAM module is
>>> installed before making the changes and revert them if it is removed. I
>>> know I can write a custom fact, but on the 0.25 version a custom fact
>>> required both puppet.conf edits and a bounce of the agent. I haven't tried
>>> on the later versions, b

Re: [Puppet Users] Best way to set variables based on packages installed on client?

[Rob Nelson]

I don't think you'll see that added as a core fact because it would still
have a relatively narrow appeal. Due to the partnership between RH/Puppet,
there may be a Satellite mod that includes such a custom fact. If you do
something like that yourself, I would keep an eye on
https://tickets.puppetlabs.com/browse/FACT-348 and the RFC for a
facter.conf file that includes TTL/caching, since that would be a pretty
heavyweight fact to generate.

Glad you found a solution. That sounds like a hairy problem in general!


Rob Nelson
rnels...@gmail.com

On Thu, Sep 15, 2016 at 8:53 AM, HPUX_PUPPET  wrote:

> I only wish it was that simple and thus the problem i had been facing.
>
> The 3rd party package requires hands-on steps to get installed, but the
> package itself isn't the issue. It is that it puts 2-5 lines at the head of
> the PAM module conf files (system-auth, password-auth, common-auth, ...).
> If the lines are pushed by a default configuration and the software it not
> installed or connected to AD, then you can't get in, even with root. You
> have to boot to single-user mode to correct it. When pushing out PAM setups
> to servers, we cannot assume the 3rd party software has been installed at
> that point.
>
> But thanks to your great encouragement, I wrote some down and dirty custom
> facts that check if it is installed and if so, the version as well. I put
> the fact in the module directory and it deployed immediately.  Not the
> experience I had with the 0.25 puppet client at all.
>
> Now I have the easy part of checking to ensure the package is installed to
> add the lines to variables I am using in the PAM template files.
>
> This post was mainly about seeing if Puppet / Factor had been tweaked over
> the years to pull lists of installed RPMs given Red Hat Satellite 6 using
> Puppet as part of their software management and server build solution.
>
> On Wednesday, September 14, 2016 at 1:31:37 PM UTC-4, Rob Nelson wrote:
>>
>> Are there cases where a node might not have the package, ever? Or do you
>> just want to make sure it's done in the right order? If you did this:
>>
>>   package{'some-pam-package':
>> ensure => present,
>>   }
>>
>> ...and the package was already installed, nothing would happen. However
>> you could then leverage that, as in the previous example, in ordering to
>> make sure the file shows up afterward.
>>
>> You could put this in a profile that is only applied to certain
>> roles/nodes, or some other conditional (i.e. a param `$manage_pam` to a
>> profile where, when true, the example code is hit), to restrict which nodes
>> receive that in their catalog. This lets the 'package' type do its job
>> rather than writing more complicated code and conditional, and protects you
>> if somehow that package is uninstalled - puppet will enforce the desired
>> state and re-install the package and configuration.
>>
>> Does that make sense?
>>
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>> On Wed, Sep 14, 2016 at 9:32 AM, HPUX_PUPPET  wrote:
>>
>>> Thanks Rob!
>>>
>>> I am sort of "starting fresh" so I have a lot of latitude here. The way
>>> it was done before was shoddy and required a lot of files, so I am trying
>>> to reduce them.
>>>
>>> I will go back to investigating a custom fact.  I have used them in the
>>> past, but the problem was more related to needing to manually go to each
>>> host to restart puppet so it would recognize that a fact had been added.
>>>
>>> Unfortunately installing PAM is less the issue as having customized
>>> lines that need to be added to the top of the files for servers using the
>>> 3rd party AD authentication for boxes where it is installed. As they had
>>> mandatory require lines, if the files are not there, we are locked out.
>>> Currently we a file param to create the needed files in temp on all boxes
>>> and then if the software was installed, we would switch files. Trying to
>>> keep it less kludgy so I was seeing if Puppet could use an RPM list from
>>> the host to check. A custom fact seems the best way to go here.
>>>
>>>
>>> On Tuesday, September 13, 2016 at 5:42:50 PM UTC-4, Rob Nelson wrote:
>>>>
>>>> I wouldn't be that shy of custom facts in Puppet 3/4 (don't know if you
>>>> are stair stepping or starting fresh), they mostly "just work". Throw them
>>>> in a module and poof, agents get them on the next run, and they're
>>>> processed before the catalog compilation of that run s

Re: [Puppet Users] Order of removal of resources

[Rob Nelson]

The dependency warning may be overstated a bit, in your situation you're
not likely to cause that issue by accident.

Another view might be that systems should be built from scratch when
significant changes are made. Regardless of your CM tool, that's generally
a better idea these days - even upgrades generally benefit from standing up
a fresh system to replace the older system.

Also, order of removal of files does seem odd, if neither is required. Was
that a contrived example or an actual example? If the latter, that seems
like a really badly behaved application, from the outside.

On Wednesday, September 21, 2016, Peter Faller  wrote:

> Thanks Craig - that does work, but what it says in the documentation is
> true:
> "Note: Chained collectors can potentially cause huge dependency cycles
> <https://docs.puppet.com/puppet/3.8/reference/lang_relationships.html#dependency-cycles>
>  and
> should be used carefully."
>
> This approach works fine for 'leaf' resources; but when the dependencies
> get more complicated it is very easy to create dependency cycles. It's
> beginning to look to me that Puppet is best suited to cases where resources
> once added, remain in place.
>
>> --
> 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/dc9d3590-bdec-4b0b-b360-20afcd97f15f%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/dc9d3590-bdec-4b0b-b360-20afcd97f15f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT_XVQVNzHsTN_JqF%2Bw-W__7hZ6oQAjtWajzp15vQSdrZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Smoke testing puppet modules within Red Hat Satellite v6.2 Puppet Master

[Rob Nelson]

Warren,

It seems like you might be running afoul of the autoloader. It expects that
within the module path, each module has a certain layout - the class ntp is
defined in ntp/manifests/init.pp, etc. if you place that in a directory
called module2, puppet will not find it, since it expects
module2/manifests/init.pp to contain the module2 class. That's my first
guess, but it could be that you obfuscated your paths and did not call it
module_name2 on disk but mas_shared_mas_menu as the error indicated,
difficult to tell from here. Let us know if that helps!

Rob Nelson

On Wednesday, September 21, 2016, Warron French 
wrote:

> As most of you I know, I am a total novice at Puppet.  I have built, on my
> own however, a PE Puppet Master at home and it is running on a CentOS-6.7
> VM.
>
> Now, I am at work, trying to write modules and smoke test them, like I
> have learned to do much better now at home.
>
> At home, I can write some basic modules without having to constantly refer
> to style guides, syntax documentation, etc... then I run:
>
>1. puppet parser validate module_name1/tests/init.pp
>2. puppet apply --noop module_name1/tests/init.pp
>
> When I run the smoke test, I see an indicate of *what changes would have
> occured*.  Normal right?
>
>
> In my work environment, on the Red Hat Satellite Server, I wrote some
> similar modules from memory, then I run:
>
>1. puppet parser validate module_name2/tests/init.pp
>2. puppet apply --noop module_name2/tests/init.pp
>
> The syntax checks out, but the error(s) I get in response to the smoke
> test are:
>
> Error: Could not find class mas_shared_mas_menu for x  on node x
>
> Error: Could not find class mas_shared_mas_menu for x on node  x
>
>
> *NOTE1:*  I have learned how to upload a puppet module to my Puppet
> Master on the Satellite Server.
>
> *NOTE2:*  I am smoketesting these modules from the ssh terminal session
> connected to the Satellite/Puppet Master server = .
>
> *NOTE3:*  I don't have any agent nodes attached to my Puppet Master.
>
>
> Can someone tell me what I am doing wrong please?
>
> --
> 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/2a3b3fc7-f287-48b4-9031-187f041a56be%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/2a3b3fc7-f287-48b4-9031-187f041a56be%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-NeFxm5NPv%2B5YnZ2YGEYW%2B81474t--i2TioysrJ0xX8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppetfile git url representation

[Rob Nelson]

J.T., is it possible that the shell Git was using a key on disk that was
removed recently?

On Wednesday, September 21, 2016, J.T. Conklin 
wrote:

>
> At work, I'm taking over primary administration of a puppet deployment
> that had previously been maintained by a contractor. Shortly before he
> left, it upgraded from PE 3.X to 2016.2.0, and moved from r10k to Code
> Manager.
>
> This has been running well, but "something happened" yesterday where
> code deploy started failing with:
>
> ERROR-> Unable to determine current branches for Git source
> 'puppet'
> (/etc/puppetlabs/code-staging/environments)
> Original exception:
> Git remote "ssh://g...@stash.example.com/puppet/puppetcode.git" uses
> the SSH protocol but no private key was given at
> /opt/puppetlabs/server/data/code-manager/worker-caches/
> deploy-pool-1/ssh---...@stash.example.com-ro-puppetcode.git
>
> Going through the PE documentation, I discovered that a SSH private key
> wasn't set up (suggesting that shell git had been being used instead of
> rugged?), so I set puppet_enterprise::profile::master::r10_private_key
> and forced a puppet run.
>
> After that, deploys could fetch our control repository, but failed for
> all our own modules in separate git repositories with a "Invalid
> credential type"..
>
> 016-09-20 14:13:48,587 ERROR [deploy-pool-1] [p.c.core] Errors while
> deploying environment 'dev' (exit code: 1):
> INFO -> Deploying environment
> /etc/puppetlabs/code-staging/environments/dev
> INFO -> Environment dev is now at
> f39d43d8e029c3208c98a76bf019387fa5cfa848
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/ntp
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/apt
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/concat
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/stdlib
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/sysctl
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/java
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/autofs
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/puppet_agent
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/transition
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/inifile
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/acpica_tools
> ERROR-> Invalid credential type
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/apache
> ERROR-> Invalid credential type
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/appfirst
> ERROR-> Invalid credential type
> INFO -> Deploying module
> /etc/puppetlabs/code-staging/environments/dev/modules/aspell
> ERROR-> Invalid credential type
>
> One difference from the PE documentation (which I didn't think could
> possibly be the problem, but fortunately tried anyway) was that our
> Puppetfile git urls were of the form:
>
>ssh://g...@stash.example.com/puppet/puppet-foo
>
> instead of
>
>g...@stash.example.com:puppet/puppet-foo
>
> Once I changed Puppetfile to use the second form, I was again able to
> use puppet-code to deploy changes. While I still need to find out the
> "something" that happened to break things, I wanted to send a message to
> the list while the details are still fresh in my mind in case this might
> be useful to someone sometime down the road, especially as this behavior
> (IMHO) violates the principle of least astonishment.
>
> --jtc
>
> --
> 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/87intpi3uh.fsf%40wopr.acorntoolworks.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/CAC76iT-nTq8G-4br40kEjXCsnWbn5zrUZinGuYXLRF5efoKOvg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: How do i set the effective role if there is a subrole

[Rob Nelson]

Ivan,

In discussing roles, I always encourage reviewing
http://www.craigdunn.org/2012/05/239/, the original guideline for the roles
and profiles pattern. It posits that the role, like the profile, is just
another class inside the 'role' module - role::www, role::mail, etc - that
is composed of profile classes - profile::apache, profile::webapp, etc.
Lots of examples in the document. The "rules", which are more like
guidelines, are near the bottom (emphasis mine):

   - *A node includes one role, and one only.*
   - A role includes one or more profiles to define the type of server
   - A profile includes and manages modules to define a logical technical
   stack
   - Modules manage resources
   - Modules should only be responsible for managing aspects of the
   component they are written for

Another guideline that has cropped up since 2012 is: If a node requires two
roles, it's time to create a new role that fits that need. So, subroles
would actually be new roles - role::webapp1 and role::webapp2 rather than
assigning role::web and role::app1 to a single node, for example. This
ensures that roles do not become coupled in accidental manners, where
someone wants to tweak a setting for webapp1 that happens to be in
role::web, causing side effects to webapp2.

Going back to your previous email, you also described role::mail where some
nodes are relays. You may need a second role for this, but it is also
possible that one of the profiles (maybe profile::mailapp) or the component
module it calls (postfix or sendmail) accept parameters that indicate
whether a node is a relay or not. In that case, you could use hiera to pass
different values to those parameters for different nodes. I wrote a bit on
the merging of Roles and Profiles with Hiera data at
https://rnelson0.com/2014/07/14/intro-to-roles-and-profiles-with-puppet-and-hiera/
that may help.



Rob Nelson
rnels...@gmail.com

On Wed, Sep 21, 2016 at 3:22 PM, Ivan Arjune  wrote:

> Are subroles implemented as a conditional statement within the profile
> manifest?
>
> --
> 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/886ef534-a8de-454c-93dd-d8fae9c2dcc1%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/886ef534-a8de-454c-93dd-d8fae9c2dcc1%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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_19LxtfyQC4ASdkEt1ar9VKqe5AM-KOd7EKkEXEKDNSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] heira debug not working

[Rob Nelson]

Use ::environment on the command line, since that's what your datadir is
looking for. environment and ::environment are not normalized to the same
value.

On Saturday, September 24, 2016, Jagga Soorma  wrote:

> Hi Guys,
>
> I am new to hiera and can't seem to get the debug command to work for
> hiera.  Seems like it is not picking up the environment variable even when
> I specify it on cli:
>
> --
> [root@resforetst01 ~]# grep -i testkey /etc/puppet/environments/
> production/hieradata/common.yaml
> testkey: hello
>
> [root@resforetst01 ~]# hiera -c /etc/puppet/hiera.yaml testkey
> environment=production --debug
> DEBUG: 2016-09-24 16:10:28 -0700: Hiera YAML backend starting
> DEBUG: 2016-09-24 16:10:28 -0700: Looking up testkey in YAML backend
> DEBUG: 2016-09-24 16:10:28 -0700: Looking for data source common
> *DEBUG: 2016-09-24 16:10:28 -0700: Cannot find datafile
> /etc/puppet/environments//hieradata/common.yaml, skipping*
> nil
>
> [root@resforetst01 ~]# grep -i datadir /etc/puppet/hiera.yaml | grep -v
> '#'
>   :datadir: "/etc/puppet/environments/%{::environment}/hieradata"
>
> [root@resforetst01 ~]# cat /etc/puppet/environments/
> production/hieradata/common.yaml | grep -v '#' | sed '/^$/d'
> ---
> pr_runlevel::default_runlevel: '3'
> selinux::mode: 'disabled'
> firewall::ensure: 'stopped'
> testkey: hello
> --
>
> Any help would be appreciated.  Am I missing some configuration here?
>
> 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/CAKyjK53nAWV6G9RPK7G4OGcV%
> 3DvpEU%3DmQ6TpoA0bGu6ZLp5GXsA%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAKyjK53nAWV6G9RPK7G4OGcV%3DvpEU%3DmQ6TpoA0bGu6ZLp5GXsA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT_MOu9RBJ7Md5%3Db7pOcqYmdgjfEOWXojckEbwW%2BKjfAvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] R10K in an existing infrastructure OR How to write yourself into a corner.

[Rob Nelson]

Have you looked at including these modules inside your r10k controlrepo?
>From a workflow perspective, that might be easier (branch, tweak files,
PR/merge to `production`), though there may be issues surrounding access
and permissions, of course. Have a gander at
http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/
for controlrepo theory and
http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/ which
details the conversion from modules in other repos to a consolidated
controlrepo.

If access rights are an issue, you could have a standalone module that is
pushed out by r10k via cron on a regular basis, across all repositories.
See
https://github.com/puppetinabox/controlrepo/blob/production/Puppetfile#L51-L53
and
https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/puppet_master.pp#L25-L29
as an example of this. This would push the current version of that module
to every environment that exists at the time. I believe that if you specify
a certain ref/branch inside an environment, it will deploy that ref/branch,
otherwise it deploys the default branch of the repo, but would certainly
verify that if you go down that road.


Rob Nelson
rnels...@gmail.com

On Tue, Sep 27, 2016 at 6:09 PM, Robert Davidson <
robert.david...@nominum.com> wrote:

> We're still running puppet 3.6.2, and are finally getting around to trying
> to implement R10K. For assorted reasons, we have not been able to do this
> before now, and have a very large stack of home-grown modules that are all
> sitting in a monolithic repo. For the most part, it's been straightforward.
> We are splitting up the modules into their own repos, tagging them with
> version numbers, etc. But I've now hit an issue that's got me blocked.
>
> We have several modules that include important data files inside them.
> (Which is bad practice, I know, but many of these were written a while ago
> and we're slowly working to refactor.)
> In our current, monolithic setup, they reside in paths like this:
> git/puppet/environments/production_ng/modules/$MODULE/
> files/customers/$FILENAME
>
> Each $FILENAME must be pushed out, with that name and it's contents, to a
> particular directory on the machine using the module. The files contain
> anywhere from ten to a hundred lines of config, varying per customer. At
> the moment, we push them using a recursive file resource into the directory.
>
> Under r10k, we want to use tags to mark version numbers and pull them into
> environments. But these config files need to change rapidly, and would
> result in ridiculous version creep if we increment every time we had to
> adjust one of them. What is a good way to deal with data files like this
> (ones where putting the contents into hiera is not really viable)? How do I
> treat them under R10K?
>
> --
> Robert Davidson
>
> --
> 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/1EE73329D6577F44A3C2FB0F7D4ACAE98D244374%40mbx-02.
> 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-urwaEHe8KiJf81Y5jcdPF7%3Dg%3D%2B-HDhy0VUSG-2bTmJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 3.8 EOL Question

[Rob Nelson]

Dan,

That might be a better question for Red Hat as they often support
bundled/associated EOL
products (like ruby 1.8.7) by themselves once the vendor support ends.

On Wednesday, September 28, 2016, Dan White  wrote:

> I found a thread from March on puppet-dev (Subject Line: End of Life
> estimate for Puppet 3.X?)
> On which Eric Sorenson said, referring to Open Source Puppet,  "As a
> practical matter we're going to have Puppet 3.8 on maintenance and security
> fixes as long as there's a supported PE version that incorporates it."
>
> My question is : How will the EOL of (PE/Open Source) Puppet 3.8 (the last of 
> the 3's!) affect Red Hat Satellite 6.x (which contains/incorporates a 
> customized Open Source Puppet 3.x) ??
>
> Dan White | d_e_wh...@icloud.com 
> 
> 
> “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/1d73e7fb-23f1-4d9c-ab1e-387490e90c6e%40me.com
> <https://groups.google.com/d/msgid/puppet-users/1d73e7fb-23f1-4d9c-ab1e-387490e90c6e%40me.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-pF0WDraaPKdKmmZvtGn-uvgVbWCUa12ge%2BRx0qNHJ0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] R10K in an existing infrastructure OR How to write yourself into a corner.

[Rob Nelson]

The 'site_configs' module is pretty equivalent to the 'data' module you
propose - odd config files, SSL certs, etc. I've been using that
successfully at home and work for over a year with r10k without any issues.
I'm not using 'data in modules' yet but that would let you combine hiera
data with the files, as well.

On Wednesday, September 28, 2016, Robert Davidson <
robert.david...@nominum.com> wrote:

> I would prefer not to have to treat these modules any differently than the
> rest - the only thing about the problem modules is that they include data
> files that need to be pushed intact. Putting them into the control repo
> would diverge them from the way we want to handle all other modules, which
> strikes me as sub-optimal. I'm mostly looking to see if anyone else has
> experience handling situations like this, and if they were able to come up
> with a way to handle it without changing how modules are handled.
>
> One thing we did think about was to create a "data" module that contains
> files like these, and are referred to inside r10K by branch rather than
> tag, letting us continue to treat the bulk of the module correctly while
> isolating our config files off to their own space. It's ugly, but could
> theoretically work. I can't help but feel that there must be a better way
> to do this, though.
>
> --
> Robert Davidson
>
>
> > -Original Message-
> > From: puppet-users@googlegroups.com  [mailto:puppet-
> 
> > us...@googlegroups.com ] On Behalf Of Rob Nelson
> > Sent: Tuesday, September 27, 2016 4:52 PM
> > To: puppet-users@googlegroups.com 
> > Subject: Re: [Puppet Users] R10K in an existing infrastructure OR How to
> > write yourself into a corner.
> >
> > Have you looked at including these modules inside your r10k controlrepo?
> > From a workflow perspective, that might be easier (branch, tweak files,
> > PR/merge to `production`), though there may be issues surrounding access
> > and permissions, of course. Have a gander at
> > http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-
> > practices/ for controlrepo theory and
> > http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/
> > which details the conversion from modules in other repos to a
> consolidated
> > controlrepo.
> >
> >
> > If access rights are an issue, you could have a standalone module that is
> > pushed out by r10k via cron on a regular basis, across all repositories.
> See
> > https://github.com/puppetinabox/controlrepo/blob/production/Puppetfile
> > #L51-L53 and
> > https://github.com/puppetinabox/controlrepo/blob/production/dist/profil
> > e/manifests/puppet_master.pp#L25-L29 as an example of this. This would
> > push the current version of that module to every environment that exists
> at
> > the time. I believe that if you specify a certain ref/branch inside an
> > environment, it will deploy that ref/branch, otherwise it deploys the
> > default branch of the repo, but would certainly verify that if you go
> down
> > that road.
> >
> >
> >
> > Rob Nelson
> > rnels...@gmail.com 
> >
> > On Tue, Sep 27, 2016 at 6:09 PM, Robert Davidson
> > > wrote:
> >
> >
> >   We're still running puppet 3.6.2, and are finally getting around to
> > trying to implement R10K. For assorted reasons, we have not been able to
> > do this before now, and have a very large stack of home-grown modules
> > that are all sitting in a monolithic repo. For the most part, it's been
> > straightforward. We are splitting up the modules into their own repos,
> > tagging them with version numbers, etc. But I've now hit an issue that's
> got
> > me blocked.
> >
> >   We have several modules that include important data files inside
> > them. (Which is bad practice, I know, but many of these were written a
> > while ago and we're slowly working to refactor.)
> >   In our current, monolithic setup, they reside in paths like this:
> >   git/puppet/environments/production_ng/modules/$MODULE/files/
> > customers/$FILENAME
> >
> >   Each $FILENAME must be pushed out, with that name and it's
> > contents, to a particular directory on the machine using the module. The
> > files contain anywhere from ten to a hundred lines of config, varying per
> > customer. At the moment, we push them using a recursive file resource
> into
> > the directory.
> >
> >   Under r10k, we want to use tags to mark version numbers and pull
> > them into environments. But these

Re: [Puppet Users] R10K in an existing infrastructure OR How to write yourself into a corner.

[Rob Nelson]

Whoops, it's called lab_config in that project (site_config is my private
repo for the home lab) and can be found at
https://github.com/puppetinabox/lab_config. There's not as much to that
since it's a reference project, but for example DNS updates are pushed out
every 15 minutes from it (agents check in every 30 minutes, though), so
it's just a matter of pushing a change to 'master' in that repo and boom,
deployed within the hour.

On Thursday, September 29, 2016, John Warburton 
wrote:

>
> On Thursday, 29 September 2016, Rob Nelson  > wrote:
>
>> The 'site_configs' module is pretty equivalent to the 'data' module you
>> propose - odd config files, SSL certs, etc.
>
>
> Rob
>
> I can't find site_configs on the forge or google. Any pointers?
>
> Thanks
>
> John
>
>
> --
> John Warburton
> Ph: 0417 299 600
> Email: jwarbur...@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/CAAJLFxXZSAxxUY-6sRR7f_3dZEAriMqzHgfrxzfcjYUM1XFvaw%
> 40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAAJLFxXZSAxxUY-6sRR7f_3dZEAriMqzHgfrxzfcjYUM1XFvaw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-aiwZcD1-7B%3DYy0brzbRrpz0-Z6Ck9_ULsDJE7D%2B-CKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

RG, typically the Duplication declaration message is followed by some
indicator of the file where it is duplicated and the line number. Are you
receiving that information and maybe snipped it off the end of the message
you included? An alternative might be any sort of `hiera_include()` or
`create_resources()` calls whose arguments may include `rsyslog` more than
once.


Rob Nelson
rnels...@gmail.com

On Wed, Oct 5, 2016 at 3:16 PM,  wrote:

> I installed the puppet module saz-rsyslog from puppet forge.
> I use The Foreman to configure nodes. The Foreman is used by puppet via
> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>
> Since the saz-rsyslog module install, I have been receiving the following
> error off and on (not consistently) across many nodes on a puppet update
> (i.e. puppet agent -t):
>
> "Could not retrieve catalog from remote server: Error 400 on SERVER:
> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare
> on node "
>
>
> My nodes are CentOS 5,6,7; and any various number of the nodes may
> experience this issue, but not all of them at the same time.
>
> One day I will see dozens of server with this error, and other nodes not
> having this issue. This may go on for days if I do not touch The Foreman.
> I'll make some changes to host configuration for puppet module class
> parameters in The Foreman - never the saz-rsyslog module though..
> After the changes, half or more of the servers having issue (not all) will
> magically have no problems.
> However, more nodes that did not have issues before, will now experience
> this issue.
>
> Also, this change of events is not directly related to The Foreman host
> configuration changes.
> I can simply perform a puppet module upgrade to a unrelated module (e.g.
> mine-yumconfig). After upgrading the unrelated module, again many nodes
> with this issue will now have it resolved, and different ones not
> experiencing the issue before will now begin experiencing it.
>
>
> The only clue I have is from this posting: http://grokbase.com/
> t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
> "... If you do not see the error on every run then it is modulated by
> something that varies between runs. That could be almost anything:
> manifests, data, results of function calls, node facts, or ENC output. ..."
>
>
> Can anyone help me understand this issue, or help me get it resolved
> permanently?
>
> When I search for answers, all I see are "You have written a duplicate
> class in your module." However, in my case, I did not write the saz-rsyslog
> module, I am only using it. It is a puppet-forge approved module with
> 635,000+ downloads. And without modifying the module, the issue can
> disappear, seemingly without rhyme or reason.
>
> -RG
>
> --
> 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/1ead58c4-ed05-4b03-9bee-6fd576d187f3%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/1ead58c4-ed05-4b03-9bee-6fd576d187f3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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_tan-L2xS26Jz1gRNVMH4amEBvmqHbQx8hZNUzdp8MAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts and Resource relationships

[Rob Nelson]

I do not know that a workaround is needed. I believe that when a package is
upgraded, the old and new versions should show up in the logs already, so
the notify may not be needed.

On Thursday, October 6, 2016, Erez Zarum  wrote:

> Ok, so the workaround is to use a variable (set default), if that fails,
> try the fact.
>
> Thanks!
>
> On Thursday, October 6, 2016 at 10:45:26 AM UTC+3, R.I. Pienaar wrote:
>>
>>
>>
>> - Original Message -
>> > From: "Erez Zarum" 
>> > To: "puppet-users" 
>> > Sent: Thursday, 6 October, 2016 09:40:44
>> > Subject: [Puppet Users] Facts and Resource relationships
>>
>> > I'm not sure if it's a bug or an expected behavior.
>> >
>> > I have written a simple fact for a module that returns a version of a
>> > binary file, it executes: "binary --version" and then parses the
>> version,
>> > no issues there, it works.
>> >
>> > The issue i am having is relying on this fact in case the binary file
>> gets
>> > upgraded during a package installation (this is the simple example)
>> >
>> > package { 'package':
>> > ensure => '1.3.8'
>> > } ->
>> > notify { "version: ${::binary_version}": }
>> >
>> > If the previous version was 1.3.7 the fact "binary_version" will return
>> > 1.3.7, the next run it will return 1.3.8 as expected.
>> > The biggest issue is if i rely on this fact to pick up a template to
>> use,
>> > if this package is not yet installed the fact won't work and will work
>> only
>> > on the second run.
>> >
>> > I can only assume this happens because the facts are being "compiled"
>> > before the catalog is.
>> >
>> > I have tried different ways to declare the relationship but it doesn't
>> work.
>>
>> yes, you cant use facts for something that changes during a run.  It's
>> for facts
>> about your node that influence the creation of the catalog.
>>
>> things the catalog changes - well thats after the catalog was created
>>
> --
> 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/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-UZyhicPbsmoF1CbTQiYQrhiPp8_PwCB5rHqmz%2Bsz17Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

Can you undo the change in foreman, see if the problem goes away, then
reimplement the change and see if the problem comes back? That would go a
long way toward isolating the cause.

On Thursday, October 6, 2016,  wrote:

>
>
> On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu
>  wrote:
>>
>> I installed the puppet module saz-rsyslog from puppet forge.
>> I use The Foreman to configure nodes. The Foreman is used by puppet via
>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>
>> Since the saz-rsyslog module install, I have been receiving the following
>> error off and on (not consistently) across many nodes on a puppet update
>> (i.e. puppet agent -t):
>>
>> "Could not retrieve catalog from remote server: Error 400 on SERVER:
>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare
>> on node "
>>
>>
>> My nodes are CentOS 5,6,7; and any various number of the nodes may
>> experience this issue, but not all of them at the same time.
>>
>> One day I will see dozens of server with this error, and other nodes not
>> having this issue. This may go on for days if I do not touch The Foreman.
>> I'll make some changes to host configuration for puppet module class
>> parameters in The Foreman - never the saz-rsyslog module though..
>> After the changes, half or more of the servers having issue (not all)
>> will magically have no problems.
>> However, more nodes that did not have issues before, will now experience
>> this issue.
>>
>> Also, this change of events is not directly related to The Foreman host
>> configuration changes.
>> I can simply perform a puppet module upgrade to a unrelated module (e.g.
>> mine-yumconfig). After upgrading the unrelated module, again many nodes
>> with this issue will now have it resolved, and different ones not
>> experiencing the issue before will now begin experiencing it.
>>
>>
>> The only clue I have is from this posting: http://grokbase.com/t
>> /gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>> "... If you do not see the error on every run then it is modulated by
>> something that varies between runs. That could be almost anything:
>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>
>>
>> Can anyone help me understand this issue, or help me get it resolved
>> permanently?
>>
>> When I search for answers, all I see are "You have written a duplicate
>> class in your module." However, in my case, I did not write the saz-rsyslog
>> module, I am only using it. It is a puppet-forge approved module with
>> 635,000+ downloads. And without modifying the module, the issue can
>> disappear, seemingly without rhyme or reason.
>>
>> -RG
>>
>
>
> Some more information
>
> I am using the latest version of the saz-rsyslog puppet module, version
> 4.0.3
> https://forge.puppet.com/saz/rsyslog
>
> As an example, I have this node called h1pa
> Yesterday afternoon this node was getting the reported duplicate
> Class[Rsyslog] declaration error
> The 12:15am update was the last report of this error
> The 12:45am update was the first clean update today
> In fact, I had 0 nodes reporting this error
>
> About 9:00am-ish we added a subnet and hostgroup to The Foreman. However
> we have not added any new nodes, nor changed the configuration to any
> existing nodes.
>
> Then, I started getting the error again
> The 9:15am update was the first report of this error this late morning
> The 9:45am update reported this error again
> My nodes reporting an error of this duplicate Class[Rsyslog] error
> increased from 0 to 12.
>
> All node reports with this error are similar to h1pa node's reports.
> I am seeing that many of the hosts experiencing this issue yesterday, are
> now experiencing it again.
>
> -RG
>
>
>
>
>
>
>
>
> --
> 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/a81931c8-14b3-46d8-94ba-1f31c4c4453a%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/a81931c8-14b3-46d8-94ba-1f31c4c4453a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT-PtvNQvFt2rp6YKrX_wMNuCMQLsgVrxHig3pxCEWf1Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

Not being a foreman user, I can't add a whole lot of detail to this, but it
does SEEM like there's something in the foreman "extras" that may be
conflicting with the direct puppet code in certain situations. My
understanding is that it provides some sort of overlay, and that could
definitely cause a conflict - it's easy with PE, for instance, to have the
Node Classifier and your puppet manifests on disk have collisions without
being obvious. I would look at what the "overlay" provides - whatever the
proper term is for it.


Rob Nelson
rnels...@gmail.com

On Fri, Oct 7, 2016 at 9:48 AM,  wrote:

> On Thursday, October 6, 2016 at 12:23:40 PM UTC-5, Rob Nelson wrote:
>>
>> Can you undo the change in foreman, see if the problem goes away, then
>> reimplement the change and see if the problem comes back? That would go a
>> long way toward isolating the cause.
>>
>>
> So I removed the rsyslog configuration from the foreman, the problem
> disappeared, then I added the rsyslog configuration back in and the problem
> immediately reappeared.
>
> The other configuration we added at 9:00am-ish  well we since added
> some very minor configuration changes for host parameters in the afternoon,
> and this problem went away. Nothing was touched after that. Then about 6
> hours ago, at 2:00am-ish, the problem reappeared.
> Then I removed the rsyslog configuration, after which the problem
> disappeared, then I re-added the rsyslog configuration and the problem
> reappeared.
>
>
>
>> On Thursday, October 6, 2016,  wrote:
>>
>>>
>>>
>>> On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu
>>> wrote:
>>>>
>>>> I installed the puppet module saz-rsyslog from puppet forge.
>>>> I use The Foreman to configure nodes. The Foreman is used by puppet via
>>>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>>>
>>>> Since the saz-rsyslog module install, I have been receiving the
>>>> following error off and on (not consistently) across many nodes on a puppet
>>>> update (i.e. puppet agent -t):
>>>>
>>>> "Could not retrieve catalog from remote server: Error 400 on SERVER:
>>>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare
>>>> on node "
>>>>
>>>>
>>>> My nodes are CentOS 5,6,7; and any various number of the nodes may
>>>> experience this issue, but not all of them at the same time.
>>>>
>>>> One day I will see dozens of server with this error, and other nodes
>>>> not having this issue. This may go on for days if I do not touch The
>>>> Foreman.
>>>> I'll make some changes to host configuration for puppet module class
>>>> parameters in The Foreman - never the saz-rsyslog module though..
>>>> After the changes, half or more of the servers having issue (not all)
>>>> will magically have no problems.
>>>> However, more nodes that did not have issues before, will now
>>>> experience this issue.
>>>>
>>>> Also, this change of events is not directly related to The Foreman host
>>>> configuration changes.
>>>> I can simply perform a puppet module upgrade to a unrelated module
>>>> (e.g. mine-yumconfig). After upgrading the unrelated module, again many
>>>> nodes with this issue will now have it resolved, and different ones not
>>>> experiencing the issue before will now begin experiencing it.
>>>>
>>>>
>>>> The only clue I have is from this posting: http://grokbase.com/t
>>>> /gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>>>> "... If you do not see the error on every run then it is modulated by
>>>> something that varies between runs. That could be almost anything:
>>>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>>>
>>>>
>>>> Can anyone help me understand this issue, or help me get it resolved
>>>> permanently?
>>>>
>>>> When I search for answers, all I see are "You have written a duplicate
>>>> class in your module." However, in my case, I did not write the saz-rsyslog
>>>> module, I am only using it. It is a puppet-forge approved module with
>>>> 635,000+ downloads. And without modifying the module, the issue can
>>>> disappear, seemingly without rhyme or reason.
>>>>
>>>> -RG
>>>>
>&g

Re: [Puppet Users] puppet 3 to 2016.4

[Rob Nelson]

Check out the docs at https://docs.puppet.com/upgrade/

On Tuesday, October 11, 2016, kevin  wrote:

> how does a enterprise work on the puppet moving on puppet 3 to 2016.4
>  can any one give me the complete description of all the steps included.
>
> --
> 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/1b80712a-f7f5-4e42-b547-52148b82fb81%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/1b80712a-f7f5-4e42-b547-52148b82fb81%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAC76iT95NbCJfgVd_fgXrCVWLts21vvzJugfE6hqPUZVSHuNzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.