chmod -R 777, vRAM e vCPU


Cos’hanno in comune un comando *NIX e le caratteristiche di una macchina virtuale?

Dei fornitori pigri.

Quando il fornitore o l’installatore di un software o di un servizio non riesce a farlo funzionare su *NIX, la prima cosa che fa è un bel chmod -R 777 su tutta la struttura ad albero dell’installazione.

Alcune volte funziona, altre volte non funziona, ma se non funziona oramai il danno è fatto e tutti i file rimangono in 777. Se funziona, da quel momento l’installatore darà quel comando come parte della procedura di installazione.

Su Windows non è diverso: spesso i fornitori di software chiedono di disabilitare l’antivirus (o di utilizzarne uno inutile) o chiedono di eseguire tutti i servizi e i programmi con privilegi elevati, magari solamente perché chi  scrive il software non ha ancora letto le linee guida di Microsoft uscite 15  e più anni fa che suggeriscono di non andare a scrivere nulla in %ProgramFiles%, ma usare invece %ProgramData%.

Rendiamoci tutti conto che queste abitudini finiscono per minare la sicurezza della piattaforma su cui viene installata una procedura.

Se un fornitore vi chiede di abbassare la sicurezza delle vostre macchine, chiedetegli di mettere nero su bianco la richiesta e di assumersi la responsabilità di quell’azione, questo di solito induce il fornitore a ponderare meglio le sue azioni.

L’evoluzione dell’annullamento della sicurezza la sto vedendo a livello di richieste di macchine virtuali.

Dall’inizio dell’anno mi sono capitate molte richieste di fornitori di clienti di macchine virtuali con vHardware assurdamente potenti per lo scopo della VM.

In questo caso ho risolto alcune volte chiedendo conto al fornitore delle specifiche. Per l’installazione di un software per cui mi venivano chieste un numero astronomico di vCPU ho richiesto il link alla documentazione del software per scoprire che la configurazione consigliata era la metà esatta di vCPU e vRAM.

Altre volte ho tacitamente ridotto le caratteristiche richieste senza che il fornitore si accorgesse della riduzione e senza compromettere il funzionamento della procedura.

Anche qui val la pena sempre di chiedere conto al fornitore delle sue richieste in quanto spesso semplicemente sparano alto per darsi un po’ di tono.

Una politica accomodante che evita lo scontro in caso di richiesta di 8 vCPU e 16 Gb di vRAMpotrebbe essere “partiamo con 2 vCPU e 8 Gb di RAM e teniamo il sistema sotto osservazione”. Poi non osservate nulla e vi accorgerete che non solo il sistema funziona benissimo, ma non arriva mai a consumare 8 Gb.


3 risposte a “chmod -R 777, vRAM e vCPU”

  1. Il problema del chmod 777 è esattamente quello che dici tu. Il problema della richiesta assurda di risorse invece è spesso un problema diverso. Il fornitore non è pigro, è paraculo. Vuole essere sicuro che se (o quando, visto come è scritto il software oggi) la sua applicazione si dimostrerà lenta come una lumaca morta, potrà dare la colpa a te che non hai rispettato le richieste hardware.

    Richieste hardware assurde erano nella norma già da anni sull’hardware fisico. Un gestionale che gira su windows con 5 client in RDP? 2 xeon, 32 Gb di ram e dischi SAS 15k in raid 10, altrimenti e` troppo lento. Due siti in croce su Ubuntu (con apache e drupal)? 2 xeon, 32 Gb di ram, 600 gb di disco SAS 15k. Facendo così, sono ragionevolmente sicuri di fare pagare al cliente (in hardware) l’incompetenza dei programmatori che non sanno scrivere software decente. Oppure semplicemente si assicurano che il cliente non possa mai dire “è troppo lento”. Oppure, se il cliente dice “voi siete matti, ci metto metà delle risorse che chiedete”, dopo qualsiasi problema sarà sempre colpa delle risorse insufficienti.

    Così per la cronaca, sulla macchina di Drupal che ho indicato sopra ho piallato tutto, messo su Proxmox Virtual Environment, e installato una decina di VM fra le quali un mail server, un firewall, un web server con 5 siti in wordpress, un database server con PostgreSQL, un paio di vm Windows server con un applicativo scritto in azienda, un server Asterisk per 40 utenti, e ho ancora spazio disco, ram, e cpu liberi.


  2. […] Poi non osservate nulla e vi accorgerete che non solo il sistema funziona benissimo, ma non arriva mai a consumare 8 Gb.

    Vedo che la convergenza evolutiva ci ha portato in maniera naturale a lavorare tutti con gli stessi principi di base 🙂

  3. Il classico problema di molti fornitori che preferiscono fare le cose male e guadagnarci di più, rischiando però di perdere un sacco di clienti o di rovinargli qualcosa (e fargli spendere altri soldi), anziché fare le persone serie ed adattare le cose secondo linee guida.

    Soprattutto il fatto delle specifiche richieste del fornitore fa infuriare, che ci vuole a dire che “servirebbero tot cose ma consiglio di prendere tot+1 per andare sul sicuro e non rischiare di spendere più soldi”?

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *