VLMS Local

This plugin is the continuity of the older VLMS block.

The core implementation of VLMS has moved from a block to a local plugin, as local plugin naturally handles sub plugin without core modification.

Installation

1. Get the plugin archive (vlms.zip, but now served from the “local” category) and deploy it into the /local folder of your LMS distribution.
2. Run the administration notifications to get the plugin registered.

Once the local plugin has been registered, there is a pair of things to do to get VLMS to start accepting virtualization:

the vconfig.php file

You need first to edit the copy the vconfig-dist.php in local/vlms to vconfig.php, and give the database access
schema to your master database. (most often, this will use the same DB access credentials than master config.php). VConfig will look like :

  $CFG->vmasterdbhost = 'localhost';
  $CFG->vmasterdbtype = 'mysqli';
  $CFG->vmasterdbname = 'lms';
  $CFG->vmasterdblogin = '<mydblogin>';
  $CFG->vmasterdbpass = '<mydbpass>';
  $CFG->vmasterdbpersist =  false;
  $CFG->vmasterprefix    = 'mdl_';
  $CFG->vlmsdefault    = 1; // tells if the default physical config can be used as true host

Keep this file in the local/vlms directory, or raise it up the root level of LMS. (No impact). What follows will consider
the first option.

the standard config.php file

you need first to hook the VLMS configuration in your config file, and define explicitly the $CFG->dirroot key as this would be done
too late by setup.php.

  $CFG->dirroot = '<your/lms/path>';
  
  $CFG->mainhostprefix = 'http://you.main.lms.prefix';
  
  include_once $CFG->dirroot.'/blocks/vlms/vconfig.php';

Note that including from a handwritten path will not preserve you to define $CFG->dirroot, as this path is used
in VLMS bootstrapping code.

the mainhostpreifx will tell the administration menu to activate the access point to the VLMS management only in the primary installation of LMS. there is indeed no reason that you can reach the VLMS control board from a child site. It just needs to discriminate clearly your master LMS url.

VLMS Features

Features Addressing the “LMS Factory” Administration

• Virtualization Hook for the standard ‘config.php’ Configuration file
• Deployment of new instances from within the Master instance administration
• LMS snapshot to create platform templates for further deployment
• On-demand LMS deployment
• Deployment of virtualized LMS within an LMS Network strategy
• VLMS Cron rotation handles automatically all instances in a VLMS array.
• Additional Key Refresh Automation to keep SSH keys always consistent.

Features Addressing the “MNetwork Level Administration”

Multiplying instances will ever raise issues of administration because increasing the amount of information to be managed and the complexity of the system. The VLMS feature provides a super-administration toolset allowing distributing administration commands across an LMS Network so getting things faster even when the number of LMS gets quite high. This administration layer provides a command framework for extensibility.

• SQL orders can be distributed on all managed nodes
• Role comparison and sync between many nodes
• Capability resync between many nodes
• The massive upgrade of all nodes when upgrading or installing new plugins.

Access to Mnetwork Level Administration

You may access to the MNet level administration clicking on the link “Administrate” showing in the footer of the “VLMS” bloc instance.

Three sub-services are available :

• Managing virtual instances and deployment: lists nodes and allows enabling, disabling snapshooting and deleting a node, …
• Super-administration: a set of primitives that can be processed simultaneously on distributed LMSs.
• MNET Services Template: A form to define a template or MNet services settings to be applied as a default to any new LMS clone.