Re: [Puppet Users] Re: Is ensure_resource() evil?

[jcbollinger]

On Wednesday, March 21, 2018 at 8:46:02 AM UTC-5, jcbollinger wrote:
>
>
>
> On Wednesday, March 21, 2018 at 4:03:28 AM UTC-5, Martin Alfke wrote:
>>
>> I prefer the each lambda over ensure_resource and create_resource. 
>> my 5pc. 
>>
>
> In this particular case, the ensure_resource() call is inside a defined 
> type that is used both internally and externally, so I don't think the 
> each() function is going to help me.  But I think I can probably solve 
> the problem (as much as I care to do) by overriding parameters of the 
> defined type instances instead of the objects of ensure_resource().  The 
> cost of that will be that the defined type needs to expose such parameters 
> in the first place, which it otherwise would not need to do, and those 
> parameters will serve an internal purpose rather than an external one.
>

... and, silly me, *of course* that doesn't work.  Overriding the 
parameters of the defined type lands too late to affect the resource it 
(maybe) declares indirectly via ensure_resource() -- which is yet another 
reason why that function is an evil demon toad, lurking in the shadows and 
waiting to pounce on you and jump up and down on your head.  With nasty, 
big, pointy teeth.


John
#evildemontoad

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/72310b5d-29d9-4463-8db2-67e64b9742a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Is ensure_resource() evil?

[jcbollinger]

On Wednesday, March 21, 2018 at 4:03:28 AM UTC-5, Martin Alfke wrote:
>
> I prefer the each lambda over ensure_resource and create_resource. 
> my 5pc. 
>

In this particular case, the ensure_resource() call is inside a defined 
type that is used both internally and externally, so I don't think the 
each() function is going to help me.  But I think I can probably solve the 
problem (as much as I care to do) by overriding parameters of the defined 
type instances instead of the objects of ensure_resource().  The cost of 
that will be that the defined type needs to expose such parameters in the 
first place, which it otherwise would not need to do, and those parameters 
will serve an internal purpose rather than an external one.


John
#ensureresourceisevil

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/69a3a69a-672b-44c1-9cc2-9c58746a6558%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Is ensure_resource() evil?

[jcbollinger]

On Tuesday, October 17, 2017 at 7:59:16 AM UTC-5, jcbollinger wrote:

>
> Nothing has changed with `ensure_resource()`.  The problem is not its 
> implementation details, but rather the nature of the usage modes the 
> function is *designed* to support.  The whole idea of it is flawed.
>


Funny story:

I have recently been working with an "approved" Forge module, which will go 
unnamed.  It has a long history, and overall is of high quality.  But it 
happens to use ensure_resource(), and sure enough, that bit me in the ass: 
it is the cause of a module bug that crops up under relatively unusual 
circumstances.  Then when I tried to fix the bug, ensure_resource() did it 
again.

The failure mode isn't even among those I usually harp on.  Maybe the 
function's behavior has changed over time, or maybe I never knew this about 
it, but in Stdlib 4, the function only protects against declaration of 
*identical* resources -- it will happily generate a resource with the same 
title as another that has already been declared, as long as there is a 
difference between their declared parameters.  This of course elicits a 
duplicate resource declaration error from Puppet (and this is intentional: 
function's docs disclose it).

And here's the kicker: after my attempted bugfix, the duplicate 
declarations in fact *are* identical, at least as expressed to 
ensure_resource().  They are rendered non-identical externally by 
application of a resource override.  Apparently, the override is applied 
either together with application of the first ensure_resource() call in 
some way that messes up the resource comparison in the second, or between 
the effects of the first call and the effects of the second call.  Maybe 
that's a bug.

To be sure, I would rather have the function fail loudly than break 
quietly, but I would even more have liked to have a module that doesn't 
depend on ensure_resource() in the first place.


John
"ensure_resource() is evil"

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

[Puppet Users] Re: Resource chaining is not being honored

[jcbollinger]

On Thursday, March 8, 2018 at 4:53:27 PM UTC-6, Johnathan Komara wrote:
 

> 'profile::a' should be applied to every server and 'profile::b' is only 
> being applied to a few servers. My understanding of resource chaining is 
> that I can alter the order in which the classes are ran. I need "b" to run 
> first so that I can key off of "defined(File['/etc/test/txt']).
>


No, you don't, and you shouldn't.  You should not use the defined() 
function at all, in fact, because it produces evaluation-order 
dependencies, which is exactly what you are dealing with.  You will find 
considerable discussion of this topic in the archives of this group, 
including several previous assertions on my part that defined() is evil.

Additionally, you are conflating two different orderings: order of manifest 
*evaluation* on the master and order of catalog *application* on the target 
node.  Resource relationships, whether established via the chain operators 
or via the appropriate resource metaparameters,affect only the latter, 
whereas defined(), being evaluated during catalog building, is affected 
only by the former.
 

>
> I have tried multiple approaches and I cannot get this to work.
>


I'm not at all surprised, since even if you are determined to use defined() 
despite my advice, you're trying to use the wrong tool for the job of 
getting the evaluation order you need to make it work.  Evaluation order 
depends primarily on the contents and lexical order of your manifests.  It 
is extremely difficult to predict, and if you have caching enabled in the 
relevant environment then you're pretty much toast.

 

> The only way that it works is if I explicitly include 'profile::b' before 
> 'profile::a' in base. 
>
> class profile::base {
>   include 'modules'
>   include '::profile::b'
>   include '::profile::a'
> }
>
> Or if I remove 'profile::a' from base and include them both in the role.
>
> class role::test_server inherits ::role {
>   include '::profile::b'
>   include '::profile::a'
> }
>
>
As I said, the contents and lexical order of your manifests.  But even that 
may not be reliable.  Classes can be included multiple times, from multiple 
locations, and if you have another location where you include ::profile::a 
before or without including ::profile::b, then your result will depend 
which declaration of ::profile::a is evaluated first.
 

>
> I have alternatives. I can set values in hiera to key off of or push out 
> custom facts.
>


And that is what you indeed should do instead.  There might be room for an 
accompanying refactoring of your manifest set to go along with it and make 
things smoother, but you'll need to determine that for yourself.

Moreover, you might not need to add anything in the first place.  You 
already have logic some place to determine whether to assign 
role::test_server to your nodes.  It seems that's the same thing you want 
to rely on here.

 

> Custom facts will not be there on the first run which is probably ok. I 
> think we would run into a few issues here and there but I could make it 
> work.
>


Custom facts could work too, but it is best for the target configuration of 
your nodes to be determined by their identities and invariant 
characteristics, based on centrally-maintained manifests and data.

 

> Everything I have read says that chaining the resource should enforce the 
> order but I am obviously missing something. Can someone see what I am doing 
> wrong or explain why this will not work?
>


In addition to what I've already said, the fact that you're using class 
inheritance has bad code smell, and in practice it contributes to your 
problem.

Class inheritance is an ancient feature of the language that was originally 
intended to provide for overriding the parameters of resources declared by 
the parent class.  It still works for that, but Puppet has other mechanisms 
for that purpose, and for avoiding the need for overrides in the first 
place, and nowadays those are stylistically preferred.  Class inheritance 
also has the side effect of causing the parent class to be evaluated before 
the child class, which is what makes the params class pattern work, and 
that pattern is the only widely accepted use for class inheritance in 
modern Puppet.

In OO-speak, prefer composition over inheritance. Very much more so in 
Puppet DSL -- which looks a lot more like an OO language than it really is 
-- than in general-purpose OO programming languages, such Java or C++.


John

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

Re: [Puppet Users] Unable to solve a require statement

[jcbollinger]

On Tuesday, March 6, 2018 at 1:50:28 PM UTC-6, P.C. Kroon wrote:
>
> Hi Jochen,
>
>  
>
> I’m going to give this back to the rest of the list since I’m out of my 
> depth, and I don’t have the time to figure out the details at the moment. 
> Good luck though 
>

In the first place, since you are using dpkg instead of apt to install the 
DEB, and especially to the extent that you care which of the two 
alternative packages are used to satisfy the package dependency, your 
Package['wpcli'] should express a direct or indirect resource dependency on 
the MySQL client Package you want to use.  Since you're using 
puppetlabs-mysql, perhaps you want to depend on Class['::mysql::client'], 
but if you're wrapping that inside a profile (different from the one in 
which your problem occurs), then you should probably depend on the profile 
class instead.  As a matter of good form and style, however, you should not 
attempt to express relationships with resources managed by other classes, 
especially across module boundaries.

You may express an explicit relationship with the DEB File resource, too, 
but you do not need to do, because Puppet will automatically generate 
dependencies between Packages and their managed source files (see the 
"Autorequires" section in the resource type's documentation 
).

Thus, you might want something like this:

$debfile = '/tmp/php-wpcli_latest_all.deb'

file { "$debfile" : 
  ensure => 'file', 
  source => 'puppet:///modules/profile/wordpress/php-wpcli_1.5.0_all.deb', 
} 

package { 'wpcli': 
  ensure   => 'installed', 
  provider => 'dpkg', 
  source   => "$debfile", 
}

# 1. This assumes that you have a profile class '::profile::mysql_client' 
wrapping the PL
#::mysql::client class.  If not, then you could depend directly on
#Class['::mysql::client'].
# 2. You could express this same relationship with a 'require' attribute, 
if you prefer.
Class['::profile::mysql_client'] -> Package['wpcli']


Note well that for the dependency on your profile class to work reliably, 
you need to ensure that the profile provides proper containment 
 of the 
appropriate application class (e.g. ::mysql::client), which you would 
achieve via appropriate use of the contain 
 function / 
statement.

Ultimately, what I'm describing as not very different from what Peter 
recommended.  It may be that I've hit on a key detail that he missed, but 
without more information about your manifest set, it's hard to confidently 
offer a solution.  If the above does not solve your problem, then I think 
it would behoove you to present a minimal yet complete example manifest set 
that reproduces the problem for you, primarily stripped-down versions of 
the manifests you and your organization wrote.  Supposing that you're using 
off-the-shelf puppetlabs-mysql, do not include any of its manifests, but 
do, please, tell us which version you are using.


John

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

[Puppet Users] Re: 'require' option is ignored?

[jcbollinger]

On Thursday, February 15, 2018 at 9:46:17 AM UTC-6, buoyant_puppy wrote:
>
> Got it, thanks everyone.
>
> Just one small point to add - I'm not actually directly concerned with 
> Execs here. If you look at my original example, I was needing to do a 
> conditional check like "if directory exists then...", and my Exec-based 
> solution for it is just an ugly workaround. I understand the puppet 
> philosophy here is focused on being declarative, but it's just extremely 
> common that we don't have the pleasure of working in a purely declarative 
> environment. As such I think it'd be nice to see unless/requires/etc evolve 
> further.
>


You are not the first to express an interest in Puppet developing in that 
direction, but Puppet already has mechanisms for the kind of thing you 
describe.  The main approaches to adapting to target-machine state are

   1. to rely on *facts* collected from the node to influence details of 
   the catalog.  To this end, there are well-developed facilities for defining 
   and distributing your own custom facts.
   2. to rely on resource providers to behave appropriately for the target 
   environment; this is under the control of provider developers, including 
   you if you wish to be one.

These are well-matched to Puppet's model of operation, which is to first 
compute a target state based on the machine's identity and current state, 
site manifests, and site data (catalog building); then to attempt to take 
whatever action is needed to put the machine in that state (catalog 
application).  A key aspect here is that the target state embodied by a 
catalog is unconditional at the level of abstraction of the catalog, and 
perhaps that's what you mean by "purely declarative".  But although that 
perhaps fits the catalog, it does not fit Puppet DSL at all, nor, 
therefore, the overall system.

In the past, I have been fond of saying "Puppet is not a script engine."  I 
consider that a strength, not a weakness.


John

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

[Puppet Users] Re: containment questions

[jcbollinger]

On Wednesday, February 14, 2018 at 12:02:41 PM UTC-6, Peter Bauer wrote:
>
> hi,
>
> i was recently bitten by ordering issues caused by missing contain/anchor 
> declarations in a PostgreSQL module which should have finished its job 
> before configuring and starting the PuppetDB which is done by another 
> module.
> So here are my questions:
> - is it possible to use the contain function also for defined resource 
> types/defines? I ended up using anchors since i could not find out how to 
> use contain here.
>


Resources, whether of defined or plugin type, are automatically contained 
by the object that declares them.  You don't need to use contain, anchors, 
or any other special measure to make that happen.  Containment needs to be 
explicitly managed only for classes.

On the other hand, it generally does not make sense for a resource instance 
to contain a class, because classes are singletons.  If a resource (of a 
defined type) contained a class, then all resources of the same type would 
need to have overlapping containment, which often is not possible (and 
whose feasibility in practice is typically unpredictable).  Therefore, 
although it sometimes makes sense for a defined type to include or even 
require a class, if you think containment is warranted then convert the 
defined type into a class itself.

 

> - am i the only one thinking that it is too error-prone and cumbersome to 
> add a contain everytime a sub-class is instantiated in a module? Since it 
> is not transitive it has to be added on every abstraction layer of a 
> module, from the init.pp down to all sub-classes until there are just 
> classes left declaring resources directly. And in case one contain is 
> missing, that code may be executed in the wrong time.
>


If you really mean "sub-class" in the class inheritance sense, then either 
your Puppet usage is highly suspect or your terminology is.  I suspect you 
just mean "class", or maybe "module class" if you want to emphasize that 
the class in question belongs to the same module as the one declaring it.  
Do not mistake Puppet DSL for an object-oriented language along C++ lines.  
The DSL is object oriented in its own fashion, but Puppet's "classes" are 
not very analogous to C++'s.

Anyway, it is an intentional design feature that classes are not 
automatically contained by the object that declares them.  This follows 
necessarily from the fact that classes can be declared multiple times in 
different scopes.  If containment were automatic then exercising that 
multiple-declaration freedom would rapidly create unresolvable dependency 
cycles.

Inasmuch as you complain about multiple layers, I'm inclined to suspect 
that your problems are partly attributable to your approach to module 
design.  A module with deeply nested containment has bad code smell to me, 
so consider flattening.


John

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

[Puppet Users] Re: containment questions

[jcbollinger]

On Thursday, February 15, 2018 at 9:09:34 PM UTC-6, Jeremiah Powell wrote:
>
> You can also use stages to define strong barriers to order large parts of 
> a task.  The canonical example is configuring a database before the 
> application that needs it.
>

Stages are the wrong tool for almost every task, and especially for 
containment problems.  Stages best serve cases where you can formulate 
*universal*, generic rules, such as "Package repositories must be installed 
and configured before anything (else) that requires managing packages," but 
which you cannot easily implement those in terms of specific relationships 
or collector-based chaining rules.
 

>
> Using contain on a defined type is not a syntax error.
>


Do you mean "using contain *in* a defined type is not a syntax error"?  
Maybe it's not, but the semantics of such usage will be troublesome at 
best.  But no, contain is not meant for use declaring resource instances, 
whether of defined or plugin types.  It is not useful for that purpose, 
because resources are *automatically* contained by whatever class or 
resource declares them.  The containment question arises only for classes, 
which, by design, are not automatically contained.

 

>   But you won't provide any of the parameters on the defined type when you 
> use contain.  This includes parameter like a unique name.
>
 

If (pointlessly) declaring a resource via the contain function in fact 
works at all, then that resource instance must get some default name, such 
as an empty one.  That would mean that such a contain could only be 
evaluated once, lest an attempt to declare a duplicate resource occur.


  So the semantic meaning is rather curious. It adds a tag to the define 
> type with the name of the class then adds a dependency between instances of 
> the defined type and the class.  All of the defined type instances.
>


I don't know what you're talking about.  Puppet does perform automatic 
tagging of classes and resources, including tagging each resource with the 
name of the class that declared it, and tags are passed along via 
containment, but this has nothing to do with the contain function in 
particular.

 

> That won't help you, though, for two reasons.  First, depending on the 
> version of Puppet the resources in the defined type won't get the 
> relationship.
>
> Look at the graph for your node.
>
> You should see the resources in your sub-classes 'floating' off the 
> graph.  They should have no relationship to anything else.
>


I think you're confused.  *Classes* may float off the containment graph, 
but *resources* can do so only if they are declared at top scope in the 
first place, because they are automatically contained by their declaring 
object -- node, class, or other resource -- as already discussed.

And at this point I'm stopping.


John

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

[Puppet Users] Re: 'require' option is ignored?

[jcbollinger]

On Thursday, February 15, 2018 at 8:17:20 AM UTC-6, jcbollinger wrote:

> This has been a point of confusion with the Exec resource type for the 
> whole nine-ish years that I have been involved with Puppet.  Maybe it's 
> time to actually file an issue against the docs to get it cleaned up.
>
>
And here's an issue for that: 
https://tickets.puppetlabs.com/browse/DOCUMENT-818.


John

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

[Puppet Users] Re: 'require' option is ignored?

[jcbollinger]

