[Puppet Users] How can we satisfy goals of having all data in hiera and not modifying the module code?

[JeremyCampbell]

We understand that all site specific data should be in Hiera. We also 
understand that modules shouldn't have to be modified when they are well 
designed e.g. the puppetlabs/apache module. However, how do I setup apache 
using this module with a virtual host without putting data into the 
manifest. E.g to create a vhost according to the docs we need to use:

apache::vhost { 'first.example.com':
  port=> '80',
  docroot => '/var/www/first',
}

As a define it would appear that we need to use create_resources() 
somewhere in the module and then create a hash in hiera e.g.

apache::my_vhosts:
  host1:
priority: "10"
vhost_name": "first.example.com"
port": "80"
docroot": "/var/www/first"

This means that we either need to put data into the manifest (e.g. first 
example) or to change the module code by implementing create_resources(). 
So how can we satisfy both goals of having all data in hiera and not 
modifying the module code?

-- 
You received this message because you are subscribed to the Google Groups 
"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/6f9aaec5-0503-488c-b70a-30887af5b353%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How can we satisfy goals of having all data in hiera and not modifying the module code?

[Juan Sierra Pons]

Hi,

You can create another abstration level and put all your specific
logic inside. Have a look to the roles & profiles literature on the
Internet.

For example create a apache profile (eg: webserver.pp) with the following:

include apache
create_resources(apache::my_vhosts,hiera_hash('apache::my_vhosts'))

This way you accomplishes the two requirements: do not touch the
module and put all your data on hiera :)

Best regards
--
Juan Sierra Pons j...@elsotanillo.net
Linux User Registered: #257202
Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo
GPG key = 0xA110F4FE
Key Fingerprint = DF53 7415 0936 244E 9B00  6E66 E934 3406 A110 F4FE
--

-- 
You received this message because you are subscribed to the Google Groups 
"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/CABS%3Dy9uC-AGkfQ%2B%3DW_Paf508Y4QGpEKNQ_fLy0tsbY2p2SmVzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How can we satisfy goals of having all data in hiera and not modifying the module code?

[Jim Ficarra]

You could setup setup the host-specific yaml as:

vhost:“first.example.com”
port:  “80”
priority:“10”
docroot:“/var/www/first”

Then your module:

$vhost = hiera(‘vhost’)
$port = hiera(‘port’)
$priority = hiera(‘priority’)
$docroot: = hiera(‘docroot’)

apache::vhost { $vhost:
  port=> $port,
  priority => $priority,
  docroot => $docroot,
}

This would allow you completely segregate the configuration from the data and 
not require modification of the module code unless something in the 
configuration changes.  You could use common.yaml for configuration data that 
applies to all hosts.


From: JeremyCampbell 
Sent: Monday, August 25, 2014 5:04 AM
To: puppet-users@googlegroups.com 
Subject: [Puppet Users] How can we satisfy goals of having all data in hiera 
and not modifying the module code?

We understand that all site specific data should be in Hiera. We also 
understand that modules shouldn't have to be modified when they are well 
designed e.g. the puppetlabs/apache module. However, how do I setup apache 
using this module with a virtual host without putting data into the manifest. 
E.g to create a vhost according to the docs we need to use:


apache::vhost { 'first.example.com':
  port=> '80',
  docroot => '/var/www/first',
}


As a define it would appear that we need to use create_resources() somewhere in 
the module and then create a hash in hiera e.g.


apache::my_vhosts:
  host1:
priority: "10"
vhost_name": "first.example.com"
port": "80"
docroot": "/var/www/first"


This means that we either need to put data into the manifest (e.g. first 
example) or to change the module code by implementing create_resources(). So 
how can we satisfy both goals of having all data in hiera and not modifying the 
module code?

-- 
You received this message because you are subscribed to the Google Groups 
"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/6f9aaec5-0503-488c-b70a-30887af5b353%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/7F6002FD5CA14856A2B8F6025998126D%40JimHPPavilionG6.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] How can we satisfy goals of having all data in hiera and not modifying the module code?

[JeremyCampbell]

That makes perfect sense and achieves exactly what we need. Thank you!

On Monday, August 25, 2014 11:34:06 AM UTC+2, Juan Sierra Pons wrote:
>
> Hi, 
>
> You can create another abstration level and put all your specific 
> logic inside. Have a look to the roles & profiles literature on the 
> Internet. 
>
> For example create a apache profile (eg: webserver.pp) with the following: 
>
> include apache 
> create_resources(apache::my_vhosts,hiera_hash('apache::my_vhosts')) 
>
> This way you accomplishes the two requirements: do not touch the 
> module and put all your data on hiera :) 
>
> Best regards 
> --
>  
>
> Juan Sierra Pons ju...@elsotanillo.net 
>  
> Linux User Registered: #257202 
> Web: http://www.elsotanillo.net Git: http://www.github.com/juasiepo 
> GPG key = 0xA110F4FE 
> Key Fingerprint = DF53 7415 0936 244E 9B00  6E66 E934 3406 A110 F4FE 
> --
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/d1135191-0e00-4897-bae6-aa537e46478a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet resource ordering/execution kungfu

[jcbollinger]

