La mise à niveau a échoué de manière spectaculaire

Les versions bêta, après les tests, sont finalement déployées en tant que version stable. Selon l’ampleur des changements apportés au cœur, des étapes spéciales peuvent être nécessaires via la ligne de commande.

Un VPS (serveur privé virtuel) est ce que vous avez payé pour que votre installation Discourse fonctionne. Sauf si vous utilisez votre PC personnel, ce qui est généralement une installation non prise en charge.

J’utilisais Upcloud comme fournisseur de VPS. J’utilise maintenant Contabo.

Toutes les bêtas, après suffisamment de tests, deviennent ce que les gens appellent des versions stables.

Dans le lien que Moin vous a fourni, vous avez :

  • Beta encore loin d’être testée (non recommandée pour la production)
  • Tests Passés (a passé de nombreux tests et est considérée comme prête pour la production) Branche recommandée par l’équipe pour la sécurité.
  • Stable si vous utilisez vos propres plugins personnalisés et thèmes/composants de thèmes. Idéal car les changements sont très lents. Mais vous êtes plus exposé aux risques de sécurité car les mises à jour sont lentes.

Les plans d’hébergement Discourse utilisent généralement la branche Tests-Passés pour garantir la meilleure sécurité et une bonne stabilité.

Ne le prenez pas mal. Mais comme vous n’êtes pas familier avec des termes comme VPS, cela suggère que vous êtes très nouveau dans ce domaine. Avez-vous installé Discourse vous-même ou avez-vous hérité d’un forum Discourse ? Nous avons tous été novices à un moment donné dans la configuration/maintenance de Discourse.

Ce n’est pas une opinion. C’est un fait si le logiciel que vous choisissez d’utiliser. Ce qui est à la hauteur de la plupart des logiciels open-source et même des logiciels propriétaires que vous utilisez. J’ai écrit vps. Android a capitalisé le V et le P.

Cependant, je comprends que vous devrez découvrir les choses par vous-même ; si vous ne voulez pas vraiment d’aide pour apprendre.

Bonne chance ! :clinking_beer_mugs::smiling_face_with_sunglasses::+1::sparkles:

Je remarque que @anon55243134 a supprimé presque tous ses messages. Je pense vraiment qu’il y a des leçons à tirer ici pour l’équipe et pour la maintenance des scripts de mise à jour et la communication autour de la mise à jour.

@anon55243134 est quelqu’un qui utilise une installation auto-hébergée de Discourse depuis des années et qui a maintenant une installation endommagée et non fonctionnelle - simplement en suivant les instructions pour la mise à niveau.

Si cela m’arrivait, je serais très contrarié et désemparé à l’idée de perdre potentiellement le contenu de mon forum. Ayant opté pour l’auto-hébergement, je pourrais ne pas être prêt ou capable de payer cher pour le faire réparer, si tant est que ce soit possible.

Je pense qu’il y a des avertissements et des vérifications insuffisants :

  • l’utilisateur a-t-il effectué une sauvegarde récente (pas un instantané des services d’hébergement !)
  • l’utilisateur l’a-t-il téléchargé
  • l’utilisateur est-il informé que la mise à jour via le web peut échouer et nécessiter une mise à jour en ligne de commande
  • l’utilisateur est-il invité à vérifier si son système d’exploitation est très ancien
  • l’utilisateur est-il informé que la migration vers un nouveau serveur à jour pourrait être la meilleure approche
  • l’utilisateur est-il averti que les mises à jour majeures (telles qu’une mise à jour de base de données) peuvent être périlleuses et que, s’il est inexpérimenté, attendre une semaine pourrait être une bonne idée, pour que les problèmes soient trouvés et corrigés

Plus inquiétant encore, dans l’un des messages supprimés, j’ai vu des échecs assez spectaculaires qui n’ont pas été interceptés et le script a continué :

cat: /shared/postgres_data/PG_VERSION: No such file or directory
...
E: Unable to locate package postgresql--pgvector
cp: cannot stat '/etc/postgresql//main/*': No such file or directory
sh: 1: /usr/lib/postgresql/bin/postgres: not found
...
Finding the real data directory for the source cluster      
could not get data directory using "/usr/lib/postgresql/bin/postgres" -D "/shared/postgres_data" -C data_directory: No such file or directory
Failure, exiting

Je n’ai pas vérifié les scripts, mais je m’attendrais à ce que l’inexistence de certains éléments soit une indication que des problèmes se profilent, et qu’il est temps d’arrêter.

5 « J'aime »

Désolé d’ouvrir une vieille boîte de Pandore ! Dans mon cas, j’ai mis à jour Ubuntu et Postgres, puis j’ai relancé la commande sudo ./launch rebuild app dans le répertoire /var/discourse, et tout semble s’être reconstruit correctement et le site est de nouveau en ligne.

Merci à tous ceux qui m’ont aidé dans cet effort. J’apprécie l’aide et je ne sais pas où je serais sans cette communauté.

Merci !

5 « J'aime »

Il y a certainement des opportunités ici pour améliorer Discourse. Ayant une instance Stable en fonctionnement depuis maintenant 7 à 8 ans, il y a toujours eu des moments où j’ai dû faire une mise à jour via la ligne de commande du serveur. Cela est même couvert dans la documentation avec une fréquence recommandée.

Cependant, la documentation n’est pas aussi facile d’accès qu’elle pourrait l’être. Le plugin de catégories de documents est certainement une amélioration. Mais toujours, à mon humble avis, pas aussi bon qu’il pourrait l’être.

