Re: [Puppet Users] External nodes in different dirs.

[Daniel Pittman]

On Sat, Dec 31, 2011 at 00:01, Douglas Garstang  wrote:
> On Fri, Dec 30, 2011 at 1:58 PM, Aaron Grewell  
> wrote:
>> Well isn't that handy!
>
> Yeah that's great except that these YAML files are littered with
> Ruby objects which makes them pretty much impossible to reach with any
> other programming langauge, like python.

Other than the object tags, and the Ruby symbol tags, none of the
content is difficult to represent in another language.  We generally
advise you disable the "object mapping" part of the YAML parser, and
things should more or less just work™.

Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

-- 
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.

Re: [Puppet Users] External nodes in different dirs.

[Douglas Garstang]

On Fri, Dec 30, 2011 at 1:58 PM, Aaron Grewell  wrote:
> Well isn't that handy!

Yeah that's great except that these YAML files are littered with
Ruby objects which makes them pretty much impossible to reach with any
other programming langauge, like python.

Doug.

-- 
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.

Re: [Puppet Users] External nodes in different dirs.

[Aaron Grewell]

Well isn't that handy!

On Fri, Dec 30, 2011 at 12:57 PM, R.I.Pienaar  wrote:
>
>
> - Original Message -
>> Thanks.
>>
>> On Fri, Dec 30, 2011 at 12:51 PM, Aaron Grewell
>>  wrote:
>> > You get only the host name from the agent.  When I did this using a
>> > YAML-based ENC I checked each environment directory in turn for a
>> > file matching the hostname and just made sure to only create it in the
>> > proper place.
>
> before calling your ENC it will write out the YAML files for each node in
> the vardir, so you could load that up and get the current facts - including
> the environment fact
>
>
>> >
>> > On Fri, Dec 30, 2011 at 12:29 PM, Douglas Garstang
>> >  wrote:
>> >> I'm using external nodes. I wanted to break up the node files into
>> >> directories based on say, the environment, dev, prod etc. Does
>> >> puppet
>> >> set anything besides the host name when it calls the external node
>> >> script, such as the environment? Are these variables available as
>> >> environment variables ?
>> >>
>> >> Doug
>> >>
>> >> --
>> >> 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.
>> >>
>> >
>> > --
>> > 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.
>> >
>>
>>
>>
>> --
>> Regards,
>>
>> Douglas Garstang
>> http://www.linkedin.com/in/garstang
>> Email: doug.garst...@gmail.com
>> Cell: +1-805-340-5627
>>
>> --
>> 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.
>>
>>
>
> --
> R.I.Pienaar
>
> --
> 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.
>

-- 
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.

Re: [Puppet Users] External nodes in different dirs.

[R.I.Pienaar]

- Original Message -
> Thanks.
> 
> On Fri, Dec 30, 2011 at 12:51 PM, Aaron Grewell
>  wrote:
> > You get only the host name from the agent.  When I did this using a
> > YAML-based ENC I checked each environment directory in turn for a
> > file matching the hostname and just made sure to only create it in the
> > proper place.

before calling your ENC it will write out the YAML files for each node in 
the vardir, so you could load that up and get the current facts - including
the environment fact


> >
> > On Fri, Dec 30, 2011 at 12:29 PM, Douglas Garstang
> >  wrote:
> >> I'm using external nodes. I wanted to break up the node files into
> >> directories based on say, the environment, dev, prod etc. Does
> >> puppet
> >> set anything besides the host name when it calls the external node
> >> script, such as the environment? Are these variables available as
> >> environment variables ?
> >>
> >> Doug
> >>
> >> --
> >> 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.
> >>
> >
> > --
> > 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.
> >
> 
> 
> 
> --
> Regards,
> 
> Douglas Garstang
> http://www.linkedin.com/in/garstang
> Email: doug.garst...@gmail.com
> Cell: +1-805-340-5627
> 
> --
> 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.
> 
> 

-- 
R.I.Pienaar

-- 
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.

Re: [Puppet Users] External nodes in different dirs.

[Douglas Garstang]

Thanks.

On Fri, Dec 30, 2011 at 12:51 PM, Aaron Grewell  wrote:
> You get only the host name from the agent.  When I did this using a
> YAML-based ENC I checked each environment directory in turn for a file
> matching the hostname and just made sure to only create it in the
> proper place.
>
> On Fri, Dec 30, 2011 at 12:29 PM, Douglas Garstang
>  wrote:
>> I'm using external nodes. I wanted to break up the node files into
>> directories based on say, the environment, dev, prod etc. Does puppet
>> set anything besides the host name when it calls the external node
>> script, such as the environment? Are these variables available as
>> environment variables ?
>>
>> Doug
>>
>> --
>> 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.
>>
>
> --
> 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.
>



-- 
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627

-- 
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.

Re: [Puppet Users] External nodes in different dirs.

[Aaron Grewell]

You get only the host name from the agent.  When I did this using a
YAML-based ENC I checked each environment directory in turn for a file
matching the hostname and just made sure to only create it in the
proper place.

On Fri, Dec 30, 2011 at 12:29 PM, Douglas Garstang
 wrote:
> I'm using external nodes. I wanted to break up the node files into
> directories based on say, the environment, dev, prod etc. Does puppet
> set anything besides the host name when it calls the external node
> script, such as the environment? Are these variables available as
> environment variables ?
>
> Doug
>
> --
> 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.
>

-- 
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] External nodes in different dirs.

[Douglas Garstang]

I'm using external nodes. I wanted to break up the node files into
directories based on say, the environment, dev, prod etc. Does puppet
set anything besides the host name when it calls the external node
script, such as the environment? Are these variables available as
environment variables ?

Doug

-- 
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.

Re: [Puppet Users] External Nodes - Puppet 2.6.4

[Nan Liu]

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 2.6.3. The reason I moved to the
> source 2.6.4 is that I wanted to update to Ruby 1.8.7 to see if that
> corrected the errors I was getting when trying to use Store Configs.
>
> Anyways, I compiled Ruby 1.8.7 from source into /usr/local/bin. I then
> installed Facter and Puppet into the same prefix.
>
> However now I can not get external nodes to work. On the client it
> gives:
>
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find node 'lv00052p.encana.com'; cannot compile
>
> From the log I see:
>
> Feb 28 15:29:55 ls1313p puppet-master[20112]: Executing '/usr/bin/
> cobbler-ext-nodes lv00052p.encana.com'
> Feb 28 15:29:55 ls1313p puppet-master[20112]: Failed to find
> lv00052p.encana.com via exec: Execution of '/usr/bin/cobbler-ext-nodes
> lv00052p.encana.com' returned 1:
> Feb 28 15:29:55 ls1313p puppet-master[20112]: Could not find node
> 'lv00052p.encana.com'; cannot compile
>
> However, if I run
>
> /usr/bin/cobbler-ext-nodes lv00052p.encana.com

