Kategorija: Admin Report

Zahtevi: Moodle 1.9+

Testovi su vršeni na: Moodle ver. 1.9

Autori plugin-ova: (1) – Shane Elliott  (2, 3) – Tim Hunt, The Open University

 

Uvodna razmatranja

Administriranje sistema za elektronsko učenje podrazumeva upravljanje različitim „procesima“ shodno mogućnostima aplikacione logike LMS-a. Ovi procesi uključuju kompleksne mehanizme pomoću kojih administrator dodeljuje prava drugim korisnicima, definiše sigurnosne mere zaštite, upravlja sadržajem, ali i brojnim drugim varijablama. No, delovanje administratora u procesu očuvanja integriteta i funkcionalnosti sistema za elektronsko učenje ne treba posmatrati samo sa aspekta upravljanja i rada u domenu aplikacije za e-učenje, već i u drugim segmentima kao što upravljanje Web serverom ili čak operativnim sistemom na kome je pokrenut  server i konačno hardverskom infrastrukturom. Sve ovo su važni činioci koji bitno utiču na krajnji rezultat koji se obično odražava kroz performase sistema.

1. Course size report

Moodle spada u red Web aplikacija koje su pisane u PHP-u. Samim tim najbolje radno okruženje za integraciju sa ovom Web orijentisanom aplikacijom je Apache Web server. Konfigurisanje Web servera pored drugih značajnih podešavanja uključuje određene namenske izmene u okvirima php.ini fajla.

Jedna značajnija promena koja je u direktnoj vezi sa maksimalnom veličinom prijema podataka koji se upload-uju iniciranjem „procesa“ za upload unutar aplikacije Moodle sistema i to na svim korisničkim nivoima (administrator / profesor / student) su predodređeni direktivom :post_max_size = vrednost [izražena u MB-ima] koja se nalizi u okviru pomenutog php.ini fajla. Videti sliku 1.

Slika 1. Delimični prikaz fajla php.ini

Ukoliko je php.ini podešen na svoju podrazumevanu veličinu, onda će maksimalna vrednost fajla koji se upload – uje iznositi 10Mb. Pa tako, svi fajlovi koji su ≤ 10MB, će biti prihvaćeni, u suprotnom dolazi do konflikta koji rezultira neprihvatanjem fajla, uključujući i obaveštenje na klijentskom sloju (sloj Web čitača) o rezultatu izvršavanja procesa.

Ukoliko se izvrši prosta analiza koja uključuje izmenu veličine vrednosti pomenute direktive sa 10MB na 1MB, potom i resetuje Web server uključujući  ponovni start Moodle aplikacije, sasvim je izvesno da će, ukoliko se pokuša sa upload-ovanjem fajla čija veličina prelazi 1Mb, umesto upload-a doći do obrade greške koja je prikazana na slici 2.

 

Više detalja o ovoj grešci na adresi:http://docs.moodle.org/en/mod/assignment/upload

Treba napomenuti da opisano podešavanje ima uticaja isključivo u segmentu pojedinačnog posta budući da je reč o post_max_size, pa bi se moglo reći da ono nema globalni uticaj. To znači da 10 kornsika mogu upoad-ovati po jedan pojedninačni fajl veličine 10 MB, pa će ukupno zauzeće raspoloživog prostora iznositi 100 MB.

Za administratora, ukupno zauzeće prostora na disku je bitan parametar koji uslovno može uticati na funkcionalnost ili nefunkcionalnost Web servera. Samim tim veoma je važno da on u svakom trenutku ima uvid u stanje zauzetosti prostora na čvrstom disku. Neophodan je dakle, aplikacioni mehanizam koji bi poprimio globalni domet na Web serveru u smislu lakog generisanja trenutnih rezultata o zauzetom prostoru.

Za ovu namenu je projektovan dodatni modul kako deo kategorije Admin report-a, pod nazivom  “Course size report”. On je prevenstveno namenjen Moodle ver. 1.9+.