On Thursday, August 21, 2014 12:30:05 PM UTC-5, Wil Cooley wrote:
>
>
> On Aug 21, 2014 5:53 AM, "jcbollinger"  > wrote:
>
> > No new parameter, but you could also repackage your RPM so that it 
> handles the permissions of /tmp itself.
>
> I suspect that would conflict with the package that already owns /tmp 
> ("basefiles" or whatever it's called).
>
> It might be possible to remount with and then without exec in the pre and 
> post install scripts.
>

I see I was too terse.  Using the pre and post scripts is just what I had 
in mind, since I presume that the relaxed permissions should be in effect 
only during the RPM's installation.

 

> To avoid modifying the original package, it might be possible to use a 
> "wrapper" package that is nothing but the scripts & dependency, exploiting 
> the transactional ordering that the scripts would run in. (If my memory of 
> how that works is accurate.)
>

Maybe.  I think that might get pretty messy if you want to support package 
upgrades, but the advantage of using the original RPM unmodified is great.  
If one does want to modify the existing RPM, however, then it is possible 
to do so without a full rebuild.  RPM Rebuild 
 can help (don't get thrown by claims 
about rebuilding installed RPMs -- it works with uninstalled RPM files, 
too).
 

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/3bba4388-33b5-4c7b-b9fa-e026e92bd4dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet 'node data' when using common node_names?

[jcbollinger]

On Saturday, August 23, 2014 12:46:59 PM UTC-5, Matt W wrote:
>
> Will,
>   Thanks for the response. I know its a bit of a unique model -- but when 
> you think about it, it makes a decent amount of sense. We run hundreds of 
> nodes that are fundamentally similar
>


And therein is one of the key problems: "similar", not "identical".  If any 
node facts (including $hostname, $fqdn, etc.) vary among these hosts that 
are identifying themselves to the master as the *same machine*, then you 
are putting yourself at risk for problems.  Moreover, if security around 
your puppet catalogs is a concern for you, then be aware that positioning 
your node-type certificates as a shared resource makes it far more likely 
that they will be breached.  Additionally, you cannot limit which machines 
can get configuration from your master.

Lest it didn't catch your eye as it went by, I re-emphasize that Puppet is 
built around the idea that a machine's SSL certname is a unique machine 
identifier within the scope of your certificate authority.  What you are 
doing can work with Puppet, but you will run into issues such as the file 
naming effects you asked about.

 

> .. i.e. "this is a web server, it gets the XYZ package installed" and 
> "this is a web server, it gets the ABC package installed". Using hostnames 
> to identify the systems node-definition makes very little sense and leaves 
> quite a bit of room for error. Explicitly setting the node-type as a fact 
> allows us to re-use the same node types but for many different environments 
> and keeps host-names out of the mix.
>


Classifying based on a fact instead of based on host name is a fine idea, 
provided that you are willing to trust clients to give their type 
accurately to the server.  Having accepted that risk, however, you do not 
by any means need the node-type fact to be expressed to the master as the 
node's *identity*.  It could as easily be expressed via an ordinary fact.

In particular, your site manifest does not need a separate node block for 
each node [identity], nor even to enumerate all the known node names.  In 
fact, it doesn't need any node blocks at all if you are not going to 
classify based on node identity.  Even if you're using an ENC, it is 
possible for it to get the node facts to use for classification.

 

> For example, I can quickly boot up a 
> "prod-mwise-dev-test-web-sever-thingy" using the same node definition as 
> our "prod-frontend-host" for some testing, without worrying about the 
> hostname regex structure.
>


And you could do that, too, with a plain fact.

 

>
>   Anyways that said ... what I'm really interested in knowing is why the 
> puppet-agents are pulling DOWN their "node information" from the puppet 
> masters?
>


Can you say a bit more about that?  What do you see that suggests agents 
are pulling down "node information" other than their catalogs (and later, 
any 'source'd files)?


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/b93f6baa-6433-4773-b647-a06b1f1c602c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Cisco: No error, but no Applying

[jcbollinger]

On Friday, August 22, 2014 3:36:33 PM UTC-5, Nan Liu wrote:
>
> On Fri, Aug 22, 2014 at 12:10 PM, Nathan Brito  > wrote:
>
>> I'm trying to apply settings on a Cisco Catalyst 2960S through the 
>> puppet, but I can not. 
>>
>> When I give the "device #puppet verbose" command, the puppet does not 
>> return me error but does not apply the manifest. 
>>
>>
>> *Follows the return of the command:*
>>
>> #puppet device --verbose
>>> Info: starting applying configuration to switch.mydomain at 
>>> telnet://admin:admin@switch.mydomain
>>> Info: Retrieving pluginfacts
>>> Info: Retrieving plugin
>>> Info: Caching catalog for switch.mydomain
>>> Info: Applying configuration version '1408732346'
>>> Notice: Finished catalog run in 0.05 seconds
>>
>>
>>
>> */etc/puppet/puppet.conf:*
>>
>> [main]
>>> logdir=/var/log/puppet
>>> vardir=/var/lib/puppet
>>> ssldir=/var/lib/puppet/ssl
>>> rundir=/var/run/puppet
>>> factpath=$vardir/lib/facter
>>> #templatedir=$confdir/templates
>>> [master]
>>> # These are needed when the puppetmaster is run by passenger
>>> # and can safely be removed if webrick is used.
>>> ssl_client_header = SSL_CLIENT_S_DN
>>> ssl_client_verify_header = SSL_CLIENT_VERIFY
>>> dns_alt_names = puppetmaster,puppetmaster.mydomain
>>
>>
>> */etc/puppet/device.conf*
>>
>> [switch.mydomain]
>>> type cisco
>>> url telnet://admin:admin@switch.mydomain
>>>
>>
>>  
>> *Manifest: /etc/puppet/manifests/switch.pp*
>>  
>>
>>> interface {
>>>   "GigabitEthernet0/1":
>>> description => "puppet test",
>>> }
>>> }
>>
>>
>
> I think this needs to be under a node that matches your device.conf 
> setting, so site.pp:
>
> node switch.mydomain {
>   interface { ...
>   }
> } 
>
>

Although there does need to be something that causes Puppet to associate 
the declarations in manifests/switch.pp with the node, that doesn't 
necessarily need to be a node block in site.pp.  Putting the declaration at 
top-level in site.pp should be enough.  Alternatively, if the master is 
recent enough to support directory environments, then turning on that 
feature would probably yield the desired behavior.

With that said, resource declarations -- such as for 
Interface['GigabitEthernet0/1'] -- normally should not be placed at top 
scope.  They should be in classes (in modules) or node blocks, instead.


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/7d378141-3b27-49fc-b381-b0e507030379%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Confused Puppet Manifest ... Possible caching issue?

[jcbollinger]

On Friday, August 22, 2014 9:38:20 AM UTC-5, Matt W wrote:
>
> Even with the caching disabled, I think we ran into this again. Can one of 
> the puppet-devs chime in here and let me know what might be going on?
>
>

I am not among the Puppet developers, but I think I already touched on the 
likely problem in your other thread.  You have multiple nodes are 
identifying themselves to Puppet as the same machine, and if you rely on 
facts that differ among identity-sharing nodes then you are poking at 
exactly the point where your shared-identity model breaks down.

Even so, I think your approach would probably work if you serialized 
catalog requests, e.g. by using the built-in webrick server, since it seems 
likely that you are experiencing a race on the server.  Specifically, I 
suspect you'll find that those calls to the REST API are all originating 
from the master itself.  If an ENC is in use then it would be high on my 
list of suspects.


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/17f251ea-b694-4c65-9b92-7150b693ba3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] how to force a zypper refresh?

[randal cobb]

Hello all,

I'm trying to solve an issue with Puppet and I'm hoping you can help guide 
me.  We have an internal YUM repository that we build/deploy to quite 
frequently, and several of the artifacts we publish to that repository need 
to be pushed out (via puppet) to servers a couple of times per day.   All 
of my servers are SLES or openSuse based, and thus use Zypper.  My question 
is, since the repository gets updated frequently and zypper doesn't refresh 
repository indexes by itself, is there a way to force a zypper refresh 
ALWAYS as the first task in a manifest?