Can you execute this as the puppet user? If you run passenger, the
owner of the config.ru file?

Thanks,

Nan

> By hand it returns error code 0 and the following results:
>
> classes: [dev_wes]
> parameters: {env: dev, from_cobbler: 1, media_path: /ks/dist/dev-ks-
> rhel-x86_64-server-5-u5,
>  org: 1, passwd_mode: compat, redhat_management_type: 'off', stype:
> wes}
>
> This all worked prior to upgrading to 2.6.4.
>
> Also, my config is:
>
>
> [main]
>    # The Puppet log directory.
>    # The default value is '$vardir/log'.
>    logdir = /var/log/puppet
>
>    # Where Puppet PID files are kept.
>    # The default value is '$vardir/run'.
>    rundir = /var/run/puppet
>
>    # Where SSL certificates are kept.
>    # The default value is '$confdir/ssl'.
>    ssldir = $vardir/ssl
>
> [agent]
>    # The file in which puppetd stores a list of the classes
>    # associated with the retrieved configuratiion.  Can be loaded in
>    # the separate ``puppet`` executable using the ``--loadclasses``
>    # option.
>    # The default value is '$confdir/classes.txt'.
>    classfile = $vardir/classes.txt
>
>    # Where puppetd caches the local configuration.  An
>    # extension indicating the cache format is added automatically.
>    # The default value is '$confdir/localconfig'.
>    localconfig = $vardir/localconfig
>
> [master]
>    # The main Puppet configuration directory. The default for this
>    # parameter is calculated based on the user.
>    confdir = /puppet/production
>
>    # Where Puppet stores dynamic and growing data. The default for
> this
>    # parameter is calculated specially, like confdir.
>    # The default value is '/var/lib/puppet'.
>    vardir = /var/lib/puppet
>
>    # external node lookup via cobbler
>    external_nodes = /usr/bin/cobbler-ext-nodes
>    node_terminus = exec
>
>    reports = tagmail
>    tagmap = $confdir/tagmail.conf
>
>    # enable store configs
>    #storeconfigs = true
>    # use Postgres for store configs
>    #dbadapter = postgresql
>    #dbuser = puppet
>    #dbpassword = puppet
>    #dbserver = ls00034p
>
> [development]
>        manifest = $confdir/manifests/dev_site.pp
>
> [tqa]
>        manifest = $confdir/manifests/tqa_site.pp
>
> Any help would be appreciated.
>
> 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.
>
>

-- 
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] External Nodes - Puppet 2.6.4

[cyrus]

I recently moved to Puppet 2.6.4. Prior to this I was using the
available RPMS for RHEL which were 2.6.3. The reason I moved to the
source 2.6.4 is that I wanted to update to Ruby 1.8.7 to see if that
corrected the errors I was getting when trying to use Store Configs.

Anyways, I compiled Ruby 1.8.7 from source into /usr/local/bin. I then
installed Facter and Puppet into the same prefix.

However now I can not get external nodes to work. On the client it
gives:

err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find node 'lv00052p.encana.com'; cannot compile

>From the log I see:

Feb 28 15:29:55 ls1313p puppet-master[20112]: Executing '/usr/bin/
cobbler-ext-nodes lv00052p.encana.com'
Feb 28 15:29:55 ls1313p puppet-master[20112]: Failed to find
lv00052p.encana.com via exec: Execution of '/usr/bin/cobbler-ext-nodes
lv00052p.encana.com' returned 1:
Feb 28 15:29:55 ls1313p puppet-master[20112]: Could not find node
'lv00052p.encana.com'; cannot compile

However, if I run

/usr/bin/cobbler-ext-nodes lv00052p.encana.com

By hand it returns error code 0 and the following results:

classes: [dev_wes]
parameters: {env: dev, from_cobbler: 1, media_path: /ks/dist/dev-ks-
rhel-x86_64-server-5-u5,
  org: 1, passwd_mode: compat, redhat_management_type: 'off', stype:
wes}

This all worked prior to upgrading to 2.6.4.

Also, my config is:


[main]
# The Puppet log directory.
# The default value is '$vardir/log'.
logdir = /var/log/puppet

# Where Puppet PID files are kept.
# The default value is '$vardir/run'.
rundir = /var/run/puppet

# Where SSL certificates are kept.
# The default value is '$confdir/ssl'.
ssldir = $vardir/ssl

[agent]
# The file in which puppetd stores a list of the classes
# associated with the retrieved configuratiion.  Can be loaded in
# the separate ``puppet`` executable using the ``--loadclasses``
# option.
# The default value is '$confdir/classes.txt'.
classfile = $vardir/classes.txt

# Where puppetd caches the local configuration.  An
# extension indicating the cache format is added automatically.
# The default value is '$confdir/localconfig'.
localconfig = $vardir/localconfig

[master]
# The main Puppet configuration directory. The default for this
# parameter is calculated based on the user.
confdir = /puppet/production

# Where Puppet stores dynamic and growing data. The default for
this
# parameter is calculated specially, like confdir.
# The default value is '/var/lib/puppet'.
vardir = /var/lib/puppet

# external node lookup via cobbler
external_nodes = /usr/bin/cobbler-ext-nodes
node_terminus = exec

reports = tagmail
tagmap = $confdir/tagmail.conf

# enable store configs
#storeconfigs = true
# use Postgres for store configs
#dbadapter = postgresql
#dbuser = puppet
#dbpassword = puppet
#dbserver = ls00034p

[development]
manifest = $confdir/manifests/dev_site.pp

[tqa]
manifest = $confdir/manifests/tqa_site.pp

Any help would be appreciated.

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.

Re: [Puppet Users] External Nodes using Curly Braces

[Douglas Garstang]

That did it. Thanks Nigel.

On Tue, Aug 3, 2010 at 12:06 PM, Nigel Kersten  wrote:
> On Tue, Aug 3, 2010 at 12:03 PM, Douglas Garstang
>  wrote:
>> The yaml specification says that yaml can either be formatted with
>> indentation, AND/OR with curly braces.
>> Does puppet handle the output from an external node script dumping
>> yaml output with curly braces?
>>
>> The python yaml library's yaml.dump() function seems to mix and match
>> both types.
>
> do you mean the default_flow_style for yaml.dump Douglas? I don't
> remember having any problems with either format when dumping from
> python to be loaded by ruby with either option in the past, but I do
> have default_flow_style=False for my external node script.
>
>
>
>>
>> Doug
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@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.
>>
>>
>
>
>
> --
> nigel
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>



