ASGARD

asgard_diagnostic repère tous les écarts vis-à-vis des droits standards^[1] prévus par ASGARD. Appliquer cette fonction est le premier réflexe à avoir lorsque des utilisateurs n’accèdent pas à des objets qu’ils devraient pouvoir utiliser (ou inversement).

En une seule commande, asgard_initialise_all_schemas permet de revenir aux droits standards d’ASGARD pour l’ensemble des schémas référencés^[2] : les producteurs^[3], éditeurs^[4] et lecteurs^[5] retrouvent leurs droits normaux, ceux des autres rôles sont révoqués. Pour un service qui n’aurait pas (volontairement) personnalisé les droits au-delà de la désignation des producteurs, éditeurs et lecteurs, c’est la meilleure manière de nettoyer sa base.

asgard_initialise_schema et asgard_initialise_obj suivent le même principe, mais respectivement à l’échelle d’un schéma et d’un objet contenu dans un schéma. Elles permettent de procéder à des corrections plus localisées.

La restauration d'une sauvegarde complète de la base de données est la seule méthode qui permette de reconstituer intégralement le contenu de la table de gestion^[6] lorsque celui-ci est accidentellement perdu, par exemple suite à la désactivation temporaire de l'extension ASGARD sur la base.

Si cette approche n'est pas envisageable, les fonctions utilitaires suivantes permettent de recalculer une partie des informations. Certaines lui échappent irrémédiablement, en particulier tous les enregistrements correspondant à des schémas inactifs^[7] hors nomenclature nationale, ou les valeurs des champs de classement (niv1[10], niv1_abr[11], niv2[12], niv2_abr[13]) pour les schémas actifs^[8] qui ne font pas partie de la nomenclature nationale^[9].

• Comme lors de l'initialisation de la table de gestion à la première activation d'ASGARD, la fonction asgard_initialisation_gestion_schema peut être utilisée pour re-référencer tous les schémas de la base, en spécifiant si nécessaire une liste de schémas à exclure. Les champs bloc[15], nom_schema[16], creation[17] et producteur[18] sont alors recalculés automatiquement lors du référencement (ainsi que les champs techniques oid_schema et oid_producteur, qui ne sont pas exposés par la vue utilisateur^[14]).

• asgard_import_nomenclature permet de réimporter dans la table de gestion tout ou partie de la nomenclature nationale des schémas sous forme de schémas inactifs et de restaurer les valeurs des champs nomenclature[19], niv1, niv1_abr, niv2, niv2_abr pour les schémas actifs portant le nom d'un schéma de la nomenclature.

• Les fonctions de recherche asgard_cherche_lecteur et asgard_cherche_editeur examinent les droits dont disposent les rôles sur un schéma pour tenter de retrouver le lecteur et l'éditeur de ce schéma, s'il en avait. Les noms de rôles ainsi obtenus peuvent ensuite être redéclarés dans les champs editeur[20] et lecteur[21] de la table de gestion. La méthode standard, recommandée dans le cas général, aura pour effet d'aligner les privilèges des rôles ainsi désignés sur les privilèges prévus par ASGARD pour les fonctions de lecteur et d'éditeur.

  1

  2

  UPDATE z_asgard.gestion_schema_usr

  3

      SET lecteur = z_asgard.asgard_cherche_lecteur(nom_schema),

  4

          editeur = z_asgard.asgard_cherche_editeur(nom_schema) ;

  UPDATE z_asgard.gestion_schema_usr
      SET lecteur = z_asgard.asgard_cherche_lecteur(nom_schema),
          editeur = z_asgard.asgard_cherche_editeur(nom_schema) ;

  Dans le cas spécifique d'une base où les droits ont fait l'objet d'une personnalisation^[1] significative et légitime par rapport au standard d'ASGARD, on pourra recourir à la fonction asgard_restaure_editeurs_lecteurs pour la préserver. Cette fonction modifie les valeurs des champs lecteur et editeur en s'appuyant sur les fonctions de recherche susmentionnées sans altérer en aucune façon les droits effectifs.

