Facter2 0 PDF

Facter 2.
0 Manual
(Generated on June 24, 2014, from git revision c72659a34a5c8ba1551b65ec02a6dd58c9213958)
Facter 2.0: Core Facts
Summary
This is a list of all of the built-in facts that ship with Facter 2.0.x. Not all of them apply to every
system, and your site may use many custom facts delivered via Puppet modules. To see the actual
available facts (including plugins) and their values on any of your systems, run facter -p at the
command line. If you are using Puppet Enterprise, you can view all of the facts for any node on the
nodes page in the console.
Facts appear in Puppet as normal top-scope variables. This means you can access any fact for a
node in your manifests with $<fact name>. (E.g. $osfamily, $memorysize, etc.)
architecture
Returns the CPU hardware architecture.
Resolution:
On OpenBSD, Linux and Debians kfreebsd, use the hardwaremodel fact.
Gentoo and Debian call x86_64 amd64.
Gentoo also calls i386 x86.
( Back to top)
augeasversion
Returns the version of the Augeas library.
Resolution:
Loads ruby-augeas and reports the value of /augeas/version, the version of the underlying
Augeas library.
Caveats:
The library version may not indicate the presence of certain lenses, depending on the system
packages updated, nor the version of ruby-augeas which may aect support for the Puppet Augeas
provider. Versions prior to 0.3.6 cannot be interrogated for their version.
( Back to top)
Facter 2.0 Manual Facter 2.0: Core Facts 2/46
blockdevice_{devicename}_size
Returns the size of a block device in bytes.
Resolution:
Parse the contents of /sys/block/{device}/size to receive the size (multiplying by 512 to correct
for blocks-to-bytes).
Caveats:
Only supports Linux 2.6+ at this time, due to the reliance on sysfs.
( Back to top)
blockdevice_{devicename}_vendor
Returns the vendor name of block devices attached to the system.
Resolution:
Parse the contents of /sys/block/{device}/device/vendor to retrieve the vendor for a device.
Caveats:
( Back to top)
blockdevice_{devicename}_model
Returns the model name of block devices attached to the system.
Resolution:
Parse the contents of /sys/block/{device}/device/model to retrieve the model name/number for
a device.
Caveats:
( Back to top)
blockdevices
Returns a comma-separated list of block devices.
Resolution:
Retrieve the block devices that were identied and iterated over in the creation of the blockdevice_
facts.
Caveats:
Block devices must have been identied using sysfs information
( Back to top)
boardmanufacturer
Returns the manufacturer of the machines motherboard.
( Back to top)
boardproductname
Returns the model name of the machines motherboard.
( Back to top)
boardserialnumber
Returns the serial number of the machines motherboard.
( Back to top)
cfkey
Returns the public key(s) for CFengine.
Resolution:
Tries each le of standard localhost.pub & cfkey.pub locations, checks if they appear to be a public
key, and then join them all together.
( Back to top)
domain
Returns the hosts primary DNS domain name.
Resolution:
On UNIX (excluding Darwin), rst try and use the hostname fact, which uses the hostname
system command, and then parse the output of that.
Failing that it tries the dnsdomainname system command.
Failing that it uses /etc/resolv.conf and takes the domain from that, or as a nal resort, the
search from that.
Otherwise returns nil.
On Windows uses the win32ole gem and winmgmts to get the DNSDomain value from the Win32
networking stack.
( Back to top)
ec2_{EC2 INSTANCE DATA}
Returns info retrieved in bulk from the EC2 API. The names of these facts should be self
explanatory, and they are otherwise undocumented. The full list of these facts is:
ec2_ami_id
ec2_ami_launch_index
ec2_ami_manifest_path
ec2_block_device_mapping_ami
ec2_block_device_mapping_ephemeral0
ec2_block_device_mapping_root
ec2_hostname
ec2_instance_id
ec2_instance_type
ec2_kernel_id
ec2_local_hostname
ec2_local_ipv4
ec2_placement_availability_zone
ec2_profile
ec2_public_hostname
ec2_public_ipv4
ec2_public_keys_0_openssh_key
ec2_reservation_id
ec2_security_groups
( Back to top)
ec2_userdata
Undocumented.
( Back to top)
facterversion
Returns the version of the facter module.
Resolution:
Uses the version constant.
( Back to top)
filesystems
Provides an alphabetic list of le systems for use by block devices such as hard drives, media cards,
etc.
Resolution:
Returns a comma-delimited list.
Caveats:
Linux only. FUSE will not be reported.
( Back to top)
ldom
Returns a list of dynamic facts that describe the attributes of a Solaris logical domain.
The facts returned will include:
DOMAINROLE
DOMAINNAME
DOMAINUUID
DOMAINCONTROL
DOMAINCHASSIS
Resolution:
Uses the output of virtinfo -ap.
Caveats:
( Back to top)
fqdn
Returns the fully qualied domain name of the host.
Resolution:
Simply joins the hostname fact with the domain name fact.
Caveats:
No attempt is made to check that the two facts are accurate or that the two facts go together. At no
point is there any DNS resolution made either.
( Back to top)
gid
Returns the group ID of the user running the puppet process.
Resolution
Uses the output of gid -ng.
( Back to top)
hardwareisa
Returns hardware processor type.
Resolution:
On Solaris, Linux and the BSDs simply uses the output of uname -p.
Caveats:
Some linuxes return unknown to uname -p with relative ease.
( Back to top)
hardwaremodel
Returns the hardware model of the system.
Resolution:
Uses purely uname -m on all platforms other than AIX and Windows.
On AIX uses the parsed modelname output of lsattr -El sys0 -a modelname.
On Windows uses the host_cpu pulled out of Rubys cong.
( Back to top)
hostname
Returns the systems short hostname.
Resolution:
On all system bar Darwin, parses the output of the hostname system command to everything
before the rst period.
On Darwin, uses the system conguration util to get the LocalHostName variable.
( Back to top)
id
Internal fact used to specify the program to return the currently running user id.
Resolution:
On all Unixes bar Solaris, just returns whoami.
On Solaris, parses the output of the id command to grab the username, as Solaris doesnt have
the whoami command.
( Back to top)
interfaces
Returns a list of the network interfaces on the machine. These interface names are also used to
construct several additional facts.
( Back to top)
ipaddress
Returns the main IP address for a host.
Resolution:
On the Unixes does an ifcong, and returns the rst non 127.0.0.0/8 subnetted IP it nds.
On Windows, it attempts to use the socket library and resolve the machines hostname via DNS.
On LDAP based hosts it tries to use either the win32/resolv library to resolve the hostname to an
IP address, or on Unix, it uses the resolv library.
As a fall back for undened systems, it tries to run the host command to resolve the machines
hostname using the system DNS.
Caveats:
DNS resolution relies on working DNS infrastructure and resolvers on the host system.
The ifcong parsing purely takes the rst IP address it nds without any checking this is a useful
IP address.
( Back to top)
ipaddress_{NETWORK INTERFACE}
Returns the IP4 address for a specic network interface (from the list in the interfaces fact).
( Back to top)
ipaddress6
Returns the main IPv6 IP address of a system.
Resolution:
OS-dependent code that parses the output of various networking tools and currently not very
intelligent. Returns the rst non-loopback and non-linklocal address found in the ouput unless a
default route can be mapped to a routeable interface. Guessing an interface is currently only
possible with BSD type systems to many assumptions have to be made on other platforms to make
this work with the current code. Most code ported or modeled after the ipaddress fact for the sake
of similar functionality and familiar mechanics.
( Back to top)
ipaddress6_{NETWORK INTERFACE}
Returns the IP6 address for a specic network interface (from the list in the interfaces fact).
( Back to top)
iphostnumber
On selected versions of Darwin, returns the hosts IP address.
Resolution:
Uses either the scutil program to get the localhost name, or parses output of ifcong for a MAC
address.
( Back to top)
is_virtual
Returns true or false if a machine is virtualized or not.
Resolution:
Hypervisors and the like may be detected as a virtual type, but are not actual virtual machines, or
should not be treated as such. This determines if the host is actually virtualized.
( Back to top)
kernel
Returns the operating systems name.
Resolution:
Uses Rubys rbcong to nd host_os, if that is a Windows derivative, the returns windows,
otherwise returns uname -s verbatim.
( Back to top)
kernelmajversion
Returns the operating systems release numbers major value.
Resolution:
Takes the rst 2 elements of the kernel version as delimited by periods.
( Back to top)
kernelrelease
Returns the operating systems release number.
Resolution:
On AIX returns the output from the oslevel -s system command.
On Windows based systems, uses the win32ole gem to query Windows Management for the
Win32_OperatingSystem value.
Otherwise uses the output of uname -r system command.
( Back to top)
kernelversion
Returns the operating systems kernel version.
Resolution:
On Solaris and SunOS based machines, returns the output of uname -v.
Otherwise returns the kernerlrelease fact up to the rst -. This may be the entire
kernelrelease fact in many cases.
( Back to top)
lsbdistcodename
Returns Linux Standard Base information for the host.
Resolution:
Uses the lsb_release system command.
Caveats:
Only works on Linux (and the kfreebsd derivative) systems. Requires the lsb_release program,
which may not be installed by default. Also is as only as accurate as that program outputs.
( Back to top)
lsbdistdescription
Resolution:
Caveats:
( Back to top)
lsbdistid
Resolution:
Caveats:
( Back to top)
lsbdistrelease
Resolution:
Caveats:
( Back to top)
lsbmajdistrelease
Returns the major version of the operation system version as gleaned from the lsbdistrelease fact.
Resolution:
Parses the lsbdistrelease fact for numbers followed by a period and returns those, or just the
lsbdistrelease fact if none were found.
( Back to top)
lsbminordistrelease
Returns the minor version of the operation system version as gleaned from the lsbdistrelease fact.
Resolution:
Parses the lsbdistrelease fact for numbers preceded by a period and returns those. If there is no
match, the fact is not present.
Caveats:
If the version number has three components (e.g., 1.2.3), only the second will be included in the
fact.
( Back to top)
lsbrelease
Resolution:
Caveats:
( Back to top)
macaddress
Returns the MAC address of the primary network interface.
( Back to top)
macaddress_{NETWORK INTERFACE}
Returns the MAC address for a specic network interface (from the list in the interfaces fact).
( Back to top)
macosx_buildversion
Returns the systems Mac OS X build version.
( Back to top)
macosx_productname
Returns the systems Mac OS X product name. Will almost always be Mac OS X.
( Back to top)
macosx_productversion
Returns the systems full Mac OS X version number. (e.g. 10.7.4)
( Back to top)
macosx_productversion_major
Returns the systems major Mac OS X version number. (e.g. 10.7)
( Back to top)
macosx_productversion_minor
Returns the systems minor Mac OS X version number. (e.g. 4)
( Back to top)
manufacturer
Returns the hardwares manufacturer information.
Resolution:
On OpenBSD, queries sysctl values, via a util class.
On SunOS Sparc, uses prtdiag via a util class.
On Windows, queries the system via a util class.
Uses util/manufacturer.rb for fallback parsing.
( Back to top)
memoryfree
Returns the amount of free memory on the system.
( Back to top)
memorysize
Returns the total amount of memory on the system.
( Back to top)
netmask
Returns the netmask for the main interfaces.
Resolution:
Uses the facter/util/netmask library routines.
( Back to top)
netmask_{NETWORK INTERFACE}
Returns the netmask for a specic network interface (from the list in the interfaces fact).
( Back to top)
network_{NETWORK INTERFACE}
Returns the network for a specic network interface (from the list in the interfaces fact).
( Back to top)
operatingsystem
Returns the name of the operating system.
Resolution:
If the kernel is a Linux kernel, check for the existence of a selection of les in /etc/ to nd the
specic avour.
On SunOS based kernels, return Solaris.
On systems other than Linux, use the kernel value.
( Back to top)
operatingsystemmajrelease
Returns the major release of the operating system.
Resolution:
Splits the version number from the operatingsystemrelease fact by . and returns the rst
element. Only available if operatingsystem returns Amazon, Centos, CloudLinux, CumulusLinux,
Debian, Fedora, OEL, OracleLinux, OVS, RedHat, Scientific, or SLC.
( Back to top)
operatingsystemrelease
Returns the release of the operating system.
Resolution:
On RedHat derivatives, returns their /etc/<variant>-release le.
On Debian, returns /etc/debian_version.
On Ubuntu, parses /etc/issue for the release version.
On Suse, derivatives, parses /etc/SuSE-release for a selection of version information.
On Slackware, parses /etc/slackware-version.
On Amazon Linux, returns the lsbdistrelease value.
On all remaining systems, returns the kernelrelease value.
( Back to top)
osfamily
Returns the operating system family.
Resolution:
Maps operating systems to operating system families, such as Linux distribution derivatives. Adds
mappings from specic operating systems to kernels in the case that it is relevant.
Caveats:
This fact is completely reliant on the operatingsystem fact, and no heuristics are used.
( Back to top)
path
Returns the $PATH variable.
Resolution:
Gets $PATH from the environment.
( Back to top)
physicalprocessorcount
Returns the number of physical processors.
Resolution:
Attempts to use sysfs to get the physical IDs of the processors. Falls back to /proc/cpuinfo and
physical id if sysfs is not available.
( Back to top)
processor
Additional Facts about the machines CPUs. Only used on BSDs.
( Back to top)
processor{NUMBER}
One fact for each processor, with processor info.
Resolution:
On Linux and kFreeBSD, parse /proc/cpuinfo for each processor.
On AIX, parse the output of lsdev for its processor section.
On Solaris, parse the output of kstat for each processor.
On OpenBSD, use uname -p and the sysctl variable for hw.ncpu for CPU count.
( Back to top)
processorcount
Returns the number of processors in the machine.
( Back to top)
productname
Returns the model identier of the machine.
( Back to top)
ps
Internal fact for what to use to list all processes. Used by Service{} type in Puppet.
Resolution:
Assumes ps -ef for all operating systems other than BSD derivatives, where it uses ps auxwww.
( Back to top)
puppetversion
Returns the version of puppet installed.
Resolution:
Requres puppet via Ruby and returns its version constant.
( Back to top)
rubysitedir
Returns Rubys site library directory.
Resolution:
Works out the version to major/minor (1.8, 1.9, etc), then joins that with all the $: library paths.
( Back to top)
rubyversion
Returns the version of Ruby facter is running under.
Resolution:
Returns RUBY_VERSION.
( Back to top)
selinux
Determine whether SE Linux is enabled on the node.
Resolution:
Checks for the existence of the enforce le under the SE Linux mount point (e.g.
/selinux/enforce) and returns true if /proc/self/attr/current does not contain kernel.
( Back to top)
selinux_config_mode
Returns the congured SE Linux mode (e.g., enforcing, permissive, or disabled).
Resolution:
Parses the output of sestatus_cmd and returns the value of the line beginning with Mode from
config file:.
( Back to top)
selinux_config_policy
Returns the congured SE Linux policy (e.g., targeted, MLS, or minimum).
Resolution:
Parses the output of sestatus_cmd and returns the value of the line beginning with Policy from
config file:.
( Back to top)
selinux_current_mode
Returns the current SE Linux mode (e.g., enforcing, permissive, or disabled).
Resolution:
Parses the output of sestatus_cmd and returns the value of the line beginning with Current
mode:.
( Back to top)
selinux_enforced
Returns whether SE Linux is enabled ( true) or not ( false).
Resolution:
Returns the value found in the enforce le under the SE Linux mount point (e.g.
/selinux/enforce).
( Back to top)
selinux_policyversion
Returns the current SE Linux policy version.
Resolution:
Reads the content of the policyvers le found under the SE Linux mount point, e.g.
/selinux/policyvers.
( Back to top)
serialnumber
Returns the machines serial number.
( Back to top)
sp_{SYSTEM PROFILER DATA}
Returns info retrieved in bulk from the OS X system proler. The names of these facts should be self
explanatory, and they are otherwise undocumented. The full list of these facts is:
sp_64bit_kernel_and_kexts
sp_boot_mode
sp_boot_rom_version
sp_boot_volume
sp_cpu_interconnect_speed
sp_cpu_type
sp_current_processor_speed
sp_kernel_version
sp_l2_cache_core
sp_l3_cache
sp_local_host_name
sp_machine_model
sp_machine_name
sp_mmm_entry
sp_number_processors
sp_os_version
sp_packages
sp_physical_memory
sp_platform_uuid
sp_secure_vm
sp_serial_number
sp_smc_version_system
sp_uptime
sp_user_name
( Back to top)
sshdsakey
Returns the hosts SSH DSA key.
( Back to top)
sshecdsakey
Returns the hosts SSH ECDSA key.
( Back to top)
sshrsakey
Returns the hosts SSH RSA key.
( Back to top)
swapencrypted
Say whether the systems swap space is encrypted. Only used on Darwin.
( Back to top)
swapfree
Returns the amount of free swap on the system.
( Back to top)
swapsize
Returns the total amount of swap space available on the system.
( Back to top)
timezone
Returns the machines time zone.
Resolution:
Usess Rubys Time modules Time.new call.
( Back to top)
type
Returns the machines chassis type.
( Back to top)
uniqueid
Returns the output of the hostid command.
( Back to top)
uptime
Returns the system uptime in a human readable format.
Resolution:
Does basic maths on the uptime_seconds fact to return a count of days, hours and minutes of
uptime
( Back to top)
uptime_days
Returns the total days of uptime.
Resolution:
Divides uptime_hours fact by 24.
( Back to top)
uptime_hours
Returns the total hours of uptime.
Resolution:
Divides uptime_seconds fact by 3600.
( Back to top)
uptime_seconds
Returns the total seconds of uptime.
Resolution:
Using the facter/util/uptime.rb module, try a variety of methods to acquire the uptime on Unix.
On Windows, the module calculates the uptime by the LastBootupTime Windows management
value.
( Back to top)
uuid
Returns the universally unique identier on systems where it is available.
Resolution:
Parses the output of dmidecode.
Caveats:
Only available on some versions of Linux, including RHEL/CentOS.
( Back to top)
virtual
Determine if the systems hardware is real or virtualized.
Resolution:
Assumes physical unless proven otherwise.
On Darwin, uses the macosx util module to acquire the SPDisplaysDataType and from that parses
it to see if its VMWare or Parallels pretending to be the display.
On Linux, BSD, Solaris, and HPUX: Much of the logic here is obscured behind util/virtual.rb, which
rather than document here, which would encourage drift, just refer to it. The Xen tests in here
rely on /sys and /proc, and check for the presence and contents of les in there. If after all the
other tests its still seen as physical, then it tries to parse the output of lspci, dmidecode and
prtdiag for obvious signs of being under VMWare, Parallels, or VirtualBox. Finally, it checks for
the existence of vmware-vmx, which would hint its VMWare.
Caveats:
Many checks rely purely on existence of les.
( Back to top)
vlans
On Linux, return a list of all the VLANs on the system.
Resolution:
On Linux only, checks for and reads /proc/net/vlan/cong and parses it.
( Back to top)
xendomains
Returns the list of Xen domains on the Dom0.
Resolution:
On a Xen Dom0 host, return a list of Xen domains using the util/xendomains library.
( Back to top)
zfs_version
Returns the version of zfs in use on the system.
Resolution:
Uses the output of zfs upgrade -v.
( Back to top)
zonename
Returns the name of the Solaris zone.
Resolution:
Uses zonename to return the name of the Solaris zone.
Caveats:
No support for Solaris 9 and below, where zones are not available.
( Back to top)
zones
Purpose:
Returns the list of zones on the system and adds one zones_ fact for each zone, with its state (e.g.
running, incomplete, or installed.)
Resolution:
Uses usr/sbin/zoneadm list -cp to get the list of zones in separate parsable lines with a
delimeter of :, which is used to split the line string and get the zone details.
Caveats:
No support for Solaris 9 and below, where zones are not available.
( Back to top)
zpool_version
Returns the version number for the ZFS storage pool.
Resolution:
Uses zpool upgrade -v to return the ZFS storage pool version number.
( Back to top)
Facter 2.0: Overview of Custom Facts With
Examples
Facter 2.0 Manual Facter 2.0: Overview of Custom Facts With Examples 26/46
Anatomy of a Facter Fact
A typical Facter fact is a fairly simple assemblage of just a few dierent elements. This page is an
example-driven tour of those elements, and is intended as a quick primer or reference for authors
of custom facts. Youll need some familiarity with Ruby to understand most of these examples. For
a gentler introduction, check out the Custom Facts Walkthrough.
First o, its important to distinguish between facts and resolutions. A fact is a piece of information
about a given node, while a resolution is a way of obtaining that information from the system. That
means that every fact needs to have at least one resolution, and facts that can run on dierent
operating systems may need to have dierent resolutions for each one.
Even though facts and resolutions are conceptually very dierent, the line can get a bit blurry at
times. Thats because declaring a second (or third, etc.) resolution for a fact looks just like declaring
a completely new fact, only with the same name as an existing fact. You can see what this looks like
in this example: dierent resolutions for dierent operating systems.
Writing Facts with Simple Resolutions
Most facts are resolved all at once, without any need to merge data from dierent sources. In that
case, the resolution is simple. Both at and structured facts can have simple resolutions.
Example: minimal fact that relies on a single shell command
Facter.add(:rubypath) do
setcode 'which ruby'
end
Example: slightly more complex fact, conned to Linux
Facter.add(:jruby_installed) do
confine :kernel => "Linux"
setcode do
jruby_path = Facter::Core::Execution.exec('which jruby')
# if 'which jruby' exits with an error, jruby_path will be an empty string
if jruby_path == ""
false
else
true
end
end
end
Example: dierent resolutions for dierent operating systems
Facter 2.0 Manual Anatomy of a Facter Fact 27/46
setcode 'which ruby'
end
confine :osfamily => "Windows"
# Windows uses 'where' instead of 'which'
setcode 'where ruby'
end
Main Components of Simple Resolutions
Simple facts are typically made up of the following parts:
Writing Structured Facts
1. A call to Facter.add(:fact_name):
This introduces a new fact or a new resolution for an existing fact.
The name can be either a symbol or a string.
You can optionally pass :type => :simple as a parameter, but it will have no eect since
thats already the default.
The rest of the fact is wrapped in the constructors do ... end block.
2. Zero or more confine statements:
These determine whether the fact/resolution will be executed.
They can either match against the value of another fact or evaluate an arbitrary Ruby
expression/block.
3. An optional has_weight statement:
When multiple resolutions are available, the one with the highest weight will be executed and
the rest will be ignored.
It must be an integer greater than 0.
The weight defaults to the number of confine statements for the resolution.
4. A setcode statement that determines the value of the fact:
It can take either a string or a block.
If given a string, Facter will execute it as a shell command and the output will be the value of
the fact.
If given a block, the blocks return value will be the value of the fact.
To execute shell commands within a setcode block, use the Facter::Core::Execution.exec
function.
If multiple setcode statements are evaluated for a single fact, Facter will only retain the
newest value.
Facter 2.0 introduced structured facts, which can take the form of hashes or arrays. You dont have
to do anything special to mark the fact as structured if your fact returns a hash or array, Facter
will recognize it as a structured fact. Structured facts can have simple or aggregate resolutions.
Example: returning an array of network interfaces
Facter.add(:interfaces_array) do
setcode do
interfaces = Facter.value(:interfaces)
# the 'interfaces' fact returns a single comma-delimited string, e.g.,
"lo0,eth0,eth1"
interfaces_array = interfaces.split(',')
interfaces_array
end
end
Example: returning a hash of IP addresses
Facter.add(:interfaces_hash) do
setcode do
interfaces_array = Facter.value(:interfaces_array)
interfaces_hash = {}
interfaces_array.each do |interface|
ipaddress = Facter.value("ipaddress_#{interface}")
if ipaddress
interfaces_hash[interface] = ipaddress
end
end
interfaces_hash
end
end
Writing Facts with Aggregate Resolutions
Aggregate resolutions allow you to split up the resolution of a fact into separate chunks. By default,
Facter will merge hashes with hashes or arrays with arrays, resulting in a structured fact, but you
can also aggregate the chunks into a at fact using concatenation, addition, or any other function
that you can express in Ruby code.
Note: Structured facts are supported in Puppet 3.3 and greater, but theyre not enabled by
default. To enable structured facts when using puppet apply, the stringify_facts option must
be set to false in the [main] section of puppet.conf. To enable structured facts in a
master/agent setup, stringify_facts must be set to false in the [main] or [master]
section on the master as well as either the [main] or [agent] section on the agent.
Example: building a structured fact progressively
Facter.add(:networking, :type => :aggregate) do
confine :kernel => "Linux"
chunk(:macaddrs) do
interfaces = {}
Sysfs.net_devs.each do |dev|
interfaces[dev.name] = {
'macaddr' => dev.macaddr,
'macbrd' => dev.macbrd,
}
end
interfaces
end
chunk(:ipv4) do
interfaces = {}
Facter::Util::IP.get_interfaces.each do |interface|
interfaces[interface] = {
'ipaddress' => Facter::Util::IP.get_ipaddress_value(interface),
'netmask' => Facter::Util::IP.get_netmask_value(interface),
}
end
interfaces
end
# Facter will merge the return values for the two chunks
# automatically, so there's no setcode statement.
end
Example: building a at fact progressively with addition
Facter.add(:total_free_memory_mb, :type => :aggregate) do
chunk(:physical_memory) do
Facter.value(:memoryfree_mb).to_i
# The 'memoryfree_mb' fact returns the number of megabytes of free memory
as a string.
end
chunk(:virtual_memory) do
Facter.value(:swapfree_mb).to_i
# The 'swapfree_mb' fact returns the number of megabytes of free swap as a
string.
end
aggregate do |chunks|
# The return value for this block will determine the value of the fact.
sum = 0
chunks.each_value do |i|
sum += i
end
sum
end
end
Main Components of Aggregate Resolutions
Aggregate resolutions have two key dierences compared to simple resolutions: the presence of
chunk statements and the lack of a setcode statement. The aggregate block is optional, and
without it Facter will merge hashes with hashes or arrays with arrays.
Facter 2.0: Custom Facts Walkthrough
1. A call to Facter.add(:fact_name, :type => :aggregate):
This introduces a new fact or a new resolution for an existing fact.
The name can be either a symbol or a string.
The :type => :aggregate parameter is required for aggregate resolutions.
The rest of the fact is wrapped in the constructors do ... end block.
2. Zero or more confine statements:
These determine whether the fact/resolution will be executed.
They can either match against the value of another fact or evaluate an arbitrary Ruby
expression/block.
3. An optional has_weight statement:
When multiple resolutions are available, the one with the highest weight will be executed and
the rest will be ignored.
The weight defaults to the number of confine statements for the resolution.
4. One or more chunk blocks, each containing:
a name parameter (used only for internal organization),
some amount of code for (partially) resolving the fact,
a return value (any type, but typically a hash or array).
5. An optional aggregate block:
If this is absent, Facter will merge hashes with hashes or arrays with arrays.
If you want to merge the chunks in any other way, youll need to specify it here.
The chunks object contains the return values for all of the chunks in the resolution.
Facter 2.0 Manual Facter 2.0: Custom Facts Walkthrough 31/46
Custom Facts
Extend facter by writing your own custom facts to provide information to Puppet.
Adding Custom Facts to Facter
Sometimes you need to be able to write conditional expressions based on site-specic data that
just isnt available via Facter, or perhaps youd like to include it in a template.
Since you cant include arbitrary ruby code in your manifests, the best solution is to a new fact to
Facter. These additional facts can then be distributed to Puppet clients and are available for use in
manifests and templates, just like any other fact would be.
The Concept
You can add new facts by writing snippets of ruby code on the Puppet master. Puppet will then use
Plugins in Modules to distribute the facts to the client.
Loading Custom Facts
Facter oers a few methods of loading facts:
$LOAD_PATH, or the ruby library load path
The environment variable FACTERLIB
Facts distributed using pluginsync
You can use these methods of loading facts do to things like test les locally before distributing
them, or you can arrange to have a specic set of facts available on certain machines.
Facter will search all directories in the ruby $LOAD_PATH variable for subdirectories named facter,
and will load all ruby les in those directories. If you had some directory in your $LOAD_PATH like
~/lib/ruby, set up like this:
#~/lib/ruby
facter
rackspace.rb
system_load.rb
users.rb
Facter would try to load facter/system_load.rb, facter/users.rb, and facter/rackspace.rb.
Facter also will check the environment variable FACTERLIB for a colon-delimited set of directories,
and will try to load all ruby les in those directories. This allows you to do something like this:
Facter 2.0 Manual Custom Facts 32/46
$ ls my_facts
system_load.rb
$ ls my_other_facts
users.rb
$ export FACTERLIB="./my_facts:./my_other_facts"
$ facter system_load users
system_load => 0.25
users => thomas,pat
Facter can also easily load fact les distributed using pluginsync. Running facter -p will load all
the facts that have been distributed via pluginsync, so if youre using a lot of custom facts inside
puppet, you can easily use these facts with standalone facter.
Custom facts can be distributed to clients using the Plugins in Modules method.
Two Parts of Every Fact
Setting aside external facts for now, every fact has at least two elements:
Facts can get a lot more complicated than that, but those two together are the minimum that you
will see in every fact.
Executing Shell Commands in Facts
Puppet gets information about a system from Facter, and the most common way for Facter to get
that information is by executing shell commands. You can then parse and manipulate the output
from those commands using standard ruby code. The Facter API gives you a few ways to execute
shell commands:
if all you want to do is run the command and use the output, verbatim, as your facts value, you
can pass the command into setcode directly. For example: setcode 'uname --hardware-
platform'
if your fact is any more complicated than that, you can call
Facter::Core::Execution.exec('uname --hardware-platform') from within the setcode
doend block. As always, whatever the setcode statement returns will be used as the facts
value.
in any case, remember that your shell command is also a ruby string, so youll need to escape
special characters if you want to pass them through.
Its important to note that not everything that works in the terminal will work in a fact. You can use
the pipe ( |) and similar operators just as you normally would, but Bash-specic syntax like if
statements will not work. The best way to handle this limitation is to write your conditional logic in
ruby.
1. a call to Facter.add('fact_name'), which determines the name of the fact
2. a setcode statement, which will be evaluated to determine the facts value.
An Example
Lets say you need to get the output of uname --hardware-platform to single out a specic type of
workstation. To do this, you would create a new custom fact. Start by giving the fact a name, in this
case, hardware_platform, and create your new fact in a le, hardware_platform.rb, on the Puppet
master server:
# hardware_platform.rb
Facter.add('hardware_platform') do
setcode do
Facter::Core::Resolution.exec('/bin/uname --hardware-platform')
end
end
You can then use the instructions in Plugins In Modules page to copy the new fact to a module and
distribute it. During your next Puppet run, the value of the new fact will be available to use in your
manifests and templates.
The best place to get ideas about how to write your own custom facts is to look at the code for
Facters core facts. There you will nd a wealth of examples of how to retrieve dierent types of
system data and return useful facts.
Using other facts
You can write a fact which uses other facts by accessing Facter.value(:somefact). If the named
fact is unresolved, Facter.value will return nil; but if the fact cant be found at all, it will throw an
error.
For example:
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
Conguring Facts
Facts have a few properties that you can use to customize how facts are evaluated.
Conning Facts
One of the more commonly used properties is the confine statement, which restricts the fact to
only run on systems that matches another given fact.
An example of the conne statement would be something like the following:
Facter.add(:powerstates) do
confine :kernel => 'Linux'
setcode do
Facter::Core::Resolution.exec('cat /sys/power/states')
end
end
This fact uses sysfs on linux to get a list of the power states that are available on the given system.
Since this is only available on Linux systems, we use the conne statement to ensure that this fact
isnt needlessly run on systems that dont support this type of enumeration.
Fact precedence
A single fact can have multiple resolutions, each of which is a dierent way of ascertaining what the
value of the fact should be. Its very common to have dierent resolutions for dierent operating
systems, for example. Its easy to confuse facts and resolutions because they are supercially
identical to add a new resolution to a fact, you simply add the fact again, only with a dierent
setcode statement.
When a fact does have more than one resolution, youll want to make sure that only one of them
gets executed. Otherwise, each subsequent resolution would override the one before it, and you
might not get the value that you want.
The way that Facter decides the issue of precedence is the weight property. Once Facter rules out
any resolutions that are excluded because of confine statments, the resolution with the highest
weight will be executed. If that resolution doesnt return a value, Facter will move on to the next
resolution (by descending weight) until it gets a suitable value for the fact.
By default, the weight of a fact is the number of connes for that resolution, so that more specic
resolutions will take priority over less specic resolutions.
# Check to see if this server has been marked as a postgres server
Facter.add(:role) do
has_weight 100
setcode do
if File.exist? '/etc/postgres_server'
'postgres_server'
end
end
end
# Guess if this is a server by the presence of the pg_create binary
has_weight 50
setcode do
if File.exist? '/usr/sbin/pg_create'
'postgres_server'
end
end
end
# If this server doesn't look like a server, it must be a desktop
setcode do
'desktop'
end
end
Timing out
If you have facts that are unreliable and may not nish running, you can use the timeout property.
If a fact is dened with a timeout and the evaluation of the setcode block exceeds the timeout,
Facter will halt the resolution of that fact and move on.
# Sleep
Facter.add(:sleep, :timeout => 10) do
setcode do
sleep 999999
end
end
Structured Facts
While the norm is for a fact to return a single string, Facter 2.0 introduced structured facts, which
take the form of either a hash or an array. All you need to do to create a structured fact is return a
hash or an array from the setcode statement. You can see some relevant examples in the writing
structured facts section of the Fact Overview.
Aggregate Resolutions
If your fact combines the output of multiple commands, it may make sense to use aggregate
resolutions. An aggregate resolution is split into chunks, each one responsible for resolving one
piece of the fact. After all of the chunks hae been resolved separately, theyre combined into a
single at or structured fact and returned.
Aggregate resolutions have several key dierences compared to simple resolutions, beginning with
the fact declaration. To introduce an aggregate resolution, youll need to add the :type =>
:aggregate parameter:
Facter.add(:fact_name, :type => :aggregate) do
#chunks go here
#aggregate block goes here
end
Each step in the resolution then gets its own chunk statement with an arbitrary name:
chunk(:one) do
'Chunk one returns this. '
end

