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.
