Puppet users - Sep 2011 - Hostname fact doesn't handle hostnames with periods

I raised a bug earlier https://projects.puppetlabs.com/issues/9766 which
could be a can of worms.

My opinion is, facter has a bug and needs (eventual) fixing even if it
causes problems for some. There is a reason we have changelogs.

Debate?

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Is it really a good idea to have a period/dot in the hostname?
Although I do agree it should be considered as a bug in terms of
"good" programing. Cheers!!


On Sep 29, 3:25 am, Doug Balmer <doug.bal...@gmail.com>
wrote:
> I raised a bug earlierhttps://projects.puppetlabs.com/issues/9766which
> could be a can of worms.
>
> My opinion is, facter has a bug and needs (eventual) fixing even if it
> causes problems for some. There is a reason we have changelogs.
>
> Debate?
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Technically, a hostname may not legally contain a dot.  A fully qualified
domain name, OTOH, pretty much has to have (at least) one dot.

On Thu, Sep 29, 2011 at 10:59 AM, Sans <r.santanu.das@gmail.com> wrote:
> Is it really a good idea to have a period/dot in the hostname?
> Although I do agree it should be considered as a bug in terms of
> "good" programing. Cheers!!
>
>
> On Sep 29, 3:25 am, Doug Balmer <doug.bal...@gmail.com> wrote:
> > I raised a bug earlierhttps://projects.puppetlabs.com/issues/9766which
> > could be a can of worms.
> >
> > My opinion is, facter has a bug and needs (eventual) fixing even if it
> > causes problems for some. There is a reason we have changelogs.
> >
> > Debate?
>
> --
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Sep 29, 2011 at 12:25:23PM +1000, Doug Balmer
wrote:
>    I raised a bug earlier [1]https://projects.puppetlabs.com/issues/9766
>    which could be a can of worms.
>    My opinion is, facter has a bug and needs (eventual) fixing even if it
>    causes problems for some. There is a reason we have changelogs.
>    Debate?
Shortly:

I would really rather that widely-used software stuck to the basic RFC
conventions as much as possible.

More discussion:

I''m really curious to know know what your "various reasons"
are. If you have a special requirement for oddly shaped hostnames I sympathize
with you, since I imagine that it''s because of some vendor or manager
with very special ideas about the world. Possibly you''d be better off
sending a patch that people can use to set a configuration option in puppet.conf
to see your unique hostname requirement behaviour.

RFC-952 has this to say about periods:

''Note that periods are only allowed when they serve to delimit
components of "domain style names".''

http://tools.ietf.org/html/rfc952

For instance, to my knowledge:

bob.office.division.company.com (fully qualified domain name)
bob (hostname, the actual computer''s name)
office.division.company.com (domain)
bob.office.division (partially qualified domain name, so I''ve heard)
>    --
>    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+unsubscribe@googlegroups.com.
>    For more options, visit this group at
>    http://groups.google.com/group/puppet-users?hl=en.
> 
> References
> 
>    Visible links
>    1. https://projects.puppetlabs.com/issues/9766
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> ''Note that periods are only allowed when they serve to delimit
components
> of "domain style names".''
>
Let''s give this sentence some context.

<quote>
  ASSUMPTIONS

   1. A "name" (Net, Host, Gateway, or Domain name) is a text string
up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.).  Note that periods are only allowed when
   they serve to delimit components of "domain style names". (See
   RFC-921, "Domain Name System Implementation Schedule", for
   background).
</quote>

No mention there of a hostname having to be the first component of a
"name".
The succeeding RFC to this definition is in RFC1123 which states the
hostname can be up to 255 characters and begin with a number. No other
mention of the first component of the name being the hostname.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, Sep 29, 2011 at 5:28 PM, Doug Balmer <doug.balmer@gmail.com>
wrote:
> ''Note that periods are only allowed when they serve to delimit
components
>> of "domain style names".''
>>
>
> Let''s give this sentence some context.
>
> <quote>
>   ASSUMPTIONS
>
>    1. A "name" (Net, Host, Gateway, or Domain name) is a text
string up
>    to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
>    sign (-), and period (.).  Note that periods are only allowed when
>    they serve to delimit components of "domain style names". (See
>    RFC-921, "Domain Name System Implementation Schedule", for
>    background).
> </quote>
>
> No mention there of a hostname having to be the first component of a
> "name". The succeeding RFC to this definition is in RFC1123 which
states the
> hostname can be up to 255 characters and begin with a number. No other
> mention of the first component of the name being the hostname.
>
>
I seem to remember having this argument in the past in a workplace...

