You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are experimenting with running xrootd in a docker container, and have found that xrootd dislikes hostnames that begin with numerical digits. Inside the docker container, the hostname is configured as a (seemingly random) hexadecimal sequence, which began with the digit '3' in our instance. This triggered an error on xrootd startup: XrdConfig: unable to determine host name.
Going deeper, in src/Xrd/XrdConfig.cc:372, we see a call to new XrdNetAddr((int)0). The constructor for XrdNetAddr calls gethostname, then XrdNetAddr::Set, where the problem is triggered. On src/XrdNet/XrdNetAddr.cc:227, we see else if (*hSpec >= '0' && *hSpec <= '9'), which is used to detect whether the hostname is in a colon-hex or dotted decimal format. If true, inet_pton is called, passing the input address hSpec. inet_pton assumes that its input is in one of the two formats, or it returns 0. In this case, hSpec is filled by gethostname, which returns the generated hexadecimal hostname.
The correct behavior is probably to use a more sophisticated means of detecting the format of hSpec, so such hostnames can be passed to the last else branch.
The text was updated successfully, but these errors were encountered:
XRootD follows RFC 952 for host name conventions. RFC 952 specifically states
" 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). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. "
Hence, the host name you provided is invalid if it starts with a non-alpha character. The full RFC can be found here: http://tools.ietf.org/html/rfc952
Digits have been allowed as starting characters since 1989. Are you saying that xrootd rejects the relaxed restrictions indicated in RFC-1123? Please see section 2.1:
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.
We are experimenting with running xrootd in a docker container, and have found that xrootd dislikes hostnames that begin with numerical digits. Inside the docker container, the hostname is configured as a (seemingly random) hexadecimal sequence, which began with the digit '3' in our instance. This triggered an error on xrootd startup:
XrdConfig: unable to determine host name
.Going deeper, in src/Xrd/XrdConfig.cc:372, we see a call to
new XrdNetAddr((int)0)
. The constructor for XrdNetAddr callsgethostname
, thenXrdNetAddr::Set
, where the problem is triggered. Onsrc/XrdNet/XrdNetAddr.cc:227
, we seeelse if (*hSpec >= '0' && *hSpec <= '9')
, which is used to detect whether the hostname is in a colon-hex or dotted decimal format. If true,inet_pton
is called, passing the input address hSpec.inet_pton
assumes that its input is in one of the two formats, or it returns 0. In this case, hSpec is filled by gethostname, which returns the generated hexadecimal hostname.The correct behavior is probably to use a more sophisticated means of detecting the format of hSpec, so such hostnames can be passed to the last
else
branch.The text was updated successfully, but these errors were encountered: