[18:26:52]
<Elzen> Salut ! o/ J'ai dû redémarrer mon serveur hier soir, et depuis, le diagnostique se plaint que le port 5349 n'est pas accessible depuis Internet. Étant donné que rien d'extérieur au serveur ne le bloque, je suppose que c'est le service qui est censé écouter dessus qui ne tourne pas, mais depuis l'admin web, tout a l'air actif. Vous sauriez m'indiquer ce que je dois relancer ?
[18:29:22]
<Thomas> Bonjour, bonne année à tous le monde.
[18:30:59]
<Thomas> Concernant l'UPnP il ne reste pas activer indéfiniment il se désactive au bout d'un moment. Est il possible de le laisser activer?
[18:31:45]
<Aleks (he/him/il/lui)> en théorie dans l'idéal oui, mais en pratique le code a pas évolué depuis des années et oui il y a un peu un truc dans le code genre "dès que l'UPnP echoue pour une raison ou une autre, il est désactivé à jamais" ce qui est pas ouf
[18:32:20]
<Thomas> Ah ok bon je vais me recréer les redirections de port à la mano (changment de box et le backup ne contient pas les redirections de ports) snifff
[18:35:55]
<Aleks (he/him/il/lui)> no idea, le diagnostique ne dit pas à quoi est lié ce port ?
[18:37:14]
<Thomas> C'est le port pour le serveur STUN non?
[18:38:26]
<Elzen> Ah beh le diagnostique est content, maintenant :-° Je n'avais effectivement pas pensé à regarder le détail, ça dit que c'est lié à coturn-synapse. Soit un service qui n'a pas l'air de réussir à se lancer tout seul au démarrage de la machine, j'ai régulièrement besoin d'aller le relancer manuellement quand je redémarre. Mais bon là ça a l'air réglé.
[18:39:52]
<Elzen> Merci, en tout cas :-)
[18:44:37]
<Elzen> Tiens, en parlant de ports : il y a un bon moment, j'en avais ouvert quelques uns (9997 à 9999) pour faire des tests, je les ai refermés depuis, mais ils sont toujours listés sur la page « gestion des ports » de l'admin web à côté des ports réellement utiles. Il y a moyen de nettoyer ça quelque part ?
[21:20:28]
<clawfire> Question bête. Comment le service nginx peux apparaitre comme running mais que j'ai un `ERR_CONNECTION_CLOSED` ?
[21:20:46]
<clawfire> `php7.4-fpm` et `php8.0-fpm` tournent sans soucis aussi
[21:20:47]
<clawfire> du moins leur service tourne 😁
[21:21:50]
<clawfire> le log du domaine qui apelle le SSO montre juste
```
185.6.235.150 - - [11/Jan/2024:20:48:16 +0000] "GET /?sso_login=[longue chaine] HTTP/2.0" 302 410 "https://thibau.lt/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
```
[21:21:50]
<clawfire> Les logs de php-fpm sont vide
[21:23:48]
<clawfire> oh! le log de nginx me montre ca :
```
2024/01/11 20:58:57 [alert] 54102#54102: worker process 54104 exited on signal 11
2024/01/11 20:58:57 [alert] 54102#54102: worker process 54103 exited on signal 11
2024/01/11 20:58:58 [alert] 54102#54102: worker process 54124 exited on signal 11
```
Juste avant de planter et de fermer la connexion.
[21:23:48]
<clawfire> J'ai essayé de voir avec `yunohost tools regen-conf --with-diff --dry-run` et il semble que le fichier sldap soit modifié / en attente
[21:23:48]
<clawfire> Une idée de comment le fait de s'authentifier avec succès sur la partie publique pourrais faire cela ?
[21:23:48]
<clawfire> J'ai essayé `yunohost tools regen-conf nginx --with-diff --dry-run` mais rien
[21:25:14]
<clawfire> ```
slapd:
applied:
pending:
/etc/ldap/slapd.ldif:
diff: @@ -1,235 +0,0 @@
-# OpenLDAP server configuration for Yunohost
-# ------------------------------------------
-#
-# Because of the Yunohost's regen-conf mechanism, it is NOT POSSIBLE to
-# edit the config database using an LDAP request.
[file continue]
```
[21:25:51]
<clawfire> Aucune idée de si ça a un lien ou si c'est juste une coincidence / un truc qui n'as rien à voir à part que ca concerne ldap
[21:25:51]
<clawfire> Si c'est bien un diff que je lis comme je crois, le fichier a juste été vidé (tout est en `-` au début de ligne)
[21:28:13]
<clawfire> J'avoue que j'aurais bien besoin d'un petit coup de main, je patauge un peu 😅
[22:56:44]
<Aleks (he/him/il/lui)> hmokay et si tu fais manuellement la commande dovetruc depuis un terminal ça raconte quoi
[22:56:45]
<thatoo> J'ai fait une erreur en manipulant un utilisateur.
Il avait comme courriel `` prenom@ynh.nomdedomaine.tld `` et en transfert `` prenom@nomdedomaine.tld ``.
J'ai voulu passer son courriel en `` prenom@nomdedomaine.tld `` mais j'ai oublié d'enlever d'abord l'email de transfert qui était le même du coup. J'ai cliqué sur "sauvegarder" et depuis, le comportement est étrange.
`` Espace utilisé de la boite aux lettres `` indique `` ? ``
et quand je sauvegarde, j'ai l'erreur suivante `` Failed to fetch quota info ... : Command 'doveadm -f flow quota get -u nathanael' returned non-zero exit status 75. ``
et surtout, ça ne prend pas vraiment en compte la sauvegarde, si je vais dans l'interface utilisateur, le changement n'a pas été pris en compte. Il faut que je le fasse une seconde fois dans l'interface utilisateur pour que ce soit effectif.
[23:00:09]
<Aleks (he/him/il/lui)> 🤔
[23:00:28]
<Aleks (he/him/il/lui)> hmkay, what if you run `ls -ld /var/mail/nathanael/`, does it shows the folder existing ?
[23:07:20]
<thatoo> Merci Aleks de toujours répondre présent et je sais que j'ai initié cette demande mais je sens que je suis trop fatigué pour faire les choses bien, je vais pas prendre le risque à cette heure ci de creuser plus cette erreur.
[23:07:22]
<thatoo> J'ai fait une erreur en manipulant un utilisateur.
Il avait comme courriel `` prenom@ynh.nomdedomaine.tld `` et en transfert `` prenom@nomdedomaine.tld ``.
J'ai voulu passer son courriel en `` prenom@nomdedomaine.tld `` mais j'ai oublié d'enlever d'abord l'email de transfert qui était le même du coup. J'ai cliqué sur "sauvegarder" et depuis, le comportement est étrange.
`` Espace utilisé de la boite aux lettres `` indique `` ? ``
et quand je sauvegarde, j'ai l'erreur suivante `` Failed to fetch quota info ... : Command 'doveadm -f flow quota get -u prenom' returned non-zero exit status 75. ``
et surtout, ça ne prend pas vraiment en compte la sauvegarde, si je vais dans l'interface utilisateur, le changement n'a pas été pris en compte. Il faut que je le fasse une seconde fois dans l'interface utilisateur pour que ce soit effectif.
[23:07:23]
<thatoo> ```
administrateur@ynh:~$ sudo doveadm -f flow quota get -u prenom
doveadm(prenom): Error: chdir(/var/mail/nathanael) failed: Not a directory
doveadm(prenom): Error: Failed to get quota resource STORAGE: quota-maildir: Failed to get STORAGE_BYTES: open(/var/mail/prenom/maildirsize) failed: Not a directory
doveadm(prenom): Error: Failed to get quota resource MESSAGE: quota-maildir: Failed to get MESSAGE: open(/var/mail/prenom/maildirsize) failed: Not a directory
Quota name=User quota Type=STORAGE Value=error Limit=error %=error
Quota name=User quota Type=MESSAGE Value=error Limit=error %=error
```