Ajoute ceci à la fin de /etc/nslcd.conf et redémarre le service.
threads 3
La nuit porte conseil…
Sur le lien plus haut pour la signature du dépôt, la solution pour mettre la clé à la bonne place, /etc/apt/trusted.gpg.d semble être valide avec ces étapes.
Trouver la clé concernée en listant
rpdom@raspberrypi:~ $ apt-key list | grep -A4 "trusted.gpg$"
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
/etc/apt/trusted.gpg
--------------------
pub rsa2048 2012-06-17 [SC]
CF8A 1AF5 02A2 AA2D 763B AE7E 82B1 2992 7FA3 303E
uid [ unknown] Raspberry Pi Archive Signing Key
Retenir les derniers 8 derniets caractères de long nombre hexadecimal, sans espaces. Ici 7FA3303E.
Ensuite exporter la clé dans un fichier temporaire.
rpdom@raspberrypi:~ $ sudo apt-key export 7FA3303E | sudo gpg --dearmor -o /tmp/raspi.gpg
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
Cela devrait créer un fichier /tmp/raspi.gpg avec la clé.
rpdom@raspberrypi:~ $ file /tmp/raspi.gpg
/tmp/raspi.gpg: PGP/GPG key public ring (v4) created Sun Jun 17 15:49:51 2012 RSA (Encrypt or Sign) 2048 bits MPI=0xabc2a41a70625f9f...
Maintenant supprimet la clé.
rpdom@raspberrypi:~ $ sudo apt-key del 7FA3303E
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK
Et mettre la clé en place.
rpdom@raspberrypi:~ $ sudo mv /tmp/raspi.gpg /etc/apt/trusted.gpg.d/
Bien faire ces étapes dans l’ordre indiqué…
Oui exact, depuis bookworm non-free est remplacé par non-free-firmware. Je corrige plus haut…
Il y a un user admin ? Il me semble que depuis bullseye c’est très déconseillé et risqué… Si c’est le cas il vaut mieux le supprimer…
ldapwhoami -x -D “uid=<ton_user>,ou=users,dc=yunohost,dc=org” -W -H ldap://localhost :
Je viens de re-tester les utilisateurs qui ont les droits ssh :
-admin : accés accepté
-patient, trés utilisé, premier utilisateur créé : accès refusé
-sauveur, utilisé exceptionnellement, créé récemment : accès accepté
Par contre les 3, même patient, ont accès à la webmin.
Les autres utilisateurs sont de simples utilisateurs.
Ajout de “threads 3” dans nslcd.conf, pas de changements.
Pour résumé : 1 utilisateur/administrateur (patient) n’a accès ni en ssh ni au portail, mais a accès à la webmin.
Tous les autres utilisateurs/administrateur ont accès à la webmin et en ssh.
Aucun utilisateur qu’il soit administrateur ou non peut accéder au portail.
Enfin, sans passer par le portail, je peux me connecter à Nextcloud pour tous les utilisateurs même patient.
Enfin, à l’instant, je viens de tomber sur une ligne concernant slapd :
Il ne serait quand même pas dans les utilisateurs locaux ?
Quel était le problème et comment l’as-tu résolu ?
Après avoir réglé le problème de PHP je me suis attaqué au message que j’avais en ssh quand je voulais me connecter au portai : api masked
J’avais accès à la webmin.
Une flopée d’alertes de fichiers conf modifiés manuellement dans le diagnostic.
Perso j’avais modifié un seul fichier de conf, celui du diagnostic pour éviter l’envoi de mail systématique.
Je les ai tous régénérés, j’ai terminé par régénérer la configuration de yunohost et j’ai pu me reconnecter au portail.
Nouveau souci : le service yunomdns est down alors qu’hier il fonctionnait :
Peux-tu jeter un coup d’oeil aux droits dans le dossier /etc/yunohost ?
As-tu d’autres domaines et essayé de te connecter au portail via ces domaines ?
Jette aussi un coup d’oeil dans /etc/yunohost/portal pour voir si tu retrouves bien tes utilisateurs dans le(s) json pour les apps de ton/tes domaines, ça peut jouer.
Je retrouve la recommendation qui date qu passage en 11
L’user admin s’appelle admin_legacy au moins ? sinon il est un alias des tous users du groupe admins et c’est probablement une source de conflits…
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.