[Puppet Users] Dealing with samhain

[Vince]

We just starting using samhain on our servers.

Since updates to our puppet manifests tend to change files on the
system that samhain monitors, I'm looking for a good way to
reinitialize the samhain database whenever puppet changes something on
the system to reduce notifications that samhain produces. I'm
wondering if anyone has an elegant way of dealing with this.

Ideally we do something like this:

1. let puppet run
2. if any files changed during the puppet run, then puppet will
automatically reinitialize samhain

or even if we can do something like this it would be fine:

1. have puppet disable samhain before it processes its manifests
2. apply manifest changes
3. reinitialize the samhain database
4. enable samhain

Any suggestions would be very helpful.

Thanks.
-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Knowing if a file is managed by puppet

[Vince Taluskie]

I'm using the puppet-ls script for this purpose.

https://github.com/deanwilson/puppet-scripts/blob/master/puppet-ls

vince

On Tue, Nov 15, 2011 at 9:22 AM, Nigel Kersten  wrote:
> On Tue, Nov 15, 2011 at 8:14 AM, Nan Liu  wrote:
>> On Tue, Nov 15, 2011 at 5:38 AM, chaica  wrote:
>>> I'm looking for a simple way to check if a file on a client (where
>>> puppetd is running) is managed by puppet. At this time, I have to put
>>> a comment on the file and have to run a puppetd -to --noop in order to
>>> see if puppet triggers actions on this file. Is there any way to
>>> simply find if a file on the client is supervised by puppet ?
>>
>> In Puppet 2.7 you can issue the command:
>> puppet catalog select $hostname $type
>
> Also as of 2.7.6, we automatically dump this info in a text file on the 
> agents.
>
> cat $(puppet agent --configprint resourcefile)
>
> file[/etc/puppetlabs/mcollective/ssl/mcollective-private.pem]
> file[/opt/puppet/libexec/mcollective/mcollective/agent/package.rb]
> file[/etc/puppetlabs/activemq/broker.p12]
> file[/etc/puppetlabs/activemq/broker.ts]
> file[/etc/puppetlabs/mcollective/ssl/mcollective-cert.pem]
> file[/opt/puppet/share/puppet-dashboard/.ssh/authorized_keys]
> file[/var/lib/peadmin/.mcollective.d/peadmin-private.pem]
> file[/opt/puppet/libexec/mcollective/mcollective/registration/meta.rb]
> file[/opt/puppet/libexec/mcollective/mcollective/util]
> file[/etc/puppetlabs/mcollective/ssl/clients/mcollective-public.pem]
> group[peadmin]
> user[peadmin]
> ...
>
> --
> 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.
>
>

-- 
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] Re: managing netgroups in /etc/passwd user resources?

[Vince Taluskie]

To answer my question: I looked around in the archives further on this
question and someone suggested to use augeas (which doesn't seem to
have a passwd file lens) or concat option.I ended up writing a
script to idempotently add entries if they were missing as an exec
resource - which works for us.  There are a number of shops that want
to use netgroup syntax its a pity the native OS commands don't appear
to support that syntax otherwise this would be easier...

Vince



