Re: [Puppet Users] puppet agent errors for non included module.

[Wolf Noble]

Hi JJ,

I've seen this happen when class dependencies are placed outside the
specific class' scope, ie:

# default.pp
#
#
Anchor['my_prereq::end'] -> Class['default']
class{ 'default':
  notice 'default'
}

I've only seen this occur with anchors, but it's entirely possible it
happens with other resources too..


I've seen a node which uses class my_prereq, and class default run, and
then another node run with neither of those classes in it's catalog, but
the error about the unsatisfied relationship still displayed…

I've not seen any other instances of this occur, but there may be other
reasons for it to happen.
HTH.

W



On Wed, Jun 12, 2013 at 3:52 PM, Jeremiah Jester
wrote:

> Does anyone know why i would get a module error for my 'base' module that
> I'm not even including for a node?  I'm explicitly NOT include the 'base',
> yet puppet-client-t2 still errors when i pull it in. Snips from both are
> below. Any ideas why this would happen?
>
> Thanks,
> JJ
>
> 
>
> site.pp file
>
> [root@puppet-master-t1 puppet]# cat manifests/site.pp
> node 'puppet-client-t1' {
> include base
> include base::firewall
> }
> node 'puppet-client-t2' {
> include monitoring
> }
>
> puppet agent run on client...
>
> jjest@puppet-client-t2 puppet]$ su -c "puppet agent -t"
> Password:
> Info: Retrieving plugin
> Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> Info: Loading facts in
> /var/lib/puppet/lib/facter/iptables_persistent_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/ip6tables_version.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb
> *Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find data item rsfw_rules in any Hiera data file and no
> default supplied at /etc/puppet/modules/base/manifests/firewall.pp:1 on
> node puppet-client-t2.mcis.washington.edu*
> *Warning: Not using cache on failed catalog*
> *Error: Could not retrieve catalog; skipping run*
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] puppetlabs_spec_helper error on environments: undefined method `invalidate_refreshes='

[René Weber]

Hi there,

I'm am currently trying to get my puppet running on Version 3.1.1 together 
with puppetlabs spec helper.
I managed to set up all my global modules correctly, including fixtures and 
specs but I can not manage to implement specs in my environment.
Everytime I run 'rake spec' in my environments' module, I receive a 
cryptical error like

 Puppet::Error:
   Could not autoload puppet/type/service: undefined method 
`invalidate_refreshes=' for # on 
node xy

*The weird thing is, if I copy a module where 'rake spec' is succeeding 
from '/etc/puppet/modules/' to my environment, I get the same result.*



*My configuration look like this:*



*/etc/puppet/environments/first/modules/vpn/Rakfile*

require 'rubygems'
require 'puppetlabs_spec_helper/rake_tasks'


*/etc/puppet/environments/first/modules/vpn/manifest/tunnel.pp*
class vpn::tunnel {
   somestuff
}

*/etc/puppet/environments/first/modules/vpn/spec/spec_helper.rb*
require 'puppetlabs_spec_helper/module_spec_helper'


And my specfile does currently only define some facts...


Any Ideas?? I am really running out of ideas.

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: New to Puppet bash: command not found

[mdcrawford]

Greetings, Earthlings.  I just subscribed.

I haven't actually tried out Puppet yet, but I just downloaded the Learn 
Puppet VM.

On Saturday, June 15, 2013 9:11:17 AM UTC-7, gfda...@gmail.com wrote:

> *bash: puppetca: command not found  * I get this no matter which 
> command I try to run.
>*^ "Bourne Again Shell"*
>

In your home directory on your Linux box are some "hidden" files and 
folders, whose names all start with a dot or period: "."

The files aren't really hidden, it's just that there is a convention that 
documents whose names start with dots aren't displayed unless you 
specifically request such display.

In a terminal program such as xterm, gterm or kterm, you can see all of 
your documents, including your "Dot Files", with the "ls -a" command.

Most likely you already have a document called ".bash_profile".  You may as 
well have documents called ".profile" or ".bashrc".

When you're using a terminal program such as gterm, there is a command 
interpreter running inside the terminal that searches for and executes each 
command when you type its after the "$" prompt.  For example:

   $ emacs

... will launch the emacs text editor.

However there are several places where these programs can be placed.  For 
regular (non-administrative) users, these are generally:

   /bin
   /usr/bin
   /usr/local/bin

You don't want bash to have to search your entire hard drive to look for 
executable files.  Instead, bash will search a preset list of directories 
(folders).  That preset list is in your PATH environment variable.  You can 
find out what its present value is:

   $ echo $PATH

Placing "$" in the front of a shell variable will result in the value 
stored in the variable being substituted for where you named the variable 
itself.

Each directory in your PATH is delimited (or separated) by a colon 
character - ":".

You don't generally want to remove existing items from PATH.  Instead, you 
usually want to add new items to its list.  bash will search the list from 
beginning to end, so if two programs with the exact same name are found in 
two different directories in your path, the one whose directory is named 
before the other will be the one that actually gets executed.

It's common for one to install personally-developed programs in a directory 
called "bin" in one's home directory.  It's path can be abbreviated as 
"~/bin".  "~" is shorthand for "my home directory".  You can prepend it to 
your PATH like so:

   $ export PATH=~/bin:"$PATH"

The double-quotes are needed only if there are space characters already 
present in your $PATH.  If you're sure there won't be any spaces, you won't 
need the quotes.

