Re: [Puppet Users] Directory Layout Recommendations for Puppetmaster?
Yes, actually. Use multiple git trees with varying levels of security. Keeping anything and everything in the same tree is indeed bound to cause hedaches in the future. On the bright side, if your changes are sufficiently self contained, git has pretty powerful tools to rebuild your tree to get rid of the sensitive data. Cheers, Felix On 02/27/2013 05:45 PM, Andreas Hilboll wrote: The only thing I haven't figured out yet is what to do with sensible files (private keys etc) that I want managed by puppet. Somehow, having those in the repo doesn't seem nice to me. Any recommendations? -- You received this message because you are subscribed to the Google Groups 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] facter vs specs
Hi, the goals seem to be different enough. Facter tries not only to gather certain pieces of system information, it also strives to a) serialize them into a canonical format and b) do everything platform independently (for supported platforms, i.e.) Facter has absolutely no capacity to supply a command for retrieving a given fact on any machine that does not itself have facter installed. That's because facts can and should have lots of ruby code around the system level invocations that can process the output. So no, I don't see them overlapping much. Cheers, Felix On 02/27/2013 06:14 PM, Andrew Pennebaker wrote: A friend pointed out that I may have been reinventing the wheel: My specs project is very similar to Puppet Labs' facter. What do you think? https://github.com/mcandre/specs#readme -- You received this message because you are subscribed to the Google Groups 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: PuppetDB queue problem
We flushed the queue and also restarted Postgres. Didn't help. On Thursday, February 28, 2013 10:14:16 AM UTC+1, ak0ska wrote: Hello, We have upgraded Puppetdb from 1.0.2 to 1.1.1 last week, and recently we noticed that queue is not processed. We don't know if this problem is directly linked to the upgrade. There are now 25 000 messages waiting in the queue. We also see errors in the Postgres log: ERROR: insert or update on table certname_catalogs violates foreign key constraint certname_catalogs_catalog_fkey DETAIL: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. STATEMENT: INSERT INTO certname_catalogs (certname,catalog,timestamp) VALUES ($1,$2,$3) RETURNING * Can this be somehow related to the the KahaDB leak thread? ( https://groups.google.com/d/topic/puppet-users/gWACi4a0BZs/discussion ) Any thoughts? Would flushing the queue solve the problem? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Puppet Manage Cisco ASA
Hello all, Does anyone currently manage Cisco ASA's out there via Puppet, if so how ? Due to the size of our network it would be great if Puppet could manage Object-groups and ACL's etc to try and standardize across our ASA hosts. e.g. On one ASA an Object-group would be called monitoring_server on another ASA mon_srv another ASA monsrv It makes understanding the rules alot harder, when there is no uniform object-groups, this is manly to due different network engineers over the years and out network evolving regards Jim -- You received this message because you are subscribed to the Google Groups 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: Puppet Manage Cisco ASA
I am aware of https://puppetlabs.com/blog/puppet-network-device-management/ but this doesn't manager ACL's or object-groups yet, and my programming skills aren't that great Or has anyone used cisco one platform kit (onepk) via puppet regards Jim On Thursday, 28 February 2013 10:36:22 UTC, jim wrote: Hello all, Does anyone currently manage Cisco ASA's out there via Puppet, if so how ? Due to the size of our network it would be great if Puppet could manage Object-groups and ACL's etc to try and standardize across our ASA hosts. e.g. On one ASA an Object-group would be called monitoring_server on another ASA mon_srv another ASA monsrv It makes understanding the rules alot harder, when there is no uniform object-groups, this is manly to due different network engineers over the years and out network evolving regards Jim -- You received this message because you are subscribed to the Google Groups 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: PuppetDB queue problem
Or maybe it did. The queue size went up to like 900 and after a while it normalized and started slowly decreasing. Right now it's empty. There were 2 insert errors in postgres log since its restart. It was perhaps on our end, but it would be good to hear some theories, or suggestions where else to look for a problem in a similar case On Thursday, February 28, 2013 10:38:42 AM UTC+1, ak0ska wrote: We flushed the queue and also restarted Postgres. Didn't help. On Thursday, February 28, 2013 10:14:16 AM UTC+1, ak0ska wrote: Hello, We have upgraded Puppetdb from 1.0.2 to 1.1.1 last week, and recently we noticed that queue is not processed. We don't know if this problem is directly linked to the upgrade. There are now 25 000 messages waiting in the queue. We also see errors in the Postgres log: ERROR: insert or update on table certname_catalogs violates foreign key constraint certname_catalogs_catalog_fkey DETAIL: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. STATEMENT: INSERT INTO certname_catalogs (certname,catalog,timestamp) VALUES ($1,$2,$3) RETURNING * Can this be somehow related to the the KahaDB leak thread? ( https://groups.google.com/d/topic/puppet-users/gWACi4a0BZs/discussion ) Any thoughts? Would flushing the queue solve the problem? -- You received this message because you are subscribed to the Google Groups 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: PuppetDB queue problem
The queue jumped back to ~1 600, and according to the puppetdb logs, it hasn't processed a single entry for like 20 minutes, but the log shows a lot of slow queries (see example below). Postgres logs show no error. And now it started processing the queue again. Slow queries: http://pastebin.com/2B4azRib On Thursday, February 28, 2013 1:09:15 PM UTC+1, ak0ska wrote: Or maybe it did. The queue size went up to like 900 and after a while it normalized and started slowly decreasing. Right now it's empty. There were 2 insert errors in postgres log since its restart. It was perhaps on our end, but it would be good to hear some theories, or suggestions where else to look for a problem in a similar case On Thursday, February 28, 2013 10:38:42 AM UTC+1, ak0ska wrote: We flushed the queue and also restarted Postgres. Didn't help. On Thursday, February 28, 2013 10:14:16 AM UTC+1, ak0ska wrote: Hello, We have upgraded Puppetdb from 1.0.2 to 1.1.1 last week, and recently we noticed that queue is not processed. We don't know if this problem is directly linked to the upgrade. There are now 25 000 messages waiting in the queue. We also see errors in the Postgres log: ERROR: insert or update on table certname_catalogs violates foreign key constraint certname_catalogs_catalog_fkey DETAIL: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. STATEMENT: INSERT INTO certname_catalogs (certname,catalog,timestamp) VALUES ($1,$2,$3) RETURNING * Can this be somehow related to the the KahaDB leak thread? ( https://groups.google.com/d/topic/puppet-users/gWACi4a0BZs/discussion ) Any thoughts? Would flushing the queue solve the problem? -- You received this message because you are subscribed to the Google Groups 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] Re: PuppetDB queue problem
If you clear the queue and rollback to the original version does the problem disappear? If you're having processing problems at the latest version thats what I would do, as I presume we're talking production here right? Can this be somehow related to the the KahaDB leak thread? No - it doesn't sound like it. ERROR: insert or update on table certname_catalogs violates foreign key constraint certname_catalogs_catalog_fkey DETAIL: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. STATEMENT: INSERT INTO certname_catalogs (certname,catalog,timestamp) VALUES ($1,$2,$3) RETURNING * That is a bit of a concern, are you receiving a lot of these? Is this constant? Use of unversioned APIs is deprecated; please use /v1/resources These are appearing in your slow query log - are you sure you're running puppetdb-terminus 1.1.1 as well? Did you restart your master after upgrading the terminus? ken. On Thu, Feb 28, 2013 at 12:54 PM, ak0ska akos.he...@gmail.com wrote: The queue jumped back to ~1 600, and according to the puppetdb logs, it hasn't processed a single entry for like 20 minutes, but the log shows a lot of slow queries (see example below). Postgres logs show no error. And now it started processing the queue again. Slow queries: http://pastebin.com/2B4azRib On Thursday, February 28, 2013 1:09:15 PM UTC+1, ak0ska wrote: Or maybe it did. The queue size went up to like 900 and after a while it normalized and started slowly decreasing. Right now it's empty. There were 2 insert errors in postgres log since its restart. It was perhaps on our end, but it would be good to hear some theories, or suggestions where else to look for a problem in a similar case On Thursday, February 28, 2013 10:38:42 AM UTC+1, ak0ska wrote: We flushed the queue and also restarted Postgres. Didn't help. On Thursday, February 28, 2013 10:14:16 AM UTC+1, ak0ska wrote: Hello, We have upgraded Puppetdb from 1.0.2 to 1.1.1 last week, and recently we noticed that queue is not processed. We don't know if this problem is directly linked to the upgrade. There are now 25 000 messages waiting in the queue. We also see errors in the Postgres log: ERROR: insert or update on table certname_catalogs violates foreign key constraint certname_catalogs_catalog_fkey DETAIL: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. STATEMENT: INSERT INTO certname_catalogs (certname,catalog,timestamp) VALUES ($1,$2,$3) RETURNING * Can this be somehow related to the the KahaDB leak thread? (https://groups.google.com/d/topic/puppet-users/gWACi4a0BZs/discussion ) Any thoughts? Would flushing the queue solve the problem? -- You received this message because you are subscribed to the Google Groups 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. -- You received this message because you are subscribed to the Google Groups 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] Re: PuppetDB queue problem
Hi, thanks for trying to help! :) If you clear the queue and rollback to the original version does the problem disappear? If you're having processing problems at the latest version thats what I would do, as I presume we're talking production here right? Yes, this is production. We would like to avoid reverting, but maybe we will have to. ERROR: insert or update on table certname_catalogs violates foreign key constraint certname_catalogs_catalog_fkey DETAIL: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. STATEMENT: INSERT INTO certname_catalogs (certname,catalog,timestamp) VALUES ($1,$2,$3) RETURNING * That is a bit of a concern, are you receiving a lot of these? Is this constant? Before we flushed the queue, quite a lot. Since we flushed it, only 4 times. Use of unversioned APIs is deprecated; please use /v1/resources These are appearing in your slow query log - are you sure you're running puppetdb-terminus 1.1.1 as well? Did you restart your master after upgrading the terminus? The terminus version is correct, however we were not entirely sure that the masters were properly restarted, so we did it now again, let's see if this changes anything. But the hanging is happening again. I checked what queries run on the database server. Some queries are running for ~ 90 mins, and there are some idle threads. There are two update commands that are waiting. I assume while those 2 don't get executed, the queue processing is halted. -- You received this message because you are subscribed to the Google Groups 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] Re: Puppet Manage Cisco ASA
jim wrote: I am aware of https://puppetlabs.com/blog/puppet-network-device-management/ but this doesn't manager ACL's or object-groups yet, and my programming skills aren't that great Or has anyone used cisco one platform kit (onepk) via puppet Cisco is working on integration and we hope to have some news on this soon. Regards James Turnbull -- James Turnbull 1-503-734-8571 To schedule a meeting with me: http://doodle.com/jamtur01 -- You received this message because you are subscribed to the Google Groups 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] How we can mangae Puppet node Automatic updates
On Thu, Feb 28, 2013 at 3:18 PM, Jithin Xavier jithin.xavi...@gmail.com wrote: Hi All, Puppet node is automatically updating every 30 minutes,Is there anyway to update that time span? Yes, this is set in the agent's puppet.conf file: http://docs.puppetlabs.com/references/3.1.latest/configuration.html#runinterval Regards, Matt. -- You received this message because you are subscribed to the Google Groups 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] Re: PuppetDB queue problem
I'm @ken_barber on irc btw if that is easier. Can't use IRC here, sorry. :( Okay. Did you clear the ActiveMQ queues after doing this? I usually just move the old KahaDB directory out of the way when I do this. I haven't though about myself, but it makes sense, so I just flushed the queue again while puppetdb service was stopped. Since this last restart it seems smooth, but it's only up for a few minutes. Okay, so were those old queries that are taking 90 minutes, what are they? SELECT COUNT(*) AS c FROM certname_catalogs cc, catalog_resources cr, certnames c WHERE cc.catalog=cr.catalog AND c.name=cc.certname AND c.deactivated IS NULL 18 instances were running, oldest was ~90 mins at the time SELECT COUNT(*) AS c FROM (SELECT DISTINCT resource FROM catalog_resources cr, certname_catalogs cc, certnames c WHERE cr.catalog=cc.catalog AND cc.certname=c.name AND c.deactivated IS NULL) 12 instances were running, oldest was ~90 mins at the time Have you tried shutting down the PuppetDB, clearing the queue - running full vacuum on the database then starting it all up again? Not yet, according to the Postgresql documentation full vacuum is not really recommended. Also it might take a while, and PuppetDB would be unavailable for the duration. What version of PostgreSQL are we talking here? What distro and version specifically? How big is the database itself? 8.4.13 on a RHEL6 based distribution. The database size might be an indicator that something is not ok. It currently takes up 512Gbs, and it grew 100Gbs over a week. We made a database dump before the PuppetDB upgrade and it was ~1Gb uncompressed. The full vacuum might solve this, but my guess that it would run quite long. How many nodes and how frequently are they checking in? A screenshot of your puppetdb dashboard might give us a good snapshot of the size of your environment as well. We have ~2500 nodes, run interval for the two major environments: 60mins for 1593 machines and 30 mins for 496. Splay limit is 900sec for both. Two screenshots from today: http://imgur.com/kG5Sth5,bLFqGAX#0 and http://imgur.com/kG5Sth5,bLFqGAX#1 Has any tuning been performed on your postgresql server? A copy of your postgresql.conf would be interesting. No tuning that I'm aware of. The same default postgresql.conf as deployed by the puppetlabs-postgres module. It's here: http://pastebin.com/njvGm4eu We can do this all privately if you are concerned about sharing information publicly as well - up to you. Like I said, I'm also on Freenode IRC as @ken_barber if this is better for you. ken. So far I don't feel like I shared anything sensitive, so this might be useful for others as well. Thanks for the help! -- You received this message because you are subscribed to the Google Groups 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] How we can mangae Puppet node Automatic updates
Thanks Matt, On which file I should edit to update runinterval? Thanks Jithin On Thu, Feb 28, 2013 at 8:56 PM, Matthew Burgess matthew.2.burg...@gmail.com wrote: On Thu, Feb 28, 2013 at 3:18 PM, Jithin Xavier jithin.xavi...@gmail.com wrote: Hi All, Puppet node is automatically updating every 30 minutes,Is there anyway to update that time span? Yes, this is set in the agent's puppet.conf file: http://docs.puppetlabs.com/references/3.1.latest/configuration.html#runinterval Regards, Matt. -- 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/d0n0k02crgI/unsubscribe?hl=en . 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- -Regards Jithin Xavier +91-9739505163 Skype- jithinxavi in.linkedin.com/in/jithinxavier/ -- You received this message because you are subscribed to the Google Groups 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] Re: Puppet Manage Cisco ASA
On 28.02.2013 16:13, James Turnbull wrote: jim wrote: I am aware of https://puppetlabs.com/blog/puppet-network-device-management/ but this doesn't manager ACL's or object-groups yet, and my programming skills aren't that great Or has anyone used cisco one platform kit (onepk) via puppet Cisco is working on integration and we hope to have some news on this soon. Hi James, I've just started working with a client to expand the network-device stuff to support more properties and more devices. Should I defer that work? Any other hints? Best Regards, David -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To 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] Re: PuppetDB queue problem
Okay. Did you clear the ActiveMQ queues after doing this? I usually just move the old KahaDB directory out of the way when I do this. I haven't though about myself, but it makes sense, so I just flushed the queue again while puppetdb service was stopped. Since this last restart it seems smooth, but it's only up for a few minutes. You mean, you've only been watching it for a few minutes, and so far so good - or it crashed? Sorry - just want to be clear :-). Okay, so were those old queries that are taking 90 minutes, what are they? SELECT COUNT(*) AS c FROM certname_catalogs cc, catalog_resources cr, certnames c WHERE cc.catalog=cr.catalog AND c.name=cc.certname AND c.deactivated IS NULL 18 instances were running, oldest was ~90 mins at the time SELECT COUNT(*) AS c FROM (SELECT DISTINCT resource FROM catalog_resources cr, certname_catalogs cc, certnames c WHERE cr.catalog=cc.catalog AND cc.certname=c.name AND c.deactivated IS NULL) 12 instances were running, oldest was ~90 mins at the time Have you tried shutting down the PuppetDB, clearing the queue - running full vacuum on the database then starting it all up again? Not yet, according to the Postgresql documentation full vacuum is not really recommended. Also it might take a while, and PuppetDB would be unavailable for the duration. Its not recommended as a re-occurring maintenance task this is true, but if your DB has had major changes due to a schema upgrade, or if vacuum hasn't ran in a while its generally okay and can provide some benefit. But yeah, judging by the size of your DB this will take a long time. I guess my point is, every recommendation has a caveat or back-story. What version of PostgreSQL are we talking here? What distro and version specifically? How big is the database itself? 8.4.13 on a RHEL6 based distribution. The database size might be an indicator that something is not ok. It currently takes up 512Gbs, and it grew 100Gbs over a week. We made a database dump before the PuppetDB upgrade and it was ~1Gb uncompressed. The full vacuum might solve this, but my guess that it would run quite long. Wow - it should be more like 5 GB or less for your size. It sounds like you've got some major fragmentation issues, your indexes may need rebuilding and yeah - a vacuum will probably help - and index rebuild. But this will require an outage I would say. When was the last time it was vacuumed? Try the SQL: select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables; And give us the output. I think by default autovacuum should be on for Postgresql 8.4 on Redhat but I can't recall. On another note ... to be honest I can't be precise about why the upgrade failed, I'm pretty sure you were running old revisions of the terminus when you upgraded but that should cause this kind of anguish. The errors you were receiving about constraints: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. Should not be occurring at all, which is all very suspect - alas I have no clue yet as to why. Have they stopped now we have cleared the queue and restarted? How many nodes and how frequently are they checking in? A screenshot of your puppetdb dashboard might give us a good snapshot of the size of your environment as well. We have ~2500 nodes, run interval for the two major environments: 60mins for 1593 machines and 30 mins for 496. Splay limit is 900sec for both. Two screenshots from today: http://imgur.com/kG5Sth5,bLFqGAX#0 and http://imgur.com/kG5Sth5,bLFqGAX#1 Okay. Has any tuning been performed on your postgresql server? A copy of your postgresql.conf would be interesting. No tuning that I'm aware of. The same default postgresql.conf as deployed by the puppetlabs-postgres module. It's here: http://pastebin.com/njvGm4eu What is the size of your database? CPU/cores ... and RAM on the box? Does your puppetdb service live on the same node as the database? I'm guessing this to be true, as your postgresql.conf is listening only on 'localhost' ... what is the memory consumption of your apps? The output of 'free' would probably be a good start. ken. -- You received this message because you are subscribed to the Google Groups 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] How we can mangae Puppet node Automatic updates
In the file /etc/puppet/puppet.conf In the [main] section. Thanks Regards, Rakesh K. On Thu, Feb 28, 2013 at 9:19 PM, Jithin Xavier jithin.xavi...@gmail.comwrote: Thanks Matt, On which file I should edit to update runinterval? Thanks Jithin On Thu, Feb 28, 2013 at 8:56 PM, Matthew Burgess matthew.2.burg...@gmail.com wrote: On Thu, Feb 28, 2013 at 3:18 PM, Jithin Xavier jithin.xavi...@gmail.com wrote: Hi All, Puppet node is automatically updating every 30 minutes,Is there anyway to update that time span? Yes, this is set in the agent's puppet.conf file: http://docs.puppetlabs.com/references/3.1.latest/configuration.html#runinterval Regards, Matt. -- 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/d0n0k02crgI/unsubscribe?hl=en . 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- -Regards Jithin Xavier +91-9739505163 Skype- jithinxavi in.linkedin.com/in/jithinxavier/ -- You received this message because you are subscribed to the Google Groups 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. -- You received this message because you are subscribed to the Google Groups 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] Classes and resources in Hiera
John,
Thanks for your response. I wasn't meaning to complain about the lack of
documentation, was just using it as a data point. I was trying to determine if
there was something I wasn't aware of that was available for me to use now or
something planned in the future. I know hiera is a relatively new major
enhancement to puppet and it is still being determined in some cases how to
best utilize it.
I (attempted) to add this functionality this morning, we'll see where it goes
(https://projects.puppetlabs.com/issues/19516). This is my first PR to puppet
directly, hopefully it is something others feel would be of value also.
jl
On Feb 28, 2013, at 7:24 AM, jcbollinger john.bollin...@stjude.org wrote:
On Wednesday, February 27, 2013 8:34:47 AM UTC-6, Justin Lambert wrote:
I've had this blog post [1] bookmarked for a while to pull the remaining node
specific config I have out of my site.pp, but wasn't sure if there was a
better method at this point.
The custom 'hiera_resources()' function described in that blog post appears
to be equivalent to a combination of the standard hiera() and
create_resources() functions. Whether that general approach is best is an
entirely separate question, however, and the answer probably depends on the
circumstances.
I've been using hiera_include for a while for classes, but it appears
functionality is something that may go away based on this feature [2] and the
fact that it is still undocumented [3]. The bug report points out include
now takes an array [4] (yeah!), but to get the correct array built from hiera
(multiple levels) I have to use hiera_array which is also still undocumented
[5].
Although hiera_include() may eventually go away, as it is indeed redundant, I
don't think there is any reason to fear that hiera_array() or hiera_hash()
will be removed. PL has limited resources at its disposal, and one of the
things that has historically been a problem for it is the thoroughness (or
lack thereof) of its documentation. It does devote effort to documentation,
to be sure, but not to such an extent that you can take lack of detailed
documentation of hiera_array() to be an indication that it is at risk of
removal.
If the lack of documentation bothers you then file a ticket against it
(supposing there isn't one already). If you're really motivated, then Puppet
is an open-source project: you can write the documentation and contribute it
if you are so inclined.
What is the current recommended way of including classes to be included in
your hiera data and is there a recommended method for including resources?
Obviously I can implement the stuff Robin and Hunter did if I'm not
implementing something that's going to go away shortly because it is a
terrible idea.
Use either
$classes = hiera('classes_key')
include $classes
or
$classes = hiera_array('classes_key')
include $classes
or a similar approach based on 'include' instead of 'hiera_include'.
If you can, derive resource parameters from class data and/or general hiera
data, but if you must model whole resource declarations in hiera then use
$resources_hash = hiera('resource_key')
create_resources('resource_name', $resources_hash)
to handle them.
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.
--
You received this message because you are subscribed to the Google Groups
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] Re: PuppetDB queue problem
FYI, I just upgraded only the PuppetDB part to 1.1.1, using the old 1.0.2 terminus I get no errors: 2013-02-28 17:06:27,711 WARN [qtp1478462104-39] [http.server] Use of unversioned APIs is deprecated; please use /v1/commands 2013-02-28 17:06:28,284 INFO [command-proc-44] [puppetdb.command] [7a4a1f70-1e85-4256-8f95-21008b6c1199] [replace facts] puppetdb2.vm 2013-02-28 17:06:30,724 WARN [qtp1478462104-32] [http.server] Use of unversioned APIs is deprecated; please use /v1/commands 2013-02-28 17:06:32,693 INFO [command-proc-44] [puppetdb.command] [a87001c5-f064-4a2d-9f9e-de903f62f824] [replace catalog] puppetdb2.vm If at all possible - I wouldn't mind a full copy of your puppetdb.log ... to dig a bit deeper. And I know I told you to clear the KahaDB queue (I always make this mistake) but I don't suppose you kept an old copy of it? ken. On Thu, Feb 28, 2013 at 3:55 PM, Ken Barber k...@puppetlabs.com wrote: Okay. Did you clear the ActiveMQ queues after doing this? I usually just move the old KahaDB directory out of the way when I do this. I haven't though about myself, but it makes sense, so I just flushed the queue again while puppetdb service was stopped. Since this last restart it seems smooth, but it's only up for a few minutes. You mean, you've only been watching it for a few minutes, and so far so good - or it crashed? Sorry - just want to be clear :-). Okay, so were those old queries that are taking 90 minutes, what are they? SELECT COUNT(*) AS c FROM certname_catalogs cc, catalog_resources cr, certnames c WHERE cc.catalog=cr.catalog AND c.name=cc.certname AND c.deactivated IS NULL 18 instances were running, oldest was ~90 mins at the time SELECT COUNT(*) AS c FROM (SELECT DISTINCT resource FROM catalog_resources cr, certname_catalogs cc, certnames c WHERE cr.catalog=cc.catalog AND cc.certname=c.name AND c.deactivated IS NULL) 12 instances were running, oldest was ~90 mins at the time Have you tried shutting down the PuppetDB, clearing the queue - running full vacuum on the database then starting it all up again? Not yet, according to the Postgresql documentation full vacuum is not really recommended. Also it might take a while, and PuppetDB would be unavailable for the duration. Its not recommended as a re-occurring maintenance task this is true, but if your DB has had major changes due to a schema upgrade, or if vacuum hasn't ran in a while its generally okay and can provide some benefit. But yeah, judging by the size of your DB this will take a long time. I guess my point is, every recommendation has a caveat or back-story. What version of PostgreSQL are we talking here? What distro and version specifically? How big is the database itself? 8.4.13 on a RHEL6 based distribution. The database size might be an indicator that something is not ok. It currently takes up 512Gbs, and it grew 100Gbs over a week. We made a database dump before the PuppetDB upgrade and it was ~1Gb uncompressed. The full vacuum might solve this, but my guess that it would run quite long. Wow - it should be more like 5 GB or less for your size. It sounds like you've got some major fragmentation issues, your indexes may need rebuilding and yeah - a vacuum will probably help - and index rebuild. But this will require an outage I would say. When was the last time it was vacuumed? Try the SQL: select relname,last_vacuum, last_autovacuum, last_analyze, last_autoanalyze from pg_stat_user_tables; And give us the output. I think by default autovacuum should be on for Postgresql 8.4 on Redhat but I can't recall. On another note ... to be honest I can't be precise about why the upgrade failed, I'm pretty sure you were running old revisions of the terminus when you upgraded but that should cause this kind of anguish. The errors you were receiving about constraints: Key (catalog)=(d1c89bbef78a55edcf560c432d965cfe1263059c) is not present in table catalogs. Should not be occurring at all, which is all very suspect - alas I have no clue yet as to why. Have they stopped now we have cleared the queue and restarted? How many nodes and how frequently are they checking in? A screenshot of your puppetdb dashboard might give us a good snapshot of the size of your environment as well. We have ~2500 nodes, run interval for the two major environments: 60mins for 1593 machines and 30 mins for 496. Splay limit is 900sec for both. Two screenshots from today: http://imgur.com/kG5Sth5,bLFqGAX#0 and http://imgur.com/kG5Sth5,bLFqGAX#1 Okay. Has any tuning been performed on your postgresql server? A copy of your postgresql.conf would be interesting. No tuning that I'm aware of. The same default postgresql.conf as deployed by the puppetlabs-postgres module. It's here: http://pastebin.com/njvGm4eu What is the size of your database? CPU/cores ... and RAM on the box? Does your puppetdb service live on the same node as the database? I'm guessing this to be true,
[Puppet Users] Re: Long puppet catalog run times on certain nodes after using pson is called
Architecture of PM is Ubuntu 12.04 in a VM with 8GB of RAM (4.7GB used) with Apache 2.2 as the front end. No network bottlenecks that I have been able to identify and the nodes this is happening on seem to be random. Different buildings on campus, different vlans, etc. I have nodes on the same network segment getting identical configs that are performing flawlessly. recurse = true is not being called in any module and no directories in my file manifests. My typical module with files has about 5 files and they are all smaller then 5KB. I'll keep digging and see if I can find any similarities on the client machines that might be causing this. It really seems client side at this point since looking in dashboard it does seem to be very consistent on the nodes that are having issues and the nodes that are good even though they are getting identical configs. Thanks, Rob On Tuesday, February 26, 2013 11:32:33 AM UTC-7, r.yeo wrote: Running the agent in debug mode on a some clients and I am seeing long run times such as this, but only after the using pson lines : Tue Feb 26 10:57:38 2013: Debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson Tue Feb 26 10:58:53 2013: Info: /Stage[main]/Vpn::Config/File[/opt/cisco/vpn/.anyconnect_global]: Evaluated in 75.03 seconds Tue Feb 26 10:58:53 2013: Debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson Tue Feb 26 11:00:08 2013: Info: /Stage[main]/Amadeuspro/File[/etc/puppet/tmp/com.HairerSoft.AmadeusPro.plist]: Evaluated in 74.78 seconds Tue Feb 26 11:00:08 2013: Info: /Stage[main]/Adobe/File[/etc/puppet/tmp/com.adobe.Reader.plist]: Starting to evaluate the resource Tue Feb 26 11:00:08 2013: Debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson Tue Feb 26 11:01:23 2013: Info: /Stage[main]/Adobe/File[/etc/puppet/tmp/com.adobe.Reader.plist]: Evaluated in 75.00 seconds Tue Feb 26 11:01:23 2013: Debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson Tue Feb 26 11:02:38 2013: Info: /Stage[main]/Puppet::Snow/File[/etc/hooks/ cleanpup.pl]: Evaluated in 75.01 seconds This catalog took 921.02 to complete : Tue Feb 26 11:02:38 2013: Notice: Finished catalog run in 916.78 seconds Tue Feb 26 11:02:38 2013: Changes: Tue Feb 26 11:02:38 2013: Events: Tue Feb 26 11:02:38 2013: Resources: Tue Feb 26 11:02:38 2013: Total: 55 Tue Feb 26 11:02:38 2013: Skipped: 6 Tue Feb 26 11:02:38 2013: Time: Tue Feb 26 11:02:38 2013:Filebucket: 0.00 Tue Feb 26 11:02:38 2013: Package: 0.00 Tue Feb 26 11:02:38 2013:Ssh authorized key: 0.00 Tue Feb 26 11:02:38 2013: User: 0.06 Tue Feb 26 11:02:38 2013: Group: 0.11 Tue Feb 26 11:02:38 2013: Exec: 0.59 Tue Feb 26 11:02:38 2013:Config retrieval: 13.28 Tue Feb 26 11:02:38 2013: Last run: 1361901758 Tue Feb 26 11:02:38 2013: File: 906.98 Tue Feb 26 11:02:38 2013: Total: 921.02 Tue Feb 26 11:02:38 2013: Version: Tue Feb 26 11:02:38 2013:Config: 1361893868 Tue Feb 26 11:02:38 2013:Puppet: 3.1.0 Also, this isn't global as I have nodes getting identical complete configs in 7 seconds and run times are just fine after the using pson lines. Example of a fast node : Tue Feb 26 11:22:57 2013: Debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson Tue Feb 26 11:22:58 2013: Info: /Stage[main]/Amadeuspro/File[/etc/puppet/tmp/com.HairerSoft.AmadeusPro.plist]: Evaluated in 0.15 seconds Tue Feb 26 11:22:58 2013: Info: /Stage[main]/Adobe/File[/etc/puppet/tmp/com.adobe.Reader.plist]: Starting to evaluate the resource Tue Feb 26 11:22:58 2013: Debug: file_metadata supports formats: b64_zlib_yaml pson raw yaml; using pson Tue Feb 26 11:22:58 2013: Info: /Stage[main]/Adobe/File[/etc/puppet/tmp/com.adobe.Reader.plist]: Evaluated in 0.07 seconds Puppet master and clients are 3.1 with Dashboard 1.2.22 and also using PuppetDB. Any thoughts why I'd have trouble and long run times on select nodes when pson is called? 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] Using $name in resources?
Using 2.6.17, I have something like this:
class yumrepos {
yumrepo { ['a',
'b']:
descr=yum repo $name,
baseurl=http://someurl/$name;;
}
}
Instead of using the names 'a' and 'b', like I'd expect (so a baseurl
of http://someurl/a), it creates .repo files with those names, and
repos inside of them, but everywhere the name should get substituted,
it substitutes the name of the class instead. Any pointers in how to
make it substitute the name of the resource instead? I have about 20
repos to define, and would rather just do it this way.
I've tried making it a resource type default in the class, as well as
specifying at the end of the array, like above. Both yield the same
results. Am I being completely dense and missing something here?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To 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] Issues with conditionals Hiera
Hello everyone! I hope your Thursdays are going swimmingly! I'm having an issue with using data looked up via Hiera and using that in a conditional in my manifest. Here is a simple use-case where I simply cannot get it to work: http://pastie.org/private/gtplsiajmmrdhjie49bda# In this example the Hiera lookup is handling as expected - globally the cagefs_enabled variable is being returned as false and on the some.fqdn.com.yaml it's being returned as true. The notice() call right after the lookup confirms that the variable is being set properly. The issue is I cannot for the life of me to get that data to work in a conditional. I've tried string comparisons and simple binary ones (1==1, 0==0) to no luck. The IF statement simply isn't being hit. Am I missing something obvious in this case? -- You received this message because you are subscribed to the Google Groups 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] Issues with conditionals Hiera
--- cagefs_enabled:- 'false' should be ---cagefs_enabled: 'false' You were creating an arrray named cagefs_enabled with the first element as true... Stefan - Zipkid - Goethals. On Thu, Feb 28, 2013 at 9:44 PM, c...@hawkhoststatus.com wrote: Hello everyone! I hope your Thursdays are going swimmingly! I'm having an issue with using data looked up via Hiera and using that in a conditional in my manifest. Here is a simple use-case where I simply cannot get it to work: http://pastie.org/private/gtplsiajmmrdhjie49bda# In this example the Hiera lookup is handling as expected - globally the cagefs_enabled variable is being returned as false and on the some.fqdn.com.yaml it's being returned as true. The notice() call right after the lookup confirms that the variable is being set properly. The issue is I cannot for the life of me to get that data to work in a conditional. I've tried string comparisons and simple binary ones (1==1, 0==0) to no luck. The IF statement simply isn't being hit. Am I missing something obvious in this case? -- You received this message because you are subscribed to the Google Groups 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. -- You received this message because you are subscribed to the Google Groups 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] Using $name in resources?
class yumrepos {
my_yumrepo{ ['a','b']: }
}
define my_yumrepo() {
yumrepo { $name:
descr=yum repo $name,
baseurl=http://someurl/$name;;
}
}
Should do the trick.
The problem is the $name variable is not usable when calling.. only in the
called type.
Regards,
Stefan - Zipkid - Goethals
On Thu, Feb 28, 2013 at 10:20 PM, Jon Stanley jonstan...@gmail.com wrote:
Using 2.6.17, I have something like this:
class yumrepos {
yumrepo { ['a',
'b']:
descr=yum repo $name,
baseurl=http://someurl/$name;;
}
}
Instead of using the names 'a' and 'b', like I'd expect (so a baseurl
of http://someurl/a), it creates .repo files with those names, and
repos inside of them, but everywhere the name should get substituted,
it substitutes the name of the class instead. Any pointers in how to
make it substitute the name of the resource instead? I have about 20
repos to define, and would rather just do it this way.
I've tried making it a resource type default in the class, as well as
specifying at the end of the array, like above. Both yield the same
results. Am I being completely dense and missing something here?
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To 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.
--
You received this message because you are subscribed to the Google Groups
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] Issues with conditionals Hiera
It may be worth noting that the notice() function printed the variable as a normal string (or seemingly) making it difficult to recognize the fact it was actually an array. I'm not sure if this is something that should be made obvious or not but it's worth noting for anyone who lands on this via Google. On Thu, Feb 28, 2013 at 5:13 PM, Cody Robertson c...@hawkhoststatus.comwrote: Clearly I have a firm grasp on YAML. That'd be the issue - thanks! For the record I tried all of the possible values (True, true, 1) - obviously it was failing as it was an array as previously mentioned. On Thu, Feb 28, 2013 at 5:11 PM, Dan White y...@comcast.net wrote: Other folks have pointed out the fact that you made an array, but have you tried using true and false without the quotes ? I believe that will produce a proper Boolean value. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin Hobbes) -- *From: *c...@hawkhoststatus.com *To: *puppet-users@googlegroups.com *Sent: *Thursday, February 28, 2013 3:44:39 PM *Subject: *[Puppet Users] Issues with conditionals Hiera Hello everyone! I hope your Thursdays are going swimmingly! I'm having an issue with using data looked up via Hiera and using that in a conditional in my manifest. Here is a simple use-case where I simply cannot get it to work: http://pastie.org/private/gtplsiajmmrdhjie49bda# In this example the Hiera lookup is handling as expected - globally the cagefs_enabled variable is being returned as false and on the some.fqdn.com.yaml it's being returned as true. The notice() call right after the lookup confirms that the variable is being set properly. The issue is I cannot for the life of me to get that data to work in a conditional. I've tried string comparisons and simple binary ones (1==1, 0==0) to no luck. The IF statement simply isn't being hit. Am I missing something obvious in this case? -- You received this message because you are subscribed to the Google Groups 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. -- You received this message because you are subscribed to the Google Groups 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. -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppet experience better in Fedora 17 or Fedora 18?
Fedora 18 is officially supported in the puppetlabs yum repos now. Last I looked it wasn't (only a couple of days ago). I have been running a couple of node on Fedora 18 for a while and there is a few issues that occur but I think they still affect 17 as well. Most of the issues I have seen relate to systemd especially when the service still has an init script. There are bug reports relating to those issues and they are still in progress. I am getting tempted to offer my services to test those bugs... I can't comment on cobbler or the bug you are seeing. Good luck either way. Pete. On 1 March 2013 07:38, thyrsus s.schaefer.at@gmail.com wrote: I've been struggling to get cobbler to bootstrap puppet in Fedora 17. Currently I'm suffering from puppet bug #9084, and I'm about to see if applying the changes from https://github.com/puppetlabs/puppet/pull/831get me functional (I've already tried the symlink to ca.pem workaround, and it didn't get me there). I'll find out this evening if that's already been applied to the fedora 17 package, in which case I'm stuck. Would I have a better experience if I skipped to Fedora 18, since it's using Puppet 3.0, or am I just trading in for a better class of puzzles? - Stephen -- You received this message because you are subscribed to the Google Groups 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. -- You received this message because you are subscribed to the Google Groups 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.
