QGIS » ASGARD

Mél de Dominique Choquet du 27 août 2020

Notre responsable SIDSIC vient de vérifier tout ce que tu as indiqué. Pas d'évolution sur la possibilité de créer un nouveau schéma.
En fait, il n'a pas changé le mot de passe initial. C'est le même dans les SQL. Cela a t-il une incidence ?
Faut-il redémarrer le serveur pour faire prendre en compte la nouvelle extension ?
As-tu une autre piste ?

Non, il ne devrait pas y avoir besoin de redémarrer le serveur.

Mais c'est très étrange.

Est-ce que tu peux déjà me dire ce que te retourne la requête suivante :

SELECT oid, rolname FROM pg_roles WHERE rolname = 'g_admin' ;

Je veux bien aussi que tu me fasses un dump SQL de ton schema z_asgard_admin, si c'est possible.

Mél de Dominique Choquet du 27 août 2020

Ceci :

"oid" "rolname"
"1776015" "g_admin"

Merci ! Jusque-là tout va bien. Je veux bien le dump SQL de z_asgard_admin pour essayer d'y voir plus clair.

Échanges non reproduits : il s'avère que la transmission des dumps n'est pas possible, car les schémas rattachés à une extension ne sont pas sauvegardés par pg_dump.

Je viens de reproduire exactement ton erreur en installant la 0.7.1 depuis la 0.6.2 avec un mot de passe de contrôle différent dans le fichier asgard--0.6.2--0.7.1.sql de celui de asgard--0.6.2.sql.

Je lance :

CREATE SCHEMA r_bdforet AUTHORIZATION g_admin ;

J'ai en retour :

@NOTICE: [table de gestion] Mise à jour du bloc pour le schéma r_bdforet (r).
NOTICE: [table de gestion] ANOMALIE. Schéma r_bdforet. L'OID actuellement renseigné pour le producteur est invalide. Poursuite avec l'OID du propriétaire courant du schéma.

ERREUR : ERREUR: ECS0. Opération annulée. Anomalie lors de l'enregistrement dans la table de gestion.
DETAIL: TA0. Opération annulée. Anomalie lors de la traduction physique des modifications de la table de gestion. / une valeur NULL viole la contrainte NOT NULL de la colonne « producteur » / La ligne en échec contient (r, f, null, null, null, null, r_bdforet, null, t, null, null, null, null, null, null, {MANUEL,NULL,"CLEAN producteur"})
HINT:
CONTEXT: fonction PL/pgsql z_asgard_admin.asgard_on_create_schema(), ligne 76 à RAISE@

Si je refais exactement la même chose avec les mêmes mots de passe, ça fonctionne.

Il faudrait vérifier que le mot de passe qui apparaît à la ligne 766 du fichier asgard--0.6.2--0.7.1.sql est bien identique à celui de l'en-tête. Ou alors c'est dans asgard--0.6.2 qu'il s'était passé quelque chose...

Mél de Dominique Choquet du 28 août 2020

Désolé pour tous ces dérangements car effectivement il ne s'agissait que d'une mauvaise recopie du mot de passe :
x7-A;#Rzo pour x7-A;#rzo
Une majuscule malencontreuse ...
J'ai donc pu créer un nouveau schéma sans difficulté.
Merci encore pour ton aide.

Comme je te l'indiquais dans le message initial, certains schémas ont pour propriétaire ADL et certaines fonctions d'ASGARD ne fonctionnent pas en étant connecté comme g_admin.
J'essaie d'utiliser la fonction prévue dans les annexes pour changer le propriétaire :
SELECT z_asgard.asgard_admin_proprietaire('ref_bdforet', 'g_admin') ;

En retour, j'ai le message :
ERROR: FAP1. Le schéma ref_bdforet n'existe pas ou n'est pas accessible. CONTEXT: PL/pgSQL function z_asgard.asgard_admin_proprietaire(text,text,boolean) line 27 at RAISE État SQL : P0001

Le schéma existe bien et la table qu'il contient a le même propriétaire : ADL
As-tu une idée ?

