2025-05-27 nginx - master branch - PR 1 of 2 #802
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
Adds Nginx template and documentation. I do not know whether it is possible for a later PR to close an earlier PR, in the same way that a PR can mark an issue for closure. Neither do I know whether it is appropriate GitHub etiquette to even try. I will simply say that, in my view, this PR supersedes any need for SensorsIot#638 and that, providing @enriquedelpino (the creator) and @robertcsakany (who made several contributions) do not object, I recommend SensorsIot#638 be closed. The Nginx container being proposed in this PR is a self-contained all-in-one solution. It is a single template and does not touch any other service definitions. That compares/contrasts with SensorsIot#638 which was spread across three service definitions, touched 15 existing service definitions and, I infer, would have implied similar changes to the service definitions of any "proxyable" (if that's a word) containers added subsequently. I have been testing the `jc21/nginx-proxy-manager` for the past couple of months. I won't claim to have given it a full workout because my testing has been limited to self-signed SSL certificates (ie no Let's Encrypt) and I have only defined "proxy hosts" (ie no "redirection hosts", "streams" or "404 hosts", and no "access lists"). The proxy hosts that I have defined include a judicious mix of HTTP and HTTPS services, running on the same and different hosts, and running in both host mode and non-host mode. I have also tested in conjunction with CNAME records defined by both PiHole and BIND9. The Nginx service as implemented by the `jc21` Docker image works and is reliable. The only problems I have found are: 1. A situation where obsolete private SSL certificates are not removed from the database when they are deleted. This was filed as [Issue 4442](NginxProxyManager/nginx-proxy-manager#4442). 2. The procedure for the "forgot password" use case is not exactly well documented. For example it's buried in places like [Issue 230](NginxProxyManager/nginx-proxy-manager#230). It's also a little bit coarse in that it kills **all** user records. Granted, in most IOTstack environments there will only be one user anyway but it's still poor practice in an SQL sense and I'd rather not perpetuate it. The documentation included with this PR adopts the approach of resetting the password of the problematic account to a known value. Signed-off-by: Phill Kelley <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Adds Nginx template and documentation.
I do not know whether it is possible for a later PR to close an earlier PR, in the same way that a PR can mark an issue for closure. Neither do I know whether it is appropriate GitHub etiquette to even try. I will simply say that, in my view, this PR supersedes any need for #638 and that, providing @enriquedelpino (the creator) and @robertcsakany (who made several contributions) do not object, I recommend #638 be closed.
The Nginx container being proposed in this PR is a self-contained all-in-one solution. It is a single template and does not touch any other service definitions. That compares/contrasts with #638 which was spread across three service definitions, touched 15 existing service definitions and, I infer, would have implied similar changes to the service definitions of any "proxyable" (if that's a word) containers added subsequently.
I have been testing the
jc21/nginx-proxy-managerfor the past couple of months. I won't claim to have given it a full workout because my testing has been limited to self-signed SSL certificates (ie no Let's Encrypt) and I have only defined "proxy hosts" (ie no "redirection hosts", "streams" or "404 hosts", and no "access lists").The proxy hosts that I have defined include a judicious mix of HTTP and HTTPS services, running on the same and different hosts, and running in both host mode and non-host mode. I have also tested in conjunction with CNAME records defined by both PiHole and BIND9.
The Nginx service as implemented by the
jc21Docker image works and is reliable. The only problems I have found are:A situation where obsolete private SSL certificates are not removed from the database when they are deleted. This was filed as Issue 4442.
The procedure for the "forgot password" use case is not exactly well documented. For example it's buried in places like Issue 230. It's also a little bit coarse in that it kills all user records. Granted, in most IOTstack environments there will only be one user anyway but it's still poor practice in an SQL sense and I'd rather not perpetuate it. The documentation included with this PR adopts the approach of resetting the password of the problematic account to a known value.