(if I am not
> mistaken).
>
>
> --
> Lowe Schmidt | +46 723 867 157
>
> On 29 January 2016 at 10:43, James Green wrote:
>
>> jamesg@puppet-master:/etc/puppet$ sudo puppet module list --environment
>> tools_office
>> /etc/puppet/environments/tools_offic
jamesg@puppet-master:/etc/puppet$ sudo puppet module list --environment
tools_office
/etc/puppet/environments/tools_office/modules
└── garethr-docker (v4.1.1)
/etc/puppet/modules
├── AlexCline-dirtree (v0.2.1)
├── AlexCline-fstab (v0.5.4)
[ lots of others ]
Why does puppet list the modules in the
: Could not retrieve catalog; skipping run
The above all happened within a few seconds. I might argue within 4-5
seconds.
Unless of course I'd misunderstood your hypothesis?
On 13 March 2015 at 05:28, Josh Cooper wrote:
>
>
> On Thu, Mar 12, 2015 at 4:21 AM, James Green
>
I was running puppet agent -t --noop repeatedly with this error.
Running again, this time omitting --noop, it succeeded. Not entirely clear
what this tells me...
On 12 March 2015 at 10:58, James Green wrote:
> Error:
> /Stage[main]/Our_unattended_upgrades/File[/etc/apt/apt.conf.d/
r setup to run under mod
passenger
Are we looking at a known bug or are we really going to need to debug this?
James
On 11 March 2015 at 09:47, James Green wrote:
> Hi,
>
> Sorry for the delayed response.
>
> In our case we are using Passenger.
>
> On 5 March 2015 at
The documentation at
https://docs.puppetlabs.com/puppetdb/latest/maintain_and_tune.html talks
about checking the MQ depth.
I'm not seeing such a thing on our dashboard but plenty of others not
documented such as Catalogue Duplication.
Am I looking at outdated documentation?
James
--
You receiv
Hi,
Sorry for the delayed response.
In our case we are using Passenger.
On 5 March 2015 at 15:24, Henrik Lindberg
wrote:
> On 2015-05-03 12:02, James Green wrote:
>
>> We occasionally have an agent fail because of this. I'm told by others
>> running the agents more fre
I have a need to report on the modules we have installed and for each:
1. The version installed
2. The latest version available to upgrade to
Any ideas how to get this as I'm not seeing a "puppet module" command to
match.
[ Fairly convinced I cannot be the first to ask this too... ]
Thanks,
Ja
We occasionally have an agent fail because of this. I'm told by others
running the agents more frequently that it appears to be at random and not
on anything particularly large.
Looks like server and agents are 3.7.4, both Ubuntu. Can't see much in the
way of server logs.
Any ideas where to go to
An excellent write-up, thank you.
In our case puppet-master is actually an LXC container instance. On
reflection the values reported by top are meaningless, and I'm not
convinced I know the solution for monitoring purposes. I might suggest
however that part of application support now needs to incl
16850 puppetdb 20 0 12.697g 418684 14848 S 0.9 0.4 4:32.74 java
That's top now since it began running around 10.30 this morning (GMT). 12G
of ram? It's the only proc in the list having a 'g' against it. Seems
excessive..?
On 16 February 2015 at 12:43, James Green
> ken.
>
> On Mon, Feb 16, 2015 at 11:23 AM, James Green
> wrote:
> > We have a puppet-master box with the following installed:
> >
> > root@puppet-master:/var/log/puppetdb# dpkg -l | grep puppet
> > ii facter 2.4.1-1puppetlabs1
We have a puppet-master box with the following installed:
root@puppet-master:/var/log/puppetdb# dpkg -l | grep puppet
ii facter 2.4.1-1puppetlabs1 all
Ruby module for collecting simple facts about a host operating system
ii hiera
0 December 2014 at 14:59, James Green wrote:
> augeas { 'postfix-master-smtp-inet' :
> context => "/files/etc/postfix/master.cf",
> changes => [
> "set smtp[type = inet]/private n",
> "set smtp[type = inet]/unprivileg
augeas { 'postfix-master-smtp-inet' :
context => "/files/etc/postfix/master.cf",
changes => [
"set smtp[type = inet]/private n",
"set smtp[type = inet]/unprivileged -",
"set smtp[type = inet]/chroot n",
"set smtp[type = inet]/wakeup -",
"set smtp[type = inet]
Could someone kindly add a notice bar to the puppet.conf web documentation
stating that:
*Changes to puppet.conf are picked up automatically by the puppet agent.
You can observe this by making a change and tailing syslog for a few
moments.*
There are a few google results teaching us how to declar
Upon further investigation, this is PUP-2700 getting us busted for any new
instances. In our case the files are held on the puppet master but we're
using passenger I'm told.
So until 3.7 is out I guess we're completely reliant on existing
instances..?
On 26 June 2014 15:54, Jam
I'm trying to "finish off" some work a colleague began which includes
distribution of some files from the puppet master.
I just fired up a new instance and watched as puppet agent -t came up with
a whole lot of errors in ensuring certain files were present. Intrigued, it
seems those with a space i
18 matches
Mail list logo