Re: [Puppet Users] Puppet Packages for Fedora 27

[Vince Skahan]

On Tuesday, March 6, 2018 at 11:31:26 AM UTC-8, Branan Purvine-Riley 
wrote:00

> We know the addition of new platforms has been lagging, and we apologize 
> for that. Fedora 27 is almost done, and should start appearing in our 
> nightly repository soon (possibly tonight, if our automated testing all 
> passes).
>
> We've been working on cleaning up our packer[1] scripts to make setting up 
> our build/test environments quicker. We have also made some process changes 
> to how we keep track up upcoming distro releases, in order to better get 
> ahead of the curve. We're still catching up, but we hope we won't lag quite 
> so far behind on future new OS releases.
>
>
>
How about your 2-3 year old vagrant boxes ?
(centos6 and centos7 specifically)

 

-- 
You received this message because you are subscribed 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/3c21961e-1409-48c5-ac5f-0dc54d64652b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] mirroring puppet forge

[Vince Skahan]

What's the preferred way these days to internally mirror puppet forge ?   
 I'd like to periodically catch up to current, but it doesn't have to be 
'that' current, as we don't update the module versions we use too often.

FWIW - we mirror things like CentOS yum repos nightly with 'reposync', but 
they tend to have more frequent updates.

-- 
You received this message because you are subscribed 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/82145038-dece-49f8-a438-e1d5eca003d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] making manifest puppet 4 aware

[Vince Skahan]

On Thursday, January 5, 2017 at 10:37:57 AM UTC-8, Gabriel Schuyler wrote:
>
> Hey Vince, the $::aio_agent_version fact only exists on Puppet 4.  So, 
> I've used its existence in the past to determine whether to use a Puppet 3 
> or 4 code block.  Just wrap your Puppet 4 code block in a conditional that 
> checks for the existence of the fact.
>
>>
>>
>>
update - I opened a ticket with PL and got a non-answer answer saying 'the 
usual way is via facts' and saying to check

   - puppetversion
   - pe_server_version
   - aio_agent_version
   - pe_build
   
What I was looking for, of course, was the one canonical way with code that 
works on both.  Guess I wish for too much.

Did a little fiddling and found the facts above are available or not 
differently in pe3.x and pe2016.x depending on whether you're on client or 
server, and the pe3.x version string is ugly and multi-word.  Nice.

So I have to agree looking for $::aio_agent_version seems to be the best 
choice for now.

(thanks Gabe!)

-- 
You received this message because you are subscribed 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/b3351578-2459-4b93-b221-a6145c7f94c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] making manifest puppet 4 aware

[Vince Skahan]

On Thursday, January 5, 2017 at 11:28:33 AM UTC-8, Rob Nelson wrote:
>
> With puppet4 showing up in vendor repos, is it safe to assume those 
> versions will not have an aio_agent_version fact?
>
> On Thu, Jan 5, 2017 at 1:37 PM, Gabriel Schuyler  > wrote:
>
>> Hey Vince, the $::aio_agent_version fact only exists on Puppet 4.  So, 
>> I've used its existence in the past to determine whether to use a Puppet 3 
>> or 4 code block.  Just wrap your Puppet 4 code block in a conditional that 
>> checks for the existence of the fact.
>>
>>
>>
This kind of uncertainty and hoops to jump through for simple stuff just 
makes me crazy.

Time to open a ticket with PL to ask for the official answer from them. 
 Stay tuned.
 

-- 
You received this message because you are subscribed 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/2f068a5e-b09e-4c80-b26a-d3a679da2a07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] making manifest puppet 4 aware

[Vince Skahan]

On Thursday, January 5, 2017 at 3:49:54 AM UTC-8, Martin Alfke wrote: 

> You can use the fact puppetversion in you rmanifests. 
>
> if versioncmp(‘3’, $::puppetversion) < 0 { 
>   # puppet 4 
> } else { 
>   # puppet 3 
> } 
>
>
There is no such fact on a PE 2016.4.2 client or server:

aio_agent_version => 1.7.1
augeas => {
  version => "1.4.0"
}
facterversion => 3.4.1


There is different stuff on a PE 3.7.2 server and client:

augeasversion => 1.2.0
facterversion => 2.2.0
puppetversion => 3.7.2 (Puppet Enterprise 3.7.0)


Only thing I can think of is looking for puppetversion, and if it's there 
strip off everthing and see if it starts with a '3', but heaven knows what 
crazy versioning semantics PuppetLabs will throw at us looking forward, so 
I don't know if that'll be a stable way to do it or not


-- 
You received this message because you are subscribed 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/40b50b46-a526-47f8-98e7-134005824ee1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] suppressing undefined variable warnings in PE2016.1

[Vince Skahan]

Is there a way to shut up the undefined variable warnings in PE2016.1 ?

Here's a trivial example:

# puppet apply -t --noop -e 'notice("this should print just a 'x' => 
x${foo}")'
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Info: Loading facts
Warning: Undefined variable 'foo'; 
   (file & line not available)
Notice: Scope(Class[main]): this should print just a x => x
Notice: Compiled catalog for myhostname.com in environment production in 
0.04 seconds

I see there is a --strict-variables where I can make compilation fail.
It seems that throwing the warning is the current default
I'm looking for a "yes I have a good reason so please just quit whining 
about what I am doing" switch :-)

Alternately, is there a way to check for the fact being not defined ?
I can not find any syntax that works in the 2016.1 parser. 