class passwd {

exec {"/opt/script/puppet/ensure_pw_present.pl +:x:/opt/script/
nologin":
path => "/usr/bin:/bin",
command => "perl /opt/script/puppet/ensure_pw_present.pl +:x:/opt/
script/nologin",
require => File["/opt/script/puppet/ensure_pw_present.pl"],
onlyif => "grep -v +:x:/opt/script/nologin /etc/passwd",
  user => root,
}

exec {"/opt/script/puppet/ensure_pw_present.pl
+@unixoperators:x:":
path => "/usr/bin:/bin",
command => "perl /opt/script/puppet/ensure_pw_present.pl
+@unixoperators:x:::
::",
require => File["/opt/script/puppet/ensure_pw_present.pl"],
onlyif => "grep -v +@unixoperators:x: /etc/passwd",
  user => root,
before => Exec['/opt/script/puppet/ensure_pw_present.pl +:x:/opt/
script/nologin'],
}



On Mar 14, 3:51 pm, VinceT  wrote:
> Hi,
>
> I'd like to maintain netgroup entries in the /etc/passwd, /etc/shadow
> files to allow all unix admins loging access and default setup nologin
> for every non-authorized user.
>
> +@unixoperators:x:
> +:x:/opt/script/nologin
>
> I saw a thread about this online, but not a definitive resolution -
> not sure if the user resource type is the right way to implement this
> currently or to try to handle via file resources
>
> Vince

-- 
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] PSON! Grrr!

[Vince Taluskie]

For what its worth, we are running into these PSON errors numerous
times as well - preparing for our first puppet rollout and causing
some questions internally.  Running fresh install 2.6.4 on RHEL 5.5 -
would love to help see this debugged.

Vince

On Fri, Apr 1, 2011 at 11:07 AM, Douglas Garstang
 wrote:
> These PSON messages are driving me crazy. It's not unusual to have to
> restart the client 3 times to get past it. Anyone know the cause? This is a
> fresh install of the puppetmaster and puppet client on CentOS 5.5 with
> puppet 2.6.4.
> Apr  1 17:04:14 rcss01 puppet-agent[1058]: Reopening log filesApr  1
> 17:04:15 rcss01 puppet-agent[1058]: Starting Puppet client version 2.6.4
> Apr  1 17:04:16 rcss01 puppet-agent[1058]: Could not retrieve catalog from
> remote server: Could not intern from pson: source did not contain any PSON!
> Apr  1 17:04:16 rcss01 puppet-agent[1058]: Not using cache on failed catalog
> Apr  1 17:04:16 rcss01 puppet-agent[1058]: Could not retrieve catalog;
> skipping runApr  1 17:05:15 rcss01 puppet-agent[1058]: Caught TERM; calling
> stop
> Apr  1 17:05:15 rcss01 puppet-agent[1230]: Reopening log files
> Apr  1 17:05:16 rcss01 puppet-agent[1230]: Starting Puppet client version
> 2.6.4Apr  1 17:05:17 rcss01 puppet-agent[1230]: Could not retrieve catalog
> from remote server: Could not intern from pson: source did not contain any
> PSON!
> Apr  1 17:05:17 rcss01 puppet-agent[1230]: Not using cache on failed catalog
> Apr  1 17:05:17 rcss01 puppet-agent[1230]: Could not retrieve catalog;
> skipping run
> Apr  1 17:05:19 rcss01 puppet-agent[1230]: Caught TERM; calling stopApr  1
> 17:05:20 rcss01 puppet-agent[1352]: Reopening log files
> Apr  1 17:05:20 rcss01 puppet-agent[1352]: Starting Puppet client version
> 2.6.4Apr  1 17:05:21 rcss01 puppet-agent[1352]: Could not retrieve catalog
> from remote server: Could not intern from pson: source did not contain any
> PSON!
> Apr  1 17:05:21 rcss01 puppet-agent[1352]: Not using cache on failed
> catalogApr  1 17:05:21 rcss01 puppet-agent[1352]: Could not retrieve
> catalog; skipping run
> Apr  1 17:05:24 rcss01 puppet-agent[1352]: Caught TERM; calling stopApr  1
> 17:05:24 rcss01 puppet-agent[1474]: Reopening log files
> Apr  1 17:05:25 rcss01 puppet-agent[1474]: Starting Puppet client version
> 2.6.4
> Apr  1 17:05:26 rcss01 puppet-agent[1474]: Could not retrieve catalog from
> remote server: Could not intern from pson: source did not contain any PSON!
> Apr  1 17:05:26 rcss01 puppet-agent[1474]: Not using cache on failed catalog
> Apr  1 17:05:26 rcss01 puppet-agent[1474]: Could not retrieve catalog;
> skipping run
> Apr  1 17:05:28 rcss01 puppet-agent[1474]: Caught TERM; calling stop
> Apr  1 17:05:29 rcss01 puppet-agent[1596]: Reopening log files
> And finally, on the FOURTH attempt!
> Apr  1 17:05:29 rcss01 puppet-agent[1596]: Starting Puppet client version
> 2.6.4
> Apr  1 17:05:33 rcss01 puppet-agent[1596]:
> (/Stage[network]/Network::Base/Network::Resolv_conf[resolv.conf]/File[/etc/resolv.conf]/content)
> content changed '{md5}bf562bbe04aeff07447f98e3775f3bd9' to
> '{md5}1401f263a98e43d48ed8bfa972ffa87d'
> Doug.
>
> --
> 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.
>

-- 
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] ca cert issue when puppetmaster doesn't reverse to puppet hostname