I've tried adding an exec item in a sample machine's manifest and having 
all the "packages" require it, but it isn't doing what I expect.  It never 
seems to run the "refresh" prior to trying to install any packages.  Here 
are a few snippets from my manifest structure:

in base.pp:
exec { zypper-refresh:
command => 'zypper --no-gpg-checks refresh',
path => ["/usr/bin", "/bin", "/sbin"],
}


package { "puppet":
ensure => installed,
require => Exec['zypper-refresh'],
}


package { "augeas":
ensure => present,
require => Package['puppet'],
}


package { "rubygem-ruby-augeas":
ensure => present,
require => Package['augeas'],
}


in test-server.pp (which inherits base.pp)
package { 'geany':
ensure => installed,
require => Exec['zypper-refresh'],
}

package { 'myjavamodule_xx':
ensure => installed,
require => Exec['zypper-refresh'],
}


etc.

Any suggestions? 

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

Re: [Puppet Users] Cisco: No error, but no Applying

[Nathan Brito]

sorry, I posted missing content. 
I had already specified node. 
Follow the correct manifest: 

node switch.mydomain {
>interface {
>   "GigabitEthernet1/0/1":
>description => "teste",
>}
> }


yet the problem continues.

Em sexta-feira, 22 de agosto de 2014 17h36min33s UTC-3, Nan Liu escreveu:
>
> On Fri, Aug 22, 2014 at 12:10 PM, Nathan Brito  > wrote:
>
>> I'm trying to apply settings on a Cisco Catalyst 2960S through the 
>> puppet, but I can not. 
>>
>> When I give the "device #puppet verbose" command, the puppet does not 
>> return me error but does not apply the manifest. 
>>
>>
>> *Follows the return of the command:*
>>
>> #puppet device --verbose
>>> Info: starting applying configuration to switch.mydomain at 
>>> telnet://admin:admin@switch.mydomain
>>> Info: Retrieving pluginfacts
>>> Info: Retrieving plugin
>>> Info: Caching catalog for switch.mydomain
>>> Info: Applying configuration version '1408732346'
>>> Notice: Finished catalog run in 0.05 seconds
>>
>>
>>
>> */etc/puppet/puppet.conf:*
>>
>> [main]
>>> logdir=/var/log/puppet
>>> vardir=/var/lib/puppet
>>> ssldir=/var/lib/puppet/ssl
>>> rundir=/var/run/puppet
>>> factpath=$vardir/lib/facter
>>> #templatedir=$confdir/templates
>>> [master]
>>> # These are needed when the puppetmaster is run by passenger
>>> # and can safely be removed if webrick is used.
>>> ssl_client_header = SSL_CLIENT_S_DN
>>> ssl_client_verify_header = SSL_CLIENT_VERIFY
>>> dns_alt_names = puppetmaster,puppetmaster.mydomain
>>
>>
>> */etc/puppet/device.conf*
>>
>> [switch.mydomain]
>>> type cisco
>>> url telnet://admin:admin@switch.mydomain
>>>
>>
>>  
>> *Manifest: /etc/puppet/manifests/switch.pp*
>>  
>>
>>> interface {
>>>   "GigabitEthernet0/1":
>>> description => "puppet test",
>>> }
>>> }
>>
>>
>
> I think this needs to be under a node that matches your device.conf 
> setting, so site.pp:
>
> node switch.mydomain {
>   interface { ...
>   }
> } 
>
> HTH,
>
> Nan
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/5363ef17-90ee-46f0-aec1-bee39e00556a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] how to force a zypper refresh?

[Darin Perusich]

Use the zypprepo module to managing your zypper repositories.

https://forge.puppetlabs.com/darin/zypprepo

puppet module install darin-zypprepo
--
Later,
Darin


On Mon, Aug 25, 2014 at 10:35 AM, randal cobb  wrote:
> Hello all,
>
> I'm trying to solve an issue with Puppet and I'm hoping you can help guide
> me.  We have an internal YUM repository that we build/deploy to quite
> frequently, and several of the artifacts we publish to that repository need
> to be pushed out (via puppet) to servers a couple of times per day.   All of
> my servers are SLES or openSuse based, and thus use Zypper.  My question is,
> since the repository gets updated frequently and zypper doesn't refresh
> repository indexes by itself, is there a way to force a zypper refresh
> ALWAYS as the first task in a manifest?
>
> I've tried adding an exec item in a sample machine's manifest and having all
> the "packages" require it, but it isn't doing what I expect.  It never seems
> to run the "refresh" prior to trying to install any packages.  Here are a
> few snippets from my manifest structure:
>
> in base.pp:
> exec { zypper-refresh:
> command => 'zypper --no-gpg-checks refresh',
> path => ["/usr/bin", "/bin", "/sbin"],
> }
>
>
> package { "puppet":
> ensure => installed,
> require => Exec['zypper-refresh'],
> }
>
>
> package { "augeas":
> ensure => present,
> require => Package['puppet'],
> }
>
>
> package { "rubygem-ruby-augeas":
> ensure => present,
> require => Package['augeas'],
> }
>
>
> in test-server.pp (which inherits base.pp)
> package { 'geany':
> ensure => installed,
> require => Exec['zypper-refresh'],
> }
>
> package { 'myjavamodule_xx':
> ensure => installed,
> require => Exec['zypper-refresh'],
> }
>
>
> etc.
>
> Any suggestions?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/a98d4d09-c0a0-480e-8904-adf075179a8e%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/CADaviKsO4GOt%3D9v-bQnW3jduAUR_q%2B1BiuUuTcNJDyjAZcuHoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Confused Puppet Manifest ... Possible caching issue?

[Matt Wise]

Its tricky because we use an ELB in front of the puppet masters, and we
know that the calls to the /node/ REST API are coming from the
ELB, but because of the way we have the ELB configured (pure TCP
passthrough), we don't get the extra headers like the x_forwarded_for
header. This makes it hard to tell where the requests for the node
information are coming from. That said, it feels odd that the puppet master
itself would reach out to its own Node API to get node information, rather
than just using the information passed in for the catalog request.

Matt Wise
Sr. Systems Architect
Nextdoor.com


On Mon, Aug 25, 2014 at 7:29 AM, jcbollinger 
wrote:

