Friday, July 21, 2023
support@conference.yunohost.org
July
Mon Tue Wed Thu Fri Sat Sun
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
           

[07:34:55] <xananax> yunohost installs apps and then mostly stays out of the way, so if your Synapse is struggling, it's almost certain YNH is not related to that.
[07:35:42] <xananax> What yunohost does is equivalent to installing Synapse manually and setting up Nginx to serve it at a proper URL, and adding a cron job for certbot
[07:36:22] <xananax> Some apps do have special configuration made by the packager, but even then, the issue would be configuration, and not yunohost (I think the Synapse package is vanilla).
[07:37:00] <xananax> Do note that Synapse can get pretty heavy on a small VPS, specially if large servers/rooms are joined
[08:01:00] <lapineige> Except when there is an issue in the app packaging, or a bug in the app that needs an upgrade to be solved and the upgrade is not yet yeady in Yunohost. That's was the case recently. There is always one more layer of human errors added 🙂
But in that case, it's unlikely
[08:01:04] <lapineige> Except when there is an issue in the app packaging, or a bug in the app that needs an upgrade to be solved and the upgrade is not yet yeady in Yunohost. That's was the case recently. There is always one more layer of human errors added 🙂
But in that case (performance issue), it's unlikely
[08:12:33] <Lars (Fulda.social)> The Last Error for the WhatsApp Bridge. I got an Error 500 when i try to Login.
[08:14:28] <Lars (Fulda.social)> ```Failed to upload QR code: failed to POST /_matrix/media/v3/upload: M_UNKNOWN (HTTP 500): Internal server error```

its an config Error of "maybe" Nginx.
[08:21:42] <Jim> > <@lars:fulda.social> ```Failed to upload QR code: failed to POST /_matrix/media/v3/upload: M_UNKNOWN (HTTP 500): Internal server error```
>
> its an config Error of "maybe" Nginx.

This is a known bug in Synapse (the matrix server).
It has been fixed upstream and the fix will land in the YNH package when it's ready.
In the meantime, you can apply the quick fix offered on the forum:

https://forum.yunohost.org/t/synapse-instant-messaging-server-matrix-network/4381/141
[08:26:30] <Jim> Or you can use the solution proposed on https://github.com/YunoHost-Apps/synapse_ynh/issues/396#issuecomment-1633615136:

/opt/yunohost/matrix-synapse/bin/pip install 'Pillow<=9.5.0-2' systemctl restart matrix-synapse.service
[08:54:18] <Lars (Fulda.social)> > <@jeremie:chezj.im> Or you can use the solution proposed on https://github.com/YunoHost-Apps/synapse_ynh/issues/396#issuecomment-1633615136:
>
> /opt/yunohost/matrix-synapse/bin/pip install 'Pillow<=9.5.0-2' systemctl restart matrix-synapse.service

IT Works now. Thanks
[10:36:55] <Nadine> Hi,
I just upgraded to latest yunohost version. Ran very smoothly, thanks for all the work. 🙏

I hoped that the new yunohost version would fix my issue with sending mails from my yunohost subdomain's mail to my main domain (main domain's mx points to a third party, not to yunohost server). However, postfix assumes that my main domain's emails are managed by yunohost server which is not the case. So, I always receive "user_unknown" error message from postfix. Indeed, the user shouldn't be known as it's an external mail service. This is what I've tried so far: https://forum.yunohost.org/t/postfix-mails-to-main-domain-are-not-sent-user-unknown/24896. What can I do to exclude my main domain from postfix ldap domains? I'm not using ldap on this domain anyway. Probably some editing in postfix's main.cf? Help greatly appreciated.
[13:42:58] <tituspijean> Lars: to answer your question posted on the wrong channel: the Synapse app does not have a configuration panel. You need to tweak `/opt/yunohost/matrix-synapse/homeserver.yaml` as root to enable user registration. Don't forget to restart the service after any alteration of the configuration file.
[13:57:12] <Lars (Fulda.social)> Okay thanks
[14:39:27] <ParanoSprite> Bonjour tout le monde
[14:41:42] <ParanoSprite> J'ai un petit soucis avec l'appli Photoview
[14:43:10] <ParanoSprite> La partie "album" n’apparaît pas chez les utilisateurs
[14:43:42] <ParanoSprite> alors qu'en tant qu'admin, les albums apparaissent ...
[14:44:01] <ParanoSprite> je pense à une histoire de droits, mais pas sûr
[14:48:29] <ParanoSprite> en fait non, j’étais encore sur mon compte admin, c'est pour ca que les albums apparaissent ...
[14:49:11] <ParanoSprite> du coup, avec un autre compte, qu'il soit en user ou en admin, les albums n'apparaissent pas.
[14:49:34] <ParanoSprite> il n'y a que mon compte où les albums apparaissent
[14:54:44] <heinzey> huh
[19:42:15] <orl> Salut !
[19:44:57] <orl> j'ai vaguement idée que ça ne peut pas marcher avec ce processeur là, mais je n'en suis pas certain en lisant les logs
[19:52:22] <tituspijean> On a raté un de tes messages sur Matrix, je le copie ici
[19:52:25] <tituspijean> > Les logs sont là : https://paste.yunohost.org/raw/emakihiwog
[19:53:44] <tituspijean> mmmh on dirait en effet que NodeJS n'est pas disponible sur armhf
[19:57:20] <yunoyolo> Heya, is there a way to disable ssl? We use a proxy nfs ssl server for all our stuff so that port 80/443 isn't individually exposed
[19:57:36] <yunoyolo> nfs? NGINX
[19:59:08] <tituspijean> there is a global setting for that 🙂
[19:59:22] <orl> tituspijean: merci pour la copie
[19:59:26] <yunoyolo> man, I *thought* I looked everywhere. I'l check again
[20:05:20] <yunoyolo> tituspijean, I don't see it. I see an option for disabling "force https", but that doesn't actually disable it. I just want to access the system via http (our ssl proxy takes care of the rest)
[20:06:01] <Aleks (he/him/il/lui)> you mean you want to *completely disable HTTPS*
[20:06:19] <Aleks (he/him/il/lui)> like why would you want that x_x
[20:06:49] <Aleks (he/him/il/lui)> if you want to access the system via HTTP, then just disable the HTTP->HTTPS redirection, which the setting does
[20:07:09] <Aleks (he/him/il/lui)> not listening at all on port 443 ain't gonna make the access to port 80 better
[20:07:31] <yunoyolo> yes, completely disabled. The reason is that we use NGinx proxy manager. It handles all the certs for all of our internal stuff
[20:07:41] <yunoyolo> I'll try that
[20:13:34] <yunoyolo> doesn't seem to actually disable it. But I have an idea. NGinx proxy manager uses lets encrypt, so I'll see if I can just copy the cert over
[20:15:27] <tituspijean> You can just disable the HTTP to HTTPS redirection and completely ignore all certificate-related stuff and alerts in the diagnosis
[20:17:57] <Aleks (he/him/il/lui)> maybe we can talk about how you are checking that it "doesn't seem to disable it" ... eg the HTTP->HTTPS redirection is probably a permanent 301, so if you browser saw it once, you need to force-clear the cache etc...
[20:22:51] <yunoyolo> >a permanent 301, so if you browser saw it once
[20:23:05] <yunoyolo> >a permanent 301, so if you browser saw it once
[20:23:05] <yunoyolo> Yes, I thought that as well. Haven't tried yet but I will
[20:29:19] <yunoyolo> tried a different browser, still redirects (and I'm going straight to the ip)