[Vince Taluskie]

I wanted to test out running puppet under Passenger and setup a new
puppetmaster (brm-up-puppet-2) box to test on.   I was seeing some
very odd error back from clients when testing:

err: Could not retrieve catalog from remote server: SSL_connect
returned=1 errno=0 state=SSLv3 read server certificate B: certificate
verify failed

with the help of some previous posters and the archive, I was able to
find some helpful debugging commands and it appears that the cert
generated when starting up the puppetmaster for the first time
generates some X509v3 Subject Alternative Name sections with
references to 'puppet' & 'puppet.sitename.com' as well, which actually
reverses back to what is currently running as prod (brm-up-puppet-1)
but not the new test puppetmaster (brm-up-puppet-2).   Putting an
alias in /etc/hosts on my clients reversing puppet to the brm-up-
puppet-2 box eliminated the cert verify issues.

I wanted to mention that and ask if that seems like the correct
assumption in the behavior for puppetmaster startup and ca creation.
Before beginning my test, I wiped out the /var/lib/puppet/ssl
directory on the new test puppetmaster.   How do others handle
multiple puppetmasters and this behavior and/or transitions needed to
swap out old WEBrick for Passenger with keeping cert management sane.

Thanks,

Vince


openssl x509 -text -noout -in /var/lib/puppet/ssl/certs/brm-up-
puppet-2.sitename.com.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=Puppet CA: brm-up-puppet-2.sitename.com
Validity
Not Before: Apr 13 21:40:39 2011 GMT
Not After : Apr 11 21:40:39 2016 GMT
Subject: CN=brm-up-puppet-2.sitename.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c5:78:d8:b4:4d:88:90:76:37:07:53:b3:b9:a1:
cf:dd:62:81:e7:07:b6:1d:44:9c:66:1f:2c:75:0e:
6a:d4:2c:bb:96:da:42:82:64:2d:eb:38:a1:4f:38:
7c:fe:28:c4:a0:eb:5e:79:54:91:e7:39:62:dc:60:
2c:77:ae:9d:ab:c4:d7:de:d7:80:33:0f:05:d3:b8:
f0:71:38:52:42:26:94:22:ea:12:13:73:e9:9c:49:
97:75:df:c4:d3:56:a7:ec:7e:7f:a7:09:8b:ac:6d:
0f:9e:0c:3f:ab:de:d5:ad:64:3c:27:f4:c5:7c:c9:
32:67:67:e1:97:12:10:fd:f5
Exponent: 65537 (0x10001)
X509v3 extensions:
Netscape Comment:
Puppet Ruby/OpenSSL Generated Certificate
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
06:96:73:3F:97:EE:B3:FC:43:DC:21:E8:D9:C9:C5:71:83:BB:
0B:00
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client
Authentication, E-mail Protection
X509v3 Subject Alternative Name:
DNS:puppet, DNS:brm-up-puppet-2.sitename.com,
DNS:puppet.sitename.com
Signature Algorithm: sha1WithRSAEncryption
53:64:d0:8a:e0:b8:76:04:b6:51:9a:3d:d0:ff:72:c9:2f:57:
8c:6a:6a:f4:ac:d8:56:20:02:bb:e0:1c:07:47:58:88:b0:68:
2a:56:70:70:62:ed:11:fb:a1:26:5a:e0:6c:5c:e7:75:a4:43:
8a:54:ce:16:02:ab:ab:06:7e:57:1d:6a:71:75:b3:2e:8b:20:
f3:e6:c6:86:7e:d5:ee:fc:ed:35:7c:2d:da:3d:10:62:97:51:
d3:ee:e3:4d:c3:79:35:3e:38:30:7e:d6:f2:b4:ab:46:5a:7f:
5a:82:05:20:c4:db:94:4c:40:76:5d:1e:3a:25:77:be:63:95:
55:00