-- 
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes using Curly Braces

[Nigel Kersten]

On Tue, Aug 3, 2010 at 12:03 PM, Douglas Garstang
 wrote:
> The yaml specification says that yaml can either be formatted with
> indentation, AND/OR with curly braces.
> Does puppet handle the output from an external node script dumping
> yaml output with curly braces?
>
> The python yaml library's yaml.dump() function seems to mix and match
> both types.

do you mean the default_flow_style for yaml.dump Douglas? I don't
remember having any problems with either format when dumping from
python to be loaded by ruby with either option in the past, but I do
have default_flow_style=False for my external node script.



>
> Doug
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>



-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes using Curly Braces

[Douglas Garstang]

The yaml specification says that yaml can either be formatted with
indentation, AND/OR with curly braces.
Does puppet handle the output from an external node script dumping
yaml output with curly braces?

The python yaml library's yaml.dump() function seems to mix and match
both types.

Doug

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Kenneth Holter]

Yay, I got it working now. Your reply lead me to bug #3514, so I
decided to extraced a fresh puppet.conf from the puppet-server RPM,
and add my modifications to it (no copy and paste). Now it works, so
it's possible that it was a CR/LF ending issue (if so I must have
pasted code from outlook or something).

Thanks for your help!


- Kenneth

On Tue, Jul 13, 2010 at 4:49 PM, Alan Barrett  wrote:
> On Tue, 13 Jul 2010, Kenneth Holter wrote:
>> So it looks like puppetmaster simply bypass the whole puppet.conf file
>> (or at least the "main" and "puppetmasterd" stanzas).
>
> I think there was a bug report about puppet.conf being ignored
> if it contained errors; but I can't find the bug report, and
> I don't see any errors in your config.
>
> --apb (Alan Barrett)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Alan Barrett]

On Tue, 13 Jul 2010, Kenneth Holter wrote:
> So it looks like puppetmaster simply bypass the whole puppet.conf file
> (or at least the "main" and "puppetmasterd" stanzas).

I think there was a bug report about puppet.conf being ignored
if it contained errors; but I can't find the bug report, and
I don't see any errors in your config.

--apb (Alan Barrett)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Kenneth Holter]

After investigating further I've found this: When commenting out the
environment stanza the puppet.conf file (in my case the "testing"
environment), everything seems ok wrt (amongs others) these variables:

[r...@puppetmaster tmp]# puppetmasterd --no-daemonize --configprint
all|egrep -i 'external|vardir|logdir|rundir'
external_nodes = /usr/bin/python /etc/puppet/tools/extlookup-satellite.py
logdir = /var/log/puppet
rundir = /var/run/puppet
vardir = /var/lib/puppet

When uncommenting the environement stanza, not only does the
"external_nodes" variable change, but also the variables defined in
the "main" stanza in puppet.conf:

[r...@puppetmaster tmp]# puppetmasterd --no-daemonize --configprint
all|egrep -i 'external|vardir|logdir|rundir'
external_nodes = none
logdir = /var/puppet/log
rundir = /var/puppet/run
vardir = /var/puppet

So it looks like puppetmaster simply bypass the whole puppet.conf file
(or at least the "main" and "puppetmasterd" stanzas).

Any clues as to why the puppetmaster would skip the puppet.conf file?
It seems possible that it performs some sort of syntax or semtatics
check of some kind before it decides to bypass the file and go with
other (default?) values, but if so I have noe clue on where the bug
might be.


- Kenneth




On Tue, Jul 13, 2010 at 9:55 AM, Kenneth Holter  wrote:

> I've pasted the output of the suggested commands here:
> http://pastebin.com/npd6akwY
>
> I noticed that configprint shows that "extrenal_nodes" gets set to
> "none" as soon as I uncomment one of the environments (in this case
> "testing"). Is there any dependencies or something that the
> puppetmaster checks for with regards to environments, which may
> explain this behavior?
>
> Btw, I verified that the client picks up the correct environment when
> using the "--environment=" flag. And also, I restart the
> puppetmaster frequently when debugging this, so I don't believe #3580
> bug applies to me.
>
>
> - Kenneth
>
> On Mon, Jul 12, 2010 at 7:40 PM, Nan Liu  wrote:
>> On Jul 12, 2010, at 8:30 AM, Kenneth Holter  wrote:
>>
>> I moved the "environments=testing" from "main" to "puppetmasterd",
>>
>> restarted puppetmaster, and tried another puppet client run. Same
>>
>> results. Even tried without that entry, still don't work.
>>
>> What I meant was
>> [main]
>> ...
>> environment=testing
>>
>> [puppetmasterd]
>> ...
>> environments=production,testing
>>
>> I found a thread indicating that the site.pp file should contain a
>>
>> default node, so I included this in /etc/puppet/manifests/site.pp:
>>
>> -- code start --
>>
>> node default {
>>
>>  info("default node")
>>
>> }
>>
>> -- code end --
>>
>> ..and found that this is being parsed instead of puppetmaster fetching
>>
>> the node information externally via the external nodes script. Any
>>
>> ideas on how to proceed debugging this?
>>
>>
>> I would run "puppetd --configprint environment" to see what's the real
>> configuration after parsing. If it's setting it to the testing
>> environment but not invoking external node, please run "puppetd
>> --configprint all | grep ldap" and forward a copy of the output.
>>
>> If it's a bug, definitely worth looking into and confirming.
>>
>> Thanks,
>>
>> Nan
>>
>> Sent from my iPhone
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@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.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Kenneth Holter]

I've pasted the output of the suggested commands here:
http://pastebin.com/npd6akwY

I noticed that configprint shows that "extrenal_nodes" gets set to
"none" as soon as I uncomment one of the environments (in this case
"testing"). Is there any dependencies or something that the
puppetmaster checks for with regards to environments, which may
explain this behavior?

Btw, I verified that the client picks up the correct environment when
using the "--environment=" flag. And also, I restart the
puppetmaster frequently when debugging this, so I don't believe #3580
bug applies to me.


- Kenneth