On your own box, substitute the directory where you placed the puppet 
executables for "~/bin" in the command line above.  If bash stops 
complaining, then you got your new $PATH right.  Now place the same command 
line in either ".profile", ".bash_profile" or ".bashrc".  However, leave 
off the initial "$" shell prompt:

   # ~/.profile

export PATH=/path/to/puppet/executables:"$PATH"

One can - and often does - have shell variables that aren't also 
environment variables:

export TERM=vt220# $TERM is an environment variable

myname=mike# $myname is a shell variable, but it's not in the 
environment

The difference between the two is that the environment is inherited by 
subprocesses.  That is, if you launch a new program from within bash, that 
new program will also know what your $PATH is.

Google for "UNIX shell tutorial".  There are lots of really good tutorials 
out there.

There are other UNIX shells, other than bash.  Bash is a Free Software 
clone of the original AT&T Bourne shell "/bin/sh", but with lots of 
features from the Berkeley C Shell "/bin/csh" added to it.

Ever Faithful,

Mike Crawford
mdcrawf...@gmail.com
CyberneticEntomologist on GitHub and the PuppetLabs sites

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Managing (and pinning) package versions with puppet

[Ken Chida]

Why not do:

package {'foo':
ensure => present
}


This will only ensure that some version of 'foo' is installed.  Also, I've 
found that excessive pinning slows down 'apt-cache policy', which puppet 
appears to run for each package resource.  I've improved puppet runs by an 
order of magnitude by removing pins.

-Ken

On Friday, June 14, 2013 3:06:00 PM UTC-7, Andres Olarte wrote:
>
> I have an installation that I'm trying to manage with puppet. For some of 
> the packages we want to have very tight control over the versions. Since 
> they are critical to our application, we only upgrade them after testing in 
> our test environment, and we schedule upgrades during low traffic times. I 
> don't want puppet to upgrade my database whenever a new package appears. I 
> specified the version in my puppet manifest to prevent the package from 
> automatically upgrading, however when I went to generate another instance 
> using the same config, that version of the package was gone from the Ubuntu 
> repo. Only the more recent ones are there.
>
> For some of the packages, I've been packing them myself into my own repo, 
> however packaging the database (postgresql) has proven too be too much 
> overhead.
>
> Any solutions or ideas?
>
> We're using Ubuntu 12.04.1 LTS.
>
>
> Thanks,
>
>
> Andres
>

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet-dashboard work well but can't see any node

[Rajat Patel]

Hi Guys,

We have Cent OS 6.4 server which is puppet master server, its take all mix 
environment(fedora/redhat/centos/windows).

Right now we have add 2 node one from ubuntu 12.10 and fedora 18.

We can deploy all policy which we want to.

To show POC to management We need config puppet-dashboard which web pages 
is coming but can see any node add to the page.

We have try adding manually which is not working out.

Kindly let us know what could be issues. 

[root@master sysconfig]# /etc/init.d/puppet-dashboard start
Starting Puppet Dashboard: config.gem: Unpacked gem rspec-rails-1.3.4 in 
vendor/gems has no specification file. Run 'rake gems:refresh_specs' to fix 
this.
config.gem: Unpacked gem factory_girl-1.3.3 in vendor/gems has no 
specification file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem sass-3.1.2 in vendor/gems has no specification 
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem daemons-1.0.10 in vendor/gems has no specification 
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem thoughtbot-shoulda-2.10.2 in vendor/gems has no 
specification file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem rack-1.1.6 in vendor/gems has no specification 
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem haml-3.1.2 in vendor/gems has no specification 
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem rspec-1.3.2 in vendor/gems has no specification 
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem rdoc-3.6.1 in vendor/gems has no specification 
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem mocha-0.9.7 in vendor/gems has no specification 
file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem will_paginate-2.3.15 in vendor/gems has no 
specification file. Run 'rake gems:refresh_specs' to fix this.
config.gem: Unpacked gem json_pure-1.7.7 in vendor/gems has no 
specification file. Run 'rake gems:refresh_specs' to fix this.
=> Booting WEBrick
=> Rails 2.3.17 application starting on http://0.0.0.0:3000
   [  OK  ]

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] The handy Grail of Modules Standards

[Alessandro Franceschi]

Dear all,
I'd like to submit to the list's attention this post about Puppet Modules 
Standard naming conventions:
http://www.example42.com/?q=The_handy_Grail_of_Modules_Standards 

and  this working draft of a proposal for a version 0.0.1 of them:
https://docs.google.com/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA/edit?usp=sharing

The topic is not new, and on this list there have already been various 
discussions on how to manage modules' interoperability ( for example this 
interesting one on cross-modules 
dependencies: 
https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/modules$20standards|sort:date/puppet-users/Fvl0aOe4RPE)
 
.

Along with the current discussions on the topic and the Puppet evolution, I 
think that few simple *suggested* naming conventions on common parameters 
for classes and defines would benefit a lot the module's ecosystem with a 
small effort.

I hope the discussion will have a real follow up, this time, and possibly 
move under the more authoritative PuppetLabs umbrella, for the moment is 
just a personal proposal, even if shared, at least in the intentions, with 
many modules' authors and Puppetteers.

You can actively contribute to the proposed naming standards on the above 
Google document (let me know your gmail account) and you are invited to 
comment here what do you think of this (not new) idea: if you think that 
starting from simple naming convention is a step to be done, what's your 
general idea on the proposed naming standards, if you have better ideas on 
naming and approach. 