something along the lines of notionally the following:
if $whatever is defined print out 'whatever = $whatever'
if $whatever is not defined print out 'whatever is not defined' or null or 
undef or whatever it evaluates to currently.

I'm probably in interpreted language overload among perl/python/bash and 
the Puppet DSL is just not grokking.

-- 
You received this message because you are subscribed 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/dcfb928f-6e74-4974-9505-88d446c682f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] windows vs. linux version compatibility

[Vince Skahan]

Still confused about the great version renumbering I guess, as well as 
version compatibility.

We have an (admittedly old) linux-hosted 3.7.x server setup ('not' enabling 
future parser), and want to try to manage some Windows boxes with puppet. 
 Which package do I grab from https://downloads.puppetlabs.com/windows for 
the Windows hosts ?Does the client version need to match the server 
version ?

Should I:

   - grab the matching puppet-3.7.x version ?
   - grab the latest puppet-3.7.x version ?
   - grab the latest puppet-3.8.x version ?
   - grab the latest puppet-agent-1.x version ?

Incidentally it would be nice if PL would have a shasums file in the 
downloads directory.  Pretty amazing to me that they don't do that.

-- 
You received this message because you are subscribed 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/c84cf863-cbd0-4748-bb5f-3822daf0b696%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] user and service interdependencies

[Vince Skahan]

On Thursday, December 17, 2015 at 3:21:28 AM UTC-8, Klavs Klavsen wrote:
>
> Someone should really create a ticket with a suggestion to fix it (with 
> some examples of what this new option should fix) - and share it here - so 
> everyone can watch the ticket and chime in (it's open source.. remember ;)
>


Ummm - that 'someone' should be 'you' if there is something you think 
should be fixed/enhanced.
 

-- 
You received this message because you are subscribed 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/a1975a2e-730f-4882-bdf1-b90caeb5012d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] slashes or dashes for module names in metadata.json ?

[Vince Skahan]

Confused - I've seen both used in PL docs, and both used in various tools 
and examples.

If I'm identifying the puppetlabs stdlib into my metadata.json file as a 
dependency, as an example:

   - do I call it 'puppetlabs/stdlib'
   - do I call it 'puppetlabs-stdlib'
   - or is the story 'both are supported now, and will continue to be 
   supported moving forward'

And is the story the same for all supported puppet versions (meaning 3.8.x 
'and' 2015.x, and the open source variants that match 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/c888c928-9265-42e8-b17a-dd41d3ffc331%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: custom facts sensitive to spaces

[Vince Skahan]

On Wednesday, September 9, 2015 at 12:01:54 AM UTC-7, Josh Cooper wrote:

> I think you're running into 
> https://tickets.puppetlabs.com/browse/FACT-1050 
> 
>
>
>
Looks like the same thing to me.
It should left+right strip spaces around the '=' sign in all cases.

I did notice that 'facter' with no arguments does show the spaces, you just 
need a font that lets you notice it's there.
Again, I ran into it on 3.8.2

Thanks

-- 
You received this message because you are subscribed 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/27ebb44f-3c6b-4e38-aa20-d79b099595fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: custom facts sensitive to spaces

[Vince Skahan]

On Wednesday, September 9, 2015 at 8:27:42 AM UTC-7, Christopher Wood wrote:

> There's a big "should" question here, maybe the desired behaviour needs to 
> be nailed down before that's a bug? 
>
> For instance, whitespace before/after the "=" could be, according to 
> functionality I've seen: 
>
> a single ascii " " 
> things described by the PCRE \s+ (includes tabs) 
> unicode versions of space characters 
> whatever Word was using for a space character that day 
>
>
I can't think of a case I've ever seen where where "key = value" is 
supposed to be interpreted as anything different than "key=value", but sure 
documenting expected behavior is always goodness.

-- 
You received this message because you are subscribed 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/91fbc85f-8a75-49e4-b44f-9142d4593ecf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] custom facts sensitive to spaces

[Vince Skahan]

I think I found a bug in facter in 3.8.2 but wanted to ask here before 
opening a PL ticket.

Basic description is that facter has different behaviors if you run it 
without vs. with a fact specified.

To recreate:

# echo 'foo = bar' > /etc/facter/facts.d/foo.txt
# facter | grep foo
foo  =>  bar
# facter foo

#

Net effect is that if you have spaces around the = sign in your custom fact 
definitions, the server doesn't match at all.  It seems to look up by name, 
which returns nothing (or a blank line, or a space - it's hard to tell 
which)

Workaround is to have no spaces around the = sign, but I think this is a 
bug needing fixing.  The behavior should be the same when you run "facter | 
grep foo" and "facter foo" shouldn't it ?

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

Re: [Puppet Users] 3.8.2 can't display used licenses, can't clear bogus usage count

[Vince Skahan]

On Monday, August 31, 2015 at 11:43:43 AM UTC-7, Lindsey Smith wrote:
>
>
>
> On Fri, Aug 28, 2015 at 10:19 AM, Vince Skahan <vince...@gmail.com 
> > wrote:
>
>>
>>- how do I clear it back to reality ?  The procedures on PL web don't 
>>work.
>>
>>
> The steps at https://docs.puppetlabs.com/pe/3.8/node_deactivation.html 
> didn't do the trick?
>  
>

u, no they dont - see the original post ?

today I'm showing 3/10 used when there is one client and the master itself.



-- 
You received this message because you are subscribed 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/bc704791-4817-4c3e-a390-37228d2df3a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] 3.8.2 can't display used licenses, can't clear bogus usage count

[Vince Skahan]

