Gestion des droits sur scenarichain-server?

Bonjour,
Je viens tout juste de migrer un serveur 4.2 en 5.0 avec succès.
Cependant, je suis confronté à un problème pour le choix de l’affectation des rôles des utilisateurs déclarés (ce problème existait certainement avant mais je n’y ai jamais vraiment été confronté concrètement.

Le problème est le suivant :
je voudrais pouvoir donner les droits à un utilisateur sur un atelier (notamment, la possibilité de changer les propriétés de l’atelier pour qu’il puisse changer quand il le souhaite le modèle documentaire utilisé).
Je souhaiterais qu’il puisse éventuellement créer d’autres ateliers à sa convenance.

Si j’ai bien compris les rôles des utilisateurs, il faudrait qu’il soit gestionnaire fonctionnel. Le problème apparait car il aurait également la maitrise totale des comptes utilisateurs et de leur rôle. Il ne pourrait pas ajouter de modèle documentaire mais pourrait les supprimer (par accident par exemple).

D’où ma question : est-ce qu’il serait possible de lui donner les droits de gestion des propriétés de son atelier sans qu’il puisse retoucher les comptes utilisateurs ni qu’il puisse supprimer les modèles/skins installés ?
Si oui, quelle serait la configuration à adopter dans ce cas de figure ?

Merci d’avance pour votre aide précieuse
Cordialement
Philippe Vignoles

1 « J'aime »

Bonjour Philippe,

Quelques éléments de réponse :

  • dans les outils communautaires (SCENARIchain-server et SCENARIsuite-starter), la gestion des ateliers est du ressort du rôle « Gestionnaire fonctionnel », comme la gestion des utilisateurs. Ce rôle se définit au niveau de l’entrepôt.
  • la gestion des packs, elle, est du ressort de l’ « Administrateur technique », pour des questions de sécurité.
  • la gestion des skins ne souffre pas de cette même contrainte sécuritaire, et est donc du ressort du « Gestionnaire fonctionnel ».

La portée de ces rôles prédéfinis n’est pas configurable depuis l’interface utilisateur. L’outil SCENARIbuilder permet en revanche de redéfinir des rôle métiers plus proche d’un contexte donné, et de recompiler l’application.

Cdt

Antoine

Kelis

1 « J'aime »

Pour étendre les possibilités de paramétrage, la prochaine version de SCENARIchain-server et SCENARIsuite-starter permettra d’affecter le rôle « Gestionnaire fonctionnel » sur des ateliers donnés. Ces utilisateurs pourront ainsi :

  • modifier le modèle documentaire affecté à l’atelier ;
  • modifier es options de l’atelier (atelier public, …) ;
  • modifier les rôles spécifiques à cet atelier ;

Cdt
Antoine
Kelis

1 « J'aime »

Bonjour Antoine,
Merci pour toutes ces précisions. Du coup, je vais sursoir un peu à la manipulation de « rebuilding » de l’applet… :smiley:
Je pensais peut-être à une autre solution mais je ne sais pas si elle est réalisable :
j’ai installé le paquetage debian de scenarichain-server 5 et je me demandais s’il était possible d’installer tout simplement une seconde applet de ce serveur ? J’ai bien compris que dans ce cas de figure, il n’est pas possible de l’installer via les paquetages mais en installation manuelle, en lui donnant un autre nom, est-ce que cela serait réalisable (j’imagine que tomcat n’aura pas de problème pour la gérer) ?
Cela me permettrait alors de définir un espace totalement vierge avec l’affectation des droits nécessaires à mon collègue qui pourrait alors s’en servir à sa convenance pour son activité pédagogique…

Cordialement
Philippe Vignoles

1 « J'aime »

Bonjour,

En effet il est tout fait possible d’installer plusieurs webapps SCEANRI dans un même Jetty ou Tomcat.
La version deb de scenariserver plus d’autres compilés pas SCENARIbuilder du moment qu’ils ont des noms différents et des bases de données différentes.

Il serait même envisageable d’utiliser la version deb pour instancier plusieurs webapps en modifiant le fichier /etc/scenarichain-server5.0/conf/webapp.properties
en paramétrant toutes les variables webapp.* à chaque fois puis en lançant scenarichain-server5.0-cfg reconfig.
Jamais testé mais ça doit marcher. Ceci dit ce ne serait pas forcément très utile, toutes les instances serait identique en terme de fonctionnalités.

1 « J'aime »

Bonjour Sam,

Merci pour ces informations précieuses (je vais essayer de les mettre en applications) et je reviendrai vers vous pour vous dire ce que j’ai réussi à faire (ou eu le temps de faire). :wink:
Cordialement
Philippe Vignoles

Rebonjour,

Je suis en train d’essayer d’installer une nouvelle applet de scenari server mais je bloque sur un point qui me paraît étrange :
à priori, la compilation de l’applet se passe bien, tomcat9 la déploie facilement mais… lorsque j’essaie de m’identifier cela ne fonctionne pas. Dans la configuration, il faut indiquer un chemin pour la localisation de la base de données (Répertoire principal de travail. Accès R/W). J’ai créé le dossier mais il ne se peuple pas et j’avoue que je ne sais pas comment le peupler. Suffit-il que je crée les dossiers principaux (addons, data et working) ou faut-il y mettre plus de chose dedans ?

Merci d’avance de votre aide
Cordialement
Philippe Vignoles

il faut surtout que Tomcat en soit le propriétaire

Oui oui, j’ai bien attribué la propriété à tomcat mais ça n’a pas l’air de se peupler…
Faut-il que ce dossier soit créé avant la compilation ?

Non. Et côté logs ?

Côté log, l’applet n’en crée aucun malgré le chemin indiqué et catalina ne semble pas gêné par le déploiement :


[2021-02-08 16:45:07] [info] Déploiement de l'archive [/var/lib/tomcat9/webapps/scchainsrv50.war] de l'application web
[2021-02-08 16:45:09] [info] Au moins un fichier JAR a été analysé pour trouver des TLDs mais il n'en contenait pas, le mode "debug" du journal peut être activé pour obtenir une liste complète de JAR scannés sans succès; éviter d'analyser des JARs inutilement peut améliorer sensiblement le temps de démarrage et le temps de compilation des JSPs
[2021-02-08 16:45:09] [info] Le déploiement de l'archive de l'application web [/var/lib/tomcat9/webapps/scchainsrv50.war] s'est terminé en [2 475] ms

J’avoue que je ne sais pas trop quoi chercher d’autre ni quoi faire…

Un autre point : dans la version packagée, il y a aussi un dossier de configuration qui contient le fichier cfg.conf (avec notamment webappUser et webappPasswd). Faut-il ajouter ces instructions quelque part ?

Je reviens sur l’idée de reconfigurer l’application en modifiant le fichier de configuration.
Est-ce que cela va rajouter autant d’applications dans tomcat ou bien cela va-t-il désintaller l’application précédemment configurée ?

Comme précisé dans la doc SCENARIchain-server 5.0 (Linux) /etc/scenarichain-server5.0/ contient deux fichiers de paramétrage de la commande scenarichain-server5.0-cfg qui lui permette de se connecter à la webapp pour effectuer des opérations de maintenance comme le redéploiement, les sauvegardres etc.

La version deb est conçue pour être mono webapp, scenarichain-server5.0-cfg ne peut avoir connaissance de une seule webapp à la fois.

Par ailleurs scenarichain-server5.0-cfg ne supprimera jamais quoi que ce soit, tout au plus il remplace un war par un autre avec le même nom.

Bonjour Sam et Antoine,
Je viens vous donner quelques nouvelles de mes manipulations…
Je pense que j’ai réussi à faire fonctionner une deuxième appweb. Ce fut un chemin semé d’embuches mais pour faire simple :

  • j’ai construit une appliweb à partir de l’archive et je l’ai déployée sur tomcat
  • il a fallu que j’édite le fichier de configuration de tomcat dans system.d (j’avais d’abord créé 2 documents indépendants mais ça n’avait pas marché, j’ai donc fusionné les lignes du document initial avec celles pour la 2e appweb : les chemins et les permissions).
  • il a fallu aussi que je complète le reverse proxy (mais ça je ne l’ai fait que lorsque j’avais constaté que mon appweb fonctionnait bien).

De toute évidence, c’est l’édition du fichier de configuration de tomcat dans system.d qui a débloqué la situation.
Pour le moment, j’en suis à l’étape de tests mais cela semble assez rassurant.
A priori, si je ne complète pas ce fil de discussion, c’est que tout marche bien.

Merci à vous pour l’aide que vous m’avez apportée.
Cordialement
Philippe Vignoles

Merci pour ce retour.
Ne pas oublier de mettre en place (et de tester) une stratégie de sauvegarde avant toute mise en production.

1 « J'aime »

Rebonjour Sam,
Ce ne fut pas long : j’ai cette fois, je pense, un dommage collatéral…
Je n’arrive plus à déposer de modèles.
Les logs m’indiquent :

[error] 13221#13221: *560 client intended to send too large body: 11917198 bytes,

Avant, ce problème n’existait pas.
Je ne vois pas ce qui coince.

Help ?
Cordialement
Philippe Vignoles

Ceci est un pb de configuration de nginx:
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
et peut-être aussi :
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout

1 « J'aime »

Chapeau Sam, c’était bien ça le problème.
Maintenant, ça marche bien.
Par contre, j’ai déclaré 100M pour la taille limite mais en pratique, quelle serait la taille la plus adaptée ? J’imagine que cela doit limiter la taille du dépôt de certaines ressources lourdes telles que des vidéos par exemple ?

Pour la stratégie de sauvegarde, j’avoue que ce serait l’idéal mais je ne pense pas avoir assez d’espace de stockage pour pouvoir la mettre en pratique immédiatement.
Merci pour votre aide en tout cas
Cordialement
Philippe Vignoles