date:20130408

I am trying to use RDoc to document everything possible inline. 

I am using this Forge module: 
https://forge.puppetlabs.com/fiddyspence/sysctl 

It's README does not show up in the generated docs. 

I have tinkered with rdoc-markup in that README without success. 

Any clues out there for this clueless one ? 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

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

[Puppet Users] Re: Allowing external users to deploy code where an existing puppet instance exists.

2013-04-08 Thread Martijn

Hi Richard,

I'm not certain Puppet itself will be able to fill that role properly. 
AFAIK there's no way to limit certain manifests access to specific 
directories, or prevent others from breaking your code. Even with a bunch 
of testing, en error in some manifest could cause catalog compilation 
errors. Someone please correct me if I'm wrong.

I think you'll need to abstract the data from the Puppet code. Perhaps, you 
can code a layer around the features your users need. Maybe a defined type 
or a provider/type that users can use, combined with a simple code-review 
tool (like Gerrit) where trusted users can review the suggested changes.

You could set up Hiera to pull data from a database or other source. Allow 
the semi-trusted users to enter that data into the database via a web-app 
or whatever. Maybe even giving them access to a directory That way you 
control the Puppet code, hence limiting what the users are allowed to 
change. They activate parts of the code by providing  data via Hiera.

Another option is to use something different altogether, though you have 
probably considered this already. We use Capistrano (actually Webistrano, a 
web frontend for it) to allow developers to deploy to production servers. 
Puppet manages the directory structure, deploy-users and permissions. 
Capistrano deploys the web application from version-control and performs 
various pre- and post-scripts such as symlinking to shared assets and 
flushing caches.

We're starting to manage Solr cores via Capistrano as well, where we 
previously used Puppet to do that. Although it worked with Puppet, we ran 
into similar problem as you: allowing semi-trusted people to manage Solr 
cores without having them break Puppet turned out to be tricky. We use the 
basic authentication of Webistrano to control who's allowed to do a deploy. 
Capistrano is not limited to deploying code from version-control. It's just 
Ruby. You could write pretty much any script you want.

Maybe you could tell us a bit more about the type of actions the users need 
to be able to perform, so we'll know what would or wouldn't work.

Regards, Martijn

Op maandag 8 april 2013 13:03:27 UTC+2 schreef Richard het volgende:

 Hi All,

 I'm currently using puppet to deploy our O/S configuration to servers.  
 I've got a requirement to allow a semi-trusted set of external users to 
 deploy application configuration onto these same hosts.  For example, 
 they'd be allowed to configure anything under a /apps directory.

 What would be the best way to achieve this?  Ideally, I don't think I want 
 to give them access to our puppet master, although if we really had to we 
 could, and restrict them to a set of directories on the master using 
 appropriate permissions.

 Should I think about running a second puppet master - either under a 
 different user or on a different host?

 Can a puppet client talk to multiple masters?

 Is there any way to restrict them so they can only write modules that 
 update files under the /apps filesystem?  For example, if I'm populating 
 /etc/hosts via an existing class, I don't want them to be able to write 
 something that conflicts with this.

 Perhaps I should be using environments for this type of setup?

 Any pointers would be welcome.

 Many thanks,

 Richard.


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

Re: [Puppet Users] Flush provider - Differentiating between new resource and modification?

On Saturday, April 6, 2013 5:22:03 PM UTC-5, Stefan Schulte wrote:

On Fri, 5 Apr 2013 00:57:32 -0700 (PDT)
Gavin Williams fatm...@gmail.com javascript: wrote:

Morning all

I'm working on converting some of my NetApp providers to
prefetch/flush style to try and optimize performance.

I've hit an issue on my Netapp_user provider, around handling
resource creation versus resource modification?
What's the easiest way to differentiate?

Current code is here:

https://github.com/fatmcgav/fatmcgav-netapp/commit/66092978f4182c5474a60011db99ee2e3e12e689

Any tips appreciated.

Regards
Gavin

There is no way to check *why* the flush method was called, you just now
that at least one property has been updated. You do not see if `ensure`
updated or let's say `passmaxage`. Does this actually cause problems?

Your prefetch() method determines which target resources already exist as
part of its normal job. It could flag those resources via some internal
variable of the resource, or perhaps even in the @property_hash. You could
even formalize that by creating a read-only property for it, if that makes
you more comfortable. At flush() time you can assume that resources that
are flagged already exist, and those that are not, don't. There is a small
window for collision if physical resources of the target type can be
created / destroyed by a different process while Puppet is running, but
that issue exists in any case.

If you were not doing prefetching then the provider could check the
existence of the physical resource as the first step of flushing. Indeed,
it would need to do so, one way or another, to correctly apply the
resource's 'ensure' parameter. Your provider can work this way despite
prefetching if you don't want to mark prefetched resources.

John

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

[Puppet Users] Re: Puppet client not auto updating

2013-04-08 Thread Martijn

Hi Sy,

The Puppet agent will usually log to syslog, both in case of errors or 
succes, so check in /var/log/syslog (on Ubuntu) for any messages. By 
default, the agent runs every half hour so I'd expect to see some entries 
in the log every half hour.

Make sure the puppet agent service runs as root. The puppet master does not 
need to be root but the agent needs permission to check and change the 
system. If you used the distro's of Puppetlabs' packages this is most 
likely already the case.

Instead of the obsolete puppetd command, use puppet agent --test for 
manually starting a run. Add --noop for a trial-run, say if you just want 
to see what would happen.

Contrary to Drew's suggestion we actually prefer running the agent service, 
instead of cron. Just to provide another opinion :). Still, both methods 
should work fine, so we'll need to figure that out first.

Regards, Martijn

Op zaterdag 6 april 2013 00:48:10 UTC+2 schreef Sy Doveton het volgende:

 Hi,

 I am new to puppet and am experimenting with some basic commands. I have a 
 puppetmaster server and a couple or servers with puppet client. All servers 
 are running ubuntu.

 I have set up the link between the master and the clients and their certs 
 have been signed etc.

 The clients have had puppet started via 'service puppet start' and can 
 confirm they are running with 'service puppet status'.

 When I make any changes on the master nothing happens on the servers. I 
 have waited a couple of hours and e.g. the required package has not been 
 installed on the client. As soon as I run on the client:-

 puppetd --test

 It will immediately install the package so I know my manifests / modules 
 are correct as it does what I request when I manually ask it. I just need 
 it to run periodically automatically and get the latest info from the 
 master.

 Any ideas of things I can check?


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

[Puppet Users] Re: Puppet client not auto updating



On Friday, April 5, 2013 5:48:10 PM UTC-5, Sy Doveton wrote:

 Hi,

 I am new to puppet and am experimenting with some basic commands. I have a 
 puppetmaster server and a couple or servers with puppet client. All servers 
 are running ubuntu.

 I have set up the link between the master and the clients and their certs 
 have been signed etc.

 The clients have had puppet started via 'service puppet start' and can 
 confirm they are running with 'service puppet status'.

 When I make any changes on the master nothing happens on the servers. I 
 have waited a couple of hours and e.g. the required package has not been 
 installed on the client. As soon as I run on the client:-

 puppetd --test

 It will immediately install the package so I know my manifests / modules 
 are correct as it does what I request when I manually ask it. I just need 
 it to run periodically automatically and get the latest info from the 
 master.

 Any ideas of things I can check?



It sounds like the 'runinterval' configuration option on the clients may be 
set to something very large.  The puppet default is 1800 (seconds), but the 
packager could have provided a larger value so as to sync less frequently.  
The configuration file is normally /etc/puppet/puppet.conf.


John

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

[Puppet Users] Re: Allowing external users to deploy code where an existing puppet instance exists.



On Monday, April 8, 2013 6:03:27 AM UTC-5, Richard wrote:

 Hi All,

 I'm currently using puppet to deploy our O/S configuration to servers.  
 I've got a requirement to allow a semi-trusted set of external users to 
 deploy application configuration onto these same hosts.  For example, 
 they'd be allowed to configure anything under a /apps directory.

 What would be the best way to achieve this?  Ideally, I don't think I want 
 to give them access to our puppet master, although if we really had to we 
 could, and restrict them to a set of directories on the master using 
 appropriate permissions.