-- 
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] debuging dashboard - RH61 puppet agent shows changes, dashboard doesn't

[Vince Taluskie]

I'm trying to debug an issue I'm noticing on RHEL 6.1 puppet clients
and reporting.   I've got dashboard v1.1.0 running under apache
passenger with 26 nodes.It's been pretty good for reporting status
and this is the first time i've come across an issue.   The issue
appears  to be cropping up on RHEL 6.1 clients.

When I run with a puppet agent --noop on another other node with
report=true in the client's puppet.conf I get a report in dashboard
showing the correct puppet run status.   However, what i've noticed is
that on RHEL 6.1 puppet client (2.6.9) - the noop puppet runs are
always returned as status 'unchanged' even when there would indeed
have been changes reverted on the client.   When I remove the --noop
flag, the behavior is normal and puppet runs with changes are reported
as such in dashboard.

Thought i'd ask if this is a known issue and if anyone else noticing
this and have a fix.   Not critical but it does mess up my reporting
as we prefer to run in noop mode except during change windows for our
production environment.

Vince

-- 
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 in an appliance model?

[Vince Taluskie]

Hey Folks,

I am looking at using puppet to help manage/coordinate system integration 
among several teams collaborating on an appliance product.This is a 
little different than other environments where I've used puppet for 
managing large numbers of systems. In the appliance case, we need to 
build & manage only a single system so a puppetmaster becomes extra baggage 
that is not really needed - what features will not work without one tho?   
Will erb templates still work?   Will modules also function without a 
puppet master?

i'm wondering if anyone has already shared their experiences with the group 
using puppet in this kind of mode.   If so, please share and I will 
summarize.

Thanks,

Vince

-- 
You received this message because you are subscribed to the Google 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] 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] 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.

[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] making manifest puppet 4 aware

[Vince Skahan]

We're transitioning from PE 3.7.2 to 2016.latest and are dealing with the 
differences in pathnames in the new version with it putting stuff under 
'code' in the tree.   Is there a recommended way to make our manifests 
puppet-3 vs puppet-4 aware programmatically ?  With the big changes in 
version strings for the pieces of the software, I haven't found a usable 
way yet...



-- 
You received this message because you are subscribed to the Google 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/2e9a4859-6004-49f8-bf84-23346952d326%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.

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 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.

[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.

[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] 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.

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] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions

[Vince Skahan]

I just set up a couple 4.0.0 virtual machines, trying to follow the 
installation instructions as-written on the website, and found some 
confusing things.

First - can somebody explain why you're referring to the software in docs 
with one version (4.0.0) and you have a very different versioning for the 
rpm/deb packagesand then the --version strings of the various utilities 
in /opt/puppetlabs/bin report something very different from either the 
4.0.0 version 'or' the rpm/deb package versions.

Is there a reason you're not packaging for the various distros using the 
same version identifiers your code and docs seem to use ?  Seems like a 
gratuitous obfuscation to me.   Why would you possibly have their major 
versions so different from what 'foo --version' reports ?

#-- (on centos server)

# rpm -qa|grep -i pup
puppetlabs-release-pc1-0.9.2-1.el7.noarch
puppet-agent-1.0.0-1.el7.x86_64
puppetserver-2.0.0-1.el7.noarch

