INN and docker default hostnames

[Grant Taylor]

On 4/4/20 11:30 AM, Richard Kettlewell wrote:
> OK, how should the postinst find pathdb, ovmethod, etc, then, in your 
> opinion?

The script can and probably should continue to use innconfval.  It just 
should not fail when receiving a non-zero return code.

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

I don't know.  I'd say a good start is to print an error but allow the 
install to continue ~> complete.

> 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.

Note hostname ≠ FQDN.

I don't think it even matters if the FQDN is private and internal to the 
organization.  As long as there is a dot in the name, thus qualifying 
it, the installer would probably be happy.

> 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...

I suspect that we have a different value of "work fine".

Yes, they call can be made to work with unqualified names.  But that is, 
and has been, so far from the default that most people see, that it's no 
longer a viable thing.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20200406/fdb42421/attachment.bin>