@meso @pernia Yes, take a look at this nginx config: https://codeberg.org/silverpill/mitra/src/branch/main/contrib/nginx/mitra-alt-fe.conf#L46
It's better to serve mitra-web with mitra though, because it adds some useful redirects.
@meso mitra serves the frontend 4 u.
thats what the web_client_dir in config is for. you build mitra-web, it puts files into a dist/ and you move the files to your web_client_dir
@silverpill @meso about that.
i talked to the clanker and found out i had to add (/|$) at the end of location ~ ^/(activities|actor|ap|api|collections|feeds|media|metrics|nodeinfo|oauth|objects|users|\.well-known) for that config to make chanfe work on a subdomain (served by nginx).
chanfe wouldn't pass requests to mitra because the regex was wrong (i think thats what the clanker said anyway), and so it wouldn't display timelines/posts etc.
@meso i think pleroma does this as well thats y it juz works cuz it comes with the fe
@meso @silverpill i rember i set up plerome and bloat on chudbsd with relayd once. considering the nginx configs r basically the same too i bet the relayd is gonna look similar
@meso @caohuak @pernia I believe this the main problem all rest looks ok > match request header append "Connection" value "upgrade" it fires on every request that matches, so a plain GET /activities arrives at Mitra with Connection: upgrade attached. Which is wrong for a non upgrade request.
The match ... append line is a hack that pollutes every request with a wrong header and doesn't actually enable the internal mode switch relayd needs. One line I suggest to replace is
http protocol mitra {
...
http websockets
...
}The client already sends those headers. A WebSocket handshake starts as a normal HTTP GET with:
GET /activities HTTP/1.1
Host: nexus.asbestos.cafe
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: ...@pernia @meso I haven't used this nginx config for a long time but the regex looks correct. Maybe there is clash between mitra and chanfe paths? @harblinger
looks like default mitra-web being served https://nexus.asbestos.cafe/
but relayd can't connect/select Mitra on 8383:
>/api/v2/instance returns an OpenBSD relayd 502 whose body says “session failed”. In current relayd source that message comes from backend connection setup failing, so I’d check whether http://127.0.0.1:8383/api/v2/instance works locally and whether relayctl show summary reports the Mitra backend as up.
curl -sv --max-time 10 -H 'Host: nexus.asbestos.cafe' \
http://127.0.0.1:8383/api/v2/instance
doas relayctl show summary
is Mitra actually up?
yeah might as well, noticed something with the TLS setup too, but that can wait
cool, yeah it might be the cert issue, I could navigate with the browser but got this when using curl:
$ curl https://nexus.asbestos.cafe/api/v2/instance
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
>the server sends only the leaf certificate, without the Let’s Encrypt intermediate. Check that relayd’s certificate file contains the full chain.
and since I don't know how to do that here's astra's response to how do I do that:
grep -c 'BEGIN CERTIFICATE' /etc/ssl/nexus.asbestos.cafe.crt
1 means it contains only one certificate. For his Let’s Encrypt setup, the file should contain the site certificate followed by the intermediate certificate—normally 2 certificates.
One wrinkle: relayd prefers /etc/ssl/nexus.asbestos.cafe:443.crt if that exists, so check that file too. relayd documentation
If he uses OpenBSD’s acme-client, check the domain block in /etc/acme-client.conf. The relevant setting should be:
domain full chain certificate "/etc/ssl/nexus.asbestos.cafe.crt"
The distinction is full chain certificate, which writes the site certificate plus intermediates, versus certificate, which writes only the site certificate. The output path must match whichever file relayd
actually loads. acme-client documentation
I am but a channel
Astra speaks through me
>Can you paste the domain "nexus.asbestos.cafe" { ... } block from /etc/acme-client.conf? Looking for whether it says domain certificate or domain full chain certificate, and which path it writes to. relayd is currently serving only the site certificate, without the intermediate.
relayd.conf
ext_inet="23.131.76.109"
table <mitra_server> { 127.0.0.1 }
table <httpd_static> { 127.0.0.1 }
http protocol mitra {
tls ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"
# tls ecdhe "X25519,P-256,P-384,secp521r1" # relayd default+secp521r1
tls ecdhe X25519
return error
tls keypair "nexus.asbestos.cafe"
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "Connection" value "upgrade"
# pass request quick header "Host" value "nexus.asbestos.cafe" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/activities*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/actor*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/ap*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/api*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/collections*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/feeds*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/media*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/metrics*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/nodeinfo*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/oauth*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/objects*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/users*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" path "/.well-known*" forward to <mitra_server>
pass request quick header "Host" value "nexus.asbestos.cafe" forward to <httpd_static>
}
relay wwwtls {
listen on $ext_inet port https tls # Comment to disable listening on IPv4
protocol mitra
# forward to <mitra_server> port 8383 check tcp timeout 500 # Adjust timeout accordingly when relayd returns 502 while Mitra is running without problems.
# When serving multiple services, add the forwards here.
# Example:
# forward to <httpd_static> port 8080 check tcp timeout 500
forward to <mitra_server> port 8383 check tcp timeout 500
forward to <httpd_static> port 8080 check tcp timeout 500
}
httpd.conf
server "nexus.asbestos.cafe" {
listen on 127.0.0.1 port 8080
root "/nexus.asbestos.cafe/latest"
}
server "*" {
listen on * port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location * {
block return 302 "https://$HTTP_HOST$REQUEST_URI"
}
}
Tell him to replace this in relayd.conf:
tls keypair "nexus.asbestos.cafe"
with:
tls keypair "nexus.asbestos.cafe" cert "/etc/ssl/nexus.asbestos.cafe.fullchain.pem"
That explicitly selects the full chain while retaining the existing private-key lookup. Documentation
Then validate:
doas relayd -n
If successful, reload:
doas rcctl reload relayd
@7666 @zer0unplanned @caohuak @meso we raped meso and he couldn't unrape himself 