J’ai installé à la maison un petit serveur HP Proliant Gen 10 qui tourne avec une Debian 10 et Yunohost en version 4.1.6 (4.1.4 pour yunohost-admin et moulinette ; 4.1.3 pour ssowat). J’ai installé l’OS et Yunohost sur un SSD et créer une une grappes de 4 disques en RAID 6 qui me sert de stockage pour nextcloud.
Lorsque je veux me connecter depuis mon PC client au portail yunohost, j’ai le message suivant :
Nom d’utilisateur ou mot de passe incorrect.
Je peux accéder en ssh à mon serveur mais j’ai souvent l’information suivante qui indique donc un problème d’accès au serveur ldap :
ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)
J’ai bien trouvé un toto sur comment reconfigurer le serveur ldap ; mais je redoute de me lancer dans une telle opération qui me semble au delà de mes modestes capacités…
Je précise que je rencontre simultanément un problème de répertoire /var toujours plein à 100 %. J’ai donc créé un autre message sur le forum pour ce second problème ([Résolu] Répertoire /var plein à 100 %).
Merci de m’avoir lu jusqu’au bout.
Longue vie à Yunohost
Edit : il me semble que mes soucis sont apparus après un malencontreux changement de groupe et propriétaire du répertoire racine. En effet, après avoir chargé des fichiers sur mon nextcloud à l’aide de FileZilla, j’ai voulu changer le groupe et propriétaire de root:root à nextcloud:nexcloud… mais une erreur d’inattention en ligne de commande m’a fait faire cette manipulation sur le répertoire racine en entier au lieu du seul répertoire de stockage de mon nextcloud ! Une fois l’erreur constatée, j’ai fait marche arrière en remettant root:root sur mon répertoire racine. Peut être une piste…?
Uuuuh, tu veux dire /, la racine du système ? C’etait une commande recursive (-R) ou bien juste sur le dossier en lui meme ?
Sinon pour le soucis de ldap je commencerais par vérifier que le service tourne avec systemctl status slapd, tenter de le redémarrer avec systemctl restart slapd (meme si systemctl dis qu’il tourne deja) et voir si ca aide
Pour ma boulette sur la racine du système /, je me souviens plus vraiment mais tous mes répertoires, sous-répertoires et fichiers ont bien l’air d’être en root:root (même ceux dans mon espace de stockage nextcloud : /media/stockage/nextcloud_data/nextcloud/data) …
systemctl status slapd` me renvoie
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access
Loaded: loaded (/etc/init.d/slapd; generated)
Drop-In: /etc/systemd/system/slapd.service.d
└─ynh-override.conf
Active: activating (auto-restart) (Result: exit-code) since Mon 2021-02-08 10
Docs: man:systemd-sysv-generator(8)
Process: 10017 ExecStart=/etc/init.d/slapd start (code=exited, status=1/FAILUR
Feb 08 10:53:20 mondomaine.tld slapd[10017]: Starting OpenLDAP: slapd failed!
Feb 08 10:53:20 mondomaine.tld systemd[1]: slapd.service: Control process exited,
Feb 08 10:53:20 mondomaine.tld systemd[1]: slapd.service: Failed with result 'exit
Feb 08 10:53:20 mondomaine.tld systemd[1]: Failed to start LSB: OpenLDAP standalon
systemctl restart slapd me renvoie :
Job for slapd.service failed because the control process exited with error code.
See “systemctl status slapd.service” and “journalctl -xe” for details.
Merci de cette commande que je ne connaissais pas ; elle me renvoie les entrées en ligne de commande depuis une ligne numérotée 83 (jusqu’à une ligne 582) mais qui semble bien plus récente que la période de ma boulette… Donc pas de trace de mes exploits d’il y a plusieurs semaines…
Edit : je viens de me rendre compte que l’historique n’est pas le même entre celui de mon PC client en ssh et celui directement du serveur. C’est logique… J’étudie celui du serveur en créant une sortie de la commande dans un fichier history _w history_08-02-2021dans lequel je retrouve bien une commande chown -R root:root / mais pas celle initiale avec nextcloud:nextcloud qui devrait se situer avant…
Mouarf ben clairement c’est pas fifou … c’est un peu l’équivalent d’un “rm -rf /” même si moins grave car pas de perte de données … mais typiquement les chown -R ca remplace toutes les permission et y’a pas vraiment de possibilité de “défaire” le truc facilement … dans le système de fichier y’a pleins de fichier/dossier avec des permissions spécifiques et si elles sont foutues en l’air c’est très compliqué de tout réparer …
re Glups
j’ai bien une image (Clonezilla) de mon ssd sur lequel est installé ma Debian et Yunohost.
mais elle à deux mois et je crains de devoir refaire ma grappe de 4 disques en raid 6 ; j’en avais bavé pour la construire avec mes petits moyens
Edit : pour la la commande history | less, c’est bizarre la liste commence à la ligne 13 mais j’ai bien retrouver la funeste chown -R root:root /
Mon nextcloud n’a que deux utilisateurs et je vais surement pouvoir faire des sauvegarde des données. Restons optimiste. En tout cas un grand merci à gmilad et Aleks !
Ce qui ne me tue pas me rend plus fort… enfin faut le dire vite…
Bonsoir,
Un tardif mais sincère merci à ljf pour sa proposition dont je comprends la logique. Après un essai infructueux en utilisant la restauration d’une image clonezilla de mon ssd sur lequel était installé Debian et Yunohost (image qui était antérieure à la création de mon Raid 6), j’ai entrepris de tout réinstaller. Ma principale application était un nextcloud avec 2 utilisateurs dont j’ai sauvegardé les données. Je commence à prendre scrupuleusement en note toute la procédure d’installation de Yunohost et de mon raid (j’hésite encore entre un 5, un 6 ou un 10) en ligne de commande depuis mon PC client (pas peu fière de moi ). J 'apprends ainsi et j’aime ça…
Merci à tous et longue vie à Yunohost !
). J 'apprends ainsi et j’aime ça…