On Thursday, February 15, 2018 at 4:41:59 AM UTC-6, buoyant_puppy wrote:
>
> I think I got this. My main issue was the 'true' logic with an 'onlyif', 
> because that's always only going to either run (= and therefore meet the 
> requirement) or not run at all (= which also meets the requirement since 
> it's not a failure).
>
>

Yes, I think that covers it.

 

> I feel the choice of words here leaves room for confusion. Like 
> "unless"... unless succeeds? unless fails? "requires" also leaves some 
> amgiuity as well, since it considers the requirement met as long as the 
> required resource did not explicitly return a failure. So "notrun" is just 
> as good as success, which to me doesn't really intuitively match what I 
> think "require" means.
>
>

This has been a point of confusion with the Exec resource type for the 
whole nine-ish years that I have been involved with Puppet.  Maybe it's 
time to actually file an issue against the docs to get it cleaned up.

But I don't think it's an issue with the metaparameter names.  Rather, it's 
a problem with the overall characterization of an Exec resource, which is 
not well addressed by the current docs.  I most recently answered 
essentially this same question over at StackOverflow 
.
  
Here's the heart of it:

Like any other resource, Execs model target-machine state, though in their 
case, that state is local to the context of one catalog run. Often it is 
described as whether the Exec's command has been run or not, but it is 
better characterized the other way around, as whether the Exec's command *needs 
to be run* or not. If it is in the "needs to be run" state then 
successfully executing the Exec's command transitions it to the "does not 
need to be run" state.


The unless, onlyif, and creates properties of an Exec serve to determine 
the initial state of the corresponding physical (so to speak) resource. If 
none of them are provided then the physical resource is initially in the 
"needs to be run" state. If one or more of them is provided then they may 
indicate that the Exec initially is in the "does not need to be run" state. 
*And 
that's the target state*. In that case, then, the Exec is successfully 
applied without running its command.


I've given substantially the same answer before in this group, too.


John

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

[Puppet Users] Re: How manage tag (exported ressources)

[jcbollinger]

On Friday, February 9, 2018 at 4:00:48 PM UTC-6, Albert Shih wrote:
>
> Hi, 
>
> I would like to know how you or what's best practice to manage tag in 
> exported resources. 
>
> For example I have two hosts H1 and H2->100, and I want export file_line 
> from H2->100 
> to H1. 
>
> So or I use a standardized tag (like "for_${::fqdn}" whatever the kind of 
> resource) than in H1 I can very easily imported those resource. Or I need 
> share a information between those two hosts (and I don't know how to do 
> that properly when I have lot of exported resources). 
>
> What's best way ? 
>


I would start by generalizing the problem a bit.  *Why* do you want to 
export a resource from H1 to H2->100?  There are two aspects that I would 
recommend being reflected by one or more tags:

   1. File_line is a very generic resource.  It will likely be helpful, 
   therefore, to tag instances with something that narrows that type in a 
   meaningful way.  For example, if there were not already a Host resource 
   type, then you might use File_line tagged with something like "hosts_line" 
   for the same purpose.
   2. Since you specifically want one host to collect this resource, it 
   sounds like there is a question of scope that might be appropriately 
   reflected by a tag.  It is unlikely that H1's *identity* is an 
   appropriate descriptor for that scope, however.  The scope in question 
   might be a data center, a compute cluster, an application, or similar.  
   That's what should be reflected by tagging.  Or maybe you don't actually 
   need a scope narrower than your whole site after all.

This permits you to decouple H1 and H2->100 from each other, making the 
whole arrangement both clearer and more flexible.  H2->100 does not need to 
know or care which node(s), if any, are going to collect the resources it 
exports, and it doesn't need to do anything differently if that changes.  
On the H1 side, the purpose of collecting the particular resources it does 
is clearer.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/513f17a8-473c-4b4d-bf09-7b6a8cf376eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to find version of an application on nodes

[jcbollinger]

On Monday, January 29, 2018 at 4:17:56 AM UTC-6, Brandon Blackmoor wrote:
>
> I apologize if this is a stupid question, but I am still a novice at 
> Puppet. I have been asked if it is possible to use Puppet to find out if an 
> application (apparmor, specifically) is installed on our various nodes 
> (Ubuntu servers, specifically). The nodes are all running puppet agent and 
> so on. We're currently running Puppet v2016.4.0.
>
> Feel free to point me to existing documentation. I did search first, but 
> my search results either seemed irrelevant or involved way more than what I 
> am actually asking for. I'm not looking to write a new module, for example.
>
>
If you're not using PE, or if the package inventory doesn't meet your 
needs, then you always have the alternative of writing a custom fact 
. This will be 
distributed automatically to nodes, which will evaluate the fact when they 
make a catalog request, providing the result among all the other fact 
values.  These will then be recorded in PuppetDB 
, from which 
you can query the results, and the values will be available during catalog 
building as top-scope variables.

John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6b05dc18-c39a-4a09-8a80-295c7043f7a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Performance issue with puppetserver

[jcbollinger]

On Tuesday, December 12, 2017 at 11:17:20 AM UTC-6, n.be...@gaijin.ru wrote:
>
>
> We have a problem with very slow work puppetserver.
>
>
> We have ~300 nodes, master runs on a server with 24 cores and 20 GB of 
> memory.
>
> Pappet agent log:
> [...]
> Time:
> [...]
>  File: 4466.81
> Total: 4810.97
>Config retrieval: 75.19
>   Service: 8.01
> Version:
>Config: 1513029567
>Puppet: 4.4.1
>
>
Your log shows very long runtime (80+ minutes) for the Puppet *agent*.  
That's neither puppetserver nor the master.

The vast majority of the agent runtime is consumed in syncing File 
resources.  That tells me that you are syncing an enormous volume of files, 
and possibly also a great number of them.  You will find numerous previous 
discussions of such problems in this group; here are the usual 
recommendations:

   1. Prefer to reserve File resources for smallish numbers of smallish 
   files.  Config files are the sweet spot for this resource type.
   2. Prefer to package files and manage them via Package resources, as 
   opposed to recursively syncing directories full of files, or otherwise 
   syncing large numbers of related files.
   3. Avoid syncing temporary files.  If you use a File resource to manage 
   a file, then it should be one that will remain on the system, because if 
   you remove it (or modify it) then Puppet will just sync it again on the 
   next run.  This can mean leaving a file in place that otherwise you would 
   remove.
   4. If you must manage a large file via a File resource then consider 
   specifying a different `checksum` attribute for it.  The default is md5, 
   but 'md5lite' will be faster and still give an ok test for modification.  
   Or you can even go with 'mtime', which is very fast, but is susceptible to 
   both false positives and false negatives.


Your log also shows a longish runtime (75 seconds) for catalog retrieval.  
The `stat()` calls in your strace suggest that you're using the 'eyaml' 
Hiera back end, and this does add overhead.  If you're storing all your 
Hiera data in the eyaml back end, then it may add a lot of overhead.  I 
suggest using eyaml only for those data that actually need to be kept in 
confidence, and among them, only those for which the general access 
controls provided by the master's system are insufficient.  Configure the 
standard back end too, and use it for the rest of your data.  There may be 
other issues, too, such as the system load from all those File transfers, 
but I see no details that point me to specific server-side problems.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4f0e88f7-2f2a-4c86-9a22-e1e072879c95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Hiera merge issue

[jcbollinger]

On Tuesday, November 21, 2017 at 10:01:39 AM UTC-6, Constantin B wrote:
>
> Hello
>
> i run : 
>
> puppet lookup --node  --debug --explain sshkeys::users
>
>  on puppet master it return a correctly merged array
> i have group/xxx.ymal + common.yaml 
> i have set 
>
>
> lookup_options:
>   sshkeys::users: # This lookup option applies to 
> parameter 'local' of class 'users'
> merge:  # Merge the values found across 
> hierarchies, instead of getting the first one
>   strategy: deep# Do a deep merge, useful when dealing 
> with Hashes (to override single subkeys)
>   merge_hash_arrays: true
>
>
> so it works fine on master and the result is correctly merged xxx + common 
>
> when i run puppet agent -t on  node to apply the config the merge is 
> incorrect it only takes xxx.yaml 
> but ignore common.yaml 
>
>
> how this is possible ? 
>


If the catalog builder really is obtaining different values for the same 
key than puppet lookup does, with the two running on the same machine (i.e. 
the master), then the only possibilities are that the two are using 
different configurations or looking at different data.  They might well be 
using different configurations if they are running as different users, and 
they might be looking at different data if they are referring to different 
environments (*i.e.* if the catalog is being built for a node that 
self-assigns its environment).

 

> how to debug hiera from slave node ? 
>


Generally speaking, you can effectively debug data lookups only on the 
machine that is actually performing the lookups.  In a master / agent 
setup, that means the master.  You can, however, use other nodes to probe 
lookup results by adding a `Notify` resource or a `File` resource to report 
on the exact result of the lookup itself, as performed by the master during 
catalog building.  That might help you discern whether the problem is with 
the lookup itself, or whether it is with how the looked-up data are used.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/118cbe1f-398d-4d7a-8f1d-e25732dd2259%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to deal with resource conflict between modules

[jcbollinger]

On Monday, November 6, 2017 at 10:13:11 AM UTC-6, titlei...@gmail.com wrote:
>
> Hello,
>
> I'm very new to Puppet and trying to implement 2 very simple modules.  
> Both of these modules should work independent of each other, but both will 
> be run on the same host.  They both require that openssh-server be 
> installed and the sshd service is started and enabled.  I'm unable to 
> figure out how to deal with this as I keep getting a Duplicate declaration 
> for Package['openssh-server'].
>
>
> package { 'openssh-server':
> ensure => installed,
> }
> service {'sshd':
> ensure  => running,
> enable  => true,
> require => Package["openssh-server"],
> }
>
>
> What is the best way to deal with this?  Please keep in mind that I'm not 
> very proficient with Puppet, still have a lot to learn.  I read through 
> some of the documentation that discusses uniqueness for resource titles and 
> names, but I don't follow how to get around that.  Should I have a "common" 
> module of sorts where duplicate things exist?  That seems to add complexity 
> and the modules will then have a dependency on that.  I would like to avoid 
> that and have each module be self contained.
>
>

Module compatibility issues are a longtime recurring matter.  A variety of 
approaches to various aspects of the problem have been devised over the 
years.  The best and most reliable solution I have so far encountered is 
first and foremost architectural: plan and implement your modules and 
manifest set so that each resource is the responsibility of exactly one 
module.  Having done that, you can rely on the singleton character of 
Puppet classes to allow you to declare your need for a particular feature 
wherever is appropriate, without risking duplicate resource errors.

In your particular case, that would involve factoring the ssh server 
resources out into their own module, either one of your own or one of the 
many existing third-party modules for the purpose, such as ghoneycutt's 
.  Then each of the two modules 
you started with uses an include-like declaration of the appropriate 
class(es) from that module to assert its need for ssh services.  For 
ghoneycutt-ssh, that would be simply

include ::ssh

Note well that an include-like class declaration should be used, not a 
resource-like class declaration.  That also means that whatever 
customization is required must be performed via automated data binding 
.

This does tend to apply pressure toward having many fine-grained modules.  
A well-regarded way to deal with that, among other issues, is to implement 
the Roles & Profiles pattern .  
That won't reduce the number of modules, but it will provide a way to 
aggregate them into sensible logical units.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/60661acd-3d50-4c01-8af7-466e9706ca36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: get physical disk for lvm usage?

[jcbollinger]

On Wednesday, November 1, 2017 at 6:07:49 AM UTC-5, Martijn wrote:
>
> Well, if you do $disks = facts['os']['disks'] (note: facts, not facter), 
> you'll have a hash of all disks in $disks. Some of the functions in 
> puppetlabs-stdlib let you modify hashes. Take a look at delete 
>  to drop keys like 
> 'fd0' and 'sda' from the hash, then you can use the remaining hash as input 
> for the LVM module.
>
>
I have always thought that the stdlib docs are a bit colloquial and 
imprecise where they describe functions that supposedly modify an array or 
hash.  What they actually do, I think, is create a *new* array or hash 
whose contents match the original, except for the specified modifications.  
This is the same distinction as between Ruby's Array.reject! and 
Array.reject, and although it's a bit subtle, it makes a tremendous 
difference.  It therefore behooves us to be as clear as possible.


John

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

[Puppet Users] Re: Disable Puppet Agent SSL Authentication

[jcbollinger]

On Wednesday, October 25, 2017 at 8:47:40 AM UTC-5, Vishal Sarin wrote:
>
> Folks, 
>
> We manage a LAB of Windows PC where the OS crash is quite often and we 
> need to install a new certs. 
>
> So, we need to delete the certs from Server frequently.
>
> Since its in-premise LAB and so I would like disable security completely 
> and have trust on other mechanism rather than SSL. 
>
> Is this do-able in puppet/foreman?
>
>
As far as I am aware, no, it is not possible to disable SSL.  Puppet relies 
deeply on it, not only for authentication and confidentiality, but also for 
node *identity*.

You can, however, largely circumvent verification aspect of managing client 
certs.  There are several ways you could do this, among them

   - Generate and install client certs manually, keeping a record of them 
   so that you can re-install them when you re-provision the machine.  This 
   will not happen automatically (no matter how you name the machine during 
   re-provisioning) but you can do it yourself.  This way, you will not need 
   to clean certs for these machines from the server in the first place.
   - Turn on the allow_duplicate_certs 
    
   option in the master's configuration.  This will cause the server to 
   automatically replace old certs with new when a certificate-signing request 
   comes in for a name that it already has a cert for.

If you choose the second option then you will have to take care to avoid 
having multiple machines with the same certname (which is the same as the 
hostname by default).


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/38316181-210f-4be0-96ba-bf6be3eea610%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Is ensure_resource() evil?

[jcbollinger]

On Wednesday, October 18, 2017 at 6:38:51 PM UTC-5, Johan Fleury wrote:
>
> Le 17/10/2017 à 08:59, jcbollinger a écrit : 
> > Nothing has changed with `ensure_resource()`.  The problem is not its 
> > implementation details, but rather the nature of the usage modes the 
> > function is *designed* to support.  The whole idea of it is flawed.  We 
> can 
> > reprise that discussion if you like, but you already have this very 
> thread 
> > and others to which it links from which you can review some of the 
> > discussions that we have had before. 
> > 
>
> What is the problem with ensure_resource? 



So we'll have the reprise, then.

The job of ensure_resource() is to declare a resource in the event that it 
is not declared.  This is primarily meant help address of module 
compatibility concerns.  That sounds just peachy, but it presents both 
conceptual and practical problems.

On the practical side,

   - the function doesn't do quite what you would expect.  All other 
   considerations aside, you would like it to declare the specified resource 
   if otherwise it would not have been declared, but what the function 
   actually does is declare the resource if it has not been declared *yet* 
   when the function is evaluated.  Evaluation-order dependencies such as that 
   produce all kinds of trouble, and in particular,
   - if another declaration of the same resource is evaluated after the 
   ensure_resource() call, then catalog building will fail with a duplicate 
   resource declaration -- the very thing that using ensure_resource() was 
   supposed to avoid.  In practice, then, ensure_resource() is reliable 
   only if it is used consistently on a per-resource basis.  Also,
   - even if all declarations of a given resource were made via 
   ensure_resource(), if in fact there is more than one then there is 
   significant risk that the resource attributes they specify are 
   inconsistent.  This is the very thing that Puppet is designed to avoid by 
   forbidding duplicate resource declarations in the first place, and it can 
   produce the result that the target machine is silently configured 
   differently than you expect.  As an extreme case, consider conflicting  
   ensure_resource() calls for some resource -- a Package, say -- in which 
   one specifies ensure => 'present' and the other specifies ensure => 
   'absent'.  Whichever happens to be evaluated first will win, foiling the 
   intent of the other.
   - All of that is exacerbated by the fact that Puppet manifest evaluation 
   order is difficult to predict, and somewhat chaotic.  That is, small 
   manifest changes in one place can produce widespread evaluation-order 
   changes across the manifest set.  As a result, your 
ensure_resource()-dependent 
   manifest set that works today may break tomorrow when some unrelated change 
   is committed, or may not work for the new machine you're about to add that 
   has a different configuration from any previous one.
   - I am also inclined to suspect, though I have not seen or worked out 
   the details, that evaluation-order dependencies are prone to play poorly 
   with Puppet's environment caching.

On the conceptual side, the mere existence of ensure_resource() and 
ensure_resources() influences manifest writers away from best practices.  
It's like a creepy guy in a panel van rolling up next to impressionable 
young Puppeteers and offering them candy.  Or "candy".

The best solution for avoiding duplicate resource declarations is to ensure 
that every resource is the responsibility of exactly one class (though 
classes may be responsible for multiple resources).  That naturally avoids 
any possibility of duplicate declarations via classes' singleton nature, 
while nevertheless allowing the requirement for that resource, and perhaps 
related ones, to be expressed independently at multiple points in the 
manifest set, in the form of include-like class declarations.  Furthermore, 
if there are conflicting requirements for the resource then those will tend 
to come quickly to developers attention, and site data can be DRYer.  But 
doing this properly is more work than just writing resource declarations as 
ensure_resource() calls, and ensure_resource() makes the immediate pain go 
away often enough to be tempting.

Oh, and note that almost every word of that applies equally to wrapping 
ordinary resource declarations in `if !defined()` checks.  `defined()` is 
evil, too, as I have previously said on more than one occasion.


John

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

[Puppet Users] Re: I accidentally removed the puppet server

[jcbollinger]

On Monday, October 16, 2017 at 10:08:20 AM UTC-5, Lucas Z. wrote:
>
> Hello everyone,
>
> I made a mistake in my Puppet Server, I ended up installing a new puppet 
> with the command apt install puppet and apt autoremove. Now, the original 
> Puppet Server apparently disappeared from /opt/puppetlabs.
>
> If i made a new fresh install of the Puppet Server, my agents will 
> be unauthorized? Is there any simpler way to bring the puppet server back?
>
> Ubuntu version: 16.04
> Puppet Server version: 5.0
>
>

I suppose you have no backup from which to recover.  In that case, it is 
important to understand that membership and participation in your Puppet 
site hinges on recognition of a common certificate authority.  By default, 
Puppet uses its own CA and a self-signed CA certificate; such a certificate 
cannot be regenerated if it is lost.

If your CA certificate was indeed lost (or even if just the private key was 
lost), and it cannot be recovered from backup, then at best your site is 
crippled.  You will be unable to authorize any new agents.  If you also 
lost the master's certificate then you are completely toast -- there is no 
way to authorize or re-authorize a master that the existing agents will 
accept without reconfiguration.  In this case, your only viable course of 
action is to re-authorize all your agents against the new master and its 
new CA.

If, on the other hand, you still have at least the CA certificate then you 
can probably recover.  I cannot provide details, but I don't doubt that 
there are those around here who can.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/14246b64-5649-42fa-b808-8613e1284285%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Is ensure_resource() evil?

[jcbollinger]

On Monday, October 16, 2017 at 5:33:12 PM UTC-5, Ken Miller wrote:
>
> Is this really still true?  From the looks of the stdlib source of 
> ensure_resource it seems like it just parses parameters and calls 
> create_resources .
>
> Trying to understand if this is 3 year old lore or still valid in 2017.
>
>

Nothing has changed with `ensure_resource()`.  The problem is not its 
implementation details, but rather the nature of the usage modes the 
function is *designed* to support.  The whole idea of it is flawed.  We can 
reprise that discussion if you like, but you already have this very thread 
and others to which it links from which you can review some of the 
discussions that we have had before.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9ab83f5e-27d7-4a98-abcd-5b1cde8f175a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Feature Request (lookup with keys containing ".")

[jcbollinger]

On Wednesday, October 4, 2017 at 10:54:30 AM UTC-5, John Baird wrote:
>
> Problem:
>   So, currently as has been explained to me, doing a lookup with keys 
> containing "." chops the key at first "." because of scoping and namespace.
>


Well, that seems a bit of an odd characterization.  I think a better 
explanation would be that lookup() chops keys at the period character *because 
that character is not allowed in (simple) keys*.  It can be regarded as an 
operator when it appears in the key expression.  That has nothing to do 
with namespace or scope in Puppet's sense of those terms.  I realize that 
this limitation on keys is not well documented, and I sympathize with you 
about the confusion that it may have caused.  FWIW, essentially the same 
issue was previously raised against Hiera as HI-485 
.

 

>   This makes file-based lookups impossible (as far as I can tell).  I 
> would like to be able to use HTTP or other backends to serve files, which 
> by their very nature WILL contain file extensions.
>


Yes, it does make general filenames unsuitable for use as keys.  If you 
want to serve files as you describe then you'll need to perform some kind 
of translation between filenames and keys.  Do note, by the way, that in 
that case, the '.' character is not the only one you would need to be 
prepared to translate.

I don't quite follow why you want to do as you describe, but you should 
consider whether the best alternative would be to take an altogether 
different approach.  We could talk about how that might look if you fill us 
in on the bigger picture.

 

> Expectation:
>   While I understand that changing the very function of lookup to 
> accomodate this is out of scope, I would still think that providing a way 
> to tell lookup to NOT chomp or namespace the lookup would be appropriate?  
>
> Something like "lookup('/path/to/somefile.txt', scope=false)"... In this 
> manner, the user and more specifically, each lookup call can determine 
> whether or not to include the dotted key.
>
> Is this something we could push forward?  How would I go about doing that ?
>


The lookup() function already has a form that accepts an options hash.  In 
principle, that could be leveraged for what you want instead of adding a 
new argument.  If you want to pursue that then the Puppet Developers 
 group would be a 
better place to discuss it, and Puppet's issue tracker 
 would be the place to submit a formal 
feature request.  I'm inclined to doubt that such a request would be 
accepted, but I've been wrong before.


John

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

[Puppet Users] Re: parts of class being skipped :(

[jcbollinger]

It's suspicious to me that you have resources managing parts of 
/etc/zabbix/zabbix_agentd.conf, but nothing in your manifest to specify 
that they should be applied before Service['zabbix-agent'] is managed, or 
to make the service take notice if those are applied when it is already 
running.  Moreover, you have nothing to specify that that file should be 
managed *after* Package['zabbix-agent'], which I presume will provide the 
base version of that file.

Regardless of your actual problem, I would think that any way around, your 
two File_line resources both need to declare relationships with those other 
resources:

  require => Package['zabbix-agent'],
  notify  => Service['zabbix-agent']

Perhaps that will even constitute a complete solution.

As a completely separate issue, your great big case statement is confusing 
and wasteful.  The only difference between the three cases is the 
release-number component of the repository path, which you have in the form 
of a variable that you know about already.  Your manifest could be 
substantially DRYed out by replacing the whole case statement to simply 
this:

  yumrepo { 'zabbix3.4_repo':
enabled  => 1,
descr=> 'Zabbix 3.4 Repo Created by Sysad',
baseurl  => "http://repo.zabbix.com/zabbix/3.4/rhel/${ 

operatingsystemmajrelease}/\$basearch/ 
",
gpgcheck => 1,
gpgkey   => 'http://repo.zabbix.com/RPM-GPG-KEY-ZABBIX',
  }

Note use of a double-quoted string to permit the $operatingsystemmajrelease 
variable to be interpolated, and the escaping of the '$' to prevent 
"$basearch" from being interpreted as a Puppet variable reference.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5c4398f4-8137-4bfc-b6de-986ec02cfbe2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Question regarding Puppet4 class params and Hiera5

[jcbollinger]

Dear Sean,

David has already given you great answers to the questions you posed.  I 
have nothing to add to those, but I feel inclined to nitpick your question 
a bit:

On Tuesday, September 26, 2017 at 10:00:49 AM UTC-5, Sean wrote:
[...]

> The class arrays are strings of fully qualified subclass names, e.g. [ 
> 'complex::redhat::subclass1', 'complex::redhat::subclass2', ] etc. 
>
> Is there a benefit to actually using class params or declaring all 
> references to class variables directly as fully qualified in the subclasses?
>
> Here's a simplified example subclass, and yes the example is silly, if we 
> enable/disable a feature in puppet code, why not just exclude the subclass 
> altogether.  Typically, that is what happens, but I was failing to find any 
> other simplistic examples to provide.
>
> class complex::redhat::subclass1 (
>   Boolean $enable_feature1,
> ) {
>
>   if $enable_feature1 {
> notify("${::osfamily} Feature 1 is enabled")
>   } else {
> notify("${::osfamily} Feature 1 is disabled")
>   }
>
> }
>
>
>

Puppet has subclasses, whose definitions can be recognized by their use of 
the 'inherits' keyword.  What you are describing are not them.  Even *bona 
fide* Puppet subclasses behave differently than most people tend to expect 
based on the uses of the term "subclass" in object-oriented programming 
languages, but the classes you are actually describing have nothing at all 
recognizable as a superclass / subclass relationship, in any accepted sense 
of the term.  In particular, each of the classes you described defines its 
own namespace, separate from and independent of all the others'.

The thrust of some of your questions suggests uncertainty about the 
relationship between those classes, which is an excellent reason to avoid 
use of the term 'subclass' for it. Even if you understood (and when you do 
understand) the relationship, describing it via the term 'subclass' is 
prone to confuse.  In fact, one class having another's name as its 
namespace has very little practical significance, other than putting them 
in the same module.  Even that is primarily organizational, not functional. 
I suggest just calling them "classes".


John

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

[Puppet Users] Re: stdlib keys() and values()

[jcbollinger]

On Thursday, September 28, 2017 at 5:49:12 AM UTC-5, Robert wrote:
>
> Eh, sorry.
>
> So why's this with the above code:
>
> Notice: /Stage[main]/Main/Notify[sdf]/message: defined 'message' as '1'
> and keys($hash) gives 'a'
>
> Why not arrays of the keys / values? Can't understand.
>

Although it is not explicitly spelled out in the docs, it should not be 
much of a surprise that the Notify type expects its 'message' parameter 
("The message to be sent to the log") to be a string.  When you provide an 
array instead, Notify must either reject it with an error, or convert the 
array to a string by some unspecified mechanism.  In the version of Puppet 
you are running, it opts in such cases to convert the array to a string by 
choosing its first element (not necessarily recursively).  I'm uncertain 
whether this is intentional behavior or simply what happens to fall out 
from the implementation in this particular variation on providing a value 
of the wrong type.

If you want to control how the arrays you're working with are converted to 
strings, then you ought to perform the conversion explicitly 
,  
Details vary to some extent based on what Puppet version you are using (the 
link goes to the docs for Puppet 4).


John

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

[Puppet Users] Re: chocolatey.config idempotency

[jcbollinger]

On Wednesday, August 2, 2017 at 9:04:06 AM UTC-5, proman wrote:
>
> I've been busy to find out why my *chocolatey.config* file is not 
> idempotent when i run *puppet apply apply_manifest.pp( *this file include 
> the puppet code from the chocolatey.config) on a specifiek vm 
> (windows-2012r2-x64). I use to get the same output even when i run it for 5 
> times for instance(that's what idempotency is all about), but every run 
> seems differently. 
>
> I'm lost where to search for this problem. Does anyone experienced this 
> before? If yes, what was the fix? if no, any suggestions where to look at?
>


Well, how about starting by figuring out what is changing between versions 
of the config file.  You haven't given us anything to go on, but here are 
some possibilities:

   - Maybe you are writing a timestamp into the file.  Naturally, that will 
   change every time you apply the catalog, even if the *meaning* of the 
   config file is unaffected by the change.
   - Maybe you are writing the same configuration details in different 
   orders.
   - Maybe you are adding comments or blank lines.
   - Maybe you are adding duplicate entries.
   - Or maybe the semantic content of the file is actually changing -- for 
   instance, you could be flip-flopping between two variations on the file.

All of those are things I've seen or heard about in other contexts, but it 
may also be that you've discovered something new.

Once you know what's changing, you should have a better idea what to look 
for in your manifests, and where to find it.


John

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

[Puppet Users] Re: Swap not getting enabled.

[jcbollinger]

On Sunday, July 30, 2017 at 11:58:25 AM UTC-5, m ahuja wrote:
>
> I do the following command in a series of commands.
> I make swap using fallocate -l 65G & chmod 0600
> I /sbin/mkswap /mnt/../../swapXXX
> I /bin/echo -en '\n/mnt../../swapXXX swap swap auto 0 0\n' >> /etc/fstab
>


You really ought to use a Mount resource to manage the /etc/fstab entry, 
but that's surely unrelated to the problem you describe.

 

>
> I then do the following and it fails. What am I doing wrong?
>
>  exec { "attach swap file":
> command => "/sbin/swapon -af -p 1",
> require => Exec["make fstab entry"],
> unless => "/sbin/swapon -s | grep 
> /mnt/ephemeral0/cassandra/swap65G",
> } ->
>
> From log file:
>
> /Stage[main]/Ax::Cassandra::Node/Exec[attach swap file]/returns: executed 
> successfully
>


Puppet seems to disagree with you: the command *does not* fail, in the 
sense that its exit status is not different from 0.

 

>
> dmesg shows 
> "Adding 68157436k swap on /mnt/ephemeral0/../swap65G.  Priority:1 
> extents:45 across:72851452k SSFS"
>
>

And that seems to confirm that it did not fail.

 

> free -m
>  total   used   free sharedbuffers cached
> Mem:  3774   3213561  8106   1646
> -/+ buffers/cache:   1460   2314
> Swap:0  0  0
>
> No swap.
>


But that is indeed odd.

 

> But if I run the command on command line it runs fine.
> If I do a puppet apply --debug --version it works fine.
>


Did you mean "--verbose"? Anyway, it is odd if the effect on the system 
varies with the use of the --debug or --verbose option, but it is not clear 
whether those are the only things that differ between the run that has the 
result you want and the one that doesn't.

You haven't given us (or at least me) enough to work with.  I would like to 
see a complete manifest that is sufficient to demonstrate the problem, 
together with sufficient procedural instructions for how to reproduce the 
incorrect behavior.  Until I see those, my best guess is that in your 
success case you apply a different, more narrowly-scoped starting manifest, 
and there is something else being applied in the failure case that causes 
the swap file to be disabled before the end of the run.


John

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

[Puppet Users] Re: Puppet certification issue

[jcbollinger]

On Monday, July 24, 2017 at 9:26:39 AM UTC-5, nan meng wrote:
>
> 1. Version: 
>
> Puppet: 4.10.4
>
> Puppet server: 2.7.2
>
> Puppet Agent: I do not use agent to do test.
>
> OS: Ubuntu 64-desktop 16.04
>
> Openssl: 1.0.2g
>

2. There is not any none default configuration. 
>
> 3. Test command: openssl s_client -connect puppet:8140##puppet is the 
> hostname of master.
>
> 4. There is not log from puppet, that is why I capture packet.
>
> 5. Use wireshark, Menu->Analyze->Decode As, TCP,  choose SSL, the result 
> is decode as SSL.
>
>
>

As I said in response to your previous message, merely connecting to the 
Puppet server without a certificate does not in itself indicate a flaw.  I 
was perhaps not clear enough in that previous response that Puppet allows 
SSL connections without a client certificate in order to service 
certificate-signing requests, as Michael has now clarified as well.

It would constitute a bug if an untrusted client -- whether a Puppet agent 
or something else -- were able to obtain a catalog or other secure data 
from the master, but you have not demonstrated such an issue as far as I 
can determine.  Simply accepting a connection without authentication via 
client certificate does not demonstrate Puppet disclosing secure data to an 
untrusted client, nor is it an indication that a client successfully 
establishing such a connection could obtain such data.

I still see no reason to believe that the behavior you describe is flawed 
or that it requires fixing. 


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f2e82476-1a61-4fc7-896d-94b053c4091e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Creating a user without a shadow entry

[jcbollinger]

On Monday, July 24, 2017 at 4:33:09 PM UTC-5, William Korb wrote:
>
> We have a rather non-standard requirement on our Puppet-managed Linux 
> systems, and I'm trying to figure out if/how Puppet can satisfy it.
> [...]
> The solution up to now was to use the same UID as generated by WINBIND to 
> add an entry to /etc/passwd. However, we don't want the encrypted stored 
> password to exist on every server, so we instead leave out the entry for 
> /etc/shadow, and WINBIND is smart enough to authenticate the user to AD for 
> us (and at boot time, the local presence of the oracle entry in /etc/passwd 
> is sufficient to allow the oracle stack to start properly).
>
> With that in mind, is there any way to get an "oracle" entry added to 
> /etc/passwd, create HOME directory and profiles, etc. without also ending 
> up with an /etc/shadow entry?
>
>

There is, but not straight out of the box via Puppet's User resource type. 
 By default, Puppet uses the local tools on each machine for managing the 
properties associated with User resources.  On Linux hosts, that generally 
means the useradd command and its siblings, or perhaps an analogous group 
of commands, and on systems that use a shadow file (which should be all of 
them) these commands manage entries in the passwd and shadow files together.

Of course, it makes sense that Puppet doesn't serve your use case out of 
the box, because the setup you are trying to achieve is non-standard for 
the systems you are configuring.  There are several ways you could approach 
it, among them:

   1. Write a custom provider for the User resource type, and employ it to 
   manage your shadow-less user(s) via User resources.  This is probably 
   the cleanest to use, but it is unquestionably the most work to implement.
   2. Manage the oracle user via a User resource with the default provider, 
   and also ensure via a separate resource that the corresponding line is 
   removed from the shadow file when necessary.  The file_line 
    resource of 
   the puppetlabs/stdlib module can help with the latter.
   3. Manage the passwd line for the oracle user by managing the passwd 
   file directly, for instance by using a File_line instead of a User.
   
Each of those approaches has both advantages and disadvantages.  They are 
listed in descending order of complexity.

Were I to choose, and supposing that this one user is a unique special 
case, I would probably choose (2).  It is tremendously easier to do than 
(1), albeit a bit more complex than (3).  Option (2) has the advantages 
over option (3) that

   - It will remove the unwanted shadow line if it (or a conflicting one) 
   is added by other means.
   - It will notice and flag an error if you should happen to add another 
   User resource for the oracle user to your manifest set.
   - It will be very clear to whomever comes after you (maybe future you) 
   just what you're doing, and that avoiding the shadow line is intentional.


John

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

[Puppet Users] Re: Sync the calls in a puppet module

[jcbollinger]

On Wednesday, July 19, 2017 at 5:27:39 AM UTC-5, Abhishek Kane wrote:
>
> Hi puppet experts,
>
> In classA I am calling some custom type and then calling classB. classB is 
> dependent on the work that is done in custom types.
>
> But in the puppet apply command I see that classB gets called before the 
> custom type, and it fails.
>
> Is there a way to sync these calls?
>


You "call" functions.  You "declare" classes and resources.  Ultimately, 
these function calls and class and resource declarations collectively 
result in the production of a "catalog" describing the configuration 
properties that must be ensured and a set of relationships among them that 
influence the order in which those properties must be synchronized.  Puppet 
synchronizes the target machine state with the catalog in a manner and 
order it chooses, subject to the constraints of the ordering relationships 
in the catalog.

So yes, Puppet has ways to direct the relative order of application of 
classes and resources.  The Puppet language reference has a whole section 
discussing the details 
, and you 
should read it.  Be sure to select the manual version corresponding to the 
Puppet version you are using.  While you're at it, you may want to read the 
rest of the language reference, too.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/aaaebf75-65cb-4a4f-8f55-e6bff28250b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet certification issue

[jcbollinger]

On Tuesday, July 18, 2017 at 10:36:17 AM UTC-5, nan meng wrote:
>
> Hi all,
>
> I have tested puppet with version 4.1 and 2.x,  found that if an agent 
> connect master without certification, the connection still can be 
> established.
> I think it is not reasonable. Because if agent connect with an wrong 
> certification the connection will be refused.
>


Merely connecting does not necessarily imply normal or successful 
operation.  The Puppet catalog request process requires master and agent to 
authenticate to each other via cryptographic certificate.  This has been a 
Puppet foundational principle forever, or at least since before I started 
using Puppet way back at version 0.24.  If indeed you can show that a 
Puppet agent is able to obtain a catalog from a Puppet master without 
presenting a certificate that the master is willing to trust, or at least 
presenting a certificate-signing request that the master is willing to 
honor, then you have identified a serious flaw.  I'm not yet prepared to 
believe that you have done that.

 

> Does anyone know how to fix it?
>


It's not clear to me that anything is broken.

 

> the attachment is packet captured using tcpdump. It can prove what I have 
> said.
>


I'm not sure what, exactly, your capture proves.  I see a TCP connection 
being established from a client to a server running on Puppet's standard 
port, 8140, at a different IP address.  I see some binary data being 
exchanged, and then the connection being closed at both ends.  But my 
protocol analyzer does not recognize the the protocol of the conversation, 
and certainly it does not recognize it as SSL / TLS.  Who knows what the 
exchange actually means, or whether it is problematic?

If you want me to believe that you have discovered a bug -- or indeed if 
you want help with a solution or workaround -- then you'll need to present 
enough information to replicate the problem.  That includes some or all of 
the following:

   - Specific versions of agent and master
   - Operating system and version on which each is running
   - All non-default configuration properties on each side
   - A manifest set and any other needed server-side data (ideally a 
   single, trivial manifest if that is indeed sufficient)
   - The specific puppet agent command issued (which should include the 
   --debug or --test flag)
   - The corresponding console and/or log output from the agent, and maybe 
   also from the master.

All software has bugs, but I anticipate that you will find Puppet to be 
operating as intended in this particular area.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/533778aa-6516-441a-8eb6-2e4a2a6173fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: does puppet have api to run and apply catalogs

[jcbollinger]

On Monday, July 10, 2017 at 9:29:34 AM UTC-5, rahav jv wrote:
>
> Hi,
>
> I'm evaluating puppet and salt.
>
> salt has an api that helps us runs command and apply salt states (like 
> catalogs) on the endpoints.
>
> is there any such alternative in puppet, an api that can help apply a 
> catalog or a manifest on the agent via the puppet master.
>


Open source Puppet's model is strictly a pull model.  It does not do remote 
control.  If you want remote control (such as to remotely trigger a Puppet 
catalog run) then Puppet, Inc. tends to recommend MCollective, a general 
purpose, multi-node remote-control system under Puppet, Inc's control. 
 MCollective has good Puppet integration.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4c335601-469f-47ae-a060-0b21c9288ccf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Avoiding duplicate declaration in a loop?

[jcbollinger]

On Thursday, July 6, 2017 at 4:45:53 PM UTC-5, buoyant_puppy wrote:
>
> Excuse my newbieness, but I'm having a basic misunderstanding regarding 
> loops.
>
> Say I have: joesfriends = jack, sam, sally
>
> I need to add each entry into a file - one per line.
>
> $joesfriends.each | String $joesfriends| {# loop
>
>   file { "/etc/list_of_joes_friends":
>
> line => "${joesfriends}"
>
>   }
>
> }
>
>
>
> This fails on a duplicate declaration errorbut how can there not be a 
> duplicate, it's a loop? The examples in the docs avoid this particular 
> situation by using the var in the filename, but that's not usually going to 
> be an option.
>


You have it backwards.  If you're trying to declare a single resource then 
it's the (Puppet) loop that's not an option.

No resource can be declared more than once.  You can, however, declare 
*distinct* resources in various iterations of a loop -- for example, 
resources representing different parts of the same file -- or you can 
construct resource properties via an iterative process in a template or 
custom function.

It's not clear exactly what you mean to do because the File resource type 
does not have a "line" property.  If you mean to describe the complete 
contents of a single file then you are looking for a way to construct a 
value for the 'content' property of one File resource.  I'd recommend a 
template  for that 
purpose.  Puppet 4 has two flavors to choose from, ERB and EPP, either one 
of which would support building the file content by iterating over the 
elements of an array.


John

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

[Puppet Users] Re: Variable scope on sub-defined ressource type

[jcbollinger]

On Monday, June 26, 2017 at 7:57:06 AM UTC-5, Prunk Dump wrote:
>
> Hello puppet Team !
>
> I have trouble upgrading some code from puppet-3.7 to puppet-4.8.
>
> I have a class, a defined type, and a sub-defined type like this :
>
>
[...]
 
 

> So there is two "mainclass::myress" declaration. Each one have a different 
> value of $myressvar inside the ressource. And each one declare one 
> "mainclass::myress::sub" ressource. In puppet 3.7 everything works just 
> like this. And
>
> -> In the "mainclass::myress::sub" déclared by "myressv1" I can access the 
> value of the "$myressvar" variable of the "myressv1" ressource just by 
> "$myressvar". So using the "$myressvar" variable inside 
> "mainclass::myress::sub" I get the value of the parent ressource.
>
>

That's doubtful.  What you describe should not work in Puppet 3.7 at all, 
neither with nor without the future parser.  I did not even find a bug 
report that would explain why it might have seemed to work for you.  Puppet 
3.7's scoping rules are documented at 
https://docs.puppet.com/puppet/3.7/lang_scope.html.  Those docs are 
substantially unchanged for all v4 releases so far, and as a matter of 
semantic versioning, I expect them to remain substantially unchanged for 
all remaining v4 releases.

Note in particular that

   - "Code inside a class definition or defined type exists in a local 
   scope."
   - "Variables and defaults declared in a local scope are only available 
   in that scope and its children."
   - "Node scope and the local scopes created by defined resources are 
   anonymous and cannot be directly referenced."
   - Although not a direct quote, the parent scope of every defined type's 
   local scope is *node scope*, regardless of where that instance is 
   declared.

I could believe that the behavior you describe was exhibited by Puppet *2*.7, 
which had very different scoping rules for variables, but the scope change 
was one of the major differences between Puppet 2 and Puppet 3.  Not only 
should what you describe not work in Puppet 3 (or 4), there is no way at 
all in v3 or v4 of the Puppet language to access the local variables of a 
defined type instance, though I believe there is a function available from 
the stdlib module for accessing their *parameters*.

All that aside, the easiest solution is probably to give 
mainclass::myress::sub a parameter by which the wanted value from a 
mainclass::myress instance is provided to it.

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

Re: [Puppet Users] Puppet works on 41 times out of 43. Help?

[jcbollinger]

On Thursday, June 22, 2017 at 5:26:41 AM UTC-5, Robert Inder wrote:

I don't understand why the behavior you describe occurs, but I also don't 
understand why you are trying to set the owner of the link in the first 
place, especially if the directory containing it belongs to root.
 

>If I change the manifest to not specify ownership of the link, 
>  it creates a "swindon" link link owned by root.
>

So why not go with that?  The link owner is relevant only to modifying or 
removing the link itself, and since you're managing it via Puppet, I don't 
see what purpose it serves to relax the permissions for that.  The link 
owner and permissions have no relevance to *traversing* the link (see 
symlink(7)).


John

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

[Puppet Users] Re: On Windows - using a resource from a different class

[jcbollinger]

On Thursday, May 11, 2017 at 9:51:09 AM UTC-5, jcbollinger wrote:
>
> [...]  If, as in this case, you do not also place an *explicit* 
> dependency on that, then you are at risk of that dependency not being met.
>

Correction: it appears that perhaps you do place such a dependency by 
require-ing class "packages", or at least that you intend to do.  If that 
class directly or indirectly is responsible for declaring Reboot['before'] 
then I conclude that either it is not doing its job or that your problem 
falls in the resource-naming category I described second.  If it directly 
or indirectly *contains* that resource (a different consideration), then no 
direct relationship is required between that resource and any resource 
declared in class 'inventor'.  In that case, you might solve the problem by 
removing the 'require' attribute from Package['vc2015'].  This would result 
in a form close to the one I recommended, with the difference being that 
class 'packages' presumably has more responsibilities than just ensuring 
that the machine reboots.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7fcdd6a8-8e0e-4324-8591-44d2132ff233%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: On Windows - using a resource from a different class

[jcbollinger]

On Tuesday, May 9, 2017 at 7:31:30 AM UTC-5, jmp242 wrote:
>
> Not sure - maybe this is a horrible idea, but I've got a package I'm using 
> that would ideally use the same reboot resource as all my other packages, 
> but in this case is in it's own class because there are several steps that 
> are more complicated than just applying the package. On many VMs and test 
> computers, this worked, but on ~7 it fails being unable to find the 
> required resource in the other class. I'm trying to upgrade using 
> chocolatey packages our Autodesk Inventor products:
> class inventor {
>   require yum, packages
>
> So at the start I require my packages class, so the resource should be 
> defined there (called reboot'before') and seems to be on most computers.
> package { 'vc2015':
>   ensure   => absent,
>   provider => 'chocolatey',
>   require  => Reboot['before'],
> }
>
> However, on about 7 computers out of ~80, I get that it can't find the 
> reboot resource. I tried doing Packages::Reboot['before'], but that didn't 
> work either... 
>


Resources are global once declared.  If the form you present works for some 
machines but not for others, therefore, it seems logical to conclude that 
the wanted resource is not declared on the systems where it fails.

And indeed, the points out a serious flaw in your approach: if you depend 
directly on a resource declared (or expected to be declared) by a different 
class, then you implicitly depend on that class being declared.  If, as in 
this case, you do not also place an *explicit* dependency on that, then you 
are at risk of that dependency not being met.  On the other hand, if you do 
place the explicit dependency (e.g. by include-ing or require-ing the 
class) then you are probably better off expressing the ordering 
relationship in terms of the class, not the resources it declares.

I note in passing, however, that there is another, separate, potential 
problem here: the correct name for the resource type for use in a resource 
reference.  The fully-qualified name should always be used, but since there 
is no Reboot among the resource types included with core Puppet, I'm 
uncertain what the fully-qualified name would be in this case.  If it is a 
native type then its name is in the anonymous namespace.  If it is a 
defined type, then its fully-qualified name depends on how it was declared, 
but it *should* have been declared in a module, with its name assigned to 
the module's namespace.  In any event, which class declares a particular 
resource instance has nothing whatever to do with how that instance can be 
referenced.
 

>
> Is this even supposed to work? I'm using Puppet Agent 1.8.1 on the client, 
> which is Windows 7 x64 SP1. Chocolatey 10.2 for business but this seems a 
> straight puppet resource / syntax error for me.
>

It can work, but it would be better to create a class whose only job is to 
ensure that the machine is rebooted, and for every other class that 
conceives a need to reboot to (1) declare that class (using one of the 
include-like forms) and (2) establish an appropriate ordering relationship 
with the class.  It is better for classes to avoid dependencies on the 
internals of other classes; if you do it at all, you should at least avoid 
doing it across module boundaries.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/45679f16-5f42-4e09-a78c-3201c937ec41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Parameterized classes vs defined-types

[jcbollinger]

On Wednesday, May 3, 2017 at 4:35:02 PM UTC-5, Lesley Kimmel wrote:
>
> I've [somewhat] recently started developing Puppet modules for use with 
> Foreman[...]
>

I recently came across some modules on the Forge that got me considering 
> using modules with defined types exposing their functionality. I think this 
> seems to be the ultimate way to do things because it allows the same 
> flexibility as the purpose-specific module setup while essentially 
> requiring you to have another module for your application or workflow which 
> utilizes the defined types from all of your defined type augmented modules.
>


I'm not sure I entirely follow you here, but since you specifically brought 
up Foreman, you should be aware that defined types are *resource* types, 
and Foreman cannot declare Puppet resources directly (the Puppet ENC 
interface has no provision for it).  Thus, if you had in mind to set the 
parameters of instances of your defined types via Foreman then your plan is 
a non-starter.

Inasmuch as you describe creating a class that uses the defined types, I 
suspect your plan is different, but then I don't see what advantage you 
perceive in defined types.  You can just as easily create a class that 
declares other classes.  In fact, this is one of the key concepts in the Roles 
& Profiles pattern , which is aimed 
pretty squarely at the problem you describe, at least as I understand it.

You should also be aware that Puppet's best mechanism for feeding 
parameters to classes is automated data binding via Hiera.  You'll find 
lots of information on that via Google.  The main drawback from your 
perspective would probably be that you cannot manage Puppet's external data 
via Foreman, at least not as far as I am aware.


John

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

[Puppet Users] Re: removing "minimum_uid=1000" value from all my pam config files

[jcbollinger]

On Thursday, March 30, 2017 at 12:58:46 PM UTC-5, Peter K wrote:
 

> I've tried exec and sed, but I couldn't figure out the necessary escaping 
> to get the filename variable to parse (here I test with 'abc'):
> define removeMinimumUID(){
> exec { '${filename}':
>   command => "/usr/bin/sed -i \'s|abc|cab|g\' ${filename}",
>   onlyif => '/usr/bin/test -e ${filename}',
>   refresh => '/usr/bin/true',
>   provider => 'posix',
>   logoutput => on_failure,
> }
> }
>
> RemoveMinimumUID { "/mnt/NY_Interactive/dev/peter/puppet/abc.txt": }
>
> Error:
> Executing: '/usr/bin/sed -i 's|abc|cab|g' '^[[0m
> ^[[mNotice: 
> /Stage[main]/Main/Removeminimumuid[/mnt/NY_Interactive/dev/peter/puppet/abc.txt]/Exec[${filename}]/returns:
>  
> /usr/bin/sed: no input files^[[0m
>
>
This is only incidentally an escaping problem.  The main issue is that the 
defined type you present uses a variable $filename from the local scope, 
but you do not define any such variable in the local scope.  Therefore, 
when evaluated as a variable reference, $filename expands to nothing.  You 
can in fact see that in the command string that the exec reports itself to 
be using.  It looks like you meant to use $title instead, or perhaps to 
define $filename = $title.

Having fixed that, your Exec resource ought to work despite the quoting / 
escaping problem associated with its title.  For the record, however, you 
can solve that minor issue by changing the single quotes to double quotes (
"${filename}") or by omitting them altogether.  Personally, though, since 
you're not using the command itself as the title, I would provide a more 
descriptive title, something like

exec { "remove minimum UID in ${filename}":
  # ...
}


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/805a11ee-835a-4c1d-bcc3-6e174ca11caf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Clarification on mount type behaviour

[jcbollinger]

On Wednesday, March 29, 2017 at 6:36:01 AM UTC-5, apgrif...@gmail.com wrote:
>
> Hi,
>
> From my testing it seems that when managing mount resources puppet only 
> compares the manifest against fstab and not mtab. For example if I have
>
> mount { '/tmp':
>   ensure  => mounted,
>   options => 'noexec,nodev,nosuid',
> }
>
> And then do mount -o remount,exec /tmp
>
> I would expect the next puppet run to correct this, but I'm not seeing 
> this, only if I edit fstab is the resource updated. Is this expected 
> behavior?
>
>
It is the longtime behavior associated with the "parsed" provider for the 
Mount resource type (the only provider for that type included in the box).  
The documentation does not explicitly say that mtab is ignored, but if you 
read carefully then you will find that the behavior is characterized in 
some places in terms of the "filesystem table" and in at least one place 
explicitly in terms of fstab.  Look in particular at the documentation for 
Mount.ensure 
.

Overall, then, the Mount resource type primarily manages entries in fstab, 
and only secondarily manages whether the designated filesystem is mounted.  
But perhaps it doesn't have to be limited that way.  Expanding its scope to 
cover the options with which the filesystem is actually mounted seems like 
a reasonable feature request.  And if you don't want to wait, then very 
likely you can roll your own by writing and using an extension of the 
existing "parsed" provider that adds the behavior you want.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3be04523-0565-4ed8-9fe8-54e2bb8f812f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: virtual resource realizing by require?

[jcbollinger]

On Thursday, March 23, 2017 at 11:23:07 AM UTC-5, garima singh wrote:
>
> Hi,
>
> I was wondering if you could find a soultion to putting virtual resource 
> as target to require metaparameter.
>


There is no inherent problem with making a resource depend on a virtual 
resource.  It is syntactically valid, and in itself it is semantically 
valid.  The problem arises if that resource is never realized for the 
target machine, and I suppose that's the issue you want help with.

I have to ensure that some resource is run only when a particular virtual 
> resource is run and successful.
>
>
Every concrete resource in the catalog is applied to the target machine.  
If you want a given resource to not be applied under certain circumstances, 
then you must ensure that it is declared only virtually if at all.  Virtual 
resource realization does not cascade along dependencies; if you're looking 
for a way to make that happen, then you need to take a step back and 
re-think your approach.

Your best option may be to wrap [realization of] the two resources in 
question in a class or defined type, so that you can cause them to be 
realized as a pair.  You may realize the same virtual resource multiple 
times with no ill effects, but this does not achieve the result of 
realization of one resource causing realization of the other.

You might also consider restructuring your manifest set to avoid relying on 
virtual resources at all.  These days it's more conventional to rely on 
external data (i.e. Hiera) to drive decisions about which classes and 
resources to declare, and this can replace the decision of whether to 
*realize* a declared virtual resource with a decision of whether to 
*declare* an ordinary resource in the first place.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3aed0c24-9fef-46ca-8120-f7d1a787807e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Unable to copy full content of directory in multiple location.

[jcbollinger]

On Monday, March 20, 2017 at 10:09:48 AM UTC-5, Pratip Ghosh wrote:
>
> Hi,
>
> I am facing following error to copy full content of directory in multiple 
> location.
>
> Error: Failed to apply catalog: Parameter command failed on Exec[copy]: 
> Command must be a String, got value of class Array at 
> /etc/puppet/modules/wordpress/manifests/wp.pp:23
>


So what's your confusion?  This is about the clearest error message you 
could hope for.  Puppet complains that it requires the 'command' parameters 
of Exec resources to be strings, but that that parameter of the Exec 
resource entitled 'copy' is instead an array.  It even provides the line 
number in your manifest, and the parameter's assigned value indeed is an 
array:
 

> exec { 'copy':
> command => ["cp -r /tmp/wordpress/* /var/www/abc_com","cp -r 
> /tmp/wordpress/* /var/www/xyz_com"],
> require => Exec['extract'],
> path => ['/bin'],
> }
>

If you want to execute two separate `cp` commands, then you have several 
options; among the best are:

   - Split them into two Exec resources
   - Join them into a single string via a semicolon, and add provider => 
   'shell' to the Exec's parameters
   - Create a script containing the commands, ensure it present on the 
   target machine, and execute the script vie an Exec resource


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c1d0045d-0f31-4a63-995a-4f65262907f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Can a resource run more then once in a catalog?

[jcbollinger]

On Friday, March 3, 2017 at 11:30:42 AM UTC-6, Peter Kristolaitis wrote:
>
> A subscribed / notified resource will only trigger once.  Puppet's basic 
> execution model only allows each resource to run once during a catalog run, 
> and you can think of notify/subscribe as a special case of using  'require' 
> to determine execution order.
>

That's not quite right.  A resource will be *synced* at most once during 
each catalog run, and it will *also* be *refreshed* at most once.  Most 
resources that have non-trivial refresh actions do something different when 
refreshed than when synced -- for example, Service resources restart.  By 
default, however, Execs have the same sync and refresh actions: to run 
their command.  Thus, the command of an Exec can be run twice in a catalog 
run.

Fortunately for the OP, however, the effect of declaring an Exec 
"refreshonly" is effectively to change its sync action from running the 
Exec's command to a no-op.  In his specific case, therefore, his Execs' 
commands will run at most once per catalog run.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/19e7ce2f-0b19-42ae-bb90-dc5c0444a5ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Manage delivery and execution of RPMs not in YUM

[jcbollinger]

On Sunday, March 5, 2017 at 6:56:11 PM UTC-6, John Gelnaw wrote:

> I created a second "mount point" in puppet via fileserver.conf, pointing 
> to a location outside the puppet git tree, so I could use 
> "puppet:///downloads/" as a source, synchronized that directory 
> to a local directory on the workstation using "ensure => directory", 
> "recurse => true", and "purge => true", then had that resource notify an 
> exec of "yum install -y *rpm"-- because yum will automatically handle 
> dependencies, sequence, and upgrades.
>
> Then any time you drop a new rpm into the directory on the puppet server, 
> the client automatically downloads and installs and/or upgrades the 
> packages.
>
> Not the "Right Way", no, but it does work, and takes less work to add new 
> packages (my way, drop new RPM in location accessible only by puppet-- 
> yum/package way, add package to http:// accessible repo, update repo 
> metadata, and (if needed) add package to node catalog if it's a new package 
> vs. an upgraded existing package).
>


That's a viable option.  I'd say that its main advantage is avoiding any 
need to update your manifest set or Hiera data when you want to add a new 
package to the group.  Even that isn't a big win, however: in my 
environment, it's a one-liner to add a package to my big list of local 
packages to manage.  Nevertheless, it is one fewer piece to get aligned in 
the right direction, and there is some value in that.

All the costs of such an approach should be taken into account, however.  
One of the more obvious ones is that the full set of RPMs will be 
maintained locally on each client machine. This could be mitigated by 
putting the packages on a network drive, so as to avoid any downloading at 
all, but that does come with its own trade offs.

Another cost is somewhat increased security exposure. If someone can obtain 
sufficient privilege to put their own RPM into the directory containing the 
local RPM copies, then Puppet will install it along with all the others.  
That constitutes a privilege escalation attack if it takes more privilege 
to install packages than it does to drop files in the target directory.

Additionally, this approach does not afford an easy way to *remove* 
packages, though it may be that package removal is rarely needed.


John

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

Re: [Puppet Users] Re: Specifying dependency ordering inside of lambda functions

[jcbollinger]

On Tuesday, February 21, 2017 at 5:44:14 AM UTC-6, Chadwick Banning wrote:
>
> Autorequires: If Puppet is managing the user’s primary group (as provided 
>> in the gid attribute) or any group listed in the groups attribute then the 
>> user resource will autorequire that group. If Puppet is managing any role 
>> accounts corresponding to the user’s roles, the user resource will 
>> autorequire those role accounts.
>
>
>
 this.

In other words, you don't need to explicitly specify relationships between 
User and Group resources to ensure that the groups to which a given user 
belongs are managed before the user himself.  I can perhaps see an argument 
for doing so anyway in a class coded as you describe for the original, but 
it is foolish to go out of your way and complicate your manifests to 
re-express relationships that are *already there*.  It's even worse to add 
altogether irrelevant relationships in order to facilitate doing so.  I'd 
simply add a comment to the manifest to document that you're relying on the 
autorequirements.


John

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

[Puppet Users] Re: console parameter value with dollar becomes interpolation

[jcbollinger]

On Friday, February 17, 2017 at 10:40:57 AM UTC-6, João Matos wrote:
>
> Hi all
>
> we're trying to assign a value to a parameter with a dollar and that is a 
> problem.
> adding a backslash only makes the string become backslashed which is not 
> what we want. Different types of quoting did seem to work either..
> I'm sure a lot of people add this issue but i couldnt find an answer on 
> search engines or this group.
>
> Any solution or simply not allowed?
>
>
The Puppet documentation describes the format for string literals 
.  There are 
multiple ways to produce a string value that contains a '$' character, but 
we cannot easily make any specific recommendations to you because you have 
not presented the problematic Puppet code.  I'm inclined to guess that in 
your attempts to find a solution by trial & error, you made offsetting 
changes, and so missed finding a solution.

It its simplest, if you want to avoid interpolation being performed then 
using single quotes instead of double quotes to delimit your string is a 
good option:

$variable = 'I am assigned to $variable'

If that does not solve your problem then we need more information before we 
can suggest a more suitable implementation.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/59e7480f-0ff4-4cb6-a637-aacbacee93f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: ensure_resource should be the default behaviour

[jcbollinger]

On Wednesday, February 15, 2017 at 11:08:09 AM UTC-6, Poil wrote:
>
> Hi, 
>
> After some years of writing puppet modules, I think the ensure_resource 
> behaviour (from stdlib) should be the default behaviour for all resources. 
>
> This will simplify the code, and made Puppet more accessible for 
> beginners. 
>
> Ref. https://forge.puppet.com/puppetlabs/stdlib/readme#ensure_resource 
> Takes a resource type, title, and a hash of attributes that describe the 
> resource(s). 
> If the resource already exists, but does not match the specified 
> parameters, this function attempts to recreate the resource, leading to 
> a duplicate resource definition error. 
>
> So I think I'm not the first to ask for this, so why not ? 
>


You're right, you're not the first to suggest this.  You will find multiple 
discussions on this topic in the archives of this group and of the 
developers group.  The most recent one I recall was in the context of a 
discussion of changes to the syntax and semantics for resource declarations 
for (then-future) Puppet 4.  Some of the ideas from that discussion were in 
fact implemented, but not the ones around reducing the duplicate 
declaration problem.  Perhaps the existence of ensure_resource() was 
considered to adequately address that aspect already.

Of course, this is primarily a module compatibility issue, for within a 
single code base, it is entirely feasible to solve the problem via one of the 
means Puppet recommends 
.  In a 
more general context, some of the same ideas still apply -- in particular, 
it makes some sense to approach the problem by stipulating that there 
shouldn't *be* a problem: instead, there should be at most one class (and 
therefore one module) in any manifest set responsible for any given 
resource, and the only way that resource it should be managed is via that 
class.  Other modules would depend on the designated module / class instead 
of managing the resource directly.  But that solves the problem by kicking 
it up a level, making it one of module *set* design and curation.

In the end, I think the biggest problem with the suggestion of changing 
resource declaration semantics to match the semantics of ensure_resource() 
is that despite being a substantial semantic shift, it would not completely 
solve the problem.  It would handle the case of multiple *identical* 
resource declarations but not cases of multiple *compatible* declarations.  
This latter is quite a hard problem, because it is not clear *a priori* 
what makes non-identical declarations compatible.  I once had some ideas on 
this topic that I still think are pretty good, though fully implementing 
and using them would be much more disruptive at this point than when I 
first suggested them.  Nevertheless, you might find this discussion 
 
of interest.  Felix Frank later implemented some of those ideas 
.

I'm game to have this discussion again in the context of present-day Puppet 
and its ecosystem, but inasmuch as Puppet, Inc. has had multiple 
suggestions and ample opportunity to make the changes you seem to want, and 
has not made them, I think it's a lost cause.


John

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

[Puppet Users] Re: inline classes

[jcbollinger]

On Wednesday, February 15, 2017 at 2:41:29 PM UTC-6, Ligne Six wrote:
>
> Hello folks,
>
> I'm wondering if it is possible to define-declare a class. Something like 
> inlining:
>
> instead of:
>
> ```
> include hello_distro   
> 
> 
>   
>   
> 
> 
> 
> class hello_distro {   
> 
> 
>   
>  notify { "Running on distro: ${facts['os']['family']}": } 
> 
> 
>
>  } 
> ```
>
> have something like:
>
> ```
> include class hello_distro {
> ...
> } 
>
>
No, Puppet has no such feature *per se*, but I don't see what advantage you 
hope it would provide, relative to simply declaring the contents of the 
class body directly at the same point.

Moreover, if you're inclined to declare a class in the same manifest in 
which you define it -- which runs counter to the prevailing views on good 
style -- I don't see how being able to merge those into a single statement 
would provide more than the most trivial advantage.  You would save 
yourself literally *one word* of code by not repeating the class name.


John



John

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

[Puppet Users] Re: optimize my configuration

[jcbollinger]

On Monday, February 13, 2017 at 10:51:42 AM UTC-6, puppetstan wrote:
>
> thanks for your answer
>
> But with this conf, my package package-5.0.el6.noarch.rpm is automatically 
> downloaded even if my package version is 5.0. So it's my problem. I don't 
> want downloaded package package-5.0.el6.noarch.rpm if my version package is 
> 5.0...
>
> file { "/tmp/package-5.0.el6.noarch.rpm":
> #ensure => 'present',
>source => "puppet:///modules/puppet/package-5.0.el6.noarch.rpm"
>   }
>
>
> package { "package":
> ensure => '5.0',
> provider => 'rpm',
> source => "/tmp/package-5.0.el6.noarch.rpm",
> require => File["/tmp/package-5.0.el6.noarch.rpm"]
> }
>
>

I strongly recommend creating a local repository for your RPMs, and using 
yum to manage packages (under Puppet direction).  The job you propose to 
have Puppet do is among yum's core behaviors.

If you insist on doing it manually, however, then you have two main choices:

   1. Accept that Puppet will maintain copies of your RPMs on each 
   machine.  Give it a place to put them where they will be persistent (i.e. 
   some place other than /tmp) -- Puppet will not download your RPMs again if 
   they are already there.
   2. Create one or more custom facts by which to convey to Puppet whether 
   the RPM(s) of interest are already installed and at the desired version.  
   Your manifests can then declare both the File resource and the Package 
   resource conditionally, based on the value of the fact.

Option (2) seems to be what you're asking for, but it is the messiest and 
most fragile alternative of all those available to you.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/61b9cbb1-63af-4a9a-b536-5b72ab95cb33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Draft for new type and provider API

[jcbollinger]

On Tuesday, January 31, 2017 at 10:04:27 AM UTC-6, David Schmitt wrote:
>
>
> The type and provider API has been the bane of my existence since I 
> [started writing native resources](
> https://github.com/DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2
> ).
>


Honestly, I've never thought the type / provider system was too bad.  
Certainly it works pretty well for simple things.  Now, I'm more of a Dev 
who does Ops than an Op who Devs, but from my perspective, the biggest 
problem with Puppet's types & providers has always been inadequate 
documentation.  The docs in this area are a bit better now than when I 
started with Puppet around eight years ago, but they have always missed 
presenting many relevant details about how the host Puppet instance, 
resource instances, and their associated provider instances interact.  This 
new effort doesn't seem to be targeting any of that.

 

> Now, finally, we'll do something about it. I'm currently working on 
> designing a nicer API for types and providers. My primary goals are to 
> provide a smooth and simple ruby developer experience for both scripters 
> and coders. Secondary goals were to eliminate server side code, and make 
> puppet 4 data types available. Currently this is completely aspirational 
> (i.e. no real code has been written), but early private feedback was 
> encouraging.
>
>

I'm confused and dubious: how is it that the guiding goals for this effort 
are all about form rather than function?  Surely, if you intend for the 
result to serve any particular function(s) then you need to be guided at 
least in part by which functions those are.  Perhaps for you that's tied up 
in what you mean by "a type and provider API", but I am confident that some 
of the details of what that means to you differ from what it means to 
others.  You really need to be explicit with this if you want good 
feedback.  Moreover, inasmuch as you seem to imagine this API eventually 
supplanting the existing one, it may save a lot of future grief and expense 
to make sure everyone is on the same page early on.

Moreover, none of the goals given are addressed the needs of the API 
client, which is Puppet itself.  Or do you have a different concept of who 
the client is?  If so, then you and I have even more different ideas of 
what a "type and provider API" is than I had supposed.

Furthermore, as wonderful as "a smooth and simple ruby developer experience 
for both scripters and coders" sounds, I think it's utterly unrealistic.  
People who aren't good at writing native code or who just want to avoid it 
have much different wants and expectations from those who are comfortable 
with writing native code.  In fact, Puppet already *has* support for 
"scripters": this is what defined types are all about.  People who don't 
want to be writing Ruby are unlikely ever to have a smooth or simple Ruby 
developer experience.  The most likely outcome of trying to simplify any 
more than serves coders well is producing something  insufficiently 
powerful / flexible.

 

> The `Puppet::SimpleResource.implement()` call receives the `current_state 
> = get()` and `set(current_state, target_state, noop)` methods. `get` 
> returns a list of discovered resources, while `set` takes the target state 
> and enforces those goals on the subject. There is only a single (ruby) 
> object throughout an agent run, that can easily do caching and what ever 
> else is required for a good functioning of the provider. The state 
> descriptions passed around are simple lists of key/value hashes describing 
> resources. This will allow the implementation wide latitude in how to 
> organise itself for simplicity and efficiency.  
>
>

So there is no mechanism for obtaining the current state of an individual 
resource?  That seems a bit of an oversight.  There are resource types that 
cannot feasibly be fully enumerated (e.g. files), and even resource types 
that cannot be enumerated at all.

Also, though you say elsewhere that the provider's set() method receives a 
list of resources to update, that is not borne out by your example code.

 

> The `Puppet::SimpleResource.define()` call provides a data-only 
> description of the Type. This is all that is needed on the server side to 
> compile a manifest. Thanks to puppet 4 data type checking, this will 
> already be much more strict (with less effort) than possible with the 
> current APIs, while providing more automatically readable documentation 
> about the meaning of the attributes. 
>
>

I'm not at all convinced that your concept of a resource type definition 
indeed covers everything needed -- or at least wanted -- on the server 
side.  For example, I'm all for engaging the type system, but

   1. The type system does not cover all potential validation needs.  In 
   particular, it cannot perform joint validation on multiple parameters.
   2. Using the type system for any but pretty simple validity checks will 
   run 

[Puppet Users] Re: Can we install puppet agent on multiple host machine using remote machine (considering puppet master is already installed on the remote machine)?

[jcbollinger]

On Monday, January 30, 2017 at 6:40:52 AM UTC-6, Patil Jyotsna wrote:
>
> Can we install puppet agent on multiple host machine using one remote 
> machine (considering puppet master is already installed on the remote 
> machine)?
>
>
I suppose you mean to ask whether you can *use Puppet* to do that.  No, 
generally you can't.  Puppet has no magic.  The agent is its way to apply 
remotely-specified configuration to any given machine; it follows that if 
the agent is not already installed then Puppet provides no way for a remote 
master to modify the system.  And that's exactly as you should want, for 
otherwise, what would prevent a rogue actor from using Puppet to apply 
changes of their choosing?

Puppet Enterprise does have mechanisms to facilitate installation of the 
agent, and there are various technologies for remote installation available 
for various computing platforms.  And for new deployments, it is advisable 
to incorporate agent installation into the provisioning and deployment 
process.  But no, Puppet does not do remote installation -- neither of 
itself, nor of anything else.  Do not be confused by the capability of the 
agent, once installed, to perform *local* software installation as directed 
by catalogs provided to it by a remote master.


John

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

Re: [Puppet Users] Local variables lost outside of .each loop

[jcbollinger]

On Monday, January 30, 2017 at 3:34:40 PM UTC-6, Martin Alfke wrote:
>
> AFAIK all variables inside a lambda are “private”: 
> https://docs.puppet.com/puppet/latest/lang_lambdas.html#lambda-scope 
>
>
... and this makes sense, because Puppet variables do not change value once 
set.  For variables to be assigned values at all in the context of lambdas 
used with iteration functions, therefore, such assignments must create 
variables scoped to one execution of the lambda.  With that being the case, 
it is natural to make that a general property of lambdas, rather than one 
sensitive to the lambda's usage.


John

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

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

[jcbollinger]

On Friday, October 21, 2016 at 9:48:02 AM UTC-5, re-g...@wiu.edu wrote:
 

> As it seems saz-rsyslog is the best puppet module for managing rsyslog, I 
> decided to take a hint from @jcbollinger on configuration, rather than 
> replacing the module.
>
> I decided to change the values of the parent Rsyslog class parameters so 
> that they are the seen as the "default" for The Foreman (I refer to 
> "default" as eluded to in a previous reply regarding use of Hiera to change 
> these values). But I did not want to implement Hiera just for one class and 
> four parameters. So I added the following changes on all puppet master 
> servers to the production/manifests/site.pp file:
>
> File: /etc/puppet/environments/production/manifests/site.pp
> class { 'rsyslog':
> preserve_fqdn=> true,
> gnutls_package_name  => false,
> relp_package_name=> false,
> rsyslog_package_name => false
> }
>
> This changes the values of these parameters globally, which is how I had 
> it set in The Foreman any way.
> And in The Foreman, I removed all values set for the parent Rsyslog class 
> parameters, leaving them checked to use the default value. I left the 
> values set in The Foreman for Rsyslog::client subclass parameters unchanged 
> (which is necessary because these values change based on node facts). I did 
> leave the rsyslog parent class assigned to all nodes in The Foreman, though 
> the ENC output does not set any parameters for this class.
>
> This fixed the duplicate declaration issue I was experiencing.
> The reason why I believe this fixed the duplicate declaration error is 
> because I assume Puppet's intended behavior is to always declare in the 
> catalog the classes from the site.pp file before the classes from the ENC.
>
> This is obviously not ideal, but I justify this with the argument that I 
> am simply changing the "default" values of the saz-rsyslog puppet module 
> Rsyslog class - but without having to modify the module's code.
> This is a good enough work-around for me for now.
> -RG
>
>

I'm glad you have found a workaround that solves the problem for you.  I 
suspect that you are basically correct about why it works; that is, that 
Puppet evaluates the top-scope declaration of class ::rsyslog before it 
evaluates any class declarations from the ENC.

To make future trouble in this area less likely, however, I recommend that 
you adjust your mental model.  Unlike my recommended solution based on 
automated data binding, what you have done is *not* analogous to changing 
Foreman's view of the default values for the class's parameters.

   - In the first place, your class declaration in site.pp is indeed a *bona 
   fide* class declaration, applying to every node.  As long as it's there, 
   every node will get class `rsyslog`, with the parameters you've specified, 
   regardless of what you specify via The Foreman.
   - In the second place, you now will *reliably* get duplicate declaration 
   errors if you try to declare any non-default parameters for class rsyslog 
   via Foreman.  That may actually be an improvement over getting such errors 
   unpredictably, however.

Note also that your solution does not resolve the underlying problem of 
your set of declarations being sensitive to evaluation order.  Instead, it 
asserts sufficient control over the evaluation order to avoid the errors 
you experienced.  I find no documentation of the relative evaluation order 
you observe, and if it is undocumented then it is fair game for a change in 
some future version of Puppet.  (And indeed, Puppet has historically been 
pretty open to changing even documented behavior, albeit in a manner 
consistent with its commitment to semantic versioning.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/47396af8-65ff-4051-86e0-88e3a363620a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[jcbollinger]

On Wednesday, October 19, 2016 at 4:51:20 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Tuesday, October 18, 2016 at 9:49:23 AM UTC-5, jcbollinger wrote:
>>
>>
>>
>> On Monday, October 17, 2016 at 3:15:51 PM UTC-5, re-g...@wiu.edu wrote:
>>>
>>>
>>>
>>> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>>>>
>>>>
>>>>
>>>> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>>>>>
>>>>> I've worked with saz in the past and believe he would be very 
>>>>> receptive to PRs that address this issue, as well, if RG or anyone else 
>>>>> wanted to contribute them. That would be one of the better solutions to 
>>>>> the 
>>>>> problem.
>>>>>
>>>>> Rob Nelson
>>>>> rnel...@gmail.com
>>>>>
>>>>>
>>>>> I think I've given you a pretty good handle on the nature of the 
>>>>>> problem, and I'm inclined to think that a solution that addresses the 
>>>>>> problem at its root will take care of the whole suite of issues.
>>>>>>
>>>>>
>>>> Lots and lots of thanks to jcbollinger.
>>>> Here is what I have done as a result of this thread:
>>>>
>>>> Submitted an issue with saz-rsyslog:
>>>> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
>>>> catalog compilation #237
>>>> https://github.com/saz/puppet-rsyslog/issues/237
>>>>
>>>> Posted a follow-up question to a related thread on The Foreman mail 
>>>> list to determine if The Foreman also may be exhibiting a bug, or if the 
>>>> issue may be my configuration:
>>>> Duplicate declaration error.
>>>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion 
>>>>   (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>>>>
>>>> My current thought at this time is two points:
>>>> 1. saz-rsyslog is written in such a way that declaring a subclass 
>>>> before the parent class causes duplicate declaration errors - but I am 
>>>> told 
>>>> the module inheritance should be addressed, and would resolve this issue.
>>>> 2. The Foreman, under undetermined circumstances (maybe my 
>>>> misconfiguration), will randomly declare parent classes and subclass out 
>>>> of 
>>>> order - but I am told this is not an issue with puppet modules that use 
>>>> inheritance correctly - thus there might be an underlying bug with The 
>>>> Foreman because this error will not appear under modules' expected 
>>>> inheritance.
>>>>
>>>>
>>> This is what was posted on The Foreman mail list group:
>>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>>>
>>>> This is an issue with the format of the ENC YAML used between Foreman 
>>>> and Puppet, and is best fixed in the module. 
>>>> The list of classes is given as a hash/dictionary and so has no 
>>>> particular order defined - it's down to the Puppet master/server to 
>>>> iterate over it, and it probably does so in no particular order. It 
>>>> isn't under Foreman's control.
>>>
>>>
>>> I now believe this is truly the root of my problem. 
>>>
>>> The evidence is looking at the ENC output and the Puppet-generated 
>>> Catalog file on each of the master puppet servers.
>>> As you can see below, the puppet-generated catalog on the 
>>> secondary-master puppet server has put rsyslog::client before rsyslog - 
>>> this causes the failure.
>>> However, The Foreman ENC output is the same on both primary and 
>>> secondary master puppet servers.
>>>
>>>
>>
>> You have taken a step backward there.  I remind you that duplicate 
>> declaration errors occur *during catalog building*, and that catalog 
>> building fails if one occurs.  It is therefore impossible to compare a 
>> catalog from the failure case to a catalog from the success case, because 
>> no catalog is ever created in the failure case.
>>
>>
> Then I was mistaken in thinking that the node file 
> (/var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml) was the data 
> (catalog pre-data) written to a file before the catalog compilation 
> procedure.
>


But you said you were looking at the *catalog* not "catalog pre-da

[Puppet Users] Re: Warning: Unable to fetch my node definition, but the agent run will continue:

[jcbollinger]

On Monday, October 17, 2016 at 10:43:44 AM UTC-5, John Gelnaw wrote:
>
> Some things to keep in mind for successful ENC scripts...
>
> First, on the agent, run:
>
> # facter fqdn
>
> This is the node name that will be reported to the puppet master 
> (equivalent to 'hostname -f').
>


... unless a different one is specified in the agent's configuration.  If 
the machines' hostnames change over time -- for example, if they get their 
hostnames via DHCP -- then configuring invariant machine-specific node 
names might solve the problem.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/0112a3c3-09d8-40c3-bdb1-2581c4da537f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[jcbollinger]

On Monday, October 17, 2016 at 3:15:51 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>>
>>
>>
>> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>>>
>>> I've worked with saz in the past and believe he would be very receptive 
>>> to PRs that address this issue, as well, if RG or anyone else wanted to 
>>> contribute them. That would be one of the better solutions to the problem.
>>>
>>> Rob Nelson
>>> rnel...@gmail.com
>>>
>>>
>>> I think I've given you a pretty good handle on the nature of the 
>>>> problem, and I'm inclined to think that a solution that addresses the 
>>>> problem at its root will take care of the whole suite of issues.
>>>>
>>>
>> Lots and lots of thanks to jcbollinger.
>> Here is what I have done as a result of this thread:
>>
>> Submitted an issue with saz-rsyslog:
>> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
>> catalog compilation #237
>> https://github.com/saz/puppet-rsyslog/issues/237
>>
>> Posted a follow-up question to a related thread on The Foreman mail list 
>> to determine if The Foreman also may be exhibiting a bug, or if the issue 
>> may be my configuration:
>> Duplicate declaration error.
>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion   
>> (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>>
>> My current thought at this time is two points:
>> 1. saz-rsyslog is written in such a way that declaring a subclass before 
>> the parent class causes duplicate declaration errors - but I am told the 
>> module inheritance should be addressed, and would resolve this issue.
>> 2. The Foreman, under undetermined circumstances (maybe my 
>> misconfiguration), will randomly declare parent classes and subclass out of 
>> order - but I am told this is not an issue with puppet modules that use 
>> inheritance correctly - thus there might be an underlying bug with The 
>> Foreman because this error will not appear under modules' expected 
>> inheritance.
>>
>>
> This is what was posted on The Foreman mail list group:
> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>
>> This is an issue with the format of the ENC YAML used between Foreman 
>> and Puppet, and is best fixed in the module. 
>> The list of classes is given as a hash/dictionary and so has no 
>> particular order defined - it's down to the Puppet master/server to 
>> iterate over it, and it probably does so in no particular order. It 
>> isn't under Foreman's control.
>
>
> I now believe this is truly the root of my problem. 
>
> The evidence is looking at the ENC output and the Puppet-generated Catalog 
> file on each of the master puppet servers.
> As you can see below, the puppet-generated catalog on the secondary-master 
> puppet server has put rsyslog::client before rsyslog - this causes the 
> failure.
> However, The Foreman ENC output is the same on both primary and secondary 
> master puppet servers.
>
>

You have taken a step backward there.  I remind you that duplicate 
declaration errors occur *during catalog building*, and that catalog 
building fails if one occurs.  It is therefore impossible to compare a 
catalog from the failure case to a catalog from the success case, because 
no catalog is ever created in the failure case.

It is useful to confirm that Foreman's ENC produces consistent output -- if 
indeed it does.  I'm not surprised that you obtained identical ENC output 
from two different Foreman servers, but it's unclear to me whether you have 
compared the failure-case ENC output with the success-case ENC output.  I 
am inclined to guess that these do differ, because clearly *something* 
changes.

Unless 

Do check the the 'ordering' parameter in the [master] section of your 
master's puppet configuration.  If it is specified, and the specified value 
is anything other than 'manifest', then it is possible that setting its 
value to 'manifest' (the default) will help.  I emphasize, however, that 
this is a workaround for sloppy manifest code, not a bona fide solution.

You've made a lot of hay about saz-rsyslog being approved / known-good / 
high-quality, with no particular justification.  Certainly the module being 
available from the Forge should not be interpreted to support such a 
conclusion.  To be clear: having looked at the code of the module in 
question, I think it is generally of good quality.  As I have already said, 
however, and as Dominic Cleal told you over on the Foreman group, the 
fundamental

Re: [Puppet Users] Re: Puppet 4 under Ubuntu 16.04

[jcbollinger]

On Monday, October 17, 2016 at 6:14:07 AM UTC-5, Ilia Ternovich wrote:
>
> Hi,
>
> I would like to install puppet first and then manage my oracle jdk 
> installation with it. I don't need OpenJDK
>


... for anything other than Puppetserver.

As far as I know, puppetserver ought to run as well on the Oracle JRE as it 
does on OpenJDK JRE, as even if we weren't talking about *Java*, the two 
products are very closely related.  Thus, yours appears to be a packaging 
problem, not a functional problem.  I take it that Ubuntu does not allow 
you to install multiple Java packages, else you wouldn't be asking, but 
some other distros do cleanly support having multiple versions installed 
simultaneously.  Anyway, since it's a packaging problem, one approach to 
solving it would be to repackage puppetserver to change its dependencies.

But you need any of that only on the master (as far as Puppet is 
concerned), for the Puppet agent does not depend on Java.  And perhaps that 
in itself resolves the problem, for what prevents you from using OpenJDK on 
the master, and whatever Puppet-managed Java you like everywhere else?


John

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

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

[jcbollinger]

On Wednesday, October 12, 2016 at 4:15:51 PM UTC-5, re-g...@wiu.edu wrote:
 

> You were right, that catalog file 
> (server1:/var/lib/puppet/client_data/catalog/server1.mydomain.example.com.json)
>  
> was from a successful build/run. There is no new catalog file when the 
> server1 node receives the duplicate declaration error.
>
> I did some further testing, and I hope I made a little progress on 
> narrowing down the issue - perhaps this adds a clue:
>
> Summary:
>  1. Both rsyslog and rsyslog::client are assigned to the node server1 via 
> a class group in The Foreman
>  2. When I remove the rsyslog::client assignment, the server1 node can 
> perform a successful puppet update, without a duplicate declaration error
>


That confirms what I have been saying all along.  Class rsyslog::client is 
a subclass of rsyslog (which is not true of most of the other rsyslog::* 
classes).  If you declare that class at all, with or without parameters, 
then you must not declare any parameters for class rsyslog.  If you want 
non-default parameters for class rsyslog then it must get them via 
automated data binding.

Technically, in fact, the module violates the DSL specifications 
 
by having rsyslog::client inherit from a parameterized class at all.  In 
practice, that combination normally works as desired, provided that any 
parameterized direct declaration of the base class is evaluated before all 
declarations of the subclass.  Evaluation-order dependencies such as this 
can be very difficult to deal with, and should be avoided at all costs.  
This is the primary reason why the resource-like class declaration syntax, 
as it was designed and implemented, was a bad idea from the very beginning.

 

>  3. Then I added rsyslog::client assignment back into the group, I 
> received the duplicate declaration error
>  4. Then, one parameter at a time, I configured The Foreman to use the 
> "default value" (checked the "use default" box) of each configured 
> parameter for the node server1, when this fact matches: fqdn=
> server1.mydomain.example.com
>  5. When all parameters are set to be "default value" for this node, even 
> though the class is still assigned to the node via The Foreman, and even 
> though the parameters are still set to a value for other nodes via The 
> Foreman, the puppet update runs successfully without a duplicate 
> declaration error on node server1
>


I suspect that if you look at the output of Foreman's ENC then you will 
find that the declaration of class rsyslog::client is different in the case 
where all parameters are set to take "default value" than when any 
parameter is assigned an explicit value.  Although I have not probed this 
before, it would be logical for Puppet to evaluate the ENC-derived 
declarations in this order:

   1. global variable assignments
   2. class declarations with explicit parameters (which are in a different 
   section of the ENC output from ...)
   3. class declarations without explicit parameters

If indeed Puppet does this, then that accounts for the behavior you 
describe by ensuring that class rsyslog is evaluated before rsyslog::client 
when no parameter values are specified for the latter.  (I re-emphasize 
that this makes a difference only because the module does not conform to 
the DSL specifications.) It seems that when both classes have parameter 
values assigned to them via The Foreman, then rsyslog::client is evaluated 
first, yielding the error; I have speculations about why that may be, but 
no solid information.

 

>  6. After this, my going back and setting just one parameter in the 
> rsyslog::client class for this node causes the duplicate declaration error
>
>

Yes, that's consistent with everything else you said.

 

> Details:
>
> In The Foreman, I have a Puppet Class config group that I assign to the 
> group of hosts in this remote location. I assign this same config group for 
> every node in the network, even ones in the local network and other remote 
> networks that do not experience duplicate class errors. Let me call this 
> group DefG1.
>
> The DefG1 config group has my default puppet module classes defined in it, 
> including the Rsyslog puppet module class.
> However, I am including a subclass rsyslog::client in addition to the main 
> class rsyslog in this group DefG1. Because I need to configure the rsyslog 
> client parameters for every node, namely the remote syslog server host.
> Now, this is not an issue with other puppet modules to include sub modules 
> (for example I also use both foreman-puppet and foreman-puppet::config 
> together without issue).
>


Again, the saz-rsyslog module has flaws that make its use susceptible to 
the kind of error you are experiencing.  The problem is not inherent in 
direct use, with or without parameters, of multiple classes from the same 
module, nor does it reflect a bug in Puppet or The Foreman.  One 

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

[jcbollinger]

On Tuesday, October 11, 2016 at 3:54:25 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Monday, October 10, 2016 at 9:07:35 AM UTC-5, jcbollinger wrote:
>>
>>
>>
>> On Friday, October 7, 2016 at 10:39:58 AM UTC-5, re-g...@wiu.edu wrote:
>>>
>>> Well... The node I have been testing the duplicate declaration on uses a 
>>> puppet secondary-master server, as it is on a remote network segment. It 
>>> does not connect directly to the puppet primary-master in which The Forman 
>>> is running on.
>>>
>>> So I did some work to get this particular "server1" node to use the 
>>> puppet primary-master that The Foreman is running on. When I run a puppet 
>>> update, it completes without error. When I switch back to the puppet 
>>> secondary-master, I get the duplicate class error.
>>>
>>> They are both running puppet 3.8.7-1 on CentOS 6.
>>> The YAML produced by both is exactly 100% the same. So I can assume the 
>>> YAML structure is not the issue.
>>>
>>> Would this suggest that the puppet secondary-master server is the issue, 
>>> or the client connecting to it is perhaps not always getting what it wants 
>>> from the slave?
>>> Remember that the puppet updates will complete correctly for many hours, 
>>> then magically change to this error. And vice-versa, be in error for many 
>>> hours, and then magically change to completing correctly. Also that 
>>> sometime changing configuration in The Forman can trigger the Error to 
>>> occur AND other times trigger to Error to stop occurring.
>>> Also note, I only have this problem with the saz-rsyslog module - NEVER 
>>> with any other puppet module.
>>> When I remove the saz-rsyslog module, all issues disappear.
>>>
>>
>>
>> I am not prepared to believe that identical implementations of Puppet's 
>> catalog builder running on substantially identical platforms with identical 
>> inputs behave differently.  Since you do see variations in behavior, 
>> therefore, I conclude that those differences can be attributed to 
>> differences in implementation, platform, or (most likely) inputs.
>>
>>  
>>
>>>
>>> I have made sure the puppet modules are 100% in sync between primary and 
>>> secondary master server.
>>> And I have restarted the puppet processes on the secondary-master 
>>> server, but the error will continue on the nodes.
>>>
>>>
>>
>> Those are good steps.  To really troubleshoot this thoroughly, however, I 
>> think you'll need to be systematic: capture the ENC output for each catalog 
>> request for a given node (or for all nodes), with timestamps and associated 
>> success / failure of catalog compilation.  Compare the ENC output for 
>> successful catalog builds with that for failed builds and look for 
>> systematics.
>>
>> Either at the same time or separately, you should look into whether 
>> Puppet's environment cache has an impact here.  Some of the behaviors you 
>> describe make me rather suspicious of this.  Supposing that you are using 
>> directory environments, you should experiment both with disabling caching 
>> altogether (set the environment_timeout configuration option to 0 (its 
>> default)) and with caching indefinitely (set environment_timeout to 
>> "unlimited").  Note that Puppet recommends against using any other setting 
>> for that option.  You could also try turning on the ignorecache option at 
>> the master.
>>
>>
>> John
>>
>>
> So I ran a `puppet agent -t` on one of the problem nodes against the 
> primary master puppet server (which was successful), and then afterwards 
> the secondary master puppet server (which produces the duplicate 
> declaration error for Class[Rsyslog]).
>
> The size of both catalog files are exactly the same (I am referring to 
> this file: 
> /var/lib/puppet/client_data/catalog/server1.mydomain.example.com.json ).
> The only difference inside the file is the order of items in the json 
> arrays.
>
>

A duplicate declaration error is a parse (i.e. catalog building) error.  If 
the master encounters one then it does not emit a catalog -- or if it did, 
it could not be one based on the failed catalog-building attempt.  I'm not 
sure what you're looking at, but it does not have the significance you are 
attributing to it.

 

> So the only difference I can see between the two puppet servers is the 
> order of the overall elements in the catalogs' json hashes and arrays.
> Could this be a cause of the duplicate declaration e

[Puppet Users] Re: Declare ressources from another stage

[jcbollinger]

On Thursday, October 6, 2016 at 9:03:26 AM UTC-5, Prunk Dump wrote:
>
>
> Can you help me on a more simpler and concrete example ?  
>
> 1) My apt::client class have a defined type :
>
>

Your apt::client class does not *have* such a defined type.  Even if the 
type's definition appears lexically within the class's (which it ought not 
to do), that does not imply any meaningful ownership or scope.

 

> define apt::client::source
>
> that allow to add sources to /etc/apt/sources.list.d. As an "apt-get 
> update" is needed after adding sources, all the resources defined in my 
> apt::client::source type :
> => require Class['apt::client::audit'] (that check if there are not 
> pending install)
> => notify Class['apt::client::update'] (that run apt-get update)
> There as no more dependencies. And the two class (  apt::client::audit and 
> apt::client::update ) are contained in the apt::client class.
>
> 2) Now I want to build a "wine" class that install wine from "backports".
>
> => the wine class require that apt is ready to install packages so 
> naturally wine class need to be run after the apt::client class.
>
> => But wine also need that the backports sources are added to 
> sources.list. So in the the wine::install class manifest I declare a 
> apt::client::source(...backports sources...) that is required by the 
> Package['wine'] resource.
>
> 3) Finally I got a dependency cycle :
>
> apt::client::update => wine::install  (because apt need to be ready)
> wine::install => apt::client::source(...backports sources...)  (because 
> the resource is declared inside the wine class and required by 
> Package['wine'])
> apt::client::source(...backports sources...) => apt::client::update (as 
> the source need to be added before apt-get update)
>
> You can say to me that I can create a specific 
> apt::client::backports_source class and include it instead of declaring it. 
> But I have many other modules that need many other specific sources.
>
> You can say that I can put the apt::client::source(...backports 
> sources...) in the apt module. But I don't want that this sources be added 
> on node that don't have wine.
>
> I there a way to achieve what I want with puppet ? Maybe with class 
> parameters ?
>

 
The cycle you describe occurs because your relationships are too 
coarse-grained.  It's not *all* of class wine::install that must be applied 
after apt::client::update, nor all of it that must be applied before 
apt::client::update.  You have one part that must be applied after, one 
part that must be applied before, and maybe a part that can be applied 
either before or after.  To resolve that situation you need to split the 
class into at least two classes, and apply the relationships with each one 
that are appropriate for it.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/59a532fb-bb93-478b-9a7a-b84b6bdf7648%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[jcbollinger]

On Friday, October 7, 2016 at 10:39:58 AM UTC-5, re-g...@wiu.edu wrote:
>
> Well... The node I have been testing the duplicate declaration on uses a 
> puppet secondary-master server, as it is on a remote network segment. It 
> does not connect directly to the puppet primary-master in which The Forman 
> is running on.
>
> So I did some work to get this particular "server1" node to use the puppet 
> primary-master that The Foreman is running on. When I run a puppet update, 
> it completes without error. When I switch back to the puppet 
> secondary-master, I get the duplicate class error.
>
> They are both running puppet 3.8.7-1 on CentOS 6.
> The YAML produced by both is exactly 100% the same. So I can assume the 
> YAML structure is not the issue.
>
> Would this suggest that the puppet secondary-master server is the issue, 
> or the client connecting to it is perhaps not always getting what it wants 
> from the slave?
> Remember that the puppet updates will complete correctly for many hours, 
> then magically change to this error. And vice-versa, be in error for many 
> hours, and then magically change to completing correctly. Also that 
> sometime changing configuration in The Forman can trigger the Error to 
> occur AND other times trigger to Error to stop occurring.
> Also note, I only have this problem with the saz-rsyslog module - NEVER 
> with any other puppet module.
> When I remove the saz-rsyslog module, all issues disappear.
>


I am not prepared to believe that identical implementations of Puppet's 
catalog builder running on substantially identical platforms with identical 
inputs behave differently.  Since you do see variations in behavior, 
therefore, I conclude that those differences can be attributed to 
differences in implementation, platform, or (most likely) inputs.

 

>
> I have made sure the puppet modules are 100% in sync between primary and 
> secondary master server.
> And I have restarted the puppet processes on the secondary-master server, 
> but the error will continue on the nodes.
>
>

Those are good steps.  To really troubleshoot this thoroughly, however, I 
think you'll need to be systematic: capture the ENC output for each catalog 
request for a given node (or for all nodes), with timestamps and associated 
success / failure of catalog compilation.  Compare the ENC output for 
successful catalog builds with that for failed builds and look for 
systematics.

Either at the same time or separately, you should look into whether 
Puppet's environment cache has an impact here.  Some of the behaviors you 
describe make me rather suspicious of this.  Supposing that you are using 
directory environments, you should experiment both with disabling caching 
altogether (set the environment_timeout configuration option to 0 (its 
default)) and with caching indefinitely (set environment_timeout to 
"unlimited").  Note that Puppet recommends against using any other setting 
for that option.  You could also try turning on the ignorecache option at 
the master.


John

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

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

[jcbollinger]

On Thursday, October 6, 2016 at 9:04:14 AM UTC-5, re-g...@wiu.edu wrote:
>
>  
>
I understand the duplicate declaration issue - I have been reading about it 
> for months trying to figure out this issue that keeps popping up. I am 
> trying to figure out how it is possible I am getting a duplicate class 
> declaration on a widely-used and approved module I have no control over 
> (that no one else has reported any similar issue as mine), when using the 
> forman to simply provide the values of parameters.
>
>

I don't know how widely-tested that module is, but it absolutely does 
exhibit what I would consider to be some violations of best practices.  As 
a result, it is more susceptible than most to duplicate declaration 
issues.  Nevertheless, it appears that simple uses of that module (e.g., of 
its classes, only ::rsyslog is declared directly) and all uses relying 
exclusively on automated data binding for parameter values should be ok.

 

> Maybe The Foreman is the cause of the ::rsyslog class to be declared more 
> than once? Might you suggest this possibility?
>


I *did* suggest that possibility, inasmuch as I suggested that it might be 
emitting the ENC analog of resource-like class declarations for it.  That 
in itself would not be enough to produce the problem, but it is a likely 
contributor.  I don't see any reason to think that it would emit multiple 
declarations itself, but it does not need to do, because there are several 
other classes in the module that explicitly or implicitly declare class 
::rsyslog.  If any of those is also declared then there is a potential 
conflict.

 

> But then I think, how would it? And why do I have this issue for hours on 
> a server, and then at some magic moment the issue just disappears? Why with 
> two of my servers sitting 1 IP away from each other, one will have this 
> issue, and the other will not?
>


I cannot answer that in any detail, but obviously something differs over 
time and / or between servers.  There is an enormous variety of 
possibilities, both inside Puppet and / or The Foreman and outside.

 

> I consider that The Foreman is causing the problem, but then I should have 
> the error on all hosts at the same time.
>


I am by no means certain that the problem is directly related to The 
Foreman, and in no way am I suggesting that The Foreman is misbehaving.  I 
am, however, suggesting that in some cases The Foreman's ENC output is 
interacting poorly with the module.  That it is possible for that to be the 
case is a consequence of details of the module implementation.

 

> The only different in the YAML between hosts is the IP addresses... every 
> other puppet module parameter value is exactly the same.
>
>

That The Foreman is emitting a class declaration with parameters at all is 
very likely a contributing factor to the problem.  Note, however, that it 
may not be just the parameter values that make a difference.  It surely 
also matters which other classes are declared, and the *order* of the class 
declarations could also have an impact.  Again, however, I see no reason to 
attribute any of this to a flaw in The Foreman.

 

> The Foreman has parameterized class support. It allows us to manage the 
> values of the puppet module parameters.
>


Yes, and when you use that support, and it works exactly as intended, you 
open yourself up to duplicate class declaration issues.  Whether any such 
issues will actually manifest depends on many factors.

 

> Old Screen Shots with explaination
>
> http://projects.theforeman.org/projects/foreman/wiki/Parameterized_class_support
>
> When using the foreman, I am not writing any files, or declaring any 
> classes. Instead, I manage the values of the puppet module parameters in 
> the The Foreman WebUI, which is simply logic like 'if this host fact meets 
> this criteria, then this puppet module parameter is set to this value'.
>


Even supposing that everything works exactly as designed, you don't need to 
write any of your own classes to end up with duplicate declaration issues.  
You do need to feed class parameters to Puppet in some way (any way) other 
than automated data binding, and you need additional declarations of the 
same classes, whether implicit or explicit, in other classes you declare.  
You certainly have the former, and the module you're using provides easy 
opportunities for the latter.


John

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

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

[jcbollinger]

On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu wrote:
>
> I installed the puppet module saz-rsyslog from puppet forge.
> I use The Foreman to configure nodes. The Foreman is used by puppet via 
> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>
> Since the saz-rsyslog module install, I have been receiving the following 
> error off and on (not consistently) across many nodes on a puppet update 
> (i.e. puppet agent -t):
>
> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
> on node "
>
>

It seems highly unlikely that merely installing the module on the master 
would cause any catalog compilations to fail, and certainly the error 
message indicates that there are some declarations of its classes in play.  
It is not the mere presence of the module, but rather the declarations of 
one or more classes in it that is causing you trouble.

 

>
> My nodes are CentOS 5,6,7; and any various number of the nodes may 
> experience this issue, but not all of them at the same time.
>
> One day I will see dozens of server with this error, and other nodes not 
> having this issue. This may go on for days if I do not touch The Foreman.
> I'll make some changes to host configuration for puppet module class 
> parameters in The Foreman - never the saz-rsyslog module though..
> After the changes, half or more of the servers having issue (not all) will 
> magically have no problems.
> However, more nodes that did not have issues before, will now experience 
> this issue.
>
> Also, this change of events is not directly related to The Foreman host 
> configuration changes.
> I can simply perform a puppet module upgrade to a unrelated module (e.g. 
> mine-yumconfig). After upgrading the unrelated module, again many nodes 
> with this issue will now have it resolved, and different ones not 
> experiencing the issue before will now begin experiencing it.
>
>
> The only clue I have is from this posting: 
> http://grokbase.com/t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
> "... If you do not see the error on every run then it is modulated by 
> something that varies between runs. That could be almost anything: 
> manifests, data, results of function calls, node facts, or ENC output. ..."
>
>
> Can anyone help me understand this issue, or help me get it resolved 
> permanently?
>
> When I search for answers, all I see are "You have written a duplicate 
> class in your module."
>


Any such claim is at best misleading.  The problem is not that you or 
anyone has written a duplicate class, it's that the class in question has 
been *declared* more than once, and at least one of those declarations uses 
the resource-like style.  In considering that, you should be aware that:

   - a declaration in resource-like style can include one emitted by your 
   ENC (part of Foreman) if it uses the form that specifies class parameters 
   explicitly, and
   - when one class inherits from another, any declaration of the derived 
   class comprises an implicit declaration of its base class.  Furthermore,
   - when class inheritance is involved, the docs 
    
   specify that any parameters of the base class must either take their 
   default values or have their values supplied by automatic external data 
   lookup.  In practice, that's too weak -- a separate resource-like 
   declaration of the base class can cause trouble even if it specifies no 
   parameter values.
   
I talked up class inheritance because I've examined the manifests of the 
latest version of the module, and there are indeed a few cases of class 
inheritance that could be feeding your problem.  There are also cases of 
ordinary declaration of class ::rsyslog by other classes in that module.  
The bottom line is that you need to follow the advice from the docs with 
respect to class ::rsyslog by avoiding declaring it via the resource-like 
style, including preventing your ENC from doing so.  Any non-default 
parameters must be provided via automated data binding.  I'm afraid I'm not 
knowledgeable enough about The Foreman to tell you how to handle that end, 
however.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a9d669b0-b043-4ec3-91b6-4667d08b9c1b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Declare ressources from another stage

[jcbollinger]

On Tuesday, October 4, 2016 at 6:55:36 AM UTC-5, Prunk Dump wrote:
>
> Hello puppet users !
>
> My problem is simple. I use the following classes in three different 
> stages (setup/main/runtime) :
>
> class { 'apt::client':
>   stage => 'setup',
> }
> ...
> ...
> class { 'hostpkg': }
> ...
> ...
> class { 'extrapkg':
>   stage => 'runtime',
> }
>
> The idea is that the "apt::client" class configure the Debian apt tools. 
> Next the "hostpkg" class install and configure the important packages (ex: 
> those needed to allow the connexion of users). And finally the "extrapkg" 
> class install the secondary packages (internet browser etc ...). But 
> sometimes the "hostpkg" or "extrapkg" packages need some extra apt sources, 
> some apt-pinning or the multiarch. So I created three resources/class :
>
>

Do take care to distinguish between operational relationships and 
management relationships.  Puppet class and resource ordering is about 
satisfying *management* relationships -- that is, situations where Puppet 
can manage resource B only after first ensuring that resource A is in its 
intended target state.  Avoid declaring unnecessary relationships, for 
there is no upside at all to having such relationships, and it incurs added 
risk of problems, such dependency cycles.  In particular, just because 
package B uses or interacts with package A does not necessarily imply that 
A must be managed before B, or vise versa.

Especially take care with run stages, for they are nothing more than a 
convenient mechanism to apply relationships to many pairs of classes at 
once.  Almost inevitably they apply a lot of unneeded relationships, but 
they may nevertheless be the best tool for a select few jobs.  Indeed, the 
Puppet docs 

 
say this:

[...] *stages should only be used with the simplest of classes,* and only 
> when absolutely necessary. Mass dependencies like package repositories are 
> effectively the only valid use case.
>

I'm inclined to suppose that there may be other valid use cases at certain 
sites, and I don't think the docs are saying that stages are always the 
best solution for ensuring that package repositories are managed before all 
packages, but do take the docs' remark in the spirit in which I think it 
was intended: run stages are the wrong tool for almost every job.

In your particular case, it may be that class apt::client is indeed one of 
those rare classes that make sense in a non-default stage, but class 
extrapkg seems very unlikely to be such a class.  In the unlikely event 
that you need any puppet-application-ordering relationships between 
resources declared in class extrapkg and (other) classes and resources in 
stage main, I see no barrier to declaring those relationships explicitly.  
Relying on doing so instead of needlessly placing class extrapkg in a 
separate stage may solve some of your problems.

 

> define apt::client::pinning( $package = $title, $pin, $priority, $ensure = 
> present)
> define apt::client::source( $sourcename = $title, $type = 'deb', $uri, 
> $distribution = $apt::client::distribution, $components, $ensure = present)
> class apt::client::multiarch
>
> There three resources are contained in the "apt::client" class as they 
> must be run before "apt-get update" (near "apt::client::end").
>


What resources?  I see (definitions of) two resource *types* and one 
class.  Class apt::client may declare instances of the two types; those 
*instances* are then contained by the class.  It might also declare and 
even also contain (in the relationship sense) class apt::client::multiarch, 
but the declaring and containing are separate considerations.  *Under no 
circumstances*, however, should the *definitions* of these types and this 
class be lexically contained within the definition of class apt::client.  
Each definition should appear in its own file.

 

> The problem come when a package in "extrapkg" need for example the 
> multiarch :
>
> -> From the "extrapkg" class I include the "apt::client::multiarch" class 
> to get the multiarch activated
>


Ok.

 

> -> As the "extrapkg" class is in the "runtime" stage, the 
> "apt::client::multiarch" is contained in the stage
>


Only if class extrapkg contains (relationship sense) class 
apt::client::multiarch, unless I've missed a change somewhere.  Indeed, 
lack of the behavior you describe was once cited as a bug, and that bug 
report was rejected.

If you do this ...

# This should be ok:
include "apt::client::multiarch"

... then you do not automatically put that class in the same run stage as 
the class declaring it.  If, on the other hand, you ...

# Don't do this with a class that may also be
# declared by other classes in different run stages:
contain "apt::client::multiarch"

... then you indeed do create a risk of dependency cycles such as you 
describe next.  The run stages docs warn about this 

Re: [Puppet Users] duplicate resource with inherit and puppet apply

[jcbollinger]

On Friday, September 30, 2016 at 2:03:06 PM UTC-5, Toni Schmidbauer wrote:
>
> Henrik Lindberg  writes: 
>
> > On 28/09/16 14:30, Toni Schmidbauer wrote: 
> > I tried this on latest puppet: 
> > 
> > === test.pp 
> > class test::subclass {} 
> > class test inherits test::subclass { 
> >   notify { 'hello?': } 
> > } 
> > include test 
>
> did some more tests with puppet 4.7. so the above works but if i move 
> tests::subclass into a separate file (subclass.pp) in the manifests 
> folder puppet apply fails with duplicate resource. 
>
> my source code layout: 
>
> ├── manifests 
> │   ├── init.pp 
> │   └── subclass.pp 
> └── tests 
> └── init.pp 
>
> manifests/init.pp: 
>
> ## code 
> class test inherits test::subclass { 
>   notify { 'hello world': } 
> } 
>
> include test 
> # end code 
>
> manifests/subclass.pp: 
>
> ## code 
> class test::subclass {} 
> # end code 
>
> tests/init.pp: 
>
> ## code 
> include test 
> # end code 
>
> i run the code with the following command 
>
> puppet apply --modulepath=/vagrant/modules manifests/init.pp 
>
> if i use 
>
> puppet apply --modulepath=/vagrant/modules tests/init.pp 
>^ 
>|- HEADS UP 
>
> puppet apply works. 
>
>

The behavior you describe seems buggy to me, but your manifests are also 
unusual.  Specifically, it is strange for test/manifests/init.pp to contain 
a top-scope declaration.  It is especially strange for that declaration to 
be "include test" because this is the very same file that would be 
evaluated, if needed, as a result of evaluating that declaration.

I suppose the reason for that is to make the manifest usable both directly 
with 'puppet apply' and as an ordinary module manifest, and I think that 
*should* work.  Nevertheless, it looks to me like an awkward mix of Puppet 
module and site manifests, and even if it worked, I would not recommend 
structuring your manifests like that.  I observe that your workaround 
involves partially splitting the site manifest part from the module 
manifest part, but personally, I'd go farther and take the site manifest 
part completely out of the module.

As I said, however, I think it should work, and even if there were a reason 
for it not to work, the error message that is emitted is bizarre for the 
code presented.  I think that's probably indicative that the code is doing 
something unexpected by its authors.  I encourage you to file a ticket for 
buggy behavior here, but if you do so, do not neglect to mention the 
diagnostic because at the very least, there are grounds here for an RFE 
around improving the diagnostic.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fec40211-95a6-4e3f-94ae-e7ea37069bdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: mount point directory permissions

[jcbollinger]

On Friday, March 21, 2014 at 11:41:25 AM UTC-5, Paolo wrote:
>
> Hi 
>
> I have the following problem: in a certain module I need to set 
> permissions on a directory after the mount was executed. If I do the 
> following 
>
> file { '/app_dir':
>   ensure  => 'directory' 
>   owner   => 'app_user' 
>   group   => 'app_group' 
>   mode   => '2775'
> } mount { '/app_dir': 
>   ensure => mounted,
>   atboot => true, 
>   device => /dev/mapper/lv_app, 
>   fstype => ext3, 
>   options => 'defaults', 
>   dump => '1', 
>   pass => '2',
>   require => File['/app_dir'],
> }
>
> This would require 2 rounds of puppet: round 1 to setup directory, mount 
> the filesystem and round 2 to fix permissions set to root:root,0755 by the 
> mount command... 
>
> In looking for a solution I found the following link: 
> https://projects.puppetlabs.com/issues/4815 
> 
>  
> that asks for the option to add permission settings to mount resource. The 
> request was rejected and in the comments 
>  Eric Sorenson writes that it would be trivial to accomplish with a 
> defined type, but without going into details... :-( Can any one give me 
> some details on how to do it with a defined type? 
>
>

Eric does give details.  In a followup comment, he refers to this example 
,
 
which apparently relies on the puppetlabs/mount_providers 
 Forge module.  Except 
the example seems to miss the point: as far as I can tell, it does nothing 
to address setting permissions of either the mount point directory or of 
the root of the filesystem mounted on it.  It furthermore relies on the 
defined() function, which I cannot endorse under any circumstances.  I 
think you need to regard his comment as a non sequitur.

We have discussed the matter here before, and I don't think the request is 
trivial at all.  In fact, there is no general solution with acceptable 
characteristics.

To see that, you need to recognize that Puppet is expected to manage the 
state of the system on an ongoing basis, not merely to set it up in a 
one-time provisioning sense.  Consider, then, what happens if there is 
already a filesystem mounted on the mount point. Puppet cannot even check, 
much less change, the properties of the mount point directory without first 
unmounting the filesystem from it, and unless the filesystem is to be 
ensured unmounted, it is simply unacceptable for Puppet to unmount the 
filesystem to manage the underlying mount point.

Another way to look at it is that the mount point directory and the mounted 
filesystem root do not have distinct identities.  That's more or less a 
design feature of a UNIX-style single-root filesystem.  You can tell which 
one the shared identity refers to at any given time, but you cannot 
reference them independently.

That does not necessarily mean that you cannot persuade Puppet to do what 
you want, but you should at least consider whether this should be a job for 
pre-Puppet provisioning.  If you insist on doing it with Puppet, then the 
details of what you want factor in to how you would implement it.  In 
general, however, the shared identity problem means that you cannot manage 
both mount point and mounted root via File resources.  Unless you want to 
write a custom resource type, that leaves you with using an Exec for one or 
the other to (maybe) accomplish everything in one catalog run.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/da68330b-0d15-4c58-99b8-79d6e4f67f0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: notify resource different between 3 and 4?

[jcbollinger]

On Monday, September 19, 2016 at 10:03:14 AM UTC-5, R.I. Pienaar wrote:
>
>
>
> On 19 Sep 2016, at 15:31, jcbollinger <john.bo...@stjude.org > 
> wrote:
> I see a difference between 3.8 and 4.6 with respect to the result of 
> interpolating an array into a string.  In Puppet 3 (and earlier) you get a 
> concatenation of the stringifications of all the elements, whereas in 
> Puppet 4, you get a more formatted representation.  I would have expected 
> such a change to be applied during a major version update -- so between 3.x 
> and 4.0 -- but a quick browse of the release notes does not appear to 
> mention it.
>
> This is not a puppet behaviour change. Newer Ruby does nicer looking to_s 
> on arrays that's why
>
>

I'm prepared to believe that there's no Puppet code change, which would 
explain why it's not documented in any release notes, but there's certainly 
an observable behavior difference between the two example runs.  If that is 
not to be accounted a Puppet behavior change then I suppose it must also be 
observable with (only) Puppet 3.8 running on different Ruby versions.  
That's a nice gotcha if you happen to rely on interpolating arrays (not 
that I would recommend doing so in any case).

On the other hand, I observe that the current (4.6) Puppet docs document 
the array interpolation format 
<https://docs.puppet.com/puppet/4.6/reference/lang_data_string.html#conversion-of-interpolated-values>,
 
independent of underlying Ruby.  That may now be a distinction without much 
practical difference, but it's the right thing to do: details of the 
infrastructure -- and especially changes to them -- ought not to leak out 
into Puppet's user-facing behavior.  This sort of thing will become more 
important as Puppet continues its movement away from Ruby as the main 
implementation language.

In any case, inasmuch as the OP was asking about behavioral differences, it 
is highly relevant that the one observable difference of any significance 
arises not because of a difference in the version of Puppet, but because of 
a difference in the version of the Ruby underneath.


John

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

[Puppet Users] Re: notify resource different between 3 and 4?

[jcbollinger]

On Friday, September 16, 2016 at 12:11:26 PM UTC-5, Christopher Wood wrote:
>
> While trying to figure out the reduce function with notice/notify I 
> happened across this thing. It looks like an unquoted array in the notify 
> resource's message only appears as its first array item. Not sure if it's a 
> bug. 
>
> I couldn't find any documentation to say if this was intended and I 
> couldn't really tell what the type was doing with the self.should bit. I am 
> not actually a programmer. 
>
> $ cat /tmp/xx.pp 
> $array = ["one", "two", "three"] 
>
> notify { 'notify one': 
>   message => "${array}", 
> } 
>
> notify { 'notify two': 
>   message => $array, 
> } 
>
> With puppet 3 I see this: 
>
> $ puppet --version 
> 3.8.7 
> $ puppet apply /tmp/xx.pp 
> Fact file /etc/facter/facts.d/monit_fail_count was parsed but returned an 
> empty data set 
> Fact file /etc/facter/facts.d/monit_fail_count was parsed but returned an 
> empty data set 
> Notice: Compiled catalog for mail82c40.carrierzone.com in environment 
> production in 0.03 seconds 
> Notice: one 
> Notice: /Stage[main]/Main/Notify[notify two]/message: defined 'message' as 
> 'one' 
> Notice: onetwothree 
> Notice: /Stage[main]/Main/Notify[notify one]/message: defined 'message' as 
> 'onetwothree' 
> Notice: Finished catalog run in 0.05 seconds 
>
> With puppet 4 I see this: 
>
> $ puppet --version 
> 4.6.2 
> $ puppet apply /tmp/xx.pp 
> Notice: Compiled catalog for cwl.hostopia.com in environment production 
> in 0.09 seconds 
> Notice: [one, two, three] 
> Notice: /Stage[main]/Main/Notify[notify one]/message: defined 'message' as 
> '[one, two, three]' 
> Notice: one 
> Notice: /Stage[main]/Main/Notify[notify two]/message: defined 'message' as 
> 'one' 
> Notice: Applied catalog in 0.11 seconds 
>


I see a difference between 3.8 and 4.6 with respect to the result of 
interpolating an array into a string.  In Puppet 3 (and earlier) you get a 
concatenation of the stringifications of all the elements, whereas in 
Puppet 4, you get a more formatted representation.  I would have expected 
such a change to be applied during a major version update -- so between 3.x 
and 4.0 -- but a quick browse of the release notes does not appear to 
mention it.

You called out the unquoted array being bound to the 'message' parameter of 
the second Notify, but that seems to have exactly the same behavior in the 
two Puppet outputs you present.  In both cases, the message is taken as the 
first element of the array.  As R.I. observed, you should not bind an array 
to a parameter that expects a string.  Given that you did so, I think 
Puppet handled the situation in a reasonable way.  I'm uncertain whether 
that behavior is documented.


John

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

Re: [Puppet Users] HOWTO ERB Template generate an array of files

[jcbollinger]

On Sunday, September 18, 2016 at 3:42:36 AM UTC-5, Warron French wrote:
>
> Hi, thanks Peter.
>
> I am writing this module to write it based on the design I have had 
> because... being a little lazy I guess you might say/think.  I know that I 
> could do a link, but I believe for something like this an actual file might 
> be required, because if the main file is deleted, then the banner is lost 
> entirely because the links will be broken.
>
>
>
As Peter said, If you have people randomly deleting system files then you 
have a bigger problem.  Furthermore, making three regular files in that 
case is only a partial mitigation of such a risk, because losing any one of 
the files still impacts consumers of that file.

But the main point I wanted to raise here is that this is one of the things 
Puppet is *for*.  Whether you use regular files or symlinks, if one or more 
of them is deleted or modified then you can expect Puppet to restore it on 
the next catalog run.  Moreover, if you have reporting enabled then the 
update will be reported to you.  This may or may not be sufficient for your 
purposes.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/98a119b6-067c-4fe6-a513-a5b83704f772%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: yumrepo difference in behaviour between CentOS 6 and 7

[jcbollinger]

On Monday, September 12, 2016 at 10:48:15 AM UTC-5, Jonathan Gazeley wrote:
>
> Hi folks, 
>
> I'm working on a manifest that manages the stock yum.repos.d definitions 
> from CentOS and can override some settings. This is tested and working 
> on CentOS 7 but produces different behaviour on CentOS 6. 
>
>
This looks like PUP-2782 .


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d201eac0-4acd-42fe-b043-5646acdb3de2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: simple node classification and custom facts

[jcbollinger]

On Tuesday, September 6, 2016 at 6:03:33 AM UTC-5, Berkeley wrote:
>
> I'm doing a refactor of my puppet code with the profiles+roles design 
> pattern.  I'm encountering what should be a simple problem, but I'm having 
> trouble finding an answer.
>
> With roles/profiles, you instantiate classes using 'include' and fetch the 
> parameter values from hiera.
>


That's not a given.  I think choice of data binding approach is largely 
perpendicular to use of roles & profiles.

 

>  Then, for each node, you specify one role, which in turn includes all the 
> relevant classes.  Right now I have a hiera hierarchy that references the 
> node's OS, environment and host name.  However, I also want to provide 
> different data based on the role of a node.  For example, a webserver and 
> an email server might run postfix; the webserver uses it to email the admin 
> when something goes wrong, but the email server uses it for much more. 
>  However, I still don't want to instantiate the parameters of the postfix 
> class explicitly from any role or profile to avoid resource conflicts.
>


This is fine if the requirement of every class that wants Postfix is simply 
that Postfix must be installed.  But suppose two profiles want conflicting 
Postfix configurations -- then you *want* Puppet to notice the conflict.  
Puppet class / resource conflicts are not a misfeature simply to be avoided 
or worked around at any cost; they are an intentional feature serving to 
help ensure internal consistency of your configurations.  The biggest 
problem with them is that they can cast too broad a net.

 

>  So, I would like to write hiera data that applies to a particular role 
> (or even a particular profile), like in the following hierarchy below, but 
> I have no idea how to do this:
>
> :hierarchy:
> - "fqdn/%{clientcert}"
> - "env/%{environment}"
> - "roles/%{role}"
> - "os/%{osfamily}
> - common
>
>
>

And what prevents you from doing exactly that?  $role does not need to be a 
fact for that to work -- it can be an ordinary top-scope variable or a 
node-scope variable, too.  And there are other alternatives 
, too.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/45c65764-abbb-4d99-b088-12d24d6954ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: puppetserver unable to start after yum update

[jcbollinger]

On Tuesday, September 6, 2016 at 12:22:03 PM UTC-5, Matthaus Litteken wrote:
>
> [...] In answer to your second question, rpmnew files are for when a 
> configuration file has been changed by the user and a package update 
> changes it. Because yum/rpm can't safely replace the configuration file, it 
> drops an rpmnew version of the file with a diff of the updated config file 
> from the package. This allows the user to manually merge in any needed 
> changes (in this case the needed change is the change to the 
> BOOTSTRAP_CONFIG setting).
>
>
It's at best misleading to describe .rpmnew files as containing a diff.  An 
x.rpmnew file is the version of x that RPM would have installed if x had no 
local modifications.  If you don't need to preserve the local modifications 
then you can replace x with x.rpmnew.  Otherwise, you can *make your own 
diff* between the two to judge how to merge the changes.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8c9d7ace-dceb-4fc1-bdb7-4955543dfc0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Noop metaparameter in class not working as expected

[jcbollinger]

On Monday, August 22, 2016 at 9:08:20 AM UTC-5, Julio Guevara wrote:
>
> Last time I bump this email :/
> Anyone has any idea?
>
>
The docs 

 
specify that:

In addition to class-specific parameters, you can also specify a value for 
> any metaparameter 
> .
>  
> In such cases, every resource contained in the class will also have that 
> metaparameter:
>

noop is a metaparameter; in fact, it is the example used in the section of 
the docs I quoted.  Your expectation is therefore correct, and Puppet's 
behavior is buggy in this regard.  I'm uncertain whether this is a 
manifestation of PUP-3630 , 
or whether it is a different issue.  You could consider asking about that 
over on puppet-developers, or in PUP-3630's comment thread.  If it is a new 
issue, then I'm sure Puppet would appreciate a bug report.


John

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

[Puppet Users] Re: Puppet Without Agent

[jcbollinger]

On Monday, August 15, 2016 at 8:41:04 AM UTC-5, guilherme...@netbr.com.br 
wrote:
>
> Hi guys,
>
> I wonder if I can use the Puppet without agent. I only need the Puppet 
> connect on some servers through SSH and run some command lines.
>
> Do you know if Puppet do this?
>
>
Puppet will not connect to another machine on your behalf or run commands 
on remote machines.

Puppet *can* be run without using the agent, however.  Puppet must be 
installed on the machine to be managed, and the needed manifests and data 
must be accessible on that machine.  You can then use 'puppet apply' to 
build and apply a catalog locally, using a manifest you designate as the 
starting manifest.  This does require somehow distributing the needed 
manifests and data; source-control systems and network filesystems are some 
of the popular means for handling that end.


John

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

Re: [Puppet Users] variable scoping and erb templates

[jcbollinger]

On Tuesday, August 16, 2016 at 7:06:28 AM UTC-5, Matt Zagrabelny wrote:
>
> Hi Lowe, 
>
> On Tue, Aug 16, 2016 at 1:31 AM, Lowe Schmidt  > wrote: 
> > What version of Puppet are you running? 
>
> Debian Jessie: 
>
> 3.7.2-4 
>
>

That looks like bug PUP-1220 
.  Note that although the 
ticket is marked as being fixed in Puppet 3.5, commentary on the ticket and 
details of the associated commit make me think that the fix only applies 
when you use the future parser.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4ca213ba-6572-473a-9624-0fc9d47942b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to refer to exported resource parameters in a template

[jcbollinger]

On Monday, August 8, 2016 at 3:55:38 PM UTC-5, Matthew Pounsett wrote:
>
>
> I'm using puppet 4.4.1.  I have a case where I need the IP addresses of 
> all the servers that fit a certain set of criteria to appear in a YAML list 
> in a config file on a particular host.
>
> It seems like the first step would be to create an exported resource with 
> the required data in it, but I haven't yet found a way to refer to those 
> data from inside a template (or from inside a module in order to populate a 
> variable I can use in a template).
>

You've already received a response in that general direction, but I want to 
observe that the underlying idea is unnatural for Puppet.  Yes, exported 
resources are a good fit to the task, but resources are not well suited to 
be vehicles for communication and data storage within the master.  Rather, 
their role and purpose is to encapsulate details of machine state in a 
manner that can be applied to the (a) target machine.

Thus, if you use exported resources for your purpose, the natural approach 
is for the various machines to export resources that serve their purpose by 
being *applied* to the target machine.  Since you want all of them to 
contribute to a single list in a single file, you're looking for a resource 
type that represents a piece of a file.  No such resource type is included 
in the Puppet core, but this is the bread & butter of the widely-used Concat 
module .


  It seems like this would be a common pattern, but the closest examples 
> I've been able to find are for realizing the exported resource to create a 
> file or other resource on a system, rather than incorporate some of the 
> exported resource's data in other resources.
>


Yes, because applying resources to a node is the natural and intended usage 
of resources.  The trick is to choose the right resources for the job.

 

>
> How do people normally go about doing something like this?  Are there some 
> examples I've just failed to find?
>
>  

Some people do hack together means to do the job more or less as you 
initially envisioned, but don't confuse mechanism with result.  I would not 
be surprised if you had seen examples of exactly what I describe, without 
recognizing that they, or something like them, would serve your purpose 
perfectly well.


John

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

Re: [Puppet Users] Re: puppet lvm module

[jcbollinger]

On Monday, August 8, 2016 at 6:35:42 PM UTC-5, Alex Samad wrote:
>
> Hi 
>
> Sorry new to puppet, not sure which mechinism your talking about. 
>


My point was not about the details of implementing custom types, it was 
simply that all native types -- both custom and Puppet-provided -- share a 
single, anonymous namespace.

  

> [...] what do i look up in the documents to learn more about this ? 
>
>
Depending on what parts you're interested in, you would probably want to 
start with either

   - the custom type documentation 
   , or
   - the plugins in modules documentation 
   .


John

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

[Puppet Users] Re: puppet lvm module

[jcbollinger]

On Monday, August 8, 2016 at 2:38:35 AM UTC-5, Alex Samad wrote:
>
> So it seems like i can access it as just filesystem 
>
> Why is that, i presume it comes from the puppet/lvm module ???
>

Custom types are implemented via the same mechanisms that the types 
included in the base package are implemented, and that mechanism has always 
provided a single, flat namespace for all types.  There are technical 
challenges to changing the current implementation in that regard, though 
I'm sure those could be overcome if there were sufficient motivation.  In 
any case, all types implemented as native types belong to the top scope, 
whether they are included in the base Puppet distribution or not.  You'll 
see this with other modules, too, such as the stdlib's file_line.


John

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

[Puppet Users] Re: Puppet not copying file from source

[jcbollinger]

On Sunday, July 31, 2016 at 12:22:19 PM UTC-5, calebl...@gmail.com wrote:
>
> I have an issue where it seems like puppet just skips some files entirely. 
> It copies one but not another. Code is identical. Path is 100% correct. The 
> same file works in an identical script(rtcp_iv1_0) but not the one I'm 
> currently working on. Has anyone seen this before?
>
> file { '/opt/apps/bin/backup_rtcp.sh':
> ensure => present,
> owner  => 'root',
> group  => 'support',
> mode   => '0755',
> source => 'puppet:///modules/rtcp_iv2_0/opt/apps/bin/backup_rtcp.sh';
> }
>
>
It looks like you really want ensure => 'file'.  Your current ensure => 
'present' will do what you seem to want under many circumstances, but there 
are plausible circumstances in which it will succeed silently without 
putting the system in the state you seem to want.  For example, Puppet 
manages content only of regular files, so if the target file initially 
exists but is a symlink, then the resource will succeed without changing 
anything.  However, I suspect that's not what you're seeing.

If the agent successfully retrieves a catalog from the master and 
successfully applies it, with no errors, and if afterward there is no file 
/opt/apps/bin/backup_rtcp.sh on the target machine, then by far the most 
likely explanation is that the catalog does not contain the resource whose 
declaration you present.  If you turn on debug logging at the agent then 
you can determine from the agent's output exactly which resources are 
present in the catalog, whether they need to be synced or not.  I can't 
explain why the resource is not in the catalog, if that is in fact the 
case; you have not presented any context, so there are too many 
possibilities.


John

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

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

[jcbollinger]

On Wednesday, July 20, 2016 at 4:42:59 AM UTC-5, Tobias Koeck wrote:
>
> Hi
>
> that worked. Thanks.
>
> So if I want to force the user to set the variables in Hiera I have to use 
> the hiera( .. ) function?
>
>
That's an odd way to put it, but if I understand you correctly then yes.  
In other words, if you want the variables to receive their values 
specifically from Hiera and not from anywhere else, then you should make 
them ordinary class variables, not parameters, and use the hiera() function 
to initialize them.  That seems pretty natural to me.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5ace2a09-dd11-4c3f-a255-28f43751a4ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Dependacies with Custom Types

[jcbollinger]

On Wednesday, July 13, 2016 at 12:52:58 AM UTC-5, Josh Cooper wrote:
[A clear and detailed explanation...]

That was great, Josh.  Are the same instructions available somewhere among 
Puppet's online docs and tutorials?  If not, they should be.

John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/774fe4a8-0aa4-4227-958a-b97e5e3afe75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Working with hiera and debugging

[jcbollinger]

On Saturday, July 2, 2016 at 1:21:03 AM UTC-5, Alex Samad wrote:
>
> Incase somebody googles to here
>
>
> i found this
>
> puppet apply --certname= -e  "notice(hiera('classes'))" --noop 
> --verbose
>
> This shows me what the puppet master is giving as classes for a specific 
> node based on certname.
>


Clarification: (1) if run on the master, that command gives (2) the value 
that the master sees for Hiera key "classes" for the designated node, (3) 
as computed without benefit of that node's facts.  That key is commonly 
used to designated names of classes to be applied, but (4) that's a 
convention, not a rule, and (5) either way, there may be other classes 
applied, too.

 

> also 
>
> hiera  -d   classes   ::osfamily=RedHat environment=production   
> ::trusted.certname=
>
>
> on the puppet master to give you info from hiera .. helpful
>


Indeed it does, and indeed it is.  Note that when Hiera is run from the 
command line like that, it uses only the fact values you specify on the 
command line, as shown.  Which fact values are significant depends on your 
hierarchy configuration and data.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/663a9cc9-320b-43f0-9513-f52ce806728d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Nodes getting catalog with incorrect resource.

[jcbollinger]

On Monday, July 4, 2016 at 4:20:12 PM UTC-5, Gino Lisignoli wrote:
>
> NRPE Module: https://github.com/example42/puppet-nrpe
>
> If you have a look at the params.pp file, lines 67-74 you will see a block 
> of code that sets the value of a variable depending on the operating system 
> version. In my environment my operating system is ubuntu, and I would 
> expect the value of the $package variable to end up as: nagios-nrpe-server. 
> But what's happening is the $package variable ends up as 'nrpe' which 
> doesn't exist.
>
> The NRPE Module doesn't do anything with exported resources
>
> Anyway, running that code locally works fine. From a puppet master I get 
> the problem described. Which is very strange. I also tried disabling our 
> puppetdb server but still had the same problem.
>
> So yesterday I managed to resolve the problem, the resolution is to 
> disable puppet environment cache. 
>
> I know the situation to make the problem happen (turn environment caching 
> on), but I don't know why it is happening. When the environment cache is 
> turned on I can clear the the cache using the puppet admin api, and then 
> for one puppet run it will work fine, but (I'm assuming) after it is cached 
> it is getting confused with other nodes generating/using the same cache but 
> with different facts.
>
>

This problem has the hallmarks of a top-scope resource declaration -- i.e. 
one outside any class, node block, or defined type.  These are allowed, and 
they are sometimes reasonable in a site manifest, but they should never 
appear in manifests that are not guaranteed always to be evaluated, such as 
those in modules.  The problem is that top-scope declarations anywhere in 
the manifest set apply in principle to all nodes, so if they appear in 
manifests that Puppet evaluates only conditionally, such as via the module 
autoloader, then the catalog builder gets an inconsistent view of the 
global declarations.

The usual symptom of inappropriate top-level declaration is that resources 
seem to leak from some catalogs to others.  It is also possible for 
resource parameters to leak under certain circumstances.  The fact that 
clearing the cache resolves the problem temporarily is a strong indication 
that your problem lies in this area.

If you do have a problem with top-level declarations, then it is probably 
in one of your own modules, not in the Example42 module.  Probably it's in 
a module that uses the example42 module, but it could be one that uses it 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4fca4db5-e217-4f3e-950e-fa17a4de3f34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: how to chmod files within directory . . . .

[jcbollinger]

On Monday, July 4, 2016 at 4:07:25 PM UTC-5, Chris Tomlin wrote:
>
> . . . . . with one type of permissions and within that same directory, 
> chmod subdirectories with different permissions.
>
> I've tried to do this with find -type exec {} but it doesn't seem to work. 
>  And I'm new to puppet so if you could show some code, i'd appreciate it.
>
>

Perhaps you could be a little more specific about what you want to do, 
especially if you want code.  Until then, here are some guidelines:

   - Do not manage the same physical resource via multiple Puppet 
   resources.  In particular, make sure there are no files that are managed 
   via both a File and an Exec.
   - Puppet knows that on Unix systems, directories modes need execute bits 
   to accompany read bits; it handles this for you to simplify recursive 
   directory management.
   - File resources in general, and recursive ones in particular, work best 
   for relatively small total numbers of files not-huge files. 
   - Except with respect to (sub)directory execute permissions, if you want 
   to manage different files to have different permissions (/ ownership / 
   security context) then you need to use separate File resources or an 
   altogether different resource type.
   - If you have a large or complex set of related files to manage, and 
   especially if none of them are expected to change frequently, then don't 
   overlook the possibility of packaging them up and managing them together 
   via a Package resource.

John

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

Re: [Puppet Users] Re: Question about custom exported resource

[jcbollinger]

On Wednesday, June 29, 2016 at 8:57:51 AM UTC-5, Bret Wortman wrote:
>
> I like that, John. Titles are guaranteed to be unique or the catalog won't 
> compile, right? This is absolutely supposed to be a one-and-only-one kind 
> of thing, so using title makes much more sense.
>


Yes, all resource titles used in a single catalog-building run must be 
unique for their types(*) with respect to that catalog-building run -- 
those of ordinary resources, those of virtual resources (even if not 
realized), those of exported resources declared (even if not collected), 
and those of other nodes' exported resources that are collected into the 
catalog.  A parallel uniqueness requirement applies to resource names, 
which are not always the same as their resources' titles.  A duplicate 
resource (type, title) or (type, name) will cause catalog compilation to 
fail.  If you want to be certain, however, then by all means write a test 
for that case.

(*) Except for the Exec resource type.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/abff9c5e-27c9-4f32-8bb2-6135046cdb17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Question about custom exported resource

[jcbollinger]

On Tuesday, June 28, 2016 at 9:56:52 AM UTC-5, Bret Wortman wrote:
>
> Here's what I'm trying to do, and I know there's a better way most likely 
> involving exported resources, but I haven't done much with them before. 
>
> I've got two types of nodes deploying custom software which Puppet is 
> setting up for us. Slave nodes have a config file which gets deployed via 
> template, and which needs to know the master node's fqdn. There is one 
> master, and it varies by subnet. Any given subnet will only have one.
>
> Right now, I'm defining the master in a .yaml file in our Hiera hierarchy 
> so that each system on a subnet knows about the master. The twist is that 
> the decision to deploy master or slave code is made through a custom fact 
> which knows about the roles a particular system is supposted to have and 
> installs the requisite software. So if no one tells me they're deploying a 
> new subnet, all the slaves get deployed without a master and puppet has to 
> play catch-up until I get it defined in hiera, and nothing works in the 
> meantime.
>
> Is the correct approach to have the config defined as an exported resource 
> from the master, and have it get collected and realized on the slaves?
>


Exported resources were the first thing I thought of as I read the 
description of your requirements.

 

> Something like this:
>
> master.pp:
>
> @@masternode { $fqdn:
> # $subnet is a custom fact
> subnet => $subnet,
> }
>
> masternode.pp:
>
> define masternode (Integer $subnet) {
> file  { '/path/to/config':
> content => template('module/config.erb')
> mode => '755',
>}
> }
>
> slave.pp:
>
> Masternode<| subnet = $subnet |>
>
> Does that look right, or am I completely off the rails?
>
>

That looks reasonable, +/- a couple of minor syntax errors.

If the only physical resource you anticipate a Masternode managing is a 
single File, however, then I would consider exporting the file directly, 
making use of the ability to have a title different from the file's path:

Mater node:

@@file { "master-config-$subnet":
  path=> '/path/to/config',
  content => template('module/config.erb'),
  user=> 'root',
  group   => 'root',
  mode=> '755',
}


Slave node:

File<| title == "master-config-$subnet" |>


Note, too, that if slave nodes on the same subnet need to be configured 
with information about each other, or if the master needs information about 
the slaves, then exported resources may again serve you.  A good trick in 
cases like those is to manually apply tags to your exported resources to 
distinguish those in one group (subnet) from those in another, and then to 
use that to filter resources when you collect them.  I could have done that 
with the above File example, too, but for collecting a single resource with 
(or that can have) a known title, I prefer to filter by title.


John

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

Re: [Puppet Users] Re: external node classifier my setup

[jcbollinger]

On Monday, June 27, 2016 at 6:42:58 PM UTC-5, Alex Samad wrote:
>
> On 27 June 2016 at 23:33, jcbollinger <john.bo...@stjude.org > 
> wrote: 
> > 
> > Alex, 
> > 
> > I will be brief(ish) this time, since wordiness seems not to be working. 
> > I've been around Puppet for a fairly long time, and I think I know what 
> I'm 
> > talking about, but by all means do evaluate my claims for yourself. 
>
> I have come to the list to get the input from people like yourself 
> with experience. I am in the learning stage. So I am taking in stuff. 
> and maybe asking silly questions. 
>
> But what I like to hear is why, not just being told what to do. 
>
> I have heard environments is not the way to go, but not why what is 
> the down side.  I have also heard from other people who use it a lot 
> that they use a lot of environments. 
>
>

We have given you several reasons why.  Examples include,

   - "[for your purposes] environments do not provide a benefit 
   commensurate with the extra complication and work they involve."
   - "Environments is a very big hammer for whats basically a tiny nail 
   you're describing."
   - "Puppet environments are highly appropriate for change management in 
   your Puppet infrastructure itself [, but ...] There is no good reason for 
   coupling that with change management for your product / service pipeline."
   - "The reason there is no direct relationship between ['operating 
   environments' and 'puppet environments'] is because a node that is in the 
   operational status of production [for example] can switch between the 
   [Puppet] production environment and any other environment of your puppet 
   code without affecting its operational status."
   - "This data is better separated via hiera."

We have also talked a bit about the uses to which environments are better 
suited; for the most part, using them for the purposes you propose 
interferes with using them (later) for those more apt purposes.

I'm sorry if these seem to be higher-level claims than you would like to 
hear, but I'm uncertain how to answer in any deeper detail.

 

> I've have decided to give it a go under 2 envornments and try and map 
> my machines in some other grouping under production.  I presume I can 
> always go back. 
>


As I said from the beginning, your machines themselves do not (or should 
not) care to which Puppet environment they are assigned if you are 
performing those assignments centrally.  So yes, you can go back and forth 
among different approaches on the master's side.

 

> > their overall configurations are not identical.  If indeed no machine in 
> any 
> > of your groups is distinguishable from any other in the same group 
> except by 
> > its network identifiers (hostname / IP / MAC) then Puppet environments 
> are 
> > even less appropriate for you than I thought.  In that case, the key 
> thing 
> > you should do is define one class per group, and have your ENC assign 
> the 
> > appropriate one of those classes to each machine. 
>
> Q) why classes - i thought the way to go was roles / profiles. 
>
>

Roles and profiles are implemented via classes.  What you seemed to have 
said suggested that even roles and profiles was more complex than you 
really needed.  Nevertheless, the one class per machine group maps directly 
to one role per group, and can be implemented that way.  There is no 
essential inconsistency here.  Your subsequent comments make me think that 
your real requirements are at least a bit more complex, as indeed I had 
initially supposed when I first suggested roles and profiles.


So I have 1 environment production 
> I have my prod server in the prod grouping ??? 
> I have my standard profile MY Winbind. its linked to a specific version. 
>


We already covered this.  The conventional ways to approach problems of 
that sort are via hiera or via your ENC.  There are many ways to implement 
the details.
 

>
> How do I now test a new version.  I presume in my "MY WInbind" class I 
> need some statements to say if in prod then this version if in test 
> this version. Is this the way to do it ? 
>


Supposing that the classes you are applying to your nodes are built to 
accommodate it (mainly that they rely on external data), you do it by 
binding different data to some nodes than you do to others.  Again, details 
vary.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/531d464d-8edd-45f5-ab43-0e7818f2b1b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: external node classifier my setup

[jcbollinger]

Alex,

I will be brief(ish) this time, since wordiness seems not to be working.  
I've been around Puppet for a fairly long time, and I think I know what I'm 
talking about, but by all means do evaluate my claims for yourself.

On Friday, June 24, 2016 at 9:20:58 PM UTC-5, Alex Samad wrote:
 

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


Your ENC does the grouping.  Environments are *one* way to organize each 
group's manifests and data, but multiple people are advising you against 
using them that way.

> Surely you don't 
> > suppose that every machine in the same operational environment will be 
> > configured identically to every other, so even if you do match Puppet 
> > environments to operational environments, that does not in itself 
> address 
> > questions about how to assign configurations to nodes -- or, in Puppet 
> > speak, how to classify nodes. 
> Why can't I expect that. if I expect puppet to look after things like 
> MOTD, SSHD config, smtp config, firewall config. users. SOE directory 
> setup. Why can't I expect them to be the same. I understand that ip 
> address and name will be different. 
>


Evidently you *do* suppose.  Wow.

Most people have machines of different kinds under management -- web 
servers, database servers, workstations, etc..  These normally have some 
commonalities in their configurations -- maybe many commonalities -- but 
their overall configurations are not identical.  If indeed no machine in 
any of your groups is distinguishable from any other in the same group 
except by its network identifiers (hostname / IP / MAC) then Puppet 
environments are even less appropriate for you than I thought.  In that 
case, the key thing you should do is define one class per group, and have 
your ENC assign the appropriate one of those classes to each machine.

 

> > In the first place, this still has nothing to do with nodes being 
> mindful of 
> > which Puppet environment they are assigned to, nor even of which 
> operational 
> > environment they are assigned to.  Nodes will use whichever winbind (for 
> > example) is installed on them, regardless of which environments you 
> label 
> > them with.  The nodes themselves don't much care what you call them -- 
> they 
> > simply operate according to the way you configure them. 
>
> But ... this is what i want to use puppet for.



You're missing my point.  Which winbind (as an example) is installed on a 
given node can absolutely be managed by Puppet.  The point is that the 
nodes themselves don't need to know which Puppet environment -- or even 
which operating environment -- they are assigned to; they just use 
whichever winbind they currently have (as managed by Puppet).

 

> when i say want to - I would like to. if i want to roll out a new test 
> version of winbind I had presume I would just change the package 
> modules for winbind to a newer version and it would roll out for that 
> environment - I would plan to leave it there for a week or month or 
> two to test. then once satisfied move than onto production. 
>


And you can do that with Puppet.  You just shouldn't use Puppet 
environments as your mechanism for mapping which nodes get which package 
versions.

 

> > 
> > In the second place, if the master has enough information to determine 
> > nodes' intended operational environments, and it knows how nodes in 
> those 
> > operational environments should be configured, then it can configure 
> those 
> > nodes appropriately.  If not, then not.  Puppet environments are one 
> vehicle 
>
> would i then need to have lots of if statements or ??? 
>


No.  It's a question of defining and assigning appropriate classes, and of 
associating the correct *data* with each node.  I cannot overemphasize the 
importance of data -- this is everything from which versions or which 
packages are supposed to be installed, to which users, to which servers to 
rely on, to the contents of the MOTD.  One of the most fundamental lessons 
of the last seven or so years of Puppet has been that externalizing data of 
almost all types is a tremendous win.


John

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

Re: [Puppet Users] Re: external node classifier my setup

[jcbollinger]

On Thursday, June 23, 2016 at 6:11:11 PM UTC-5, Alex Samad wrote:
>
> On 24 June 2016 at 00:16, jcbollinger <john.bo...@stjude.org > 
> wrote: 
>

[...]
 

> > In the first place, I recommend not using multiple Puppet environments 
> > unless you have a Puppet-related reason for doing so.  The prime reason 
> in 
> > this category would be that you want to allow for use of different 
> versions 
> > of the same Puppet modules to be used with one group of nodes than with 
> > another.  When no such reason applies, environments do not provide a 
> benefit 
> > commensurate with the extra complication and work they involve. 
> > 
> > In the second place, yes, you're wrong.  The Puppet environment to which 
> a 
> > node is assigned affects the details of the catalogs built for it, which 
> in 
> > turn affects those nodes' configurations.  The master makes decisions 
> based 
> > on node environment, but nodes need not and should not care why they are 
> > configured as they are.  For example, nodes do not need to know or care 
> > about the meaning of the contents of their MOTD; they just need to 
> present 
> > the text -- whatever it is -- to users when they log in and when they 
> ask 
>
> I agree but how do you make them difference for different nodes, if I 
> specify a group of nodes that have a specific MOTD... the nodes don't 
> care but ( i was using it as an example). maybe a better one would be 
> say smtp setup - all nodes have it, non prod must point to the non 
> prod smtp server. 
>
>

How is configuring which SMTP server a node uses fundamentally different 
from configuring a node's MOTD?  In either case you're just plugging the 
right data into the right hole.  The holes are even similar in shape: part 
or all of a particular text file in a known location (or on Windows, the 
holes are sometimes registry entries).

You said earlier that your master will assign nodes to environments, and at 
that time you were identifying Puppet environments with operational 
environments.  It follows that you anticipate that your master will have 
enough information to identify nodes' intended operational environments.  
How the master should translate that information into node configurations 
is an entirely different question, and largely orthogonal to whether Puppet 
environments are associated with operational environments.  Surely you 
don't suppose that every machine in the same operational environment will 
be configured identically to every other, so even if you do match Puppet 
environments to operational environments, that does not in itself address 
questions about how to assign configurations to nodes -- or, in Puppet 
speak, how to *classify* nodes.

In fact, Puppet has several mechanisms for that, one of them being the one 
that you already plan on using to assign nodes to environments: the external 
node classifier (ENC) <https://docs.puppet.com/guides/external_nodes.html>.  
Puppet also makes heavy use of external data for configuring nodes, 
generally accessed via its Hiera <https://docs.puppet.com/hiera/latest/> 
hierarchical data subsystem.  Hiera data can be used to directly classify 
nodes (hiera_include()), or to supplement classification performed 
primarily elsewhere (automated data binding, hiera(), hiera_hash(), 
hiera_array()).  I prefer to put most of the load on Hiera, myself, but the 
reasons for that would be an entirely separate discussion.

Furthermore, how you structure your manifest set plays heavily into how 
easily this all works out.  If you are not already aware of Craig Dunn's 
"Roles and Profiles" pattern <http://www.craigdunn.org/2012/05/239/>, then 
you should familiarize yourself with it.  You are not obligated to use it, 
but I think it synergizes with your objectives, and it has been applied 
with great success in a lot of places.

 

> > for it.  Likewise, they do not need to know why they are configured to 
> > access a particular database server, why they have the particular vhosts 
> > configured that they do, why they have the particular users and 
> passwords 
> > they have, why they mount the particular remote file systems they mount, 
> > etc.. 
> > 
>
>
> Sorry our argument seems counter intuitive.  Maybe I am miss 
> understanding. 
>
> For example I have had a lot of issue with winbind. (centos 6.x).  So 
> my thought is 
>
> production environment - has all the prod nodes. 
> It has a specific version of winbind, might be old but it works 
>
> My other environments have different newer versions of winbind. 
>
>
> if you can explain how I can do that with 1 environment . happy to 
> learn. I haven't done a puppet setup before - which is why i'm asking 
> and questioning. 
>

Re: [Puppet Users] Re: external node classifier my setup

[jcbollinger]

On Thursday, June 23, 2016 at 1:30:37 AM UTC-5, Alex Samad wrote:
>
> Hi 
>
> So I am a bit of a newbie.  My assumption was to setup using a master 
> puppet server. But I wanted to make sure that environment was handled 
> by the master puppet - I have control over that and I might not be 
> able to exclude control over the managed box from other users (dam 
> developers !). 
>
>

I'm inclined to agree that central control is to be preferred.  Do be 
aware, however, that control over node environment is mostly a *management* 
feature, not a *security* feature.  Your master can control what resources 
it records in nodes' catalogs, but those nodes' admins can disable Puppet, 
make it run in --noop mode, make it present false facts to the master, and 
many other things.  Do not grant privileges to people whom you do not 
trust, and do not trust anyone any more than you need to do.

 

> I wanted some way to test what I was doing was correct. 
>
>

And you found one.

 

> " 
> If your nodes care deeply about which Puppet environment they are 
> assigned to, then you are doing something wrong. 
> " 
>
> so I am planning on having atleast a production, sim , inf, non prod 
> and a dev environment. 
>
> I would presume a box would want to know which environment they are 
> in, because in prod they might be on  a certain rpm / module or 
> certain config - lets say for example MOTD. 
>
> But i might be wrong ? 
>
>

In the first place, I recommend *not* using multiple Puppet environments 
unless you have a Puppet-related reason for doing so.  The prime reason in 
this category would be that you want to allow for use of different versions 
of the same Puppet modules to be used with one group of nodes than with 
another.  When no such reason applies, environments do not provide a 
benefit commensurate with the extra complication and work they involve.

In the second place, yes, you're wrong.  The Puppet environment to which a 
node is assigned affects the details of the catalogs built for it, which in 
turn affects those nodes' configurations.  The *master* makes decisions 
based on node environment, but nodes need not and should not care why they 
are configured as they are.  For example, nodes do not need to know or care 
about the meaning of the contents of their MOTD; they just need to present 
the text -- whatever it is -- to users when they log in and when they ask 
for it.  Likewise, they do not need to know why they are configured to 
access a particular database server, why they have the particular vhosts 
configured that they do, why they have the particular users and passwords 
they have, why they mount the particular remote file systems they mount, 
*etc*..

 

> My thought had been to align production environment with production 
> server, infra with infra servers and non prod non infra in the non 
> prod environment. 
>


Even if you ignore my advice and do that, what I'm saying is that you 
should not identify Puppet's sense of "environment" with any external 
concept going by the same name.  I maintain that nodes probably don't need 
to be explicitly aware of the label of their operational environment, 
either, but especially if you're exerting central control over Puppet 
environments, there is no reason for nodes to care how Puppet labels those 
environments.


John

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

[Puppet Users] Re: get one file with all server in puppet (export resource)

[jcbollinger]

On Thursday, June 23, 2016 at 4:17:39 AM UTC-5, Andreas Dvorak wrote:
>
> Hi,
>
> now I have change it a little, but it still does not work.
>
> class check_mk::agent::serverlist {
>   @@server_list { "$::hostname":
> filename => '/tmp/checkmkhosts',
>   }
>
>   define server_list ( $filename ) {
> ensure_resource ( 'file', $filename, {} )
>   }
>
> }
>
>

Do not nest classes or defines inside classes.  The fact that Puppet 
accepts nesting at all is essentially a legacy feature.  Put each class 
definition and each defined type definition in its own file.

Furthermore, do not use the defined() or ensure_resource() functions, at 
least not until you've a lot more experience.  Approaches based on these 
functions at minimum have evaluation-order dependencies, which can bite 
you.  They provide a means to paper over your problem instead of actually 
fixing it.

 

> class check_mk::server::serverlist {
>   Server_list <<| |>>
> }
>
> Error 400 on SERVER: Resource type server_list doesn't exist
>
>

The name of the defined type nested in your previous class is 
check_mk::agent::serverlist::server_list, so a reference to it would be 
spelled 
Check_mk::Agent::Serverlist::Server_list. But changing that will not solve 
your problem, because the file you end up managing will be empty.

The first thing you need to appreciate is that exported (and virtual) 
resources have no magic.  In particular, above all else they are resources, 
with substantially all the characteristics and constraints of resources.  
In particular, they must have unique names and titles; for exported 
resources, that applies both in the context from which they are exported 
and in the ones into which they are imported.  It does not generally make 
sense to export a resource unless that resource is uniquely characteristic 
of the node whose catalog exports it.

The canonical example for exported resources is probably managing /etc/hosts 
by exporting and collecting Host resources.  Note in particular that 
resources exchanged for that purpose represent individual entries in the 
hosts file, no one of them represents the *whole* hosts file.  That case 
depends on the Host type knowing how to identify and manage individual host 
entries.

I see at least three approaches that could work for you:

   1. Write a custom type and provider, along lines parallel to the Host 
   type.  This is far and away the cleanest to use, but it's a fair amount of 
   work, and probably not a good place for an inexperienced Puppeteer to start.
   2. Get the Concat module from the forge, and use that.  Your nodes can 
   export Concat::Fragment resources representing the parts (lines) of the 
   file, and Concat provides for assembling them into a single file on the 
   node that collects those fragments.  This would be my recommendation.
   3. Even simpler, however, would be to install the puppetlabs-stdlib 
   module and use its File_line resource as the one you export and collect.

Note well the common characteristic of all of those approaches: they 
provide for modelling the separate parts of the target file separately, so 
that each node that exports a part exports only that part for which it is 
responsible.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/adbd969d-89b0-4d14-b880-0762efdbf47a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: external node classifier my setup

[jcbollinger]

On Wednesday, June 22, 2016 at 2:21:27 AM UTC-5, Alex Samad wrote:
>
> :)))
>
> seems like after writing this I found my answer
>
> I used 
>
> puppet agent --test --verbose
>
> shows me that it is classified as environment alex. thats good.
>
> but
> puppet  config print environment 
> still show production? so I am guessing the above just looks at the puppet 
> config files and as I haven't set environment it defaults to production !
>
> So the question is, is this the best way to do it ?
>
>

The command ...

puppet config print environment

... indeed does print a value derived from the local Puppet configuration 
file.  The default for this value is 'production'.  Whatever value the 
command prints is the value that will be used for the node's environment, 
*provided 
that* the node-specified environment is not overridden by an external node 
classifier running on the master.  This allows nodes to request specific 
environments, while still affording the master the final say.  No matter 
whether the setting takes a default or explicit value in the node's local 
configuration (which 'puppet config print environment' will print), that 
value must be taken as provisional at best.

If your nodes care deeply about which Puppet environment they are assigned 
to, then you are doing something wrong.  If you just want to check, 
however, then the method you discovered, relying on verbose output from the 
agent, seems entirely reasonable.  You could perhaps tweak that by adding a 
--tags option that filters out all resources, so that you get node 
information without applying anything.  You cannot get a reliably correct 
answer without consulting the master, because the master has the final word 
on the matter.


John

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

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

[jcbollinger]

On Monday, June 13, 2016 at 7:45:12 AM UTC-5, Matt Larson wrote:
>
> Eric et al,
>
> Thanks again for your help with this!  I realize how crazy it may seem to 
> want to rebuild from source.  My company has become so paranoid of open 
> source software due to recent events,
>


At the risk of taking this a bit off-topic, which "recent events" are they 
that make your company hypervigilant about open-source software?

More on-topic: perhaps your company would prefer to license Puppet PE over 
devoting resources to vetting the open-source release.  I mean, when they 
pay for OS X, surely they don't perform a source-level review of the 
underlying BSD-licensed kernel and utilities.  Similarly with all the 
devices they buy that have Linux inside.  And of course, there can be no 
question of demanding to review the source of the many closed-source 
applications they use.  So if the distinguishing characteristic determining 
whether they want to review is whether they've spent money, then I'm 
confident that Puppet, Inc. would be pleased to help solve your problem by 
accepting money in exchange for PE.  It's a win-win!


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/569b4f99-d85c-4c9e-9da9-bd1799557c6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How to handle multiple modules requiring the same packages

[jcbollinger]

On Monday, June 13, 2016 at 5:21:42 AM UTC-5, Justin Rowles wrote:
>
> At risk of bumping a now truly ancient thread (which I found because I 
> have a 3rd party module and one of my own which both want to control a 
> specific package), I don't see why puppet should complain when two 
> identical (or at least non-contradictory) invocations of the same resource 
> are found.
>


You have necro'd a thread that was already necro'd once before.  I guess if 
history is any indicator, we can expect it to be necro'd again some time 
around July, 2018.  But let's see whether we can defy history, shall we?

In any case, there is no answer to the question of *why* Puppet works as it 
does in this regard that will be of any help to you.  That is, no answer to 
that question will help you resolve your present issue.  There has been a 
great deal of discussion of the general topic over the years; in fact, I 
think it may be Puppet's single most controversial characteristic.  Yet it 
endures.

If you really want to discuss why, then that discussion would be better 
conducted over on puppet-developers.

If you just want to vent, then ok, get it out of your system.

If you have specific questions about how to apply some of the plethora of 
information and advice that is already available, or if you have some 
pattern that you think has not been adequately covered, then by all means, 
please do start a new thread to discuss it.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/67379af9-8f81-419a-a86f-c92a1af558bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Run Puppet Class only once

[jcbollinger]

On Tuesday, June 7, 2016 at 5:13:33 AM UTC-5, Christoph wrote:
>
> Hi there,
>
> I want to run a whole puppet class only once when provisioning a system 
> for the first time.
>
> Unfortunately I do not find a way to do this. 
>
> I know how to run commands once using onlyif or unless or creates, but 
> what about running a whole class ?
>
>

As Rob described, what you describe goes against the Puppet grain.  Classes 
and resources should be idempotent -- *that* is the purpose of Exec's onlyif, 
unless, and creates parameters.  Puppet is not a script engine; it is a 
state management system.

If you insist on writing and applying classes that are not idempotent, 
however, then your options for controlling whether such classes are applied 
to a given node on a given run are these:

   1. Assign the class only to nodes to which you want to apply it
   
That implies that you need a mechanism to determine whether your class 
needs to be applied; among the more promising of such mechanisms are (i) 
manipulating node facts and (ii) establishing separate environments within 
Puppet.  Note also that you must be sure to disable usage of cached 
catalogs wherever there is any chance that a catalog contains a class that 
should not be re-applied.


John

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

[Puppet Users] Re: Include class with parameters

[jcbollinger]

On Wednesday, June 8, 2016 at 11:49:58 PM UTC-5, Harish Kothuri wrote:
>
> Hi,
>
> I have classA with parameter and i want to include this in another classB 
> . I expected to consider the default value defined in foreman for classA 
> but it's not happening. 
>
>
> class classA ($version)
> {
>
[...] 

> }
>
>
> class classB($variable)
> {
>
> *include classA   # throws error in this line "Must pass parameter to 
> Class [ClassA]*
> [...]
> }
>
>

The Foreman is providing you an opportunity to define a default for the 
class parameter *for its own purposes*.  This default applies when you 
assign a class to a node directly via The Foreman, but it is external to 
Puppet.  It does not apply when one class assigns another to the node.

You have three main options:

   1. In class B, use resource-like declaration of class A, in which you 
   explicitly specify a value for class A's parameter.
   2. Rely on automated data binding (i.e. Hiera) to specify a value for 
   class A's parameter.
   3. Specify your default value for the parameter in class A's definition.

In fact, those options are non-exclusive: you can use any combination.  
They are listed in priority order; the first one that provides a parameter 
value wins.  For classes assigned directly via The Foreman, any parameter 
assignments via The Foreman are roughly equivalent to option (1).  
Parameter value binding is evaluated on a per-parameter basis, so different 
parameters' values can be assigned via different options.

HOWEVER, if you have any classes that may be declared more than once then 
option (1) is largely off the table.  That option can be exercised at most 
once for any given class, and that must occur in the first-evaluated 
declaration of the class for a given catalog.  It can be difficult to 
control the order in which declarations are evaluated, so exercising option 
(1) safely can be tricky.

Inasmuch as you can have only one default value per parameter built into a 
class definition, and inasmuch as one prefers to avoid modifying 
third-party modules, option (3) has somewhat limited utility.  You cannot 
rely on it (exclusively) where you want a parameter to take different 
values in different cases, and if you do not like the value you get this 
way then your only means to change it is to modify the class definition.

That leaves option (2) as the only truly general-purpose approach.  
Automated data binding was one of the greatest advances in Puppet 3 -- 
learn it, live it, love it.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/82e67d0b-d1d7-4418-80e8-679ff99cdcc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Hiera, define, class, putting all together

[jcbollinger]

On Tuesday, June 7, 2016 at 8:02:24 AM UTC-5, Helmut Schneider wrote:
>
> jcbollinger wrote: 
>
>
Without the case statement, how can I make sure that ubuntu only 
> receives classes for ubuntu and not e.g. for Windows then? 
>
>

That is where your data hierarchy comes in.  You have a level named 
"ubuntu-common"; it therefore stands to reason that if you have any Windows 
machines under management then there is also a "windows-common" (even if 
it's only notional).  These would be *alternatives* for a particular level 
of your hierarchy, and you would select which to use based on node facts.  
That's precisely what you presently do via the 'case' statement, but you 
can, and probably should, do it directly in your hierarchy definition.  
This is one of the primary uses of Hiera interpolation tokens.  The Hiera 
docs for defining a hierarchy 
<https://docs.puppet.com/hiera/3.1/hierarchy.html> discuss this and provide 
an example.  (I've linked to the Hiera 3.1 docs, but substantially the same 
thing applies to older Hiera as well.)


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e2eb4a36-5ae2-4dee-86fa-f938ade5f9d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[jcbollinger]

On Wednesday, June 8, 2016 at 4:06:10 AM UTC-5, Matt Larson wrote:
>
> I did try installing via the PC1 (AIO) repo, and it worked ok for me at 
> home.  But like I said, can't do that at work.
>
> What is your main concern with AIO?  I don't wanna make a bad step here.   
> At first, AIO sounded scary to me... like some alternative to rpm/yum (in 
> case of rhel-based distros), but it's still the same packaging mechanism, 
> just dedicated repos per collective release, yes?
>
>

No, AIO is quite a different beast from a separate repo per release.  It is 
Puppet software plus private copies of substantially all dependencies, all 
in a single package.  It is true that the packages in question are of the 
target machines' native package type, but that's not the point.  I have 
both philosophical and practical objections to the practice, without regard 
to the details of Puppet's AIO packages specifically.  Your Infosec people 
are going to hate it more specifically and intensely, and it is possible 
that you will even run into a policy that forbids (third party) AIO 
packages altogether.  If they undertake the required review, then expect it 
to take a long time, because they will need to review every component 
included in the AIO.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/98b0d9d0-c522-42dd-90ea-755900446d62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find class

[jcbollinger]

>
>
> I ran 'puppet module list' and got the following.
> /etc/puppet/environments/production/modules
>

[...]

And are you certain that node server01 is in the 'production' environment?  
That is the default, but you do mention that you have at least one other.

Does file 
/etc/puppet/environments/production/modules/apache/manifests/init.pp exist 
on the master?  Is it, and every directory in the path to it, accessible to 
the master process (which ordinarily runs unprivileged)?

Do you see any relevant diagnostics in the master's log that you can 
correlate with the diagnostic emitted by the agent?


John

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

[Puppet Users] Re: Hiera, define, class, putting all together

[jcbollinger]

On Saturday, June 4, 2016 at 7:20:19 PM UTC-5, Helmut Schneider wrote:
>
> Hi, 
>
> I'm new to puppet and read docs as much as possible, so forgive some 
> confusion in my code. 
>
>
[...]
 

> nodes/xyz.yaml: 
> packages: 
>   - postfix 
>   - wget 
> apacheModules: 
>   - mpm_prefork 
>   - php 
>   - ssl 
>
>
[...]
 

> nodes.pp: 
> case $operatingsystem { 
>   /^(Debian|Ubuntu)$/: { 
>
 
[...]

$ubuntuDefaultApacheModules = hiera_array ('apacheModules', '', 
> 'ubuntu-common') 
> $ubuntuExtraApacheModules = hiera_array ('apacheModules', '', 
> "nodes/$fqdn") 
> $ubuntuApacheModules = [ $ubuntuDefaultApacheModules, 
> $ubuntuExtraApacheModules ] 
> hiera_include ('classes', '', 'ubuntu-common') 
>   } 
>   default: { 
>} 
> } 
> hiera_include ('classes', '', "nodes/$fqdn") 
> [...] 
> install-packages { [ $ubuntuDefaultPackages, $packages ]: } <= works 
> apache24::modules { $ubuntuApacheModules: } <= fails 
>
> The error is: 
>
> Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: Duplicate declaration: Apache24::Modules[mpm_prefork] is 
> already declared in file 
> /etc/puppet/environments/production/manifests/nodes.pp:54; cannot 
> redeclare at /etc/puppet/environments/production/manifests/nodes.pp:54 
> on node xyz 
>
> Apache24::Modules[mpm_prefork] varies. I'm using the apache class from 
> puppetlabs. Apache24::Modules is called only from nodes.pp, there are 
> no duplicates. 
>
>

If there are no duplicates among your Hiera data, then it follows that you 
are *creating* the duplication in your manifests, which indeed appears to 
be plausible.  In any event, you do appear to be using Hiera in a less than 
efficient manner.  Here are some important considerations that bear on the 
question:

   - The choice among functions hiera(), hiera_array(), and hiera_hash() 
   has little to do with the expected type of the value returned.  Although 
   the latter two do return an array and a hash, respectively, the plain 
   hiera() function will also return one of those if that is the type of 
   the data it finds associated with the given key.  The primary distinction 
   among these is the lookup strategy.  In particular, the hiera_array() 
   function performs an "array-merge" lookup, which collects data from the 
   whole hierarchy, whereas the plain hiera() function performs a priority 
   lookup, returning only the value from the highest-priority hierarchy level 
   that provides one.
   - The third parameter to the hiera-family functions is optional, and 
   usually unneeded.  Additionally, I suspect its docs are misleading for 
   hiera_hash() and hiera_array(): whereas it does cause the specified 
   hierarchy level to be consulted, first, it does not makes sense for these 
   two functions for the search to stop there in the event that the key is 
   found in the override level.  That ought to apply only to the hiera() 
   function, from which the docs for that argument in the other two functions 
   appear to have been copied.
   
 

> My question is: Is the approach itself correct? I want to pass 
> $packages and $apachemodules to a class that does the install. 
>
>

There's nothing inherently wrong with constructing those arrays and using 
them as resource titles.  There's nothing any more wrong about using 
array-titled, resource-like class declarations than there is about using 
resource-like class declarations in general.  If you use array titles, 
however, then you undertake responsibility to ensure that the arrays 
contain no duplicate elements.  In this case, it appears that you have 
ensured the opposite.

Consider this call:

hiera_array ('apacheModules', '', 'ubuntu-common')

It performs an array-merge lookup for key 'apacheModules', with hierarchy 
level 'ubuntu-common' inserted at the top of the hierarchy.  That level is 
already in the hierarchy for the node, or so I must presume.  Now remember 
that an array-merge lookup collects data from every level in the hierarchy, 
so if that duplicate level contains any data for the requested key then you 
will automatically get dupes for all those data.

Even if you weren't getting dupes by virtue of having the same hierarchy 
level consulted twice, it looks like you have a second avenue for dupes.  
You are performing two array-merge lookups and then concatenating the 
results.  Since each array-merge lookup will collect data from the whole 
hierarchy (plus, in your case, an extra level), the two sets of results you 
are concatenating will have many elements in common, so concatenating them 
produces dupes.

The bottom line is that you're making this a lot harder than it needs to 
be.  You have no need to use a manual hierarchy override if you simply 
define the hierarchy appropriately, as the details of your error suggest 
you have already done.  And you do not need separate array-merge lookups 
for each key: with the hierarchy defined correctly, a single one will 

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

[jcbollinger]

On Friday, June 3, 2016 at 1:51:10 PM UTC-5, LinuxDan wrote:
>
> First Silly Question: Why ?
> What do you need to do that cannot be done with the RPM's from a 
> Puppetlabs repo ?
>

If I were undertaking the exercise, it would be to avoid the AIO 
structure.  I may one day undertake that exercise, but until now I have 
instead just avoided upgrading to Puppet 4.


John

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