>
>
> On Friday, August 22, 2014 9:38:20 AM UTC-5, Matt W wrote:
>>
>> Even with the caching disabled, I think we ran into this again. Can one
>> of the puppet-devs chime in here and let me know what might be going on?
>>
>>
>
> I am not among the Puppet developers, but I think I already touched on the
> likely problem in your other thread.  You have multiple nodes are
> identifying themselves to Puppet as the same machine, and if you rely on
> facts that differ among identity-sharing nodes then you are poking at
> exactly the point where your shared-identity model breaks down.
>
> Even so, I think your approach would probably work if you serialized
> catalog requests, e.g. by using the built-in webrick server, since it seems
> likely that you are experiencing a race on the server.  Specifically, I
> suspect you'll find that those calls to the REST API are all originating
> from the master itself.  If an ENC is in use then it would be high on my
> list of suspects.
>
>
> 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/EorzYWGEUUE/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/17f251ea-b694-4c65-9b92-7150b693ba3e%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/CAOHkZxMg_RZPTAVnFa3sfTc41hjHgCB1FBLbhD7MNBnCaNoU0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Facts as arrays?

[Peter Berghold]

Hi,

I'm studying the custom facts examples and I noticed that facts tend to be
scalars. (Perl speak)

Are they ever arrays?  For instance I want to write a custom fact that
parses the /etc/fstab and returns the mounted file systems as a fact to
allow amanda to be automagically configured to back up my servers.

Thoughts?

-- 

Peter L. Berghold   salty.cowd...@gmail.com

http://blog.berghold.net

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAArvnv3ZWHYsZbaJXPje%3D4UCAsArETrmcfSAjp1502UXxPwk%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] how to force a zypper refresh?

[randal cobb]

Thanks for the very quick reply!  I'll give that a shot.

On Monday, August 25, 2014 11:37:26 AM UTC-4, Darin Perusich wrote:
>
> Use the zypprepo module to managing your zypper repositories. 
>
> https://forge.puppetlabs.com/darin/zypprepo 
>
> puppet module install darin-zypprepo 
> -- 
> Later, 
> Darin 
>
>
> On Mon, Aug 25, 2014 at 10:35 AM, randal cobb  > wrote: 
> > Hello all, 
> > 
> > I'm trying to solve an issue with Puppet and I'm hoping you can help 
> guide 
> > me.  We have an internal YUM repository that we build/deploy to quite 
> > frequently, and several of the artifacts we publish to that repository 
> need 
> > to be pushed out (via puppet) to servers a couple of times per day.   
> All of 
> > my servers are SLES or openSuse based, and thus use Zypper.  My question 
> is, 
> > since the repository gets updated frequently and zypper doesn't refresh 
> > repository indexes by itself, is there a way to force a zypper refresh 
> > ALWAYS as the first task in a manifest? 
> > 
> > I've tried adding an exec item in a sample machine's manifest and having 
> all 
> > the "packages" require it, but it isn't doing what I expect.  It never 
> seems 
> > to run the "refresh" prior to trying to install any packages.  Here are 
> a 
> > few snippets from my manifest structure: 
> > 
> > in base.pp: 
> > exec { zypper-refresh: 
> > command => 'zypper --no-gpg-checks refresh', 
> > path => ["/usr/bin", "/bin", "/sbin"], 
> > } 
> > 
> > 
> > package { "puppet": 
> > ensure => installed, 
> > require => Exec['zypper-refresh'], 
> > } 
> > 
> > 
> > package { "augeas": 
> > ensure => present, 
> > require => Package['puppet'], 
> > } 
> > 
> > 
> > package { "rubygem-ruby-augeas": 
> > ensure => present, 
> > require => Package['augeas'], 
> > } 
> > 
> > 
> > in test-server.pp (which inherits base.pp) 
> > package { 'geany': 
> > ensure => installed, 
> > require => Exec['zypper-refresh'], 
> > } 
> > 
> > package { 'myjavamodule_xx': 
> > ensure => installed, 
> > require => Exec['zypper-refresh'], 
> > } 
> > 
> > 
> > etc. 
> > 
> > Any suggestions? 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to puppet-users...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/a98d4d09-c0a0-480e-8904-adf075179a8e%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/2e324cae-7005-4ef5-b294-b4cc99eac71e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet 'node data' when using common node_names?

[Matt Wise]

Comments inline

Matt Wise
Sr. Systems Architect
Nextdoor.com


On Mon, Aug 25, 2014 at 6:55 AM, jcbollinger 
wrote:

>
>
> On Saturday, August 23, 2014 12:46:59 PM UTC-5, Matt W wrote:
>>
>> Will,
>>   Thanks for the response. I know its a bit of a unique model -- but when
>> you think about it, it makes a decent amount of sense. We run hundreds of
>> nodes that are fundamentally similar
>>
>
>
> And therein is one of the key problems: "similar", not "identical".  If
> any node facts (including $hostname, $fqdn, etc.) vary among these hosts
> that are identifying themselves to the master as the *same machine*, then
> you are putting yourself at risk for problems.  Moreover, if security
> around your puppet catalogs is a concern for you, then be aware that
> positioning your node-type certificates as a shared resource makes it far
> more likely that they will be breached.  Additionally, you cannot limit
> which machines can get configuration from your master.
>

To be very clear, we do not share certs across nodes. We absolutely use
independent certs and sign them uniquely -- in fact, bug #7244
 was opened by me specifically
for improving the security around SSL certs and auto signing. We make heavy
use of dynamic CSR facts to securely sign our keys.

More specifically, we've been waiting for the CSR attribute system to allow
us to embed the puppet 'node type' (note, not identifier) in the SSL certs
so that clients can't possibly retrieve a node type that isn't their own. (Bug
#7243 ). It looks like this
has been finally implemented, so we'll be looking into using it very soon (
here

).


>
> Lest it didn't catch your eye as it went by, I re-emphasize that Puppet is
> built around the idea that a machine's SSL certname is a unique machine
> identifier within the scope of your certificate authority.  What you are
> doing can work with Puppet, but you will run into issues such as the file
> naming effects you asked about.
>
>
>
>> .. i.e. "this is a web server, it gets the XYZ package installed" and
>> "this is a web server, it gets the ABC package installed". Using hostnames
>> to identify the systems node-definition makes very little sense and leaves
>> quite a bit of room for error. Explicitly setting the node-type as a fact
>> allows us to re-use the same node types but for many different environments
>> and keeps host-names out of the mix.
>>
>
>
> Classifying based on a fact instead of based on host name is a fine idea,
> provided that you are willing to trust clients to give their type
> accurately to the server.  Having accepted that risk, however, you do not
> by any means need the node-type fact to be expressed to the master as the
> node's *identity*.  It could as easily be expressed via an ordinary fact.
>
> In particular, your site manifest does not need a separate node block for
> each node [identity], nor even to enumerate all the known node names.  In
> fact, it doesn't need any node blocks at all if you are not going to
> classify based on node identity.  Even if you're using an ENC, it is
> possible for it to get the node facts to use for classification.
>

