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 (Julien ?LIE)
2. Re: INN and docker default hostnames (Julien ?LIE)
3. Re: INN and docker default hostnames (Richard Kettlewell)
----------------------------------------------------------------------
Message: 1
Date: Sun, 22 Sep 2024 09:22:31 +0200
From: Julien ?LIE <[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
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?
> 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.
> In short I think the concerns about relaxing INN's check are not really
> well-founded.
We could also keep the check, writing the warning in the logs but not
making it fatal. Instead of a warning, it could be a (non-fatal) error
so that the news admin sees it (the log file is sometimes separate).
--
Julien ?LIE
??Vita breuis, ars longa, occasio praeceps, experimentum pericolosum,
iudicium difficile.?? (Hippocrate)
------------------------------
Message: 2
Date: Sun, 22 Sep 2024 09:49:04 +0200
From: Julien ?LIE <[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
In addition:
> We could also keep the check, writing the warning in the logs but not
> making it fatal.? Instead of a warning, it could be a (non-fatal) error
> so that the news admin sees it (the log file is sometimes separate).
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.)
--
Julien ?LIE
??Ne crains pas d'avancer lentement, crains seulement de t'arr?ter.??
(proverbe chinois)
------------------------------
Message: 3
Date: Sun, 22 Sep 2024 09:38:44 +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 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
------------------------------
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 3
*******************************************
