Often, we are faced with the problem that standard facts that come with puppet are not always enough. The solution to this problem can be achieved by adding new facts. You can add your own Ruby facts to the puppet server. Then the server, using synchronization plug-ins, will distribute them to all clients.
In order to see all the facts that are now on the client, use the command facter -p
What are the facts you can see at the beginning of the
article by
BadooExample
Suppose we need to get the output of the uname -i command to determine the system capacity. For this we need to create a fact. Let's call our fact hardware_platform, and create hardware_platform.rb, on the Puppet server:
')
{modulepath}
{── {module}
Lib── lib
Fac── facter
Facts in Facts
We can use factual values ​​when writing our own using the Facter.value (“somefact”) or Facter.somefact construct. In the absence of a fact, the first will return 0, and the second exception.
Facter.add("osfamily") do setcode do distid = Facter.value('lsbdistid') case distid when /RedHatEnterprise|CentOS|Fedora/ "redhat" when "ubuntu" "debian" else distid end end end
Now after the next launch of the agent puppet on the client, the fact will become available.
Comment
On the puppet server and client in the [main] section there should be an option
pluginsync = true
Customize the facts.
Facts have several parameters that can be used to fine-tune facts.
Timeout
If your fact is unreliable and cannot always shut down correctly, you can use timeout. If the execution time of the setcode block is longer than the timeout, Facter will interrupt the process and assign the value specified on the error to the fact.
Caching
If the facts do not change for some time or it takes a long time to find them, they can be cached. To do this, we need to add the option ': ttl' when declaring a fact
Facter.add("mylongoperation", :ttl => 600) do setcode do ... ... end end
0 - never cache. The default behavior.
-1 - Cash forever. Useful for one-time operations. For example: the name of the distribution.
Importance of facts
Facts have a parameter - weight. Facts with more weight are performed before
Limiting facts
We can limit the execution of facts on the basis of other facts with the help of the parameter - confine.
For example, finding a fact only if the system kernel is Linux.
Facter.add(:powerstates) do confine :kernel => "Linux" setcode do Facter::Util::Resolution.exec('cat /sys/power/states') end end