On Thu, Jul 11, 2019 at 1:30 PM Ben Ford <ben.f...@puppet.com> wrote:

> If you just return a string, then that's how it's interpreted even if it
> matches a keyword. To return a datatype, you'd need to return json.
>
> echo '{"gdm_installed": true}'
>
>
> and
>
> echo '{"gdm_installed": false}'
>
>
>
>
> On Thu, Jul 11, 2019 at 12:55 PM 'Prentice Bisbal' via Puppet Users <
> puppet-users@googlegroups.com> wrote:
>
>> I'm trying to use bash to create custom facts that are booleans,
>>
>
One clarification, "custom facts" are written in ruby (
https://puppet.com/docs/facter/latest/custom_facts.html), while facts
written in bash are examples of "external facts" (
https://puppet.com/docs/puppet/latest/external_facts.html).

Unfortunately, when I do, the values are interpreted as strings, and not
>> booleans. For example, here is my bash script, gdm.sh:
>>
>> #!/bin/bash
>>
>> PATH=/usr/bin:/bin:/usr/sbin:/sbin
>>
>> rpm --quiet -q gdm
>> retval=$?
>> if [ $retval -eq 0 ]; then
>>      echo gdm_installed=true
>> else
>>      echo gdm_installed=false
>> fi
>>
>> When I run the script, I get output in the following format, depending
>> on whether or not the gdm package is installed on the node:
>>
>> gdm_installed=true
>> gdm_installed=false
>>
>>  From everything I've read online, that should be sufficient, but when I
>> run 'puppet facts, I see that the values for gdm_installed are strings
>> and not booleans. For example:
>>
>> # puppet facts | grep false
>>      "fips_enabled": false,
>>      "gdm_installed": "false",
>>      "clientnoop": false
>>
>>
>> What am I doing wrong here? Is there something special about bash that
>> prevents it from being used like this?
>>
>
When writing a custom fact like:

Facter.add("myfact") do
  setcode { false }
end

The boolean fact value is preserved. This is why the core "fips_enabled"
and "clientnoop" facts are boolean false. When writing an external fact,
fact values will always be strings unless you emit them as structured data
(json or yaml) like Ben suggested.


>> --
>> Prentice
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/883d5506-d9aa-8aa1-4904-89176566efac%40pppl.gov
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CACkW_L63NeWyik17zwXKs7O5GM8GWZSzoGzTQmfGNiTMcwXRyg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CACkW_L63NeWyik17zwXKs7O5GM8GWZSzoGzTQmfGNiTMcwXRyg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Josh Cooper | Software Engineer
j...@puppet.com | @coopjn

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2Bu97unk51rSQfcd2iRsEms%2BDY7e1fm%3DhMA6xXLPAfGok-B7xA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to