At 64 cores, the load average comes out to .4 per core. Somebody correct
me, but that actually seems fairly low.
That said, if you want to pursue this further, I would suggest
implementing something like this to give you a better idea of your
Puppet Server health:
Hi Robert!
Is separating the customer data an option? That would let you manage the
modules without having to increment them constantly, while pulling the customer
data from another location - perhaps from a GIT repository using Puppet's
vcsrepo module.
- Rilindo
-Original Message-
You can use any VCS with Puppet. I know of one shop that uses Mercurial.
Most of the tooling and integration are closely coupled with git and most of
the workflows assumes that you will be using git. So it would be a good idea to
get up to speed with it.
Of note that you can use git with svn
By default, the certname is the fully qualified domain. You can change it via
the node_name_value or node_name_fact; however, you need to have a very good
reason to change the settings before you move forward with it.
https://docs.puppetlabs.com/references/latest/configuration.html#certname
-
1) Does it work with Foreman?
Yes, though if you are not using Foreman for anything other than
Reporting and ENC, Puppet's console is pretty capable as a replacement.
2) Can it be installed from an internal RPM repository?
Yes. There is a Foreman repo you'll need to sync for the base
Hi Hoize,
To clarify, did you put Foreman on top of your existing Puppet
infrastructure or did you use the Puppet Master that Foreman installed?
It would make sense if it were the latter, because Foreman re-uses
Puppet's certificates for its own SSL setup. That, in turn, would
explain why
Hi Hoize,
To clarify, did you put Foreman on top of your existing Puppet
infrastructure or did you use the Puppet Master that Foreman installed?
It would make sense if it were the latter, because Foreman re-uses
Puppet's certificates for its own SSL setup. That, in turn, would
explain why
Hi Hoize,
To clarify, did you put Foreman on top of your existing Puppet
infrastructure or did you use the Puppet Master that Foreman installed?
It would make sense if it were the latter, because Foreman re-uses
Puppet's certificates for its own SSL setup. That, in turn, would
explain why
It seems you are using this as a way to classify nodes. Your best option is to
use an ENC (Foreman or Hiera) to classify your nodes, ideally using the roles
and profiles pattern to abstract your modules.
On Jan 9, 2015, at 1:52 PM, Jason Price japr...@gmail.com wrote:
This doesn't make me
The syntax appears to be correct, from what I see. Being that this Apache
module came from PuppetLabs, I think it is safe to assume that the module is
robust. I would try to try enable full debugging on both the agent and the
master.
Also, on the agent, try to walk through the installation of
This line here:
content = template(samba/smb.erb, samba/${hostname}.erb),
What is your intention with having multiple .erb files per hostname? That might
help us figure if there a different solution is warranted.
-Rilindo
On Aug 7, 2013, at 3:20 PM, Ted Fiedler fiedl...@gmail.com wrote:
I
I guess this piece of code is what you created , because puppet-gitlab has that
already defined service.pp already has that defined:
file {
'/etc/init.d/gitlab':
ensure = file,
content = template('gitlab/gitlab.init.erb'),
owner = root,
group = root,
mode
Assuming that you are running a typical puppet master configuration, if you
review the Puppet process flow here:
http://www.aosabook.org/images/puppet/TimingDiagram.png
You would see that the issue likely occurring during plugin stage. This seems
to be cause because it looks like it is not
Starting in Pupet 3.2, there is experimental support for iteration:
http://docs.puppetlabs.com/puppet/3/reference/lang_experimental_3_2.html#collection-manipulation-and-iteration
On Jun 10, 2013, at 3:41 PM, Martin Langhoff martin.langh...@gmail.com wrote:
Sysadmins have the (reasonable?)
It seems that there is a possible problem with your repo configuration. That
is, it is attempting to install a 32 bit version of the binary package, even
you are probably running a 64 bit version of RHEL. I suspect you probably will
encounter this problem as well with other packages. If you are
I have a puppet master that I had recently split into two, one handling just CA
functionality and one handling the normal puppet master operations.
puppet_ca
puppet_master
Otherwise, both are configured identically as follows:
1) The modules are stored into separate environments under
I usually explicitly set the $puppetversion in my manifest for my environment.
Furthermore, I have my own mirror copied from puppet labs repo and install it
from that location instead. That way, I have control of what I push out and
only update when I know that the new version is sound.
So I
As Steven said, it is normal for a puppet-master not to allow a re-imaged
machine until the certificate is re-generated. I will point out that depending
on the your environment, it may be a security risk to any client to
authenticate against the puppet-master.
For my environment, I explicitly
Fair enough. I looked at the docs again after I sent the email and yes, looks
like I can, with some caveats.
Thanks!
On Aug 8, 2012, at 11:45 PM, Ryan Coleman r...@puppetlabs.com wrote:
On Wed, Aug 8, 2012 at 6:18 PM, Foster Rilindo rili...@mac.com wrote:
I currently have puppet configured
Puppet will work with 1.8.5. It is passenger that requires 1.8.7, specifically
rack.
Fortunately, Puppet labs has the older rack version you can use here:
http://yum.puppetlabs.com/el/5Server/dependencies/x86_64/
On Jun 26, 2012, at 10:47 AM, Dan White wrote:
I am stuck on RHEL 5 for the
I wrote a custom fact called xen_total_memory that pulls the xen memory from
xm info:
require 'facter/util/memory'
begin
xen_total_memory = `xm
info`.grep(/total_memory/).to_s.split(/:/)[1].lstrip.chomp
rescue
xen_total_memory =
end
Facter.add('xen_total_memory') do
confine :kernel = [
21 matches
Mail list logo