Doing as you describe would not affect what parts of target nodes the 
external users could configure.

 


 Should I think about running a second puppet master - either under a 
 different user or on a different host?



Probably not.

 


 Can a puppet client talk to multiple masters?



Each agent must be paired with one master.  It is possible to configure 
multiple agents on the same node, talking to different masters, but I don't 
recommend it.

If you were to do it anyway, however, then you would want to make sure that 
the external users' agent only had access to those parts of target nodes 
that it was supposed to be able to change.  That would certainly mean not 
running it as root, which in turn implies that it could not manage anything 
that requires root access.  In the end, that probably means it could manage 
only the contents of certain directories, and when you reduce it to that 
level there are better options (such as a scheduled sync of the target 
directories with a source-control repository).
 


 Is there any way to restrict them so they can only write modules that 
 update files under the /apps filesystem?  For example, if I'm populating 
 /etc/hosts via an existing class, I don't want them to be able to write 
 something that conflicts with this.



Puppet does not have a mechanism for restricting which target resources a 
given module may manage.

If you are looking only to protect against accidental conflicts, then 
Puppet provides limited protection automatically by failing catalog 
compilation when it sees multiple declarations of the same resource.  You 
could set up monitoring to detect that.  Indeed, your own team could cause 
the same kind of problem, so it's worth watching out for it in any case.

That does absolutely nothing to protect against malicious interference with 
your systems' configurations, however.  Modules installed in your 
puppetmaster can cause agents to do literally anything that target nodes' 
security framework allows them to do, so anyone who can modify any modules 
without oversight and code review is *de facto* trusted.
 


 Perhaps I should be using environments for this type of setup?



Environments would help you only if there were some systems on which your 
external users could be fully trusted, but others on which they were not.  
That could play a part in a review process for module updates, or it might 
naturally fit with what you're trying to do, but it doesn't achieve what 
you started out asking about.

 

 Any pointers would be welcome.



Puppet is very powerful, but with great power comes great responsibility.  
People to whom you are unwilling to grant such responsibility must not be 
given access to your master.  That extends even to ERB templates, for Ruby 
code running in such a template can accidentally or maliciously muck with 
Puppet internals (though doing so accidentally is unlikely).

You can allow your external users to upload flat application configuration 
files or flat file fragments to a source-control system from which the 
master will periodically pull.  That limits your exposure to only the 
application(s) being configured.  The module that actually manages the 
target files based on these sources should be reviewed and approved by your 
team.  You can also allow users to manage ERB templates if you trust them 
to be competent and benign.  You probably should set up permissions so that 
the puppetmaster process has read-only access to its manifests and other 
data (which is good on general principles).


John

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

Re: [Puppet Users] Re: memory issue



On Monday, April 8, 2013 5:28:19 AM UTC-5, Mamta Garg wrote:

 Hi jcbollinger ,

 I have added 1 GB more RAM on server and now my free RAM is more than 2 
 GB.Also started puppet ,puppetmaster,puppet-dashboard services.

 But nodes are still showing unresponsive.Any idea?



I already suggested that your small swap size could be part of the 
problem.  Have you tried increasing that?  For 3MB RAM, I would want to see 
at least 3MB of swap space.

Alternatively, the message pointing to memory as the problem could be a red 
herring.  It might be that you are running out of a different system 
resource instead, such as number of concurrent processes or open files.  
That would be unlikely if the master is running as the only service on a 
physical machine, but if it's running in a VM then perhaps such a problem 
is occurring at the VM host.


John

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

Re: [Puppet Users] Re: memory issue

2013-04-08 Thread Erik Dalén

it could be that you have a ulimit for the amount of ram the puppetmaster 
process (or puppet user) can use.


--  
Erik Dalén


On Monday 8 April 2013 at 12:28, Mamta Garg wrote:

 Hi jcbollinger ,
  
 I have added 1 GB more RAM on server and now my free RAM is more than 2 
 GB.Also started puppet ,puppetmaster,puppet-dashboard services.
  
 But nodes are still showing unresponsive.Any idea?
  
 Thanks,
 Mamta
  
  
 On Mon, Apr 1, 2013 at 9:31 AM, jcbollinger john.bollin...@stjude.org 
 (mailto:john.bollin...@stjude.org) wrote:
   
   
  On Monday, April 1, 2013 6:15:54 AM UTC-5, Mamta Garg wrote:
   HI jcbollinger ,

   Thanks for your reply!

   I have attached my master machine memory infor screenshot.Could you guide 
   me with that ,whats is wrong?
   I am using one master at a time.
   
   
  I don't see a smoking gun, but I find it suspicious that you have so little 
  swap. I generally want to see at least as much swap as total RAM, and I 
  usually configure 1.5x or sometimes even 2x RAM. The 2G total RAM in your 
  box is perhaps a bit light, too, but not so much so that I would expect to 
  see problems for a single puppetmaster process. Unless the box is providing 
  other memory-hungry services as well.
   
  Do check the puppetmaster process's memory usage, as you may find that 
  puppet needs up to as much free memory as its then-current usage to 
  successfully fork(), which it does whenever it runs an external program. 
  (That additional allocation is released when the external program exits.) 
  It is not uncommon for the master to use hundreds of MB of memory.
   
  For Puppet to fail (only) occasionally with the kind of error you report, 
  you are probably are running right on the edge of the master's capacity. In 
  that case, increasing swap would probably make the errors cease, at least 
  for the time being, but you will see a slowdown somewhere whenever the 
  system needs to page anything out. Possibly little enough that you don't 
  notice. Alternatively, you can probably make the error go away by adding 
  RAM. You may be able to make it go away temporarily by restarting the 
  puppetmaster service (or apache/passenger of that's the way you're running 
  it, etc.), but then the issue is likely to reappear fairly soon.
   
   
   
  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 
  (mailto:puppet-users%2bunsubscr...@googlegroups.com).
  To post to this group, send email to puppet-users@googlegroups.com 
  (mailto:puppet-users@googlegroups.com).
  Visit this group at http://groups.google.com/group/puppet-users?hl=en.
  For more options, visit https://groups.google.com/groups/opt_out.
   
   
  
  
  
  
 --  
 Thanks and Regards,
 Mamta Garg
 --  
 You received this message because you are subscribed to the Google 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 post to this group, send email to puppet-users@googlegroups.com 
 (mailto:puppet-users@googlegroups.com).
 Visit this group at http://groups.google.com/group/puppet-users?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  



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

[Puppet Users] Re: Announce: Hiera 1.2.0 Available

2013-04-08 Thread Chuck

Hiera 1.2.0 is refusing to use the Puppet_logger  backend on my puppet 
masters and is dumping ALL of its logs into my HTTP error.log file.  Which 
then fills up my /var/log file system.

puppetdb-terminus-1.2.0-1.el6.noarch
puppet-3.1.1-1.el6.noarch
puppet-server-3.1.1-1.el6.noarch
hiera-1.2.0-1.el6.noarch


[Mon Apr 08 16:07:33 2013] [notice] Apache/2.2.15 (Unix) DAV/2 
Phusion_Passenger/3.0.17 mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured -- 
resuming normal operations
WARN: Mon Apr 08 16:07:37 + 2013: Not using Hiera::Puppet_logger. It 
does not report itself to be suitable.
DEBUG: Mon Apr 08 16:07:37 + 2013: Hiera YAML backend starting


