Fix nginx startup failure on IPv4-only hosts#268
Open
upmcplanetracker wants to merge 3 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
addresses issue #267
The container currently fails to start on systems with IPv6 disabled because nginx currently tries to load up as dual-stack only so hard-crashes when it can't bind to [::]:80. This makes the Vert web page unreachable for anyone running IPv4-only.
what I changed -
I replaced the static
nginx/default.confwith a template (nginx/default.conf.template) that uses a placeholder for the IPv6 listen directiveI added a startup script that checks for IPv6 kernel support before nginx starts
If IPv6 is available, the script adds listen [::]:80; to the config, making the page dual stack
If IPv6 is unavailable, the placeholder is removed and nginx starts cleanly on IPv4 only
The script then hands off to the original nginx entrypoint so all other container behavior stays the same
I didn't touch -
nginx/default-ssl.confthis is still IPv4-only. If the project needs dual-stack SSL in the future, the same approach can be applied there (add listen [::]:80; to the HTTP redirect block and listen [::]:443 ssl; to the HTTPS block, with matching placeholder logic in the startup script). I'll leave that to the maintainer's discretion depending on how SSL is deployed.