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
(Dominik 'Rathann' Mierzejewski)
3. Re: INN and docker default hostnames (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Fri, 20 Sep 2024 12:12:05 +0200
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: INN and docker default hostnames
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"; format=flowed
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?
We already read some environment variables like INNCONF (alternate path
to inn.conf), NNTPSERVER, INND_BIND_ADDRESS, INND_BIND_ADDRESS6,
FROMHOST, ORGANIZATION, and UU_MACHINE.
Why not have the following behaviour for the hostname:
- the INN_HOSTNAME environment variable if fully qualified;
- 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.
> 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.
--
Julien ?LIE
??If your dog is barking at the back door and your wife yelling at the
frontdoor, who do you let in first? The dog of course? at least
he'll shut up after you let him in!??
------------------------------
Message: 2
Date: Fri, 20 Sep 2024 12:23:39 +0200
From: Dominik 'Rathann' Mierzejewski <[email protected]>
To: [email protected]
Subject: Re: INN and docker default hostnames
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Friday, 20 September 2024 at 12:12, Julien ?LIE wrote:
[...]
> I suggest to also recognize an INN_HOSTNAME environment variable, if set.
> Wouldn't it solve the problems when using Docker or like?
>
> We already read some environment variables like INNCONF (alternate path to
> inn.conf), NNTPSERVER, INND_BIND_ADDRESS, INND_BIND_ADDRESS6, FROMHOST,
> ORGANIZATION, and UU_MACHINE.
>
> Why not have the following behaviour for the hostname:
> - the INN_HOSTNAME environment variable if fully qualified;
> - 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.
Perhaps INND_HOSTNAME would be better for consistency with the existing
INND_* variables?
Regards,
Dominik
--
Fedora https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The Sayings of Muad'Dib" by the Princess Irulan
------------------------------
Message: 3
Date: Fri, 20 Sep 2024 12:51:11 +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 Dominik,
>> I suggest to also recognize an INN_HOSTNAME environment variable, if set.
>> Wouldn't it solve the problems when using Docker or like?
>>
>> We already read some environment variables like INNCONF (alternate path to
>> inn.conf), NNTPSERVER, INND_BIND_ADDRESS, INND_BIND_ADDRESS6, FROMHOST,
>> ORGANIZATION, and UU_MACHINE.
>
> Perhaps INND_HOSTNAME would be better for consistency with the existing
> INND_* variables?
I suggested INN_HOSTNAME because the variable applies to innd, innfeed,
nnrpd...
The existing INND_BIND_* variables only apply to innd.
--
Julien ?LIE
??Vita breuis, ars longa, occasio praeceps, experimentum pericolosum,
iudicium difficile.?? (Hippocrate)
------------------------------
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 1
*******************************************