Let's grab this handy Grail :-)
Alessandro Franceschi
Example42

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Managing (and pinning) package versions with puppet

[Rajat Patel]

In my opinion the version and/or holdable features should be re-implemented 
as a new variable, such as:

package { 'apache2'
  ensure => installed,
  version => '2.0.64',
  hold => true,
}


Rajat

On Saturday, June 15, 2013 3:36:00 AM UTC+5:30, Andres Olarte wrote:
>
> I have an installation that I'm trying to manage with puppet. For some of 
> the packages we want to have very tight control over the versions. Since 
> they are critical to our application, we only upgrade them after testing in 
> our test environment, and we schedule upgrades during low traffic times. I 
> don't want puppet to upgrade my database whenever a new package appears. I 
> specified the version in my puppet manifest to prevent the package from 
> automatically upgrading, however when I went to generate another instance 
> using the same config, that version of the package was gone from the Ubuntu 
> repo. Only the more recent ones are there.
>
> For some of the packages, I've been packing them myself into my own repo, 
> however packaging the database (postgresql) has proven too be too much 
> overhead.
>
> Any solutions or ideas?
>
> We're using Ubuntu 12.04.1 LTS.
>
>
> Thanks,
>
>
> Andres
>

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] The handy Grail of Modules Standards

[Matthias Saou]

Hi,

First off... is these some pun I'm not getting, or was it supposed to
be "Holy Grail"? Just wondering :-)

Also, when I read "Puppet Modules Standard naming conventions", I
thought it was just about module names, but it seems to be about
parameter naming inside all of the module resources.

After reading the shared Google document, I got reminded a lot of
what I've seen happen with RPM packaging over the years. Lot of
similarities, since both Puppet and RPM are tools which give a lot of
freedom in the way things get implemented.

Think of GNU/Linux distributions such as Fedora, RHEL, Mandriva, SuSE,
etc. which all use RPM packages as their building blocks : They are not
to be considered compatible for various reasons, yet they could have
been in theory.

With Puppet, each author is currently like each distribution using RPM :
Doing things in a given ecosystem, with implementation choices being
made, all of which can easily differ enough to make modules from
different authors incompatible.

Now the problem that I see here is that with RPM things have never been
able to converge on a global scale. There isn't one single right answer,
and it has never been the tool's goal to enforce how it's being used,
especially when it's purely cosmetic or related to details that many
find irrelevant.

Where I'm trying to get at is that I see Puppet as being similar in the
fact that it doesn't try to enforce any high-level cosmetic choices,
such as parameter names, and I think it's the right behavior for the
basic tool itself.

>From there, I'm all for trying to "standardize" something, but that's
actually much harder than it seems, and won't work unless there is some
enforcing being done at some point. One possibility would be to have a
review-based approval process for forge modules, where guidelines would
have to be enforced before a module gets published. Of course, that's a
lot of time and resources, for what boils down to being considered
"boring work" by most. It's what works for many GNU/Linux distributions
(Debian, Fedora, etc.).

Just my 2¢ ;-)

Matthias

-- 
Matthias Saou  ██  ██
 ██  ██
Web: http://matthias.saou.eu/  ██
Mail/XMPP:  matth...@saou.eu   ██  
   ██
GPG: 4096R/E755CC63██  ██  ██
 8D91 7E2E F048 9C9C 46AF  ██  ██  ██  ██
 21A9 7A51 7B82 E755 CC63  

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] ruby issue

[jcbollinger]

On Friday, June 14, 2013 9:13:19 PM UTC-5, Michael Stanhke wrote:
>
> Puppet Labs doesn't try to replace packages in 
> provided by the upstream OS vendor.
>

Yay!  Thank you!  PL has no business replacing vendor-supplied OS 
components.  It especially has no business configuring repositories such 
that there is a risk of users installing such replacement components 
without realizing they are doing so.  WTG, PL.


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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] The handy Grail of Modules Standards

[Alessandro Franceschi]

On Monday, June 17, 2013 1:17:45 PM UTC+2, Matthias Saou wrote:
>
> Hi, 
>
> First off... is these some pun I'm not getting, or was it supposed to 
> be "Holy Grail"? Just wondering :-) 
>

It's holy but is also handy, as I think it's just at hands reach.
 

>
> Also, when I read "Puppet Modules Standard naming conventions", I 
> thought it was just about module names, but it seems to be about 
> parameter naming inside all of the module resources. 
>
> After reading the shared Google document, I got reminded a lot of 
> what I've seen happen with RPM packaging over the years. Lot of 
> similarities, since both Puppet and RPM are tools which give a lot of 
> freedom in the way things get implemented. 
>
> Think of GNU/Linux distributions such as Fedora, RHEL, Mandriva, SuSE, 
> etc. which all use RPM packages as their building blocks : They are not 
> to be considered compatible for various reasons, yet they could have 
> been in theory. 
>
> With Puppet, each author is currently like each distribution using RPM : 
> Doing things in a given ecosystem, with implementation choices being 
> made, all of which can easily differ enough to make modules from 
> different authors incompatible. 
>
> Now the problem that I see here is that with RPM things have never been 
> able to converge on a global scale. There isn't one single right answer, 
> and it has never been the tool's goal to enforce how it's being used, 
> especially when it's purely cosmetic or related to details that many 
> find irrelevant. 
>
> Where I'm trying to get at is that I see Puppet as being similar in the 
> fact that it doesn't try to enforce any high-level cosmetic choices, 
> such as parameter names, and I think it's the right behavior for the 
> basic tool itself. 
>
> From there, I'm all for trying to "standardize" something, but that's 
> actually much harder than it seems, and won't work unless there is some 
> enforcing being done at some point. One possibility would be to have a 
> review-based approval process for forge modules, where guidelines would 
> have to be enforced before a module gets published. Of course, that's a 
> lot of time and resources, for what boils down to being considered 
> "boring work" by most. It's what works for many GNU/Linux distributions 
> (Debian, Fedora, etc.). 
>
> Just my 2¢ ;-) 
>

