Making some headway, I now have a work-around but would like to know
the real reason since my work around involves modifying the Puppet
code.
Here is the issue in: /usr/local/lib/ruby/site_ruby/1.8/puppet/util.rb
# The idea here is to avoid IO#read whenever possible.
output_file="/dev/null"
More info. It appears it has to do with the Ruby I compiled. I am
running RHE5 which only comes with Ruby 1.8.5. Since I was
experiencing issues with Store Configs I wanted to update to 1.8.7 so
I could use the latest ActiveRecord, etc. Therefore I download the
Ruby 1.8.7 source and compile and ins
I have some more info.
notice: Starting Puppet master version 2.6.5
info: mount[files]: allowing * access
debug: No modules mount given; autocreating with default permissions
debug: No plugins mount given; autocreating with default permissions
debug: Finishing transaction 23799637825120
info: acce
Yes. The file is executable by everyone. Plus this worked prior to
installing Ruby 1.8.7 and Puppet 2.6.4.
On Feb 28, 3:40 pm, Nan Liu wrote:
> On Mon, Feb 28, 2011 at 3:36 PM, cyrus wrote:
> > I recently moved to Puppet 2.6.4. Prior to this I was using the
> > available RPMS for RHEL which were
On Mon, Jun 7, 2010 at 3:02 PM, Alan Barrett wrote:
> On Sun, 06 Jun 2010, Nicolas Szalay wrote:
>> - "Douglas Garstang" a =??crit :
>> | I was just doing a little research on the best way to switch over to
>> | external nodes. It seems like you can't use a combination of the two
>> | systems
On Sun, 06 Jun 2010, Nicolas Szalay wrote:
> - "Douglas Garstang" a =??crit :
> | I was just doing a little research on the best way to switch over to
> | external nodes. It seems like you can't use a combination of the two
> | systems. Apparently if the external node tool can't find an extern
On Sun, 06 Jun 2010, Ashley Penney wrote:
> This is currently killing me too. I also heavily used definitions in
> nodes for things that didn't really seem to belong in modules (one
> offs, mount points for admins to rummage around on the command line,
> the odd tweak here and there) and the inabi
On Sun, 06 Jun 2010, Douglas Garstang wrote:
> I was just doing a little research on the best way to switch over to
> external nodes. It seems like you can't use a combination of the two
> systems.
I assume that "the two systems" means (1) an external node classifier,
and (2) node {...} definition
Am 06.06.2010 09:53, schrieb Douglas Garstang:
Just how is that going to help? If you define a default external node,
the error will go away, but since your internal node is now defined as
a default external node that does nothing, any future changes to the
internal nodes until they are cut over
On Sun, Jun 6, 2010 at 3:53 AM, Douglas Garstang wrote:
>
> I was just doing a little research on the best way to switch over to
> external nodes. It seems like you can't use a combination of the two
> systems. Apparently if the external node tool can't find an external
> node (because it hasn't b
Hello,
- "Douglas Garstang" a écrit :
| I was just doing a little research on the best way to switch over to
| external nodes. It seems like you can't use a combination of the two
| systems. Apparently if the external node tool can't find an external
| node (because it hasn't been cut over ye
On Sat, Jun 5, 2010 at 11:53 PM, Douglas Garstang
wrote:
> Can someone point me to some good examples of external node use? The
> documentation is pretty sparse.
>
> We used to pass a bunch of settings back to our modules from
> definitions on the node manifests. Since external nodes don't support
On Thu, May 20, 2010 at 3:31 PM, Paul Lathrop wrote:
> In this situation, the problem you need to address isn't Puppet, it's
> your infrastructure. The infrastructure you describe is going to be
> nuts to manage no matter what set of tools you are trying to use. It
> doesn't make the tools deficie
In this situation, the problem you need to address isn't Puppet, it's
your infrastructure. The infrastructure you describe is going to be
nuts to manage no matter what set of tools you are trying to use. It
doesn't make the tools deficient.
Basically, if you build your house on a swamp, don't comp
Douglas Garstang writes:
> > classes: [ ]
> > parameters: { }
> >
> > So if you need different Apache versions on two different nodes, your
> > node classifier could supply this for node1:
> >
> > classes: [ apache-server ]
> > parameters: { apache_version=2.0.63 }
> >
> > and this for
On Thu, May 20, 2010 at 2:18 PM, Steven VanDevender wrote:
> Douglas Garstang writes:
> > On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop
> wrote:
> > > You are getting a bunch of misguided answers to this. I'm also
> > > perplexed by your assertion that external nodes requires you to write
>
Douglas Garstang writes:
> On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop wrote:
> > You are getting a bunch of misguided answers to this. I'm also
> > perplexed by your assertion that external nodes requires you to write
> > custom scripts to parse node manifests.
> >
> > No, you cannot put
On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop wrote:
> You are getting a bunch of misguided answers to this. I'm also
> perplexed by your assertion that external nodes requires you to write
> custom scripts to parse node manifests.
>
> No, you cannot put resources directly into nodes when you are
According to experience what's the pros/cons of those methods to store the
nodes?
Like ldap, DB, a library/framework like clusto/puppetdashboard/foreman etc.
Thanks
On Sat, May 15, 2010 at 5:22 PM, Silviu Paragina wrote:
> On 15.05.2010 00:30, Baker, Luke Jefferson wrote:
>
>> Speaking of exte
On 15.05.2010 00:30, Baker, Luke Jefferson wrote:
Speaking of external nodes..
Any decent tutorials out there for someone that has no idea where to start? ;)
External nodes are a way of looking up classes and vars to be applied to
a node via an external application.
http://docs.puppetlabs.c
On 15.05.2010 00:30, Baker, Luke Jefferson wrote:
Speaking of external nodes..
Any decent tutorials out there for someone that has no idea where to start? ;)
To my last e-mail. Correction extlookup does not do external node
lookup. :) It's a puppet function sorry about the confussion.
On 5/14/2010 10:38 PM, Paul Lathrop wrote:
No, you cannot put resources directly into nodes when you are using
external nodes. In practice, this hasn't mattered; you wrap your
resources in a class, done.
Exactly. The most straght-forward way to do this is to s/node/class/ and
include $fqdn via
Users] Re: External Nodes
> What you gain is truly node-scoped variables (AWESOME). Contrary to
> Ken's assertion about global variables, instead you have your external
> node script place variables into the output YAML; these variables are
> then available to all the classes a
> What you gain is truly node-scoped variables (AWESOME). Contrary to
> Ken's assertion about global variables, instead you have your external
> node script place variables into the output YAML; these variables are
> then available to all the classes and resources that apply to that
> node.
I apol
You are getting a bunch of misguided answers to this. I'm also
perplexed by your assertion that external nodes requires you to write
custom scripts to parse node manifests.
No, you cannot put resources directly into nodes when you are using
external nodes. In practice, this hasn't mattered; you wr
> and so on. For these scripts I need to do a lot of reading and writing
> of the nodes. For example, to update the software version, a script
> would check the node out of svn, modify the version_core attribute,
> comit it back in with a comment saying exactly what it did, and then
> trigger a pup
- "Douglas Garstang" wrote:
> On Thu, May 13, 2010 at 9:53 AM, Ken wrote:
> > Yes your write - you can only really do the equiv of:
> >
> > node foo {
> > $bar = "bleah"
> > include some_class
> > }
> >
> > No resources. So really your left using a swarm of global vars that
> > can passed
On Thu, May 13, 2010 at 9:53 AM, Ken wrote:
> Yes your write - you can only really do the equiv of:
>
> node foo {
> $bar = "bleah"
> include some_class
> }
>
> No resources. So really your left using a swarm of global vars that
> can passed down to the resources you have show above which are st
Yes your write - you can only really do the equiv of:
node foo {
$bar = "bleah"
include some_class
}
No resources. So really your left using a swarm of global vars that
can passed down to the resources you have show above which are stored
in a class. So something like:
node foo {
$software
On Thu, May 13, 2010 at 9:08 AM, Douglas Garstang
wrote:
> From the puppet documentation at
> http://docs.puppetlabs.com/guides/external_nodes.html:
>
> "External nodes can’t specify resources of any kind - they can only
> specify class membership, environments and attributes. Those classes
> can
additionally, it can avoid problems with variable scoping, defining the
right variables per host instead of using inheritance..
my 1cent.
Ohad
On Sun, Oct 4, 2009 at 9:16 PM, Andrew Shafer wrote:
>
>
> I've got a question post puppet camp. I'm not sure I understand the
>> benefit of external n
I've got a question post puppet camp. I'm not sure I understand the
> benefit of external nodes and storeconfigs.
>
> If you put node data or other puppet configuration in external
> sources, it would seem to me that:
>
> 1. Your complicating your configuration by essentially putting your
> puppet
We are in the process of deploying puppet for ~2500 servers. The main
reason why we even went with puppet was due to the fact that it supports
external node lookups. As the previous poster mentioned, defining node
configs for even 100 machines is already painful, not to mention several
thousan
I'm not necessarily selling it. Use whatever works best for you. But consider:
- scale: if you have 20 nodes, I don't think its a big deal to maintain all the
nodes in a .pp file, but what if you have 200, or 2000 ( or more ). Having the
ability to group nodes in some external tool ( ldap, s
Hi Matt,
Thats a bit odd, when using external nodes you shouldn't need any node
definitions within your manifests.
any chance you have some leftover nodes definitions?
Ohad
On Mon, Sep 28, 2009 at 5:52 PM, Matt wrote:
>
> Update:-
>
> I added a default node to a manifest file, just -
>
> node
Matt schrieb:
> Hi all,
>
> I've hit a wall trying to get external nodes working on our production
> puppet master. I'm using the foreman to supply the external nodes
> information and have it all working in the dev environment.
>
> manually -
> # su - puppet
> -bash-3.2$ cd /etc/puppet
> -bash-
You're right, I removed all /var/lib/puppet/* from the client except
the ssl directory and the next poll worked.
Still requires me to have a default node though on the puppetmaster.
Should the client really cache bad catalogs?
2009/9/28 Nicolas Szalay :
> Le lundi 28 septembre 2009 à 10:52 +010
Le lundi 28 septembre 2009 à 10:52 +0100, Matt a écrit :
> Update:-
>
> I added a default node to a manifest file, just -
>
> node default {
> include env
> }
>
> This appears to have made the puppetmasterd kick in to action and
> compile the catalog from the foreman for that node. i.e. I se
Update:-
I added a default node to a manifest file, just -
node default {
include env
}
This appears to have made the puppetmasterd kick in to action and
compile the catalog from the foreman for that node. i.e. I see
puppetmasterd compile all the correct classes for the node and not
just th
Steven VanDevender wrote:
> However, what I'd really prefer to do is use the external node
> classifier only to supply the setting of the Puppet "environment"
> variable, and leave all of the class membership details in our existing
> nodes.pp (included from site.pp).
Just turn all your nodes in
On Sat, Aug 8, 2009 at 3:20 AM, Steven VanDevender wrote:
>
> However, what I'd really prefer to do is use the external node
> classifier only to supply the setting of the Puppet "environment"
> variable, and leave all of the class membership details in our existing
> nodes.pp (included from site.
41 matches
Mail list logo
