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 <doug.bal...@gmail.com> 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 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.
