Problèmes d'accès à la base de données après la mise à niveau v3.5.2 -> v3.6.0.beta2

Soutien
1
  • v3.5.2 → v3.5.2
  • v3.6.0.beta2 → v3.6.0.beta2

Ce fil de discussion m’a mené ici : Upgrade failed. Database stopped. (multisite install)

J’ai maintenant des problèmes d’accès à la base de données :


2025-11-02 17:13:51.212 UTC [1975] postgres@c_discourse LOG:  le nom d'utilisateur fourni (postgres) et le nom d'utilisateur authentifié (discourse) ne correspondent pas 
2025-11-02 17:13:51.212 UTC [1975] postgres@c_discourse FATAL:  l'authentification par identité a échoué pour l'utilisateur « postgres » 
2025-11-02 17:13:51.212 UTC [1975] postgres@c_discourse DETAIL:  La connexion correspond à la ligne 89 de pg_hba.conf : « local   all             postgres       
                        peer »

postgres=# \l
Liste des bases de données
Nom      |  Propriétaire | Encodage | Fournisseur de locale |   Collation     |    Ctype     | Localisation ICU | Règles ICU |   Privilèges d'accès
-------------±---------±---------±----------------±------------±------------±-----------±----------±----------------------
b_discourse | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =Tc/postgres          +
|          |          |                 |             |             |            |           | postgres=CTc/postgres +
|          |          |                 |             |             |            |           | discourse=CTc/postgres
c_discourse | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =Tc/postgres          +
|          |          |                 |             |             |            |           | postgres=CTc/postgres +
|          |          |                 |             |             |            |           | discourse=CTc/postgres
discourse   | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =Tc/postgres          +
|          |          |                 |             |             |            |           | postgres=CTc/postgres +
|          |          |                 |             |             |            |           | discourse=CTc/postgres
postgres    | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           |
template0   | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =c/postgres           +
|          |          |                 |             |             |            |           | postgres=CTc/postgres
template1   | postgres | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =c/postgres           +
|          |          |                 |             |             |            |           | postgres=CTc/postgres
(6 lignes)

Le fichier multisite.yaml a changé entre ces versions.

Original :
secondsite:
adapter: postgresql
database: b_discourse
pool: 25
timeout: 5000
db_id: 2
host_names:
- ``forum.domain.com

Nouveau :
mlp:
adapter: postgresql
database: discourse_mlp
username: discourse_mlp
password: applejack
host: dbhost
pool: 5
timeout: 5000
host_names:
- discourse.nudderdomain.com
- discourse.nudderdomain.internal

Je n’ai jamais défini de mots de passe ou d’utilisateurs pour le multisite car ce n’était pas nécessaire ou indiqué dans le modèle original lors de leur configuration.

Initialement, je n’ai pas pu effectuer la mise à niveau car le multisite a échoué en raison de problèmes de permissions sur les deux sites listés dans multisite.yml. L’ajout de postgres comme utilisateur à multisite.yml n’a pas fonctionné pour la migration. Maintenant, je vois que j’aurais peut-être dû essayer discourse ?

Changer simplement le propriétaire en discourse résoudra-t-il le problème ? Dois-je ajouter des utilisateurs et des mots de passe pour le multisite afin qu’il corresponde à l’actuel ?

Quelle est la meilleure SOLUTION À LONG TERME ici ?

3

Votre publication est très difficile à lire, je l’ai donc mise en non répertoriée. Veuillez corriger la mise en forme et je pourrai la répertorier à nouveau.

2 « J'aime »
4

Malheureusement, j’ai fait de grands efforts pour le rendre aussi compréhensible/cohérent que possible.

Je sais ce que je veux dire. :wink:

EDIT : OK, j’ai compris. L’autre forum que j’utilise est un peu différent. J’utilise des triples apostrophes sur la ligne avant et après le bloc. Maintenant, je vois ce qui se passe. Celui-ci, le premier jeu d’apostrophes insère une fenêtre dans laquelle coller. Je ne comprenais pas pourquoi les triples apostrophes ne fonctionnaient pas et < /> ne me donnait pas ce que je voulais vraiment.

1 « J'aime »
6

Vous pouvez basculer vers l’éditeur markdown si vous avez besoin de faire beaucoup de choses en markdown dans votre publication.