On Mon, Jul 12, 2010 at 7:40 PM, Nan Liu  wrote:
> On Jul 12, 2010, at 8:30 AM, Kenneth Holter  wrote:
>
> I moved the "environments=testing" from "main" to "puppetmasterd",
>
> restarted puppetmaster, and tried another puppet client run. Same
>
> results. Even tried without that entry, still don't work.
>
> What I meant was
> [main]
> ...
> environment=testing
>
> [puppetmasterd]
> ...
> environments=production,testing
>
> I found a thread indicating that the site.pp file should contain a
>
> default node, so I included this in /etc/puppet/manifests/site.pp:
>
> -- code start --
>
> node default {
>
>  info("default node")
>
> }
>
> -- code end --
>
> ..and found that this is being parsed instead of puppetmaster fetching
>
> the node information externally via the external nodes script. Any
>
> ideas on how to proceed debugging this?
>
>
> I would run "puppetd --configprint environment" to see what's the real
> configuration after parsing. If it's setting it to the testing
> environment but not invoking external node, please run "puppetd
> --configprint all | grep ldap" and forward a copy of the output.
>
> If it's a bug, definitely worth looking into and confirming.
>
> Thanks,
>
> Nan
>
> Sent from my iPhone
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Nan Liu]

On Jul 12, 2010, at 8:30 AM, Kenneth Holter  wrote:

I moved the "environments=testing" from "main" to "puppetmasterd",

restarted puppetmaster, and tried another puppet client run. Same

results. Even tried without that entry, still don't work.


What I meant was
[main]
...
environment=testing

[puppetmasterd]
...
environments=production,testing

I found a thread indicating that the site.pp file should contain a

default node, so I included this in /etc/puppet/manifests/site.pp:


-- code start --

node default {

 info("default node")

}

-- code end --


..and found that this is being parsed instead of puppetmaster fetching

the node information externally via the external nodes script. Any

ideas on how to proceed debugging this?



I would run "puppetd --configprint environment" to see what's the real
configuration after parsing. If it's setting it to the testing
environment but not invoking external node, please run "puppetd
--configprint all | grep ldap" and forward a copy of the output.

If it's a bug, definitely worth looking into and confirming.

Thanks,

Nan

Sent from my iPhone

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Alan Barrett]

On Mon, 12 Jul 2010, Kenneth Holter wrote:
> I'm trying to set up puppetmaster with external node classifier and
> multiple environments, and have found that the external nodes script
> is only run if I don't define any environments. Once I add an
> environment to the /etc/puppet/puppet.conf file, the external nodes
> script is no longer run.

You might be encountering bug #3580 (if the same client connects
multiple times, then puppetmasterd runs the node classifier only once),
or an issue related to filetimeout (by default, edits are noticed only
15 seconds later), or an interaction between the two.  Kill and restart
puppetmasterd to be sure you are testing the changes you think you are
testing.

--apb (Alan Barrett)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Kenneth Holter]

Thanks for your reply.


This is the line I've been running on the client side:

-- code start --
puppetd --server puppetmaster.example.local --environment=testing
--verbose --no-daemonize
-- code end --

I moved the "environments=testing" from "main" to "puppetmasterd",
restarted puppetmaster, and tried another puppet client run. Same
results. Even tried without that entry, still don't work.

I found a thread indicating that the site.pp file should contain a
default node, so I included this in /etc/puppet/manifests/site.pp:

-- code start --
node default {
   info("default node")
}
-- code end --

..and found that this is being parsed instead of puppetmaster fetching
the node information externally via the external nodes script. Any
ideas on how to proceed debugging this?


- Kenneth



On Mon, Jul 12, 2010 at 2:27 PM, Nan Liu  wrote:
> On Mon, Jul 12, 2010 at 7:41 AM, Kenneth Holter 
> wrote:
>>
>> In my current setup I have the following puppet.conf file:
>>
>> -- code start --
>> [main]
>
> ...
>>
>>    environments = testing
>
> Looking at the documentation and environments default thread
> (http://groups.google.com/group/puppet-users/browse_thread/thread/f97bfad1e46c83c4?hl=en#),
> this line should be environment = testing to specify the default
> environment. The setting "environments=production,testing,development"
> belongs in the puppetmasterd section which controls which environments are
> allowed.
>
>> [testing]
>>    manifest = /srv/puppet/testing/site.pp
>>    modulepath = /srv/puppet/testing/modules
>> -- code start --
>>
>> If I comment out the last three lines, the external nodes script is
>> run (I've verified this by running "stat "
>> before and after issuing a client request).
>>
>> I'm kind of stuck, so advice on how to debug this will be greatly
>> apprecited.
>
>
> We can try to tackle the issue from two sides and be more explicit about the
> environment, either check via puppetd --environment=testing, or in the YAML
> file produced by the external node classifier, ensure it return a line
> containing:
>
> environment: testing
>
> Thanks,
>
> Nan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Nan Liu]

On Mon, Jul 12, 2010 at 7:41 AM, Kenneth Holter wrote:

> In my current setup I have the following puppet.conf file:
>
> -- code start --
> [main]
>
...

>environments = testing
>

Looking at the documentation and environments default thread (
http://groups.google.com/group/puppet-users/browse_thread/thread/f97bfad1e46c83c4?hl=en#),
this line should be environment = testing to specify the default
environment. The setting "environments=production,testing,development"
belongs in the puppetmasterd section which controls which environments are
allowed.

[testing]
>manifest = /srv/puppet/testing/site.pp
>modulepath = /srv/puppet/testing/modules
> -- code start --
>
> If I comment out the last three lines, the external nodes script is
> run (I've verified this by running "stat "
> before and after issuing a client request).
>
> I'm kind of stuck, so advice on how to debug this will be greatly
> apprecited.
>

We can try to tackle the issue from two sides and be more explicit about the
environment, either check via puppetd --environment=testing, or in the YAML
file produced by the external node classifier, ensure it return a line
containing:

environment: testing

Thanks,

Nan

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script does not work with multiple environments

[Kenneth Holter]

Hi all.


I'm trying to set up puppetmaster with external node classifier and
multiple environments, and have found that the external nodes script
is only run if I don't define any environments. Once I add an
environment to the /etc/puppet/puppet.conf file, the external nodes
script is no longer run. In my current setup I have the following
puppet.conf file:

-- code start --
[main]
# Where Puppet stores dynamic and growing data.
# The default value is '/var/puppet'.
vardir = /var/lib/puppet

# The Puppet log directory.
# The default value is '$vardir/log'.
logdir = /var/log/puppet

# Where Puppet PID files are kept.
# The default value is '$vardir/run'.
rundir = /var/run/puppet

# Where SSL certificates are kept.
# The default value is '$confdir/ssl'.
ssldir = $vardir/ssl

environments = testing

[puppetd]
# The file in which puppetd stores a list of the classes
# associated with the retrieved configuratiion.  Can be loaded in
# the separate ``puppet`` executable using the ``--loadclasses``
# option.
# The default value is '$confdir/classes.txt'.
classfile = $vardir/classes.txt

# Where puppetd caches the local configuration.  An
# extension indicating the cache format is added automatically.
# The default value is '$confdir/localconfig'.
localconfig = $vardir/localconfig

[puppetmasterd]
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
certificate_revocation = false

external_nodes = /usr/bin/python /etc/puppet/tools/extlookup-satellite.py
node_terminus = exec

[testing]
manifest = /srv/puppet/testing/site.pp
modulepath = /srv/puppet/testing/modules
-- code start --

If I comment out the last three lines, the external nodes script is
run (I've verified this by running "stat "
before and after issuing a client request).

I'm kind of stuck, so advice on how to debug this will be greatly apprecited.


Best regards,
Kenneth

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes script for fetching info from Red Hat Satellite server

[Kenneth Holter]

Hi all,


does anyone know of any existing scripts for fetching node YAML info
from Red Hat Satellite server? We need to set puppetmaster up to fetch
node info from the satellite server.


Regards,
Kenneth Holter

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Examples

[Rob McBroom]

On Jun 6, 2010, at 2:53 AM, Douglas Garstang wrote:

> We used to pass a bunch of settings back to our modules from
> definitions on the node manifests. Since external nodes don't support
> definitions, I presume these definitions have go get pushed back into
> a module and a class somewhere, and then included in the external
> node. You effectively then include the node's class (where the
> definition are) in the external node. This seems completely
> counter-intuitive to me, and I must have it wrong, so I was hoping to
> see some real world examples.

