Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révision Les deux révisions suivantes | ||
local:vmoodle:technique [2019/08/26 11:14] admin [Contraintes sur les scripts CLI] |
local:vmoodle:technique [2020/06/30 08:31] florence [VMoodle : Guide technique] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | <html><!-- nomoodle --></html>{{ :blocks:logo-apl.png?nolink |}}<html><!-- /nomoodle --></html> | ||
=====VMoodle : Guide technique ===== | =====VMoodle : Guide technique ===== | ||
Ligne 52: | Ligne 53: | ||
=== Scripts additionnels === | === Scripts additionnels === | ||
- | Sur la base de cette structure de lancement industrialisé, d'autres scripts spécifiques VMoodle sont disponibles dans le répertoire ||/local/vmoodle/cli|| | + | Sur la base de cette structure de lancement industrialisé, d'autres scripts spécifiques VMoodle sont disponibles dans le répertoire ''/local/vmoodle/cli'' |
+ | |||
+ | * [[:local:vmoodle:cli:start_mnet_node|Initialisation réseau mnet]] | ||
+ | * [[:local:vmoodle:cli:init_mnet_node|Amorçage réseau mnet]] | ||
+ | * [[:local:vmoodle:cli:renew_mnetkeys|Renouvellement des paires de clefs mnet]] | ||
+ | |||
+ | * [[:local:vmoodle:cli:bulkstartmnet|Initialisation du réseau mnet (industrialisation)]] | ||
+ | * [[:local:vmoodle:cli:bulkinitmnet|Amorçage réseau mnet (industrialisation)]] | ||
+ | * [[:local:vmoodle:cli:bulkrenewmentkeys|Renouvellement des paires de clefs mnet (industrialisation)]] | ||
+ | |||
+ | === Lanceur de commande de superadministration === | ||
+ | |||
+ | VMoodle dispose d'un jeu de commandes de super-administration réseau pour lancer des actions sur tout ou partie des instances moodle virtualisées. Ces commandes peuvent être invoquées à partir de l'interface d'administration VMoodle, mais aussi désormais en ligne de commande par la commande : | ||
+ | |||
+ | php local/vmoodle/cli/run_command.php | ||
+ | |||
+ | La commande s'exécutera toujours en partant de l'instance principale (on ne peut lancer une commande de super-administration dans une instance virtuelle). La commande accepte 4 paramètres : | ||
+ | |||
+ | * **fromhost** : si la commande doit effectuer une copie de données à partir d'une instance de référence (synchro de config, copie de table, copie de fichiers, etc), alors on donnera l'identité (wwwroot) de cette instance. En l'absence de paramètre c'est la plate-forme principale qui sera prise comme 'source'. | ||
+ | * **tohosts** : une liste à virgule des identités d'instances destinataires de la commande. Les cibles sont identifiées par leur wwwroot. Alternativement, ''tohostsmatch'' peut être utilisée avec un motif REGEXP simplifié (* pour .* et ? pour .?) pour sélectionner un ensembles d'instances par filtrage de nom. | ||
+ | * **command** : Le nom de la classe-commande (voir [[:local/vmoodle/technique:commandclasses|Liste des classes-commandes en annexe]]) | ||
+ | * **attributes** : une liste de clefs/valeurs formatée comme une QUERYSTRING http. | ||
+ | |||
+ | Exemple de commande : | ||
+ | \$sudo -u www-data /usr/bin/php local/vmoodle/cli/run_command.php | ||
+ | --fromhost=http://source.virtual.moodle.org | ||
+ | --tohosts=http://target1.other.moodle.org,http://target2.other.moodle.org | ||
+ | --command=generic/CopyFilearea --attributes=fileareaid=mod_h5p%2Flibraries%3A0 | ||
+ | |||
+ | === Test des hôtes cibles sur une cible "tohostsmatch" === | ||
+ | |||
+ | Il est possible de contrôle la liste des cibles d'un lancement de commande avant de la lancer effectivement : | ||
+ | |||
+ | php run_command.php --command=showtargets [--fromhost=<fromwwwroot>] --tohostsmatch=<testedpattern> | ||
+ | |||
+ | Le résultat de cette commande affiche la liste des Moodle virtuels auxquels la commande sera appliquée. | ||
+ | |||
+ | |||
- | === | ||
==== Utilisation de plusieurs Moodle sur la même racine d'hôtes (sous-répertoires) ==== | ==== Utilisation de plusieurs Moodle sur la même racine d'hôtes (sous-répertoires) ==== | ||
- | Actuellement ce type d'installation n'est pas supporté par VMoodle. | + | L'utilisation de la clef supplémentaire de configuration : |
+ | |||
+ | $CFG->vmoodleusesubpath = true; | ||
+ | |||
+ | Permet d'activer la configuration 'sous-répertoires' de VMoodle. Toutes les instances virtuelles seront alors | ||
+ | opérées comme un premier niveau de sous-répertoire d'une raçine de domaine unique : | ||
+ | |||
+ | https://mon.vmoodle.org/moodle1 | ||
+ | https://mon.vmoodle.org/moodle2 | ||
+ | https://mon.vmoodle.org/moodle3 | ||
+ | ... | ||
+ | |||
+ | L'avantage de ce modèle est l'économie en termes de certificats HTTPS (un seul certificat de domaine pour toutes les instances). Il peut par contre provoquer une certaine confusion dans la mémorisation de données saisies côté client web. | ||
+ | |||
+ | Le nom d'instance est automatiquement capté à partir du nom du sous-répertoire. | ||
+ | |||
+ | La mise en place de moodle virtualisés à un niveau inférieur de l'arborescence n'est pas supportée. | ||
+ | |||
+ | Pour mettre en place ce type il sera nécessaire d'assurer la mise en place de liens symboliques d'instance dans le répertoire d'installation du code de moodle : | ||
+ | |||
+ | drwxrwsr-x 11 root root admin | ||
+ | drwxrwsr-x 24 root root auth | ||
+ | drwxrwsr-x 6 root root availability | ||
+ | drwxrwsr-x 7 root root backup | ||
+ | drwxrwsr-x 6 root root badges | ||
+ | -rw-rwSr-- 1 root root behat.yml.dist | ||
+ | drwxrwsr-x 70 root root blocks | ||
+ | drwxrwsr-x 3 root root blog | ||
+ | -rw-rwSr-- 1 root root brokenfile.php | ||
+ | drwxrwsr-x 6 root root cache | ||
+ | drwxrwsr-x 6 root root calendar | ||
+ | drwxrwsr-x 4 root root cohort | ||
+ | drwxrwsr-x 4 root root comment | ||
+ | drwxrwsr-x 4 root root competency | ||
+ | drwxrwsr-x 5 root root completion | ||
+ | ... | ||
+ | |||
+ | lrwxrwxrwx 1 root root moodle1 => . | ||
+ | lrwxrwxrwx 1 root root moodle2 => . | ||
+ | lrwxrwxrwx 1 root root moodle3 => . | ||
+ | ... | ||
+ | |||
+ | Cette mise en place assure à chaque moodle virtualisé en sous-répertoire la disponibilité du code source de moodle. Les outillages de gestion des instances gèrent la mise en place de ces liens symboliques pour le compte de l'administrateur Moodle à travers une procédure locale de sudo. La configuration VMoodle doit désigner un utilisateur sudo ayant la possibilité de manipuler le répertoire d'installation de moodle, à partir de l'utilisateur titulaire de l'exécution du serveur (apache, httpd, nginx, ou autre suivant l'environnement). | ||
------- | ------- |