[09:52:24]
<tituspijean> isAAAc: can you re-trigger the diagnosis? Might have been a fluke?
[09:52:34]
<thatoo> Je fais face à une situation que je ne comprends pas.
```
$ groups
USERNAME www-data nextcloud admins all_users mail.main xmpp.main listmonk.admin listmonk.main nextcloud.api nextcloud.main listmonk.api
$ ls -al /var/www/nextcloud/apps
ls: cannot access '/var/www/nextcloud/apps': Permission denied
$ sudo ls -al /var/www
total 24
drwxr-xr-x+ 6 root root 4096 Mar 26 08:29 .
drwxr-xr-x 13 root root 4096 Aug 30 2023 ..
drwxr-xr-x 2 root root 4096 Dec 6 2022 html
drwxr-x--- 2 listmonk www-data 4096 Jan 4 11:17 listmonk
drwxr-x--- 14 nextcloud www-data 4096 Mar 26 08:45 nextcloud
drwxr-xr-x 18 root root 4096 Apr 9 07:06 .well-known
```
[09:53:19]
<thatoo> Pourquoi
```
$ ls -al /var/www/nextcloud/apps
ls: cannot access '/var/www/nextcloud/apps': Permission denied
```
et donc pourquoi je ne peux pas cd dans le dossier alors que je suis membre des groups www-data et nextcloud et que les dossiers sont en r-x pour le groupe?
[10:04:41]
<thatoo> ```
$ sudo namei -mo /var/www/nextcloud/apps
f: /var/www/nextcloud/apps
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root www
drwxr-x--- nextcloud www-data nextcloud
drwxr-xr-x nextcloud www-data apps
```
[10:06:31]
<thatoo> Pourquoi je peux faire sans sudo
`ls -al /`
`ls -al /var`
mais pas
`ls -al /var/www`
sans sudo
[10:07:10]
<thatoo> ni les dossiers à l'intérieur de /var/www
[10:08:45]
<thatoo> aha, qu'est-ce que signifie le petit + dans
```
$ sudo ls -al /var/www
drwxr-xr-x+ 6 root root 4096 Mar 26 08:29 .
```
[10:11:14]
<thatoo> tout est là https://forum.yunohost.org/t/acceder-a-un-repertoire-drwxr-xr-x/26952/3
merci Aleks (he/him/il/lui)
[10:54:44]
<isAAAc> > <@titus:pijean.ovh> isAAAc: can you re-trigger the diagnosis? Might have been a fluke?
ouep je regarde ce que ça a donné hier soir et ce matin
[10:57:38]
<isAAAc> tituspijean: ok yesterday evening and this morning ✅ thx for the remind
[18:27:26]
<Centralscrutinizer> good evening yunohosters
[18:29:00]
<Centralscrutinizer> i wanted to give another try to mautrix_signal bridge, but I can't understand from the github repo if master branch is already the go version of the bridge...
[18:32:05]
<Centralscrutinizer> because something strange happens when installing it... the installation process is succesfull and no error is given, but the service fails to start. As I understand the bridge is now installed in /var/www/mautrix\_signal but no bin folder is created there
[18:34:35]
<Centralscrutinizer> Thanks, so no matter what I try, it will not work
[18:34:35]
<orhtej2> > i wanted to give another try to mautrix_signal bridge, but I can't understand from the github repo if master branch is already the go version of the bridge...
It's python as it installs 0.4.3 and go is 0.5.0+
[18:36:21]
<Centralscrutinizer> as far as I know the python bridge still uses signald, that it is not compaible with signal new apis...But I might be wrong
[18:36:21]
<orhtej2> Idk what does not work 🤷♂️
[19:22:50]
<rodinux> Hello, une question a vous poser. Est-il possible pour un utilisateur utilisant un dyndns avec un sous domaine pour une application d'avoir tout de même les configurations MX SPF de ce sous-domaine ?
[19:24:06]
<rodinux> avec un domaine en ynh.fr
[19:32:01]
<Aleks (he/him/il/lui)> en l'état le SPF n'est mis que sur le domaine racine, pas les sous-domaine
[19:37:37]
<rodinux> Ok, c'est pour une personne qui est embêtée avec l'app paheko...
[19:41:03]
<@rosbeefandino:3cmr.fr> > <@Alekswag:matrix.org> en l'état le SPF n'est mis que sur le domaine racine, pas les sous-domaine
c'est une specification du champs spf ou une implementations secifique a ynh?
[19:41:35]
<@rosbeefandino:3cmr.fr> je ne suis ûas
[19:43:40]
<@rosbeefandino:3cmr.fr> le serveur mail ne se base t'il pas sur le @sous.domaine.tld pour aller chercher le spf? et le dns de sous.domaine.tld n'est il pas heberge sur le ynh?
[19:47:29]
<Aleks (he/him/il/lui)> on pourrait le gérer, mais c'est pas trivial, ça demande de taffer sur le serveur dyndns et le client également, c'est pas spécialement une priorité et anyway idéalement les gens devraient vraiment prendre un nom de domaine à elleux sur le long terme parce qu'iels sont pas vraiment "propriétaire" du dyndns
[19:56:24]
<rodinux> Sinon quel est le risque potentiel si pour le coup passe le SMTP à `SMTP_HOST = false;` ce qui revient à utiliser le mail de php_mail()...
[19:57:31]
<Aleks (he/him/il/lui)> le risque est que les mails ne soient pas signé DKIM et donc soient marqués comme spam (ou pire, refusés complètement) par les GAFAM
[19:58:09]
<Aleks (he/him/il/lui)> (sinon on s'embetterait pas à faire une conf compliquée avec login/password pour le mail)