Vos problèmes de mot de passe de base de données sont étranges. Avez-vous envisagé de passer à un nouveau serveur ? Ce serait peut-être plus rapide et plus facile que de lutter contre ce problème.

7

Avez-vous suivi ces instructions ? (Il ne semble pas ?)

C’est un pari assez sûr, mais assurez-vous d’avoir les éléments tels que décrits dans le sujet d’installation multisite.

Si vos sites fonctionnent maintenant, je vous encourage également à effectuer une installation multisite propre et à sauvegarder/restaurer les bases de données. Vous pouvez copier tout le reste comme décrit dans Déplacer un site Discourse vers un autre VPS avec rsync

8

Je me demandais pourquoi j’avais nommé mes bases de données b_discourse et c_discourse. Maintenant je sais pourquoi. :wink:

## Les plugins vont ici
## voir https://meta.discourse.org/t/19157 pour les détails
hooks:
  after_postgres:
     - exec: sudo -u postgres createdb b_discourse || exit 0
     - exec:
          stdin: |
            grant all privileges on database b_discourse to discourse;
          cmd: sudo -u postgres psql b_discourse
          raise_on_fail: false

     - exec: sudo -u postgres createdb c_discourse || exit 0
     - exec:
          stdin: |
            grant all privileges on database c_discourse to discourse;
          cmd: sudo -u postgres psql c_discourse
          raise_on_fail: false

     - exec: /bin/bash -c 'sudo -u postgres psql b_discourse <<'alter schema public owner to discourse;'
     - exec: /bin/bash -c 'sudo -u postgres psql b_discourse <<'create extension if not exists hstore;'
     - exec: /bin/bash -c 'sudo -u postgres psql b_discourse <<'create extension if not exists pg_trgm;'

Je ne comprends pas bien comment les privilèges sont accordés, alors je me posais des questions à ce sujet. (capture d’écran ci-dessus pour deux bases de données problématiques) :

image
image326×205 3.61 KB

9

Eh bien, bonnes nouvelles, mauvaises nouvelles. :frowning:
Maintenant, nous voulons :frowning:

2025-11-07 18:05:41.555 UTC [4724] discourse@b_discourse ERROR:  must be owner of extension vector
2025-11-07 18:05:41.555 UTC [4724] discourse@b_discourse STATEMENT:  ALTER EXTENSION vector UPDATE TO '0.8.0';
2025-11-07 18:05:41.752 UTC [4725] discourse@c_discourse ERROR:  must be owner of extension vector
2025-11-07 18:05:41.752 UTC [4725] discourse@c_discourse STATEMENT:  ALTER EXTENSION vector UPDATE TO '0.8.0';

au lieu de

ALTER EXTENSION vector UPDATE TO ‘0.7.0’;

Mais :

b_discourse=# ALTER EXTENSION vector UPDATE TO '0.8.0';
ERROR:  extension "vector" has no update path from version "0.7.4" to version "0.8.0"

J’ai hésité à simplement changer les propriétaires des bases de données, mais je suppose que ce sera la prochaine étape.

10

Existe-t-il un moyen de faire en sorte que ./launcher se connecte en tant qu’utilisateur postgres ? Cela semblerait résoudre tous mes problèmes de mise à niveau ici.

b_discourse=# select e.extname, u.usename 
             from pg_extension e 
             join pg_user u on e.extowner = u.usesysid;
 extname  |  usename  
----------+-----------
 plpgsql  | postgres
 hstore   | postgres
 pg_trgm  | postgres
 unaccent | discourse
 vector   | postgres
(5 rows)

Il semble y avoir des « problèmes » rien qu’en essayant de changer le propriétaire de l’extension. La première référence que j’ai trouvée date de 2017 et en 2022, ce n’est toujours pas implémenté.

11

J’ai utilisé apt pour installer la nouvelle extension et j’ai réussi. Mince alors. Maintenant, je vais faire des sauvegardes correctes et passer à Postgres 15. Mais pas ce soir. :wink:

Mon historique semble avoir été effacé, je ne peux donc pas vous dire exactement comment j’ai procédé, mais méfiez-vous. Il nécessite postgres 13 et tentera de le réinstaller.

PS : Il s’avère que j’avais activé les sauvegardes automatiques mais que j’avais oublié leur existence. Pas que je savais où elles se trouvaient. Je vais mettre en place un processus rsync pour les placer dans le répertoire où je fais également mes autres sauvegardes de serveur.

2 « J'aime »