FEATURE: Move letsencrypt scripts to work on boot #977
Conversation
171ce88 to
c111b26
Compare
|
One complication to note, is moving the configuration out to boot like this breaks some assumptions (that the ssl configuration is available at build time) for the socketed template. Perhaps it would be better to have these available as new templates? Alternatively, it might be sufficient as-is as |
|
Also, if you boot the image and it doesn't have dns pointed at it, you're
likely to get rate limited by let's encrypt.
Jay Pfaffman ***@***.***>
http://www.literatecomputing.com/
…On Wed, Jul 16, 2025, 7:06 PM Jeff Wong ***@***.***> wrote:
*featheredtoast* left a comment (discourse/discourse_docker#977)
<#977 (comment)>
One complication to note, is moving the configuration out to boot like
this breaks some assumptions (that the ssl configuration is available at
build time) for the socketed template.
Perhaps it would be better to have these available as new templates?
—
Reply to this email directly, view it on GitHub
<#977 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAWZ4ZGLC25TZMRZIS7DFH33IZ2CHAVCNFSM6AAAAACBUDJS4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZZGI4TEOJWGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
@pfaffman that same concern exists in the current templates already - the current templates also have to grab templates on boot already. I'm not changing how the ssl cert is attained, just making it so things also can get configured at boot. |
|
Agreed. The current way you get rate limited building a container. The proposed way you get rate limited running a container. They are both bad. Maybe the new way is better? |
|
No, what I mean is both the old and proposed way here request the cert on container boot here: This proposal doesn't change anything about when that's done. |
Allows ssl and letsencrypt templates to run on boot via initscripts This change adds the decision to configure https or letsencrypt to be at runtime rather than at build time via env vars. Under the hood, these are the commands, just migrated to shellscripts that run when a container boots. Runs on existence of ENABLE_SSL (base ssl template) or LETSENCRYPT_ACCOUNT_EMAIL (ssl template+letsencrypt template) Both cases checks and errors on blank hostname.
c111b26 to
35f932f
Compare
templates/web.ssl.template.yml
Outdated
| contents: | | ||
| EOF | ||
|
|
||
| > /etc/nginx/conf.d/outlets/server/10-http.conf |
There was a problem hiding this comment.
This redirection is non-idiomatic. Use touch or install /dev/null.
There was a problem hiding this comment.
The purpose of this line is to empty the file. I've updated to use install /dev/null - thanks for the pointer!
There was a problem hiding this comment.
Oooh, that was a possibility I had not considered. echo > $FILE is the normal way to do that, sorry. (Possibly with a comment to explain that it already exists and we want to wipe out the contents.)
split up if statements. Add spaces around heredoc. use install /dev/null rather than empty redirect to clear a file.
|
This pull request has been mentioned on Discourse Meta. There might be relevant details there: https://meta.discourse.org/t/connection-refused-on-self-hosted-instance-after-rebuild/376224/2 |
|
This pull request has been mentioned on Discourse Meta. There might be relevant details there: |
Allows ssl and letsencrypt templates to run on boot via initscripts
This change adds the decision to configure https or letsencrypt to be at runtime
rather than at build time via env vars.
Under the hood, these are the commands, just migrated to shellscripts
that run when a container boots.
Runs on existence of ENABLE_SSL (base ssl template)
or LETSENCRYPT_ACCOUNT_EMAIL (ssl template+letsencrypt template)
Both cases checks and errors on blank hostname.