ASGARD

Si le serveur PostgreSQL s’inscrit dans le cadre de l’offre Eole/PostgreSQL du pôle interministériel MTE-MCTRC-Mer, alors l’administrateur de données n’a rien de particulier à faire. Les nouvelles versions de l’extension sont mises à disposition automatiquement sur les serveurs Eole (synchronisation quotidienne, cf. Configuration dans l'interface Zephir des serveurs Eole pour plus de détails).

On pourra donc se reporter directement au point Activation de l'extension sur une base pour la suite de la procédure.

Les fichiers asgard--x.x.x.sql et asgard.control doivent être copiés dans le répertoire des extensions du serveur PostgreSQL.

Si ASGARD est installé dans une base de données contenant déjà des schémas, il est possible d’intégrer les schémas souhaités dans la gestion d’ASGARD :

• en masse, par la fonction asgard_initialisation_gestion_schema (schéma z_asgard_admin), qui enregistre dans la table de gestion tous les schémas existants hors schémas système et hors une éventuelle liste d’exceptions fournie en argument de la fonction ;
• un par un, avec la fonction asgard_initialise_schema (schéma z_asgard).

On se reportera aux descriptifs de ces fonctions pour de plus amples précisions sur leurs modalités d'utilisation.

Dans la grande majorité des cas, asgard_initialisation_gestion_schema pourra être lancée sans risque sur l’ensemble des schémas et il est recommandé de le faire. Son seul effet concret, au-delà de l’enregistrement dans la table de gestion^[1], est d’attribuer au propriétaire du schéma la propriété de tous les objets qui s’y trouvent, s’il n’en disposait pas déjà.

D'une manière générale, asgard_initialisation_gestion_schema (utilisable uniquement par un membre de g_admin ou un super-utilisateur) est plus puissante qu'asgard_initialise_schema. En particulier, elle saura prendre en charge les schémas dont le propriétaire n'est pas un super-utilisateur, mais seulement un rôle de groupe^[4] dont g_admin n'est pas (encore) membre.

Ainsi, en cas d'erreur avec asgard_initialise_schema, on pourra :

• si c'est possible, utiliser asgard_initialisation_gestion_schema au lieu d'asgard_initialise_schema. Lorsqu'il ne l'était pas déjà, elle rendra automatiquement g_admin membre des rôles propriétaires des schémas (producteurs^[5], au sens d'ASGARD), ainsi que prévu par ASGARD pour tous les producteurs ;

• lancer la fonction asgard_initialise_schema avec un super-utilisateur. Là aussi, l'un des effets du référencement sera de rendre g_admin membre du producteur du schéma ;

• rendre manuellement g_admin membre du rôle propriétaire en question avant de lancer la fonction asgard_initialise_schema.

Dans cette situation, il n'y a que deux alternatives :

• changer le propriétaire du schéma avant le référencement (en désignant un rôle de groupe) ;

• à défaut, exclure le schéma du référencement et donc du système de gestion des droits d'ASGARD.

À l'issue du référencement initial, les schémas apparaîtront dans la table de gestion^[1] avec comme producteur^[5] le rôle qui en était propriétaire. À ce stade, aucun lecteur^[7] ou éditeur^[8] n'est désigné, quand bien même d'autres rôles disposent vraisemblablement déjà de privilèges sur certains objets.

Il est souhaitable de remettre en ordre les droits en s'appuyant sur le système producteur/éditeur/lecteur d’ASGARD. Une personnalisation plus fine des droits^[9] restera toujours possible, mais elle devrait être réservée aux cas où il a été établi que les profils d'ASGARD ne répondent pas aux besoins. L'un des grands intérêts du système très simple d'ASGARD est en effet qu'il permet à l'administrateur de conserver une vision d'ensemble sur les droits alloués via la table de gestion^[1]. Les privilèges non prévus par ASGARD ne seront pas visibles dans la table de gestion, ce qui les rend plus difficiles à connaître et maîtriser.

Les fonctions asgard_cherche_lecteur et asgard_cherche_editeur permettent de scanner les droits dont disposent actuellement les rôles sur les objets des schémas pour déterminer si certains d'entre eux ont de fait des privilèges correspondant à ceux des profils d'ASGARD. En première approche, il est possible de préremplir la table de gestion en désignant formellement ces lecteurs et éditeurs de fait comme lecteurs et éditeurs des schémas :

UPDATE z_asgard.gestion_schema_usr

    SET lecteur = z_asgard.asgard_cherche_lecteur(nom_schema),

        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) ;

Avec la requête ci-avant, les rôles désignés comme lecteur ou éditeur verront leurs privilèges alignés sur ceux que prévoit ASGARD pour les lecteurs et éditeurs des schémas. Ils peuvent donc gagner ou perdre quelques droits qui divergeaient du standard. S'il importe de préserver strictement leurs droits originaux, une alternative consiste à utiliser la fonction asgard_restaure_editeurs_lecteurs.

Les fonctions de recherche peuvent accélérer un peu le processus, mais elles ne permettront pas de désigner automatiquement des éditeurs et lecteurs pour tous les schémas qui le justifient. Pour l'essentiel, cette opération devra être réalisée manuellement.

Avant ou après la désignation des lecteurs et éditeurs, il est conseillé de nettoyer les privilèges alloués aux autres rôles sur les schémas référencés. Cette opération peut être réalisée en une seule fois avec la fonction asgard_initialise_all_schemas (variante 0), schéma par schéma avec asgard_initialise_schema, voire objet par objet avec asgard_initialise_obj. À tout moment, la fonction asgard_diagnostic peut être utilisée pour détecter les privilèges qui échappent au système producteur/éditeur/lecteur d'ASGARD.

Par ailleurs, ASGARD permet d’importer tout ou partie de la nomenclature nationale^[10] dans la table de gestion^[1], sous la forme de schémas pré-référencés^[11] qui pourront ensuite être créés. L’import se fait avec la fonction asgard_import_nomenclature.