On Wednesday, April 3, 2013 7:39:05 PM UTC-5, Matthaus Litteken wrote:

 Hiera 1.2.0 is a feature release in the 1.x series with 
 new features and bug fixes. 

 Downloads are available at: 
  * Source: https://downloads.puppetlabs.com/hiera/hiera-1.2.0.tar.gz 

 RPMs are available at https://yum.puppetlabs.com/el or /fedora 

 Rubygem available at http://rubygems.org/gems/hiera 

 Debs are available at https://apt.puppetlabs.com 

 Mac package is available at 
 https://downloads.puppetlabs.com/mac/hiera-1.2.0.dmg 

 Please report feedback via the Puppet Labs Redmine site, using a 
 affected version of 1.2.0: 
  http://projects.puppetlabs.com/projects/hiera/ 

 Fixes targeted at the final of this version in our bug tracker: 
 http://projects.puppetlabs.com/versions/332 

  
 ## Hiera 1.2.0 Release Notes ## 
  
 # Features 

 Add deep-merge feature to backend lookups 

 - Config option :merge_behavior = :native|:deep|:deeper 
 - Add optional requirement on deep_merge gem to support 
   :deep and :deeper options 
 - Update Yaml backend to use Backend.merge_answer 
 - Update Json backend to use Backend.merge_answer 

 (#16644) Add a generic file cache 

 Add a general file cacher in Hiera::Filecache based on the work that 
 was 
 done in the YAML backend. 

 Adjust the YAML and JSON backends to use this cache 

 (#18718) Create logger to handle fallback 

 Sometimes a logger has been configured, but is not suitable for being 
 used. An example of this is when the puppet logger has been 
 configured, 
 but hiera is not being used inside puppet. This adds a FallbackLogger 
 that will choose among the provided loggers for one that is suitable. 

 # Bug Fixes 

 (#17434) Detect loops in recursive lookup 

 The recursive lookup functionality was vulnerable to infinite 
 recursion 
 when the values ended up referring to each other. This keeps track of 
 the names that have been seen in order to stop a loop from occuring. 
 The 
 behavior for this was extracted to a class so that it didn't clutter 
 the 
 logic of variable interpolation. The extracted class also specifically 
 pushes and pops on an internal array in order to limit the amount of 
 garbage created during these operations. This modification should be 
 safe so long a new Hiera::RecursiveLookup is used for every parse that 
 is done and it doesn't get shared in any manner. 

 (#17434) Support recursive interpolation 

 The original code for interpolation had, hidden somewhere in its 
 depths, 
 supported recursive expansion of interpolations. This adds that 
 support 
 back in. 

 = 
 ## Hiera 1.2.0 Changelog ## 
 = 

 Andrew Parker (13): 
   26311b7 (#18718) Load logger classes eagerly 
   2520aa3 (#18718) Create logger to handle fallback 
   074f5c8 (#18718) Enable console fallback when logger not suitable 
   8db2949 (#18718) Implement suitablity check for puppet logger 
   dc98e2d (#17434) Add YARD for #parse_string 
   06dcf8e (#17434) Clarify tests for #parse_string 
   dc6c538 (#17434) Add tests to exclude unwanted lookups 
   3a2660d (#17434) Stronger assertion about how keys are looked up 
   4d85f92 (Maint) Describe desired behavior in backend specs 
   023001d (#17434) Simplify string interpolation 
   9a3f1fd (#17434) Simplify logic around looking up values 
   453b489 (#17434) Support recursive interpolation 
   9a62bfd (#17434) Detect loops in recursive lookup 

 Jeff McCune (4): 
   b2623d9 (maint) Add Travis CI Support 
   fcecdbf (maint) Add Travis CI support to active branches 
   5262050 (maint) Add Ruby 2.0.0 to Travis build matrix 
   d9db368 Add contributing document to Hiera 

 Justen Walker (7): 
   4ac8372 Add deep-merge feature to backend lookups 
   3da83b2 Allow both symbols and strings when deciding behavior of 
 merge_answer 
   950076b Fix undefined method `[]' for nil:NilClass error in 
 yaml_backend_spec.rb 
   b317d10 Add deep-merge feature to backend lookups 
   13b79ef Allow both symbols and strings when deciding behavior of 
 merge_answer 
   d84cd11 Fix undefined method `[]' for nil:NilClass error

Re: [Puppet Users] Re: Puppet and OVO/ITO/OML

2013-04-08 Thread Stefan Schulte

On Sun, 7 Apr 2013 02:16:07 -0700 (PDT)
ro...@liveperson.com wrote:

 Thanks for all the information Stefan!
 I'd be happy to see the module you're using if it's possible.
 
 Roee.
 

Ok so I have a hpoml::client class to include at node level. It
basically consists of a hpoml::user class where I define the `opc_op`
User and the `opcgrp` group (to have consistent uid and gid across
machines) and the class hpoml::client::package. I guess I can share
that one:

class hpoml::client::package ($server = 'your_master_server', $minversion = 
'11.11.025') {

  if ! ($::operatingsystem in [ 'Solaris', 'RedHat' ]) {
fail operatingsystem ${::operatingsystem} is currently not supported. Must 
be one of Solaris, RedHat
  }

  $installer = '/some/nas/share/Agt_11.11.x/oainstall.sh'
  $install_arguments = '-install -agent -includeupdates -defer_configure'
  $update_arguments = '-install -agent -includeupdates'

  exec { 'Install_OML':
command  = ${installer} ${install_arguments},
creates  = [
  '/opt/OV/bin/ovc',
  '/opt/OV/bin/ovconfget',
],
timeout  = '1800',  # 30 minutes
  }

  exec { 'Configure_OML':
command = '/opt/OV/bin/OpC/install/oainstall.sh -configure -agent',
creates = [
  '/var/opt/OV/installation/inventory/HPOvAgtLc.xml',
  '/var/opt/OV/installation/inventory/HPOvBbc.xml',
  '/var/opt/OV/installation/inventory/HPOvConf.xml',
  '/var/opt/OV/installation/inventory/HPOvCtrl.xml',
  '/var/opt/OV/installation/inventory/HPOvDepl.xml',
  '/var/opt/OV/installation/inventory/HPOvEaAgt.xml',
  '/var/opt/OV/installation/inventory/HPOvGlanc.xml',
  '/var/opt/OV/installation/inventory/HPOvPacc.xml',
  '/var/opt/OV/installation/inventory/HPOvPerfAgt.xml',
  '/var/opt/OV/installation/inventory/HPOvPerfMI.xml',
  '/var/opt/OV/installation/inventory/HPOvPerlA.xml',
  '/var/opt/OV/installation/inventory/HPOvSecCC.xml',
  '/var/opt/OV/installation/inventory/HPOvSecCo.xml',
  '/var/opt/OV/installation/inventory/HPOvXpl.xml',
  '/var/opt/OV/installation/inventory/Operations-agent.xml',
],
require = Exec['Install_OML'],
  }

  exec { 'Activate_OML':
command = /opt/OV/bin/OpC/install/opcactivate -srv ${server} -cert_srv 
${server},
unless  = /opt/OV/bin/ovconfget sec.core.auth MANAGER | /bin/grep 
${server},
require = Exec['Configure_OML'],
  }

  # only patch if ovo is already installed and if the current version
  # is below the minversion. We do not downgrade.
  if $::opcagtversion and versioncmp($::opcagtversion, $minversion)  0 {
exec { 'Patch_OML':
  command = ${installer} ${update_arguments},
  timeout = '1800',  # 30 minutes
  require = Exec['Install_OML'],
}
  }
}

works pretty well. If we get a new version I try the installer by hand
a couple of times (the class does not downgrade, only upgrade). If it
does not fail I bump the $minversion default parameter and puppet will
patch all my systems.

-Stefan

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

[Puppet Users] Announce: Module puppetalbs/puppetdb 1.2.1 Available

2013-04-08 Thread Ken Barber

A new release of the puppetlabs/puppetdb module is now available on the Forge:

http://forge.puppetlabs.com/puppetlabs/puppetdb/1.2.1

This is a bugfix releases that solves the PuppetDB startup exception:

java.lang.AssertionError: Assert failed: (string? s)

This was due to the default `node-ttl` and `node-purge-ttl` settings
not having a time suffix by default. These settings required 's', 'm',
'd' etc. to be suffixed, even if they are zero.

Changes


* (Dominic Cleal) Add unit suffix to TTL settings to avoid issue #20099

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

[Puppet Users] More Hiera and Environment questions

Hi everyone,

I have a question that I can't seem to find a solution to.

I am using hiera, and having a hard time understanding how to pass 
environments for dynamic look ups.

For example, if my hiera.yaml looks like this:

:hierarchy: - %{::environment} - common

How / where do I pass the $environment variable that the host will know 
it's in a particular environment. I had something working before using an 
ENC, but I do not have an option of using an ENC this time around.

Thanks!

Tony

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

Re: [Puppet Users] More Hiera and Environment questions

http://docs.puppetlabs.com/guides/environment.html#on-the-agent-node 

I put it in the [agent] block of puppet.conf 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Tony C tonyjch...@gmail.com 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 1:28:37 PM 
Subject: [Puppet Users] More Hiera and Environment questions 

Hi everyone, 


I have a question that I can't seem to find a solution to. 


I am using hiera, and having a hard time understanding how to pass environments 
for dynamic look ups. 


For example, if my hiera.yaml looks like this: 


:hierarchy: - %{::environment} - common 



How / where do I pass the $environment variable that the host will know it's in 
a particular environment. I had something working before using an ENC, but I do 
not have an option of using an ENC this time around. 


Thanks! 


Tony 

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


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

[Puppet Users] Show manifest code in rdoc

2013-04-08 Thread banjer

Is it possible to have puppet doc show all of the manifest code in the 
generated docs?  I'm generating some html docs and would love to be able to 
look at the actual code for each class or define statement.  With syntax 
highlighting would be even sweeter.

I'm using the following to create my docs:

sudo puppet doc --all --mode rdoc --outputdir 
/usr/local/foreman/public/puppet/rdoc/development --modulepath 
/etc/puppet/modules/

FYI:

Puppet master 3.1.1
Foreman 1.1.1
these both run on CentOS 6.4

Thanks for your comments.

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

Re: [Puppet Users] More Hiera and Environment questions

Oops, I copied and pasted the wrong thing.


hiera.yaml

:yaml:
  :datadir: /etc/puppetlabs/hieradata/%{::environment}
:hierarchy:
  - common
  - %{::application}


On my agent puppet.conf, I have tried what you suggested already but it 
can't find the value in hiera.

[agent]
certname = xx
server = xx
report = true
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
graph = true
pluginsync = true
environment = dev
application = app_1


On Monday, April 8, 2013 10:33:26 AM UTC-7, Ygor wrote:

 http://docs.puppetlabs.com/guides/environment.html#on-the-agent-node

 I put it in the [agent] block of puppet.conf

 “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)

 --
 *From: *Tony C tonyj...@gmail.com javascript:
 *To: *puppet...@googlegroups.com javascript:
 *Sent: *Monday, April 8, 2013 1:28:37 PM
 *Subject: *[Puppet Users] More Hiera and Environment questions

 Hi everyone,

 I have a question that I can't seem to find a solution to.

 I am using hiera, and having a hard time understanding how to pass 
 environments for dynamic look ups.

 For example, if my hiera.yaml looks like this:

 :hierarchy: - %{::environment} - common

 How / where do I pass the $environment variable that the host will know 
 it's in a particular environment. I had something working before using an 
 ENC, but I do not have an option of using an ENC this time around.

 Thanks!

 Tony

 -- 
 You received this message because you are subscribed 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 javascript:.
 To post to this group, send email to puppet...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/puppet-users?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  


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

Re: [Puppet Users] More Hiera and Environment questions

2013-04-08 Thread Ellison Marks

If you're running puppet as a service, have you restarted the service since 
adding that value?

On Monday, April 8, 2013 10:40:45 AM UTC-7, Tony C wrote:

 Oops, I copied and pasted the wrong thing.


 hiera.yaml

 :yaml:
   :datadir: /etc/puppetlabs/hieradata/%{::environment}
 :hierarchy:
   - common
   - %{::application}


 On my agent puppet.conf, I have tried what you suggested already but it 
 can't find the value in hiera.

 [agent]
 certname = xx
 server = xx
 report = true
 classfile = $vardir/classes.txt
 localconfig = $vardir/localconfig
 graph = true
 pluginsync = true
 environment = dev
 application = app_1


 On Monday, April 8, 2013 10:33:26 AM UTC-7, Ygor wrote:

 http://docs.puppetlabs.com/guides/environment.html#on-the-agent-node

 I put it in the [agent] block of puppet.conf

 “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)

 --
 *From: *Tony C tonyj...@gmail.com
 *To: *puppet...@googlegroups.com
 *Sent: *Monday, April 8, 2013 1:28:37 PM
 *Subject: *[Puppet Users] More Hiera and Environment questions

 Hi everyone,

 I have a question that I can't seem to find a solution to.

 I am using hiera, and having a hard time understanding how to pass 
 environments for dynamic look ups.

 For example, if my hiera.yaml looks like this:

 :hierarchy: - %{::environment} - common

 How / where do I pass the $environment variable that the host will know 
 it's in a particular environment. I had something working before using an 
 ENC, but I do not have an option of using an ENC this time around.

 Thanks!

 Tony

 -- 
 You received this message because you are subscribed 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 post to this group, send email to puppet...@googlegroups.com.
 Visit this group at http://groups.google.com/group/puppet-users?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  



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

Re: [Puppet Users] More Hiera and Environment questions

Yes, I have restarted every service. If I replace the %{environment} and 
%{application} with the actual values in hiera.yaml, everything works so I 
know at least I'm on the right track.

I have also run the hiera command with -c  with environment=dev 
application=app1 and that works as well.

Tony

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

Re: [Puppet Users] More Hiera and Environment questions

I think the double-colon is the problem. 

In my hiera.yaml , I have 

:hierarchy: 
- %{environment}/%{hostname} 
- %{environment}/common 
- %{hostname} 
- common 

And it works 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Tony C tonyjch...@gmail.com 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 1:40:45 PM 
Subject: Re: [Puppet Users] More Hiera and Environment questions 

Oops, I copied and pasted the wrong thing. 




hiera.yaml 



:yaml: 
:datadir: /etc/puppetlabs/hieradata/%{::environment} 
:hierarchy: 
- common 
- %{::application} 




On my agent puppet.conf, I have tried what you suggested already but it can't 
find the value in hiera. 



[agent] 
certname = xx 
server = xx 
report = true 
classfile = $vardir/classes.txt 
localconfig = $vardir/localconfig 
graph = true 
pluginsync = true 
environment = dev 
application = app_1 



On Monday, April 8, 2013 10:33:26 AM UTC-7, Ygor wrote: 



http://docs.puppetlabs.com/guides/environment.html#on-the-agent-node 

I put it in the [agent] block of puppet.conf 


“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) 


From: Tony C  tonyj...@gmail.com  
To: puppet...@googlegroups.com 
Sent: Monday, April 8, 2013 1:28:37 PM 
Subject: [Puppet Users] More Hiera and Environment questions 

Hi everyone, 


I have a question that I can't seem to find a solution to. 


I am using hiera, and having a hard time understanding how to pass environments 
for dynamic look ups. 


For example, if my hiera.yaml looks like this: 


:hierarchy: - %{::environment} - common 



How / where do I pass the $environment variable that the host will know it's in 
a particular environment. I had something working before using an ENC, but I do 
not have an option of using an ENC this time around. 


Thanks! 


Tony 

-- 
You received this message because you are subscribed 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 post to this group, send email to puppet...@googlegroups.com . 
Visit this group at http://groups.google.com/group/puppet-users?hl=en . 
For more options, visit https://groups.google.com/groups/opt_out . 






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


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

Re: [Puppet Users] More Hiera and Environment questions

Sorry. I am mistaken on this 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Dan White y...@comcast.net 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 1:56:53 PM 
Subject: Re: [Puppet Users] More Hiera and Environment questions 


I think the double-colon is the problem. 

In my hiera.yaml, I have 

:hierarchy: 
- %{environment}/%{hostname} 
- %{environment}/common 
- %{hostname} 
- common 

And it works 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Tony C tonyjch...@gmail.com 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 1:40:45 PM 
Subject: Re: [Puppet Users] More Hiera and Environment questions 

Oops, I copied and pasted the wrong thing. 




hiera.yaml 



:yaml: 
:datadir: /etc/puppetlabs/hieradata/%{::environment} 
:hierarchy: 
- common 
- %{::application} 




On my agent puppet.conf, I have tried what you suggested already but it can't 
find the value in hiera. 



[agent] 
certname = xx 
server = xx 
report = true 
classfile = $vardir/classes.txt 
localconfig = $vardir/localconfig 
graph = true 
pluginsync = true 
environment = dev 
application = app_1 



On Monday, April 8, 2013 10:33:26 AM UTC-7, Ygor wrote: 



http://docs.puppetlabs.com/guides/environment.html#on-the-agent-node 

I put it in the [agent] block of puppet.conf 


“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) 


From: Tony C  tonyj...@gmail.com  
To: puppet...@googlegroups.com 
Sent: Monday, April 8, 2013 1:28:37 PM 
Subject: [Puppet Users] More Hiera and Environment questions 

Hi everyone, 


I have a question that I can't seem to find a solution to. 


I am using hiera, and having a hard time understanding how to pass environments 
for dynamic look ups. 


For example, if my hiera.yaml looks like this: 


:hierarchy: - %{::environment} - common 



How / where do I pass the $environment variable that the host will know it's in 
a particular environment. I had something working before using an ENC, but I do 
not have an option of using an ENC this time around. 


Thanks! 


Tony 

-- 
You received this message because you are subscribed 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 post to this group, send email to puppet...@googlegroups.com . 
Visit this group at http://groups.google.com/group/puppet-users?hl=en . 
For more options, visit https://groups.google.com/groups/opt_out . 






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




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


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

Re: [Puppet Users] More Hiera and Environment questions

Yes, the double colon was a problem, also it looks like in the agent conf, 
this does not work
applicaton = app_1

So this goes back to my original issue. Without an ENC, how can I 'tag my 
machines with specific info. I was playing with custom facts but it looks 
like the same facts get applied to every node. 

Thanks!

Tony

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

Re: [Puppet Users] More Hiera and Environment questions

I must retract my earlier claim. 
I tried mine with and without the scoping double-colon and it works both ways. 

The documentation ( http://docs.puppetlabs.com/hiera/1/variables.html ) uses 
the double-colon. 

HOWEVER, I think (again) I see your problem: What is application ? 

All the variables I use are in the settings ( 
http://docs.puppetlabs.com/references/latest/configuration.html ) 

application is not a setting. 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Tony C tonyjch...@gmail.com 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 2:04:05 PM 
Subject: Re: [Puppet Users] More Hiera and Environment questions 

Yes, the double colon was a problem, also it looks like in the agent conf, this 
does not work 
applicaton = app_1 


So this goes back to my original issue. Without an ENC, how can I 'tag my 
machines with specific info. I was playing with custom facts but it looks like 
the same facts get applied to every node. 


Thanks! 


Tony 

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


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

Re: [Puppet Users] More Hiera and Environment questions

Thank you so much. I have never seen that page before. I think my issue is 
resolved for now. I'll open another post for facts.

On Monday, April 8, 2013 11:11:18 AM UTC-7, Ygor wrote:

 I must retract my earlier claim.
 I tried mine with and without the scoping double-colon and it works both 
 ways.

 The documentation ( http://docs.puppetlabs.com/hiera/1/variables.html ) 
 uses the double-colon.

 HOWEVER, I think (again) I see your problem: What is application ?

 All the variables I use are in the settings ( 
 http://docs.puppetlabs.com/references/latest/configuration.html )

 application is not a setting.

 “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)

 --
 *From: *Tony C tonyj...@gmail.com javascript:
 *To: *puppet...@googlegroups.com javascript:
 *Sent: *Monday, April 8, 2013 2:04:05 PM
 *Subject: *Re: [Puppet Users] More Hiera and Environment questions

 Yes, the double colon was a problem, also it looks like in the agent conf, 
 this does not work
 applicaton = app_1

 So this goes back to my original issue. Without an ENC, how can I 'tag my 
 machines with specific info. I was playing with custom facts but it looks 
 like the same facts get applied to every node. 

 Thanks!

 Tony

 -- 
 You received this message because you are subscribed 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 javascript:.
 To post to this group, send email to puppet...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/puppet-users?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  


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

[Puppet Users] Re: Announce: Module puppetalbs/puppetdb 1.2.1 Available

2013-04-08 Thread Felipe Salum

Ken,

Looks like the new parameters (report_ttl, node_ttl, node_purge_ttl) are 
not working. It is not being sent by the puppetdb::server class to the 
database_ini class. Neither from the puppetdb main class to the 
puppetdb::server class.

It is also not being used in database_ini as it is set to use only the 
values coming from the params.

I sent a pull request to fix it 
https://github.com/puppetlabs/puppetlabs-puppetdb/pull/49

Let me know if that helps.

Thanks,
Felipe

On Monday, April 8, 2013 10:21:12 AM UTC-7, Ken Barber wrote:

 A new release of the puppetlabs/puppetdb module is now available on the 
 Forge: 

 http://forge.puppetlabs.com/puppetlabs/puppetdb/1.2.1 

 This is a bugfix releases that solves the PuppetDB startup exception: 

 java.lang.AssertionError: Assert failed: (string? s) 

 This was due to the default `node-ttl` and `node-purge-ttl` settings 
 not having a time suffix by default. These settings required 's', 'm', 
 'd' etc. to be suffixed, even if they are zero. 

 Changes 
  

 * (Dominic Cleal) Add unit suffix to TTL settings to avoid issue #20099 


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

[Puppet Users] Announce: Facter 1.7.0-rc2 Available

2013-04-08 Thread Matthaus Owens

Facter 1.7.0-rc2 is a feature release candidate in the 1.x series with
new features and bug fixes. For current documentation on Facter 1.7.0,
please see: http://docs.puppetlabs.com/facter/1.7/

To see a list of the issues addressed by this release, check out the
1.7.0 version in our issue tracker at:
https://projects.puppetlabs.com/versions/348

Downloads are available at:
 * Source https://downloads.puppetlabs.com/facter/facter-1.7.0-rc2.tar.gz

Available in native package format in the pre-release repositories at:
http://yum.puppetlabs.com and http://apt.puppetlabs.com

For information on how to enable the Puppet Labs pre-release repos, see:
http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#enabling-the-prerelease-repos

Gems are available via rubygems at
https://rubygems.org/downloads/facter-1.7.0.rc2.gem
  or by using `gem install --pre facter`

Mac packages are available at
https://downloads.puppetlabs.com/mac/facter-1.7.0-rc2.dmg

Please report feedback via the Puppet Labs Redmine site, using an
affected facter version of 1.7.0-rc2:
https://projects.puppetlabs.com/projects/facter/

==
##  Facter 1.7.0-rc2 Contributors  ##
==
Adrien Thebo, Andrew Elwell, Andrew Parker, Ashley Penney, Chris
Price, Christopher Webber, Daniel Black, Daniel Pittman, Eric
Sorenson, Erik Dalén, Evan Pierce, Garrett Honeycutt, Garrett Wollman,
Gary Larizza, Grant Heffernan, Hailee Kenney, Hunter Haugen, Jacob
Helwig, Jared Curtis, Jason Gill, Jeff McCune, Jeff Weiss, Jonathan
Grochowski, Josh Cooper, Joshua Hoblitt, Ken Barber, Kyle Anderson,
Luis Fernandez Alvarez, Luke Kanies, Marc Fournier, Matthaus Owens,
Max Riveiro, Michael Kincaid, Michael Moll, Michael Renz, Mikael
Fridh, Moses Mendoza, Nan Liu, Nicolas Vigier, Niels Abspoel, OMCnet
Development Team, Patrick Carlisle, Pierre-Gilles Mialon, Rahul
Gopinath, Russell Harrison, Stefan Schulte, Tim Sharpe, Timur
Batyrshin, Todd Zullinger, Wolf Noble, rlinehan

===
## Facter 1.7.0-rc2 Release Notes ##
===

External Facts

It's now possible to create external facts with structured text (e.g.
YAML, JSON, or a Facter-specific plaintext format) or with a script
that returns fact names and values in a specific format (e.g. Ruby or
Perl). Please see the custom facts guide for a detailed explanation
and caveats.

on_flush DSL method

Also new in Facter 1.7 is the on_flush DSL method, usable when
defining new custom facts. This feature is designed for those users
who are implementing their own custom facts.

The on_flush method allows the fact author to register a callback
Facter will invoke whenever a cached fact value is flushed. This is
useful to keep a set of dynamically generated facts in sync without
making lots of expensive system calls to resolve each fact value.

Please see the solaris_zones fact for an example of how the on_flush
method is used to invalidate the cached value of a model shared by
many dynamically generated facts.

=
##  Facter 1.7.0-rc2 Changelog  ##
=
Adrien Thebo (25):
  12bb73f (#2157) Add external fact support
  19f8328 (#2157) external facts command line - bin/facter
  223293c (#2157) external facts command line - lib/facter/application.rb
  87fc73e (#2157) external facts command line - lib/facter/util/config.rb
  45e5bf1 (#2157) external facts command line -
lib/facter/util/directory_loader.rb
  07720aa (#2157) external facts - lib/facter/util/directory_loader.rb
  34a337e (#2157) parser classes can register an array of
extensions - lib/facter/util/config.rb
  3c12374 (#2157) raise error if parser doesn't implement #results
- lib/facter/util/parser.rb
  a4317a5 (#2157) Catch infinite infinite loop when loading json -
lib/facter/util/parser.rb
  cab9b7d (#2157) add support for scriptparser on windows -
lib/facter/util/parser.rb
  87e4691 (#2157) add powershell script parser - facter/util/parser.rb
  45b8cf3 (#2157) external facts command line - install.rb
  c22b9ff (#2157) Add external facts README to redhat spec
  da1982b (#2157) add readme for libexec external facts
  70ea5b1 (#2157) Update config spec to test ext_fact_dir
  11535d0 (#2157) Used puppetlabs spec helper for directoryloader tests
  76104aa (#2157) Update directory_spec to reference new libexec dir
  22c5a25 (#2157) directory_loader uses results instead of values
  e0668a7 (#2157) test directory loader to make sure loading
non-existing directories is all cool, yo
  becb778 (#2157) shorten spec_helper require in parser_spec.rb
  75b7cea (#2157) cleanup and reformatting of directory_loader_spec
  9285308 (#2157) Converted parser spec to use PuppetlabsSpec::Files helper
  6f9a10a (#2157) Add test coverage for parser matches? function
  f188d09 (maint) centralize system fact stubbing in virtual specs
  0818832 Revert Merge branch

[Puppet Users] Not custom facts, but variables?

After reading several posts, it looks like setting a key on every host, and 
supplying a different value based on that host's function is not a proper 
use of facts, but more for variables.

We are using hiera, and based on my hierarchy,


:hierarchy:
  - common
  - %{application}
:yaml:
  :datadir: /etc/puppetlabs/hieradata/%{environment}

Without using an ENC, what's are some good ways to tag the server with a 
value for %{application}. 

thanks so much,

Tony


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

Re: [Puppet Users] Not custom facts, but variables?


I am still confuzzled by your application 

Would you provide a more specific example ? 
I am thinking that this is something that can be controlled at the module level 

http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#parser-set-variables
 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Tony C tonyjch...@gmail.com 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 2:28:40 PM 
Subject: [Puppet Users] Not custom facts, but variables? 

After reading several posts, it looks like setting a key on every host, and 
supplying a different value based on that host's function is not a proper use 
of facts, but more for variables. 


We are using hiera, and based on my hierarchy, 






:hierarchy: 
- common 
- %{application} 

:yaml: 
:datadir: /etc/puppetlabs/hieradata/%{environment} 


Without using an ENC, what's are some good ways to tag the server with a 
value for %{application}. 


thanks so much, 


Tony 





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


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

Re: [Puppet Users] Not custom facts, but variables?

2013-04-08 Thread Jonathan Proulx

On Mon, Apr 8, 2013 at 2:28 PM, Tony C tonyjch...@gmail.com wrote:

 After reading several posts, it looks like setting a key on every host,
 and supplying a different value based on that host's function is not a
 proper use of facts, but more for variables.

 We are using hiera, and based on my hierarchy,


 :hierarchy:
   - common
   - %{application}
 :yaml:
   :datadir: /etc/puppetlabs/hieradata/%{environment}

 Without using an ENC, what's are some good ways to tag the server with a
 value for %{application}.


I do exactly this using facts.

using puppetlabs_stdlib module to provide simple custom facts from
/etc/facter/facts.d (after partitioning and installing a base OS) our
install process writes a custom text file to this directory defining facts
for role, group and cluster which are all parts of our hiera
hierarchy and then calls puppet for the first time.

This may not be the best way in a more orderly environment but I work in an
academic research lab so have lots of messy edge cases that can't be
determined by name or IP and need to delegate these definitions to people
who are not admin enough to have access to our puppet repo but do have
local root on the systems they manage...

-Jon

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

[Puppet Users] Re: Remove msi from windows 7

2013-04-08 Thread Paul Tötterman



 Could someone help me to understand why the place absent, the package you 
 are installing is not removed?

  package { 'mozilla':


This is a wild guess, but the package title (name, whatever it's called) 
should match the item in the Programs and Features Control Panel.

Try fixing that and see if the problem persists.

Cheers,
Paul 

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

Re: [Puppet Users] Not custom facts, but variables?

sure, to be specific,

we have environments, dev, test, qa, stage, and prod. That part I got with 
your help on my last post. Thank you.

Within these environments, we have applications. We only have a few apps. 
So let's say some machines are oracle db machines, some are tomcat, and 
some are apache. 

I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each 
of these yaml files contain some key value pair that is specific to that 
environment. 

So when some machine is provisioned, I want to say this machine is a tomcat 
machine, and I don't care what environment it since I will let the agent 
conf figure that out. That way I can one puppet module for tomcat, but 
different values per environment.

I hope that makes sense, and if my approach is completely wrong, I'm open 
to hear some alternatives. Thanks again everyone.

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

Re: [Puppet Users] Not custom facts, but variables?

Based on your description, I would suggest the following: 

Let's take tomcat as a specific example. 
Assumption: You have a tomcat module that can be configured with parameters. 

Here is the suggestion: Add a hostname level to your heirarchy. 

OK, so now for node hostx.example.org, you want this to be a tomcat server. All 
you need do is put the appropriate parameters into hostx.example.org.yaml 

I am still a hiera n00b myself, so I am not totally sure exactly how to do 
this, but I am working on it. 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Tony C tonyjch...@gmail.com 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 2:43:41 PM 
Subject: Re: [Puppet Users] Not custom facts, but variables? 

sure, to be specific, 


we have environments, dev, test, qa, stage, and prod. That part I got with your 
help on my last post. Thank you. 


Within these environments, we have applications. We only have a few apps. So 
let's say some machines are oracle db machines, some are tomcat, and some are 
apache. 


I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of 
these yaml files contain some key value pair that is specific to that 
environment. 


So when some machine is provisioned, I want to say this machine is a tomcat 
machine, and I don't care what environment it since I will let the agent conf 
figure that out. That way I can one puppet module for tomcat, but different 
values per environment. 


I hope that makes sense, and if my approach is completely wrong, I'm open to 
hear some alternatives. Thanks again everyone. 

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


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

Re: [Puppet Users] Not custom facts, but variables?

2013-04-08 Thread Jonathan Proulx

On Mon, Apr 8, 2013 at 2:57 PM, Dan White y...@comcast.net wrote:

 Based on your description, I would suggest the following:

 Let's take tomcat as a specific example.
 Assumption: You have a tomcat module that can be configured with
 parameters.

 Here is the suggestion: Add a hostname level to your heirarchy



but if you have multiple tomcat servers (for example) then you have to
repeat data for each hostname which is exactly the wrong thing.

using a custom fact (I use role for essentially the same thing Tony wants
to use application for) you can classify nodes without an ENC and without
repeating yourself.

My hierarchy is:
# cat /etc/puppet/hiera.yaml
---
:hierarchy:
 - %{fqdn}
 - %{role}
 - %{group}
 - %{osfamily}
 - common
:backends:
 - yaml
 - puppet
:yaml:
 :datadir: /etc/puppet/environments/%{environment}/data
:puppet:
 :datasource: data

I do have fqdn, but that is always too specific, except maybe for testing.
Role is what the system does and group is who manages it, both of these
come form custom facts on the system in /etc/factor/facts.d (requires
puppetlabs_stdlib) so I can have multiple nodes (in some cases hundreds)
with the same role.  Keying this off fqdn or cert name would me a nightmare

Picking the right hierarchy and the right level into to place data is a bit
of a black art, but crucial to having a manageable config.  This has been
workable for me for the past 9 months or so, but not pretenses to
perfection...

-Jon



 OK, so now for node hostx.example.org, you want this to be a tomcat
 server.  All you need do is put the appropriate parameters into
 hostx.example.org.yaml

 I am still a hiera n00b myself, so I am not totally sure exactly how to do
 this, but I am working on it.


 “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)

 --
 *From: *Tony C tonyjch...@gmail.com
 *To: *puppet-users@googlegroups.com
 *Sent: *Monday, April 8, 2013 2:43:41 PM
 *Subject: *Re: [Puppet Users] Not custom facts, but variables?


 sure, to be specific,

 we have environments, dev, test, qa, stage, and prod. That part I got with
 your help on my last post. Thank you.

 Within these environments, we have applications. We only have a few apps.
 So let's say some machines are oracle db machines, some are tomcat, and
 some are apache.

 I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each
 of these yaml files contain some key value pair that is specific to that
 environment.

 So when some machine is provisioned, I want to say this machine is a
 tomcat machine, and I don't care what environment it since I will let the
 agent conf figure that out. That way I can one puppet module for tomcat,
 but different values per environment.

 I hope that makes sense, and if my approach is completely wrong, I'm open
 to hear some alternatives. Thanks again everyone.

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



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




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

Re: [Puppet Users] Not custom facts, but variables?

That looks great. 

Another thing to consider: As of hiera 1.2.0, you have deep merge for hashes. 
You do not need to repeat parameters at every level ! 


“Sometimes I think the surest sign that intelligent life exists elsewhere in 
the universe is that none of it has tried to contact us.” 
Bill Waterson (Calvin  Hobbes) 

- Original Message -
From: Jonathan Proulx j...@jonproulx.com 
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 3:14:04 PM 
Subject: Re: [Puppet Users] Not custom facts, but variables? 


On Mon, Apr 8, 2013 at 2:57 PM, Dan White  y...@comcast.net  wrote: 






Based on your description, I would suggest the following: 

Let's take tomcat as a specific example. 
Assumption: You have a tomcat module that can be configured with parameters. 

Here is the suggestion: Add a hostname level to your heirarchy 






but if you have multiple tomcat servers (for example) then you have to repeat 
data for each hostname which is exactly the wrong thing. 


using a custom fact (I use role for essentially the same thing Tony wants to 
use application for) you can classify nodes without an ENC and without 
repeating yourself. 


My hierarchy is: 
# cat /etc/puppet/hiera.yaml 
--- 
:hierarchy: 
- %{fqdn} 
- %{role} 
- %{group} 
- %{osfamily} 
- common 
:backends: 
- yaml 
- puppet 
:yaml: 
:datadir: /etc/puppet/environments/%{environment}/data 
:puppet: 
:datasource: data 


I do have fqdn, but that is always too specific, except maybe for testing. 
Role is what the system does and group is who manages it, both of these 
come form custom facts on the system in /etc/factor/facts.d (requires 
puppetlabs_stdlib) so I can have multiple nodes (in some cases hundreds) with 
the same role. Keying this off fqdn or cert name would me a nightmare 


Picking the right hierarchy and the right level into to place data is a bit of 
a black art, but crucial to having a manageable config. This has been workable 
for me for the past 9 months or so, but not pretenses to perfection... 



-Jon 





blockquote


OK, so now for node hostx.example.org , you want this to be a tomcat server. 
All you need do is put the appropriate parameters into hostx.example.org.yaml 

I am still a hiera n00b myself, so I am not totally sure exactly how to do 
this, but I am working on it. 



“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) 


From: Tony C  tonyjch...@gmail.com  
To: puppet-users@googlegroups.com 
Sent: Monday, April 8, 2013 2:43:41 PM 
Subject: Re: [Puppet Users] Not custom facts, but variables? 



sure, to be specific, 


we have environments, dev, test, qa, stage, and prod. That part I got with your 
help on my last post. Thank you. 


Within these environments, we have applications. We only have a few apps. So 
let's say some machines are oracle db machines, some are tomcat, and some are 
apache. 


I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of 
these yaml files contain some key value pair that is specific to that 
environment. 


So when some machine is provisioned, I want to say this machine is a tomcat 
machine, and I don't care what environment it since I will let the agent conf 
figure that out. That way I can one puppet module for tomcat, but different 
values per environment. 


I hope that makes sense, and if my approach is completely wrong, I'm open to 
hear some alternatives. Thanks again everyone. 

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






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



/blockquote



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


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from

Re: [Puppet Users] Not custom facts, but variables?

Thanks for your response, but I can see me possibly having tons of yaml 
files since it's very possible I may have 100 tomcat servers, all with the 
same configuration. I don't think it will scale. 

 
On Monday, April 8, 2013 11:57:10 AM UTC-7, Ygor wrote:

 Based on your description, I would suggest the following:

 Let's take tomcat as a specific example.
 Assumption: You have a tomcat module that can be configured with 
 parameters.

 Here is the suggestion: Add a hostname level to your heirarchy.

 OK, so now for node hostx.example.org, you want this to be a tomcat 
 server.  All you need do is put the appropriate parameters into 
 hostx.example.org.yaml

 I am still a hiera n00b myself, so I am not totally sure exactly how to do 
 this, but I am working on it.

 “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)

 --
 *From: *Tony C tonyj...@gmail.com javascript:
 *To: *puppet...@googlegroups.com javascript:
 *Sent: *Monday, April 8, 2013 2:43:41 PM
 *Subject: *Re: [Puppet Users] Not custom facts, but variables?

 sure, to be specific,

 we have environments, dev, test, qa, stage, and prod. That part I got with 
 your help on my last post. Thank you.

 Within these environments, we have applications. We only have a few apps. 
 So let's say some machines are oracle db machines, some are tomcat, and 
 some are apache. 

 I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each 
 of these yaml files contain some key value pair that is specific to that 
 environment. 

 So when some machine is provisioned, I want to say this machine is a 
 tomcat machine, and I don't care what environment it since I will let the 
 agent conf figure that out. That way I can one puppet module for tomcat, 
 but different values per environment.

 I hope that makes sense, and if my approach is completely wrong, I'm open 
 to hear some alternatives. Thanks again everyone.

 -- 
 You received this message because you are subscribed 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 javascript:.
 To post to this group, send email to puppet...@googlegroups.comjavascript:
 .
 Visit this group at http://groups.google.com/group/puppet-users?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  


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

Re: [Puppet Users] Not custom facts, but variables?

Jon,

Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar 
with this module. I read on it but not sure specifically how you are using 
it.

Thanks,

Tony

On Monday, April 8, 2013 12:14:04 PM UTC-7, Jonathan Proulx wrote:

 On Mon, Apr 8, 2013 at 2:57 PM, Dan White yg...@comcast.net javascript:
  wrote:

 Based on your description, I would suggest the following:

 Let's take tomcat as a specific example.
 Assumption: You have a tomcat module that can be configured with 
 parameters.

 Here is the suggestion: Add a hostname level to your heirarchy



 but if you have multiple tomcat servers (for example) then you have to 
 repeat data for each hostname which is exactly the wrong thing.

 using a custom fact (I use role for essentially the same thing Tony 
 wants to use application for) you can classify nodes without an ENC and 
 without repeating yourself.

 My hierarchy is:
 # cat /etc/puppet/hiera.yaml
 ---
 :hierarchy:
  - %{fqdn}
  - %{role}
  - %{group}
  - %{osfamily}
  - common
 :backends: 
  - yaml
  - puppet
 :yaml:
  :datadir: /etc/puppet/environments/%{environment}/data
 :puppet:
  :datasource: data

 I do have fqdn, but that is always too specific, except maybe for 
 testing.  Role is what the system does and group is who manages it, 
 both of these come form custom facts on the system in /etc/factor/facts.d 
 (requires puppetlabs_stdlib) so I can have multiple nodes (in some cases 
 hundreds) with the same role.  Keying this off fqdn or cert name would me a 
 nightmare

 Picking the right hierarchy and the right level into to place data is a 
 bit of a black art, but crucial to having a manageable config.  This has 
 been workable for me for the past 9 months or so, but not pretenses to 
 perfection...

 -Jon

   

 OK, so now for node hostx.example.org, you want this to be a tomcat 
 server.  All you need do is put the appropriate parameters into 
 hostx.example.org.yaml

 I am still a hiera n00b myself, so I am not totally sure exactly how to 
 do this, but I am working on it.


 “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)

 --
 *From: *Tony C tonyj...@gmail.com javascript:
 *To: *puppet...@googlegroups.com javascript:
 *Sent: *Monday, April 8, 2013 2:43:41 PM
 *Subject: *Re: [Puppet Users] Not custom facts, but variables?


 sure, to be specific,

 we have environments, dev, test, qa, stage, and prod. That part I got 
 with your help on my last post. Thank you.

 Within these environments, we have applications. We only have a few apps. 
 So let's say some machines are oracle db machines, some are tomcat, and 
 some are apache. 

 I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each 
 of these yaml files contain some key value pair that is specific to that 
 environment. 

 So when some machine is provisioned, I want to say this machine is a 
 tomcat machine, and I don't care what environment it since I will let the 
 agent conf figure that out. That way I can one puppet module for tomcat, 
 but different values per environment.

 I hope that makes sense, and if my approach is completely wrong, I'm open 
 to hear some alternatives. Thanks again everyone.

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




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

[Puppet Users] Re: Not custom facts, but variables?

Looks like external facts are available after facter 1.7, i'm using 1.6 

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

Re: [Puppet Users] Not custom facts, but variables?

2013-04-08 Thread Jonathan Proulx

On Mon, Apr 8, 2013 at 3:33 PM, Tony C tonyjch...@gmail.com wrote:

Jon,

Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar
with this module. I read on it but not sure specifically how you are using
it.

stdlib provides many useful functions, most of which are called by other
modules.

The use that relates to this case is facter-dot-d see
https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3/for
a write up.

The simple case (which is the one we use is making a plain text file in
/etc/facter/facts.d (anything in there ending in .txt gets parsed as plain
text)) with key=value pairs that then become facter facts.

for example on my puppet managed workstation:

$ cat /etc/facter/facts.d/csail.txt
role=wkst
autofs=true

So when puppet runs the fact role is set to wkst which pulls in the
right classes to make a generic workstation, the fact group mentioned
above is undefined which is OK there's just no customization based on
groups and autofs is a facter key that our local wkst module looks at to
see if our NFS automount should be configured or not. By default we don't
but the local root user can define this to true and on the next puppet run
the config will happen for them.

We install the stdlib module on the puppet masters (implemneted as a git
submodule in our git repo) and use pluginsync=true on the clients to pull
down the bits they need from this and other modules. Though you could
distribute the required facter-dot-d.rb file in other ways, pluginsync is
most convenient for us.

-Jon

[Puppet Users] Re: Show manifest code in rdoc

2013-04-08 Thread llowder



On Monday, April 8, 2013 12:36:33 PM UTC-5, banjer wrote:

 Is it possible to have puppet doc show all of the manifest code in the 
 generated docs?  I'm generating some html docs and would love to be able to 
 look at the actual code for each class or define statement.  With syntax 
 highlighting would be even sweeter.

 I'm using the following to create my docs:

 sudo puppet doc --all --mode rdoc --outputdir 
 /usr/local/foreman/public/puppet/rdoc/development --modulepath 
 /etc/puppet/modules/

 FYI:


I don't think puppet doc / rdoc can, but something like pocco[1] may be 
able to.
 

 Puppet master 3.1.1
 Foreman 1.1.1
 these both run on CentOS 6.4

 Thanks for your comments.


 [1] https://github.com/nanliu/puppet-pocco

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

Re: [Puppet Users] Not custom facts, but variables?

Right on!

Thanks Jon,

That was it. Got it working just as you stated. It's exactly what I need.

Tony

On Monday, April 8, 2013 1:01:58 PM UTC-7, Jonathan Proulx wrote:

On Mon, Apr 8, 2013 at 3:33 PM, Tony C tonyj...@gmail.com
javascript:wrote:

Jon,

Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar
with this module. I read on it but not sure specifically how you are using
it.

stdlib provides many useful functions, most of which are called by other
modules.

The use that relates to this case is facter-dot-d see
https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3/for
a write up.

for example on my puppet managed workstation:

$ cat /etc/facter/facts.d/csail.txt
role=wkst
autofs=true

-Jon

Re: [Puppet Users] Re: replacing mkdir -p

2013-04-08 Thread Luca Gioppo

Can you post a complete example please?
Thanks
Luca


2013/4/4 Mike Power dodts...@gmail.com

 Actually I found if I created a resource between path and file called
 element, I could give it a unique name.  Then inside the body I could check
 to see if the File is declared, if not I could declare it.

 On Thursday, April 4, 2013 9:23:54 AM UTC-7, Mike Power wrote:

 Puppet right now requires every element of a path to have an individual
 file definition.  This makes it had to take an arbitrary path as a
 parameter.  You are forced to require your client to make the entire path
 structure for you or instead you use an exec resource and call mkdir -p.
 Using an exec resource does not generate an File resources so autorequire
 does not work.

 I didn't like this, I wanted to be able to once specify a path and have
 puppet do that autorequire as needed.

 Something like:
 path {/blah/blah/blah/and/blah:
 }


 In order to make this happen I would have to manually define each file:
 file {/blah/:
 ensure  = directory,
 }

 file {/blah/blah/:
 ensure  = directory,
 }

 file {/blah/blah/blah/:
 ensure  = directory,
 }

 file {/blah/blah/blah/and/:
 ensure  = directory,
 }

 file {/blah/blah/blah/and/blah/:
 ensure  = directory,
 }

 Of course there is a short hand for this:
 file {[/blah/, /blah/blah/, /blah/blah/blah/,
 /blah/blah/blah/and/,/blah/**blah/blah/and/blah/]:
 ensure  = directory,
 }

 Then it occurred to me I could parse the path and produce the array of
 elements needed.  Something like:
 $path = /blah/blah/blah/and/blah
 $file_list = split($path, $file_separator)
 $paths = inline_template('% parent = nil %%=@file_list.collect{
 |file| parent.nil? ? parent = #{@file_separator}:parent =
 #{parent}#{file}#{@file_**separator}}.join(@path_**separator) %')
 $path_list = split($paths, $path_separator)
 file{$path_list:
 ensure  = directory,
 }

 This works great once.  Then you get errors like:
 Error: Duplicate declaration: File[/]

 If there anyway to trim down the produced array by removing the resources
 that already exist?







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




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

[Puppet Users] Puppet parameterized class - include for declaration?

2013-04-08 Thread Shantanu


The parameterized classes guide mentions that a parameterized class is 
declared using following syntax [1]:

class {'classname': }


But the puppetlabs postgresql 
modulehttps://github.com/puppetlabs/puppet-postgresql#setupmentions that a 
parameterized class '
postgresql::serverhttps://github.com/puppetlabs/puppet-postgresql/blob/master/manifests/server.pp'
 
can be declared using 'include' syntax [2]. 

So is 'include' syntax supported for parameterized classes now?

--
Shantanu


1. http://docs.puppetlabs.com/guides/parameterized_classes.html
2. https://github.com/puppetlabs/puppet-postgresql#setup


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

Re: [Puppet Users] Re: replacing mkdir -p