Je n’ai plus accès à la webadmin ni via ssh.
La seule solution pour me connecter est en local (ou via proxmox) avec le root.
Lorsque je veux modifier le mot de passe d’un utilisateur, il m’est répondu que celui-ci n’existe pas.
Lorsque je fais la liste des users : sudo yunohost user list error during ldap search operation : ... desc : no such objet
Pareil avec sudo yunohost group list
J’avais pourtant une instance qui fonctionnait bien depuis 4 ans.
J’ai fait récemment une mise à jour sans soucis.
Ce problème est arrivé après un reboot.
Je venais de créer un nouvel utilisateur “linux” en ligne de commande et l’avais affecté au groupe “admins”. Celui-ci n’existe pas non plus.
Hier j’ai créé des hooks pour modifier les configurations de postfix et dovecot.
Je me suis rendu compte qu’il y avait d’autres erreurs sur la commande regen-conf.
(erreur du type slapcat: slap_init no backend et idem avec slapadd je crois)
Aujourd’hui, j’ai carrément ceci : https://paste.yunohost.org/raw/xolakupahi
un ls /home/ me donne bien les dossiers de tous les utilisateurs habituels. (mais un getent passwd myuser ne donne rien pour l’ensemble des utilisateurs habituels (sauf root, et le user créé à l’installation de debian avant yunohost)
Ça semble indiquer que la base LDAP a disparu … Mais bon difficile de savoir magiquement pourquoi, visiblement tu a bricolé beaucoup de choses avant que ça arrive …
Oui oui je réponds ça moi aussi, je sais bien. C’était juste pour dire que mon install n’était pas neuve.
C’est en effet ce que j’ai compris aussi. Mais non, je n’ai pas bidouillé tant que ça. J’ai essayé de comprendre des choses, mais je n’ai pas lancé de commande importante. Du moins à ce que je crois.
On est d’accord que un regen-conf ne remet pas la base ldap à zéro ?
Et ya un moyen de la récupérer / reconstruire, cette base ldap ?
Non ça ne remet pas la base à zero, mais bon, tu parles d’avoir créé un user “linux” et l’avoir ajouté au groupe “admins” (qui normalement est un groupe ldap donc mixer user unix et LDAP ça ressemble à une recette pour un désastre)
Déjà je commencerais par voir si le service slapd est bien up et running, et si par hasard un groupe “admins” unix n’aurait pas été créé qui conflicterais avec le groupe ldap
Le user “linux”, je l’ai créé par commandes yunohost : yunohost user create linux et yunohost user group add admins linux
Et il n’y a pas de groupe “admins” unix. Je viens de vérifier.
Pour ce qui est de slapd : systemctl status slapd donne “active (running)”
Ben du coup difficile de savoir qu’est-ce qui a causé tout ça, là on a juste un résumé flou, tu dis que tu ajoutais des hooks hier et que il y avait déjà des erreurs liées à ldap mais que tu sembles avoir ignorer à ce moment là
Le plus simple c’est si tu avais un backup de la base LDAP (inclue dans les backups système de YunoHost).
Les hooks ne concernaient pas ldap, et ils fonctionnaient.
Les erreurs ldap, en effet, j’essayais de les comprendre en cherchant sur le net. Je ne les ai en effet pas traité, car je ne savais pas quoi faire.
J’ai en effet une archive avec un dossier /conf/ldap et 3 fichiers dedans (cd…ldif, dc…ldif et slapd.conf)
Je peux en faire quelque chose sans restaurer tout le backup ?
Si c’est un backup créé avec l’outil de backup de Yunohost, oui, il suffit de restaurer ce morceau du backup. Si c’est juste des fichiers à l’arrache en vrac récupéré manuellement, alors il faut recoller les morceaux à la main et c’est pas spécialement trivial (en supposant que ce soit les morceaux pertinents)
merci.
Je peux faire ça directement, sans rien enlever avant ?
Je pose la question parce que le script de backup me la pose : do you really want to restore an already installed system ?
cela me donne une erreur du même type que pour le regen_conf : Info : Preparing archive for restauration... Error: 'error during LDAP search operation with: base= 'ou=groups,dc=yunohost,dc=org', filter='(objectclass=groupOfNamesYnh)', attrs=['cn' 'members' 'permission'] and exception {'desc': 'No such object'}'
Merci, j’ai avancé un grand coup. ouf !
J’ai tout de même une erreur sur postgresql.
Et il faut apparement que je reconfigure tous les droits pour chaque appli et service.
mais au moins, j’ai accès à la webadmin et les users sont revenus.
Merci énormément de ta réactivité.
Je vois ce que je peux faire pour la suite.
Bon quand même, ce que j’ai restauré date de la dernière version de yunohost, où il y avait encore un user “admin”.
Il y a quelque chose à faire pour revenir proprement à la configuration de la nouvelle version ?
L’outil diagnostic ne me signale aucun problème. (en fait si, il me signale “Failed to get label for app toutesMesApplis ?”)
Et aussi : dans la webadmin, onglet applications : je les ai toutes, mais lorsque je les ouvre, cela mouline sans ne rien afficher.
De même, dans la gestion des groupes et autorisations, je n’ai accès à aucune application pour donner des droits par utilisateurs (la liste des permissions est vide).
Je ne peux donc pas accéder aux applications, vu que les users n’ont pas les droits d’accès, et je ne sais pas comment les remettre, vu ce que j’ai dit au dessus. (lorsque je me connecte via le sso aux différents users, je n’ai aucune application disponible)
Après redémarrage, les problèmes ci-dessus persistent, plus le fait que je n’ai même plus accès aux applis qui étaient jusque là restées accessibles à tous (aux visiteurs). La redirection de la racine vers le site web ne fonctionne plus, elle me demande à la place une connexion sso, mais aucune ne permet d’accéder au site.
Si je comprend bien, il faudrait que je restaure aussi postgreSQL, mais dans la sauvegarde d’où j’ai sorti le conf_ldap, il n’existe pas de conf_ssowat… (je l’ai dans une archive encore plus ancienne, sur un dd externe…)
Et par ailleurs, j’attendrai bien une réponse concernant la compatibilité entre l’ancienne et nouvelle version yunohost : Qu’est ce que je risque si je fais un restore --system avec une backup d’avril 2022 ?
Je viens donner des nouvelles :
J’ai restauré tout le system (sans les apps) de ma sauvegarde d’avril 2022.
Cela n’a pas résolu le problème de lien entre LDAP et les applis (les permissions n’existaient toujours pas).
J’ai donc désinstaller chaque appli une par une, puis ré-installer chaque appli à partir des dépôts (pour recréer les permissions comme il faut), puis supprimer cette appli vierge, et enfin restaurer la sauvegarde que j’en avais. Et là miracle, je retrouvais le bon comportement de LDAP et des permissions pour la plupart des applis. (une restauration directe à fonctionné pour les webApp)
Cela n’a pas pas fonctionné pour nextcloud (mais j’ai pu récupérer les fichiers dans /home/yunohost.app/nextcloud…) ni pour etherpad_mypads (et là je galère à récupérer, je ne sais pas où chercher dans le backup)
Reste une question : puis-je supprimer l’utilisateur admin_legacy via la webadmin ?
Et une autre : le diagnostic et le service de mises à jour me disent que tout est ok. Pourtant, je n’ai pas refait de mise à jour system depuis la restauration. C’est bizarre non ?