Hello Wyat,
thanks for the link. The PostgreSQL version is not an issue, this has been
upgraded to 9.6 recently.
The ticket assumes everything will be done online while the Puppet masters are
running etc.
Actually, I would just do it with a maintenance window and take all puppet
masters offlin
On 12/05/2017 01:57 PM, Dietrich, Stefan wrote:
Hello,
in order to finish our Puppet 4.x migration (and than Puppet 5.x, yay),
PuppetDB has to be upgraded as well.
If I read the upgrade docs correctly, a direct upgrade from PuppetDB 2.3.x is
not supported [1].
So in order to do this, an upg
Hello,
in order to finish our Puppet 4.x migration (and than Puppet 5.x, yay),
PuppetDB has to be upgraded as well.
If I read the upgrade docs correctly, a direct upgrade from PuppetDB 2.3.x is
not supported [1].
So in order to do this, an upgrade to the latest version for each major release
i
And resolved... that was ugly.
Turns out the ENC was returning an unconfigured node because it couldn't
access the mysql db when running 'puppet lookup' I ran that trace I was
talking about and a painful bout of pouring through trace later, I saw
several references to not being able to access
On Tuesday, December 5, 2017 at 4:33:05 AM UTC-5, Antony Fomenko wrote:
>
> Hi.
> You should update to Puppet 5. But if you use PuppetDB and want to save
> data you will have to make a stop in Puppet4 with latest PuppetDB 2.x, then
> update PuppetDB to 4.x and afterwards migrate to Puppet5 and
On Tuesday, December 5, 2017 at 3:36:11 PM UTC-5, Jo wrote:
>
> Also this helps deal with managing large numbers of ports with common
> configuration: https://github.com/jorhett/puppet-device_hiera
>
> This is production-quality, with years of use at some very large entities.
>
> Regarding Puppe
Also this helps deal with managing large numbers of ports with common
configuration: https://github.com/jorhett/puppet-device_hiera
This is production-quality, with years of use at some very large entities.
Regarding Puppet device, that's not an inherent limitation. It's pretty
easy to build your
Enter code here...
Well, at least I've already checked all the things you're asking about.
While the problem is frustrating, I do hate proving I'm a complete idiot to
the internet :)
On Tuesday, December 5, 2017 at 1:50:10 PM UTC-6, Christopher Wood wrote:
>
> Quoth your earlier post:
>
> [[s
(inline)
On Tue, Dec 05, 2017 at 11:23:32AM -0800, dkoleary wrote:
>On Tuesday, December 5, 2017 at 1:10:44 PM UTC-6, Christopher Wood wrote:
>
> Twofold:
>
> "fqdn" is usually a puppet fact, I suspect you wouldn't find that if you
> grepped your hiera data. Try these as root
On Tuesday, December 5, 2017 at 1:10:44 PM UTC-6, Christopher Wood wrote:
>
> Twofold:
>
> "fqdn" is usually a puppet fact, I suspect you wouldn't find that if you
> grepped your hiera data. Try these as root on any node:
>
You are quite right. My attempt to simplify the problem apparently w
Twofold:
"fqdn" is usually a puppet fact, I suspect you wouldn't find that if you
grepped your hiera data. Try these as root on any node:
facter fqdn
facter -p | less
If you do have a hiera key called "fqdn", you can try looking it up on any host
which has your environments in the usual place
Hi;
I'm running open source puppet server ver 5. So far, I've been exceedingly
happy with the performance and maintainability of it. I'm about to start a
rewrite of a module and would like to verify some hiera data. Quick google
search shows what looks like it should be the perfect tool - pr
I'm confused, because I created this on my client only:
> /opt/puppetlabs/facter/facts.d/boo.json:
> { "boo": "boo222" }
>
> And added this to me module:
>notify { "boo is ${boo}": }
>
> And received:
> Notice: boo is boo222
>
> Doesn't that demonstrate that files in facts.d/boo.json are loade
On Tuesday, December 5, 2017 at 1:39:38 PM UTC+1, Rob Nelson wrote:
>
> Facts are loaded, and distributed from the master, before the catalog
> compilation step. See
> https://docs.puppet.com/facter/3.3/custom_facts.html#external-facts.
> Rather than distributing the json files as a File resou
I found that a single "apt-get update" exec before any packages were managed
was useful enough. Out of interest, what is the use case that needs "apt-get
update" before every package is installed?
Lately here the "yum upgrade" is a daily thing with some incremental canarying
as the month goes o
Folks;
using puppet with the apt module, I am looking for a way to do
- an apt-get update && apt-get dist-upgrade *once* on each puppet agent
run, and
- an apt-get update before each package to be installed.
Right now I am playing with various exec[] approaches but none seems really
to do wha
Facts are loaded, and distributed from the master, before the catalog
compilation step. See
https://docs.puppet.com/facter/3.3/custom_facts.html#external-facts. Rather
than distributing the json files as a File resource, you could add an
executable fact to a module and the fact could communicate wi
On Friday, December 1, 2017 at 5:59:51 PM UTC+1, R.I. Pienaar wrote:
>
>
> All functions like foo() run on the master during compile. It's a multi
> phase process, the only way a node can influence the compile time is
> using facts.
>
> You could integrate your CMDB with puppet using a hiera
Hi.
You should update to Puppet 5. But if you use PuppetDB and want to save
data you will have to make a stop in Puppet4 with latest PuppetDB 2.x, then
update PuppetDB to 4.x and afterwards migrate to Puppet5 and PuppetDB5 due
to Puppet5 incompatibility with PuppetDB 2.x
On Sunday, December 3,
19 matches
Mail list logo
