Mai putin practica in sensul ca nu poti sa faci un upgrade la
firmware-le la un storage sau la switchuri FC cand vrea muschiul tau
(chiar daca in teorie se poate face fara service interruption) - cel
putin nu la fel de usor pe cat dai upgrade la jre pe masina ta (mai ales
daca l-ai dat deja si ti-ai dat seama dupa ca nu mai ai acces la consola
de management).
In schimb masini virtuale poti sa le deploaiezi "din poignet" fara vreun
impact.



Andrei Pascal wrote:
> Aia cu "mai puțin practică" e discutabilă. La o versiune mai veche de
> ILOM-uri au găsit ai noștri niște memory leakage-uri care trimiteau ILOM-ul
> în bălării și era nevoie de ILOM reset la o săptămână-două... :D
> 
> 2014-11-25 13:05 GMT+02:00 Dan Nae <d...@roedu.net>:
> 
>> Subscriu(cu top post) la ultimul punct, noi avem masini virtuale "de
>> management" cu versiuni antice de java pentru problemele de genul asta
>> (cu care evident nu te dai pe net).
>> O alta solutie (mai putin practica) e sa upgradezi firmware-ul la
>> echipamentul care nu mai merge, in cele mai multe cazuri noile versiuni
>> de firmware merg cu noile versiune de javra.
>>
>>
>> Vali Dragnuta wrote:
>>> 1.Ce ai patit tu e o problema care nu isi are originea doar in java.
>>> Pe de-o parte, din cauza unor buguri mai vechi in java care s-au lasat
>>> cu ceva 0-days cu oarece succes, browserele au inceput sa chitzaie daca
>>> te prind cu jre-uri mai vechi si pe care le considera nesigure. Din
>>> cauza asta nu poti sa-ti folosesti java mai veche cu care toolurile de
>>> administrare functionau. Nu am cautat, dar e posibil sa existe in
>>> browserul tau preferat ceva setare hidden - sau alternativ un plugin -
>>> care sa inhibe warningul pentru jre vechi -permitindu-ti astfel sa
>>> folosesti un jre convenabil scopului tau;
>>>
>>> 2.A doua problema este ca de la versiuni de java ceva mai noi, runtimeul
>>> verifica daca appletul/codul pe care vrei sa-l rulezi este semnat.
>>> Daca este semnat si certificatul poate fi validat, atunci va functiona
>>> totul as expected, daca nu atunci in functie de setari ori blocheaza cu
>>> totul appletul ORI ii restrictioneaza accesul, spre exemplu nu-i da voie
>>> sa deschida socketi - ceea ce probabil ti se intimpla tie.
>>> Ai ori alternativa de a whitelista fiecare site la care te conectezi si
>>> sa-l declari ca trusted, SAU (si asta mi se pare mai elegant) sa iti
>>> importi certificatele toolurilor de administrare pe toate statiile de la
>>> care folosesti consola aia de administrare. Deployment automat de
>>> certificate poti face in ziua de astazi destul de lejer. Java va valida
>>> certificatele prezentate si contra listei de CA-uri din sistemul de
>>> operare.Poti in principiu sa-ti faci un bundle de certificate pe care
>>> sa-l poti instala automat pe toate statiile relevanta.
>>>
>>>
>>> 3. A treia potentiala problema este data de incompatibilitati
>>> inevitabile intre versiuni. Daca consola ta a fost initial facuta sa
>>> functioneze cu java 1.5 si intre timp tu incerci sa rulezi cu 1.8 sint
>>> ceva sanse ca unele clase, unele interfete sa se fi obsoletat si cum e
>>> normal sa nu mai functioneze pe versiuni noi.
>>>
>>> In fine, as putea sa-ti sugerez sa-ti instalezi intr-o locatie
>>> alternativa o versiune mai veche de browser + javele aferente astfel
>>> incit pentru administrarea acelor tooluri sa folosesti doar comboul de
>>> browser mai vechi + jre mai vechi.
>>>
>>>
>>>
>>> _______________________________________________
>>> RLUG mailing list
>>> RLUG@lists.lug.ro
>>> http://lists.lug.ro/mailman/listinfo/rlug
>>
>> _______________________________________________
>> RLUG mailing list
>> RLUG@lists.lug.ro
>> http://lists.lug.ro/mailman/listinfo/rlug
>>
> 
> 
> 

_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Raspunde prin e-mail lui