custom fact should not run on Solaris

95 views
Skip to first unread message

Andreas Dvorak

unread,
Dec 18, 2013, 9:29:39 AM12/18/13
to puppet...@googlegroups.com
Dear all

I have a module spacewalk with a custom fact to define if the server has been registered to spacewalk.
The module should only run on RedHat server

class profiles::base {
...
  case $::osfamily {
    redhat:{
      include spacewalk
      include logrotate
      include postfix
    }
    solaris:{
      include sendmail
    }
    default:{
      fail("Unsupported platform: ${::osfamily}")
    }
  }
}

but the fact of the module spacewalk is run on Solaris.
bash-3.00# /opt/csw/bin/facter osfamily   
Solaris
bash-3.00# /opt/csw/bin/puppet agent --test
Info: Retrieving plugin
Notice: /File[/var/opt/csw/puppet/lib/facter/spacewalk.rb]/ensure: defined content as '{md5}9aea0fbd79bc329b3685b7cfd22a5809'

I have another custom fact that should only run on certain server but it is installed on every server.
Can you please help me?
Are facts always installed on every server even if the module of the fact in only installed on certain server?

Best regards,
Andreas

Jeff Bachtel

unread,
Dec 18, 2013, 10:34:39 AM12/18/13
to puppet...@googlegroups.com
Facts are autoloaded from all modules and distributed to all agents,
because that step occurs before the DSL is parsed for manifests (as it
should be, because the DSL can be (is) impacted by facts).

It is up to the custom fact to case itself out of execution for certain
operating systems. For instance, from the postgresql pupmod comes this
snippet from the customer fact about default versions:

Facter.add("postgres_default_version") do
setcode do
result =
case Facter.value('osfamily')
when 'RedHat'
get_redhatfamily_postgres_version()
when 'Linux'
get_redhatfamily_postgres_version()
when 'Debian'
get_debianfamily_postgres_version()
else
nil
end

Jeff
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/95b66593-0ff9-4ffe-b54c-963bb84f7010%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Felix Frank

unread,
Dec 18, 2013, 10:40:15 AM12/18/13
to puppet...@googlegroups.com
Yes, exactly, but this begs the question: Am I out of date for adding

confine :operatingsystem => %w{Debian SLES OpenSUSE CentOS}

outside the setcode block?

Thanks,
Felix

Jeff Bachtel

unread,
Dec 18, 2013, 12:35:48 PM12/18/13
to puppet...@googlegroups.com
I think that pattern's still good. Possibly that's the difference
between a nil fact being set and the fact being missing, however.

Jeff

Andreas Dvorak

unread,
Dec 19, 2013, 8:26:49 AM12/19/13
to puppet...@googlegroups.com
Dear all

thank you for helping me.
My solution is this:
require 'facter'
Facter.add(:spacewalk) do
  confine :osfamily => "RedHat"
    f = File.new("/etc/sysconfig/rhn/up2date")
    text = f.read
    if text =~ /sv2653/ then
      setcode do "true" end
    else
      setcode do "false" end
    end
end

Best regards
Andreas

Erik Dalén

unread,
Dec 19, 2013, 11:26:05 AM12/19/13
to puppet...@googlegroups.com
you should put the code of the fact inside the setcode block, so:

require 'facter'
Facter.add(:spacewalk) do
  confine :osfamily => "RedHat"
  setcode do
    f = File.new("/etc/sysconfig/rhn/up2date")
    text = f.read
    if text =~ /sv2653/ then
      "true"
    else
      "false"
    end
  end
end

or even simplify it to:

require 'facter'
Facter.add(:spacewalk) do
  confine :osfamily => "RedHat"
  setcode { !!(File.read("/etc/sysconfig/rhn/up2date") =~ /sv2653/) }
end



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

For more options, visit https://groups.google.com/groups/opt_out.



--
Erik Dalén
Reply all
Reply to author
Forward
0 new messages