Using a combination of both our nodes self-identifying themselves as well
as the puppet node name architecture allows us to leverage the security of
the 'auth' config file, while also having dynamically configured nodes
where hostname doesn't matter. Realistically, hostnames are a terrible
method for security ... someone could always break into a 'www' server and
rename it to 'prod-db-thingy' and have it match the regex and subsequently
get the database puppet manifest. (Just as a stupid simple example).

For what its worth, our old model was a single 'default' node type and a
simple fact ('base_class=my_web_server'). This worked extremely well, but
left us more open to basically any client being able to request any catalog
compilation. The auth-file in this world was effectively useless for
preventing already-verified nodes from doing bad things.

>
>
>
>> For example, I can quickly boot up a "prod-mwise-dev-test-web-sever-thingy"
>> using the same node definition as our "prod-frontend-host" for some
>> testing, without worrying about the hostname regex structure.
>>
>
>
> And you could do that, too, with a plain fact.
>
>
>
>>
>>   Anyways that said ... what I'm really interested in knowing is why the
>> puppet-agents are pulling DOWN their "node information" from the puppet
>> masters?
>>
>
>
> Can you say a bit more about that?  What do you see that suggests agents
> are pulling down "node information" other than their catalogs (and later,
> any 'source'd files)?
>
>
With nearly every puppet catalog compile, we also see GET requests like
this:

10.216.61.76 - XXX - puppet "GET /production/node/xyz? HTTP/1.1" 200 1373

Re: [Puppet Users] Facts as arrays?

[Christopher Wood]

On Mon, Aug 25, 2014 at 12:01:03PM -0400, Peter Berghold wrote:
>Hi, 
>I'm studying the custom facts examples and I noticed that facts tend to be
>scalars. (Perl speak) 
>Are they ever arrays?  For instance I want to write a custom fact that
>parses the /etc/fstab and returns the mounted file systems as a fact to
>allow amanda to be automagically configured to back up my servers. 
>Thoughts?

That's a "try it and see", if you have the correct version:

https://docs.puppetlabs.com/facter/2.0/fact_overview.html#writing-structured-facts

However, for having bits of one server configure bits on another, you may get 
some mileage out of exported resources:

https://docs.puppetlabs.com/puppet/latest/reference/lang_exported.html
https://docs.puppetlabs.com/puppet/latest/reference/lang_collectors.html
https://docs.puppetlabs.com/guides/exported_resources.html

More specifically, that your random nodes would export resources consisting of 
"amanda configuration fragment", whether files or something else. Then your 
amanda host would collect these resources to have its list of things to back 
up. You will need somewhere to store exported resources and/or facts, you will 
likely want this thing:

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

Also dig around on the forge, it has interesting things to read over.

https://forge.puppetlabs.com/pdxcat/amanda

(At my current place we export ssh host keys, which are collected elsewhere to 
list hosts available to mcollective clients. Same generic idea.)


>--
> 
>Peter L. Berghold   [1]salty.cowd...@gmail.com
> 
>[2]http://blog.berghold.net
> 
>--
>You received this message because you are subscribed to the Google Groups
>"Puppet Users" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to [3]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [4]https://groups.google.com/d/msgid/puppet-users/CAArvnv3ZWHYsZbaJXPje%3D4UCAsArETrmcfSAjp1502UXxPwk%2Bw%40mail.gmail.com.
>For more options, visit [5]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:salty.cowd...@gmail.com
>2. http://blog.berghold.net/
>3. mailto:puppet-users+unsubscr...@googlegroups.com
>4. 
> https://groups.google.com/d/msgid/puppet-users/CAArvnv3ZWHYsZbaJXPje%3D4UCAsArETrmcfSAjp1502UXxPwk%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer
>5. 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/20140825161941.GA3753%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] "Server configurations require Augeas >= 1.0.0" on Ubuntu 14.04 LTS puppetmaster

[Morgan Haskel]

Trey,

The '>= 1.0.0' is referring to the libaugeas version, and it's based on the
`augeasversion` fact.  You'll need to have augeas installed on the node
you're trying to include tomcat on.

Morgan


On Sun, Aug 24, 2014 at 12:38 PM, Trey Duskin  wrote:

> Hi all,
>
> I'm trying to get a module to work (puppetlabs-tomcat) which uses Augeas
> to manage a config file.  However, whenever I try to compile the manifest
> which includes this module, I get an error on the puppet master:
>
> Server configurations require Augeas >= 1.0.0 at
> /etc/puppet/modules/tomcat/manifests/config/server/connector.pp:28
>
> I have installed augeas on the puppet master machine using the
> camptocamp-augeas module as follows in my site.pp:
>
> node 'puppet' {
>   include augeas
> }
>
> From the documentation, I think this is all I need to do to get Augeas
> installed on the puppet master so it can use the augeas support.  dpkg -l
> seems to confirm this:
>
> ubuntu@puppet:~$ dpkg -l | grep augeas
> ii  augeas-lenses1.2.0-0ubuntu1all
>  Set of lenses needed by libaugeas0 to parse config files
> ii  augeas-tools 1.2.0-0ubuntu1.1  amd64
>  Augeas command line tools
> ii  libaugeas-ruby1.9.1  0.5.0-2   all
>  Transitional package for ruby-augeas
> ii  libaugeas0   1.2.0-0ubuntu1amd64
>  Augeas configuration editing library and API
> ii  ruby-augeas  0.5.0-2   amd64
>  Augeas bindings for the Ruby language
>
> However, I keep getting this error.  Is the ">= 1.0.0" message referring
> to the version of the ruby bindings?  Or am I missing something else
> entirely?
>
> I am using puppetmaster and puppet agent directly from the Puppet Labs APT
> repo, which gave me 3.6.2
>
> Thanks in advance,
> Trey
>
> --
> You received this message because you are subscribed to the Google Groups
> "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/7b385fdc-8660-4765-89ae-dd7fdca2f4d1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Morgan Haskel
mor...@puppetlabs.com
Module Engineer

*Join us at PuppetConf 2014 , September
20-24 in San Francisco*
*Register by September 8th to take advantage of the Final Countdown

*
*—**save $149!*

-- 
You received this message because you are subscribed to the Google Groups 
"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/CA%2BFnDv26cJtUB17thXBGs2W73QEwTpcUuD1x_dEDYMStv855Gg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts as arrays?

[Peter Berghold]

Facter.add(:mounted_fs) do
setcode do
i=0
mountedfs = []
f=open("|egrep 'ext|reiser' /etc/fstab")
x=f.read
f.close
x.split(/[\n]+/).each do |line|
fields=line.split(/[\s\n\t]+/)
mountedfs[i]=fields[1]
i = i+1
end
mountedfs
end

end

ok... so why doesn't mounted_fs show up in facts?  what am I missing?  (my
first fact as a matter of fact)



