No idea what virtual box is doing, I'd try to keep it internal and use
existing facts like "interfaces", lop off the loopback interface and grab
the last element of the "array" and use Facter.value as you are doing
John
On 10 February 2015 at 05:31, John D'Ausilio <jdausi...@gmail.com> wrote:
> I have more information .. it seems almost like facter is caching a stale
> result. While troubleshooting at the commandline I commented out the second
> line (Facter::value) and had it just return the name it was finding. After
> I made that change 'facter last_interface' returned the (correct) interface
> name, while 'facter | grep last_interface' produced the same IP address as
> before!
>
> It appears that this problem is happening only on the target box (Centos
> 6.6 minimal, running in virtualbox) but not on my development system
> (Ubuntu 14.04 on real hardware). Is there anything weird about behaviour in
> virtualbox vms?
>
> On Mon, Feb 9, 2015 at 11:12 AM, John D'Ausilio <jdausi...@gmail.com>
> wrote:
>
>> Just to make sure .. simplified without perl ..
>>
>> [root@uc-01 ~]# cat
>> /opt/wdts/puppet/production/modules/puppet/lib/facter/last_interface.rb
>> Facter.add('last_interface') do
>> setcode do
>> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback | sed
>> \'s/://g\' | cut -d\' \' -f2 | sort -n | tail -1')
>> Facter.value("ipaddress_"+name)
>> end
>> end
>>
>> [root@uc-01 ~]# ip -o l
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN \
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>> state UP qlen 1000\ link/ether 08:00:27:b6:de:19 brd ff:ff:ff:ff:ff:ff
>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>> state UP qlen 1000\ link/ether 08:00:27:1d:eb:14 brd ff:ff:ff:ff:ff:ff
>> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>> state UP qlen 1000\ link/ether 08:00:27:90:be:4c brd ff:ff:ff:ff:ff:ff
>> [root@uc-01 ~]# facter | grep last_interface
>> last_interface => 10.0.2.15
>> [root@uc-01 ~]# facter last_interface
>> 10.200.111.100
>> [root@uc-01 ~]#
>>
>> On Mon, Feb 9, 2015 at 10:34 AM, John D'Ausilio <jdausi...@gmail.com>
>> wrote:
>>
>>> Point taken on perl overkill .. trying to get something working and
>>> copy/pasted someone else's solution ;)
>>>
>>> In any case, I expect this to get all of the non-localhost interface
>>> names, sort them, and return me the IP address of the last in the
>>> list.
>>> When run from commandline by name it works great. When I run facter
>>> alone (show all facts) or Puppet runs it it appears to instead give me
>>> the first one in the list.
>>>
>>> On Mon, Feb 9, 2015 at 9:25 AM, jcbollinger <john.bollin...@stjude.org>
>>> wrote:
>>> >
>>> >
>>> > On Sunday, February 8, 2015 at 3:47:58 PM UTC-6, John D'Ausilio wrote:
>>> >>
>>> >> So I have a custom fact which works fine from the commandline: facter
>>> >> last_interface (it returns the ip address of the last of a sorted
>>> list of
>>> >> interface names)
>>> >>
>>> >> If I just run facter without parameters, the value in last_interface
>>> is
>>> >> incorrect!
>>> >>
>>> >> Is there something different between the environment when running
>>> facter
>>> >> without args and the environment when asking for a specific fact?
>>> >>
>>> >> Facter.add('last_interface') do
>>> >> setcode do
>>> >> name = Facter::Core::Execution.exec('ip -o l | grep -v loopback |
>>> perl
>>> >> -lane\'$F[1]=~s/://g;print $F[1]\' | sort -n | tail -1')
>>> >> Facter.value("ipaddress_"+name)
>>> >> end
>>> >> end
>>> >>
>>> >
>>> >
>>> > No. The environment provided to Facter (or to any command) is
>>> determined by
>>> > how you launch the command. The arguments to the command cannot
>>> affect its
>>> > environment.
>>> >
>>> > We might be able to offer better insight if you explained what fact
>>> value
>>> > you expect, and why, and what you actually see in the incorrect case.
>>> >
>>> > I will say right now, however, that it is awfully strange and
>>> heavyweight to
>>> > use Perl as part of determining the fact value when the fact
>>> computation is
>>> > already running in Ruby. Even if you want to do the whole job with an
>>> > external pipeline, 'sed' would be a lighter-weight (and simple-syntax)
>>> > choice. Nevertheless, I don't see how that could contribute to
>>> differing
>>> > results.
>>> >
>>> >
>>> > John
>>> >
>>> > --
>>> > 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/f0aa94a6-aa55-4420-97f0-1f82c55c6207%40googlegroups.com
>>> .
>>> >
>>> > 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/CAO1ctWe0xJPd43M5ck%2BJcmYA32YZ%3DO-mCk6jSyuLV7s0ng%2Bi5Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAO1ctWe0xJPd43M5ck%2BJcmYA32YZ%3DO-mCk6jSyuLV7s0ng%2Bi5Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
John Warburton
Ph: 0417 299 600
Email: jwarbur...@gmail.com
--
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/CAAJLFxXgDy%2BAAcirMjwZVuZd9dqy5qz0UjM_i2Lr4EQjMCpboQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
