Using bash for custom facts - results are strings, not booleans

18 views
Skip to first unread message

Prentice Bisbal

unread,
Jul 11, 2019, 3:55:43 PM7/11/19
to puppet...@googlegroups.com
I'm trying to use bash to create custom facts that are booleans,
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?

--
Prentice

Ben Ford

unread,
Jul 11, 2019, 4:30:54 PM7/11/19
to puppet...@googlegroups.com
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}'



--
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...@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.

Josh Cooper

unread,
Jul 12, 2019, 3:55:58 PM7/12/19
to puppet...@googlegroups.com
On Thu, Jul 11, 2019 at 1:30 PM Ben Ford <ben....@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...@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...@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...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


--
Josh Cooper | Software Engineer

Helmut Schneider

unread,
Jul 23, 2019, 4:08:00 AM7/23/19
to puppet...@googlegroups.com
'Prentice Bisbal' via Puppet Users wrote:

> I'm trying to use bash to create custom facts that are booleans,
> 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

Does that change anything?

rpm --quiet -q gdm && echo 'gdm_installed=true' || echo
'gdm_installed=false'

Jesse Hathaway

unread,
Jul 23, 2019, 10:49:39 AM7/23/19
to Puppet Users
On Thursday, July 11, 2019 at 2:55:43 PM UTC-5, Prentice Bisbal wrote:
I'm trying to use bash to create custom facts that are booleans,
Unfortunately, when I do, the values are interpreted as strings, and not
booleans. For example, here is my bash script, gdm.sh: 

As Ben and Josh stated you need to use json or yaml output to get datatypes
other than strings. The docs are still out of date on this supported feature.

Here is an example of the difference:

key value output only parses strings:

  $ cat butter
  #!/bin/bash
  echo 'butter=false'

  $ facter --json butter
  {
    "butter": "false"
  }

yaml output parses yaml datatypes

  $ cat bubbles
  #!/bin/bash

  cat <<'EOF'
  ---
  bubbles: false
  EOF

  $ facter --json bubbles
  {
    "bubbles": false
  } 

Ben Ford

unread,
Jul 23, 2019, 9:09:39 PM7/23/19
to puppet...@googlegroups.com

> On Jul 23, 2019, at 7:49 AM, Jesse Hathaway <je...@mbuki-mvuki.org> wrote:
>
> The docs are still out of date on this supported feature.

One thing to note here is that whenever you find a docs page lacking, you can now provide feedback directly on the page. Just scroll to the bottom and give it a star ⭐️ rating. That will open a dialogue for you to provide suggestions for improvement.

Thanks for pointing this out! I'll make sure the team sees this.
Reply all
Reply to author
Forward
0 new messages