From memory the conclusion was that it is *labels* that can''t have
periods
in them, and hostnames are allowed to be a series of labels connected with
periods.

I''m not particularly in favor of the original suggestion, but I
don''t think
that RFC quoting alone is going to give us the right answer as to whether we
should do it or not.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
>  but I don''t think that RFC quoting alone is going to give us the
right
> answer as to whether we should do it or not.
>
100% agree.

To add to my point, facter should be reporting facts. If the hostname,
albeit possibly incorrectly, is set to "foo.bar" then it should report
it
so.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Except that is the fqdn.
On Sep 29, 2011 7:05 PM, "Doug Balmer" <doug.balmer@gmail.com>
wrote:
>>
>> but I don''t think that RFC quoting alone is going to give us
the right
>> answer as to whether we should do it or not.
>>
>
> 100% agree.
>
> To add to my point, facter should be reporting facts. If the hostname,
> albeit possibly incorrectly, is set to "foo.bar" then it should
report it
> so.
>
> --
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

So Dexter P sent me an email on this and I want to paraphrase:

"I understand there are major implications to this and the task may be
challenging, one suggestion would be to set up another facter
parameter something like

uname.hostname

or

uname.domain

or perhaps a configuration parameter to use POSIX compliance parameters."

Which makes more sense.

Our concept of ''hostname'' as a fact is equivalent to hostname
-s up
until now - it doesn''t mean the result of the
''hostname'' command
necessarily.

ken.

On Thu, Sep 29, 2011 at 7:05 PM, Doug Balmer <doug.balmer@gmail.com>
wrote:
>>  but I don''t think that RFC quoting alone is going to give us
the right
>> answer as to whether we should do it or not.
>
> 100% agree.
> To add to my point, facter should be reporting facts. If the hostname,
> albeit possibly incorrectly, is set to "foo.bar" then it should
report it
> so.
>
> --
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> Except that is the fqdn.
>
No.  "foo.bar" could be the hostname but foo.bar.example.com could be
the
FQDN.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> "I understand there are major implications to this and the task may be
> challenging, one suggestion would be to set up another facter
> parameter something like
>
> uname.hostname
>
> or
>
> uname.domain
>
> or perhaps a configuration parameter to use POSIX compliance
parameters."
>
> Which makes more sense.
>
> Our concept of ''hostname'' as a fact is equivalent to
hostname -s up
> until now - it doesn''t mean the result of the
''hostname'' command
> necessarily.

This makes sense and is an easy compromise. Could I suggest the doco reflect
that $hostname is `hostname -s`?

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> Our concept of ''hostname'' as a fact is equivalent to
hostname -s up
>> until now - it doesn''t mean the result of the
''hostname'' command
>> necessarily.
>
>
> This makes sense and is an easy compromise. Could I suggest the doco
> reflect that $hostname is `hostname -s`?
>
... or at least your definition of what a hostname is.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Just to weigh into the debate.

To give the Unix administrator choice to set the hostname to what they
determine falls into line with what Unix already provides. Generally
whether its a bad or good decision to use the returned uname() system
call variable or uname() regexed to the first dot its up to the
application.

I would argue it should be a per site decision through a configuration
parameter as to what they deem to be the hostname. Yes there certainly
are RFCs that outline best practice but an administrator may decide to
go against RFCs based on a company/individual decision (Take SMTP
servers switching on RFC filters or disabling). I think that facter
should empower the administrator to make that decision making them own
the issue.


IE some applications that adhere to this...