# puppet --version
4.0.0

 

# cfacter --version
0.4.1 (commit e9333e184e57106f7ce3fb6b44b05656f417d245)

# facter --version
2.4.3


# hiera --version
2.0.1

 

# mco --version
/opt/puppetlabs/bin/mco 2.8.1

# puppetserver --version
puppetserver version: 2.0.0 


#---(on debian client)

# dpkg -l | grep -i pup
ii  puppet-agent   1.0.0-1wheezy amd64 
   The Puppet Agent package contains all of the elements needed to run 
puppet, including ruby, facter, hiera and mcollective.
ii  puppetlabs-release-pc1 0.9.2-1wheezy all   
   Release packages for the Puppet Labs PC1 repository

# puppet --version
4.0.0


# cfacter --version
0.4.1 (commit e9333e184e57106f7ce3fb6b44b05656f417d245)

# facter --version
2.4.3

# hiera --version
2.0.1

# mco --version
/opt/puppetlabs/bin/mco 2.8.1
 



Also your 4.0 docs have lots of pointers back to 3.7 info, which is also 
pretty confusing, as well as having links that don't resolve.

   - https://docs.puppetlabs.com/puppet/4.0/reference/system_requirements.html 
(in the main body) 'pre-install tasks' doesn't resolve, but it does 
   resolve in the menu on the left
   - https://docs.puppetlabs.com/puppet/4.0/reference/install_linux.html 
   points to 3.7 docs for the bottom half-dozen links
   
Lastly, when installing the agent system, it didn't register the cert 
request with the master until I ran agent with --test and 'then' started 
the agent with puppet 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/50ea86b0-2c74-4cc8-a07b-1ae1860b383f%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, April 23, 2015 at 3:44:35 PM UTC-7, jcf wrote:
>
> There is actually nothing in semver that precludes co-terming major 
> release versions,  and less that precludes "--version"  from both 
> displaying the local package version,  AND the release number targeted by 
> said package if you disagreed with the first point. This is one of those 
> circumstances where being pedantic means you reduce understanding,  not 
> increase it.
>

Agree.

What I'm looking for is clarity for the users.  What is there now is beyond 
unclear.

The problem as I see it is bundling.  Puppet is grouping standalone 
components into an aggregate 'release' of something bigger.  The pieces 
have versions that are far different from the aggregate.   Each piece's 
--version string doesn't even match the version of the rpm they were 
bundled into. That is just wrong.

Put yourself in the user's shoes:

   - I think I'm running puppet open source 4.0.0 including both server and 
   agent
   - there is a puppetserver-2.0.0 there, and a puppet-agent-1.0.0 there   
   - geez, I must be YEARS behind current !
   - so I look in /opt/puppetlabs/bin and see five binaries, none of which 
   have --version = 4.0.0 or even 'close' to the rpm version they came from
   - and that is clear 'how' exactly ?

My suggestion would be:

   - puppetserver rpm should be 4.0.0 for puppet release 4.0.0
   - puppet-agent rpm should be 4.0.0 for puppet release 4.0.0

And to me I'd add:

   - everything in a typically public-interface directory (not a bundled 
   ruby version, for example) that is therein and supports a --version should 
   return a version reflecting the rpm version they were packaged in somehow 
   that is user obvious.

or if you can't do that, bundle each of them into their own individually 
versioned rpms (ie. facter-2.4.3) and have puppet-agent require multiple 
rpms.

-- 
You received this message because you are subscribed to the Google 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/d210c3b2-3c27-4b0c-9287-1821bebe8f5d%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 Monday, April 27, 2015 at 2:30:00 PM UTC-7, Eric Sorenson wrote:

> As an example, if it started out at puppet-agent-4.0.0 to match 
> puppet-4.0.0, but the only change in the next AIO package is to incorporate 
> a feature update in Facter (a hypothetical 2.5.0), we'd want to reflect 
> that feature update in puppet-agent-4.1.0. But should that then trigger a 
> release of a puppet-4.1.0 *even though nothing has changed in puppet*? 
>

