Re: [Puppet Users] Does create_resources support virtual resources?

[Alex Harvey]

On Saturday, March 31, 2012 at 6:04:28 AM UTC+11, Gary Larizza wrote:
>
> Create_resources doesn't support virtual users, but Hiera DOES support 
> hash-merging, so it could find all users in all hierarchies with hiera_hash 
> and then declare them at once. 


Presumably at some point this feature was added; create_resources does in 
fact now support virtual and exported resources:
https://docs.puppet.com/puppet/latest/function.html#createresources

It's also in the at least latest version of Puppet 3.
 

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

Re: [Puppet Users] Re: Documenting corner cases

[Alex Harvey]

And of course there may not be an error message or an output string to
search on.  In that case, I would be appreciative to a reporter who spends
time thinking about the kinds of search phrases that others might come up
with to find the same issue.  Test them, see where they lead.

If they took me to someone's unanswered question on Stack Exchange or
Ask.puppetlabs.com or some other forum I'd add links there back to the
now-documented issue.

On 13 April 2016 at 01:11, Alex Harvey  wrote:

>
>
> On Tuesday, April 12, 2016 at 5:40:03 AM UTC+10, Rob Nelson wrote:
>>
>> Some of us (and I seem to be really good at this) run into edge cases
>> that others often do not. The information is then stored in some obscure
>> Jira ticket, GitHub issue, or just in someone's head. When the next person
>> runs into the same corner case, if they're lucky, they'll stumble onto an
>> error message that is in the previous ticket/issue and find the answer.
>> However, in many cases, that user will end up not finding the issue, or not
>> seeing the relation between that issue and the user's situation.
>>
>> If you had a preference for where you would expect to find corner cases
>> documented, what would that be? I'll suggest a few common places to start:
>>
>> A) Jira tickets at https://tickets.puppetlabs.com/browse (e.g.
>> https://tickets.puppetlabs.com/browse/PUP-6106)
>> B) Github issues on the project (e.g.
>> https://github.com/rodjek/rspec-puppet/issues/377)
>> C) As an addendum on the closest-related official documentation (e.g. the
>> very last paragraph at
>> https://docs.puppet.com/hiera/1/lookup_types.html#example
>> <https://www.google.com/url?q=https%3A%2F%2Fdocs.puppet.com%2Fhiera%2F1%2Flookup_types.html%23example&sa=D&sntz=1&usg=AFQjCNFBFeKc8N8NFtUBzURJJT0Pw9-udQ>
>> )
>>
>> Please write in any other locations you would look for it. I'm very
>> interested in making sure that others don't feel the same pains I do, so
>> want to be sure to get the most eyes I can on documentation.
>>
>>
> A good question and I have thought about this a lot.
>
> I'm sure like most, my first search is on Google for the error message,
> and that will search Jira & Github & public documentation too.  No luck,
> I'll had quotes to force Google to search for the exact string.  Next I'll
> search the code using grep and regular expressions, or Github search.  Then
> it's off to git blame to see if there's any more info.
>
> As far as what I'd expect, rather than hope for, if it's really an
> edge-case, and the observed behaviour is not designed behaviour, then I'd
> expect to find it documented in Jira or Github, and I'd expect and hope to
> not find it mentioned in public documentation.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/-xwPAfgOsTA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/7e0aec54-6021-4eeb-a7f7-d21ac5b2ff09%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/7e0aec54-6021-4eeb-a7f7-d21ac5b2ff09%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[Puppet Users] Re: Documenting corner cases

[Alex Harvey]

On Tuesday, April 12, 2016 at 5:40:03 AM UTC+10, Rob Nelson wrote:
>
> Some of us (and I seem to be really good at this) run into edge cases that 
> others often do not. The information is then stored in some obscure Jira 
> ticket, GitHub issue, or just in someone's head. When the next person runs 
> into the same corner case, if they're lucky, they'll stumble onto an error 
> message that is in the previous ticket/issue and find the answer. However, 
> in many cases, that user will end up not finding the issue, or not seeing 
> the relation between that issue and the user's situation.
>
> If you had a preference for where you would expect to find corner cases 
> documented, what would that be? I'll suggest a few common places to start:
>
> A) Jira tickets at https://tickets.puppetlabs.com/browse (e.g. 
> https://tickets.puppetlabs.com/browse/PUP-6106)
> B) Github issues on the project (e.g. 
> https://github.com/rodjek/rspec-puppet/issues/377)
> C) As an addendum on the closest-related official documentation (e.g. the 
> very last paragraph at 
> https://docs.puppet.com/hiera/1/lookup_types.html#example 
> 
> )
>
> Please write in any other locations you would look for it. I'm very 
> interested in making sure that others don't feel the same pains I do, so 
> want to be sure to get the most eyes I can on documentation.
>
>
A good question and I have thought about this a lot.

I'm sure like most, my first search is on Google for the error message, and 
that will search Jira & Github & public documentation too.  No luck, I'll 
had quotes to force Google to search for the exact string.  Next I'll 
search the code using grep and regular expressions, or Github search.  Then 
it's off to git blame to see if there's any more info.

As far as what I'd expect, rather than hope for, if it's really an 
edge-case, and the observed behaviour is not designed behaviour, then I'd 
expect to find it documented in Jira or Github, and I'd expect and hope to 
not find it mentioned in public documentation.

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

Re: [Puppet Users] Puppet 4 syntax highlighting in Wordpress

[Alex Harvey]

On Tuesday, April 12, 2016 at 5:48:14 AM UTC+10, Nigel Kersten wrote:
>
> I do Puppet syntax highlighting like this:
>
> Open up puppet code in Vim with syntax highlighting on.
>
> Use ":TOhtml" to save it as a formatted HTML file.
>
> Either use the HTML snippet directly on a web page, or for some GUI HTML 
> editors, they'll understand styled text in your clipboard buffer (that's 
> how I preserve editable text, but syntax highlighted for PowerPoint/Keynote 
> slide decks)
>
> This way I can toggle stuff like Vim line numbering that sometimes I want 
> on, and sometimes I want off, and I'm using the same syntax highlighter 
> that I use for normal editing of Puppet code.
>
>
I just tried it.  That is, indeed, really cool.  Thank you so much!

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

Re: [Puppet Users] Puppet 4 syntax highlighting in Wordpress

[Alex Harvey]

I still haven't found any Puppet syntax highlighting plugins for Puppet (3 
or 4).  I'll be most grateful to anyone willing to share their secrets with 
me. :)

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

Re: [Puppet Users] Puppet 4 syntax highlighting in Wordpress

[Alex Harvey]

Ruby highlighting's not doing so well in my case:

<https://lh3.googleusercontent.com/-AqAkwuVNI34/Vvi5lnYOEHI/AoU/JRURT5ahstsonFmaobjZ-LXc5Gw-qzYLg/s1600/Screen%2BShot%2B2016-03-28%2Bat%2B3.55.27%2Bpm.png>

There must be a solution to this because there are lots of Puppet blogs out 
there that are all looking great.


On Monday, March 28, 2016 at 1:54:24 AM UTC+11, Trevor Vaughan wrote:
>
> Hi Alex,
>
> I don't think that any specific highlighting has been released for Puppet 
> 4 but I find that the Ruby syntax highlighting does a reasonable job in 
> most cases.
>
> Trevor
>
> On Sun, Mar 27, 2016 at 4:53 AM, Alex Harvey  > wrote:
>
>> Hi all,
>>
>> Does anyone out there have any tips for getting nice-looking Puppet 4 
>> syntax highlighting to work in a Wordpress blog?  I am currently using Alex 
>> Mills's SyntaxHighlighter Evolved 
>> <http://www.viper007bond.com/wordpress-plugins/syntaxhighlighter/> and I 
>> found one apparently unmaintained plugin for Puppet 3 era plugin 
>> en-jbrinkley/syntaxhighlighter-puppet 
>> <https://github.com/en-jbrinkley/syntaxhighlighter-puppet>.  Googling 
>> isn't bringing up anything written after Puppet 4 was released.
>>
>> All the best,
>> Alex
>>
>> --
>> Partner
>> RAZOR Consulting
>> t: +61 409 665 227
>> w: http://razorconsulting.com.au
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/3d915b0d-402a-4944-9ef2-fc1f64908519%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/3d915b0d-402a-4944-9ef2-fc1f64908519%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
>
> -- This account not approved for unencrypted proprietary information --
>

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

[Puppet Users] Puppet 4 syntax highlighting in Wordpress

[Alex Harvey]

Hi all,

Does anyone out there have any tips for getting nice-looking Puppet 4 
syntax highlighting to work in a Wordpress blog?  I am currently using Alex 
Mills's SyntaxHighlighter Evolved 
 and I 
found one apparently unmaintained plugin for Puppet 3 era plugin 
en-jbrinkley/syntaxhighlighter-puppet 
.  Googling isn't 
bringing up anything written after Puppet 4 was released.

All the best,
Alex

--
Partner
RAZOR Consulting
t: +61 409 665 227
w: http://razorconsulting.com.au

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

Re: [Puppet Users] puppetlabs-firewall: source param as array

[Alex Harvey]

Hi all,

In case anyone else is looking to solve this problem in a standard way, I 
have written a fairly simple module that attempts to close out this gap:
https://forge.puppetlabs.com/alexharvey/firewall_multi/readme

Best regards,
Alex


On Wednesday, November 30, 2011 at 11:17:25 AM UTC+11, Mohamed wrote:
>
> in case it help someone, I got it too do what I needed this way:
>
> # Allow netbackup
> define allow_netbackup() {
> firewall { "300 allow netbackup traffic from ${name}":
> proto   => 'tcp',
> dport   => [13724,1556,10102,10082],
> source  => $name,
> action  => accept,
> }
> }
> allow_netbackup { $netbackup_master_servers:}
> allow_netbackup { $netbackup_media_servers: }
>
> You're right Jacob. The bug in the module is really a documentation
> bug. The doc says it expects an array for source and for destination,
> when it should not.
> Looking at the code it seems the module cannot provide anything
> iptables itself does not, and iptables does not provide for list of
> ips/networks in source and dest.
>
>
> Thanks,
> Mohamed.
>
> On Tue, Nov 29, 2011 at 5:25 PM, Mohamed Lrhazi  > wrote:
> > Cool. Thanks guys.
> >
> > On Tue, Nov 29, 2011 at 5:23 PM, Jacob Helwig  > wrote:
> >> On 2011-11-29 13:05 , Mohamed Lrhazi wrote:
> >>> Hi,
> >>>
> >>> am trying this rule:
> >>>
> >>>
> >>> firewall { '100 allow ssh from GUNET':
> >>>   proto   => 'tcp',
> >>>   dport   => '22',
> >>>   source  => ['10.0.0.0/8','192.168.0.0/16',],
> >>>   action  => accept,
> >>> }
> >>>
> >>>
> >>> and it only seems to add a rule for the first subnet. The second is
> >>> silently ignored.
> >>>
> >>> is my syntax incorrect?
> >>>
> >>> Thanks,
> >>> Mohamed.
> >>>
> >>
> >> The type doesn't appear to be written to handle accepting arrays in the
> >> source property, so given how it's written it's expected behavior,
> >> though sounds like it's rather undesirable.
> >>
> >> --
> >> Jacob Helwig
> >> http://about.me/jhelwig
> >>
> >>
> >
>
>

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

Re: [Puppet Users] firewall module to accept array of sources/dests

[Alex Harvey]

Hi all,

I have a working prototype and any feedback would be welcome.
https://github.com/alexharv074/puppet-firewall_multi

Kind regards,
Alex



On 21 February 2016 at 10:28, Felix Frank 
wrote:

> On 02/19/2016 04:00 AM, Alex Harvey wrote:
>
>> So I think I'll call it:
>>
>> firewall_multi
>>
>> It will basically accept any parameter that firewall accepts and pass it
>> straight through to the firewall resource, unless that parameter is the
>> source or destination, in which case it will of course loop through these
>> arrays, spawing one firewall resource for each.
>>
>
> :thumbs_up: :-)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/6pF_AP3lZbk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/56C8F68B.4000504%40Alumni.TU-Berlin.de
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [Puppet Users] firewall module to accept array of sources/dests

[Alex Harvey]

On 14 February 2016 at 00:30, Felix Frank 
wrote:
>
> Sure, but I feel that this case is especially confusing.
>
> The user does not remove a resource from their manifest. They change a
> parameter of one of their resources, which feels like changing a property
> value for a proper resource. The fact that this may not be sync'ed
> correctly by the agent can be surprising, and removing firewall rules is a
> highly critical operation.
>
> So, yes, I think you should go ahead and build that module, but please
> make sure to plaster its documentation with warnings ;-)
>

OK, noted.

I have decided that I will create a new Puppet Forge module for this, one
for Puppet 3 and a separate one for Puppet 4.  This way I can avoid
creating a new support burden for the team that manages Puppet Labs
firewall and still deliver the features needed.  If it proves to be
popular, I'll be happy to have it merged into the support Puppet Forge
firewall module at any time.

It will deliver just a single defined type (and the Puppet 3 version will
also deliver a private defined type to workaround the lack of iterator.).

As far as the naming is concerned I wish I could call it:

firewall::multi

That would be nice because it could be moved to the firewall module at a
later date and no one using it would need to refactor.  However that would
result in a module name clash with the Puppet Labs firewall module, which
is a dependency.

So I think I'll call it:

firewall_multi

It will basically accept any parameter that firewall accepts and pass it
straight through to the firewall resource, unless that parameter is the
source or destination, in which case it will of course loop through these
arrays, spawing one firewall resource for each.

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

Re: [Puppet Users] firewall module to accept array of sources/dests

[Alex Harvey]

On 13 February 2016 at 09:57, Felix Frank 
wrote:

> On 02/12/2016 07:11 AM, Alex Harvey wrote:
>
>>
>> ACCEPT tcp  --  1.1.1.1/24   0.0.0.0/0   multiport dports
>> 80,443 /* 100 allow http and https access */
>> ACCEPT tcp  --  2.2.2.2/24   0.0.0.0/0 multiport dports
>> 80,443 /* 100 allow http and https access */
>>
>> The provider could be modified so as to represent these as:
>>
> 
>
> Conceptionally, it might just work. But it would be quite hard, and create
> a maintenance nightmare. (Have you *looked* at the current provider
> instances/parsing methods? Oh my...)


