Re: [Puppet Users] Puppet agent hangs on "Executing: '/sbin/service nfs start'

[Bret Wortman]

It must have been a long day yesterday. I thought this was something Puppet 
was doing internally. I'm closing in on the root cause now.

On Thursday, August 29, 2019 at 1:45:03 AM UTC-4, Dirk Heinrichs wrote:
>
> Am Mittwoch, den 28.08.2019, 11:49 -0700 schrieb Bret Wortman:
>
> Debug: Executing: '/sbin/service nfs start'
>
>
> First thing to try: Does it also hang if you run the command manually? 
> Maybe it's a problem with that specific service.
>
> Bye...
>
> Dirk
>
> -- 
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18
> *Email*: dhei...@opentext.com 
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan, 
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you 
> are not the intended recipient (or have received this e-mail in error) 
> please notify the sender immediately and destroy this e-mail. Any 
> unauthorized copying, disclosure or distribution of the material in this 
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
> Weitergabe dieser Mail sind nicht gestattet.
>

-- 
You received this message because you are subscribed 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/ae218244-ba5d-43ac-8493-0c1ddff4c97b%40googlegroups.com.

[Puppet Users] Puppet agent hangs on "Executing: '/sbin/service nfs start'

[Bret Wortman]

My agent is 6.6.0 and my server is 6.4.0, so I realize this may be a 
mismatch problem, though why the repos have advanced the agent past the 
server, I don't know.

Anyway:

My agents on C6 are now hanging and refusing to progress. This happens 
randomly; some part of the catalog will get applied but not all. When I 
just now tried to debug one, it hangs reliably at the following:

# puppet agent -t --debug
:
:
Debug: Executing: '/sbin/service nfs status'
Debug: Executing: '/sbin/chkconfig nfs'
Debug: Executing: '/sbin/service nfs start'

Has anyone else seen this? It's new to me...

Thanks!


Bret Wortman
The Damascus Group LLC

-- 
You received this message because you are subscribed 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/69c5b56c-ceb3-4b59-8bc1-5631baba7a8f%40googlegroups.com.

Re: [Puppet Users] Re: Puppet 6 regenerate all certs fails with OpenSSL::X509::StoreError

[Bret Wortman]

That worked like a champ. Now I just need to read up on how to get my 
puppetserver talking to puppetdb again...


Thanks, Maggie!


On 10/22/2018 11:36 AM, Maggie Dreyer wrote:
Unfortunately that particular docs page was incorrectly updated for 
Puppet 6. If you are running Puppet 6 master AND agents, you can 
regenerate your CA by using `puppetserver can setup`. This creates a 
basic intermediate CA with a self-signed root and a CA signing cert. 
It will also create a new cert for your puppet master. You can read 
more about this model here: 
https://puppet.com/docs/puppetserver/6.0/intermediate_ca.html, and 
more about the new `puppetserver ca` subcommand here: 
https://puppet.com/docs/puppetserver/6.0/subcommands.html#ca.


However, please note that if you still have some Puppet 5 agents, 
you'd be better off just restarting Puppet Server, which will generate 
a new non-intermediate CA (a self-signed root that also is the CA 
signing cert that issues node certificates). Puppet 5 agents do not 
properly support the intermediate CA setup without manual intervention.


Whichever route you take to regenerate your CA and master cert, you 
will also need to regenerate the certs for your agents. This can be 
accomplished by starting Puppet Server, deleting the SSL dir on each 
agent node (and puppetdb), then running `puppet agent -t` to submit a 
signing request to the server. On a Puppet 6 master, use `puppetserver 
ca sign --certname ` to sign the cert, followed by 
another `puppet agent -t` on the agent to retrieve it.


We made a series of major CA improvements in Puppet 6, which you can 
read about in the release notes here 
<https://puppet.com/docs/puppetserver/6.0/release_notes.html> and here 
<https://puppet.com/docs/puppet/6.0/release_notes.html>. While 
updating the docs for this release, we realized that a major overhaul 
of the CA and SSL docs was needed, as many of them haven't been 
touched since the release of Puppet 4. We are in the process of 
getting that written and published now. We really appreciate feedback 
like this to help us identify spots that are still wrong or confusing.


Please let me know if anything in here doesn't work right for you!
Maggie

On Mon, Oct 22, 2018, 5:48 AM Bret Wortman 
mailto:bret.wort...@damascusgrp.com> wrote:


Out of curiosity, I updated the server to 6.0.1. No change.


On Monday, October 22, 2018 at 7:25:10 AM UTC-4, Bret Wortman wrote:

We had an issue where someone removed our puppet server's
ssl directory, so we need to regenerate all our certs. I'm
following the instructions at
https://puppet.com/docs/puppet/6.0/ssl_regenerate_certificates.html
but am having difficulties:

# puppetserver ca list -a
Traceback (most recent call last):
     9: from
/opt/puppetlabs/server/apps/puppetserver/cli/apps/ca:5 in ''
     8: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/cli.rb:89:
in 'run'
     7: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:60:
in 'run'
     6: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:113:
in 'get_all_certs'
     5: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:113:
in 'new'
     4: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/certificate_authority.rb:16:
in 'initialize'
     3: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/certificate_authority.rb:16:
in 'new'
     2: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:19:
in 'initialize'
     1: from

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:108:
in 'make_store'

/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:109:in
'add_file': system lib (OpenSSL::X509::StoreError)
#

Has anyone encountered this before? Any thoughts on how to
regenerate my certs on this system and get us going again?

Note: I have puppet installed on one server and puppetdb on
another, in case 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 e

[Puppet Users] Re: Puppet 6 regenerate all certs fails with OpenSSL::X509::StoreError

[Bret Wortman]

Out of curiosity, I updated the server to 6.0.1. No change.


On Monday, October 22, 2018 at 7:25:10 AM UTC-4, Bret Wortman wrote:
>
> We had an issue where someone removed our puppet server's ssl directory, 
> so we need to regenerate all our certs. I'm following the instructions at 
> https://puppet.com/docs/puppet/6.0/ssl_regenerate_certificates.html but 
> am having difficulties:
>
> # puppetserver ca list -a
> Traceback (most recent call last):
>  9: from /opt/puppetlabs/server/apps/puppetserver/cli/apps/ca:5 in 
> ''
>  8: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/cli.rb:89:
>  
> in 'run'
>  7: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:60:
>  
> in 'run'
>  6: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:113:
>  
> in 'get_all_certs'
>  5: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:113:
>  
> in 'new'
>  4: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/certificate_authority.rb:16:
>  
> in 'initialize'
>  3: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/certificate_authority.rb:16:
>  
> in 'new'
>  2: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:19:
>  
> in 'initialize'
>  1: from 
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:108:
>  
> in 'make_store'
> /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:109:in
>  
> 'add_file': system lib (OpenSSL::X509::StoreError)
> #
>
> Has anyone encountered this before? Any thoughts on how to regenerate my 
> certs on this system and get us going again?
>
> Note: I have puppet installed on one server and puppetdb on another, in 
> case 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/7715f962-0e79-44f8-9e25-ade744378c37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet 6 regenerate all certs fails with OpenSSL::X509::StoreError

[Bret Wortman]

We had an issue where someone removed our puppet server's ssl directory, so 
we need to regenerate all our certs. I'm following the instructions 
at https://puppet.com/docs/puppet/6.0/ssl_regenerate_certificates.html but 
am having difficulties:

# puppetserver ca list -a
Traceback (most recent call last):
 9: from /opt/puppetlabs/server/apps/puppetserver/cli/apps/ca:5 in 
''
 8: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/cli.rb:89:
 
in 'run'
 7: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:60:
 
in 'run'
 6: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:113:
 
in 'get_all_certs'
 5: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/action/list.rb:113:
 
in 'new'
 4: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/certificate_authority.rb:16:
 
in 'initialize'
 3: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/certificate_authority.rb:16:
 
in 'new'
 2: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:19:
 
in 'initialize'
 1: from 
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:108:
 
in 'make_store'
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppetserver-ca-1.0.0/lib/puppetserver/ca/utils/http_client.rb:109:in
 
'add_file': system lib (OpenSSL::X509::StoreError)
#

Has anyone encountered this before? Any thoughts on how to regenerate my 
certs on this system and get us going again?

Note: I have puppet installed on one server and puppetdb on another, in 
case 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/6f6d349b-186d-46e7-b472-957b856ae60f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet server stopped working

[Bret Wortman]

I did, by building a new server. That said, I'd try this advice before
starting over:
https://puppet.com/docs/puppet/5.5/ssl_regenerate_certificates.html

For us it was also a change to move from a monolithic, everything on one
server architecture to something a bit more distributed.

On Thu, Jul 19, 2018 at 11:35 AM, Scott Hazelhurst <
scott.hazelhu...@gmail.com> wrote:

> Were you able to resolve this issue? I am now getting the same problem
>
> Thanks
>
> Scott
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/puppet-users/c9tpVjpF4sc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/23914a82-0812-4aa8-92cc-ae35dbd6b6be%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[Puppet Users] Re: PKIX path validation failed

[Bret Wortman]

Here's how I recovered:

# service puppetdb stop
# yum remove puppetdb
# cd /etc/puppetlabs
# mv puppetdb puppetdb.orig
# puppet apply puppetdb.pp
# service puppetserver stop && service puppetserver start

And we appear to be better off now. Note that puppetdb.pp was a one-shot 
manifest I wrote to just install puppetdb. I suspect that I somehow changed 
the puppetserver certs after installing puppetdb originally, and reapplying 
the manifest without removing the older /etc/puppetlabs/puppetdb directory 
prevented it from generating new certs.


On Wednesday, July 11, 2018 at 2:23:37 AM UTC-4, Thomas Müller wrote:
>
>
>
> Am Dienstag, 10. Juli 2018 20:04:03 UTC+2 schrieb Bret Wortman:
>>
>> I'm standing up a new replacement puppet server in place of the one we 
>> trashed a few weeks ago, and am running into a new, interesting issue.
>>
>> I'm running puppet and puppetdb on the same server. Postgres is up and 
>> running. When I try to run puppet agent -t on a random system, I get this:
>>
>> # puppet agent -t
>> Warning: Unable to fetch my node definition, but the agent run will 
>> continue
>> :
>> Info: Retrieving pluginfacts
>> Info:Retrieving plugin
>> Info: Loading facts
>> Error: Could not retrieve catalog from remote server: Error 500 on 
>> SERVER: Server Error: Failed to execute 
>> '/pdb/cmd/v1?checksum=&version=5&certname=zw129.my.net&command=replace_fact&producer-timestamp='
>>  
>> on at least 1 of the following 'server_urls': https://puppet.my.net:8081
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog: skipping run
>> #
>>
>>
>> So I peeked in /var/log/puppetlabs/puppetserver/puppetserver.log and 
>> found:
>>
>> ERROR [qtp6662638830-70] [c.p.h.c.i.PersistentSyncHttpClient] Error 
>> executing http request
>> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>> :
>> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
>> :
>> Caused by: sun.security.validator.ValidatorException: PKIX path 
>> validation failed: java.security.cert.CertPathValidatorException: Path does 
>> not chain with any of the trust anchors
>> :
>>
>> So I'm thinking something in the certificate chain is wrong, but I'm 
>> hesitant to dive in and start replacing certs without being pretty sure of 
>> what I'm doing, lest we end up starting over yet again. Has anyone else 
>> encountered anything like this?
>>
>>
>>
> Sounds like maybe multiple issues:
>
> * if an ENC is configured the ENC request maybe failed
> * puppetdb does not use certs that are signed by the puppetserver CA
>
> I would start by checking puppetdb certs.
>
> - Thomas
>

-- 
You received this message because you are subscribed 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/d51e334f-17c5-4546-9b25-264d80885a74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] PKIX path validation failed

[Bret Wortman]

I'm standing up a new replacement puppet server in place of the one we 
trashed a few weeks ago, and am running into a new, interesting issue.

I'm running puppet and puppetdb on the same server. Postgres is up and 
running. When I try to run puppet agent -t on a random system, I get this:

# puppet agent -t
Warning: Unable to fetch my node definition, but the agent run will continue
:
Info: Retrieving pluginfacts
Info:Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Failed to execute 
'/pdb/cmd/v1?checksum=&version=5&certname=zw129.my.net&command=replace_fact&producer-timestamp='
 
on at least 1 of the following 'server_urls': https://puppet.my.net:8081
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog: skipping run
#


So I peeked in /var/log/puppetlabs/puppetserver/puppetserver.log and found:

ERROR [qtp6662638830-70] [c.p.h.c.i.PersistentSyncHttpClient] Error 
executing http request
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
:
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
:
Caused by: sun.security.validator.ValidatorException: PKIX path validation 
failed: java.security.cert.CertPathValidatorException: Path does not chain 
with any of the trust anchors
:

So I'm thinking something in the certificate chain is wrong, but I'm 
hesitant to dive in and start replacing certs without being pretty sure of 
what I'm doing, lest we end up starting over yet again. Has anyone else 
encountered anything like this?

Thanks!


Bret

-- 
You received this message because you are subscribed 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/ee42f087-55fb-4df9-b1a4-759139fb522e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] PKIX path validation failed

[Bret Wortman]

I'm standing up a new replacement puppet server in place of the one we 
trashed a few weeks ago, and am running into a new, interesting issue.

I'm running puppet and puppetdb on the same server. Postgres is up and 
running. When I try to run puppet agent -t on a random system, I get this:

# puppet agent -t
Warning: Unable to fetch my node definition, but the agent run will continue
:
Info: Retrieving pluginfacts
Info:Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Failed to execute 
'/pdb/cmd/v1?checksum=&version=5&certname=zw129.my.net&command=replace_fact&producer-timestamp='
 
on at least 1 of the following 'server_urls': https://puppet.my.net:8081
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog: skipping run
#


So I peeked in /var/log/puppetlabs/puppetserver/puppetserver.log and found:

ERROR [qtp6662638830-70] [c.p.h.c.i.PersistentSyncHttpClient] Error 
executing http request
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
:
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
:
Caused by: sun.security.validator.ValidatorException: PKIX path validation 
failed: java.security.cert.CertPathValidatorException: Path does not chain 
with any of the trust anchors
:

So I'm thinking something in the certificate chain is wrong, but I'm 
hesitant to dive in and start replacing certs without being pretty sure of 
what I'm doing, lest we end up starting over yet again. Has anyone else 
encountered anything like this?

Thanks!


Bret

-- 
You received this message because you are subscribed 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/4987feae-5034-441a-8ba6-9dbf753e5266%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppetserver won't start

[Bret Wortman]

After accidentally running puppet agent on our puppet server, the server no 
longer works. I've run a "yum reinstall puppetserver" on it to no avail.

What's happening is that it keeps trying to start but fails for some 
reason. /var/log/messages shows:

:
puppet puppetserver: at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
puppet puppetserver: at 
java.util.concurrent.ThreadPooLExecutor$Worker.run(ThreadPoolExecutor.java:624)
puppet puppetserver: at java.lang.Thread.run(Thread.java:748)
puppet puppetserver: Background process 4918 exited before start had 
completed
puppet systemd: puppetserver.service: control process exited, code-exited 
status=1
puppet systemd: Failed to start puppetserver Service.
puppet systemd: Unit puppetserver.service entered failed state.
puppet systemd: puppetserver.service failed.
puppet systemd: puppetserver.service holdoff time over, scheduling restart.

Any thoughts about what to check next to see why this is failing?

-- 
You received this message because you are subscribed 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/461e5335-006c-47e8-ab0a-ec801496cf41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet server stopped working

[Bret Wortman]

Aha! According to the puppetserver.log, I've got a weird keypar:

ERROR [async-dispatch-2] [p.t.internal] Error during service init!!!
java.lang.IllegalArgumentException: Expected a KeyPair or PrivateKey, got 
org.bouncycastle.openssl.PEMEncryptedKeyPair@748f579b
:
:

What is this thing, and how can I recreate my server's original (or a new) 
keypair?

On Monday, July 2, 2018 at 9:18:40 AM UTC-4, Patrick Lesher wrote:
>
> One of our guys did something similar a couple weeks ago and we didn’t 
> have a backup.  It sounds like ours was a little different in that the 
> server was running fine, remote agents could connect, process, etc, but the 
> puppet master’s agent refused to run.
>
> Ours is a mono deployment on a single VM so I could take a snapshot and 
> play around with it.
>
>
> In the end I did an upgrade to the latest 2018 ( it was 2017.x ) and 
> everything came up working.  I’m not sure if that will help you but it 
> solved our problem.
>
>
>
> On Jul 2, 2018, at 7:35 AM, Bret Wortman  > wrote:
>
> I accidentally ran puppet agent on our puppet master and now puppet server 
> won't start up any more. Multiple reboots have failed to clear the 
> situation and I can't figure out what file changed.
>
> Here's the tail end of /var/log/messages | grep puppetserver, minus the 
> datestamps:
>
> :
> puppet puppetserver: at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> puppet puppetserver: at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> puppet puppetserver: at java.lang.Thread.run(Thread.java:748)
> puppet puppetserver: Background process 4918 exited before start had 
> completed
> puppet systemd: puppetserver.service: control process exited, code=exited 
> status=1
> puppet systemd: Failed to start puppetserver Service.
> puppet systemd: Unit puppetserver.service entered failed state.
> puppet systemd: puppetserver.service failed.
> puppet systemd: puppetserver.service holdoff time over, scheduling restart
> puppet systemd: Starting puppetserver Service...
> puppet puppetserver: OpenJDK 64-Bit Server VM warning: ignoring option 
> MaxPermSize=256m; support was removed in 8.0
>
> Any thoughts about where to look next for a solution, or at least a more 
> in-depth understanding of what's going on? This server has been in 
> operation for several years without any issues until we stomped something...
>
> 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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/39635033-2e37-49de-8e86-493c7829654a%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/puppet-users/39635033-2e37-49de-8e86-493c7829654a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

[Puppet Users] Re: Puppet server stopped working

[Bret Wortman]

Further to this, journalctl -xe has this to contribute when I try to start 
it up:

:
systemd[1]: Unit puppetserver.service entered failed state.
systemd[1]: puppetserver.service failed.
polkitd[632]: Unregistered Authentication Agent for 
unix-process:16477:1258070 (system bus name :1.652, object pathy 
/org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_us.UTF
:



On Monday, July 2, 2018 at 8:35:33 AM UTC-4, Bret Wortman wrote:
>
> I accidentally ran puppet agent on our puppet master and now puppet server 
> won't start up any more. Multiple reboots have failed to clear the 
> situation and I can't figure out what file changed.
>
> Here's the tail end of /var/log/messages | grep puppetserver, minus the 
> datestamps:
>
> :
> puppet puppetserver: at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> puppet puppetserver: at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> puppet puppetserver: at java.lang.Thread.run(Thread.java:748)
> puppet puppetserver: Background process 4918 exited before start had 
> completed
> puppet systemd: puppetserver.service: control process exited, code=exited 
> status=1
> puppet systemd: Failed to start puppetserver Service.
> puppet systemd: Unit puppetserver.service entered failed state.
> puppet systemd: puppetserver.service failed.
> puppet systemd: puppetserver.service holdoff time over, scheduling restart
> puppet systemd: Starting puppetserver Service...
> puppet puppetserver: OpenJDK 64-Bit Server VM warning: ignoring option 
> MaxPermSize=256m; support was removed in 8.0
>
> Any thoughts about where to look next for a solution, or at least a more 
> in-depth understanding of what's going on? This server has been in 
> operation for several years without any issues until we stomped something...
>
> 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/7a4aefa7-5e9f-4c98-a7e9-e97b8e2ab474%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet server stopped working

[Bret Wortman]

I accidentally ran puppet agent on our puppet master and now puppet server 
won't start up any more. Multiple reboots have failed to clear the 
situation and I can't figure out what file changed.

Here's the tail end of /var/log/messages | grep puppetserver, minus the 
datestamps:

:
puppet puppetserver: at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
puppet puppetserver: at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
puppet puppetserver: at java.lang.Thread.run(Thread.java:748)
puppet puppetserver: Background process 4918 exited before start had 
completed
puppet systemd: puppetserver.service: control process exited, code=exited 
status=1
puppet systemd: Failed to start puppetserver Service.
puppet systemd: Unit puppetserver.service entered failed state.
puppet systemd: puppetserver.service failed.
puppet systemd: puppetserver.service holdoff time over, scheduling restart
puppet systemd: Starting puppetserver Service...
puppet puppetserver: OpenJDK 64-Bit Server VM warning: ignoring option 
MaxPermSize=256m; support was removed in 8.0

Any thoughts about where to look next for a solution, or at least a more 
in-depth understanding of what's going on? This server has been in 
operation for several years without any issues until we stomped something...

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/39635033-2e37-49de-8e86-493c7829654a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Trouble translating Hiera 3 -> 5 config file

[Bret Wortman]

When run on the master querying a node that isn't the master:

# puppet lookup --node zw129 --explain sudo::disable_sssd
Merge strategy first
  Data Binding "hiera"
No such key: "sudo::disable_sssd"
  Data Provider "Environment Data Provider"
No such key: "sudo::disable_sssd"
  Module "sudo" using Data Provider "Module DataProvider"
No such key: "sudo::disable_sssd"
#

But I know from the way the manifest behaves on that system that this 
should return "true". Am I missing another parameter or option?


On Wednesday, May 31, 2017 at 5:56:48 AM UTC-4, Henrik Lindberg wrote:
>
> On 30/05/17 17:09, Bret Wortman wrote: 
> > I'm working on upgrading to the Hiera 5 spec and moving away from our 
> > global config, but to do that I need to first make sure I have a working 
> > H5 config file, so I set to translating our current one using the 
> > Puppetlabs documentation. 
> > 
> > I must be missing something critical because a slew of things get 
> > defined differently when I run with the H5 file so I haven't been able 
> > to cut over to it successfully yet. 
> > 
> > Hiera 3 version: 
> > --- 
> > :backends: 
> >- yaml 
> > 
> > :yaml: 
> >:datadir: 
> "/etc/puppetlabs/code/environments/%{::environment}/hieradata" 
> > 
> > :hierarchy: 
> >- "%{::hostname}" 
> >- "%{::sitename}" 
> >- common 
> > 
> > Hiera 5 version: 
> > --- 
> > version: 5 
> > defaults: 
> >datadir: hieradata 
> >data_hash: yaml_data 
> > hierarchy: 
> >- name: "Per-node data" 
> >  path: "%{facts.hostname}.yaml" 
> > 
> >- name: "Per-site data" 
> >  path: "%{facts.sitename}.yaml" 
> > 
> >- name: "Other data" 
> >  paths: 
> >- "common.yaml" 
> > 
> > --- 
> > 
> > Am I missing something simple? Is there a good way to test (and the 
> > "debugging hiera" page is pretty much useless if you're at this point 
> > and are using environments to store your hiera data). 
> > 
>
> You can test with the CLI 'puppet lookup --explain' - you probably want 
> to make sure your node has called in to the master first so the facts 
> are available for it, but can run for the current node as well. 
>
> You also get the explain style output in the puppet log if you are 
> running with debug level logging turned on when compiling a catalog. 
>
> - henrik 
>
> > -- 
> > You received this message because you are subscribed 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  
> > <mailto:puppet-users+unsubscr...@googlegroups.com >. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/ee507df8-8c6f-429a-9f95-a924b8c8960b%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/puppet-users/ee507df8-8c6f-429a-9f95-a924b8c8960b%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
You received this message because you are subscribed 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/770fb5ed-b8ac-410e-bb98-e04771f8861f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Trouble translating Hiera 3 -> 5 config file

[Bret Wortman]

I'm working on upgrading to the Hiera 5 spec and moving away from our 
global config, but to do that I need to first make sure I have a working H5 
config file, so I set to translating our current one using the Puppetlabs 
documentation.

I must be missing something critical because a slew of things get defined 
differently when I run with the H5 file so I haven't been able to cut over 
to it successfully yet.

Hiera 3 version:
---
:backends:
  - yaml

:yaml:
  :datadir: "/etc/puppetlabs/code/environments/%{::environment}/hieradata"

:hierarchy:
  - "%{::hostname}"
  - "%{::sitename}"
  - common

Hiera 5 version:
---
version: 5
defaults:
  datadir: hieradata
  data_hash: yaml_data
hierarchy:
  - name: "Per-node data"
path: "%{facts.hostname}.yaml"

  - name: "Per-site data"
path: "%{facts.sitename}.yaml"

  - name: "Other data"
paths:
  - "common.yaml"

---

Am I missing something simple? Is there a good way to test (and the 
"debugging hiera" page is pretty much useless if you're at this point and 
are using environments to store your hiera data).

-- 
You received this message because you are subscribed 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/ee507df8-8c6f-429a-9f95-a924b8c8960b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppetdb has not logged any new input in past 7 hours

[Bret Wortman]

BTW, that fixed it. Thanks!

On Wednesday, August 17, 2016 at 8:22:03 PM UTC-4, Bret Wortman wrote:
>
> I'd love to figure out how that changed on me, because your changes remind 
> me that it USED to look like that!
>
> Bret Wortman  
> http://wrapbuddies.co/
>
> On Aug 17, 2016, 8:01 PM -0400, Wyatt Alt , wrote:
>
> Hey Bret, sorry for the gap in communication. Try making these changes:
>
> * to the [master] section,
> storeconfigs=true
> storeconfigs_backend=puppetdb
> reports=puppetdb
>
> * to the [agent] section for each node, change "reports=puppetdb" to
> "report=true".
>
> I think that should straighten it out.
>
> Wyatt
>
>

-- 
You received this message because you are subscribed 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/fd1fa93f-3289-4f60-b60d-29a78fb77ee1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppetdb has not logged any new input in past 7 hours

[Bret Wortman]

I'd love to figure out how that changed on me, because your changes remind me 
that it USED to look like that!

Bret Wortman
http://wrapbuddies.co/

On Aug 17, 2016, 8:01 PM -0400, Wyatt Alt , wrote:
> Hey Bret, sorry for the gap in communication. Try making these changes:
>
> * to the [master] section,
> storeconfigs=true
> storeconfigs_backend=puppetdb
> reports=puppetdb
>
> * to the [agent] section for each node, change "reports=puppetdb" to
> "report=true".
>
> I think that should straighten it out.
>
> Wyatt

-- 
You received this message because you are subscribed 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/7c3c6be7-3ce8-440f-83d6-a74555e667ba%40Spark.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Need to move puppetdb database -- best approach?

[Bret Wortman]

Yeah, I realized this was a red herring and deleted the original post 
before writing the other you've been helping me with. I also realized that 
the contents of the directory indicated was so small that it couldn't be 
nearing a resource limitation. Thanks for the directions, though, I'll 
definitely file them away just in case.

On Wednesday, August 17, 2016 at 2:41:38 PM UTC-4, Wyatt Alt wrote:
>
>
>
> On 8/17/16 6:26 AM, Bret Wortman wrote:
>
>
> On Wednesday, August 17, 2016 at 9:19:34 AM UTC-4, Bret Wortman wrote: 
>>
>> I'll confess that I know next to nothing about Postgres databases, so I'm 
>> going to ask before I royally mess anything up: what's the best way to 
>> relocate my database from one partition to another? I need to move my files 
>> from their current location (which seems to be 
>> /opt/puppetlabs/server/data/puppetdb/mq/localhost to somewhere under /data. 
>> I know I'll need to shut puppetdb and postgresql down to do the move, but 
>> how do I ensure everything is available & ready when I need to bring things 
>> back up again? 
>>
>> The reason is that I'm getting messages in my puppetdb log files like 
>> this:
>>
>> Store limit is 102400 mb (current store usage is 10 mb). The data 
>> directory: /opt/puppetlabs/server/data/puppetdb/mq/localhost/KahaDB only 
>> ahs 20671 mb of usable space - resetting to maximum available disk space: 
>> 20682.
>>
>
> Before going down the road of moving postgres, note that this error isn't 
> actually talking about postgres, but rather PuppetDB's vardir, which is 
> used by activemq. Vardir can be changed with this parameter: 
> https://docs.puppet.com/puppetdb/latest/configure.html#vardir.
>
> The warning is saying you only have 20 gigs of space in your vardir, and 
> so the store limit will be reset to 20 gigs instead of the default of 100. 
> You can make the warning go away by setting this parameter to 20 gigs: 
> https://docs.puppet.com/puppetdb/latest/configure.html#store-usage, or 
> you can change the vardir parameter to point somewhere on /data, though the 
> queue will not generally get to 20 gigs unless something is very wrong 
> (note that you currently use 10mb). The warning is common and not generally 
> a big deal.
>
> If it happens that postgres is also on that 20 gig partition and you're 
> still worried about that, the process for moving the cluster would be
>
> * stop puppetdb and postgres
> * copy the postgres data directory (can be located with "show 
> data_directory;" run in psql) to the /data partition using cp -a, to keep 
> permissions
> * update the PGDATA variable in your postgres systemd unit file to point 
> to the new location
> * restart postgres + puppetdb
>
> If all goes well things will start up, and you can delete the original, 
> but you may have to work through some permissions issues to ensure that the 
> postgres user really can access the new location. I'd definitely recommend 
> testing the process first and somehow ensuring you're able to wind it back 
> easily.
>
> Wyatt
>
>
>> The /data partition is much larger and I won't have to worry about 
>> filling up my root partition this way.
>>
>> Thanks,
>>
>>
>> Bret
>>
> -- 
> You received this message because you are subscribed 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/a04a8c97-2047-4877-aa85-e259796d80cd%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/puppet-users/a04a8c97-2047-4877-aa85-e259796d80cd%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: [Puppet Users] Re: Puppetdb has not logged any new input in past 7 hours

[Bret Wortman]

https://gist.github.com/wortmanb/4896962accb5aa24bcb33b893f6ef477

On Wednesday, August 17, 2016 at 2:37:31 PM UTC-4, Wyatt Alt wrote:
>
> Can you post a gist of your master's full puppet.conf?
>

-- 
You received this message because you are subscribed 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/f9846873-407c-48d4-8cec-09096e9888d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppetdb has not logged any new input in past 7 hours

[Bret Wortman]

For a node I know has been updated, I get (just listing the timestamps):

"facts_timestamp" : "2016-08-17T17:52:33.899Z",

"report_timestamp" : "2016-08-16T21:15:22.376Z",
"catalog_timestamp" : "2016-08-16T21:14:24.444Z", 

 

So it seems that facts are being stored, but reports & catalogs aren't. The 
puppet.conf file on this (and all other clients) contains:

reports   = puppetdb


Is there something else I need to have set? I don't think we changed config 
this morning



On Wednesday, August 17, 2016 at 1:50:58 PM UTC-4, Wyatt Alt wrote:
>
> I'd check the timestamps in the output of
>
> curl -X GET http://localhost:8080/pdb/query/v4/nodes/fs1603.our.net
>
> (with a real certname if that one is fake). These will tell you when the 
> last report/facts/catalog for the node were stored.
>
> Nothing about the log output you've posted indicates an issue storing 
> data, so I'm wondering if the problem is with what puppet 
> explorer/puppetboard are considering an "update". For example maybe reports 
> got switched off and only reports are considered in that determination (I 
> have no idea if this is true).
>
> Wyatt
>
> On Wed, Aug 17, 2016 at 9:39 AM, Bret Wortman  > wrote:
>
>> Versions:
>>
>>
>> # rpm -qa | grep puppet
>> puppetserver-2.4.0-1.el7.noarch
>> puppetdb-4.2.0-1.el7.noarch
>> puppetexplorer-2.0.0-1.noarch
>> puppetdb-termini-4.2.0-1.el7.noarch
>> puppet-agent-1.6.0-1.el7.x86_64
>> # rpm -qa | grep postgres
>> postgresql95-libs-9.5.4-1PGDG.rhel7.x86_64
>> postgresql95-9.5.4-IPGDG.rhel7.x86_64
>> postgresql95-server-9.5.4-IPGDG.rhel7.x86_64
>> postgresql95-contrib-9.5.4-IPGDG.rhel7.x86_64
>> #
>>
>>
>> On Wednesday, August 17, 2016 at 12:37:12 PM UTC-4, Bret Wortman wrote:
>>>
>>> My puppetdb instance is up and running but hasn't stored any updates of 
>>> any kind in the past 7 hours, according to both Puppet Explorer and 
>>> Puppetboard.
>>>
>>> The process is running and so is postgres. Puppet configs haven't 
>>> changed in that time. /var/log/puppetlabs/puppetdb/puppetdb.log shows 
>>> plenty of updates coming in:
>>>
>>> 2016-08-17 16:31:48,887 INFO  [p.p.command] [-UUID-] [replace facts] 
>>> branfile1.our.net
>>> 2016-08-17 16:31:59,136 INFO  [p.p.command] [-UUID-] [replace facts] 
>>> zs311.our.net
>>> 2016-08-17 16:32:11,347 INFO  [p.p.command] [-UUID-] [replace facts] 
>>> gs1205.our.net
>>> 2016-08-17 16:32:12,982 WARN  [p.p.q.engine] The event-counts entity is 
>>> experimental and may be altered or removed in the future.
>>> 2016-08-17 16:32:15,237 INFO  [p.p.command] [-UUID-] [replace facts] 
>>> fs1603.our.net
>>>
>>>
>>> and so on.
>>>
>>> There's nothing obviously wrong when Puppetdb starts up in the logfile, 
>>> either. What should I be looking at to see why it's accepting these updates 
>>> but (apparently) not storing them? Does anyone know postgres better than I 
>>> do who could give me some way to directly query the database to see if one 
>>> of the above updates (or any other, for that matter) exists?
>>>
>>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/8a76426c-1da9-4d24-9ffe-ffc9d8cae59b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/8a76426c-1da9-4d24-9ffe-ffc9d8cae59b%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[Puppet Users] Puppetdb has not logged any new input in past 7 hours

[Bret Wortman]

My puppetdb instance is up and running but hasn't stored any updates of any 
kind in the past 7 hours, according to both Puppet Explorer and Puppetboard.

The process is running and so is postgres. Puppet configs haven't changed 
in that time. /var/log/puppetlabs/puppetdb/puppetdb.log shows plenty of 
updates coming in:

2016-08-17 16:31:48,887 INFO  [p.p.command] [-UUID-] [replace facts] 
branfile1.our.net
2016-08-17 16:31:59,136 INFO  [p.p.command] [-UUID-] [replace facts] 
zs311.our.net
2016-08-17 16:32:11,347 INFO  [p.p.command] [-UUID-] [replace facts] 
gs1205.our.net
2016-08-17 16:32:12,982 WARN  [p.p.q.engine] The event-counts entity is 
experimental and may be altered or removed in the future.
2016-08-17 16:32:15,237 INFO  [p.p.command] [-UUID-] [replace facts] 
fs1603.our.net


and so on.

There's nothing obviously wrong when Puppetdb starts up in the logfile, 
either. What should I be looking at to see why it's accepting these updates 
but (apparently) not storing them? Does anyone know postgres better than I 
do who could give me some way to directly query the database to see if one 
of the above updates (or any other, for that matter) exists?

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/c447df8c-a53e-4455-b8cc-de534b9f64bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppetdb has not logged any new input in past 7 hours

[Bret Wortman]

Versions:


# rpm -qa | grep puppet
puppetserver-2.4.0-1.el7.noarch
puppetdb-4.2.0-1.el7.noarch
puppetexplorer-2.0.0-1.noarch
puppetdb-termini-4.2.0-1.el7.noarch
puppet-agent-1.6.0-1.el7.x86_64
# rpm -qa | grep postgres
postgresql95-libs-9.5.4-1PGDG.rhel7.x86_64
postgresql95-9.5.4-IPGDG.rhel7.x86_64
postgresql95-server-9.5.4-IPGDG.rhel7.x86_64
postgresql95-contrib-9.5.4-IPGDG.rhel7.x86_64
#


On Wednesday, August 17, 2016 at 12:37:12 PM UTC-4, Bret Wortman wrote:
>
> My puppetdb instance is up and running but hasn't stored any updates of 
> any kind in the past 7 hours, according to both Puppet Explorer and 
> Puppetboard.
>
> The process is running and so is postgres. Puppet configs haven't changed 
> in that time. /var/log/puppetlabs/puppetdb/puppetdb.log shows plenty of 
> updates coming in:
>
> 2016-08-17 16:31:48,887 INFO  [p.p.command] [-UUID-] [replace facts] 
> branfile1.our.net
> 2016-08-17 16:31:59,136 INFO  [p.p.command] [-UUID-] [replace facts] 
> zs311.our.net
> 2016-08-17 16:32:11,347 INFO  [p.p.command] [-UUID-] [replace facts] 
> gs1205.our.net
> 2016-08-17 16:32:12,982 WARN  [p.p.q.engine] The event-counts entity is 
> experimental and may be altered or removed in the future.
> 2016-08-17 16:32:15,237 INFO  [p.p.command] [-UUID-] [replace facts] 
> fs1603.our.net
>
>
> and so on.
>
> There's nothing obviously wrong when Puppetdb starts up in the logfile, 
> either. What should I be looking at to see why it's accepting these updates 
> but (apparently) not storing them? Does anyone know postgres better than I 
> do who could give me some way to directly query the database to see if one 
> of the above updates (or any other, for that matter) exists?
>
> 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/8a76426c-1da9-4d24-9ffe-ffc9d8cae59b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Need to move puppetdb database -- best approach?

[Bret Wortman]

I got to looking at the storage issue because it also seems that no new 
reports have been recorded in over 4 hours, when my nodes have definitely 
been accessing puppet and completing agent runs during this same time.

On Wednesday, August 17, 2016 at 9:19:34 AM UTC-4, Bret Wortman wrote:
>
> I'll confess that I know next to nothing about Postgres databases, so I'm 
> going to ask before I royally mess anything up: what's the best way to 
> relocate my database from one partition to another? I need to move my files 
> from their current location (which seems to be 
> /opt/puppetlabs/server/data/puppetdb/mq/localhost to somewhere under /data. 
> I know I'll need to shut puppetdb and postgresql down to do the move, but 
> how do I ensure everything is available & ready when I need to bring things 
> back up again?
>
> The reason is that I'm getting messages in my puppetdb log files like this:
>
> Store limit is 102400 mb (current store usage is 10 mb). The data 
> directory: /opt/puppetlabs/server/data/puppetdb/mq/localhost/KahaDB only 
> ahs 20671 mb of usable space - resetting to maximum available disk space: 
> 20682.
>
> The /data partition is much larger and I won't have to worry about filling 
> up my root partition this way.
>
> Thanks,
>
>
> Bret
>

-- 
You received this message because you are subscribed 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/a04a8c97-2047-4877-aa85-e259796d80cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Need to move puppetdb database -- best approach?

[Bret Wortman]

I'll confess that I know next to nothing about Postgres databases, so I'm 
going to ask before I royally mess anything up: what's the best way to 
relocate my database from one partition to another? I need to move my files 
from their current location (which seems to be 
/opt/puppetlabs/server/data/puppetdb/mq/localhost to somewhere under /data. 
I know I'll need to shut puppetdb and postgresql down to do the move, but 
how do I ensure everything is available & ready when I need to bring things 
back up again?

The reason is that I'm getting messages in my puppetdb log files like this:

Store limit is 102400 mb (current store usage is 10 mb). The data 
directory: /opt/puppetlabs/server/data/puppetdb/mq/localhost/KahaDB only 
ahs 20671 mb of usable space - resetting to maximum available disk space: 
20682.

The /data partition is much larger and I won't have to worry about filling 
up my root partition this way.

Thanks,


Bret

-- 
You received this message because you are subscribed 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/0e1c6c98-7b85-489e-aca6-57c975b1a51e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Service entry for puppet agents not working

[Bret Wortman]

They matched. Good thought, though.



*Bret Wortman*
http://wrapbuddies.co/
<http://wrapbuddies.co/>

On Tue, Aug 9, 2016 at 9:11 AM, Rob Nelson  wrote:

>
> On Tue, Aug 9, 2016 at 8:51 AM, Bret Wortman  wrote:
>
>> What I failed to mention before is that the failure scenario is that I'll
>> get a "Could not evaluate: Could not retrieve file metadata for
>> puppet:///modules/ourlib/pip.conf: end of file reached"
>>
>
> Maybe try adding something like "/usr/bin/ruby/usr/bin/puppet config print
> modulepath > /root/puppet.debug" to cron and compare it with the results
> you get when you run that interactively. It's possible that there's some
> difference due to the cron environment, which I always find tricky to
> debug, but I think it's best to determine if it's an issue at all before
> banging your head against that wall. Just grasping at straws here,
> admittedly.
>
>
> Rob Nelson
> rnels...@gmail.com
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/puppet-users/HC2knEe4HKw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/CAC76iT_uA8qtfRaHhzALUHL2DfyRX%
> 2Bxau7kFiagxHtVxh3UFGA%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAC76iT_uA8qtfRaHhzALUHL2DfyRX%2Bxau7kFiagxHtVxh3UFGA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

[Puppet Users] Re: Service entry for puppet agents not working

[Bret Wortman]

In trying to work out the environmental differences, I _have_ noticed that 
the daemon runs as the puppet user, but when I run it interactively, it 
runs as root. As root, it works, as puppet, it works, but from root's 
crontab, it doesn't.

What I failed to mention before is that the failure scenario is that I'll 
get a "Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/ourlib/pip.conf: end of file reached". It's always the 
same file, but that file works just fine for most hosts and works as 
described above. It's just that root's crontab doesn't play nice on some 
systems. Scratching my head.

On Monday, August 8, 2016 at 8:40:24 AM UTC-4, Bret Wortman wrote:
>
> We've been using cron to manage our puppet agents for the past few years 
> but have discovered some issues where it's running under a different 
> environment and is having trouble completing when run in cron, but it works 
> fine as a daemon or from the command line. So I'm preparing to switch over.
>
> Unfortunately, the following doesn't work for my 3.8.6 agents on Centos 6 
> systems even though it works fine for 4.3 agents:
>
> service { "puppet":
> ensure => running,
> enable => true,
> hasstatus => true,
> hasrestart => true,
> }
>
>
> What we see on some agents is that puppet will restart the service each 
> and every time it runs, which gives us lots of false "changes".
>
> # service puppet status
> puppet dead but pid file exists
> # ps aux | grep puppet | grep agent
> root  9879  0.0  0.0 134404 43516 ?   Ss 12:220:00 
> /usr/bin/ruby/usr/bin/puppet agent
>
>
> Has anyone else seen this or know of a workaround? I've tried various ways 
> of providing a "status => " command but haven't found anything that works 
> 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/60e9ca91-f7a0-4ac3-a94a-791d31184d49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Service entry for puppet agents not working

[Bret Wortman]

The affected node (or, at least, the one I'm looking at) doesn't actually
have rundir set. The hunt for a rational explanation and ideal solution
goes on. :-)

Thanks, Rob!



*Bret Wortman*
http://wrapbuddies.co/
<http://wrapbuddies.co/>

On Mon, Aug 8, 2016 at 12:07 PM, Rob Nelson  wrote:

>
> On Mon, Aug 8, 2016 at 11:09 AM, Bret Wortman 
> wrote:
>
>> Yep, it's not finding the pidfile because the init script is looking in
>> /var/run/puppet/agent.pid and the daemon is putting it at
>> /var/lib/puppet/run/agent.pid. So for now I'm going to modify the init
>> script wherever we are having this problem.
>
>
> We saw this issue when we performed an upgrade and the puppet.conf file's
> rundir was different than where the services file was looking for the .pid
> file. The recommendation was to remove the rundir setting from puppet.conf,
> as the default location was the same as what the service file expected,
> rather than to hardcode it to the correct value, in case it changed in the
> future.
>
>
> Rob Nelson
> rnels...@gmail.com
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/puppet-users/HC2knEe4HKw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-users/CAC76iT-%2BkkFUeB3W%2BGwfmMyqW6-
> tGJuhbESnj8txJCRZpSQcWw%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAC76iT-%2BkkFUeB3W%2BGwfmMyqW6-tGJuhbESnj8txJCRZpSQcWw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[Puppet Users] Re: Service entry for puppet agents not working

[Bret Wortman]

Yep, it's not finding the pidfile because the init script is looking in 
/var/run/puppet/agent.pid and the daemon is putting it at 
/var/lib/puppet/run/agent.pid. So for now I'm going to modify the init 
script wherever we are having this problem.

We're upgrading the systems as we update them to Centos7.

I don't know what it is about the environment that's different. That'll be 
an investigation for another day. The change to cron was basically to 
spread out our agent communication load throughout the hour (we were only 
having them check in hourly -- for us, that's plenty). This started as a 
way to figure out if there was somehow something different in the 
environments. I think there is. Just need to figure out what it is now.

Thanks!


On Monday, August 8, 2016 at 8:40:24 AM UTC-4, Bret Wortman wrote:
>
> We've been using cron to manage our puppet agents for the past few years 
> but have discovered some issues where it's running under a different 
> environment and is having trouble completing when run in cron, but it works 
> fine as a daemon or from the command line. So I'm preparing to switch over.
>
> Unfortunately, the following doesn't work for my 3.8.6 agents on Centos 6 
> systems even though it works fine for 4.3 agents:
>
> service { "puppet":
> ensure => running,
> enable => true,
> hasstatus => true,
> hasrestart => true,
> }
>
>
> What we see on some agents is that puppet will restart the service each 
> and every time it runs, which gives us lots of false "changes".
>
> # service puppet status
> puppet dead but pid file exists
> # ps aux | grep puppet | grep agent
> root  9879  0.0  0.0 134404 43516 ?   Ss 12:220:00 
> /usr/bin/ruby/usr/bin/puppet agent
>
>
> Has anyone else seen this or know of a workaround? I've tried various ways 
> of providing a "status => " command but haven't found anything that works 
> 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/4affc1bf-5721-4883-822f-61e9e007c162%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Service entry for puppet agents not working

[Bret Wortman]

We've been using cron to manage our puppet agents for the past few years 
but have discovered some issues where it's running under a different 
environment and is having trouble completing when run in cron, but it works 
fine as a daemon or from the command line. So I'm preparing to switch over.

Unfortunately, the following doesn't work for my 3.8.6 agents on Centos 6 
systems even though it works fine for 4.3 agents:

service { "puppet":
ensure => running,
enable => true,
hasstatus => true,
hasrestart => true,
}


What we see on some agents is that puppet will restart the service each and 
every time it runs, which gives us lots of false "changes".

# service puppet status
puppet dead but pid file exists
# ps aux | grep puppet | grep agent
root  9879  0.0  0.0 134404 43516 ?   Ss 12:220:00 
/usr/bin/ruby/usr/bin/puppet agent


Has anyone else seen this or know of a workaround? I've tried various ways 
of providing a "status => " command but haven't found anything that works 
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/5ae7de27-705f-4856-aa07-68449af7385a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: File_line only if the file exists

[Bret Wortman]

I know that file_line should autorequire the file since it's being managed, 
so the "require"s aren't strictly necessary.

To test for the file's existence, you'll need to write a custom fact. See 
this for 
suggestions: 
http://stackoverflow.com/questions/18784329/how-to-test-for-existence-of-a-file-on-the-puppet-master


Bret

On Friday, July 8, 2016 at 1:01:28 PM UTC-4, mike r wrote:
>
> Quick question, Im writing a module that makes sure file_line exists but 
> cant figure out how to only apply this if the target file exists, heres the 
> module so far
>
>
> $file = '/etc/modprobe.d/CIS.conf'
>
> file { $file :
>   ensure => file,
>   mode   => '0600',
>   owner  => 'root',
>   group  => 'root',
> }
>
>
> file_line { "(1.1.18) ${file} - cramfs":
>   ensure  => present,
>   path=> $file,
>   line=> 'install cramfs /bin/true',
>   require => File[$file],
> }
>
> file_line { "(1.1.19) ${file} - freevxfs":
>   ensure  => present,
>   path=> $file,
>   line=> 'install freevxfs /bin/true',
>   require => File[$file],
> }
>
>
> I added the Require for each file_line but when I test on a node I get 
> this, 
>
> *Notice: 
> /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File[/etc/modprobe.d/CIS.conf]/ensure:
>  
> current_value absent, should be file (noop)*
>
>
> *Error: /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File_line[(1.1.18) 
> /etc/modprobe.d/CIS.conf - cramfs]: Could not evaluate: No such file or 
> directory @ rb_sysopen - /etc/modprobe.d/CIS.confError: 
> /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File_line[(1.1.19) 
> /etc/modprobe.d/CIS.conf - freevxfs]: Could not evaluate: No such file or 
> directory @ rb_sysopen - /etc/modprobe.d/CIS.confError: 
> /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File_line[(1.1.20) 
> /etc/modprobe.d/CIS.conf - jffs2]: Could not evaluate: No such file or 
> directory @ rb_sysopen - /etc/modprobe.d/CIS.conf*
> Error: /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File_line[(1.1.21) 
> /etc/modprobe.d/CIS.conf - hfs]: Could not evaluate: No such file or 
> directory @ rb_sysopen - /etc/modprobe.d/CIS.conf
> Error: /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File_line[(1.1.22) 
> /etc/modprobe.d/CIS.conf - hfsplus]: Could not evaluate: No such file or 
> directory @ rb_sysopen - /etc/modprobe.d/CIS.conf
> Error: /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File_line[(1.1.23) 
> /etc/modprobe.d/CIS.conf - squashfs]: Could not evaluate: No such file or 
> directory @ rb_sysopen - /etc/modprobe.d/CIS.conf
> Error: /Stage[main]/Cis_rhel7::Rule::Rule_1_1_18/File_line[(1.1.24) 
> /etc/modprobe.d/CIS.conf - udf]: Could not evaluate: No such file or 
> directory @ rb_sysopen - /etc/modprobe.d/CIS.conf
> Info: Class[Cis_rhel7::Rule::Rule_1_1_18]: Unscheduling all events on 
> Class[Cis_rhel7::Rule::Rule_1_1_18]
>
> All my resources are have a resource default of NOOP, since Im doing a 
> compliance check. Cant figure out how to make File_line only get applied if 
> the file exists. 
>

-- 
You received this message because you are subscribed 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/e3d4ac1a-7249-473f-a65f-4cc555f7946b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Guidelines on setting http_keepalive_timeout

[Bret Wortman]

I've got a very, very flaky network and many remote hosts which phone home 
hourly to pick up puppet updates. Some will complete really quickly, others 
can take minutes for a do-nothing agent run. My server is 4.3 and clients 
are mostly 3.8.6 but some are 4.3 as well. A mix of Centos (6 & 7) and 
Fedora (21+).

Every so often, I get the "Could not retrieve file metadata for ... :end of 
file reached" error on clients. It's usually random -- some will run fine 
for a days, then suddenly exhibit this once or twice, then be fine again.

To try to get to a state where my errors actually mean something, I started 
cranking up the http_keepalive_timeout value. I'll readily admit that I'm 
not sure I completely understand how to bound it. I started at 30s, went to 
3m, and am now sitting on 30m on the server, 29m on agents.

How big should this be? Enough to encapsulate a complete successful run or 
the expected duration of a single file request? What's the downside of 
cranking this up? The affected file has changed since I raised the value so 
I think it's having some affect, but I'm also seeing more failures (though 
that may be a red herring if our network is acting up today).

What's a good guideline for properly settting this value?


-- 
You received this message because you are subscribed 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/0fd32cf6-c4d4-46f4-8642-f200b0379db4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: How can I install puppetexplorer by hand?

[Bret Wortman]

Adding this here for the next guy who forgets the simple things:

# puppet agent -t --tags puppetexplorer


Worked like a champ. I checked my current /etc/httpd config into a git 
repo, ran the above, examined all the diffs, and recycled httpd when I was 
happy. It's now working great.


On Wednesday, July 13, 2016 at 10:04:39 AM UTC-4, Bret Wortman wrote:
>
> I've got an existing server running Puppet, PuppetDB, puppetboard and a 
> handful of other apache-based services. As this is our lone Puppet server, 
> I'm hesitant to use puppet to configure itself as that just seems 
> problematic should I ever completely hose something up.
>
> Anyway, all our apache files are hand-setup so I'm heistant to use the 
> spotify-puppetexplorer module since it relies on puppet-apache to set 
> things up. Can anyone give some guidance about what is meant, on the github 
> page for the project, by this: "Then proxy /api to port 8080 of your 
> PuppetDB instance (except the /commands endpoint)."? I've added this file 
> to my apache config and while the proxying appears to work, it's giving me 
> a "Testing 123" apache page:
>
> 
> ServerName pe.internal.net
> ProxyPass /api http://127.0.0.1:8080/
> 
>
> I installed puppetexplorer-2.0.0 from rpm. At present, I don't appear to 
> have anything listening on port 8080 according to netstat, but lsof gives 
> this:
>
> # lsof -i:8080
> COMMANDPID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
> java26581  puppetdb   18u  IPv6 14596869  0t0  TCP 
> localhost:webcache (LISTEN)
> httpd   27652apache   13u  IPv4 15705226  0t0  TCP 
> localhost:33704->localhost:webcache (CLOSE_WAIT)
> httpd   27662apache   13u  IPv4 15700933  0t0  TCP 
> localhost:33687->localhost:webcache (CLOSE_WAIT)
>
> What am I missing to get this working? I can see that everything installed 
> under /usr/share/puppetexplorer -- am I right in thinking my VirtualHost 
> entry needs to specify that in a  ?
>
> Or should I just back up everything under /etc/httpd and give the 
> installation module a go? It looks like it was going to wreak holy havoc 
> with our httpd.conf file
>

-- 
You received this message because you are subscribed 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/29b41298-8203-466f-9734-2c44c23f5464%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] How can I install puppetexplorer by hand?

[Bret Wortman]

I've got an existing server running Puppet, PuppetDB, puppetboard and a 
handful of other apache-based services. As this is our lone Puppet server, 
I'm hesitant to use puppet to configure itself as that just seems 
problematic should I ever completely hose something up.

Anyway, all our apache files are hand-setup so I'm heistant to use the 
spotify-puppetexplorer module since it relies on puppet-apache to set 
things up. Can anyone give some guidance about what is meant, on the github 
page for the project, by this: "Then proxy /api to port 8080 of your 
PuppetDB instance (except the /commands endpoint)."? I've added this file 
to my apache config and while the proxying appears to work, it's giving me 
a "Testing 123" apache page:


ServerName pe.internal.net
ProxyPass /api http://127.0.0.1:8080/


I installed puppetexplorer-2.0.0 from rpm. At present, I don't appear to 
have anything listening on port 8080 according to netstat, but lsof gives 
this:

# lsof -i:8080
COMMANDPID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
java26581  puppetdb   18u  IPv6 14596869  0t0  TCP 
localhost:webcache (LISTEN)
httpd   27652apache   13u  IPv4 15705226  0t0  TCP 
localhost:33704->localhost:webcache (CLOSE_WAIT)
httpd   27662apache   13u  IPv4 15700933  0t0  TCP 
localhost:33687->localhost:webcache (CLOSE_WAIT)

What am I missing to get this working? I can see that everything installed 
under /usr/share/puppetexplorer -- am I right in thinking my VirtualHost 
entry needs to specify that in a  ?

Or should I just back up everything under /etc/httpd and give the 
installation module a go? It looks like it was going to wreak holy havoc 
with our httpd.conf file

-- 
You received this message because you are subscribed 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/315f429f-8bd4-49e7-a99f-1a60f40d28c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Bret Wortman]

Nope. I'm good. This is working like a champ now.

Thanks, John!



*Bret Wortman*
http://wrapbuddies.co/
<http://wrapbuddies.co/>

On Thu, Jun 30, 2016 at 9:05 AM, jcbollinger 
wrote:

>
>
> On Wednesday, June 29, 2016 at 8:57:51 AM UTC-5, Bret Wortman wrote:
>>
>> I like that, John. Titles are guaranteed to be unique or the catalog
>> won't compile, right? This is absolutely supposed to be a one-and-only-one
>> kind of thing, so using title makes much more sense.
>>
>
>
> Yes, all resource titles used in a single catalog-building run must be
> unique for their types(*) with respect to that catalog-building run --
> those of ordinary resources, those of virtual resources (even if not
> realized), those of exported resources declared (even if not collected),
> and those of other nodes' exported resources that are collected into the
> catalog.  A parallel uniqueness requirement applies to resource names,
> which are not always the same as their resources' titles.  A duplicate
> resource (type, title) or (type, name) will cause catalog compilation to
> fail.  If you want to be certain, however, then by all means write a test
> for that case.
>
> (*) Except for the Exec resource type.
>
>
> John
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/x7DmiOtbrTY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/abff9c5e-27c9-4f32-8bb2-6135046cdb17%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/abff9c5e-27c9-4f32-8bb2-6135046cdb17%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

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

[Bret Wortman]

I like that, John. Titles are guaranteed to be unique or the catalog won't
compile, right? This is absolutely supposed to be a one-and-only-one kind
of thing, so using title makes much more sense.

Thanks for the tip -- I'll write it up and do some testing later today
before swapping it for the hiera-dependent version.




*Bret Wortman*
http://wrapbuddies.co/
<http://wrapbuddies.co/>

On Wed, Jun 29, 2016 at 9:06 AM, jcbollinger 
wrote:

>
>
> On Tuesday, June 28, 2016 at 9:56:52 AM UTC-5, Bret Wortman wrote:
>>
>> Here's what I'm trying to do, and I know there's a better way most likely
>> involving exported resources, but I haven't done much with them before.
>>
>> I've got two types of nodes deploying custom software which Puppet is
>> setting up for us. Slave nodes have a config file which gets deployed via
>> template, and which needs to know the master node's fqdn. There is one
>> master, and it varies by subnet. Any given subnet will only have one.
>>
>> Right now, I'm defining the master in a .yaml file in our Hiera hierarchy
>> so that each system on a subnet knows about the master. The twist is that
>> the decision to deploy master or slave code is made through a custom fact
>> which knows about the roles a particular system is supposted to have and
>> installs the requisite software. So if no one tells me they're deploying a
>> new subnet, all the slaves get deployed without a master and puppet has to
>> play catch-up until I get it defined in hiera, and nothing works in the
>> meantime.
>>
>> Is the correct approach to have the config defined as an exported
>> resource from the master, and have it get collected and realized on the
>> slaves?
>>
>
>
> Exported resources were the first thing I thought of as I read the
> description of your requirements.
>
>
>
>> Something like this:
>>
>> master.pp:
>>
>> @@masternode { $fqdn:
>> # $subnet is a custom fact
>> subnet => $subnet,
>> }
>>
>> masternode.pp:
>>
>> define masternode (Integer $subnet) {
>> file  { '/path/to/config':
>> content => template('module/config.erb')
>> mode => '755',
>>}
>> }
>>
>> slave.pp:
>>
>> Masternode<| subnet = $subnet |>
>>
>> Does that look right, or am I completely off the rails?
>>
>>
>
> That looks reasonable, +/- a couple of minor syntax errors.
>
> If the only physical resource you anticipate a Masternode managing is a
> single File, however, then I would consider exporting the file directly,
> making use of the ability to have a title different from the file's path:
>
> Mater node:
>
> @@file { "master-config-$subnet":
>   path=> '/path/to/config',
>   content => template('module/config.erb'),
>   user=> 'root',
>   group   => 'root',
>   mode=> '755',
> }
>
>
> Slave node:
>
> File<| title == "master-config-$subnet" |>
>
>
> Note, too, that if slave nodes on the same subnet need to be configured
> with information about each other, or if the master needs information about
> the slaves, then exported resources may again serve you.  A good trick in
> cases like those is to manually apply tags to your exported resources to
> distinguish those in one group (subnet) from those in another, and then to
> use that to filter resources when you collect them.  I could have done that
> with the above File example, too, but for collecting a single resource with
> (or that can have) a known title, I prefer to filter by title.
>
>
> John
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/x7DmiOtbrTY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/b8390e69-de73-461e-aa20-b04d48f29222%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/b8390e69-de73-461e-aa20-b04d48f29222%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

[Puppet Users] Question about custom exported resource

[Bret Wortman]

Here's what I'm trying to do, and I know there's a better way most likely 
involving exported resources, but I haven't done much with them before. 

I've got two types of nodes deploying custom software which Puppet is 
setting up for us. Slave nodes have a config file which gets deployed via 
template, and which needs to know the master node's fqdn. There is one 
master, and it varies by subnet. Any given subnet will only have one.

Right now, I'm defining the master in a .yaml file in our Hiera hierarchy 
so that each system on a subnet knows about the master. The twist is that 
the decision to deploy master or slave code is made through a custom fact 
which knows about the roles a particular system is supposted to have and 
installs the requisite software. So if no one tells me they're deploying a 
new subnet, all the slaves get deployed without a master and puppet has to 
play catch-up until I get it defined in hiera, and nothing works in the 
meantime.

Is the correct approach to have the config defined as an exported resource 
from the master, and have it get collected and realized on the slaves? 
Something like this:

master.pp:

@@masternode { $fqdn:
# $subnet is a custom fact
subnet => $subnet,
}

masternode.pp:

define masternode (Integer $subnet) {
file  { '/path/to/config':
content => template('module/config.erb')
mode => '755',
   }
}

slave.pp:

Masternode<| subnet = $subnet |>

Does that look right, or am I completely off the rails?

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/b6e394d0-1431-4731-aade-d41a7d0be16a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Git Repo Strategy

[Bret Wortman]

I made the conversion a little over a year ago and it's been a dream ever 
since. The Puppetfiles aren't that hard -- We store each module in its own 
repo and use branches to determine environments. For each new environment 
we want to use, we just branch the "puppet" repo which contains the 
Puppetfile and let it know which modules will be under test for this 
environment. It's a lot simpler than it sounds.

On Wednesday, June 15, 2016 at 11:27:28 AM UTC-4, broncosd183 wrote:
>
> Awesome thanks for the feedback and options Rich and Christopher. I'm 
> outlining a plan of attack now and going to make a pass at installing R10k 
> and configuring it correctly. The main hurdle was the puppetfile and its 
> dependencies; however, that looks much more feasible now.
>
> On Friday, June 10, 2016 at 10:56:03 AM UTC-4, Rich Burroughs wrote:
>>
>> I'm assuming this could be done. We're talking about UNIX she'll commands 
>> and there's a way to do just about anything. But I can't imagine it being 
>> simple or fun to use. Like could you do Pull Requests on Github between 
>> these repos? Maybe, depending on how you set it up. People nowadays 
>> recommend against monolithic repos too, and that's what you'd have. You'd 
>> just have a bunch of them.
>>
>> The normal recommended workflow with r10k is using branches for those 
>> environments, not separate repos. Then you have the ability to merge 
>> between branches, so it's easy to promote those changes along your pipeline.
>>
>> I remember back before I started using r10k, it seemed very confusing to 
>> me. I think there's a bit more info out about it now. In terms of getting a 
>> Puppetfile setup, one of the hard things there is that you need to account 
>> for all of the dependencies. Rob Nelson made this cool Ruby gem that makes 
>> generating the file a bit easier. You can pass it a set of Forge modules 
>> and it will also include their dependencies:
>>
>>
>> https://github.com/rnelson0/puppet-generate-puppetfile/blob/master/README.md
>>
>> It's pretty slick.
>>
>> Personally I'd recommend you stick it out and figure out how to make r10k 
>> work for what you're doing. I would bet you'd be glad you did after. If you 
>> have problems ask specific question here or IRC or Slack. There are a lot 
>> of people using it now and there should be lots who can help.
>>
>>
>> Rich 
>> On Fri, Jun 10, 2016 at 7:34 AM Funsaized  wrote:
>>
>>> Hello, 
>>>
>>> I am relatively new to puppet and am trying to develop a good workflow 
>>> in conjunction with git/github to keep a better version control system. The 
>>> version of puppet that I am working with and has been implemented is a bit 
>>> dated, and using R10k and developing a puppetfile would be quite time 
>>> consuming. I know that R10k and dynamic environments is the recommended way 
>>> of doing things, though for now I'm not sure if its the best for my 
>>> scenario and how everything has been previously set up. My question is is 
>>> there a simple way to just map one git repo for each environment (dev, QA, 
>>> production, etc). That way changes could be made in the dev environment, 
>>> then moved over to the correct repos when the changes are confirmed in 
>>> order? Would this be as simple as declaring each folder withing the 
>>> /puppet/environments folder as a git repo and controlling that way? 
>>>
>>> Deployment strategy
>>>
>>> -   Upload changes to Dev repo
>>>
>>> -   Deploy Dev changes to Dev master
>>>
>>> -   Test
>>>
>>> -   Merge Dev changes to QA repo
>>>
>>> -   Rinse and repeat
>>>
>>> -- 
>>> You received this message because you are subscribed 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/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

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

[Puppet Users] Re: Puppetserver & puppetdb setup: "Path does not chain with any of the trust anchors"

[Bret Wortman]

I brought the puppetdb module and dependencies over to our development 
network and tried using it. All goes well until it tries to connect:

Notice: Unable to connect to puppetdb server 
(https://puppet.internal.net:8081): SSL_connect returned=1 errno=0 
state=error: certificate verify failed: [unable to get local issuer 
certificate for /CN=puppet.internal.net]
Notice: Failed to connect to puppetdb; sleeping 2 seconds before retry

And this just loops. Does this point to a problem with puppetserver or 
puppetdb?


On Wednesday, June 15, 2016 at 10:20:07 AM UTC-4, Bret Wortman wrote:
>
> I've installed postgresql and it's working with razor just fine. I 
> followed the puppetdb setup instructions for installing it from packages 
> and all looks good *except* that when puppetserver tries to connect to 
> it, the logs show a variety of java stack traces where the root cause 
> appears to be the above message.
>
> The puppetdb and puppetserver (and razor) are all running on the same 
> host, called "puppet". I can telnet to puppet port 8081 and something looks 
> like it answers. I don't get bounced from the port immediately, anyway. 
> When I browse to it, I get a certificate error in chrome, "...the 
> authenticity of the received data could not be verified."
>
> And, of course, my clients all fail:
>
> :
> Info: Loading facts
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Failed to execute 
> '/pdb/cmd/v1?checksum=7afbbb51c169c25ffede98f9bde4d456615392e7' on any of 
> the following 'server_urls': https://puppet.internal.net:8081
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> On the server:
>
> # cat /etc/puppetlabs/puppetdb.conf
> [main]
> server_urls=https://puppet.internal.net:8081
>
> [database]
> classname=org.postgresql.Driver
> subprotocol=postgresql
> subname=//puppet.internal.net:5432/puppetdb
> username=[username]
> password=[password]
> # cat puppet.conf
> [master]
> :
> storeconfigs = true
> storeconfigs_backend = puppetdb
>
> [agent]
> classfile = $vardir/classes.txt
> localconfig = $vardir/localconfig
> reports = puppetdb
> pluginsync = true
> http_keepalive_timeout = 30
> # ls /etc/puppetlabs/puppetdb/ssl
> ca.pem  private.pem  public.pem
> # lsof -i:8081
> COMMAND  PIDUSER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> java5151 puppetdb  33u  IPv6 887988  0t0 TCP 
> puppet.internal.net:tproxy (LISTEN)
> # netstat -a | grep 8081
> # netstat -a | grep 8080
> #
>
> Those last two have me confused, but I'm not sure they're indicative of a 
> problem. Anyone seen this before or have any idea where to look next? 
>
>

-- 
You received this message because you are subscribed 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/ce6ff671-329c-400f-acf2-09333a83f489%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppetserver & puppetdb setup: "Path does not chain with any of the trust anchors"

[Bret Wortman]

I've installed postgresql and it's working with razor just fine. I followed 
the puppetdb setup instructions for installing it from packages and all 
looks good *except* that when puppetserver tries to connect to it, the logs 
show a variety of java stack traces where the root cause appears to be the 
above message.

The puppetdb and puppetserver (and razor) are all running on the same host, 
called "puppet". I can telnet to puppet port 8081 and something looks like 
it answers. I don't get bounced from the port immediately, anyway. When I 
browse to it, I get a certificate error in chrome, "...the authenticity of 
the received data could not be verified."

And, of course, my clients all fail:

:
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Failed to execute 
'/pdb/cmd/v1?checksum=7afbbb51c169c25ffede98f9bde4d456615392e7' on any of 
the following 'server_urls': https://puppet.internal.net:8081
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

On the server:

# cat /etc/puppetlabs/puppetdb.conf
[main]
server_urls=https://puppet.internal.net:8081

[database]
classname=org.postgresql.Driver
subprotocol=postgresql
subname=//puppet.internal.net:5432/puppetdb
username=[username]
password=[password]
# cat puppet.conf
[master]
:
storeconfigs = true
storeconfigs_backend = puppetdb

[agent]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
reports = puppetdb
pluginsync = true
http_keepalive_timeout = 30
# ls /etc/puppetlabs/puppetdb/ssl
ca.pem  private.pem  public.pem
# lsof -i:8081
COMMAND  PIDUSER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java5151 puppetdb  33u  IPv6 887988  0t0 TCP 
puppet.internal.net:tproxy (LISTEN)
# netstat -a | grep 8081
# netstat -a | grep 8080
#

Those last two have me confused, but I'm not sure they're indicative of a 
problem. Anyone seen this before or have any idea where to look next? 

-- 
You received this message because you are subscribed 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/5f6e7eac-ff49-4b3f-9ada-4bb32a18652f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re-enrolling clients after major version upgrade

[Bret Wortman]

Well, I _thought_ it helped. Many systems are connecting fine, others are 
still getting a different ca.pem file. I suspect for some reason the server 
is getting its copy overwritten somehow. I'm going to keep an eye on it now.

On Tuesday, June 14, 2016 at 10:07:13 AM UTC-4, Bret Wortman wrote:
>
> I did the following (which I'd done before) and it seems to have helped:
>
> # puppet resource service upppetserver ensure=stopped
> # rm -rf /etc/puppetlabs/puppet/ssl
> # puppet cert list -a
> # puppet master --no-daemonize --verbose
> ^C
> # puppet resource servcie puppetserver ensure=running
> #
>
>
>
> On Tuesday, June 14, 2016 at 9:50:44 AM UTC-4, Christopher Wood wrote:
>>
>> To your specific issue, it looks like your agent's CA cert doesn't match 
>> the issuer of the new puppetmaster's CA cert ("unable to get local issuer 
>> certificate"). If I recall correctly, an agent without a CA cert will 
>> download one from the puppetmaster the first time and thereafter check it. 
>> You might check the cert chains to see what's going on, or if you 
>> downloaded the CA cert at all. 
>>
>> Otherwise I noticed this bit: 
>>
>> # rpm -rf /var/lib/puppet/ssl /etc/puppet/ssl /etc/puppetlabs/puppet/ssl 
>> # ssh puppet puppet cert list host.internal.net 
>> Error: Could not find a certificate for host.internal.net 
>>
>> Is it supposed to say rpm not rm? I Presume it's just the logging which 
>> is removing the quotes too. 
>>
>> Rhubarbing more generally, I had some success syncing the ssl directory 
>> during our own 3->4 update. I never found a reason to use a new cert for 
>> the same host when I already had one. 
>>
>> file { '/etc/puppetlabs/puppet/ssl': 
>>   ensure   => directory, 
>>   backup   => false, 
>>   recurse  => true, 
>>   recurselimit => 99, 
>>   require  => Package[$package], 
>>   source   => '/var/lib/puppet/ssl', 
>> } 
>>
>> The catalog with that class was only a during-update thing, of course. 
>>
>> if versioncmp($::puppetversion, '4.0.0') >= 0 { 
>>   include "role::${::stype}" 
>> } 
>> else { 
>>   include ::puppet_upgrade 
>> } 
>>
>> Otherwise you could: 
>>
>> rsync -a --delete /var/lib/puppet/ssl /etc/puppetlabs/puppet/ 
>>
>> On Tue, Jun 14, 2016 at 06:39:13AM -0700, Bret Wortman wrote: 
>> >So I'm trying to use Ansible to automate the process of re-enrolling 
>> all 
>> >my systems after the upgrade from 3.8.6 to 4.3, and many (though not 
>> all) 
>> >of my clients are reporting thusly: 
>> ># rpm -rf /var/lib/puppet/ssl /etc/puppet/ssl 
>> /etc/puppetlabs/puppet/ssl 
>> ># ssh puppet puppet cert list host.internal.net 
>> >Error: Could not find a certificate for host.internal.net 
>> ># puppet agent -t --noop 
>> >Info: Creating a new SSL key for host.internal.net 
>> >Info: Caching certificate for ca 
>> >Info: csr_attributes file loading from 
>> /etc/puppet/csr_attributes.yaml 
>> >Info: Creating a new SSL certificate request for host.internal.net 
>> >Info: Certificate Request fingerprint (SHA256): 75:6A:17:... 
>> >Info: Caching certificate for host.internal.net 
>> >Error: Could not request certificate: SSL_connect returned=1 errno=0 
>> >state=SSLv3 read server certificate B: certificate verify failed: 
>> [unable 
>> >to get local issuer certificate for /CN=puppet.internal.net] 
>> >Exiting: failed to retrieve certificate and waitforcert is disabled 
>> ># ssh root@puppet puppet cert list -a | grep host.internal.net 
>> >+ "host.internal.net" (SHA256) 42:AF:68:... 
>> ># puppet agent --version 
>> >3.8.6 
>> ># 
>> >I'm having success on other 3.8.6 clients and others as far back as 
>> 3.8.1. 
>> >What's going on here that I'm not understanding? 
>> > 
>> >-- 
>> >You received this message because you are subscribed to the Google 
>> Groups 
>> >"Puppet Users" group. 
>> >To unsubscribe from this group and stop receiving emails from it, 
>> send an 
>> >email to [1]puppet-users...@googlegroups.com. 
>> >To view this discussion on the web visit 
>> >[2]
>> https://groups.google.com/d/msgid/puppet-users/6717bc33-381d-4890-90c0-a9be684dc9e5%

Re: [Puppet Users] Re-enrolling clients after major version upgrade

[Bret Wortman]

I did the following (which I'd done before) and it seems to have helped:

# puppet resource service upppetserver ensure=stopped
# rm -rf /etc/puppetlabs/puppet/ssl
# puppet cert list -a
# puppet master --no-daemonize --verbose
^C
# puppet resource servcie puppetserver ensure=running
#



On Tuesday, June 14, 2016 at 9:50:44 AM UTC-4, Christopher Wood wrote:
>
> To your specific issue, it looks like your agent's CA cert doesn't match 
> the issuer of the new puppetmaster's CA cert ("unable to get local issuer 
> certificate"). If I recall correctly, an agent without a CA cert will 
> download one from the puppetmaster the first time and thereafter check it. 
> You might check the cert chains to see what's going on, or if you 
> downloaded the CA cert at all. 
>
> Otherwise I noticed this bit: 
>
> # rpm -rf /var/lib/puppet/ssl /etc/puppet/ssl /etc/puppetlabs/puppet/ssl 
> # ssh puppet puppet cert list host.internal.net 
> Error: Could not find a certificate for host.internal.net 
>
> Is it supposed to say rpm not rm? I Presume it's just the logging which is 
> removing the quotes too. 
>
> Rhubarbing more generally, I had some success syncing the ssl directory 
> during our own 3->4 update. I never found a reason to use a new cert for 
> the same host when I already had one. 
>
> file { '/etc/puppetlabs/puppet/ssl': 
>   ensure   => directory, 
>   backup   => false, 
>   recurse  => true, 
>   recurselimit => 99, 
>   require  => Package[$package], 
>   source   => '/var/lib/puppet/ssl', 
> } 
>
> The catalog with that class was only a during-update thing, of course. 
>
> if versioncmp($::puppetversion, '4.0.0') >= 0 { 
>   include "role::${::stype}" 
> } 
> else { 
>   include ::puppet_upgrade 
> } 
>
> Otherwise you could: 
>
> rsync -a --delete /var/lib/puppet/ssl /etc/puppetlabs/puppet/ 
>
> On Tue, Jun 14, 2016 at 06:39:13AM -0700, Bret Wortman wrote: 
> >So I'm trying to use Ansible to automate the process of re-enrolling 
> all 
> >my systems after the upgrade from 3.8.6 to 4.3, and many (though not 
> all) 
> >of my clients are reporting thusly: 
> ># rpm -rf /var/lib/puppet/ssl /etc/puppet/ssl 
> /etc/puppetlabs/puppet/ssl 
> ># ssh puppet puppet cert list host.internal.net 
> >Error: Could not find a certificate for host.internal.net 
> ># puppet agent -t --noop 
> >Info: Creating a new SSL key for host.internal.net 
> >Info: Caching certificate for ca 
> >Info: csr_attributes file loading from 
> /etc/puppet/csr_attributes.yaml 
> >Info: Creating a new SSL certificate request for host.internal.net 
> >Info: Certificate Request fingerprint (SHA256): 75:6A:17:... 
> >Info: Caching certificate for host.internal.net 
> >Error: Could not request certificate: SSL_connect returned=1 errno=0 
> >state=SSLv3 read server certificate B: certificate verify failed: 
> [unable 
> >to get local issuer certificate for /CN=puppet.internal.net] 
> >Exiting: failed to retrieve certificate and waitforcert is disabled 
> ># ssh root@puppet puppet cert list -a | grep host.internal.net 
> >+ "host.internal.net" (SHA256) 42:AF:68:... 
> ># puppet agent --version 
> >3.8.6 
> ># 
> >I'm having success on other 3.8.6 clients and others as far back as 
> 3.8.1. 
> >What's going on here that I'm not understanding? 
> > 
> >-- 
> >You received this message because you are subscribed to the Google 
> Groups 
> >"Puppet Users" group. 
> >To unsubscribe from this group and stop receiving emails from it, 
> send an 
> >email to [1]puppet-users...@googlegroups.com . 
> >To view this discussion on the web visit 
> >[2]
> https://groups.google.com/d/msgid/puppet-users/6717bc33-381d-4890-90c0-a9be684dc9e5%40googlegroups.com.
>  
>
> >For more options, visit [3]https://groups.google.com/d/optout. 
> > 
> > References 
> > 
> >Visible links 
> >1. mailto:puppet-users+unsubscr...@googlegroups.com  
> >2. 
> https://groups.google.com/d/msgid/puppet-users/6717bc33-381d-4890-90c0-a9be684dc9e5%40googlegroups.com?utm_medium=email&utm_source=footer
>  
> >3. https://groups.google.com/d/optout 
>
>

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

[Puppet Users] Re-enrolling clients after major version upgrade

[Bret Wortman]

So I'm trying to use Ansible to automate the process of re-enrolling all my 
systems after the upgrade from 3.8.6 to 4.3, and many (though not all) of 
my clients are reporting thusly:

# *rpm -rf /var/lib/puppet/ssl /etc/puppet/ssl /etc/puppetlabs/puppet/ssl*
# *ssh puppet puppet cert list host.internal.net*
Error: Could not find a certificate for host.internal.net
# *puppet agent -t --noop*
Info: Creating a new SSL key for host.internal.net
Info: Caching certificate for ca
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for host.internal.net
Info: Certificate Request fingerprint (SHA256): 75:6A:17:...
Info: Caching certificate for host.internal.net
Error: Could not request certificate: SSL_connect returned=1 errno=0 
state=SSLv3 read server certificate B: certificate verify failed: [unable 
to get local issuer certificate for /CN=puppet.internal.net]
Exiting: failed to retrieve certificate and waitforcert is disabled
# *ssh root@puppet puppet cert list -a | grep host.internal.net*
+ "host.internal.net" (SHA256) 42:AF:68:...
# *puppet agent --version*
3.8.6
#

I'm having success on other 3.8.6 clients and others as far back as 3.8.1. 
What's going on here that I'm not understanding?

-- 
You received this message because you are subscribed 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/6717bc33-381d-4890-90c0-a9be684dc9e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Upgraded Puppet server from 3.8 to 4.5 and Hiera stopped working

[Bret Wortman]

Somehow, I got this working. I'm honestly not sure how, but I'm not going 
to argue with success.

I've restarted the server and it's still working. Thanks for your help, 
Peter!

On Monday, June 13, 2016 at 12:56:19 PM UTC-4, Peter Kristolaitis wrote:
>
> With the change to "split environments by default", you need to provide 
> the environment name on the command line:
>
> [root@sh00cw-pup01ny hieradata]# hiera profiles::packages::centos 
> nil
> [root@sh00cw-pup01ny hieradata]# hiera profiles::packages::centos 
> environment=production
> ["bind-utils", "curl", "nmap", "tcpdump", "unzip", "wget"]
>
> This is done automatically by the Puppet server when compiling the 
> manifest, but you need to do it manually on the command line.
>
>
> On 2016-06-13 12:37 PM, Bret Wortman wrote:
>
> Oh, and my hiera version is now 3.0.6. We lag a bit behind on our 
> development & production networks 
>
>
> On Monday, June 13, 2016 at 12:37:03 PM UTC-4, Bret Wortman wrote: 
>>
>> That got me past the error, but I still am getting "nil" no matter what I 
>> ask for. 
>>
>> And I've looked -- the keys I'm querying for are defined, at a minimum, 
>> in /etc/puppetlabs/code/environments/production/hieradata/common.yaml.
>>
>>
>> On Monday, June 13, 2016 at 12:06:56 PM UTC-4, Peter Kristolaitis wrote: 
>>>
>>> I suspect your hiera install is confused because you have both the 
>>> puppet-agent and hiera packages installed.   Hiera now ships as part of the 
>>> puppet-agent package and gets installed as /opt/puppetlabs/bin/hiera; there 
>>> is no separate hiera package.  Hiera 1.3.4 is also quite old -- on a box 
>>> with puppet-agent v1.5.1 installed, 'hiera -v' gives me version 3.2.0.
>>>
>>> You probably need to get rid of the hiera package and make sure that 
>>> you're using the new version provided by puppet-agent.
>>>
>>>
>>> On 2016-06-13 11:54 AM, Bret Wortman wrote:
>>>
>>> This morning, I upgraded to Puppet 4 using the PC1 repository and even 
>>> through I have the puppet server running, the Hiera files we rely heavily 
>>> on aren't being seen. I'm getting false values for everything which really 
>>> screwed up some of the boxes I was testing with. 
>>>
>>> # hiera -c /etc/puppetlabs/code/hiera.yaml localtime::timezone -y 
>>> test.yaml
>>> Could not load YAML scope: LoadError: cannot load such file -- puppet
>>> # cat /etc/puppetlabs/code/hiera.yaml
>>> ---
>>> :backends:
>>>   - yaml
>>>
>>> :yaml:
>>>   :datadir: 
>>> "/etc/puppetlabs/code/environments/${::environment}/hieradata"
>>>
>>> :hierarchy:
>>>   - "%{::hostname}"
>>>   - "%{::sitename}"
>>>   - common
>>>
>>> # ls /etc/puppetlabs/code/environments/production/hieradata/common.yaml
>>> /etc/puppetlabs/code/environments/production/hieradata/common.yaml
>>> # cat test.yaml
>>> ---
>>> "::hostname": testws
>>> "::sitename": hq
>>> # rpm -qa | grep hiera
>>> hiera-1.3.4-5.el7.noarch
>>> # rpm -qa | grep puppet
>>> puppetdb-3.2.2-1.el7.noarch
>>> puppetserver-2.2.1-1.el7.noarch
>>> puppet-agent-1.3.5-1.el7.x86_64
>>> #
>>>
>>> All the files under environments/production/hieradata used to reside 
>>> under /etc/puppet/environments/production/data, but were moved & renamed to 
>>> accomodate the upgrade. And promptly stopped working.
>>>
>>> Where should I be looking? Do I still need to have the "puppet" rpm 
>>> installed?
>>>
>>>
>>> Bret
>>> -- 
>>> You received this message because you are subscribed 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/63b7a931-d52c-4c1a-822d-f9000e87507f%40googlegroups.com>
>>> https://groups.google.com/d/
>>> msgid/puppet-users/63b7a931-d52c-4c1a-822d-f9000e87507f%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com .
> To view this discussion on the web visit 
> <https://groups.google.com/d/msgid/puppet-users/25b411ce-855e-4fd2-8d7f-4a724cb25ea5%40googlegroups.com?utm_medium=email&utm_source=footer>
> https://groups.google.com/d/msgid/puppet-users/25b411ce-855e-4fd2-8d7f-4a724cb25ea5%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

Re: [Puppet Users] Upgraded Puppet server from 3.8 to 4.5 and Hiera stopped working

[Bret Wortman]

Oh, and my hiera version is now 3.0.6. We lag a bit behind on our 
development & production networks


On Monday, June 13, 2016 at 12:37:03 PM UTC-4, Bret Wortman wrote:
>
> That got me past the error, but I still am getting "nil" no matter what I 
> ask for.
>
> And I've looked -- the keys I'm querying for are defined, at a minimum, in 
> /etc/puppetlabs/code/environments/production/hieradata/common.yaml.
>
>
> On Monday, June 13, 2016 at 12:06:56 PM UTC-4, Peter Kristolaitis wrote:
>>
>> I suspect your hiera install is confused because you have both the 
>> puppet-agent and hiera packages installed.   Hiera now ships as part of the 
>> puppet-agent package and gets installed as /opt/puppetlabs/bin/hiera; there 
>> is no separate hiera package.  Hiera 1.3.4 is also quite old -- on a box 
>> with puppet-agent v1.5.1 installed, 'hiera -v' gives me version 3.2.0.
>>
>> You probably need to get rid of the hiera package and make sure that 
>> you're using the new version provided by puppet-agent.
>>
>>
>> On 2016-06-13 11:54 AM, Bret Wortman wrote:
>>
>> This morning, I upgraded to Puppet 4 using the PC1 repository and even 
>> through I have the puppet server running, the Hiera files we rely heavily 
>> on aren't being seen. I'm getting false values for everything which really 
>> screwed up some of the boxes I was testing with. 
>>
>> # hiera -c /etc/puppetlabs/code/hiera.yaml localtime::timezone -y 
>> test.yaml
>> Could not load YAML scope: LoadError: cannot load such file -- puppet
>> # cat /etc/puppetlabs/code/hiera.yaml
>> ---
>> :backends:
>>   - yaml
>>
>> :yaml:
>>   :datadir: "/etc/puppetlabs/code/environments/${::environment}/hieradata"
>>
>> :hierarchy:
>>   - "%{::hostname}"
>>   - "%{::sitename}"
>>   - common
>>
>> # ls /etc/puppetlabs/code/environments/production/hieradata/common.yaml
>> /etc/puppetlabs/code/environments/production/hieradata/common.yaml
>> # cat test.yaml
>> ---
>> "::hostname": testws
>> "::sitename": hq
>> # rpm -qa | grep hiera
>> hiera-1.3.4-5.el7.noarch
>> # rpm -qa | grep puppet
>> puppetdb-3.2.2-1.el7.noarch
>> puppetserver-2.2.1-1.el7.noarch
>> puppet-agent-1.3.5-1.el7.x86_64
>> #
>>
>> All the files under environments/production/hieradata used to reside 
>> under /etc/puppet/environments/production/data, but were moved & renamed to 
>> accomodate the upgrade. And promptly stopped working.
>>
>> Where should I be looking? Do I still need to have the "puppet" rpm 
>> installed?
>>
>>
>> Bret
>> -- 
>> You received this message because you are subscribed 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/63b7a931-d52c-4c1a-822d-f9000e87507f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> https://groups.google.com/d/msgid/puppet-users/63b7a931-d52c-4c1a-822d-f9000e87507f%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>

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

Re: [Puppet Users] Upgraded Puppet server from 3.8 to 4.5 and Hiera stopped working

[Bret Wortman]

That got me past the error, but I still am getting "nil" no matter what I 
ask for.

And I've looked -- the keys I'm querying for are defined, at a minimum, in 
/etc/puppetlabs/code/environments/production/hieradata/common.yaml.


On Monday, June 13, 2016 at 12:06:56 PM UTC-4, Peter Kristolaitis wrote:
>
> I suspect your hiera install is confused because you have both the 
> puppet-agent and hiera packages installed.   Hiera now ships as part of the 
> puppet-agent package and gets installed as /opt/puppetlabs/bin/hiera; there 
> is no separate hiera package.  Hiera 1.3.4 is also quite old -- on a box 
> with puppet-agent v1.5.1 installed, 'hiera -v' gives me version 3.2.0.
>
> You probably need to get rid of the hiera package and make sure that 
> you're using the new version provided by puppet-agent.
>
>
> On 2016-06-13 11:54 AM, Bret Wortman wrote:
>
> This morning, I upgraded to Puppet 4 using the PC1 repository and even 
> through I have the puppet server running, the Hiera files we rely heavily 
> on aren't being seen. I'm getting false values for everything which really 
> screwed up some of the boxes I was testing with. 
>
> # hiera -c /etc/puppetlabs/code/hiera.yaml localtime::timezone -y test.yaml
> Could not load YAML scope: LoadError: cannot load such file -- puppet
> # cat /etc/puppetlabs/code/hiera.yaml
> ---
> :backends:
>   - yaml
>
> :yaml:
>   :datadir: "/etc/puppetlabs/code/environments/${::environment}/hieradata"
>
> :hierarchy:
>   - "%{::hostname}"
>   - "%{::sitename}"
>   - common
>
> # ls /etc/puppetlabs/code/environments/production/hieradata/common.yaml
> /etc/puppetlabs/code/environments/production/hieradata/common.yaml
> # cat test.yaml
> ---
> "::hostname": testws
> "::sitename": hq
> # rpm -qa | grep hiera
> hiera-1.3.4-5.el7.noarch
> # rpm -qa | grep puppet
> puppetdb-3.2.2-1.el7.noarch
> puppetserver-2.2.1-1.el7.noarch
> puppet-agent-1.3.5-1.el7.x86_64
> #
>
> All the files under environments/production/hieradata used to reside under 
> /etc/puppet/environments/production/data, but were moved & renamed to 
> accomodate the upgrade. And promptly stopped working.
>
> Where should I be looking? Do I still need to have the "puppet" rpm 
> installed?
>
>
> Bret
> -- 
> You received this message because you are subscribed 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/63b7a931-d52c-4c1a-822d-f9000e87507f%40googlegroups.com?utm_medium=email&utm_source=footer>
> https://groups.google.com/d/msgid/puppet-users/63b7a931-d52c-4c1a-822d-f9000e87507f%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

[Puppet Users] Upgraded Puppet server from 3.8 to 4.5 and Hiera stopped working

[Bret Wortman]

This morning, I upgraded to Puppet 4 using the PC1 repository and even 
through I have the puppet server running, the Hiera files we rely heavily 
on aren't being seen. I'm getting false values for everything which really 
screwed up some of the boxes I was testing with.

# hiera -c /etc/puppetlabs/code/hiera.yaml localtime::timezone -y test.yaml
Could not load YAML scope: LoadError: cannot load such file -- puppet
# cat /etc/puppetlabs/code/hiera.yaml
---
:backends:
  - yaml

:yaml:
  :datadir: "/etc/puppetlabs/code/environments/${::environment}/hieradata"

:hierarchy:
  - "%{::hostname}"
  - "%{::sitename}"
  - common

# ls /etc/puppetlabs/code/environments/production/hieradata/common.yaml
/etc/puppetlabs/code/environments/production/hieradata/common.yaml
# cat test.yaml
---
"::hostname": testws
"::sitename": hq
# rpm -qa | grep hiera
hiera-1.3.4-5.el7.noarch
# rpm -qa | grep puppet
puppetdb-3.2.2-1.el7.noarch
puppetserver-2.2.1-1.el7.noarch
puppet-agent-1.3.5-1.el7.x86_64
#

All the files under environments/production/hieradata used to reside under 
/etc/puppet/environments/production/data, but were moved & renamed to 
accomodate the upgrade. And promptly stopped working.

Where should I be looking? Do I still need to have the "puppet" rpm 
installed?


Bret

-- 
You received this message because you are subscribed 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/63b7a931-d52c-4c1a-822d-f9000e87507f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Odd razor error on freshly set up server

[Bret Wortman]

I'm working on setting up a new razor server and have gotten the 
microkernel boot to work fine. But now, when it tries to provision the new 
node, I get this:

:
Filename: bootstrap.ipxe
tftp://192.168.1.101/bootstrap.ipxe... ok
bootstrap.ipxe : 1626 bytes [script]
http://192.168.1.101:8150/svc/boot?net0=[snip]... ok
Noop installer (Installed by Razor)
Installation node: http://192.168.1.101:8150/api/nodes/5
Installation repo: http://192.168.1.101:8150/svc/repo/microkernel/
forcing local booting with sanboot 0x80
Booting from SAN device 0x80
Boot from SAN device 0x80 failed: Exec format error 
(http://ipxe.org/2e852001)
Could not boot: Exec format error (http://ipxe.org/2e852001)
Could not boot image: Result too large (http://ipxe.org/46022001)
No more network devices

Operating System not found

Now, I noticed two things here: First, it's using a "Noop" installer when 
the profile I have calls for centos/7:

[root@puppet ~]# razor policies
>From http://localhost:8150/api/collections/policies:

+-+++++++---+
| name| repo   | task   | broker | enable | max_co | tags   | nodes |
| |||| d  | unt||   |
+-+++++++---+
| centos- | centos | centos | puppet | true   || (none) | 0 |
| for-sma | 7  | /7 |||||   |
| ll  |||||||   |
+-+++++++---+

Query an entry by including its name, e.g. `razor policies centos-for-small`

[root@puppet ~]# razor brokers
>From http://localhost:8150/api/collections/brokers:

++-+-+--+
| name   | broker_type | configuration   | policies 
|
++-+-+--+
| noop   | noop| (none)  | 0   
 |
++-+-+--+
| puppet | puppet  | {"server"=>"puppet.wedgeofli.me", "envi | 1   
 |
|| | ronment"=>"production"} | 
 |
++-+-+--+

Query an entry by including its name, e.g. `razor brokers noop`

[root@puppet ~]# razor repos centos7
>From http://localhost:8150/api/collections/repos/centos7:

 name: centos7
  iso_url: ---
  url: http://mirrors.kernel.org/centos/7/os/x86_64
 task: centos/7

Query additional details via: `razor repos centos7 [task]`

[root@puppet ~]# razor policies centos-for-small
>From http://localhost:8150/api/collections/policies/centos-for-small:

   name: centos-for-small
   repo: centos7
   task: centos/7
 broker: puppet
enabled: true
  max_count: nil
   tags: (none)
  nodes: 0

Query additional details via: `razor policies centos-for-small [broker, 
configuration, nodes, repo, tags, task]`

[root@puppet ~]# 


So I'm not sure where the noop is coming from. It had been set in the 
policy originally, but I updated it to what you see here and still it's 
trying to use the noop installer.

Secondly, The url http://192.168.1.101:8150/api/nodes/5 is wrong -- it 
should be /api/collections/nodes/node5. Is this partly to blame, and if so, 
why is razor using the wrong url to its own api? Did I mis-set this 
somewhere?

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/5c7a14b5-911e-430c-bfed-46dac4432c47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Can't access custom fact as hash

[Bret Wortman]

For completeness' sake, the answer was to set stringify_facts = false in 
puppet.conf's [main] section.

On Wednesday, November 4, 2015 at 8:09:36 AM UTC-5, Bret Wortman wrote:
>
> This is on Puppet open source V3.8.3 server and V3.8.1 client.
>
> On Wednesday, November 4, 2015 at 8:08:20 AM UTC-5, Bret Wortman wrote:
>>
>> I defined this custom fact, which queries a local tool to determine what 
>> roles a particular system should have assigned to it:
>>
>> Facter.add(:dgroles) do
>> setcode do
>> roles = {}
>> res_hash = {}
>> results = Facter::Core::Execution.exec("dg-role -b").split("/n")
>> results.each do |res|
>> rs=res.split(" ")
>> res_hash[rs[0]] = rs[1].split(',')
>> end
>> res_hash
>> end
>> end
>>
>>
>> This works fine from the command line:
>>
>> $ facter -p dgroles
>> {"BAD"=>["wks", "lnx"]}
>>
>>
>> And when I use it in a notify:
>>
>> ---manifest excerpt---
>>
>> notify { "roles: $::dgroles": }
>>
>>
>> which produces:
>>
>> Notice: roles: {"BAD"=>["wks", "lnx"]}
>>
>>
>> But when I try to actually use the hash, as in:
>>
>> ---manifest excerpt---
>>
>> if count(delete(keys($::dgroles),'GOOD')) > 0 {
>> exec { 'dg-role-a-update':
>> command => 'dg-role -a update',
>> }
>> }
>>
>>
>> Then I get this error when running puppet agent -t:
>>
>> Error: Could not retrieve catalog from remote server: Error 400 on 
>> SERVER: keys(): Requires hash to work with at 
>> /etc/puppet/environments/roles/modules/dglib/manifests/config.pp:54 on node 
>> zw129.damascusgrp.com
>>
>>
>> What am I doing wrong 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/7b2f36a8-3709-4442-b17a-aabaff678c69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Can't access custom fact as hash

[Bret Wortman]

This is on Puppet open source V3.8.3 server and V3.8.1 client.

On Wednesday, November 4, 2015 at 8:08:20 AM UTC-5, Bret Wortman wrote:
>
> I defined this custom fact, which queries a local tool to determine what 
> roles a particular system should have assigned to it:
>
> Facter.add(:dgroles) do
> setcode do
> roles = {}
> res_hash = {}
> results = Facter::Core::Execution.exec("dg-role -b").split("/n")
> results.each do |res|
> rs=res.split(" ")
> res_hash[rs[0]] = rs[1].split(',')
> end
> res_hash
> end
> end
>
>
> This works fine from the command line:
>
> $ facter -p dgroles
> {"BAD"=>["wks", "lnx"]}
>
>
> And when I use it in a notify:
>
> ---manifest excerpt---
>
> notify { "roles: $::dgroles": }
>
>
> which produces:
>
> Notice: roles: {"BAD"=>["wks", "lnx"]}
>
>
> But when I try to actually use the hash, as in:
>
> ---manifest excerpt---
>
> if count(delete(keys($::dgroles),'GOOD')) > 0 {
> exec { 'dg-role-a-update':
> command => 'dg-role -a update',
> }
> }
>
>
> Then I get this error when running puppet agent -t:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> keys(): Requires hash to work with at 
> /etc/puppet/environments/roles/modules/dglib/manifests/config.pp:54 on node 
> zw129.damascusgrp.com
>
>
> What am I doing wrong 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/edbd7141-97a7-47a3-84a4-4cb2c45b4109%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Can't access custom fact as hash

[Bret Wortman]

I defined this custom fact, which queries a local tool to determine what 
roles a particular system should have assigned to it:

Facter.add(:dgroles) do
setcode do
roles = {}
res_hash = {}
results = Facter::Core::Execution.exec("dg-role -b").split("/n")
results.each do |res|
rs=res.split(" ")
res_hash[rs[0]] = rs[1].split(',')
end
res_hash
end
end


This works fine from the command line:

$ facter -p dgroles
{"BAD"=>["wks", "lnx"]}


And when I use it in a notify:

---manifest excerpt---

notify { "roles: $::dgroles": }


which produces:

Notice: roles: {"BAD"=>["wks", "lnx"]}


But when I try to actually use the hash, as in:

---manifest excerpt---

if count(delete(keys($::dgroles),'GOOD')) > 0 {
exec { 'dg-role-a-update':
command => 'dg-role -a update',
}
}


Then I get this error when running puppet agent -t:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
keys(): Requires hash to work with at 
/etc/puppet/environments/roles/modules/dglib/manifests/config.pp:54 on node 
zw129.damascusgrp.com


What am I doing wrong 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/a41759da-de77-408e-ba22-6b12bc0d356e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Confused after system upgrade - F22, Puppet 4.1.0-5

[Bret Wortman]

Actually, I think my hiera problem may be rleated to this line in my 
hiera.yaml file:

:yaml:
  :datadir: '/etc/puppet/environments/%{environment}/data'

Since I saw that environments changed in Puppet 4.

On Thursday, October 8, 2015 at 12:08:35 PM UTC-4, Bret Wortman wrote:
>
> So I upgraded our Puppet server to Fedora 22, which brought with it an 
> upgrade from Puppet 3.8-ish to 4.1.0-5. And as this wasn't expected (I 
> should have read and studied more -- it's definitely my fault), a few 
> things have confused me as I've started reading the Puppetlabs site for 4.1 
> documentation:
>
> 1. It says that config files are now under /etc/puppetlabs/puppet, but the 
> RPM says it installed everything to /etc/puppet as always. Which is right?
>
> 2. My hiera config, or at least the default .yaml file I set up, isn't 
> being seen -- I suspect this is related to #1, but could something else be 
> to blame? The specific error when running a Puppet 4.1 client against my 
> system (actually, the agent running on the server since this was the first 
> F22 upgrade we did) is:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Evalutaiton Error: Error while evaluating a Function Call, Could not find 
> data item proxy in any Hiera data file and no default supplied at 
> /path/to/manifests/site.pp:25:10 on node puppetserver.foo.net
>
> 3. Has Puppetlabs stopped providing RPMs at their yum server? I haven't 
> seen a full set since F20.
>
> Thanks,
>
>
> Bret Wortman
>
>

-- 
You received this message because you are subscribed 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/5b2ec91c-ca65-4e6d-9b26-e354d165a169%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Confused after system upgrade - F22, Puppet 4.1.0-5

[Bret Wortman]

So I upgraded our Puppet server to Fedora 22, which brought with it an 
upgrade from Puppet 3.8-ish to 4.1.0-5. And as this wasn't expected (I 
should have read and studied more -- it's definitely my fault), a few 
things have confused me as I've started reading the Puppetlabs site for 4.1 
documentation:

1. It says that config files are now under /etc/puppetlabs/puppet, but the 
RPM says it installed everything to /etc/puppet as always. Which is right?

2. My hiera config, or at least the default .yaml file I set up, isn't 
being seen -- I suspect this is related to #1, but could something else be 
to blame? The specific error when running a Puppet 4.1 client against my 
system (actually, the agent running on the server since this was the first 
F22 upgrade we did) is:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Evalutaiton Error: Error while evaluating a Function Call, Could not find 
data item proxy in any Hiera data file and no default supplied at 
/path/to/manifests/site.pp:25:10 on node puppetserver.foo.net

3. Has Puppetlabs stopped providing RPMs at their yum server? I haven't 
seen a full set since F20.

Thanks,


Bret Wortman

-- 
You received this message because you are subscribed 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/0e9e133a-1d48-45c3-9a1f-ead296205868%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Could not retrieve catalog from remote server: end of file reached

[Bret Wortman]

Bingo! I set the timeout to 15s on server and agent both (some of our 
network links are pretty crappy) and now everyone's connecting as before. 
Thanks for the tip!

On Wednesday, October 1, 2014 6:24:07 PM UTC-4, Josh Cooper wrote:
>
>
>
> On Wed, Oct 1, 2014 at 10:47 AM, Bret Wortman  > wrote:
>
>> I guess not. I upgraded the server to match but the problem persists.
>>
>>
>> On Wednesday, October 1, 2014 1:38:16 PM UTC-4, Bret Wortman wrote:
>>>
>>> We're running through Passenger and Apache. Puppetdb back-end. Puppet 
>>> 3.6.2-1 on F20 on the server, Puppet 3.7.1-1 C6.5 on the client. H. 
>>> Could the newer client be the problem?
>>>
>>> On Wednesday, October 1, 2014 1:31:00 PM UTC-4, Henrik Lindberg wrote:
>>>>
>>>> On 2014-01-10 19:21, Bret Wortman wrote: 
>>>> > This is happening on some of my clients. It'll happen about 1 out of 
>>>> 20 
>>>> > runs, but it's really getting to be a problem. There's nothing 
>>>> > indicative in /var/log/messages or any other server-side log that I 
>>>> can 
>>>> > find, and this is all the output I'm seeing on the client: 
>>>> > 
>>>> > # puppet agent - t 
>>>> > Info: Retrieving pluginfacts 
>>>> > Info: Retrieving plugin 
>>>> > Info: Loading facts 
>>>> > Error: Could not retrieve catalog from remote server: end of file 
>>>> reached 
>>>> > Warning: Not using cache on failed catalog 
>>>> > Error: Could not retrieve catalog; skipping run 
>>>> > # 
>>>> > 
>>>> > Any guidance on how to get more details out of Puppet about what's 
>>>> going 
>>>> > wrong here? It's persistent, but again, doesn't happen 100% of the 
>>>> time. 
>>>> > And it's only happening on certain agents, so I'm pretty sure it's 
>>>> > related to a module somewhere that's doing something wrong, but for 
>>>> the 
>>>> > life of me, I can't suss out which module is causing the problem. 
>>>> > 
>>>> > 
>>>> > Bret Wortman 
>>>> > 
>>>>
>>>> Are you using Webrick ? If so, there are versions of Puppet 3x that 
>>>> have 
>>>> issues with concurrent operation (more than one agent at the same time) 
>>>> that can cause all kinds of weird behavior - typically resulting in 
>>>> truncated streams. 
>>>>
>>>> Try latest 3.6, or 3.7. The best fix is to stop using Webrick in favor 
>>>> of Passenger. Webrick is really not for production use. 
>>>>
>>>> - henrik 
>>>>
>>>> -- 
>>>>
>>>> Visit my Blog "Puppet on the Edge" 
>>>> http://puppet-on-the-edge.blogspot.se/ 
>>>>
>>>>  -- 
>> You received this message because you are subscribed 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/f159d59a-aa57-4648-8e34-cb39686469fa%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/f159d59a-aa57-4648-8e34-cb39686469fa%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> You may be running into https://tickets.puppetlabs.com/browse/PUP-3238. 
> Is the passenger KeepAliveTimeout shorter than the the puppet agent's 
> timeout? If so, the server may close an idle connection, e.g. while the 
> agent is running facter.
>
> See also 
> https://docs.puppetlabs.com/puppet/3.7/reference/release_notes.html#performance-improvements
>
> Josh
>
> -- 
> Josh Cooper
> Developer, Puppet Labs
>  

-- 
You received this message because you are subscribed 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/751f4b93-383a-44d1-9ee5-e6539cc62559%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Could not retrieve catalog from remote server: end of file reached

[Bret Wortman]

I guess not. I upgraded the server to match but the problem persists.

On Wednesday, October 1, 2014 1:38:16 PM UTC-4, Bret Wortman wrote:
>
> We're running through Passenger and Apache. Puppetdb back-end. Puppet 
> 3.6.2-1 on F20 on the server, Puppet 3.7.1-1 C6.5 on the client. H. 
> Could the newer client be the problem?
>
> On Wednesday, October 1, 2014 1:31:00 PM UTC-4, Henrik Lindberg wrote:
>>
>> On 2014-01-10 19:21, Bret Wortman wrote: 
>> > This is happening on some of my clients. It'll happen about 1 out of 20 
>> > runs, but it's really getting to be a problem. There's nothing 
>> > indicative in /var/log/messages or any other server-side log that I can 
>> > find, and this is all the output I'm seeing on the client: 
>> > 
>> > # puppet agent - t 
>> > Info: Retrieving pluginfacts 
>> > Info: Retrieving plugin 
>> > Info: Loading facts 
>> > Error: Could not retrieve catalog from remote server: end of file 
>> reached 
>> > Warning: Not using cache on failed catalog 
>> > Error: Could not retrieve catalog; skipping run 
>> > # 
>> > 
>> > Any guidance on how to get more details out of Puppet about what's 
>> going 
>> > wrong here? It's persistent, but again, doesn't happen 100% of the 
>> time. 
>> > And it's only happening on certain agents, so I'm pretty sure it's 
>> > related to a module somewhere that's doing something wrong, but for the 
>> > life of me, I can't suss out which module is causing the problem. 
>> > 
>> > 
>> > Bret Wortman 
>> > 
>>
>> Are you using Webrick ? If so, there are versions of Puppet 3x that have 
>> issues with concurrent operation (more than one agent at the same time) 
>> that can cause all kinds of weird behavior - typically resulting in 
>> truncated streams. 
>>
>> Try latest 3.6, or 3.7. The best fix is to stop using Webrick in favor 
>> of Passenger. Webrick is really not for production use. 
>>
>> - henrik 
>>
>> -- 
>>
>> Visit my Blog "Puppet on the Edge" 
>> http://puppet-on-the-edge.blogspot.se/ 
>>
>>

-- 
You received this message because you are subscribed 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/f159d59a-aa57-4648-8e34-cb39686469fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Could not retrieve catalog from remote server: end of file reached

[Bret Wortman]

We're running through Passenger and Apache. Puppetdb back-end. Puppet 
3.6.2-1 on F20 on the server, Puppet 3.7.1-1 C6.5 on the client. H. 
Could the newer client be the problem?

On Wednesday, October 1, 2014 1:31:00 PM UTC-4, Henrik Lindberg wrote:
>
> On 2014-01-10 19:21, Bret Wortman wrote: 
> > This is happening on some of my clients. It'll happen about 1 out of 20 
> > runs, but it's really getting to be a problem. There's nothing 
> > indicative in /var/log/messages or any other server-side log that I can 
> > find, and this is all the output I'm seeing on the client: 
> > 
> > # puppet agent - t 
> > Info: Retrieving pluginfacts 
> > Info: Retrieving plugin 
> > Info: Loading facts 
> > Error: Could not retrieve catalog from remote server: end of file 
> reached 
> > Warning: Not using cache on failed catalog 
> > Error: Could not retrieve catalog; skipping run 
> > # 
> > 
> > Any guidance on how to get more details out of Puppet about what's going 
> > wrong here? It's persistent, but again, doesn't happen 100% of the time. 
> > And it's only happening on certain agents, so I'm pretty sure it's 
> > related to a module somewhere that's doing something wrong, but for the 
> > life of me, I can't suss out which module is causing the problem. 
> > 
> > 
> > Bret Wortman 
> > 
>
> Are you using Webrick ? If so, there are versions of Puppet 3x that have 
> issues with concurrent operation (more than one agent at the same time) 
> that can cause all kinds of weird behavior - typically resulting in 
> truncated streams. 
>
> Try latest 3.6, or 3.7. The best fix is to stop using Webrick in favor 
> of Passenger. Webrick is really not for production use. 
>
> - henrik 
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
You received this message because you are subscribed 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/6dd97f89-ce31-4455-a81b-b1e53f0cd928%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Could not retrieve catalog from remote server: end of file reached

[Bret Wortman]

This is happening on some of my clients. It'll happen about 1 out of 20 
runs, but it's really getting to be a problem. There's nothing indicative 
in /var/log/messages or any other server-side log that I can find, and this 
is all the output I'm seeing on the client:

# puppet agent - t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: end of file reached
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
#

Any guidance on how to get more details out of Puppet about what's going 
wrong here? It's persistent, but again, doesn't happen 100% of the time. 
And it's only happening on certain agents, so I'm pretty sure it's related 
to a module somewhere that's doing something wrong, but for the life of me, 
I can't suss out which module is causing the problem.


Bret Wortman

-- 
You received this message because you are subscribed 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/fe84700f-8b4b-4676-a20a-13bd41a9a90c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Different modes for directory, contents?

[Bret Wortman]

Yep, I saw it this time. I was scanning too quickly the last few times I
read that page. Sorry, John. I saw and followed the link, but missed the
relevant bit of doco.

Thanks again!



*Bret Wortman*
http://about.me/wortmanbret



On Fri, Apr 18, 2014 at 9:39 AM, jcbollinger wrote:

>
>
> On Thursday, April 17, 2014 9:33:11 AM UTC-5, Bret Wortman wrote:
>>
>> Doesn't this also make the directory itself 644 instead of 755? Maybe I
>> need to play around with it a bit more.
>>
>>
>
> No, it doesn't.  I repeat: Puppet will add add search permission to
> directories wherever there is read permission.  My previous response
> contained a link to the relevant documentation.
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/YvyV72vReyc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/8229c707-e0da-4908-9668-88dd388d39d0%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/8229c707-e0da-4908-9668-88dd388d39d0%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [Puppet Users] Re: Different modes for directory, contents?

[Bret Wortman]

Doesn't this also make the directory itself 644 instead of 755? Maybe I
need to play around with it a bit more.



*Bret Wortman*
http://about.me/wortmanbret



On Thu, Apr 17, 2014 at 9:17 AM, jcbollinger wrote:

>
>
> On Wednesday, April 16, 2014 7:06:53 AM UTC-5, Bret Wortman wrote:
>>
>> Is there a simple way to enforce a different mode for a directory and its
>> contents when the contents of the directory are highly variable? What I
>> mean is that I've got a case where some developers want a directory
>> "/var/log/httpd" to be protected 755 but the contents they want at 644. Is
>> there a simple, Puppet-ish way to make this happen, or are we basically
>> stuck with:
>>
>> file { '/var/log/httpd':
>> ensure => directory,
>> mode => '0644',
>> recurse => true,
>> }
>>
>>
>
> I'm missing something.  That declaration ought to do exactly what you say
> you want (Puppet will add add search permission to directories wherever
> there is read permission; see
> http://docs.puppetlabs.com/references/3.4.stable/type.html#file-attribute-mode).
> Where do you imagine simplifying it or making it more "puppet-ish"?
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/YvyV72vReyc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/90f5de75-6672-41a4-81b0-e95eab6354ab%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/90f5de75-6672-41a4-81b0-e95eab6354ab%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

[Puppet Users] Different modes for directory, contents?

[Bret Wortman]

Is there a simple way to enforce a different mode for a directory and its 
contents when the contents of the directory are highly variable? What I 
mean is that I've got a case where some developers want a directory 
"/var/log/httpd" to be protected 755 but the contents they want at 644. Is 
there a simple, Puppet-ish way to make this happen, or are we basically 
stuck with:

file { '/var/log/httpd':
ensure => directory,
mode => '0644',
recurse => true,
}

It appears the default is to write the files at 644 and the directory at 
700, so maybe all I need to do is bump the directory to 755 to make them 
happy, but there's no way to monitor both ends of this that I can see.


Bret

-- 
You received this message because you are subscribed 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/72bf774d-39d5-4df6-9c99-cfb1e2260ef2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Retrieving pluginfacts?

[Bret Wortman]

This is new to our environment and is only occurring on a handful of 
systems:

When they run puppet agent, we see this:

# puppet agent -t
Info: Retrieving pluginfacts
Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional 
resources using 'eval_generate': Error 400 on SERVER: Not authorized to 
call search on /file_metadata/pluginfacts with {:links=>"manage", 
:recurse=>true, :Ignore=>[".svn", "CVS", ".git"], :checksum_type=>"md5"}
Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not 
retrieve file metadata for puppet://zgepetto.foo.net/pluginfacts: Error 400 
on SERVER: Not authorized to call find on /file_metadata/pluginfacts with 
{:links=>"manage", :source_permissions=>"use"}
Wrapped exception:
Error 400 on SERVER: Not authorized to call find on 
/file_metadata/pluginfacts with {:links=>"manage", 
:source_permissions=>"use"}
Info: Retrieving plugin
Info: Loading facts in 
/var/lib/puppet/lib/facter/postgres_default_version.rb
:
:

The pupet agent run then proceeds to complete as normal.

I've never seen "pluginfacts" before. Is this something new, or is 
something awry in our server's config? Why are we only seeing this on a 
sparse few systems?


Bret

-- 
You received this message because you are subscribed 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/fac59898-cd9a-4fe6-8f43-e8da162b01b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Failed to generate additional resources using 'eval_generate'

[Bret Wortman]

Were you able to solve this? It's started happening to me now and I can't 
for the life of me figure it out

On Saturday, March 15, 2014 8:04:01 PM UTC-4, bluethundr wrote:
>
> Hey all,
>
>  I'm getting the following error on only one of my puppet hosts:
>
> Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional 
> resources using 'eval_generate': Error 400 on SERVER: Not authorized to 
> call search on /file_metadata/pluginfacts with {:links=>"manage", 
> :checksum_type=>"md5", :ignore=>[".svn", "CVS", ".git"], :recurse=>true}
> Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not 
> retrieve file metadata for puppet://puppet.jokefire.com/pluginfacts: 
> Error 400 on SERVER: Not authorized to call find on 
> /file_metadata/pluginfacts with {:links=>"manage", 
> :source_permissions=>"use"}
> Wrapped exception:
> Error 400 on SERVER: Not authorized to call find on 
> /file_metadata/pluginfacts with {:links=>"manage", 
> :source_permissions=>"use"}
>
> The client is an ubuntu 13.10 host running puppet agent version 3.5.0 
> against a puppet master 2.7.3
>
> Could someone give me a hand in how to handle this error?
>
> Thanks
> Tim
>
> -- 
> GPG me!!
>
> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>
>  

-- 
You received this message because you are subscribed 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/48d06357-fc5f-4eae-829c-3e8119ca00d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: How to execute a target action before this one when this one triggers

[Bret Wortman]

Here's what I did, and it seems to be working for now:

service { 'cups':
ensure => running,
enable => true,
}

file { '/etc/cups/printers.conf':
require => Package['cups'],
ensure => present,
source => 'puppet:///modules/printers/printers.conf',
mode => '0600',
owner => 'root',
group => 'lp',
notify => Exec['replace-restart-cups'],
}

exec { 'replace-restart-cups':
path => '/usr/bin:/usr/sbin',
command => 'cp /etc/cups/printers.conf /tmp && systemctl 
stop cups.service && cp /tmp/printers.conf /etc/cups/',
logoutput => true,
refreshonly => true,
notify => Service['cups'],
}

Basically, the file replacement (in its original location) triggers a 
copy-shutdown-recopy sequence which is an unabashed hack. But since cups 
doesn't clobber the replaced file until the service shuts down, and we make 
a copy before we shut it down, this works. So far. But it's definitely 
kludgey.


Bret

On Tuesday, January 28, 2014 3:48:01 PM UTC-5, jcbollinger wrote:
>
>
>
> On Tuesday, January 28, 2014 11:42:18 AM UTC-6, Jose Luis Ledesma wrote:
>>
>> I dont know if this may work, just an idea ( but I think it is really an 
>> ugly idea)
>>
>> Setup a dummy file for printers.conf anywhere I the filesystem
>>
>> Make it to notify the exec stop cups( setting refreshonly=true) chain it 
>> with the right file printers.conf and notify from here the cups service.
>>
>
> In the same vein, but perhaps slightly nicer, might be to sync the conf 
> file just once, with a secondary file on the target node as Jose suggests, 
> and to use that to signal an Exec that does a stop; file copy; start 
> sequence on the service.  Something like this:
>
> file { '/var/lib/site/cupsd.conf':
>   ensure => 'file',
>   content => template('cupsd.conf.erb')
> }
>
> exec { 'install-cupsd.conf-update':
>   command => '/sbin/service cups stop && cp /var/lib/site/cupsd.conf 
> /etc/cups.d/ && /sbin/service/cups start',
>   provider => 'shell',
>   refreshonly => true,
>   subscribe => File['/var/lib/site/cupsd.conf'']
> }
>
> The main problem with an approach along these lines is that it fails to 
> notice local changes to the real target config file.  It will modify the 
> true target file only when the computed content differs from the content of 
> the *proxy* file (i.e. /var/lib/site/cupsd.conf), but if local changes 
> are applied to /etc/cups.d/cupsd.conf then Puppet will not recognize the 
> need to sync.
>
> I suppose one could use an 'onlyif' parameter to the Exec instead of 
> 'refreshonly' / 'subscribe', and roll in a comparison of the proxy config 
> file with the real target.  That all will get very complicated very 
> quickly, though, if you want to manage anything about the real config file 
> other than its contents.
>
> The idea of declaring a predicate as a separate resource that will be 
> synced only if some other resource needs to be synced is not implemented in 
> Puppet, and does not fit well into the Puppet model.  Each declared 
> resource determines for itself whether it is in sync, and what to do if it 
> isn't.
>
> Therefore, the most correct way to do this in Puppet is to create a custom 
> type / provider to handle it.  The first hint was that we were whipping up 
> solutions around Execs.  The fact that the service and the config file need 
> to be managed in concert, the latter *around* the former, is the real 
> indication that the whole thing ought to be modeled as a single resource, 
> however.
>
>
> John
>
>

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

Re: [Puppet Users] Re: How to execute a target action before this one when this one triggers

[Bret Wortman]

Yeah, that's what we do in 99% of our manifests, but for cups, the config
file contains this disclaimer right at the top:

# Printer configuration file for CUPS v1.5.4
# Written by cupsd on 2014-01-24 09:47
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING

And the manpages say the same thing: "...If you do choose to edit this file
manually, you will need to stop the scheduler first, make your changes, and
then start the scheduler to make them active."

It just seems like a useful thing, if not exactly common, to say "hey, do
this thing before me, but only when I trigger." Declaring a predicate step,
as it were.





*Bret Wortman*
http://about.me/wortmanbret



On Tue, Jan 28, 2014 at 9:10 AM, jcbollinger wrote:

>
>
> On Monday, January 27, 2014 1:50:24 PM UTC-6, Bret Wortman wrote:
>>
>> I'm looking at the case of distributing /etc/cups/printers.conf.
>>
>> When this file changes, I'd like to distribute it. But before placing the
>> new file, cupsd needs to be shut down, and restarted again afterwards. This
>> can be done easily enough using an Exec to shut it down and the existing
>> Service entry to trigger a restart, but how can I tell my manifest that
>> when the File triggers, first do the Exec, then the File, then the Service?
>>
>> Is there a way to chain these together to produce the effect I'm looking
>> for? To stop a service before deploying a new config file, then start it up
>> again?
>>
>
>
> No easy way to do that, no.  On the other hand, it's probably not
> necessary.  You should be able to put the new config in place first, then
> trigger a service restart; it is a rare service that cannot be updated in
> that way.  Moreover, it makes the length of the service interruption
> slightly shorter, and it does not leave the service down if the file update
> fails for some reason.  Your manifest will also be simpler.  Just remove
> the Exec, and you should be good to go.
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/MGIkGFm1LYY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/fd78-f5e9-4fa2-82c4-37a5eaef0d8a%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

[Puppet Users] How to execute a target action before this one when this one triggers

[Bret Wortman]

I'm looking at the case of distributing /etc/cups/printers.conf.

When this file changes, I'd like to distribute it. But before placing the 
new file, cupsd needs to be shut down, and restarted again afterwards. This 
can be done easily enough using an Exec to shut it down and the existing 
Service entry to trigger a restart, but how can I tell my manifest that 
when the File triggers, first do the Exec, then the File, then the Service?

Is there a way to chain these together to produce the effect I'm looking 
for? To stop a service before deploying a new config file, then start it up 
again?

file { '/etc/cups/printers.conf':
require => Package['cups'],
source => 'puppet:///modules/cups/printers.conf',
notify => Service['cupsd'],
:
}

service { 'cupsd':
ensure => running,
enable => true,
}

exec { 'stop-cupsd':
command => 'service cupsd stop',
:
}

-- 
You received this message because you are subscribed 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/2878a401-5bd8-4ac5-996f-79c4dc289724%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Variable scoping question

[Bret Wortman]

Stare at your own problem long enough and it'll come to you.

Move the case to the manifest:

class yum {
:
case $site {
'a': { $proxy = 'proxya' }
'b': { $proxy = 'proxyb' }
'c': { $proxy = 'proxyc' }
:
default: { $proxy = '' }
}

Then change the "$proxy" to "@proxy" in the templates and lose the first 
line (scope.function_template()). Worked like a charm. 

Then I realized the data actually belonged in Hiera, not in code, so the 
case statement then just decomposed into:

$proxy = hiera('proxy')


Bret

On Friday, January 17, 2014 10:43:36 AM UTC-5, Bret Wortman wrote:
>
> I'm trying to improve my code reuse a bit, and I have some templates that 
> all start with a common case statement to determine a local proxy (I'm 
> simplifying the file slightly for our discussion here):
>
> file: proxy.erb
> <% proxy = case @site
>when "a" then "proxya"
>when "b" then "proxyb"
>when "c" then "proxyc"
>when "d" then "proxyd"
> end -%>
>
> This gets included in each template something like this:
>
> file: CentOS-Base.repo.erb
> <%= scope.function_template(["yum/proxy.erb"]) -%>
> :
> [base]
> name=CentOS-$releasever - Base
> :
> <% if $proxy -%>
> proxy=http://<%= $proxy %>:3128
> <% end -%>
> :
>
> The problem is that the "proxy" variable isn't visible from the outer 
> scope. How can I either qualify the outer reference to see it, or somehow 
> export it? Is this possible in some other fashion? I don't want to repeat 
> this code across all the various repo files; adding a proxy shouldn't mean 
> editing every single repo file template when it could mean editing just one 
> file that gets included somehow. At least, that's the goal.
>
> Thanks!
>
>
> Bret
>
>

-- 
You received this message because you are subscribed 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/988d847f-8f39-4f39-88e9-64039c958002%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Variable scoping question

[Bret Wortman]

I'm trying to improve my code reuse a bit, and I have some templates that 
all start with a common case statement to determine a local proxy (I'm 
simplifying the file slightly for our discussion here):

file: proxy.erb
<% proxy = case @site
   when "a" then "proxya"
   when "b" then "proxyb"
   when "c" then "proxyc"
   when "d" then "proxyd"
end -%>

This gets included in each template something like this:

file: CentOS-Base.repo.erb
<%= scope.function_template(["yum/proxy.erb"]) -%>
:
[base]
name=CentOS-$releasever - Base
:
<% if $proxy -%>
proxy=http://<%= $proxy %>:3128
<% end -%>
:

The problem is that the "proxy" variable isn't visible from the outer 
scope. How can I either qualify the outer reference to see it, or somehow 
export it? Is this possible in some other fashion? I don't want to repeat 
this code across all the various repo files; adding a proxy shouldn't mean 
editing every single repo file template when it could mean editing just one 
file that gets included somehow. At least, that's the goal.

Thanks!


Bret

-- 
You received this message because you are subscribed 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/926cc7db-5357-44f6-a802-101bf3a986d9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] How best to distribute yaml file for custom fact?

[Bret Wortman]

That seems to do the trick (I went with the site.pp addition). Thanks for
your help!



*Bret Wortman*
http://about.me/wortmanbret



On Fri, Dec 13, 2013 at 11:17 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:

> Hi,
>
> I can at least supply a sensible workaround: In your templates, instead
> of relying on @factname being available, use
>
> has_variable?("@factname") ? @factname : 
>
> Untested, not sure if this works with the @varname syntax in templates.
>
> Alternatively, you can do this in site.pp:
>
> if ! $factname { $factname =  }
>
> Depending on circumstance, this won't address your issue. As yet another
> alternative, you can keep puppet from parsing the template at all when
> the fact is not yet present with the same syntax.
>
> HTH,
> Felix
>
> On 12/12/2013 08:25 PM, Bret Wortman wrote:
> > I have a yaml file I'd like to distribute to my systems, and it contains
> > some identifiers which help determine where that system is (this _can_
> > be determined from the IP address, but it's so much nicer to use a
> > custom fact -- we're basically assigning names to our various subnets
> > and storing those in these yaml files where we can use them in manifests
> > and templates).
> >
> > The problem is that we are using them in templates. So when I try to
> > distribute the file, the template fails to parse, and the whole puppet
> > run just aborts. If it were just an error, I could deal with it. But
> > this seems to be a show-stopper. I see that 3.4.0 will have a way to
> > distribute these files as part of pluginsync, but I need this sooner
> > than that (and since I'm in production, I'm hesitant to jump to a .0
> > release in any case).
> >
> > Any bright ideas?
> >
> >
> > Bret
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/zMDPDGg9Nbw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/52AB3325.5050200%40alumni.tu-berlin.de
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

[Puppet Users] How best to distribute yaml file for custom fact?

[Bret Wortman]

I have a yaml file I'd like to distribute to my systems, and it contains 
some identifiers which help determine where that system is (this _can_ be 
determined from the IP address, but it's so much nicer to use a custom fact 
-- we're basically assigning names to our various subnets and storing those 
in these yaml files where we can use them in manifests and templates).

The problem is that we are using them in templates. So when I try to 
distribute the file, the template fails to parse, and the whole puppet run 
just aborts. If it were just an error, I could deal with it. But this seems 
to be a show-stopper. I see that 3.4.0 will have a way to distribute these 
files as part of pluginsync, but I need this sooner than that (and since 
I'm in production, I'm hesitant to jump to a .0 release in any case).

Any bright ideas? 


Bret

-- 
You received this message because you are subscribed 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/15f7ab89-3e32-4226-a360-fc53d9f3be89%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Exported resource resolving oddly

[Bret Wortman]

I think you're right. Thanks, John and Ken for helping get me straightened
out.



*Bret Wortman*
http://about.me/wortmanbret



On Thu, Nov 21, 2013 at 1:52 PM, jcbollinger wrote:

>
>
> On Thursday, November 21, 2013 10:29:37 AM UTC-6, Bret Wortman wrote:
>>
>> Wait -- so this collects every occurrence thoughout the database, not
>> just for the system being processed?
>>
>
>
> Yes, that's the point of exported resources.  They allow resources the
> catalog compilation process for one node's catalog to emit resource
> declarations that are available for incorporation into ANY node's catalog.
> It only makes sense to do this with resources that are in some way specific
> to the exporting node.  The canonical example is Host resources -- if each
> node exports a Host resource describing itself and collects all the
> exported Hosts, then all managed nodes will end up with /etc/hosts files
> listing (at least) all managed nodes.
>
>
>
>> I think the word "node" was tripping me up in the online documentation --
>> I was reading "node" and thinking "resource". Okay, I get it now, and
>> you're absolutely right -- this is a terrible use of exported resources. I
>> think what I was looking for was virtual, not exported, resources.
>>
>>
>
> No, I think you were just looking for collections.  You can use them with
> ordinary (non-virtual) resources.  If you are not already using virtual
> resources to manage the Yum repos then I don't see what advantage you would
> obtain by converting your ordinary resources to virtual ones.
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/zNFaLT3tf3Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/8f851721-c4f2-44e8-97ad-5e68afd8581d%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [Puppet Users] Exported resource resolving oddly

[Bret Wortman]

Wait -- so this collects every occurrence thoughout the database, not just
for the system being processed? I think the word "node" was tripping me up
in the online documentation -- I was reading "node" and thinking
"resource". Okay, I get it now, and you're absolutely right -- this is a
terrible use of exported resources. I think what I was looking for was
virtual, not exported, resources.



*Bret Wortman*
http://about.me/wortmanbret



On Thu, Nov 21, 2013 at 11:15 AM, Bret Wortman  wrote:

> The curl command, incidentally, returned nothing on the server, and
> errored on the client when typed in verbatim. And from the client, when I
> changed "localhost" to the name of the puppet master, I got a "curl (7):
> couldn't connect to host" error. I'll try Zach's tool next.
>
>
>
> *Bret Wortman*
> http://about.me/wortmanbret
>
>
>
> On Thu, Nov 21, 2013 at 10:53 AM, Ken Barber  wrote:
>
>> > I'm trying my hand at my first exported resource. In fact, this comes
>> from
>> > converting an older resource to an exported one, which might explain the
>> > problem
>> >
>> > Currently, I have two classes:
>> >
>> > class yum {
>> >File <<| tag == 'repofile' |>> ~> Exec['yum clean all']
>> >:
>> > }
>> >
>> > class yum::foo {
>> >include yum
>> >@@file { 'foo-yum':
>> >   tag => 'repofile',
>> >   path => '/etc/yum.repos.d/foo.repo',
>> >   ensure => file,
>> >   source => 'puppet:///modules/yum/foo.repo',
>> >}
>> > }
>> >
>> > When I try to run this by including yum::foo in a class, I get this
>> error:
>> >
>> > Error: Could not retrieve catalog from remote server: Error 400 on
>> SERVER:
>> > Another local or imported resource exists with the type and title
>> > File[foo-repofile] on node osem2.foo.net
>> > Warning: Not using cache on failed catalog
>> > Error: Could not retrieve catalog; skipping run
>> > #
>> >
>> > So I go looking for anything containing foo-repofile:
>> >
>> > # cd /etc/puppet/modules && find . -type f | xargs grep foo-repofile
>> > #
>> >
>> > ORIGINALLY, this resource was called foo-repofile, but at that time, it
>> was
>> > in a different module and wasn't exported. How can I purge that from
>> > PuppetDB so it gets over it and lets me use this new one? Or is the the
>> > problem somewhere or something else?
>>
>> So this is a duplicate exported resource. Something in your content
>> has created this scenario at some time, and its usually either a)
>> genuine, you really have exported the same type/title combination
>> twice from two nodes, and are now collecting it onto one, a constraint
>> violation or b) an old node has exported this in the past, and that
>> node has not been deactivated.
>>
>> The trick is to figure out how to debug these issues, since they are
>> often quite solveable.
>>
>> Zach Smith has created a tool for analyzing what has been exported to
>> PuppetDB: http://forge.puppetlabs.com/zack/exports and this is a great
>> start.
>>
>> You can also query this manually yourself:
>>
>> $ curl 'http://localhost:8080/v3/resources?query=\["=","exported",true\]'
>>
>> In general, the trick to avoid this error is to make sure the types
>> you export can never collide. In your code:
>>
>> @@file { 'foo-yum':
>>   path => '/etc/yum.repos.d/foo.repo',
>> }
>>
>> ... you are exporting something with a very fixed title and namevar
>> (foo-yum and path respectively) ... basically if two nodes export
>> this, you will always get a collision on the collecting host, so the
>> pattern you have will only work if there is 1 export, or if you pin
>> the collection query to the node that exported it.
>>
>> To be honest though - exported resources might not be appropriate for
>> this yum repo use case anyway, although perhaps I don't see it :-).
>> Can you explain why you are trying to use exported resources for this
>> purpose?
>>
>> ken.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Puppet Users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/puppet-users/zNFaLT3tf3Q/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/CAE4bNTmXwwyYwBG6aR9cNc%2BjS_MzLvoaeBaOSPT5XhCkwSQxFw%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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

[Puppet Users] Exported resource resolving oddly

[Bret Wortman]

I'm trying my hand at my first exported resource. In fact, this comes from 
converting an older resource to an exported one, which might explain the 
problem

Currently, I have two classes:

class yum {
   File <<| tag == 'repofile' |>> ~> Exec['yum clean all']
   :
}

class yum::foo {
   include yum
   @@file { 'foo-yum':
  tag => 'repofile',
  path => '/etc/yum.repos.d/foo.repo',
  ensure => file,
  source => 'puppet:///modules/yum/foo.repo',
   }
}

When I try to run this by including yum::foo in a class, I get this error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Another local or imported resource exists with the type and title 
File[foo-repofile] on node osem2.foo.net
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
#

So I go looking for anything containing foo-repofile:

# cd /etc/puppet/modules && find . -type f | xargs grep foo-repofile
# 

ORIGINALLY, this resource was called foo-repofile, but at that time, it was 
in a different module and wasn't exported. How can I purge that from 
PuppetDB so it gets over it and lets me use this new one? Or is the the 
problem somewhere or something else?

Thanks!


Bret

-- 
You received this message because you are subscribed 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/997d02b2-82bd-42af-8a3d-01522a4ee72f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Exported resource resolving oddly

[Bret Wortman]

It's partly to experiment with something I just learned, in all honesty.
But it's also because this is a resource that I only want on certain
systems, and after installing it (or any yum file for that matter), I want
to trigger a "yum clean all" so that puppet doesn't spin for a while before
yum finally discovers the new yumfile. So collecting it in the yum module
permits me to only have the "yum clean all" exec defined in one place,
triggered by the collection. And it permits me to add other,
system-specific and application-specific repos from time to time as needed
as well. These are usually put together by our developers, not repos that
we're trying to pull from the internet.

I'll readily admit it may not be the best use, but it's proving a good
learning experience.

I tried altering the title by embedding $hostname, but that didn't help.
What if I embed $title within the namevar instead, and changed title to be
the actual filename? I'll try that next



*Bret Wortman*
http://about.me/wortmanbret



On Thu, Nov 21, 2013 at 10:53 AM, Ken Barber  wrote:

> > I'm trying my hand at my first exported resource. In fact, this comes
> from
> > converting an older resource to an exported one, which might explain the
> > problem
> >
> > Currently, I have two classes:
> >
> > class yum {
> >File <<| tag == 'repofile' |>> ~> Exec['yum clean all']
> >:
> > }
> >
> > class yum::foo {
> >include yum
> >@@file { 'foo-yum':
> >   tag => 'repofile',
> >   path => '/etc/yum.repos.d/foo.repo',
> >   ensure => file,
> >   source => 'puppet:///modules/yum/foo.repo',
> >}
> > }
> >
> > When I try to run this by including yum::foo in a class, I get this
> error:
> >
> > Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER:
> > Another local or imported resource exists with the type and title
> > File[foo-repofile] on node osem2.foo.net
> > Warning: Not using cache on failed catalog
> > Error: Could not retrieve catalog; skipping run
> > #
> >
> > So I go looking for anything containing foo-repofile:
> >
> > # cd /etc/puppet/modules && find . -type f | xargs grep foo-repofile
> > #
> >
> > ORIGINALLY, this resource was called foo-repofile, but at that time, it
> was
> > in a different module and wasn't exported. How can I purge that from
> > PuppetDB so it gets over it and lets me use this new one? Or is the the
> > problem somewhere or something else?
>
> So this is a duplicate exported resource. Something in your content
> has created this scenario at some time, and its usually either a)
> genuine, you really have exported the same type/title combination
> twice from two nodes, and are now collecting it onto one, a constraint
> violation or b) an old node has exported this in the past, and that
> node has not been deactivated.
>
> The trick is to figure out how to debug these issues, since they are
> often quite solveable.
>
> Zach Smith has created a tool for analyzing what has been exported to
> PuppetDB: http://forge.puppetlabs.com/zack/exports and this is a great
> start.
>
> You can also query this manually yourself:
>
> $ curl 'http://localhost:8080/v3/resources?query=\["=","exported",true\]'
>
> In general, the trick to avoid this error is to make sure the types
> you export can never collide. In your code:
>
> @@file { 'foo-yum':
>   path => '/etc/yum.repos.d/foo.repo',
> }
>
> ... you are exporting something with a very fixed title and namevar
> (foo-yum and path respectively) ... basically if two nodes export
> this, you will always get a collision on the collecting host, so the
> pattern you have will only work if there is 1 export, or if you pin
> the collection query to the node that exported it.
>
> To be honest though - exported resources might not be appropriate for
> this yum repo use case anyway, although perhaps I don't see it :-).
> Can you explain why you are trying to use exported resources for this
> purpose?
>
> ken.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/zNFaLT3tf3Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAE4bNTmXwwyYwBG6aR9cNc%2BjS_MzLvoaeBaOSPT5XhCkwSQxFw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [Puppet Users] Exported resource resolving oddly

[Bret Wortman]

The curl command, incidentally, returned nothing on the server, and errored
on the client when typed in verbatim. And from the client, when I changed
"localhost" to the name of the puppet master, I got a "curl (7): couldn't
connect to host" error. I'll try Zach's tool next.



*Bret Wortman*
http://about.me/wortmanbret



On Thu, Nov 21, 2013 at 10:53 AM, Ken Barber  wrote:

> > I'm trying my hand at my first exported resource. In fact, this comes
> from
> > converting an older resource to an exported one, which might explain the
> > problem
> >
> > Currently, I have two classes:
> >
> > class yum {
> >File <<| tag == 'repofile' |>> ~> Exec['yum clean all']
> >:
> > }
> >
> > class yum::foo {
> >include yum
> >@@file { 'foo-yum':
> >   tag => 'repofile',
> >   path => '/etc/yum.repos.d/foo.repo',
> >   ensure => file,
> >   source => 'puppet:///modules/yum/foo.repo',
> >}
> > }
> >
> > When I try to run this by including yum::foo in a class, I get this
> error:
> >
> > Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER:
> > Another local or imported resource exists with the type and title
> > File[foo-repofile] on node osem2.foo.net
> > Warning: Not using cache on failed catalog
> > Error: Could not retrieve catalog; skipping run
> > #
> >
> > So I go looking for anything containing foo-repofile:
> >
> > # cd /etc/puppet/modules && find . -type f | xargs grep foo-repofile
> > #
> >
> > ORIGINALLY, this resource was called foo-repofile, but at that time, it
> was
> > in a different module and wasn't exported. How can I purge that from
> > PuppetDB so it gets over it and lets me use this new one? Or is the the
> > problem somewhere or something else?
>
> So this is a duplicate exported resource. Something in your content
> has created this scenario at some time, and its usually either a)
> genuine, you really have exported the same type/title combination
> twice from two nodes, and are now collecting it onto one, a constraint
> violation or b) an old node has exported this in the past, and that
> node has not been deactivated.
>
> The trick is to figure out how to debug these issues, since they are
> often quite solveable.
>
> Zach Smith has created a tool for analyzing what has been exported to
> PuppetDB: http://forge.puppetlabs.com/zack/exports and this is a great
> start.
>
> You can also query this manually yourself:
>
> $ curl 'http://localhost:8080/v3/resources?query=\["=","exported",true\]'
>
> In general, the trick to avoid this error is to make sure the types
> you export can never collide. In your code:
>
> @@file { 'foo-yum':
>   path => '/etc/yum.repos.d/foo.repo',
> }
>
> ... you are exporting something with a very fixed title and namevar
> (foo-yum and path respectively) ... basically if two nodes export
> this, you will always get a collision on the collecting host, so the
> pattern you have will only work if there is 1 export, or if you pin
> the collection query to the node that exported it.
>
> To be honest though - exported resources might not be appropriate for
> this yum repo use case anyway, although perhaps I don't see it :-).
> Can you explain why you are trying to use exported resources for this
> purpose?
>
> ken.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/zNFaLT3tf3Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAE4bNTmXwwyYwBG6aR9cNc%2BjS_MzLvoaeBaOSPT5XhCkwSQxFw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: [Puppet Users] Re: Managing account shells with augeas

[Bret Wortman]

You know what's sad? I looked at setm when I was poking around with
augtool, but didn't see any examples using Puppet so I never circled back
to it.

I ended up writing a shell script with a sed script inside, distributing
that using file and then executing it via an exec in refreshonly mode. I'll
give this a second try shortly, though.

Thanks!




*Bret Wortman*
http://about.me/wortmanbret



On Wed, Nov 13, 2013 at 2:47 PM, David Lutterkort wrote:

> On Wednesday, November 13, 2013 11:23:15 AM UTC-8, Bret Wortman wrote:
>>
>> Next fun topic for today: our security folks want to change all the
>> /sbin/nologin and related shells to /dev/null. Augeas seems the perfect
>> tool for this, but I'm having a devil of a time getting close to something
>> that'll work:
>>
>> augeas { 'fix-bad-passwd-shells':
>> context => "/files/etc/passwd",
>> changes => "set */shell[.='/sbin/nologin'] /dev/null",
>> onlyif => "match */shell[.='/sbin/nologin'] size > 0",
>> }
>>
>
> The problem is that set will only change a single node, and barf if you
> give it an expression that matches multiple nodes. What you need is setm:
>
> augeas { 'fix-bad-passwd-shells':
> context => "/files/etc/passwd",
> changes => "setm */shell[.='/sbin/nologin'] . /dev/null",
> onlyif => "match */shell[.='/sbin/nologin'] size > 0",
> }
>
>
>
>> I really wanted my onlyif to look more like:
>>
>> onlyif => "match */shell includes nologin"
>>
>
> You shouldn't really need the onlyif at all - Augeas is smart enough to
> not do anything when your setm didn't result in any changes (and IIRC the
> Puppet Augeas type has the same kind of smarts)
>
>
>> to catch other variations (like /usr/sbin/nologin), but that didn't work
>> at all. Is there a way to make that work?
>>
>
> You can also select nodes by doing a regexp match against their content;
> the following should work:
>
>  match */shell[. =~ regexp('.*/nologin$')]
>
> David
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/l28JtX83izY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/270de415-d94b-4412-96a7-c78ef3bb358b%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

[Puppet Users] Managing account shells with augeas

[Bret Wortman]

Next fun topic for today: our security folks want to change all the 
/sbin/nologin and related shells to /dev/null. Augeas seems the perfect 
tool for this, but I'm having a devil of a time getting close to something 
that'll work:

augeas { 'fix-bad-passwd-shells':
context => "/files/etc/passwd",
changes => "set */shell[.='/sbin/nologin'] /dev/null",
onlyif => "match */shell[.='/sbin/nologin'] size > 0",
}

I really wanted my onlyif to look more like:

onlyif => "match */shell includes nologin"

to catch other variations (like /usr/sbin/nologin), but that didn't work at 
all. Is there a way to make that work?

And this match works in augtool and when I run puppet, but the "set" 
doesn't. It just doesn't do anything. I think I'm close -- any augeas 
experts care to show me the error of my ways? This really feels like black 
magic.


Bret

-- 
You received this message because you are subscribed 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/ca56fd84-1395-49e7-a547-efbbaf47dae4%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Accessing hash values in defined type

[Bret Wortman]

Thanks. I'll give that a look.

I got it working like this:

define compliance::file {
  $fmode=$title['mode']
  $fname=$title['name']

  file { $fname:
path => $fname,
mode => $fmode,
  }
}

And then I can reference it like this:

compliance::file { $files: }

But I'd like to find something cleaner. Thanks for the tip, Gavin.

On Wednesday, November 13, 2013 9:47:15 AM UTC-5, Gavin Williams wrote:
>
> Bret 
>
> Sounds like 'create_resources' might be a good fit here... Take a look at 
> http://four-eyes.net/2013/09/puppet-passing-a-hash-of-variables-to-a-defined-type/
>  
>
> Alternatively, if you can't use 'create_resources' you probably want to 
> add a parameter to the defined type, and then use the indexing syntax as 
> defined here: 
> http://docs.puppetlabs.com/puppet/3/reference/lang_datatypes.html#hashesto 
> call out specific keys from said parameter. 
>
> HTH
> Gav
>
> On Wednesday, 13 November 2013 12:57:35 UTC, Bret Wortman wrote:
>>
>> I'm sure this is so simple I'm just not seeing it. I have an array of 
>> hashes of filenames & modes defined in hiera (the actual problem is a tad 
>> more complex, but for simplicity, if I can solve this, I can solve the 
>> bigger problem):
>>
>> files:
>>   - name: /etc/skel/.bashrc
>> mode: 600
>>   - name: /etc/sysctl.conf
>> mode: 600
>>
>> and so on.
>>
>> I then have a class which loads this hash and wants to execute a defined 
>> type for it, basically enforcing the mode for each file:
>>
>> define compliance::file {
>>   file { "$title":
>> mode => ???
>>   }
>> }
>>
>> And that's where I'm stuck -- how on earth do I get at the "mode" value 
>> of the array of hashes? Is there an easier way to do this that allows me to 
>> add additional hash keys for various files later?
>>
>> 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/a725ae3a-bf95-4a07-af67-c849e3970075%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Accessing hash values in defined type

[Bret Wortman]

I'm sure this is so simple I'm just not seeing it. I have an array of 
hashes of filenames & modes defined in hiera (the actual problem is a tad 
more complex, but for simplicity, if I can solve this, I can solve the 
bigger problem):

files:
  - name: /etc/skel/.bashrc
mode: 600
  - name: /etc/sysctl.conf
mode: 600

and so on.

I then have a class which loads this hash and wants to execute a defined 
type for it, basically enforcing the mode for each file:

define compliance::file {
  file { "$title":
mode => ???
  }
}

And that's where I'm stuck -- how on earth do I get at the "mode" value of 
the array of hashes? Is there an easier way to do this that allows me to 
add additional hash keys for various files later?

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/b011caaf-98da-4a32-b370-0373f92ac5f8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] hiera config oddness

[Bret Wortman]

I'm trying to set up hiera for the first time, and something really odd is
happening.

I set up my hiera.yaml file in /etc/puppet/, and it was pretty simple:

---
:backends:
  - yaml
:hierarchy:
  - "%{hostname}"
  - common

:yaml:
  :datadir: /etc/puppet/data

So I added a "flag" class, which just has a manifest containing one
"notify" so I can see that it's getting loaded. I stuck it in
"data/common.yaml":

---
puppetserver : 'zgepetto.foo.net'
ipamaster : 'ipamaster'

classes:
  - role::base
  - flag

And lo and behold, the notify showed up when I ran puppet agent -t --noop.

Then I tried moving the flag mention into a file named for my test node,
zw129.yaml:

---
classes:
  - role::workstation
  - flag

But the flag never got picked up. Confused, I moved it back to common.yaml
and there it was again. Eventually, I got around to removing "common" from
my hiera.yaml file (leaving only the "{hostname}" in the hierarchy) and
still common is getting loaded, even after doing a "service puppetmaster
restart".

I've looked around for other instances of hiera.yaml but don't see any.
What else could be causing hiera to load a common.yaml that I'm not asking
for, and neglecting the zw129.yaml that I am asking for? It sure feels like
I'm picking up an incorrect config file somewhere, but I'm not sure where
to look or what logfile to examine next.

Thanks!

*
*
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret

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

[Puppet Users] System manifests & parse order

[Bret Wortman]

Is there a way to set up my system so that I can do something like this in
my site.pp file:

import 'nodes/*.pp'
import 'node-groups/*.pp'

What I'm looking for is a way to have a node-groups/webserver.pp file which
specifies the default configuration for a web server. Then, if I have a
one-off web server which requires a different configuration, I can drop it
into nodes/web1.pp and have that manifest be the one which is used for the
named host

Within the node-groups/*.pp files, nodes are specified using regexes.
Within the nodes/*.pp files, they'd be specified using exact strings.

I'm doing this now, but have discovered that quite often, the group
manifest gets used in preference to the individual manifest. How can I
reverse this behavior? Is it even possible?

*
*
*Bret Wortman*

http://damascusgrp.com/
http://about.me/wortmanbret

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

Re: [Puppet Users] Re: Array use as loop-type construct?

[Bret Wortman]

Oh. I've never really grokked the defined type stuff. I can see now I
need to dig in and make sense of it.

Thanks, John!


*
*
*Bret Wortman*
<http://damascusgrp.com/>
http://damascusgrp.com/ <http://bretwortman.com/>
http://about.me/wortmanbret


On Mon, Jul 29, 2013 at 1:19 PM, jcbollinger wrote:

>
>
> On Tuesday, July 23, 2013 12:32:43 PM UTC-5, Bret Wortman wrote:
>>
>> I'm trying to use a puppet manifest to set up a series of backup jobs on
>> servers which are each running a variety of mysql databases. My manifest
>> currently looks something like this, which almost works:
>>
>> class backups () {
>>
>> Cron {
>> ensure => present,
>> user => root,
>> }
>>
>> $remote_dest = ['zx2:/data/src/backups','zx3:**/data/backups']
>>
>> if $hostname == "www" {
>> $databases = ['phpbb3','wikidb','rt4','**wordpress']
>> $bkp_dest = "/data/backup"
>> elsif...
>> :
>> }
>>
>> cron { $databses:
>> command => "mysqldump --user admin $databases | gzip >
>> mysql-$databases-`date +%Y%m%d`.gz",
>> hour => 1,
>> minute => 20,
>> }
>>
>> cron { $remote_dest:
>> command => "rsync -arzv $bkp_dest $remote_dest",
>> hour => 4,
>> minute => 40,
>> }
>> }
>>
>> I get the right number of cron jobs built, but when the array variables
>> are quoted, I get the contents all concatenated together.
>>
>
>
> Yes, that is what you get when you convert an array to a string.
>
>
>
>> What I'd like is to simulate a "for x in array" kind of construct. Is
>> that possible using puppet? I'd rather not have to build this and specify
>> each job by hand, which seems really clunky given the elegance of the tool.
>> I'm sure I'm just not seeing something.
>>
>
>
> There is the template approach you discovered, when it is applicable.  The
> more general approach is to use a defined type in conjunction with Puppet's
> shorthand for declaring multiple resources based on an array of their
> titles.  You're example code is heading in the right direction.  Here's how
> a working version might look:
>
> define backups::database () {
>   cron { "backup_database_${title}":
>
> ensure  => present,
> user=> root,
> command => "mysqldump --user admin ${title} | gzip >
> mysql-${title}-`date +%Y%m%d`.gz",
> hour=> 4,
> minute  => 40,
>   }
> }
>
> define backups::remote () {
>   cron { "backup_remote_dest_${title}":
>
> ensure  => present,
> user=> root,
> command => "rsync -arzv ${backups::bkp_dest} ${title}",
> hour=> 1,
> minute  => 20,
>   }
> }
>
> class backups {
>   # ...
>   # Set variables, including $databases, $bkp_dest, and $remote_dest
>   # ...
>
>   backups::database { $databases: }
>   backups::remote { $remote_dest: }
> }
>
> Note the use of the automatic $title variable inside the definitions to
> refer to the title of the defined type instance.  You can declare other
> parameters to the definition, too, but as used in the example, all
> instances would get the same values for those parameters.  There are ways
> to be cleverer about that sort of thing, once you have a hold of what's
> going on.
>
>
> John
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/rm1wx3s4ZiE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

[Puppet Users] Re: Array use as loop-type construct?

[Bret Wortman]

For completeness, I solved this myself by using a template instead of 
trying to do this all within a manifest:

#!/bin/sh

<% databases.each do |db| -%>
<%= "mysqldump --user admin #{db} | gzip > mysql-#{db}-`date +%Y%m%d`.gz" %>
<% end -%>

<% remote_dest.each do |rd| -%>
<%= "rsync -arzv #{bkp_dest} #{rd}" %>
<% end -%>

And the manifest then simplifies to:

file { "backup-script":
ensure => present,
path => $mysql-backup-script,
content => template('backups/backup-mysql.erb'),
mode => 744,
owner => "root",
group => "root",
}

cron { "backup-mysql":
command => $mysql-backup-script,
    hour => 1,
minute => 20,
require => File['backup-script'],
}



On Tuesday, July 23, 2013 1:32:43 PM UTC-4, Bret Wortman wrote:
>
> I'm trying to use a puppet manifest to set up a series of backup jobs on 
> servers which are each running a variety of mysql databases. My manifest 
> currently looks something like this, which almost works:
>
> class backups () {
>
> Cron {
> ensure => present,
> user => root,
> }
>
> $remote_dest = ['zx2:/data/src/backups','zx3:/data/backups']
>
> if $hostname == "www" {
> $databases = ['phpbb3','wikidb','rt4','wordpress']
> $bkp_dest = "/data/backup"
> elsif...
> :
> }
>
> cron { $databses:
> command => "mysqldump --user admin $databases | gzip > 
> mysql-$databases-`date +%Y%m%d`.gz",
> hour => 1,
> minute => 20,
> }
>
> cron { $remote_dest:
> command => "rsync -arzv $bkp_dest $remote_dest",
> hour => 4,
> minute => 40,
> }
> }
>
> I get the right number of cron jobs built, but when the array variables 
> are quoted, I get the contents all concatenated together. What I'd like is 
> to simulate a "for x in array" kind of construct. Is that possible using 
> puppet? I'd rather not have to build this and specify each job by hand, 
> which seems really clunky given the elegance of the tool. I'm sure I'm just 
> not seeing something.
>
> Thanks!
>
>
> Bret
>

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

[Puppet Users] Array use as loop-type construct?

[Bret Wortman]

I'm trying to use a puppet manifest to set up a series of backup jobs on 
servers which are each running a variety of mysql databases. My manifest 
currently looks something like this, which almost works:

class backups () {

Cron {
ensure => present,
user => root,
}

$remote_dest = ['zx2:/data/src/backups','zx3:/data/backups']

if $hostname == "www" {
$databases = ['phpbb3','wikidb','rt4','wordpress']
$bkp_dest = "/data/backup"
elsif...
:
}

cron { $databses:
command => "mysqldump --user admin $databases | gzip > 
mysql-$databases-`date +%Y%m%d`.gz",
hour => 1,
minute => 20,
}

cron { $remote_dest:
command => "rsync -arzv $bkp_dest $remote_dest",
hour => 4,
minute => 40,
}
}

I get the right number of cron jobs built, but when the array variables are 
quoted, I get the contents all concatenated together. What I'd like is to 
simulate a "for x in array" kind of construct. Is that possible using 
puppet? I'd rather not have to build this and specify each job by hand, 
which seems really clunky given the elegance of the tool. I'm sure I'm just 
not seeing something.

Thanks!


Bret

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

Re: [Puppet Users] How to indicate multiple dependency?

[Bret Wortman]

I wasn't sure how the "before" would work in that instance -- and my 
experimental facilities are limited. But if the before really won't trigger 
until all the members of the array complete, then that sounds like the 
perfect solution for me. Thanks!

On Wednesday, May 8, 2013 9:57:19 AM UTC-4, pmbuko wrote:
>
> On May 8, 2013, at 6:52 AM, Bret Wortman 
> > 
> wrote:
>
> What's the right/best way to indicate that a particular entry in a 
> manifest (a file in this case) depends on successful installation of over 
> 30 packages, all indicated in the same manifest? I could do this, but it 
> seems cumbersome:
>
> package { 'pkg1': }
> Package['pkg1'] -> File['file1']
>
> package { 'pkg2': }
> Package['pkg2'] -> File['file2']
> :
> :
> file { 'file2':
> path => '/path/to/file2',
> :
> }
>
> There must be a better way that I'm just not seeing. Thanks!
>
>
> Bret Wortman
>
>
> Bret,
>
> Puppet lets you use arrays to make your manifests more concise. In this 
> case, if these 30 package resources differ only in name, i.e. all their 
> parameters are the same except for the package name, then you can use this 
> following to make the dependency declaration less cumbersome:
>
> package { [ "pkg1",
> "pkg2",
> .
> .
> "pkg30" ]:
>   ensure => installed,
>   before => File['file2'],
> }
> file { 'file2':
>   ensure  => file,
>   path=> "/path/to/file2",
>   content => "I exist only after all 30 packages are installed.",
> }
>
> --
> Peter
>

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

[Puppet Users] Re: How to indicate multiple dependency?

[Bret Wortman]

On Wednesday, May 8, 2013 9:09:34 AM UTC-4, jcbollinger wrote:
>
>
>
> On Wednesday, May 8, 2013 5:52:44 AM UTC-5, Bret Wortman wrote:
>>
>> What's the right/best way to indicate that a particular entry in a 
>> manifest (a file in this case) depends on successful installation of over 
>> 30 packages, all indicated in the same manifest? 
>
>
>
> What is the significance to you of the packages being in the same 
> manifest?  To Puppet, it matters very little.  Do you mean they are in the 
> same class?  Or could they be made to be?
>

They are in the same class, actually. I wasn't clear enough -- wrote this 
before my coffee kicked in.
 

>
>  
>
>> I could do this, but it seems cumbersome:
>>
>> package { 'pkg1': }
>> Package['pkg1'] -> File['file1']
>>
>> package { 'pkg2': }
>> Package['pkg2'] -> File['file2']
>> :
>> :
>> file { 'file2':
>> path => '/path/to/file2',
>> :
>> }
>>
>>
>
> You've confused me a bit there.  Your question suggests that you want a 
> single file depending on all the packages, but the example looks like you 
> may mean multiple files, each depending on one package.  Or maybe not.  I 
> am proceeding based on the question rather than on the ambiguous example.
>

Blaming coffee again. The "file2" is a typo. All the right-hand sides 
should read ' -> File["file1"]'.
 

>
>  
>
>> There must be a better way that I'm just not seeing. Thanks!
>>
>>
> There is a variety of ways.  If the packages are all in the same class, 
> and File['file2'] is in a different one, then you can declare the file this 
> way:
>
> file { '/path/to/file2':
>   require => Class['mymodule::manypackages']
> }
>
> Alternatively, you can use tags to recognize the packages in question, and 
> write the relationship like this:
>
> Package<| tag == '' |> -> File['/path/to/file2']
>
> Tag 'some-tag' could be explicitly declared on the Packages, or under some 
> circumstances it would work to just use the class name (which is 
> automatically included in resources' tags).  With explicitly declared tags, 
> this can work even when the packages are in different classes or even not 
> in classes at all.
>
> Or you can perhaps use resource defaults for this.  That's more brittle 
> and more susceptible to unintended relationships, but it's easy to set up.  
> To do that, put this at the top of the body of the class(es) that declare 
> the packages:
>
> include 
>
> Package {
>   before => File['/path/to/file2']
> }
>
> There are other alternatives, too.
>

Okay, so if the class actually looks like this, say:

class blacklisted () {

Package {
ensure => absent,
tag => "blacklisted",
}

package { 'pkg1': }
package { 'pkg2': }
package { 'pkg3': }
:
package { 'pkg30': }

file { '/path/to/file1':
ensure => present,
}

Package<| tag == 'blacklisted' |> -> File['/path/to/file1']

}

Should do it, right? I've never done anything with tags before, but this 
may cause me to rework a few modules I've written
 

>
>
> John
>
>

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

Re: [Puppet Users] Trouble writing authorized_keys2

[Bret Wortman]

I ended up deleting the whole .ssh directory for these users and that 
resolved the problem. It's also worked well on new systems now, so I think 
I'm out of the woods. Thanks for the pointers!

On Tuesday, May 7, 2013 2:09:40 PM UTC-4, Stefan Schulte wrote:
>
> On Tue, 7 May 2013 10:11:44 -0400 
> Bret Wortman > wrote: 
>
> > I've got a situation where a manifest fails when writing one 
> > particular key for a user. What I have is a manifest that looks like 
> > this: 
> > 
> > class my::accounts () { 
> > 
> > Ssh_authorized_key { 
> > ensure => present, 
> > type => ssh-dss, 
> > } 
> > 
> > Then, after making sure the user, group, and authorized_keys2 file 
> > exist: 
> > 
> > ssh_authorized_key { "key-name-1": 
> > key => "omitted", 
> > user => "user", 
> > target => "/home/user/.ssh/authorized_keys2", 
> > require => File["/home/user/.ssh/authorized_keys2"], 
> > } 
> > 
> > There's a lengthy series of these -- most of them work, but one will 
> > fail with this error: 
> > 
> > Error: Puppet::Util::FileType::FileTypeFlat could not write 
> > /home/user/.ssh/authorized_keys2: Permission denied - 
> > /home/user/.ssh/authorized_keys2 
> > Error: /Stage[main]/My::Accounts/Ssh_authorized_key[key-name-8]: 
> > Could not evaluate: Puppet::Util::FileType::FileTypeFlat could nto 
> > write /home/xmmgr/.ssh/authorized_keys2: Permission denied - 
> > /home/user/.ssh/authorized_keys2 
> > 
> > This is not the first nor the last key, and I get around 19 entries 
> > in the file, so I'm not seeing why this one in particular is failing. 
> > Structurally, it looks exactly like all the others. Any ideas? 
> > 
> > Thanks! 
> > 
>
> Do you also see notice messages about changing targets? If a ssh key is 
> already present in targetA and you specifiy targetB in your manifest, 
> puppet will try to migrate the key from targetA to targetB. As a result 
> puppet has to rewrite both targetA (remove the key) and targetB (add 
> the key) and there is a know bug where puppet tries to write the files 
> with the wrong user context (hence the Permission denied messages). 
>
> So if you see "target change" events, you'll probably hit 
> http://projects.puppetlabs.com/issues/10850#note-12 
>
> -Stefan 
>

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

[Puppet Users] How to indicate multiple dependency?

[Bret Wortman]

What's the right/best way to indicate that a particular entry in a manifest 
(a file in this case) depends on successful installation of over 30 
packages, all indicated in the same manifest? I could do this, but it seems 
cumbersome:

package { 'pkg1': }
Package['pkg1'] -> File['file1']

package { 'pkg2': }
Package['pkg2'] -> File['file2']
:
:
file { 'file2':
path => '/path/to/file2',
:
}

There must be a better way that I'm just not seeing. Thanks!


Bret Wortman

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

[Puppet Users] How to have one file depend on many packages

[Bret Wortman]

Here's a puzzler (though I'm sure the answer is obvious and I'm just not 
seeing it):

I have a manifest where I'm listing about 40-50 packages that I want the 
system to remove, and a file that I want to create only after successful 
removal of all the packages.

What's the best way to show this dependency so that the file is only 
created after all the packages are removed?

Thanks!


Bret

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

[Puppet Users] Trouble writing authorized_keys2

[Bret Wortman]

I've got a situation where a manifest fails when writing one particular key
for a user. What I have is a manifest that looks like this:

class my::accounts () {

Ssh_authorized_key {
ensure => present,
type => ssh-dss,
}

Then, after making sure the user, group, and authorized_keys2 file exist:

ssh_authorized_key { "key-name-1":
key => "omitted",
user => "user",
target => "/home/user/.ssh/authorized_keys2",
require => File["/home/user/.ssh/authorized_keys2"],
}

There's a lengthy series of these -- most of them work, but one will fail
with this error:

Error: Puppet::Util::FileType::FileTypeFlat could not write
/home/user/.ssh/authorized_keys2: Permission denied -
/home/user/.ssh/authorized_keys2
Error: /Stage[main]/My::Accounts/Ssh_authorized_key[key-name-8]: Could not
evaluate: Puppet::Util::FileType::FileTypeFlat could nto write
/home/xmmgr/.ssh/authorized_keys2: Permission denied -
/home/user/.ssh/authorized_keys2

This is not the first nor the last key, and I get around 19 entries in the
file, so I'm not seeing why this one in particular is failing.
Structurally, it looks exactly like all the others. Any ideas?

Thanks!

*
*
*Bret Wortman*
<http://damascusgrp.com/>
http://damascusgrp.com/ <http://bretwortman.com/>
http://twitter.com/BretWortman

-- 
You received this message because you are subscribed 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] Certificate nightmares

[Bret Wortman]

It was. I filed it away for future reference!

*
*
*

Bret Wortman***
http://bretwortman.com/
http://twitter.com/BretWortman



On Mon, Feb 11, 2013 at 7:55 AM, Nikola Petrov  wrote:

> I think this should be put somewhere in a wiki or the docs.
>
>
> /me referencing this email for future
>
> Best, Nikola
>
> On Fri, Feb 08, 2013 at 03:58:22PM -0800, Nick Fagerlund wrote:
> > If a brand new never-seen-before agent starts up, it goes like this:
> >
> > * Do I have a private key? Nope? Better generate one.
> > * Okay, do I have a certificate? Nope? See if the master already has one
> > for me. This looks like a GET request to /certificate/.
> >   * If it gets one, it's good to go.
> > * Master didn't give me a cert. Okay, have I submitted a certificate
> > signing request before? Look in $ssldir/certificate_requests for my own
> > name.
> >   * If there's one there, it bails and waits, assuming it's waiting for
> the
> > master to sign that thing.
> > * Okay, there's nothing there, but maybe I developed amnesia. Better ask
> > the master if I've asked for one. This looks like a GET request to
> > /certificate_request/.
> >   * If the master says it's already asked, it will just bail and say "I'm
> > still waiting for that."
> > * Okay, I never even asked for a cert, it looks like. Well, time to ask
> for
> > one. This looks like a PUT request to /certificate_request/.
> >   * Now if autosign is turned on, it can GET /certificate/ and
> > continue; otherwise it'll bail and go through this whole process again
> next
> > time, in which case it says "yes I have a private key, no I don't have a
> > cert" and gets to work on the second step above.
> >
> > What I'm seeing in that snippet from your log is that it seems to think
> it
> > has submitted a certificate request before. I just tested with my own
> > machines, and it looks like if your agent still has a
> > $ssldir/certificate_requests/name.pem file sitting around (and crucially,
> > it doesn't automatically destroy these when it gets a cert, so if it used
> > to have a cert and you didn't nuke the whole SSLdir, it's probably
> there),
> > it asks for a cert but doesn't ask the master if it's ever asked for a
> > cert.
> >
> > So check that certificate_requests dir and nuke it if there's anything
> > there, then get back to us?
> >
> > On Wednesday, February 6, 2013 10:23:28 AM UTC-8, Bret Wortman wrote:
> > >
> > > My test node doesn't have its certs either.
> > >
> > > I've now started puppetmaster in verbose mode:
> > >
> > > # puppet master --no-daemonize --verbose
> > > :
> > > :
> > > :
> > > Info: Could not find certificate for 'nodename.my.net'
> > > Info: Could not find certificate for 'nodename.my.net'
> > > Info: Could not find certificate for 'nodename.my.net'
> > >
> > > This will repeat three times whenever I try to connect. For another
> node
> > > that tried to connect while I was testing, I get something more
> sinister:
> > >
> > > Warning: Denying access: Forbidden request: othernode.my.net(10.0.0.1)
> > > access to /file_metadata/plugins [search] at :99
> > > Error: Forbidden request: othernode.my.net(10.0.0.1) access to
> > > /file_metadata/plugins [search] at :99
> > > Info: access[/]: defaulting to no access for othernode.my.net
> > >
> > > Also repeating four times; one [search], two [find]s and a [save].
> > >
> > >
> > > On Wednesday, February 6, 2013 1:18:52 PM UTC-5, Wolf Noble wrote:
> > >>
> > >> Did you try removing the cert from a node and seeing if that changes
> the
> > >> behavior? you removed the certs from the master, but the node still
> thinks
> > >> it has a valid cert maybe?
> > >>
> > >>
> > >> 
> > >>
> > >> This message may contain confidential or privileged information. If
> you
> > >> are not the intended recipient, please advise us immediately and
> delete
> > >> this message. See http://www.datapipe.com/legal/email_disclaimer/ for
> > >> further information on confidentiality and the risks of non-secure
> > >> electronic communication. If you cannot access these links, please
> notify
> > >> us by reply message and we will send the contents to you.
> > >>
&

Re: [Puppet Users] Certificate nightmares

[Bret Wortman]

It was this problem. After nuking the /var/lib/puppet/ssl directory, it 
re-synced with the server just fine. Thanks!

On Friday, February 8, 2013 6:58:22 PM UTC-5, Nick Fagerlund wrote:
>
> If a brand new never-seen-before agent starts up, it goes like this:
>
> * Do I have a private key? Nope? Better generate one.
> * Okay, do I have a certificate? Nope? See if the master already has one 
> for me. This looks like a GET request to /certificate/.
>   * If it gets one, it's good to go.
> * Master didn't give me a cert. Okay, have I submitted a certificate 
> signing request before? Look in $ssldir/certificate_requests for my own 
> name.
>   * If there's one there, it bails and waits, assuming it's waiting for 
> the master to sign that thing. 
> * Okay, there's nothing there, but maybe I developed amnesia. Better ask 
> the master if I've asked for one. This looks like a GET request to 
> /certificate_request/.
>   * If the master says it's already asked, it will just bail and say "I'm 
> still waiting for that."
> * Okay, I never even asked for a cert, it looks like. Well, time to ask 
> for one. This looks like a PUT request to /certificate_request/.
>   * Now if autosign is turned on, it can GET /certificate/ and 
> continue; otherwise it'll bail and go through this whole process again next 
> time, in which case it says "yes I have a private key, no I don't have a 
> cert" and gets to work on the second step above. 
>
> What I'm seeing in that snippet from your log is that it seems to think it 
> has submitted a certificate request before. I just tested with my own 
> machines, and it looks like if your agent still has a 
> $ssldir/certificate_requests/name.pem file sitting around (and crucially, 
> it doesn't automatically destroy these when it gets a cert, so if it used 
> to have a cert and you didn't nuke the whole SSLdir, it's probably there), 
> it asks for a cert but doesn't ask the master if it's ever asked for a 
> cert. 
>
> So check that certificate_requests dir and nuke it if there's anything 
> there, then get back to us?
>
> On Wednesday, February 6, 2013 10:23:28 AM UTC-8, Bret Wortman wrote:
>>
>> My test node doesn't have its certs either.
>>
>> I've now started puppetmaster in verbose mode:
>>
>> # puppet master --no-daemonize --verbose
>> :
>> :
>> :
>> Info: Could not find certificate for 'nodename.my.net'
>> Info: Could not find certificate for 'nodename.my.net'
>> Info: Could not find certificate for 'nodename.my.net'
>>
>> This will repeat three times whenever I try to connect. For another node 
>> that tried to connect while I was testing, I get something more sinister:
>>
>> Warning: Denying access: Forbidden request: othernode.my.net(10.0.0.1) 
>> access to /file_metadata/plugins [search] at :99
>> Error: Forbidden request: othernode.my.net(10.0.0.1) access to 
>> /file_metadata/plugins [search] at :99
>> Info: access[/]: defaulting to no access for othernode.my.net
>>
>> Also repeating four times; one [search], two [find]s and a [save].
>>
>>
>> On Wednesday, February 6, 2013 1:18:52 PM UTC-5, Wolf Noble wrote:
>>>
>>> Did you try removing the cert from a node and seeing if that changes the 
>>> behavior? you removed the certs from the master, but the node still thinks 
>>> it has a valid cert maybe? 
>>>
>>>
>>>  
>>>
>>> This message may contain confidential or privileged information. If you 
>>> are not the intended recipient, please advise us immediately and delete 
>>> this message. See http://www.datapipe.com/legal/email_disclaimer/ for 
>>> further information on confidentiality and the risks of non-secure 
>>> electronic communication. If you cannot access these links, please notify 
>>> us by reply message and we will send the contents to you. 
>>>
>>

-- 
You received this message because you are subscribed 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] Certificate nightmares

[Bret Wortman]

My test node doesn't have its certs either.

I've now started puppetmaster in verbose mode:

# puppet master --no-daemonize --verbose
:
:
:
Info: Could not find certificate for 'nodename.my.net'
Info: Could not find certificate for 'nodename.my.net'
Info: Could not find certificate for 'nodename.my.net'

This will repeat three times whenever I try to connect. For another node 
that tried to connect while I was testing, I get something more sinister:

Warning: Denying access: Forbidden request: othernode.my.net(10.0.0.1) 
access to /file_metadata/plugins [search] at :99
Error: Forbidden request: othernode.my.net(10.0.0.1) access to 
/file_metadata/plugins [search] at :99
Info: access[/]: defaulting to no access for othernode.my.net

Also repeating four times; one [search], two [find]s and a [save].


On Wednesday, February 6, 2013 1:18:52 PM UTC-5, Wolf Noble wrote:
>
> Did you try removing the cert from a node and seeing if that changes the 
> behavior? you removed the certs from the master, but the node still thinks 
> it has a valid cert maybe? 
>
>
>  
>
> This message may contain confidential or privileged information. If you 
> are not the intended recipient, please advise us immediately and delete 
> this message. See http://www.datapipe.com/legal/email_disclaimer/ for 
> further information on confidentiality and the risks of non-secure 
> electronic communication. If you cannot access these links, please notify 
> us by reply message and we will send the contents to you. 
>

-- 
You received this message because you are subscribed 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] Certificate nightmares

[Bret Wortman]

I should add that shortly thereafter, webrick reports this:

[2013-02-06 12:06:45] ERROR OpenSSL::SSL::SSLError: SSL_accept returned=1 
errno=0 state=SSLv3 read client certificate A: sslv3 alert certificate 
revoked
/usr/share/ruby/vendor_ruby/puppet/network/http/webrick.rb:32:in 
`accept'
/usr/share/ruby/vendor_ruby/puppet/network/http/webrick.rb:32:in `block 
(3 levels) in listen'
/usr/share/ruby/webrick/server.rb:191:in `call'
/usr/share/ruby/webrick/server.rb:191:in `block in start_thread'

This repeats quite a few times before stopping.

On Wednesday, February 6, 2013 12:07:43 PM UTC-5, Bret Wortman wrote:
>
> Yeah, It is running (though I had been assuming that -- thanks for 
> prompting me to check!); "puppet agent -t" works when run on the master, 
> but only there. And I can see the requests hitting in the 
> /var/log/puppet/masterhttp.log file:
>
> [2013-02-06 12:04:55] nodename.my.net - - [06/Feb/2013:12:04:55 EST] "GET 
> /production/certificate/nodename.my.net? HTTP/1.1" 404 40
> [2013-02-06 12:04:55] - -> /production/certificate/nodename.my.net?
>
> It's absolutely right that the cert doesn't exist yet -- the client should 
> be requesting one (since I deleted the one it had both on the that node and 
> on the server via puppet cert clean) but that request isn't getting 
> through, it seems.
>
>
>
> On Wednesday, February 6, 2013 12:01:43 PM UTC-5, Brendan O'Bra wrote:
>>
>> Are you sure the master is running?
>> This:
>> Error: Could not request certificate: Connection refused - connect(2)
>> seems like it might not be listening.
>>
>>
>> On Wed, Feb 6, 2013 at 7:44 AM, Bret Wortman wrote:
>>
>>> I think I really hosed my certificates somehow this morning trying to 
>>> get PuppetDB and Puppet talking again -- here's where I stand.
>>>
>>> My Puppet master and PuppetDB are again talking, or at least, aren't 
>>> complaining about communication.
>>>
>>> From my puppet master, I can run "puppet agent -t", and it runs just 
>>> fine.
>>>
>>> From any other node on which puppet had been running, I get this:
>>>
>>> # puppet agent -t
>>> Error: Could not request certificate: Connection refused - connect(2)
>>> Exiting; failed to retrieve certificate and waitforcert is disabled
>>> #
>>>
>>> Now, I have auto-signing enabled (my systems are on a private network) 
>>> and when I go to my master:
>>>
>>> # puppet cert list
>>> #
>>>
>>> There's nothing. Nothing in the logs. No one is talking to my 
>>> puppetmaster this morning.
>>>
>>> I *did* delete a bunch of certs in my flailing attempts to get puppet & 
>>> puppetdb talking and suspect that may be the cause; but how can I get my 
>>> remote agents talking to the puppet master again?
>>>
>>> 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...@googlegroups.com.
>>> To post to this group, send email to puppet...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>
>>
>> -- 
>> GVoice: 707.410.0371 
>> LinkedIn: http://www.linkedin.com/in/brendanobra
>>
>>  

-- 
You received this message because you are subscribed 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] Certificate nightmares

[Bret Wortman]

Yeah, It is running (though I had been assuming that -- thanks for 
prompting me to check!); "puppet agent -t" works when run on the master, 
but only there. And I can see the requests hitting in the 
/var/log/puppet/masterhttp.log file:

[2013-02-06 12:04:55] nodename.my.net - - [06/Feb/2013:12:04:55 EST] "GET 
/production/certificate/nodename.my.net? HTTP/1.1" 404 40
[2013-02-06 12:04:55] - -> /production/certificate/nodename.my.net?

It's absolutely right that the cert doesn't exist yet -- the client should 
be requesting one (since I deleted the one it had both on the that node and 
on the server via puppet cert clean) but that request isn't getting 
through, it seems.



On Wednesday, February 6, 2013 12:01:43 PM UTC-5, Brendan O'Bra wrote:
>
> Are you sure the master is running?
> This:
> Error: Could not request certificate: Connection refused - connect(2)
> seems like it might not be listening.
>
>
> On Wed, Feb 6, 2013 at 7:44 AM, Bret Wortman 
> 
> > wrote:
>
>> I think I really hosed my certificates somehow this morning trying to get 
>> PuppetDB and Puppet talking again -- here's where I stand.
>>
>> My Puppet master and PuppetDB are again talking, or at least, aren't 
>> complaining about communication.
>>
>> From my puppet master, I can run "puppet agent -t", and it runs just fine.
>>
>> From any other node on which puppet had been running, I get this:
>>
>> # puppet agent -t
>> Error: Could not request certificate: Connection refused - connect(2)
>> Exiting; failed to retrieve certificate and waitforcert is disabled
>> #
>>
>> Now, I have auto-signing enabled (my systems are on a private network) 
>> and when I go to my master:
>>
>> # puppet cert list
>> #
>>
>> There's nothing. Nothing in the logs. No one is talking to my 
>> puppetmaster this morning.
>>
>> I *did* delete a bunch of certs in my flailing attempts to get puppet & 
>> puppetdb talking and suspect that may be the cause; but how can I get my 
>> remote agents talking to the puppet master again?
>>
>> 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...@googlegroups.com .
>> To post to this group, send email to puppet...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> GVoice: 707.410.0371 
> LinkedIn: http://www.linkedin.com/in/brendanobra
>
>  

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

[Puppet Users] Certificate nightmares

[Bret Wortman]

I think I really hosed my certificates somehow this morning trying to get 
PuppetDB and Puppet talking again -- here's where I stand.

My Puppet master and PuppetDB are again talking, or at least, aren't 
complaining about communication.

>From my puppet master, I can run "puppet agent -t", and it runs just fine.

>From any other node on which puppet had been running, I get this:

# puppet agent -t
Error: Could not request certificate: Connection refused - connect(2)
Exiting; failed to retrieve certificate and waitforcert is disabled
#

Now, I have auto-signing enabled (my systems are on a private network) and 
when I go to my master:

# puppet cert list
#

There's nothing. Nothing in the logs. No one is talking to my puppetmaster 
this morning.

I *did* delete a bunch of certs in my flailing attempts to get puppet & 
puppetdb talking and suspect that may be the cause; but how can I get my 
remote agents talking to the puppet master again?

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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Re: Best way for conditional dependency?

[Bret Wortman]

A. So since that module won't be included on all machines, neither will 
the dependency. I get it.

Thanks, Joe.

On Tuesday, February 5, 2013 3:06:08 PM UTC-5, joe wrote:
>
> If freeipa-client will be on all systems, just order it the other way. 
>
> In the user module, make your class before freeipa-client. That way, the 
> ordering is only in place when you include the user class.
>
> On Tuesday, February 5, 2013 11:21:30 AM UTC-7, Bret Wortman wrote:
>>
>> I have a situation where I have a module which manages some user accounts 
>> which, if required by a system, need to be physically present on that box. 
>> I have another module which sets up freeipa-client for all systems.
>>
>> The catch is that when the first module is present, it needs to be 
>> installed prior to the ipa-client module. But if I give ipa-client a 
>> dependency on it, it will force it to always be installed, which isn't what 
>> I want. 
>>
>> What's the most puppet-ish way to handle this?
>>
>

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

[Puppet Users] Best way for conditional dependency?

[Bret Wortman]

I have a situation where I have a module which manages some user accounts 
which, if required by a system, need to be physically present on that box. 
I have another module which sets up freeipa-client for all systems.

The catch is that when the first module is present, it needs to be 
installed prior to the ipa-client module. But if I give ipa-client a 
dependency on it, it will force it to always be installed, which isn't what 
I want. 

What's the most puppet-ish way to handle this?

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

[Puppet Users] F18 import error?

[Bret Wortman]

Should I be concerned?

[root@fs1 ~]# cobbler import --name=F18 
--path=rsync://mirrors.kernel.org/fedora/releases/18/Fedora/x86_64/os 
--arch=x86_64
task started: 2013-01-18_062009_import
task started (id=Media import, time=Fri Jan 18 06:20:09 2013)
Found a redhat compatible signature: Packages
adding distros
creating new distro: F18-x86_64
creating new profile: F18-x86_64
associating repos
traversing distro F18-x86_64
descent into /var/www/cobbler/ks_mirror/F18-x86_64
processing repo at : /var/www/cobbler/ks_mirror/F18-x86_64
need to process repo/comps: /var/www/cobbler/ks_mirror/F18-x86_64
looking for /var/www/cobbler/ks_mirror/F18-x86_64/repodata/*comps*.xml
running: createrepo -c cache -s sha --groupfile 
/var/www/cobbler/ks_mirror/F18-x86_64/repodata/4045e44200e7c3ddf565c6b8c7512455737c5d0dfcfe6df1e089885c6701620f-Fedora-18-comps.xml
 
/var/www/cobbler/ks_mirror/F18-x86_64
received on stdout: Spawning worker 0 with 4125 pkgs
Workers Finished
Gathering worker results

Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs

received on stderr: Traceback (most recent call last):
  File "/usr/share/createrepo/genpkgmetadata.py", line 291, in 
main(sys.argv[1:])
  File "/usr/share/createrepo/genpkgmetadata.py", line 269, in main
mdgen.doRepoMetadata()
  File "/usr/lib/python2.7/site-packages/createrepo/__init__.py", line 978, 
in doRepoMetadata
rp.getFilelists(complete_path, csum)
  File "/usr/lib64/python2.7/site-packages/sqlitecachec.py", line 54, in 
getFilelists
self.repoid))
TypeError: Can not create dirnames index: unable to open database file

associating kickstarts
*** TASK COMPLETE ***
[root@fs1 ~]## cobbler distro list
   F18-x86_64
   c6-i386
   c6-x86_64
   f17-PAE-i386
   f17-i386
   f17-x86_64
[root@fs1 ~]# 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/h0U2iSnReV8J.
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] Converting puppet client to servr

[Bret Wortman]

Which files will I need to transfer to the new puppet master?

/var/lib/puppet/ssl/ca/ca_crt.pem
/var/lib/puppet/ssl/certs/ca.pem
/var/lib/puppet/ssl/certs/woof.hostname.com.pem

We had been planning for a central "master master" anyway and it already
has a dns alias for "puppet". Once I solve the distribution problem, I'll
take on keeping these boxes in sync.

*
*
*

Bret Wortman***
http://bretwortman.com/
http://twitter.com/BretWortman




On Thu, Dec 13, 2012 at 5:15 AM, Luke Bigum  wrote:

> On Wednesday, December 12, 2012 10:35:21 PM UTC, Bret Wortman wrote:
>
>>  Yeah, I was starting to think that was the solution.
>>
>>
> That's not strictly necessary, you can install a Puppet Master with Puppet
> just fine, the problem you're running into is how to manage the Puppet CA
> across multiple Masters. This is not an easy problem to solve. If you start
> a master for the first time it will initialise it's own personal CA and
> certificate. This will conflict with the cert it got from the *other*
> master when it was installed and probably the cause of your connectivity
> problems. Also, your other agents won't be able to jump between masters
> because the CAs are different.
>
> I would break the problem into these tasks:
>
> - Decide on a centralised CA (a Puppet Master Master even) that you can
> generate other Puppet Master certificates from and give that cert the
> 'puppet' alias if you use it at your sites (puppet ca generate
> woof.hostname.com --dns-alt-names puppet)
> - Figure out how to get this Cert and the Master CA onto your new Puppet
> Master instead of letting the Puppet Mater. NFS? HTTPS download? Package?
> - Figure out how to share certificates between Puppet Masters so an Agent
> can check in to different Puppet Masters. Centralised CA? Multi-way rsync?
>
> -Luke
>
> --
>> Bret Wortman
>> http://bretwortman.com/
>> http://twitter.com/bretwortman
>>
>> On Wednesday, December 12, 2012 at 5:26 PM, Jakov Sosic wrote:
>>
>> On 12/12/2012 10:04 PM, Bret Wortman wrote:
>>
>> Is there an easy way to convert a puppet client into being a puppet
>> master?
>>
>> Here's the scenario. I'm using puppet to configure all my systems, and
>> would like it to be able to deploy a new puppet master as well. We have
>> systems worldwide so having local puppet masters is very desirable for
>> fault tolerance. So Kickstart (via cobbler) installs a puppet client
>> during the initial system installation, then puppet installs everything
>> else. And I've written a puppet-server module to attempt to deploy the
>> puppet-server package, but I end up getting into certificate problems
>> every time.
>>
>> The initial cert draws complaints, so I delete it and clean the
>> certificate from the master, but then the systems will not connect under
>> any circumstances:
>>
>> # puppet agent -t
>> Exiting: no certificate found and waitforcert is disabled
>>
>> There's no request on the master (either this or the other).
>>
>> Thoughts?
>>
>>
>> You should deploy master through cobbler, or run masterless puppet to
>> set up the master.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet...@googlegroups.com.
>> To unsubscribe from this group, send email to puppet-users...@**
>> googlegroups.com.
>> For more options, visit this group at http://groups.google.com/**
>> group/puppet-users?hl=en<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 view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/tQYBNKzPoQAJ.
>
> 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.

Re: [Puppet Users] Converting puppet client to servr

[Bret Wortman]

Yeah, I was starting to think that was the solution.  


-- 
Bret Wortman
http://bretwortman.com/
http://twitter.com/bretwortman


On Wednesday, December 12, 2012 at 5:26 PM, Jakov Sosic wrote:

> On 12/12/2012 10:04 PM, Bret Wortman wrote:
> > Is there an easy way to convert a puppet client into being a puppet master?
> > 
> > Here's the scenario. I'm using puppet to configure all my systems, and
> > would like it to be able to deploy a new puppet master as well. We have
> > systems worldwide so having local puppet masters is very desirable for
> > fault tolerance. So Kickstart (via cobbler) installs a puppet client
> > during the initial system installation, then puppet installs everything
> > else. And I've written a puppet-server module to attempt to deploy the
> > puppet-server package, but I end up getting into certificate problems
> > every time.
> > 
> > The initial cert draws complaints, so I delete it and clean the
> > certificate from the master, but then the systems will not connect under
> > any circumstances:
> > 
> > # puppet agent -t
> > Exiting: no certificate found and waitforcert is disabled
> > 
> > There's no request on the master (either this or the other).
> > 
> > Thoughts?
> 
> You should deploy master through cobbler, or run masterless puppet to
> set up the master.
> 
> -- 
> 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] Converting puppet client to servr

[Bret Wortman]

Is there an easy way to convert a puppet client into being a puppet master?

Here's the scenario. I'm using puppet to configure all my systems, and 
would like it to be able to deploy a new puppet master as well. We have 
systems worldwide so having local puppet masters is very desirable for 
fault tolerance. So Kickstart (via cobbler) installs a puppet client during 
the initial system installation, then puppet installs everything else. And 
I've written a puppet-server module to attempt to deploy the puppet-server 
package, but I end up getting into certificate problems every time.

The initial cert draws complaints, so I delete it and clean the certificate 
from the master, but then the systems will not connect under any 
circumstances:

# puppet agent -t
Exiting: no certificate found and waitforcert is disabled

There's no request on the master (either this or the other).

Thoughts?

Puppet 3.0.1 from puppetlabs rpms on Fedora 17.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/VR0FzMXrsPkJ.
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.