I'm running PE 3.8.2 and doing a lot of build/nuke/build cycles in vagrant, 
so I need to watch my license usage.

My server currently shows 5/10 licenses used although there's only one 
client actually.

   - where is this license usage stored ?  Has to be a database someplace 
   with bogus data
   - how do I clear it back to reality ?  The procedures on PL web don't 
   work.

And lastly, I need the future parser 'off' because the splunkforwarder 
module isn't compliant yet (bug is being worked by PL).   When I do certain 
combinations of restarting pe processes while trying to clear the blasted 
license count, it 'continually' reenables the future parser in puppet.conf 
- The pattern seems to be that when I restart pe-memcached and 
pe-console-services to try to reset the licenses displayed, it adds the 
darn line back into puppet.conf on me (silently) and my next runs blow up 
massively (not so silently).


Is there a parser = not_future_quite_yet_dude option I can set in 
puppet.conf ?  Is there a database to clear ?  What is going on 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/d585bc9f-0c09-4767-8bd9-6803a7c583fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppetlabs-mysql how to create a certain grant

[Vince Skahan]

I'm configuring VIVO with puppet and part of the fun is creating a mysql 
database and doing some minimal setup.

   - grant all on vivo.* to ‘root’@’localhost’ identified by ‘vivo’;


It's been a while since I did mysql so I'm probably not finding the secret 
jargon decoder ring for googling this one, but I'm trying to do a 
minimalist implementation:

   - install mysql server and start it up
   - run the equivalent of mysql_secure_installation (including setting the 
   mysql root password)
   - create the database
   - grant privs to the user as mentioned above
   - touch as little under the hood as possible :-)

I 'think' where I'm lost is the identified by 'vivo' thing at the end of 
the grant statement above and how to convert that into puppetlabs-mysql 
definitions, but any suggestions/examples would be appreciated...

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/818e81d8-888c-4602-ab55-937eafb7029b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetlabs-splunk doesn't appear to be future-parser compliant

[Vince Skahan]

On Thu, Aug 20, 2015 at 4:21 PM Vince Skahan vince...@gmail.com 
javascript: wrote:

 On Thursday, August 20, 2015 at 3:40:59 PM UTC-7, Morgan Haskel wrote:

 Hi Vince,

 This sounds like an issue with the MODULE, could you please submit a 
 ticket at https://tickets.puppetlabs.com/browse/MODULES?



ok - done - https://tickets.puppetlabs.com/browse/MODULES-2448 

-- 
You received this message because you are subscribed 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/1d8b54c7-58da-4be8-8ccc-62ce9ad2c518%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetlabs-splunk doesn't appear to be future-parser compliant

[Vince Skahan]

On Thursday, August 20, 2015 at 3:40:59 PM UTC-7, Morgan Haskel wrote:

 Hi Vince,

 This sounds like an issue with the MODULE, could you please submit a 
 ticket at https://tickets.puppetlabs.com/browse/MODULES?



I'd love to, but I can't complete your form successfully.

The  'splunk' module does not appear in the pulldown list and the ticket 
submission gui won't let me enter an unknown module name even though the 
gui lets me type in there (ugh).

-- 
You received this message because you are subscribed 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/6cdedd09-5575-4181-ada7-1dfe8beee394%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppetlabs-splunk doesn't appear to be future-parser compliant

[Vince Skahan]

Is the official supported puppetlabs-splunk module 'not' future parser 
compatible ?

Create a foo.pp containing:
 class { 'splunk::forwarder': }

Run puppet apply --noop with the future parser disabled - looks good...

# puppet apply --noop foo.pp
Notice: Compiled catalog for localhost.localdomain in environment 
production in 0.49 seconds
Notice: /Stage[main]/Splunk::Forwarder/Package[splunkforwarder]/ensure: 
current_value absent, should be present (noop)
Notice: 
/Stage[main]/Splunk::Forwarder/Splunkforwarder_input[default_host]/ensure: 
current_value absent, should be present (noop)
Notice: 
/Stage[main]/Splunk::Forwarder/Splunkforwarder_output[tcpout_defaultgroup]/ensure:
 
current_value absent, should be present (noop)
Notice: 
/Stage[main]/Splunk::Forwarder/Splunkforwarder_output[defaultgroup_server]/ensure:
 
current_value absent, should be present (noop)
Notice: 
/Stage[main]/Splunk::Forwarder/Ini_setting[forwarder_splunkd_port]/ensure: 
current_value absent, should be present (noop)
Notice: Class[Splunk::Forwarder]: Would have triggered 'refresh' from 5 
events
Notice: 
/Stage[main]/Splunk::Platform::Posix/Exec[license_splunkforwarder]/returns: 
current_value notrun, should be 0 (noop)
Notice: Class[Splunk::Platform::Posix]: Would have triggered 'refresh' from 
1 events
Notice: /Stage[main]/Splunk::Virtual/Service[splunk]/ensure: current_value 
stopped, should be running (noop)
Notice: Class[Splunk::Virtual]: Would have triggered 'refresh' from 1 events
Notice: Stage[main]: Would have triggered 'refresh' from 3 events
Notice: Finished catalog run in 0.31 seconds

Run the same test specifying the future parser - total fail

# puppet apply --noop foo.pp --parser future
Notice: Compiled catalog for localhost.dhcp4.washington.edu in environment 
production in 0.79 seconds
Error: Could not find dependent Service[splunk] for 
Package[splunkforwarder] at 
/etc/puppetlabs/puppet/modules/splunk/manifests/forwarder.pp:76

