Mise à niveau de la version du noyau requise lors de la mise à jour manuelle de Discourse

Soutien Installation
22

Si vous rsync /var/discourse entre des droplets dans le même centre de données, votre temps d’arrêt peut être minime et votre solution de repli n’est qu’une réversion DNS.

Le nouveau VPS n’a besoin que de docker et potentiellement de swap.

2 « J'aime »
23

Salut,

J’obtiens également cette erreur en exécutant Red Hat Enterprise Linux 7, avec le noyau 3.10.0. RHEL8 n’est pas beaucoup plus récent.

1 « J'aime »
24

Pareil ici, 3.1.0.beta1 fonctionne bien sur CentOS7 (3.10.0-1160.76.1.el7.x86_64)

Manifestement, les noyaux des distributions reçoivent beaucoup de backports. Vérifier la version du noyau vanilla de cette manière a également causé des problèmes dans d’autres projets. Existe-t-il un moyen de contourner cette vérification depuis la ligne de commande ?

—MISE À JOUR—
J’ai modifié le script de lancement pour contourner la vérification - plusieurs installations CentOS7 ont été mises à jour sans problème.

5 « J'aime »
25

Est-ce que ce problème va être éclairci ? Les exigences système ne nécessitent aucune version de noyau et Centos 7/RHEL 7 n’est pas encore en fin de vie (EOL). Docker ne nécessite pas non plus de noyau plus récent. Je ne pense pas que contourner manuellement la vérification soit la bonne solution à long terme.

2 « J'aime »
26

J’étais sur le point de mettre à niveau un ancien forum et j’ai rencontré la même erreur. Centos7 n’a pas encore atteint sa fin de vie, pourriez-vous trouver une solution alternative pour Ubuntu 14.04 ?

27

Si vous pensez que vous utilisez le noyau le plus récent de votre fournisseur d’OS (avec des correctifs rétroportés), vous pourriez vouloir essayer de contourner la vérification. Je le ferais ! Ceci est le problème où la vérification a été ajoutée. Je pense que vous pourriez simplement supprimer ou commenter la commande exit dans votre script ./launcher, dans ce paragraphe :

  # Au moins la version minimale
  if compare_version "${kernel_min_version}" "${test}"; then
    echo "ERREUR : La version du noyau ${test} n'est pas prise en charge, veuillez passer à au moins ${kernel_min_version}"
    exit 1
  fi

Si, par conséquent, la mise à niveau échoue toujours, vous devrez trouver un moyen d’exécuter votre Discourse sur un noyau plus récent.

(Il est tout à fait possible que ce conseil soit considéré comme hors sujet, mais je pense que ce qui s’est passé, c’est que nous avons une vérification de numéro de version plutôt qu’une vérification de fonctionnalité (urandom), et cette approche peut donner de faux positifs.)

4 « J'aime »
28

Je rencontre ce problème en ce moment et notre forum est en panne à cause de cela. Comment puis-je modifier le script du lanceur et commenter la vérification du noyau (au moins jusqu’à ce que Centos7 obtienne cette mise à jour ou que nous essayions de migrer le forum vers un autre serveur) ?

MISE À JOUR :
J’ai réussi (par essais et erreurs) à mettre à jour le lanceur et, au lieu de commenter le noyau, j’ai simplement défini une version inférieure comme exigence. Cela a bien fonctionné.

Ce n’est peut-être pas une bonne solution à long terme, mais notre société d’hébergement nous a déjà informés que Centos7 n’obtiendra pas la version 4.4 du noyau… quelqu’un peut-il expliquer ce que cela signifie en termes pratiques ?

1 « J'aime »
29

Il semble que Centos 7 recevra des mises à jour jusqu’à mi-2024.

À un moment donné - possiblement avant la fin de vie (EOL) - Discourse, qui évolue constamment, nécessitera quelque chose que Centos 7 n’a pas, et vous devrez mettre à jour votre système d’exploitation (ou migrer vers une nouvelle instance avec une version de système d’exploitation appropriée). Il semble que ce moment ne soit pas encore arrivé.

Comme toujours, avant d’essayer de mettre à jour Discourse, maintenant ou à l’avenir, faites une sauvegarde de vos forums et conservez une copie de sauvegarde sécurisée, ainsi qu’une copie sécurisée de votre fichier app.yml.

1 « J'aime »
30

Quel noyau exécutez-vous qui fonctionne avec la reconstruction que vous venez de faire ?

Si c’est quelque chose de inférieur à 4.4 et que cela fonctionne, alors il semble que @falco doive à nouveau réduire la version requise.

31

(Étant donné que les distributions auront des rétroportages de fonctionnalités et de correctifs des noyaux ultérieurs, une vérification de la version du noyau est un instrument très rudimentaire. Je comprends l’idée de réduire la charge de support, mais il y a aussi un effet inverse lorsque la vérification de sécurité a un faux positif. Et à mesure que Discourse gagne en popularité, ce problème s’aggrave. Il est beaucoup préférable de vérifier une fonctionnalité que de vérifier une version.)

2 « J'aime »
32

Notre système exécute les éléments suivants :

  • CentOS Linux release 7.9.2009 (Core)
  • Kernel 3.10.0-1160.88.1.el7.x86_64
1 « J'aime »
Change attachment size limit without rebuilding?
33

Mise à jour de ceci :
Bien que notre forum fonctionne maintenant, nous voyons cette erreur de plus en plus souvent :\n\u003e # Oups\n\u003e \n\u003e Le logiciel qui alimente ce forum de discussion a rencontré un problème inattendu. Nous nous excusons pour le désagrément.\n\u003e \n\u003e Des informations détaillées sur l’erreur ont été enregistrées et une notification automatique générée. Nous allons examiner cela.\n\u003e \n\u003e Aucune autre action n’est nécessaire. Cependant, si la condition d’erreur persiste, vous pouvez fournir des détails supplémentaires, y compris les étapes pour reproduire l’erreur, en publiant un sujet de discussion dans la catégorie de commentaires du site.\n\nCela peut-il être lié d’une manière ou d’une autre au problème des exigences minimales du noyau ? Cette « instabilité » (appelons-la ainsi) est devenue plus perceptible ces derniers jours/semaines. Elle semble aller et venir, parfois le forum fonctionne bien, et parfois non.\n\nEDIT : Laissez tomber, je pense que c’était lié à un problème postgresql (avoir trop de processus en cours associés à des images sans conteneur, ce qu’un nettoyage du lanceur a résolu).

1 « J'aime »
34

Je serais enclin à être d’accord avec cela. Pensez-vous que c’est une bonne idée @Falco ?

1 « J'aime »
35

Oui, les PR sont les bienvenus pour le détecter correctement.

2 « J'aime »
36

Salut Falco,

J’ai rencontré ce problème en essayant de mettre à jour Discourse de 3.1.0.beta2 à 3.1.0.beta4.

Cela semblait être une mise à niveau mineure, mais en raison de la vérification du noyau, la mise à jour a été beaucoup plus complexe sur CentOS7. Peut-être que la prochaine fois, un numéro de version différent pourrait mieux refléter l’impact relativement élevé des changements.

En lisant la discussion, je ne peux pas vraiment dire quelle vérification de fonctionnalité est réellement nécessaire, peut-être si vous pouvez élaborer là-dessus, quelqu’un sera en mesure de soumettre une PR.

1 « J'aime »
37

C’est dans le post de @Ed_S :

Sur Ruby 3.1, il y a une RuntimeException lors de l’appel de Random.urandom sur des plateformes où il n’est pas correctement implémenté, ce qui inclut les personnes exécutant Ubuntu 14.04 avec le noyau 3.13.

Kernel needs upgrading but that's not an option right now