Hostname fact doesn't handle hostnames with periods

[Doug Balmer]

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?

[Sans]

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

[Brian Gallew]

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

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Christopher Wood]

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

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...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@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

[Doug Balmer]

'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.

[Nigel Kersten]

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.

 

[Doug Balmer]

 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.

[Scott Smith]

Except that is the fqdn.

[Ken Barber]

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.

[Doug Balmer]

Except that is the fqdn.

No.  "foo.bar" could be the hostname but foo.bar.example.com could be the FQDN.

[Doug Balmer]

"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`?

[Doug Balmer]

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.

[jcbollinger]

On Sep 29, 9:01 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:

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

[Matt]

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.

[easybeats]

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

[Ken Barber]

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.

[Brian Gallew]

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.

[Aaron Grewell]

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. 

[jcbollinger]

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

[Doug Balmer]

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".

[Ken Barber]

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.

[Matthew Black]

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.

[Matthew Black]

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

[Ken Barber]

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.

[easybeats]

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;
}

[Tim Coote]

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.

[Ken Barber]

> 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.

[easybeats]

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.

[Matthew Black]

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.

[Adrien Thebo]

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

[John Warburton]

On 8 October 2011 09:26, Adrien Thebo <adr...@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 

[Ken Barber]

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

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

ken.

[Steve Shipway]

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.sh...@auckland.ac.nz
Ph: +64 9 373 7599 ext 86487

[Tim Coote]

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.

[Tim Coote]

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.