Pas de souci pour le mot de passe. Je me rends compte que c'était une mauvaise idée de ma part de vous le faire modifier. Trop de risques d'oubli lors des mises à jour et en plus ce n'est pas trivial à corriger derrière. Contente de savoir que tout est rentré dans l'ordre.

Pour changer le propriétaire, tu peux juste faire ALTER SCHEMA ... OWNER TO .... Asgard appellera lui-même la fonction que tu cites.

Et je pense qu'il est normal que ça ne fonctionne pas, quelle que soit la ommande utilisée. adl est un super-utilisateur, g_admin n'en est pas membre et, en l'occurrence, il n'a probablement même pas accès au schéma (privilège USAGE), raison pour laquelle Asgard te renvoie cette erreur "FAP1. Le schéma ref_bdforet n'existe pas ou n'est pas accessible.". Même s'il avait accès au schéma, il faut être propriétaire d'un schéma pour changer le propriétaire, donc c'est dans tous les cas impossible pour g_admin.

La bonne méthode est de te connecter avec le rôle adl et de lancer ALTER SCHEMA ref_bdforet OWNER TO g_admin ou modifier le producteur dans la vue gestion_schema_usr pour tous les schémas concernés.

Mél de Dominique Choquet du 28 août 2020

J'avais bien pensé à me connecter avec le rôle ADL mais j'espérais qu'ASGARD puisse le faire depuis le rôle g_admin car il y a plusieurs schémas à changer de propriétaire. Je vais tout faire d'un coup pour ne pas avoir à y revenir.

Merci encore pour ton aide et le temps que tu m'as accordé !

De rien !

Et, oui, ASGARD ne permet pas d'outrepasser les règles de PostgreSQL en matière de droits.

Ton cas montre bien pourquoi il est important de ne pas conserver de schémas avec un propriétaire super-utilisateur, car g_admin n'a pas (et ne peut pas avoir) la main dessus, alors qu'il l'aura automatiquement pour n'importe quel autre propriétaire. C'est une très bonne chose que tu sois justement en train d'y remédier !

Ok, cette méthode marche aussi, même si déplacer les objets un à un n'est vraiment pas la panacée.

Mais l'erreur sur que tu rencontres avec ALTER SCHEMA OWNER TO n'est absolument pas normale et je me demande si ce n'est pas une conséquence à retardement de manipulations que tu aurais faites alors que les mots de passe étaient décorrélés. Je crains qu'il n'y ait des anomalies dans ta table de gestion.

Peux-tu m'envoyer le résultat des quatre requêtes suivantes :

SELECT oid, rolname FROM pg_roles ;

SELECT DISTINCT oid_producteur, producteur, creation FROM z_asgard_admin.gestion_schema ;

SELECT oid, nspname FROM pg_namespace ;

SELECT DISTINCT oid_schema, nom_schema, creation FROM z_asgard_admin.gestion_schema ;

Dans un second message

En plus de mon message précédent, juste pour confirmer : as-tu exécuté le script que je t'ai envoyé ? si tu ne l'as pas fait, fais-le, par précaution.

Je crois d'ailleurs que je vais l'envoyer à tous les utilisateurs d'Asgard et leur dire de ne plus jamais toucher au mot de passe de contrôle après ça. C'était censé être une garantie sur l'intégrité des données, mais c'est complètement contre-productif en cas d'oubli de mise en cohérence des mots de passe. Vous êtes déjà deux à avoir eu des problèmes à cause de ça.

Merci !

Je regarde ça et reviens vers toi.

Il est normal que la requête "a_executer.sql" ne te dise rien de spécial. Elle ne fait que remplacer le code de toutes les fonctions où apparaît le mot de passe, pour garantir qu'il soit identique partout.

As-tu encore un schéma dont adl est propriétaire pour retenter le changement de propriétaire suite au lancement de la requête (en étant connecté avec adl, bien sûr) ? Il est possible que ça ait résolu le problème.

Mél de Dominique Choquet du 28 août 2020

Effectivement, maintenant, je peux changer le propriétaire d'un schéma. Toutes les tables ont aussi pour propriétaire g_admin.
Impeccable !
C'est beaucoup plus rapide que la méthode manuelle que j'avais commencé à mettre en oeuvre.;-)