Custom fact ( complete fail )

[omfg9899]

  I know I must be missing something stupid, but I have tried for 2 days now without success.

 

 I am using puppet stand alone, no master.

 I need a simple custom fact to be created to assist in deploying the correct configuration at build time.

  I made this super simple fact.. 

<fact>

# envir.rb

Facter.add('environment_class') do

    setcode '/bin/cat /etc/default/environment.info'

    end

</fact>

I have placed this file in MANY different places as suggested and it never works.  However, if i run facter envir.rb  it will stick the fact into the fact list.  This fact basically determines if the system is dev/cert or prod and assigns certain configs for various services based on that value.  The only thing in the environment.info file is going to be prod or cer or prod.

  Out of desperation I ran strace to see if it was even looking at the file and to my surprise it was.  I  was surprised to see that it was infact touching the file but can't understand the output.

<output>

tat("/etc/facter/facts.d/envir.rb", {st_mode=S_IFREG|0755, st_size=104, ...}) = 0

geteuid()                               = 0

getegid()                               = 0

getuid()                                = 0

getgid()                                = 0

access("/etc/facter/facts.d/envir.rb", X_OK) = 0

.......

open("/etc/facter/facts.d/envir.rb.ttl", O_RDONLY) = -1 ENOENT (No such file or directory)

stat("/etc/facter/facts.d/envir.rb", {st_mode=S_IFREG|0755, st_size=104, ...}) = 0

rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0

pipe([5, 6])                            = 0

futex(0x7f5fe8480a84, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f5fe8480a80, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1

futex(0x7f5fe8480ab0, FUTEX_WAKE_PRIVATE, 1) = 1

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f5fe86b19d0) = 4959

rt_sigaction(SIGVTALRM, {0x7f5fe81c74e0, [], SA_RESTORER, 0x7f5fe7f8c4a0}, {0x7f5fe81c74e0, [], SA_RESTORER, 0x7f5fe7f8c4a0}, 8) = 0

clone(child_stack=0x7f5fe2523ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f5fe25249d0, tls=0x7f5fe2524700, child_tidptr=0x7f5fe25249d0) = 4960

futex(0x7f5fe8480ae4, FUTEX_WAIT_PRIVATE, 7, NULL) = 0

futex(0x7f5fe8480ab0, FUTEX_WAIT_PRIVATE, 2, NULL) = 0

futex(0x7f5fe8480ab0, FUTEX_WAKE_PRIVATE, 1) = 0

close(6)                                = 0

fcntl(5, F_GETFL)                       = 0 (flags O_RDONLY)

./facter_dot_d.rb:148: command not found: /etc/facter/facts.d/envir.rb

</output>

 Any thoughts?

 Thanks in advance.

 J

[omfg9899]

P.S. If I run "facter envir.rb" it works, it shows up in the list.. :/

 J

[Felix Frank]

On 09/07/2014 05:41 PM, omfg9899 wrote:
> I have placed this file in MANY different places as suggested and it
> never works.

Well...*what* places?

The facts.d directory is the one place where this does *not* belong.

Please try /etc/puppet/modules/env/lib/facter/envir.rb

provided that /etc/puppet/modules is in your modulepath.

[omfg9899]

  So I didn't have a "/etc/puppet/modules/env/lib/facter/" directory structure of any kind.

  I had a structure of "/var/els/puppet/modules/facts/files/envir.rd" and /var/els/puppet/modules/env/lib/facter/envir.rb"

 Neither of those work, however, I am just running facter.  If puppet runs facter differently I wouldn't know what that difference is.

I did notice a strange directory "/usr/lib/ruby/site_ruby/1.8/facter/" where a-lot of stuff was coming out of. 

 Any thoughts?

 Thanks,

 J

[Felix Frank]

As I mentioned, you *modulepath* is key here.

What is the output of

puppet apply --configprint modulepath
puppet apply --configprint environmentpath

Also, what version of Puppet is this?

[omfg9899]

puppet apply --configprint modulepath 

/etc/puppet/modules:/usr/share/puppet/modules

puppet apply --configprint environmentpath 

invalid parameter: environmentpath

 I inherited this, and am thinking more and more that it wasn't implemented anywhere close to best practices.

  So the environmentpath seems to have been deprecated from what I read.

  Based on the on the "puppet apply --configprint modulepath", surely placing these factor files in either of directories wouldn't make a difference?

  I think the following may have worked, but it seems hacky and I need to do further tesitng.

