[08:59:45]
<Melchisedech[m]> Hi, this morning I noticed I couldn’t connect to my Yunohost through SSH anymore. Maybe I’ve lost it for weeks, I didn’t use my SSH access for quite a time. I gained access to the shell by installing ShellInABox. I thought it was related to all the recent upgrades in Yunohost that might have caused troubles with my custom SSH config. So I decided to regenerate a clean / default SSH config through yunohost tools regen-conf ssh --with-diff --dry-run but… I have no output, like my config was the default one. But I can assure you my /et/ssh/sshd_config file is not default at all.
[09:24:45]
<Melchisedech[m]> Ok, I’ve found a workaround. I forced a regen, copied my public key to the server and then forbid password authentication. Now it works fine.
[10:44:51]
<lautre> Cool.
I don't know the "regen-conf ssh" tools, but the `--dry-run` let's me think that will do nothing.
[10:46:14]
<lautre> Next time you have problem with ssh connexion, you can add `-v` or `-vv` or `-vvv` to make you client ssh verbose.
[10:46:29]
<fch> anyone elseo having problems after nextcloud upgrade to 25.0.4 when connection to desktop clients?
[10:47:01]
<lautre> What logs say?, fch?
[10:48:08]
<lautre> On the server, do you see the connexions attempts from your Desktop client?
[10:48:18]
<lautre> And, in your computer, there is any logs about this? Try to kill you Desktop Client, and run it from a terminal
[10:49:21]
<lautre> And, may be your Desktop Client is too old. I don't know, you should ask to NextCloud about this. But in this case, you should see something in logs
[10:49:38]
<fch> How do I see logs from nextcloud, I don't find it under services
[10:50:22]
<fch> > And, may be your Desktop Client is too old. I think it was the problem as I am using debian stable, but then on the other machine with fedora, same problem
[10:50:45]
<fch> I thought it was the problem*
[10:55:22]
<YnhNginx> J'ai tenté de modifier le fichier yunohost_api.conf.inc dans nginx et cela n'a rien changé
[10:56:33]
<YnhNginx> Merci bcp pour votre aide :)
[11:00:21]
<YnhNginx> J'ai également modifié le fichier yunohost_admin.conf.inc, sans susses, depuis ces changements mon nginx est down et ne se relance plus du tout.
[11:05:58]
<titus[m]> > Bonjour à tous. J'ai eu le malheur d’utiliser l'option "Activer la liste des IP autorisées pour l'administration Web", puis j'ai renseigné mon IP publique. En espérant d’autoriser à l'administration de mon Ynh que mon IP perso. Sauf que cela n'as pas marché, donc j'ai voulu faire la marche arrière, en cela n'as pas marché non plus.
Le premier message de YnhNginx qui n'a pas été transmis au salon Matrix
[11:14:41]
<tituspijean> YnhNginx donc, remettons-ça à zéro 🙂
Connecte-toi à ton serveur en SSH et fais:
`sudo yunohost settings set security.webadmin.webadmin_allowlist_enabled -v 'no'`
[11:16:07]
<tituspijean> Pour NGINX: `sudo yunohost tools regen-conf nginx -n -d` pour vérifier les différences puis simplement `yunohost tools regen-conf nginx -f` pour réinitialiser tes modifs
[11:17:27]
<tituspijean> De manière générale, toute action faite sur la webadmin peut-être défaite en SSH, il suffit de consulter la documentation et `man yunohost`, et d'appeler à l'aide ici avant de tout dézinguer. ^^
[11:26:11]
<fch> > What logs say?, fch?
Error: Undefined array key "s01" at /var/www/nextcloud/apps/user_ldap/templates/part.wizard-server.php#10
[11:28:07]
<YnhNginx> @titus:pijean.ovh Merci bcp pour ton aide
[16:39:54]
<FredJ> Bonsoir,
Voici mon soucis :
Sur un Yunohost 11.1.10 il y a le service php7.4-fpm qui s'arrête sans prévenir. Ce qui a une incidence sur Nextcloud en particulier et donc pour les utilisateurs connectés.
Avec un
`yunohost service restart php7.4-fpm`
ça repart, mais je ne sais jamais combien de temps ça va tenir.
Vous avez déjà rencontré ce soucis?
Merci de votre aide,
[16:42:04]
<FredJ> Info supplémentaire :
avec
`yunohost service status`
je vois qu'il y a php7.4-fpm et php8.0-fpm qui tournent en même temps. Je ne sais pas si c'est bloquant ou normal...
[16:55:18]
<AerisOne> c'est normal, certaines applications nécessitent php8 quand d'autres sont encore sous php7.4.
est-ce que tu as installé des apps récemment ? (autrement dit : est-ce que c'est depuis l'installation d'une app précise que tu as ce soucis ?)
est-ce que tu aurais également moyen de récupérer les logs de php7.4 la prochaine fois qu'il plantera ?
[16:58:12]
<nicofrand> Hey! Y'aurait des utilisateurs de Kresus ici, qui ont la dernière maj (0.19) d'installée ? Si oui, pouvez-vous aller dans « Accès bancaire » et cliquer sur l'icône calendrier d'un des comptes et me dire si vous avez une erreur ?
[17:11:57]
<FredJ> > <@aerisone:matrix.org> c'est normal, certaines applications nécessitent php8 quand d'autres sont encore sous php7.4.
>
> est-ce que tu as installé des apps récemment ? (autrement dit : est-ce que c'est depuis l'installation d'une app précise que tu as ce soucis ?)
>
> est-ce que tu aurais également moyen de récupérer les logs de php7.4 la prochaine fois qu'il plantera ?
Merci de ta réponse concernant les 2 versions de php.
Ce soucis a commencé depuis la double migration debian10 -> 11 et vers Yunohost 11. Avant, je n'ai jamais eu ce soucis.
[17:43:58]
<lautre> À tout hasard, est ce que Php8 est aussi instable?
[17:46:25]
<lautre> Clairement, ce n'est pas normal que ça ne soit pas relancé tout seul. Normalement c'est systemd qui s'en charge.
Il faudrait voir le status de la version 7 de ton php quand il a planté, à travers systemd (systemctl). Il y a aussi des journaux spécifiques à Systemd.
[17:47:15]
<lautre> Par exemple si le processus php7 (fpm?) plnate trop rapidement après relance par systemd, alors il ne sera pas relancé après quelques échecs
[17:49:46]
<lautre> J'ai essayé de faire écouter un service (Lufi), sur le port 81, en plus de 80 et 443, tout en désactivant la redirection 81->443
Ça nécessiterait de modifier aussi le système sso de la même manière, donc, nous y avons renoncés.
[18:40:28]
<FredJ> > <@lautre:matrix.org> À tout hasard, est ce que Php8 est aussi instable?
Non, php8 ne plante pas.
[18:41:15]
<FredJ> > <@lautre:matrix.org> Clairement, ce n'est pas normal que ça ne soit pas relancé tout seul. Normalement c'est systemd qui s'en charge.
> Il faudrait voir le status de la version 7 de ton php quand il a planté, à travers systemd (systemctl). Il y a aussi des journaux spécifiques à Systemd.
OK, j'irais voir dans les log la prochaine fois que ça plantera.... j'espère pas tout de suite quand même...
Merci pour ces pistes.
A+,
[19:02:00]
<Chatpitaine Caverne> Au cas où aussi, Nextcloud 25 est passé à PHP8.1.
[19:30:01]
<rathantara> There is something like Genetec in Linux eco?
[21:25:57]
<lautre> Pour ceux qui ont un Spip, il y a une mise à jour de sécurité importante. Mais, vous pouvez utiliser l'écran de sécurité dans certains cas.
[21:35:07]
<tituspijean> Hello all, I'm on v11.1.10 and I cannot login with SFTP on a freshly installed my_webapp:
```
sftp -P PORT my_webapp@SERVER
Debian GNU/Linux 11
my_webapp@SERVER's password:
client_loop: send disconnect: Broken pipe
Connection closed.
Connection closed
```
I cannot find anything relevant in the logs, any idea what might be the problem? (ssh conf is clean and regen'd)
[21:42:19]
<Aleks (he/him/il/lui)> hmkay, does `groups my_webapp` lists `sftp.app` ?
[21:42:46]
<tituspijean> yup!
[21:43:50]
<Aleks (he/him/il/lui)> 🤔
[21:44:16]
<Aleks (he/him/il/lui)> maybe there's more clue in /var/log/auth.log 🤔
[21:46:06]
<tituspijean> ooooooh
[21:46:10]
<tituspijean> `fatal: bad ownership or modes for chroot directory component "/var/www/"`
[21:46:18]
<tituspijean> I thought we fixed that?
[21:46:33]
<Aleks (he/him/il/lui)> eeeeh yeah
[21:46:34]
<Aleks (he/him/il/lui)> hmmm
[21:46:40]
<Aleks (he/him/il/lui)> well it should complain about /var/www/my_webapp
[21:46:52]
<Aleks (he/him/il/lui)> i mean sftp is supposed to access /var/www/my_webapp/www
[21:47:08]
<Aleks (he/him/il/lui)> and because of this some permission should be right on /var/www/my_webapp
[21:47:21]
<Aleks (he/him/il/lui)> but i don't think it should complain about /var/www
[21:47:30]
<Aleks (he/him/il/lui)> i may be wrong tho
[21:48:00]
<Aleks (he/him/il/lui)> what's the output of `ls -ld /var/www` ?
[23:32:20]
<tituspijean> Could it be why I'm getting the error, since " All components of the [chroot] pathname must be root-owned directories that are not writable by any other user or group"?
[23:32:20]
<tituspijean> Damn that was it.
[23:32:21]
<tituspijean> I really don't know when/why I did that. It seems to be unrelated to the admins group thing
[23:32:21]
<tituspijean> Aleks (he/him/il/lui) I see that my user has write access to /var/www via ACLs, through the admins group I guess