Facter expects that a FACTERLIB environment variable to be set to help locate libfacter.so - https://github.com/puppetlabs/facter/blob/f7ca2ac28b4e60703ae7979c7cde7239e59b40e8/lib/facter.rb.in#L30
- When running the MCollective agent plugin on Windows, it's daemon is hosted under rubyw.exe.
- When the plugin is loaded, it calls require 'puppet' at https://github.com/puppetlabs/mcollective-puppet-agent/blob/02ddb2ce3a96f4ee3ee7cc4b63c17bd25571a65e/util/puppet_agent_mgr.rb#L35
- That it turn performs a require 'facter', which then proceeds to load facter.rb and try to find libfacter.so
However, since FACTERDIR environment variable is not set, and since the default specified path on Windows is set at compile time and doesn't match the installation directory (which should probably be addressed as a separate issue), Puppet fails to load libfacter.so. Presumably the same scenario will affect loading native facter from modules / module tests that require 'puppet', so this necessitates a Facter based solution rather than a MCO + packaging solution.
When Puppet is launched from the command line on Windows, its through an environment.bat that sets FACTERDIR.
Theoretically then, one solution would be to launch MCO through a batch file, and ensure the batch file sets FACTERDIR. Not so fast! This was previously the approach, but loading services through batch files has problems, and as part of
MCO-548, the usage of daemon.bat was discontinued on Windows and replaced with an invocation of rubyw.exe in the service registration.
The appropriate fix here seems to be to load libfacter.so relatively on Windows based on the location of facter.rb. In Windows packaging, such a structure is always present