Linux Kernel -
# hostname myhost.dev.domain.site
# sysctl -n kernel.hostname
myhost.dev.domain.site

# hostname myhost.dev
# sysctl -n kernel.hostname
myhost.dev

# hostname myhost
# sysctl -n kernel.hostname
myhost


bash - From the bash man page
              \H     the hostname     (IE Because of no qualification,
it considers this to be the hostname not the short form of it)
              \h      the hostname up to the first `.''

A site admin is allowed the flexability to set either

PS1=\u@\H (username + value in kernel.hostname)

or

PS1=\u@\h (username + value to the first dot of kernel.hostname)



Anything that uses the uname system call will more than likely use the
struct value directly (I would suspect this to be the vast majority of
Unix applications). If application owner decides to use the short from
they would employ a regex to the first dot.


So in this vain of empowering the puppet user...

A suggestion of a configuration parameter (possibly as another fact
itself or in a configuration file) IE
hostname_shortform = true | 1    (Default value)
hostname_shortform = false | 0   (Set by the user)

This would allow the puppet user to decide what goes into facter and
ultimately their application configuration files, whether its the
short form or standard hostname let them take the credit or hang
themselves.

-Dex

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sep 29, 9:01 pm, Nigel Kersten <ni...@puppetlabs.com>
wrote:
> On Thu, Sep 29, 2011 at 5:28 PM, Doug Balmer <doug.bal...@gmail.com>
wrote:
> > ''Note that periods are only allowed when they serve to
delimit components
> >> of "domain style names".''
>
> > Let''s give this sentence some context.
>
> > <quote>
> >   ASSUMPTIONS
>
> >    1. A "name" (Net, Host, Gateway, or Domain name) is a
text string up
> >    to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
> >    sign (-), and period (.).  Note that periods are only allowed when
> >    they serve to delimit components of "domain style names".
(See
> >    RFC-921, "Domain Name System Implementation Schedule",
for
> >    background).
> > </quote>
>
> > No mention there of a hostname having to be the first component of a
> > "name". The succeeding RFC to this definition is in RFC1123
which states the
> > hostname can be up to 255 characters and begin with a number. No other
> > mention of the first component of the name being the hostname.
>
> I seem to remember having this argument in the past in a workplace...
>
> From memory the conclusion was that it is *labels* that can''t have
periods
> in them, and hostnames are allowed to be a series of labels connected with
> periods.
>
> I''m not particularly in favor of the original suggestion, but I
don''t think
> that RFC quoting alone is going to give us the right answer as to whether
we
> should do it or not.

So I was all set to jump in saying how absurd the idea of hostnames
with periods in them was, but after all little thought and poking
about I came to a conclusion similar to the one Nigel describes.  The
components of a qualified name may not contain periods, but nothing I
can find defines a machine''s "hostname" to be only the leaf
component
of (one of) its FQDN(s).  Or any part of any of its FQDNs, for that
matter.

In practice, it is not safe, at least on Linux, to assume that the
"hostname" command will return an unqualified name or that "$
(hostname).$(dnsdomainname)" is even a resolvable name for the node,
much less a FQDN for it.

On the other hand, there is a de facto standard for FQDN, and domain
name established via the ''hostname'' and
''dnsdomainname'' commands where
those are available.  Their manual on CentOS/RHEL 5 and 6 (dated
January 1996, so it''s well established practice) specifies that a
node''s FQDN is the name the resolver returns for the host name, and
that the (DNS) domain name is everything after the first dot in the
FQDN.  That dovetails with the documentation of the resolver
configuration file.  It still does not, however, require the hostname
to be the part before the first dot -- that''s merely a convention.

After some consideration, I don''t think Facter''s current
behavior of
using the first name component as the value of the "hostname" fact can
reasonably be classified as a bug (but see below).  On the contrary,
this debate highlights the fact that there are at least two distinct,
reasonable definitions for "hostname" in common use:

1) The string returned by gethostname(2)
2) The FQDN less the domain portion, where the domain portion is the
first dot and everything after

I suspect that the average sysadmin is blissfully unaware of the
distinction, or even that there can be a distinction.  Facter simply
uses the latter definition, which I suspect is more often the desired
result when the two disagree.  The best approach would probably be to
add a new fact by which the other interpretation of hostname could be
conveyed.


I do think there are some potential bugs in this area, however:

1) the Darwin R7 version of the hostname fact does not truncate the
hostname at the first dot the way the mainline version does.  Perhaps
this is not an issue in practice (i.e. maybe in that environment the
result can never contain a dot), but that''s not clear to me at the
moment

2) When Facter encounters and truncates a hostname containing a dot,
it assumes that the part after the dot was the (DNS) domain name, and
uses that in preference to its other methods for identifying the
domain name.  That relies on the ''hostname'' command never to
return a
partially-qualified name, which is not safe.

(Facter also appears to have some other questionable behavior in its
"domain" fact, but that''s going off-topic.)


John

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

You are trying to cherry pick from the assumptions. They explicitly
state that the period delimits components of "domain style names". I
know that phrase seems questionable and had me confused a little but
if you look at the RFC and the date it was created DNS was just coming
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.



On Sep 29, 8:28 pm, Doug Balmer <doug.bal...@gmail.com>
wrote:
> > ''Note that periods are only allowed when they serve to
delimit components
> > of "domain style names".''
>
> Let''s give this sentence some context.
>
> <quote>
>   ASSUMPTIONS
>
>    1. A "name" (Net, Host, Gateway, or Domain name) is a text
string up
>    to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
>    sign (-), and period (.).  Note that periods are only allowed when
>    they serve to delimit components of "domain style names". (See
>    RFC-921, "Domain Name System Implementation Schedule", for
>    background).
> </quote>
>
> No mention there of a hostname having to be the first component of a
"name".
> The succeeding RFC to this definition is in RFC1123 which states the
> hostname can be up to 255 characters and begin with a number. No other
> mention of the first component of the name being the hostname.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

So the two solutions I''m groking from this conversation are:

1) New fact that maps closer to the ''hostname'' command (for
example)
2) Configuration item that changes behaviour of the hostname fact.

Obviously we don''t support configuration specifically in facter at
this point - but ignoring that for now - what would people prefer?
What would create the least amount of surprise? Or is there more
options available ...

ken.

On Fri, Sep 30, 2011 at 12:40 AM, easybeats <dexterp@gmail.com>
wrote:
> Just to weigh into the debate.
>
> To give the Unix administrator choice to set the hostname to what they
> determine falls into line with what Unix already provides. Generally
> whether its a bad or good decision to use the returned uname() system
> call variable or uname() regexed to the first dot its up to the
> application.
>
> I would argue it should be a per site decision through a configuration
> parameter as to what they deem to be the hostname. Yes there certainly
> are RFCs that outline best practice but an administrator may decide to
> go against RFCs based on a company/individual decision (Take SMTP
> servers switching on RFC filters or disabling). I think that facter
> should empower the administrator to make that decision making them own
> the issue.
>
>
> IE some applications that adhere to this...
>
>
>
> Linux Kernel -
> # hostname myhost.dev.domain.site
> # sysctl -n kernel.hostname
> myhost.dev.domain.site
>
> # hostname myhost.dev
> # sysctl -n kernel.hostname
> myhost.dev
>
> # hostname myhost
> # sysctl -n kernel.hostname
> myhost
>
>
> bash - From the bash man page
>              \H     the hostname     (IE Because of no qualification,
> it considers this to be the hostname not the short form of it)
>              \h      the hostname up to the first `.''
>
> A site admin is allowed the flexability to set either
>
> PS1=\u@\H (username + value in kernel.hostname)
>
> or
>
> PS1=\u@\h (username + value to the first dot of kernel.hostname)
>
>
>
> Anything that uses the uname system call will more than likely use the
> struct value directly (I would suspect this to be the vast majority of
> Unix applications). If application owner decides to use the short from
> they would employ a regex to the first dot.
>
>
> So in this vain of empowering the puppet user...
>
> A suggestion of a configuration parameter (possibly as another fact
> itself or in a configuration file) IE
> hostname_shortform = true | 1    (Default value)
> hostname_shortform = false | 0   (Set by the user)
>
> This would allow the puppet user to decide what goes into facter and
> ultimately their application configuration files, whether its the
> short form or standard hostname let them take the credit or hang
> themselves.
>
> -Dex
>
> --
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

