You can effectively override a fact by setting the weight, as follows
Facter.add(:hostname) do
has_weight 200
setcode do
# your own hostname implementation
end
end
On Fri, Oct 7, 2011 at 12:57 PM, Matthew Black <mjbl...@gmail.com> wrote:
> You are confusing Standards (RFC) and POSIX. They are typically mutually
> exclusive in their roles.
> RFC dictates the standards the information should be presented. POSIX
> dictates the API that the information is obtained. The difference can be
> plainly seen in message protocols, like
> smtp. http://nemo.its.uiowa.edu/reference/sendmail-rfc.html
> I would rather facter had a way to override fact definitions, so I could use
> custom facts for things like hostname.
> Instead of having Facter.add(:hostname) it would be
> Facter.replace(:hostname), then the problem would be solved by creating a
> custom hostname and domain facts for people who want to go against the
> standards. In fact the idea of replacing facts with custom facts might be
> handy in other situations and I vote to have that added instead of changing
> how facter pulls information.
> Although until sometime as that is in place you can always modify the
> hostname.rb and domain.rb in facter lib to present the data the way you want
> it for your environment.
>
>
> On Fri, Oct 7, 2011 at 11:54 AM, easybeats <dext...@gmail.com> wrote:
>>
>> Hi Tim,
>>
>> > IMO, you've got to be clear what the underlying information model that
>> > puppet / facter supports is. In particular, if you simply say that the
>> > facts are the data reported by the underlying tools, then you've got
>> > zero abstraction of the model and it's 'an exercise for the user to
>> > handle the differences between platforms.
>>
>> I agree with you there needs to be clarity as to what standard/
>> information model is to be supported. To me there are two standards in
>> operation here and an assumption being made.
>>
>> At this time to me DNS is assumed to be the only valid overarching
>> "directory service" and "naming standard".
>>
>> POSIX the underlying Unix standard makes no such assumptions as to
>> which overarching directory service or naming standard will be in
>> operation. Hypothetically should a site admin choose to support WINS
>> (heaven forbid) or some other standard, POSIX which has portability in
>> mind caters for that. I concede DNS is the most widely used directory
>> standard, naming service around but it is still an assumption.
>>
>> If DNS is the only valid naming standard that can apply to the
>> hostname is to the exclusion of IEEE Std 1003.1-2008 (POSIX:2008)
>> which to my knowledge doesn't comment on the restriction of character
>> sets for hostnames, so currently puppet at this point in time can not
>> report on a POSIX compliant hostname from the Kernel if it contains a
>> period (.). (NB if puppet were to support this I'm suggesting a
>> different fact so as to not interfer with current operations)
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html
>>
>> If to support multiplatform (IE Windows), one must allow for and
>> consider other valid directory naming standards and directory services
>> and or the underlying OS standard.
>>
>> > Alternatively, you can
>> > define a canonical ontology and how the different tools map onto that
>> > ontology. Even with such an ontology, you probably need to include
>> > platform specific types in the data model.
>> > fwiw, I'm also a big fan of encouraging best practice in the use of
>> > the tools, so in this instance, the teaching/documentation would show
>> > how to avoid naming pitfalls introduced by differences in standards
>> > and how to remediate an environment that's fallen into such a trap.
>> > Otherwise, the tools get bogged down in handling nasty
>> > inconsistencies, which are impossible to cope with cleanly in code as
>> > they depend on implicit or explicit customer organisational policies -
>> > and the tool gets blamed for any shortfalls, while the organisation
>> > keeps digging itself deeper into the trap.
>>
>> I agree with promoting best practice, however which standard(s) is/are
>> to be supported on a given platform should be taken into account.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
