Re: [Puppet Users] Not custom facts, but variables?
Right on! Thanks Jon, That was it. Got it working just as you stated. It's exactly what I need. Tony On Monday, April 8, 2013 1:01:58 PM UTC-7, Jonathan Proulx wrote: > > > On Mon, Apr 8, 2013 at 3:33 PM, Tony C >wrote: > >> Jon, >> >> Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar >> with this module. I read on it but not sure specifically how you are using >> it. >> >> > stdlib provides many useful functions, most of which are called by other > modules. > > The use that relates to this case is "facter-dot-d" see > https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3/for > a write up. > > The simple case (which is the one we use is making a plain text file in > /etc/facter/facts.d (anything in there ending in .txt gets parsed as plain > text)) with key=value pairs that then become facter facts. > > for example on my puppet managed workstation: > > $ cat /etc/facter/facts.d/csail.txt > role=wkst > autofs=true > > So when puppet runs the fact "role" is set to "wkst" which pulls in the > right classes to make a generic workstation, the fact "group" mentioned > above is undefined which is OK there's just no customization based on > groups and "autofs" is a facter key that our local wkst module looks at to > see if our NFS automount should be configured or not. By default we don't > but the local root user can define this to true and on the next puppet run > the config will happen for them. > > We install the stdlib module on the puppet masters (implemneted as a git > submodule in our git repo) and use "pluginsync=true" on the clients to pull > down the bits they need from this and other modules. Though you could > distribute the required facter-dot-d.rb file in other ways, pluginsync is > most convenient for us. > > -Jon > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
On Mon, Apr 8, 2013 at 3:33 PM, Tony C wrote: > Jon, > > Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar > with this module. I read on it but not sure specifically how you are using > it. > > stdlib provides many useful functions, most of which are called by other modules. The use that relates to this case is "facter-dot-d" see https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3/for a write up. The simple case (which is the one we use is making a plain text file in /etc/facter/facts.d (anything in there ending in .txt gets parsed as plain text)) with key=value pairs that then become facter facts. for example on my puppet managed workstation: $ cat /etc/facter/facts.d/csail.txt role=wkst autofs=true So when puppet runs the fact "role" is set to "wkst" which pulls in the right classes to make a generic workstation, the fact "group" mentioned above is undefined which is OK there's just no customization based on groups and "autofs" is a facter key that our local wkst module looks at to see if our NFS automount should be configured or not. By default we don't but the local root user can define this to true and on the next puppet run the config will happen for them. We install the stdlib module on the puppet masters (implemneted as a git submodule in our git repo) and use "pluginsync=true" on the clients to pull down the bits they need from this and other modules. Though you could distribute the required facter-dot-d.rb file in other ways, pluginsync is most convenient for us. -Jon -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
On Mon, Apr 8, 2013 at 3:25 PM, Dan White wrote:
> That looks great.
>
> Another thing to consider: As of hiera 1.2.0, you have deep merge for
> hashes.
> You do not need to repeat parameters at every level !
>
> That's good to know. We've been using hiera arrays to collect things like
classes and packages from multiple levels of the hierarchy, this lets me
keep a site.pp that is essentially:
node default {
hiera_include("classes")
}
and pull in all packages that are required (but not otherwise managed) with:
$basepackages = hiera_array('basepackages')
package { $basepackages:
ensure => latest,
require => Class['csail::apt::csailrepo'],
}
we use this for things like development tool and desktop applications that
we want installed but aren't otherwise manages (unlike services that
generally have their own module to handle all that). In both cases clsees
and packages can be defined at any level of the hierarchy and all that are
found are activated.
being able to merge hashes like that sounds interesting, though perhaps the
topic is starting to drift a bit
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
Jon,
Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar
with this module. I read on it but not sure specifically how you are using
it.
Thanks,
Tony
On Monday, April 8, 2013 12:14:04 PM UTC-7, Jonathan Proulx wrote:
>
> On Mon, Apr 8, 2013 at 2:57 PM, Dan White
> > wrote:
>
>> Based on your description, I would suggest the following:
>>
>> Let's take tomcat as a specific example.
>> Assumption: You have a tomcat module that can be configured with
>> parameters.
>>
>> Here is the suggestion: Add a hostname level to your heirarchy
>>
>
>
> but if you have multiple tomcat servers (for example) then you have to
> repeat data for each hostname which is exactly the wrong thing.
>
> using a custom fact (I use "role" for essentially the same thing Tony
> wants to use "application for) you can classify nodes without an ENC and
> without repeating yourself.
>
> My hierarchy is:
> # cat /etc/puppet/hiera.yaml
> ---
> :hierarchy:
> - %{fqdn}
> - %{role}
> - %{group}
> - %{osfamily}
> - common
> :backends:
> - yaml
> - puppet
> :yaml:
> :datadir: /etc/puppet/environments/%{environment}/data
> :puppet:
> :datasource: data
>
> I do have fqdn, but that is always too specific, except maybe for
> testing. "Role" is what the system does and "group" is who manages it,
> both of these come form custom facts on the system in /etc/factor/facts.d
> (requires puppetlabs_stdlib) so I can have multiple nodes (in some cases
> hundreds) with the same role. Keying this off fqdn or cert name would me a
> nightmare
>
> Picking the right hierarchy and the right level into to place data is a
> bit of a black art, but crucial to having a manageable config. This has
> been workable for me for the past 9 months or so, but not pretenses to
> perfection...
>
> -Jon
>
>
>
>> OK, so now for node hostx.example.org, you want this to be a tomcat
>> server. All you need do is put the appropriate parameters into
>> hostx.example.org.yaml
>>
>> I am still a hiera n00b myself, so I am not totally sure exactly how to
>> do this, but I am working on it.
>>
>>
>> “Sometimes I think the surest sign that intelligent life exists elsewhere
>> in the universe is that none of it has tried to contact us.”
>> Bill Waterson (Calvin & Hobbes)
>>
>> --
>> *From: *"Tony C" >
>> *To: *puppet...@googlegroups.com
>> *Sent: *Monday, April 8, 2013 2:43:41 PM
>> *Subject: *Re: [Puppet Users] Not custom facts, but variables?
>>
>>
>> sure, to be specific,
>>
>> we have environments, dev, test, qa, stage, and prod. That part I got
>> with your help on my last post. Thank you.
>>
>> Within these environments, we have applications. We only have a few apps.
>> So let's say some machines are oracle db machines, some are tomcat, and
>> some are apache.
>>
>> I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each
>> of these yaml files contain some key value pair that is specific to that
>> environment.
>>
>> So when some machine is provisioned, I want to say this machine is a
>> tomcat machine, and I don't care what environment it since I will let the
>> agent conf figure that out. That way I can one puppet module for tomcat,
>> but different values per environment.
>>
>> I hope that makes sense, and if my approach is completely wrong, I'm open
>> to hear some alternatives. Thanks again everyone.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users...@googlegroups.com .
>> To post to this group, send email to puppet...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users...@googlegroups.com .
>> To post to this group, send email to puppet...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
Thanks for your response, but I can see me possibly having tons of yaml files since it's very possible I may have 100 tomcat servers, all with the same configuration. I don't think it will scale. On Monday, April 8, 2013 11:57:10 AM UTC-7, Ygor wrote: > > Based on your description, I would suggest the following: > > Let's take tomcat as a specific example. > Assumption: You have a tomcat module that can be configured with > parameters. > > Here is the suggestion: Add a hostname level to your heirarchy. > > OK, so now for node hostx.example.org, you want this to be a tomcat > server. All you need do is put the appropriate parameters into > hostx.example.org.yaml > > I am still a hiera n00b myself, so I am not totally sure exactly how to do > this, but I am working on it. > > “Sometimes I think the surest sign that intelligent life exists elsewhere > in the universe is that none of it has tried to contact us.” > Bill Waterson (Calvin & Hobbes) > > -- > *From: *"Tony C" > > *To: *puppet...@googlegroups.com > *Sent: *Monday, April 8, 2013 2:43:41 PM > *Subject: *Re: [Puppet Users] Not custom facts, but variables? > > sure, to be specific, > > we have environments, dev, test, qa, stage, and prod. That part I got with > your help on my last post. Thank you. > > Within these environments, we have applications. We only have a few apps. > So let's say some machines are oracle db machines, some are tomcat, and > some are apache. > > I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each > of these yaml files contain some key value pair that is specific to that > environment. > > So when some machine is provisioned, I want to say this machine is a > tomcat machine, and I don't care what environment it since I will let the > agent conf figure that out. That way I can one puppet module for tomcat, > but different values per environment. > > I hope that makes sense, and if my approach is completely wrong, I'm open > to hear some alternatives. Thanks again everyone. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users...@googlegroups.com . > To post to this group, send email to puppet...@googlegroups.com > . > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
That looks great.
Another thing to consider: As of hiera 1.2.0, you have deep merge for hashes.
You do not need to repeat parameters at every level !
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
- Original Message -
From: "Jonathan Proulx"
To: puppet-users@googlegroups.com
Sent: Monday, April 8, 2013 3:14:04 PM
Subject: Re: [Puppet Users] Not custom facts, but variables?
On Mon, Apr 8, 2013 at 2:57 PM, Dan White < y...@comcast.net > wrote:
Based on your description, I would suggest the following:
Let's take tomcat as a specific example.
Assumption: You have a tomcat module that can be configured with parameters.
Here is the suggestion: Add a hostname level to your heirarchy
but if you have multiple tomcat servers (for example) then you have to repeat
data for each hostname which is exactly the wrong thing.
using a custom fact (I use "role" for essentially the same thing Tony wants to
use "application for) you can classify nodes without an ENC and without
repeating yourself.
My hierarchy is:
# cat /etc/puppet/hiera.yaml
---
:hierarchy:
- %{fqdn}
- %{role}
- %{group}
- %{osfamily}
- common
:backends:
- yaml
- puppet
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data
:puppet:
:datasource: data
I do have fqdn, but that is always too specific, except maybe for testing.
"Role" is what the system does and "group" is who manages it, both of these
come form custom facts on the system in /etc/factor/facts.d (requires
puppetlabs_stdlib) so I can have multiple nodes (in some cases hundreds) with
the same role. Keying this off fqdn or cert name would me a nightmare
Picking the right hierarchy and the right level into to place data is a bit of
a black art, but crucial to having a manageable config. This has been workable
for me for the past 9 months or so, but not pretenses to perfection...
-Jon
OK, so now for node hostx.example.org , you want this to be a tomcat server.
All you need do is put the appropriate parameters into hostx.example.org.yaml
I am still a hiera n00b myself, so I am not totally sure exactly how to do
this, but I am working on it.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
From: "Tony C" < tonyjch...@gmail.com >
To: puppet-users@googlegroups.com
Sent: Monday, April 8, 2013 2:43:41 PM
Subject: Re: [Puppet Users] Not custom facts, but variables?
sure, to be specific,
we have environments, dev, test, qa, stage, and prod. That part I got with your
help on my last post. Thank you.
Within these environments, we have applications. We only have a few apps. So
let's say some machines are oracle db machines, some are tomcat, and some are
apache.
I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of
these yaml files contain some key value pair that is specific to that
environment.
So when some machine is provisioned, I want to say this machine is a tomcat
machine, and I don't care what environment it since I will let the agent conf
figure that out. That way I can one puppet module for tomcat, but different
values per environment.
I hope that makes sense, and if my approach is completely wrong, I'm open to
hear some alternatives. Thanks again everyone.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com .
To post to this group, send email to puppet-users@googlegroups.com .
Visit this group at http://groups.google.com/group/puppet-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com .
To post to this group, send email to puppet-users@googlegroups.com .
Visit this group at http://groups.google.com/group/puppet-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .
--
You re
Re: [Puppet Users] Not custom facts, but variables?
On Mon, Apr 8, 2013 at 2:57 PM, Dan White wrote:
> Based on your description, I would suggest the following:
>
> Let's take tomcat as a specific example.
> Assumption: You have a tomcat module that can be configured with
> parameters.
>
> Here is the suggestion: Add a hostname level to your heirarchy
>
but if you have multiple tomcat servers (for example) then you have to
repeat data for each hostname which is exactly the wrong thing.
using a custom fact (I use "role" for essentially the same thing Tony wants
to use "application for) you can classify nodes without an ENC and without
repeating yourself.
My hierarchy is:
# cat /etc/puppet/hiera.yaml
---
:hierarchy:
- %{fqdn}
- %{role}
- %{group}
- %{osfamily}
- common
:backends:
- yaml
- puppet
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data
:puppet:
:datasource: data
I do have fqdn, but that is always too specific, except maybe for testing.
"Role" is what the system does and "group" is who manages it, both of these
come form custom facts on the system in /etc/factor/facts.d (requires
puppetlabs_stdlib) so I can have multiple nodes (in some cases hundreds)
with the same role. Keying this off fqdn or cert name would me a nightmare
Picking the right hierarchy and the right level into to place data is a bit
of a black art, but crucial to having a manageable config. This has been
workable for me for the past 9 months or so, but not pretenses to
perfection...
-Jon
> OK, so now for node hostx.example.org, you want this to be a tomcat
> server. All you need do is put the appropriate parameters into
> hostx.example.org.yaml
>
> I am still a hiera n00b myself, so I am not totally sure exactly how to do
> this, but I am working on it.
>
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> *From: *"Tony C"
> *To: *puppet-users@googlegroups.com
> *Sent: *Monday, April 8, 2013 2:43:41 PM
> *Subject: *Re: [Puppet Users] Not custom facts, but variables?
>
>
> sure, to be specific,
>
> we have environments, dev, test, qa, stage, and prod. That part I got with
> your help on my last post. Thank you.
>
> Within these environments, we have applications. We only have a few apps.
> So let's say some machines are oracle db machines, some are tomcat, and
> some are apache.
>
> I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each
> of these yaml files contain some key value pair that is specific to that
> environment.
>
> So when some machine is provisioned, I want to say this machine is a
> tomcat machine, and I don't care what environment it since I will let the
> agent conf figure that out. That way I can one puppet module for tomcat,
> but different values per environment.
>
> I hope that makes sense, and if my approach is completely wrong, I'm open
> to hear some alternatives. Thanks again everyone.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
Based on your description, I would suggest the following: Let's take tomcat as a specific example. Assumption: You have a tomcat module that can be configured with parameters. Here is the suggestion: Add a hostname level to your heirarchy. OK, so now for node hostx.example.org, you want this to be a tomcat server. All you need do is put the appropriate parameters into hostx.example.org.yaml I am still a hiera n00b myself, so I am not totally sure exactly how to do this, but I am working on it. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) - Original Message - From: "Tony C" To: puppet-users@googlegroups.com Sent: Monday, April 8, 2013 2:43:41 PM Subject: Re: [Puppet Users] Not custom facts, but variables? sure, to be specific, we have environments, dev, test, qa, stage, and prod. That part I got with your help on my last post. Thank you. Within these environments, we have applications. We only have a few apps. So let's say some machines are oracle db machines, some are tomcat, and some are apache. I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of these yaml files contain some key value pair that is specific to that environment. So when some machine is provisioned, I want to say this machine is a tomcat machine, and I don't care what environment it since I will let the agent conf figure that out. That way I can one puppet module for tomcat, but different values per environment. I hope that makes sense, and if my approach is completely wrong, I'm open to hear some alternatives. Thanks again everyone. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en . For more options, visit https://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
sure, to be specific, we have environments, dev, test, qa, stage, and prod. That part I got with your help on my last post. Thank you. Within these environments, we have applications. We only have a few apps. So let's say some machines are oracle db machines, some are tomcat, and some are apache. I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of these yaml files contain some key value pair that is specific to that environment. So when some machine is provisioned, I want to say this machine is a tomcat machine, and I don't care what environment it since I will let the agent conf figure that out. That way I can one puppet module for tomcat, but different values per environment. I hope that makes sense, and if my approach is completely wrong, I'm open to hear some alternatives. Thanks again everyone. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
On Mon, Apr 8, 2013 at 2:28 PM, Tony C wrote:
> After reading several posts, it looks like setting a key on every host,
> and supplying a different value based on that host's function is not a
> proper use of facts, but more for variables.
>
> We are using hiera, and based on my hierarchy,
>
>
> :hierarchy:
> - common
> - %{application}
> :yaml:
> :datadir: /etc/puppetlabs/hieradata/%{environment}
>
> Without using an ENC, what's are some good ways to "tag" the server with a
> value for %{application}.
>
I do exactly this using facts.
using puppetlabs_stdlib module to provide simple custom facts from
/etc/facter/facts.d (after partitioning and installing a base OS) our
install process writes a custom text file to this directory defining facts
for "role", "group" and "cluster" which are all parts of our hiera
hierarchy and then calls puppet for the first time.
This may not be the best way in a more orderly environment but I work in an
academic research lab so have lots of messy edge cases that can't be
determined by name or IP and need to delegate these definitions to people
who are not admin enough to have access to our puppet repo but do have
local root on the systems they manage...
-Jon
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Not custom facts, but variables?
I am still confuzzled by your "application"
Would you provide a more specific example ?
I am thinking that this is something that can be controlled at the module level
http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#parser-set-variables
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
- Original Message -
From: "Tony C"
To: puppet-users@googlegroups.com
Sent: Monday, April 8, 2013 2:28:40 PM
Subject: [Puppet Users] Not custom facts, but variables?
After reading several posts, it looks like setting a key on every host, and
supplying a different value based on that host's function is not a proper use
of facts, but more for variables.
We are using hiera, and based on my hierarchy,
:hierarchy:
- common
- %{application}
:yaml:
:datadir: /etc/puppetlabs/hieradata/%{environment}
Without using an ENC, what's are some good ways to "tag" the server with a
value for %{application}.
thanks so much,
Tony
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Not custom facts, but variables?
After reading several posts, it looks like setting a key on every host, and
supplying a different value based on that host's function is not a proper
use of facts, but more for variables.
We are using hiera, and based on my hierarchy,
:hierarchy:
- common
- %{application}
:yaml:
:datadir: /etc/puppetlabs/hieradata/%{environment}
Without using an ENC, what's are some good ways to "tag" the server with a
value for %{application}.
thanks so much,
Tony
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
