Skip to content

Inventory discovery

Mikhail Gusarov edited this page Nov 12, 2013 · 1 revision

Problem

OS/distro detection code is fragile and hard to extend.

Idea

After detecting built-in hard classes CFEngine runs a set of scripts using module protocol. Classes reported by those modules are treated as hard classes. Variables reported are put into inventory scope by default (one can change the scope by a ^context directive).

Files layout

The following files are run after built-in discovery is performed, but before running promises.cf:

  • $INPUTSDIR/inventory-discovery/*.{discovery,exe}
  • $INPUTSDIR/inventory-discovery/$(sys.class)/*.{discovery,exe}.
  • $INPUTSDIR/inventory-discovery/$(sys.arch)/*.{discovery,exe}.
  • $INPUTSDIR/inventory-discovery/$(sys.class)-$(sys.arch)/*.{discovery,exe}.

*.discover files are run on non-Windows and if they are executable. *.exe files are run on Windows. Order of running inventory-discovery files is not guaranteed.

Rationale

  • Discovery code resides in policy repository in order to be transferred to clients using normal policy distribution mechanisms. This avoids problem similar to modules directory being outside of normal policy transfer workflow.
  • sys.class/sys.arch handling allows to use OS/arch-specific detection code (e.g. binaries).
  • File extension requirement avoids running temporary/transient files (E.g. foo~ from Vim, foo.cf-something or foo.rpmorig from CFEngine and RPM).
Clone this wiki locally