On Tue, Nov 9, 2010 at 6:01 PM, Edward Bailey <eds.mailing.list.acco...@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 <ni...@puppetlabs.com> wrote: >> >> On Tue, Nov 9, 2010 at 3:45 PM, <eds.mailing.list.acco...@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 <z...@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.acco...@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-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. >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Zach >> >> z...@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-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. >> > >> >> >> >> -- >> 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-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. > -- 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-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.
