Hi Mike,
On Thu, Mar 24, 2016 at 3:58 PM, Mike Reed <mjohn.r...@gmail.com> wrote:
> Hey Peter,
>
> I've done some additional reading and I believe I understand what's
> happening now.
>
> Thank you very much for the information and help.
>
Glad you got things working; let me know if there are any other questions
that come up.
>
> Cheers,
>
> Mike
>
>
> On Thursday, March 24, 2016 at 2:25:38 PM UTC-7, Mike Reed wrote:
>>
>> Hey Peter,
>>
>> Thank you for the reply and the information.
>>
>> In terms of the piped greps, the second <domain> string is actually our
>> internal domain name (which I removed and replaced with <domain>) for
>> security sake.
>>
>> I'm a little confused by code above as I'm still not getting what I would
>> expect from your code above. I think part of my confusion is how the
>> recommended code gives me a true/false value. I've changed the fact to now
>> look like this:
>>
>> require 'facter'
>>
>> Facter.add(:pbis_joined) do
>> setcode do
>> !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli
>> query | grep -i 'domain' | grep -i '<doman>'}).nil? && $?.success?
>> end
>> end
>>
>> The issue I'm seeing is that on a machine that is added to the domain, I
>> would expect the /opt/pbis...command to return true (as evidenced by the
>> exit status of zero on the command line). However, upon running this new
>> fact, I get a value of: pbis_joined => false; even though I know the
>> machine is on the domain and running the command manually does give me an
>> exit status of '0' on this particular machine.
>>
>> I tried this new fact on another machine that I know is not joined to the
>> domain and I do get a 'false' on that box.
>>
>> If the problem is that #exec returns nil or a string; and being that I'm
>> looking to evaluate against an integer, could I not just do something like
>> 'domain_return.to_i' in the original code?
>>
>
I wasn't very clear on what #exec returns: the string it returns is the
stdout output of the executed process as a string; thus it would not
contain a representation of the exit code as you've already surmised.
Unfortunately, right now Ruby's built-in `$?` global variable is the only
way of getting at the exit code from the executed process with the way the
Facter execution API is currently defined.
>
>> I wanted to thank you again for your help. It is very much appreciated.
>>
>> Cheers,
>>
>> Mike
>>
>>
>>
>> On Thursday, March 24, 2016 at 1:06:48 PM UTC-7, Peter Huene wrote:
>>>
>>> Hi Mike,
>>>
>>> On Thu, Mar 24, 2016 at 12:30 PM, Mike Reed <mjohn...@gmail.com> wrote:
>>>
>>>> Hey Peter,
>>>>
>>>> Thank you for the reply.
>>>>
>>>> If I run the command on a machine that I know is 'joined' to the domain
>>>> and run 'echo $?' immediately after, I get a return of '0'.
>>>>
>>>
>>> If you're going solely off of grep's exit status, try this:
>>>
>>> ```
>>> Facter.add(:pbis_joined) do
>>> setcode do
>>> !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli
>>> query | grep -i 'domain' | grep -i '<domain>'}).nil? && $?.success?
>>> end
>>> end
>>> ```
>>>
>>> Breaking that down:
>>>
>>> ```
>>> !Facter::Util::Resolution.exec(%q{/opt/pbis/bin/domainjoin-cli query |
>>> grep -i 'domain' | grep -i '<domain>'}).nil?
>>> ```
>>>
>>> This runs the command and ensures #exec doesn't return nil (which will
>>> happen if it failed to execute the command, e.g. command not found).
>>>
>>> ```
>>> $?.success?
>>> ```
>>>
>>> This ensures the executed process exited with a zero exit code (i.e. $?
>>> in a shell == 0).
>>>
>>> On an aside: do you need the piped greps? Seems like the latter grep
>>> would be all that's needed assuming you're looking for just "<domain>",
>>> unless you intended this to be either "domain" or "<domain>", which won't
>>> work as currently constructed.
>>>
>>>
>>>>
>>>> Thank you again,
>>>>
>>>> Mike
>>>>
>>>> On Thursday, March 24, 2016 at 12:13:53 PM UTC-7, Peter Huene wrote:
>>>>>
>>>>> Hi Mike,
>>>>>
>>>>> On Thu, Mar 24, 2016 at 11:59 AM, Mike Reed <mjohn...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> I'm a little stumped on why this fact is returning the incorrect
>>>>>> value and I was hoping somebody would have some advice on this one.
>>>>>>
>>>>>> The fact is very basic and looks like this:
>>>>>>
>>>>>> # custom fact for detecting if machine is joined to the domain
>>>>>> require 'facter'
>>>>>>
>>>>>> Facter.add(:pbis_joined) do
>>>>>> setcode do
>>>>>> domain_check = %q{/opt/pbis/bin/domainjoin-cli query | grep -i
>>>>>> 'domain' | grep -i '<domain>'}
>>>>>> domain_return = Facter::Util::Resolution.exec(domain_check)
>>>>>> if domain_return == 0
>>>>>>
>>>>>
>>>>> Facter::Util::Resolution.exec returns the command's output as a string
>>>>> or nil if the command failed. Thus, I would expect this conditional
>>>>> (`domain_return == 0`) to never evaluate to true because a string or a nil
>>>>> can never equal 0.
>>>>>
>>>>> What does the command output if you run it manually when you expect
>>>>> the `pbis_joined` facter to be true?
>>>>>
>>>>>
>>>>>> pbis_joined = true
>>>>>> else
>>>>>> pbis_joined = false
>>>>>> end
>>>>>> end
>>>>>> end
>>>>>>
>>>>>
>>>>> Also, the `pbis_joined` local variable serves no purpose here, as it
>>>>> is the return value from the block that sets the fact's value.
>>>>>
>>>>>
>>>>>>
>>>>>> Regardless of whether the domain_check command is a success on the
>>>>>> client, I always get a value of 'true' from the fact. In fact, if I
>>>>>> completely remove the /opt/pbis folder from the machine and run the fact
>>>>>> again, I still get a value of 'true'. Additionally, If I manually run
>>>>>> the
>>>>>> domain_check command on a machine that I know is not joined to the
>>>>>> domain,
>>>>>> I will still get a value of 'true' from the fact.
>>>>>>
>>>>>> I've also tried both single '=' and double '==' for the 'if
>>>>>> domain_return' piece of the fact and neither seem to give me what I want.
>>>>>> I then thought that the domain_check object may not be considered an
>>>>>> integer when comparing against the '0' so I added 'domain_return.to_i'
>>>>>> and
>>>>>> still got the same result.
>>>>>>
>>>>>> The code within the manifest that looks to this fact looks like
>>>>>> this: if ($::pbis_joined == true) {etc,etc,etc}
>>>>>>
>>>>>> I do have stringify_facts set to 'false' within puppet.conf on both
>>>>>> the client and the master.
>>>>>>
>>>>>> Puppet version 3.6.2/Hiera version: 1.3.4
>>>>>>
>>>>>> Does anybody have any suggestions they can give me as to why I'm not
>>>>>> getting the correct return value?
>>>>>>
>>>>>> As always, thanks to everybody for their help and support.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/a1f8ece8-627b-478d-a108-97c91d76d654%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/puppet-users/a1f8ece8-627b-478d-a108-97c91d76d654%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> 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.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/puppet-users/c7d8d40d-5121-426e-a208-a8a4af3bffb1%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/puppet-users/c7d8d40d-5121-426e-a208-a8a4af3bffb1%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> 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/68cbdf79-5e24-4bca-ac17-dc016bfbf42f%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/68cbdf79-5e24-4bca-ac17-dc016bfbf42f%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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/CACZQQfOgkXQMa97VHH6%2Bmzt4AbMXmVK8aZ221m4LBU8ZTAgocA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