ALso, let''s not forget that "all the world is *not* linux". 
"hostname -s" doesn''t do what you think it does when
it''s not the GNU toolset.

On Sep 29, 2011, at 9:13 PM, Doug Balmer wrote:
> Our concept of ''hostname'' as a fact is equivalent to
hostname -s up
> until now - it doesn''t mean the result of the
''hostname'' command
> necessarily.
> 
> This makes sense and is an easy compromise. Could I suggest the doco
reflect that $hostname is `hostname -s`?
> 
> ... or at least your definition of what a hostname is.
> 
> -- 
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I''d prefer that the existing behavior remain the same and that a new
fact be
added for those that require it.  I''d rather not have to interrogate a
hypothetical Facter config file to determine what it means by
''hostname'' on
each given system.

On Fri, Sep 30, 2011 at 10:49 AM, Ken Barber <ken@puppetlabs.com> wrote:
> So the two solutions I''m groking from this conversation are:
>
> 1) New fact that maps closer to the ''hostname'' command
(for example)
> 2) Configuration item that changes behaviour of the hostname fact.
>
> Obviously we don''t support configuration specifically in facter at
> this point - but ignoring that for now - what would people prefer?
> What would create the least amount of surprise? Or is there more
> options available ...
>
> ken.
>
> On Fri, Sep 30, 2011 at 12:40 AM, easybeats <dexterp@gmail.com>
wrote:
> > Just to weigh into the debate.
> >
> > To give the Unix administrator choice to set the hostname to what they
> > determine falls into line with what Unix already provides. Generally
> > whether its a bad or good decision to use the returned uname() system
> > call variable or uname() regexed to the first dot its up to the
> > application.
> >
> > I would argue it should be a per site decision through a configuration
> > parameter as to what they deem to be the hostname. Yes there certainly
> > are RFCs that outline best practice but an administrator may decide to
> > go against RFCs based on a company/individual decision (Take SMTP
> > servers switching on RFC filters or disabling). I think that facter
> > should empower the administrator to make that decision making them own
> > the issue.
> >
> >
> > IE some applications that adhere to this...
> >
> >
> >
> > Linux Kernel -
> > # hostname myhost.dev.domain.site
> > # sysctl -n kernel.hostname
> > myhost.dev.domain.site
> >
> > # hostname myhost.dev
> > # sysctl -n kernel.hostname
> > myhost.dev
> >
> > # hostname myhost
> > # sysctl -n kernel.hostname
> > myhost
> >
> >
> > bash - From the bash man page
> >              \H     the hostname     (IE Because of no qualification,
> > it considers this to be the hostname not the short form of it)
> >              \h      the hostname up to the first `.''
> >
> > A site admin is allowed the flexability to set either
> >
> > PS1=\u@\H (username + value in kernel.hostname)
> >
> > or
> >
> > PS1=\u@\h (username + value to the first dot of kernel.hostname)
> >
> >
> >
> > Anything that uses the uname system call will more than likely use the
> > struct value directly (I would suspect this to be the vast majority of
> > Unix applications). If application owner decides to use the short from
> > they would employ a regex to the first dot.
> >
> >
> > So in this vain of empowering the puppet user...
> >
> > A suggestion of a configuration parameter (possibly as another fact
> > itself or in a configuration file) IE
> > hostname_shortform = true | 1    (Default value)
> > hostname_shortform = false | 0   (Set by the user)
> >
> > This would allow the puppet user to decide what goes into facter and
> > ultimately their application configuration files, whether its the
> > short form or standard hostname let them take the credit or hang
> > themselves.
> >
> > -Dex
> >
> > --
> > 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sep 30, 1:16 pm, Aaron Grewell <aaron.grew...@gmail.com>
wrote:
> I''d prefer that the existing behavior remain the same and that a
new fact be
> added for those that require it.  I''d rather not have to
interrogate a
> hypothetical Facter config file to determine what it means by
''hostname'' on
> each given system.

I completely agree.

John

> On Fri, Sep 30, 2011 at 10:49 AM, Ken Barber <k...@puppetlabs.com>
wrote:
> > So the two solutions I''m groking from this conversation are:
>
> > 1) New fact that maps closer to the ''hostname''
command (for example)
> > 2) Configuration item that changes behaviour of the hostname fact.
>
> > Obviously we don''t support configuration specifically in
facter at
> > this point - but ignoring that for now - what would people prefer?
> > What would create the least amount of surprise? Or is there more
> > options available ...
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.balmer@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.balmer@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I think you missed the point I was trying to convey. Anyway you want to try to
flip it, you are still going against the grain with using a period in the
hostname. Even libc it states what a hostname is and what a fqdn is, see below.
So if libc defines a hostname like below, then facter will be the least of your
issues down the road.

In DNS, the full host name is properly called the FQDN (Fully Qualified Domain
Name) and consists of the hostname, then a period, then the domain name. The
domain name itself usually has multiple components separated by periods. So for
example, a system''s hostname may be ‘chicken’ and its domain name might
be ‘ai.mit.edu’, so its FQDN (which is its host name) is ‘chicken.ai.mit.edu’.

http://www.gnu.org/s/hello/manual/libc/Host-Identification.html




On Oct 3, 2011, at 6:59 PM, Doug Balmer 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <mjblack@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.balmer@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Ken,

I''ve posted earlier using "easybeats". This is me
"Dex".

I''ve been reading C source code, plus RHEL documentation to shed some
more light

If you run the hostname command with an invalid character, IE...

hostname invalid\#hostname
hostname: the specified hostname is invalid

It filters out what it believes to be invalid characters and prints a
warning but sets the hostname. Looking at the source code for the
"hostname" command  (which is the entry point for setting the systems
hostname) for Debian, it filters out for alphanumeric, dash (-) and
period (.). At the top there is a comment stating it uses the rules
from RFC 1034 http://tools.ietf.org/html/rfc1034. (See snippet below)

To mean this means that at least for Linux Systems the period (.) is
allowed when setting the hostname of the box . IE entries
configuration files use the "hostname" command to set the name of the
system.

/etc/hostname - (Debian)
/etc/sysconfig/networking - (Red Hat)

Heres the clincher for me, having looked at Red Hats documentation, it
was intended "hostname" either the short form (to the first period) or
the fqdn (both of which is allowed as the hostname).

from
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/sn-Netconfig-x86.html
"Setup prompts you to supply a host name for this computer, either as
a fully-qualified domain name (FQDN) in the format hostname.domainname
or as a short host name in the format hostname.", notice the period at
the end.

So my conclusions

1. hostname on Linux was intended as either the FQDN or SHORT FORM (To
first period). Periods are allowed in Linux hostname
2. While the hostname fact does not reflect the actual hostname value
as held in the Linux kernel (which can contain periods), it does
present the correct intepretation of RFC 952.

So the "hostname" and "fqdn" facts are strict and correct
interpretations of RFC 952, however as stated in a previous post I
still maintain that facter should represent the hostname (using a
different fact) held as a Linux Kernel C struct value "sysctl -n
kernel.hostname" even if it is only part of the fqdn, The example I
used was SMTP servers enabling/disabling filtering based on strict RFC
interpretations, also the hostname command in Debian doesn''t restrict
setting of invalid hostnames but warns the user.

-Dex

-snippet from the hostname command-
/*
 * Check the format of a user-specified hostname. Uses the rules from
RFC 1035,
 * section 2.3.1.
 */
int
check_name(char *name)
{
        int i, len = strlen(name);

        /* Handle leading and trailing hyphen now. */
        if (!len || !isalnum(name[0]) || !isalnum(name[len-1]))
                return 0;

        for (i = 0; i < len; i++) {
                if (!isalnum(name[i]) && name[i] !=
''-'' && name[i] !''.'')
                        return 0;
                if (name[i] == ''-'' && (name[i - 1] ==
''.'' || name[i +
1] == ''.''))
                        return 0;
                if (name[i] == ''.'' && name[i - 1] ==
''.'')
                        return 0;
        }

        return 1;
}


-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I''ve had issues like this in a previous life (I was a founder of
Tideway Systems and we put a lot of effort into finding info from the
runtime environment and reasoning about what the returned info meant).
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. 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.

It is usually useful to separate out the data returned from
interrogation from how facter has interpreted it. Not least for
debugging and provenance purposes.

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.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> I''ve had issues like this in a previous life (I was a founder of
> Tideway Systems and we put a lot of effort into finding info from the
> runtime environment and reasoning about what the returned info meant).
> 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. 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.
So in this proposal we have ''hostname'' which is defined as the
shortname, and ''uname_nodename'' which is the data derived from
the
system. One is cross-platform, the other is specific to POSIX systems
with the uname data available.

So if we created ''uname_nodename'' this could be used
internally be the
''hostname'' fact if on a POSIX system that supports it. In OWL
ontological terms this is not a ''owl:sameAs'' but a derived
relationship of some kind (?).
> It is usually useful to separate out the data returned from
> interrogation from how facter has interpreted it. Not least for
> debugging and provenance purposes.
Indeed. At the moment all facts are equal. I hope in the future name
spacing can logically separate facts out - but I''m not sure enough
metadata can be gleaned from namespaces - something to think about.

I agree though - there is value in the separation. not only to solve
the problem users are having here - but from a reporting/debugging
perspective you can see more clearly what the system is really set to
- not just how facter interprets it.

In fact there is a similar discussion for proper reporting for the
operatingsystem fact for windows:

http://projects.puppetlabs.com/issues/7643
http://projects.puppetlabs.com/issues/7621

In #7643 we talk about exposing all the Win32_OperatingSystem WMI/CIM
class vars ... and in #7621 we would simply use those for the
operatingsystem fact on windows. Real value/contrived value layers has
its value.
> 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.
It seems to me that most people have set the hostname to be the fqdn.
And in a way (for right or wrong) this has become a
pseudo-expectation. Not just for Puppet but for other things. I have
worked with Doug and Dexter in places where they have done this - and
have found myself working around issues in other places at times.

Thanks for your informed input :-).

ken.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <dexterp@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <mjblack@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 <dexterp@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 8 October 2011 09:26, Adrien Thebo <adrien@puppetlabs.com> wrote:
> 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
>
>
Now that is something worth knowing. Can this be added to the documentation?
I can''t see reference to it in
http://docs.puppetlabs.com/guides/custom_facts.html or
http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts

Thanks

John

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

http://projects.puppetlabs.com/issues/10001

I noticed we are also missing the '':timeout'' option.

ken.

On Sun, Oct 9, 2011 at 11:06 PM, John Warburton <jwarburton@gmail.com>
wrote:
> On 8 October 2011 09:26, Adrien Thebo <adrien@puppetlabs.com> wrote:
>>
>> 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
>>
>
> Now that is something worth knowing. Can this be added to the
documentation?
> I can''t see reference to it in
> http://docs.puppetlabs.com/guides/custom_facts.html or
> http://projects.puppetlabs.com/projects/1/wiki/Adding_Facts
>
> Thanks
>
> John
>
> --
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

We have a situation here where we have multiple internal subdomains, but want to
configure Nagios to identify  hosts without our main domain.  Thus, the
''hostname'' we use for some items would be hostname.subdomain .
We also have to strrip off a certain subdomain (I wont go into the convoluted
reasons for this).

To do this (in the cases it is necessary) I simply take the fqdn and use
search/replace to replace the trailing domain name with nothing.  So, no need to
change facter as I can use fqdn.

$hostname = foo
$fqdn = foo.dept.auckland.ac.nz
$nagioshostname = regsubst( $fqdn,
''(\.itss|\.no)?\.auckland\.ac\.nz$'',
'''',''I'' )

This might be sufficuient for what the original poster was asking?

Of course, they could always define a custom fact to hold the output of uname if
they prefer.  One of the great things about the puppet/facter model is that you
can do this with very little effort.

I would definitely not want to change the current behaviour of fqdn and
hostname.

Steve

Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
s.shipway@auckland.ac.nz
Ph: +64 9 373 7599 ext 86487


-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi easybeats

On Oct 7, 4:54 pm, 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.
DNS is a general purpose naming service. However, note that its most
common use is to assign names to IP addresses, not hosts.
>
> If DNS is the only valid naming standard that can apply to thehostnameis 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 complianthostnamefrom the Kernel if it contains a
> period (.). (NB if puppet were to support this I''m suggesting a
> differentfactso 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.
this is where you need to be clear how the puppet model relates to
these standards. You cannot reconcile the differences and will get
stick if you try.
>
> > 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.
Agreed. However, there''s a trap here: the model just becomes whatever
the tools on a platform return. It''s then an exercise for the user to
work out the mapping, which is not what most of them are skilled at
and at least they will be inconsistent.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Ken
[sorry for top-posting]
I''m not a fan of supporting bad practice too strongly, it just becomes
a stick with which to beat yourself with ;-)

I think that it would be better to show folk how to get a better
model, and to point out that fqdns are not properties of hosts
(they''re properties of IP addresses). Indeed, there''s a common
antipattern of reuse of hostnames (ie the names that the boxes think
they have).  There are also some nasties where IP addresses on boxes
are different from how they appear from the outside.

I think that OWL''s not a good target technology to use. If you put
that much flexibility into the ontology that''s supported, it''s
really
hard to get useful work out of the tool (the user spends all their
time trying to work out a model, which they''re probably not skilled
at).

personally, I''d have a model for the technology and some documentation
to show how this maps to different proprietary and de jure standards.
The product should then honour this model, using whatever platform
tools are available (and flagging where the tools are inconsistent/
incomplete, rather than trying to plug the holes.)
Tim

On Oct 6, 11:50 am, Ken Barber <k...@puppetlabs.com>
wrote:
> > I''ve had issues like this in a previous life (I was a founder
of
> > Tideway Systems and we put a lot of effort into finding info from the
> > runtime environment and reasoning about what the returned info meant).
> > 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. 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.
>
> So in this proposal we have ''hostname'' which is defined
as the
> shortname, and ''uname_nodename'' which is the data derived
from the
> system. One is cross-platform, the other is specific to POSIX systems
> with the uname data available.
>
> So if we created ''uname_nodename'' this could be used
internally be the
> ''hostname''factif on a POSIX system that supports it. In
OWL
> ontological terms this is not a ''owl:sameAs'' but a
derived
> relationship of some kind (?).
>
> > It is usually useful to separate out the data returned from
> > interrogation from how facter has interpreted it. Not least for
> > debugging and provenance purposes.
>
> Indeed. At the moment all facts are equal. I hope in the future name
> spacing can logically separate facts out - but I''m not sure enough
> metadata can be gleaned from namespaces - something to think about.
>
> I agree though - there is value in the separation. not only to solve
> the problem users are having here - but from a reporting/debugging
> perspective you can see more clearly what the system is really set to
> - not just how facter interprets it.
>
> Infactthere is a similar discussion for proper reporting for the
> operatingsystemfactfor windows:
>
>
http://projects.puppetlabs.com/issues/7643http://projects.puppetlabs.com/issues/7621
>
> In #7643 we talk about exposing all the Win32_OperatingSystem WMI/CIM
> class vars ... and in #7621 we would simply use those for the
> operatingsystemfacton windows. Real value/contrived value layers has
> its value.
>
> > 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.
>
> It seems to me that most people have set thehostnameto be the fqdn.
> And in a way (for right or wrong) this has become a
> pseudo-expectation. Not just for Puppet but for other things. I have
> worked with Doug and Dexter in places where they have done this - and
> have found myself working around issues in other places at times.
>
> Thanks for your informed input :-).
>
> ken.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.