On Mon, Aug 25, 2014 at 12:19 PM, Christopher Wood <
christopher_w...@pobox.com> wrote:

> On Mon, Aug 25, 2014 at 12:01:03PM -0400, Peter Berghold wrote:
> >Hi,
> >I'm studying the custom facts examples and I noticed that facts tend
> to be
> >scalars. (Perl speak)
> >Are they ever arrays?  For instance I want to write a custom fact that
> >parses the /etc/fstab and returns the mounted file systems as a fact
> to
> >allow amanda to be automagically configured to back up my servers.
> >Thoughts?
>
> That's a "try it and see", if you have the correct version:
>
>
> https://docs.puppetlabs.com/facter/2.0/fact_overview.html#writing-structured-facts
>
> However, for having bits of one server configure bits on another, you may
> get some mileage out of exported resources:
>
> https://docs.puppetlabs.com/puppet/latest/reference/lang_exported.html
> https://docs.puppetlabs.com/puppet/latest/reference/lang_collectors.html
> https://docs.puppetlabs.com/guides/exported_resources.html
>
> More specifically, that your random nodes would export resources
> consisting of "amanda configuration fragment", whether files or something
> else. Then your amanda host would collect these resources to have its list
> of things to back up. You will need somewhere to store exported resources
> and/or facts, you will likely want this thing:
>
> https://docs.puppetlabs.com/puppetdb/
>
> Also dig around on the forge, it has interesting things to read over.
>
> https://forge.puppetlabs.com/pdxcat/amanda
>
> (At my current place we export ssh host keys, which are collected
> elsewhere to list hosts available to mcollective clients. Same generic
> idea.)
>
>
> >--
> >
> >Peter L. Berghold   [1]salty.cowd...@gmail.com
> >
> >[2]http://blog.berghold.net
> >
> >--
> >You received this message because you are subscribed to the Google
> Groups
> >"Puppet Users" group.
> >To unsubscribe from this group and stop receiving emails from it,
> send an
> >email to [3]puppet-users+unsubscr...@googlegroups.com.
> >To view this discussion on the web visit
> >[4]
> https://groups.google.com/d/msgid/puppet-users/CAArvnv3ZWHYsZbaJXPje%3D4UCAsArETrmcfSAjp1502UXxPwk%2Bw%40mail.gmail.com
> .
> >For more options, visit [5]https://groups.google.com/d/optout.
> >
> > References
> >
> >Visible links
> >1. mailto:salty.cowd...@gmail.com
> >2. http://blog.berghold.net/
> >3. mailto:puppet-users+unsubscr...@googlegroups.com
> >4.
> https://groups.google.com/d/msgid/puppet-users/CAArvnv3ZWHYsZbaJXPje%3D4UCAsArETrmcfSAjp1502UXxPwk%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer
> >5. 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/20140825161941.GA3753%40iniquitous.heresiarch.ca
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Peter L. Berghold   salty.cowd...@gmail.com

http://blog.berghold.net

-- 
You received this message because you are subscribed to the Google Groups 
"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/CAArvnv0S4KkeDui9OBLpX-%3DrTRNa%3DW%2BqLL0X3nnUcqAih8fJSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Facts as arrays?

[Christopher Wood]

Well good, because it's now my second. ;)

Are you running facter -p, to pull in puppet-specific facts?

https://docs.puppetlabs.com/facter/latest/core_facts.html#summary

Have you seen pluginsync pull this fact to the agent node (look in syslog, 
/var/log/messages on redhat derivatives)?

https://docs.puppetlabs.com/guides/plugins_in_modules.html

Are you running facter with a user that has read permissions on the full path 
to /var/lib/puppet/lib/facter/yourfactfile.rb? 

You can try dumping the fact into /var/lib/puppet/lib/facter on your local 
machine to test it (remember about file permissions). I tried your fact and it 
worked as root, not as me, due to 750 permissions on /var/lib/puppet. If it 
works for you but not for puppet after you've seen pluginsync work then 
something is pretty odd. At this point I'd start reading agent output in debug 
mode to see what gives after using that fact in a manifest.






On Mon, Aug 25, 2014 at 04:06:04PM -0400, Peter Berghold wrote:
>Facter.add(:mounted_fs) do
>        setcode do
>                i=0
>                mountedfs = []
>                f=open("|egrep 'ext|reiser' /etc/fstab")
>                x=f.read
>                f.close
>                x.split(/[\n]+/).each do |line|
>                        fields=line.split(/[\s\n\t]+/)
>                        mountedfs[i]=fields[1]
>                        i = i+1
>                end
>        mountedfs
>        end
>end
>ok... so why doesn't mounted_fs show up in facts?  what am I missing?  (my
>first fact as a matter of fact)
> 
>On Mon, Aug 25, 2014 at 12:19 PM, Christopher Wood
><[1]christopher_w...@pobox.com> wrote:
> 
>  On Mon, Aug 25, 2014 at 12:01:03PM -0400, Peter Berghold wrote:
>  >    Hi, 
>  >    I'm studying the custom facts examples and I noticed that facts
>  tend to be
>  >    scalars. (Perl speak) 
>  >    Are they ever arrays?  For instance I want to write a custom fact
>  that
>  >    parses the /etc/fstab and returns the mounted file systems as a
>  fact to
>  >    allow amanda to be automagically configured to back up my servers. 
>  >    Thoughts?
> 
>  That's a "try it and see", if you have the correct version:
> 
>  
> [2]https://docs.puppetlabs.com/facter/2.0/fact_overview.html#writing-structured-facts
> 
>  However, for having bits of one server configure bits on another, you
>  may get some mileage out of exported resources:
> 
>  [3]https://docs.puppetlabs.com/puppet/latest/reference/lang_exported.html
>  
> [4]https://docs.puppetlabs.com/puppet/latest/reference/lang_collectors.html
>  [5]https://docs.puppetlabs.com/guides/exported_resources.html
> 
>  More specifically, that your random nodes would export resources
>  consisting of "amanda configuration fragment", whether files or
>  something else. Then your amanda host would collect these resources to
>  have its list of things to back up. You will need somewhere to store
>  exported resources and/or facts, you will likely want this thing:
> 
>  [6]https://docs.puppetlabs.com/puppetdb/
> 
>  Also dig around on the forge, it has interesting things to read over.
> 
>  [7]https://forge.puppetlabs.com/pdxcat/amanda
> 
>  (At my current place we export ssh host keys, which are collected
>  elsewhere to list hosts available to mcollective clients. Same generic
>  idea.)
> 
>  >    --
>  >
>  >    Peter L. Berghold  
>  [1][8]salty.cowd...@gmail.com
>  >
>  >    [2][9]http://blog.berghold.net
>  >
>  >    --
>  >    You received this message because you are subscribed to the Google
>  Groups
>  >    "Puppet Users" group.
>  >    To unsubscribe from this group and stop receiving emails from it,
>  send an
>  >    email to [3][10]puppet-users+unsubscr...@googlegroups.com.
>  >    To view this discussion on the web visit
>  >   
>  
> [4][11]https://groups.google.com/d/msgid/puppet-users/CAArvnv3ZWHYsZbaJXPje%3D4UCAsArETrmcfSAjp1502UXxPwk%2Bw%40mail.gmail.com.
>  >    For more options, visit [5][12]https://groups.google.com/d/optout.
>  >
>  > References
>  >
>  >    Visible links
>  >    1. mailto:[13]salty.cowd...@gmail.com
>  >    2. [14]http://blog.berghold.net/
>  >    3. mailto:[15]puppet-users+unsubscr...@googlegroups.com
>  >    4.
>  
> [16]https://groups.google.com/d/msgid/puppet-users/CAArvnv3ZWHYsZbaJXPje%3D4UCAsArETrmcfSAjp1502UXxPwk%2Bw%40mail.gmail.com?utm_medium=email&utm_source=footer
>  >    5. [17]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 [18]puppet-users+unsubscr...@googlegroups.com.
> 