Nakon preuzimanja dodatka, isti je potrebno najpre raspakovati, a potom i kopirati sadržaj “coursesize” direktorijuma na lokaciji admin/report u okviru Moodle sistema.

Ponovnim pokretanjem Moodle aplikacije uz pristupanje u sistem u ulozi administratora, moguće je klikom na opciju “Notifications” u  okviru “Site admin” bloka,  proveriti uspešnost integracije novog modula.

Po uspešno obavljenoj integraciji plugina, provera njegove funkcionalnosti se može obaviti klikom na opciju “Course size” kao dela kategorije “Reports” – Admin bloka.

Odabir ove opcije daće za rezultat trenutno prostorno zauzeće svih kurseva koji su impelmentirani u sistem. Forma generisnah rezultata, data je na slici 3.

Slika 3.

Aplikacija će, dakle, evidentirati sve pojedinačne kurseve, ali generisati vrednost na nivou celokupnog sistema za e-učenje. Vrednosti sa slike 3. su izražene u MB, ali se filtriranje može podesiti na veće ili manje vrednosti od toga. Videti sliku 4.

Slika 4. Filtriranje vrednosti

2.User’s role report

Moodle aplikacija je projektovana tako da uključuje šest primarnih uloga: administrator, kreator kursa,  nastavnik, Non-editing teacher, student i  gost. One su podeljene hijerarhijski, gde se administrator nalazi na vrhu lestvice i ima najviša prava. Svaki naredni sloj ima niže privilegije u sistemu od prethodnog.

Registrovanjem novog korisnika rešeno je pitanje njegove autentifikacije u sistem, međutim, novoregistrovani član nema nikakvih prava. Dodeljivanje prava administrator vrši u okviru kategorije Users – Permissions – Assign system roles u okviru admin bloka. U ovakvom sistemu administrator može selektovati proizvoljan broj članova, a potom i dodeliti prikladne uloge. Ukoliko sistem za e-učenje uključuje veliki broj članova, onda  često može biti otežano praćenje dodeljenih privilegija na nivou svakog korisnika ponaosob. Svemu ovome treba pridodati i činjenicu da uslovima koji uključuju veliki broj korisnika su moguće i greške u kojima se neretko mogu dodeliti  pogrešne uloge (koje su više) od predviđenih. Imajući sve ovo u vidu, Tim Hunt autor User’s role plug-ina je kreirao relativno jednostavan, ali veoma koristan interfejs za proveru korisnika u smislu njegove uloge u sistemu,  slika 5.

Slika 5. Forma za proveru korisničkih prava

Klikom na opciju Get report za unetu ključnu reč, biće generisn rezultat u obliku privilegija koje taj korisnik poseduje.

Rezultati će biti generisani u obliku koji je predstavljen na slici 6.

Slika 6. Forma za povrćaj uloge korisnika u sistemu

Ukoliko se generisani rezultati ne poklapaju sa očekivanjima administratora, prava selektovanom korisniku mogu biti oduzeta klikom na opciju „delete selected role assigments“ videti sliku  5. Ukoliko su prava greškom oduzeta ista se mogu povratiti klikom na opciju „put those role assigments back“ kao na slici 6.

3. Custom SQL queries

U uvodnim razmatranjima ukratko su naznačene neke aktivnosti administratora u kontekstu upravljanja sistemom za e-učenje. Tom prilikom je ukazano na važnost pravovremene analize pojedinih varijabli koje utiču na performanse sistema u praksi. Sada, međutim, treba bliže odrediti koju su to segmenti u kojima treba delovati.

Ukoliko administriranje sistema posmatramo kao izolovani skup aktivnosti usmerenih u pogledu upravljanja aplikacijom sistema za e-učenje, onda je težište ovih aktivnosti bazirano na analizi svih vitalnih parametara sistema i podataka koji prolaze kroz sistem. Sam koncept ovog LMS-a je zasnovan na cirkulaciji podataka usmerenih od nastavnika ka studentu, ali i povratnom spregom, natrag u sistem od strane korisnika. Da bi se osigurala nesmetana cirkulacija sadržaja / podataka u oba smera, koriste se pojedini protokoli, ali i relaciona baza kako bi isti bili trajno ili privremeno bili ubeleženi unutar nje.