I'm running 3.8.2 here FWIW, but the same failure happens (more verbosely) 
on 2015.2

Wondering if this might be related to 
https://tickets.puppetlabs.com/browse/PUP-4520 which was reportedly fixed 
according to the PUP.

Thoughts ?  Bug in puppet or the module ?
There's definitely a bug someplace

Should I report a bug to PL on this one ?  On the module, or the PE product 
itself ?

-- 
You received this message because you are subscribed 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/93a38d17-4b04-4706-b9f0-bb1529b8adbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] 2015.2 strange message

[Vince Skahan]

On Saturday, August 15, 2015 at 5:06:09 AM UTC-7, Kylo Ginsberg wrote:

 On Thu, Aug 13, 2015 at 9:20 PM, Vince Skahan vince...@gmail.com 
 javascript: wrote:


 I'm sorry but you're going to need to reparse that one into English.
 You want me to check for what (where?) and change what (where?) ?


 The easiest fix for you would be to update to 2.3.0 or greater of the 
 gentoo-portage module.



Thanks for the plain English response :-)

Seems to me that 2015.2 shouldn't have these kinds of issues.  Which PUP 
did you open to fix this obvious bug in the commercial product ?
 

-- 
You received this message because you are subscribed 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/33e894d4-c084-43cd-ba97-9ff652b8389e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] 2015.2 strange message

[Vince Skahan]

Spun up a 2015.2 system and every time an agent runs we see Error: Facter: 
error while resolving custom facts in 
/opt/puppetlabs/puppet/cache/lib/facter/portage.rb: cannot load such file 
-- facter/util/resolution.   Any ideas ?

I saw one bug report at https://github.com/gentoo/puppet-portage/issues/136 
saying facter needed to be updated and this was allegedly done in 2015.2, 
but perhaps not (???)

Vagrant box I'm testing on is centos-6.7 fully patched up.

-- 
You received this message because you are subscribed 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/e23e8c46-3b97-4a7e-bb88-ccba4abc06a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] 2015.2 strange message

[Vince Skahan]

I'm sorry but you're going to need to reparse that one into English.
You want me to check for what (where?) and change what (where?) ?


On Thursday, August 13, 2015 at 11:44:25 AM UTC-7, Peter Huene wrote:

 On Thu, Aug 13, 2015 at 10:21 AM, Vince Skahan vince...@gmail.com 
 javascript: wrote:

 Spun up a 2015.2 system and every time an agent runs we see Error: 
 Facter: error while resolving custom facts in 
 /opt/puppetlabs/puppet/cache/lib/facter/portage.rb: cannot load such file 
 -- facter/util/resolution.   Any ideas ?

 I saw one bug report at 
 https://github.com/gentoo/puppet-portage/issues/136 saying facter needed 
 to be updated and this was allegedly done in 2015.2, but perhaps not (???)


 This was fixed in the puppet-portage module itself, so updating the module 
 to a fixed version or porting the fix to the fact file (simply delete the 
 require 'facter/util/resolution' line) should solve the problem with Facter 
 3.  This particular fix is also backwards compatible with 2.x, as 2.x also 
 required this file before resolving any custom facts.

 If memory serves, I searched through the Forge for references in custom 
 facts depending on the Facter 2.x implementation's file structure and found 
 only this one.  Therefore I didn't end up adding the workaround to Facter 
 itself to support requiring parts of 2.x Facter beyond simply `require 
 'facter'` (which itself is also unnecessary, but was more frequently 
 done).  We could revisit fixing this in Facter itself (basically 
 manipulating the load path to fake the load of 'facter/util/resolution') if 
 it proves to be a more widespread problem affecting other modules.
  


 Vagrant box I'm testing on is centos-6.7 fully patched up.

 -- 
 You received this message because you are subscribed to the Google Groups 
 Puppet Users group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to puppet-users...@googlegroups.com javascript:.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/puppet-users/e23e8c46-3b97-4a7e-bb88-ccba4abc06a4%40googlegroups.com
  
 https://groups.google.com/d/msgid/puppet-users/e23e8c46-3b97-4a7e-bb88-ccba4abc06a4%40googlegroups.com?utm_medium=emailutm_source=footer
 .
 For more options, visit https://groups.google.com/d/optout.




 -- 
 --
 Peter Huene
 Software Engineer, Puppet Labs
 Puppet Open Source Team
 ---

 PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9!



-- 
You received this message because you are subscribed 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/f1afa917-2cd3-4955-8056-5c47feba170f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppetlabs-splunk needs LOTS of usage examples

[Vince Skahan]

On Wednesday, July 29, 2015 at 6:44:30 AM UTC-7, Christina K. wrote:

 Hi Vince, 
 To do that you will need to populate the 

 https://github.com/puppetlabs/puppetlabs-splunk/blob/master/manifests/forwarder.pp
  
 forwarder_input parameter. The title won't matter so you can have 3 
 different titles pointing to a splunkforwarder_input parameter section. 
 Section is defined in each hash as below:
 You will need to say something like


[...deleted for brevity...]
 







 Let me know if this helps.







It doesmuch appreciated.

Amazing how it takes 15 lines of puppet to write a four-line ini file 
stanza, and 5 lines of puppet to write each additional line to that 
stanza.   I guess I was assuming I could cook up an array of key=value 
hashes one per line.  Something in needing to use bogus titles that are 
never used and also needing to repeat the section name every time just bugs 
me I guess.

Thanks again for the example - gotta love examples that work !