Mes recommandations pour l’améliorer seraient d’avoir des liens directement dans l’interface web d’administration. Peut-être avec un lien (?) pour faire apparaître une pop-up avec quelques infos et un lien vers un sujet ici sur Meta avec des infos plus détaillées.

Avec le panneau de mise à jour, il serait utile d’avoir aussi des informations supplémentaires de la même manière, même avec Core & Docker, pour griser le bouton avec un message indiquant qu’il faut faire la mise à jour depuis la ligne de commande du serveur, avec un lien vers les notes de version de cette release spécifique, avec la première section détaillant les exigences, par exemple Docker Version X et Ubuntu LTS version X (ou distributions Linux officielles supportées équivalentes). Le sujet lié devrait selon moi aussi inclure des éléments pour copier-coller en ligne de commande du serveur.

Concernant les scripts, je ne sais pas combien cela pourrait être facile à faire. Mais faire en sorte que le script initial vérifie certaines exigences de base. Si une dépendance requise n’est pas présente, il doit sortir avec un message et peut-être un lien vers les informations de base nécessaires.

Le message d’échec de la mise à jour doit être plus intuitif. Bien qu’il indique de faire défiler vers le haut pour voir les erreurs précédentes, j’ai constaté qu’il y a des erreurs qui semblent communes et qui n’affectent pas la reconstruction. Exporter les erreurs clés dans un fichier journal qui a causé l’échec de la reconstruction serait bien meilleur. Toutefois, ces changements proposés nécessiteront probablement beaucoup de travail et de temps.

Avec Documentation > Self-Hosting, il faut vraiment un guide plus complet pour commencer, avec une introduction sur ce qu’il faut savoir avant de s’auto-héberger. Comme une bonne connaissance du système d’exploitation, comme Ubuntu LTS, avec quelques infos de base sur la maintenance et la mise à niveau de la distribution. Les meilleures pratiques pour les sauvegardes et des tutoriels directs. Ces informations pourraient même être ajoutées en tant que sujet avec des tags dans la catégorie Staff, avec des liens vers Meta.

Bloomberg, si je me souviens bien, a réalisé un bon sujet sur ce qui s’est passé dans ce sujet. Pour ma part, je m’excuse auprès de @anon55243134. Cependant, ils doivent aussi prendre en charge leur propre partie. Si vous cherchez du support, il faut être prêt à écouter ce qui est dit et fournir les informations demandées pour que tous ceux qui le peuvent puissent aider à guider vers des solutions possibles.

Nous pouvons tous avoir des idées ou des opinions sur comment le design, etc., pourrait être meilleur. Mais en attendant les changements que nous aimerions voir, nous devons accepter la situation actuelle.
Je sais à quel point il est déconcertant d’avoir des temps d’arrêt nuisibles. Il y a quelque temps, j’ai eu un problème avec le client pour lequel je suis bénévole en tant qu’administrateur. Je leur ai fait une pétition pendant plus d’un mois lorsque je ne pouvais pas reconstruire l’application à cause d’un serveur trop petit, et les instructions pour libérer de l’espace ici n’ont pas permis de résoudre le problème, ils ont ignoré mon conseil et finalement, comme je l’avais prévu, le serveur a subi une panne majeure. Ils ont fini par payer un membre ici pour réparer le problème, ce qui a impliqué le déploiement d’un nouveau serveur avec suffisamment d’espace. Le site a été en panne pendant plus de 2 semaines à cause de leur négligence. Plus tard, ils ne géraient pas la maintenance du serveur de messagerie et alors que le site n’était pas en panne, l’absence d’e-mails de notification a causé beaucoup de dégâts. Je pourrais en dire plus. Mais ce n’est pas un problème de Discourse. C’est un problème d’hébergement autonome.

Il y a longtemps, j’ai rencontré un problème de reconstruction causé par un fichier modèle. Le journal m’a donné suffisamment d’indices pour explorer une hypothèse selon laquelle en commentant le fichier modèle, cela aurait résolu mon problème. Quand je suis venu ici, j’ai posté ce que j’avais fait, ce qui a aidé à identifier le problème pour l’équipe.

De tous côtés, nous devons nous efforcer de nous améliorer. Prenez le temps de lire et d’écouter ceux qui ont de l’expérience et des compétences pour aider à résoudre les problèmes. C’est ainsi que j’ai acquis ma conscience des choses que je peux faire. Pour les domaines (particulièrement avec la complexité de Discourse) pour lesquels je ne suis pas expérimenté, je fais des recherches autant que possible, je demande de l’aide et je prends en compte les conseils de tous ceux ici qui maîtrisent davantage ce logiciel fantastique.

@anon55243134, si tu es prêt à donner sa chance aux choses, peut-être que nous pourrons tous t’aider à revenir en ligne. Il faut simplement éviter pendant ce processus de dévier vers « comment on pense que ça devrait être » et accepter pour le moment « comment c’est ». Une fois tout réparé, nous pourrons tirer des leçons et commencer une bonne discussion avec des recommandations pour améliorer les choses, et accepter, si l’équipe est réceptive (ce qui est généralement le cas), que cela prendra un certain temps, car d’autres projets sont en cours. De notre côté, nous pouvons travailler sur des idées, et ceux qui ont de véritables connaissances peuvent, s’ils ont du temps, travailler sur certaines des informations nécessaires pour les instructions, les meilleures pratiques, etc.

5 « J'aime »