Skip to content

Latest commit

 

History

History
 
 

lab-08.1-Create-a-custom-fact

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 

Lab 8.1: Create a custom fact

Take a look at your /etc/krb5.conf file. This configures the Kerberos network authentication service. It is not configured on these machines, so your default realm should be set to EXAMPLE.COM. If we were to write classes that could use Kerberos authentication, it would likely be useful to know what this is set to.

Your task is to write a default_realm fact to expose this information as a global variable. Using the command line to parse this value might look something like

awk '/default_realm/{print $NF}' /etc/krb5.conf

Steps

Develop your fact

  1. Change directory to your [modulepath]

    $ cd $(puppet agent --configprint environmentpath)/production/modules

  2. Create a new module kerberos with the pdk command.

    $ pdk new module

  3. You will see several questions requiring an answer. Enter the answers as you see below:

    Replace the N in studentN with your student number, e.g. student8

    Question Answer
    Module Name kerberos
    Forge Name studentN
    Credit author Student N
    License Apache-2.0
    Operating systems RedHat
  4. Change directories to kerberos.

  5. Create your default_realm.rb custom fact.

    • Edit lib/facter/default_realm.rb
    • Execute the sample shell command as a setcode string.
  6. Syntax check and test your new fact locally.

    • /opt/puppetlabs/puppet/bin/ruby -c lib/facter/default_realm.rb
    • RUBYLIB="kerberos/lib" facter default_realm

Deploy and validate your new fact

  1. Deploy your codebase.

  2. Trigger pluginsync as part of a Puppet run:

    puppet agent -t

  3. Review the log output. You should see the md5 hash of the file as it syncs.

  4. Syntax check the fact file.

    ruby -c $(puppet config print plugindest)/facter/default_realm.rb

  5. Run facter to retrieve the value of your fact.

    facter -p default_realm

A full fledged development workstation would likely have Puppet available locally, meaning that you could validate code before deploying and syncing.

Solution

Your module structure should resemble

[root@training modules]# tree kerberos/
kerberos/
└── lib
    └── facter
        └── default_realm.rb

Example file: kerberos/lib/facter/default_realm.rb

Facter.add("default_realm") do
  setcode "/bin/awk '/^#/ {next} /default_realm/{print $NF}' /etc/krb5.conf"
end

| Previous Lab | Next Lab |