[-] gyoo@lemmy.ca 1 points 4 months ago

No I'm not. I don't have any crashes or anything of the sort and I am monitoring it very closely. Also, using curl works just fine, so it doesn't seem to be about the server...

[-] gyoo@lemmy.ca 1 points 4 months ago

That's what I tought, but both cinny and element web have this issue and it sounds like people should be able to go up to 2GB.

[-] gyoo@lemmy.ca 4 points 4 months ago

Des trous d'culs.

[-] gyoo@lemmy.ca 3 points 4 months ago

Well, the thing is that the threat is still very much present today. The french language is declining in Quebec, the youth speak more and more english, the internet is basically in english, no matter how hard you try, french music and movies are either inexistant or nobody watches them, there's routinely stories comming out of Quebecers trying to get a service from the federal, only to get shut down because nobody speak french on the other end of the line, it's more and more difficult to get a job where it's feasible to speak french all day, higher-ups in corporations live decades in the metropolis without speaking a word of french, university students are tought their fields in english, in a french class and McGill (an english university) get 90% of the grants in the province, and on and on and on. The battle is not about the conquest wars or the october crisis, it's about today.

[-] gyoo@lemmy.ca 2 points 4 months ago

As I said, the CAQ is doing a particularly bad job at the moment. They have made very poor financial decisions over the past decade and now they have to claw the deficit, blaming the problems on everything else, you know, the usual political stuff. So now they cut funding for everything, promising that nothing will be affected and they create new laws to make it appear as if they're doing something before the next election drives them in the ground.

I will conceed that there is a background of xenophobia in a lot of these movements, but it is not mainstream. And remember that the CAQ is not the OQLF and it is not the population. The CAQ's poll rating are devastating right now. And when that story came out, pretty much everybody reacted saying "yet another stupid decision from the CAQ".

[-] gyoo@lemmy.ca 1 points 4 months ago* (last edited 4 months ago)

It works with curl, but I don't really know how to test the web client behind the rathole. The service is only accessible through the reverse proxy, which depends on the domain name to send requests correctly. Even if I managed to access the client in this way, element web would just send the file to the domain name, which would just come back through the rathole.

[-] gyoo@lemmy.ca 1 points 4 months ago* (last edited 4 months ago)

I have actually tried hosting Nextcloud, but I only have 1GB of ram and already running more than 2GB of swap often means the linux kernel crashes because of memory corruption. This is a personnal server, so the main reason is to have a big selling point for my family/friends/close colleagues to switch. It's also a testing ground for a project with an organisation I'm working with that would use the service for work stuff, and again it's a big selling point that we can send 50 times the file size as Discord for free.

[-] gyoo@lemmy.ca 1 points 4 months ago

Yeah, I can't find either of those settings in the configuration docs and I wasn't just sending images.

[-] gyoo@lemmy.ca 1 points 4 months ago

How would I do that? The curl command already works and the service is being handeld by the reverse proxy, which depends on the domain name to pass the requests correctly. Even if I succeeded, element-web is configured to send the file to the domain name, not the local address.

[-] gyoo@lemmy.ca 1 points 4 months ago

The idea is to have one nginx container responsible for the tls handling and request distribution (I have more than one service running on the device) and the other for actually handling the request. It keeps things organised.

[-] gyoo@lemmy.ca 2 points 4 months ago* (last edited 4 months ago)

Although I agree that the CAQ is doing a terrible job at the moment and that the bureaucrats at the OQLF sometimes exagerate without considering themseleves if there exists an alternative, it is about culture and has always been. The politics in Quebec have always rotated arround the defense against english assimilation.

[-] gyoo@lemmy.ca 1 points 4 months ago

J'ai hâte qu'on arrête de lécher les bottes à Microsoft...

8
submitted 4 months ago* (last edited 4 months ago) by gyoo@lemmy.ca to c/matrix@lemmy.ml

I am trying to increase the upload limit on my matrix server. I would like to push it to 500MB, but it keeps failing the upload past ~180MB. There is very little information about the failure, the client just says "Unkown error", nginx says "error 499", which means the client disconnected to quickly. Additionally, trying to recreate the failure with curl just results in a success, so the issue seems to be with the client. I tried with element-web, element desktop, element x and cinny and they all have this issue.