Yeah, I have.  Main reason I'm leaning to (2). :)


> 2.
>>
>> Add to the firewall module (or perhaps a new Forge module) a defined type
>> that wraps around the existing firewall types/providers.  In Puppet 4, that
>> should be easy to do in the DSL using an iterator; but because I'd like to
>> support Puppet 3 as well, it's a bit trickier.  Still, quite doable.  The
>> hardest part seems to be thinking up a name for the new type.  Any
>> suggestions?
>>
>
> While naming things *is* one of the hardest problems in software, I'm sure
> we can figure something out on this one. No worries.
>
> Iterating on the DSL level is nice and all, but it will cause issues for
> users who don't purge unmanaged firewall rules (granted, that should be a
> rare issue, but then I'm willing to bet that there are people with weird
> edge cases like that.)
>
> The problem is that removing sources from the array of your multiplexer
> resource will just lead to some firewall resources not being in the catalog
> anymore. Their respective rules will remain orphaned, which is not what the
> user will expect.
>

Is this really a problem though?  The documentation for the module
recommends that users do purge the unmanaged firewall rules.  If they
choose not to, then they should understand that means they need to take
care of those manually.  It's no different to any other resource in
Puppet.  If one day I stop managing the /etc/motd file, I should understand
that Puppet won't delete the file; it'll simply leave it in whatever state
it was in.

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

Re: [Puppet Users] firewall module to accept array of sources/dests

[Alex Harvey]

Hi Felix, Hunter

Thanks for the responses.

There's no doubt that it's a tricky feature to write, but having the 
feature would be a big win for the community and my customers.  So I'd 
really like to do this, and I'm sure if we put our heads together we can 
come up with the best design possible.

I am playing in my mind with a few ways of doing this.

1.

Suppose we have two rules as follows:

ACCEPT tcp  --  1.1.1.1/24   0.0.0.0/0   multiport 
dports 80,443 /* 100 allow http and https access */ 

ACCEPT tcp  --  2.2.2.2/24   0.0.0.0/0   multiport 
dports 80,443 /* 100 allow http and https access */ 

The provider could be modified so as to represent these as:

firewall { '100 allow http and https access':  



  ensure => 'present',

  action => 'accept',

  chain  => 'INPUT',

  checksum_fill  => 'false',

  clamp_mss_to_pmtu  => 'false',

  clusterip_new  => 'false',

  dport  => ['80', '443'],

  isfragment => 'false',

  kernel_timezone=> 'false',

  log_uid=> 'false',

  physdev_is_bridged => 'false',

  proto  => 'tcp',

  random => 'false',

  rdest  => 'false',

  reap   => 'false',

  rsource=> 'false',

  rttl   => 'false',

  socket => 'false',

  source => ['1.1.1.1/24', '2.2.2.2/24'],

  table  => 'filter',

  time_contiguous=> 'false',

}


How?  I don't know yet.  At first glance it's hard to see why this would be 
a hugely difficult coding problem, but I suspect that many unpleasant 
edge-cases that I haven't thought of yet lie in wait for me, and that's why 
I lean to option 2.

2.

Add to the firewall module (or perhaps a new Forge module) a defined type 
that wraps around the existing firewall types/providers.  In Puppet 4, that 
should be easy to do in the DSL using an iterator; but because I'd like to 
support Puppet 3 as well, it's a bit trickier.  Still, quite doable.  The 
hardest part seems to be thinking up a name for the new type.  Any 
suggestions?

Best regards,
Alex


On Friday, February 12, 2016 at 11:35:33 AM UTC+11, Hunter Haugen wrote:
>
> The difficulty with allowing multiple sources is that it falls in line 
> only with a scripted workflow, not an idempotent workflow. This is from the 
> iptables manpage: "Multiple addresses can be specified, but this will 
> expand to multiple rules (when adding with -A), or will cause multiple 
> rules to be deleted (with -D)."
>
> Converting the firewall type to manage multiple rules with a single 
> resource is surely the way to madness ;).
>
>
>
>
> -Hunter
>
> On Thu, Feb 11, 2016 at 2:33 PM, Felix Frank  > wrote:
>
>> On 02/09/2016 06:41 AM, Alex Harvey wrote:
>>
>>> Can I get some feedback at this early stage that my PR would be 
>>> accepted, assuming I can come up with a clean, working solution?
>>>
>>
>> Hi,
>>
>> I don't think that anyone will be able to answer this without at least 
>> looking at what you're building, or intend to.
>>
>> From experience, cool features like this have good chances, *unless* they 
>> come with some pitfalls or a catch that the maintainer (Puppet Labs?) is 
>> not willing to accept.
>>
>> As for the feature you're looking at: My gut tells me that you might not 
>> be able to come up with a clean model to support all that. Multiple 
>> destination ports should not be problematic, thanks to netfilter's 
>> multiport module.
>>
>> But multiple addresses get expanded into distinct rules, IIRC. This 
>> likely cannot be reconciled with Puppet's resource model, or not without 
>> introducing some bizarre semantic tricks.
>>
>> So my advice is to open a PR as soon as possible, even if the feature 
>> does not work yet, just to showcase your approach and gather the feedback 
>> you came seeking here.
>>
>> HTH,
>> Felix
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/56BD0C52.80307%40Alumni.TU-Berlin.de
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[Puppet Users] Re: What I think that is needed for a practical Puppet class

[Alex Harvey]

That's fantastic work you are doing there.

I also agree with your approach to teaching.  Traditionally new Puppet 
users have been trained with a view to writing their own modules, only to 
find out at the end that the real work is in building infrastructure out of 
Forge modules.  As you say, this made sense about 8 years ago, in the days 
when the Forge either didn't exist, or was too immature to support most 
user's needs.  Today, new Puppet users need to be taught to resist the urge 
to write their own modules.  To do so well requires fairly advanced skills 
in programming, and it's rarely necessary.

In my approach the most important concepts to impart to the new users are:

   - How to install Puppet and set up the infrastructure
   - How to set up your first control repo, Hiera data, and how to 
   structure Roles and Profiles
   - Git basics
   - the CI infrastructure like Jenkins, Travis CI etc
   - Librarian-puppet and R10K
   - basic rspec-puppet & Vagrant/Beaker

I spend some time on the basics of the language, but I regard writing your 
own Puppet modules as the advanced work that comes later.

Best regards,
Alex


