[Puppet Users] node performance - rack wrapper app
Hi All, For those of us dealing with slow puppet runs, due to having hundreds or thousands of node manifests, I've release a simple rack wrapper app. The app will determine which site.pp to use based on the fqdn of the requesting agent. It just a wrapper to the puppet rack call that passes the --manifest ARGV with a more targeted "site.pp". So you could have one import statement (site.pp) for each domain instead of having the puppet server parse all nodes on each run. It's a great stop-gap for those of us migrating a large environment to Hiera but in need of faster runs in the interim. Let me know your thoughts: https://github.com/rbowlby/puppet-manifest-router Cheers, Ryan -- 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] Nagios XI + Puppet?
Hi All, I currently make use of Icinga (nagios fork) + Puppet for fully automated monitoring. It's worked great up to this point. I've recently been asked to integrate fine grained notifications support into icinga. I'm not entirely sure puppet manifests are the right place to manage contacts, contact groups, and their use within host and service definitions for notifications. Has anyone made use of the puppet + Nagios XI? Would it be possible to manage notifications within the webUI while still using puppet for generating the host,hostgroup,service configs? Pagerduty isn't an option for reasons I can't get into here. Thanks, Ryan -- 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: Inheritance of classes in Ruby DSL
...Bueller Anyone have an answer for this? This seems like a pretty pertinent feature for anyone looking to take advantage of the ruby DSL. I for one would be eternally grateful. -Ryan On Wednesday, June 13, 2012 8:08:07 AM UTC-7, Ingo Fischer wrote: > > I have the same question (see > https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/inheritance$20ruby$20dsl/puppet-users/RtMbu8yFZCc/Zet8ackZgnYJ) > > and need this behavior for my project. > > Is inheritance possible at all with the Ruby DSL? If not, should we create > an issue for that? > > Am Dienstag, 15. Mai 2012 10:16:22 UTC+2 schrieb alxrem: >> >> Hello. >> >> Is it possible to describe inheritance of classes in Ruby DSL? >> > -- 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: librarian-puppet
We went with git super projects and submodules instead of librarian-puppet. Might want to look at using git for management of per puppet-module repositories as well. On Wednesday, July 25, 2012 7:37:10 AM UTC-7, llo...@oreillyauto.com wrote: > > I've heard this project mentioned a few times and I have found the > projects site on github. > > Is there information available on how to setup the repos that it would > pull from (layout etc)? The boxes I would be using this on do not have > access to the Puppet Forge but this project looks like it would be useful > in addressing somethings I've been trying to decide on how to handle for a > while now. > > I know that as of yet there isn't a way to setup a true private forge, > though some options are in the works (pulp, for example). Unfortunately, > pulp is currently on officially supported on Fedora/RHEL based systems and > YUM repos, though they are working on expanding the options. > > Any other suggestions or recommendations for getting started with this > would be appreciated as well. > > Thanks. > > --Lee > -- 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/-/7UlS4Gcb5-YJ. 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] librarian-puppet vs git superproject?
Thanks all, we've decided to stick with git super project and per module repositories. Some of the modules will be a clone from github, but most are internal. It seems to suit our needs and we don't see a reason to implement librarian-puppet. Ohad, I setup pulp at work and it's pretty good (tasks get stuck occasionally). We don't use consumer though, we manage packages via puppet. I'm actually thinking of creating a pulp defines for some of the pulp-server tasks "pulp-admin repo create". I guess I should publish our existing pulp module. I take it you're talking about a future release where pulp has a plugin model and is more of a generalized "manage all the things" tool? Is there going to be a plugin for the forge or something? -Ryan On Tuesday, July 24, 2012 1:00:00 AM UTC-7, ohad wrote: > > > > On Tue, Jul 24, 2012 at 9:49 AM, David Schmitt wrote: > >> On 24.07.2012 00:43, Ryan Bowlby wrote: >> >>> Can anyone comment on their experiences with librarian-puppet or using >>> git superproject with per puppet module repositories? We are in the >>> midst of determining which route is optimal for our environment. It >>> seems like using git superprojects would mean one less new tool for >>> everyone to learn. What then would be the advantages of librarian-puppet? >>> >> >> I've played around with repo (android's git forest manager) but it's just >> too much complexity for non-developers. I've now switched to everything in >> one .git and it's just so much easier to manage. Putting external modules >> in a separate branch and then subtree merge is a viable, albeit still too >> complex, way for tracking externals. >> >> > I myself still use submodules, as most of my modules are not in the > forge, maybe that would change once pulp will offer an alternative. > > Ohad > >> >> Best Regards, David >> >> >> -- >> 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+unsubscribe@** >> 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/-/L6w5ahoRnKsJ. 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] librarian-puppet vs git superproject?
Can anyone comment on their experiences with librarian-puppet or using git superproject with per puppet module repositories? We are in the midst of determining which route is optimal for our environment. It seems like using git superprojects would mean one less new tool for everyone to learn. What then would be the advantages of librarian-puppet? Thanks, Ryan Bowlby -- 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/-/4Kf47PY2sIwJ. 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] Re: How to take away install privilege from users other than puppet?
That's not really a puppet question. Typically installation of software in normal (posix compliant) locations requires root privileges. Merely limiting the commands one is capable of executing via sudo would likely be enough. -Ryan On Saturday, July 14, 2012 10:29:33 PM UTC-7, Ganesh Ganesh wrote: > > Hi Guys, > > I am trying to configure to my client machine, I want prevent user > don't do installation, All installation done through puppet only, How > to do it, Guide me... > > -Ganesh. > > Did I learn something today? If not, I wasted it. > -- 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/-/7Y0OVn6FEaUJ. 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] Re: can nodes be grouped with IP address?
I would probably grimace and find my right eye twitch ramp back up if this
was in my environmentbut here you go:
node default {
if $::ipaddress =~ /^10\.0\.[3,4]\.\d{1,3}$/ {
include testing # testing class
}
}
Obviously make sure no other matching node defs exist for this host.
-Ryan
On Thursday, July 5, 2012 11:34:39 AM UTC-7, Hai wrote:
>
> instead of using hostname wildcard, is there a way to define nodes by
> their IP addresses? for example, I want to put all nodes with 10.0.2.x and
> 10.0.3.0 to a nodes group called "testing". how can I do this?
>
> thanks.
>
--
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/-/KGRDXRuwnZ4J.
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] Re: Built in rollback features
I tend to expose the ensure related resource attributes as parameters that
can be specified at the node level:
class { "apache":
package_ensure => "absent",
}
The natural evolution is to get to a point within the organization where
reinstalling a host is no longer scary. If the provisioning process is
working well you can likely do a rolling reinstall of the infrastructure to
ensure against system "state drift". That's often much easier than
attempting to write each module to support the arguably antiquated idea of
rollbacks.
-Ryan
Hope Turnbull doesn't see this post, no more princess rape digressions. lol
On Thursday, July 5, 2012 1:45:13 PM UTC-7, gilbertc777 wrote:
>
> Hi Everyone,
>
> I am relativly new to writing puppet modules, and am working to architecht
> our puppet implementation. One of the questions I have, is rolling back a
> puppet run. What are the best ways to accomplish this.
>
> For instance, if I add a module to manage autofs, apply it to a server,
> and then no longer want to manage autofs on the server, how would I make it
> so that I can roll the server back to the unconfigured state?
>
> Also, when managing local account using puppet, what are ideas to handle
> the following case:Users A, B and C are added to all our servers. After
> running for some time, we need to only remove User B.
>
> I have read on multiple blogs about having !classes, but I want to try and
> work towards using more of an industry standard and wanted to get other
> peoples opinions.
>
> Thanks!
> Chuck
>
--
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/-/j6GaxxfnPR8J.
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] file_line type issue, possible bug
Thanks Jeff, I'll heed that advice. Wouldn't it make sense though to have the file resource "respect" changes made by file_line. Behind the scenes, if the file resource were able to know about the file_line additions and could remove them before calculating the md5 then both can be used on the same file. The current conflict doesn't have to be a conflict, I assumed puppet did this already. -Ryan On Sunday, June 10, 2012 9:58:23 AM UTC-7, Jeff McCune wrote: > > On Sun, Jun 10, 2012 at 3:56 AM, Ryan Bowlby wrote: > > Hi All, > > > > I am using the file_line type included in stdlib to add a line to > > /etc/sudoers. On each run the sudo module replaces /etc/sudoers, then > > file_line resource adds the line back. It's happening on each run and I > > can't seem to figure out to get the sudo module's file resource to stop > > replacing the file on each run. I was hoping the file resource would > ignore > > any lines propagated by the file_line resource. Is this a bug or am I > just > > missing something? > > It's not a bug, it's just how things work. > > What's happening is that you have two models (File_line and > File[/etc/sudoers]) of the same resource (/etc/sudoers) and the two > models conflict with each other. > > The file resource has no knowledge of the file_line resource. I'd use > one or the other but not both. > > A file resource is most appropriate when you can manage the entire > contents of the file. A file_line resource is appropriate when you > can't manage the entire contents of the file, only portions of it. > > Hope this helps, > -Jeff > -- 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/-/NcyEJNStTq4J. 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] file_line type issue, possible bug
Hi All, I am using the file_line type included in stdlib to add a line to /etc/sudoers. On each run the sudo module replaces /etc/sudoers, then file_line resource adds the line back. It's happening on each run and I can't seem to figure out to get the sudo module's file resource to stop replacing the file on each run. I was hoping the file resource would ignore any lines propagated by the file_line resource. Is this a bug or am I just missing something? -Ryan -- 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/-/L7OtmlWKio0J. 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] Duplicate package resource solutions?
Hi Guys,
I searched through the forum and found a few related threads but no clear
puppet sanctioned solution. We have several modules that require the same
package, for example rsync or gcc. We usually solve these conflicts by
making that package a standalone module. We don't want to have modules
exist for the sole purpose of installing gcc. Initially we had a
development-tools module that installed the RH equivalent of the
"Development Tools" yum group. In some cases only a third of the packages
were truly required, so this solution seems suboptimal.
What would be the downside of creating a module called common-packages
which would become the central location for simple packages (no
daemon/service, etc)? Declare all the packages within the common-packages
class as virtual resources. Then each module can feed off that class for
the individual packages it requires. This would solve the problem caused by
multiple identical package resources being defined throughout modules.
class common-packages {
@package { "rsync":
ensure => "present",
}
...
}
class somemodule {
include common-packages
realize(Package["rsync"])
...
}
We obviously would create individual modules for packages that require any
advanced logic: apache, tomcat, etc. What would be the downside to doing
this?
Thanks,
Ryan
--
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/-/EYtF4SJppcQJ.
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] Re: override parameter within base class?
Thanks John, but it appears the ability to override a parent class
parameter is limited to the resources DEFINED within that class. In my
base class I am merely declaring/instantiating the apache class and
not defining it. The overriding of parameters does not appear to work
in that case.
I ended up just doing a few simple wrapper parameters as advised by
Nick. I like the Hiera idea but it will have to wait since we have so
much low hanging fruit to pick for the time being. Thanks everyone!
-Ryan
On May 30, 2:00 pm, jcbollinger wrote:
> On May 30, 2:37 pm, Ryan Bowlby wrote:
>
>
>
>
>
>
>
>
>
> > Hi All,
>
> > Is there a way to override the value of a parameter to a declared
> > class within my base class. My nodes use a base class that
> > occasionally need to be changed. Example:
>
> > class "base" {
> > class { "apache":
> > mpm => "worker",
> > }
> > ..other awesomeness
>
> > }
>
> > Then in the nodes:
>
> > node "a" {
> > include base
>
> > }
>
> > # made up syntax
> > node "specialhost" {
> > class "special" inherits base {
> > Class { "apache": mpm => "prefork" }
> > }
>
> > }
>
> > How do I override the mpm param within the apache declaration within
> > the base class for "specialhost"? Is this possible and if not what are
> > the common workarounds?
>
> What you wrote is similar to what I would expect to work, which would
> be this:
>
> class special inherits base {
> Class['apache'] { mpm => 'prefork' }
>
> }
>
> node 'specialhost' {
> include 'special'
>
> }
>
> That's the standard syntax for subclasses overriding their parent
> class's resource's parameters. In practice, I'd put the subclass
> definition in its own file in a suitable module, of course.
>
> John
--
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] override parameter within base class?
Hi All,
Is there a way to override the value of a parameter to a declared
class within my base class. My nodes use a base class that
occasionally need to be changed. Example:
class "base" {
class { "apache":
mpm => "worker",
}
..other awesomeness
}
Then in the nodes:
node "a" {
include base
}
# made up syntax
node "specialhost" {
class "special" inherits base {
Class { "apache": mpm => "prefork" }
}
}
How do I override the mpm param within the apache declaration within
the base class for "specialhost"? Is this possible and if not what are
the common workarounds?
Thanks,
Ryan
--
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] Re: Check if class has been included?
On May 4, 6:34 am, jcbollinger wrote:
> On May 4, 1:54 am, Dan Carley wrote:
>
>
>
>
>
>
>
>
>
> > On 3 May 2012 23:32, jcbollinger wrote:
>
> > > Hmm. I guess I misunderstood your objective. It is still true that
> > > 'defined' is not a good approach, however, and also that
> > > os::motd::register is a bit rude to not take care of declaring its
> > > dependencies itself.
>
> > > It might work to declare all your os::motd::register instances
> > > virtually, right where they now are, and then collect them at the end
> > > of each node definition. I suspect, though, that you would end up
> > > with the same problem you already have.
>
> > > Generally, I recommend replacing "is foo defined?" conditions with "is
> > > foo *supposed to be* defined?". The latter can be evaluated based on
> > > global or class variables, or (better) external data.
>
> > It's a fine use case for virtual resources. Each class would declare the
> > virtual:
>
> > class pulp {
> > @os::motd::register { $name: }
> > ...
> > }
>
> > Then os::motd would, when included in the catalog, collect/realize
> > everything available:
>
> > class os::motd {
> > Os::Motd::Register <| |>
> > ...
> > }
>
> Yes, that's similar to what I suggested. I suspect, however, that it
> will not solve the OP's problem of wanting to avoid declaring class
> os::motd on some nodes, given that os::motd::register depends on that
> class having been declared. Under those circumstances, I expect that
> even a virtual declaration of os::motd::register will fail if os::motd
> is not (already) declared, regardless of whether the virtual resources
> are ever collected.
>
> Also, I strongly suspect that collecting os::motd::register instances
> in os::motd would not work, because no such instances can have been
> declared at the time that the collection declaration is parsed.
>
> That all does suggest another possible approach, though: the situation
> would be much improved if os::motd::register's dependency on os::motd
> could be removed. Without seeing the code I can only speculate, but
> it may be that os::motd could be refactored to make that possible.
> For instance, if os::motd::register's need is merely for class
> variables from os::motd, then perhaps those can be extracted into a
> separate os::motd::params class that os::motd::register would use
> instead.
>
> John
Dead on John. I ended up going simple and making os::motd::register a
simple define that creates a file in /var/lib/puppet. If os::motd
happens to be declared then it just concatenates those individual
files into one that is further added to motd using puppet-concat.
Worked like a gem, K.I.S.S.
Thanks Guys.
--
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] Re: Check if class has been included?
My apologies on terminology and thank you for the list of best
options. My problem is this, I want to have this os::motd::register
defined type exist in the main class of every module. Yet I don't want
to force a host to have to include os::motd. I want it as an option.
The fact that I don't want to include os::motd on each node means all
three options don't work.
I'm starting to think using the os::motd::register defined type in
every module is not the way to go. Perhaps using exported resources is
a more flexible method of achieving this?
Thanks,
Ryan
On May 3, 7:19 am, jcbollinger wrote:
> On May 2, 3:14 pm, Ryan Bowlby wrote:
>
>
>
>
>
>
>
>
>
> > Hi All,
>
> > I recently added the puppet-concat module in order to implement the
> > example motd use case. Now our motd includes a list of modules being
> > used on the server, which is awesome.
>
> > All the modules define an motd::register so they expect that the motd
> > module was included. When a node does not include the module all those
> > dependent modules fail. I would like to have each module first check
> > to see if the motd class has been included.
>
> > Current example:
>
> > class pulp (..
> > .
>
> > # list this module/class in motd
> > os::motd::register {"pulp": }
>
> > }
> > Future example:
>
> > class pulp (..
> > .
> > if defined(os::motd) {
> > # list this module/class in motd
> > os::motd::register {"pulp": }
> > }
>
> > }
>
> You are confusing me with your terminology. An entity referred to in
> a Puppet manifest as 'os::motd' is either a class or a defined type in
> module 'os', not a module itself. You can "include" or "declare" a
> class, but not a module. You can "instantiate" or sometimes "declare
> [an instance of]" a defined type, or some people "call" one. Your
> manifests cannot directly refer to a module at all, only to its
> contents.
>
> I'm not familiar with the motd module, but os::motd::register must be
> a defined type. It should be the responsibility of the definition to
> include any classes it depends on. It can and should do so unless one
> or more of those classes is parameterized, so that your own classes
> that use it Just Work. If the definition needs a parameterized class
> to have been declared, however, then it thereby leaves you hanging.
>
> > The question is whether this is the right way to go about it? Does the
> > define wait for all class declarations before checking (does order
> > matter)?
>
> No and no (and yes). Parse-order dependency is a prime reason why
> such useage of the 'defined' function is poor practice. There has
> even been some discussion of deprecating it.
>
> If 'os::motd' is an unparameterized class, then your best options are:
> 1) put "include 'os::motd'" at the begining of the body of
> os::motd::register, OR
> 2) put "include 'os::motd'" at the begining of every class that
> instantiates os::motd::register, OR
> 3) put "include 'os::motd'" at the begining of every node definition
> (or make your ENC output that class first in its class list)
>
> If 'os::motd' is a parameterized class then your best bet is to adjust
> your node declarations / ENC so that os::motd is declared first for
> every node.
>
> John
--
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] Check if class has been included?
Hi All,
I recently added the puppet-concat module in order to implement the
example motd use case. Now our motd includes a list of modules being
used on the server, which is awesome.
All the modules define an motd::register so they expect that the motd
module was included. When a node does not include the module all those
dependent modules fail. I would like to have each module first check
to see if the motd class has been included.
Current example:
class pulp (..
.
# list this module/class in motd
os::motd::register {"pulp": }
}
Future example:
class pulp (..
.
if defined(os::motd) {
# list this module/class in motd
os::motd::register {"pulp": }
}
}
The question is whether this is the right way to go about it? Does the
define wait for all class declarations before checking (does order
matter)?
Thanks,
Ryan
--
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] Re: scaling puppet, skipping puppetmaster?
Currently we have two puppetmaster servers with ALL requests being load balanced. I use unison to keep the ssl directory in sync between hosts. Each server runs keepalived and requests go to a VIP that exists on one of the servers. The server with the VIP load balances the requests (mod_proxy) between both servers. It's working relatively fine, though it would be ideal to have the agents connect at semi-random intervals in order to reduce "thundering herd" issues. We are over 500 without any real issues. Also, the decentralized approach works fine but there are caveats related to the use of custom functions that rely on a central server, virtual resources(?), etc. I would try to scale your masters as it's not that hard. -Ryan -- 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] Agent thundering herd solutions?
I'm hoping to have all the puppet agents run on a 20 minute interval with 480sec on either side. I don't want to launch the agent from cron in order to achieve a level of randomness. Is there a splay/random option that can be included in the sysconfig file or config file? I want to continue running the agent as a daemon. Thanks, Ryan -- 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] Re: Empty node definition mysteriously runs yum class!
Nailed it. Accidentally had the include outside the class at "top- level". That's a scary uhum feature. Might need to look into integrating some test code that looks for top-level includes within the modules dir and warns. Thanks John! -Ryan On Mar 29, 5:42 am, jcbollinger wrote: > On Mar 28, 3:00 pm, Ryan Bowlby wrote: > > > I'm having an issue where every single puppet node included our yum > > class as part of the catalog. In all instances the nodes node > > definition was empty. Has anyone experienced something like this > > before? Is the yum class colliding with an internal class? > > > We do not define a node default or use any node regex that would have > > caused this. No other rogue classes are being included except the yum > > class. > > My first guess would be that you declare your yum class at top level > (== outside any node definition or other class) somewhere in one of > the manifests that all the affected nodes use. Top-level declarations > apply to all nodes, and they can be in any manifest file. > > John -- 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] Empty node definition mysteriously runs yum class!
I'm having an issue where every single puppet node included our yum class as part of the catalog. In all instances the nodes node definition was empty. Has anyone experienced something like this before? Is the yum class colliding with an internal class? We do not define a node default or use any node regex that would have caused this. No other rogue classes are being included except the yum class. -- 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] Testing catalog run on REAL node as git pre-push hook?
Hi All, We'd like to do some form of testing of our module changes against production nodes before being released into production. While somewhat expensive it seems doing a noop against all nodes using the modified module is the best way to determine unexpected results. The question then is how are people implementing this? Any real world talks or posts describing something like this would be great. Ideally we want to put a git pre-push hook in place within the production branch that performs a noop catalog run against the affected nodes and reports results and determines if errors were encountered. Thanks!!! Ryan Bowlby -- 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] Display puppet managed resources in motd?
Hi All, I'd like to display which resources are managed by Puppet in a given host's motd file. Does anyone know the best way to accomplish this? As we transition to puppet it would be helpful to know what resources are currently being managed by puppet. Alternatively, if anyone has created a command line utility that prints a list of resources managed by puppet then that would do as well. Cheers, Ryan -- 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] Re: Error 400 on SERVER: Could not autoload active_record: uninitialized constant ActiveRecord
Thank you, you just added hours to my life! 3.0.11 works perfect. Perhaps the puppetlabs docs should make note of this? -- 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/-/AtyLWUsZhWEJ. 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] Re: Conditional copy of file
Wrap the file resource in an if that checks if $conf_file is defined.
I would also recommend replacing the case statement with a
parametrized class with the default for $conf_file being undef.
Also, if you were okay with having a default blank file present then
you could just replace your current case statement with a list to the
file source attribute:
file { "/path/to/my/file":
source => [
"/modules/nfs/files/file.$host",
"/modules/nfs/files/file"
]
}
http://docs.puppetlabs.com/references/2.7.0/type.html
On Feb 1, 6:21 am, kashif wrote:
> Hi
> It may have been answered earlier but I could not find anywhere. My
> requirement is that I want to copy a file from server to agent in few
> conditions but don't want to touch file in rest of the condition
>
> class example {
> case $hostname {
> node1 : {$conf_file = 'file1'}
> node2: {$conf_file = 'file2'}
> }
> file { '/etc/network/test':
> ensure => file,
> source => "puppet:///modules/example/
> $conf_file",
> }
> }
>
> It is working but I want that in case none of the above condition is
> true then 'test' file should not be touched.
> But what is happening here that, if hostname is different from node1
> or 2 then puppet creates a empty test directory in /etc/network/
> folder.
> Any suggestion ?
> thanks
> Kashif
--
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] Re: Puppet can't start service (dropbox) but init.d command works manually
I second checking for required environment variables. Attempt to run
in a shell that hasn't sourced your .bash_profile and related login-
time config files. Also, try it with an exec with "/bin/bash -x /etc/
init.d/dropbox start" to further troubleshoot.
On Jan 30, 3:05 pm, "Richard K. Miller"
wrote:
> I'm using Dropbox's command-line daemon on one of our machines and
> want to use Puppet to keep it running. The dropbox service is already
> installed and allows me to successfully execute /etc/init.d/dropbox
> [start/stop/restart/service]. Here's my code:
>
> class dropbox::service {
> service { "dropbox":
> ensure => running,
> }
>
> }
>
> I get the following syslog error when this runs:
> (/Stage[main]/Dropbox::Service/Service[dropbox]/ensure) change from
> stopped to running failed: Could not start Service[dropbox]: Execution
> of '/etc/init.d/dropbox start' returned 1: at /etc/puppet/modules/
> dropbox/manifests/init.pp:14
>
> However, if I run the above command manually, it works fine and
> returns 0:
>
> root@webhost:~# /etc/init.d/dropbox start ; echo $?
> Starting dropbox...
> 0
>
> Any ideas why puppet can't start the dropbox daemon?
>
> Richard
--
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] Re: Puppet security issue?
Thanks Brice, using mod_rpaf fixed the issue! I've also realized why puppet SHOULD NOT rely on the X-Forwarded-For for determining source information to authorize API access. As soon as I had it working with mod_rpaf I performed an API request with a hostname different than the actual machine: malicious host root$ curl -k -H "X-Forwarded-For: trustedhost.domain" - H "Accept: pson" https://puppet.domain:8140/production/certificate_statuses/no_key Which worked, not too surprising. So while mod_rpaf DID fix the issue it also didn't secure anything. Alas, one should always make use of puppet client certificate based auth, especially when using a proxy that may or may not muddle with the origination information. Also, for those who find this later: On CentOS 6.x this is available as an RPM in atomic: rpm -Uvh http://www6.atomicorp.com/channels/atomic/centos/6/x86_64/RPMS/atomic-release-1.0-14.el6.art.noarch.rpm yum -y install mod_rpaf adding the following to the vhost: RPAFenable On RPAFsethostname On RPAFproxy_ips 127.0.0.1 Now that I know it works I'll likely build an RPM for the local repo, rather than rely on a lesser known repo. Thanks again, Ryan Bowlby On Jan 26, 11:37 pm, Brice Figureau wrote: > On 27/01/12 02:14, Ryan Bowlby wrote: > > > Hi All, > > > I have a two puppet servers using Apache with mod_proxy as the > > frontend. Similar to what what's described in Pro Puppet. > > Unfortunately, Apache mod_proxy is passing the puppetca requests using > > the loopback IP instead of the original source IP. > > You're not mentioning what stack your master are running. > But if they're running on Apache and Passenger, may I suggest using > mod_rpaf? > > > This is a bit of a security concern when configuring auth.conf! An > > example stanza in auth.conf: > > > # allow certificate management on provisioning server without cert > > path ~ /cert* > > auth no > > allow localhost > > If you instead make this a certname, then it's secure again. > > > With that near the bottom of auth.conf ALL hosts can now perform any > > API calls matching that path. This is due to puppet using the > > 127.0.0.1 passed by Apache. > > > I need one of the following: > > > 1. A way to do IP passthrough in apache such that the correct > > originating IP is used. > > Configure your mod_proxy to pass the IP in X-Forwarded-For. > > > 2. Puppet to make use of the X-Forwarded-For header if it exists and > > to fallback in instances where it doesn't. > > And mod_rpaf is what you need, running in your master apache. > > > > > > > > > > > Likely the latter is the best method. Please feel free to correct me > > if I am missing something. I have verified that with the above > > auth.conf stanza ALL hosts can perform all /cert* related API calls. > > Additionally here is a log line: > > > 127.0.0.1 - - [27/Jan/2012:00:32:00 +] "GET /production/ > > certificate_statuses/no_key HTTP/1.1" 200 343 "-" "curl/7.15.5 (x86_64- > > redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/ > > 0.6.5" > > > That's a request from another server. Here are the Apache configs: > > >http://pastebin.com/rDKPSjjy > > > Thanks everyone! > > Ryan Bowlby > > -- > Brice Figureau > My Blog:http://www.masterzen.fr/ -- 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] Re: Issue Installing Puppet on Red Hat6
I use CentOS 6.2 with yum-priorities and several additional repositories. In general the following priority order works well: updates -> extras -> puppetlabs -> epel -> rpmforge Then, as said previously, just run yum -y install puppet-dashboard and continue following docs. That setup will allow you access to just about every package you would need without causing crazy dependency issues. -Ryan On Jan 26, 3:33 pm, Gmoney wrote: > I have been trying to follow the bootstrap instructions for installing > puppet-dashboard. I keep getting error about rubyge(rake) and > rubygems. I'd appreciate any help or corrections, thanks in advance. > > ruby-libs-1.8.7.299-4.el6.x86_64 > ruby-1.8.7.299-4.el6.x86_64 > > These are some installation steps I took. > > rvm tools rvm-env ruby bash > rvm install 1.8.7 > > yum install ruby > > downloaded rubygems from:http://rubygems.org/pages/download > > gem install rubygems-update > > LD_LIBRARY_PATH=/usr/local/rvm/src/ruby-1.8.7-p357:$PATH > export LD_LIBRARY_PATH > gem install mysql-2.8.1.gem > > install rake: > git clone g...@github.com:gmoneyice/rake > cd /root/ruby > gem install rake > > Here is the error: > > yum install puppet-dashboard > Loaded plugins: rhnplugin > This system is not registered with RHN. > RHN support will be disabled. > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package puppet-dashboard.noarch 0:1.2.4-1.el6 set to be updated > --> Processing Dependency: ruby-mysql for package: puppet- > dashboard-1.2.4-1.el6.noarch > --> Processing Dependency: rubygem(rake) for package: puppet- > dashboard-1.2.4-1.el6.noarch > --> Processing Dependency: rubygems for package: puppet- > dashboard-1.2.4-1.el6.noarch > --> Running transaction check > ---> Package puppet-dashboard.noarch 0:1.2.4-1.el6 set to be updated > --> Processing Dependency: rubygem(rake) for package: puppet- > dashboard-1.2.4-1.el6.noarch > --> Processing Dependency: rubygems for package: puppet- > dashboard-1.2.4-1.el6.noarch > ---> Package ruby-mysql.x86_64 0:2.8.2-1.el6 set to be updated > --> Finished Dependency Resolution > Error: Package: puppet-dashboard-1.2.4-1.el6.noarch (puppetlabs- > products) > Requires: rubygem(rake) > Error: Package: puppet-dashboard-1.2.4-1.el6.noarch (puppetlabs- > products) > Requires: rubygems > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest -- 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] Re: passing argument to a class or a module
Classes can only be declared once while defines can be declared multiple times. So if you wanted two vhost files a define would be needed. On Jan 26, 3:47 pm, Joehillen wrote: > whoa, my bad. I learned puppet before 2.6 > > Now I don't know why there is a distinction between classes and defines. > I'll have to read up. > > Thanks -- 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] Puppet security issue?
Hi All, I have a two puppet servers using Apache with mod_proxy as the frontend. Similar to what what's described in Pro Puppet. Unfortunately, Apache mod_proxy is passing the puppetca requests using the loopback IP instead of the original source IP. This is a bit of a security concern when configuring auth.conf! An example stanza in auth.conf: # allow certificate management on provisioning server without cert path ~ /cert* auth no allow localhost With that near the bottom of auth.conf ALL hosts can now perform any API calls matching that path. This is due to puppet using the 127.0.0.1 passed by Apache. I need one of the following: 1. A way to do IP passthrough in apache such that the correct originating IP is used. 2. Puppet to make use of the X-Forwarded-For header if it exists and to fallback in instances where it doesn't. Likely the latter is the best method. Please feel free to correct me if I am missing something. I have verified that with the above auth.conf stanza ALL hosts can perform all /cert* related API calls. Additionally here is a log line: 127.0.0.1 - - [27/Jan/2012:00:32:00 +] "GET /production/ certificate_statuses/no_key HTTP/1.1" 200 343 "-" "curl/7.15.5 (x86_64- redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/ 0.6.5" That's a request from another server. Here are the Apache configs: http://pastebin.com/rDKPSjjy Thanks everyone! Ryan Bowlby -- 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] Re: params.pp class with parametrized class support?
Show off! ;) Great example thanks. I noticed you fully qualify variables within the very class they were assigned. Is that best practice now? I've created a simple apache module using your openssh module as inspiration. I still need to modify params.pp to check for globally defined vars. In the current incarnation it optionally installs the mod_ssl package if the "apache:ssl" class is declared (which inherits the apache class). Would you recommend doing optional packages as sub classes? Does it make more sense to install optional packages based on class parameters? https://github.com/rbowlby/apache On Jan 18, 1:58 am, Alessandro Franceschi wrote: > Look here at how I do this:https://github.com/example42/puppet-openssh -- 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] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
Looking into it now, thanks. Related question, I see a lot of modules
where an optional package is available as another class, example
include apache::ssl
would install apache and mod_ssl. With parametrized classes is it now
better to make this a parameter?
node blahblah {
class { 'apache':
ssl_package => true,
}
}
I'm just trying to do things "right" the first time.
On Jan 17, 9:59 pm, Nigel Kersten wrote:
> On Tue, Jan 17, 2012 at 9:33 PM, Ryan Bowlby wrote:
> > Thanks for the great replies Nigel. As a person currently rolling out
> > Puppet into production I'm stricken with doubt about how to best
> > represent variables in a module. It would seem to me that I need to:
>
> > 1. set default values in params.pp (based on facts, yadda yadda)
> > 2. allow those values to be overridden by global namespace variables
> > (for enc support)
> > 3. further allow parametrized class declarations to take precedence
> > over 1 and 2
>
> > Can you point me to a module that does this? Alternatively, can you
> > make a recommendation for module best practices going forward.
>
> Have you looked at Hiera yet Ryan? An awful lot of this is baked into it,
> and you may find you don't need to set these at the ENC level.
>
> --
> Nigel Kersten
> Product Manager, Puppet Labs
--
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] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
Thanks for the great replies Nigel. As a person currently rolling out
Puppet into production I'm stricken with doubt about how to best
represent variables in a module. It would seem to me that I need to:
1. set default values in params.pp (based on facts, yadda yadda)
2. allow those values to be overridden by global namespace variables
(for enc support)
3. further allow parametrized class declarations to take precedence
over 1 and 2
Can you point me to a module that does this? Alternatively, can you
make a recommendation for module best practices going forward.
Thanks,
Ryan Bowlby
On Jan 16, 9:31 am, Nigel Kersten wrote:
> On Mon, Jan 16, 2012 at 7:23 AM, Alessandro Franceschi wrote:
>
> > On Sunday, January 15, 2012 9:30:02 PM UTC+1, Nigel Kersten wrote:
>
> >> So here's the rough idea we have in place.
>
> > Let me contextualize: What you suggest here is what may be introduced in
> > 2.8 , when Hiera will be integrated into Puppet?
>
> Yes, but "Telly", not "2.8".
>
> We may use Telly to fully adopt Semantic Versioning (http://semver.org)
> and take this opportunity to reset to "3.0.0" instead of "2.8".
>
>
>
>
>
>
>
>
>
>
>
> >> Parameterized class lookups are automatically consulted in a Hiera
> >> backend.
>
> >> The lookup order would be as follows:
>
> >> 1. directly supplied value in the declaration of the class:
> >> class { "foo": param => "value" }
>
> >> 2. Hiera backend
>
> >> 3. Default value supplied in the definition of the class:
> >> class foo ($param = "value") { ... }
>
> >> This would happen automatically, without requiring the use of a hiera()
> >> like function in the class definition.
>
> > +1
> > I like the fact that this is transparent... if you have an Hiera backend
> > then it's used, if not (or if you use an older Puppet version), normal
> > behavior is followed.
>
> Yep.
>
>
>
>
>
>
>
>
>
>
>
> > It's clear that we need to have a way for module authors to specify values
> >> in the definition of the class.
>
> >> Is this satisfied well by having the values in the manifests themselves
> >> as in (3) above?
>
> > Well a simple class foo ($param = "value") { ... } might not be enough,
> > some logic (for example a different value for different operating systems)
> > to give defaults values might be needed (back to params.pp ...)
>
> >> Or should we be encouraging authors to put a Hiera-style backend inside
> >> their modules and have that be consulted for default values?
>
> > For me is saner to leave to puppet dsl the management of the values to
> > attribute to these internal variables.
> > It's how we always have done it and, for me, it works.
>
> But this is really because there has been no other option right? It's never
> really been easy for module authors to ship default data values inside
> modules, but not in manifests.
>
> I agree it works, but I'd like us to think about whether we can improve it.
>
>
>
> >> I'm not particularly fond of the work we're making people do around
> >> polluting the global namespace with class-specific data.
> >> That's something I think we should probably remove entirely, but open to
> >> suggestions.
>
> > -1 if I understood well
> > If you mean that you would remove the possibility to define top scope
> > variables with custom names (ie things like ::monitor = true but also
> > ::monitor_openssh = true) please let me know when and how this could happen.
>
> No no no.
>
> I more meant that we've had a whole lot of clustered behavior that has
> meant we've forced people to use global namespace variables in say ENCs to
> pass down to modules.
>
> Users and authors shouldn't *have* to do that, and I'd like to make sure
> we're giving people better options than always having to put everything in
> top scope.
>
> > As a user I'm not so fond of radical changes in the Puppet code that make
> > unusable manifests made for earlier Puppet versions (hint: dynamic
> > variables scoping no more possible in 2.8: I understand that they were a
> > source of various problems, but that was just for users misuse due
> > eventually to not clear enough directives/documentation/best practices).
> > I understand that this is done for a "better future" and that
> > retrocompatibility should not be a dogma, but... well... when I write some
> > Puppet code I hope it's going to work for some years...
>
> I'd argue that the dynamic variable scoping resulted in quite fundamental
> problems, but yes, there's totally a balancing act here between progress
> and compatibility.
--
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] params.pp class with parametrized class support?
If I wanted to allow all the variables normally set within params.pp to also be assigned as class parameters or as global variables how would I do this? I still want all the variables to be initially set to defaults within the params.pp class but allow for them to be overridden at the node level. Does this make sense? Anyone have examples? Thanks! -- 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] delayed final state??
I have a somewhat abstract best practice question. In some instances fully applying a node's puppet catalog results in that node interacting with production infrastructure. Sometimes you want to provision a new host and have it apply it's puppet catalog but not yet integrate into the production environment. What methods have people taken to delay the final production state of a host without disabling puppet entirely? Also, any terminology I should be aware of? Example: host provisioned -> initial puppet apply -> system and services configured -> waiting for prod deployment -> deployed -- 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] certificate sync methods?
Hi All, We are going to setup two puppet masters, each will include the full stack of services. Apache as the frontend on both load balancing to the backend services on both. We will be using keepalived and VIP whose A record is puppet.domain. We would like to have the CA in active/active on the two servers. The question then is what is the best method for synchronizing certs between these hosts bi-directionally? My first thought was doing something with inotify but then there is also unison. While we may end up doing as Pro Puppet suggests and having only one be active and the other CA a hot standby, it would still be best to sync bi-directionally. What are others doing? -Ryan -- 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.