-- 
You received this message because you are subscribed 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/e1e4c23a-8d4c-4ea2-b68b-4805f3b0b04c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppetlabs-splunk needs LOTS of usage examples

[Vince Skahan]

On Wednesday, July 29, 2015 at 12:28:58 PM UTC-7, Garrett Honeycutt wrote:

 Sandy, 

 Thanks for sharing your code! Would you consider putting in on github or 
 a similar place with a corresponding license. 



I was going to write up a quick set of example docs (with attribution to 
the real author :-) and submit a PR if that's ok with you guys.

 

-- 
You received this message because you are subscribed 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/952529cf-a07e-457f-815a-d4132fb2e05e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Enterprise 2015.2 is now available!

[Vince Skahan]

On Tuesday, July 28, 2015 at 9:02:34 AM UTC-7, Stephanie Stouck wrote:

 The new Puppet Enterprise 2015.2 is here! We've added features to help you 
 deploy and move faster without sacrificing reliability, with new 
 capabilities to:


I give up.  I can't tell what this is.

Is this the first PE based on open source 4.x ?
Or the next PE based on open source 3.8.x ?

You don't say either way.
Your download link points to 3.8

c'mon you have to at least 'try' to document thing 

-- 
You received this message because you are subscribed 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/73a0e8ac-1897-48e7-9e54-db616885849a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppetlabs-splunk needs LOTS of usage examples

[Vince Skahan]

Does anybody actually use the puppetlabs-splunk module ?

I've been battling this for too many hours and have a bunch of questions.  
I can't really find any references via Google that this is getting much 
usage, and the documentation in the module itself seems essentially 
non-existent, but I thought I'd ask just in case:

   - how do you define a section for inputs.conf that has multiple 
   key=value pairs

If I wanted a inputs.conf stanza of the following, how do I make that 
happen ?

[monitor:///var/log/nginx]
disabled = false
index = main
sourcetype = nginx


 I came up with the following, but the problem is it only permits 
'one' setting and value.

splunkforwarder_input { 'nginx':
section = 'monitor:///var/log/nginx',
setting = 'disabled'
value = 'false',
  }

Is there a way to get it to accept multiple free-form multiple key=value 
pairs ?  It's using their ini module under the hood isn't it ? Is there a 
secret decoder ring of examples someplace ?


   - the README file seems totally wrong to me. On a centos6 system, it 
   doesn't try to install the universal forwarder rpm from the source tree it 
   tells you to build, and it doesn't use the version/build info it tells you 
   to put into parameters. It does a 'yum install splunkforwarder' with odd 
   options, and no (visible to me) way to control yum options, which repo(s) 
   are enabled/disabled, etc.   While the installation 'does' work and it 
   enables and starts the process well, the whole thing seems like half a 
   solution with a tenth of the docs that I'd expect a 'supported' module to 
   have.

FWIW, I only figured out what was expected by reading the (minimal) tests 
in the module sources.  I'd have expected some examples/readme files to 
save hundreds of potential users that pain.


class { 'splunk::params':
 version = '6.1.2',
 build   = '213098',
 server  = 'splunk.apps.oris.washington.edu',
  }
class { 'splunk::forwarder' :

  }


Am I missing something in how to decipher this thing ?  Should we have to 
spend hours trying to reverse engineer a basically undocumented module that 
doesn't even really say what it does/doesn't support in terms of 
functionality or should we just shop elsewhere or roll our own ?  Guess I'm 
pretty lost/confused/tired of battling this thing.  Ideas ?



 


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

[Puppet Users] Re: Lucid leaving apt.puppetlabs.com

[Vince Skahan]

Totally agree with those sentiments.most projects have something ala 
'archives.something.com' site with the historical releases.

That said, you 'could' mirrror the puppetlabs stuff with reposync (or .deb 
equivalent) and set up your local copy to add and not delete anything...


-- 
You received this message because you are subscribed 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/6d0936e8-416c-4587-92dd-3080d826638f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] rpm installation ordering question and yum repos

[Vince Skahan]

Like many sites, we have internal yum repos that contain our 
internally-created rpms, as well as some other repos that are internal 
mirrors of upstream sites (centos updates, etc.).   We're running into an 
ordering issue that I'm looking for what the current suggested best 
practice is

We cooked up a 'my-mirrors-release' rpm notionally like 'epel-release' or 
'centos-release' etc. that you'd commonly see.  Contents are the 
/etc/yum.repos.d files for the various internal repos, and some /etc/pki 
gpg keys for the repos that have signed rpms. Typical yum repo stuff.

Question is how to ensure that our local mirrors-release rpm installs 
before any other rpms that would need to have the repo defined in order to 
find the rpms therein.  In other words we want this rpm installed first. 
Like 'really' first

We're trying to avoid having to specify having the my-mirrors-release rpm 
be installed before rpmXYZ every time we specify a rpm to be installed in 
all the places we might want to specify a package be installed.   Looking 
for suggestions for a current best practice  (assume puppet 3.8 but if 
there's 4.0 magic, that would be good to know)

One solution we came up with is the bottom line in the code snippet below.  
Is this today's best practice for this kind of thing ?  Again - we're 
trying to ensure this 'one' rpm is there before installing later rpms that 
would depend on it.   Suggestions ?


class myprofiles::my_mirrors {  # disable upstream repos  yumrepo { 'updates':  
enabled = 0, }  # enable our mirrors  yumrepo { 'my-repos': 
baseurl = 'http://mirrors.example.com/my-mirrors-release/el6', enabled 
= 1,  }  package { 'my-mirrors-release':provider = yum,ensure   
= latest,require  = Yumrepo['my-repos'],  }  # Ensure our repositories 
are installed before any other package.  # (Otherwise the package may not be 
found.)  Package| title == 'my-mirrors-release' | - Package| title != 
'my-mirrors-release' |
}


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

