Product SiteDocumentation Site

3.2. Partizionare il sistema

3.2.1. Scegliere uno schema di partizionamento intelligente

Scegliere uno schema di partizionamento intelligente dipenderà da come verrà usata la macchina. È buona regola creare delle partizioni sufficientemente grandi e prestare attenzione ai seguenti fattori:
  • Any directory tree which a user has write permissions to, such as e.g. /home, /tmp and /var/tmp/, should be on a separate partition. This reduces the risk of a user DoS by filling up your "/" mount point and rendering the system unusable (Note: this is not strictly true, since there is always some space reserved for root which a normal user cannot fill), and it also prevents hardlink attacks. [2]
  • Ogni directory di dimensione variabile es. /var (specialmente /var/log) deve stare su una partizione separata. Attenzione, su un sistema Debian, dovreste creare la directory /var leggermente più grande di altri sistemi, perché i pacchetti scaricati (nella cache di apt) vengono conservati in /var/cache/apt/archives.
  • Tutte le directory dove volete installare del software che non appartiene alla distribuzione devono stare in partizioni separate. Secondo File Hierarchy Standard (Gerarchia Standard dei File system) queste directory sono /opt oppure /usr/local. Se queste directory stanno su partizioni separate, non verranno cancellate se reinstallaste di nuovo Debian.
  • Dal punto di vista della sicurezza è importante cercare di mettere i dati statici in partizioni proprie, montate in sola lettura. Meglio ancora se questi dati vengono messi su supporti di sola lettura. Vedete più avanti in questo capitolo per maggiori dettagli.
Nel caso in cui gestiate un mail server è importante avere una partizione separata per la directory spool delle mail. Gli utenti remoti (sia consapevolmente che inconsapevolmente) possono riempire la directory mail spool (/var/mail o /var/spool/mail). Se la directory spool è in una partizione separata, questa eventualità non bloccherà il sistema . Altrimenti, se la directory spool è sulla stessa partizione di /var, il sistema avrà gravi problemi quali: non potrete creare i file di log, non potrete installare pacchetti aggiuntivi e dei programmi (se usano la directory /var/run) avranno problemi a partire o verranno rallentati.
Inoltre, per le partizioni per le quali non siete sicuri dello spazio che occorre, è preferibile installare Logical Volume Manager (lvm-common ed i pacchetti binari per il vostro kernel, questi possono essere lvm10, lvm6, oppure lvm5). Usando lvm si possono creare gruppi di volumi che possono occupare più volumi fisici multipli.

3.2.2. Selezionare il file system appropriato

During the system partitioning you also have to decide which file system you want to use. The default file system[3] selected in the Debian installation for Linux partitions is ext3, a journaling file system. It is recommended that you always use a journaling file system, such as ext3, reiserfs, jfs or xfs, to minimize the problems derived from a system crash in the following cases:
  • Per i computer portatili, in tutti i file system installati. In questo modo se le batterie si esaurissero inaspettatamente o se il sistema si bloccasse per una questione relativa all'hardware (come nel caso della configurazione di X, che è piuttosto comune) la perdita di dati durante un riavvio hardware sarebbe meno probabile.
  • Per i sistemi in produzione che registrano grandi quantità di dati (come i server di posta, i server ftp, i file system di rete...) si raccomanda un file system journalling sulle partizioni interessate. In questo modo, in caso di crash del sistema, il server impiegherà meno tempo a riavviarsi e controllare i file system, inoltre la perdita di dati sarà meno probabile.
Lasciando da parte le discussioni sulle prestazioni dei file system journalling (visto che talvolta possono trasformarsi in guerre di religione), è meglio, generalmente, usare il file system ext3. Il motivo è che questo è compatibile all'indietro con ext2, così se si dovessero presentare problemi con il journalling, è possibile disabilitarlo e avere comunque un file system funzionante. Inoltre, in caso si debba ripristinare il sistema con un dischetto di avvio (o CDROM) non serve un kernel modificato. Se il kernel è un 2.4 il supporto per ext3 è già  disponibile, se il kernel è un 2.2, pur perdendo le caratteristiche del journalling sarete in grado di avviare il file system. Invece, nel caso stiate usando altri tipi di file system journalling potreste non essere in grado di ripristinare, a meno che non abbiate un kernel 2.4 o 2.6 con i moduli necessari all'avvio già compilati. Se avete un dischetto di salvataggio con un kernel 2.2 potrebbe essere ancora più difficile accedere a reiserfs o xfs.
In ogni caso, l'integrità dei dati potrebbe essere meglio garantita da ext3 visto che esegue un file-data journalling mentre gli altri eseguono soltanto il meta-data journalling, vedete in http://lwn.net/2001/0802/a/ext3-modes.php3.
Notice, however, that there are some partitions that might not benefit from using a journaling filesystem. For example, if you are using a separate partition for /tmp/ you might be better off using a standard ext2 filesystem as it will be cleaned up when the system boots.


[2] A very good example of this kind of attacks using /tmp is detailed in http://www.hackinglinuxexposed.com/articles/20031111.html and http://www.hackinglinuxexposed.com/articles/20031214.html (notice that the incident is Debian-related). It is basicly an attack in which a local user stashes away a vulnerable setuid application by making a hard link to it, effectively avoiding any updates (or removal) of the binary itself made by the system administrator. Dpkg was recently fixed to prevent this (see http://bugs.debian.org/225692) but other setuid binaries (not controlled by the package manager) are at risk if partitions are not setup correctly.
[3] Since Debian GNU/Linux 4.0, codename etch