"export FACTERLIB="/var/els/puppet/modules/env/lib/facter"; /usr/bin/puppet apply /var/els/puppet/manifests/site.pp --modulepath /var/els/puppet/modules --debug"

 After running that it "appears" that the new fact is there.  I am going to do a test build and see if it works.

 Thanks,

J

[Felix Frank]

On 09/08/2014 05:29 PM, omfg9899 wrote:
> puppet apply --configprint modulepath
> /etc/puppet/modules:/usr/share/puppet/modules
>
> puppet apply --configprint environmentpath
> invalid parameter: environmentpath
>
>
>
> I inherited this, and am thinking more and more that it wasn't
> implemented anywhere close to best practices.
> So the environmentpath seems to have been deprecated from what I read.

No, you got that backwards. Modulepath is deprecated in favor of
environmentpath, but your Puppet version does not yet support that.
Which is fine, it's a rather new feature.

> Based on the on the "puppet apply --configprint modulepath", surely
> placing these factor files in either of directories wouldn't make a
> difference?

What makes you say that?

On the contrary, /etc/puppet/modules/env/lib/facter/environment_class.rb
should have definitely worked, because Puppet would pick up the "env"
module and locate the lib/facter/environment_class.rb fact.

When the code is placed there, can you make double sure that these do
not work?

puppet apply -e 'notify { $environment_class: }'

facter -p | grep environment_class

(When writing this I realized that your file used to be named "envir.rb"
which was another mistake - it must be named after the fact I think).

> I think the following may have worked, but it seems hacky and I need
> to do further tesitng.
> "export FACTERLIB="/var/els/puppet/modules/env/lib/facter";
> /usr/bin/puppet apply /var/els/puppet/manifests/site.pp --modulepath
> /var/els/puppet/modules --debug"

Well, the proper way to do this would be

FACTERLIB=/var/els/puppet/modules/env/lib/facter puppet apply
/var/els/puppet/manifests/site.pp --modulepath /var/els/puppet/modules

And yes, it's hardly ideal.

> After running that it "appears" that the new fact is there. I am going
> to do a test build and see if it works.

Meh. Try with the corrected file name in the proper module location.

If you want to stick to /var/els, add the following to your puppet.conf

[main]
modulepath=/var/els/puppet/modules

But then, you likely have more stuff there, so perhaps you even want to
override $configdir or another deeply rooted config value.

Good luck.

[Garrett Honeycutt]

Hi,

Take a look at external facts[1]. Since your fact is spawning a shell to
cat a file, you could get the same functionality without the effort of
maintaining that code.

Given a text file, /etc/facter/facts.d/environment_class.txt with the
contents

environment_class=some_text

you would have the custom fact 'environment_class' with the value
'some_text'.

[1] -
https://docs.puppetlabs.com/facter/latest/custom_facts.html#external-facts

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[omfg9899]

  I may not have been clear..

  We don't "currently" use a puppet master, although we are currently evaluating this, among other options moving forward.  The mess I was left with appears to have absolutely minimal configuration as to just get to point B as quickly as possible.

 So when these instances come up the directory that the modules are untarred in are just that.  A dumping place for the entire puppet repo since we have no master.

/etc/facter/ doesn't exist at all, while this can be remedied I would think that the puppet install should have created it.  This is why I have been looking for a directory that I place my facts in that puppet will just "pickup" and run.  The aforementioned fix did not work, the variables I need were not present and the proper 'versioned' config files did not install.

 Doing an strace revealed that facter never touched /etc/facter/facter.d/ . This is troubling because it was before..  Puppet is proving to be very troublesome.

 I just need a place to plop down a few .rb files and then let ruby rip the install up.

[omfg9899]

  I didn't want to leave this unanswered..

 In the end, I had to create a "script" using the "files" function inside cloud formation.

  In the "script" I set the value "FACTERLIB=/var/els/puppet/modules/facts/files" and in that same script executed my puppet apply command and it worked.  Amazon came back later with this answer.

"

"commands" : {

    "run_puppet" : {

        "command" : "/usr/bin/puppet apply /var/els/puppet/manifests/site.pp --modulepath /var/els/puppet/modules --debug", "sleep 3s",

        "env" : { "FACTERLIB" : "/var/els/puppet/modules/facts/files" },

        "cwd" : "~",

        "ignoreErrors" : "false"

    }

}"

 Which is cleaner than the way I did it and I may change to that method in the future.  But for now, I am sticking with what works and will test out other methods later.  That wouldn't be so clean if one considers that the whole of the template would have to be changed to fit this or the order of operations would be 

 Thanks,

 

  J