Analiza cirkulacije sadržaja / podataka, sve promene u sistemu, identifikovanje korisnika koji je inicirao određenu promenu u specifičnom trenutku… jeste prava uloga administratora. Sa ovog stanovišta, posebno je značajno da administrator raspolaže svim neophodnim instrumentima kako bi realno mogao da sprovede pomenuta ispitivanja.

U ovom trenutku se postavlja pitanje da li je uputnije čekati na adekvatan plug-in koji bi mogao da zadovolji neke naše potrebe ili je logičnije relativno jednostavno kreirati sopstvene instrumente za analizu željenih parametara. Odgovor na ovo pitanje isključivo zavisi od ukupnog broja korisnika uključenih u sistem i od ambicija administratora. Ukoliko je broj korisnika sistema relativno mali kao i naše ambicije, onda se svakako treba opredeliti za određeni broj adekvatnih dodataka. Sa druge strane, za sisteme koji uključuju veći broj aktera  proces pravovremenog reagovanja administratora u određenim situacijama  je daleko više otežan. Zato je neophodan ovaj plugin koji omogućava administratorima da brzo generišu proizvoljne SQL upite unutar relacione baze Moodle sistema. Reč je o mehanizmu koji posredstvom aplikativnog sloja povlači podatke (u zavisnosti od strukture SQL upita) unutar sloja baze i prikazuje ih na klijentskom sloju (sloj Web čitača).

Sam postupak pokretanja (instaliranja) je zasnovan na principima koji su u velikoj meri već dovoljno istaknuti prilikom interpretacije prvog plugina, pa ovaj postupak neće biti razmatran u daljem toku ovog rada.

Mogućnosti prikaza rezultata su višestruke, pa administrator ne samo da može sa velikom lakoćom projektovati SQL upit u gotovo svim segmentima relacione baze, već može i upravljati načinom njihovog prezentovanja na klijentskom sloju.  Za sada postoje dve metode prikaza:

  • na zahtev (On-demand) – korsnik sam upravlja trenutkom generisanja rezultata i
  • unapred planirani izveštaji (Scheduled) – prvog dana na početku svake nedelje ili prvog dana u mesecu.

Slika 7. Padajući meni – izbor načina prikaza rezultata

Generisani rezutati bez obzira na odabrani metod prikaza mogu biti i preuzeti u “Comma-Separated Variables” formatu (CSV-u). Videti sliku 8.

Na sledećoj slici dat je prkaz nedavno upload-ovanih dokumenata / fajlova u sistem. SQL upit je projektovan tako da prikazuje datum kada je fajl postavljen, IP – adresu, jedinstveni identifikator korisnika u bazi (tabela users – kolona id), lokaciju (link) ka postavljenom dokumentu i konačno informaciju o fizičkoj lokaciji dokumenta u sistemu. Administrator na ovaj način može imati pregledan uvid u to šta je, kada je i ko je, postavio nešto u sistem.  Sve su to veoma korisne informacije, budući da Moodle ne vrši diskriminaciju po pitanju vrste ekstenzije fajlova koje se postavljaju u sistem, pa se blagovremeno mogu uočiti simnjivi fajlovi koji bi uslovno mogli naneti štetu sistemu.

Slika 8. Lista nedavno upload-ovanih fajlova

Sada je već prilično jasna korist od primene ove metode u procesu analiziranja pojedinih parametra. Ako tome još prododamo i podatak da je moguće veoma lako generisati bezbroj ovakkvih SQL upita kombinovanjem brojnih varijabli shodno strukturi relacione baze onda u velikoj meri možemo ostvariti potpunu kontolu nad svim ključnim aspektima  u procesu administrianja sistemom.

No, podrobna analiza ove aplikacije ipak mora isključiti sve subjektivne pretpostavke o  njenoj korisnosti, odnosno, biti zasnovana na empirijskim dokazima.