Re: [Puppet Users] Confused Puppet Manifest ... Possible caching issue?

[Felix Frank]

On 08/14/2014 07:24 PM, Matt Wise wrote:
>
> 1. What is the purpose of calling the Node API? Is the agent doing
> this? Why?

That's a good one. Does your log not indicating where those calls originate?

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBA5C9.3020804%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Monkey patch puppet type

[Felix Frank]

On 08/24/2014 08:04 AM, Mickaël Canévet wrote:
> Hello,
>
> I'd like to know if there is a way to monkey patch a puppet type for
> example to add an auto requirement:
>
> https://github.com/puppetlabs/puppetlabs-firewall/pull/380/files
>
> Thanks,
> Mickaël

Well, you can always maintain your personal fork of the firewall module,
and include that patch.

For core types, you will have to build your own packages (if that's how
you install your agents).

Is that what you're asking?

Best,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBA71C.5090405%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Confused Puppet Manifest ... Possible caching issue?

[Matt Wise]

The log shows the remote connecting IP -- but the IP is the ELB in front of
our puppet servers. Unfortunately because we're doing pure TCP-passthrough,
ELB logging itself is not useful either in this case. :/

Matt Wise
Sr. Systems Architect
Nextdoor.com


On Mon, Aug 25, 2014 at 2:08 PM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:

> On 08/14/2014 07:24 PM, Matt Wise wrote:
> >
> > 1. What is the purpose of calling the Node API? Is the agent doing
> > this? Why?
>
> That's a good one. Does your log not indicating where those calls
> originate?
>
> --
> 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/EorzYWGEUUE/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/53FBA5C9.3020804%40Alumni.TU-Berlin.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/CAOHkZxO%3DEXgLJ_iHeo%3DOY2bW83DmTJyr-5x%2BNGS1POpc9Zc4mQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] agent needs to get info from another agent (dependency)

[Felix Frank]

Hi,

yes, you will need exported resources, and it won't be an easy design at
all.

I imagine it would work roughly like this (assuming Agent 1 runs
central_server and Agents 2 and 3 run slave_server instances).

Sketch of the manifest for the central server:

class central_server {
concat { '/etc/server_config': ... }
Central_server_snippet<<| tag == 'this-cluster' |>>
}

define central_server_snippet($slave_name) {
concat::fragment { "central-server-$name":
  target => '/etc/server_config',
  content => "something-with $slave_name\n";
}
@@slave_server_snippet { "for-$name": content => "something-with
$ipaddress" }
}

The slave servers do:

class slave_server {
@@central_server_snippet { "$fqdn": slave_name => "$hostname" }
Slave_server_snippet<<| title == "for-$fqdn" |>>
}

The idea being that the central server will not export its settings to
the slaves before they have exported their respective names to him.

Untested and incomplete. YMMV.

Cheers,
Felix

On 08/22/2014 03:13 PM, Sai Kothapalle wrote:
> Hi,
>
>  Here is my unique case. I have a speech search application for which
> the standard installation is to install the application components on
> 3 nodes or agents. The components have the following depency
>
>   *  Agent 1 needs hostname of agent 2 and agent 3 which is written
> into a config file
>   *  Agent 2 and Agent 3 need the private IP address of Agent 1 to be
> written into a config file which it uses while starting up the
> service.
>
> I am able to install the packages using puppet and load the config
> files using erb templates. However, I am unsure of how to go about the
> dependency between agents. Did lookup Exported resources but while the
> syntax gives an option to export a type, how do I export IP address
> etc. is there a better option> Thanks for the help
>

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBAACE.9050805%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Confused Puppet Manifest ... Possible caching issue?

[Felix Frank]

On 08/25/2014 11:17 PM, Matt Wise wrote:
> The log shows the remote connecting IP -- but the IP is the ELB in
> front of our puppet servers. Unfortunately because we're doing pure
> TCP-passthrough, ELB logging itself is not useful either in this case. :/
Uhm I see. Bummer.

Is that a Linux box? Could you resort to TPROXY to pass the client IP
through? =)

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBAB82.1020901%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Error 406 while communicating with puppet on port 443

[Felix Frank]

On 08/22/2014 05:52 AM, Ed Lima wrote:
> /
> /
> I can get to port 443 on the master fine from the node:
>

Well, that's nice and all, but are you aware that Puppet uses port 8140
by default?

Are you using Passenger? Please check your Apache configuration then.

If you are not using Passenger, then 443 is most definitely wrong,
because your master is not overriding the masterport setting.

Is masterport=443 set in the puppet.conf of your agent? It is not quite
clear to me why your agent tries that port at all.

Thanks,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBACBA.6080401%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet script/module for 3 environment

[Felix Frank]

On 08/21/2014 12:53 AM, Frans Thamura wrote:
> hi all
>
> anyone have an example that run puppet script in 3 enviroment,
>
> 1. puppet vagrant
> 2. puppet apply
> 3. puppet master
>
> can share?
>
> thx
>
> F -> still stack test my own in that environment

Hi,

a manifest that is fit for the master can be used for puppet apply
directly. Copy everything to the standalone node and apply the site.pp
manifest.

As for vagrant, you will have to copy your modules and manifests to the
appropriate location in the vagrant project (or whatchamacallit with
vagrant).

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBADB3.1020907%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Q: execute a working manifest with modules

[Felix Frank]