I won't say there's a correct way to think about this, but I can tell you what 
makes sense to me (and apparently those designing Puppet's architecture).

Don't think about what needs to happen to a node. Think about WHY it needs to 
happen. For instance, don't think “I need httpd on this machine”. Think “This 
machine is a web server” and “Web servers need to have httpd installed” as two 
separate things. This naturally puts all of your nodes into classes. Maybe you 
only have one such server now, but will you always? Do you want to recreate the 
entire configuration when a similar node becomes necessary?

I’m not sure what you plan to use for external nodes, but I use LDAP where 
classes are the primary thing, but you can also set various ‘puppetVars’ on an 
individual node if you really need a one-off configuration.

-- 
Rob McBroom


The magnitude of a problem does not affect its ownership.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Examples

[Douglas Garstang]

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
definitions, I presume these definitions have go get pushed back into
a module and a class somewhere, and then included in the external
node. You effectively then include the node's class (where the
definition are) in the external node. This seems completely
counter-intuitive to me, and I must have it wrong, so I was hoping to
see some real world examples.

Doug

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Joe McDonagh]

What's the state of storedconfigs these days?

Doug.

   
In what sense? I am using it right now for other pieces of 
infrastructure, works pretty nicely but I am not exactly large scale. 
What did you want to accomplish with it?


--
--
Joe McDonagh
Operations Engineer
AIM: YoosingYoonickz
IRC: joe-mac on freenode
"When the going gets weird, the weird turn pro."

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] External nodes Ignore Missing Classes

[Nigel Kersten]

On Thu, May 27, 2010 at 3:25 PM, Douglas Garstang
wrote:

> On Thu, May 27, 2010 at 2:51 PM, Nigel Kersten  wrote:
> >
> >
> > On Thu, May 27, 2010 at 2:47 PM, Douglas Garstang <
> doug.garst...@gmail.com>
> > wrote:
> >>
> >> All,
> >>
> >> I just did a super simple test where I used the simple external nodes
> >> script at http://docs.puppetlabs.com/guides/external_nodes.html.
> >>
> >> I ran it against an existing node (which you have to since I don't see
> >> how you can tell it not to), and there was no errors. I then realised
> >> that even though the classes specified were not available, puppet did
> >> not complain on the client. That's a bit of a problem isn't it?
> >>
> >> If I put an "include foo" in a node manifest, and foo doesn't exist,
> >> puppet will complain. If I put "classes: foo" in an external node
> >> script, and foo doesn't exist, puppet on the client does NOT complain.
> >
> > I actually just noticed this yesterday too. Definitely seems bug worthy,
> at
> > a minimum there should be something notified client-side about it.
>
> Egads. I'd call it a complete deal breaker for external nodes.
>
>
Well that depends. I understand you're not happy about feeling like you've
been  forced into using them, and I'm not defending the functionality at
all, but it may not be a deal breaker for everyone.

I have presubmit hooks such that I can't create externally defined nodes
that refer to classes that don't exist, and have unrecognized log message
collation on my servers, so things like this leap out.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes Ignore Missing Classes

[Douglas Garstang]

On Thu, May 27, 2010 at 2:51 PM, Nigel Kersten  wrote:
>
>
> On Thu, May 27, 2010 at 2:47 PM, Douglas Garstang 
> wrote:
>>
>> All,
>>
>> I just did a super simple test where I used the simple external nodes
>> script at http://docs.puppetlabs.com/guides/external_nodes.html.
>>
>> I ran it against an existing node (which you have to since I don't see
>> how you can tell it not to), and there was no errors. I then realised
>> that even though the classes specified were not available, puppet did
>> not complain on the client. That's a bit of a problem isn't it?
>>
>> If I put an "include foo" in a node manifest, and foo doesn't exist,
>> puppet will complain. If I put "classes: foo" in an external node
>> script, and foo doesn't exist, puppet on the client does NOT complain.
>
> I actually just noticed this yesterday too. Definitely seems bug worthy, at
> a minimum there should be something notified client-side about it.

Egads. I'd call it a complete deal breaker for external nodes.

Doug.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Michael DeHaan]

>
> Aw Jeez... I wonder if someone could, like, document just how that works?
>

:)

I'll file a bug on myself to clean up that section of the doc site.

I'd suspect that returning nothing is an error because it's not YAML,
but I'll have to check.

--Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Douglas Garstang]

