Kolektiv autorů PROEFES
Virtualizace LMS Moodle
Masarykova univerzita Brno 2015
Kolektiv autorů PROEFES
Virtualizace LMS Moodle
Masarykova univerzita Brno 2015
Název projektu: Prostředí pro sdílení e-learningových zdrojů a znalostí pro školy Jihomoravského kraje Stručný název projektu: PROEFES Registrační číslo: CZ.1.07/1.3.41/01.0033 Projekt je realizován Ústavem výpočetní techniky Masarykovy univerzity. Partnerem projektu je Ústav celoživotního vzdělávání Západočeské univerzity v Plzni.
c
2015 Masarykova univerzita
Obsah 1
Motivace
5
2
Správa jednotlivých instalací
5
3
Ekonomické hledisko
8
4
Bezpečnostní hledisko
9
5
Technické možnosti
6
Virtualizace nepodporovaná v Moodle 6.1 Virtualizace na úrovni celých serverů . . . 6.2 Souběžné násobné instalace LMS Moodle . 6.3 Virtualizace na úrovni kontejnerů (Docker) 6.4 MOOSH . . . . . . . . . . . . . . . .
7
Existující řešení přímo v LMS Moodle 7.1 Jedna instance LMS sdílená všemi 7.2 Role Manažera vs. Správce . . . . 7.3 IoMad . . . . . . . . . . . . . 7.4 VMoodle . . . . . . . . . . . .
11
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
12 12 14 15 16
. . . .
17 17 18 18 21
8
Správa uživatelů
24
9
Další důležité otázky k vyřešení 9.1 Certifikáty . . . . . . . . . . . . . . . . . . . . . . . 9.2 Technická a uživatelská podpora . . . . . . . . . . . . .
25 25 26
10 Závěr
26
11 Použité zdroje
27
1
Motivace
LMS Moodle je jedním z nejčastějších e-learningových řešení nasazovaných v České republice. Jednou z jeho hlavních výhod je pořizovací cena — systém je open-source, tedy zdarma včetně zdrojových kódů. Navíc využívá poměrně známých technologií pro svůj provoz, což technicky zdatnému správci podstatně zjednodušuje úvodní instalaci. Skrytá cena open-source technologií ovšem není v jejich případě v pořízení a instalaci, ale v návazné správě a souvisejících aktivitách. A tak na přelomu roku 2014 / 2015 celá řada škol i soukromých institucí stále využívá Moodle ve verzi 1.9.x, jejíž podpora skončila v červenci 2012 (informace z dotazníkového šetření provedeného v rámci projektu). Tento fakt může být daný jednak tím, že stará verze stále do jisté míry funguje, nicméně z velké části také skutečností, že aktualizace již běžících systémů představuje časově i technicky náročnější činnost. A to nemluvě o okamžiku, kdy některá část aktualizace selže. Právě návaznou správu systému Moodle by mohl vyřešit systém virtualizace, resp. sdílených instalací, kdy každá instituce má zdání vlastního e-learningového systému, spravovaného však centrálně skupinou proškolených specialistů.
2
Správa jednotlivých instalací
Jak vlastně vypadá a co obnáší tradiční řešení Moodle na školách a proč má smysl se zabývat tématem virtualizace? Jak již bylo naznačeno v úvodu, počáteční instalaci LMS Moodle zvládne i trochu šikovnější administrátor. Nicméně v průběhu života LMS je třeba provádět i jeho aktualizace na několika úrovních, případně upravovat hardware a konfiguraci systému tak, aby zvládal přibývající požadavky. Pokusíme-li se rozklíčovat potřebné komponenty a role na efektivní správu e-learningového systému, mohl by seznam vypadat takto:
moodle.ics.muni.cz
5
Hardware Server, na kterém systém poběží. Ačkoliv pořizovací náklady na IT průběžně klesají a dostatečně výkonný server pro malou školu je možné pořídit za relativně snadné peníze, nejde jen o náklady na pořízení. Může dojít k technické poruše (nejčastěji poškozený disk či zdroj), která na kratší či delší dobu odstaví důležitý výukový systém. Také může dojít ke ztrátě dat, je tedy dobré myslet na zálohování. Více se dozvíte v dalších částech této zprávy. Software V případě LMS Moodle je možné pořídit a využívat jak samotný e-learningový, tak i operační systém a další nezbytné komponenty zdarma. Aby však bylo možné jakékoliv řešení používat, je třeba mít k dispozici i jednoho či více lidí, kteří se starají o jeho chod. V praxi to často bývá člověk jediný, na malých školách nadšený učitel IT. Co je však náplní jejich práce? Správa hardware serveru Za normálních okolností vše funguje, nicméně v případě výpadků či selhávání jednotlivých součástí serveru je třeba mít k dispozici buď náhradní řešení, nebo vše začít rychle řešit. Operační systém a jeho údržba Situace podobná hardware, nicméně u operačních systémů vycházejí pravidelné bezpečnostní aktualizace, jejichž význam nelze v dnešní době podceňovat. Správce by měl v takovém případě včas takové aktualizace nainstalovat a ověřit, že nedošlo k narušení funkčnosti řešení jako celku. Správce webového serveru a databáze Tato role je často sloučena s rolí předchozí, nicméně o to větší nároky klade na zodpovědnou osobu. Nad rámec operačního systému vyžaduje většina moderních LMS (a Moodle není výjimkou) ke své činnosti i databázi a webový server. Tedy další komponenty, které sice mohou fungovat víceméně samostatně, nicméně v případě problémů je třeba mít někoho, kdo je schopen problémy vyřešit. Bezpečnostní aktualizace se týkají i této složky, jejich správce by měl tedy sledovat i aktualizace těchto programů. Administrátor Moodle Jeho úkolem je nejen sledovat a případně aktualizovat Moodle, ale také jej správně nastavovat, hlídat bezpečnostní oznámení týkající se právě Moodle, zavádět uživatele, provádět a obnovovat
6
PROEFES
zálohy kurzů, je-li třeba. Měl by zajistit povolení vytvoření kurzu a vytváření dalších systémových záležitostí (kategorie, kohorty, atd.). Jeho úkolem také může být komunikace s hlavními vývojáři Moodle a hlášení chyb, které vyžadují právě zásah z hlavního vývoje. Uživatelská podpora Moodle V běžném provozu každého LMS se objeví celá řada dotazů uživatelů, ať už tvůrců materiálů, tutorů, nebo studentů. Ať už proto, že někteří zapomněli vlastní heslo a nevědí, jak jej obnovit či provést jeho reset, nebo mají technické obtíže při přístupu ke konkrétnímu materiálu. Kdokoliv, kdo se zabývá uživatelskou podporou, by měl být empatický a schopný odpovědět stručně a přesto vstřícně. Součástí uživatelské podpory může být i školení uživatelů v nejnovějších vlastnostech aktualizovaného LMS, případně o jeho největších změnách, které by autory či studenty mohly mást. Programátor Tato role je dozajista nepovinná, jen často může usnadnit řešení technických problémů se systémem. Jako každý softwarový produkt, i LMS mívá chyby, které se projevují jen za určitých podmínek nebo v určitých typech úkonů. Mít v týmu programátora, nebo člověka, který kódu LMS rozumí, může výrazně zrychlit řešení hlášených problémů a zvýšit kvalitu LMS jako celku. Ačkoliv to vypadá jako příliš detailní výpis, je přinejmenším náročné to všechno v řádné kvalitě stíhat v jedné osobě, zejména při dalším zaměstnání. Krom možných výhod však existují i obavy z virtualizovaných či tzv. cloudových řešení:
•
Ztráta kontroly nad soukromými daty
•
Nedostatečná flexibilita poskytovatele, případně pomalé reakční časy na požadavky
•
Nedostatečná či špatná komunikace mezi poskytovatelem LMS řešení a zákazníky
•
Malá možnost přizpůsobení řešení podmínkám zákazníka
Některým z těchto bodů se budeme podrobněji věnovat v dalších částech této zprávy.
moodle.ics.muni.cz
7
3
Ekonomické hledisko
V čem tedy shledáváme výhody případné virtualizace, resp. sdílených instalací? Jednotná správa Ušetří čas správce v jednotlivých rolích. Viditelné je to zejména na úrovni aktualizací, kdy při správně provedené virtualizace je možné aktualizovat všechny spravované instance LSM Moodle za dobu potřebnou pro aktualizaci instance jediné. Platí to nicméně i pro další aktualizace, které se v průběhu životního cyklu e-learningového systému objeví. Sloučení nákladů na hardware Vyšší dostupnost řešení za nižší cenu (není problém držet náhradní díly či použít dražší hardware tak, aby určité typy selhání nenastaly a přesto nebyly pořizovací a provozní náklady zbytečně vysoké). V současnosti je navíc běžné, že i hardware lze virtualizovat a tím jej jednak využívat efektivněji, jednak připravit tzv. „škálovatelné“ řešení, které se přizpůsobuje požadavkům na výkon a přístupnost, aniž by to dramaticky ovlivňovalo cenu. Vyšší kvalita poskytovaných služeb Lze očekávat, že specializovaný tým je dražší než jednotlivec, který vykonává správu e-learningového systému na bázi dobrovolnosti, zpravidla za drobný příplatek. Nicméně tím může utrpět kvalita a v kritických chvílích i pověst instituce, která služby e-learningového řešení využívá. Sdílená instalace může za cenu vyšších nákladů na lidské zdroje, která se ovšem rozprostře mezi všechny zapojené instituce, poskytovat očekávanou nadstandardní úroveň služeb. Bezpečnostní hledisko Dá se na to pohlížet jako na problematické místo (vždyť se jedná o centralizaci dat), nebo na výhodu, neboť o tato centrální data se starají lidé, pro které je to náplň práce a často i koníček současně. Nejde jen o úvodní zabezpečení celého řešení, ale zejména o jeho pravidelné udržování, tedy o pravidelné aktualizace jak operačního systému a souvisejících služeb, tak i aktualizace LMS Moodle a správná nastavení všech spolupracujících komponent celého systému. Součástí bezpečnosti je i zálohování, žádná ze zapojených institucí tak nepřijde o svá data, ať už vinou selhání hardwaru nebo softwaru, případně lidskou chybou.
8
PROEFES
Všechny předchozí body neznamenají automatické šetření peněz, přinášejí však přinejmenším výrazně kvalitnější službu a minimalizují potenciální rizika selhání řešení e-learningu na školách.
4
Bezpečnostní hledisko
Sdílené instalace, bez ohledu na svoji potenciální ekonomickou výhodnost, musí vyřešit a zodpovědět několik důležitých otázek z pohledu bezpečnosti — a to nejen otázky technické. Pro přehlednost vyjmenujeme některé nejdůležitější body:
•
Krádež dat
•
Výpadky kvůli přetížení
•
Výpadky kvůli chybám hardware
•
Zastaralé verze software
•
Útoky hackerů (ať již na slabé články systému, nebo útoky typu odepření služby, DDoS)
•
Odchody kritických zaměstnanců (správci, podpora)
Současný pohled Moodle komunity na možnost centralizovaného poskytování sdílených či virtualizovaných řešení LMS Moodle je spíše skeptický. Velikou roli v tom hraje obava o bezpečnost dat zákazníků, v tomto případě škol, v takovém centrálním modelu. Proto ostatně LMS Moodle prozatím oficiálně nepodporuje žádné řešení pro snadnou virtualizaci instancí LMS (resp. v terminologii Moodle komunity jde o tzv. „multi-tenancy“). Je možné, že v tom částečně hraje roli i malá zkušenost s centralizovanými poskytovateli Moodle řešení — vždyť část škol bezproblémově využívá služeb firem Google nebo Microsoft, které s postupem času do tzv. cloudu přesunuly většinu svého portfolia. Přesto je obava o bezpečnost dat a jejich případné zneužití legitimní a je dobré ji nebagatelizovat, ale vysvětlovat. Poskytovatel centrálního řešení by měl být
moodle.ics.muni.cz
9
schopen doložit, jakým způsobem se s daty nakládá a jak je zajištěna jejich bezpečnost, nejlépe předem, při nabízení služby. Dostatečná a dobrá komunikace směrem k institucím je tedy nezbytný základ. Existují však i zřejmé výhody centrálního řešení, a to právě z pohledu bezpečnosti. IT bezpečnost je totiž komplexní, náročné a na správnou implementaci i drahé téma, jehož správné nasazení se zdaleka ne vždy podaří. A nejde jen o problém instalace — aby byla zajištěna bezpečnost systému, je třeba jej během celé doby provozu aktualizovat, správně nastavovat a sledovat aktuální bezpečnostní trendy.
Jen pro zajímavost: za rok 2014 bylo ohlášeno 48 oficiálních bezpečnostních zranitelností (CVE), které mohly být zneužity na systémech s LMS Moodle. Přičemž spousta zranitelností je nalezena a opravena vývojářským týmem Moodle dřív, než jsou nalezeny externími analytiky a zaneseny do této oficiální CVE databáze. Organizace, které tak používají Moodle ve verzích starších než 2.5, mají potenciálně nebezpečné instalace, které by motivovaní útočníci mohli zneužít. Například k získání neautorizovaného přístupu k některým datům uvnitř e-learningového systému, nebo k jejich modifikaci. Odhlédneme-li od IT bezpečnosti, týká se toto téma ještě jedné podstatné věci, a tou je zabezpečení provozu e-learningového systému pro potřeby škol a dalších institucí. Nejde přitom jen o zajištění technické dostupnosti, tedy že neselže některá z hardwarových, softwarových či síťových složek, která webová řešení ke svému
10
PROEFES
životu potřebují. Všechny navíc musí být dostatečně dimenzované na očekávaný provoz i ve špičkách. Týká se to také varianty, kdy odejde klíčový pracovník a která může být v menších organizacích kritická, zejména v případě, kdy je naprostá většina rolí svěřena jednomu člověku. Řešení virtualizovaných či sdílených instalací, které zpracovává centrální instituce pro další zákazníky, zpravidla tomuto riziku předchází větším týmem, kvalitní interní dokumentací, školeními a např. systémem na správu chyb.
5
Technické možnosti
Přejděme tedy k technickým detailům jednotlivých virtualizačních řešení. V průběhu realizace projektu bylo vypracováno několik možných variant přístupu k problému virtualizovaných instancí LMS Moodle, které teď postupně představíme. Včetně rozborů týkajících se jednoduchosti jejich správy, možnosti přizpůsobení jednotlivých instancí, správy uživatelů a bezpečnosti. Jak již bylo zmíněno, oficiální podporu pro multi-tenancy, tedy sdílení instancí, LMS Moodle neposkytuje. Bylo tedy třeba zvážit několik variant s různými úrovněmi virtualizace. Podařilo se najít i projekty, které jsou neoficiálním vylepšením Moodle a právě vlastnost sdílení jednoho Moodle více institucemi přidávají. Autoři systému Moodle doporučují následující hardwarové požadavky pro provoz jejich systému: Disk Procesor Zálohy Paměť RAM
160 GB, ovšem 5 GB jako realistické minimum 1 GHz, spíše však 2 GHz procesor, alespoň dvoujádrový Další úložiště pro zálohy 1 GB RAM na každých 20 souběžných uživatelů
Na takový systém je poté ještě nutné nainstalovat např. něco, co se v IT světě webových aplikací označuje jako LAMP, tedy Linux, Apache, MySQL a PHP ve verzích odpovídajících tomu, co v aktuální revizi vyžaduje daná verze Moodle.
moodle.ics.muni.cz
11
6
Virtualizace nepodporovaná v Moodle
S rozmachem virtualizačních řešení na několika úrovních (plná hardwarová virtualizace, sdílení datových úložišť a diskových polí, sdílení operačního systému v rámci tzv. „kontejnerů“, sdílení instancí jednotlivých procesů pro poskytování podobné funkcionality) se nabízí podobná škála i pro virtualizaci LMS Moodle, aniž by bylo nutné vůbec zasahovat do jejich kódu. Která řešení sem patří?
•
Plná virtualizace celých serverů
•
Apache, částečné sdílení kódu
•
Kontejnerová řešení
Vzhledem k tomu, že jedním z důležitých prvků celého řešení je i jeho výkon, je možné se zaobírat i vhodností distribuce databáze na různé další servery. V tradičním případě jsou všechny komponenty Moodle uloženy na jediném serveru, ať již fyzickém, nebo virtuálním. Na tomtéž serveru je tedy jak webový server s PHP, tak i data (ne však zálohy) a databázový server. Zatímco tedy u webu a aplikačního kódu LMS Moodle se budeme snažit, aby byl sdílen co nejvíce instancemi, u databázových serverů paradoxně můžeme chtít jejich oddělení. Ačkoliv do takových detailů v naší zprávě nepůjdeme, je dobré na tuto možnost pamatovat v případě problémů s přílišným zatížením celého e-learningového řešení, například při nečekaně vysokém množství souběžných uživatelů.
6.1
Virtualizace na úrovni celých serverů
Toto řešení je tu zmíněno zejména pro pořádek, neboť spíše než výhody obsahuje celou řadu nevýhod. Díky moderním virtualizačním řešením (VMWare ESX, KVM) je možné jednoduše na jednom fyzickém serveru provozovat celou řadu serverů virtuálních. To je v mnoha případech zcela žádoucí, zejména jedná-li se o servery s různou funkcionalitou a různými zákazníky, kde je jejich oddělení na takovéto úrovni téměř nezbytné.
12
PROEFES
Pro potřeby jednoduché virtualizace LMS Moodle má však takový přístup některé zásadní nevýhody. První z nich je nutnost souběžné správy celých serverů (operačních systémů, základních databázových a webových služeb). Samotná instalace ještě příliš komplikovaná není a je možné ji zjednodušit na maximální míru. Problém pak nastává právě při další správě, aktualizaci operačního systému, aktualizaci dalších vrstev a v neposlední řadě i aktualizaci a správě samotných instancí LMS Moodle. V době hledání úvodního technického řešení nebylo snadné provádět tuto správu efektivně, což se ovšem v průběhu let a s vyšším zapojováním celých desítek serverů změnilo. K dispozici jsou kompletní řešení, např. Puppet, Chef, Ansible, Salt, Landscape a pravděpodobně další. Ta vznikla zejména pro snazší orchestraci (jak se této sadě úkolů odborně říká) serverů umístěných v cloudu, tedy např. na službě Amazon AWS. Problém násobné správy serverů tedy je v současné době řešitelný. Některá řešení dokonce umožňují dynamicky volit poskytovatele cloudových služeb tak, aby se např. v důsledku minimalizovala cena. Navíc je možné najít přímo připravené obrazy pro provozování LMS Moodle. Celé řešení je však náročné na hardwarové zdroje — kvůli takovéto plnohodnotné virtualizaci je nutné využít mnohem víc paměti, diskového prostoru i procesorového času na vytvoření zdání, že uživatelé pracují s jejich vlastním systémem. V jednoduchosti se dá říci, že hardwarové nároky pro instalaci jednoho LMS Moodle (uvedené na začátku kapitoly) se násobí s každou instancí. Virtualizační řešení (např. VMWare ESX) sice umí i v takovémto případě šetřit zdroje, ale v případě větších desítek instancí by byla režie veliká. Pokud však pomineme předchozí nevýhody, jistou výhodou je možnost mít dedikované databázové servery s jinými výkonnostními parametry než samotné webové servery. Také platí, že jednotlivé instituce budou mít k dispozici celé vlastní servery, na kterých v případě nutnosti mohou prosazovat vlastní bezpečnostní politiky. A právě pro vyšší bezpečnost nebo pro lepší rozkládání zátěže serverů v provozních špičkách se může virtualizace na úrovni serverů vhodně doplnit s některým z dalších, níže popsaných řešeních.
moodle.ics.muni.cz
13
6.2
Souběžné násobné instalace LMS Moodle
Vychází-li virtualizace na úrovni celých serverů jako náročné řešení, je možné se podívat na možnost o úroveň výše, tedy sdílení webových a databázových serverů, ideálně i sdílení zdrojových kódů LMS Moodle. Při vhodné konfiguraci webového serveru (ať už to bude oblíbený Apache nebo méně známý nginx) je možné při vhodné konfiguraci sdílet přinejmenším zdrojové kódy LMS Moodle tak, aby při jejich aktualizaci došlo k aktualizování všech instancí. Princip je relativně jednoduchý — Moodle se v základu řídí svým konfiguračním souborem, config.php, ve kterém je uvedeno spojení na databázi, informace o datových složkách a také nezbytné věci kolem jména serveru a jeho plného URL. Pokud se tedy pro každou instanci podaří udržovat vlastní konfigurační soubor a vytvářet vlastní databázi, je možné relativně elegantně sdílet alespoň zdrojový kód. Takové řešení v jednoduchosti přináší:
•
Šetření zdrojů (operační systém, databáze i webový server musí běžet jen jednou)
•
Jednoduché sdílení kódu LMS Moodle a s tím spojené snadné aktualizace
Nicméně stále neřeší několik problémů:
•
Generování konfiguračních souborů pro jednotlivé instance
•
Jednotný způsob nastavování vlastností ve všech/vybraných instancích
•
Bezpečnost (administrátor jediné instance může nevhodným zásahem zničit všechny ostatní)
Přesto však jde o směr dobrý, kterým se následně vydal projekt VMoodle popsaný v další části zprávy.
14
PROEFES
6.3
Virtualizace na úrovni kontejnerů (Docker)
V polovině roku 2014 byla vydána první oficiální stabilní verze projektu Docker (https://www.docker.com/). Docker je otevřenou platformou, která nabízí standardizované prostředí pro vývoj a testování nových či stávajících softwarových projektů. Pomocí speciálního konfiguračního jazyka mohou správci jednoduše vytvářet nové instance (nebo v terminologii Dockeru tzv. kontejnery), ve kterých je možné snadno pouštět a testovat jednotlivé verze produktů. Takto vyzkoušené řešení je pak velmi snadné distribuovat mezi další virtuální stroje, do cloudu nebo poskytovat vývojářům. Z technického hlediska jde o velmi lehkou formu virtualizace, kdy vše běží na původním systému (v tomto případně OS Linux) a jednotlivé kontejnery jsou od sebe bezpečnostně odděleny. Celé řešení tak budí zevnitř virtualizovaného kontejneru pocit, že běží na samostatném systému. Správci využívající platformu Docker pak mohou definovat bezpečnostní pravidla, co všechno bude kontejnerům umožněno. Pro potřeby LMS Moodle by toto řešení bylo vhodné zejména v případě, že by někteří uživatelé vyžadovali vyšší bezpečnost svých e-learningových platforem. Současně je to velmi vhodné pro vývoj, kdy vývojáři mohou dostat velmi přesnou kopii provozního prostředí a veškeré úpravy odladit nejprve v ní. Vzhledem k tomu, že komunita kolem projektu Docker je velmi aktivní, není těžké nalézt i konfigurační soubory pro Docker takové, které velmi jednoduše připraví funkční Moodle pro prvotní použití (např. https://github.com/s ergiogomez/docker-moodle). Takový model by mohl usnadnit bezpečnou instalaci Moodle na školách, které by sdílené instalace nechtěly, přesto by však neměly zkušenosti s instalací LMS Moodle. I přesto je však třeba znovu upozornit na to, že instalace je pouze úvodní a relativně jednoduchá část celé správy a využít Dockeru má zhruba ty samé výhody i nevýhody jako předchozí způsob sdílení/virtualizace.
moodle.ics.muni.cz
15
6.4
MOOSH
Možným spojovacím článkem pro automatizaci správy jednotlivých instancí uvnitř jinak nezávislých kontejnerů by za určitých okolností mohl být i projekt MOOSH, Moodle Shell (http://moosh-online.com).
Jeho schopnosti od doby úvodního vývoje projektu poněkud narostly, takže v současné době zvládá dobře následující kategorie operací:
•
Spravovat uživatele v Moodle a jejich role
•
Manipulace s kurzy (například přidávání kurzů, přihlašování uživatelů, zálohy)
•
Operace nad soubory uvnitř Moodle
•
Instalace rozšiřujících modulů i aktualizace samotného LMS Moodle
V případě, že by jednotlivé instance fungovaly v samostatných prostorech, MOOSH by po dalších úpravách jistě zvládal automatizované operace nad celou skupinou vybraných kontejnerů či instancí a během času by bylo možné k němu vytvořit webové rozhraní pro správu.
16
PROEFES
V současné době je podporován Moodle 2.6, přičemž některé operace v něm stále nejsou bezproblémové (http://moosh-online.com/ci).
7
Existující řešení přímo v LMS Moodle
Jak již bylo v textu zmíněno, oficiální vývojáři LMS Moodle prozatím žádné řešení pro snadné sdílení jedné instance vícero institucemi nenabídli. Neznamená to však, že by žádná řešení, která by se snažila tuto podporu implementovat, neexistovala. Kolem oficiální podpory multi-tenancy se vedou stále diskuze, jejichž úkolem je vyřešit celou řadu technický, praktických i bezpečnostních problémů. Podle posledních příspěvků v odpovídajících fórech zatím vítězí přístup pomocí mechanismu kohort, který však nebude v této zprávě rozebírán. V příštích odstavcích se místo toho pokusíme nastínit možné přístupy k problému sdílení instalace a virtualizace pro jednotlivé instituce právě v prostředí LMS Moodle. Ať již za pomoci standardních prostředků, nebo s využitím projektů třetích stran. Z produktů či modulů třetích stran se nám podařilo najít řešení Elis, Totara, IoMad a VMoodle, přičemž posledním dvěma bude věnován větší prostor v této zprávě. Řešení VMoodle jsme nakonec použili pro řešení projektu PROEFES, IoMad by mohl být výborným doplňkem pro instituce, které nevyžadují vyšší míru virtualizace a pocitu „vlastního“ e-learningového řešení.
7.1
Jedna instance LMS sdílená všemi
Tento model je poměrně často a úspěšně vyzkoušený v praxi. Jedná se o jednu instalaci LMS Moodle, ve které každý zúčastněný subjekt získává vlastní prostor. Uživatelé jsou společní pro celou instanci, jakákoliv bezpečnost je řešena na úrovni přístupových oprávnění do kurzů a kategorií. Ačkoliv takové řešení není špatné, neumožňuje detailnější míru personalizace celého LMS pro potřeby škol, jen obtížně lze využít případné řešení správy uživatelů, pokud by jej škola již měla. V kombinaci se speciální rolí Manažera
moodle.ics.muni.cz
17
(viz níže) jde však o řešení, které je přesto velmi funkční a za dodržení mnoha pravidel může jít o provozuschopný model. V rámci projektu PROEFES jsme takové řešení volili pro školy, které neměly zájem o vlastní instalaci, přesto si však chtěly vyzkoušet možnosti nových verzí LMS Moodle bez nutnosti starat se o jakoukoliv administraci.
7.2
Role Manažera vs. Správce
Ačkoliv se nejedná přímo o virtualizační řešení, jedna z cest ke sdílení jediné instalace LSM Moodle vede přes kategorie a speciální typ uživatelů. Moodle ve verzi 2.0 a vyšších získal novou roli, která se jmenuje Manager a doplňuje administrátorskou roli, která se oficiálně nazývá Site Administrator. Díky tomuto rozdělení dvou zásadních rolí je možné lépe přidělovat oprávnění v systému Moodle, tedy dávat jednotlivým menším správcům LMS Moodle pouze roli manažera, která sice nemá absolutní moc v systému, přesto však umožňuje dělat důležité změny a nastavení. Pokud se jedna instalace rozdělí na více částí pomocí kategorií, může každou část spravovat jeden manažer. Existuje neoficiální doporučení, které radí dělat většinu možných úprav nastavení LMS Moodle v roli manažera a roli administrátora využívat jen ve výjimečných případech. S tím lze v každém případě souhlasit, neboť vede administrátory Moodle k využívání principu nejnižších nutných oprávnění, považovanému za dobrou bezpečnostní praxi.
7.3
IoMad
Nyní se pojďme podívat na neoficiální rozšíření LMS Moodle, které má jméno IoMad a je k dispozici opět včetně zdrojových kódů. Autoři svému řešení věnují poměrně hodně času a v současnosti je již k dispozici podpora pro Moodle 2.8, poslední verzi v době aktualizace této zprávy. Hlavní vlastnosti, které IoMad přidává do klasického Moodle, se dají shrnout do následujících bodů:
18
PROEFES
•
Multi-tenancy, tedy sdílení jedné instance Moodle vícero institucemi
•
E-komerce — v tomto rozšíření přibyla možnost, aby klienti za přístup ke vzdělávacím lekcím platili — ať již přímo pro sebe, nebo spíše pro celé organizace
•
Licence — díky nim je možné omezit přístup do jednotlivých instancí dle množství uživatelů, času, po který smějí vstupovat do přístupných kurzů a času, kdy jim vyprší přístup do celého LMS
•
Lepší reporting, tedy hlášení o tom, jak jsou jednotlivé instance využívány
Základním principem IoMad řešení je přidání konceptu organizací, jejich oddělení a odpovídajících rolí, to vše cíleno pravděpodobně pro možnost nabízení komerčních kurzů v prostředí LMS Moodle. Od toho také bod zavedení e-komerce a licencí.
Co se týče instalace, jedná se víceméně o standardní způsob, velmi podobný jako u originálního LMS Moodle. Je tedy možné stáhnout celý zdrojový strom odpovídající dané verzi Moodle a ten následně nakonfigurovat naprosto stejně, jako by administrátor konfiguroval původní Moodle. Po instalaci pouze přibude v administrátorském bloku navíc sekce specifická pro IoMad. V něm je pak možné jednotlivé organizace, nové role i licence zadávat. Tyto organizace se v systému navzájem nevidí. Autoři vhodně vyřešili i skrývání zbytečných administrátorských možností v případě, že je uživatel pouhým členem organizace, případně pouhým školeným zaměstnancem. Může se to zdát jako drobnost, přesto však přehlednost uživatelského rozhraní je v tomto případě plusem.
moodle.ics.muni.cz
19
Trochu nešťastné je úvodní zvolené téma celého řešení, neboť vypadá jako lehce punkové, se snahou okamžitě zaujmout. Naštěstí je možné zvolit jiné téma (které však v nasazení na Moodle 2.8 lehce rozhodí vzhled), nebo je při profesionálním nasazení jistě možné upravit šablony tak, aby bylo vše dostatečně sladěné s některým z dodávaných vzhledů. Úvodní obrazovka administrativního panelu IoMad řešení také odkazuje na „dashboard“ (nástěnku) s dostatečně přehlednými akcemi. Na obrázku je dashboard v režimu hlavního administrátora celého Moodle. Je tedy možné vidět i záložky pro všechny myslitelné aktivity.
V tomto dashboardu je možné přehledně pracovat s každou vybranou „společností“, v našem případě by to mohly být školy a další zapojené instituce. Po nahrání uživatelů do hlavní instance, zpravidla se jedná pouze o (e-learningové) manažery jednotlivých společností, mohou tito uživatelé následně přidávat / nahrávat vlastní zaměstnance a přidělovat jim role v „jejich“ Moodle. Každý takto vytvořený uživatel se po přihlášení dostane právě jen do omezeného výhledu, který mu byl přidělen kombinací oprávnění hlavního správce Moodle a pak jeho vlastní organizace (či oddělení). Mechanismus licencí umožňuje hlavním správcům omezovat množství uživatelů, kteří přistupují k jednotlivým kurzům pod hlavičkou dané organizace, omezit jejich působení v kurzu nastavením času, případně převádět volná místa do jiných kurzů — tedy zhruba vše, co by se dalo očekávat od systému pro vnitřní vzdělávání firem spravovanému externí firmou.
20
PROEFES
To vše je doplněno podrobným reportingem, kdy si i organizace či její oddělení může přehledně zjistit, jak si zaměstnanci v průchodu kurzy vedou, zda je navštěvují pravidelně, případně zda je plní včas. Co řešení IoMad naopak neumožňuje, je mít uživatele v jednotlivých organizacích spravované jiným způsobem, než je přímý upload (např. LDAP). Dále neumožňuje větší možnosti přizpůsobení vzhledu. Každá organizace má možnost si přidat vlastní logo a lehce změnit barevné podání, což ne vždy musí být dostatečné. Z pohledu námi zamýšleného řešení, kdy jsme chtěli mít možnost přidělit jednotlivým školám i jejich vlastní subdomény, případně migrovat jejich domény a existující e-learningové systémy na naše virtualizované řešení, nebyl bohužel IoMad nejvhodnější volbou, neboť tuto variantu neumožňuje. Přesto se nám podařilo najít řešení, které nabízelo vše potřebné. Jedná se o VMoodle.
7.4
VMoodle
Pro vlastní implementaci projektu PROEFES jsme nakonec zvolili řešení VMoodle, volně dostupné a v současnosti již ke stažení i v oficiálním repozitáři zdrojových kódů na serveru GitHub.
moodle.ics.muni.cz
21
Základní požadavky na hledané řešení, které VMoodle naplnil, byly zhruba následující:
•
Umožnit zapojeným institucím (školám) mít vlastní subdoménu
•
Dát jim možnost plné správy vlastních instancí, přesto však s možností dohledu a správy z centrálního bodu
•
Měla-li by zapojená instituce vlastní, funkční správu uživatelů na bázi LDAP nebo OpenID, mělo řešení umožnit jeho integraci do námi nabízeného řešení
•
V případě potřeby vyjít vstříc při automatickém nastavování spravovaných instancí — umožnit nastavit konkrétní věc ve všech instancích najednou
Některé z těchto bodů se dají splnit i některými z technik popsanými dříve, nicméně VMoodle nabídl sjednocené řešení, a to formou modulu pro Moodle. Instalace celého řešení není ovšem zdaleka bezproblémová a komplikovanější je i držení tempa s vývojem hlavního Moodle. Aktuální řešení VMoodle podporuje pouze verzi 2.6, podpora pro verzi 2.7 je ve vývoji. Vlastní instalace totiž vyžaduje nejen dohrání modulu (což je v Moodle standardní operace), ale také úpravu některých systémových souborů formou tzv. patche, tedy záplaty. Vyžaduje trochu odbornější znalosti než např. instalace IoMad, což právě může být zdrojem problémů. Logika řešení VMoodle je založená na jedné hlavní instanci, z které se postupně dají odvozovat a vytvářet instance podřízené. Ty vznikají buď kopií instance mateřské, nebo je možné provést tzv. snapshot (aktuální obraz) některé z jiných instancí a ten použít jako předlohu pro nově vytvářenou instanci. To s sebou nese jisté výhody, kdy je možné naplnit instanci kurzy víceméně automaticky. Současně je třeba však dbát na to, aby v původní předloze nebyly např. nechtěné uživatelské účty. Během doby používání se nám osvědčilo mít jednu instanci právě jako zdrojovou, nepouštět do ní reálné uživatele a dodělávat drobné změny dle potřeby. Vytváření nové instance pak vypadá velmi podobně jako nastavování nové instalace Moodle. Je třeba uvést zkrácené jméno instance, které je současně registrované jako součást domény, cesty k datovým souborům a napojení na
22
PROEFES
databázi. VMoodle poté zajistí správné vytvoření konfiguračního souboru, jeho použití při přístupu na danou doménu a úvodní naplnění nové instance přesně dle předlohy. Je-li to žádoucí, vytvoří i autorizované klíče mezi mateřskou a nově vytvářenou instancí tak, aby spolu obě mohly komunikovat přes tzv. RPC, tedy vzdálené volání služeb. Toho se následně využívá pro hromadné operace nad vytvořenými instancemi. VMoodle také zajistí mechanismus tzv. Single Sign On pro uživatele z mateřské instance. Znamená to, že jednotliví uživatelé z hlavní instance se mohou bezproblémově přihlásit do vytvářených instancí, a to automaticky s administrátorskými právy. Tento způsob přihlašování je výborný v případě, že si správci klientské instance nějakým zásadním způsobem poškodí uživatelské účty, zruší oprávnění administrátora nebo poškodí autentizační mechanismy v jejich instanci Moodle. Jednotlivé vytvořené instance jsou přehledně zobrazeny v tabulce, která jednak ukazuje jejich jméno a stav, jednak i další technické údaje kolem nastavení jednotlivých instancí. Bohužel se během používání ukázala celá řada problémů a nedodělků v řešení VMoodle. Zpravidla jsou daná překotným vývojem oficiální Moodle a nedostatečným časem vývojářů jeho virtualizovaného vylepšení, místy poněkud nevhodně zvolenou architekturou a programátorskými prohřešky.
moodle.ics.muni.cz
23
Část chyb jsme opravili vlastními silami, část je nahlášená v oficiálním nástroji pro VMoodle (https://github.com/vfremaux/moodle-block_vmoodl e/issues) a čeká na své opravení. Autor celého řešení sice reaguje poměrně vstřícně, k opravě chyb se ovšem nedostává. Situaci navíc komplikuje fakt, že v současnosti je již Moodle ve verzi 2.8 a brzy bude vydána další. Podpora pro verzi 2.6 končí v květnu 2015. VMoodle by mohlo být potenciálně skvělé řešení, které ovšem táhne dolů celá řada chyb. Pro provoz virtualizovaných instancí se dá doporučit pouze tehdy, má-li tým jako jednoho z členů šikovného programátora, který se vyzná v útrobách systému Moodle.
8
Správa uživatelů
Poslední velká oblast, která se váže ke sdíleným/virtualizovaným instalacím a která si však vyžaduje mnohem komplexnější přístup, než na který bylo v projektu místo, je správa uživatelů (identity management). Ukázalo se, že jednotlivé školy často nemají vlastní správu uživatelů a do e-learningového systému tedy zavádějí uživatele ručně, za pomoci CSV souborů. Některé neměly ani sjednocené školní e-maily a využívaly soukromých e-mailů jednotlivých žáků, což s sebou neslo další problémy (přeplněné schránky, jen obtížné trasování, proč byl některý z e-mailů nedoručen, atd.)
24
PROEFES
Mnohem lepší a systémovější by bylo, kdyby se školám podařilo přejít buď na systém vlastních LDAP serverů, např. po vzoru řešení Eduroam, nebo využít řešení dalších, např. OpenID. Po dobré technické analýze by jistě bylo možné využití i některého akademického řešení pro správu gridových výpočetních platforem (PERUN, http: //perun.cesnet.cz/web/). V rámci projektu PROEFES jsme vyšli vstříc alespoň školám bez kvalitní správy uživatelů. Vznikl zde modul, který lépe kontroluje CSV používané pro vytváření uživatelů.
9
Další důležité otázky k vyřešení
Centrální správa webových systémů (nemusí jít nutně pouze o e-learningové), s sebou nese i další problémy, které je třeba precizně a systematicky vyřešit. Jedná se o vhodnou práci s bezpečnostními certifikáty (používanými na zabezpečení přenosů mezi prohlížeči uživatelů a vlastním LMS), správné nastavení a práce se zálohami (na úrovni serverů i dat uložených v rámci LMS) a v neposlední řadě i dobrá uživatelská podpora.
9.1
Certifikáty
Správa certifikátů je relativně jednoduchý úkon, který však v kontextu posledního roku získává na důležitosti. Správce certifikátů má za úkol hlídat jejich platnost, komunikovat s certifikační autoritou a správně zajišťovat obnovu certifikátů tak, aby nedošlo k nedostupnosti serverů. Pro řešení PROEFES jsme zvolili variantu tzv. hvězdičkových certifikátů, kdy jakákoliv subdoména v naší správě byla automaticky zajištěna jedním certifikátem. To významně zrychlilo zavádění jednotlivých nových instancí i jejich testování. Pokud by školy vyžadovaly vlastní domény hostované centrálně, bylo by třeba pro námi navrhované řešení sáhnout do konfigurace webového serveru (Apache, v našem případě) a nakonfigurovat tzv. SNI (Server Name Indication). To je
moodle.ics.muni.cz
25
podporováno od Apache 2.2.12 na straně serveru, takže zde by v tom nebyl zásadní problém. Co by však mohlo být problematické, je chybějící podpora tohoto mechanismu v Internet Exploreru na počítačích s operačním systémem Windows XP. Ten již sice není oficiálně podporován, ale na školách se stále používá. Z bezpečnostního hlediska je třeba upozornit na to, že v oblasti kolem certifikátů a knihoven, které obstarávají kryptografické operace, se v roce 2014 a úvodu roku 2015 objevilo několik zásadních zranitelností, které by profesionální správci neměli podcenit – Poodle, HeatBleed, BEAST a nově i FREAK (detaily např. na http://cyberwarzone.com/the-most-brutal-securi ty-bugs-freak-shellshock-poodle-heartbleed-and-beast).
9.2
Technická a uživatelská podpora
Opomíjenou stránkou virtualizačních řešení (zpravidla všech) je lepší hlášení chyb od uživatelů ke správcům. Se vzrůstající úrovní sdílení se může stát, že množství uživatelů hlásících chyby v systému přesáhne úroveň, která se dá jednoduše zpracovávat v e-mailové podobě. V projektu PROEFES jsme tedy vyvinuli lepší modul pro hlášení chyb, který umožňuje nejen snáze a rychleji doručit důležité informace od uživatelů k administrátorům (virtuální instance, použitý prohlížeč na straně uživatele, automatický snímek obrazovky s možností vyznačovat, kde se problém nachází), ale také obsahuje nejčastěji kladené dotazy a případná oznámení směrem k uživatelům, čímž do jisté míry může zmenšit množství duplicitně hlášených chyb. Úvod textu se též zmiňoval o náročnosti převodu Moodle z verze 1.9 na 2.x. Součástí projektu PROEFES je tedy i převodník, který s procesem převodu pomáhá a snaží se vyřešit celou řadu potenciálně problematických míst.
10
Závěr
Doufáme, že tato zpráva bude sloužit jako výchozí bod pro další podobné aktivity a usnadní podobným projektům jejich vznik i mnohem snazší provoz.
26
PROEFES
11
Použité zdroje 1. http://www.somerandomthoughts.com/blog/2014/01/27/re
view-iomad-for-moodle-part-1 2. http://www.cvedetails.com/vulnerability-list/vendor_
id-2105/product_id-3590/Moodle-Moodle.html 3. https://docs.moodle.org/28/en/Installing_Moodle 4. https://docs.moodle.org/28/en/Manager_role 5. http://www.infoworld.com/article/2609482/data-
center/data-center-review-puppet-vs-chef-vs-ansiblevs-salt.html?null 6. https://github.com/sergiogomez/docker-moodle 7. http://www.iomad.org 8. https://github.com/vfremaux/moodle-block_vmoodle/tr
ee/MOODLE_27_STABLE 9. https://www.digicert.com/ssl-support/apache-multiple-
ssl-certificates-using-sni.htm
moodle.ics.muni.cz
27
