Perhaps my logic isn''t that good here and I shouldn''t be using
a custom fact at all but what I am trying to do is ascertain which version of
the passenger gem is actually installed because I need to reference it in
various places in apache & nginx configuration (the specific location of the
passenger binary).
but my erb fails because the fact $passenger_version hasn''t been
created yet.
so I tried...
file {"/etc/apache2/mods-enabled/passenger.load":
... snip ...
require => Facter["datacenter"],
}
and in /etc/puppet/modules/custom/lib/facter/datacenter.rb I have
Facter.add("datacenter") do
setcode do
datacenter = "unknown"
# Get current ip address from Facter''s own database
ipaddr = Facter.value(:ipaddress)
... snip ...
datacenter
end
end
#
# Provide an additional ''passenger_version'' fact
# to use in apache & nginx modules
#
Facter.add("passenger_version") do
setcode do
passenger_version = "unknown"
exec(''/usr/local/bin/passenger --version >
/tmp/passenger_version'')
passenger_version =
"File.open(''/tmp/passenger_version'',
&:readline).chomp.split('' '').last"
passenger_version
end
end
but it never seems to add the ''passenger_version'' fact
1. How can I make sure that the fact is ascertained before the template file is
parsed?
2. If I am setting up a new system, passenger won''t be installed until
some point in the declarative process and at that point, how would I ensure that
the fact is ascertained?
Thanks
--
Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com
1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com
Need help communicating between generations at work to achieve your desired
success? Let us help!
--
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.
Hi, What I do is a little different for zmanda. I have a fact that looks for a local release file that contains the version number installed. If that file doesn''t exist then it returns 0.0.0. The version file is created after the successful install. I thought the gem provider was anyway? Can''t you pass the version in the package declaration? Cheers, Den On 25/06/2011, at 8:12, Craig White <craig.white@ttiltd.com> wrote:> Perhaps my logic isn''t that good here and I shouldn''t be using a custom fact at all but what I am trying to do is ascertain which version of the passenger gem is actually installed because I need to reference it in various places in apache & nginx configuration (the specific location of the passenger binary). > > but my erb fails because the fact $passenger_version hasn''t been created yet. > > so I tried... > > file {"/etc/apache2/mods-enabled/passenger.load": > ... snip ... > require => Facter["datacenter"], > } > > and in /etc/puppet/modules/custom/lib/facter/datacenter.rb I have > > Facter.add("datacenter") do > setcode do > datacenter = "unknown" > # Get current ip address from Facter''s own database > ipaddr = Facter.value(:ipaddress) > ... snip ... > datacenter > end > end > # > # Provide an additional ''passenger_version'' fact > # to use in apache & nginx modules > # > > Facter.add("passenger_version") do > setcode do > passenger_version = "unknown" > exec(''/usr/local/bin/passenger --version > /tmp/passenger_version'') > passenger_version = "File.open(''/tmp/passenger_version'', &:readline).chomp.split('' '').last" > passenger_version > end > end > > but it never seems to add the ''passenger_version'' fact > > 1. How can I make sure that the fact is ascertained before the template file is parsed? > > 2. If I am setting up a new system, passenger won''t be installed until some point in the declarative process and at that point, how would I ensure that the fact is ascertained? > > Thanks > > -- > Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white@ttiltd.com > 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com > > Need help communicating between generations at work to achieve your desired success? Let us help! > > -- > 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.
On Jun 24, 2011, at 3:40 PM, Denmat wrote:> Hi, > > What I do is a little different for zmanda. > > I have a fact that looks for a local release file that contains the version number installed. If that file doesn''t exist then it returns 0.0.0. > > The version file is created after the successful install. > > I thought the gem provider was anyway? Can''t you pass the version in the package declaration?----- getting the version isn''t exactly the problem and yes, the version is in the package installation set - which I plan to revisit later because it seems that when it comes to gem packages, ''ensure => latest'' didn''t seem to work but I didn''t want to waste time on that. My issues seem to be... 1. I want to require => /etc/puppet/modules/custom/lib/facter/$SOME_CUSTOM_FACT is actually executed and the fact is established before a particular package is installed/configured. I can''t seem to find the proper syntax for requiring that fact first - before the attempted installation. 2. It seems that the custom/lib/facter directory is a bit squirrelly in that it gags on the automatic backup files created by emacs (FILENAME.rb~) and if I create a resource that depends upon a fact, the resource installation fails and the fact is never established when I was sort of expecting facter to run at the outset of any agent activity. Craig -- 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.
On Fri, Jun 24, 2011 at 4:28 PM, Craig White <craig.white@ttiltd.com> wrote:> 1. I want to require => /etc/puppet/modules/custom/lib/facter/$SOME_CUSTOM_FACT is actually executed and the fact is established before a particular package is installed/configured. I can''t seem to find the proper syntax for requiring that fact first - before the attempted installation.If you''re distributing facts as plugins in modules like this, the pluginsync should cause the fact to be evaluated before the manifests are parsed and the catalog is compiled. Something is going wrong if you''re not getting your fact evaluated on first run. You definitely have pluginsync on on the node?> 2. It seems that the custom/lib/facter directory is a bit squirrelly in that it gags on the automatic backup files created by emacs (FILENAME.rb~) and if I create a resource that depends upon a fact, the resource installation fails and the fact is never established when I was sort of expecting facter to run at the outset of any agent activity.Best practice in my opinion is to have all this in version control, and have your version control system ignore all such backup files, but it might be worth reporting a feature request to automatically exclude the common text editor backup files. -- 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.
On Sat, Jun 25, 2011 at 07:51, Nigel Kersten <nigel@puppetlabs.com> wrote:> On Fri, Jun 24, 2011 at 4:28 PM, Craig White <craig.white@ttiltd.com> wrote:[…]>> 2. It seems that the custom/lib/facter directory is a bit squirrelly in that it gags on the automatic backup files created by emacs (FILENAME.rb~) and if I create a resource that depends upon a fact, the resource installation fails and the fact is never established when I was sort of expecting facter to run at the outset of any agent activity. > > Best practice in my opinion is to have all this in version control, > and have your version control system ignore all such backup files, but > it might be worth reporting a feature request to automatically exclude > the common text editor backup files.Regardless of that, if you can submit a bug report about the failure, that would be excellent. Facter *shouldn''t* be that easy to break. ;) (Facter does run at the outset of any activity, and again after pluginsync, as Nigel notes. :) Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <daniel@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sat, Jun 25, 2011 at 11:54 AM, Daniel Pittman <daniel@puppetlabs.com> wrote:> Regardless of that, if you can submit a bug report about the failure, > that would be excellent. Facter *shouldn''t* be that easy to break. ;)Ugh. I missed that there was an error in this case, and yes, we totally shouldn''t gag on such a common case. -- 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.
On Jun 25, 2011, at 7:51 AM, Nigel Kersten wrote:> On Fri, Jun 24, 2011 at 4:28 PM, Craig White <craig.white@ttiltd.com> wrote: > >> 1. I want to require => /etc/puppet/modules/custom/lib/facter/$SOME_CUSTOM_FACT is actually executed and the fact is established before a particular package is installed/configured. I can''t seem to find the proper syntax for requiring that fact first - before the attempted installation. > > If you''re distributing facts as plugins in modules like this, the > pluginsync should cause the fact to be evaluated before the manifests > are parsed and the catalog is compiled. > > Something is going wrong if you''re not getting your fact evaluated on > first run. You definitely have pluginsync on on the node?---- Got this solved - custom facts syntax seems to be a little particular about ''exec'' commands and apparently much prefers ''system'' commands and that is why I was having issues getting it to run - fixed now. Yes, I had pluginsync on the node. ----> >> 2. It seems that the custom/lib/facter directory is a bit squirrelly in that it gags on the automatic backup files created by emacs (FILENAME.rb~) and if I create a resource that depends upon a fact, the resource installation fails and the fact is never established when I was sort of expecting facter to run at the outset of any agent activity. > > Best practice in my opinion is to have all this in version control, > and have your version control system ignore all such backup files, but > it might be worth reporting a feature request to automatically exclude > the common text editor backup files.---- OK - starting up doesn''t always involve best practices ;-) In my case, I am racing to get up to a certain point and working with multiple VMWare images as my test bed and thus working full-time in a production mode and delaying the inevitable switch over to SVN and development & test modes. But I am sure that the issue will still remain in ''development'' and ''test'' modes if I actively edit in ''lib'' directories instead of on my own desktop and commit via SVN. This does however leave the last remaining chicken or the egg issue however and that is if I change the version in my passenger gem setup, it would take 2 separate runs of puppet agent... the first one to update the passenger gem and the next one to discover that ''fact'' before the changes are implemented into the nginx & apache templates. I suppose I can leave this messy for now unless someone has a methodology that I can syntactically require the custom ''fact'' to be applied immediately after the gem is updated but before the apache & nginx ''configure.pp'' is ''notified'' by passenger.pp. Thanks Craig -- 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.
On Jun 27, 12:44 pm, Craig White <craig.wh...@ttiltd.com> wrote:> On Jun 25, 2011, at 7:51 AM, Nigel Kersten wrote: > > > On Fri, Jun 24, 2011 at 4:28 PM, Craig White <craig.wh...@ttiltd.com> wrote: > > >> 1. I want to require => /etc/puppet/modules/custom/lib/facter/$SOME_CUSTOM_FACT is actually executed and the fact is established before a particular package is installed/configured. I can''t seem to find the proper syntax for requiring that fact first - before the attempted installation. > > > If you''re distributing facts as plugins in modules like this, the > > pluginsync should cause the fact to be evaluated before the manifests > > are parsed and the catalog is compiled. > > > Something is going wrong if you''re not getting your fact evaluated on > > first run. You definitely have pluginsync on on the node? > > ---- > Got this solved - custom facts syntax seems to be a little particular about ''exec'' commands and apparently much prefers ''system'' commands and that is why I was having issues getting it to run - fixed now. Yes, I had pluginsync on the node.This is not a peculiarity of custom facts. Ruby''s ''exec'' command (and the shell''s and the corresponding family of C functions, etc.) don''t just execute a command: they *replace* the currently running process with the specified command. Among other things, that means that the exec''ed command never returns (since there''s nothing for it to return to); its exit is instead the end of the program. There are excellent reasons to want that behavior under some circumstances (often in conjunction with ''fork''; at some level this is how ''system'' is implemented), but custom facts are not typically among those circumstances. Always choose ''system'' instead of ''exec'' unless you know exactly why you want the latter. Cheers, John -- 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.