Edward Bailey
2010-Nov-09 01:42 UTC
[Puppet Users] question about custom facts and environmental variables
I am having a great deal of trouble using a custom fact in a module and I am
hoping someone can help me out.
I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these are
really old versions.
The custom fact is defined using an environmental variable
export FACTER_VERTICAL="dev fit"
and I can see the fact in the output of facter
[xxxxx ~]# facter | grep -i vertical
vertical => dev fit
In the module I am trying to use the fact in the following way
file { "/etc/yum.repos.d/env32-envision.repo":
ensure => present,
mode => 0664,
owner => root,
group => root,
content => $vertical ? {
"dev fit" =>
template("ads_yum2/env32-dev-fit.repo.erb"),
default =>
template("ads_yum2/env32-dev-staging.repo.erb"),
require => File["/etc/yum.repos.d/base_os.repo"],
}
}
When I restart puppet the output is the default option instead of the "dev
fit" option. If I run puppet interactively "puppetd --debug
--test" I get
the correct output based on the custom fact. I understand that puppet will
not inherent environmental variables but since the fact is present I thought
this approach would work. Am I wrong?
I have been banging my head against the wall over this for some time. I
appreciate any input.
Thanks
Ed
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Zach Leslie
2010-Nov-09 22:45 UTC
Re: [Puppet Users] question about custom facts and environmental variables
Hi Ed, You are correct that the environment will not get imported into puppet. When you restart the puppet daemon, you are missing your custom fact because daemon will run as its own process with its own environment, so just exporting the variable will only effect your current running environment and not the puppet daemon environment. As such, the behavior your are seeing is expected. Looking around, I think this looks like a better way to get facts in: http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts This will allow you to get some level of synchronization of your custom facts from your master to your clients in a much cleaner way. Hope this helps. Zach On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey < eds.mailing.list.account@gmail.com> wrote:> I am having a great deal of trouble using a custom fact in a module and I > am hoping someone can help me out. > > I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these are > really old versions. > > The custom fact is defined using an environmental variable > > export FACTER_VERTICAL="dev fit" > > and I can see the fact in the output of facter > > [xxxxx ~]# facter | grep -i vertical > vertical => dev fit > > In the module I am trying to use the fact in the following way > > file { "/etc/yum.repos.d/env32-envision.repo": > ensure => present, > mode => 0664, > owner => root, > group => root, > content => $vertical ? { > "dev fit" => > template("ads_yum2/env32-dev-fit.repo.erb"), > default => > template("ads_yum2/env32-dev-staging.repo.erb"), > require => File["/etc/yum.repos.d/base_os.repo"], > } > } > > When I restart puppet the output is the default option instead of the "dev > fit" option. If I run puppet interactively "puppetd --debug --test" I get > the correct output based on the custom fact. I understand that puppet will > not inherent environmental variables but since the fact is present I thought > this approach would work. Am I wrong? > > I have been banging my head against the wall over this for some time. I > appreciate any input. > > Thanks > > Ed > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Zach zach@puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
eds.mailing.list.account@gmail.com
2010-Nov-09 23:45 UTC
Re: Re: [Puppet Users] question about custom facts and environmental variables
ok - that makes sense, but why does facter have a feature http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter where you can expose environmental variables as facts if puppet will not recognize the facts? Is the issue because of the old version of facter I am using? Thanks Ed On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote:> Hi Ed,> You are correct that the environment will not get imported into puppet. > When you restart the puppet daemon, you are missing your custom fact > because daemon will run as its own process with its own environment, so > just exporting the variable will only effect your current running > environment and not the puppet daemon environment. As such, the behavior > your are seeing is expected.> Looking around, I think this looks like a better way to get facts in: > http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts> This will allow you to get some level of synchronization of your custom > facts from your master to your clients in a much cleaner way.> Hope this helps.> Zach> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey > eds.mailing.list.account@gmail.com> wrote:> I am having a great deal of trouble using a custom fact in a module and I > am hoping someone can help me out.> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these are > really old versions.> The custom fact is defined using an environmental variable> export FACTER_VERTICAL="dev fit"> and I can see the fact in the output of facter> [xxxxx ~]# facter | grep -i vertical > vertical => dev fit> In the module I am trying to use the fact in the following way> file { "/etc/yum.repos.d/env32-envision.repo": > ensure => present, > mode => 0664, > owner => root, > group => root,> content => $vertical ? { > "dev fit" => template("ads_yum2/env32-dev-fit.repo.erb"), > default => template("ads_yum2/env32-dev-staging.repo.erb"),> require => File["/etc/yum.repos.d/base_os.repo"], > } > }> When I restart puppet the output is the default option instead of > the "dev fit" option. If I run puppet interactively "puppetd --debug > --test" I get the correct output based on the custom fact. I understand > that puppet will not inherent environmental variables but since the fact > is present I thought this approach would work. Am I wrong?> I have been banging my head against the wall over this for some time. I > appreciate any input.> Thanks> Ed> --> You received this message because you are subscribed to the Google > Groups "Puppet Users" group.> To post to this group, send email to puppet-users@googlegroups.com.> To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com.> For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en.> -- > Zach > zach@puppetlabs.com> --> You received this message because you are subscribed to the Google > Groups "Puppet Users" group.> To post to this group, send email to puppet-users@googlegroups.com.> To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com.> For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nigel Kersten
2010-Nov-10 00:29 UTC
Re: Re: [Puppet Users] question about custom facts and environmental variables
On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.account@gmail.com> wrote:> ok - that makes sense, but why does facter have a feature > http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter > where you can expose environmental variables as facts if puppet will not > recognize the facts? Is the issue because of the old version of facter I am > using?Most times I''ve seen people use this functionality has been with puppetd in non-daemon mode. FACTER_foo="woot" puppetd --onetime --verbose --no-daemonize Plus, this works well with standalone "puppet" applying local manifests too. It looks like things aren''t so simple in daemon mode. Is there a reason you''re not actually doing this as a real fact?> > Thanks > > Ed > > On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote: >> Hi Ed, >> >> You are correct that the environment will not get imported into puppet. >> When you restart the puppet daemon, you are missing your custom fact because >> daemon will run as its own process with its own environment, so just >> exporting the variable will only effect your current running environment and >> not the puppet daemon environment. As such, the behavior your are seeing is >> expected. >> >> >> Looking around, I think this looks like a better way to get facts in: >> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts >> >> This will allow you to get some level of synchronization of your custom >> facts from your master to your clients in a much cleaner way. >> >> >> Hope this helps. >> >> Zach >> >> >> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey >> eds.mailing.list.account@gmail.com> wrote: >> >> I am having a great deal of trouble using a custom fact in a module and I >> am hoping someone can help me out. >> >> >> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these are >> really old versions. >> >> The custom fact is defined using an environmental variable >> >> >> export FACTER_VERTICAL="dev fit" >> >> and I can see the fact in the output of facter >> >> [xxxxx ~]# facter | grep -i vertical >> vertical => dev fit >> >> In the module I am trying to use the fact in the following way >> >> >> >> file { "/etc/yum.repos.d/env32-envision.repo": >> ensure => present, >> mode => 0664, >> owner => root, >> group => root, >> >> >> content => $vertical ? { >> "dev fit" => >> template("ads_yum2/env32-dev-fit.repo.erb"), >> default => >> template("ads_yum2/env32-dev-staging.repo.erb"), >> >> >> require => File["/etc/yum.repos.d/base_os.repo"], >> } >> } >> >> When I restart puppet the output is the default option instead of the "dev >> fit" option. If I run puppet interactively "puppetd --debug --test" I get >> the correct output based on the custom fact. I understand that puppet will >> not inherent environmental variables but since the fact is present I thought >> this approach would work. Am I wrong? >> >> >> >> I have been banging my head against the wall over this for some time. I >> appreciate any input. >> >> Thanks >> >> Ed >> >> >> >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> >> >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> >> >> >> >> -- >> Zach >> zach@puppetlabs.com >> >> >> >> >> >> >> >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> >> >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Edward Bailey
2010-Nov-10 02:01 UTC
Re: Re: [Puppet Users] question about custom facts and environmental variables
The purpose behind setting up the fact this way is that I thought it would be an easy way to populate servers with extra metadata without having to drop a file and then a fact with some shell code on every server. For example, we have a number of servers that simply cannot be identified as being part of say the dev final integration test environment without the addition of something like a fact. Nothing native to the server such as the host name would be of any use. By dropping a file in /etc/profile.d using the environmental variable feature of facter looked like a real easy way to create the metadata I need. Now that I know this approach will not work I will use option 2 and go on with life. Its not a big deal I was just confused for a little bit. Thanks again Ed On Tue, Nov 9, 2010 at 7:29 PM, Nigel Kersten <nigel@puppetlabs.com> wrote:> On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.account@gmail.com> > wrote: > > ok - that makes sense, but why does facter have a feature > > > http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter > > where you can expose environmental variables as facts if puppet will not > > recognize the facts? Is the issue because of the old version of facter I > am > > using? > > Most times I''ve seen people use this functionality has been with > puppetd in non-daemon mode. > > FACTER_foo="woot" puppetd --onetime --verbose --no-daemonize > > Plus, this works well with standalone "puppet" applying local > manifests too. It looks like things aren''t so simple in daemon mode. > > Is there a reason you''re not actually doing this as a real fact? > > > > > Thanks > > > > Ed > > > > On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote: > >> Hi Ed, > >> > >> You are correct that the environment will not get imported into puppet. > >> When you restart the puppet daemon, you are missing your custom fact > because > >> daemon will run as its own process with its own environment, so just > >> exporting the variable will only effect your current running environment > and > >> not the puppet daemon environment. As such, the behavior your are > seeing is > >> expected. > >> > >> > >> Looking around, I think this looks like a better way to get facts in: > >> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts > >> > >> This will allow you to get some level of synchronization of your custom > >> facts from your master to your clients in a much cleaner way. > >> > >> > >> Hope this helps. > >> > >> Zach > >> > >> > >> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey > >> eds.mailing.list.account@gmail.com> wrote: > >> > >> I am having a great deal of trouble using a custom fact in a module and > I > >> am hoping someone can help me out. > >> > >> > >> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these > are > >> really old versions. > >> > >> The custom fact is defined using an environmental variable > >> > >> > >> export FACTER_VERTICAL="dev fit" > >> > >> and I can see the fact in the output of facter > >> > >> [xxxxx ~]# facter | grep -i vertical > >> vertical => dev fit > >> > >> In the module I am trying to use the fact in the following way > >> > >> > >> > >> file { "/etc/yum.repos.d/env32-envision.repo": > >> ensure => present, > >> mode => 0664, > >> owner => root, > >> group => root, > >> > >> > >> content => $vertical ? { > >> "dev fit" => > >> template("ads_yum2/env32-dev-fit.repo.erb"), > >> default => > >> template("ads_yum2/env32-dev-staging.repo.erb"), > >> > >> > >> require => File["/etc/yum.repos.d/base_os.repo"], > >> } > >> } > >> > >> When I restart puppet the output is the default option instead of the > "dev > >> fit" option. If I run puppet interactively "puppetd --debug --test" I > get > >> the correct output based on the custom fact. I understand that puppet > will > >> not inherent environmental variables but since the fact is present I > thought > >> this approach would work. Am I wrong? > >> > >> > >> > >> I have been banging my head against the wall over this for some time. I > >> appreciate any input. > >> > >> Thanks > >> > >> Ed > >> > >> > >> > >> > >> > >> -- > >> > >> You received this message because you are subscribed to the Google > Groups > >> "Puppet Users" group. > >> > >> To post to this group, send email to puppet-users@googlegroups.com. > >> > >> To unsubscribe from this group, send email to > >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > >> > >> > >> For more options, visit this group at > >> http://groups.google.com/group/puppet-users?hl=en. > >> > >> > >> > >> > >> > >> > >> -- > >> Zach > >> zach@puppetlabs.com > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> You received this message because you are subscribed to the Google > Groups > >> "Puppet Users" group. > >> > >> To post to this group, send email to puppet-users@googlegroups.com. > >> > >> To unsubscribe from this group, send email to > >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Nigel Kersten - Puppet Labs - http://www.puppetlabs.com > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Patrick
2010-Nov-10 02:06 UTC
Re: [Puppet Users] question about custom facts and environmental variables
On Nov 9, 2010, at 6:01 PM, Edward Bailey wrote:> The purpose behind setting up the fact this way is that I thought it would be an easy way to populate servers with extra metadata without having to drop a file and then a fact with some shell code on every server. > > For example, we have a number of servers that simply cannot be identified as being part of say the dev final integration test environment without the addition of something like a fact. Nothing native to the server such as the host name would be of any use. By dropping a file in /etc/profile.d using the environmental variable feature of facter looked like a real easy way to create the metadata I need. Now that I know this approach will not work I will use option 2 and go on with life. Its not a big deal I was just confused for a little bit.Does "server" mean "puppet server" or "puppet client that serving something not related to puppet"?> > On Tue, Nov 9, 2010 at 7:29 PM, Nigel Kersten <nigel@puppetlabs.com> wrote: > On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.account@gmail.com> wrote: > > ok - that makes sense, but why does facter have a feature > > http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter > > where you can expose environmental variables as facts if puppet will not > > recognize the facts? Is the issue because of the old version of facter I am > > using? > > Most times I''ve seen people use this functionality has been with > puppetd in non-daemon mode. > > FACTER_foo="woot" puppetd --onetime --verbose --no-daemonize > > Plus, this works well with standalone "puppet" applying local > manifests too. It looks like things aren''t so simple in daemon mode. > > Is there a reason you''re not actually doing this as a real fact? > > > > > Thanks > > > > Ed > > > > On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote: > >> Hi Ed, > >> > >> You are correct that the environment will not get imported into puppet. > >> When you restart the puppet daemon, you are missing your custom fact because > >> daemon will run as its own process with its own environment, so just > >> exporting the variable will only effect your current running environment and > >> not the puppet daemon environment. As such, the behavior your are seeing is > >> expected. > >> > >> > >> Looking around, I think this looks like a better way to get facts in: > >> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts > >> > >> This will allow you to get some level of synchronization of your custom > >> facts from your master to your clients in a much cleaner way. > >> > >> > >> Hope this helps. > >> > >> Zach > >> > >> > >> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey > >> eds.mailing.list.account@gmail.com> wrote: > >> > >> I am having a great deal of trouble using a custom fact in a module and I > >> am hoping someone can help me out. > >> > >> > >> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these are > >> really old versions. > >> > >> The custom fact is defined using an environmental variable > >> > >> > >> export FACTER_VERTICAL="dev fit" > >> > >> and I can see the fact in the output of facter > >> > >> [xxxxx ~]# facter | grep -i vertical > >> vertical => dev fit > >> > >> In the module I am trying to use the fact in the following way > >> > >> > >> > >> file { "/etc/yum.repos.d/env32-envision.repo": > >> ensure => present, > >> mode => 0664, > >> owner => root, > >> group => root, > >> > >> > >> content => $vertical ? { > >> "dev fit" => > >> template("ads_yum2/env32-dev-fit.repo.erb"), > >> default => > >> template("ads_yum2/env32-dev-staging.repo.erb"), > >> > >> > >> require => File["/etc/yum.repos.d/base_os.repo"], > >> } > >> } > >> > >> When I restart puppet the output is the default option instead of the "dev > >> fit" option. If I run puppet interactively "puppetd --debug --test" I get > >> the correct output based on the custom fact. I understand that puppet will > >> not inherent environmental variables but since the fact is present I thought > >> this approach would work. Am I wrong? > >> > >> > >> > >> I have been banging my head against the wall over this for some time. I > >> appreciate any input. > >> > >> Thanks > >> > >> Ed > >> > >> > >> > >> > >> > >> -- > >> > >> You received this message because you are subscribed to the Google Groups > >> "Puppet Users" group. > >> > >> To post to this group, send email to puppet-users@googlegroups.com. > >> > >> To unsubscribe from this group, send email to > >> puppet-users+unsubscribe@googlegroups.com. > >> > >> > >> For more options, visit this group at > >> http://groups.google.com/group/puppet-users?hl=en. > >> > >> > >> > >> > >> > >> > >> -- > >> Zach > >> zach@puppetlabs.com > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> You received this message because you are subscribed to the Google Groups > >> "Puppet Users" group. > >> > >> To post to this group, send email to puppet-users@googlegroups.com. > >> > >> To unsubscribe from this group, send email to > >> puppet-users+unsubscribe@googlegroups.com. > >> > >> > >> For more options, visit this group at > >> http://groups.google.com/group/puppet-users?hl=en. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Nigel Kersten - Puppet Labs - http://www.puppetlabs.com > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nigel Kersten
2010-Nov-10 02:21 UTC
Re: Re: [Puppet Users] question about custom facts and environmental variables
On Tue, Nov 9, 2010 at 6:01 PM, Edward Bailey <eds.mailing.list.account@gmail.com> wrote:> The purpose behind setting up the fact this way is that I thought it would > be an easy way to populate servers with extra metadata without having to > drop a file and then a fact with some shell code on every server. > > For example, we have a number of servers that simply cannot be identified as > being part of say the dev final integration test environment without the > addition of something like a fact. Nothing native to the server such as the > host name would be of any use. By dropping a file in /etc/profile.d using > the environmental variable feature of facter looked like a real easy way to > create the metadata I need. Now that I know this approach will not work I > will use option 2 and go on with life. Its not a big deal I was just > confused for a little bit.Ahah. So I suggest you try something different. * make /etc/facts.d/ * write a fact that looks for files here, and makes "real" facts based on the file name and contents. Then you can just drop files there and get the same result. Do you feel like updating the wiki to point out the limitations with puppet in daemon mode and the FACTER_* environment variables Edward?> > Thanks again > > Ed > > On Tue, Nov 9, 2010 at 7:29 PM, Nigel Kersten <nigel@puppetlabs.com> wrote: >> >> On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.account@gmail.com> >> wrote: >> > ok - that makes sense, but why does facter have a feature >> > >> > http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter >> > where you can expose environmental variables as facts if puppet will not >> > recognize the facts? Is the issue because of the old version of facter I >> > am >> > using? >> >> Most times I''ve seen people use this functionality has been with >> puppetd in non-daemon mode. >> >> FACTER_foo="woot" puppetd --onetime --verbose --no-daemonize >> >> Plus, this works well with standalone "puppet" applying local >> manifests too. It looks like things aren''t so simple in daemon mode. >> >> Is there a reason you''re not actually doing this as a real fact? >> >> > >> > Thanks >> > >> > Ed >> > >> > On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote: >> >> Hi Ed, >> >> >> >> You are correct that the environment will not get imported into puppet. >> >> When you restart the puppet daemon, you are missing your custom fact >> >> because >> >> daemon will run as its own process with its own environment, so just >> >> exporting the variable will only effect your current running >> >> environment and >> >> not the puppet daemon environment. As such, the behavior your are >> >> seeing is >> >> expected. >> >> >> >> >> >> Looking around, I think this looks like a better way to get facts in: >> >> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts >> >> >> >> This will allow you to get some level of synchronization of your custom >> >> facts from your master to your clients in a much cleaner way. >> >> >> >> >> >> Hope this helps. >> >> >> >> Zach >> >> >> >> >> >> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey >> >> eds.mailing.list.account@gmail.com> wrote: >> >> >> >> I am having a great deal of trouble using a custom fact in a module and >> >> I >> >> am hoping someone can help me out. >> >> >> >> >> >> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these >> >> are >> >> really old versions. >> >> >> >> The custom fact is defined using an environmental variable >> >> >> >> >> >> export FACTER_VERTICAL="dev fit" >> >> >> >> and I can see the fact in the output of facter >> >> >> >> [xxxxx ~]# facter | grep -i vertical >> >> vertical => dev fit >> >> >> >> In the module I am trying to use the fact in the following way >> >> >> >> >> >> >> >> file { "/etc/yum.repos.d/env32-envision.repo": >> >> ensure => present, >> >> mode => 0664, >> >> owner => root, >> >> group => root, >> >> >> >> >> >> content => $vertical ? { >> >> "dev fit" => >> >> template("ads_yum2/env32-dev-fit.repo.erb"), >> >> default => >> >> template("ads_yum2/env32-dev-staging.repo.erb"), >> >> >> >> >> >> require => File["/etc/yum.repos.d/base_os.repo"], >> >> } >> >> } >> >> >> >> When I restart puppet the output is the default option instead of the >> >> "dev >> >> fit" option. If I run puppet interactively "puppetd --debug --test" I >> >> get >> >> the correct output based on the custom fact. I understand that puppet >> >> will >> >> not inherent environmental variables but since the fact is present I >> >> thought >> >> this approach would work. Am I wrong? >> >> >> >> >> >> >> >> I have been banging my head against the wall over this for some time. I >> >> appreciate any input. >> >> >> >> Thanks >> >> >> >> Ed >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "Puppet Users" group. >> >> >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> >> >> To unsubscribe from this group, send email to >> >> puppet-users+unsubscribe@googlegroups.com. >> >> >> >> >> >> For more options, visit this group at >> >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Zach >> >> zach@puppetlabs.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "Puppet Users" group. >> >> >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> >> >> To unsubscribe from this group, send email to >> >> puppet-users+unsubscribe@googlegroups.com. >> >> >> >> >> >> For more options, visit this group at >> >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "Puppet Users" group. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> >> >> >> -- >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Edward Bailey
2010-Nov-10 04:36 UTC
Re: [Puppet Users] question about custom facts and environmental variables
server means the hardware that the puppet client manages On Tue, Nov 9, 2010 at 9:06 PM, Patrick <kc7zzv@gmail.com> wrote:> > On Nov 9, 2010, at 6:01 PM, Edward Bailey wrote: > > The purpose behind setting up the fact this way is that I thought it would > be an easy way to populate servers with extra metadata without having to > drop a file and then a fact with some shell code on every server. > > For example, we have a number of servers that simply cannot be identified > as being part of say the dev final integration test environment without the > addition of something like a fact. Nothing native to the server such as the > host name would be of any use. By dropping a file in /etc/profile.d using > the environmental variable feature of facter looked like a real easy way to > create the metadata I need. Now that I know this approach will not work I > will use option 2 and go on with life. Its not a big deal I was just > confused for a little bit. > > > Does "server" mean "puppet server" or "puppet client that serving something > not related to puppet"? > > > On Tue, Nov 9, 2010 at 7:29 PM, Nigel Kersten <nigel@puppetlabs.com>wrote: > >> On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.account@gmail.com> >> wrote: >> > ok - that makes sense, but why does facter have a feature >> > >> http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter >> > where you can expose environmental variables as facts if puppet will not >> > recognize the facts? Is the issue because of the old version of facter I >> am >> > using? >> >> Most times I''ve seen people use this functionality has been with >> puppetd in non-daemon mode. >> >> FACTER_foo="woot" puppetd --onetime --verbose --no-daemonize >> >> Plus, this works well with standalone "puppet" applying local >> manifests too. It looks like things aren''t so simple in daemon mode. >> >> Is there a reason you''re not actually doing this as a real fact? >> >> > >> > Thanks >> > >> > Ed >> > >> > On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote: >> >> Hi Ed, >> >> >> >> You are correct that the environment will not get imported into puppet. >> >> When you restart the puppet daemon, you are missing your custom fact >> because >> >> daemon will run as its own process with its own environment, so just >> >> exporting the variable will only effect your current running >> environment and >> >> not the puppet daemon environment. As such, the behavior your are >> seeing is >> >> expected. >> >> >> >> >> >> Looking around, I think this looks like a better way to get facts in: >> >> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts >> >> >> >> This will allow you to get some level of synchronization of your custom >> >> facts from your master to your clients in a much cleaner way. >> >> >> >> >> >> Hope this helps. >> >> >> >> Zach >> >> >> >> >> >> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey >> >> eds.mailing.list.account@gmail.com> wrote: >> >> >> >> I am having a great deal of trouble using a custom fact in a module and >> I >> >> am hoping someone can help me out. >> >> >> >> >> >> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these >> are >> >> really old versions. >> >> >> >> The custom fact is defined using an environmental variable >> >> >> >> >> >> export FACTER_VERTICAL="dev fit" >> >> >> >> and I can see the fact in the output of facter >> >> >> >> [xxxxx ~]# facter | grep -i vertical >> >> vertical => dev fit >> >> >> >> In the module I am trying to use the fact in the following way >> >> >> >> >> >> >> >> file { "/etc/yum.repos.d/env32-envision.repo": >> >> ensure => present, >> >> mode => 0664, >> >> owner => root, >> >> group => root, >> >> >> >> >> >> content => $vertical ? { >> >> "dev fit" => >> >> template("ads_yum2/env32-dev-fit.repo.erb"), >> >> default => >> >> template("ads_yum2/env32-dev-staging.repo.erb"), >> >> >> >> >> >> require => File["/etc/yum.repos.d/base_os.repo"], >> >> } >> >> } >> >> >> >> When I restart puppet the output is the default option instead of the >> "dev >> >> fit" option. If I run puppet interactively "puppetd --debug --test" I >> get >> >> the correct output based on the custom fact. I understand that puppet >> will >> >> not inherent environmental variables but since the fact is present I >> thought >> >> this approach would work. Am I wrong? >> >> >> >> >> >> >> >> I have been banging my head against the wall over this for some time. I >> >> appreciate any input. >> >> >> >> Thanks >> >> >> >> Ed >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> You received this message because you are subscribed to the Google >> Groups >> >> "Puppet Users" group. >> >> >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> >> >> To unsubscribe from this group, send email to >> >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> >> . >> >> >> >> >> >> For more options, visit this group at >> >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Zach >> >> zach@puppetlabs.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> You received this message because you are subscribed to the Google >> Groups >> >> "Puppet Users" group. >> >> >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> >> >> To unsubscribe from this group, send email to >> >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> >> . >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> >> >> >> -- >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Edward Bailey
2010-Nov-10 04:40 UTC
Re: Re: [Puppet Users] question about custom facts and environmental variables
Sure I can update the wiki - I hope I can save some else time the next time this come up. I like your suggestion, but I cant quite visualize how I could write a fact that will parse any files in /etc/fact.s and create separate facts from the output. Would I use some sort of loop or will facter parse an array? Thanks Ed> Ahah. So I suggest you try something different. > > * make /etc/facts.d/ > * write a fact that looks for files here, and makes "real" facts based > on the file name and contents. > > Then you can just drop files there and get the same result. > > Do you feel like updating the wiki to point out the limitations with > puppet in daemon mode and the FACTER_* environment variables Edward? > > > > > Thanks again > > > > Ed > > > > On Tue, Nov 9, 2010 at 7:29 PM, Nigel Kersten <nigel@puppetlabs.com> > wrote: > >> > >> On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.account@gmail.com> > >> wrote: > >> > ok - that makes sense, but why does facter have a feature > >> > > >> > > http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter > >> > where you can expose environmental variables as facts if puppet will > not > >> > recognize the facts? Is the issue because of the old version of facter > I > >> > am > >> > using? > >> > >> Most times I''ve seen people use this functionality has been with > >> puppetd in non-daemon mode. > >> > >> FACTER_foo="woot" puppetd --onetime --verbose --no-daemonize > >> > >> Plus, this works well with standalone "puppet" applying local > >> manifests too. It looks like things aren''t so simple in daemon mode. > >> > >> Is there a reason you''re not actually doing this as a real fact? > >> > >> > > >> > Thanks > >> > > >> > Ed > >> > > >> > On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote: > >> >> Hi Ed, > >> >> > >> >> You are correct that the environment will not get imported into > puppet. > >> >> When you restart the puppet daemon, you are missing your custom fact > >> >> because > >> >> daemon will run as its own process with its own environment, so just > >> >> exporting the variable will only effect your current running > >> >> environment and > >> >> not the puppet daemon environment. As such, the behavior your are > >> >> seeing is > >> >> expected. > >> >> > >> >> > >> >> Looking around, I think this looks like a better way to get facts in: > >> >> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts > >> >> > >> >> This will allow you to get some level of synchronization of your > custom > >> >> facts from your master to your clients in a much cleaner way. > >> >> > >> >> > >> >> Hope this helps. > >> >> > >> >> Zach > >> >> > >> >> > >> >> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey > >> >> eds.mailing.list.account@gmail.com> wrote: > >> >> > >> >> I am having a great deal of trouble using a custom fact in a module > and > >> >> I > >> >> am hoping someone can help me out. > >> >> > >> >> > >> >> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know these > >> >> are > >> >> really old versions. > >> >> > >> >> The custom fact is defined using an environmental variable > >> >> > >> >> > >> >> export FACTER_VERTICAL="dev fit" > >> >> > >> >> and I can see the fact in the output of facter > >> >> > >> >> [xxxxx ~]# facter | grep -i vertical > >> >> vertical => dev fit > >> >> > >> >> In the module I am trying to use the fact in the following way > >> >> > >> >> > >> >> > >> >> file { "/etc/yum.repos.d/env32-envision.repo": > >> >> ensure => present, > >> >> mode => 0664, > >> >> owner => root, > >> >> group => root, > >> >> > >> >> > >> >> content => $vertical ? { > >> >> "dev fit" => > >> >> template("ads_yum2/env32-dev-fit.repo.erb"), > >> >> default => > >> >> template("ads_yum2/env32-dev-staging.repo.erb"), > >> >> > >> >> > >> >> require => File["/etc/yum.repos.d/base_os.repo"], > >> >> } > >> >> } > >> >> > >> >> When I restart puppet the output is the default option instead of the > >> >> "dev > >> >> fit" option. If I run puppet interactively "puppetd --debug --test" I > >> >> get > >> >> the correct output based on the custom fact. I understand that puppet > >> >> will > >> >> not inherent environmental variables but since the fact is present I > >> >> thought > >> >> this approach would work. Am I wrong? > >> >> > >> >> > >> >> > >> >> I have been banging my head against the wall over this for some time. > I > >> >> appreciate any input. > >> >> > >> >> Thanks > >> >> > >> >> Ed > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "Puppet Users" group. > >> >> > >> >> To post to this group, send email to puppet-users@googlegroups.com. > >> >> > >> >> To unsubscribe from this group, send email to > >> >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > >> >> > >> >> > >> >> For more options, visit this group at > >> >> http://groups.google.com/group/puppet-users?hl=en. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Zach > >> >> zach@puppetlabs.com > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "Puppet Users" group. > >> >> > >> >> To post to this group, send email to puppet-users@googlegroups.com. > >> >> > >> >> To unsubscribe from this group, send email to > >> >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > >> > For more options, visit this group at > >> > http://groups.google.com/group/puppet-users?hl=en. > >> > > >> > >> > >> > >> -- > >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Puppet Users" group. > >> To post to this group, send email to puppet-users@googlegroups.com. > >> To unsubscribe from this group, send email to > >> puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Nigel Kersten - Puppet Labs - http://www.puppetlabs.com > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Nigel Kersten
2010-Nov-10 05:17 UTC
Re: Re: [Puppet Users] question about custom facts and environmental variables
On Tue, Nov 9, 2010 at 8:40 PM, Edward Bailey <eds.mailing.list.account@gmail.com> wrote:> Sure I can update the wiki - I hope I can save some else time the next time > this come up. > > I like your suggestion, but I cant quite visualize how I could write a fact > that will parse any files in /etc/fact.s and create separate facts from the > output. Would I use some sort of loop or will facter parse an array?Have a look at our docs on custom facts: http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts as they''re really quite easy to whip up. and because I''m feeling lazy, here''s a thing I posted a while ago for someone who wanted to create facts named after lines in a file, all with the value "true" webapps_conf = "/etc/webapps.conf" if File.readable?(webapps_conf) f = File.open(webapps_conf, ''r'') f.readlines.each do |line| webapp = line.chomp Facter.add("webapp_#{webapp}_enabled") do setcode do "true" end end end f.close end so you can see how you can create facts while in a loop. You''ll want to probably instead loop over the contents of a directory, check you can read the file, and make a fact with the name of the file, and return the contents of the file as the value.> > Thanks > > Ed > > > >> >> Ahah. So I suggest you try something different. >> >> * make /etc/facts.d/ >> * write a fact that looks for files here, and makes "real" facts based >> on the file name and contents. >> >> Then you can just drop files there and get the same result. >> >> Do you feel like updating the wiki to point out the limitations with >> puppet in daemon mode and the FACTER_* environment variables Edward? >> >> > >> > Thanks again >> > >> > Ed >> > >> > On Tue, Nov 9, 2010 at 7:29 PM, Nigel Kersten <nigel@puppetlabs.com> >> > wrote: >> >> >> >> On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.account@gmail.com> >> >> wrote: >> >> > ok - that makes sense, but why does facter have a feature >> >> > >> >> > >> >> > http://docs.puppetlabs.com/guides/faq.html#can-i-access-environmental-variables-with-facter >> >> > where you can expose environmental variables as facts if puppet will >> >> > not >> >> > recognize the facts? Is the issue because of the old version of >> >> > facter I >> >> > am >> >> > using? >> >> >> >> Most times I''ve seen people use this functionality has been with >> >> puppetd in non-daemon mode. >> >> >> >> FACTER_foo="woot" puppetd --onetime --verbose --no-daemonize >> >> >> >> Plus, this works well with standalone "puppet" applying local >> >> manifests too. It looks like things aren''t so simple in daemon mode. >> >> >> >> Is there a reason you''re not actually doing this as a real fact? >> >> >> >> > >> >> > Thanks >> >> > >> >> > Ed >> >> > >> >> > On Nov 9, 2010 5:45pm, Zach Leslie <zach@puppetlabs.com> wrote: >> >> >> Hi Ed, >> >> >> >> >> >> You are correct that the environment will not get imported into >> >> >> puppet. >> >> >> When you restart the puppet daemon, you are missing your custom fact >> >> >> because >> >> >> daemon will run as its own process with its own environment, so just >> >> >> exporting the variable will only effect your current running >> >> >> environment and >> >> >> not the puppet daemon environment. As such, the behavior your are >> >> >> seeing is >> >> >> expected. >> >> >> >> >> >> >> >> >> Looking around, I think this looks like a better way to get facts >> >> >> in: >> >> >> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts >> >> >> >> >> >> This will allow you to get some level of synchronization of your >> >> >> custom >> >> >> facts from your master to your clients in a much cleaner way. >> >> >> >> >> >> >> >> >> Hope this helps. >> >> >> >> >> >> Zach >> >> >> >> >> >> >> >> >> On Mon, Nov 8, 2010 at 5:42 PM, Edward Bailey >> >> >> eds.mailing.list.account@gmail.com> wrote: >> >> >> >> >> >> I am having a great deal of trouble using a custom fact in a module >> >> >> and >> >> >> I >> >> >> am hoping someone can help me out. >> >> >> >> >> >> >> >> >> I am using facter-1.5.0-2.el4 and puppet-0.24.5-1.el4. I know >> >> >> these >> >> >> are >> >> >> really old versions. >> >> >> >> >> >> The custom fact is defined using an environmental variable >> >> >> >> >> >> >> >> >> export FACTER_VERTICAL="dev fit" >> >> >> >> >> >> and I can see the fact in the output of facter >> >> >> >> >> >> [xxxxx ~]# facter | grep -i vertical >> >> >> vertical => dev fit >> >> >> >> >> >> In the module I am trying to use the fact in the following way >> >> >> >> >> >> >> >> >> >> >> >> file { "/etc/yum.repos.d/env32-envision.repo": >> >> >> ensure => present, >> >> >> mode => 0664, >> >> >> owner => root, >> >> >> group => root, >> >> >> >> >> >> >> >> >> content => $vertical ? { >> >> >> "dev fit" => >> >> >> template("ads_yum2/env32-dev-fit.repo.erb"), >> >> >> default => >> >> >> template("ads_yum2/env32-dev-staging.repo.erb"), >> >> >> >> >> >> >> >> >> require => File["/etc/yum.repos.d/base_os.repo"], >> >> >> } >> >> >> } >> >> >> >> >> >> When I restart puppet the output is the default option instead of >> >> >> the >> >> >> "dev >> >> >> fit" option. If I run puppet interactively "puppetd --debug --test" >> >> >> I >> >> >> get >> >> >> the correct output based on the custom fact. I understand that >> >> >> puppet >> >> >> will >> >> >> not inherent environmental variables but since the fact is present I >> >> >> thought >> >> >> this approach would work. Am I wrong? >> >> >> >> >> >> >> >> >> >> >> >> I have been banging my head against the wall over this for some >> >> >> time. I >> >> >> appreciate any input. >> >> >> >> >> >> Thanks >> >> >> >> >> >> Ed >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> You received this message because you are subscribed to the Google >> >> >> Groups >> >> >> "Puppet Users" group. >> >> >> >> >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> >> >> >> >> To unsubscribe from this group, send email to >> >> >> puppet-users+unsubscribe@googlegroups.com. >> >> >> >> >> >> >> >> >> For more options, visit this group at >> >> >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Zach >> >> >> zach@puppetlabs.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> You received this message because you are subscribed to the Google >> >> >> Groups >> >> >> "Puppet Users" group. >> >> >> >> >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> >> >> >> >> To unsubscribe from this group, send email to >> >> >> puppet-users+unsubscribe@googlegroups.com. >> >> >> >> >> >> >> >> >> For more options, visit this group at >> >> >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> >> >> > >> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "Puppet Users" group. >> >> > To post to this group, send email to puppet-users@googlegroups.com. >> >> > To unsubscribe from this group, send email to >> >> > puppet-users+unsubscribe@googlegroups.com. >> >> > For more options, visit this group at >> >> > http://groups.google.com/group/puppet-users?hl=en. >> >> > >> >> >> >> >> >> >> >> -- >> >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "Puppet Users" group. >> >> To post to this group, send email to puppet-users@googlegroups.com. >> >> To unsubscribe from this group, send email to >> >> puppet-users+unsubscribe@googlegroups.com. >> >> For more options, visit this group at >> >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "Puppet Users" group. >> > To post to this group, send email to puppet-users@googlegroups.com. >> > To unsubscribe from this group, send email to >> > puppet-users+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> > http://groups.google.com/group/puppet-users?hl=en. >> > >> >> >> >> -- >> Nigel Kersten - Puppet Labs - http://www.puppetlabs.com >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Nigel Kersten - Puppet Labs - http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.