On Thu, Jun 25, 2020, at 12:33 AM, Stephen J. Turnbull wrote:
Ruth Ivimey-Cook writes:
The localhost address is coming in via the hosts file, which is a relatively standard practice IMO.
OK, so I did a little research on this. You don't need to read this to continue discussion, but since other users have expressed interest in splitting hostname from listener IP address, I am posting what I've learned about aliasing hostname to localhost. This doesn't apply directly to multihomed hosts as also mentioned in this thread, and additions and corrections are, of course, welcome.
It had been my understanding that conventional wisdom is that "127.0.0.1 localhost" is *all* that you should put in /etc/hosts in most cases, so I did a couple of web searches. As far as my search-fu got me, there is no standard beyond putting localhost itself in there, which is used by a lot of boot scripts. But as a matter of common practice, the Debian family supplies an /etc/hosts that defaults to aliasing the host's FQDN to 127.0.1.1 (not 127.0.0.1), apparently as a kludge to keep GNOME happy: http://www.leonardoborda.com/blog/127-0-1-1-ubuntu-debian/
systemd-resolvd does something different; in the case that there is no interface configured *and* no /etc/hosts entry, it resolves the "local, configured hostname" to 127.0.0.2 (again, not 127.0.0.1). But if there is an interface configured, it resolves to that interface's IP. Apparently this is intended to speed up systemd-based boot processes by allowing them to run in parallel. Fedora issue tracker reports it leads to a problem similar to the one being discussed, eg, https://bugzilla.redhat.com/show_bug.cgi?id=1116538#c25
Bottom line: neither the Debian family nor the Red Hat family aliases hostname to localhost; by default it's a separate "interface". And Red Hat does it conditionally on no real interface found.
As far as I can tell, these workarounds are about placating software that breaks in one way or another if the host's own FQDN does not resolve at all when they start up, presumably because the resolver can't reach the network -- but they don't care if it's consistent with DNS as long as it connects to the local host, which leads to a fairly arbitrary practice of aliasing the hostname to localhost. All of which suggests to me that such software should be special-casing the host's various identifiers (hostname, canonical FQDN, /etc/hosts aliases, all of which it can easily discover) and translate them to "localhost", rather than asking the resolver to do it and creating an inconsistency with DNS.
Of course, getting other software to Do The Right Thing is pretty hopeless, but the solution is simple: wait for the network to come up and use the configured interface's address by looking up the canonical hostname. This works for GNOME and Postfix (mentioned in the references above), and for Mailman.
AFAICS, the exceptions are (1) running a high-availability "cloud" system that needs to scale very quickly on-demand (in which case you want to start things in parallel and need to deal with the real race conditions involved), and (2) a need to do work while disconnected. The former is over my pay grade but apparently Fedora has not managed to get it 100% reliable even with systemd. The latter case can be dealt with by putting your static IP address in /etc/hosts when you have one, which I presume
Sorry to chime in pretty late on this topic, but I didn't know about the research you did above. Thanks Steve!
I have had some of these issues in the past, but they were related to Mail routing from Postfix to the Mailman container. The problem was that docker would assign these DNS names to each container based on their names and magically update every container's /etc/hsots so they can talk to other containers through these docker given DNS names. However, the postfix running on the host won't be because docker doesn't put this DNS name anywhere else.
So, if I put 0.0.0.0 for LMTP server to bind to, it would use that address to generate Postfix's transport maps and of course it won't be able to reach Core running at an IP assigned at runtime. But the way I got around the problem was by adding regex based routing for Postfix. Exim worked because all I had to do was make the directories visible on the host.
About HTTP requests, I would say Core doesn't really need to know the external address that it is reachable at, only the interface it needs to bind to. In a containerized environment, the IP/FQDN could actually change, so if we are optimizing this for situations like containers/multi-host, it would require an Admin to update the configs.
Instead, what I was thinking was to just ignore the host, port in the self_link in Mailmanclient. The purpose of self_link is mostly to reflect the path to the resource itself in the API and I am not sure if it requires the complete URL with scheme, host and port. That should allow Web components to reach the resources without Core knowing or caring about what address it is externally reachable at.
Thoughts?
I could change it, but then perhaps other things would not work. I would prefer to be able to specify what I need.
Notwithstanding the discussion above about why it "shouldn't" break anything, I wouldn't be surprised if something breaks -- such configuration choices tend to ramify. I sympathize with you not wanting to change a configuration that works for you.
Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)