[Puppet Users] Re: how to export path in bashrc via puppet script

[Vince Skahan]

On Thursday, July 16, 2015 at 9:58:53 AM UTC-7, ayy...@orzota.com wrote:

  exec { file1:
   command = /bin/echo export 
 JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk.x86_64;  /home/haas/.bashrc,
 }
 }

  
try single quoting the inner or outer pair of quotes ?

-- 
You received this message because you are subscribed 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/c8a1b3b8-0899-41bf-ba73-e4c8e693c4ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: yum disable/enable repo with wildcards

[Vince Skahan]

On Monday, July 6, 2015 at 7:44:17 AM UTC-7, jcbollinger wrote:

 Puppet provides a Yumrepo resource type for managing Yum repository 
 definitions.  It has an 'enabled' property, which you can set false to 
 disable repos you want to keep but not use.  This has the advantage that 
 you no longer need to disable these repos from the command line, either, 
 but the disadvantage that it affects only the repos you in fact manage.


I worked around it for the moment by using install_options ala:

  package { 'xyz':
ensure = installed,
install_options = [ { --disablerepo = * }, { --enablerepo  = 
localmirror-* }, ],
  }

But yes I guess just disabling the upstream repos is the right way to go, 
as their names are well known.
 

If you are concerned that unmanaged repos may be be added to your systems, 
 and you are running at least Puppet 3.5, then you should be able to use the 
 Resources metaresource to purge unmanaged repos.


I'm struggling with translating that last statement into English I can 
understand.have an example I could try ?

-- 
You received this message because you are subscribed 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/a9a8c5d9-af40-4ad3-840e-335e571377de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] yum disable/enable repo with wildcards

[Vince Skahan]

We've set up local mirrors of a number of upstream repos, and want to point 
our puppet-managed boxes at the local mirrors only.

Assuming we named our mirror repos local-mirror-whatever, if I was using 
yum on the commandline, I could do it on the fly by disabling all repos and 
then enabling the repo(s) that I wanted visible for that yum transaction 
ala:
yum --disablerepo=* --enablerepo=local-mirror* install foo

Is there a clean way to do this in puppet ?

Alternately, I guess I could just remove all the files (other than ours) in 
/etc/yum.repos.d but that seems a little kludgey to me and I'd need to make 
sure that subsequent yum updates didn't put them back on me.

Any ideas ?


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

[Puppet Users] Re: PL policy toward fixing known bugs in PE 3.8.x

[Vince Skahan]

On Thursday, June 25, 2015 at 5:49:09 PM UTC-7, Eric Sorenson wrote:

 On Thursday, June 25, 2015 at 2:43:34 PM UTC-7, Vince Skahan wrote:


 

 We absolutely do backport upstream fixes into the commercial releases, for 
 exactly the reasons that you describe. We do not backport *every* change, 
 as that gets insanely complicated really quickly. It's generally safer and 
 less confusing to regularly rebase onto newer upstream releases instead of 
 cherry-picking individual fixes. 

 The process generally is that customers who are getting bit by bugs raise 
 support requests through the commercial support team, who work with product 
 management (my team) and the developers to get fixes prioritized, coded and 
 released.  This particular bug didn't have any commercial support tickets 
 associated with it, nor any high community priority around it, so it just 
 slotted into the normal flow of upstream-into-product release train.



hmmm - I guess I was expecting something a little more proactive when an 
official PL module reveals a bug in the current official PE product.

I'd have 'thought' that kind of scenario, especially with a two-liner fix, 
would have gotten into 3.8.x by definition as trivial to do, especially 
since 3.8.x will be around for 12+ months as you mention.  You worked 4.x 
open source which was great, so it'll be there when 4.x PE comes out I 
guess, but I was kind of expecting the current PE product would have 
something like this in there without somebody needing to open a support 
ticket.

If you want I can do that vs. 3.x via my work email if that would help.


I might add that the the discussion on the bug report showed whether to fix 
the PL module or the product showed this one got a lot of good thought.  
Only strange thing to me was that the two-liner fix is so trivial, I'd have 
expected it fixed by definition in at least the most recent supported PE 
version.


- what can we expect in term of bug fixes in the 6 or more month 
window between Open Source 4.x and PE 4.x in terms of supporting your 
'paying' customers ?

 I'm not sure why you keep putting quotes around 'paying'. It's real, 
 actual money from real customers, who we love a lot. :)


oh - I was just trying to draw the distinction between folks who give you 
money vs. folks running the free eval of the same product.  As you said, 
the commercially licensed folks could open a ticket saying it's important 
to them and perhaps expect a little more responsiveness than an open source 
or eval user who might reasonably get an answer of *understood - this is 
fixed in 4.0 open source, so you can go to that or alternately do the 
two-line patch for your open source 3.x installation*'.

Hope this helps. You can see the release timeline and support lifecycle I 
 was talking about here: 
 https://puppetlabs.com/misc/puppet-enterprise-lifecycle


yup - appreciate the responselet me know if you want me to open a 
ticket to get this into the next 3.8.x (via my work email).

Thanks...


 

-- 
You received this message because you are subscribed 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/e4e19a29-dca0-4b49-957e-8d7831e09053%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions

[Vince Skahan]