On Thu, May 27, 2010 at 2:58 PM, Nigel Kersten  wrote:
>
>
> On Thu, May 27, 2010 at 2:56 PM, Douglas Garstang 
> wrote:
>>
>> On Thu, May 27, 2010 at 2:52 PM, Nigel Kersten  wrote:
>> >
>> >
>> > On Thu, May 27, 2010 at 2:42 PM, Douglas Garstang
>> > 
>> > wrote:
>> >>
>> >> On Thu, May 27, 2010 at 10:34 AM, Michael DeHaan
>> >> 
>> >> wrote:
>> >> > On Thu, May 27, 2010 at 1:23 PM, Douglas Garstang
>> >> >  wrote:
>> >> >> On Thu, May 27, 2010 at 9:55 AM, Nigel Kersten 
>> >> >> wrote:
>> >> >>>
>> >> >>>
>> >> >>> On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang
>> >> >>> 
>> >> >>> wrote:
>> >> 
>> >>  Does switching to external nodes require a forklift approach?
>> >> 
>> >>  The other day, I specified an external node script in puppet.conf,
>> >>  and
>> >>  puppet complained about every single node that wasn't handled by
>> >>  the
>> >>  external script. It would be nice (and more realistic) to be able
>> >>  to
>> >>  cut one node over at a time. Is this possible?
>> >> >>>
>> >> >>> Absolutely.
>> >> >>> My external node script just returns the default config for any
>> >> >>> node
>> >> >>> it
>> >> >>> can't find a specific config for.
>> >> >>
>> >> >> That's not going to work. When the node isn't defined as an external
>> >> >> node, I want it to use the node manifest file, not a default. If I
>> >> >> was
>> >> >> going to start using external nodes, some nodes would be external
>> >> >> and
>> >> >> some nodes would not be external, until they where all converted. It
>> >> >> looks like while this was the case, nothing would work.
>> >> >
>> >> > As I understood things, external nodes is supposed to work as an
>> >> > overlay on top of site.pp
>> >> >
>> >> > Is this not working if you just return an empty list of
>> >> > classes/variables for a node?
>> >> >
>> >> > IIRC this works this way today -- let us know if there's a problem
>> >> > with
>> >> > it.
>> >>
>> >> Sorry, I really don't follow you. The external node is specified in
>> >> the puppet.conf file. Doesn't that mean ALL nodes are run through
>> >> it???
>> >
>> > I believe what Michael is saying is rather than returning *nothing*, you
>> > should return an empty node definition with empty parameters/classes.
>>
>> If the external node script returns an empty node, that might be fine
>> for making sure the client runs cleanly, and doesn't break anything
>> that's already deployed. However, it will also mean that any changes
>> made to the node manifest file will be ignored. That seems kinda
>> bad...
>
> No, I think he's saying that if you return an empty node definition, the
> node manifest file will be consulted.
> The external node classifier just gets consulted first.
> This doesn't really seem ideal. It seems like if an external node classifier
> doesn't actually return anything, the manifest should be consulted.

Aw Jeez... I wonder if someone could, like, document just how that works?

Doug.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Nigel Kersten]

On Thu, May 27, 2010 at 2:56 PM, Douglas Garstang
wrote:

> On Thu, May 27, 2010 at 2:52 PM, Nigel Kersten  wrote:
> >
> >
> > On Thu, May 27, 2010 at 2:42 PM, Douglas Garstang <
> doug.garst...@gmail.com>
> > wrote:
> >>
> >> On Thu, May 27, 2010 at 10:34 AM, Michael DeHaan <
> mich...@puppetlabs.com>
> >> wrote:
> >> > On Thu, May 27, 2010 at 1:23 PM, Douglas Garstang
> >> >  wrote:
> >> >> On Thu, May 27, 2010 at 9:55 AM, Nigel Kersten 
> >> >> wrote:
> >> >>>
> >> >>>
> >> >>> On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang
> >> >>> 
> >> >>> wrote:
> >> 
> >>  Does switching to external nodes require a forklift approach?
> >> 
> >>  The other day, I specified an external node script in puppet.conf,
> >>  and
> >>  puppet complained about every single node that wasn't handled by
> the
> >>  external script. It would be nice (and more realistic) to be able
> to
> >>  cut one node over at a time. Is this possible?
> >> >>>
> >> >>> Absolutely.
> >> >>> My external node script just returns the default config for any node
> >> >>> it
> >> >>> can't find a specific config for.
> >> >>
> >> >> That's not going to work. When the node isn't defined as an external
> >> >> node, I want it to use the node manifest file, not a default. If I
> was
> >> >> going to start using external nodes, some nodes would be external and
> >> >> some nodes would not be external, until they where all converted. It
> >> >> looks like while this was the case, nothing would work.
> >> >
> >> > As I understood things, external nodes is supposed to work as an
> >> > overlay on top of site.pp
> >> >
> >> > Is this not working if you just return an empty list of
> >> > classes/variables for a node?
> >> >
> >> > IIRC this works this way today -- let us know if there's a problem
> with
> >> > it.
> >>
> >> Sorry, I really don't follow you. The external node is specified in
> >> the puppet.conf file. Doesn't that mean ALL nodes are run through
> >> it???
> >
> > I believe what Michael is saying is rather than returning *nothing*, you
> > should return an empty node definition with empty parameters/classes.
>
> If the external node script returns an empty node, that might be fine
> for making sure the client runs cleanly, and doesn't break anything
> that's already deployed. However, it will also mean that any changes
> made to the node manifest file will be ignored. That seems kinda
> bad...
>

No, I think he's saying that if you return an empty node definition, the
node manifest file will be consulted.

The external node classifier just gets consulted first.

This doesn't really seem ideal. It seems like if an external node classifier
doesn't actually return anything, the manifest should be consulted.


>
> What's the state of storedconfigs these days?
>
> Doug.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Douglas Garstang]

On Thu, May 27, 2010 at 2:52 PM, Nigel Kersten  wrote:
>
>
> On Thu, May 27, 2010 at 2:42 PM, Douglas Garstang 
> wrote:
>>
>> On Thu, May 27, 2010 at 10:34 AM, Michael DeHaan 
>> wrote:
>> > On Thu, May 27, 2010 at 1:23 PM, Douglas Garstang
>> >  wrote:
>> >> On Thu, May 27, 2010 at 9:55 AM, Nigel Kersten 
>> >> wrote:
>> >>>
>> >>>
>> >>> On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang
>> >>> 
>> >>> wrote:
>> 
>>  Does switching to external nodes require a forklift approach?
>> 
>>  The other day, I specified an external node script in puppet.conf,
>>  and
>>  puppet complained about every single node that wasn't handled by the
>>  external script. It would be nice (and more realistic) to be able to
>>  cut one node over at a time. Is this possible?
>> >>>
>> >>> Absolutely.
>> >>> My external node script just returns the default config for any node
>> >>> it
>> >>> can't find a specific config for.
>> >>
>> >> That's not going to work. When the node isn't defined as an external
>> >> node, I want it to use the node manifest file, not a default. If I was
>> >> going to start using external nodes, some nodes would be external and
>> >> some nodes would not be external, until they where all converted. It
>> >> looks like while this was the case, nothing would work.
>> >
>> > As I understood things, external nodes is supposed to work as an
>> > overlay on top of site.pp
>> >
>> > Is this not working if you just return an empty list of
>> > classes/variables for a node?
>> >
>> > IIRC this works this way today -- let us know if there's a problem with
>> > it.
>>
>> Sorry, I really don't follow you. The external node is specified in
>> the puppet.conf file. Doesn't that mean ALL nodes are run through
>> it???
>
> I believe what Michael is saying is rather than returning *nothing*, you
> should return an empty node definition with empty parameters/classes.