I run a continuwuity server on a Raspberry Pi 4B, behind two nginx reverse proxies and a rathole tunnel. Continuwuity, and the two reverse proxies run inside docker compose projects. Here is my architecture :

                   __
                 .(  ).
               (`Cloud )
                `-----`
                   |
                   V
          +- Outside server -+
          |   +---------+    |
          |   | rathole |    |
          |   +---------+    |
          +--------|---------+
                   |
+- Home network ---|-------------------------+
| +- RasPi --------|-----------------------+ |
| |                V                       | |
| |       +- tunnel docker -+              | |
| |       | +---------+     |              | |
| |       | | nginx 1 |     |              | |
| |       | +---------+     |              | |
| |       +-----|-|---------+              | |
| |             | |                        | |
| |             | +- other services -->... | |
| |             |                          | |
| |             V                          | |
| |       +- matrix docker --+             | |
| |       |   +---------+    |             | |
| |       |   | nginx 2 |    |             | |
| |       |   +---------+    |             | |
| |       |        |         |             | |
| |       | +------V-------+ |             | |
| |       | | Continuwuity | |             | |
| |       | +--------------+ |             | |
| |       +------------------+             | |
| +----------------------------------------+ |
+--------------------------------------------+

Of course, I made sure to increase the upload limit in Continuwuity :

max_request_size = 500000000

And in both nginx instances :

client_max_body_size 500M;

From what I can gather from other issues on the internet, it seems it could be related to timeout errors. Although they all seem to be talking about 2-8Gb files, I am probably running much weaker hardware than they do, so it checks out.

I tried setting the following values in both nginx instances :

location / {
    proxy_connect_timeout       600;
    proxy_send_timeout          600;
    proxy_read_timeout          600;
    send_timeout                600;
    proxy_next_upstream         off;
    proxy_buffering             off;

    proxy_pass ...;
}

And setting timeout values in Continuwuity :

client_receive_timeout = 75
client_request_timeout = 180
client_response_timeout = 120
client_shutdown_timeout = 10

Since that didn't have any effect, I bumped them by 20x and 40x respectively :

location / {
    proxy_connect_timeout       18000;
    proxy_send_timeout          18000;
    proxy_read_timeout          18000;
    send_timeout                18000;
    proxy_next_upstream         off;
    proxy_buffering             off;

    proxy_pass ...;
}
client_receive_timeout = 3000
client_request_timeout = 7200
client_response_timeout = 4800
client_shutdown_timeout = 400

But that did not have any effect. I also looked at modifying element-web's settings, but there doesn't seem to be anything related to timeouts.

I also saw that encrypted vs. unencrypted rooms might have an effect, but I got ~190MB max in encrypted rooms and ~180MB in unencrypted rooms.

Finally, I tried using curl :

curl -X POST https://server.domain/_matrix/media/v3/upload -H "Authorization: Bearer <token>" -H "Content-Type application/octet-stream" --data @200mb.file
# success
# returns a mxc:// url
curl -X POST https://server.domain/_matrix/client/v1/media/download/server.name/file_id -H "Authorization: Bearer <token>" -o 200mb_copy.file
# See that the two files are identical

I am at a loss. What can I do to solve this issue?

EDIT 1:

I did some tests and I can post 1GB files both inside and outside the pi, but it still doesn’t work for the web client.

17
submitted 4 months ago by gyoo@lemmy.ca to c/selfhosted@lemmy.world

I am trying to increase the upload limit on my matrix server. I would like to push it to 500MB, but it keeps failing the upload past ~180MB. There is very little information about the failure, the client just says "Unkown error", nginx says "error 499", which means the client disconnected to quickly. Additionally, trying to recreate the failure with curl just results in a success, so the issue seems to be with the client. I tried with element-web, element desktop, element x and cinny and they all have this issue.

I run a continuwuity server on a Raspberry Pi 4B, behind two nginx reverse proxies and a rathole tunnel. Continuwuity, and the two reverse proxies run inside docker compose projects. Here is my architecture :

                   __
                 .(  ).
               (`Cloud )
                `-----`
                   |
                   V
          +- Outside server -+
          |   +---------+    |
          |   | rathole |    |
          |   +---------+    |
          +--------|---------+
                   |
+- Home network ---|-------------------------+
| +- RasPi --------|-----------------------+ |
| |                V                       | |
| |       +- tunnel docker -+              | |
| |       | +---------+     |              | |
| |       | | nginx 1 |     |              | |
| |       | +---------+     |              | |
| |       +-----|-|---------+              | |
| |             | |                        | |
| |             | +- other services -->... | |
| |             |                          | |
| |             V                          | |
| |       +- matrix docker --+             | |
| |       |   +---------+    |             | |
| |       |   | nginx 2 |    |             | |
| |       |   +---------+    |             | |
| |       |        |         |             | |
| |       | +------V-------+ |             | |
| |       | | Continuwuity | |             | |
| |       | +--------------+ |             | |
| |       +------------------+             | |
| +----------------------------------------+ |
+--------------------------------------------+

Of course, I made sure to increase the upload limit in Continuwuity :

max_request_size = 500000000

And in both nginx instances :

client_max_body_size 500M;

From what I can gather from other issues on the internet, it seems it could be related to timeout errors. Although they all seem to be talking about 2-8Gb files, I am probably running much weaker hardware than they do, so it checks out.

I tried setting the following values in both nginx instances :

location / {
    proxy_connect_timeout       600;
    proxy_send_timeout          600;
    proxy_read_timeout          600;
    send_timeout                600;
    proxy_next_upstream         off;
    proxy_buffering             off;

    proxy_pass ...;
}

And setting timeout values in Continuwuity :

client_receive_timeout = 75
client_request_timeout = 180
client_response_timeout = 120
client_shutdown_timeout = 10

Since that didn't have any effect, I bumped them by 20x and 40x respectively :

location / {
    proxy_connect_timeout       18000;
    proxy_send_timeout          18000;
    proxy_read_timeout          18000;
    send_timeout                18000;
    proxy_next_upstream         off;
    proxy_buffering             off;

    proxy_pass ...;
}
client_receive_timeout = 3000
client_request_timeout = 7200
client_response_timeout = 4800
client_shutdown_timeout = 400

But that did not have any effect. I also looked at modifying element-web's settings, but there doesn't seem to be anything related to timeouts.

I also saw that encrypted vs. unencrypted rooms might have an effect, but I got ~190MB max in encrypted rooms and ~180MB in unencrypted rooms.

Finally, I tried using curl :

curl -X POST https://server.domain/_matrix/media/v3/upload -H "Authorization: Bearer <token>" -H "Content-Type application/octet-stream" --data @200mb.file
# success
# returns a mxc:// url
curl -X POST https://server.domain/_matrix/client/v1/media/download/server.name/file_id -H "Authorization: Bearer <token>" -o 200mb_copy.file
# See that the two files are identical

I am at a loss. What can I do to solve this issue?

view more: next ›

gyoo

0 post score
0 comment score
joined 4 months ago