On Saturday, January 2, 2016 at 9:36:45 AM UTC+11, Rudy Gevaert wrote:
>
> Hi,
>
> This is just report of something I just wrote on my blog (
> http://blog.webworm.org/content/whats-needed-practical-puppet-class) . 
>  Feel free to comment here or through (@rgevaert) twitter or email.
>
> I'm a happy user of Puppet and love sharing my knowledge with other people. 
>  Although I'm not that active online, I've done quiet some work in 
> getting Puppet known and used in environments that aren't that easily 
> addressable.  More specifically, IT departments at several universities 
> in Cuba and Ethiopia.  This as part of several IT for development 
>  programmes.  If you want to learn more about that work, read the paper I 
> published 
> 
>  about 
> it.  I also started the Puppet User Group in Ethiopia 
> .
> Last December I was in Cuba to follow up on my projects.  When I was at 
> the Universidad de Oriente in Santiago De Cuba I spent some time with the 
> university staff working with Puppet.  The adoption is still very young 
> and they are still in the 'learning and testing' phase.
>  
> During our hands on sessions it became clear to me that there is need for 
> specific instructors material that teaches the use of Puppet by using 
> already available modules.
> I've seen many 'introduction to Puppet' presentations and created several 
> myself.  But to be honest I never really saw any presentation that showed 
> the audience to start from scratch and build up your infrastructure by 
> using already available modules.
>  
> Why is that necessary?  Because I've seen so many newbies getting lost in 
> setting up Puppet and then loosing way to much time with reinventing the 
> wheel.  New users to Puppet, and very specifically users who don't have 
> access to peers that are already using Puppet, have a hard time deciding 
> what to do first.  And many of them start out like so many people started 
> with Puppet 8 years ago: some small classes and no modules.  But 
> unfortunately they get stuck there and don't move on.
>  
> In the same category of missing information is how to set up an easy and 
> usable work flow.  For people who are new to Puppet (and maybe even Git 
> too!) setting up dynamic environments is too difficult.  There are just 
> too many ways to do it.  I think it's important to have this in place. 
>  Similarly getting a good syntax checking and puppet lint tests
> in place right from the beginning is key in writing good Puppet code.
>  
> It's not that there is no good documentation or tutorials.  Puppetlabs 
> provides 
> a "learning VM ". But the 
> learning VM is more for individual learning.  Recently I found Example42 
> Puppet Tutorial .  I 
> find the example42 Puppet Tutorial very good.  And best of all, the tutorial 
> is Free Software too.  I've already decided to start using this tutorial 
> if I need to teach Puppet in the future.  They also provide some example 
> architectures.  But I'm missing the approach I was discussing. 
>  
> So what should be in the approach I'm looking for?
>  
> For example I think the new users (let's call them students) should be shown 
> how to build a small infrastructure with existing modules. Installing 
> modules to manage some key components in your infrastructure:
>
>- motd updating (not important but good first exercise)
>- repository management
>- DNS configuration in resolve.conf
>- user management
>- ssh configuration
>- firewall rules
>- setting up an apache web server
>- setting up a MySQL server
>
>  
> Only after completing these ste

[Puppet Users] firewall module to accept array of sources/dests

[Alex Harvey]

Hi all,

I just ran into an issue with the firewall module
https://tickets.puppetlabs.com/browse/MODULES-3066

It looks like I'm not the first user of this module to be surprised to 
discover that it can't do this:

firewall { '100 allow http and https access':

  source => [

'1.1.1.1/24',

'1.1.2.1/24',

  ],

  dport  => [80, 443],

  proto  => tcp,

  action => accept,

}

Apparently there is a long history of people having a go at adding this 
feature and then giving up.

Well, I am that sort of person who doesn't feel comfortable in a world 
where the above declaration is impossible, therefore will volunteer to add 
the feature.

Can I get some feedback at this early stage that my PR would be accepted, 
assuming I can come up with a clean, working solution?

Thanks,
Alex

-- 
Alex Harvey
RAZOR Consulting

http://razorconsulting.com.au
T: +61 409 665 227

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

Re: [Puppet Users] librarian-puppet vs R10K

[Alex Harvey]

On Friday, January 29, 2016 at 2:31:14 AM UTC+11, Steve Traylen wrote:
>
>
> There's another one to consider 
> https://github.com/cernops/jens 
> it recently got an update to accept hook calls from gitlab. We get 
> our git pushes deployed in 0.4s now.  
>

Thanks I'll keep it in mind!

>
>

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

Re: [Puppet Users] librarian-puppet vs R10K

[Alex Harvey]

On Friday, January 29, 2016 at 6:15:41 AM UTC+11, Garrett Honeycutt wrote:
>
>
> Hi Alex, 
>
> I generally implement both for customers. Though I use Dan Bode's 
> librarian-puppet-simple which purposely does not handle dependencies. I 
> spoke at a couple Puppet Camp's regarding dealing with modules and here 
> are slides[1] explaining the pro's and con's of the different approaches. 
>

Thanks.  Your slides are just what I needed to see.  And I didn't know 
about librarian-puppet-simple and I'm glad I do now.  Yes, dependency 
resolution is indeed a mixed blessing.  When you say you implement both do 
you mean you use librarian-puppet-simple on the CI side of the pipeline and 
R10K on the deployment to Puppet masters side?
 

>
> R10k is great, even with a build pipeline, because the caching feature 
> really speeds up the build jobs over librarian-puppet, which will need 
> to download the git repo's each time. 
>

It may be a documentation problem that I'm struggling with.  You don't 
happen to know of any code or documentation that shows how to R10K in the 
build pipeline?  By the way, Librarian-puppet does support caching via 
$LIBRARAN_PUPPET_TMP, which can point to a long-lived directory on the CI 
server.  So, actually, Librarian-puppet has never been a bottleneck for me, 
and unnoticeable relative to the time it takes all the tests to run.


> I've also used r10k to build Puppet platform as a service for large 
> enterprises that have many products and teams with their own distinct 
> environments. This allows many teams to leverage each others work while 
> giving them their own autonomy with regards to number of environments, 
> testing abilities, module versions and release schedules. 
>

I'd love to know more about this. :) 

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

[Puppet Users] librarian-puppet vs R10K

[Alex Harvey]

Hi all,

I am interested in the future of the Librarian-puppet project - to find out 
how many people are still using it, and if there are people out there who 
actually prefer it over R10K.

I recently looked into R10K for a few projects I was working on, and I 
found it to be surprisingly complicated.  It had many features I didn't 
seem to need, features that overlap with features provided by 
Jenkins/Bamboo, and appeared designed with a view to helping people deploy 
code in complex ways, help them to test short lived branches on Puppet 
masters, etc.  This might have made sense once, but if you're doing all 
your development in a test-driven fashion in Vagrant/Rspec-puppet/Beaker, I 
can't see a need for R10K's features, and concluded it was mainly just a 
lot harder to understand than Librarian-puppet.  I do see that it performs 
better, but again, Librarian-puppet has never been a bottleneck.

Other views most appreciated.

With best regards,
Alex

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

Re: [Puppet Users] Re: Compiling catalogs as CD pipeline

[Alex Harvey]

I finally got around to writing the promised blog post:
http://razorconsulting.com.au/parallelising-rspec-puppet.html

I might add right here that I'd be willing to add this functionality into 
the Puppet Labs supported modules if I could get someone to give me 
feedback on the approach and if people think it's a valuable contribution.

On Wednesday, October 21, 2015 at 3:14:00 AM UTC+11, David Schmitt wrote:
>
>
>
> On 20/10/2015 08:32, Alex Harvey wrote:
>
> In case anyone is looking at this in the archives: 
>
> I ended up concluding that the tool we were using is redundant and 
> superseded by rspec-puppet.
>
> I now have rspec-puppet host tests that look something like:
>
> require 'spec_helper'
>
>
> ['myhost1, 'myhost2'].each do |fqdn|
>
>
>   hostname, node_environment, n, node_datacentre =
>
> /(.*)\.(.*)([12])\..*\.(.*)\..*\.mydomain.com/.match(fqdn).captures
>
>
>   node_stream = node_environment + n
>
>
>   describe fqdn do
>
> let(:facts) {{
>
>   :hostname   => hostname,
>
>   :otherfacts => otherfacts,
>
> }}
>
> it {
>
>   should compile.with_all_deps
>
> }
>
>   end
>
>
> end
>
> I also set up parallel_tests from 
> https://github.com/grosser/parallel_tests  and this got my tests running 
> in less than 5 minutes, whereas they were taking over 20 minutes before I 
> did that.
>
> There isn't a lot of good documentation on how to do all this, and I hope 
> to write a blog post fairly soon.
>
>
> Excellent, that would be most helpful!
>
>
>
> Cheers, David
>

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

[Puppet Users] Re: catalog-diff and create_resources not correct

[Alex Harvey]

Actually looks like there's an open PR to fix this here
https://github.com/acidprime/puppet-catalog-diff/pull/28

On Wednesday, December 23, 2015 at 3:55:11 PM UTC+11, Alex Harvey wrote:
>
> Hi Johan,
>
> I read your excellent blog post on this
>
> http://johan.koewacht.net/puppet/2015/01/12/catalog-diff-create_resources.html
>
> I have also run into the same issue.  Was this ever resolved?  
>
> You wrote at the end,
>
> But question now, should we patch the catalog-diff preprocessor.rb or 
> puppet’s native create_resources.rb
>
>
> Considering that the purpose of the catalog diff tool is to assist in 
> migrations from earlier to later versions of Puppet, it's no use patching 
> create_resources.rb in a newer version of Puppet.  I think this is really a 
> bug in the catalog diff tool?
>
> Thanks,
> Alex
>
> On Tuesday, December 23, 2014 at 8:36:27 PM UTC+11, Johan De Wit wrote:
>>
>> Hi, 
>>
>> We wanted to use catalog diff to verify the old and new catalogs during 
>> conversionto hiera.  They should be both have the saem resources with the 
>> same paramters.
>> But every resource that is created in the 'new' version with 
>> create_resources(), gives a wrong catalog diff.
>>
>> The resource is indeed in both catalogs, only the old one contains 2 
>> automatic attributes (file: and line:).  I suspect this is the cause.
>>
>> Anyone experienced simular result ?
>>
>> In the meantime, I try to understand the catalog-diff code to see where 
>> this could be corrected.
>>
>> Grts
>>
>> johan
>>
>>
>>Catalog diff output :
>>
>>
>> 
>>test_node 
>>100.0% 
>>
>>
>> 
>>Total resources in old: 0
>>Total resources in new: 1
>>Only in new:
>>notify[my_test_notify]
>>Catalag percentage added:   100.00
>>Catalog percentage removed: 0.00
>>Catalog percentage changed: 0.00
>>Added and removed resources:+1 / 0
>>Node percentage:100.0
>>Node differences:   1
>>
>>
>> 
>>1 out of 1 nodes changed. 
>>100.0% 
>>
>>
>> 
>>Nodes with the most changes by percent changed:
>>1. test_node 
>>100.00%
>>Nodes with the most changes by differeces:
>>1. test_node 
>> 1false
>> 
>>The manifest new and catalog entry
>> 
>>node 'test_node' {
>>   $my_notify =  { 'my_test_notify' => { 'message' => 'this is a test 
>>notify',
>> 'name' => 'test_notify',
>> 'withpath' => 'true', }
>>}
>>   create_resources(notify, $my_notify)
>>}
>> 
>>  {
>>"parameters": {
>>  "withpath": "true",
>>  "message": "this is a test notify",
>>  "name": "test_notify"
>>},
>>"exported": false,
>>"tags": [
>>  "notify",
>>  "my_test_notify",
>>  "node",
>>  "test_node",
>>  "class"
>>],
>>"title": "my_test_notify",
>>"type": "Notify"
>>  }
>> 
>>
>> 
>>The manifest OLD
>> 
>>node 'test_node' {
>>   notify { 'my_test_notify':
>> message  => 'this is a test notify',
>> name => 'test_notify', 
>> withpath => true,
>>   }
>>}
>> 
>>
>>"title": "test

[Puppet Users] Re: catalog-diff and create_resources not correct

[Alex Harvey]

Hi Johan,

I read your excellent blog post on this
http://johan.koewacht.net/puppet/2015/01/12/catalog-diff-create_resources.html

I have also run into the same issue.  Was this ever resolved?  

You wrote at the end,

But question now, should we patch the catalog-diff preprocessor.rb or 
puppet’s native create_resources.rb


Considering that the purpose of the catalog diff tool is to assist in 
migrations from earlier to later versions of Puppet, it's no use patching 
create_resources.rb in a newer version of Puppet.  I think this is really a 
bug in the catalog diff tool?

Thanks,
Alex

On Tuesday, December 23, 2014 at 8:36:27 PM UTC+11, Johan De Wit wrote:
>
> Hi, 
>
> We wanted to use catalog diff to verify the old and new catalogs during 
> conversionto hiera.  They should be both have the saem resources with the 
> same paramters.
> But every resource that is created in the 'new' version with 
> create_resources(), gives a wrong catalog diff.
>
> The resource is indeed in both catalogs, only the old one contains 2 
> automatic attributes (file: and line:).  I suspect this is the cause.
>
> Anyone experienced simular result ?
>
> In the meantime, I try to understand the catalog-diff code to see where 
> this could be corrected.
>
> Grts
>
> johan
>
>
>Catalog diff output :
>
>
> 
>test_node 
>100.0% 
>
>
> 
>Total resources in old: 0
>Total resources in new: 1
>Only in new:
>notify[my_test_notify]
>Catalag percentage added:   100.00
>Catalog percentage removed: 0.00
>Catalog percentage changed: 0.00
>Added and removed resources:+1 / 0
>Node percentage:100.0
>Node differences:   1
>
>
> 
>1 out of 1 nodes changed. 
>100.0% 
>
>
> 
>Nodes with the most changes by percent changed:
>1. test_node   
>  100.00%
>Nodes with the most changes by differeces:
>1. test_node   
>   1false
> 
>The manifest new and catalog entry
> 
>node 'test_node' {
>   $my_notify =  { 'my_test_notify' => { 'message' => 'this is a test 
>notify',
> 'name' => 'test_notify',
> 'withpath' => 'true', }
>}
>   create_resources(notify, $my_notify)
>}
> 
>  {
>"parameters": {
>  "withpath": "true",
>  "message": "this is a test notify",
>  "name": "test_notify"
>},
>"exported": false,
>"tags": [
>  "notify",
>  "my_test_notify",
>  "node",
>  "test_node",
>  "class"
>],
>"title": "my_test_notify",
>"type": "Notify"
>  }
> 
>
> 
>The manifest OLD
> 
>node 'test_node' {
>   notify { 'my_test_notify':
> message  => 'this is a test notify',
> name => 'test_notify', 
> withpath => true,
>   }
>}
> 
>
>"title": "test_node",
>"type": "Node"
>  },
>  {
>"parameters": {
>  "withpath": true,
>  "message": "this is a test notify",
>  "name": "test_notify"
>},
>"exported": false,
>"line": 12,
>"file": 
>
> "/etc/puppetlabs/puppet/environments/rese_old/manifests/nodes/test_node.pp",
>"tags": [
>  "notify",
>  "my_test_notify",
>  "node",
>  "test_node",
>  "class"
>],
>"title": "my_test_notify",
>"type": "Notify"
>  }
>
>
>
>
> -- 
> Johan De Wit
>
> Open Source Consultant
>
> Red Hat Certified Engineer  (805008667232363)
> Puppet Certified Professional 2013/2014 (PCP006)
> _
>  
> Open-Future Phone +32 (0)2/255 70 70
> Zavelstraat 72  Fax   +32 (0)2/255 70 71
> 3071 KORTENBERG Mobile+32 (0)474/42 40 73
> BELGIUM http://www.open-future.be
> _
>  
>
>
> Upcoming Events:
>
> Zabbix Certified Specialist | 
> http://www.open-future.be/zabbix-certified-professional-training-8th-till-9th-janaury
>
> Zabbix Cert

Re: [Puppet Users] Beaker and mock services

[Alex Harvey]

Hi all

What if we added a feature to the Puppet Labs spec helper rake tasks
allowing us to selectively merge in modified versions of some files to the
fixtures directory, rather than currently only supporting symlinking in
entire directories?

I want to use a modified version of one file manifests/base.pp but I want
everything else in manifests to be used as is.  Currently, the spec helper
allows me via .fixtures.yml to symlink into fixtures the entire directory
of manifest code.

If there was a feature that allowed me to make everything in manifests
available as-is except for base.pp then I could commit a modified file
site_manifests/base.pp in fixtures that removes the class for joining the
FreeIPA domain.

Any other ideas?

On 24 October 2015 at 19:25, Alex Harvey  wrote:

>
>
> On Thursday, October 22, 2015 at 8:11:46 PM UTC+11, David Schmitt wrote:
>>
>> fakes/mocks in s/w development have a very limited scope: usually only
>> one or two methods with pre-defined return values. If you really do not
>> want to test integration with a certain service, perhaps making that
>> explicit and having a test version of a profile that does not include the
>> FreeIPA support makes sense? It would also ensure that other services (like
>> SSO on the apache ??) do not depend too heavily on FreeIPA.
>>
>> It reminds me a bit of Aspect Oriented Programming, where cross-cutting
>> concerns are extracted from the code and re-injected by the compiler in a
>> uniform way across the board.
>>
>
> Actually, I have worked on a number of projects in my time where
> developers did mock up some reasonably complex fakes for integration
> testing.
>
> I have been thinking about this more.  At the moment, integration tests
> are limited because Beaker does not allow us to modify either the source
> manifest code or the compiled catalogs under test.  We had a flow like:
>
> Beaker --> provisioner (vagrant, vSphere etc) --> Serverspec
>
> Could we instead have something like:
>
> Beaker --> Rspec-puppet (possibly producing modified catalogs) -->
> provisioner --> Serverspec
>
> We have so much awesome functionality in Rspec-puppet but the big gotcha
> is that we have no way of testing the catalogs that it produces on real
> systems.
>
> Could I be onto something here?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/u87-bbzZei8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/de2ab5b7-a9d9-405d-9211-9f1f5b1bb72f%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/de2ab5b7-a9d9-405d-9211-9f1f5b1bb72f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [Puppet Users] Beaker and mock services

[Alex Harvey]

On Thursday, October 22, 2015 at 8:11:46 PM UTC+11, David Schmitt wrote:
>
> fakes/mocks in s/w development have a very limited scope: usually only one 
> or two methods with pre-defined return values. If you really do not want to 
> test integration with a certain service, perhaps making that explicit and 
> having a test version of a profile that does not include the FreeIPA 
> support makes sense? It would also ensure that other services (like SSO on 
> the apache ??) do not depend too heavily on FreeIPA.
>
> It reminds me a bit of Aspect Oriented Programming, where cross-cutting 
> concerns are extracted from the code and re-injected by the compiler in a 
> uniform way across the board.
>

Actually, I have worked on a number of projects in my time where developers 
did mock up some reasonably complex fakes for integration testing.

I have been thinking about this more.  At the moment, integration tests are 
limited because Beaker does not allow us to modify either the source 
manifest code or the compiled catalogs under test.  We had a flow like:

Beaker --> provisioner (vagrant, vSphere etc) --> Serverspec

Could we instead have something like:

Beaker --> Rspec-puppet (possibly producing modified catalogs) --> 
provisioner --> Serverspec

We have so much awesome functionality in Rspec-puppet but the big gotcha is 
that we have no way of testing the catalogs that it produces on real 
systems.

Could I be onto something here?

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

Re: [Puppet Users] Beaker and mock services

[Alex Harvey]

On 21 October 2015 at 23:28, Gareth Rushgrove 
wrote:

> On 20 October 2015 at 08:49, Alex Harvey  wrote:
> > Hi all,
> >
> > I am investigating whether or not I can use Beaker to do acceptance
> testing
> > on roles and profiles.
> >
> > I've had a look at Liam Bennett's excellent blog posts -
> >
> http://tech.opentable.co.uk/blog/2014/09/01/testing-puppet-with-beaker-pt-dot-3-testing-roles/
> > http://www.slideshare.net/liamjbennett/cfgmgmt2015-testing-with-beaker
> >
> > I need to handle a situation in my tests where, say, a role that I am
> > testing will apply a base class which will cause the node, for instance,
> to
> > join a FreeIPA domain.  But I don't want Beaker to actually build a
> FreeIPA
> > box.  And I don't want my short-lived node to join a real FreeIPA domain.
> >
> > I would hope that Beaker could either build Mock Services
> > https://en.wikipedia.org/wiki/Mock_object
> >
> > Or better still, tell Beaker to expect the base class to try to apply the
> > FreeIPA class, and just pretend it succeeds.  Just as you can stub out
> > methods in rspec etc.
> >
> > Has anyone done anything like this before?
> >
>
> You can actually do something like that :)
>
> Beaker is going to run you Puppet code on the node(s) it spins up,
> probably using apply manifest like so:
>
> apply_manifest(pp, :catch_failures=>true)
>
> If this sees an error while doing so (because your FreeIP class
> doesn't apply) then it will throw an error. However...
>
> If you check the API docs you can see:
>
>
> http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/PuppetHelpers#apply_manifest_on-instance_method
>
> apply_manifest(pp, :accept_all_exit_codes => true)
>
> This will run your puppet code and not throw an error.
>
> Now, whether this works for you really depends on if any other classes
> depend on the FreeIPA class. And you can't easily test for idempotent
> runs easily with this.
>
> Another approach if you can change the puppet code is to introduce a
> switch in the profile, for instance if a fact exists like MOCK_FREEIPA
> you could not include the class. And then drop that fact into your
> beaker test environment.
>
> Also see the other points about testing at different levels but you
> can absolutely do it in your acceptance tests.
>

Thanks Gareth.

Both of these solutions are a bit messy but it is good to know of all the
options.  One of the big issues I would encounter immediately I used
:accept_all_exit_codes is that the FreeIPA code takes several minutes to
time out if the server can't be contacted.  Or if I moved all this logic
associated with testing into the code, that would work, but it is not
really where test logic belongs, and it would rather clutter my base
classes.

I feel that there is some space here for a new approach to acceptance
testing.  I am not sure that I agree that acceptance tests should be
end-to-end tests.  Consider:

   - spinning up a FreeIPA system - not to mention all the other external
   services that a base class might depend upon - takes a long time.  The
   longer tests take to run, the less likely people will actually run them.
   - not all developers will have workstations that can run such
   resource-intensive tests.
   - I actually don't want to test that every single role can join the
   FreeIPA domain - I only want to test that once, and preferably in tests
   associated with my FreeIPA modules and classes.

Another approach might be to could create a long-lived acceptance test
environment that only contains a DNS, FreeIPA, etc, however:

   - this would introduce a management burden - sysadmins needed to keep
   them running, clean up junk related to broken tests etc.
   - It would also introduce a cost - we would have to pay Amazon to always
   have these instances running.

I actually think deploying into a real UAT environment is the only real
end-to-end test of the code that matters before it goes to production.

Now, if I am testing a web server role, rspec-puppet allows me to do very
useful testing on catalogs - but if I am testing a front end web server
role, I only want to know that it builds a properly configured Apache.  I
suppose, therefore, that I could just test the front end web server
profile; although it would be good to also test as much of the integration
as is practical.

What if Beaker was extended to provide a framework for provisioning fakes -
if it accepted plugins somehow for a mocked up FreeIPA service etc.  Would
that be unrealistically complicated?  In the development world, developers
must be mocking up these sorts of fakes all the time.  How do they do it -
do they just continually reinvent the wheel or are the

[Puppet Users] Beaker and mock services

[Alex Harvey]

Hi all,

I am investigating whether or not I can use Beaker to do acceptance testing 
on roles and profiles. 

I've had a look at Liam Bennett's excellent blog posts -
http://tech.opentable.co.uk/blog/2014/09/01/testing-puppet-with-beaker-pt-dot-3-testing-roles/
http://www.slideshare.net/liamjbennett/cfgmgmt2015-testing-with-beaker

I need to handle a situation in my tests where, say, a role that I am 
testing will apply a base class which will cause the node, for instance, to 
join a FreeIPA domain.  But I don't want Beaker to actually build a FreeIPA 
box.  And I don't want my short-lived node to join a real FreeIPA domain.  

I would hope that Beaker could either build Mock Services
https://en.wikipedia.org/wiki/Mock_object

Or better still, tell Beaker to expect the base class to try to apply the 
FreeIPA class, and just pretend it succeeds.  Just as you can stub out 
methods in rspec etc.

Has anyone done anything like this before?

Kind regards,
Alex Harvey

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

[Puppet Users] Re: Compiling catalogs as CD pipeline

[Alex Harvey]

In case anyone is looking at this in the archives:

I ended up concluding that the tool we were using is redundant and 
superseded by rspec-puppet.

I now have rspec-puppet host tests that look something like:

require 'spec_helper'


['myhost1, 'myhost2'].each do |fqdn|


  hostname, node_environment, n, node_datacentre =

/(.*)\.(.*)([12])\..*\.(.*)\..*\.mydomain.com/.match(fqdn).captures


  node_stream = node_environment + n


  describe fqdn do

let(:facts) {{

  :hostname   => hostname,

  :otherfacts => otherfacts,

}}

it {

  should compile.with_all_deps

}

  end


end

I also set up parallel_tests from https://github.com/grosser/parallel_tests 
 and this got my tests running in less than 5 minutes, whereas they were 
taking over 20 minutes before I did that.

There isn't a lot of good documentation on how to do all this, and I hope 
to write a blog post fairly soon.

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

[Puppet Users] Re: [announce] puppetlabs-concat 2.0.x release deletion

[Alex Harvey]

Ah, thanks very much for clearing that up.

On Tuesday, June 30, 2015 at 5:50:04 AM UTC+10, Alex Dreyer wrote:
>
>
>
> On Monday, June 29, 2015 at 12:55:44 AM UTC-7, Alex Harvey wrote:
>>
>> I'm not exactly sure what's going on here but Puppet Forge seems to be 
>> still advertising the versions 2.0.0 and 2.0.1
>>
>> From librarian-puppet install --verbose
>> ...
>> [Librarian] Resolving puppetlabs-concat (< 2.0.0) <
>> https://forgeapi.puppetlabs.com> 
>> [Librarian] Checking manifests 
>> [Librarian] Module puppetlabs-concat found versions: 2.0.1, 2.0.0, 1.2.3, 
>> 1.2.2, 1.2.1, 1.2.0, 1.1.2, 1.1.1, 1.1.0, 1.1.0-rc1, 1.0.4, 1.0.3, 1.0.2, 
>> 1.0.1, 1.0.0, 1.0.0-rc1
>>
>> It is necessary at the moment to explicitly request a version of < 2.0.0 
>> in Puppetfile.
>>
>
> It looks like librarian wasn't checking to see if a release was deleted. 
> It appears to be fixed already in 
> https://github.com/rodjek/librarian-puppet/commit/88efacffccdc26768542d7598f9721de2bc892cd
>
>
>> Looks like Nan Liu had the same problem here
>> https://github.com/echocat/puppet-nfs/pull/28
>>
>> Is this something that will be fixed up soon?
>>
>> On Saturday, June 13, 2015 at 4:57:20 AM UTC+10, Bryan Jen wrote:
>>>
>>> FYI The puppetlabs-concat 2.0.0 and 2.0.1 releases have been deleted 
>>> from the Forge. If you're using either of those versions, please downgrade 
>>> to 1.2.3 as soon as possible. We have also reverted the puppetlabs-concat 
>>> github master to 1.2.3, if you would like to continue using 2.x or 
>>> contribute to 2.x, there is a development branch named "2.0.x" to 
>>> contribute to.
>>>
>>> On Thursday, June 11, 2015 at 3:02:06 PM UTC-7, Bryan Jen wrote:
>>>>
>>>> If you aren’t using puppetlabs-concat or are still using the 
>>>> puppetlabs-concat module with version 1.x you don’t need to continue 
>>>> reading. But, if you’re using puppetlabs-concat 2.0.x...
>>>>
>>>> tl;dr - we have uncovered an issue in the Puppet core that impacts the 
>>>> puppetlabs-concat 2.0.x series and are deleting those releases from the 
>>>> forge. Please downgrade your environments to use puppetlabs-concat 1.2.x. 
>>>>
>>>> We recently reworked the puppetlabs-concat module to transition from an 
>>>> exec running a ruby script to concatenate files together to a native type 
>>>> (hooray!). This gave us vast performance improvements, but with the way 
>>>> the 
>>>> type was implemented we ended up running into a Puppet bug (
>>>> https://tickets.puppetlabs.com/browse/PUP-1963) 
>>>> that we can’t effectively work around with the existing code. Due to 
>>>> this, we’re pulling the 2.0.x release series. The Puppet bug was causing 
>>>> us 
>>>> to not properly propagate notify and subscribe metaparameters triggered by 
>>>> changes in puppetlabs-concat resources. This means that, for example, 
>>>> services subscribing to concat resources will not get restarted when the 
>>>> configuration file is updated.
>>>>
>>>> To mitigate these issues, the puppetlabs-concat 2.0.x releases will be 
>>>> deleted from the forge. They will still be available for download but will 
>>>> not be installable using the PMT. We are still hoping to rework 
>>>> puppetlabs-concat to use a native type, however we don’t have a firm 
>>>> timeline for when that work will happen.
>>>>
>>>> -- 
>>>> Bryan Jen
>>>> *brya...@puppetlabs.com*
>>>> Modules Software Engineer
>>>>
>>>> *PuppetConf 2015 <http://2015.puppetconf.com/> is coming to Portland, 
>>>> Oregon! Join us October 5-9.*
>>>> *Register now to take advantage of the Early Adopter discount 
>>>> <https://www.eventbrite.com/e/puppetconf-2015-october-5-9-tickets-13115894995?discount=EarlyAdopter>
>>>>  *
>>>> *—**save $349!*
>>>>  
>>>

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

[Puppet Users] Re: [announce] puppetlabs-concat 2.0.x release deletion

[Alex Harvey]

I'm not exactly sure what's going on here but Puppet Forge seems to be 
still advertising the versions 2.0.0 and 2.0.1

>From librarian-puppet install --verbose
...
[Librarian] Resolving puppetlabs-concat (< 2.0.0) 
 
[Librarian] Checking manifests 
[Librarian] Module puppetlabs-concat found versions: 2.0.1, 2.0.0, 1.2.3, 
1.2.2, 1.2.1, 1.2.0, 1.1.2, 1.1.1, 1.1.0, 1.1.0-rc1, 1.0.4, 1.0.3, 1.0.2, 
1.0.1, 1.0.0, 1.0.0-rc1

It is necessary at the moment to explicitly request a version of < 2.0.0 in 
Puppetfile.

Looks like Nan Liu had the same problem here
https://github.com/echocat/puppet-nfs/pull/28

Is this something that will be fixed up soon?

On Saturday, June 13, 2015 at 4:57:20 AM UTC+10, Bryan Jen wrote:
>
> FYI The puppetlabs-concat 2.0.0 and 2.0.1 releases have been deleted from 
> the Forge. If you're using either of those versions, please downgrade to 
> 1.2.3 as soon as possible. We have also reverted the puppetlabs-concat 
> github master to 1.2.3, if you would like to continue using 2.x or 
> contribute to 2.x, there is a development branch named "2.0.x" to 
> contribute to.
>
> On Thursday, June 11, 2015 at 3:02:06 PM UTC-7, Bryan Jen wrote:
>>
>> If you aren’t using puppetlabs-concat or are still using the 
>> puppetlabs-concat module with version 1.x you don’t need to continue 
>> reading. But, if you’re using puppetlabs-concat 2.0.x...
>>
>> tl;dr - we have uncovered an issue in the Puppet core that impacts the 
>> puppetlabs-concat 2.0.x series and are deleting those releases from the 
>> forge. Please downgrade your environments to use puppetlabs-concat 1.2.x. 
>>
>> We recently reworked the puppetlabs-concat module to transition from an 
>> exec running a ruby script to concatenate files together to a native type 
>> (hooray!). This gave us vast performance improvements, but with the way the 
>> type was implemented we ended up running into a Puppet bug (
>> https://tickets.puppetlabs.com/browse/PUP-1963) 
>> that we can’t effectively work around with the existing code. Due to 
>> this, we’re pulling the 2.0.x release series. The Puppet bug was causing us 
>> to not properly propagate notify and subscribe metaparameters triggered by 
>> changes in puppetlabs-concat resources. This means that, for example, 
>> services subscribing to concat resources will not get restarted when the 
>> configuration file is updated.
>>
>> To mitigate these issues, the puppetlabs-concat 2.0.x releases will be 
>> deleted from the forge. They will still be available for download but will 
>> not be installable using the PMT. We are still hoping to rework 
>> puppetlabs-concat to use a native type, however we don’t have a firm 
>> timeline for when that work will happen.
>>
>> -- 
>> Bryan Jen
>> *brya...@puppetlabs.com *
>> Modules Software Engineer
>>
>> *PuppetConf 2015  is coming to Portland, 
>> Oregon! Join us October 5-9.*
>> *Register now to take advantage of the Early Adopter discount 
>> 
>>  *
>> *—**save $349!*
>>  
>

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

[Puppet Users] Re: Compiling catalogs as CD pipeline

[Alex Harvey]

On Monday, May 25, 2015 at 11:25:35 PM UTC+10, Clayton O'Neill wrote:
>
> On Sunday, May 24, 2015 at 4:05:15 AM UTC-4, Alex Harvey wrote:
>
>> As part of an upgrade to Puppet 4, my team is considering to switch from 
>> an in-house tool that compiles puppet manifests into catalog against the 
>> installed version of Puppet
>> https://github.com/oldNoakes/puppet-validator
>>
>> Looking around it seems that others do things like puppet-lint, puppet 
>> parser validate, puppet-rspec and beaker in their pipelines.
>>
>> Do others also compile catalogs from their CI/CD systems?  If so, how do 
>> others do it?
>>
>
> We do before and after catalog compiles for every change pre-merge, and 
> push the results into Gerrit (the code review tool we use).  We have 
> jenkins jobs that pull back the puppet facts from every puppet master a few 
> times a day ,and we do the catalog compiles against every node type served 
> by every puppet master.  We've got some home grown scripts for doing this 
> that parallelizes the catalog compiles across multiple jenkins slaves and 
> across multiple cpus on each slave so it only takes a few minutes to run 
> the test.  We've found the before and after diff to be hugely useful. 
>  We're using R.I.Pienaar's catalog-diff tool, since rodjek's is a bit more 
> opinionated in ways that don't work as well for us.
>
> We've proposed a talk for PuppetConf to talk about this and some other 
> aspects of our CI/CD infra that might be common in other organizations, but 
> we've not seen many people talk about. 
>

Yes, I think that's a great idea.  The code we use also compiles catalogs 
for every node, but doesn't go as far as to tell us the differences before 
and after for every node.  If you have skeptical managers worried that 
Puppet could break every node in your system, your idea would give you a 
very high level of confidence that such things could never happen.

If I may ask, how do you actually compile the catalog though.  Are you 
using puppet master --compile or calling the internals directly?  Is your 
code publicly available?

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

[Puppet Users] Compiling catalogs as CD pipeline

[Alex Harvey]

Hi all,

As part of an upgrade to Puppet 4, my team is considering to switch from an 
in-house tool that compiles puppet manifests into catalog against the 
installed version of Puppet
https://github.com/oldNoakes/puppet-validator

Looking around it seems that others do things like puppet-lint, puppet 
parser validate, puppet-rspec and beaker in their pipelines.

Do others also compile catalogs from their CI/CD systems?  If so, how do 
others do it?

Thanks,
Alex

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

Re: [Puppet Users] Error handling in base class in cloud solutions

[Alex Harvey]

On Monday, April 20, 2015 at 10:49:28 PM UTC+10, Pete Brown wrote:
>
> Comments inline.
>
> On 9 Mar 2015 17:19, "Alex Harvey" > 
> wrote:
>
> > I have two questions:
> >
> > Question #1.   Most puppet cloud solutions typically a base class 
> that configures services common to all nodes like the resolver, Nagios, 
> LDAP, etc.  These classes all depend on the existence of external services 
> to function (i.e. a DNS server; a DHCP server; a Nagios server; an LDAP 
> server; and a Logstash system).  Without these services, puppet is expected 
> to fail as it applies the said base class.
> >
> > Now imagine there's a role that builds a front end web server that 
> applies a profile that includes the base class.
> >
> > If we try to apply that class in a vagrant environment it fails, unless:
> >
> > 1)  Our vagrant model environment itself firstly provides a DNS, Nagios, 
> LDAP server - I imagine no one actually does this because no one would have 
> a development laptop with sufficient grunt to spin up all these services 
> simultaneously, and not to mention the time it would take to spin them all 
> up.
>
> You are using puppet to manage your cloud instances right?
> If you use images for your instances (using something like packer and 
> provisioning them with puppet) they will load up pretty quickly.
> You could set dependencies on the instances each instance requires.
> So your instances become just another resource.
>
I think you are misunderstanding the problem.

Allow me to add some example code that might make it clearer.

Imagine I have a base class that includes a FreeIPA client class and a 
metrics colllection class:

class base {
  ...
  include freeipa::client
  include metrics::client
}

Assume that both the FreeIPA client and metrics client classes manage 
services or sets of services, and these services won't start unless there 
exists a FreeIPA server and a metrics server on the network.

Let's assume further that I don't want my production FreeIPA or metrics 
servers to be polluted with data from short-lived developer vagrant 
instances.

So back to my questions,

1)  How can I run up this instance in vagrant without building on my laptop 
either real external services (FreeIPA & metrics collection) or mock 
services that pretend to be the real thing (and, I have no idea how I would 
actually build a mock FreeIPA service but I suppose it's one solution in 
theory).

2)  (More crucially) How can this chicken-egg problem be resolved when 
building the first instances in my empty cloud at the start of the project. 
 If I build the FreeIPA server first, it will fail because it needs the 
metrics collection server.  If I build the metrics server first, it fails 
because it needs the FreeIPA server.

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

[Puppet Users] Re: Error handling in base class in cloud solutions

[Alex Harvey]

Hi all,

I didn't get any responses here so wondering if I might get a response 
second time around.  I have colleagues telling me the answer is "these 
problems are easy if you Ansible or Salt", which strikes me intuitively as 
BS, but has motivated me to dig again to see how others in the Puppet 
community have solved these problems.

Best regards,
Alex

On Monday, March 9, 2015 at 6:19:21 PM UTC+11, Alex Harvey wrote:
>
> Hi all
>
> I'm after some feedback on best practices with regards to error handling.
>
> I have two questions:
>
> Question #1.   Most puppet cloud solutions typically a base class that 
> configures services common to all nodes like the resolver, Nagios, LDAP, 
> etc.  These classes all depend on the existence of external services to 
> function (i.e. a DNS server; a DHCP server; a Nagios server; an LDAP 
> server; and a Logstash system).  Without these services, puppet is expected 
> to fail as it applies the said base class.
>
> Now imagine there's a role that builds a front end web server that applies 
> a profile that includes the base class.
>
> If we try to apply that class in a vagrant environment it fails, unless:
>
> 1)  Our vagrant model environment itself firstly provides a DNS, Nagios, 
> LDAP server - I imagine no one actually does this because no one would have 
> a development laptop with sufficient grunt to spin up all these services 
> simultaneously, and not to mention the time it would take to spin them all 
> up.
> 2)  We could set up an external dedicated Puppet development environment 
> whose only purpose is to support developers testing Puppet code - this will 
> incur an additional ongoing cost to the project, and create a system that 
> needs to be maintained probably without resources to actually maintain it.
> 3)  We could allow vagrant instances to be serviced by an actual 
> development environment used by the application developers - this creates a 
> management burden - our PuppetDB, Nagios system; LDAP system etc is going 
> to be continually polluted with junk data relating to these short-lived 
> development VMs - this feels quite wrong to me.
> 4)  We add conditional logic into the Puppet code - "unless I am a vagrant 
> box, apply the firewall, DNS, DHCP, LDAP & logstash classes" - although I 
> dislike conditional logic, this is the solution I'm leaning towards.
>
> Or something else?
>
> Question #2.  How do people normally handle the absence of these 
> services at the beginning of the project, before any of the above-mentioned 
> external services even exist?
>
> We could:
>
> 1)  Just let the code fail if the services aren't available - very ugly.
> 2)  Comment out services like DNS, Nagios etc in the base class until 
> they've been built - almost as ugly.
> 3)  Handle the service failures in the code - trouble is, you can't really 
> tell Puppet not to, say, apply the Nagios class if Nagios server can't be 
> contacted.
>
> Hopefully there's a better way. :)
>
> TIA,
> Alex
>

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