If the external node script returns an empty node, that might be fine
for making sure the client runs cleanly, and doesn't break anything
that's already deployed. However, it will also mean that any changes
made to the node manifest file will be ignored. That seems kinda
bad...

What's the state of storedconfigs these days?

Doug.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Nigel Kersten]

On Thu, May 27, 2010 at 2:42 PM, Douglas Garstang
wrote:

> On Thu, May 27, 2010 at 10:34 AM, Michael DeHaan 
> wrote:
> > On Thu, May 27, 2010 at 1:23 PM, Douglas Garstang
> >  wrote:
> >> On Thu, May 27, 2010 at 9:55 AM, Nigel Kersten 
> wrote:
> >>>
> >>>
> >>> On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang <
> doug.garst...@gmail.com>
> >>> wrote:
> 
>  Does switching to external nodes require a forklift approach?
> 
>  The other day, I specified an external node script in puppet.conf, and
>  puppet complained about every single node that wasn't handled by the
>  external script. It would be nice (and more realistic) to be able to
>  cut one node over at a time. Is this possible?
> >>>
> >>> Absolutely.
> >>> My external node script just returns the default config for any node it
> >>> can't find a specific config for.
> >>
> >> That's not going to work. When the node isn't defined as an external
> >> node, I want it to use the node manifest file, not a default. If I was
> >> going to start using external nodes, some nodes would be external and
> >> some nodes would not be external, until they where all converted. It
> >> looks like while this was the case, nothing would work.
> >
> > As I understood things, external nodes is supposed to work as an
> > overlay on top of site.pp
> >
> > Is this not working if you just return an empty list of
> > classes/variables for a node?
> >
> > IIRC this works this way today -- let us know if there's a problem with
> it.
>
> Sorry, I really don't follow you. The external node is specified in
> the puppet.conf file. Doesn't that mean ALL nodes are run through
> it???
>

I believe what Michael is saying is rather than returning *nothing*, you
should return an empty node definition with empty parameters/classes.


>
> Doug
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes Ignore Missing Classes

[Nigel Kersten]

On Thu, May 27, 2010 at 2:47 PM, Douglas Garstang
wrote:

> All,
>
> I just did a super simple test where I used the simple external nodes
> script at http://docs.puppetlabs.com/guides/external_nodes.html.
>
> I ran it against an existing node (which you have to since I don't see
> how you can tell it not to), and there was no errors. I then realised
> that even though the classes specified were not available, puppet did
> not complain on the client. That's a bit of a problem isn't it?
>
> If I put an "include foo" in a node manifest, and foo doesn't exist,
> puppet will complain. If I put "classes: foo" in an external node
> script, and foo doesn't exist, puppet on the client does NOT complain.
>

I actually just noticed this yesterday too. Definitely seems bug worthy, at
a minimum there should be something notified client-side about it.




>
> Doug
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External nodes Ignore Missing Classes

[Douglas Garstang]

All,

I just did a super simple test where I used the simple external nodes
script at http://docs.puppetlabs.com/guides/external_nodes.html.

I ran it against an existing node (which you have to since I don't see
how you can tell it not to), and there was no errors. I then realised
that even though the classes specified were not available, puppet did
not complain on the client. That's a bit of a problem isn't it?

If I put an "include foo" in a node manifest, and foo doesn't exist,
puppet will complain. If I put "classes: foo" in an external node
script, and foo doesn't exist, puppet on the client does NOT complain.

Doug

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Douglas Garstang]

On Thu, May 27, 2010 at 10:34 AM, Michael DeHaan  wrote:
> On Thu, May 27, 2010 at 1:23 PM, Douglas Garstang
>  wrote:
>> On Thu, May 27, 2010 at 9:55 AM, Nigel Kersten  wrote:
>>>
>>>
>>> On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang 
>>> wrote:

 Does switching to external nodes require a forklift approach?

 The other day, I specified an external node script in puppet.conf, and
 puppet complained about every single node that wasn't handled by the
 external script. It would be nice (and more realistic) to be able to
 cut one node over at a time. Is this possible?
>>>
>>> Absolutely.
>>> My external node script just returns the default config for any node it
>>> can't find a specific config for.
>>
>> That's not going to work. When the node isn't defined as an external
>> node, I want it to use the node manifest file, not a default. If I was
>> going to start using external nodes, some nodes would be external and
>> some nodes would not be external, until they where all converted. It
>> looks like while this was the case, nothing would work.
>
> As I understood things, external nodes is supposed to work as an
> overlay on top of site.pp
>
> Is this not working if you just return an empty list of
> classes/variables for a node?
>
> IIRC this works this way today -- let us know if there's a problem with it.

Sorry, I really don't follow you. The external node is specified in
the puppet.conf file. Doesn't that mean ALL nodes are run through
it???

Doug

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Michael DeHaan]

On Thu, May 27, 2010 at 1:23 PM, Douglas Garstang
 wrote:
> On Thu, May 27, 2010 at 9:55 AM, Nigel Kersten  wrote:
>>
>>
>> On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang 
>> wrote:
>>>
>>> Does switching to external nodes require a forklift approach?
>>>
>>> The other day, I specified an external node script in puppet.conf, and
>>> puppet complained about every single node that wasn't handled by the
>>> external script. It would be nice (and more realistic) to be able to
>>> cut one node over at a time. Is this possible?
>>
>> Absolutely.
>> My external node script just returns the default config for any node it
>> can't find a specific config for.
>
> That's not going to work. When the node isn't defined as an external
> node, I want it to use the node manifest file, not a default. If I was
> going to start using external nodes, some nodes would be external and
> some nodes would not be external, until they where all converted. It
> looks like while this was the case, nothing would work.

As I understood things, external nodes is supposed to work as an
overlay on top of site.pp

Is this not working if you just return an empty list of
classes/variables for a node?

IIRC this works this way today -- let us know if there's a problem with it.

--Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Douglas Garstang]

On Thu, May 27, 2010 at 9:55 AM, Nigel Kersten  wrote:
>
>
> On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang 
> wrote:
>>
>> Does switching to external nodes require a forklift approach?
>>
>> The other day, I specified an external node script in puppet.conf, and
>> puppet complained about every single node that wasn't handled by the
>> external script. It would be nice (and more realistic) to be able to
>> cut one node over at a time. Is this possible?
>
> Absolutely.
> My external node script just returns the default config for any node it
> can't find a specific config for.

