I did not agree or disagree with any solution. I disagreed with your statement that the issue is very obscure.
Both my solutions work for me. My first solution was based on DIRECT information from Nginx.
I assume your solution has been tested and works. Good. You are a great asset to Virtualmin and the community.
I doubt anyone reading the forum has the time and resources to go fully in depth. I gave up following this thread.
I don’t know on what basis you state sample configs provided by Nginx does not work. If it works on a physical server with static IP and with simple standard routers then you cannot say it does not work. Do you really expect Nginx should be providing configs for every bizarre multi layer non standardised virtualisation set up and non standardised complex routing setups by cloud providers? Cloud providers do their best. I have even seen the issue with dedicated servers. Scary.
Very presumptious. It made no difference to the security whether the two lines that worked for me are included or not on the servers that were affected (not on my production servers). If I tried a static config of the IPv4 address with the IPv4 address to be offered then IPv4 does not work. It had to be offered and accepted. It is trivial to check if the server is operating with the correct IPv4 address.
Also any stock Virtualmin requires IPv4 and/or IPv6 to be working before it is installed and in fact Virtualmin should passivey detect and follow the config system. In fact it does not always do so. I could bombard you with bugs on this. Instead I just work around them.
The link is to a to a sample systemd .service file for Debian in SOURCE CODE. For anyone involved in code distribution or fixing problems, Debian or not, that is pure gold, is documentation, is better than ordinary documentation and is what I would look for after seeing some reference in ordinary documentation.
Maybe a request should be made to Nginx to provide a reference in ordinary documentation and expand on it, if not already there.
With regard to nonlocal_bind Linux kernel options, I did not post an example of their use to a Virtualmin forum before.
I can’t remember. I originally noted it as a possible solution following a comment that it was a solution arising from issues to the way AWS assigns IP addresses.
AWS is not unique in this behaviour (cannot assign IPv4 statically in affected servers) and it worked for me.
I have not done further follow up work. They are Linux kernel config options and I don’t want to examine Linux kernel source code. No general comments/interpretations on the web on what it does can be trusted.
I am not asserting both solutions I have proposed are used together. Either solution on its own is fine.
The point of the systemd solution is to delay starting nginx until networking is ‘up’. In hindsight it looks like an obvious solution. According to systemd documentation, it lets network management decide what ‘up’ means when network-online.target is used. So whether it works could be hit or miss.
I assume the point of the kernel configuration solution is to do something similiar at the ioctl level. Such as delay a network address initialisation by a user land application until it is confirmed the relevant network address is up (on the assumption an IP address may be obtained non locally). Again it seems obvious. It might be less hit and miss. However I understand it won’t work unless an up to date network stack is used by the application.