[Puppet Users] Re: Dependency problem for Puppet yum package

[Alex Harvey]

On Tuesday, April 7, 2015 at 3:05:09 AM UTC+10, staceyt...@gmail.com wrote:
>
> Hi all,
>
> I am trying to use puppet to downgrade my gdm package from 64 to 39, but 
> got package dependency problem:
>
> Here is my class:
>
> class gdmver39 {
>   yumrepo { 'custom':
> baseurl => 'file:/home/admin/REPO/WS6.4',
> enabled => 1,
>   }
>
>   package { "gdm-libs": ensure => '2.30.4-39.el6', require => 
> Yumrepo["custom"] }   
>   package { "gdm-plugin-fingerprint": ensure => '2.30.4-39.el6', require 
> => Yumrepo["custom"] }
>   package { "gdm": ensure => '2.30.4-39.el6', require => Yumrepo["custom"] 
> } 
> }
>
> I think myabe i should add the parameter below to my 'gdm' line'?
>
>   require Package['gdm-libs', 'gdm-plugin-fingerprint'] 
>
> How to tell puppet to handle the dependency automatically?
>
 
You probably want something like:

class gdmver39 {
  yumrepo { 'custom':
baseurl => 'file:/home/admin/REPO/WS6.4',
enabled => 1,
  }