On Tuesday, June 23, 2015 at 6:03:50 PM UTC-7, Eric Sorenson wrote:

 I love metapackages too, but short of porting yum to Windows, Mac OS X, 
 and 
 Solaris I don't see how they meet those requirements. 


That's certainly reasonable. Cross-platform is hard to do.


 If I¹m only doing a security update to facter, I shouldn¹t have to 
 replace a 
  gigantic bundle with whatever else it pulls In.  I can see you release 
  management people hating this later, as well as security teams. 

 So the puppet-agent package is 17 megabytes on EL7, so gigantic is a bit 
 of 
 an overstatement here. Agreed that the release pipeline is more 
 complicated, 
 and I can definitely understand the desire to just update the one thing 
 that 
 needs a bugfix. 

  
It doesn't change too often.  That's not massive by today's measures.
Smaller than the far more frequent big firefox updates (ugh).

 

  I suspect this confusion will hinder deployment ­ the AIO packaging is 
  certainly in the cons category for us. 

 I really want to understand this, because it's a big deal. (My life goal 
 at 
 this point is to get as many people as possible upgraded to Puppet 4, so 
 anything that gets in the way of that is a problem!) There's been a bunch 
 of 
 different points in the thread, some of them about the numbering and some 
 about the packaging itself; what would reduce the confusion for you? 

  


What's hard is that you're trying to name a collection of differently 
numbered pieces as an aggregate version for that 'collection', which is why 
unifying your versioning will help a lot.

Release everything puppet-4.x with a 4.x.something version identifier for 
your AIO bundles.
That will help a lot.   And don't forget to catch up all your docs to only 
use the 4.x terminology :-)

 

-- 
You received this message because you are subscribed 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/26efcef2-45bf-47cc-a28d-67084c00dfac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] PL policy toward fixing known bugs in PE 3.8.x

[Vince Skahan]

I'm fiddling with PE 3.8.1 to understand the pros+cons of potentially 
updating our 3.7.0 PE server to that as a path toward the coming soon 4.x 
version of PE.

Unfortunately, even doing the initial module installations to 3.8.1 
immediately showed issues. In this case, I ran into the error in module.rb 
mentioned in PUP 3121 and fixed with the two-line patch in 
https://github.com/puppetlabs/puppet/pull/3310 - trivial bug, trivial patch 
to PE. 

According to the PUP the bug was fixed in 4.0.0 (great) but not fixed in 
the PE 3.8.x versions that came out after that (not so great).  
Hand-patching my PE setup fixed the issue, but there's something that 
doesn't feel right about needing to hand-patch a commercial product to get 
it to work.

Questions:

   - why wasn't it fixed in the 3.8.1 PE commercial product ?  If PE is 
   your flagship commercial product, why would you 'not' backport trivial 
   fixes like this for your 'paying' customers ?
   - what, if anything, are you fixing in the 3.8.x PE commercial product 
   at this point ?
   - what can we expect in term of bug fixes in the 6 or more month window 
   between Open Source 4.x and PE 4.x in terms of supporting your 'paying' 
   customers ?
   
I guess I'm not understanding the business model here.  It's great you're 
moving forward to 4.0 and it's improvements, but if your for-pay product 
has bugs that will be around for a year plus (ex: this one) until your 
commercial 4.0-based product eventually appears, even assuming we jump 
day-one to that (we wouldn't, as 'that' will need time to mature), why 
would we pay the money to run buggy software ?

Confused in the PL approach toward support of their 'commercial' vs. 'open 
source' product lines.

-- 
You received this message because you are subscribed 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/d0e5efd6-24fa-481c-bb98-61e720c7464a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions

[Vince Skahan]

On Thursday, June 18, 2015 at 4:18:37 PM UTC-7, Ken Bowley wrote:

 This is better than what is currently being used, but I'm strongly in the 
 AIO idea to be stupid.  Split it into multiple packages and use proper 
 dependencies like every other sane packaging system has done for a long, 
 long time.

 If all you do is bump the version of facter, then only have me download 
 and install the meta package that depends on the new facter, and the new 
 facter package, not everything.



Agree.   Thought I'd chime in (late) as the original poster.

Versioning starting with 4.x is a good start, but I still think your AIO 
approach is wrong.

Have collector rpms that 'require' the pieces of the puzzle and package 
hiera/etc. in individually bundled standalone packages.  If you do that:

   - you can keep versioning facter to 2.x.y if you want
   - you can keep versioning puppetserver any way you want
   - and just version the collection (bundle, pick a term) with the 4.x.x 
   identifier you want to publicize as release-4.x.x

To update the client, 'yum update puppet' and have it update the sub-pieces 
it needs (hiera/mco/etc.)


To update the server, 'yum update puppetserver' and have it do the server 
piece.


Lastly, if it's me, I would not bundle the agent/client stuff 'in' the 
puppetserver package.  I would 'require' the client-stuff to be 
co-installed with the server stuff using the packaging mechanisms the os 
providers already give you.


(in other words, release 'empty' rpms that require x and y and z - works 
great if you don't cause dependency hell by getting too fancy)



-- 
You received this message because you are subscribed 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/04f724ea-b55f-4ba8-a96e-35a580c6c31a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: centos 7 boxes on vagrant cloud?

[Vince Skahan]

On Wednesday, October 8, 2014 at 2:15:25 PM UTC-7, Scott Schneider wrote:

 I was wondering when there will be official centos 7 boxes from puppet 
 labs on https://vagrantcloud.com/puppetlabs 
 https://www.google.com/url?q=https%3A%2F%2Fvagrantcloud.com%2Fpuppetlabssa=Dsntz=1usg=AFQjCNEE88DCnBFChQGREk2MUMsz0xmbgA
 ?
 Also it would be nice to have a link on the puppet vagrant cloud homepage 
 to what repo these boxes are generated from like the chef project does to 
 https://github.com/opscode/bento.


 Hi Chris,

 You've caught us in the middle of re-working our automated Vagrant imaging 
 pipeline.  I expect to have new builds published to Vagrant Cloud later 
 this week or early next week.

 We're also working on setting up a ticketing project for bug reporting and 
 publicizing our Packer repository, as suggested.  Stay tuned!



It's been over 'eight' months - would it be possible to at least have a 
readme file in that directory saying what the heck is in each box and what 
isn't ?

The pattern seems to be:

   - distro-version-arch-nocm = is this a base box with no puppet 
   software at all ?
   - distro-version-arch-puppet   = is this base + puppet server + 
   agent ?   The free one ?  The trial version of enterprise ?
   - distro-version-arch-puppet-enterprise = is this base + puppet 
   enterprise agent-only ?
   - distro-version-arch-openstack = no clue what this is

It would be greatly appreciated if somebody who knows at PL would take five 
minutes and provide the secret decoder ring at the top of the webpage.




The cryptic descriptions are basically unreadable 

-- 
You received this message because you are subscribed 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/f340c814-56fa-4028-b7ef-248f50f1ee20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] puppet enterprise free eval hardware requirements

[Vince Skahan]

On Tuesday, March 31, 2015 at 12:48:40 AM UTC-7, Brad Knowles wrote:

 When running the eval copy of PE 3.7.2 on AWS, we have found that you can 
 boot the master if the VM is an m3.medium (3.5GB), but you run into memory 
 problems that cause the system to be unreliable.  If we use m3.larges 
 (7.5GB), the systems are just fine.  We haven’t come anywhere close to 
 stressing the CPU or RAM of an m3.large in that kind of environment, but 
 AWS doesn’t give you a whole lot of options between them. 

 So, on a 16GB NUC, I would think you could devote 6GB to the puppet master 
 and still have enough RAM left over to run 10x nodes with 1GB RAM each, and 
 you should be fine. 



Thanks - for under 10 clients is 100GB for storage really needed ?Would 
more like 50 be good enough ?

Thinking of kickstarting up a centos7 host under qemu-kvm (on a centos7 
host) if that matters.

-- 
You received this message because you are subscribed 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/2368e43a-6c1f-47a6-8e06-717b52e58f5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet enterprise free eval hardware requirements

[Vince Skahan]

geez puppet needs a 'lot' of oomph to spin up the first node

Evaluation Environment

An evaluation environment is run on a monolithic installation and is 
suitable for evaluating PE on 250 or fewer nodes. We recommend that your 
hardware meets the following:


   - A 4-core server with 6 GB of RAM
 - At least 100 GB of free storage in /opt for PuppetDB
  
We strongly recommend that users on systems with 4 GB of RAM upgrading or 
migrating to PE 3.7 from PE 3.3 or earlier upgrade to 6 GB of RAM before 
attempting to upgrade or migrate their PE installation.


I have a 16-GB ram Intel NUC 
(http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/nuc-kit-d54250wyk-product-brief.pdf)
 
running Centos7 and was thinking of spinning up some VMs to try this out. 
 Does this system have enough oomph to run the 10-node-max free eval, or am 
I going to be stuck with running masterless perhaps ?

-- 
You received this message because you are subscribed 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/82a4264b-1e7d-415e-9476-608e3b83110c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppetmaster installation instructions questions

[Vince Skahan]

I'm trying to set up a puppet master and client under ESXi in a home lab 
using Debian wheezy.  Following the instructions at 
*https://docs.puppetlabs.com/guides/install_puppet/post_install.html#configure-a-puppet-master-server*
 quickly 
got me into a state of confusion regarding what to do.

After the step that sets up the master's cert there is a paragraph saying 
*You'll 
want to set a few settings in puppet.conf before putting the new master to 
work.  See the list of master-related settings for details*.

There is indeed a list that sentence links to. Which settings are the bare 
minimum that I need to have a rudimentary client/server setup on a private 
network work ok ?

Do I 'need' to configure anything other than *ca=true *and setting 
*alt_dns_names* to match the hostname(s) of the puppet master ?

-- 
You received this message because you are subscribed 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/30b4301c-fac3-40a9-8278-31d5a58b6e8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] conditionally running apt-get update

[Vince Skahan]

In trying to spin up on puppet in a Vagrant environment, one of the things 
I have to do to my VM is 'apt-get update' at least once to catch the base 
box's understanding of what packages are where up to current.  That takes a 
long enough time that I'd like to do it just once, or very rarely rather 
than every time I run 'vagrant provision'

Right now, my toplevel manifest does the update once before trying to 
install anything.

exec { run apt-get update:
  path= '/usr/bin',
  command = 'apt-get update',
}

# install and configure nginx
class {'nginx': }



Ansible has a nice feature where you can specify how long you want the 
cache valid for, and it skips doing everything if the cache isn't that old 
(yet)

  - name: update apt cache
   apt: update_cache=yes cache_valid_time=84600


Is there something similar for Puppet, or can somebody suggest a reasonable 
workaround ?


-- 
You received this message because you are subscribed 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/6e0e38f7-9b0e-49ed-b59e-e03b112bae0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.