Thanks for your opinion, even if I don't fully agree with it.
Puppet is a language and so people do the same things in different ways, 
and they all work and do what they are supposed to do.
But if we think about modules REUSABILITY and INTEROPERABILITY some 
patterns have to be followed.
Some of the parameters described in the document are somehow REQUIRED, 
IMHO, if you want to make a really reusable module (for example the ones 
that let you decide how to manage your configuration files... if you 
enforce a logic in a module or a specific template and don't allow override 
by users, then you are not making a reusable module, so for example a 
parameter like "template" is just needed).
So, since, at least some of, these parameters are needed for a reusable 
module  it's just a matter of defining few naming conventions (and managing 
external modules dependencies in a sane way) to make different modules 
happily live better together.

Note, I don't say that ALL the modules should have ALL these parameters, 
I'd consider these Standard Namings as suggestions which people may decide 
to follow or not (somehow similar to the Code Style suggestions, which 
leverage the style of the Puppet code and have found tools like puppet-lint 
to validate them). Once enough good and prominent Puppet modules will 
follow these naming conventions, it will be easier for people to switch 
modules, integrate the best ones from different sources (without forking 
them) , use these parameters from a WEB interface, a a standard framework 
from smoke testing and have the benefits which are better described in the 
blog post.

Note also that these proposals are based on the current Puppet language 
specifications, I want to start from what can be used now, with an eye on 
the evolution on Puppet, but with still feet on the ground: nothing new or 
to invent, just few basic naming convention to agree upon and *suggest*.

I still think that this is at hands reach :-)

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: puppetlabs-apt and package resource dependency

[jcbollinger]

On Friday, June 14, 2013 4:02:30 AM UTC-5, n...@clue.co.za wrote:
>
> Hi
>
> I have only recently started using modules off the forge and running a 
> recent version of Puppet (the majority of our network is still utilising 
> 0.25.4).  I spent a significant amount of time ensuring that dependencies 
> in our existing Puppet implementation result in a single Puppet run will 
> always succeed with the intended config applied to a node.
>
> When making use of puppetlabs-apt I notice that there is nothing included 
> in that module that would make the Exec['apt_update'] run before other 
> package resources in my catalogue.
>


That is because any such relationship would be outside the module's scope 
-- the module is about managing your apt configuration, not about managing 
packages via apt.

 

>  My thought would be to add something like this to update.pp:
>   
> Exec['apt_update'] -> Package <| title != "python-software-properties" and 
> title != "software-properties-common" |>
>
>

Adding something along these general lines to your manifest set is fine if 
it is appropriate for you, but it does not belong in the puppetlabs-apt 
module.  For one thing, it would needlessly (and perhaps harmfully) catch 
packages that use providers other than apt, such as gem.  Although I think 
it's a poor practice to use multiple package managers on the same system, 
some people do so.  There are other potential problems as well.

 

> I have also tried using the tag metaparameter ( tag != "apt" ) but then 
> ended up with a dependency cycle.
>


I'm not surprised you did, with that.

 

>
> Does anyone have an opinion as to why this is a terrible idea?  I ask 
> because I have submitted a pull request for the change prior to reading the 
> very informative page about contributing to puppetlabs modules and would 
> value any community feedback on my approach.
>
>

As I said, what you are suggesting does not belong in the module, though 
something like it may be appropriate for manifest sets that use the 
module.  Outside the module, though, it would probably be better practice 
to use something like this:

Class['apt::update'] -> Package<|  |>

so as not to rely on module implementation details.


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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] ruby issue

[Stuart Cracraft]

Don't replace them.

Just PROVIDE them.

One-stop shop for yum downloads for non PE people.

The analogy is PE Enterprise for the normal "rank-and-file".

What you like to call "the Collective"...

On Jun 17, 2013, at 10:27 AM, jcbollinger  wrote:

> 
> 
> On Friday, June 14, 2013 9:13:19 PM UTC-5, Michael Stanhke wrote:
> Puppet Labs doesn't try to replace packages in 
> provided by the upstream OS vendor.
> 
> Yay!  Thank you!  PL has no business replacing vendor-supplied OS components. 
>  It especially has no business configuring repositories such that there is a 
> risk of users installing such replacement components without realizing they 
> are doing so.  WTG, PL.
> 
> 
> John
>  
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Puppet Users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/puppet-users/ghDZsdkC3C0/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
> 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Issue installing on RHEL 6 (2.6.32-358.2.1.el6.x86_64)

[Kenneth Edgar]

We do use Satellite and this server is subscribed to 64bit repos.  I found 
I was using the incorrect puppet labs repo, and installed the following one 
instead... however I still have the same 
issue. 
http://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-7.noarch.rpm