On 08/20/2014 11:23 PM, Frans Thamura wrote:
> I try the
>
> puppet apply --modulepath=/vagrant/data/puppet/modules
I think Yanis just misread your original invocation, which was fine.

The error message is quite obvious: The file
/vagrant/puppet/modules/tomcat/templates/tomcat-users.xml.erb does not
exist. You will need to research the reason for that.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBAE38.6020600%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] custom script execution and sending output back to master

[Felix Frank]

On 08/21/2014 04:25 PM, kaustubh chaudhari wrote:
>
> I want puppet agent to send this file or the output of the command #
> cat /etc/issue to the master?
>
> Is this possible, if yes can some one suggest or redirect me to some
> docs that i can refer too.

That requirement is practically the verbatim definition of External Facts.

https://docs.puppetlabs.com/facter/2.1/custom_facts.html#external-facts

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBAEAE.7090600%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet over stunnel fileserver issues

[Felix Frank]

On 08/18/2014 08:33 PM, jlittle wrote:
>
> I have two remote locations and my puppetmaster is behind a firewall
> and I want to allow access to it through stunnel so I tunneled the
> port to a client machine and aliased the puppetmasters name to
> localhost.  I can connect to the puppetmaster and my external node
> classifier can identify the server and assign it a class but I can't
> seen to get transfers from the fileserver.  My guess is that its
> trying to use random ports like an ftp server would so I though I
> would throw this question to the group to see if anyone else has had
> any luck or what people are doing with remote locations and 1
> puppetmaster.
>
> Jason

Hi,

no, all Puppet calls use the same port ($masterport).

I marvel at your setup. Would you mind sharing the stunnel configuration
for posterity?

Is your master's private key shared with the stunnel process? That
sounds exceedingly dangerous.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBAFAB.4060206%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Invalid Option --port=8140

[Felix Frank]

On 08/15/2014 09:34 PM, Mark Gardner wrote:
> I'm upgrading puppet from 3.3.1 to 3.6.2 on Suse Linux Enterprise 11 SP3
>
> The puppet service wont start with this error collected error from
> /var/log/puppet/puppet.conf
> Fri Aug 15 13:12:35 -0500 2014 Puppet (err): Could not parse
> application options: invalid option: --port=8140
>
> It looks to me that the init script needs to be changed to use
> masterport instead of port.   I'm not sure that it's something that
> needs to be changed in the file or something that needs to be fixed in
> the spec file? 

Holy monkey. Are those the packages that SuSE provides?

In upstream puppet, there *never* was a --port option. That was likely a
vendor patch then. Whee. What fun.

I suppose you kept your old initscript during the package update (as you
do), so that it didn't notice that this particular patch was reverted
for the current version?

I'm guessing wildly here, but it would at least make sense. Have you
checked the package's change log?

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"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/53FBB0E5.2010002%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] About RabbitMQ Puppet Module on the Forge

[Luis Mayorga]

 

Hi,


We have been using Puppet Enterprise for a while now and we are very 
interested on testing RabbitMQ as our solution for an application we are 
testing.  I have developed a demo using the Puppetlabs RabbitMQ Puppet 
Module but it seems that i am stuck with the configuration.


https://github.com/lmayorga1980/rabbitmq-server


Whenever I run the cluster status (`*rabbitmqctl cluster_status*` from 
https://www.rabbitmq.com/clustering.html) it seems that my three vagrant 
machines are not in a cluster.


Now it seems that I do have some issue with the cluster_nodes attribute 


….
> node 'rabbitmqserver1' inherits base {
>   class{ 'qserver' :
> node_name => 'rabbit',
> cluster_node_type => 'ram',
> cluster_nodes => ['rabbit@rabbitmqserver2', 
> 'rabbit@rabbitmqserver3']
>   }
> }
> node 'rabbitmqserver2' inherits base {
>   class{ 'qserver' :
> node_name => 'rabbit',
> cluster_node_type => 'ram',
> cluster_nodes => ['rabbit@rabbitmqserver1', 
> 'rabbit@rabbitmqserver3']
>   }
> }
> node 'rabbitmqserver3' inherits base {
>   class{ 'qserver' :
> node_name => 'rabbit',
> cluster_node_type => 'disc',
> cluster_nodes => ['rabbit@rabbitmqserver1', 
> 'rabbit@rabbitmqserver2']
>   }
> }


Any help will be much appreciated. 

-- 
You received this message because you are subscribed to the Google Groups 
"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/bf2c7552-eba9-4f9e-bb87-34d525cf94e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Announce: Facter 2.2.0

[Adrien Thebo]

Facter 2.2.0 is a backward-compatible features-and-fixes release in the
Facter 2 series. The release adds structured versions of several core fact
types and contains backports of facts that were merged into Facter master
but were not released in Facter 2.0.1.

Headline features
  - new structured facts: os, system_uptime, processors

To download Facter, follow the instructions here:
http://docs.puppetlabs.com/guides/install_puppet/pre_install.html

Release notes are available here:
http://docs.puppetlabs.com/facter/latest/release_notes.html
To see a complete list of issues fixed in this release:
https://tickets.puppetlabs.com/issues/?filter=12624
We're tracking bugs people find in this release with the "Affected Version"
field set to "2.2.0": https://tickets.puppetlabs.com/issues/?filter=12623

-- 
Adrien Thebo | Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"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/CALVJ9SJAX-hQipBeRAoGW9PtKfuOSmqp7pOSqo72uQeHAbotCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Monkey patch puppet type

[Mickaël Canévet]

Le lundi 25 août 2014 23:14:11 UTC+2, Felix.Frank a écrit :
>
> On 08/24/2014 08:04 AM, Mickaël Canévet wrote: 
> > Hello, 
> > 
> > I'd like to know if there is a way to monkey patch a puppet type for 
> > example to add an auto requirement: 
> > 
> > https://github.com/puppetlabs/puppetlabs-firewall/pull/380/files 
> > 
> > Thanks, 
> > Mickaël 
>
> Well, you can always maintain your personal fork of the firewall module, 
> and include that patch. 
>
> For core types, you will have to build your own packages (if that's how 
> you install your agents). 
>
> Is that what you're asking? 
>
> Best, 
> Felix 
>

Well, actually no. I'd really like to be able to provide a monkey patch 
that will apply on top of puppetlabs's module so that I don't have to 
maintain a fork (which is what I do right now) while my patch is not 
accepted upstream.
As declaring a parent for a puppet type is obsolete, I can't use 
inheritance to do that, that's why I was wondering if monkey patching could 
do the trick.

Thanks,
Mickaël

-- 
You received this message because you are subscribed to the Google Groups 
"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/760805a9-255e-4ac2-9f17-115025b5f371%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.