On Oct 28, 2008, at 12:21 PM, Andrew Wasilczuk wrote:
>
> Hiya,
>> Facter uses the first found value.
>>
>> Unfortunately, it currently has no way to specifically force a higher
>> priority on a resolution mechanism -- this would be a good thing to
>> file as a feature request.
>>
>> However, resolutions are sorted in descending order by the number of
>> confinements, so if you add a confine you know will be true (e.g., in
>> your case, confine :operatingsystem => :solaris), then your extra
>> confine will cause your fact resolution mechanism to be sorted first.
>>
>> Yes, I know this is hackish; please file a feature request, as it'd
>> be
>> pretty easy to fix at this point (because of refactoring in 1.5).
>>
> I'm looking to upgrade from facter 1.3.7 to 1.5.2 on FreeBSD, but I've
> hit a problem similar to the one described here. Just to make sure I
> got this right, because resolutions are sorted in descending order
> facter will get the domain name from resolv.conf first and fall back
> to
> other methods only if it fails?
>
> In facter 1.3.7 the domain name would always be set from the hostname.
> Changing resolv.conf would make no difference. The situation is
> reversed in 1.5.2 where resolv.conf seems to have the upper hand. In
> most cases I put more trust in the hostname being correct rather than
> resolv.conf, which is often generated dynamically by dhcp. One
> scenario
> where this is problematic is on laptops which roam through different
> dhcp networks. In this case you can't trust resolv.conf at all.
>
> Was this an intended change or is this a bug?
>
> Setting confine :kernel => :FreeBSD on the domain fact (the one that
> uses the hostname) "fixes" the problem, but maintaining a separate
> fork
> of facter just to get this one thing working is overkill.
This is a bug, and (I believe) has been fixed in the current repo. I
think we'll be putting out a 1.5.3 release soon with this fix.
--
At my lemonade stand I used to give the first glass away free and charge
five dollars for the second glass. The refill contained the antidote.
-- Emo Phillips
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
