Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: INN and docker default hostnames (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 Sep 2024 10:00:45 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: INN and docker default hostnames
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 162, Issue 2
*******************************************
