INN and docker default hostnames

[Richard Kettlewell]

On 20/09/2024 11:12, Julien ÉLIE wrote:
> Hi all,
> 
> Following a discussion we had here in April 2020.  We regularly have 
> questions about Docker installations where hostnames are not fully 
> qualified.  Let's see if we cannot improve that.
> 
> Currently, INN takes for the hostname in the following order:
> - the result of gethostname(3) if fully qualified;
> - the result of getaddrinfo(3) if fully qualified;
> - the concatenation of "hostname.domain" where hostname is the result of 
> gethostname(3) and domain the value of the eponym parameter in inn.conf.
> 
> I suggest to also recognize an INN_HOSTNAME environment variable, if 
> set.  Wouldn't it solve the problems when using Docker or like?

I think so, yes.

>> INN refuses to run with a single component hostname because the chances
>> are low that it's globally unique, and historically INN considers it
>> unsafe to run without an FQDN to put in the Path.  This is an old, old
>> check, predating containers and Docker and all of that world.
>>
>> I do think it's at least mildly dubious to run INN without an FQDN to put
>> into the Path header.  I'm a little dubious about relaxing this
>> check in general, since putting unqualified hostnames in the Path header
>> and using them for loop checking sounds likely to cause weird problems.
> 
> I also agree not to relax the check because of potential unexpected 
> issues in generated Path and Message-ID header fields.

I feel like there's some misapprehensions here.

Firstly the use case is not 'running INN without an FQDN'. The use case 
is installation only. The random hostnames only exist during 
installation; by the time the news server is exchanging articles, INN 
has a normal pathhost.

Secondly the chance that the Docker random hostnames are globally unique 
is very very high. They are random 96-bit strings and only exist for a 
short time. Even if we imagine an operator neglecting to set a real 
pathhost for some reason, there would have to be billions of servers 
affected before there any more than a negligible probability of a 
collision. It's just not a realistic outcome.

In short I think the concerns about relaxing INN's check are not really 
well-founded.

ttfn/rjk