What I found is that since we branch rhel's channels to "freeze" them at a 
certain level for quarterly updating, these puppetlabs rpm's must have had 
higher requirements that were not available using our "frozen" channels.  I 
added the server to the default rhel 6 64 bit channel and updated it, then 
the packages installed properly.

Thanks,
Ken

On Sunday, June 9, 2013 3:12:10 PM UTC-5, Jon Stanley wrote:
>
> On Fri, Jun 7, 2013 at 4:45 PM, Kenneth Edgar 
> > 
> wrote: 
> >Protected multilib versions: libselinux-2.0.94-5.3.el6.i686 != 
> > libselinux-2.0.94-5.3.el6_4.1.x86_64 
> >  You could try using --skip-broken to work around the problem 
> >  You could try running: rpm -Va --nofiles --nodigest 
>
> Basically this indicates a problem with your yum configuration or 
> repos. What it's refusing to do is to install differing versions of 
> the same package for different architectures (i686 and x86_64) 
>
> Particularly, the libselinux package has an issue. What this error 
> means is that you attempted to install libselinux-2.0.94-5.3.el6.i686 
> but you have 2.0.94-5.3.el6_4.1.x86_64 already installed (or the other 
> way around, I forget) 
>
> If you're using the install media as a repo on an updated system, that 
> would explain this. The el6_4 dist tag indicates an async errata (i.e. 
> released between major RHEL releases) for RHEL6.4, while the .el6 is 
> what gets shipped on install media (overly simplifying things here, 
> you could have prior releases async errata, for example el6_3 in a 
> minor release if there were no other changes) for a minor release. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Managing (and pinning) package versions with puppet

[jcbollinger]

On Monday, June 17, 2013 5:05:41 AM UTC-5, Rajat Patel wrote:
>
> In my opinion the version and/or holdable features should be 
> re-implemented as a new variable, such as:
>
> package { 'apache2'
>   ensure => installed,
>   version => '2.0.64',
>   hold => true,
> }
>
>
>
 
Would you care to comment on why you think that would be better?  A 
specific version number is a special case of 'hold', which itself is a 
special case of 'installed'.  Splitting them out as separate parameters 
would create the opportunity for them to be inconsistent, and I don't see 
anything useful to be gained in return.


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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet dashboard on FreeBSD 9

[Ivailo Tanusheff]

Hi,

I am trying to install puppet-dashboard on FreeBSD 9, but with no success.
The link on their site: 
http://docs.puppetlabs.com/dashboard/manual/1.2/bootstrapping.html make me 
no good and is almost useless.
Can someone provide some knowledge or how to do this? Or I have to give up 
on that?

Regasrds,
Ivailo Tanusheff

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppet agent errors for non included module.

[jcbollinger]

On Monday, June 17, 2013 2:12:35 AM UTC-5, Wolf Noble wrote:
>
> Hi JJ,
>
> I've seen this happen when class dependencies are placed outside the 
> specific class' scope, ie:
>
> # default.pp
> #
> #
> Anchor['my_prereq::end'] -> Class['default']
> class{ 'default':
>   notice 'default'
> }
>
>

It is incorrect to make that relationship declaration (via the chain 
operator) if there are any nodes that do not declare the specified anchor, 
because top-level declarations in *any* manifest file apply to all nodes.  
It is poor practice to make declarations at top level like that other than 
class and defined-type definitions, however, except sometimes in site.pp 
and manifests 'import'ed by it.  When they appear in other places, Puppet 
may or may not see them during any given catalog run, but you must not 
assume that Puppet will fail to see them under any given circumstances.

Thus, manifest files that are intended to be autoloaded should contain 
exactly one thing at top-level: the definition of the class or defined type 
that is the autoloading target.


On the other hand, I would be surprised if a top-level dependency 
declaration caused a referenced class to be declared when it otherwise was 
not declared.  That's not an issue in the example because a declaration of 
the class involved occurs in the same manifest, at the same level as the 
chain, so the class (but not necessarily the anchor) will always be 
declared if the relationship is declared.  That could point to the actual 
problem, though: there may somewhere be just such a top-level declaration 
of class 'base::firewall'.  Otherwise, it must be that class 'monitoring' 
declares class 'base::firewall', either directly or indirectly.


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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Accessing other parts of the Hiera tree

[jcbollinger]

On Monday, June 17, 2013 12:28:18 AM UTC-5, Robin Powell wrote:
>
> This seems to come up for me a lot.  As an example, my Hiera data 
> includes both hypervisors and the VMs that they contain.  It would 
> be very useful to have the VMs say "I'm a VM on host X" and, in 
> templates in host X, be able to say "What are all my VMs?". 
>


It is inherently non-idiomatic for your templates (or manifests) to pose 
such a question, or really any question.  Rather than asking a question, 
the templates may need to say "my VMs are [...]".  I know I'm being 
nit-picky with the wording, but people really need to get a firm grip on 
the concept in order to master Puppet.

 

>
> Doing this via storeconfigs rather defeats the purpose of my Hiera 
> tree, which is to be the single source of truth. 
>


I think you're focusing on the wrong thing when you say that.  To the 
extent that it's applicable to the problem, storeconfigs is simply the 
infrastructure that makes exported resources work.  It is in no way an 
independent source of truth, because everything in it comes from 
declarations made in one manifest or another, based on node facts and 
possibly on data from some other source.  Put another way, in its 
application to problems of this kind, storeconfigs serves merely as an 
asynchronous communication channel.

Focusing on exported resources, then, these are simply a mechanism for 
making declarations during the compilation of one node's catalog that can 
later be incorporated by reference into any node's catalog.  Such 
declarations draw on whatever source(s) of truth you choose, and no others, 
just like any other declarations your manifests make.  Collecting exported 
resources later does not introduce any new sources of truth.
 

>
> The way I'm currently doing it is to have a script that collates all 
> my Hiera host data into a special YAML file, and then have templates 
> read that YAML. 
>
>

So you in fact *don't* have a single source of truth currently.  Not any 
more so than you would have with exported resources, at least.  Your 
collation script and special YAML file simply take the place of 
master-mediated resource export and the storeconfigs database, 
respectively.  Perhaps you have other reasons to want to avoid 
storeconfigs, but otherwise I cannot imagine why you think what you've come 
up with is superior to using exported resources.

 

> I'm wondering if there's a better/more correct/more idiomatic way to 
> engage in this sort of referential linking across the Hiera tree? 
>
>

It depends in part on whether you intend to extend your 
single-source-of-truth requirement to include DRY requirements on your 
hiera data.  One possibility would be to provide indices in your hiera data 
-- for example, for each VM host, an array of the names of its VMs.  That's 
not DRY, however, if it duplicates information in VMs' individual data 
files.

If you want all needed data stored in hiera, with no redundancy and no use 
of intermediate collation, then all the data need to be provided to (at 
least) all the associated nodes; that is, to the VM host and all its VMs.  
They all need to get all the data, else there is no escaping a need for 
some kind of data duplication.

You might find it convenient and logical to structure it as one large, 
complex, nested value, from which the individual components would select 
the pieces they need.  For example, a hash with VM hostnames as keys, and 
hashes of VM names to VM parameter hashes as values (i.e. a trebly-nested 
hash).  Alternatively, there are ways you could spread out the data over 
multiple Hiera keys, but the overall logical structure is going to be 
similar.

It should be obvious at this point is that with this kind of data 
structure, you are not going to be able to use automated class parameter 
binding to assist in declaring most of the various interrelated bits and 
pieces.

Given those choices, I would probably opt for exported resources, myself.


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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: puppetlabs_spec_helper error on environments: undefined method `invalidate_refreshes='

[Trung Nguyen]

I am getting the same exact error. My puppet version is 3.2.1. The weird 
thing is that, my other nodes running on different version of puppet did 
not experience this error. This is a new node running on VMWare  Centos 
system. Anyone has any idea?

On Monday, June 17, 2013 1:36:17 AM UTC-7, René Weber wrote:
>
> Hi there,
>
> I'm am currently trying to get my puppet running on Version 3.1.1 together 
> with puppetlabs spec helper.
> I managed to set up all my global modules correctly, including fixtures 
> and specs but I can not manage to implement specs in my environment.
> Everytime I run 'rake spec' in my environments' module, I receive a 
> cryptical error like
>
>  Puppet::Error:
>Could not autoload puppet/type/service: undefined method 
> `invalidate_refreshes=' for # on 
> node xy
>
> *The weird thing is, if I copy a module where 'rake spec' is succeeding 
> from '/etc/puppet/modules/' to my environment, I get the same result.*
>
>
>
> *My configuration look like this:*
>
>
>
> */etc/puppet/environments/first/modules/vpn/Rakfile*
>
> require 'rubygems'
> require 'puppetlabs_spec_helper/rake_tasks'
>
>
> */etc/puppet/environments/first/modules/vpn/manifest/tunnel.pp*
> class vpn::tunnel {
>somestuff
> }
>
> */etc/puppet/environments/first/modules/vpn/spec/spec_helper.rb*
> require 'puppetlabs_spec_helper/module_spec_helper'
>
>
> And my specfile does currently only define some facts...
>
>
> Any Ideas?? I am really running out of ideas.
>

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet Windows package not seeing DisplayName in Registry?

[Adnan Chowdhury]

I don't foresee any bad side-effects.


On Sat, Jun 15, 2013 at 1:48 AM, Josh Cooper  wrote:

>
>
> On Thursday, June 13, 2013, Reginald Choudari wrote:
>
>>
>>
>> On Wednesday, June 12, 2013 5:23:50 PM UTC-4, Josh Cooper wrote:
>>>
>>>
>>>
>>>
>>> On Wed, Jun 12, 2013 at 12:51 PM, Reginald Choudari <
>>> adnancho...@gmail.com> wrote:
>>>
 Tried renaming the title of the resource to what the name attribute was
 set to; no go.

 After doing a 'puppet resource package' on the agent, I see a list of
 packages but the package listed here is not shown ... I confirmed that it
 is still showing 'ensure: created' in the event logs every puppet run.

 Thanks
>>>
>>>
>>> Can you export the Uninstall registry key for that package? I want to
>>> see what the SystemComponent, etc values are.
>>>
>>>
 On Friday, June 7, 2013 10:54:36 AM UTC-4, Reginald Choudari wrote:
>
> Hello,
>
> I've got Package resource on my Windows machine that keeps creating
> itself even though the package has been properly installed.
>
> I've got the name attribute set to the DisplayName found in the
> Registry for the package.
>
> Every time the agent polls, I see in the Event Logs:
>
> /Stage[main]/Mssql_rtwo_sptwo/Package[mssql2008r2sp2_exec]/**e**nsure:
> created
>
> This is what's in my manifest:
>
> package { 'mssql2008r2sp2_exec':
> ensure  => installed,
> name=> 'SQL Server 2008 R2 SP2 Common Files',
> provider=> windows,
> source  => "C:\\puppet_temp\\${mssql_**file**name}",
> install_options => ['/quiet', '/**IAcceptSQLServerLicenseTerms**',
> '/allinstances'],
> require => Exec['run_mssql2008r2sp2_**artif**
> act_extract_ps1'],
>   }
>
> I'm thinking there has got to be some weird bug/error with this ...
> Can anyone help?
>
> Thanks in advance
>
  --
 You received this message because you are subscribed to the Google
 Groups "Puppet Users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to puppet-users...@**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
 .



>>>
>>> Josh
>>>
>>> --
>>> Josh Cooper
>>> Developer, Puppet Labs
>>>
>>> *Join us at PuppetConf 2013, August 22-23 in San Francisco - *
>>> http://bit.ly/pupconf13*
>>> **Register now and take advantage of the Early Bird discount - save 25%!
>>> *
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "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.
>>
>>
>>
>
> Unfortunately, Windows does not have an API for retrieving installed
> packages. So we scan the registry and apply heuristics to determine which
> packages to report on.
>
> The overall goal has been for Puppet to report on the same set of packages
> that you see in Add/Remove Programs. Packages whose registry
> value SystemComponent=1 are hidden from ARP, so Puppet does the same, see
> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/windows/exe_package.rb#L34
>
> Since Puppet never reports on SystemComponents, it will always think they
> are absent, and need to be installed each time it runs.
>
> I'm thinking Puppet should not exclude SystemComponents? Are there any bad
> side effects if we included them?
>
> Josh
>
>
> --
> Josh Cooper
> Developer, Puppet Labs
>
> *Join us at PuppetConf 2013, August 22-23 in San Francisco - *
> http://bit.ly/pupconf13*
> **Register now and take advantage of the Early Bird discount - save 25%!*
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/ftvvO51bX1U/unsubscribe.
>
> To unsubscribe from this group and all its topics, 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.
>
> 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 emai

Re: [Puppet Users] Puppet Windows package not seeing DisplayName in Registry?

[Kevin D]

Josh,

You mentioned:

> Unfortunately, Windows does not have an API for retrieving installed 
> packages.
>

Does this include the WMI class 
Win32_Product?
  
Win32_product provides a limited set of information about all products 
installed using MSI/Windows Installer.  Although Windows Installer is a 
standard, not all compiled installers use this method.

-Kev


-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet Windows package not seeing DisplayName in Registry?

[Josh Cooper]

On Mon, Jun 17, 2013 at 12:05 PM, Kevin D wrote:

> Josh,
>
> You mentioned:
>
> Unfortunately, Windows does not have an API for retrieving installed
>> packages.
>>
>
> Does this include the WMI class 
> Win32_Product?
> Win32_product provides a limited set of information about all products
> installed using MSI/Windows Installer.  Although Windows Installer is a
> standard, not all compiled installers use this method.
>
> -Kev
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "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.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

Win32_Product has issues. Simply enumerating the set of installed packages
will cause a consistency check to be performed on all packages:

http://sdmsoftware.com/group-policy-blog/wmi/why-win32_product-is-bad-news/
http://gregramsey.net/2012/02/20/win32_product-is-evil/
http://support.microsoft.com/kb/974524

Josh

-- 
Josh Cooper
Developer, Puppet Labs

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Early Bird discount - save 25%!*

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Puppet Management with Dual Boot Workstation

[Neil M]

Hi everyone, I'm trying to figure out what is the best way to handle a 
single system that dual boots with a puppet client running in each.  In 
this case we are talking about Ubuntu 12.04 and Windows 8.  Should I just 
copy the certificate from one OS to the other?  Should I have a different 
certificate for each OS?  In this case can they have the same hostname, as 
it is the same IP address for both OSes?  Can I somehow use a different 
hostname for each that doesn't match DNS?  I understand from a client point 
of view it probably doesn't matter a whole lot, but I am also using Foreman 
(and I imagine Puppet Dashboard would have a similar issue) and I'd like to 
be able to check on the facts and status of both Ubuntu and Windows at any 
given time, not just the OS that happens to be running at the moment.  
Thanks!

Neil

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Puppet 3.1.1 Windows crashes

[Josh Cooper]

On Fri, Jun 14, 2013 at 10:59 PM, Josh Cooper  wrote:

>
>
> On Tuesday, June 11, 2013, Michael O'Dea wrote:
>
>> Sorry for the long delay - since I'd mitigated I moved on to other
>> things.  Thanks for the quick fix.  Deploying servers is no simple process
>> in my environment so I guess I'll need to stick with the old clients for a
>> while.
>>
>>
> Do you happen to be running on non en_us systems? I'm wondering if there
> is an issue with multibyte to UTF-16LE conversion of the event record
> data.
>
> On Thursday, June 6, 2013 4:45:08 PM UTC-4, Josh Cooper wrote:
>>>
>>> Hi Michael,
>>>
>>> On Thu, Jun 6, 2013 at 8:01 AM, Michael O'Dea  wrote:
>>>
>>> I neglected to mention this crash leaves behind the lockfile, so while
>>> the puppet service is still running, all future puppet runs exit saying
>>> "another puppet run is in progress".
>>>
>>>
>>>
>>> On Thursday, June 6, 2013 10:55:21 AM UTC-4, Michael O'Dea wrote:
>>>
>>> I noticed that a number of my Windows hosts had stopped dialing in, and
>>> upon closer inspection I found that Puppet was crashing in Ruby and
>>> wevtapi.dll.  I can't find any reference to this in the issue tracker,
>>> although I've got over a dozen occurrences in my environment, all with the
>>> same descriptions as below.  I checked to see if the times were similar, in
>>> case the server presented some bad data to cause the issue, but the crashes
>>> occurred at all different times and days.
>>>
>>> My question is, has anyone else seen this? Is this a known issue?
>>>
>>>
>>> It is now :) 
>>> https://projects.**puppetlabs.com/issues/21109
>>>
>>>
>>>   If it is fixed in 3.2.1, can I install 3.2.1 clients against a 3.1.x
>>> server?
>>>
>>>
>>> In general, running newer agents against older servers is not supported.
>>>
>>>
>>>   In the meantime, I will be rolling back to an older 2.7.x version that
>>> we'd run for some time without issue.
>>>
>>> Thanks in advance.  Fault details below.
>>>
>>> Faulting application name: ruby.exe, version: 1.8.7.371, time stamp:
>>> 0x5083a46c
>>>
>>> Faulting module name: wevtapi.DLL, version: 6.1.7600.16385, time stamp:
>>> 0x4a5bdb2d
>>> Exception code: 0xc005
>>> Fault offset: 0x1360
>>> Faulting process id: 0xa48
>>> Faulting application start time: 0x01ce5e0840c39580
>>> Faulting application path: C:\Program Files (x86)\Puppet
>>> Labs\Puppet\sys\ruby\bin\ruby.exe
>>> Faulting module path: C:\Windows\system32\wevtapi.**DL**L
>>>
>>>
>>> This is the DLL responsible for windows event logging (the new API in
>>> Vista and up). By default, puppet creates an eventlog log destination, and
>>> there must be an issue in either puppet or the win32-eventlog gem we are
>>> using. What's strange is that the code is unchanged since 2.7.14. So
>>> perhaps it's an issue with the message resource dll. I will take a look.
>>>
>>> For workarounds, you could change the default log destination to a file
>>> while we debug the issue. I don't think this can be controlled via
>>> puppet.conf, but you use the registry module to configure the puppet
>>> service start arguments to include `--logdest ` to log to a file.
>>>
>>> Josh
>>>
>>> --
>>> Josh Cooper
>>> Developer, Puppet Labs
>>>
>>> *Join us at *
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "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.
>>
>>
>>
>
> Josh
>
>
> --
> Josh Cooper
> Developer, Puppet Labs
>
> *Join us at PuppetConf 2013, August 22-23 in San Francisco - *
> http://bit.ly/pupconf13*
> **Register now and take advantage of the Early Bird discount - save 25%!*
>
>
Do you happen to have a usermode dumps enabled? If not, could you enable it
on one of the systems where you were seeing the issue, as described here:
http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx.

If you do capture a crash, please contact me off list.

Josh

-- 
Josh Cooper
Developer, Puppet Labs

*Join us at PuppetConf 2013, August 22-23 in San Francisco - *
http://bit.ly/pupconf13*
**Register now and take advantage of the Early Bird discount - save 25%!*

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Accessing other parts of the Hiera tree

[Robin Lee Powell]

[snipped heavily, hopefully nothing important]

On Mon, Jun 17, 2013 at 09:48:48AM -0700, jcbollinger wrote:
> 
> On Monday, June 17, 2013 12:28:18 AM UTC-5, Robin Powell wrote:
> >
> > Doing this via storeconfigs rather defeats the purpose of my
> > Hiera tree, which is to be the single source of truth. 
> >
> 
> 
> I think you're focusing on the wrong thing when you say that.  To
> the extent that it's applicable to the problem, storeconfigs is
> simply the infrastructure that makes exported resources work.  It
> is in no way an independent source of truth, because everything in
> it comes from declarations made in one manifest or another, based
> on node facts and possibly on data from some other source.

I didn't see the point in getting into this before, but you raise
valid issues, so:

That would be true, if facts automatically expired when not renewed,
but they don't.  I've had *no end* of trouble with lies sticking
around because they were in storeconfigs.  I don't mean to propose
that they *should* auto-expire, as that doesn't fit the model at
all, but it's still a very real problem.

> You might find it convenient and logical to structure it as one
> large, complex, nested value, from which the individual components
> would select the pieces they need.  For example, a hash with VM
> hostnames as keys, and hashes of VM names to VM parameter hashes
> as values (i.e. a trebly-nested hash).  Alternatively, there are
> ways you could spread out the data over multiple Hiera keys, but
> the overall logical structure is going to be similar.

*nodnod*  OK, that seems sane, thanks.

> It should be obvious at this point is that with this kind of data
> structure, you are not going to be able to use automated class
> parameter binding to assist in declaring most of the various
> interrelated bits and pieces.

Enh; I've already gotten around that with my users setup by using
create_resources(...)

> Given those choices, I would probably opt for exported resources,
> myself.

It's been so bad for me.  ;_;  After the 4th time of "Why won't
nagios stop alerting on this host I turned off and removed from all
my configs!?! ... Oh.", I got really sick of it.  The *main goal*
for me in using Hiera is to never use storeconfigs ever again.

-Robin

-- 
You received this message because you are subscribed to the Google Groups 
"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.
For more options, visit https://groups.google.com/groups/opt_out.