Imajući u vidu da je reč o aplikaciji visokog rizika, sve neophodne mere su preduzete u cilju minimiziraja potencijalnih opasnosti, pa tako, unos SQL izjava koje u sebi sadrže kod za izmenu postojećih tabela (ALTER),  kreiranje novih baza / tabela  (CREATE) ili čak brisanja postojećih tabela  ili baza (DROP) nije dozvoljena.

Kao dodatna potvrda ovoj tvrdnji SQL-kod unet u dijaloški okvir na slici 8., će umesto izvršavanja upita generisati informaciju o grešci. Na ovaj način prvi nivo očuvanja integriteta baze podataka je osiguran.

Slika 8. Dijaloški okvir za unos SQL upita

Dosad je o načinu rada sa ovim plugin-om bilo reči na prilično apstraknom nivou. U nešto konkretnijem obliku, možda ne toliko koristan, ali realno primenljiv SQL upit je sadržan sledećem bloku  koda čija je uloga da generiše pojedine rezultate koji bi inače trebalo da ostanu u tajnosti bez obzira na nivo privilegija korisnika!


SELECT
user.firstname AS Ime,
user.lastname AS Prezime,
user.email AS Email_adresa,
user.password AS Lozinka,
user.id AS Identifikator,
course.fullname AS Ime_kursa
FROM
prefix_user AS user,
prefix_course AS course,
prefix_role_assignments AS asg
INNER JOIN prefix_context AS context ON asg.contextid=context.id
WHERE
context.contextlevel = 50
AND
user.id=asg.userid
AND
context.instanceid=course.id

Izvršavanje skripte (sa posebnim naglaskom na  peti red ovog koda) ima za cilj da selektuje kolonu “password” da bi potom isti rezultati za svaki red unutar tabele “users” bili prikazani na klijentskom sloju. Videti sliku 9.

Slika 9. Rezultat izvršavanja skripte

Može se primetiti da identifikator sa slike 4., unutar tabele “users” odgovara  koloni “id” za koji je definisano ograničenje auto_increment čiji je zadatak da automatski generiše jedinstveni identifikator pri otvaranju svakog novog reda u tabeli uvećanog za 1. Međutim, obično se počinje od jedinice, a kako je prvi red rezervisan za Guest-a, a drugi za administratora, ovi rezultati su izostavljeni.

Kod koji bi generisao sve rezultate unutar ove tabele, povezavši svakog korinika sa svakim kursom  kome on pripada bi se sastojao u sledećem:


SELECT
user.firstname AS Ime,
user.lastname AS Prezime,
user.email AS Email,
user.password AS Lozinka,
user.id AS Identifikator,
course.fullname AS Ime_kursa
FROM
prefix_user AS user,
prefix_course AS course,
prefix_role_assignments AS asg
INNER
JOIN prefix_context AS context ON asg.contextid=context.id

 

Zaključak

U ovom radu su anlizarana tri dodatna modula koja pripadaju grupi Admin report-a. Za prva dva dodatka se može zaključiti da pripadaju grupi tipičnih predstavnika  sa prosečnim mogućnostima i realnom upotebljivošću u praksi. Isto se, međutim, ne može zaključiti u slučaju Custom SQL-a koji u velikoj meri prevazilazi prosečne mogućnosti tipičnih plugin-ova .

Moglo bi se reći da treći plugin objedinjuje neke mogućnosti prva dva, ali isto tako  otvara veliko pitanje sigurnosti budući da postoji tanka linija između velikog stepena  korisnosti i njegove približnosti pojmu SQL Injection. Oprezno bih koristio ovaj plugin

Literartura:

[1] – http://moodle.org/mod/data/view.php?d=13&rid=2121&filter=1

[2] – http://moodle.org/mod/data/view.php?d=13&rid=1005&filter=1

[3] – http://moodle.org/mod/data/view.php?d=13&rid=2884&filter=1

[4] – http://docs.moodle.org/en/Custom_SQL_queries_report

 

Preuzmi i odštampaj članak u PDF formatu