BlackBoard – Disaster recovery

Cu subtitlul: Ești sigur că ți-ai făcut copiile de siguranță astăzi?

Sau: Cum o problemă stupidă poate provoca un dezastru major.

În UAIC s-a implementat de mult un sistem de e-learning care are la bază BlackBoard, produsul cu cea mai mare cotă de piață din domeniu. Scump … dar bun. Tot cam în aceeași perioadă s-au angajat și oamenii pentru a administra o astfel de structură.

De câțiva ani buni experimentăm noi și noi metode de e-learning… cum spun unii, sistem de asistare a educației cum îi spunem noi. Probabil cea mai grea parte a acestui proces este determinarea și implicarea într-o astfel de activitate. Dar când lucrurile sunt puse oarecum la punct și procesul este în curs de dezvoltare permanentă, apare o eroare!

Când astfel de erori apar din vina sistemului, a producătorului sau alte cauze naturale, ai pe cine să dai vina. Când erorile vin din hacking sau rea voință ai și niște vinovați respobilizabili. Dar când erorile apar din nerespectarea unor proceduri simple de operare, atunci nu poți să mai spui nimic. Revii la filosofia iobăgiei românești, ridici din umeri și: Asta este!

Pornind totuși de la principiul că Lucrurile sunt mai simple decât par o să fac în continuare o scurtă istorisire tehnică asupra a ceea ce s-a întâmplat.

1. Administratorul BlackBoard (AB) a venit la mine pentru a îmi comunica faptul că nu se mai pot loga utilizatorii în sistem pentru că s-a decis el să modifice pagina de Login.

1.A. Am încercat și eu această acțiune și într-adevăr nu se întâmpla nimic.

1.B. L-am sfătuit să studieze problema și să o rezolve.

2. A doua zi AB a venit din nou la mine și mi-a spus că a studiat problema și că nu își dă seama.

2.A. I-a spus să consulte jurnalele.

2.b. I-am spus să deschidă un tiket în pagina de suport on-line.

3. A treia zi a venit și mi-a spus că cei de la suport i-au dat o rezoluție care nu mergea.

3.A. Am verificat și eu soluția propusă de suport și nu avea nici o legătură cu realitatea.

3.B. I-a spus AB să citească jurnalele.

4.5. Zilele 4 și 5 au fost weekend, timp în care AB nu lucrează.

6. AB vine și spune că tot nu a găsit nici o soluție și că nu înțelege sistemul.

6.A. Am luat direct legătura cu suportul pentru ajutor.

6.B. Am primit un răspuns “profesionist”: Suportul dorea acces direct pe server.I-am dat acces pe server. Suportul își terminase tura și avea să se uite a doua zi.

7. Suportul nu a intrat a doua zi și a transmis e-mail că nu poate accesa serverul remote.

7.A. [:)] Era clar că trebuia să aplic o soluție radicală.

7.B. După terminarea programului de la serviciu și de tată, după ora 22 în loc să-mi fac programul de soț m-am apucat de rezolvat serverul.

Înțelegerea soluției.

1. Ca orice aplicație Web BlackBoard este structurat pe 3 straturi: Interfața, aplicația și persistența.

Da e destul de ciudat să se folosească Tomcat ca server de aplicații, fiind cunoscut că și IIS poate face acest lucru, iar cei mai mulți folosesc Tomcat direct ca server Web.

2. Pentru a rezolva orice problemă trebuie întâi să citești jurnalele (logurile). În modelul nostru trebuie să citești 3 jurnale. Scuze 4, pentru că multe jurnale sunt stocate direct în Event Viewer-ul din Windows.

Cât îți ia să citești jurnalele respective? O oră? Două? Treei?!

Răspunsul este depinde. Depinde de cum ți-ai configurat infrastructura.

3. Beneficiul major al virtualizării este că poți face oricând un snapshot al mașiinii virtuale. Toată implementarea de mai sus este stocată în mașini virtuale.

4. Soluția: Așa că pentru a analiza mai lejer logurile, am făcut o copie a mașinii virtuale, după care am șters toate logurile:

• Event Viewer-ul din Windows
• Jurnalele de SQL Server nu am știut cum să le șterg
• Jurnalele de IIS din C:\WINDOWS\system32\LogFiles. Sigur trebuie oprit serviciul cu iisreset /stop.
• Oprite serviciile de BlacKBoard (bb-tomcat și bb-colab) și șterse toate jurnalele din: disk:\blacboard\logs

Pasul următor a fost startarea pe rând a serviciilor: SQL – citit logurile, IIS – citit logurile,bb-tomcat – citit logurile, bb-colab – citit logurile.

Surpriză: Nici o eroare!

Totul funcționa perfect numai că userii nu se puteau loga în continuare în sistem.

Reluăm modelul:

• Baza de date nu dă eroare!
• Serverul de aplicații nu dă eroare!
• Serverul de Web nu dă eroare!

Dar clientul nu se conectează. Deci clientul ia contact pentru prima dată cu interfața… problema trebuie tratată invers: de la interfață la baza de date.

Nici o eroare în jurnale… dar nici alte informații. Ce verifici următorul lucru?Unde se salvează logurile site-ului web?

Supriza 2:Logurilede IIS pentru site-ul web al BlackBoard-ului nu se salvează implicit în system32\logs ci în S:\blackboard\logs\httpd !!!

O înregistrare de log arată cam așa:

#Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2009-12-09 22:22:46 W3SVC2 127.0.0.1 GET / – 80 – 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;+Trident/4.0;+.NET+CLR+1.1.4322;+
.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;+.NET+CLR+3.0.04506.648;
+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 301 0 0
2009-12-09 22:22:46 W3SVC2 127.0.0.1 GET /images/ci/logos/GatewayButtons_gradient.gif – 80 – 127.0.0.1 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.2;
+Trident/4.0;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.30;
+.NET+CLR+3.0.04506.648;+.NET+CLR+3.0.4506.2152;+.NET+CLR+3.5.30729) 301 0 0

Ciudat, nu?Trebuie să ai putere pentru a putea citi un astfel de fișier, nu?

Da, dar dacă imporți logul în Excel trebea e mult mai simplă pentru că poți face un simplu filtru și vezi că pe coloana sc-status apare de multe ori mesajul 301. Care nu este 404 sau 401, erori bine cunoscute din IIS.

301înseamnă conform site-urilor de documentație: Moved Permanently
Asta înseamnă că site-ul nu mai este unde este pentru că a fost mutat. Ba nu aș spune eu. Este tot acolo! Adminul nu a modificat site-ul IIS și nimic altceva… ci doar un simplu fișier.

Privind cu atenție ce se întâmplă în browser… mi-am dat seama că de fapt în momentul în care se apăsa butonul Login adresa se modifica din HTTP în HTTPS! Dar în IIS nu era configurat HTTPS!!!

Ulterior am identificat faptul că adminul specificase din interfața grafică a BlackBoard că site-ul va face autentificarea în HTTPS, ignorând documentația de rigoare care spunea că este nevoie de configurarea IIS în mod simultan.

Nice! În 2 minute am configurat un certificat, SSL în IIS și gata!

Învățăminte în loc de concluzii:

1. Citește documentația!
2. Fă un backup înainte de a face orice configurare!
3. Fă orice configurare în mediul de test și după aia aplică în productiv!
4. Spune-i suportului să-ți ceară logurile!
5. Identifică unde sunt salvate logurile!
6. Citește cu atenție logurile!
7. Dacă ai o problemă, dedică tot timpul pentru a o rezolva.

Lucrurile sunt mai simple decât par… dar trebuie să le vezi (înțelegi) în ansamblu și cu claritate!