Hi Matthew, So just to be clear - I don't think we'll want to change the 'hostname' fact from its current behaviour. I think this is agreed from all angles.
So the special case here that Doug is describing is when someone uses a shorter name as the hostname on a box. For example 'mybox.mylocation' and the domain name has the trailing part 'mydomain.com'. What I'm really curious about and need help understanding ... is to find out who else is doing this on the list to figure out the value of adding handling for this case. ken. On Wed, Oct 5, 2011 at 8:54 AM, Matthew Black <mjbl...@gmail.com> wrote: > 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 <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. >> > > -- > 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.