  # set defaults for package type within this class
  Package {
ensure => '2.30.4-39.el6',
require => Yumrepo['custom'],
  }

  package { 'gdm-libs': }   
  package { 'gdm-plugin-fingerprint': }
  package { 'gdm': require => [Package['gdm-libs'], 
Package['gdb-plugin-fingerprint'] }
}

That said, I probably wouldn't use Puppet to do this.  I would have puppet 
just ensure that the packages are present and then do the downgrade outside 
of Puppet.
  

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

Re: [Puppet Users] misbehaving file resource on only one server

[Alex Harvey]

Providing this isn't a production host, I'd use locate to find the file 
posix.rb (that's your built-in file provider), then insert some puts 
statements to see if you can find out exactly where in the code it's 
failing.

On Friday, March 27, 2015 at 3:49:24 PM UTC+11, Gabriel Filion wrote:
>
> On 27/03/15 12:40 AM, Gabriel Filion wrote: 
> >> Failing that, strace'ing might show you something more useful. 
> > I'll see what I can find with strace... 
>
> unfortunately, nothing really useful.. 
>
> in the output below, the first file access gives the same error as the 
> one failing, but seems to work ok: 
>
> lstat("/etc/munin/plugin-conf.d/if_err_eth0.conf", 0x7fff125de9c0) = -1 
> ENOENT (No such file or directory) 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> gettimeofday({1427430950, 856657}, NULL) = 0 
> gettimeofday({1427430950, 856828}, NULL) = 0 
> gettimeofday({1427430950, 856904}, NULL) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> gettimeofday({1427430950, 857379}, NULL) = 0 
> gettimeofday({1427430950, 857540}, NULL) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> gettimeofday({1427430950, 857827}, NULL) = 0 
> gettimeofday({1427430950, 857970}, NULL) = 0 
> lstat("/etc/munin/plugin-conf.d/uptime.conf", 0x7fff125de9c0) = -1 
> ENOENT (No such file or directory) 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> gettimeofday({1427430950, 858358}, NULL) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> gettimeofday({1427430950, 858793}, NULL) = 0 
> gettimeofday({1427430950, 859145}, NULL) = 0 
> sendto(3, "<27>Mar 27 00:35:50 puppet-agent"..., 191, MSG_NOSIGNAL, 
> NULL, 0) = 191 
> write(1, "\33[1;35merr: /Stage[main]/Site_mu"..., 165err: 
> /Stage[main]/Site_munin/Munin::Plugin[uptime]/File[/etc/munin/plugin-conf.d/uptime.conf]:
>  
>
> Could not 
> evaluate: undefined method `[]=' for :chec:Symbol) = 165 
> write(1, "\n", 1 
> )   = 1 
> gettimeofday({1427430950, 859715}, NULL) = 0 
> gettimeofday({1427430950, 859788}, NULL) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> gettimeofday({1427430950, 860310}, NULL) = 0 
> gettimeofday({1427430950, 860568}, NULL) = 0 
> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 
> gettimeofday({1427430950, 860877}, NULL) = 0 
> gettimeofday({1427430950, 861091}, NULL) = 0 
>
> -- 
> Gabriel Filion 
>

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

[Puppet Users] Re: Question about directory environment setting.

[Alex Harvey]

On Thursday, March 19, 2015 at 11:50:08 AM UTC+11, Hiu wrote:
>
> hi Alex,
>>>
>>
> thanks for getting it works. But, what is the reasons having 
> environment.conf? Under which type of circumstance that we need this 
> configuration file? Thanks Again! 
>

As you can see from the documentation, environments "may" contain an 
environment.conf, which allows you to override any or all of these four 
config file settings:
http://docs.puppetlabs.com/puppet/latest/reference/config_file_environment.html#allowed-settings

If you don't already have a requirement to use this feature, you can 
presumably just not use the environment.conf file, and configure your 
directory environment by following this:
http://docs.puppetlabs.com/puppet/latest/reference/environments_configuring.html

I have only ever used the legacy config file environments, and I don't know 
what motivated the change to directory environments.

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

[Puppet Users] Re: Facts which depend on (not-yet-installed) packages

[Alex Harvey]

Have a look at how the build in RPM provider works, for instance:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/rpm.rb#L37

On Wednesday, March 18, 2015 at 2:46:05 PM UTC+11, Alex Harvey wrote:
>
> Can't you avoid this problem altogether by determining the PHP version in 
> your custom provider code?  Then you wouldn't need a custom fact at all, 
> and in your manifest, have the custom type require the PHP package.
>
> On Monday, March 16, 2015 at 6:04:53 AM UTC+11, Jan S. wrote:
>>
>> Hello,
>>
>> I have the following use case: For a custom class/type I need to know 
>> which php_version is installed on the machine. So I wrote a custom fact 
>> like this:
>>
>> Facter.add('php_version') do
>>   setcode do
>> Facter::Util::Resolution.exec('/usr/bin/php -i | /bin/egrep -e "^PHP 
>> Version" | /usr/bin/head -n 1 | /usr/bin/cut -d " " -f 4 | /usr/bin/cut -d 
>> "-" -f 1')
>>   end
>> end
>>
>> It works great. Except: When php is not yet installed (there is a 
>> Package['php'] definition, too). Then it will return an empty string.
>>
>> Thus I have to run puppet two times to get the expected result.
>>
>> I am sure that this is expected behavior of puppet. How do I handle such 
>> case?
>>
>> Regards
>>
>> Jan
>>
>> -- 
>>   
>>   http://dracoblue.net
>>  
>

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

[Puppet Users] Re: Facts which depend on (not-yet-installed) packages

[Alex Harvey]

Can't you avoid this problem altogether by determining the PHP version in 
your custom provider code?  Then you wouldn't need a custom fact at all, 
and in your manifest, have the custom type require the PHP package.

On Monday, March 16, 2015 at 6:04:53 AM UTC+11, Jan S. wrote:
>
> Hello,
>
> I have the following use case: For a custom class/type I need to know 
> which php_version is installed on the machine. So I wrote a custom fact 
> like this:
>
> Facter.add('php_version') do
>   setcode do
> Facter::Util::Resolution.exec('/usr/bin/php -i | /bin/egrep -e "^PHP 
> Version" | /usr/bin/head -n 1 | /usr/bin/cut -d " " -f 4 | /usr/bin/cut -d 
> "-" -f 1')
>   end
> end
>
> It works great. Except: When php is not yet installed (there is a 
> Package['php'] definition, too). Then it will return an empty string.
>
> Thus I have to run puppet two times to get the expected result.
>
> I am sure that this is expected behavior of puppet. How do I handle such 
> case?
>
> Regards
>
> Jan
>
> -- 
>   
>   http://dracoblue.net
>  

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

[Puppet Users] Re: Question about directory environment setting.

[Alex Harvey]

I don't have a PE3.7 handy to try it but it looks like you simply don't 
need a section in your environment.conf file, as the error message says.  I 
think you need to look at this page:
http://docs.puppetlabs.com/puppet/latest/reference/config_file_environment.html

On Wednesday, March 18, 2015 at 1:31:10 PM UTC+11, Hiu wrote:
>
> hi all,
>
> I am pretty new to puppet, and installed puppet 3.7.4 and centos66. I have 
> read some documentations about the directory environment setting. but i 
> can't figure out how to make it work. My aim is create another environment 
> e.g. development. May be it should a simple mistake but, please by all 
> means point me out of a way. thanks!
>
> here is my master puppet.conf
>
> [main]
> environmentpath = /etc/puppet/environments
> certificate_expire_warning = 5184000
> hostprivkey = 
> /var/lib/puppet/ssl/private_keys/centos66-pm.localhost.pem
> httplog = /var/log/puppet/http.log
> publickeydir = /var/lib/puppet/ssl/public_keys
> plugindest = /var/lib/puppet/lib
> catalog_terminus = compiler
> route_file = /etc/puppet/routes.yaml
> localcacert = /var/lib/puppet/ssl/certs/ca.pem
> privatekeydir = /var/lib/puppet/ssl/private_keys
> pluginfactdest = /var/lib/puppet/facts.d
> facts_terminus = yaml
> node_cache_terminus = write_only_yaml
> immutable_node_data = false
> confdir = /etc/puppet
> passfile = /var/lib/puppet/ssl/private/password
> csr_attributes = /etc/puppet/csr_attributes.yaml
> hiera_config = /etc/puppet/hiera.yaml
> hostcert = /var/lib/puppet/ssl/certs/centos66-pm.localhost.pem
> factpath = /var/lib/puppet/lib/facter:/var/lib/puppet/facts
> default_file_terminus = rest
> ssldir = /var/lib/puppet/ssl
> libdir = /var/lib/puppet/lib
> rundir = /var/run/puppet
> hostpubkey = /var/lib/puppet/ssl/public_keys/centos66-pm.localhost.pem
> requestdir = /var/lib/puppet/ssl/certificate_requests
> pluginsource = puppet://puppet/plugins
> node_terminus = plain
> statedir = /var/lib/puppet/state
> logdir = /var/log/puppet
> environment_timeout = 180
> privatedir = /var/lib/puppet/ssl/private
> pluginfactsource = puppet://puppet/pluginfacts
> data_binding_terminus = hiera
> vardir = /var/lib/puppet
> hostcrl = /var/lib/puppet/ssl/crl.pem
> http_keepalive_timeout = 4
> hostcsr = /var/lib/puppet/ssl/csr_centos66-pm.localhost.pem
> inventory_terminus = yaml
> name = master
> certdir = /var/lib/puppet/ssl/certs
> filetimeout = 15
> splaylimit = 1800
> agent_catalog_run_lockfile = 
> /var/lib/puppet/state/agent_catalog_run.lock
> classfile = /var/lib/puppet/state/classes.txt
> lastrunreport = /var/lib/puppet/state/last_run_report.yaml
> clientbucketdir = /var/lib/puppet/clientbucket
> ca_server = puppet
> graphdir = /var/lib/puppet/state/graphs
> report_server = puppet
> waitforcert = 120
> statefile = /var/lib/puppet/state/state.yaml
> inventory_server = puppet
> puppetdlog = /var/log/puppet/puppetd.log
> client_datadir = /var/lib/puppet/client_data
> lastrunfile = /var/lib/puppet/state/last_run_summary.yaml
> agent_disabled_lockfile = /var/lib/puppet/state/agent_disabled.lock
> runinterval = 1800
> resourcefile = /var/lib/puppet/state/resources.txt
> node_name_value = centos66-pm.localhost
> configtimeout = 120
> ca_port = 8140
> localconfig = /var/lib/puppet/state/localconfig
> report_port = 8140
> clientyamldir = /var/lib/puppet/client_yaml
> inventory_port = 8140
> reportdir = /var/lib/puppet/reports
> storeconfigs_backend = active_record
> bucketdir = /var/lib/puppet/bucket
> fileserverconfig = /etc/puppet/fileserver.conf
> yamldir = /var/lib/puppet/yaml
> #masterlog = /var/log/puppet/puppetmaster.log
> default_manifest = /etc/puppet/manifests/site.pp
> disable_per_environment_manifest = false
> #modulepath = /etc/puppet/modules:/usr/share/puppet/modules
> rest_authconfig = /etc/puppet/auth.conf
> basemodulepath = /etc/puppet/modules:/usr/share/puppet/modules
> server_datadir = /var/lib/puppet/server_data
> masterhttplog = /var/log/puppet/masterhttp.log
> #manifestdir = /etc/puppet/manifests
> pidfile = /var/run/puppet/master.pid
> config = /etc/puppet/puppet.conf
> autosign = /etc/puppet/autosign.conf
> cert_inventory = /var/lib/puppet/ssl/ca/inventory.txt
> csrdir = /var/lib/puppet/ssl/ca/requests
> ca_name = Puppet CA: centos66-pm.localhost
> capass = /var/lib/puppet/ssl/ca/private/ca.pass
> cacert = /var/lib/puppet/ssl/ca/ca_crt.pem
> ca_ttl = 15768
> capub = /var/lib/puppet/ssl/ca/ca_pub.pem
> caprivatedir = /var/lib/puppet/ssl/ca/private
> serial = /var/lib/puppet/ssl/ca/serial
> signeddir = /var/lib/puppet/ssl/ca/signed
> cadir = /var/lib/puppet/ssl/ca
> cakey = /var/lib/puppet/ssl/ca/ca_k

[Puppet Users] Re: how to install multiple packages from the list

[Alex Harvey]

I would suggest taking a step back - why do you have a requirement to read 
the list of packages from a file?

On Friday, March 13, 2015 at 10:15:07 PM UTC+11, Alex Miroshnik wrote:
>
> Hi Guys, 
>
> I need to install multiple packages on the Ubuntu 14.0.4 using puppet. All 
> packages are listed in the file (about 100 packages) one package name on 
> the row. Is this possible? If it is possible, could you please give me a 
> hint how to do this.
> I know  I can specify the array of the packages:
>
> $pkg_list = [ "pkg1", "pkg2", "pkg3" ]
> package { $pkg_list: ensure => "installed" }
>
> but this is not my case as I have quite a few packages in the list.
>
> Thank you in advance!
>

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

[Puppet Users] Re: Java Client to access Puppet Node Classifier API

[Alex Harvey]

The node classifier API is documented here:
https://docs.puppetlabs.com/pe/latest/nc_index.html

As far as how you would write this in Java, well that's a Java programming 
question and you'll probably need a Java forum to find help with that.

On Friday, March 13, 2015 at 5:43:16 AM UTC+11, Kiran wrote:
>
> Hi All,
>
> I am new to this group. I would like to call Puppet Node Classifier Rest 
> API from Java client. I couldn't find any document. Can someone please 
> provide steps or document.
>
> I want to perform following tasks using java client.
>
> Adding a class to a node group
> Adding a child group
> Deleting a node group
> etc...
>
> Thanks in advance.
>
> Regards
> Kiran
>

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

[Puppet Users] Re: Puppet as patch management

[Alex Harvey]

While it's possible to do stuff like this in Puppet, it's not really 
configuration management that you're doing here; it's systems 
administration.  If your requirement is to have patches installed 
automatically, I would write this as a 10 line shell script, and have 
Puppet just take care of installing the script as a cron task.

On Friday, March 13, 2015 at 5:45:16 AM UTC+11, Brian Morris wrote:
>
> I don't have enough nodes to justify running my own patch repository, but 
> here is the manifest I use for patching our Debian-derived systems. First, 
> though, here is the facter called "updates_already_running"
>
> Facter.add(:updates_already_running) do
>  confine :osfamily => "Debian"
>  setcode do
>  if Facter::Util::Resolution.exec("ps aux | grep 'dpkg\|apt-get' | grep 
> -v grep")
>  "yes"
>  end
>  end
> end
>
> And, here is the manifest:
>
> class system_updates { 
>  # ==Purpose
>  # This class is used for running system updates on all Linux assets.
>  #
>  # ==Actions
>  # * Compiles a list of available updates
>  # * Ensures that any pending package problems are resolved
>  # * Applies all available updates
>  # * Automatically cleans up any packages that are no longer needed
>  # * Empties genericadmin's mailbox
>
>  # * Reboots the system if any updates require it
>  #
>  #
>  if ( $::updates_already_running ) {
>  }
>  else {
>  
>  Exec["lock_prep"] -> Exec["apt_prep"] -> Exec["apt_update"] ->  Exec[
> "apt_fix"] -> Exec["apt_upgrade"] -> Exec["apt_remove"] ->  Exec[
> "empty_mailbox"] -> Exec["reboot"]
>  #
>  #
>  exec { "lock_prep":
>   command   => "rm -f /var/lib/dpkg/lock ; rm -f 
> /var/lib/apt/lists/lock ; rm -f /var/cache/apt/archives/lock",
> }
>  exec { "apt_prep":
>   command   => "rm -rf /var/lib/apt/lists/* ; mkdir 
> /var/lib/apt/lists/partial",
>  }
>  exec { "apt_update":
>  command => "apt-get update",
>  }
>  exec { "apt_fix":
>  command => "apt-get -f install",
>  }
>  exec { "apt_upgrade":
>  command => "apt-get -o Dpkg::Options::=\"--force-confdef\" -o 
> Dpkg::Options::=\"--force-confold\" -y --force-yes dist-upgrade",
>  }
>  exec { "apt_remove":
>  command => "apt-get -y autoremove",
>  }
>  exec { "empty_mailbox":
>  command   => 'echo "" > /home/genericadmin/mbox',
>  onlyif=> "test -f /home/genericadmin/mbox",
>  }
>  exec { "reboot":
>  command => "reboot",
>  onlyif => "test -f /var/run/reboot-required",
>  }
>  }
> }
>
> I hope this helps you.
>
> Brian
>

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

[Puppet Users] Re: Puppet as patch management

[Alex Harvey]

While it's possible to do stuff like this in Puppet, this isn't really 
configuration management you're doing; it's systems administration.  If 
your requirement is to have patches installed automatically, I would write 
a 10 line shell script, and use puppet to install it as a cron job.

On Wednesday, March 11, 2015 at 10:37:26 PM UTC+11, Alfredo De Luca wrote:
>
> Hi all. 
> I am configuring Puppet in our environment for configuration 
> management. Also I am using Hiera and it's so great so far. 
> Now managers are asking if we can use it as patch mgmt tool. I said 
> Puppet it's not but it can help with patch/pkg distribution which I 
> think it could be very good. 
> Do you agree on that? 
> Any more info/thoughts would be appreciated. 
>
> Regards 
>
>
> -- 
> Alfredo 
>

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

[Puppet Users] Re: Puppet as patch management

[Alex Harvey]

I don't recommend using Puppet for anything to do with patching, even in 
the distribution of the patches.  (Actually, I'm not sure how Puppet would 
be used to distribute patches even in principle.)  Anyhow, sooner or later 
you're going to want a tool that was actually designed for patch and 
package management so you'd to save yourself expensive rework, I'd just do 
it at the outset.  You may find that something like MCollective is useful 
if you need a way to, say, run yum update on a lot of boxes all at once, 
but that's about it.

On Wednesday, March 11, 2015 at 10:37:26 PM UTC+11, Alfredo De Luca wrote:
>
> Hi all. 
> I am configuring Puppet in our environment for configuration 
> management. Also I am using Hiera and it's so great so far. 
> Now managers are asking if we can use it as patch mgmt tool. I said 
> Puppet it's not but it can help with patch/pkg distribution which I 
> think it could be very good. 
> Do you agree on that? 
> Any more info/thoughts would be appreciated. 
>
> Regards 
>
>
> -- 
> Alfredo 
>

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

[Puppet Users] Error handling in base class in cloud solutions

[Alex Harvey]

Hi all

I'm after some feedback on best practices with regards to error handling.

I have two questions:

Question #1.   Most puppet cloud solutions typically a base class that 
configures services common to all nodes like the resolver, Nagios, LDAP, 
etc.  These classes all depend on the existence of external services to 
function (i.e. a DNS server; a DHCP server; a Nagios server; an LDAP 
server; and a Logstash system).  Without these services, puppet is expected 
to fail as it applies the said base class.

Now imagine there's a role that builds a front end web server that applies 
a profile that includes the base class.

If we try to apply that class in a vagrant environment it fails, unless:

1)  Our vagrant model environment itself firstly provides a DNS, Nagios, 
LDAP server - I imagine no one actually does this because no one would have 
a development laptop with sufficient grunt to spin up all these services 
simultaneously, and not to mention the time it would take to spin them all 
up.
2)  We could set up an external dedicated Puppet development environment 
whose only purpose is to support developers testing Puppet code - this will 
incur an additional ongoing cost to the project, and create a system that 
needs to be maintained probably without resources to actually maintain it.
3)  We could allow vagrant instances to be serviced by an actual 
development environment used by the application developers - this creates a 
management burden - our PuppetDB, Nagios system; LDAP system etc is going 
to be continually polluted with junk data relating to these short-lived 
development VMs - this feels quite wrong to me.
4)  We add conditional logic into the Puppet code - "unless I am a vagrant 
box, apply the firewall, DNS, DHCP, LDAP & logstash classes" - although I 
dislike conditional logic, this is the solution I'm leaning towards.

Or something else?

Question #2.  How do people normally handle the absence of these 
services at the beginning of the project, before any of the above-mentioned 
external services even exist?

We could:

1)  Just let the code fail if the services aren't available - very ugly.
2)  Comment out services like DNS, Nagios etc in the base class until 
they've been built - almost as ugly.
3)  Handle the service failures in the code - trouble is, you can't really 
tell Puppet not to, say, apply the Nagios class if Nagios server can't be 
contacted.

Hopefully there's a better way. :)

TIA,
Alex

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

Re: [Puppet Users] dynamic hiera_config setting

[Alex Harvey]

On Wednesday, June 18, 2014 10:47:20 AM UTC+10, Alex Harvey wrote:
>
>
> I am also encountering this issue (puppet 3.3.1) - is it still a known 
> issue?
>

Ignore - I found the open Jira ticket here
https://tickets.puppetlabs.com/browse/HI-46 

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

Re: [Puppet Users] dynamic hiera_config setting

[Alex Harvey]

On Wednesday, August 14, 2013 12:57:17 PM UTC+10, Henrik Lindberg wrote:

> I was hoping that it would derive the hiera.yaml path dynamically from 
> > the clients' environment when it checks in, but this seems not to be the 
> > case. 
> > 
> That is correct, it does not do that. 
> - henrik 
>

I am also encountering this issue (puppet 3.3.1) - is it still a known 
issue?

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

Re: [Puppet Users] Hiera, version control & encrypted backends

[Alex Harvey]

I was thinking about a situation like this -

*) Puppet designer decides to place all credentials in a single database 
(encrypted Hiera).
*) developers clone the version controlled copy of it all over the place, 
e.g. to their laptops, that random box that everyone logs into.
*) version controlled copy then potentially sits next to copies of the keys 
used to decipher it.
*) some lazy developer decides not to use a passphrase in his key.
*) laptop then gets hacked, lost or stolen, etc.

Perhaps I'm being paranoid?


On Monday, April 14, 2014 2:17:36 AM UTC+10, Matthew Kennedy wrote:
>
> We use hiera-eyaml... This let's us selectively encrypt keys (passwords) 
> and let everything else remain plaintext. 
>
> We use git and have very little concern as long as we keep our private key 
> secure. 
>
> We also publish our public key so others can encrypt sensitive data 
> themselves. Because we have several teams that have ownership over various 
> pieces of sensitive information this makes managing secrets 'easy'. 
> On Apr 13, 2014 4:05 AM, "Alex Harvey" > 
> wrote:
>
>> Hi all,
>>
>> I'm pondering a design problem and would appreciate some advice:
>>
>> A reason for externalising data in Hiera is often said to be so that 
>> configuration data can be stored in a version control system, e.g.
>> http://puppetlabs.com/blog/first-look-installing-and-using-hiera
>>
>> Meanwhile, the reason for using an encrypted Hiera backend is so that 
>> sensitive configuration data can be stored in Hiera, e.g.
>>
>> http://www.craigdunn.org/2011/10/secret-variables-in-puppet-with-hiera-and-gpg/
>>
>> Thus, there is a catch: if data is too sensitive to be stored in an 
>> unencrypted Hiera backend, it is probably too sensitive to be stored in a 
>> version control system like git.
>>
>> I've seen people out there have considered encrypted version control 
>> systems, others have said sensitive configuration data shouldn't be stored 
>> at all, and so on - I can't find much discussion of the problem itself 
>> though.
>>
>> After thinking about it for a while, the best I could come up with was 
>> supposing there ought to be a way of partially encrypting the Hiera 
>> backend, and perhaps dealing with it using a separate level in the 
>> hierarchy.
>>
>> I note the Raziel project along these lines by Jens Bräuer:
>> https://github.com/jbraeuer/raziel/
>> http://bit.ly/raziel-slides 
>>
>> Is this more of an open problem or has the community come up with a best 
>> practice recommendation here?
>>
>> Kind regards,
>> Alex
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/c13c06e9-8370-4dea-8210-13774da934ae%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/c13c06e9-8370-4dea-8210-13774da934ae%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[Puppet Users] Hiera, version control & encrypted backends

[Alex Harvey]

Hi all,

I'm pondering a design problem and would appreciate some advice:

A reason for externalising data in Hiera is often said to be so that 
configuration data can be stored in a version control system, e.g.
http://puppetlabs.com/blog/first-look-installing-and-using-hiera

Meanwhile, the reason for using an encrypted Hiera backend is so that 
sensitive configuration data can be stored in Hiera, e.g.
http://www.craigdunn.org/2011/10/secret-variables-in-puppet-with-hiera-and-gpg/

Thus, there is a catch: if data is too sensitive to be stored in an 
unencrypted Hiera backend, it is probably too sensitive to be stored in a 
version control system like git.

I've seen people out there have considered encrypted version control 
systems, others have said sensitive configuration data shouldn't be stored 
at all, and so on - I can't find much discussion of the problem itself 
though.

After thinking about it for a while, the best I could come up with was 
supposing there ought to be a way of partially encrypting the Hiera 
backend, and perhaps dealing with it using a separate level in the 
hierarchy.

I note the Raziel project along these lines by Jens Bräuer:
https://github.com/jbraeuer/raziel/
http://bit.ly/raziel-slides 

Is this more of an open problem or has the community come up with a best 
practice recommendation here?

Kind regards,
Alex

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

[Puppet Users] Benefits of retrofitting Puppet to a legacy fleet

[Alex Harvey]

Hi all,

I am going to have a meeting to sell the idea of retrofitting Puppet to a 
fleet of already-built legacy Unix systems to a skeptical management (as 
opposed to only using it to build new linux systems, where I don't need to 
sell the idea).

Here, "legacy Unix" means AIX, Solaris, HP-UX, and various versions of 
Linux.  Much of the work is already done as far as deployment to these 
platforms is concerned, so the difficulty of compiling Ruby, etc, on 
Platform X version Y doesn't need to be considered.

I see the following benefits:

1)  Having facter on every computer in the company is good.
2)  Having MCollective replace your for loops everywhere is good.
3)  Being able to standardise configuration of some simple services, e.g. 
NTP, root's profile, etc., is better than not having standardised these 
services.
4)  Any services that you can migrate into Puppet become visible in Puppet 
manifests, which is always better than documentation in a Wiki, which may 
or may not be up to date.

Being more ambitious, I am thinking that with MCollective, it might be 
possible to use Puppet to install patches etc. on legacy systems.  Maybe 
even possible, with a lot of effort, to fully automate the patching of 
everything, and have the change management system automatically updated as 
well.

Any/all ideas/criticisms are appreciated.  I have one week to write the 
proposal.

Thanks in advance.
Alex

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

Re: [Puppet Users] Puppet, git & security

[Alex Harvey]

On Friday, May 17, 2013 12:35:24 AM UTC+10, Martin Langhoff wrote:
>
> On Wed, May 15, 2013 at 2:44 AM, Stephen Gran 
> > wrote: 
> > Your push server can run git update and then rsync to the masters. 
>
> Why rsync if you have git? 
>

Martin, John, thanks for your feedback - it's very helpful.

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

Re: [Puppet Users] Puppet, git & security

[Alex Harvey]

On Thursday, May 16, 2013 12:48:22 AM UTC+10, jcbollinger wrote:
>
>
> If you want your masters to rely on a revision control system for 
> manifests, data, or whatever, then it follows that the masters must be 
> permitted to access that system.  If they may not do so across network 
> segments, then it follows that the repository must be hosted on the same 
> segment as the masters.  It also follows that if the masters are on 
> different segments then you need some kind of cross-segment replication of 
> the revision-control repository.
>
> Furthermore, git is probably not the best choice of revision-control 
> system for what I think you're asking.  As I understand git operation 
> (which is imperfectly), you could certainly push changes to a remote 
> repository, but you would also need to pull from the repository side before 
> those changes would be available to other clients (such as the masters).  
> This is different from the more traditional approach of systems such as 
> Subversion.
>
> As far as how easy it is to manage your Puppet infrastructure, I don't 
> think I understand how you're partitioning subsystems.  I would account 
> everything you're talking about as part of managing Puppet, and clearly, 
> operating under the constraints you describe is harder than operating 
> without them.  On the other hand, if you postulate that the problem of 
> getting the needed code and data into an accessible repository is solved 
> and out of scope, then why would you suppose there would be any difference 
> between managing Puppet in your environment and managing it in a 
> less-constrained one?
>

John, thanks for your comments.

I was actually thinking of doing something similar to what Stephen Gran 
suggested above; let rsync can take care of ensuring that all puppet 
masters always have the same copy of the same code tree.  So in that 
situation there is no need for the puppet masters to have access to the 
revision control system.  Indeed, I am not even sure that this 
configuration will be any more troublesome than having the puppet masters 
contact the git repositories using git pulls.

What do you think?

>

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

Re: [Puppet Users] Puppet, git & security

[Alex Harvey]

On Wednesday, May 15, 2013 2:51:14 PM UTC+10, yersinia.spiros wrote:
>
> Sorry for the top posting. 
>
> Imho, i think this is a question that could be asked on the git mailing 
> list. 
>

Sorry, my question apparently isn't clear enough - this definitely isn't a 
git question that can be answered at the git mailing list.  I am interested 
in both how you might configure a push-only solution from revision control 
system to puppet masters, but more importantly, can Puppet be just as easy 
to manage if I do this?

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

Re: [Puppet Users] Puppet, git & security

[Alex Harvey]

On Wednesday, May 15, 2013 3:40:28 PM UTC+10, denmat wrote:
>
> I haven't worked out a pure git way but Jenkins, git export, rsync are a 
> good solid combo :) 
>

Do you know of any documentation or blog posts from others using a 
configuration like this?  My initial thinking was to use rsync but I am 
concerned about getting bitten by Puppet manageability or scalability 
issues down the track that I haven't thought of.  Thus my interest in the 
experiences of others who may have a push-only relationship between their 
revision control systems and the puppet masters.

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

[Puppet Users] Puppet, git & security

[Alex Harvey]

Hi all,

In my company we have a security policy that frowns upon things like puppet 
masters making git pull requests to other network segments.  Allowing code 
to be pushed into these segments is less of a problem.

This policy makes it difficult to do stuff like,
https://puppetlabs.com/blog/git-workflow-and-puppet-environments/

I am wondering if anyone out there has ever faced a similar problem and has 
worked out a way to build a push-only configuration from GIT code 
repositories to puppet masters.

Best regards,
Alex

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

Re: [Puppet Users] Apache module

[Alex Harvey]

On Wednesday, January 30, 2013 7:16:32 AM UTC+11, ashely wrote:

I suspect you are correct about in house apache modules.  I also found 
> the various apache modules on forge or elsewhere did not accomodate our 
> site's needs.  It is a tough problem. 
>
> We ended up building 2 apache modules.  the first handles our messy 
> "inherited" web site configs.  I opted to keep the httpd.conf static and 
> place all the messy stuff into vhost.conf files.  These get managed 
> either by template or static file depending on complexity.  This is less 
> than ideal and very site dependant.  We are up to 90+ vhost templates, 
> one per url. 
>
> In the second version I tried to be more general.  I wanted a way for 
> any given application which needs web frontend to generate a vhost 
> config within it's own module without having to directly include an 
> apache class.  In the node def I can then include many such webapp 
> classes in any combination.  I then include my apache class which 
> serves any vhosts configs it finds in /etc/apache/vhost.d or whatever. 
> I am using exported resourses for the vhost configs, but I probably 
> don't need to. 
>
> In both versions I keep the httpd.conf static, and put the apache config 
> complexity into the vhost configs.   
>

Thanks Ashley for your thoughts.  I suspect this is what I'll do too.

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

[Puppet Users] Apache module

[Alex Harvey]

Hi all,

I've spent a bit of time today investigating whether or not I can use the 
Puppet Labs Apache module -
https://forge.puppetlabs.com/puppetlabs/apache

I've noted this helpful blog post -
http://blog.akquinet.de/2011/11/23/managing-an-apache-server-with-puppet/

However after examining the Apache configuration I've inherited it seems to 
me that the publicly available module exposes only a fraction of the Apache 
options in the manifests.

E.g. I have inherited several hundred RewriteRules along with RewriteConds, 
and all that ugliness, non standards paths to files, non standard values 
passed to prefork and and worker MPM, and so on.  

In general, looking in templates/httpd.conf.erb file, though, it appears to 
me that the vast majority of Apache's configuration options can't be 
controlled by puppet if you use the Apache module.  Rather they're 
hardcoded in this file.

This leads me to suspect that most sites must be using Apache modules that 
were entirely developed in house?  Or have most sites just decided that 
most of Apache's options shouldn't ever be changed from these default 
settings?  Or is there a better Apache module I should look at?  Or should 
I take the initiative and feedback lots and lots of changes to the module?

Thanks in advance for feedback.

Kind regards,
Alex Harvey

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

Re: [Puppet Users] Puppet 3.0 fails install on Solaris 10 w/ ruby 1.8.7

[Alex Harvey]

On Thursday, December 20, 2012 4:49:33 AM UTC+11, Philip Brown wrote:
>
>
> That being said, since puppet IS ruby code, "a large component of 'right'" 
> could reasonably be defined as "there should be a functional ruby gem for 
> it"!
>

And if that doesn't work for you there are two other considerations -

- some people need to maintain their own patches for facter & puppet.  At 
this point puppet labs has accepted all of my patches upstream but sooner 
or later I expect to encounter a situation where I need to maintain patches 
of my own.

- having a single package manager for the puppet stack means when I want to 
see my installed puppet version I only need to know one command - gem 
list.  So it's easier than having to know the commands for six package 
managers.  And my installed puppet code is always in 
/usr/local/lib/ruby/gems/1.8/gems no matter what platform I'm on.  

Now the best solution would be for every Unix to just standardise on a 
single package management system.  Debian's one is quite good.  Now, 
there's an ideal world for you. :)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/isVupjCkblgJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet 3.0 fails install on Solaris 10 w/ ruby 1.8.7

[Alex Harvey]

On Tuesday, December 18, 2012 2:02:28 AM UTC+11, jcbollinger wrote:
>
>
> The requirement for a local C compiler is pretty much a function of the 
> choice to use gems in general.  In principle, any gem may contain a native 
> extension that needs to be built, so gem-dependent systems need to have the 
> requisite development tools.
>
> I avoid 'gem' on principle, relying instead on hosts' native package 
> managers.  It is a bad idea to mix multiple package managers with 
> overlapping areas of responsibility, and on systems that have a system-wide 
> package manager, that precludes using any other.
>

Gems are convenient at sites where many different native package managers 
are in use.  A site that has RedHat, Ubuntu, Solaris 10, Solaris 11, AIX & 
HP-UX will have six different native package managers to work with and 
rolling puppet, hiera & facter into all of these formats is time consuming 
compared to using gems.

Since it appears the intention was to allow hiera to depend on either json 
or json_pure (which unfortunately appears to be impossible in a gemspec 
file) I have raised a bug against hiera -
http://projects.puppetlabs.com/issues/18214

Hopefully we can change this dependency as it effectively makes it 
impossible to install puppet as a gem.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/hLt-301VlT4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Puppet 3.0 fails install on Solaris 10 w/ ruby 1.8.7

[Alex Harvey]

On Tuesday, October 2, 2012 9:28:09 AM UTC+10, Matthaus Litteken wrote:
>
> The puppet 3 gem requires hiera, whose latest version requires json, 
> which can be either json (a c extension), or json_pure (a ruby 
> implementation). If it is the c extension, make and gcc are required 
> to build the c components. The mkmf error usually indicates that make 
> and/or gcc are unavailable. 
>

I am also encountering this issue but using json_pure doesn't help -

# gem install --local json_pure-1.7.5.gem hiera-1.1.1.gem puppet-3.0.1.gem
Successfully installed json_pure-1.7.5
ERROR:  While executing gem ... (Gem::DependencyError)
Unable to resolve dependencies: hiera requires json (>= 0)

Meanwhile, a requirement for there to be a C compiler on every host seems 
to be insane.


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/pnu5ltSxORkJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Solaris processor count facts - bug or feature?

[Alex Harvey]

On Friday, December 7, 2012 9:05:32 PM UTC+11, Andrew Beresford wrote:
>
> How about creating a processorcorecount and processorthreadcount with 
> "correct" meanings? That then leaves the option to deprecate 
> processorcount. 
>
> I've realised that at some point in the past I have created a 
> processorthreadcount fact because I needed a consistent source of this 
> information on both Solaris and Linux. 
>

I'm not sure - certainly I'd agree those would be good names for the facts 
if we were starting again (and should the 'processorX' facts be renamed as 
well)?  I think for the moment I'm just going to implement the HP-UX facts 
to work the same way as the linux facts and create a thread on the puppet 
developers list to see what others think should be done about this cores vs 
threads connundrum.  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/xUqTLQbfJwUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Ruby for HP-UX 11.00

[Alex Harvey]

Hi all,

I have been trying to compile Ruby on HP-UX 11.00 but there are too many 
dependencies and no publicly available packages for these on such an old 
operating system and I'm forced to give up.  As a last resort - and it's a 
long shot indeed! - I am wondering if anyone out there has managed to 
compile ruby for HP-UX 11.00 and if so would they be willing to share their 
packages with me?

Best regards,
Alex

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/lbXWT2-Y2qEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Solaris processor count facts - bug or feature?

[Alex Harvey]

> I prefer the core count definition, but whatever it is, it should be 
> consistent between Linux and Solaris. 
>

Yes it certainly should be the same on all platforms - the question is if 
we change it who is going to be impacted and how can we manage the change?  
I believe the vast majority of Puppet users run linux so probably the 
Solaris code needs to be changed to conform to the linux rather than vice 
versa.  Unless lots of people think the linux fact is in fact the one 
that's 'wrong'?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/zZSTUqGrMRAJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] compiling ruby on HP-UX / PA-RISC

[Alex Harvey]

It turns out static linking didn't work either but for the benefit of 
people reading this in the archives I found a workaround -

There is some documentation of HP-UX PA-RISC compiler here 
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801?ciid=4727276391695110VgnVCM10275d6e10RCRD
 

(There's probably a better one somewhere but that's the one I used.)

The +b option is used by the linker to embed a library path list in the 
executable for use at run time. However, if passing these options via CC or 
GCC then the option should be -Wl,+b. The mkmf.log file showed, however, 
that an unknown option +b was being passed directly to gcc.  I found this 
was coming from configuration in 
/usr/local/lib/ruby/1.8/hppa2.0w-hpux11.11/rbconfig.rb.

After running configure I made the following change in config.status - 

mv config.status config.status.orig 
sed -e 's/^.*RPATHFLAG.*$/S["RPATHFLAG"]=" -Wl,+b%1$-s"/' 
config.status.orig >config.status 
chmod +x config.status 
./config.status 

This resulted in /usr/local/lib/ruby/1.8/hppa2.0w-hpux11.11/rbconfig.rb 
having 

# grep RPATHFLAG /usr/local/lib/ruby/1.8/hppa2.0w-hpux11.11/rbconfig.rb 
CONFIG["RPATHFLAG"] = " -Wl,+b%1$-s" 

which is what I wanted.

However, the make step still didn't run properly because -Wl,+b was now 
passed to ld, which is also wrong. 

Thus after the make step finished I made another change - 

cd ext/zlib 
mv Makefile Makefile.orig 
sed -e 's#^LIBPATH.*$#LIBPATH = -L. -L$(topdir) -L/usr/local/lib 
+b/usr/local/lib#' Makefile.orig >Makefile 
make 

That works fine. 

Then cd ../.. && make install and the zlib extension was installed. 

I also updated the redmine ticket https://bugs.ruby-lang.org/issues/7279

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/ShJkD1LgbvYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Solaris processor count facts - bug or feature?

[Alex Harvey]

On Monday, December 3, 2012 9:54:49 PM UTC+11, Andrew Beresford wrote:
>
> Feature :)

 
I do understand what the code is doing but question whether that's what it 
should be doing.  While it's ultimately a matter of opinion, it violates 
the 'principle of least surprise' for me and also my Solaris colleagues.

At any rate, I finally managed to find a multi-core linux box I could try 
this on and have confirmed that the associated linux facts behave in the 
way I would have expected them to on Solaris -

physicalprocessorcount => 1
processor0 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor1 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor2 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor3 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor4 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor5 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor6 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processor7 => Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
processorcount => 8

This is a 4-core CPU with 8 threads.  

See the spec for the i7-2600
http://ark.intel.com/products/52213

So I do think the Solaris behaviour is in error.

Maybe we need a 'processorcorecount' fact instead?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/oCN9JSsfcsgJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Solaris processor count facts - bug or feature?

[Alex Harvey]

On Tuesday, November 20, 2012 12:02:21 PM UTC+11, Alex Harvey wrote:
>
> Hi all,
>
> This relates to a discussion we are having in the Redmine ticket 
> https://projects.puppetlabs.com/issues/11612.
>
> I am extending the processorcount, physicalprocessorcount and processorX 
> facts that exist for Linux and Solaris.
>
> I personally find the behaviour of the processor facts on Solaris 
> surprising -
>
> myhost# facter |grep proc
> physicalprocessorcount => 1
> processor0 => SPARC64-VII
> processor1 => SPARC64-VII
> processor2 => SPARC64-VII
> processor3 => SPARC64-VII
> processor4 => SPARC64-VII
> processor5 => SPARC64-VII
> processor6 => SPARC64-VII
> processor7 => SPARC64-VII
> processorcount => 4
>
>
> We can see that physicalprocessorcount is returning the number of physical 
> CPUs which is good, the processorX array is getting populated with virtual 
> CPUs, and processorcount is returning the number of cores.  The command 
> used to set processorcount is essentially kstat cpu_info |grep core_id 
> |sort -u.
>
> However, I suspect Solaris sysadmins are more familiar with using commands 
> like psrinfo, prtdiag, and mpstat to get CPU count, and these all report 
> the number of CPUs as 8 rather than 4.
>
> If I was writing this from scratch I would have a fact called something 
> like ProcessorCoreCount and have that report 4 and then a separate fact 
> ProcessorCount that would report 8 - as psrinfo is doing.
>
> Therefore I am interested to know if others out there regard this 
> behaviour as a 'bug or feature', and also get some feedback on how people 
> are using these facts out there.
>

There were no responses here - I'd like to bump this up for a second go at 
getting some responses.  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/tD9YuRt9PWcJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Solaris processor count facts - bug or feature?

[Alex Harvey]

Hi all,

This relates to a discussion we are having in the Redmine ticket 
https://projects.puppetlabs.com/issues/11612.

I am extending the processorcount, physicalprocessorcount and processorX 
facts that exist for Linux and Solaris.

I personally find the behaviour of the processor facts on Solaris 
surprising -

myhost# facter |grep proc
physicalprocessorcount => 1
processor0 => SPARC64-VII
processor1 => SPARC64-VII
processor2 => SPARC64-VII
processor3 => SPARC64-VII
processor4 => SPARC64-VII
processor5 => SPARC64-VII
processor6 => SPARC64-VII
processor7 => SPARC64-VII
processorcount => 4


We can see that physicalprocessorcount is returning the number of physical 
CPUs which is good, the processorX array is getting populated with virtual 
CPUs, and processorcount is returning the number of cores.  The command 
used to set processorcount is essentially kstat cpu_info |grep core_id 
|sort -u.

However, I suspect Solaris sysadmins are more familiar with using commands 
like psrinfo, prtdiag, and mpstat to get CPU count, and these all report 
the number of CPUs as 8 rather than 4.

If I was writing this from scratch I would have a fact called something 
like ProcessorCoreCount and have that report 4 and then a separate fact 
ProcessorCount that would report 8 - as psrinfo is doing.

Therefore I am interested to know if others out there regard this behaviour 
as a 'bug or feature', and also get some feedback on how people are using 
these facts out there.

Thanks in advance.

Best regards,
Alex Harvey

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/WlRmUVNCey4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] compiling ruby on HP-UX / PA-RISC

[Alex Harvey]

On Monday, November 5, 2012 4:27:54 PM UTC+11, Michael Stanhke wrote:
>
>
> 1.  You may need to file a bug with ruby-lang.org 
> 2.  Would static linking help at all with being maintainable? 
>
> Thanks Michael.  Actually static linking should be fine - I didn't think 
of it.  I also raised a bug as you suggested, 
https://bugs.ruby-lang.org/issues/7279.  I'll see how it goes.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/bIVrG6etHBMJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] compiling ruby on HP-UX / PA-RISC

[Alex Harvey]

Hi all,

Not sure if anyone out there would be using HP-UX on PA-RISC but just in 
case we've run into a real brick wall on this one.

We are apparently encountering exactly the same issue as this person did -
http://www.ruby-forum.com/topic/191987

We can get around the issue using the same workaround mentioned in the 
above thread but it's not really a maintainable solution.

Does anyone have any further ideas of what could be stopping us from 
compiling?  

We're trying to compile ruby 1.8.7p352 on HP-UX 11.11 PA-RISC.

Best regards,
Alex Harvey

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/_gb66_Nv3ukJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] multiple puppet masters on multiple subnets

[Alex Harvey]

Thanks guys, I really appreciate the responses here.  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/xGWoov-8j58J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] multiple puppet masters on multiple subnets

[Alex Harvey]

On Thursday, September 27, 2012 9:13:32 AM UTC+10, Pete wrote:
>
> Another option would be to put all your puppet code into a git repo 
> and setup each master to pull from a central repo over ssh. 
> That _Should_ be secure enough. 
>
> I am also curious why you need this sort of setup. 
> Is it for PCI compliance or something similar? 
>

Yeah, that's my plan B.

As I mentioned I am working in a large organisation and the security people 
have a lot of power.  A Puppet Master can in principle do a lot of damage 
because you are effectively "root everywhere at once".  So it's simply 
unlikely that our security people are going to let a single Puppet Master 
be in control of all these subnets, and the point where it is going to get 
rejected is if I ask for every host on subnet A to be allowed to talk to 
the Puppet Master that lives on subnet Z.  Whether this is a good or bad 
security policy could be debated but it's not up to me.

An alternative is to have a central repo server as suggested here.  I could 
have independent Puppet Masters on all the subnets and that would probably 
satisfy the security requirement.  The trouble is I would then lose the 
ability to have a global view of everything.  Thus, if I wanted, say, a 
report of all hosts I manage with a special configuration of some service, 
I'll have to log into all the Puppet Masters individually to get this 
information - or write a script to somehow extract it from the git repo.  
So I will have lost one of the key benefits of Puppet.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/huzW1IAfegEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] multiple puppet masters on multiple subnets

[Alex Harvey]

Hi all,

I am interested to hear from anyone who might have deployed Puppet in a
large organisation with a lot of subnets firewalled off from each other.

I am considering to have, if possible, a 'master' Puppet Master controlling
'client' Puppet Masters that live on the firewalled subnets.  I would like
to allow the client Puppet Masters communicate with the master Puppet
Master only for the purpose of obtaining their manifests for the local
subnet.  The Master Puppet Master in turn would talk to a single git/code
server.  Then of course all the Puppet clients on each subnet would only
know about the local Puppet Masters.

Has anyone done this before or have any advice on whether or not this is a
good idea?

Best wishes,
Alex Harvey

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

Re: [Puppet Users] Puppet / scalability

[Alex Harvey]

On 15 May 2012 22:10, Steve Traylen  wrote:

>
>   We are currently along way from that with a single master and around 200
> nodes
>   while we learn puppet and migrate away from quattor.
>   The 300k figures are a couple of years away, we will have a respectable
> figure
>   sometime this year we would hope.
>
> Steve (CERN IT)
>

I have had a careful look at
http://projects.puppetlabs.com/projects/1/wiki/Whos_Using_Puppet

This list is, in fairness, consistent with what the CFEngine rep told me.
If there are sites out there with >3K or even >10K nodes, but not listed at
Puppet's website, it is reasonable to suppose that the CFEngine rep doesn't
know about them. :)

Is it possible that this list needs updating?  Maybe large sites aren't as
keen to share their stories with the world?

>From the list, I also get the feeling that sites using Puppet to manage
their infrastructure tend to be Linux sites.  Google appears to be using
Puppet to manage "all recent Mac OS X and Linux desktops, laptops, servers
in the corporate infrastructure".  They don't use it "in production",
whatever that means.  For those taking it beyond Linux and Mac OS X, I see
Solaris mentioned a bit.  Are Sun/Oracle still using it for their Solaris
kit?  I don't see any mention of AIX at all.  I believe I have heard the
same rumour of the large company at 10K nodes that uses Solaris, AIX and
Linux.

So, I am no longer doubting that Puppet can scale to a site as large as
ours - especially given what James Turnbull wrote above - but I'd like to
ensure that I get my facts right.

Is it possible that the large ~ 10K site is one of the first of its kind in
the world - especially to use it for AIX?  What about the 30K site?  A
CFEngine document I downloaded claims, "Puppet has recently retracted
claims of running 35000 servers at a major bank."  Is this also true?

Best wishes.

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

Re: [Puppet Users] Puppet / scalability

[Alex Harvey]

Thanks kindly to all for the thoughtful responses.  I'll be looking closely
at the idea of using load balanced Puppet servers.

I wonder if anyone has any thoughts on the other problem I'm told I'll
probably encounter, namely the difficulty in compiling Ruby and other
packages in AIX, HPUX & earlier versions of Solaris?

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

[Puppet Users] Puppet / scalability

[Alex Harvey]

Hi list,

I am looking at configuration management tool options.

I have a large fleet (> 3,000 hosts) and highly heterogeneous
(RHEL3-5, CentOS, 5RH7, Solaris 10 LDOMs/zones, Solaris 8-9, AIX 5.3 &
6.1 LPARs, HP-UX & Tru64 + Windows).  We care mainly about RHEL and
new versions of Solaris & AIX but ability to compile on older versions
is an advantage.  Probably, the Windows will be managed by SCCM.

I have read that Puppet could have scalability problems to a site as
large as ours.  To keep this simple, I'd like feedback on whether that
is likely to be true for us.

A rep from CFengine has told me that ours would be the largest Puppet
site in the world (I think that's not true).  Could someone confirm?

General feedback also welcome.

Kind regards,
Alex Harvey

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