Bug 773099

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

What's the real issue here? The hostname can be set to myhost.mydomain without a problem.

(In reply to Jan Synacek from comment #5)
> What's the real issue here? The hostname can be set to myhost.mydomain
> without a problem.

The real problem here is that a domain name with a trailing dot is a legal and valid and _unambiguous_ domain name per RFC 1034 section 3.1:

  Since a complete
  domain name ends with the root label, this leads to a printed form which
  ends in a dot.  We use this property to distinguish between:

     - a character string which represents a complete domain name
       (often called "absolute").  For example, "poneria.ISI.EDU."

     - a character string that represents the starting labels of a
       domain name which is incomplete, and should be completed by
       local software using knowledge of the local domain (often
       called "relative").  For example, "poneria" used in the
       ISI.EDU domain.

To fail when an unambiguous, complete and legal domain name is specified such as is happening in the case of this ticket, is a bug.

What is the real-world problem with this?  I wish you'd have asked me that almost 4 years ago when I originally opened this ticket.

But given that this is a bug and somebody has hit it in the real world and that the fix is absolutely trivial, what is the resistance to fixing it?  Here's the patch:

--- /mnt/centos6.5/usr/share/system-config-network/netconfpkg/NC_functions.py	2010-11-11 15:19:49.000000000 -0500
+++ /tmp/foo	2015-11-27 07:38:52.997684620 -0500
@@ -245,8 +245,8 @@
 
 # we want to compile the regexp just once (not as fast as I expect)
 ip_pattern = re.compile('^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$')
-hostname_pattern = re.compile('^([a-zA-Z]|[0-9]|_)(([a-zA-Z]|[0-9]|-|_)*([a-zA-Z]|[0-9]|_))?(\.([a-zA-Z]|[0-9]|_)(([a-zA-Z]|[0-9]|-|_)*([a-zA-Z]|[0-9]))?)*$')
-length_pattern = re.compile('^[a-zA-Z0-9-_]{1,64}(\.([a-zA-Z0-9-_]{1,64}))*$')
+hostname_pattern = re.compile('^([a-zA-Z]|[0-9]|_)(([a-zA-Z]|[0-9]|-|_)*([a-zA-Z]|[0-9]|_))?(\.([a-zA-Z]|[0-9]|_)(([a-zA-Z]|[0-9]|-|_)*([a-zA-Z]|[0-9]))?)*\.?$')
+length_pattern = re.compile('^[a-zA-Z0-9-_]{1,64}(\.([a-zA-Z0-9-_]{1,64}))*\.?$')
 def testHostname(hostname):
     # hostname: names separated by '.' every name must be max 63 
     # chars in length and the hostname max length is 255 chars

And the proofs:

$ python
Python 2.7.10 (default, Sep 24 2015, 17:50:09) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> hostname_pattern = re.compile('^([a-zA-Z]|[0-9]|_)(([a-zA-Z]|[0-9]|-|_)*([a-zA-Z]|[0-9]|_))?(\.([a-zA-Z]|[0-9]|_)(([a-zA-Z]|[0-9]|-|_)*([a-zA-Z]|[0-9]))?)*\.?$')
>>> length_pattern = re.compile('^[a-zA-Z0-9-_]{1,64}(\.([a-zA-Z0-9-_]{1,64}))*\.?$')
>>> length_pattern.match("www.redhat.com")
<_sre.SRE_Match object at 0x7f66f0197938>
>>> length_pattern.match("www.redhat.com.")
<_sre.SRE_Match object at 0x7f66f01979c0>
>>> hostname_pattern.match("www.redhat.com")
<_sre.SRE_Match object at 0x7f66f8dcdeb8>
>>> hostname_pattern.match("www.redhat.com.")
<_sre.SRE_Match object at 0x7f66f8caf410>

Given that it is actually a bug and that I have provided the patch to fix it, I am going to unset the NOTABUG label and reopen this.

I misread the bug description, hence the confusion.

In the current release (system-config-network-1.6.0.el6.3), hostname_pattern already contains the trailing dot, but length_pattern doesn't.

Ok, regexp is ok now, but we are not using this function anywhere in tui so it is just dead code.

Filled another bug (BZ#1308891 so we actually use this function in tui).

Marking this as verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0792.html