Les mécanismes d'ASGARD produisent des erreurs reconnaissables à leurs messages qui commencent par un code composé de deux à quatre lettres majuscules, identifiant la fonction qui a généré l'erreur, suivies d'un chiffre et d'un point. Par exemple « FLG1. Le rôle role_inconnu n'existe pas. » est le message d'erreur renvoyé par la fonction asgard_all_login_grant_role lorsque le rôle fourni en argument n'existe pas. Ces erreurs bloquent des actions interdites ou impossibles du point de vue d'ASGARD ou de PostgreSQL, avec des messages aussi explicites que possible, qui doivent normalement permettre à l'utilisateur de comprendre pourquoi sa commande a été rejetée et de prendre les mesures nécessaires.

Pour faciliter l'analyse des erreurs, beaucoup de fonctions d'ASGARD interceptent les erreurs provoquées par l'exécution de leurs commandes. Elles restituent le message de l'erreur remontée en ajoutant au début leur propre combinaison de lettres majuscules suivie du chiffre « 0 » et, au lieu d'un point, du caractère « > ». Les erreurs ainsi interceptées peuvent avoir été générées :

• Par la fonction elle-même, auquel cas le caractère « > » sera suivi par un code dont la combinaison de lettres majuscules sera identique à celle du premier code, mais avec un chiffre différent de zéro, un point, puis le descriptif de l'erreur.

  1

  2

  ERREUR:  FIS0 > FIS1. Opération interdite. Le schéma public est un schéma système.

  ERREUR:  FIS0 > FIS1. Opération interdite. Le schéma public est un schéma système.

• Par une autre fonction d'ASGARD appelée par la fonction elle-même ou par un déclencheur activé par les actions effectuées par la fonction. Dans ce cas, le caractère « > » sera suivi d'un code dont la combinaison de lettres majuscules est différente de celle de la première fonction. Il est possible d'avoir plusieurs codes « 0 » successifs avant le descriptif de l'erreur. Par exemple :

  1

  2

  ERREUR: ECS0 > TA0 > TA3. Opération interdite (schéma c_bibliotheque). Le producteur/propriétaire du schéma ne doit pas être un rôle de connexion.

  ERREUR: ECS0 > TA0 > TA3. Opération interdite (schéma c_bibliotheque). Le producteur/propriétaire du schéma ne doit pas être un rôle de connexion.

• Directement par PostgreSQL. Dans ce cas, le caractère « > » n'est pas suivi d'un code, uniquement du descriptif de l'erreur PostgreSQL.

Du fait de l'exécution en chaîne de plusieurs fonctions, il peut être difficile d'interpréter la description de l'erreur au vu de la commande initiale. C'est particulièrement vrai dans le troisième cas, d'une part parce que les messages de PostgreSQL ne tiennent naturellement pas compte du contexte d'ASGARD, d'autre part parce que la plupart des fonctions d'ASGARD intègrent des contrôles qui leur permettent de substituer leurs propres erreurs, avec des messages plus parlants, aux erreurs natives de PostgreSQL les plus susceptibles d'apparaître. Les erreurs PostgreSQL résiduelles correspondent donc à des cas a priori mal maîtrisés par ASGARD. Elles sont plus susceptibles d'être révélatrices de dysfonctionnements.

La survenue d'erreurs incompréhensibles justifie pleinement de faire appel à l'assistance.

De telles erreurs peuvent notamment survenir dans les cas suivants :

• Certains privilèges des rôles g_admin ou g_admin_ext qui sont requis par les mécanismes d'AsgardMenu ont été involontairement révoqués. Dans cette situation, les messages devraient être de la teneur suivante :

  1

  2

  ERREUR:  ECS0 > droit refusé pour la table gestion_schema 

  ERREUR:  ECS0 > droit refusé pour la table gestion_schema 

  Exécuter la fonction asgard_initialise_all_schemas avec la variante n°2 permet de résoudre ce problème. Cette variante est spécifiquement prévue pour une telle situation. Elle ne présente pas de risque d'effet de bord et peut être lancée de manière préventive.

• Lorsque les champs d'identifiants système de la table de gestion sont corrompus. La fonction asgard_nettoyage_oids permet de remédier à ce problème. On se reportera au descriptif de la fonction pour plus de précisions sur les circonstances dans lesquelles il est recommandé de l'utiliser.