If facter switched to using uname on unix/linux, it would be a problem. If I type uname -n it will spit out the fqdn to me. If I type hostname -s, it gives me the short, the actual hostname. I don't think a switch like that will solve the original issue provided.
On Oct 4, 2011, at 6:20 AM, Ken Barber wrote: > So again quoting Dexter (who should really be participating in this > discussion himself :-P). Perhaps a more POSIX purist set of facts > based around the posix/opengroup standards would be desirable: > > http://pubs.opengroup.org/onlinepubs/009604599/basedefs/sys/utsname.h.html > http://pubs.opengroup.org/onlinepubs/009695399/utilities/uname.html > > For example ... > > uname_nodename: is uname -n only and isn't contrived > uname_release: is uname -r > uname_version: is uname -v > ...etc... > > This duplicates a lot of facts in behaviour - but sticks to the posix > compliance interpretation only. I'm not 100% on weither this is the > correct approach but the idea sounds sane enough - the question is > really if it is core worthy or not. If this is implemented how many > people would prefer or use this directly (besides Doug of course - who > has made his sentiments clear :-P)? > > My main concern here is that this implementation is not truly > cross-platform - only POSIX specific (which is pretty good coverage > anyway - but not complete). The point and vision of facter (and most > puppet resources) is to provide cross-os compatibility where possible > if anything providing a later that binds POSIX and other non-posix OS > to one type of data ... so I see these facts as binding puppet content > to POSIX only machines. So while the interface may be there ... we > would want to be careful to avoid using it directly in cross-os > resources and puppet code. Having said that, this would not be the > first time we have had to provide OS specific facts :-). > > IMO - If implemented I can envision providing this interface and on > POSIX machines just using these facts to glean things like > 'kernelversion' on compatible machines instead of duplicating the > uname -v call again. > > ken. > > On Mon, Oct 3, 2011 at 11:59 PM, Doug Balmer <[email protected]> wrote: >>> about. In fact, I think if you were to use periods it would confuse >>> DNS resolve because it follows the same convention as stated in the >>> RFC. If I were external trying to look up host.server.domain.com, my >>> DNS would try to look for a nameserver for server.domain.com. You >>> would still be forced to use a new zone file for server.domain.com. >> >> man resolv.conf >> See options ndots >> If I have a host with FQDN foo.bar.example.com and I have "options >> ndots:2\nsearch example.com" in /etc/resolv.conf then I can resolve >> "foo.bar". >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