That's not going to work. When the node isn't defined as an external
node, I want it to use the node manifest file, not a default. If I was
going to start using external nodes, some nodes would be external and
some nodes would not be external, until they where all converted. It
looks like while this was the case, nothing would work.

Doug.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Nigel Kersten]

On Thu, May 27, 2010 at 9:35 AM, Douglas Garstang
wrote:

> Does switching to external nodes require a forklift approach?
>
> The other day, I specified an external node script in puppet.conf, and
> puppet complained about every single node that wasn't handled by the
> external script. It would be nice (and more realistic) to be able to
> cut one node over at a time. Is this possible?
>

Absolutely.

My external node script just returns the default config for any node it
can't find a specific config for.


>
> Doug.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>


-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes Require a Forklift?

[Douglas Garstang]

Does switching to external nodes require a forklift approach?

The other day, I specified an external node script in puppet.conf, and
puppet complained about every single node that wasn't handled by the
external script. It would be nice (and more realistic) to be able to
cut one node over at a time. Is this possible?

Doug.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes

[Michael DeHaan]

> If I can't have resources of any type in an external node, what's the
> point? And... how can I do this? The reason I am looking at external
> nodes again, even though I still think the concept is misguided is
> because I need to write custom scripts to parse the node manifests,
> and that's a pain in the ass.

Hey Doug,

You're right in that Puppet can't do this presently -- but we're
looking at adding the ability to specify these in external_nodes (and
in Dashboard) probably in the release after 0.26 ... so, probably not
soon enough for you, but I agree it's pretty important.

(0.26 adds parametrized classes, which is definitely useful as well).

Previously the thinking is that forcing each node to assign itself to
a class is a best practice, but there's a tradeoff to be made there,
and in the case of lots of heterogeneousness, that means a lot more
classes that you probably want to avoid :)

I think node classification itself is quite useful (not as you say
misguided), but incomplete... yes :)

Once we have parametrized classes this will allow us the ability to do
things in Dashboard like allow prompting for required parameters when
assigning a class to a node... so it should be pretty slick.
Separating the rules/policy/model of your infrastructure
from the person who tells machines what each machine what to do is the
basic idea here -- so you can turn over the reins to someone who is
different than the person who writes your Puppet code ... and in many
cases, that's via an external application.

--Michael

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes

[Douglas Garstang]

>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 be in hierarchies however, so inheritance is available."

So, does this mean I can't do this with external nodes?

node node1 inherits parent_node {

var=val
include moduleA
include moduleB
include moduleC

definitionA { ..}
definitionB {...}
definitionC {...}

}

If I can't have resources of any type in an external node, what's the
point? And... how can I do this? The reason I am looking at external
nodes again, even though I still think the concept is misguided is
because I need to write custom scripts to parse the node manifests,
and that's a pain in the ass.

Doug.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] External Nodes and storeconfigs

[Douglas Garstang]

So...

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 config in two different locations, and
2. Most importantly, your losing the ability to version control your
configuration. It would seem to me that of utmost importance in any
prod environment is the ability to diff incremental config pushes, and
maybe roll them back where necessary.

Am I missing a benefit that over rides disadvantages 2 and 3?

Doug.

--~--~-~--~~~---~--~~
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] external nodes issue

[Matt]

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.

I've started all processes in debug - running Puppet 0.25

puppetd -
debug: Puppet::Network::Format[json]: false value when expecting true
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find default node or by name with 'sl01.domain.sl,
sl01.domain, sl01' on node sl01.domain.sl
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

puppetmasterd -
info: Not using expired node for sl01.domain.sl from cache; expired at
Mon Sep 28 09:28:47 +0100 2009
debug: Executing '/etc/puppet/node.rb sl01.domain.sl'
info: Caching node for sl01.domain.sl

err: Could not find default node or by name with 'sl01.domain.sl,
sl01.domain, sl01' on node sl01.domain.sl
err: Could not find default node or by name with 'sl01.domain.sl,
sl01.domain, sl01' on node sl01.domain.sl

foreman -
Processing HostsController#externalNodes (for 127.0.0.1 at 2009-09-28
09:39:30) [GET]
  Parameters: {"fqdn"=>"sl01.domain.sl", "action"=>"externalNodes",
"controller"=>"hosts"}
Completed in 9ms (View: 0, DB: 1) | 200 OK
[http://localhost/hosts/externalNodes?fqdn=sl01.domain.sl]

manually -
# su - puppet
-bash-3.2$ cd /etc/puppet
-bash-3.2$ ./node.rb sl01.domain.sl
---
parameters:
  s3: "false"
  puppetmaster: sl02.domain.sl
  java: jre16007
  domainname: domain.sl
classes:
- env
- ganglia


Anyone have any idea how I can find out whats going on?

The only difference I can see between the production and dev boxes is
that the production box uses certdnsnames, as it has both external and
internal clients -
  certname=sl02.domain.com
  certdnsnames=sl02.domain.com:sl02.domain.sl

Thanks,

Matt

--~--~-~--~~~---~--~~
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] external nodes and environments

[Steven VanDevender]

I'd like to extend our Puppet installation to support split production
and development environments.  We're using Subversion to manage Puppet
configurations and already have the recommended /etc/puppet layout to
handle a separate development branch.

What I'd like to do is have a centralized source of information (that
is, not having to edit individual puppet.conf files on clients) to
indicate which hosts are in the development environment, which seems to
lead me to setting up an external node classifier.

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).  The documentation suggests this
should probably work, but also says things like "If you specify any
nodes in your site.pp, you must specify all nodes in site.pp, even those
that are looked up via the external nodes script."  What exactly does
that mean?  We currently have a number of Puppet clients that just use a
default template without having an explicit node definition; would those
have to have explicit entries in our nodes.pp rather than falling into
the "node default"?

We're also starting to use Cobbler for automated installation, and I've
looked at the configuration management hooks in Cobbler that can be used
with an external node classifier in Puppet.  These are somewhat
appealing, but again I'd rather not have to migrate all the class
membership information into Cobbler, and only use the "kickstart
metadata" field in a host profile to specify whether a host is in the
development environment.  Also, since using Cobbler as an external node
classifier requires fetching URLs out of the Cobbler web interface to
get the host data, I am nervous about causing problems for Puppet if
Cobbler happens to be down.

If anyone else is using Cobbler for their Puppet external node
classifier, do you just have to keep Cobbler up all the time, or do you
have a way to keep the external node classifier working even when
Cobbler isn't up at the time?


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---