slacky.eu

Buongiorno a tutti, ho recuperato un vecchio atom con il quale ho realizzato un piccolo server casalingo per svariati usi. Sono un bel po' pigro ultimamente e avevo optato per FreeNas, ma poi ho scoperto che gira solo sui 64bit con almeno 8GB di RAM consigliati (questa vorrei me la spiegassero).
Perciò ho fatto tutto con slackware ma sempre perchè sono pigro, ma in realtà la curiosità non si è assopita del tutto ho pensato di crearmi una piccola app php per amministrarlo (no...webmin è troppo dispersivo).
Il primo problema ovviamente è far si che il php esegua comandi da root in modo 'sicuro' usando sudo.
Inizialmente avevo pensato di mettere l'utente con cui gira il php nel file sudoers in modo che non venga richiesta alcuna password.
Per rendere il tutto piu' sicuro ho poi pensato che visto che ho bisogno di un login per entrare nell'app sfruttare quello dell'utente root.. salvare la password crittata in un cookie e riusarla per lanciare il comando sudo con la password.

Secondo voi è una buona idea?!?! Vi è mai capitata una cosa del genere?!!? Se si.. come avete fatto!??!

Ciau

Non rispondo alla tua domanda ma, se sei pigro, potresti usare SMS (Super Mini Server), che è basato su Slackware, funziona bene, c'è sia a 32 che a 64 bit, però usa Webmin.

Su freenas.org leggo

* FreeNAS no longer supports 32-bit hardware. The last FreeNAS Release with 32-bit hardware support was FreeNAS 9.2.1.9. http://download.freenas.org/9.2.1.9/RELEASE/x86/ This release also supported the UFS filesystem. Deployments on 32-bit hardware using UFS had lower hardware requirements of a 4GB boot device and 4GB of RAM. PLEASE NOTE that further security and stability updates to the 9.2.1.x branch are not guaranteed.

Quindi c'è una versione a 32 bit, non garantiscono però futuri aggiornamenti
Altra cosa interessante che ho trovato è la spiegazione del perché sono richiesti così tanti GB di RAM.

The best way to get the most out of your FreeNAS™ system is to install as much RAM as possible. If your RAM is limited, consider using UFS until you can afford better hardware. ZFS typically requires a minimum of 6 GB of RAM in order to provide good performance; in practical terms (what you can actually install), this means that the minimum is really 8 GB. The more RAM, the better the performance, and the FreeNAS™ Forums provide anecdotal evidence from users on how much performance is gained by adding more RAM. For systems with large disk capacity (greater than 6 TB), a general rule of thumb is 1GB of RAM for every 1TB of storage.

Saluti,
MuRdOcK

miklos ha scritto:Sono un bel po' pigro ultimamente e avevo optato per FreeNas, ma poi ho scoperto che gira solo sui 64bit con almeno 8GB di RAM consigliati (questa vorrei me la spiegassero).

Come ti ha già scritto Murdock gli 8GB derivano dall'uso di ZFS.
Tuttavia c'è da notare che la regola 1GB di RAM per ogni TB di storage vale SOLO nel caso in cui la pool ZFS abbia attiva la deduplicazione.
In sostanza se sulla tua pool ZFS non hai la dedup attiva puoi anche avere un solo GB di RAM. Al massimo in condizioni del genere l'unico accorgimento sarebbe di tweakare la ARC Cache per mettere un tetto ai consumi di RAM libera da parte del file system.
Quindi il limite minimo degli 8GB è puramente teorico e basato sull'idea di poter sfruttare tutte le funzionalità di ZFS.

Tra l'altro il rapporto RAM/storage non è nemmeno una cosa che hanno inventato quelli di FreeNAS, ma è stato stabilito da Jeff Bonwick (creatore e ingegnere capo del team ZFS in Sun Microsystems) proprio riguardo l'uso della funzionalità di dedup.

Certo, c'è da dire che in un NAS la deduplicazione può essere un'arma vincente, specie se combinata con la compressione; tuttavia prima ancora di usarla ci sono delle considerazioni da fare:
1) quanta ridondanza effettiva c'è;
2) quanto storage si ha a disposizione della propria pool;
3) quante risorse (cpu e memoria) si hanno nel NAS;

La dedup consuma molto processore e memoria ed è un'operazione che avviene in I/O (sì, la dedup in ZFS avviene online) e che rimane persistente per tutta la durata della presenza della pool.
Ovvero finché la pool non viene esportata (ergo, smontata) ZFS continuerà a monitorare la ridondanza dei dati e a procedere alla loro deduplicazione.

Il che vuol dire che se non si ha una REALE necessità di deduplicare ciò che si otterrà sarà solo un deterioramento delle prestazioni a fronte di un guadagno inesistente.
Per stabilire se c'è o meno la necessità di deduplicare si usa e si controlla il risultato finale.
Se il punteggio risultante sarà inferiore a 2 allora è meglio NON deduplicare, in quanto la ridondanza è talmente poca che non ne vale la pena.
Se il punteggio è superiore o uguale a 2 allora si può prendere in considerazione l'idea di deduplicare il dataset (il subvolume, per dirla in termini di Btrfs) più pieno di dati e che quindi è più prono all'avere duplicati. Sì, avete letto bene: il dataset, non la pool. Utilizzare la dedup su una pool intera è folle, a meno di casi (rari) in cui è necessario farlo.

In ogni caso, dedup o meno, se si ha la possibilità di espandere la RAM entro i limiti supportati dalla scheda madre e dal processore è meglio.
ZFS usa tanta RAM quanta ne trova nella macchina per darla in pasto alla ARC Cache, quindi averne il più possibile permette al file system di essere più prestante (+ cache == + velocità in fase di lettura).


Sul fatto di girare solo a 64-bit anche questo credo che c'entri con l'uso di ZFS.
ZFS a 32-bit è da sempre considerato non sicuro per via del fatto che è un file system a 128-bit e progettato direttamente per lavorare in ambienti a 64-bit con enormi quantitativi di memoria, processori e dischi (configurazioni Mirror/RAID in particolar modo).

grazie a tutti per le esaurienti spiegazioni anche se mi avete sempre più convinto che nn ho bisogno di un NAS così sofisticato nel frattempo ho ipotizzato una possibile soluzione al mio problema(nn più tramite sudo, ma piuttosto il classico comando su) che appena definita vi proporro...nn sia mai nasca qualcosa di buono