je poste ici plutôt que dans support car j’essaye de piger après-coup sans avoir pensé à garder les logs. Hier soir, j’ai tenté de faire un peu de ménage sur mon installation en déplaçant plusieurs applis d’un domaine vers un autre (dans le but de n’en garder qu’un des deux).
Sauf que, pour quelques unes d’entre elles, il semble qu’il y ait eu un énorme viandage : ça s’est terminé par un message disant qu’elle n’avait pas été trouvée dans la liste des applications installées, et évidemment toutes les données qui allaient avec complètement virées.
Pour le coup, il y a eu relativement peu de dégâts (j’ai perdu quelques pads, mais rien qui ne soit refaisable). Mais à la réflexion, que ce genre de trucs soit susceptibles de se passer a tendance à me faire un peu peur pour plus tard. Donc j’aimerais savoir, si parmi les devs qui fréquentent ce lieu, quelqu’un sait sous quelles conditions le message d’erreur sus-mentionné est susceptible d’apparaître.
Sur le coup, j’ai connement d’abord pensé à réinstaller tout avant de me dire que garder les logs auraient pu être utile, donc, avec toutes les opérations effectués entre temps, le panneau « journaux » de la web admin ne fournit plus que des opérations plus récentes
Je suis sur une 4.1.8, sur laquelle j’ai fait quelques bidouilles, mais a priori rien qui concernait les domaines/applis en question, donc je ne vois pas trop ce qui a causé le souci à la base, d’autant que j’ai fait d’autres déplacements avant ça et depuis.
S’il y a moyen de remonter plus haut dans les logs de yunohost avec la ligne de commande, signalez-moi comment et j’irai chercher ça, ça pourra sans doute aider.
Sans le nom des apps qui ont planté, ni les logs, ni les quelques modifs que tu as faites sur ton serveur… disons qu’on ne pourra vraiment pas t’aider, et on ne pourra pas comprendre ce qu’il se passe.
Oui. Les logs sont dans /var/log/yunohost/categories/operation/ et probablement que ls /var/log/yunohost/categories/operation/20210504*change_url* devrait te lister tout ça.
Pour les partager, tu peux utiliser la commande yunohost log display <CHEMIN> --share
Je me doute bien que ça n’aide pas, oui, désolé ^^’ Mais grâce à ton message, j’ai pu retrouver les logs, donc ça va pouvoir avancer.
Donc, des précisions sur mes modifs. J’ai jusque là trois domaines dont, outre mon domaine principal :
– Un domaine secondaire sur lequel je n’ai rien modifié de particulier côté conf’, mais que je n’ai pas déclaré côté DNS, j’y accède parce que j’ai la bonne adresse IP dans le /etc/hosts de mon serveur principal.
– Un autre domaine secondaire qui lui est bien déclaré côté DNS, mais dont j’ai modifié le fichier /etc/nginx/domain.conf pour faire en sorte que toute requête qui arrive dessus soit redirigée vers le domaine principal (son /etc/nginx.domain.d n’est pas lu par nginx).
L’idée est d’avoir quelque part où installer des trucs pour les tester, sans que ce soit accessible publiquement. J’ai décidé hier de déplacer les applis du domaine secondaire sans DNS vers le domaine secondaire avec DNS, ce qui me semble être préférable à la réflexion (je compte donc garder celui-ci, et virer celui qui n’est pas déclaré). Mais visiblement, je ne sais plus exactement pourquoi (je crois que je voulais remettre en l’état le temps de tester autre chose), j’ai également fait la manip’ inverse hier soir, et c’est apparemment celle-ci qui a foiré.
À vue de nez, ça concernait Etherpad et Converse (Element aussi a foiré, mais un foirage « normal », qui ne s’est pas soldé par une disparition ninja ; ceci dit du coup je l’ai désinstallé et réinstallé à la main à la place. Je peux filer les logs de celui-ci si besoin)
J’peux partager les logs de Converse aussi d’ailleurs, mais voici déjà ceux d’Etherpad, parce que j’ai du coup l’opération dans les deux sens. Je mets tous les logs concernés <lien autodétruit> pour le moment.
S’il te plaît oui, car le log de 22:03 mentionne clairement Converse comme étant la fautive.
2021-05-04 22:03:12,933: WARNING - mai 04 22:03:12 nginx[1222]: nginx: [emerg] open() "/etc/nginx/conf.d/DOMAINE.d/converse.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/DOMAINE.conf:15
Il est fort probable que YunoHost ayant détecté une modification manuelle du fichier, le système n’ait pas réussi à restaurer le fichier après une erreur lors du changement d’URL de Converse. Mais là je parle au pifomètre sans le log.
2021-05-04 22:00:31,840: DEBUG - 3205 DEBUG - mai 04 22:00:31 nginx[29583]: nginx: [emerg] open() "/etc/nginx/conf.d/DOMAINE.d/synapse.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/DOMAINE.d/synapse.conf:1
Je pressens un moment formulaire A38…
As-tu les logs pour Synapse?
Est-ce que le domaine que je censure était celui que tu as bidouillé? Parce que, clairement si, NGINX essayait de le lire.
C’est bien ce domaine-là, mais si nginx essayait de lire ce fichier, c’est que j’avais un lien symbolique qui pointait dessus depuis un autre répertoire, du coup, quand j’ai viré synapse (proprement) du domaine de test, le lien ne pointait plus vers rien. Je l’ai effacé en réinstallant proprement synapse au bon endroit, mais avec les émotions d’hier, j’avais complètement zappé ça.
C’est sans doute ce lien symbolique foireux qui est l’origine de toute la cascade qui a suivi, donc ^^’
Bon, on va dire que du coup, la bonne nouvelle, c’est que vu que je n’ai pas l’intention de refaire ce genre de conneries, ça ne risque pas de se reproduire…
J’autodétruis l’archive des logs. Merci à toi (et désolé) pour le temps que tu y as passé.
Ceci dit, je réitère ma question initiale : qu’est-ce qui fait, concrètement, qu’il se trouve à « ne pas trouver X parmi les applications installées » ? C’est le fait qu’il y ait une erreur nginx au moment de restaurer le backup ?
NGINX est un composant important de YunoHost. S’il renvoit des erreurs que le système ne sait pas corriger, alors tout plante. Dans ton cas, tu avais altéré un autre fichier de configuration pour renvoyer vers un fichier inexistant, ce qui faisait planter NGINX systématiquement.
Lors de l’opération change_url, YunoHost réalise une sauvegarde et fait les modifications adéquates… jusqu’au rechargement de NGINX, qui renvoit cette erreur. Face à cette erreur, YunoHost annule l’opération en supprimant l’app et en tentant de restaurer la sauvegarde. Comme le problème vient d’un fichier n’émanant pas de l’app en question, l’erreur de NGINX demeure et la restauration échoue. L’app reste donc supprimée.
La conclusion:
YunoHost est assez arrangeant concernant les modifications manuelles en général, mais il faut absolument que tu les gardes en tête et que tu surveilles les services que tu bidouilles.
Tu aurais peut-être dû t’arrêter au premier échec et investiguer les fichiers journaux pour voir ce qu’il se passait.
Tu vas pouvoir restaurer les sauvegardes et réessayer si tu corriges le souci avec NGINX. Tu peux utiliser la commande yunohost tools regen-conf nginx pour écraser les modifs. (Peut-être faut-il que tu enlèves les liens symboliques au préalable).
je souscris volontiers au fait que j’ai eu de très mauvais réflexes, et que YunoHost a plutôt super bien géré le truc
C’est normalement tout réglé de mon côté (j’ai passé la soirée après ça réinstaller ce qui devait l’être, mon système est maintenant à peu près dans l’état désiré), j’ai posté surtout pour piger pour ne pas refaire les mêmes bêtises à l’avenir.
En tout cas, j’ai redémarré plusieurs fois nginx en cours de route pendant les réinstallations, et il n’y a eu aucun nouvel incident à déplorer.
Par contre, tu me dis que les backups sont toujours là et que, maintenant que les soucis que j’avais causé sont réglés, je peux les restaurer ? Ça peut m’intéresser quand même pour Etherpad (la seule appli concernée qui avait des données stockées).
Je remarque effectivement que la commande yunohost a un paramètre backup (j’ai beaucoup trop tendance à tout faire par la webadmin, alors que d’hab je préfère la ligne de commande… il va falloir que je creuse beaucoup plus cette commande yunohost ^^).
J’ai réinstallé etherpad entre temps (mais pas encore ouvert de nouveau pad dessus) : est-ce qu’il vaut mieux que je supprime la version actuelle avant de tenter une restauration, ou que je la garde en l’état ?
En tout cas, merci beaucoup, et encore une fois bravo pour tout le taff effectué, votre système est trèèèès cool
Si les sauvegardes ont bien été faites, elles devraient être listées dans la webadmin. Mais tu peux passer par la ligne de commande sans soucis aussi. Au pifomètre je dirais qu’on a 95% des commandes accessibles dans la webadmin (en taux d’utilisation ; il y a le regen-conf et les yunohost settings de mémoire qui n’y sont pas).
Il va falloir que tu supprimes Etherpad au préalable, car la sauvegarde essaiera de se restaurer au même emplacement.
Je précise que j’ai vérifié le script change_url du paquet etherpad, et il y a bien la mécanique pour sauvegarder avant de faire des changements. Donc, tu devrais pouvoir restaurer depuis la webadmin “Sauvegarde” > “Archives locales” > “ethertpad-pre-change-url” ou un truc du genre
Oui, entre temps, j’ai remarqué ça dans la webadmin aussi, j’étais complètement passé à côté jusque là. Je suis vraiment totalement à côté de la plaque, dans cette affaire ><
Ceci dit : la restauration s’est bien passée, mais ça ne m’a pas rendu les pads perdus. C’est très probablement encore ma faute (je suppose que j’avais dû écraser la sauvegarde en faisant une autre fausse manip’ au moment de la réinstallation), et de toute façon, ça n’est pas spécialement grave (je n’ai rien perdu qui ne soit pas raisonnablement refaisable).
Alors, j’ai déplacé Etherpad après la restauration : ça m’a créé un backup qui est bien appelé etherpad-mypads-pre-upgrade2, alors que le backup de Converse datant du soir du crash, par exemple, s’appelle converse-pre-upgrade1, donc ça tendrait à dire que j’ai dû restaurer depuis le backup datant de juste avant l’incident et pas un hypothétique truc fait plus tard dans la soirée, sinon j’imagine qu’on en serait à 3.
En revanche, le backup etherpad-mypads-pre-upgrade1 que j’avais utilisé pour restaurer n’est pour sa part manifestement plus là (je ne sais pas à quel moment il a été supprimé).
Etherpad utilise bien une base de données, MySQL pour être précis, et j’ai bien un fichier dump dans le backup2. J’ai regardé un peu ce qu’il contient, mais la façon dont Etherpad utilise la base de données semble assez étrange (une seule table “store”, contenant deux colonnes “key” et “value”, qui contiennent apparemment tout et n’importe quoi…), et à vue de nez, je ne vois rien dedans (pas plus que dans la base de donnée actuellement en activité) qui corresponde à mes anciens pads.
Là encore, j’aurais sans doute dû récupérer le backup1 pour le tester avant, mais bon, si j’avais deux sous de présence d’esprit ça se saurait ^^’
Je vais partir du principe que c’est mort pour mes anciens pads, mais si vous voulez que je profite d’avoir une nouvelle install pour faire quelques tests, n’hésite pas à le demander, tant qu’à faire, si ma mésaventure peut s’avérer utile, ce ne sera pas plus mal ^^
Oui les données d’etherpad sont dans la table “store” de la bdd mysql. SI il n’y a aucune données dans aucun des .sql sauvegardé, tu peux malheureusement considérer que c’est mort