Great example and question which I think indicates the issues I am trying 
to get across re: the existing versioning and bundling.

My view as a user is that puppet 4.0 is a version of an architecture and 
its matching DSL and API.   Now that might be totally at odds with how PL 
views it, but lets go down that path for discussion purposes for a bit 
further and see what packaging/versioning might result.

   - puppetserver being versioned 2.0.0 is needlessly confusing, if it's 
   puppet (the product) 4.0.0 that it implements.  What's 'in' it seems 
   reasonable, it's just the server piece, but its rpm version should line up 
   with what the binary reports when you use --version against it.
   - puppet-agent is the main issue, it's really a package that could be 
   called puppet-agent-plus-everything-else-but-the-kitchen-sink.   Too much 
   stuff that is a little loosely related to puppet 4.0.0 (the 
   architecture/api) is in there, and since they are so loosely related 
   (currently) you didn't change their version strings, which differ greatly. 
It also has the same mismatch of rpm version (1.0.0) vs. architecture 
   version (4.0.0) for the rpm vs. the agent itself.

And yes, now that 4.0.0 is out, I know it'll be a joy to switch gears 
moving forward...

Using your example, if you needed to update facter to a hypothetical 2.5.0, 
what would you do ? You'd need to roll your existing puppet-agent-2.0.0 rpm 
to something different.  What version do you call it ?   The agent (within) 
is strongly linked to the server 4.0.0, the ruby interpreter and misc utils 
in there far less so.  Would you just call the package puppet-agent-2.1.0 
hypothetically ?  The fact that puppet-agent-4.0.0 is in there (and that 
the cfacter change didn't alter anything 'puppet') is still confusing if 
you pick anything other than 4.0.x, but as you said a roll in facter that 
doesn't change the puppet api wouldn't normally cause a puppet-agent 
version roll.   Confusing no matter which way you go.

I'd suggest you need to break the core puppet stuff (server, agent) apart 
from the utils (mco, facter/cfacter, hiera) and common (ruby) pieces.   
Version the server/agent stuff to match the puppet api version.  Version 
the utils any way you want if they're not linked really to the puppet 
version.  Same for your ruby version.

So I'd suggest repackaging ala:

puppetserver-4.0.0-1.el7.noarch
puppet-agent-4.0.0-1.el7.x86_64  <= just the agent piece

puppet-utils-4.0.0-1.el7.x86_64  <= hiera/facter/cfacter/mco 

puppet-ruby-1.9.whatever.el7.x86_64  <= just the ruby interpreter


or if you wanted to do (to me) a better componentization, I'd suggest:

puppetserver-4.0.0-1.el7.noarch
puppet-agent-4.0.0-1.el7.x86_64  <= just the agent piece

puppet-facter-2.4.3-1.el7.x86_64
puppet-mco-2.8.1-1.el7.x86_64
puppet-hiera-2.0.1.el7.x86_64

puppet-ruby-1.9.whatever-1.el7.x86_64



Your AIO installation of the multiple pieces currently in the agent rpm 
would still work, it would be just adding 'requires' to the agent rpm.   Of 
course now that 4.0.0 is in the field, switching gears is an adventure in 
itself I guess  and getting from 4.0.0 to 4.1.0 would be interesting to say 
the least.  At a minimum, it would let you roll hiera or mco or facter or 
ruby asynchronously at their own rates.

Sorry for the long response.  Feel free to email if I lost you someplace 
above.


-- 
You received this message because you are subscribed to the Google 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/ebfee61b-7c25-4b5e-b8ea-5282980e131b%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 
>> 
>> ?
>> 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] 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.

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.

[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.

[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: 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] 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] 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: 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] 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] 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  > 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 .
>> 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=email&utm_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.

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  > 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] 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] 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.

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 > 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.

[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.

[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.

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  > 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] 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.

[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] 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] 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] 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.