INN and docker default hostnames

[Richard Kettlewell]

On 04/04/2020 18:07, Grant Taylor wrote:
> I seriously question if the failure is in INN itself or the Debian 
> package manager.
> 
> I bet that innconfval is working exactly like it should and that 
> something is not liking what innconfval is returning.
I see nothing in the man page for innconfval that says it critiques 
aspects of the local environment even when asked for unrelated 
configuration parameters, so I suspect you would lose your bet, unless 
of course you are aware of some other specification for the program.

> I'm not convinced that this is a bug in INN.  In fact, I think this is a 
> bug in the installer / script that it's using.

OK, how should the postinst find pathdb, ovmethod, etc, then, in your 
opinion?

> I suspect it's something outside of INN that's not liking what it's seeing.

Suspect? There is no mystery about the causes of the behavior observed. 
The question is what should be done about it.

>> My suggestion is that INN should believe getaddrinfo(), i.e. remove 
>> the strchr() check for '.'.
> 
> Names without a period in them are unqualified (in the DNS world).
> 
> INN "SHOULD" (in the RFC sense of the word) have a FQDN to work with. 
> Much like email servers SHOULD have an FQDN.

Why?

What it actually needs is a valid hostname for the environment it's 
running in. And it's got one, it just doesn't like it.

INN is the odd one out here: so far my personal experience is that mail 
servers, web servers, database servers and middleware for specialized 
hardware all work fine...

ttfn/rjk