chunk(:two) do
'Chunk two returns this.'
end
In a simple resolution, the code always includes a setcode statement that determines the facts
value. Aggregate resolutions never have a setcode statement. Instead, they have an optional
aggregate block that combines the chunks. Whatever value the aggregate block returns will be the
facts value. Heres an example that just combines the strings from the two chunks above:
aggregate do |chunks|
result = ''
chunks.each do |chunk|
result += chunk
end
result
end
# Returns "Chunk one returns this. Chunk two returns this."
If the chunk blocks either all return arrays or all return hashes, you can omit the aggregate block. If
you do, Facter will automatically merge all of your data into one array or hash and use that as the
facts value.
For more examples of aggregate resolutions, see the aggregate resolutions section of the Fact
Overview page.
Viewing Fact Values
If your puppet master(s) are congured to use PuppetDB and/or the inventory service, you can view
and search all of the facts for any node, including custom facts. See the PuppetDB or inventory
service docs for more info.
External Facts
What are external facts?
External facts provide a way to use arbitrary executables or scripts as facts, or set facts statically
with structured data. If youve ever wanted to write a custom fact in Perl, C, or a one-line text le,
this is how.
Fact Locations
The best way to distribute external facts is with pluginsync, which added support for them in
Puppet 3.4/Facter 2.0.1. To add external facts to your puppet modules, just place them in
<MODULEPATH>/<MODULE>/facts.d/.
If youre not using pluginsync, then external facts must go in a standard directory. The location of
this directory varies depending on your operating system, whether your deployment uses Puppet
Enterprise or open source releases, and whether you are running as root/Administrator. When
calling facter from the command line, you can specify the external facts directory with the --
external-dir option.
In a module (recommended):
<MODULEPATH>/<MODULE>/facts.d/
On Unix/Linux/Mac OS X:
/etc/facter/facts.d/ # Puppet Open Source
/etc/puppetlabs/facter/facts.d/ # Puppet Enterprise
On Windows 2003:
C:\Documents and Settings\All Users\Application Data\PuppetLabs\facter\facts.d\
On other supported Windows Operating Systems (Windows Vista, 7, 8, 2008, 2012):
C:\ProgramData\PuppetLabs\facter\facts.d\
When running as a non-root / non-Administrator user:
Note: These directories will not necessarily exist by default; you may need to create them. If
you create the directory, make sure to restrict access so that only Administrators can write to
the directory.
<HOME DIRECTORY>/.facter/facts.d/
Executable facts Unix
Executable facts on Unix work by dropping an executable le into the standard external fact path
above.
An example external fact written in Python:
#!/usr/bin/env python
data = {"key1" : "value1", "key2" : "value2" }
for k in data:
print "%s=%s" % (k,data[k])
You must ensure that the script has its execute bit set:
chmod +x /etc/facter/facts.d/my_fact_script.py
For Facter to parse the output, the script must return key/value pairs on STDOUT in the format:
key1=value1
key2=value2
key3=value3
Using this format, a single script can return multiple facts.
Executable facts Windows
Executable facts on Windows work by dropping an executable le into the external fact path for
your version of Windows. Unlike with Unix, the external facts interface expects Windows scripts to
end with a known extension. Line endings can be either LF or CRLF. At the moment the following
extensions are supported:
.com and .exe: binary executables
.bat and .cmd: batch scripts
.ps1: PowerShell scripts
As with Unix facts, each script must return key/value pairs on STDOUT in the format:
key1=value1
key2=value2
key3=value3
Using this format, a single script can return multiple facts in one return.
BATCH SCRIPTS
The le encoding for .bat/.cmd les must be ANSI or UTF8 without BOM (Byte Order Mark),
otherwise you may get strange output.
Here is a sample batch script which outputs facts using the required format:
@echo off
echo key1=val1
echo key2=val2
echo key3=val3
REM Invalid - echo 'key4=val4'
REM Invalid - echo "key5=val5"
POWERSHELL SCRIPTS
The encoding that should be used with .ps1 les is pretty open. PowerShell will determine the
encoding of the le at run time.
Here is a sample PowerShell script which outputs facts using the required format:
Write-Host "key1=val1"
Write-Host 'key2=val2'
Write-Host key3=val3
You should be able to save and execute this PowerShell script on the command line.
Structured Data Facts
Facter can parse structured data les stored in the external facts directory and set facts based on
their contents.
Structured data les must use one of the supported data types and must have the correct le
extension. At the moment, Facter supports the following extensions and data types:
.yaml: YAML data, in the following format:
---
key1: val1
key2: val2
key3: val3
.json: JSON data, in the following format:
{
"key1": "val1",
"key2": "val2",
"key3": "val3"
}
.txt: Key value pairs, in the following format:
key1=value1
key2=value2
key3=value3
As with executable facts, structured data les can set multiple facts at once.
STRUCTURED DATA FACTS ON WINDOWS
All of the above types are supported on Windows with the following caveats:
The line endings can be either LF or CRLF.
The le encoding must be either ANSI or UTF8 without BOM (Byte Order Mark).
Troubleshooting
If your external fact is not appearing in Facters output, running Facter in debug mode should give
you a meaningful reason and tell you which le is causing the problem:
# facter --debug
One example of when this might happen is in cases where a fact returns invalid characters. Let say
you used a hyphen instead of an equals sign in your script test.sh:
#!/bin/bash
echo "key1-value1"
Running facter --debug should yield a useful error message:
...
Fact file /etc/facter/facts.d/sample.txt was parsed but returned an empty data
set
...
If you are interested in nding out where any bottlenecks are, you can run Facter in timing mode
and it will reect how long it takes to parse your external facts:
facter --timing
The output should look similar to the timing for Ruby facts, but will name external facts with their
full paths. For example:
$ facter --timing
kernel: 14.81ms
/usr/lib/facter/ext/abc.sh: 48.72ms
/usr/lib/facter/ext/foo.sh: 32.69ms
/usr/lib/facter/ext/full.json: 104.71ms
/usr/lib/facter/ext/sample.txt: 0.65ms
....
EXTERNAL FACTS AND STDLIB
If you nd that an external fact does not match what you have congured in your facts.d
directory, make sure you have not dened the same fact using the external facts capabilities found
in the stdlib module.
Drawbacks
While external facts provide a mostly-equal way to create variables for Puppet, they have a few
drawbacks:
An external fact cannot internally reference another fact. However, due to parse order, you can
reference an external fact from a ruby fact.
External executable facts are forked instead of executed within the same process.
Distributing executable facts through pluginsync requires puppet 3.4.0 or greater.
Facter 2.0: Release Notes
This page documents the history of the Facter 2.0 series.
Facter 2.0.2
Released June 10, 2014.
Facter 2.0.2 is a security release in the Facter 2 series. It has no other bug xes or new features.
Security Fixes
CVE-2014-3248 (AN ATTACKER COULD CONVINCE AN ADMINISTRATOR TO UNKNOWINGLY EXECUTE
MALICIOUS CODE ON PLATFORMS WITH RUBY 1.9.1 AND EARLIER)
When running on Ruby 1.9.1 or earlier, previous versions of Facter would load Ruby source les
from the current working directory. This could lead to the execution of arbitrary code.
Facter 2.0.1
Released April 1, 2014. (RC1: February 28; RC2: March 12; RC3: March 25; RC4: March 28.)
Facter 2.0 Manual Facter 2.0: Release Notes 42/46
Facter 2.0.1 is the rst release in the Facter 2 series. (See the note below about Facter 2.0.0.)
More Return Types and Structured Facts
Facts are no longer limited to strings; they can now return any of the following types: Integer, Float,
TrueClass, FalseClass, NilClass, String, Array, Hash. The last two are especially signicant facts can
now combine associated pieces of information into a single data structure. Facter 2.0.1 doesnt
include any structured facts yet, but you can start writing your own custom structured facts
immediately.
Aggregate Resolutions
Facter 2 also adds aggregate resolutions, which allow you to resolve a fact in multiple steps rather
than all in one setcode statement. Aggregate resolutions are great for structured facts, but you can
also use them to resolve complex at facts as well. See Writing Facts With Aggregate Resolutions for
more details and examples.
Related issues:
FACT-237: Allow fact resolutions to be built up piece-wise
FACT-239: Expose dierent resolution types in DSL
Pluginsync for External Facts
External facts have been around since Facter 1.7, but there hasnt been a way to eectively include
them in modules until now. If youre using Puppet 3.4 or later with Facter 2.0.1, you can now
include external facts in <MODULEPATH>/<MODULE>/facts.d/ and they will be distributed to agent
nodes.
FACT-194: Merge external facts support to Facter 2
Breaking Changes
Removed facts:
selinux_mode has been removed since it was duplicated by selinux_config_policy.
memorytotal has been removed since it was duplicated by memorysize.
API changes:
Fact values can now only be accessed using the Facter.value method. See Using other facts in
the Custom Facts Walkthrough for more information and examples. Facts that refer to other
facts with the deprecated Facter.fact_name notation will have to be updated.
Previously, Facter would treat the empty string as nil (a falsey value). Because Facter 2 allows
resolutions to return nil directly, the empty string is now treated just like any other string (i.e.,
truthy). Custom facts that relied on this behavior in the past will need to be updated. The only
exception is the string form of the setcode method (e.g., setcode 'lsb_release -a'), which
still treats the empty string (or a non-zero exit code) as nil.
Other Features
FACT-134: Perform basic sanity checks on Facter output
Facter now does sanity checking on the output of facts. Facter previously assumed that all facts
would be of type String but did not enforce this; Facter now validates that facts are one of (Integer,
Float, TrueClass, FalseClass, NilClass, String, Array, Hash).
FACT-341: Windows operatingsystemrelease support
On Windows, the operatingsystemrelease fact now returns XP,2003, 2003 R2, Vista, 2008, 7,
2008 R2, 8, or 2012, depending on the version reported by WMI.
Improvements
FACT-94: Unvendor CFPropertyList
Removes vendored code for CFPropertyList in favor of treating it as a separate dependency and
managing it with Rubygems.
FACT-163: Fact loading logic is overly complicated
In Facter 1.x the fact search path would be recursively loaded, but only when using Facter via the
command line. In Facter 2.0 only fact les at the top level of the search path will be loaded, which
matches the behavior when loading facts with Puppet.
FACT-266: Backport Facter::Util::Conne improvements to Facter 2
Adds several improvements to Facter::Util::Confine, including the ability to conne a fact to a
block.
FACT-321: Remove deprecated code for 2.0
Code that had previously been marked deprecated has now been removed.
FACT-322: Remove special casing of the empty string
Previous versions of Facter would interpret an empty string (and only an empty string) as nil. Now
that facts can return more than just strings (i.e., they can directly return nil), empty strings no
longer have this special case.
FACT-186: Build Windows-specic gem
Adds Windows-specic gem dependencies for Facter 2.
FACT-207: Remove deprecated ldapname
Removes all instances of ldapname, completing its deprecation.
FACT-242: Remove Fedora 18 from default build targets
Fedora 18 has reached end-of-life and will no longer be supported. This release removes F18 as a
build target.
FACT-272: Update Facter man page for 2.0
The man page for Facter 2 now includes the new command line options.
FACT-342: Add Ubuntu 14.04 (Trusty Tahr) support
This release adds spec and acceptance tests for Ubuntu 14.04, also known as Trusty Tahr.
FACT-447: Remove Ruby 1.8.5 support
Earlier versions of Facter included support for Ruby 1.8.5, which required a number of monkey
patches for compatibility. As of Facter 2.0.1 RC4, the minimum supported version of Ruby is 1.8.7.
Bug Fixes
FACT-155: operatingsystemrelease in Solaris 10 behaves dierently from Solaris 11
On Solaris 10, the operatingsystemrelease fact would incorrectly be set to the update version. This
release corrects the bug.
FACT-202: Fix undened path in macaddress.rb
One of the possible resolutions for the macaddress fact would incorrectly return nil. This release
xes the bug.
FACT-351: undened method ipaddress for Facter:Module
This bug would cause the netmask fact to fail on Darwin under some circumstances. This release
xes the bug.
FACT-356: vlan fact returns the empty string when undened
FACT-357: lsb facts return the empty string when undened
These two bugs were caused by FACT-322 (remove special casing of the empty string). Previous
versions of facter would ignore facts that returned "", and the LSB and VLAN facts depended on this
behavior to ensure that they wouldnt appear on systems where they werent relevant. Once the
special casing of the empty string was removed in Facter 2.0.1, facts that returned "" would show
up in facters output as "", rather than not showing up at all. The LSB and VLAN facts have been
updated to x this bug.
Facter 2.0.0
For historical reasons, Facter 2.0.0 was never released. Facter 2.0.1 is the rst release in the Facter
2 series.
In May 2012, several release candidates were published for a Facter 2.0.0 release, using code that
had diverged from the 1.6 series. After testing it, the Puppet community and developers decided
that this code wasnt yet usable and the release was canceled, in favor of continuing work that
became the Facter 1.7 series.
Since the 2.0.0rc1 tag in the Facter repo was already occupied by that canceled release, and since
issuing a RC5 out of nowhere might have been confusing, we decided to go directly to 2.0.1
instead.
2010 Puppet Labs info@puppetlabs.com 411 NW Park Street / Portland, OR 97209 1-877-575-
9775

Facter2 0 PDF

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Facter2 0 PDF

Cargado por

Copyright:

Formatos disponibles

Facter 2.

También podría gustarte