INN and docker default hostnames

[Richard Kettlewell]

On 22/09/2024 08:22, Julien ÉLIE wrote:
> Hi Richard,
> 
>> 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.
> 
> How can INN determine that its installation is not finished?

It can't, and it shouldn't pretend that it can.

>> 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.
> 
> Under the use case of installation only, one possibility is Docker but 
> there are others.  We cannot be sure that there is a random generated 
> hostname.  It may be a hard-coded "buildkitsandbox" hostname without any 
> randomness, or any other string.
We can't be sure the hostname is unique just because it has a dot in it, 
either. buildkitsanbox.local would pass the check.

If the goal is uniqueness (the comments don't say) then it's using in 
inaccurate proxy for it, and (as we've seen here) the inaccuracy does 
actually affect some of us.

 > Alternately, the check could be removed from the current function
 > (innconf_validate), and a new innconf_validate_hostname function
 > added which only runs that check but called from programs needing it
 > (innxmit, gencancel, inews, rnews, innd, innfeed, nnrpd) and not by
 > almost all the programs as currently (like makedbz, makehistory,
 > innconfval, ctlinnd, inndf for which I totally agree it does not
 > make any sense).  Would it solve the problem?  (I think so.)

I expect innd's refusal to start would cause the Debian package setup to 
fail.

ttfn/rjk