Closed airjer closed 1 year ago
If you hadn't deleted the part of the template asking for your debug output, I might be able to check :p
I am not able to reproduce this, the default Caddy config aggressively redirects all HTTP requests to HTTPS with a 308:
* Connected to *** (***) port 80 (#0)
> GET /c/memes@lemmy.ml HTTP/1.1
> Host: ***
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://***/c/memes@lemmy.ml
< Server: Caddy
< Date: Tue, 11 Jul 2023 15:33:42 GMT
< Content-Length: 0
* Closing connection 0
* Clear auth, redirects to port from 80 to 443
* Issue another request to this URL: 'https://***/c/memes@lemmy.ml'
* Trying ***:443...
* Connected to *** (***) port 443 (#1)
Detected runtime: docker (Docker version 24.0.4, build 3713ee1)
Detected compose: docker compose (Docker Compose version v2.19.1)
Runtime state: OK
==== System Information ====
OS: Linux
KERNEL: 5.4.0-153-generic (x86_64)
HOSTNAME: OK
SHELL: bash
MEMORY:
total used free shared buff/cache available
Mem: 7.7Gi 503Mi 259Mi 88Mi 7.0Gi 6.9Gi
Swap: 979Mi 1.0Mi 978Mi
DISTRO:
----------------------------
NAME="Ubuntu"
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
----------------------------
==== Lemmy-Easy-Deploy Information ====
Version: 1.2.7
IMAGE CREATED STATUS
lemmy-easy-deploy-proxy 45 minutes ago Up 45 minutes
ghcr.io/ubergeek77/lemmy-ui:0.18.2 45 minutes ago Up 45 minutes
ghcr.io/ubergeek77/lemmy:0.18.1 45 minutes ago Up 45 minutes
postgres:15-alpine 45 minutes ago Up 45 minutes
asonix/pictrs:0.4.0-beta.19 45 minutes ago Up 45 minutes
Integrity:
0dcb79d994394bd204f7034ce2bd58838d9d1187262463c95d3abb70a1d6d421 ./deploy.sh
1e9b0c0988998dcc33cb0fbfdb0e1679229424e724f898b797380adc7d102446 ./templates/Caddy-Dockerfile.template
c1202e70662dd2228da36a35a0f38ec8fc81bec8964d7315d02e8671a58dd7d7 ./templates/Caddyfile.template
2537678c7971df36c1ed95f4228d3cfcb15bb4a28a60d939eaf8dd75b5d64a36 ./templates/cloudflare.snip
c9cb4c5fee12930e17798a02ae1bd12e2dc69e149a394c24511bc9d4e6b776d4 ./templates/compose-email.snip
c494a610bcb4cd1cfc0a4fe4fb0f6d437b2a84a0ad1625daee240e6dd6f1c910 ./templates/compose-email-volumes.snip
d9928baea61975bd432e1a4a7439c04468547c9b42e2bb483c6f18d9438665eb ./templates/docker-compose.yml.template
1c202b1b6e87c65b2fcda6035c9fe3f8631d76662907ffd38f24b14686e30647 ./templates/lemmy-email.snip
c834cdce9eaf77f38155b404724fdfe66845575386ee516987452aa715642a6f ./templates/lemmy.hjson.template
Custom Files:
*** No custom files ***
==== Settings ====
CLOUDFLARE: Yes
CADDY_DISABLE_TLS: false
CADDY_HTTP_PORT: 80
CADDY_HTTPS_PORT: 443
LEMMY_TLS_ENABLED: true
ENABLE_EMAIL: true
SMTP_PORT: 587
ENABLE_POSTFIX: no
POSTGRES_POOL_SIZE: 5
==== Generated Files ====
Deploy Version: 0.18.1;0.18.2
total 36K
drwxr-xr-x 2 0 0 4.0K Jul 10 23:46 caddy
-rw-r--r-- 1 0 0 79 Jul 11 07:55 caddy.env
-rw-r--r-- 1 0 0 1.7K Jul 11 07:55 docker-compose.yml
-rw-r--r-- 1 0 0 50 Jul 8 02:47 lemmy.env
-rw-r--r-- 1 0 0 689 Jul 11 07:55 lemmy.hjson
-rw-r--r-- 1 0 0 49 Jul 8 02:47 pictrs.env
-rw-r--r-- 1 0 0 29 Jul 11 07:55 postfix.env
-rw-r--r-- 1 0 0 51 Jul 8 02:47 postgres.env
-rw-r--r-- 1 0 0 14 Jul 11 07:56 version
I've noticed in ./live/Caddy/Caddyfile all the urls are prefixed with http://
I've noticed in ./live/Caddy/Caddyfile all the urls are prefixed with http://
It sounds like you may have:
deploy.sh
with CADDY_DISABLE_TLS
set to true
CADDY_DISABLE_TLS
to false
But then didn't redeploy? Changes to the config can only be applied on redeploys.
If you run ./deploy.sh -f
, the script will redeploy this and remove the http://
prefix, now that you have reverted the setting of CADDY_DISABLE_TLS
.
I initially had LEMMY_TLS_ENABLED="false" and set that to true and redeployed. I haven't messed with the CADDY_DISABLE_TLS
root@COV0177:~/Lemmy-Easy-Deploy# curl -H 'Accept: application/activity+json' 'https://lemmyf.uk/post/4103'
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
{
"lemmy": "https://join-lemmy.org/ns#",
"litepub": "http://litepub.social/ns#",
"pt": "https://joinpeertube.org/ns#",
"sc": "http://schema.org/",
"ChatMessage": "litepub:ChatMessage",
"commentsEnabled": "pt:commentsEnabled",
"sensitive": "as:sensitive",
"matrixUserId": "lemmy:matrixUserId",
"postingRestrictedToMods": "lemmy:postingRestrictedToMods",
"removeData": "lemmy:removeData",
"stickied": "lemmy:stickied",
"moderators": {
"@type": "@id",
"@id": "lemmy:moderators"
},
"expires": "as:endTime",
"distinguished": "lemmy:distinguished",
"language": "sc:inLanguage",
"identifier": "sc:identifier"
}
],
"type": "Page",
"id": "https://lemmyf.uk/post/4103",
"attributedTo": "http://lemmyf.uk/u/willya",
"to": [
"http://lemmyf.uk/c/announcements",
"https://www.w3.org/ns/activitystreams#Public"
],
"name": "Testing",
"cc": [],
"content": "<p>1 2 3</p>\n",
"mediaType": "text/html",
"source": {
"content": "1 2 3",
"mediaType": "text/markdown"
},
"attachment": [],
"commentsEnabled": true,
"sensitive": false,
"published": "2023-07-11T06:09:12.270911+00:00",
"language": {
"identifier": "en",
"name": "English"
},
"audience": "http://lemmyf.uk/c/announcements"
}root@COV0177:~/Lemmy-Easy-Deploy#
I edited the Caddyfile.template and it seems to have updated the live one, for whatever reason though url's are still coming back with http:// formatted ones on this command.
It's not possible for you to have an http://
prefix in the Caddyfile unless you set that variable to true or 1:
Can you try redeploying?
Also,
I edited the Caddyfile.template and it seems to have updated the live one, for whatever reason though url's are still coming back with http:// formatted ones on this command.
Please do not edit the Caddyfile.template directly. If you need custom modifications, you can use Advanced Configuration, although I cannot provide help for issues related to this.
I initially had LEMMY_TLS_ENABLED="false" and set that to true and redeployed. I haven't messed with the CADDY_DISABLE_TLS
That will make the links returned in activities http
as you are experiencing. On my instance, they return https
as expected.
For both issues, I think you may not actually be redeploying even if you think you are. In your debug output, I can see your containers have been up for 45 minutes at the time of the post. When you redeploy, they should be re-created.
root@COV0177:~/Lemmy-Easy-Deploy# ./deploy.sh -f
WARNING: Force deploying; this will regenerate configs and deploy again even if there were no updates
Passwords will NOT be re-generated
========================================
Lemmy-Easy-Deploy by ubergeek77 (v1.2.7)
========================================
Detected runtime: docker (Docker version 24.0.4, build 3713ee1)
Detected compose: docker compose (Docker Compose version v2.19.1)
Runtime state: OK
Current Backend Version: 0.18.1
Latest Backend Version: 0.18.1
Current Frontend Version: 0.18.2
Latest Frontend Version: 0.18.2
Re-deploy these versions? [Y/n] y
Finding the best available Backend image, please wait...
--> Using Backend Image: ghcr.io/ubergeek77/lemmy:0.18.1
Finding the best available Frontend image, please wait...
--> Using Frontend Image: ghcr.io/ubergeek77/lemmy-ui:0.18.2
[+] Pulling 5/5
✔ proxy Skipped - No image to be pulled 0.0s
✔ postgres Pulled 0.9s
✔ lemmy Pulled 0.7s
✔ lemmy-ui Pulled 0.7s
✔ pictrs Pulled 0.9s
[+] Building 0.7s (9/9) FINISHED
=> [proxy internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 202B 0.0s
=> [proxy internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [proxy internal] load metadata for docker.io/library/caddy:latest 0.0s
=> [proxy internal] load metadata for docker.io/library/caddy:builder 0.6s
=> [proxy stage-1 1/2] FROM docker.io/library/caddy:latest 0.0s
=> [proxy builder 1/2] FROM docker.io/library/caddy:builder@sha256:***** 0.0s
=> CACHED [proxy builder 2/2] RUN xcaddy build --with github.com/caddy-dns/cloudfl 0.0s
=> CACHED [proxy stage-1 2/2] COPY --from=builder /usr/bin/caddy /usr/bin/caddy 0.0s
=> [proxy] exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:******* 0.0s
=> => naming to docker.io/library/lemmy-easy-deploy-proxy 0.0s
[+] Running 6/6
✔ Container lemmy-easy-deploy-proxy-1 Remo... 1.4s
✔ Container lemmy-easy-deploy-lemmy-ui-1 R... 10.3s
✔ Container lemmy-easy-deploy-lemmy-1 Remo... 0.5s
✔ Container lemmy-easy-deploy-postgres-1 R... 0.3s
✔ Container lemmy-easy-deploy-pictrs-1 Rem... 0.5s
✔ Network lemmy-easy-deploy_default Remove... 0.1s
[+] Running 6/6
✔ Network lemmy-easy-deploy_default Create... 0.0s
✔ Container lemmy-easy-deploy-postgres-1 S... 0.5s
✔ Container lemmy-easy-deploy-pictrs-1 Sta... 0.5s
✔ Container lemmy-easy-deploy-lemmy-1 Star... 0.8s
✔ Container lemmy-easy-deploy-lemmy-ui-1 S... 1.0s
✔ Container lemmy-easy-deploy-proxy-1 Star... 1.3s
Checking deployment status...
Checking proxy... OK!
Checking lemmy... OK!
Checking lemmy-ui... OK!
Checking pictrs... OK!
Checking postgres... OK!
Deploy complete!
BE: 0.18.1
FE: 0.18.2
--------------------------------------------------------------------------------------
NOTE: Please do not run from the ./live folder directly, or you may cause issues!
To shut down your deployment, run:
./deploy.sh --shutdown
To start your deployment back up, run
./deploy.sh
If you must manage your deployment manually, it is critical to supply the stack name:
docker compose -p "lemmy-easy-deploy" [up/down/etc]
--------------------------------------------------------------------------------------
LEMMY_TLS_ENABLED="false" you're saying this should be false and not true?
I was saying that it being false
would do this, it should be true
.
It could also be that you've found a bug in Lemmy that causes that setting to not be considered once the database is already initialized.
Are the http prefixes in ./live/caddy/Caddyfile gone now?
Yes, the prefixes are gone now. Same problems though it seems.
It could also be that you've found a bug in Lemmy that causes that setting to not be considered once the database is already initialized.
If this is the case, is there anything that I can do?
First, go into the Lemmy-Easy-Deploy folder, and run this:
cat ./live/lemmy.hjson
You will see your config file. Don't post it here, it will have passwords :p
In that config file, you should see a block like this:
hostname: "***"
bind: "0.0.0.0"
port: 8536
tls_enabled: true
That tls_enabled
option should be true
as I have shown here. If it's false
, then that's why you're having issues.
But, if it is true
, and you are still having issues, then it would go on the Lemmy issue tracker, not the UI one:
https://github.com/LemmyNet/lemmy/issues
Requests with the application/*
header go directly to the Lemmy backend, so this wouldn't be a frontend issue, I don't think.
Whether or not https
is used is set here, so hopefully you only have a configuration issue:
Yep it’s set to true. So my only option is deleting and starting over?
Try making a new post now that the server is running with that setting and see if it's any different with curl. I think the data in your old post might only be set once.
:( same results. Any other ideas?
Unfortunately I'm not sure what to recommend in this case. If you don't have important data, you could start over and delete everything:
./deploy.sh --shutdown
docker volume rm lemmy-easy-deploy_caddy_config lemmy-easy-deploy_caddy_data lemmy-easy deploy_pictrs_data lemmy-easy-deploy_postgres_data
rm -rf ./live
Otherwise, it looks like Lemmy-Easy-Deploy is configuring everything as expected, so I suppose you could make a new issue with your redacted ./lemmy.hjson
config and see what they say. You should tell them that it was created with that setting set to false during first time setup.
Submitted the bug report. Seems like it should be such an easy fix somewhere. That's the only thing making me hesitant on deleting and starting over.
Did you check the FAQ & Troubleshooting section for answers to common questions and issues?
Describe the issue
Running curl -h on pages in my instance shows that http is being used for most links and not https. This seems to be causing issues in quite a few areas. Comments from my instance aren’t syncing to others and /c/ urls fail. What mistake would I have had to of made for SSL to not be applied universally?